네트워크 리드·아키텍트 CS 기초 면접

네트워크 리드 · 아키텍트 (10년+) CS 기초 7문항 조회수 40 · 2026-08-04 (화) 15:15:01
1 네트워크 아키텍처
Hard

Q. 대규모 글로벌 서비스에서 Anycast와 Unicast를 함께 사용하는 아키텍처를 설계한다고 가정합니다. 각각의 라우팅 방식이 어떤 원리로 동작하며, 어떤 서비스 계층에 각각을 적용하는 것이 적절한지 설명해주세요. 특히 장애 상황에서의 동작 차이도 함께 설명해주세요.

DNS, CDN, 로드밸런서 등 각 계층의 특성과 요구사항을 고려해보세요.

A. 모범답안

Unicast는 하나의 IP 주소가 특정 단일 목적지를 가리키며, 라우팅 테이블에 따라 특정 경로로만 패킷이 전달됩니다. Anycast는 동일한 IP 주소를 여러 지리적 위치의 서버에 할당하고, BGP 라우팅 프로토콜이 네트워크 토폴로지상 가장 가까운 노드로 패킷을 자동 라우팅합니다. DNS나 CDN 엣지 서버처럼 stateless하고 지연시간이 중요한 서비스는 Anycast를 적용하여 자동 지역 분산과 DDoS 완화 효과를 얻습니다. 반면 세션 상태를 유지해야 하는 애플리케이션 서버나 데이터베이스는 Unicast를 사용하고 상위 레이어(L7)에서 로드밸런싱을 수행합니다. Anycast 환경에서 특정 노드 장애 시 BGP가 자동으로 라우팅을 변경하여 다음 가까운 노드로 트래픽이 전환되지만, 진행 중인 TCP 연결은 끊어질 수 있어 재시도 로직이 필요합니다.

핵심 포인트
  • • Anycast는 동일 IP를 여러 위치에 할당하여 BGP가 최근접 노드로 라우팅
  • • Stateless 서비스(DNS, CDN)는 Anycast, Stateful 서비스는 Unicast 적용
  • • Anycast는 자동 장애 전환이 가능하지만 TCP 세션 유지는 보장하지 않음
답변에 넣으면 좋은 키워드
Anycast Unicast BGP 라우팅 stateless 지연시간 장애 전환
실무에서는

Cloudflare, AWS Route53 같은 글로벌 DNS 서비스와 CDN에서 Anycast를 활용하여 전 세계 사용자에게 낮은 지연시간을 제공합니다.

Follow-up 질문

Anycast 환경에서 TCP 연결이 끊어지는 문제를 해결하기 위해 애플리케이션 레벨에서 어떤 전략을 사용할 수 있을까요?

2 TCP/IP 프로토콜
Hard

Q. TCP의 혼잡 제어 알고리즘 중 Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery의 동작 원리와 각 단계 간 전환 조건을 설명해주세요. 특히 cwnd(congestion window)와 ssthresh(slow start threshold) 값이 어떻게 변화하는지 구체적으로 설명해주세요.

패킷 손실 감지 방법(타임아웃 vs 중복 ACK)에 따라 알고리즘 전환이 다릅니다.

A. 모범답안

Slow Start는 연결 초기에 cwnd를 1 MSS부터 시작하여 ACK를 받을 때마다 지수적으로 증가시켜 네트워크 용량을 빠르게 탐색합니다. cwnd가 ssthresh에 도달하면 Congestion Avoidance 단계로 전환되어 RTT마다 cwnd를 1 MSS씩 선형 증가시킵니다. 패킷 손실이 3개의 중복 ACK로 감지되면 Fast Retransmit이 동작하여 타임아웃을 기다리지 않고 즉시 재전송하고, ssthresh를 현재 cwnd의 절반으로 설정한 후 Fast Recovery로 전환하여 cwnd를 ssthresh + 3으로 설정합니다. 타임아웃으로 손실이 감지되면 더 심각한 혼잡으로 판단하여 ssthresh를 cwnd의 절반으로 설정하고 cwnd를 1로 초기화하여 Slow Start부터 다시 시작합니다. 이러한 메커니즘으로 TCP는 네트워크 상태에 적응적으로 전송률을 조절합니다.

