network

Network 면접 Q&A 정리 — 인강 노트

형식: 하나의 질문에 대해 브론즈 → 실버 → 골드 답변을 비교하고, 답변 간 차이 포인트와 꼬리 질문을 정리한다.

www.google.com 접속 시 웹 브라우저 요청 흐름을 설명해 주세요
TCP가 무엇이고 장단점을 설명해 주세요
UDP는 무엇이고 TCP와 어떻게 다른가요
3웨이 / 4웨이 핸드셰이크에 대해 설명해 주세요
TCP는 데이터가 안전하게 도착한다는 것을 어떻게 보장하나요 (신뢰성·흐름 제어·혼잡 제어)
TCP/IP는 무엇이고 OSI 7계층과의 관계는 무엇인가요 (TCP와 TCP/IP는 같은 건가요)
DNS가 무엇이고 www.naver.com 접속 과정을 DNS와 연관지어 설명해 주세요
DNS 서버에 IP 주소를 요청할 때 왜 UDP를 사용하나요
DNS 서버는 어떤 종류가 있고, A/CNAME/TXT 같은 레코드는 왜 나뉘나요
HTTP란 무엇이고 동작 방식을 설명해 주세요
HTTP의 특징은 무엇인가요 (비연결성과 무상태성)
HTTP 메서드의 멱등성이란 무엇인가요
TLS 핸드셰이크는 어떤 순서로 진행되나요 (HTTPS)
CA 인증서를 발급받는 이유는 무엇이고, Let's Encrypt와 유료 CA의 차이는 무엇인가요
RESTful API란 무엇이고 REST풀하게 설계한다는 것은 어떤 의미인가요
REST API와 gRPC의 차이는 무엇이고 gRPC는 어떤 상황에 쓰나요
SOP와 CORS에 대해 설명해 주세요
심플 리퀘스트와 프리플라이트 리퀘스트는 어떤 기준으로 나뉘나요
HTTP는 무상태인데 로그인 상태는 어떻게 유지하나요
인증과 인가는 어떻게 다른가요
쿠키와 세션은 어떻게 다른가요
JWT는 어떤 구조이고 왜 액세스 토큰과 리프레시 토큰으로 나누나요
JWT가 탈취되면 어떻게 대응하고 탈취 여부는 어떻게 판단하나요
리프레시 토큰을 서버에 저장한다면 세션과 무엇이 다른가요
OAuth 2.0의 동작 원리를 설명해 주세요
SSO는 어떤 구조로 동작하며 OAuth 2.0과는 어떤 관계인가요
웹소켓이란 무엇인가요 — HTTP와의 차이와 연결 과정
웹소켓 연결 유지 메커니즘(핑퐁)과 STOMP를 설명해 주세요
SSE의 개념과 특징, 웹소켓과의 차이를 설명해 주세요
폴링 / 롱 폴링 / SSE를 비교하고 SSE 라이프 사이클을 설명해 주세요

1. www.google.com 접속 시 웹 브라우저 요청 흐름을 설명해 주세요

핵심 답변 (골드 수준)

사용자가 브라우저 주소창에 www.google.com을 입력하면 다음 순서로 진행된다.

DNS 캐시 확인 — 브라우저는 먼저 DNS 캐시를 확인하고, 캐시에 없으면 DNS 질의를 통해 IP 주소를 얻는다.
TCP 연결 수립 — IP가 확보되면 클라이언트와 서버는 3웨이 핸드셰이크로 TCP 연결을 수립한다.
HTTP 요청 — 그 연결 위로 메서드와 헤더를 담은 HTTP 요청을 보낸다.
HTTP 응답 — 서버는 요청을 처리한 뒤 상태 코드와 본문을 포함한 HTTP 응답을 반환한다.
렌더링 — 브라우저는 응답받은 HTML, CSS, 자바스크립트를 파싱하여 DOM과 CSSOM을 만들고, 렌더 트리를 구성해 화면에 그린다.
연결 종료 — 연결을 종료할 때는 TCP 4웨이 핸드셰이크가 사용될 수 있다.

주소창 입력
   │
   ▼
DNS 캐시 확인 ──(없으면)──▶ DNS 질의 → IP 획득
   │
   ▼
TCP 3웨이 핸드셰이크 (연결 수립)
   │
   ▼
HTTP 요청 (메서드 + 헤더) ──▶ 서버 처리 ──▶ HTTP 응답 (상태 코드 + 본문)
   │
   ▼
HTML/CSS/JS 파싱 → DOM + CSSOM → 렌더 트리 → 화면에 그리기
   │
   ▼
(종료 시) TCP 4웨이 핸드셰이크

핵심 키워드 4가지: DNS 캐시와 DNS 질의 → TCP 3웨이 핸드셰이크 → HTTP 요청/응답 → 렌더링 파이프라인. 이 네 가지를 시간 순으로 유기적으로 이어서 답변한다.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"URL을 입력하면 DNS가 동작하고 TCP로 연결해서 데이터를 받아 와서 화면에 보여준다"	용어는 알지만 하나의 흐름으로 들리지 않는다. DNS가 무슨 일을 하는지, TCP 연결이 언제 열리는지, 응답이 어떻게 화면이 되는지가 전부 뭉뚱그려져 있다
실버	"DNS로 IP를 얻고 TCP 연결 수립 후 HTTP 요청, 서버가 응답하면 HTML을 화면에 보여준다"	큰 순서는 잡혀 있으나 TCP 연결이 어떻게 열리는지, HTML이 어떻게 실제 화면으로 이어지는지가 비어 있다
골드	위 핵심 답변	① 출발점을 DNS 캐시 → 질의로 연결 ② HTTP 요청/응답을 TCP 연결의 생애 주기 안에 배치 ③ 응답 이후를 렌더링 파이프라인(DOM·CSSOM·렌더 트리)으로 마무리

꼬리 질문

"그 HTTP 요청이 실제 네트워크로 나갈 때는 어떤 단위로 포장되나요?" — 시간 순으로 봤던 HTTP 요청이 실제 네트워크로 나갈 때 TCP 세그먼트 → IP 패킷 → 링크 계층 프레임으로 캡슐화되어 나간다는 관점(TCP/IP 계층과 패킷 캡슐화)으로 다시 설명할 수 있어야 한다.

2. TCP가 무엇이고 장단점을 설명해 주세요

핵심 답변 (골드 수준)

TCP는 OSI 모델의 전송 계층에서 동작하는 연결 지향 프로토콜이다. 데이터를 보내기 전에 3웨이 핸드셰이크로 논리적인 가상 회선을 먼저 수립하고, 이 연결 위에서 시퀀스 번호, ACK, 재전송 같은 메커니즘으로 신뢰성을 보장한다.

장점: 데이터의 순서와 무결성을 보장한다.
단점: 연결 설정과 유지 비용 때문에 UDP보다 상대적으로 느리고, 구조상 1대1 통신을 전제로 해서 브로드캐스트나 멀티캐스트에는 적합하지 않다.

포인트:

"안정적으로 보낸다"는 결과이고, "전송 계층에서 연결을 먼저 수립한다"가 동작 방식이다. 이 표현이 들어가야 TCP의 위치와 역할이 함께 잡힌다.
가상 회선은 실제 선을 새로 까는 것이 아니라 통신 전에 논리적인 연결 상태를 만든다는 뜻이다. 이 표현이 있어야 3웨이 핸드셰이크로 자연스럽게 넘어갈 수 있다.
신뢰성과 비용을 같은 구조에서 설명한다 — 시퀀스 번호·ACK·재전송으로 신뢰성을 얻는 만큼 연결 설정·유지 비용이 생긴다. 장단점을 같은 구조로 설명하면 암기가 아니라 원리로 말하는 인상을 준다.

핵심 키워드 4가지: 전송 계층, 연결 지향, 신뢰성, 1대1 통신.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"데이터를 안정적으로 보내는 프로토콜. 잘 도착하는 게 장점, 느린 게 단점"	결과만 말한다. 어느 계층인지, 왜 안정적인지, 왜 느린지가 빠져 있다
실버	"전송 계층의 연결 지향 프로토콜로 연결을 먼저 수립해 신뢰성이 높다. 순서대로 도착하는 게 장점, 연결 설정 비용으로 느린 게 단점"	방향성은 좋으나 ① 신뢰성을 보장하는 실제 장치 ② 1대1 통신이라는 구조적 제약이 빠져 있다
골드	위 핵심 답변	가상 회선, 신뢰성 메커니즘(시퀀스 번호·ACK·재전송), 1대1 한계까지 채웠다

꼬리 질문

"그럼 UDP는 TCP와 어떻게 다른가요?" — 단점으로 연결 설정 비용과 1대1 구조를 말했으니 자연스럽게 비교 대상이 나온다. (→ 질문 3)
"연결을 먼저 맺는다"고 말하면 3웨이 핸드셰이크 질문이 이어진다. (→ 질문 4)

3. UDP는 무엇이고 TCP와 어떻게 다른가요

핵심 답변 (골드 수준)

UDP는 전송 계층의 비연결 지향 프로토콜로, TCP처럼 3웨이 핸드셰이크로 연결을 먼저 만들지 않고 데이터그램 단위로 바로 전송한다. 그래서 순서 보장, 도착 보장, 자동 재전송은 제공하지 않지만 연결 설정과 상태 유지 비용이 없어 오버헤드가 낮다.

TCP가 신뢰성과 순서를 프로토콜이 책임지는 1대1 연결이라면, UDP는 빠른 전송과 브로드캐스트·멀티캐스트에 유리하다. DNS, 실시간 스트리밍, 게임처럼 약간의 손실보다 지연 시간이 더 중요한 경우에 사용하고, 신뢰성이 필요하면 애플리케이션 계층에서 별도로 보완한다(예: 메시지에 시퀀스 번호를 붙이고 ACK를 받지 못하면 재전송).

포인트:

"연결을 안 맺는다"에서 멈추면 결과만 말한 것이다. 데이터그램 단위로 바로 보낸다고 해야 전송 방식을 설명한 것이 된다.
UDP가 빠른 이유는 막연히 "가벼워서"가 아니라 연결 설정과 상태 유지 비용이 적기 때문이다.
신뢰성 보완의 위치를 말할 수 있으면 UDP를 "TCP보다 부족한 것"이 아니라 다른 목적의 선택지로 설득력 있게 설명할 수 있다.

핵심 키워드 4가지: 비연결 지향, 데이터그램, 낮은 오버헤드, 애플리케이션 계층 보완.

답변 레벨 차이

레벨	답변 요지	평가
실버	"연결을 먼저 수립하지 않고 바로 보내서 빠르지만 신뢰성이 없다. 영상 스트리밍·음성 통화에 쓴다"	방향은 괜찮으나 "왜 빠른지"(데이터그램·상태 유지 비용)가 없고, "신뢰성이 없다"로 끝내면 부실한 프로토콜처럼 들린다
골드	위 핵심 답변	데이터그램 전송 구조, 낮은 오버헤드의 이유, 신뢰성의 애플리케이션 계층 보완까지 설명

꼬리 질문

