네트워크 기술 면접 질문 모음 (통합본)

2026.07.18 | 전공자·정보처리기사 수준 | 인프라 직무 대비 | 총 104문항 · ★★★ 최빈출 / ★★ 자주 출제 / ★ 기본

이 파일 하나로 모든 단원이 포함되어 있어 어디로 옮겨도 동작합니다.

단원
네트워크 기초와 계층 모델10문항
데이터링크 계층과 스위칭12문항
IP 주소와 서브네팅 최빈출15문항
라우팅10문항
전송 계층: TCP와 UDP 최빈출16문항
응용 계층: HTTP와 DNS 최빈출15문항
네트워크 보안12문항
실무 네트워크 최빈출14문항

1단원. 네트워크 기초와 계층 모델

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. OSI 7계층을 각 계층의 역할과 함께 설명하세요. ★★★

답안 ① 물리 계층: 비트를 전기·광 신호로 변환해 전송(케이블, 허브). ② 데이터링크 계층: 같은 네트워크 내 프레임 전달, MAC 주소 기반, 오류 검출(스위치, 이더넷). ③ 네트워크 계층: 서로 다른 네트워크 간 패킷 라우팅, IP 주소 기반(라우터). ④ 전송 계층: 종단 간(end-to-end) 신뢰성 있는 전달, 포트 번호로 프로세스 구분(TCP/UDP). ⑤ 세션 계층: 통신 세션의 수립·유지·종료. ⑥ 표현 계층: 데이터 형식 변환, 암호화, 압축. ⑦ 응용 계층: 사용자에게 서비스 제공(HTTP, DNS, SMTP). 면접에서는 "각 계층의 대표 장비와 프로토콜, PDU(비트-프레임-패킷-세그먼트)"까지 이어서 묻는 경우가 많습니다.

관련 개념 PDU(비트/프레임/패킷/세그먼트), 계층별 장비(허브/스위치/라우터), 계층별 주소(MAC/IP/포트)

Q2. OSI 7계층과 TCP/IP 4계층 모델의 차이는 무엇인가요? ★★★

답안 OSI 7계층은 ISO가 만든 이론적 참조 모델이고, TCP/IP 4계층은 실제 인터넷 구현에서 나온 실용 모델입니다. TCP/IP 모델은 네트워크 액세스(물리+데이터링크), 인터넷(네트워크), 전송, 응용(세션+표현+응용)으로 OSI를 압축합니다. OSI는 문제 진단과 표준화 논의의 공통 언어로 쓰이고("L4 스위치", "L7 장애" 같은 표현), 실제 프로토콜 스택은 TCP/IP를 따릅니다. 세션·표현 계층의 기능은 실무에서 대부분 응용 계층(TLS, 직렬화 라이브러리)에 흡수되어 있습니다.

관련 개념 참조 모델 vs 구현 모델, 계층 매핑, L4/L7 용어의 어원

Q3. 캡슐화와 역캡슐화 과정을 설명하세요. ★★★

답안 송신 측에서 데이터가 계층을 내려가며 각 계층의 헤더가 덧붙는 과정이 캡슐화입니다. 응용 데이터에 TCP 헤더(포트)가 붙어 세그먼트가 되고, IP 헤더(IP 주소)가 붙어 패킷이 되고, 이더넷 헤더(MAC 주소)와 트레일러가 붙어 프레임이 되어 비트로 전송됩니다. 수신 측은 역순으로 각 계층이 자기 헤더를 떼어 해석하며 위로 올리는 역캡슐화를 수행합니다. 핵심은 각 계층이 자기 계층 헤더만 보고 판단하며 상위 데이터를 그대로 페이로드로 취급한다는 것으로, 이 독립성 덕분에 계층별 교체·발전이 가능합니다.

관련 개념 헤더/페이로드/트레일러, 계층 독립성, MTU와 헤더 오버헤드

Q4. 회선 교환과 패킷 교환의 차이를 설명하세요. ★★

답안 회선 교환은 통신 전에 전용 경로를 설정하고 통신 내내 그 회선을 독점합니다(전통 전화망). 대역폭이 보장되고 지연이 일정하지만, 침묵 구간에도 자원이 낭비되고 회선 수립 시간이 필요합니다. 패킷 교환은 데이터를 패킷으로 쪼개 각 패킷이 독립적으로 경로를 찾아가며, 링크를 여러 통신이 통계적으로 공유합니다(인터넷). 자원 효율이 높고 장애 우회가 가능하지만, 혼잡 시 지연·손실이 발생하고 순서가 뒤바뀔 수 있습니다. 인터넷이 패킷 교환을 채택했기에 TCP 같은 신뢰성 계층이 필요해졌습니다.

관련 개념 전용 회선, 통계적 다중화, 데이터그램 vs 가상 회선, QoS

Q5. 단위와 지표: 대역폭, 처리량, 지연시간, RTT, 지터의 차이는? ★★★

답안 대역폭(bandwidth)은 링크가 이론적으로 전송할 수 있는 초당 비트 수(용량)입니다. 처리량(throughput)은 실제로 전달된 데이터율로, 혼잡·손실·프로토콜 오버헤드 때문에 대역폭보다 작습니다. 지연시간(latency)은 패킷이 출발지에서 목적지까지 가는 시간으로 전파·전송·처리·큐잉 지연의 합입니다. RTT는 왕복 시간으로 ping이 측정하는 값입니다. 지터(jitter)는 지연의 변동 폭으로 실시간 음성·영상 품질에 치명적입니다. "대역폭이 큰데 왜 느리냐"는 질문에 지연시간(특히 RTT)과 대역폭은 별개 축임을 설명할 수 있어야 합니다. 예로 위성 링크는 대역폭이 커도 RTT가 수백 ms입니다.

관련 개념 4가지 지연 요소, BDP(대역폭-지연 곱), ping/iperf, bps vs Bps

Q6. 유니캐스트, 브로드캐스트, 멀티캐스트, 애니캐스트의 차이는? ★★

답안 유니캐스트는 1:1 전송(일반 통신). 브로드캐스트는 같은 네트워크(브로드캐스트 도메인) 내 전체에게 전송하며 ARP 요청, DHCP Discover가 대표적입니다. 라우터는 브로드캐스트를 차단하므로 서브넷을 넘지 못합니다. 멀티캐스트는 특정 그룹 가입자에게만 전송(IPTV, OSPF의 224.0.0.5, IGMP로 그룹 관리). 애니캐스트는 같은 주소를 여러 노드에 부여하고 라우팅이 가장 가까운 노드로 전달하는 방식으로, 글로벌 DNS 루트 서버와 CDN, 구글 8.8.8.8이 활용합니다. IPv6는 브로드캐스트가 없고 멀티캐스트로 대체했다는 점도 언급하면 좋습니다.

관련 개념 브로드캐스트 도메인, IGMP, 애니캐스트 DNS, IPv6의 브로드캐스트 부재

Q7. 웹 브라우저에 www.google.com을 입력하면 일어나는 일을 설명하세요. ★★★

답안 네트워크 전 계층을 관통하는 종합 문제입니다. ① 브라우저·OS 캐시에서 DNS 확인, 없으면 DNS 리졸버에 질의해 IP 획득(재귀적 질의: 루트→TLD→권한 서버). ② TCP 3-way 핸드셰이크로 서버 443 포트에 연결. ③ TLS 핸드셰이크(인증서 검증, 키 교환)로 암호화 채널 수립. ④ HTTP 요청 전송, 서버(실제로는 로드밸런서→웹 서버→WAS→DB)가 응답. ⑤ 브라우저가 HTML 파싱, 추가 리소스(CSS/JS/이미지)를 병렬 요청, 렌더링. 이 과정에서 하위로는 ARP로 게이트웨이 MAC을 알아내고, NAT를 거치고, 각 라우터가 홉마다 라우팅합니다. 지원 직무에 따라 DNS·TCP·TLS 중 깊게 파고들 부분을 조절해 답하는 것이 요령입니다.

관련 개념 DNS 재귀/반복 질의, 3-way 핸드셰이크, TLS, ARP, NAT, 렌더링 파이프라인

Q8. 인캡슐레이션 관점에서 스위치, 라우터, L4/L7 스위치는 각각 어디까지 보나요? ★★

답안 L2 스위치는 이더넷 프레임의 MAC 주소까지만 보고 포워딩합니다. 라우터(L3)는 IP 헤더의 목적지 주소를 보고 라우팅합니다. L4 스위치(로드밸런서)는 TCP/UDP 포트와 세션 정보까지 보고 서버로 분산합니다. L7 스위치(ALB, 리버스 프록시)는 HTTP 헤더·URL·쿠키 등 응용 데이터까지 해석해 경로 기반 라우팅, 콘텐츠 기반 분기를 수행합니다. 위 계층을 볼수록 지능적인 처리가 가능하지만 그만큼 처리 비용이 커집니다. 클라우드에서는 AWS의 NLB(L4)와 ALB(L7) 선택 기준으로 자주 출제됩니다.

관련 개념 포워딩 vs 라우팅, NLB vs ALB, 리버스 프록시, DPI

Q9. 표준화 기구와 RFC란 무엇인가요? ★

답안 인터넷 프로토콜 표준은 IETF가 RFC 문서로 관리합니다(TCP=RFC 9293, HTTP/1.1=RFC 9112 등). IEEE는 이더넷(802.3), 무선랜(802.11) 등 하위 계층 표준을, ISO는 OSI 모델을, ITU-T는 통신 인프라 표준을 담당합니다. IANA/ICANN은 IP 주소와 도메인, 포트 번호 할당을 관리합니다. 면접에서 직접 묻는 빈도는 낮지만 "well-known 포트는 누가 정하나" 같은 질문의 배경 지식이 됩니다.

관련 개념 IETF/RFC, IEEE 802 시리즈, IANA(포트·주소 할당), well-known 포트(0-1023)

Q10. 네트워크 토폴로지(성형, 버스형, 링형, 메시형)의 특징을 비교하세요. ★

답안 성형(star)은 중앙 장비(스위치)에 모든 노드가 연결됩니다. 관리가 쉽고 한 링크 장애가 국소적이지만 중앙 장비가 단일 장애점(SPOF)입니다. 현대 LAN의 표준입니다. 버스형은 하나의 공유 매체에 모두 연결(초기 이더넷)되어 저렴하지만 충돌과 매체 장애에 취약해 사라졌습니다. 링형은 토큰 패싱으로 충돌이 없지만 한 노드 장애가 전체에 영향을 줄 수 있습니다. 메시형은 노드 간 다중 연결로 내결함성이 최고이며, 데이터센터의 스파인-리프 구조나 백본망이 부분 메시입니다. 실무 질문은 "데이터센터는 왜 스파인-리프인가"(동서 트래픽 증가, 균일한 홉 수)로 이어질 수 있습니다.

관련 개념 SPOF, 스파인-리프, 동서/남북 트래픽, 이중화

↑ 목차로

3단원. 네트워크 계층: IP 주소와 서브네팅 (최빈출 단원)

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. IPv4 주소의 구조와 클래스, 그리고 CIDR가 등장한 배경을 설명하세요. ★★★

답안 IPv4는 32비트 주소로 네트워크 부분과 호스트 부분으로 나뉩니다. 초기에는 A(/8), B(/16), C(/24) 클래스로 고정 분할했지만, B는 너무 크고(6.5만 호스트) C는 너무 작아(254 호스트) 주소가 심하게 낭비됐습니다. CIDR는 클래스를 없애고 프리픽스 길이(/22 등)로 필요한 만큼만 네트워크를 자르는 방식이며, 여러 네트워크를 하나의 프리픽스로 묶는 경로 집약(supernetting)으로 라우팅 테이블 크기도 줄였습니다. 현재 인터넷 라우팅은 전부 CIDR 기반입니다.

관련 개념 클래스풀 vs 클래스리스, 프리픽스 표기, 경로 집약, 주소 고갈

Q2. 서브넷 마스크란 무엇이고, 서브네팅은 왜 하나요? ★★★