핵심 포인트
  • • Slow Start는 지수 증가, Congestion Avoidance는 선형 증가로 cwnd 조절
  • • 3 중복 ACK 시 Fast Retransmit/Recovery, 타임아웃 시 cwnd 1로 초기화
  • • ssthresh는 혼잡 감지 시 현재 cwnd의 절반으로 설정되어 재전송 기준점 역할
답변에 넣으면 좋은 키워드
cwnd ssthresh Slow Start Congestion Avoidance Fast Retransmit Fast Recovery 중복 ACK
실무에서는

고성능 API 서버나 스트리밍 서비스에서 TCP 혼잡 제어 튜닝을 통해 처리량과 지연시간을 최적화합니다.

Follow-up 질문

최근 데이터센터 환경에서 사용되는 DCTCP나 BBR 같은 현대적 혼잡 제어 알고리즘은 전통적인 TCP Reno/Cubic과 어떤 차이가 있나요?

3 네트워크 보안
Hard

Q. TLS 1.3에서 TLS 1.2 대비 개선된 핸드셰이크 프로세스와 보안 강화 사항을 설명해주세요. 특히 0-RTT 재개 연결의 동작 원리와 보안상 트레이드오프도 함께 설명해주세요.

핸드셰이크 라운드트립 수와 사용 가능한 암호화 스위트의 변화를 중심으로 생각해보세요.

A. 모범답안

TLS 1.3은 핸드셰이크를 1-RTT로 단축하여 TLS 1.2의 2-RTT 대비 연결 설정 시간을 절반으로 줄였습니다. 클라이언트가 ClientHello에서 키 교환 파라미터를 미리 보내면 서버가 ServerHello와 함께 암호화된 데이터를 즉시 전송할 수 있습니다. RSA 키 교환과 정적 DH를 제거하고 완전 순방향 비밀성(PFS)을 제공하는 ECDHE만 지원하여 과거 세션 키 노출 시에도 이전 통신 내용을 보호합니다. 0-RTT 모드는 이전 세션의 PSK(Pre-Shared Key)를 사용하여 핸드셰이크 없이 즉시 애플리케이션 데이터를 전송할 수 있지만, 재전송 공격(replay attack)에 취약하므로 멱등성이 보장되는 요청에만 사용해야 합니다. MD5, SHA-1, RC4 같은 취약한 암호화 알고리즘을 완전히 제거하고 AEAD 암호만 지원하여 보안을 강화했습니다.

핵심 포인트
  • • 1-RTT 핸드셰이크로 연결 시간 단축, 완전 순방향 비밀성 필수 적용
  • • 0-RTT는 재연결 시 지연 제거하지만 replay attack 위험으로 멱등 요청에만 사용
  • • 취약한 암호화 스위트 제거 및 AEAD 암호만 지원하여 보안 강화
답변에 넣으면 좋은 키워드
TLS 1.3 1-RTT 0-RTT 완전 순방향 비밀성 ECDHE replay attack AEAD
실무에서는

CDN과 API 게이트웨이에서 TLS 1.3 최적화를 통해 모바일 환경의 핸드셰이크 지연을 줄여 사용자 경험을 개선합니다.

Follow-up 질문

0-RTT의 replay attack 위험을 완화하기 위해 서버 측에서 구현할 수 있는 방어 메커니즘에는 어떤 것들이 있나요?

4 DNS 아키텍처
Medium

Q. 대규모 마이크로서비스 환경에서 서비스 디스커버리를 구현할 때 DNS 기반 방식과 별도의 서비스 레지스트리(Consul, etcd) 방식의 장단점을 비교 설명해주세요. 각 방식에서 장애가 발생한 인스턴스를 제외하는 메커니즘도 함께 설명해주세요.

TTL, 헬스체크, 전파 지연, 클라이언트 캐싱 측면을 고려해보세요.

A. 모범답안

DNS 기반 방식은 표준 프로토콜을 사용하여 별도 클라이언트 라이브러리가 불필요하고 기존 인프라와 통합이 쉽지만, TTL로 인한 캐싱 문제와 헬스체크 반영 지연이 발생할 수 있습니다. 서비스 레지스트리 방식은 실시간 헬스체크와 즉각적인 인스턴스 제거가 가능하며, 메타데이터(버전, 태그)를 함께 저장할 수 있어 정교한 라우팅이 가능합니다. DNS는 장애 인스턴스를 제거하려면 DNS 레코드를 업데이트하고 TTL이 만료될 때까지 기다려야 하지만, Consul 같은 레지스트리는 헬스체크 실패 시 즉시 서비스 목록에서 제외하고 watch 메커니즘으로 클라이언트에 실시간 알림합니다. 실무에서는 외부 트래픽은 DNS 기반 로드밸런싱을, 내부 서비스 간 통신은 서비스 메시나 레지스트리 기반 디스커버리를 사용하는 하이브리드 접근이 일반적입니다.

