이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
네트워크 프로토콜 수업에서 TCP/IP 스택을 처음 공부했을 때는 이론처럼 느껴졌는데, 실제 프로젝트에서 디버깅하면서 그 이해가 얼마나 중요한지 체감했습니다. API 호출이 간헐적으로 타임아웃되는 문제를 잡을 때 TCP의 연결 수립과 종료 단계를 알고 있어야 TIME_WAIT 상태로 소켓이 쌓이는 원인을 파악할 수 있었습니다. 프레임워크가 네트워크 통신을 추상화해도 장애가 나는 시점에서는 결국 계층 아래를 들여다봐야 합니다.
tcpdump로 패킷을 직접 캡처해보면서 지연이 어느 계층에서 발생하는지 확인하는 방식이 추측보다 훨씬 빠른 진단을 가능하게 했습니다. 지금도 네트워크 관련 이상 현상을 만나면 프로토콜 상태 머신을 먼저 떠올리는 습관이 생겼습니다.
TCP/IP를 공부하고 나서 그 위에서 동작하는 TLS와 HTTP/2의 동작을 이해하는 것이 자연스럽게 연결됐습니다. TLS 핸드셰이크가 TCP 연결 위에서 추가적인 왕복을 필요로 한다는 것을 이해하니, HTTPS 요청이 HTTP보다 느린 이유와 TLS 세션 재사용이 왜 중요한지를 알 수 있었습니다. HTTP/2의 멀티플렉싱이 단일 TCP 연결에서 여러 요청을 병렬로 처리하는 구조라는 것도, TCP 레이어를 이해하고 있어야 왜 연결 수를 줄이는 것이 이점인지를 납득할 수 있었습니다.
프로토콜 지식은 위 계층을 이해하는 기반이 되는 결이 있다는 것을 이 경험에서 배웠습니다. 네트워크 공부는 한 계층을 이해하면 인접 계층이 왜 그렇게 설계됐는지가 보이는 결이 있었습니다.
TCP/IP 지식을 실제 성능 문제에 연결한 경험이 있습니다. API 서버에서 외부 서비스를 자주 호출할 때 응답이 지연되는 문제가 있었습니다. 매 요청마다 TCP 연결을 새로 맺는 것이 문제였는데, 3-Way Handshake 비용이 쌓이면 전체 응답 시간에 영향을 주는 결이 있었습니다.
Keep-Alive 설정으로 연결을 재사용하도록 바꿨더니 응답 시간이 개선됐습니다. 단, 연결을 오래 유지하면 유휴 연결이 쌓이는 문제도 있어서 연결 풀 크기와 타임아웃을 함께 조정했습니다. TCP 연결 생성 비용을 알고 있어야 연결 풀링의 필요성을 설계 단계에서 판단하는 결이 있다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.