카테고리 없음

프로그래밍 면접질문대비 스터디 3주차

Lim임 2026. 4. 21. 13:23

면접 준비 3주차

CS

1. OSI 7계층과 그 존재 이유, TCP/IP 4계층에 대해 설명해보세요.

OSI 7계층이란?

OSI(Open Systems Interconnection) 모델은 네트워크 통신을 7개의 계층으로 나눈 표준 모델입니다.
각 계층은 독립적인 역할을 가지며, 바로 위아래 계층과만 통신합니다.

OSI 7계층이 존재하는 이유

표준화: 서로 다른 회사, 운영체제, 장비 간 통신이 가능하도록 공통 규약을 정의합니다.
모듈화: 특정 계층에 문제가 생기면 그 계층만 수정·교체할 수 있어 유지보수가 용이합니다.
추상화: 개발자가 하위 계층의 물리적 구현을 몰라도 상위 계층에서 통신 기능을 사용할 수 있습니다.

계층	이름	역할	예시
7	응용(Application)	사용자와 직접 상호작용	HTTP, FTP, DNS
6	표현(Presentation)	데이터 인코딩/압축/암호화	SSL, JPEG, ASCII
5	세션(Session)	통신 세션 관리 (연결 유지/종료)	NetBIOS
4	전송(Transport)	데이터 신뢰성, 흐름 제어, 포트 관리	TCP, UDP
3	네트워크(Network)	IP 주소 기반 라우팅	IP, ICMP
2	데이터링크(Data Link)	MAC 주소 기반 노드 간 통신, 오류 검출	Ethernet, Wi-Fi
1	물리(Physical)	비트를 전기/광신호로 변환	케이블, 허브

TCP/IP 4계층

실제 인터넷에서 사용하는 모델로, OSI 7계층을 실용적으로 단순화한 모델입니다.

TCP/IP 계층	대응하는 OSI 계층	역할
응용(Application)	5, 6, 7	HTTP, DNS, FTP
전송(Transport)	4	TCP, UDP
인터넷(Internet)	3	IP, ICMP
네트워크 접근(Network Access)	1, 2	Ethernet, Wi-Fi

OSI는 이론적 표준, TCP/IP는 실제 인터넷에서 사용하는 구현 모델입니다.

예상 꼬리 질문 ①: TCP와 UDP의 차이점은 무엇인가요?

TCP는 연결 지향 프로토콜로, 3-way handshake를 통해 연결을 맺고 데이터의 순서 보장, 재전송, 흐름 제어를 지원합니다. 신뢰성이 높지만 속도가 상대적으로 느립니다. 파일 전송, HTTP 통신 등에 사용됩니다.

UDP는 비연결형 프로토콜로, 연결 과정 없이 데이터를 바로 전송합니다. 신뢰성은 낮지만 속도가 빠릅니다. 실시간 스트리밍, 게임, DNS 조회 등에 사용됩니다.

예상 꼬리 질문 ②: 3-way handshake가 무엇인가요?

TCP 연결을 수립하는 과정입니다.

SYN: 클라이언트가 서버에 연결 요청
SYN-ACK: 서버가 요청을 수락하고 응답
ACK: 클라이언트가 확인 응답 → 연결 수립

연결 종료 시에는 4-way handshake(FIN → ACK → FIN → ACK)를 사용합니다.

2. 인증과 인가에 대해 설명해주세요.

인증 (Authentication)

"당신이 누구인지"를 확인하는 과정입니다.
사용자가 주장하는 신원이 실제로 맞는지 검증합니다.

예시: 로그인 시 아이디/비밀번호 입력, 지문 인식, OTP 인증

인가 (Authorization)

"당신이 무엇을 할 수 있는지"를 결정하는 과정입니다.
인증된 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인합니다.

예시: 일반 유저는 관리자 페이지 접근 불가, 본인 게시글만 수정 가능

순서

인증 → 인가 순으로 이루어집니다. 인증 없이는 인가가 의미가 없습니다.

- 실제 웹에서의 흐름 (JWT 기준)

사용자가 로그인 → 서버가 신원을 인증하고 JWT 토큰 발급
이후 요청마다 토큰을 헤더에 포함
서버가 토큰을 검증해 해당 유저의 권한을 확인 → 인가

예상 꼬리 질문 ①: 세션 기반 인증과 토큰 기반 인증(JWT)의 차이는 무엇인가요?