답안 서브넷 마스크는 IP 주소에서 어디까지가 네트워크이고 어디부터가 호스트인지 구분하는 32비트 값입니다(255.255.255.0 = /24). IP와 마스크를 AND 연산하면 네트워크 주소가 나오고, 두 IP의 네트워크 주소가 같으면 같은 서브넷(직접 통신), 다르면 게이트웨이를 거칩니다. 서브네팅의 목적은 ① 브로드캐스트 도메인 축소, ② 부서·용도별 망 분리와 보안 정책 적용, ③ 주소 공간의 효율적 배분, ④ 계층적 주소 설계로 라우팅 단순화입니다.

관련 개념 AND 연산, 네트워크/브로드캐스트 주소, 기본 게이트웨이 판단 로직

Q3. 192.168.10.0/26 네트워크에서 사용 가능한 호스트 수와 각 서브넷 범위를 구하세요. ★★★

답안 /26은 호스트 비트가 6비트이므로 서브넷당 주소 64개, 사용 가능한 호스트는 64−2(네트워크 주소, 브로드캐스트 주소 제외)=62개입니다. 192.168.10.0/24를 /26으로 나누면 4개 서브넷: ① .0~.63(네트워크 .0, 브로드캐스트 .63), ② .64~.127, ③ .128~.191, ④ .192~.255. 각 서브넷의 첫/끝 주소를 뺀 범위가 호스트 할당 가능 구간입니다. 이런 계산은 "255.255.255.192가 마스크", "블록 크기는 256−192=64"로 빠르게 푸는 연습이 필요하며, 정보처리기사와 인프라 면접 양쪽에서 가장 흔한 계산 문제입니다.

관련 개념 2^n−2 공식, 블록 크기 계산법, /31·/32의 예외(P2P 링크, 호스트 라우트)

Q4. 공인 IP와 사설 IP의 차이, 사설 대역 3가지를 말해보세요. ★★★

답안 공인 IP는 인터넷에서 유일하며 IANA/ISP가 할당합니다. 사설 IP는 내부망에서 자유롭게 쓰는 주소로 인터넷에서 라우팅되지 않으며, RFC 1918이 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 세 대역을 정의합니다. 사설 IP 장비가 인터넷에 나가려면 NAT로 공인 IP로 변환해야 합니다. 실무에서는 클라우드 VPC CIDR 설계 시 온프레미스 대역과 겹치지 않게 잡는 것(겹치면 VPN/전용선 연결 시 라우팅 충돌)이 중요한 포인트로 자주 출제됩니다. 추가로 169.254.0.0/16(APIPA, DHCP 실패 시 자동 할당)도 알아두면 좋습니다.

관련 개념 RFC 1918, NAT, VPC CIDR 설계, APIPA/링크로컬, CGNAT(100.64/10)

Q5. NAT의 동작 원리와 종류(SNAT/DNAT/PAT)를 설명하세요. ★★★

답안 NAT는 IP 헤더의 주소를 변환해 사설망과 인터넷을 연결합니다. SNAT는 출발지 주소를 변환하며, 내부→인터넷 방향에서 사설 IP를 공인 IP로 바꿉니다. PAT(NAPT)는 포트 번호까지 활용해 공인 IP 하나를 수많은 내부 장비가 공유하는 방식으로, 가정용 공유기와 클라우드 NAT 게이트웨이가 이것입니다. 변환 테이블(내부IP:포트 ↔ 공인IP:포트)을 유지하며 응답을 역변환합니다. DNAT는 목적지 주소를 변환하며, 외부에서 들어온 요청을 내부 서버로 보내는 포트 포워딩·로드밸런서에 쓰입니다. NAT는 주소 절약과 내부망 은닉 효과가 있지만, 종단 간 연결성을 깨서 P2P·IPsec에 문제를 일으키고 상태 테이블이 병목이 될 수 있습니다.

관련 개념 PAT/NAPT, 포트 포워딩, NAT 테이블 고갈, 헤어핀 NAT, STUN(NAT 통과)

Q6. IP 헤더의 TTL 필드는 어떤 역할을 하나요? ★★★

답안 TTL은 패킷이 통과할 수 있는 최대 홉 수로, 라우터를 지날 때마다 1씩 감소하고 0이 되면 폐기되며 발신자에게 ICMP Time Exceeded를 보냅니다. 목적은 라우팅 루프에 빠진 패킷이 영원히 도는 것을 방지하는 것입니다. traceroute는 이를 역이용해 TTL을 1, 2, 3...으로 올려 보내며 각 홉에서 돌아오는 Time Exceeded 응답으로 경로를 알아냅니다. OS별 초기값(리눅스 64, 윈도우 128)이 달라 ping 응답의 TTL로 상대 OS를 추정하기도 합니다.

관련 개념 라우팅 루프 방지, traceroute 원리, ICMP Time Exceeded, IPv6의 Hop Limit

Q7. ICMP는 어떤 프로토콜이고 ping은 어떻게 동작하나요? ★★★

답안 ICMP는 IP 계층의 오류 통보와 진단용 프로토콜입니다(포트 개념 없음). 주요 메시지는 Echo Request/Reply(ping), Destination Unreachable(호스트·포트 도달 불가), Time Exceeded(TTL 만료), Fragmentation Needed(PMTUD)입니다. ping은 Echo Request를 보내고 Reply가 오기까지의 RTT와 손실률을 측정합니다. 주의할 점은 방화벽이 ICMP를 차단하는 경우가 많아 "ping 안 됨 ≠ 서비스 다운"이라는 것이며, 반대로 ICMP를 전부 막으면 PMTUD가 깨져 통신 장애를 만들 수 있어 선별적 허용이 바람직합니다.

관련 개념 Echo Request/Reply, Unreachable 코드, PMTUD와 ICMP 차단 부작용, ICMP 플러드

Q8. IPv6의 특징과 IPv4 대비 개선점을 설명하세요. ★★

답안 IPv6는 128비트 주소로 고갈 문제를 근본 해결합니다(2^128개). 개선점은 ① 헤더 단순화·고정 길이(40바이트)로 라우터 처리 효율화, ② NAT 불필요한 종단 간 연결성 복원, ③ SLAAC로 주소 자동 구성(DHCP 없이 RA 기반), ④ IPsec 지원 내장, ⑤ 브로드캐스트 제거(멀티캐스트로 대체), ⑥ 라우터에서 단편화 금지(출발지만 수행)입니다. 표기는 콜론 16진수(2001:db8::1, 연속된 0은 ::로 축약 1회 가능)입니다. 전환 기술로 듀얼 스택(양쪽 동시 운영, 주류), 터널링, NAT64/DNS64가 있습니다.

관련 개념 SLAAC/RA, 링크로컬(fe80::/10), 듀얼 스택, NAT64, 주소 축약 규칙

Q9. 기본 게이트웨이가 없으면 어떤 통신이 안 되나요? ★★

답안 같은 서브넷 내 통신은 ARP와 L2 포워딩만으로 가능하므로 정상 동작하지만, 다른 서브넷·인터넷으로 나가는 모든 통신이 불가능해집니다. 호스트는 목적지 IP를 서브넷 마스크와 비교해 외부라고 판단하면 패킷을 게이트웨이 MAC으로 보내는데, 그 대상이 없기 때문입니다. 실무 트러블슈팅에서 "내부 서버끼리는 되는데 인터넷만 안 돼요"의 1순위 점검 항목이 게이트웨이 설정(및 게이트웨이 장비의 상태)이며, ip route(리눅스), route print(윈도우)로 확인합니다.

관련 개념 라우팅 판단 로직, 기본 경로(0.0.0.0/0), ip route, 게이트웨이 이중화(VRRP)

Q10. DHCP의 동작 과정(DORA)을 설명하세요. ★★★

답안 DHCP는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 서버를 자동 할당합니다. 과정은 DORA: ① Discover — 클라이언트가 브로드캐스트로 서버 탐색, ② Offer — 서버가 사용 가능한 IP 제안, ③ Request — 클라이언트가 특정 제안 수락을 브로드캐스트(서버 여럿일 때 선택 알림), ④ Ack — 서버가 임대(lease) 확정. 임대 기간의 50% 시점에 갱신을 시도합니다. 서브넷마다 브로드캐스트가 갇히므로, 중앙 DHCP 서버를 쓸 때는 라우터에 DHCP 릴레이를 설정합니다. 보안 이슈로 비인가 DHCP 서버(rogue)가 잘못된 게이트웨이를 뿌리는 공격이 있으며 DHCP 스누핑으로 방어합니다.

관련 개념 DORA, 임대 갱신(T1/T2), DHCP 릴레이, DHCP 스누핑, 고정 임대(reservation)

Q11. IP 단편화는 언제 발생하고 왜 피해야 하나요? ★★

답안 패킷이 링크 MTU보다 크면 라우터(IPv4)나 출발지가 패킷을 조각으로 나눕니다. 재조립은 최종 목적지에서만 수행합니다. 피해야 하는 이유는 ① 조각 하나만 유실돼도 전체 패킷 재전송, ② 라우터·호스트의 처리 부담, ③ 방화벽이 조각을 차단하거나 조각을 악용한 공격(티어드롭 등)이 존재, ④ IPv6는 라우터 단편화를 아예 금지하기 때문입니다. 실무 대응은 PMTUD로 경로 MTU를 탐지하고, TCP는 MSS를 조정(터널 구간에서 MSS 클램핑)해 단편화 자체를 예방하는 것입니다.

관련 개념 단편화 오프셋/식별자, PMTUD, MSS 클램핑, VPN 구간 MTU 이슈

Q12. VRRP 같은 게이트웨이 이중화 프로토콜은 왜 필요한가요? (인프라 연계) ★★

답안 기본 게이트웨이는 서브넷의 단일 장애점입니다. 라우터가 죽으면 해당 서브넷 전체가 외부와 단절됩니다. VRRP는 라우터 두 대 이상이 가상 IP(VIP)와 가상 MAC을 공유하고, 마스터가 광고(advertisement)를 보내다 죽으면 백업이 수 초 내 마스터로 승격해 같은 VIP로 서비스를 잇는 표준 프로토콜입니다. 호스트 입장에서는 게이트웨이 IP가 그대로라 무중단 전환됩니다. 시스코 전용 HSRP, 로드 분산이 가능한 GLBP도 같은 계열이며, 방화벽·로드밸런서 이중화에도 동일한 VIP 개념이 쓰입니다. keepalived가 리눅스에서 VRRP를 구현한 대표 도구입니다.

관련 개념 VIP, 마스터/백업 선출, keepalived, HSRP, 프리엠션

Q13. 클라우드 VPC 설계 시 CIDR와 서브넷은 어떻게 잡아야 하나요? (인프라 연계) ★★★

답안 ① CIDR 크기: 향후 확장을 고려해 넉넉히(/16 권장), 단 온프레미스·타 VPC와 겹치지 않게 잡습니다. 겹치면 VPN·피어링 시 라우팅이 불가능합니다. ② 서브넷 분할: 가용영역(AZ)별 × 용도별(퍼블릭/프라이빗/DB)로 나눕니다. 퍼블릭 서브넷은 IGW 경로를, 프라이빗은 NAT 게이트웨이 경로를 갖습니다. ③ 예약 주소: AWS는 서브넷당 5개(네트워크, 라우터, DNS, 예약, 브로드캐스트)를 제외하고 할당됩니다. ④ 쿠버네티스를 쓰면 파드가 IP를 대량 소비하므로(EKS의 VPC CNI) 서브넷을 크게 잡아야 합니다. IP 고갈은 실제로 흔한 운영 장애입니다.

관련 개념 VPC 피어링과 CIDR 중복, 퍼블릭/프라이빗 서브넷, NAT 게이트웨이, 파드 IP 고갈

Q14. 같은 서브넷의 두 호스트 통신과 다른 서브넷 간 통신의 패킷 흐름 차이를 설명하세요. ★★★

답안 같은 서브넷: 출발 호스트가 목적지 IP를 마스크와 비교해 같은 네트워크임을 확인 → 목적지 IP의 MAC을 ARP로 조회 → 프레임의 목적지 MAC=상대방 MAC으로 직접 전송(스위치 경유). 다른 서브넷: 외부 네트워크로 판단 → 게이트웨이 MAC을 ARP로 조회 → 목적지 IP는 최종 상대로 유지한 채 목적지 MAC만 게이트웨이로 설정해 전송 → 라우터가 IP를 보고 다음 홉으로 라우팅하며 홉마다 MAC 재작성. 핵심 문장은 "IP 주소는 끝까지 유지되고, MAC 주소는 홉마다 바뀐다"이며, 이 원리를 정확히 설명하면 L2/L3 이해를 한 번에 증명할 수 있습니다.