"그러면 TCP는 연결을 어떻게 만들고 어떻게 끝내나요?" (→ 질문 4)

4. 3웨이 / 4웨이 핸드셰이크에 대해 설명해 주세요

핵심 답변 (골드 수준)

3웨이 핸드셰이크는 TCP의 연결 설정 과정이다. 클라이언트가 SYN을 보내고, 서버가 SYN+ACK로 응답한 뒤, 클라이언트가 마지막 ACK를 보내면서 양쪽의 시퀀스 번호와 송수신 가능 상태를 확인한다. 서버는 클라이언트 SYN에 대한 ACK와 자신의 SYN을 한 번에 보낼 수 있어서 세 번의 교환으로 충분하다.

[연결 설정: 3-way]                 [연결 종료: 4-way]
클라이언트          서버            종료 시작 측         상대 측
    │── SYN ─────────▶│                │── FIN ─────────▶│
    │◀─── SYN+ACK ────│                │◀─── ACK ────────│  (수신 확인만 먼저)
    │── ACK ─────────▶│                │   (남은 데이터 송신 마무리)
    │   연결 수립      │                │◀─── FIN ────────│
                                       │── ACK ─────────▶│
                                       │  TIME_WAIT 대기  │

4웨이 핸드셰이크는 TCP의 연결 종료 과정이다. 종료를 시작한 쪽이 FIN을 보내면, 상대는 먼저 ACK로 수신을 확인하고 — 아직 보낼 데이터가 남아 있을 수 있으므로 — 자신의 송신을 마친 뒤 별도의 FIN을 보낸다. TCP 종료는 양쪽 송신 방향을 각각 닫는 구조라서 보통 4번의 교환이 된다.

마지막 ACK를 보낸 쪽은 TIME_WAIT 상태로 잠시 대기한다. 이유는 두 가지다.

지연된 패킷이 다음 연결에 섞이는 것을 막기 위해
마지막 ACK가 유실됐을 때 상대의 FIN 재전송에 다시 응답하기 위해

핵심 키워드 4가지: SYN·SYN+ACK·ACK 연결 설정 3단계, ACK와 SYN의 결합(3번인 이유), ACK와 FIN의 분리(4번인 이유), TIME_WAIT.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"연결 시작 시 패킷 3번, 종료 시 4번 주고받는 과정"	화이트보드에 그릴 수 있는 게 없다. 어떤 플래그가 오가는지, 왜 3번/4번인지 없음
실버	"SYN → SYN+ACK → ACK로 수립, 종료는 FIN → ACK → FIN → ACK"	흐름은 알지만 ① 왜 연결은 3번이고 종료는 4번인지 ② 왜 TIME_WAIT이 필요한지가 빠져 있다
골드	위 핵심 답변	플래그의 목적(시퀀스 번호·송수신 상태 확인), 3/4 비대칭의 이유, TIME_WAIT의 두 가지 이유까지 설명

실전 팁: 유니콘 스타트업 면접에서 화이트보드에 클라이언트-서버 패킷 흐름을 직접 그리며 설명하라는 요구를 받은 사례가 있다. 화살표를 그려 설명할 수 있을 정도로 이해해야 한다.

꼬리 질문

"그 연결 위에서 데이터가 안전하게 도착한다는 건 어떻게 보장하나요?" (→ 질문 5)

5. TCP는 데이터가 안전하게 도착한다는 것을 어떻게 보장하나요 (신뢰성·흐름 제어·혼잡 제어)

핵심 답변 (골드 수준)

TCP는 시퀀스 번호와 ACK를 사용해 세그먼트의 순서와 수신 여부를 확인하고, 손실이 감지되면 재전송으로 복구한다. 또한 체크섬으로 헤더와 데이터의 오류를 검출해 잘못된 세그먼트를 걸러낸다.

전송 속도 조절은 흐름 제어와 혼잡 제어로 나눠서 봐야 한다.

흐름 제어: 수신 측의 버퍼와 처리 능력에 맞춰 송신량을 조절하는 것
혼잡 제어: 네트워크 전체가 막히지 않도록 송신 윈도우를 동적으로 조절하는 것

혼잡 제어에서는 처음에는 슬로우 스타트로 조심스럽게 전송량을 늘리고, 이후에는 AIMD처럼 손실이 없으면 조금씩 늘리고 손실이 감지되면 크게 줄이는 방식으로 네트워크 상태에 맞춘다.

핵심은 TCP의 신뢰성이 단순히 ACK 하나가 아니라 손실 복구와 속도 제어까지 함께 묶여 있다는 점이다.

핵심 키워드 4가지: 시퀀스 번호와 ACK, 재전송과 체크섬, 흐름 제어, 혼잡 제어.

답변 레벨 차이

레벨	답변 요지	평가
실버	"시퀀스 번호를 부여하고 ACK로 응답, 누락·타임아웃 시 재전송, 체크섬으로 검증. 혼잡 제어는 네트워크가 막혔을 때 속도를 줄이는 기능 정도"	신뢰성 기본 장치는 좋지만 혼잡 제어를 "속도 줄이는 기능"으로만 말하면 흐름 제어와의 차이 질문에 바로 취약해진다
골드	위 핵심 답변	① 시퀀스 번호·ACK를 역할(순서·수신 여부 확인)로 설명 ② 흐름 제어(수신 측)와 혼잡 제어(네트워크 전체)의 책임 분리 ③ 슬로우 스타트·AIMD로 동적 조절 감각을 표현

주의: 흐름 제어와 혼잡 제어를 구분하지 못하면 앞부분을 잘 말하고도 마지막 디테일에서 점수를 잃는다. 실제 하이퍼커넥트 면접에서 신뢰성 메커니즘까지 답하고 혼잡 제어에서 막힌 사례가 소개되었다. "둘 다 송신량 조절 아닌가요?"라는 되물음에도 보는 대상이 다르다(수신 측 vs 네트워크 전체)로 답하면 흔들리지 않는다.

꼬리 질문

"TCP/IP는 TCP랑 같은 건가요? OSI 7계층과는 어떤 관계죠?" (→ 질문 6)

6. TCP/IP는 무엇이고 OSI 7계층과의 관계는 무엇인가요 (TCP와 TCP/IP는 같은 건가요)

핵심 답변 (골드 수준)

TCP/IP는 인터넷에서 실제로 쓰이는 프로토콜 스택이고, TCP는 그 안의 전송 계층에서 동작하는 하나의 프로토콜이다. 반면 OSI 7계층은 통신 과정을 응용·표현·세션·전송·네트워크·데이터 링크·물리 계층으로 나눈 참조 모델이다.

두 모델의 대응 관계:

TCP/IP 4계층	OSI 7계층
응용 계층	응용 + 표현 + 세션 계층
전송 계층 (TCP, UDP 동작)	전송 계층
인터넷 계층	네트워크 계층
네트워크 인터페이스 계층	데이터 링크 + 물리 계층

핵심은 TCP/IP는 실제 구현에 가까운 4계층 모델이고 OSI는 통신을 설명하기 위한 7계층 참조 모델이라는 점이다.

핵심 키워드 4가지: TCP/IP(프로토콜 스택), TCP(전송 계층 프로토콜), OSI 7계층(참조 모델), 계층 매핑. 매핑은 전부 외울 필요는 없고, 전송 계층과 응용 계층 정도는 정확히 답할 수 있게 준비한다.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"TCP/IP는 인터넷 프로토콜 묶음, OSI는 7계층 모델. 4계층 vs 7계층 차이"	계층 숫자만 있고, 어느 계층이 어디에 대응되는지 없음
실버	"TCP/IP는 실제 프로토콜 스택, OSI는 참조 모델. 전송 계층끼리 대응되고 거기서 TCP/UDP 동작"	성격 차이는 보이지만 응용 계층·네트워크 인터페이스 계층의 매핑이 빠져 있다
골드	위 핵심 답변	① 첫 문장에서 TCP/IP와 TCP의 이름 혼동을 정리 ② 구체적 계층 매핑 + 모델의 성격 차이(실제 구현 vs 참조 모델)

꼬리 질문

이 질문으로 TCP/UDP 섹션이 정리되고, 다음은 응용 계층에서 도메인 이름을 IP로 바꾸는 DNS로 이어진다. (→ 질문 7)

7. DNS가 무엇이고 www.naver.com 접속 과정을 DNS와 연관지어 설명해 주세요

핵심 답변 (골드 수준)

DNS는 www.naver.com 같은 도메인 이름을 IP 주소로 바꿔주는 시스템이다. 사람은 숫자로 된 IP를 일일이 기억하기 어렵고 컴퓨터는 실제 통신에 IP가 필요하기 때문에, DNS가 둘 사이를 이어준다.

조회 흐름:

브라우저가 www.naver.com에 접속하면 먼저 로컬 DNS 서버에 질의한다.
로컬 DNS 서버에 정보가 없으면 루트 DNS 서버에서 .com 최상위(TLD) DNS 서버의 위치를 받는다.
최상위 DNS 서버에서 naver.com을 관리하는 권한 DNS 서버의 위치를 받는다.
권한 DNS 서버에서 www.naver.com의 실제 IP 주소를 받아온다.

호스트 ──질의──▶ 로컬 DNS ──▶ 루트 DNS      (".com TLD 서버는 여기")
                    │  ◀──────────┘
                    ├──▶ 최상위(TLD) DNS    ("naver.com 권한 서버는 여기")
                    │  ◀──────────┘
                    └──▶ 권한 DNS           ("www.naver.com의 IP는 x.x.x.x")
호스트 ◀──IP 응답── 로컬 DNS (TTL 동안 캐싱)

호스트 입장에서는 로컬 DNS에 한 번 요청하면 로컬 DNS가 나머지 과정을 대신 처리해 주는 재귀 질의 구조로 보인다. 로컬 DNS는 받아온 IP를 TTL 동안 캐싱해 이후 같은 요청에는 상위 DNS 서버들을 다시 거치지 않고 응답할 수 있다.

포인트:

왜 필요한지부터 말한다 — 사람은 도메인을 쓰고 컴퓨터는 IP로 통신한다.
조회 흐름을 서버 역할로 나눈다 — 중요한 것은 상위 서버가 모든 답을 직접 주는 게 아니라 다음에 물어볼 서버의 위치를 알려준다는 점이다.
재귀 질의와 캐싱 — 가비아 같은 DNS 관리 도구에서 입력하는 TTL 값이 바로 이 캐싱 유지 시간이다.

핵심 키워드 3가지: 도메인 이름 → IP 주소, 로컬 → 루트 → 최상위 → 권한의 조회 흐름, 재귀 질의와 캐싱.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"DNS는 도메인을 IP로 바꿔주는 서버. 입력하면 IP를 찾아서 알려주고 접속된다"	결과만 말했다. 왜 필요한지, 어떤 순서로 찾는지가 없다. "찾아서 알려준다"는 표현이 너무 넓다
실버	"사람이 외우기 어려운 IP 대신 도메인을 쓰게 해주는 시스템. 로컬 DNS에 질의하고 없으면 상위 DNS 서버들을 거쳐 IP를 받아온다"	필요성과 출발점은 잡았으나 "상위 DNS 서버들"이 뭉뚱그려져 있고 캐싱이 빠졌다
골드	위 핵심 답변	서버별 역할 구분(위치 안내 vs 실제 레코드), 재귀 질의, TTL 캐싱까지 구조로 설명