핵심 포인트
  • • DNS는 표준 프로토콜 장점이 있지만 TTL 캐싱과 헬스체크 반영 지연 존재
  • • 서비스 레지스트리는 실시간 헬스체크와 즉각적인 인스턴스 제거 가능
  • • 외부는 DNS, 내부는 레지스트리 기반 하이브리드 접근이 실무적
답변에 넣으면 좋은 키워드
DNS 서비스 디스커버리 TTL 헬스체크 서비스 레지스트리 Consul Service Mesh
실무에서는

MSA 환경에서 동적으로 스케일되는 수백 개의 서비스 인스턴스를 자동으로 발견하고 로드밸런싱하는데 필수적입니다.

Follow-up 질문

Kubernetes 환경에서 Service와 Endpoints 오브젝트가 서비스 디스커버리를 어떻게 구현하는지 설명해주세요.

5 네트워크 성능
Hard

Q. HTTP/2의 멀티플렉싱과 HTTP/3(QUIC)의 스트림 독립성이 어떻게 다르며, 각각이 해결하려는 문제는 무엇인가요? 특히 패킷 손실 상황에서의 동작 차이를 TCP의 Head-of-Line Blocking 관점에서 설명해주세요.

HTTP/2는 TCP 위에서, HTTP/3는 UDP 위에서 동작한다는 점을 고려하세요.

A. 모범답안

HTTP/2는 단일 TCP 연결 위에서 여러 스트림을 멀티플렉싱하여 HTTP/1.1의 파이프라인 문제를 해결했지만, TCP 레벨에서 Head-of-Line Blocking이 여전히 발생합니다. 하나의 패킷이 손실되면 TCP는 순서 보장을 위해 해당 패킷이 재전송될 때까지 이후 모든 패킷의 전달을 블로킹하므로, 논리적으로 독립적인 다른 스트림들도 함께 지연됩니다. HTTP/3는 UDP 기반 QUIC 프로토콜을 사용하여 각 스트림이 독립적인 순서 보장을 가지므로, 특정 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않습니다. QUIC는 연결 마이그레이션 기능도 제공하여 클라이언트 IP가 변경되어도(Wi-Fi에서 LTE로 전환) 연결을 유지할 수 있습니다. 또한 TLS 1.3을 프로토콜에 통합하여 핸드셰이크를 단축하고 0-RTT 연결 재개를 지원합니다.

핵심 포인트
  • • HTTP/2는 TCP 위 멀티플렉싱으로 애플리케이션 레벨 HOL 해결했으나 TCP 레벨 HOL은 존재
  • • HTTP/3(QUIC)는 UDP 기반으로 스트림별 독립적 순서 보장하여 완전한 HOL 제거
  • • QUIC는 연결 마이그레이션과 통합 TLS로 추가 이점 제공
답변에 넣으면 좋은 키워드
HTTP/2 HTTP/3 QUIC 멀티플렉싱 Head-of-Line Blocking 스트림 독립성 연결 마이그레이션
실무에서는

동영상 스트리밍이나 실시간 통신 서비스에서 패킷 손실이 빈번한 모바일 환경의 성능을 개선하는데 HTTP/3가 활용됩니다.

Follow-up 질문

현재 프로덕션 환경에서 HTTP/3 도입 시 고려해야 할 인프라적 제약사항과 모니터링 포인트는 무엇인가요?

6 라우팅 프로토콜
Medium

Q. BGP(Border Gateway Protocol)가 AS(Autonomous System) 간 라우팅에서 경로를 선택하는 기준과 우선순위를 설명해주세요. 특히 AS Path, Local Preference, MED의 역할과 이들이 실제 트래픽 엔지니어링에 어떻게 활용되는지 설명해주세요.

BGP는 거리보다 정책 기반 라우팅 프로토콜이라는 점을 고려하세요.

A. 모범답안

