이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
TCP 관련 커널 옵션 이해를 바탕으로 해결한 문제 중 하나는 TIME_WAIT 소켓 누적이었습니다. 짧은 주기로 연결을 맺고 끊는 서비스에서 TIME_WAIT 상태 소켓이 쌓여 포트가 고갈되는 현상이 발생했고, net.ipv4.tcp_tw_reuse 옵션으로 연결 재사용을 허용해 해결했습니다.
keepalive 설정도 중요했습니다. 장시간 유휴 상태인 연결이 중간 방화벽에서 끊기는 문제가 있었는데, tcp_keepalive_time과 tcp_keepalive_intvl 값을 조정해 연결이 살아있음을 주기적으로 확인하도록 했습니다.
backlog 크기도 조정했습니다. 트래픽이 급증할 때 연결 요청이 큐를 초과하면 클라이언트가 연결 거부를 받는 상황이 생겨, net.core.somaxconn 값을 늘려 피크 타임 연결 수용량을 확보했습니다.
TCP 성능 최적화에서 소켓 버퍼 크기를 늘리면 처리량이 올라갈 것이라 기대하고 net.core.rmem_max와 net.core.wmem_max를 조정한 적이 있었습니다. 실제 측정에서는 기대만큼 변화가 없었습니다. 설정은 바꿨는데 어디가 병목인지 파악을 못 한 채 파라미터를 건드린 셈이었습니다.
이후 ss -tn으로 먼저 실제 수신 큐가 차는지 여부를 확인하는 방식으로 순서를 바꿨습니다. 버퍼 크기 조정이 의미 있으려면 수신 큐가 꽉 차는 패턴이 먼저 보여야 합니다. 측정 없이 파라미터를 건드리는 것은 노이즈만 만든다는 걸 그때 배웠습니다.
이 경험으로 TCP 튜닝은 어떤 파라미터를 바꿀지보다 어디가 병목인지 먼저 측정하는 것이 중요하다는 걸 배웠습니다.
TCP 커널 옵션 중 Nagle 알고리즘이 의도치 않게 지연을 만드는 자리를 직접 경험했습니다. 소켓 통신에서 응답이 간헐적으로 40ms 지연되는 문제가 있었는데, 로그에는 서버 처리 시간이 거의 0에 가까웠습니다. 서버 문제가 아닌 것이 분명했습니다.
tcpdump로 패킷을 잡아보니 작은 패킷들이 묶여 나가면서 ACK 타이밍과 맞물려 40ms 지연이 생기는 패턴이었습니다. 소켓에 TCP_NODELAY 옵션을 설정하니 40ms 지연이 즉시 사라졌습니다.
이 경험으로 TCP 동작을 이해하지 못하면 로그에 남지 않는 지연이 어디서 오는지 방향을 못 잡는다는 걸 배웠습니다. 커널 옵션 한 줄이 측정 가능한 차이를 만드는 자리를 직접 확인한 경험이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.