이 질문은 이력서에 배포 경험·도메인 연결 경험이 있으면 자주 이어진다.

꼬리 질문

"그 질의는 어떤 프로토콜로 오가나요?" (→ 질문 8)

8. DNS 서버에 IP 주소를 요청할 때 왜 UDP를 사용하나요

핵심 답변 (골드 수준)

DNS는 짧은 질의와 응답이 빠르게 오가야 하므로 기본적으로 UDP를 사용한다.

3웨이 핸드셰이크가 없다 — TCP는 데이터를 주고받기 전에 3웨이 핸드셰이크로 연결을 수립해야 하지만, UDP는 연결 설정 없이 바로 질의를 보낼 수 있어 DNS처럼 작은 요청에는 비용이 낮다.
스테이트리스 단발 질의 — DNS 질의는 보통 하나의 요청과 하나의 응답으로 끝난다. 서버가 클라이언트별 연결 상태를 오래 유지할 필요가 없기 때문에 같은 자원으로 더 많은 요청을 처리할 수 있다.
TCP 폴백 — 다만 항상 UDP만 쓰는 것은 아니다. 응답이 크거나 DNSSEC처럼 더 많은 데이터가 필요한 경우에는 TCP 폴백으로 보완한다.

포인트: "TCP는 느리다"가 아니라 **"연결 수립 과정이 먼저 필요하다"**라고 말해야 DNS 같은 작은 질의에 UDP가 왜 가벼운지 설명된다. TCP 폴백까지 언급하면 단정적인 답변을 피할 수 있다.

핵심 키워드 3가지: 3웨이 핸드셰이크 없음, 스테이트리스 단발 질의, TCP 폴백.

답변 레벨 차이

레벨	답변 요지	평가
실버	"빠른 응답이 중요해서 UDP. TCP처럼 연결을 맺으면 시간이 더 걸리는데 DNS는 짧은 질의·응답 한 번으로 끝나는 경우가 많다"	괜찮은 답변이지만 ① 왜 연결 상태를 오래 유지할 필요가 없는지 ② 예외(TCP 폴백)가 빠져 있다
골드	위 핵심 답변	연결 수립 비용, 스테이트리스 구조, TCP 폴백 예외까지 포함

실전 팁: 게임 회사 면접에서 TCP/UDP 차이 → DNS 조회 흐름 → 이 질문으로 하나의 유기적 흐름으로 이어진 사례가 있다. "DNS는 UDP를 씁니다"라는 이름만으로는 부족하고, 왜 DNS 질의에 UDP가 잘 맞는지를 말해야 한다.

꼬리 질문

"DNS 서버는 어떤 종류가 있고, A/CNAME/TXT 같은 레코드는 왜 나뉘나요?" (→ 질문 9)

9. DNS 서버는 어떤 종류가 있고, A/CNAME/TXT 같은 레코드는 왜 나뉘나요

핵심 답변 (골드 수준)

DNS 레코드는 도메인에 대한 정보를 저장하는 항목이다.

레코드	역할
A	도메인을 IPv4 주소에 매핑
CNAME	한 도메인이 다른 정식 도메인을 가리키게 하는 별칭
TXT	임의의 텍스트 값 저장 — 도메인 소유권 검증, SPF 같은 메일 인증 등에 사용

DNS 서버는 역할에 따라 로컬 DNS, 루트 DNS, 최상위(TLD) DNS, 권한 DNS 서버로 나뉜다.

서버	역할
로컬 DNS	클라이언트의 질의 창구
루트 DNS	.com 같은 최상위 DNS 서버의 위치 안내
최상위(TLD) DNS	특정 도메인의 권한 DNS 서버 위치 안내
권한 DNS	실제 레코드 값 저장

이렇게 나누는 이유는 전 세계 모든 도메인 정보를 한 서버가 관리할 수 없기 때문이다. 상위 서버가 직접 모든 답을 들고 있는 대신 하위 서버의 위치를 알려주는 권한 위임 구조를 쓰면 관리 책임을 나눌 수 있고, 한 곳에 부하와 장애가 집중되는 것을 줄일 수 있다.

실무 연결: 무료 SSL 인증서를 발급받을 때 인증 기관이 요구한 값을 TXT 레코드에 넣어 도메인 소유권을 확인하는 식으로, TXT 레코드는 실제 운영에서 자주 마주친다.

핵심 키워드 3가지: A·CNAME·TXT 레코드, 로컬·루트·최상위·권한 서버, 권한 위임.

답변 레벨 차이

레벨	답변 요지	평가
실버	"A는 IP 매핑, CNAME은 별칭, TXT는 텍스트 값(소유권 검증·메일 인증). DNS 서버도 로컬·루트·최상위·권한처럼 역할에 따라 나뉜다"	기본기는 있으나 이름 나열에 가깝다. 각 서버의 역할 설명과 "왜 나누는가"(권한 위임)가 빠졌다
골드	위 핵심 답변	① 레코드의 정의를 먼저 깔고 ② 서버의 책임을 나눠 설명하고 ③ 권한 위임 구조의 이유(관리 분산·부하/장애 분산)까지 설명

꼬리 질문

여기까지가 DNS 한 묶음이다. 브라우저가 IP를 얻었으니, 다음은 그 주소의 서버와 실제로 어떤 메시지를 주고받는지 — HTTP로 이어진다. (→ 질문 10)

10. HTTP란 무엇이고 동작 방식을 설명해 주세요

핵심 답변 (골드 수준)

HTTP는 웹에서 클라이언트와 서버가 리소스를 주고받기 위해 사용하는 응용 계층 프로토콜이다.

클라이언트는 URI로 대상 리소스를 지정하고 GET이나 POST 같은 메서드로 원하는 동작을 표현해 요청을 보낸다.
서버는 요청을 처리한 뒤 상태 코드, 헤더, 본문을 담아 응답한다.
즉 HTTP는 데이터를 직접 운반하는 프로토콜이라기보다 요청과 응답의 의미와 형식을 정하는 규칙이다. 실제 연결과 전송은 아래 계층의 TCP나 QUIC 같은 프로토콜이 맡고, HTTP는 그 위에서 어떤 리소스에 어떤 동작을 할지 약속한다.

포인트:

"데이터"가 아니라 **"리소스"**라고 말한다 — 서버에 있는 어떤 대상(문서, 사용자 정보, 주문 내역 등)을 중심으로 보는 통신임을 드러낸다.
요청을 **URI(대상) + 메서드(동작)**로 쪼개서 설명한다.
응답을 상태 코드·헤더·본문으로 나눠 말하면 이후 상태 코드나 헤더 질문으로 이어져도 자연스럽다.
HTTP의 위치(응용 계층, 전송은 TCP/QUIC)까지 말하면 네트워크 전체 흐름 안에서 설명할 수 있다.

핵심 키워드 3가지 + α: 응용 계층 프로토콜, URI와 메서드, 상태 코드·헤더·본문 (+ 전송은 TCP/QUIC 같은 아래 계층이 맡는다).

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"웹에서 데이터를 주고받는 프로토콜. 주소를 입력하면 HTTP로 요청이 가고 화면이 뜬다"	결과만 말했다. 누가 요청하고 누가 응답하는지, 어떤 규칙으로 오가는지 없음
실버	"클라이언트-서버 간 통신 규약. 요청을 보내면 처리해서 응답을 돌려주고 HTML·JSON 등을 주고받는다"	요청-응답 구조는 나왔지만, 어떤 대상에 어떤 동작을 표현하는지와 네트워크 구조 안의 위치가 빠졌다
골드	위 핵심 답변	리소스 중심 + URI/메서드 + 상태 코드·헤더·본문 + 계층 역할 분리

꼬리 질문

"HTTP는 요청과 응답을 계속 연결된 상태로 관리하나요? 서버가 이전 요청을 기억하나요?" — 비연결성과 무상태성으로 이어진다. (→ 질문 11)

11. HTTP의 특징은 무엇인가요 (비연결성과 무상태성)

핵심 답변 (골드 수준)

HTTP의 핵심 특징은 비연결성과 무상태성이다.

비연결성: 서버가 클라이언트와의 연결을 필요 이상으로 계속 점유하지 않고 요청-응답 단위로 자원을 사용하는 성질이다. HTTP/1.1 이후에는 keep-alive로 연결을 재사용할 수 있지만, 애플리케이션 관점에서는 각 요청이 독립적으로 처리된다.
무상태성: 서버가 이전 요청의 상태를 기본적으로 기억하지 않는 성질이라, 필요한 정보는 클라이언트가 매 요청에 함께 보내야 한다.
이 구조는 서버 확장에는 유리하지만, 로그인처럼 상태 유지가 필요한 기능은 쿠키·세션·토큰 같은 별도 메커니즘으로 보완해야 한다.

포인트:

비연결성을 "매 요청마다 연결 종료"로 단정하지 않는다 — HTTP/1.0 기준으로는 틀린 말이 아니지만, HTTP/1.1 이후의 연결 재사용까지 고려한 "연결 자원을 필요 이상으로 점유하지 않는다"가 더 정확하다.
무상태성을 요청 정보의 책임으로 연결한다 — "클라이언트가 매 요청마다 보내야 한다"가 있어야 로그인 상태 유지 질문에 대응된다.
보완 장치(쿠키·세션·토큰)는 이 시점에서는 큰 방향만 언급한다. 깊은 비교는 꼬리 질문이 왔을 때 하면 된다.

핵심 키워드 3가지: 비연결성(HTTP/1.1 이후 연결 재사용 고려), 무상태성, 상태 유지 보완 메커니즘.

답변 레벨 차이

레벨	답변 요지	평가
실버	"비연결성은 연결 자원을 오래 붙잡지 않는 것, 무상태성은 이전 요청을 기억하지 않는 것. 매 요청이 독립적으로 처리된다"	두 용어의 구분은 좋으나 "그게 왜 장점이죠? 로그인은 어떻게 유지하죠?"에 대한 내용(필요성과 보완)이 빠졌다
골드	위 핵심 답변	버전 변화(keep-alive) 고려, 클라이언트의 정보 전송 책임, 서버 확장 유리 + 상태 유지 보완까지

꼬리 질문

"그러면 HTTP 버전별로 뭐가 달라졌나요?" — HTTP/1.0, 1.1, 2.0, 3.0이 각각 어떤 문제를 줄이기 위해 나왔는지로 이어진다.
"GET과 POST는 뭐가 다르고 PUT/PATCH는 어떻게 구분하나요?" — 메서드 질문으로 이어지고, 여기서 멱등성 키워드가 나온다. (→ 질문 12)

12. HTTP 메서드의 멱등성이란 무엇인가요

핵심 답변 (골드 수준)

HTTP의 멱등성은 같은 요청을 한 번 보내든 여러 번 보내든 서버 리소스의 최종 상태가 같아지는 성질이다.