관련 개념 온링크 판단, ARP 대상 결정, 홉바이홉 포워딩, 라우터의 TTL 감소·체크섬 재계산

Q15. 0.0.0.0, 127.0.0.1, 255.255.255.255는 각각 어떤 주소인가요? ★★

답안 0.0.0.0은 '모든 인터페이스' 또는 '미지정 주소'입니다. 서버가 0.0.0.0:80에 바인드하면 모든 NIC에서 요청을 받고, 라우팅 테이블의 0.0.0.0/0은 기본 경로를 뜻합니다. 127.0.0.1은 루프백으로, 자기 자신과의 통신이며 패킷이 NIC 밖으로 나가지 않습니다(127.0.0.0/8 전체가 루프백). 255.255.255.255는 제한된 브로드캐스트로 로컬 세그먼트의 전체에게 전달되며 라우터를 넘지 않습니다(DHCP Discover가 사용). 면접에서 "서버가 127.0.0.1에만 바인드되어 외부 접속이 안 되는 장애"(bind 주소 확인)는 흔한 실무 사례입니다.

관련 개념 바인드 주소, 루프백 인터페이스, 제한된/지향성 브로드캐스트, ss -tlnp 확인

↑ 목차로

4단원. 라우팅

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. 라우터가 패킷을 포워딩하는 과정을 설명하세요. ★★★

답안 라우터는 패킷의 목적지 IP를 라우팅 테이블과 대조해 다음 홉과 출력 인터페이스를 결정합니다. 이때 최장 프리픽스 일치(longest prefix match) 원칙을 따릅니다. 10.1.2.3이 10.0.0.0/8과 10.1.2.0/24 모두에 일치하면 더 구체적인 /24를 선택합니다. 일치 항목이 없으면 기본 경로(0.0.0.0/0)로, 그것도 없으면 폐기 후 ICMP Unreachable을 보냅니다. 포워딩 시 TTL을 1 감소시키고 헤더 체크섬을 재계산하며, L2 헤더를 다음 홉의 MAC으로 재작성합니다. 제어 평면(라우팅 프로토콜로 테이블 구성)과 데이터 평면(실제 포워딩, ASIC 하드웨어 처리)의 분리도 언급하면 좋습니다.

관련 개념 최장 프리픽스 일치, 기본 경로, 제어/데이터 평면, FIB

Q2. 정적 라우팅과 동적 라우팅의 차이와 각각의 사용처는? ★★★

답안 정적 라우팅은 관리자가 경로를 수동 등록합니다. 예측 가능하고 CPU·대역폭 오버헤드가 없으며 보안상 단순하지만, 장애 시 자동 우회가 없고 규모가 커지면 관리가 불가능합니다. 소규모 망, 스텁 네트워크, 기본 경로 지정에 적합합니다. 동적 라우팅은 라우터끼리 프로토콜(OSPF, BGP 등)로 경로 정보를 교환해 자동으로 테이블을 만들고, 장애 시 대체 경로로 수렴합니다. 중대규모 망의 표준입니다. 같은 목적지에 여러 출처의 경로가 있으면 관리 거리(AD)(직접 연결 0 < 정적 1 < eBGP 20 < OSPF 110...)로 우선순위를 정합니다.

관련 개념 수렴(convergence), 관리 거리, 스텁 네트워크, 플로팅 스태틱(백업 경로)

Q3. 거리 벡터와 링크 상태 라우팅 프로토콜의 차이를 설명하세요. ★★★

답안 거리 벡터(RIP)는 이웃에게서 받은 "목적지까지의 거리와 방향"만 알고 이를 주기적으로 전파합니다. 구현이 단순하지만 전체 토폴로지를 모르므로 수렴이 느리고 라우팅 루프(카운트 투 인피니티)가 생길 수 있어 스플릿 호라이즌, 포이즌 리버스, 최대 홉(RIP는 15) 같은 보완책이 필요합니다. 링크 상태(OSPF, IS-IS)는 각 라우터가 링크 상태 정보(LSA)를 전체에 플러딩해 모두가 동일한 토폴로지 지도(LSDB)를 만들고, 다익스트라(SPF) 알고리즘으로 최단 경로를 각자 계산합니다. 수렴이 빠르고 루프에 강하지만 CPU·메모리를 더 씁니다.

관련 개념 벨만-포드 vs 다익스트라, 카운트 투 인피니티, 스플릿 호라이즌, LSA/LSDB

Q4. OSPF의 동작 방식과 에어리어 개념을 설명하세요. ★★

답안 OSPF는 링크 상태 IGP로, 라우터들이 Hello 패킷으로 네이버 관계를 맺고 LSA를 교환해 LSDB를 동기화한 뒤 SPF로 최단 경로를 계산합니다. 비용(cost)은 기본적으로 대역폭 기반입니다. 대규모 망에서는 SPF 재계산과 LSA 플러딩 부담을 줄이기 위해 에어리어로 분할하며, 모든 에어리어는 백본(Area 0)에 연결되어야 하고 경계 라우터(ABR)가 에어리어 간 경로를 요약해 전달합니다. 멀티액세스 구간에서는 DR/BDR을 선출해 LSA 교환을 집중시킵니다. 사내망·데이터센터 IGP의 사실상 표준(IS-IS와 함께)입니다.

관련 개념 네이버/어드제이선시, Area 0, ABR/ASBR, DR/BDR, cost

Q5. BGP는 무엇이고 OSPF 같은 IGP와 어떻게 다른가요? ★★★

답안 BGP는 AS(자율 시스템) 간 경로를 교환하는 EGP로, 인터넷 전체의 라우팅을 담당하는 유일한 프로토콜입니다. IGP가 '조직 내부에서 가장 빠른 경로'를 찾는다면, BGP는 경로 벡터 방식으로 AS 경로 목록(AS_PATH)을 교환하며 '정책적으로 어떤 이웃을 경유할지'를 결정합니다. 비용보다 정책(Local Preference, AS_PATH 길이, MED 등 속성 순서)이 우선입니다. TCP 179로 피어링하고, eBGP(다른 AS 간)와 iBGP(같은 AS 내 전파)로 나뉩니다. 수렴은 느리지만 수십만 프리픽스 규모를 감당합니다. 클라우드에서도 Direct Connect/ExpressRoute, 온프레미스 연동에 BGP가 필수라 인프라 면접 비중이 높아졌습니다.

관련 개념 AS, AS_PATH/Local Pref/MED, eBGP vs iBGP, 풀 테이블(90만+ 프리픽스)

Q6. BGP 하이재킹 같은 라우팅 사고는 왜 발생하나요? (보안 연계) ★★

답안 BGP는 상대가 광고하는 프리픽스가 정당한지 검증하는 장치가 원래 없어서, 실수나 악의로 남의 프리픽스를 광고하면 인터넷 트래픽이 엉뚱한 곳으로 빨려갑니다. 더 구체적인(긴) 프리픽스는 최장 일치로 항상 이기므로 /24 광고로 /16 소유자의 트래픽을 가로챌 수 있습니다. 파키스탄의 유튜브 차단 시도가 전 세계 유튜브를 마비시킨 사건(2008)이 유명합니다. 대응은 RPKI(프리픽스-AS 소유 관계를 암호학적으로 검증하는 ROA), 피어 필터링, IRR 등록이며, 대형 ISP·클라우드 중심으로 RPKI 검증이 확산되고 있습니다.

관련 개념 프리픽스 하이재킹, RPKI/ROA, 경로 유출(route leak), MANRS

Q7. 라우팅 테이블에서 최장 프리픽스 일치 문제를 풀어보세요. ★★

답안 예: 테이블에 ① 0.0.0.0/0 → R1, ② 172.16.0.0/16 → R2, ③ 172.16.5.0/24 → R3이 있을 때 172.16.5.10 행 패킷은 셋 모두에 일치하지만 가장 긴 /24인 R3으로 갑니다. 172.16.9.1은 ①②에 일치해 R2로, 8.8.8.8은 ①만 일치해 R1(기본 경로)로 갑니다. 이 원리 덕분에 "큰 대역은 본사로, 특정 서브넷만 지사로" 같은 세밀한 경로 제어와 경로 집약이 공존할 수 있습니다. 실무에서는 VPN 스플릿 터널링, 클라우드 라우트 테이블 우선순위 해석에 그대로 적용됩니다.

관련 개념 경로 선택 순서(프리픽스 길이 → AD → 메트릭), 라우트 테이블 판독, 스플릿 터널링

Q8. AS(자율 시스템)란 무엇인가요? ★

답안 하나의 관리 주체가 일관된 라우팅 정책으로 운영하는 네트워크 덩어리로, 고유 AS 번호(ASN)를 부여받습니다(예: 통신사, 대형 클라우드, 대기업). 인터넷은 약 7만 개 이상의 AS가 BGP로 연결된 그래프입니다. AS 간 관계는 트랜짓(돈 내고 인터넷 전체 도달성 구매)과 피어링(상호 트래픽 무정산 교환, IX에서 주로)으로 나뉘며, 이 경제적 관계가 BGP 정책(누구에게 어떤 경로를 광고할지)을 결정합니다.

관련 개념 ASN, 트랜짓 vs 피어링, IX(인터넷 익스체인지), 티어1 ISP

Q9. ECMP(등가 다중 경로)란 무엇이고 어디에 쓰이나요? (인프라 연계) ★★

답안 같은 목적지에 대해 비용이 동일한 경로가 여러 개일 때 트래픽을 분산해 대역폭을 활용하는 기법입니다. 패킷 단위로 분산하면 순서 역전으로 TCP 성능이 망가지므로, 플로우 단위 해시(5-튜플)로 같은 플로우는 같은 경로를 타게 합니다. 데이터센터 스파인-리프 구조가 ECMP의 대표 활용처로, 리프에서 여러 스파인으로 균등 분산합니다. 또한 L4 로드밸런싱(라우터에서 VIP를 여러 서버로 ECMP 분산), 애니캐스트와 조합해 대규모 서비스 프론트엔드를 구성합니다. 해시 불균형과 경로 변경 시 플로우 재배치(리해싱) 문제가 운영 포인트입니다.

관련 개념 5-튜플 해시, 스파인-리프, 플로우 극성(elephant flow), consistent hashing

Q10. 트러블슈팅: 특정 목적지로만 통신이 안 될 때 라우팅 관점에서 어떻게 진단하나요? ★★★

답안 ① 내 라우팅 테이블 확인: ip route get <목적지>로 어떤 경로·인터페이스로 나가는지 확인합니다. 잘못된 정적 경로나 더 구체적인 프리픽스가 트래픽을 삼키는지 봅니다. ② traceroute/mtr로 어느 홉에서 끊기는지 파악합니다. 특정 홉 이후 무응답이면 그 지점의 라우팅·방화벽·되돌아오는 경로를 의심합니다. ③ 비대칭 라우팅 확인: 가는 길과 오는 길이 다르면 상태 기반 방화벽이 응답을 차단할 수 있습니다. ④ 클라우드면 라우트 테이블, 보안 그룹/NACL, 피어링 경로를 점검합니다. ⑤ MTU 문제(큰 패킷만 실패)는 ping -s로 크기를 바꿔 테스트합니다. "양방향 경로를 모두 생각한다"가 핵심 원칙입니다.

관련 개념 ip route get, mtr, 비대칭 라우팅과 상태 기반 방화벽, 클라우드 라우트 테이블

↑ 목차로

5단원. 전송 계층: TCP와 UDP (최빈출 단원)

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. TCP와 UDP의 차이를 설명하세요. ★★★