BGP는 최단 경로가 아닌 정책 기반으로 경로를 선택하며, Local Preference(가장 높은 우선순위), AS Path 길이, Origin 타입, MED, eBGP over iBGP 순서로 평가합니다. Local Preference는 AS 내부에서만 전파되며 아웃바운드 트래픽의 출구 경로를 제어하는데 사용되고, 값이 높을수록 선호됩니다. AS Path는 경로에 포함된 AS 번호의 리스트로 루프 방지와 경로 길이 비교에 사용되며, AS Path Prepending으로 인위적으로 경로를 길게 만들어 트래픽을 우회시킬 수 있습니다. MED(Multi-Exit Discriminator)는 인접 AS에게 자신의 AS로 들어오는 인바운드 트래픽의 진입점을 제안하는 용도로, 값이 낮을수록 선호되며 동일 AS에서 온 경로 간에만 비교됩니다. 실무에서는 이들을 조합하여 primary/backup 링크 구성, 트래픽 분산, 비용 최적화를 수행합니다.

핵심 포인트
  • • Local Preference는 아웃바운드 트래픽 제어, MED는 인바운드 트래픽 제안에 사용
  • • AS Path는 루프 방지와 경로 선택에 사용되며 Prepending으로 트래픽 엔지니어링 가능
  • • BGP는 정책 기반 라우팅으로 비즈니스 요구사항에 따른 경로 제어 가능
답변에 넣으면 좋은 키워드
BGP AS Path Local Preference MED AS 트래픽 엔지니어링 정책 기반 라우팅
실무에서는

멀티 ISP 환경에서 트래픽 비용 최적화와 장애 시 자동 페일오버를 위해 BGP 정책을 설계하고 운영합니다.

Follow-up 질문

BGP 하이재킹 공격의 원리와 이를 방지하기 위한 RPKI(Resource Public Key Infrastructure)의 역할을 설명해주세요.

7 네트워크 가상화
Hard

Q. VXLAN(Virtual Extensible LAN)이 기존 VLAN의 한계를 어떻게 극복하는지 설명하고, Overlay 네트워크로서 VXLAN의 캡슐화 과정과 VTEP(VXLAN Tunnel Endpoint)의 역할을 설명해주세요. 특히 멀티테넌트 클라우드 환경에서 네트워크 격리를 어떻게 구현하는지 포함해주세요.

VLAN의 4096개 제한과 L2 도메인 확장 문제를 생각해보세요.

A. 모범답안

VLAN은 12비트 태그로 최대 4096개의 네트워크만 구분할 수 있어 대규모 멀티테넌트 환경에는 부족하며, L2 도메인이 물리적 네트워크 경계에 제한됩니다. VXLAN은 24비트 VNI(VXLAN Network Identifier)로 약 1600만 개의 논리 네트워크를 지원하고, L3 네트워크 위에서 L2 오버레이를 구현하여 데이터센터 간 L2 확장이 가능합니다. VTEP는 호스트나 스위치에 위치하여 원본 이더넷 프레임을 VXLAN 헤더로 캡슐화하고 UDP(포트 4789)로 전송하며, 수신 측 VTEP가 디캡슐화하여 원본 프레임을 복원합니다. 각 테넌트는 독립적인 VNI를 할당받아 완전한 네트워크 격리를 보장하며, 동일한 IP 대역을 여러 테넌트가 중복 사용할 수 있습니다. Kubernetes나 OpenStack 같은 클라우드 플랫폼에서 컨테이너/VM 간 네트워크를 구성하는 기본 기술로 활용됩니다.

핵심 포인트
  • • VXLAN은 24비트 VNI로 VLAN의 4096개 제한 극복 및 약 1600만 개 네트워크 지원
  • • VTEP가 L2 프레임을 UDP로 캡슐화하여 L3 네트워크 위 오버레이 구현
  • • VNI 기반 테넌트 격리로 멀티테넌트 환경에서 독립적 네트워크 제공
답변에 넣으면 좋은 키워드
VXLAN VLAN VNI VTEP Overlay 네트워크 캡슐화 멀티테넌트 네트워크 격리
실무에서는

AWS VPC, Azure VNet 같은 클라우드 네트워크와 Kubernetes CNI 플러그인에서 테넌트 격리와 네트워크 가상화를 구현하는데 사용됩니다.

Follow-up 질문

VXLAN 환경에서 east-west 트래픽 증가로 인한 성능 문제를 해결하기 위한 아키텍처 전략은 무엇이 있을까요?

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!