GET, HEAD, OPTIONS: 안전한(safe) 메서드이며 멱등하다.
PUT, DELETE: 반복 호출해도 최종 상태가 같아지므로 멱등하다. (같은 PUT은 같은 값으로 교체될 뿐이고, DELETE는 첫 요청 이후 이미 삭제된 상태다. 응답 코드는 달라질 수 있지만 서버 리소스의 최종 상태는 같다.)
POST: 호출할 때마다 새 리소스 생성이나 결제 처리 같은 작업이 반복될 수 있어 기본적으로 멱등하지 않다.
PATCH: 구현 방식에 따라 다르다 — 특정 필드를 특정 값으로 바꾸면 멱등하지만, "조회 수 1 증가" 같은 방식이면 반복할 때마다 상태가 달라진다.

멱등성은 재시도와 중복 요청 때문에 중요하다. 네트워크 오류로 같은 요청이 다시 전송될 수 있는데(결제 버튼 재클릭, 클라이언트 타임아웃 후 재시도 등), 멱등하지 않은 요청은 주문이나 결제가 두 번 처리될 수 있어 중복 방지 장치가 필요하다.

포인트: 기준을 "응답 내용이 같다"가 아니라 **"서버 리소스의 최종 상태가 같다"**로 잡아야 한다. 같은 GET 요청을 두 번 보냈을 때 그 사이 데이터가 바뀌면 응답 내용은 달라질 수 있지만, GET은 서버 상태를 바꾸지 않으므로 여전히 멱등하다.

핵심 키워드 3가지: 서버 리소스의 최종 상태, 멱등한 메서드의 예시, 중복 처리 방지.

답변 레벨 차이

레벨	답변 요지	평가
실버	"같은 요청을 여러 번 보내도 결과가 같다는 의미. GET/PUT/DELETE는 멱등, POST는 비멱등"	"결과가 같다"는 표현이 위험하다 — 응답 내용이 항상 같다는 뜻으로 들릴 수 있다
골드	위 핵심 답변	① 기준을 서버 상태로 정정 ② PUT/DELETE를 최종 상태 관점으로 설명 ③ POST/PATCH를 조심스럽게 다루고 ④ 실무적 중요성(재시도·중복)까지 연결

꼬리 질문

여기까지가 HTTP 섹션이다. HTTP 질문은 따로 떨어져 있지 않다 — 요청·응답 구조 → 특징 → 버전 변화 → 메서드/멱등성 → API 설계 질문으로 이어지는 하나의 흐름으로 준비한다. 다음은 HTTPS/TLS로 이어진다. (→ 질문 13)

13. TLS 핸드셰이크는 어떤 순서로 진행되나요 (HTTPS)

이 부분은 강의에서 레벨 비교 없이 보충 슬라이드로 설명된 내용이다. TLS 1.3 기준.

핵심 정리

HTTPS에서 HTTP 요청이 바로 암호화되어 나가는 것이 아니다. 먼저 브라우저와 서버가 ① 어떤 방식으로 보호할지 ② 서버를 믿어도 되는지 ③ 이 연결에서 쓸 암호화 키를 어떻게 준비할지 정하는 과정이 TLS 핸드셰이크다.

클라이언트                                 서버
    │── ClientHello ─────────────────────▶│  지원 TLS 버전, 사이퍼 스위트,
    │                                     │  랜덤 값, 키 교환 정보(클라이언트
    │                                     │  공개 키 key share, ECDHE 등)
    │◀──────────────────── ServerHello ───│  선택한 TLS 버전·사이퍼 스위트,
    │                                     │  서버 쪽 공개 키 key share,
    │                                     │  서버 인증서
    │  [인증서 검증]                        │
    │  브라우저/OS 신뢰 저장소 + CA 체인으로   │
    │  서버 인증서 유효성 확인                │
    │                                     │
    │  [세션 키 도출 — 양쪽에서 각자 계산]     │
    │  클라이언트: 자기 개인 값 + 서버 공개 값  │
    │  서버:      자기 개인 값 + 클라이언트 공개 값
    │                                     │
    │◀────────── Finished 교환 ──────────▶│  핸드셰이크 무결성 + 키 재료 확인
    │                                     │
    │◀═══════ 이후 HTTP 요청/응답을 TLS로 암호화 ═══════▶│

ClientHello — 클라이언트가 지원 가능한 TLS 버전, 사이퍼 스위트, 랜덤 값, 키 교환 정보(클라이언트 측 공개 키 key share, ECDHE 같은 키 교환 알고리즘)를 전송한다.
ServerHello — 서버가 사용할 TLS 버전과 사이퍼 스위트를 고르고, 서버 쪽 공개 키 key share를 보내면서 서버 인증서도 함께 전달한다.
인증서 검증 — 클라이언트는 브라우저/OS의 신뢰 저장소와 CA 체인으로 서버 인증서가 유효한지 검증한다.
세션 키 준비 — 세션 키는 이 TLS 연결에서 HTTP 요청·응답을 암호화/복호화하는 통신용 대칭 키다. 중요한 점은 세션 키를 통째로 네트워크에 보내지 않는다는 것이다.
- 클라이언트와 서버는 각자 이 연결에서만 쓸 개인 값을 만들고, 거기서 만들어진 공개 값(key share)만 상대에게 보낸다.
- 클라이언트는 자기 개인 값 + 서버 공개 값으로, 서버는 자기 개인 값 + 클라이언트 공개 값으로 세션 키를 계산한다. ECDHE 같은 키 교환 알고리즘은 이 두 계산의 결과가 같게 나오도록 설계되어 있다.
- 중간에서 패킷을 훔쳐보는 사람은 양쪽의 공개 값은 볼 수 있지만 개인 값은 네트워크로 나가지 않으므로, 같은 알고리즘을 알아도 같은 공유 비밀 값을 계산할 수 없다.
- TLS는 이 공유 비밀 값을 바로 HTTP 암호화에 쓰는 것이 아니라 키 재료로 사용한다.
Finished 교환 — 지금까지의 핸드셰이크 내용이 중간에서 바뀌지 않았는지, 양쪽이 같은 키 재료를 가지고 있는지 확인한다.
여기까지 끝나면 그때부터 HTTP 요청과 응답이 TLS로 암호화되어 오간다.

정리: TLS 핸드셰이크는 서버를 인증하고, 암호 방식을 맞추고, 이 연결에서 사용할 세션 키(대칭 키)를 준비한 뒤 실제 HTTPS 통신으로 넘어가는 과정이다.

관련 개념(강의에서 언급): 비대칭 키는 인증·서명 역할을 한다 — 개인 키로 서명하고 공개 키로 검증하면 누가 만든 것인지 확인할 수 있다.

꼬리 질문

"서버 인증서는 왜 신뢰할 수 있죠? 왜 CA에서 받아야 하나요? Let's Encrypt는 무료인데 유료 CA와는 뭐가 다르죠?" (→ 질문 14)

14. CA 인증서를 발급받는 이유는 무엇이고, Let's Encrypt와 유료 CA의 차이는 무엇인가요

핵심 답변 (골드 수준)

CA에서 인증서를 받는 이유는 브라우저와 OS가 신뢰하는 루트 CA에서 이어지는 신뢰 체인 안에 들어가 서버 신원을 검증받기 위해서다. 개인이 만든 자가 서명 인증서는 제3자 검증이 없어 기본 신뢰 저장소에 연결되지 않으므로 브라우저가 경고를 표시한다.

Let's Encrypt는 ACME 기반으로 인증서 발급과 갱신을 자동화한 무료 CA이며, 도메인 소유권만 확인하는 DV(Domain Validation) 인증서를 제공한다. 일반 웹사이트는 Let's Encrypt만으로도 HTTPS 적용에 충분한 경우가 많다.

유료 CA와의 차이는 암호화 강도 자체가 아니라 검증 범위와 지원에 있다. 도메인뿐 아니라 회사 정보까지 확인받거나, 장애 대응 지원과 인증서 관리 옵션이 필요한 경우에는 유료 CA를 선택할 수 있다.

포인트:

CA 인증서를 신뢰 체인으로 설명한다 — 브라우저/OS의 신뢰 저장소에 있는 루트 CA에서 이어지는 체인 안에 있어야 검증 근거가 생긴다.
Let's Encrypt는 "테스트용이라서 무료"가 아니다 — 브라우저와 OS가 신뢰하는 정식 CA이며, 자동화된 방식으로 도메인 소유권을 확인해 발급한다.
유료 CA 선택의 기준은 가격이 아니라 검증 범위와 운영 지원이다.

핵심 키워드 4가지: 신뢰 체인, 자가 서명 인증서(의 한계), Let's Encrypt = 무료 CA + DV, 유료 CA와의 차이 = 검증 범위와 운영 지원.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"유료 CA가 더 안전하고, Let's Encrypt는 무료라 개인 프로젝트·테스트용"	위험한 프레임. Let's Encrypt도 정식 CA이고 암호화 강도는 무료/유료로 갈리지 않는다. 가격만 보고 인증서를 이해한 것으로 보인다
실버	"신뢰 기관이 사이트를 확인했다는 증명을 받기 위해 CA 발급. 자가 서명은 브라우저가 경고. Let's Encrypt는 무료로 발급해 주는 CA"	기본기는 있으나 Let's Encrypt의 검증 범위(DV), 유료 CA와의 실제 차이가 비어 있어 "그럼 회사들은 왜 돈 내고 사나요?"에 취약
골드	위 핵심 답변	신뢰 체인 구조, ACME/DV, 검증 범위·운영 지원이라는 차이 기준까지

실전 사례: 야놀자 면접에서 "CA 인증서를 발급받는 이유와 무료 CA인 Let's Encrypt와의 차이"를 그대로 질문받은 경험이 소개되었다.

꼬리 질문

여기까지가 HTTPS 한 묶음이다. 다음은 그 위에서 API를 어떻게 설계하는지 — REST API와 CORS로 이어진다. (→ 질문 15)

15. RESTful API란 무엇이고 REST풀하게 설계한다는 것은 어떤 의미인가요

핵심 답변 (골드 수준)

RESTful API는 리소스를 중심으로 URI를 설계하고, HTTP 메서드와 상태 코드를 표준 의미에 맞게 사용하는 API 설계 방식이다. 핵심은 세 가지다.

URI는 행위가 아니라 리소스를 표현한다 — /users/1처럼 사용자 리소스를 나타내고, /getUser처럼 동사를 넣은 URI는 피한다. getUser는 서버가 어떤 함수를 실행하는지에 가깝고, /users/1은 클라이언트가 어떤 대상을 다루는지 보여준다.
행위는 HTTP 메서드로 표현한다 — GET은 조회, POST는 생성, PUT/PATCH는 수정, DELETE는 삭제처럼 메서드의 의미를 일관되게 사용한다. 상태 코드까지 표준 의미에 맞게 쓰면 호출하는 쪽이 응답을 예측하기 쉬워진다.
요청은 무상태성을 지킨다 — 서버가 클라이언트의 이전 요청 상태에 의존하지 않도록, 요청마다 인증 정보·리소스 식별자·필요한 파라미터를 포함한다.