세션 기반 인증은 서버가 세션 정보를 직접 저장(상태 유지, stateful)하고, 클라이언트는 세션 ID만 쿠키로 가집니다.

서버 메모리를 사용하고, 분산 서버 환경에서 세션 공유 문제가 생길 수 있습니다.

JWT 기반 인증은 서버가 상태를 저장하지 않고(stateless), 토큰 자체에 유저 정보와 서명이 담겨 있습니다. 서버 부하는 낮지만 토큰이 탈취되면 만료 전까지 막기 어렵습니다. 그래서 Access Token의 만료 시간을 짧게 하고 Refresh Token을 함께 사용합니다.

예상 꼬리 질문 ②: JWT의 구조를 설명해주세요.

JWT는 점(.)으로 구분된 세 부분으로 구성됩니다.

Header: 토큰 타입(JWT)과 알고리즘(HS256 등) 정보, Base64로 인코딩
Payload: 사용자 ID, 권한, 만료 시간 등 클레임(claim) 데이터, Base64로 인코딩
Signature: Header + Payload를 비밀키로 서명한 값 → 위변조 방지

Payload는 Base64 인코딩이라 누구나 디코딩할 수 있으므로, 비밀번호 같은 민감한 정보는 담으면 안 됩니다.

3. 컴파일러와 인터프리터의 차이점과 각 예시를 설명하세요.

사진출처: https://blog.naver.com/tipsware/221041215416

인간이 이해할 수 있는 고수준 언어(C++,Java,JavaScript 등)를 CPU가 이해할 수 있는 저수준 언어(기계어)로 번역(변환)하는 방식은 두 가지로, *인터프리터 방식과 *컴파일러 방식이 있다.

컴파일러 (Compiler)

소스 코드 전체를 한꺼번에 분석하고 기계어(또는 중간 코드)로 변환한 후 실행 파일을 생성합니다.

실행 전에 모든 번역이 완료되므로 실행 속도가 빠릅니다.
문법 오류가 있으면 컴파일 자체가 실패합니다.
예시: C, C++, Go, Rust, Java (→ 바이트코드로 컴파일)

**오브젝트 코드(목적코드):

[ .c > .obj ] 소스코드를 컴파일한 결과물, 즉 컴파일된 파일

C언어의 경우)

1. [파일명.c]인 소스파일에 프로그램을 작성하여 저장함 >

2. 컴파일러에 의해 어셈블리 코드로 변함(일반적인 컴파일러들은 어셈블러의 역할도 수행) > 바이너리 코드로 변경됨 > 변경된 바이너리 코드는 [파일명.obj]인 오브젝트 파일로 불리고 링커의 대상이 됨 >

3. 링커로 인해 [파일명.exe]인 *실행파일을 만듦.

*실행파일: CPU에 일을 시키는 프로그램