답안 TCP는 연결 지향으로, 3-way 핸드셰이크로 연결을 수립하고 시퀀스 번호·ACK·재전송으로 신뢰성(순서 보장, 유실 복구)을 제공하며 흐름·혼잡 제어를 수행합니다. 대신 헤더가 크고(기본 20바이트) 지연이 있습니다. UDP는 비연결형으로 포트 구분과 체크섬만 제공하는 최소한의 프로토콜입니다(헤더 8바이트). 빠르고 오버헤드가 적지만 유실·순서·중복을 애플리케이션이 처리해야 합니다. TCP는 웹, 메일, 파일 전송 등 정확성이 중요한 곳에, UDP는 DNS, 실시간 스트리밍·게임, VoIP 등 속도·실시간성이 중요한 곳에 쓰입니다. "왜 DNS는 UDP인가"(작은 질의-응답에 연결 수립이 낭비, 단 큰 응답과 존 전송은 TCP) 같은 후속 질문에 대비하세요.

관련 개념 신뢰성 메커니즘, 헤더 비교, DNS의 UDP/TCP 혼용, QUIC(UDP 기반 신뢰 전송)

Q2. TCP 3-way 핸드셰이크 과정을 설명하세요. ★★★

답안 ① 클라이언트가 SYN(시퀀스 번호 x)을 전송 → ② 서버가 SYN+ACK(자신의 시퀀스 y, 응답 x+1)로 응답 → ③ 클라이언트가 ACK(y+1)를 보내면 연결 수립(ESTABLISHED). 3번의 교환이 필요한 이유는 양쪽 모두 자신의 초기 시퀀스 번호(ISN)를 상대에게 알리고 확인받아야 하기 때문입니다. 2-way로는 서버의 ISN을 클라이언트가 확인해줬는지 서버가 알 수 없습니다. ISN을 난수로 정하는 이유는 이전 연결의 지연 패킷과의 혼동 방지와 시퀀스 추측 공격 방어입니다. 서버는 SYN을 받으면 SYN_RECV 상태로 백로그 큐에 쌓아두는데, 이를 노린 것이 SYN 플러딩 공격입니다.

관련 개념 ISN, SYN_RECV/백로그 큐, SYN 플러딩과 SYN 쿠키, TFO(TCP Fast Open)

Q3. TCP 연결 종료(4-way handshake)와 TIME_WAIT 상태를 설명하세요. ★★★

답안 종료는 ① FIN → ② ACK → ③ (반대 방향) FIN → ④ ACK의 4단계입니다. 4단계인 이유는 TCP가 전이중이라 양방향을 각각 닫아야 하고, FIN을 받은 쪽이 남은 데이터를 마저 보낼 수 있어야 하기 때문입니다(하프 클로즈). 먼저 닫은 쪽은 마지막 ACK 후 TIME_WAIT 상태로 2MSL(보통 60초) 대기합니다. 이유는 ① 마지막 ACK가 유실되면 상대의 FIN 재전송에 다시 응답하기 위해, ② 이전 연결의 지연 패킷이 같은 포트 조합의 새 연결에 섞이는 것을 방지하기 위해서입니다. 짧은 연결을 대량으로 맺는 클라이언트(프록시, LB)에서는 TIME_WAIT 소켓이 수만 개 쌓여 포트 고갈이 날 수 있으며, 커넥션 풀·keep-alive 사용과 tcp_tw_reuse 튜닝으로 대응합니다.

관련 개념 하프 클로즈, 2MSL, TIME_WAIT 포트 고갈, tcp_tw_reuse, CLOSE_WAIT 누적(앱이 close 안 함)

Q4. TCP 헤더의 주요 필드와 플래그를 설명하세요. ★★

답안 주요 필드는 출발/목적지 포트(16비트씩), 시퀀스 번호(보낸 바이트 위치), 확인 응답 번호(다음에 받기를 기대하는 바이트), 윈도우 크기(수신 가능 버퍼), 체크섬, 옵션(MSS, 윈도우 스케일, SACK, 타임스탬프)입니다. 플래그는 SYN(연결 요청), ACK(확인), FIN(정상 종료), RST(강제 리셋: 닫힌 포트 접근, 비정상 상태), PSH(버퍼링 없이 즉시 전달), URG(긴급)입니다. 실무에서 RST의 의미(연결 거부 vs 방화벽 리셋 vs 애플리케이션 크래시)를 패킷 캡처로 구분하는 질문이 나올 수 있습니다.

관련 개념 시퀀스/ACK 번호 계산, 윈도우 스케일 옵션, SACK, RST의 발생 원인들

Q5. TCP 흐름 제어(슬라이딩 윈도우)를 설명하세요. ★★★

답안 흐름 제어는 수신자의 처리 능력을 초과하지 않도록 송신 속도를 조절하는 것입니다. 수신자는 ACK에 자신의 남은 버퍼 크기(수신 윈도우, rwnd)를 실어 보내고, 송신자는 ACK 없이 보낼 수 있는 데이터량을 그 범위로 제한합니다. 윈도우 안의 여러 세그먼트를 한꺼번에 보내고 ACK가 오면 윈도우를 미끄러뜨리는(slide) 방식이라 슬라이딩 윈도우입니다. 윈도우가 0이 되면 송신을 멈추고, 제로 윈도우 프로브로 재개 시점을 확인합니다. 원래 16비트(64KB) 한계는 윈도우 스케일 옵션으로 확장하며, 고대역폭·고지연(BDP가 큰) 구간에서는 윈도우가 작으면 대역폭을 못 채우므로 버퍼 튜닝이 성능 포인트입니다.

관련 개념 rwnd, 제로 윈도우, 윈도우 스케일, BDP와 버퍼 사이징, 실리 윈도우 신드롬

Q6. TCP 혼잡 제어(슬로 스타트, 혼잡 회피, 빠른 재전송/회복)를 설명하세요. ★★★

답안 혼잡 제어는 네트워크의 수용 능력을 초과하지 않도록 조절하는 것으로, 송신자가 혼잡 윈도우(cwnd)를 유지하며 실제 전송량은 min(cwnd, rwnd)입니다. ① 슬로 스타트: cwnd를 1 MSS부터 ACK마다 2배씩(RTT당) 지수 증가시켜 가용 대역을 빠르게 탐색합니다. ② 임계값(ssthresh) 도달 후 혼잡 회피: RTT당 1 MSS씩 선형 증가(AIMD). ③ 빠른 재전송: 중복 ACK 3개를 받으면 타임아웃 전에 즉시 재전송. ④ 빠른 회복: 이때 cwnd를 절반으로 줄이고 혼잡 회피로 진행(타임아웃 시에는 cwnd=1로 리셋). 손실을 혼잡 신호로 보는 전통 방식(Reno/CUBIC)과 달리, 구글의 BBR은 대역폭·RTT를 직접 측정해 무선처럼 손실이 혼잡이 아닌 환경에서 성능이 좋습니다. 리눅스 기본은 CUBIC입니다.

관련 개념 cwnd/ssthresh, AIMD, 3 중복 ACK, CUBIC vs BBR, 버퍼블로트

Q7. TCP 재전송은 어떤 조건에서 발생하나요? ★★

답안 ① RTO(재전송 타임아웃): 보낸 세그먼트의 ACK가 RTO 내에 안 오면 재전송합니다. RTO는 측정한 RTT의 평균과 편차로 동적 계산되며(Jacobson 알고리즘), 재전송할 때마다 2배씩 늘어납니다(지수 백오프). ② 빠른 재전송: 수신자가 결번을 발견하면 같은 ACK를 반복 전송하고, 송신자가 중복 ACK 3개를 받으면 타임아웃을 기다리지 않고 재전송합니다. SACK 옵션은 어느 블록이 도착했는지 정확히 알려줘 불필요한 재전송을 줄입니다. 운영 관점에서 재전송률(retrans)은 네트워크 품질의 핵심 지표로, ss -i나 netstat -s, 모니터링 대시보드로 추적합니다.

관련 개념 RTO 계산, 지수 백오프, SACK, 재전송률 모니터링(ss -i)

Q8. UDP 기반인 QUIC(HTTP/3)이 등장한 이유는 무엇인가요? ★★★

답안 TCP의 구조적 한계 때문입니다. ① HOL(Head-of-Line) 블로킹: HTTP/2가 한 TCP 연결에 스트림을 다중화해도, TCP는 바이트 순서를 보장하므로 패킷 하나가 유실되면 모든 스트림이 함께 멈춥니다. QUIC은 스트림별 독립 전달로 이를 해결합니다. ② 핸드셰이크 지연: TCP+TLS는 2~3 RTT가 필요하지만 QUIC은 전송과 암호화 핸드셰이크를 통합해 1 RTT, 재연결 시 0 RTT입니다. ③ 연결 마이그레이션: TCP는 4-튜플이 바뀌면(와이파이→LTE) 연결이 끊기지만 QUIC은 연결 ID로 유지합니다. ④ TCP는 커널·중간 장비에 박혀 개선이 어려운 반면(ossification), QUIC은 사용자 공간 구현이라 빠르게 진화합니다. TLS 1.3이 내장되어 항상 암호화됩니다.

관련 개념 HOL 블로킹, 0-RTT, 연결 ID, 프로토콜 경직화, HTTP/3

Q9. 포트 번호의 범위와 역할, 소켓의 식별 방법을 설명하세요. ★★★

답안 포트는 16비트(0~65535)로 호스트 내 프로세스(서비스)를 구분합니다. 0~1023은 well-known(HTTP 80, HTTPS 443, SSH 22, DNS 53 등, 바인드에 루트 권한 필요), 1024~49151은 등록 포트, 49152~65535는 임시(ephemeral) 포트로 클라이언트가 사용합니다. TCP 연결은 (출발 IP, 출발 포트, 목적 IP, 목적 포트) 4-튜플로 유일하게 식별되므로, 서버는 80 포트 하나로도 수만 클라이언트와 동시 연결이 가능합니다. "서버 포트는 하나인데 어떻게 여러 연결을 받나"는 이 4-튜플 개념을 확인하는 최빈출 질문입니다.

관련 개념 well-known 포트, 임시 포트 범위(ip_local_port_range), 4-튜플, SO_REUSEPORT

Q10. 백로그 큐와 accept의 관계, 그리고 대량 접속 시 생기는 문제를 설명하세요. ★★

답안 서버 커널은 두 큐를 유지합니다. SYN 큐(핸드셰이크 진행 중)와 accept 큐(핸드셰이크 완료, 앱의 accept() 대기). listen(backlog)의 backlog와 somaxconn이 accept 큐 크기를 정합니다. 앱이 accept를 빨리 못 하면(스레드 부족, GC 멈춤) accept 큐가 넘쳐 새 연결이 드롭되거나 SYN+ACK 재전송이 발생하고, 클라이언트는 간헐적 연결 타임아웃을 겪습니다. SYN 큐를 겨냥한 SYN 플러딩은 SYN 쿠키로 방어합니다. ss -lnt의 Recv-Q/Send-Q로 큐 상태를 확인하는 것이 실무 진단 포인트입니다.

관련 개념 SYN 큐/accept 큐, somaxconn, SYN 쿠키, ss -lnt Recv-Q

Q11. keep-alive(TCP와 HTTP)는 각각 무엇을 하나요? ★★

답안 TCP keepalive는 유휴 연결이 살아 있는지 커널이 주기적 프로브로 확인하는 기능입니다(기본 2시간 후 시작, 튜닝 가능). 상대가 죽었거나 중간 장비(NAT/방화벽)가 세션을 지웠으면 연결을 정리합니다. NAT 테이블은 유휴 세션을 수 분 만에 지우므로, 장수 연결(DB, gRPC)은 keepalive 간격을 NAT 타임아웃보다 짧게 설정해야 "한참 놀다가 첫 쿼리만 실패"하는 장애를 예방합니다. HTTP keep-alive는 별개 개념으로, 요청마다 TCP 연결을 새로 맺지 않고 하나의 연결을 재사용하는 것입니다(HTTP/1.1 기본). 핸드셰이크·슬로 스타트 비용을 절약합니다.

관련 개념 NAT 세션 타임아웃, tcp_keepalive_time, 커넥션 풀, HTTP/1.1 persistent connection

Q12. 대역폭이 충분한데 단일 TCP 연결의 전송 속도가 안 나오는 이유는? ★★