이렇게 리소스 / 행위 / 요청 상태를 분리해서 설계하면 클라이언트와 서버가 API의 의미를 예측 가능하게 이해할 수 있다.

핵심 키워드 3가지: 리소스 중심 URI, HTTP 메서드와 상태 코드, 무상태성.

답변 레벨 차이

레벨	답변 요지	평가
실버	"URI를 명사로 만들고 HTTP 메서드를 CRUD에 매핑하는 방식" (면접장·실무에서 흔한 수준)	URI·메서드·CRUD는 나왔지만 ① 왜 리소스 중심이어야 하는지 ② GET/POST를 왜 구분해야 하는지 ③ 무상태성이 빠져서 "API 명명 규칙" 수준으로 들린다
골드	위 핵심 답변	리소스/행위/무상태성의 3분리 + 각각의 이유. 클라이언트-서버의 역할 분리까지 이어진다

실전 사례: 야놀자 면접에서 URI와 메서드 얘기만 하고 "왜 그렇게 설계해야 하는지"를 풀지 못해 아쉬웠던 경험이 소개되었다. 이 질문은 REST라는 단어를 외웠는지가 아니라 API를 리소스 중심으로 바라보고 있는지를 확인한다.

꼬리 질문

"요즘은 MSA에서 gRPC를 많이 쓰는데, REST API와 gRPC는 뭐가 다른가요?" (→ 질문 16)

16. REST API와 gRPC의 차이는 무엇이고 gRPC는 어떤 상황에 쓰나요

핵심 답변 (골드 수준)

REST API는 리소스를 URI로 표현하고 HTTP 메서드로 조작하는 방식이며, gRPC는 원격 서버의 함수를 호출하듯 통신하는 RPC 프레임워크다.

일반적인 REST API가 HTTP + JSON 조합을 많이 쓴다면, gRPC는 HTTP/2 위에서 Protobuf를 사용한다.
Protobuf는 이진 직렬화 포맷이라 JSON보다 데이터 크기가 작고 파싱 비용이 낮으며, proto 스키마를 기준으로 클라이언트와 서버 코드를 생성해 서비스 간 계약을 명확히 할 수 있다.
HTTP/2 기반이라 하나의 연결에서 다중 스트림과 양방향 스트리밍도 사용할 수 있다.
그래서 gRPC는 여러 언어로 작성된 서비스들이 내부에서 자주 통신하는 MSA 환경이나 서버 간 통신에 잘 맞는다.
다만 사람이 읽기 어렵고, proto 관리가 필요하며, 브라우저에서 직접 호출하려면 gRPC-Web이나 프록시 구성이 필요해 외부 공개 API에는 REST가 더 단순한 선택일 때가 많다.

포인트:

먼저 통신 모델을 잡는다 — 리소스 조작 vs 원격 함수 호출. 이 차이를 앞에 두어야 단순 성능 비교로 흐르지 않는다.
"빠르다"는 결론에 기술적 근거를 붙인다 — HTTP/2 멀티플렉싱 + Protobuf의 작은 크기·낮은 파싱 비용.
사용 기준과 트레이드오프 — proto는 계약을 명확히 해주지만 관리 비용도 만든다. 내부 서버 간 통신에는 gRPC, 외부 공개 API에는 REST가 단순한 선택일 때가 많다.

핵심 키워드 4가지: 리소스 조작 vs RPC 호출, HTTP/2와 Protobuf, proto 스키마(계약), 사용 기준.

답변 레벨 차이

레벨	답변 요지	평가
실버	"REST는 HTTP+JSON, gRPC는 HTTP/2+Protobuf. gRPC는 작고 빨라서 서버 간 통신·MSA에서 사용"	대비는 맞지만 통신 모델 차이(리소스 vs 함수 호출)가 빠져 "JSON이냐 Protobuf냐" 비교로만 들린다. 계약(스키마) 관점과 단점도 없다
골드	위 핵심 답변	통신 모델 → 성능의 근거 → 계약 → 트레이드오프와 사용 기준 순으로 정리

실무 연결: 채널톡에서도 gRPC를 많이 쓰는데, .proto 파일 관리는 낯설지만 서비스 간 계약이 파일로 남고 그 계약으로 코드를 생성할 수 있는 것이 장점으로 소개되었다.

꼬리 질문

"브라우저에서 API를 호출할 때 출처가 다르면 어떻게 되나요?" — 브라우저 보안 정책, SOP와 CORS로 이어진다. (→ 질문 17)

17. SOP와 CORS에 대해 설명해 주세요

핵심 답변 (골드 수준)

**SOP(Same-Origin Policy)**는 브라우저가 스크립트에서 다른 출처의 리소스 응답을 마음대로 읽지 못하게 제한하는 브라우저 보안 정책이다. 여기서 같은 출처란 프로토콜, 호스트, 포트가 모두 같은 경우를 말한다.

**CORS(Cross-Origin Resource Sharing)**는 SOP 때문에 기본적으로 막히는 교차 출처 요청을 서버가 명시적으로 허용할 수 있게 하는 예외 메커니즘이다. 서버는 응답의 Access-Control-Allow-Origin 헤더로 허용할 출처를 알려주고, 브라우저가 이 헤더를 확인해 응답을 클라이언트 코드에 노출할지 결정한다.

CORS 요청은 조건에 따라 본 요청을 바로 보내는 심플 리퀘스트와 본 요청 전에 OPTIONS로 허용 여부를 확인하는 프리플라이트 리퀘스트로 나뉜다.

포인트:

SOP의 주체는 브라우저다 — 서버끼리의 통신을 막는 규칙이 아니라, 브라우저의 스크립트가 다른 출처의 응답을 읽지 못하게 막는 정책이다.
오리진의 3요소 — 도메인만 같다고 같은 출처가 아니다. HTTP와 HTTPS가 다르면 다른 출처이고, 포트가 달라도 다른 출처다.
서버와 브라우저의 역할 분담 — "서버가 풀어준다"만 말하면 반쪽이다. 서버는 허용 출처를 헤더로 말하고, 브라우저가 그것을 보고 응답 노출을 결정한다.
답변 순서가 중요하다 — CORS 에러 해결법부터 말하지 말고, 먼저 SOP가 무엇을 막는지 말한 뒤 CORS를 그 제한의 명시적 예외로 이어간다.

핵심 키워드 4가지: SOP, 오리진의 3요소(프로토콜·호스트·포트), Access-Control-Allow-Origin, 심플 리퀘스트와 프리플라이트 리퀘스트.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"CORS는 다른 출처 요청 시 생기는 문제를 풀어주는 정책. 에러 나면 서버에서 허용해 주면 된다"	실무 경험은 느껴지지만 SOP가 빠져서 CORS가 왜 필요한지 설명이 안 된다
실버	"SOP는 같은 출처끼리만 공유하게 제한하는 브라우저 정책, CORS는 서버가 허용하면 예외를 두는 방식. 서버는 응답 헤더로 허용 출처를 알려준다"	순서는 안정적이나 ① 같은 출처의 판단 기준 ② 허용 헤더 이름 ③ 심플/프리플라이트 구분이 빠졌다
골드	위 핵심 답변	주체(브라우저), 오리진 3요소, 헤더와 역할 분담, 요청 방식 구분까지

실무 배경: 개발 환경의 localhost:3000(리액트) → localhost:8080(API), 운영의 app.example.com → api.example.com처럼 출처가 다른 통신에서 브라우저가 CORS 검사를 수행하고, 서버가 허용하지 않으면 차단된다.

꼬리 질문

"심플 리퀘스트와 프리플라이트 리퀘스트는 정확히 뭐가 다르죠?" (→ 질문 18)

18. 심플 리퀘스트와 프리플라이트 리퀘스트는 어떤 기준으로 나뉘나요

핵심 답변 (골드 수준)

심플 리퀘스트는 GET, HEAD, POST처럼 단순한 메서드와 브라우저가 허용하는 단순 헤더 조건을 만족할 때 프리플라이트 없이 본 요청을 바로 보내는 방식이다. 실무에서 자주 쓰는 application/json 콘텐츠 타입이나 Authorization 헤더가 붙으면 단순 요청 조건을 벗어나 보통 프리플라이트가 발생한다.

프리플라이트 리퀘스트는 본 요청 전에 브라우저가 OPTIONS 요청을 보내 서버가 해당 오리진·메서드·헤더를 허용하는지 먼저 확인하는 방식이다. 이때 서버는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 같은 응답 헤더로 허용 범위를 알려준다.

프리플라이트가 필요한 이유: DELETE나 커스텀 헤더가 포함된 요청처럼 단순하지 않은 교차 출처 요청을 보내기 전에, 서버가 허용하는 범위인지 확인하기 위해서다.
한 번 통과한 프리플라이트 결과는 Access-Control-Max-Age로 캐싱해 예비 요청 비용을 줄일 수 있다.

포인트:

심플 리퀘스트를 조건으로 말한다. 허용 콘텐츠 타입 값을 전부 외울 필요는 없고, "단순한 메서드 + 단순 헤더 조건"이라는 기준과 "application/json·Authorization이 붙으면 보통 프리플라이트가 발생한다"는 실무 사례를 말하면 된다.
프리플라이트가 확인하는 것은 막연한 "허용 여부"가 아니라 이 오리진이, 이 메서드로, 이 헤더를 써서 요청해도 되는지다. 그래서 응답에 Allow-Methods, Allow-Headers가 필요하다.
캐싱까지 붙이면 동작 원리와 성능 비용을 함께 보고 있다는 인상을 준다.

핵심 키워드 4가지: 심플 리퀘스트의 조건, 프리플라이트(OPTIONS), 오리진·메서드·헤더 확인, Access-Control-Max-Age 캐싱.

답변 레벨 차이

레벨	답변 요지	평가
실버	"심플은 바로 본 요청, 프리플라이트는 먼저 OPTIONS를 보내고 허용되면 본 요청"	구분은 맞지만 "언제/어떤 기준으로" 나뉘는지가 없다. 실제 요청에서 왜 OPTIONS가 나갔는지 설명할 수 없다
골드	위 핵심 답변	조건 기준, 프리플라이트가 확인하는 3가지, 응답 헤더, 캐싱까지

흔한 오해: "GET이나 POST는 무조건 심플 리퀘스트"라고 생각하기 쉽지만, 메서드 외에 헤더·콘텐츠 타입 조건도 함께 봐야 한다.

꼬리 질문

출처가 허용된 뒤에도 남는 질문 — "이 요청을 보내는 사용자가 누구냐" — 인증과 인가로 이어진다. (→ 질문 19)

19. HTTP는 무상태인데 로그인 상태는 어떻게 유지하나요

핵심 답변 (골드 수준)

HTTP는 무상태라서 요청마다 사용자를 다시 식별할 인증 정보가 필요하다. 로그인에 성공하면 서버는 클라이언트에게 세션 아이디나 토큰 같은 인증 정보를 발급하고, 클라이언트는 이후 요청마다 그 값을 함께 보낸다.

세션 방식: 서버가 세션 저장소에 사용자 상태를 두고, 클라이언트는 쿠키에 담긴 세션 아이디를 보낸다.
토큰 방식: 서버가 서명된 토큰을 발급하고, 클라이언트는 쿠키나 Authorization 헤더로 토큰을 보내 인증 상태를 전달한다.