*컴파일(Compiler/번역,변환하는 프로그램) [C,C++,C#,JAVA,Ada,파스칼 등]

프로그램 소스코드 전체를 한꺼번에 스캔하여 번역하는 과정을 거친다.

초기실행 시간이 오래 걸리지만, 작업을 **단순화시켜 전체적인 실행시간은 더 빠를 수 있다는 장점이 있다.

변환하는 과정에서 **오브젝트 코드(Object Code)라는 파일을 만들어야 하기 때문에 많은 메모리가 필요함
전체 코드를 검사한 후 오류메세지를 생성하기에, 프로그램 실행 전에 오류를 발견할 수 있다는 장점이 있다.

**단순화

컴파일 과정에서 특정 함수를 많이 반복해야 할 경우, 함수를 반복하는 것이 아니라 함수의 결과물을 반복하도록 컴파일한다. 이처럼 불필요한 동작을 제거하는 방식을 최적화(Optimization)라 한다.

-----

인터프리터 (Interpreter)

소스 코드를 한 줄씩 읽고 즉시 실행합니다. 별도의 실행 파일을 생성하지 않습니다.

즉시 실행 가능하고 디버깅이 편하지만 실행 속도가 상대적으로 느립니다.
오류가 있는 줄에 도달해야 오류가 발생합니다.
예시: Python, JavaScript(전통적), Ruby

JavaScript는 컴파일러? 인터프리터?

JavaScript는 원래 인터프리터 언어였지만, 현대 엔진(V8 등)은 JIT(Just-In-Time) 컴파일 방식을 사용합니다. 실행 시점에 자주 사용되는 코드를 기계어로 컴파일해 성능을 높입니다. 즉, 두 방식의 장점을 혼합한 형태입니다.

장점 / 단점

*인터프리터(Interpreter/해석기) [JavaScript,Python,Ruby,스크래치 등]

자바스크립트 파일을 받으면, 코드를 한 줄 한 줄 해석하면서

바로 기계어(Machine Code)로 번역하여 실행하는 방식.

코드실행 전 *컴파일 단계가 없기 때문에 실행속도가 빠르다는 장점이 있다.

별도의 실행파일이 없어서, 매 실행마다 인터프리트 과정이 반복 수행되어 메모리 사용 효율은 좋으나 실행시간이 더 소요됨
한 번에 한 문장씩 번역 및 실행하기 때문에 오류를 만나면 그 즉시 프로그램을 중지한다.
소스코드가 쉽게 공개된다는 단점이 있다.

[출처] 개초보 리액트 설명문[리액트뭐임/인터프리터뭐임]|작성자 뫠

예상 꼬리 질문 ①: JIT 컴파일이란 무엇인가요?

JIT(Just-In-Time) 컴파일은 프로그램 실행 중에 필요한 코드를 실시간으로 기계어로 컴파일하는 방식입니다. 인터프리터처럼 바로 실행할 수 있는 유연성을 가지면서, 자주 실행되는 코드(hot code)는 컴파일해 캐싱하여 실행 속도를 높입니다. V8 엔진(Chrome, Node.js)이 대표적으로 JIT를 사용합니다.

예상 꼬리 질문 ②: Java는 컴파일 언어인가요, 인터프리터 언어인가요?

Java는 두 가지 모두에 해당합니다.

소스 코드(.java)를 컴파일러가 바이트코드(.class)로 변환합니다.
JVM(Java Virtual Machine)이 바이트코드를 인터프리팅하거나 JIT 컴파일로 실행합니다.

"한 번 작성하면 어디서나 실행(Write Once, Run Anywhere)"이 가능한 이유가 바로 JVM 덕분입니다.

4. 가상 메모리에 대해 설명해보세요.

가상 메모리란?

실제 물리적 RAM의 크기에 관계없이, 각 프로세스가 자신만의 독립적인 연속된 메모리 공간을 갖는 것처럼 보이게 하는 메모리 관리 기법입니다.

운영체제가 물리 메모리(RAM)와 하드디스크의 일부(스왑 공간)를 조합해 프로세스에게 가상의 주소 공간을 제공합니다.

왜 필요한가?

물리 메모리보다 큰 프로그램을 실행할 수 있습니다.
각 프로세스가 독립된 주소 공간을 가지므로 다른 프로세스의 메모리에 직접 접근할 수 없어 보안과 안정성이 향상됩니다.
여러 프로세스가 메모리를 효율적으로 공유할 수 있습니다.

동작 원리 (페이징 기법)

가상 주소 공간과 물리 메모리를 동일한 크기의 블록(페이지)으로 나눕니다.
페이지 테이블이 가상 주소 → 물리 주소를 매핑합니다.
필요한 페이지만 물리 메모리에 올려두고, 나머지는 디스크에 저장합니다.

페이지 폴트 (Page Fault)

프로세스가 접근하려는 페이지가 물리 메모리에 없을 때 발생합니다. OS가 해당 페이지를 디스크에서 RAM으로 불러오는데, 이 과정에서 성능 저하가 발생합니다. 페이지 폴트가 너무 자주 발생하면 스래싱(Thrashing) 이 생겨 성능이 급격히 저하됩니다.

예상 꼬리 질문 ①: 스래싱(Thrashing)이란 무엇인가요?

프로세스가 실제 작업보다 페이지를 교체하는 데 더 많은 시간을 소비하는 현상입니다.
메모리에 너무 많은 프로세스가 올라가 있을 때, 각 프로세스에 할당된 페이지 수가 부족해져 페이지 폴트가 연속적으로 발생합니다. 해결책으로는 프로세스 수를 줄이거나, 물리 메모리를 증설하거나, 워킹 셋(Working Set) 기법으로 필요한 페이지를 예측해 메모리에 유지하는 방법이 있습니다.

예상 꼬리 질문 ②: 페이지 교체 알고리즘에는 어떤 것이 있나요?

물리 메모리가 가득 찼을 때 어떤 페이지를 내보낼지 결정하는 알고리즘입니다.

FIFO: 가장 먼저 올라온 페이지를 먼저 제거. 구현 간단하지만 성능이 좋지 않을 수 있음.
LRU (Least Recently Used): 가장 오랫동안 사용되지 않은 페이지 제거. 실제로 많이 사용되는 방식.
OPT (Optimal): 앞으로 가장 오랫동안 사용되지 않을 페이지 제거. 이론상 최적이지만 미래를 알 수 없어 실제 구현은 불가.

프론트엔드

1. 호이스팅에 대해서 설명해주세요.

호이스팅(Hoisting)이란?

JavaScript 엔진이 코드를 실행하기 전 변수 선언과 함수 선언을 해당 스코프의 최상단으로 끌어올리는 동작입니다.

실제 코드가 이동하는 것이 아니라, 자바스크립트 엔진이 코드를 파싱하는 단계에서 선언을 먼저 메모리에 등록하는 것입니다.

선언 정보만 등록되며 변수종류와 뭐에따라 달라집니다.

변수 호이스팅

var 호이스팅

var는 선언과 동시에 undefined로 초기화됩니다. 선언 전에 접근해도 에러가 나지 않고 undefined를 반환합니다.

console.log(a); // undefined
var a = 1;

let, const 호이스팅

ES5에 나온 개념으로

let과 const도 호이스팅이 되지만 초기화가 되지 않아, 선언 전에 접근하면 ReferenceError가 발생합니다.
이 선언 시점 전까지의 구간을 TDZ(Temporal Dead Zone, 일시적 사각지대) 라고 합니다.

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 1;

함수 선언식 vs 함수 표현식

함수 선언식(function foo() {})은 함수 전체가 호이스팅되어 선언 전에 호출할 수 있습니다.
함수 표현식(const foo = function() {})은 변수 선언만 호이스팅되므로 선언 전에 호출하면 에러가 납니다.

hello(); // "Hello!" (함수 선언식은 가능)
function hello() { console.log("Hello!"); }

greet(); // TypeError: greet is not a function
var greet = function() { console.log("Hi!"); }

예상 꼬리 질문 ①: TDZ(Temporal Dead Zone)가 무엇인가요?

let과 const로 선언된 변수가 호이스팅은 되었지만 아직 초기화되지 않은 상태의 구간입니다. 스코프의 시작부터 실제 선언문에 도달하기 전까지가 TDZ입니다. 이 구간에서 해당 변수에 접근하면 ReferenceError가 발생합니다. TDZ는 예측하기 어려운 var의 동작을 개선하기 위해 도입된 개념입니다.

var에는 TDZ가 없다.

예상 꼬리 질문 ②: var 대신 let/const를 써야 하는 이유는 무엇인가요?

스코프: var는 함수 스코프, let/const는 블록 스코프입니다. var는 if문이나 for문 블록 밖에서도 접근이 가능해 예상치 못한 버그를 유발합니다.
재선언: var는 같은 스코프에서 같은 이름으로 재선언이 가능하지만, let/const는 불가능합니다.
호이스팅 안전성: var는 undefined로 초기화되어 조용히 버그를 만들 수 있지만, let/const는 TDZ로 명확한 에러를 냅니다.
const: 재할당이 불가능하므로 의도하지 않은 값 변경을 방지합니다. 기본적으로 const를 사용하고, 재할당이 필요한 경우만 let을 사용하는 것이 권장됩니다.

let과 const의 차이점이뭔가요?

const 재할당 불가 let은 재할당 가능

const는 값을 바꿀 수 없나요?

const obj = { name: "seoin" };
obj.name = "kim";   // ✅ 가능 (참조값은 그대로, 내부 프로퍼티만 변경)
obj = {};           // ❌ 불가 (참조 자체를 바꾸는 재할당)

const는 참조(주소)가 고정되는 것이지, 참조한 데이터의 내용까지 고정하는 게 아닙니다.

2. CSR vs SSR vs SSG 차이를 설명하세요.

CSR (Client-Side Rendering)

브라우저가 빈 HTML을 받고, JavaScript 번들을 다운로드한 후 클라이언트 측에서 직접 화면을 렌더링하는 방식입니다.

장점: 초기 로딩 이후 페이지 전환이 빠르고 부드럽습니다 (SPA 경험). 서버 부하가 낮습니다.
단점: 초기 로딩이 느립니다. JavaScript가 실행되기 전까지 빈 화면이 보입니다. 크롤러가 JS를 실행하지 못하는 경우 SEO에 불리합니다.
예시: React (기본), Vue, Angular

브라우저가 빈 HTML을 렌더링 하고 JS로

인증에 적합

SSR (Server-Side Rendering)

사용자가 요청할 때마다 서버에서 HTML을 완성해 클라이언트에 전달하는 방식입니다.

장점: 초기 로딩이 빠르고 완성된 HTML을 내려주므로 SEO에 유리합니다. 실시간 데이터 반영에 적합합니다.
단점: 요청마다 서버에서 렌더링하므로 서버 부하가 높습니다. 페이지 이동 시 전체 새로고침이 발생할 수 있습니다.
예시: Next.js (getServerSideProps), Nuxt.js

서버가 HTML을 미리 완성해두고 요청시에 보내줌

SEO에는 유리할 수 있으나 서버부하가 높아지는 단점이 있습니다.

뉴스나 커머스에 적합

SSG (Static Site Generation)

빌드 시점에 미리 모든 HTML을 생성해두고, 요청 시 정적 파일을 그대로 서빙하는 방식입니다.

장점: 응답 속도가 가장 빠릅니다 (CDN 캐싱 가능). SEO에 매우 유리합니다. 서버가 없어도 됩니다.
단점: 내용이 변경될 때마다 재빌드가 필요합니다. 실시간 데이터에 적합하지 않습니다.
예시: Next.js (getStaticProps), Gatsby, Jekyll

빌드 타임

속도와 SEO에는 최적 자주바뀌는 데이터는 부적합

블로그나 문서에 적합

비교 요약

	CSR	SSR	SSG
렌더링 위치	클라이언트	서버 (요청마다)	빌드 타임
초기 로딩	느림	빠름	가장 빠름
SEO	불리	유리	매우 유리
실시간 데이터	적합	적합	부적합
서버 부하	낮음	높음	없음
적합한 서비스	대시보드, 관리자 페이지	뉴스, 커머스	블로그, 문서

예상 꼬리 질문 ①: Next.js의 ISR(Incremental Static Regeneration)이란 무엇인가요?

ISR은 SSG의 단점을 보완한 방식으로, 특정 주기(예: 60초마다)마다 정적 페이지를 백그라운드에서 재생성합니다. 정적 파일의 빠른 응답 속도를 유지하면서도 일정 주기로 최신 데이터를 반영할 수 있습니다. Next.js에서 getStaticProps에 revalidate 옵션을 설정하면 사용할 수 있습니다.

예상 꼬리 질문 ②: SEO 관점에서 CSR의 단점을 어떻게 보완할 수 있나요?

CSR은 크롤러가 JS 실행 전 빈 HTML만 보는 경우 SEO에 불리합니다. 보완 방법으로는:

SSR 도입: Next.js처럼 서버에서 완성된 HTML을 내려줍니다.
Pre-rendering: React Helmet, React Snap 등으로 주요 페이지를 미리 정적 HTML로 생성합니다.
Dynamic Rendering: Googlebot 같은 크롤러에게는 SSR 결과를, 일반 사용자에게는 CSR 결과를 제공합니다.
메타 태그 관리: 크롤러가 읽는 <title>, <meta>, Open Graph 태그를 적절히 설정합니다.

? 크롤러가 왜 빈 HTML만 보게될까요?

크롤러는 HTML파일만 읽고 JS를 실행하지 않는데, CSR은 초기 HTML의 텅빈페이지를 보게되는구나

SSR은 완성된 HTML(JS)포함된

? Hydration

하이드레이션은 서버에서 렌더링된 정적 html에 자바스크립트 이벤트리스너나 동적 연결하는 것을 의미합니다.

현재글프로그래밍 면접질문대비 스터디 3주차

임서인 학습해라

쓰다보면 늘어나는 코드지식

async, Export Named, 코딩테스트, 클린코드, top-level await, 함수 호출(), 함수 참조, SPLIT, reverse, export default, 자바스크립트, 모듈, Named Import, 함수, default import, 포맷팅, Await, 만 ~, 비동기, 객체,

Today :
Yesterday :