답안 후보는 ① BDP 대비 작은 윈도우: 처리량 ≤ 윈도우/RTT이므로, RTT 100ms에 윈도우 64KB면 최대 5Mbps뿐입니다. 윈도우 스케일과 소켓 버퍼(tcp_rmem/wmem) 확인. ② RTT 자체가 큼: 슬로 스타트·혼잡 회피의 증가 속도가 RTT에 비례해 장거리 구간은 느리게 가속합니다. ③ 패킷 손실: 1%의 손실도 손실 기반 혼잡 제어에서는 치명적으로 속도를 깎습니다(BBR로 개선 가능). ④ 중간 장비의 대역 제한·셰이핑. ⑤ 애플리케이션이 데이터를 공급 못 함(디스크 병목). 진단은 iperf3로 순수 네트워크 성능 분리 → ss -i로 cwnd·재전송 확인 → 손실 구간을 mtr로 추적하는 순서가 정석입니다.

관련 개념 처리량=윈도우/RTT, BDP, 손실과 CUBIC 성능 곡선, iperf3/ss -i/mtr

Q13. netstat/ss에서 CLOSE_WAIT가 계속 쌓이면 무엇이 문제인가요? ★★

답안 CLOSE_WAIT는 상대가 FIN을 보냈는데 우리 쪽 애플리케이션이 아직 close()를 호출하지 않은 상태입니다. 이 상태가 쌓인다는 것은 네트워크 문제가 아니라 애플리케이션 버그입니다. 커넥션·응답 객체를 닫지 않는 리소스 누수, 예외 경로에서 close 누락, 커넥션 풀 반환 실패 등이 원인입니다. 방치하면 파일 디스크립터 고갈("Too many open files")로 서비스가 멈춥니다. 대응은 코드에서 try-with-resources/defer 등으로 닫음을 보장하고, fd 사용량 모니터링을 거는 것입니다. TIME_WAIT(정상적 종료 흔적)와 성격이 완전히 다르다는 점을 구분해 설명하는 것이 포인트입니다.

관련 개념 FIN 수신 후 상태, fd 누수, ulimit -n, TIME_WAIT와의 구분

Q14. Nagle 알고리즘과 TCP_NODELAY는 무엇인가요? ★

답안 Nagle 알고리즘은 작은 데이터를 즉시 보내지 않고, 이전에 보낸 데이터의 ACK가 올 때까지 모아서 보내 작은 패킷 범람(예: 1바이트 페이로드에 40바이트 헤더)을 막는 기법입니다. 처리량에는 유리하지만 지연에 민감한 통신에는 해롭고, 특히 지연 ACK와 결합하면 상호 대기로 수십~수백 ms 지연이 생깁니다. 그래서 실시간성이 중요한 애플리케이션(게임, 금융, RPC)은 TCP_NODELAY 소켓 옵션으로 Nagle을 끕니다. 현대 프레임워크(gRPC, Redis 클라이언트 등) 상당수가 기본으로 끕니다.

관련 개념 작은 패킷 오버헤드, 지연 ACK와의 상호작용, TCP_NODELAY, writev/버퍼링 대안

Q15. 소켓 프로그래밍 관점에서 blocking, non-blocking, I/O 멀티플렉싱을 설명하세요. ★★

답안 블로킹 소켓은 read/accept가 데이터·연결이 올 때까지 스레드를 멈추므로, 동시 처리를 하려면 연결당 스레드가 필요해 수천 연결에서 한계가 옵니다. 논블로킹 소켓은 즉시 반환(EAGAIN)하지만 폴링 낭비가 생깁니다. I/O 멀티플렉싱은 여러 소켓을 한꺼번에 감시해 준비된 것만 처리하는 방식으로, select(fd 1024 제한, 매번 전체 스캔) → poll(개수 제한 해소) → epoll(리눅스, 준비된 fd만 반환, O(1)) 순으로 발전했습니다. nginx, Redis, Node.js가 epoll 기반 이벤트 루프로 C10K 문제를 해결한 대표 사례입니다. 최신 io_uring은 완료 기반 비동기로 시스템 콜 자체를 줄입니다.

관련 개념 C10K, select/poll/epoll 차이, 에지/레벨 트리거, io_uring, 이벤트 루프

Q16. TCP 연결 상태 전이도에서 주요 상태를 순서대로 설명하세요. ★★

답안 클라이언트: CLOSED → SYN_SENT(SYN 전송) → ESTABLISHED(SYN+ACK 수신, ACK 전송) → FIN_WAIT_1(close, FIN 전송) → FIN_WAIT_2(ACK 수신) → TIME_WAIT(상대 FIN에 ACK) → 2MSL 후 CLOSED. 서버: CLOSED → LISTEN → SYN_RECV(SYN 수신) → ESTABLISHED(ACK 수신) → CLOSE_WAIT(FIN 수신) → LAST_ACK(FIN 전송) → CLOSED(ACK 수신). 각 상태가 무엇을 기다리는 상태인지(FIN_WAIT_2=상대 FIN 대기, LAST_ACK=내 FIN의 ACK 대기)로 이해하면 암기가 아니라 논리로 답할 수 있고, ss로 본 상태 분포에서 장애를 읽어내는 실무 능력으로 연결됩니다.

관련 개념 상태 전이도, 동시 열기/닫기, ss -tan state 필터, 상태별 장애 시그니처

↑ 목차로

6단원. 응용 계층: HTTP와 DNS (최빈출 단원)

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. HTTP의 특징(무상태성, 비연결성)과 그 극복 방법을 설명하세요. ★★★

답안 HTTP는 요청-응답 구조의 텍스트 기반(HTTP/1.x) 프로토콜로, 무상태(stateless) — 서버가 이전 요청을 기억하지 않음 — 가 핵심 특징입니다. 덕분에 서버 확장(어느 서버가 받아도 됨)이 쉽지만, 로그인 유지 같은 상태가 필요한 기능은 쿠키/세션/토큰으로 해결합니다. 비연결성(요청마다 연결 종료)은 HTTP/1.1의 keep-alive(연결 재사용)로 개선되었습니다. 무상태성이 로드밸런싱·오토스케일링을 가능하게 하는 설계 기반이라는 점을 인프라 관점에서 연결해 답하면 좋습니다.

관련 개념 무상태와 수평 확장, 쿠키/세션/JWT, keep-alive, 멱등성

Q2. 쿠키와 세션의 차이, 그리고 JWT 토큰 방식과의 비교를 설명하세요. ★★★

답안 쿠키는 서버가 Set-Cookie로 내려주고 브라우저가 저장해 매 요청에 자동 첨부하는 클라이언트 측 데이터입니다. 세션은 상태를 서버(메모리/Redis)에 저장하고 클라이언트에는 세션 ID만 쿠키로 주는 방식으로, 민감 정보가 서버에 있어 안전하고 즉시 무효화가 가능하지만, 서버가 여러 대면 세션 공유(Redis 등 중앙 저장소)가 필요합니다. JWT는 서명된 토큰 자체에 사용자 정보를 담아 서버가 상태를 저장하지 않는 방식으로, 확장에 유리하고 MSA에 적합하지만 발급 후 강제 만료가 어렵습니다(블랙리스트나 짧은 만료+리프레시 토큰으로 보완). 보안 속성(HttpOnly, Secure, SameSite)도 함께 언급하면 좋습니다.

관련 개념 세션 스토어(Redis), 스티키 세션, JWT 서명·만료 전략, HttpOnly/SameSite

Q3. HTTP 메서드와 멱등성, 안전성을 설명하세요. ★★★

답안 주요 메서드는 GET(조회), POST(생성/처리), PUT(전체 교체), PATCH(부분 수정), DELETE(삭제), HEAD(헤더만), OPTIONS(지원 메서드 확인, CORS 프리플라이트)입니다. 안전(safe)은 서버 상태를 바꾸지 않는 성질(GET, HEAD), 멱등(idempotent)은 여러 번 실행해도 결과가 같은 성질(GET, PUT, DELETE는 멱등, POST는 아님)입니다. 멱등성이 중요한 이유는 재시도 안전성 때문입니다. 네트워크 오류 시 멱등 요청은 안심하고 재시도할 수 있지만 POST 재시도는 중복 결제 같은 사고가 되므로, 실무에서는 멱등성 키(Idempotency-Key)로 보완합니다. 게이트웨이·프록시의 자동 재시도 정책도 멱등 메서드에만 적용하는 것이 원칙입니다.

관련 개념 safe/idempotent 분류표, 멱등성 키, 재시도 정책, REST 설계

Q4. 주요 HTTP 상태 코드를 계열별로 설명하세요. ★★★

답안 2xx 성공: 200 OK, 201 Created, 204 No Content. 3xx 리다이렉션: 301(영구 이동), 302(임시 이동), 304(Not Modified, 캐시 유효). 4xx 클라이언트 오류: 400(잘못된 요청), 401(인증 필요), 403(권한 없음 — 401과의 차이가 단골 질문), 404(없음), 429(요청 과다, 레이트 리밋). 5xx 서버 오류: 500(내부 오류), 502(Bad Gateway — 프록시가 업스트림에서 잘못된 응답 수신), 503(서비스 불가 — 과부하·점검), 504(Gateway Timeout — 업스트림 응답 시간 초과). 인프라 직무에서는 502/503/504의 구분이 중요합니다. 502는 백엔드가 죽었거나 연결 거부, 504는 백엔드가 느림, 503은 LB가 보낼 곳이 없거나 서버가 의도적 거부 — 로드밸런서 뒤 장애 진단의 첫 갈림길입니다.

관련 개념 401 vs 403, 301 vs 302, 502/503/504 진단, 304와 조건부 요청

Q5. HTTP/1.1, HTTP/2, HTTP/3의 차이를 설명하세요. ★★★

답안 HTTP/1.1은 텍스트 기반이며 연결당 한 번에 하나의 요청-응답만 처리해(파이프라이닝은 실패), 브라우저가 도메인당 6개 연결을 열어 병렬화합니다. HTTP/2는 바이너리 프레이밍으로 하나의 연결에 여러 스트림을 다중화하고, 헤더 압축(HPACK), 우선순위를 지원해 연결 수를 줄이고 성능을 높였습니다. 하지만 TCP 위라서 패킷 손실 시 모든 스트림이 함께 멈추는 TCP HOL 블로킹이 남습니다. HTTP/3은 전송을 UDP 기반 QUIC으로 바꿔 스트림별 독립 전달로 HOL을 해소하고, TLS 1.3 내장, 0-RTT 재연결, 연결 마이그레이션을 제공합니다. 요약: 1.1=연결 병렬화, 2=스트림 다중화, 3=전송 계층 교체.

관련 개념 멀티플렉싱, HPACK/QPACK, TCP HOL 블로킹, QUIC, Alt-Svc

Q6. DNS의 계층 구조와 이름 해석(resolution) 과정을 설명하세요. ★★★

답안 DNS는 루트 → TLD(.com) → 권한 네임서버(example.com)의 계층 구조입니다. 클라이언트가 재귀 리졸버(ISP, 8.8.8.8 등)에 질의하면, 리졸버가 반복 질의로 ① 루트 서버에 물어 .com TLD 서버 주소를 받고 ② TLD 서버에 물어 example.com의 권한 서버 주소를 받고 ③ 권한 서버에서 최종 A 레코드를 받아 클라이언트에 응답합니다. 각 단계 결과는 TTL 동안 캐시되어 대부분의 질의는 캐시에서 끝납니다. 클라이언트 관점 순서는 브라우저 캐시 → OS 캐시/hosts 파일 → 리졸버입니다. TTL은 변경 전파 속도와 질의 부하의 트레이드오프로, 서버 이전 전에 TTL을 미리 낮추는 것이 실무 관행입니다.

관련 개념 재귀 vs 반복 질의, 루트/TLD/권한 서버, TTL과 캐시, dig +trace

Q7. 주요 DNS 레코드 타입(A, AAAA, CNAME, MX, TXT, NS, SOA)을 설명하세요. ★★

답안 A는 도메인→IPv4, AAAA는 도메인→IPv6 매핑입니다. CNAME은 도메인의 별칭으로 다른 도메인을 가리키며(www→example.com), 루트 도메인(apex)에는 표준상 쓸 수 없어 클라우드 LB 연결 시 ALIAS/ANAME 레코드가 등장했습니다. MX는 메일 수신 서버, TXT는 임의 텍스트로 SPF/DKIM/DMARC(메일 인증)와 도메인 소유 확인에 쓰입니다. NS는 그 존을 관리하는 네임서버, SOA는 존의 기본 정보(시리얼, 갱신 주기)입니다. 실무에서는 "CNAME과 A의 차이", "apex에 CNAME이 안 되는 이유"가 자주 나옵니다.