아이디나 비밀번호를 직접 저장하지 않는 이유는 민감 정보 노출 위험을 줄이기 위해서다.

포인트:

무상태를 인증 정보의 필요성으로 연결한다 — "서버가 기억하지 못한다 → 그래서 매 요청마다 다시 식별할 정보가 필요하다"까지 이어져야 로그인 상태 유지를 무상태 HTTP의 예외처럼 말하지 않게 된다.
세션 방식과 토큰 방식을 한 문장씩 나눠 말하면 이후 쿠키·세션·JWT 꼬리 질문에 편하게 대응할 수 있다.
"로그인 정보를 저장한다"가 아니라 "민감 정보 대신 인증 증거를 보낸다" — 이 표현이 보안 오해를 피한다.

핵심 키워드 3가지: 무상태, 세션 아이디 또는 토큰, 민감 정보 제외.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"로그인하면 브라우저가 로그인 정보를 저장해 두고 다음 요청부터 그걸로 유지"	질문의 전제(무상태가 왜 문제인지)를 놓쳤고, "로그인 정보"는 비밀번호를 평문 저장하는 것처럼 들려 위험하다
실버	"무상태라 기억 못 하니 로그인 성공 시 쿠키에 값을 저장하고 요청마다 보내 식별"	전제는 잡았으나 쿠키에 무엇을 담는지(세션 ID/토큰, 민감 정보 아님)가 빠졌다
골드	위 핵심 답변	필요성 → 세션/토큰 두 방식 → 민감 정보 배제의 이유까지

꼬리 질문

"사용자를 식별하는 것과, 그 사용자가 어떤 기능을 쓸 수 있는지는 같은 문제인가요?" — 인증과 인가의 차이. (→ 질문 20)

20. 인증과 인가는 어떻게 다른가요

핵심 답변 (골드 수준)

인증(Authentication)은 사용자가 누구인지 확인하는 과정이고, 인가(Authorization)는 인증된 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인하는 과정이다. 인증이 먼저 신원을 확정하고, 인가는 그 신원에 어떤 권한이 연결되는지 판단한다.

구현에서는 역할 단위로 권한을 묶는 RBAC이나 토큰의 접근 범위를 담는 OAuth 스코프로 인가를 표현할 수 있다. 토큰을 가지고 있다는 사실과, 그 토큰으로 특정 작업을 할 권한이 있다는 사실은 별개로 봐야 한다.

실무 감각: 실무에서는 인증보다 인가 로직이 복잡한 경우가 훨씬 많다 — 사용자마다 역할이 다르고 API마다 필요한 권한이 다르기 때문이다. 관리자만 접근 가능한 화면, 본인만 수정 가능한 정보처럼 "누구인지"와 "무엇을 할 수 있는지"는 완전히 다른 문제다.

핵심 키워드 3가지: 인증(신원 확인), 인가(권한 확인), 권한 매핑 방식(RBAC 또는 OAuth 스코프).

답변 레벨 차이

레벨	답변 요지	평가
실버	"인증은 누구인지 확인, 인가는 어떤 기능·데이터에 접근할 수 있는지 확인"	기본 개념은 맞지만 정의만 말한 답변. 권한이 실제로 어디에 저장되고 무엇을 보고 허용/거부하는지가 없다
골드	위 핵심 답변	정의 + 실제 권한 관리 방식(RBAC/스코프) + 토큰 소지 ≠ 권한이라는 구분까지

꼬리 질문

"그 세션 아이디나 토큰은 어디에 담고, 누가 상태를 기억하나요?" — 쿠키와 세션. (→ 질문 21)

21. 쿠키와 세션은 어떻게 다른가요

핵심 답변 (골드 수준)

쿠키와 세션의 핵심 차이는 클라이언트 저장과 서버 저장이다.

쿠키: 클라이언트가 키-밸류 데이터를 저장하고 요청에 함께 보내는 방식이다.
세션: 실제 사용자 데이터를 서버에 저장한 뒤, 클라이언트가 세션 아이디를 쿠키로 보내 서버에서 세션을 찾는 방식이다.

쿠키에 민감 정보를 직접 노출하면 노출·변조 위험이 있으므로 보안 옵션을 사용한다.

옵션	역할
HttpOnly	자바스크립트 접근 차단
Secure	HTTPS 전송만 허용
SameSite	크로스 사이트 요청에서 쿠키 전송 제한

세션은 실제 정보가 서버에 있어 제어하기 쉽지만, 사용자가 늘수록 서버가 관리해야 하는 세션 저장소 비용이 커진다.

포인트:

쿠키와 세션을 대립시키지 않는다 — 세션도 결국 세션 아이디가 쿠키로 오가야 동작한다. 이 연결을 말해야 둘을 따로 외운 것이 아니라 같이 쓰인다는 것을 안다는 뜻이 된다.
보안 옵션을 이름만 던지지 않고 역할로 나눠 말한다.
세션의 **트레이드오프(저장소 비용)**까지 인정하면 이후 JWT 꼬리 질문에 자연스럽게 이어진다.

핵심 키워드 3가지: 클라이언트 저장 vs 서버 저장, 세션 아이디는 쿠키로 전달, 보안 옵션과 저장소 비용.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"쿠키는 브라우저 저장, 세션은 서버 저장. 그래서 세션이 더 안전"	둘을 너무 대립시킨다. 세션 아이디가 쿠키로 오간다는 연결이 없으면 암기에 그친다
실버	"쿠키는 클라이언트 키-밸류 저장, 세션은 서버에 정보 저장 후 세션 아이디만 쿠키로 주고받아 상대적으로 안전"	연결 구조까지 좋으나 쿠키 보안 옵션과 세션의 비용(단점)이 빠졌다
골드	위 핵심 답변	동작(연결 구조) + 옵션(HttpOnly/Secure/SameSite) + 비용(저장소)의 3박자

꼬리 질문

"서버가 세션을 계속 들고 있지 않아도 되는 방식은 없나요?" — 토큰 자체에 검증 가능한 정보를 담는 JWT로 이어진다. (→ 질문 22)

22. JWT는 어떤 구조이고 왜 액세스 토큰과 리프레시 토큰으로 나누나요

핵심 답변 (골드 수준)

JWT는 헤더, 페이로드, 시그니처 세 부분으로 이루어진 서명 기반 토큰이다.

로그인에 성공하면 서버는 헤더와 페이로드를 만들고 서명을 붙여 JWT를 발급하며, 클라이언트는 이후 요청마다 이 토큰을 함께 보낸다.
서버는 토큰을 받을 때 서명과 exp 같은 클레임을 검증해 무결성과 유효성을 확인한다.
페이로드는 암호화가 아니라 인코딩이므로 누구나 열어볼 수 있다. 따라서 비밀번호 같은 민감 정보를 넣지 않아야 한다.

토큰을 나누는 이유:

액세스 토큰은 짧게 두어 탈취 시 피해 시간을 줄인다.
리프레시 토큰은 상대적으로 길게 두어 재로그인 없이 새 액세스 토큰을 받을 수 있게 한다.
이렇게 나누는 이유는 탈취 위험과 사용성의 절충이다.

핵심 키워드 3가지: 헤더·페이로드·시그니처, 서명과 클레임 검증, 위험과 사용성의 절충.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"로그인할 때 서버가 발급해 주는 토큰. 요청 시 보내면 인증된 사용자로 처리"	JWT라는 이름을 쓴 이유(구조·서명)가 없다. "JWT"를 "토큰"으로 바꿔도 같은 말이 된다
실버	"헤더·페이로드·시그니처로 이루어진 토큰. 발급 후 요청마다 검증. 액세스/리프레시로 나눠 사용"	구조는 나왔지만 ① 무엇을 검증하는지(서명·exp) ② 왜 나누는지(이유)가 없다
골드	위 핵심 답변	서명 기반 검증, 페이로드 = 인코딩(민감 정보 금지), 토큰 분리 = 탈취 위험 vs 사용성 절충

꼬리 질문

"그럼 실제로 탈취되면 어떻게 하고, 탈취 여부는 어떻게 판단하나요?" (→ 질문 23)

23. JWT가 탈취되면 어떻게 대응하고 탈취 여부는 어떻게 판단하나요

핵심 답변 (골드 수준)

JWT 액세스 토큰을 별도 저장소 없이 검증하는 구조라면 발급 후 만료 전까지 즉시 폐기하기 어렵다. 그래서:

기본 대응: 짧은 만료 시간으로 피해 시간을 줄인다.
즉시 차단이 필요하면: 토큰 식별자(jti)를 블랙리스트에 저장해 검증 단계에서 거부한다. 이는 검증 시 상태를 조회해야 하므로 JWT의 장점 일부를 포기하는 대신 보안 제어 지점을 얻는 선택이다.
탈취 의심 신호: 평소와 다른 디바이스 핑거프린트, IP·지역 변화, 비정상적으로 잦은 재발급 요청 같은 신호를 조합해 판단한다. (오탐 가능성은 있지만 "평소와 다른 접속 패턴"이라는 모호한 표현보다 훨씬 구체적이다.)
탈취가 확인되면: 리프레시 토큰을 폐기하고 해당 사용자를 강제 로그아웃시켜 재발급 경로를 끊는다.

핵심 키워드 3가지: 짧은 만료 시간, 블랙리스트와 jti, 이상 징후 판단의 구체적 방법론.

답변 레벨 차이

레벨	답변 요지	평가
실버	"탈취되면 만료까지 막기 어려우니 액세스 토큰 만료를 짧게 두고, 리프레시 토큰은 서버에서 폐기 가능하게 관리. 탈취는 평소와 다른 접속 패턴으로 의심"	한계 인식과 방향은 맞지만 ① 즉시 차단이 필요할 때 무엇을 추가하는지(블랙리스트) ② "평소와 다른 패턴"의 구체적 기준이 없다
골드	위 핵심 답변	한계 인정 → 블랙리스트/jti라는 실무 장치 → 구체적 탐지 신호 → 확인 시 조치(리프레시 폐기 + 강제 로그아웃)

실전 사례: 토스뱅크 면접에서 JWT 기본 질문 후 탈취 대응으로 이어졌고, 발급·검증까지는 답했지만 "탈취를 어떻게 의심하고 어떻게 해결할 건가"에서 막혔던 경험이 소개되었다. 이 질문은 JWT의 약점을 제대로 아는지 확인하는 질문이다.

꼬리 질문

"리프레시 토큰을 서버에서 관리한다면 그건 세션이랑 뭐가 다른가요?" (→ 질문 24)

24. 리프레시 토큰을 서버에 저장한다면 세션과 무엇이 다른가요

핵심 답변 (골드 수준)

리프레시 토큰을 서버에 저장하면 JWT 방식도 완전한 무상태가 아니라 부분 상태성을 갖는다. 다만 세션과 완전히 같지는 않다. 차이는 조회 시점이다.