관련 개념 apex와 ALIAS, SPF/DKIM/DMARC, 존 파일, PTR(역방향 조회)

Q8. DNS는 왜 UDP를 쓰고, 언제 TCP로 전환하나요? ★★

답안 일반 질의는 작은 요청-응답 한 쌍이라 연결 수립 오버헤드가 없는 UDP 53이 효율적입니다. TCP 53을 쓰는 경우는 ① 응답이 UDP 크기 제한을 넘어 잘림(TC 비트) 표시가 왔을 때 재시도(전통 512바이트, EDNS0으로 확장 가능), ② 존 전송(AXFR, 주-보조 서버 간 존 복제), ③ 최근의 DNS over TLS(853)입니다. 방화벽에서 "DNS는 UDP만 열면 된다"고 TCP 53을 막으면 큰 응답(DNSSEC 등)과 존 전송이 실패하는 장애가 생기므로 둘 다 열어야 한다는 것이 실무 포인트입니다.

관련 개념 TC 비트, EDNS0, AXFR/IXFR, DoT/DoH

Q9. GSLB와 DNS 기반 로드밸런싱을 설명하세요. (인프라 연계) ★★

답안 DNS 라운드 로빈은 하나의 도메인에 여러 A 레코드를 등록해 응답 순서를 바꿔가며 분산하는 가장 단순한 방법이지만, 서버 장애를 감지하지 못하고 캐시 때문에 제어가 부정확합니다. GSLB는 DNS 응답을 지능화한 것으로, 헬스체크로 살아있는 사이트만 응답하고, 지리적 근접성·지연시간·가중치 기반으로 데이터센터/리전 단위 트래픽을 분배합니다. 재해 복구(DR) 시 DNS 응답을 백업 사이트로 바꿔 페일오버하는 것이 대표 활용입니다. 한계는 TTL 캐시로 인한 전환 지연이며, 그래서 TTL을 짧게(30~300초) 둡니다. AWS Route 53의 라우팅 정책(지연시간, 지역, 페일오버)이 GSLB의 구현입니다.

관련 개념 헬스체크, 페일오버와 TTL, Route 53 라우팅 정책, 애니캐스트와의 비교

Q10. REST API란 무엇이고 설계 원칙은 무엇인가요? ★★

답안 REST는 HTTP의 의미론을 활용한 아키텍처 스타일로, 자원을 URI로 표현하고(/users/123), 행위를 HTTP 메서드로 표현하며(GET 조회, POST 생성, PUT/PATCH 수정, DELETE 삭제), 표현(주로 JSON)을 주고받습니다. 원칙은 무상태성(요청에 필요한 정보 포함), 균일한 인터페이스, 캐시 가능성, 계층화입니다. 설계 관행으로 명사형 복수 URI, 적절한 상태 코드 사용, 버저닝(/v1), 페이지네이션, HATEOAS(엄밀한 REST)가 있습니다. 대안 기술로 GraphQL(클라이언트가 필요한 필드 지정, 오버페칭 해소)과 gRPC(HTTP/2+프로토버프, 내부 서비스 간 고성능 통신)를 비교해 답할 수 있으면 좋습니다.

관련 개념 자원/표현, 상태 코드 활용, GraphQL/gRPC 비교, API 게이트웨이

Q11. 웹 캐싱은 어떻게 동작하나요? (Cache-Control, ETag) ★★

답안 HTTP 캐싱은 응답 헤더로 제어합니다. Cache-Control: max-age=3600은 브라우저·프록시가 1시간 동안 재검증 없이 캐시를 쓰게 하고, no-cache는 매번 재검증, no-store는 저장 금지, private/public은 공유 캐시(CDN) 저장 여부를 정합니다. 만료 후에는 조건부 요청으로 재검증합니다. 서버가 준 ETag(콘텐츠 해시)를 If-None-Match로 보내거나 Last-Modified를 If-Modified-Since로 보내면, 변경이 없을 때 서버가 304 Not Modified(본문 없음)로 응답해 대역폭을 절약합니다. 정적 자산은 파일명에 해시를 넣고 max-age를 길게(캐시 버스팅), HTML은 no-cache로 두는 것이 표준 전략입니다.

관련 개념 max-age/no-cache/no-store, ETag/304, 캐시 버스팅, CDN 캐시 무효화

Q12. CORS는 왜 존재하고 어떻게 동작하나요? ★★

답안 브라우저의 동일 출처 정책(SOP)은 스크립트가 다른 출처(스킴+도메인+포트)의 응답을 읽지 못하게 해, 악성 사이트가 사용자의 쿠키 인증을 업고 타 사이트 데이터를 훔치는 것을 막습니다. CORS는 서버가 명시적으로 허용한 교차 출처 요청만 브라우저가 허용하도록 완화하는 표준입니다. 서버가 Access-Control-Allow-Origin 헤더로 허용 출처를 선언하고, 단순 요청이 아닌 경우(커스텀 헤더, PUT/DELETE 등) 브라우저가 먼저 OPTIONS 프리플라이트로 허용 여부를 확인합니다. 중요한 이해 포인트는 CORS가 브라우저의 보호 장치라는 것입니다. 서버 간 호출이나 curl에는 적용되지 않으므로 CORS는 보안 경계가 아니라 브라우저 사용자 보호 장치이며, 서버 측 인증·인가는 별도로 필요합니다.

관련 개념 SOP, 프리플라이트, Allow-Origin/Credentials, CSRF와의 관계

Q13. 웹소켓(WebSocket)과 HTTP 폴링 방식들을 비교하세요. ★★

답안 실시간 양방향 통신 요구에 대한 답들입니다. 폴링은 클라이언트가 주기적으로 요청하는 방식으로 단순하지만 지연과 낭비가 큽니다. 롱 폴링은 서버가 이벤트가 생길 때까지 응답을 보류해 지연을 줄이지만 여전히 요청 반복 오버헤드가 있습니다. SSE는 하나의 HTTP 연결로 서버→클라이언트 단방향 스트림을 제공합니다(알림, 피드에 적합). 웹소켓은 HTTP Upgrade 핸드셰이크(101 Switching Protocols)로 시작해 완전 양방향 지속 연결을 제공하며 채팅, 게임, 협업 도구에 적합합니다. 인프라 관점에서 웹소켓은 장수 연결이므로 LB의 유휴 타임아웃 설정, 스티키 세션 또는 pub/sub 백플레인(Redis) 설계가 필요합니다.

관련 개념 Upgrade 핸드셰이크, SSE, LB 타임아웃과 장수 연결, 스케일아웃 시 메시지 브로커

Q14. 이메일 전송 프로토콜(SMTP, POP3, IMAP)을 설명하세요. ★

답안 SMTP(25, 제출은 587)는 메일 발송·중계 프로토콜로, 발신 클라이언트→발신 서버→수신 서버 구간을 담당합니다. 수신함 읽기는 POP3(110/995) — 메일을 로컬로 내려받고 서버에서 삭제하는 단말 중심 방식 — 와 IMAP(143/993) — 메일을 서버에 두고 여러 기기에서 동기화 — 가 담당합니다. 현대는 IMAP(또는 웹메일/Exchange)이 표준입니다. 스팸·위조 방지를 위한 SPF(발신 IP 검증), DKIM(서명), DMARC(정책)를 함께 알아두면 "우리 회사 메일이 스팸함에 들어가요" 같은 실무 질문에 대응할 수 있습니다.

관련 개념 MTA/MUA, 포트 25/587/465, SPF/DKIM/DMARC, 오픈 릴레이

Q15. curl로 API 장애를 진단하는 방법을 설명해보세요. (실무 연계) ★★

답안 ① curl -v로 상세 과정(DNS 해석, TCP 연결, TLS 핸드셰이크, 요청/응답 헤더)을 단계별로 확인해 어느 단계에서 실패하는지 분리합니다. ② DNS 의심 시 --resolve로 특정 IP를 강제해 DNS와 서버 문제를 분리합니다(LB 뒤 특정 서버 직접 테스트에도 유용). ③ -w 옵션으로 time_namelookup, time_connect, time_starttransfer를 찍어 지연 구간을 정량화합니다. ④ TLS 문제는 -k(검증 생략)로 인증서 문제인지 확인 후 openssl s_client로 체인을 봅니다. ⑤ 헤더·바디를 조작(-H, -d)해 재현 조건을 좁힙니다. "브라우저에선 되는데 서버에선 안 돼요"류 문제는 프록시 환경변수, SNI, User-Agent 차이를 점검합니다.

관련 개념 curl -v/-w/--resolve, openssl s_client, SNI, 단계별 지연 분석

↑ 목차로

7단원. 네트워크 보안

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. 대칭키 암호화와 비대칭키 암호화의 차이를 설명하세요. ★★★

답안 대칭키는 암호화와 복호화에 같은 키를 씁니다(AES). 빠르고 대용량에 적합하지만, 통신 상대와 키를 안전하게 공유하는 문제가 있습니다. 비대칭키(공개키)는 공개키와 개인키 쌍을 씁니다(RSA, ECC). 공개키로 암호화하면 개인키로만 풀 수 있어 키 배포 문제가 없고 전자서명·인증이 가능하지만 연산이 느립니다. 그래서 실무에서는 하이브리드 방식을 씁니다. 비대칭키로 세션 키(대칭키)를 안전하게 교환한 뒤, 실제 데이터는 빠른 대칭키로 암호화합니다. TLS가 정확히 이 구조입니다.

관련 개념 AES/RSA/ECC, 키 배포 문제, 하이브리드 암호화, 전자서명

Q2. TLS 핸드셰이크 과정을 설명하세요. ★★★

답안 TLS는 ① 암호 협상(클라이언트가 지원 암호 스위트·TLS 버전 제시, 서버가 선택), ② 서버 인증(서버가 인증서 전송, 클라이언트가 CA 체인으로 검증), ③ 키 교환(ECDHE로 양쪽이 사전 마스터 시크릿을 안전하게 합의), ④ 세션 키 도출 후 대칭키 암호화 통신으로 전환합니다. TLS 1.3은 이 과정을 1 RTT로 단축하고(1.2는 2 RTT), 재연결 시 0-RTT를 지원하며, 취약한 알고리즘(RSA 키 교환, RC4 등)을 제거했습니다. ECDHE를 쓰는 이유는 전방향 안전성(PFS) — 서버 개인키가 유출돼도 과거에 녹음된 트래픽을 복호화할 수 없음 — 을 위해서입니다.

관련 개념 암호 스위트, 인증서 체인 검증, ECDHE, PFS, TLS 1.3 개선점

Q3. HTTPS에서 인증서와 CA는 어떤 역할을 하나요? ★★★

답안 인증서는 "이 공개키가 이 도메인의 것이 맞다"를 CA(인증 기관)가 보증한 전자 문서입니다. 브라우저는 OS·브라우저에 내장된 신뢰 루트 CA 목록을 기준으로, 서버 인증서 → 중간 CA → 루트 CA로 이어지는 체인의 서명을 검증하고, 도메인 일치·유효기간·폐기 여부(CRL/OCSP)를 확인합니다. 하나라도 실패하면 경고를 띄웁니다. 이 구조 덕분에 사용자는 처음 보는 사이트도 신뢰할 수 있습니다(PKI). Let's Encrypt가 무료·자동화(ACME)로 HTTPS를 보편화했습니다. 실무 단골 장애는 인증서 만료, 중간 인증서 누락(브라우저는 되는데 일부 클라이언트에서 실패), 도메인 불일치(SAN 누락)입니다.

관련 개념 PKI, 인증서 체인, OCSP/CRL, SAN, Let's Encrypt/ACME, 인증서 만료 모니터링

Q4. 대칭키 교환에 쓰이는 Diffie-Hellman의 핵심 아이디어는? ★★

답안 DH는 공개된 채널에서 도청자가 보고 있어도 양쪽만 같은 비밀 값을 만들어내는 키 교환 방법입니다. 공개 값(g, p)과 각자의 비밀 값(a, b)으로 g^a, g^b를 교환하고, 각자 상대 값에 자기 비밀 지수를 올리면 둘 다 g^(ab)에 도달합니다. 도청자는 g^a, g^b를 봐도 이산 로그 문제 때문에 a, b를 역산할 수 없습니다. 매 연결마다 임시(ephemeral) 키 쌍을 쓰는 ECDHE가 전방향 안전성을 제공합니다. "키를 주고받지 않고 어떻게 같은 키를 갖느냐"는 질문의 답이 바로 DH입니다.

관련 개념 이산 로그 문제, ECDHE, 전방향 안전성, 중간자 공격(인증서로 방어)

Q5. 방화벽의 종류(패킷 필터링, 상태 기반, 차세대)를 설명하세요. ★★★

답안 패킷 필터링(stateless)은 각 패킷의 IP·포트·프로토콜을 규칙과 대조해 허용/차단합니다. 빠르지만 연결 문맥을 몰라 정교한 제어가 어렵습니다. 상태 기반(stateful)은 연결 상태 테이블을 유지해 "내가 보낸 요청의 응답"만 자동 허용하므로, 아웃바운드는 열되 인바운드는 기존 연결의 응답만 통과시키는 정책이 가능합니다(현대 방화벽의 기본). 차세대 방화벽(NGFW)은 여기에 애플리케이션 식별(포트가 아닌 실제 앱), IPS, TLS 검사, 사용자 인증 연동을 더합니다. 클라우드의 보안 그룹은 상태 기반 인스턴스 방화벽, NACL은 상태 비저장 서브넷 방화벽으로 대비되며 이 차이가 자주 출제됩니다.

관련 개념 stateful vs stateless, NGFW/IPS, 보안 그룹 vs NACL, 기본 거부(default deny)

Q6. DDoS 공격의 유형과 방어 방법을 설명하세요. ★★★

답안 볼류메트릭(대역폭 고갈: UDP 플러드, DNS·NTP 증폭)은 실제 대역폭을 채워 정상 트래픽을 밀어냅니다. 프로토콜 공격(SYN 플러드처럼 연결 자원·상태 테이블 고갈). 애플리케이션 계층(HTTP 플러드처럼 적은 트래픽으로 서버 로직·DB를 소진, 탐지가 어려움). 방어는 계층적입니다. ① 상류의 스크러빙 센터/CDN(Cloudflare, AWS Shield)이 대용량 트래픽을 흡수·정화, ② 애니캐스트로 공격을 지리적으로 분산, ③ 레이트 리미팅·캡차·WAF로 애플리케이션 공격 필터링, ④ SYN 쿠키·연결 제한, ⑤ 오토스케일링으로 용량 확보. 핵심은 "혼자 감당하지 말고 상류에서 흡수한다"는 것입니다.

관련 개념 증폭 공격(반사), SYN 플러드, 스크러빙, 애니캐스트 분산, 레이트 리미팅

Q7. 중간자 공격(MITM)은 무엇이고 어떻게 방어하나요? ★★

답안 공격자가 통신 양단 사이에 끼어들어 트래픽을 가로채거나 변조하는 공격입니다. 수법으로 ARP 스푸핑(LAN 내), 악성 Wi-Fi AP, DNS 스푸핑, BGP 하이재킹이 있습니다. 방어의 핵심은 암호화와 인증입니다. TLS는 인증서로 상대 신원을 검증해 공격자가 중간에서 위조하지 못하게 합니다(그래서 인증서 경고를 무시하면 안 됨). 추가로 HSTS(HTTP를 강제로 HTTPS로), 인증서 피닝(앱이 특정 인증서만 신뢰), DNSSEC, 신뢰할 수 없는 네트워크에서 VPN 사용이 있습니다. "TLS를 쓰면 왜 MITM이 막히는가"는 인증서 검증 원리로 답하면 됩니다.

관련 개념 ARP/DNS 스푸핑, TLS 인증, HSTS, 인증서 피닝, DNSSEC

Q8. VPN의 동작 원리와 종류를 설명하세요. ★★

답안 VPN은 공용 네트워크 위에 암호화된 터널을 만들어 사설망처럼 안전하게 통신하는 기술입니다. 사이트 간 VPN은 두 네트워크(본사-지사, 온프레미스-클라우드)를 연결하며 주로 IPsec을 씁니다(AH/ESP, IKE로 키 협상). 원격 접속 VPN은 개인 단말을 회사망에 연결하며 SSL/TLS VPN, WireGuard 등을 씁니다. 캡슐화로 원래 패킷을 새 헤더로 감싸 전달하므로 MTU가 줄어드는 점(단편화·성능 이슈)을 유의해야 합니다. 최근에는 "네트워크 위치를 신뢰하지 않고 매 접근을 인증"하는 제로 트러스트(BeyondCorp 모델)가 전통 VPN을 보완·대체하는 흐름입니다.

관련 개념 IPsec(ESP/IKE), SSL VPN, WireGuard, 터널 MTU, 제로 트러스트

Q9. 인증(Authentication)과 인가(Authorization)의 차이는? ★★

답안 인증은 "당신이 누구인지 확인"하는 것(로그인, 신원 증명)이고, 인가는 "무엇을 할 권한이 있는지 확인"하는 것(권한·접근 제어)입니다. 인증이 먼저, 인가가 나중입니다. HTTP에서 인증 실패는 401, 인가 실패는 403으로 구분됩니다. 다중 요소 인증(MFA)은 지식(비밀번호)·소유(OTP·기기)·생체 중 둘 이상을 결합해 인증을 강화합니다. 인가 모델로 RBAC(역할 기반), ABAC(속성 기반)가 있습니다. OAuth2(위임 인가)와 OpenID Connect(그 위의 인증)의 구분도 함께 알아두면 좋습니다.

관련 개념 401 vs 403, MFA, RBAC/ABAC, OAuth2 vs OIDC

Q10. 포트 스캔과 이를 탐지·차단하는 방법을 설명하세요. ★

답안 포트 스캔은 공격자가 열린 포트와 서비스를 파악하는 정찰 활동입니다(nmap). TCP SYN 스캔(SYN만 보내고 SYN+ACK 오면 열림으로 판단, 연결은 미완성해 로그 회피), 연결 스캔, UDP 스캔 등이 있습니다. 탐지·차단은 ① IDS/IPS가 짧은 시간에 다수 포트 접근 패턴을 탐지, ② 방화벽에서 불필요한 포트를 기본 거부로 닫고 필요한 것만 열기, ③ fail2ban으로 반복 시도 IP 차단, ④ 공격 표면 최소화(관리 포트는 VPN·배스천 뒤로). "닫힌 포트는 RST, 필터링된 포트는 무응답"이라는 응답 차이로 방화벽 유무까지 추정된다는 점도 이해 포인트입니다.

관련 개념 nmap, SYN 스캔, IDS/IPS, fail2ban, 공격 표면 최소화

Q11. 클라우드 보안 그룹과 NACL의 차이를 설명하세요. (인프라 연계) ★★★

답안 둘 다 AWS의 가상 방화벽이지만 계층과 성격이 다릅니다. 보안 그룹(SG)은 인스턴스(ENI) 단위로 적용되는 상태 기반 방화벽으로, 허용 규칙만 있고(명시적 거부 불가), 인바운드를 허용하면 응답 아웃바운드는 자동 허용됩니다. NACL은 서브넷 단위의 상태 비저장 방화벽으로, 허용·거부 규칙을 번호 순서로 평가하며 상태를 기억하지 않아 인바운드와 아웃바운드(임시 포트 범위 포함)를 양쪽 다 명시해야 합니다. 일반적으로 세밀한 제어는 SG로 하고, NACL은 서브넷 광역 차단(특정 IP 대역 블랙리스트)에 보조적으로 씁니다. "SG만 열었는데 통신이 안 된다 → NACL의 아웃바운드/임시 포트 확인"이 전형적 트러블슈팅 흐름입니다.

관련 개념 상태 기반 vs 비저장, 인스턴스 vs 서브넷 범위, 임시 포트, 허용 전용 vs 허용/거부

Q12. 시큐어 코딩 관점의 네트워크 취약점(SQL 인젝션, XSS, CSRF)을 간단히 구분하세요. ★

답안 SQL 인젝션은 사용자 입력이 쿼리로 해석되어 DB를 조작당하는 것으로, 파라미터 바인딩(프리페어드 스테이트먼트)으로 방어합니다. XSS는 악성 스크립트가 다른 사용자의 브라우저에서 실행되는 것으로, 출력 이스케이프·CSP·쿠키 HttpOnly로 방어합니다. CSRF는 로그인된 사용자의 브라우저가 자동 첨부하는 쿠키를 악용해 의도치 않은 요청을 보내게 하는 것으로, CSRF 토큰·SameSite 쿠키로 방어합니다. 공통 원칙은 "사용자 입력을 신뢰하지 말고, 입력 검증과 출력 인코딩을 분리하라"입니다. 네트워크 직무라도 애플리케이션 보안 기본은 자주 묻습니다.

관련 개념 프리페어드 스테이트먼트, CSP, SameSite, OWASP Top 10

↑ 목차로

8단원. 실무 네트워크 (로드밸런싱·트러블슈팅·클라우드)

대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념

Q1. 로드밸런서의 알고리즘(라운드로빈, 최소연결, 해시)을 설명하세요. ★★★

답안 라운드 로빈은 서버에 순서대로 분배합니다. 단순하지만 서버 성능·부하가 다르면 불균형해질 수 있어 가중 라운드 로빈으로 보완합니다. 최소 연결(least connections)은 현재 활성 연결이 가장 적은 서버로 보내, 처리 시간이 제각각인(장수 연결이 섞인) 워크로드에 유리합니다. IP/URL 해시는 출발지 IP나 URL을 해시해 항상 같은 서버로 보내므로 캐시 지역성이나 세션 고정에 좋지만, 서버 증감 시 매핑이 대거 흔들리는 문제가 있어 consistent hashing으로 완화합니다. 추가로 최소 응답시간 방식도 있습니다. 워크로드 특성(연결 수명, 상태 유무)에 맞춰 고르는 것이 핵심입니다.

관련 개념 가중치, 최소 연결, consistent hashing, 최소 응답시간, 헬스체크 연동

Q2. L4 로드밸런서와 L7 로드밸런서의 차이는 무엇인가요? ★★★

답안 L4 LB는 전송 계층(TCP/UDP)에서 IP·포트만 보고 분산합니다. 패킷을 거의 그대로 전달해 매우 빠르고 처리량이 높으며, 어떤 프로토콜이든 다룰 수 있지만 콘텐츠 기반 라우팅은 못 합니다(AWS NLB). L7 LB는 응용 계층(HTTP)까지 해석해 URL 경로·호스트 헤더·쿠키 기반 라우팅, SSL 종료, 헤더 조작, 압축, 재작성이 가능합니다(AWS ALB, nginx, HAProxy). 대신 매 요청을 파싱해 오버헤드가 큽니다. 마이크로서비스에서 /api/users는 A 서비스, /api/orders는 B 서비스로 보내는 경로 기반 라우팅이 L7의 대표 활용입니다. 선택 기준: 단순 고성능 TCP는 L4, HTTP 지능형 라우팅은 L7.

관련 개념 NLB vs ALB, SSL 종료, 경로/호스트 기반 라우팅, 리버스 프록시

Q3. 로드밸런서 뒤에서 클라이언트 실제 IP를 어떻게 알 수 있나요? ★★★

답안 LB나 프록시를 거치면 서버에는 LB의 IP가 출발지로 찍혀, 로그·접근제어·지역 판별이 무의미해집니다. 해결책은 ① X-Forwarded-For(XFF) 헤더: L7 프록시가 원 클라이언트 IP를 헤더에 추가합니다(여러 단 거치면 목록이 됨, 신뢰 경계 밖 값은 위조 가능하니 신뢰 프록시가 덮어써야 함). ② X-Forwarded-Proto로 원래 스킴(https) 전달. ③ TCP 레벨(L4)에서는 헤더를 못 쓰므로 Proxy Protocol로 원 IP를 앞에 붙입니다. 서버·앱은 이 헤더를 신뢰할 프록시에서 온 경우에만 채택하도록 설정해야 하며, 잘못 신뢰하면 IP 위조로 접근제어가 우회됩니다.