세션: 매 요청마다 세션 아이디로 서버 저장소를 조회한다.
JWT 방식: 일반 요청에서는 액세스 토큰의 서명과 만료 시간을 검증해 처리하고, 리프레시 토큰 저장소는 액세스 토큰 재발급이나 강제 로그아웃을 처리할 때 사용된다.

그래서 세션처럼 서버 제어 지점은 생기지만, 매 요청의 인증 방식은 여전히 토큰 검증에 가깝다. 대신:

액세스 토큰 만료 전 즉시 폐기는 별도 블랙리스트 없이는 어렵다.
매 요청에 토큰 크기만큼 전송 비용이 생긴다.

결국 차이는 상태를 어디까지 저장하고, 언제 조회하느냐에 있다.

핵심 키워드 3가지: 부분 상태성, 조회 시점의 차이, 폐기와 비용. "상태가 있냐 없냐"보다 그 상태를 언제 어떻게 보느냐가 더 중요하다.

답변 레벨 차이

레벨	답변 요지	평가
실버	"리프레시 토큰을 서버에 저장하면 JWT도 상태를 가져 세션과 비슷해진다. 그래도 액세스 토큰은 저장소 조회 없이 검증할 수 있다는 차이가 있다"	부분 상태성 인정과 차이는 잡았지만 "비슷하지만 다르다"는 모호하다. 구체적인 조회 시점의 차이를 말해야 납득된다
골드	위 핵심 답변	부분 상태성 인정 + 매 요청 조회(세션) vs 재발급·강제 로그아웃 시 조회(JWT) + 비용(전송 크기, 블랙리스트)

배경: 이 질문(역시 토스뱅크 꼬리 질문 사례)은 JWT를 무조건 무상태라고 외운 답변을 걸러내는 좋은 질문이다. 리프레시 토큰을 서버에 저장하는 순간 JWT 방식에도 상태가 생긴다.

꼬리 질문

여기까지는 우리 서비스가 직접 로그인 상태를 만들고 관리하는 이야기였다. "구글이나 카카오처럼 외부 서비스의 인증과 권한을 빌려오는 건 어떻게 동작하나요?" — OAuth 2.0. (→ 질문 25)

25. OAuth 2.0의 동작 원리를 설명해 주세요

핵심 답변 (골드 수준)

OAuth 2.0은 사용자의 비밀번호를 클라이언트에 넘기지 않고 특정 자원에 대한 접근 권한 위임을 처리하는 인가 프레임워크다. 본질은 인증(로그인 기능)이 아니라 권한 위임이다.

네 가지 주체:

주체	역할
리소스 오너 (Resource Owner)	자원의 주인 (사용자)
클라이언트 (Client)	자원 접근을 요청하는 애플리케이션
인가 서버 (Authorization Server)	동의를 확인하고 토큰을 발급
리소스 서버 (Resource Server)	실제 자원을 제공

대표적인 흐름인 Authorization Code Grant:

사용자가 동의하면 클라이언트가 먼저 **일회성 인가 코드(authorization code)**를 받는다.
클라이언트는 이 코드를 액세스 토큰으로 교환한다. 이때 클라이언트 시크릿이나 PKCE로 요청 주체를 확인한다.
이후 클라이언트는 액세스 토큰으로 리소스 서버에 요청해 허용된 범위(scope)의 자원에 접근한다.

핵심 키워드 3가지: 접근 권한 위임, 4가지 주체(리소스 오너·클라이언트·인가 서버·리소스 서버), Authorization Code Grant.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"구글·카카오 계정으로 로그인하는 기능. 다른 서비스 계정으로 우리 서비스에 로그인하게 해준다"	사용자가 보는 장면만 말했다. OAuth의 본질(비밀번호를 넘기지 않는 권한 위임 인가 프레임워크)을 완전히 놓친다
실버	"비밀번호를 직접 주지 않고 자원 접근 권한을 위임하는 프로토콜. 동의하면 인가 서버에서 토큰을 받아 자원에 접근"	본질은 잡았으나 ① 누가 무엇을 하는지(4주체) ② 코드 → 토큰 교환 단계가 빠졌다
골드	위 핵심 답변	권한 위임 관점 + 4주체 분리 + 인가 코드 → 토큰 교환(시크릿/PKCE) 순서까지

꼬리 질문

"한 번 로그인하면 여러 서비스를 쓸 수 있는 SSO는 OAuth와 같은 건가요?" (→ 질문 26)

26. SSO는 어떤 구조로 동작하며 OAuth 2.0과는 어떤 관계인가요

핵심 답변 (골드 수준)

SSO는 한 번의 인증 결과를 여러 서비스가 신뢰하여 추가 로그인 없이 접근하게 하는 단일 로그인 구조다.

핵심은 각 서비스(서비스 프로바이더, SP)가 직접 인증하지 않고 중앙의 아이덴티티 프로바이더(IdP)에 인증을 위임하고, IdP가 발급한 증표를 신뢰한다는 점이다.
SSO는 SAML이나 OIDC 같은 표준으로 구현할 수 있다.
OIDC는 OAuth 2.0 위에 인증 계층을 얹은 표준이다. OAuth 2.0 자체는 인가 프레임워크이므로 SSO와 OAuth를 같은 개념으로 보면 안 된다.

포인트:

"한 번 로그인"은 그냥 편한 기능이 아니라 한 번 인증한 결과를 여러 서비스가 믿는 방식이라는 구조로 전달해야 한다.
SSO는 제품명이 아니라 구조이고, 그 구조를 구현하는 대표 표준이 SAML과 OIDC다.
OAuth 2.0(인가) ↔ OIDC(그 위의 인증 계층) ↔ SSO(단일 로그인 구조)의 관계 구분이 이 질문의 핵심이다.

핵심 키워드 3가지: 단일 로그인, IdP와 서비스 프로바이더, SAML/OIDC와 OAuth 2.0의 차이 — SSO는 로그인 구조, OAuth 2.0은 권한 위임 프레임워크.

답변 레벨 차이

레벨	답변 요지	평가
실버	"한 번 로그인하면 여러 서비스를 추가 로그인 없이 쓸 수 있게 해주는 방식. OAuth로 구현하는 경우가 많다"	사용자 경험 설명은 맞지만 '어떻게(How)'가 빠졌다. 특히 "OAuth로 구현"은 위험한 표현 — OAuth는 인가 프레임워크이므로 OIDC 같은 인증 표준까지 구분해야 한다
골드	위 핵심 답변	IdP 중심 구조 + 표준(SAML/OIDC) + OAuth 2.0과의 관계 구분

실무 배경: 채널톡에서도 여러 내부 도구·연동 서비스로 이동할 때 재로그인하지 않기 위해 SSO를 많이 쓴다. 사용자에게는 편하지만, 뒤에서는 중앙 인증 주체를 여러 서비스가 신뢰하는 구조다.

꼬리 질문

여기까지가 인증·인가 섹션이다. 인증 질문이 나오면 먼저 둘로 나눈다 — 누구인지 확인(인증) / 무엇을 할 수 있는지 확인(인가) — 쿠키·세션·JWT·OAuth 2.0·SSO는 그것을 실제 서비스에서 처리하는 방식이다. 다음은 실시간 통신으로 이어진다. (→ 질문 27)

27. 웹소켓이란 무엇인가요 — HTTP와의 차이와 연결 과정

핵심 답변 (골드 수준)

웹소켓은 클라이언트와 서버가 한 번 연결을 수립한 뒤 같은 연결에서 계속 메시지를 주고받는 양방향 지속 연결 프로토콜이다.

HTTP만으로는 서버의 변경 사항을 실시간으로 받으려면 폴링이나 롱 폴링처럼 반복 요청 또는 응답 대기가 필요하지만, 웹소켓은 연결 하나를 유지한 채 양쪽이 필요한 시점에 메시지를 보낼 수 있다.
연결은 일반적으로 HTTP/1.1 기반 HTTP 업그레이드 핸드셰이크로 시작한다.

클라이언트                                서버
    │── HTTP 요청 (웹소켓으로 전환 요청) ──▶│
    │◀── 101 Switching Protocols ────────│  전환 수락
    │                                    │
    │◀═══ 기존 TCP 연결이 웹소켓 연결로 전환 ═══▶│
    │◀═══ 웹소켓 프레임(텍스트/바이너리)으로 양방향 메시지 ═══▶│

클라이언트가 HTTP 요청으로 웹소켓으로 전환하고 싶다고 알린다.
서버가 이를 수락하면 101 Switching Protocols 응답을 돌려준다.
이후 그 TCP 연결이 웹소켓 연결로 전환되고, 텍스트나 바이너리 데이터를 웹소켓 프레임으로 주고받는다.

포인트:

"실시간"이라는 말은 결과에 가깝다 — 골드는 그 결과를 만드는 구조인 양방향 지속 연결을 말한다.
세부 헤더명을 줄줄이 외울 필요는 없고 전환 흐름(HTTP 요청 시작 → 101 응답 → TCP 연결이 웹소켓으로 쓰임)을 기억한다.
연결만 맺었다고 끝이 아니라, 그 뒤에 웹소켓 프레임으로 주고받는다고 해야 HTTP 요청-응답과 다른 통신 방식이라는 것이 선명해진다.

핵심 키워드 3가지: 양방향 지속 연결, HTTP 업그레이드와 101 Switching Protocols, 웹소켓 프레임.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"실시간 양방향 통신 프로토콜. HTTP는 요청-응답인데 웹소켓은 연결을 계속 유지하며 주고받는다"	키워드는 맞지만 결과만 말한다. 왜 HTTP만으로 실시간 수신이 부담인지, 연결이 어떤 과정으로 만들어지는지 없음
실버	"HTTP는 요청해야 응답하는 구조라 실시간 수신엔 폴링/롱 폴링이 필요. 웹소켓은 연결을 유지하며 양방향 메시지를 주고받아 채팅·알림에 적합"	필요성과 차이는 좋으나 연결 전환 과정(처음엔 HTTP였다가 어떻게 웹소켓이 되는지)이 모호하다
골드	위 핵심 답변	구조(양방향 지속 연결) + 업그레이드 핸드셰이크 흐름 + 전환 이후 단위(프레임)

꼬리 질문

"그 연결이 계속 살아 있는지는 어떻게 확인하나요? 그 위에서 메시지는 어떻게 주고받나요?" — 핑퐁과 STOMP. (→ 질문 28)

28. 웹소켓 연결 유지 메커니즘(핑퐁)과 STOMP를 설명해 주세요

핵심 답변 (골드 수준)

핑퐁(하트비트): 웹소켓은 장시간 연결을 유지하므로, 상대가 살아 있는지 확인하고 중간 장비의 유휴 연결 종료를 줄이기 위한 핑퐁 하트비트가 필요하다. 서버나 라이브러리가 핑(ping)을 보내면 상대가 퐁(pong)으로 응답하고, 애플리케이션 레벨에서 별도 하트비트 메시지로 같은 목적을 구현하기도 한다.

STOMP: 웹소켓 위에서 사용하는 메시징 서브 프로토콜이다. CONNECT, SUBSCRIBE, SEND 같은 명령(command)과 헤더, 본문 구조를 제공하고, 데스티네이션(destination) 기반 pub/sub을 표현할 수 있어 채팅방이나 알림 주제처럼 구독 단위로 메시지를 전달하기 좋다.

역할 분리: 기본 웹소켓이 데이터 통로라면, STOMP는 그 위에 메시지 형식과 라우팅 규칙을 얹는 역할이다.

포인트:

핑퐁을 운영 관점으로 설명한다 — 생존 확인은 출발점이고, 오래 열어두는 연결은 중간 장비의 타임아웃 정책을 피할 수 없으므로 유휴 연결 종료 완화라는 목적까지 붙인다.
STOMP를 형식이 아니라 라우팅 규칙으로 설명한다 — 웹소켓만으로도 메시지는 보낼 수 있지만, 여러 채팅방·알림 주제·구독자가 생기면 "어디로 보낼지"가 필요하다. STOMP의 명령과 destination 기반 pub/sub이 바로 그 구독·발행 구조를 표현하는 장치다.

핵심 키워드 4가지: 핑퐁 하트비트, 유휴 연결 종료 완화, STOMP 명령·헤더·본문, 데스티네이션 기반 pub/sub.

답변 레벨 차이

레벨	답변 요지	평가
실버	"연결이 살아있는지 확인하려고 핑퐁 프레임을 주고받는다. STOMP는 웹소켓 위에서 명령·헤더·본문 형식으로 메시지를 구조화하는 프로토콜"	방향은 맞으나 ① 핑퐁이 생존 확인 이상의 목적(유휴 종료 완화)이 있는지 ② STOMP 형식으로 무엇을 얻는지(구독/라우팅)가 빠졌다
골드	위 핵심 답변	운영 장치로서의 핑퐁 + pub/sub 라우팅으로서의 STOMP + 통로/규칙의 역할 분리

꼬리 질문

"모든 실시간 기능에 양방향 통로가 필요할까요?" — 알림·진행률처럼 서버가 밀어주기만 하면 되는 기능의 선택지, SSE로 이어진다. (→ 질문 29)

29. SSE의 개념과 특징, 웹소켓과의 차이를 설명해 주세요

핵심 답변 (골드 수준)

SSE(Server-Sent Events)는 서버에서 클라이언트로 실시간 데이터를 계속 보내기 위한 단방향 스트리밍 기술이다.

웹소켓이 연결 전환 뒤 텍스트나 바이너리 메시지를 양방향으로 주고받는 프로토콜이라면, SSE는 HTTP 응답 스트림을 유지하면서 서버 이벤트를 클라이언트로 흘려보낸다.
브라우저는 EventSource API로 SSE를 지원하고, 서버는 text/event-stream 콘텐츠 타입으로 data: 형식의 이벤트를 내려준다.
연결이 끊기면 브라우저가 기본적으로 자동 재연결을 시도할 수 있어, 알림·진행률·실시간 피드처럼 서버가 일방적으로 갱신을 밀어주는 기능에 잘 맞는다.
대신 텍스트 기반 이벤트 스트림이라서 바이너리 직접 전송이나 클라이언트→서버 실시간 전송에는 맞지 않고, 그런 경우에는 웹소켓이 더 적합하다.

포인트:

기준을 방향성으로 잡는다 — 채팅처럼 클라이언트도 서버로 보내야 하면 웹소켓, 알림·진행률처럼 서버가 밀어주기만 하면 SSE가 더 단순할 수 있다. 이것은 특징이자 선택 기준이다.
SSE를 "HTTP를 쓴다" 수준이 아니라 서버가 응답을 바로 끝내지 않고 열어둔 채 이벤트를 계속 내려주는 구조(HTTP 응답 스트림)로 설명한다. 그래야 폴링과도, 웹소켓과도 구분된다.
**자동 재연결(장점)과 한계(텍스트 기반, 단방향)**를 같이 말한다 — 장단점을 모두 아는 사람이 트레이드오프 비교에서 더 좋은 평가를 받는다.

핵심 키워드 4가지: 단방향 스트리밍, HTTP 응답 스트림, EventSource와 text/event-stream, 자동 재연결과 SSE의 한계.

답변 레벨 차이

레벨	답변 요지	평가
브론즈	"서버에서 클라이언트로 실시간으로 보내주는 기술. 웹소켓과 비슷한데 좀 더 간단"	"비슷하다"에서 멈추면 구분 기준이 없다. 핵심(단방향 스트림)이 빠져 웹소켓의 쉬운 버전으로 이해한 것처럼 들린다
실버	"서버→클라이언트 단방향. 웹소켓은 양방향이라는 게 가장 큰 차이. 일반 HTTP를 그대로 써서 구현이 간단"	방향성 구분은 좋으나 실제 동작(EventSource 연결, text/event-stream 응답)이 빠졌다
골드	위 핵심 답변	방향성 기준 + HTTP 응답 스트림 구조 + 자동 재연결 + 한계까지

실전 팁: "실시간 알림을 웹소켓으로 풀겠다"고 답하면 "서버가 알림을 보내기만 하면 되는데 왜 양방향이 필요하죠?"라고 되물을 수 있다. 실시간이면 무조건 웹소켓이라는 자동 답변을 멈추고 단방향 서버 푸시 선택지를 고려해야 한다.

꼬리 질문

"그냥 폴링 하면 안 되나요? 롱 폴링과 SSE는 뭐가 다르죠?" (→ 질문 30)

30. 폴링 / 롱 폴링 / SSE를 비교하고 SSE 라이프 사이클을 설명해 주세요

핵심 답변 (골드 수준)

세 방식의 비용 구조 비교:

방식	동작	비용 구조
숏 폴링	클라이언트가 정해진 주기마다 요청	새 데이터가 없어도 빈 응답이 반복된다
롱 폴링	새 데이터가 생기거나 타임아웃까지 서버가 응답을 붙잡아 둠	빈 응답은 줄지만 응답이 끝날 때마다 다시 요청해야 한다
SSE	하나의 HTTP 응답 스트림을 유지해 서버 이벤트를 계속 내려줌	반복 요청 비용 자체를 줄인다

셋 다 "실시간 비슷한 것"이 아니라 비용의 종류가 다른 방식이다.

SSE 라이프 사이클:

클라이언트가 EventSource를 생성해 서버에 연결 요청을 보낸다.
서버가 text/event-stream 응답 스트림을 열어둔다.
이후 서버는 data: 형식의 이벤트를 계속 보내고, 클라이언트는 이를 message 이벤트로 받는다.
연결이 끊기면 브라우저가 자동으로 재연결을 시도하고, 서버는 retry 간격을 지정할 수 있다.
서버가 이벤트 id와 재전송을 지원하면, 클라이언트는 Last-Event-ID로 마지막 이벤트 이후부터 이어받을 수 있다.

주의: 자동 재연결이 곧 자동 이어받기는 아니다. 서버가 이벤트 id를 내려주고 그 id 이후 이벤트를 다시 보내줄 수 있어야 Last-Event-ID 이어받기가 가능하다. 이 조건을 붙이면 기술적으로 훨씬 정확한 답이 된다.

핵심 키워드 4가지: 숏 폴링, 롱 폴링, SSE 지속 스트림, 자동 재연결과 Last-Event-ID 이어받기.

답변 레벨 차이

레벨	답변 요지	평가
실버	"숏 폴링은 일정 간격 반복 요청, 롱 폴링은 새 데이터가 생길 때까지 응답을 미뤘다가 전달, SSE는 한 번 연결하면 계속 흘려보내는 스트림이라 반복 요청 불필요"	기본 비교는 되지만 ① 비용의 종류가 어떻게 달라지는지 ② 질문에 포함된 SSE 라이프 사이클이 빠졌다
골드	위 핵심 답변	비용 구조를 방식별로 다르게 설명 + 라이프 사이클을 순서대로 + Last-Event-ID를 조건부로 정확히 설명

실전 팁: "출석 현황 실시간 갱신에 폴링을 쓰셨는데 왜 SSE를 고려하지 않으셨나요?" 같은 질문이 나올 수 있다. 이때 폴링이 틀렸다는 식으로 답하면 안 된다 — 갱신 주기가 길고 구현을 단순하게 가져가고 싶다면 폴링도 충분히 합리적이다. 면접관이 보는 것은 선택의 사실이 아니라 왜 그 선택이 그 상황에 맞았는지다.

실시간 통신 섹션 총정리 — 선택 기준

웹소켓: 양방향 지속 연결이 필요할 때 강하다. 핑퐁과 STOMP를 묶으면 오래 유지되는 연결과 구독 구조까지 설명할 수 있다.
SSE: 서버가 클라이언트로만 밀어주면 되는 상황에서 HTTP 응답 스트림과 자동 재연결을 활용하는 선택지다.
폴링/롱 폴링: 단순하지만 반복 요청·재요청 비용을 함께 봐야 한다.

면접에서는 도구 이름보다 선택 기준이 훨씬 중요하다. 양방향이 필요한지, 서버 푸시만 필요한지, 갱신 주기는 어떤지까지 말할 수 있으면 실시간 통신 질문을 한 묶음으로 정리한 것이다.

Network 면접 Q&A 정리 — 인강 노트

목차

1. www.google.com 접속 시 웹 브라우저 요청 흐름을 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

2. TCP가 무엇이고 장단점을 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

3. UDP는 무엇이고 TCP와 어떻게 다른가요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

4. 3웨이 / 4웨이 핸드셰이크에 대해 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

5. TCP는 데이터가 안전하게 도착한다는 것을 어떻게 보장하나요 (신뢰성·흐름 제어·혼잡 제어)

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

6. TCP/IP는 무엇이고 OSI 7계층과의 관계는 무엇인가요 (TCP와 TCP/IP는 같은 건가요)

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

7. DNS가 무엇이고 www.naver.com 접속 과정을 DNS와 연관지어 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

8. DNS 서버에 IP 주소를 요청할 때 왜 UDP를 사용하나요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

9. DNS 서버는 어떤 종류가 있고, A/CNAME/TXT 같은 레코드는 왜 나뉘나요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

10. HTTP란 무엇이고 동작 방식을 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

11. HTTP의 특징은 무엇인가요 (비연결성과 무상태성)

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

12. HTTP 메서드의 멱등성이란 무엇인가요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

13. TLS 핸드셰이크는 어떤 순서로 진행되나요 (HTTPS)

핵심 정리

꼬리 질문

14. CA 인증서를 발급받는 이유는 무엇이고, Let's Encrypt와 유료 CA의 차이는 무엇인가요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

15. RESTful API란 무엇이고 REST풀하게 설계한다는 것은 어떤 의미인가요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

16. REST API와 gRPC의 차이는 무엇이고 gRPC는 어떤 상황에 쓰나요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

17. SOP와 CORS에 대해 설명해 주세요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

18. 심플 리퀘스트와 프리플라이트 리퀘스트는 어떤 기준으로 나뉘나요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

19. HTTP는 무상태인데 로그인 상태는 어떻게 유지하나요

핵심 답변 (골드 수준)

답변 레벨 차이

꼬리 질문

20. 인증과 인가는 어떻게 다른가요

핵심 답변 (골드 수준)

답변 레벨 차이