관련 개념 X-Forwarded-For/Proto, Proxy Protocol, 신뢰 프록시 설정, IP 스푸핑 위험

Q4. 헬스체크는 왜 중요하고 어떻게 설계하나요? ★★

답안 LB는 헬스체크로 각 서버의 상태를 감시해 비정상 서버를 자동으로 제외하고 정상 서버로만 트래픽을 보냅니다. 얕은 체크(TCP 포트 열림, HTTP 200)는 가볍지만 "포트는 살아있는데 DB 연결이 끊긴" 상태를 놓칩니다. 깊은 체크(/health가 DB·의존 서비스까지 점검)는 정확하지만, 공통 의존성(DB)이 흔들리면 모든 서버가 동시에 unhealthy가 되어 전체 장애가 될 수 있어 균형이 필요합니다. 파라미터로 주기, 타임아웃, 임계 횟수(연속 몇 번 실패해야 제외)를 조정합니다. 배포 시에는 헬스체크 통과 후 트래픽을 받게 해(그레이스풀) 초기화 중 요청 실패를 막습니다.

관련 개념 얕은/깊은 체크, /health 엔드포인트, 그레이스풀 셧다운/스타트업, 캐스케이딩 장애

Q5. 포워드 프록시와 리버스 프록시의 차이는? ★★

답안 포워드 프록시는 클라이언트 앞에 서서 내부 사용자의 외부 요청을 대신 수행합니다. 사내 인터넷 접근 제어, 캐싱, 익명화가 목적이며 서버는 프록시를 클라이언트로 인식합니다. 리버스 프록시는 서버 앞에 서서 외부 요청을 받아 내부 서버로 전달합니다. SSL 종료, 로드밸런싱, 캐싱, 압축, WAF, 백엔드 은닉이 목적이며 클라이언트는 프록시를 서버로 인식합니다(nginx, HAProxy, CDN 엣지). "누구를 대리하느냐"(포워드=클라이언트, 리버스=서버)가 구분의 핵심입니다.

관련 개념 nginx/HAProxy, SSL 종료, 백엔드 은닉, API 게이트웨이

Q6. CDN은 어떻게 동작하고 어떤 이점을 주나요? ★★★

답안 CDN은 전 세계 엣지 서버에 콘텐츠를 캐싱해, 사용자가 지리적으로 가까운 엣지에서 받게 합니다. 사용자를 가까운 엣지로 보내는 것은 애니캐스트나 DNS(GSLB)가 담당합니다. 이점은 ① 지연 감소(RTT 단축), ② 원본 서버 부하 경감(캐시 히트는 원본까지 안 감), ③ 대역폭 절감, ④ DDoS 흡수와 WAF 제공입니다. 정적 콘텐츠(이미지, JS, 비디오)가 주 대상이지만, 동적 콘텐츠도 엣지까지의 최적화된 연결과 마이크로캐싱으로 가속합니다. 운영 포인트는 캐시 무효화(배포 시 오래된 자산 문제 → 파일명 해싱), Cache-Control 설계, 캐시 히트율 모니터링입니다.

관련 개념 엣지 서버, 오리진, 캐시 히트율, 캐시 무효화/퍼지, 엣지 컴퓨팅

Q7. "사이트가 느려요"라는 신고를 받으면 어떻게 접근하겠습니까? ★★★

답안 계층적으로 문제를 분리합니다. ① 범위 확인: 전체인지 특정 사용자·지역·페이지인지(모니터링·다른 지역에서 재현). ② 클라이언트→서버 경로 분해: 브라우저 개발자도구로 DNS/연결/TTFB/다운로드/렌더링 중 어디가 느린지 봅니다. TTFB가 크면 서버·네트워크, 다운로드가 크면 대역폭·자산 크기, 렌더링이 크면 프론트엔드. ③ 네트워크 구간: ping/mtr로 RTT·손실, traceroute로 느린 홉 파악. ④ 서버 측: LB→웹→WAS→DB 각 구간 지연(APM), CPU·메모리·커넥션 풀·슬로 쿼리 확인. ⑤ 최근 변경: 배포·트래픽 급증·설정 변경 이력. 핵심은 추측하지 말고 구간별로 측정해 병목을 좁히는 것입니다.

관련 개념 TTFB, 개발자도구 워터폴, mtr, APM, 병목 구간 분리

Q8. 네트워크 트러블슈팅 도구(ping, traceroute, dig, tcpdump, ss)의 용도를 설명하세요. ★★★

답안 ping은 도달성·RTT·손실 확인(단, ICMP 차단 시 무의미). traceroute/mtr는 경로상 각 홉의 지연·손실을 확인해 어디서 끊기는지 파악(mtr은 연속 측정). dig/nslookup은 DNS 조회로 이름 해석 문제 진단(dig +trace로 위임 경로 추적). tcpdump/Wireshark는 실제 패킷을 캡처해 핸드셰이크, 재전송, RST, TLS 오류 등을 눈으로 확인하는 최종 병기. ss(netstat 후속)는 로컬 소켓 상태(LISTEN 여부, 연결 상태 분포, 큐 길이) 확인. curl -v는 HTTP·TLS 단계별 진단. 문제 유형에 따라 "이름 해석은 dig, 경로는 mtr, 실제로 오가는 건 tcpdump, 내 소켓은 ss"로 도구를 매핑해 답하면 실무 감각을 보여줄 수 있습니다.

관련 개념 mtr, dig +trace, tcpdump 필터, ss -tanp, Wireshark

Q9. 3-tier 아키텍처의 네트워크 구성을 설명하세요. (인프라 연계) ★★

답안 웹(프레젠테이션) - 애플리케이션(WAS) - DB 3계층을 네트워크로 분리하는 표준 설계입니다. 인터넷 → 로드밸런서 → 퍼블릭/DMZ 서브넷의 웹 계층 → 프라이빗 서브넷의 앱 계층 → 더 격리된 프라이빗 서브넷의 DB 계층 순으로, 각 계층 사이에 방화벽/보안 그룹으로 필요한 포트만 허용합니다(웹은 443만 인바운드, 앱은 웹에서 오는 8080만, DB는 앱에서 오는 3306만). DB는 인터넷 아웃바운드도 차단합니다. 목적은 최소 권한과 침해 확산 차단(웹이 뚫려도 DB에 직접 못 감)입니다. 클라우드에서는 서브넷·보안 그룹·NACL로 이 경계를 구현합니다.

관련 개념 DMZ, 계층별 서브넷, 최소 권한, 배스천 호스트, 심층 방어

Q10. 클라우드 네트워킹 핵심 요소(VPC, 서브넷, IGW, NAT GW, 피어링)를 설명하세요. ★★★

답안 VPC는 클라우드 안의 격리된 사설 네트워크(CIDR 지정)입니다. 서브넷은 VPC를 가용영역·용도별로 나눈 것으로, 라우트 테이블에 인터넷 경로가 있으면 퍼블릭, 없으면 프라이빗입니다. IGW(인터넷 게이트웨이)는 VPC를 인터넷에 연결하며, 퍼블릭 서브넷의 공인 IP 인스턴스가 양방향 통신하게 합니다. NAT 게이트웨이는 프라이빗 서브넷 인스턴스가 아웃바운드만 인터넷에 나가게 합니다(패치·API 호출용, 인바운드는 불가). VPC 피어링/Transit Gateway는 VPC 간(또는 온프레미스와) 사설 연결을 제공하며, 이때 CIDR가 겹치면 안 됩니다. 이 요소들의 조합이 클라우드 인프라 면접의 핵심 주제입니다.

관련 개념 VPC/서브넷/라우트 테이블, IGW vs NAT GW, VPC 피어링/TGW, VPC 엔드포인트(프라이빗 링크)

Q11. TCP 연결이 간헐적으로 끊기는 문제, 원인 후보들을 나열해보세요. ★★

답안 ① NAT/방화벽 세션 타임아웃: 유휴 장수 연결을 중간 장비가 조용히 정리 → keepalive를 타임아웃보다 짧게. ② LB 유휴 타임아웃: LB가 무통신 연결을 끊음(웹소켓·DB 연결에 흔함) → 타임아웃 상향 또는 애플리케이션 keepalive. ③ MTU/PMTUD 블랙홀: 큰 패킷만 실패 → ping -s 테스트, MSS 클램핑. ④ 비대칭 라우팅으로 상태 기반 방화벽이 응답 차단. ⑤ 간헐적 패킷 손실(불량 케이블·과부하 링크) → mtr 장시간 관찰. ⑥ 서버 측 커넥션 풀 만료나 리소스 고갈. ⑦ IP 충돌·DHCP 임대 문제. tcpdump로 끊기는 순간의 FIN/RST 여부를 보면 "누가 먼저 끊었는지"를 특정할 수 있어 원인 범위를 크게 좁힙니다.

관련 개념 세션 타임아웃, keepalive, PMTUD 블랙홀, 비대칭 라우팅, RST 분석

Q12. 마이크로서비스에서 서비스 디스커버리와 서비스 메시가 필요한 이유는? ★★

답안 MSA에서는 서비스 인스턴스가 오토스케일링·배포로 동적으로 뜨고 지므로 IP를 하드코딩할 수 없습니다. 서비스 디스커버리(Consul, etcd, 쿠버네티스 DNS)는 서비스 이름으로 현재 살아있는 인스턴스를 찾게 해줍니다. 호출 측이 조회하는 클라이언트 사이드와, LB·프록시가 대신하는 서버 사이드 방식이 있습니다. 서비스 메시(Istio, Linkerd)는 각 파드에 사이드카 프록시(Envoy)를 붙여 서비스 간 트래픽의 로드밸런싱·재시도·서킷 브레이커·mTLS 암호화·관측성을 애플리케이션 코드 수정 없이 인프라 계층에서 제공합니다. 네트워크 복잡성이 앱에서 플랫폼으로 옮겨간 것이 핵심입니다.

관련 개념 서비스 디스커버리, 쿠버네티스 Service/DNS, 사이드카(Envoy), mTLS, 서킷 브레이커

Q13. QoS(서비스 품질)란 무엇이고 언제 필요한가요? ★

답안 QoS는 한정된 대역폭에서 트래픽에 우선순위를 부여해 중요한 트래픽의 품질을 보장하는 기술입니다. 음성(VoIP)·영상회의는 지연·지터에 민감하므로 대용량 파일 전송보다 우선 처리해야 합니다. 기법으로 트래픽 분류·마킹(DSCP), 우선순위 큐잉, 대역폭 예약, 트래픽 셰이핑(초과분 지연)·폴리싱(초과분 폐기)이 있습니다. 기업망·통신사망에서 중요하며, 인터넷 전체에는 적용이 어렵습니다(그래서 실시간 앱은 애플리케이션 차원의 적응형 코덱·버퍼로 대응). 클라우드에서는 대역폭·IOPS 등에 대한 리소스 보장·제한으로 유사 개념이 나타납니다.

관련 개념 DSCP 마킹, 우선순위 큐, 셰이핑 vs 폴리싱, 버퍼블로트

Q14. 서킷 브레이커와 재시도, 타임아웃이 네트워크 안정성에 왜 중요한가요? ★★

답안 분산 시스템에서 한 서비스의 장애가 호출 사슬을 타고 전체로 번지는 캐스케이딩 장애를 막기 위해서입니다. 타임아웃이 없으면 느린 응답을 무한정 기다리다 스레드·커넥션이 고갈됩니다(반드시 설정). 재시도는 일시적 오류를 극복하지만, 무분별하면 이미 힘든 서버에 부하를 가중(재시도 폭풍)하므로 지수 백오프+지터와 멱등성 확인이 필요합니다. 서킷 브레이커는 실패율이 임계치를 넘으면 회로를 '열어' 일정 시간 호출을 즉시 차단(빠른 실패)해 죽어가는 서비스에 회복 시간을 주고, 반쯤 열림 상태로 조금씩 재시도하며 복구를 확인합니다. 이 세 가지가 함께 회복 탄력성(resilience)을 만듭니다.

관련 개념 캐스케이딩 장애, 지수 백오프+지터, 재시도 폭풍, 서킷 브레이커 상태(closed/open/half-open), 벌크헤드

↑ 목차로