420. CLOSE_WAIT / LAST_ACK 상태

핵심 인사이트 (3줄 요약)

본질: CLOSE_WAIT / LAST_ACK 상태는 전송 계층에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: CLOSE_WAIT / LAST_ACK 상태를 이해하면 신뢰성과 지연 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

개념: TCP 4-Way Handshake 종료 과정에서, 연결 해제 요청을 '수신한 측(Passive Close)'의 OS 소켓이 거치게 되는 상태 머신(State Machine)의 과도기적 두 단계.
필요성: 만약 통신이 무 자르듯 뚝 끊긴다면? 내가 구글 드라이브에 100MB 파일을 올리고 있는데, 99MB쯤 올라갔을 때 구글 서버(앱)가 갑자기 급한 일이 생겨서 나한테 FIN(끊자!) 패킷을 날렸다고 치자. 내가 그걸 받고 즉각 셔터를 내리면, 기껏 올린 99MB 파일은 전송 실패로 쓰레기통에 처박힌다. "네가 바쁜 건 알겠고 일단 셔터(입구)는 닫아줄게. 하지만 내가 내보낼 1MB 찌꺼기 트래픽이 아직 남아있으니 이거 마저 밀어 넣을 때까지만 출구 쪽 셔터를 붙잡아줘!!" 이것이 패시브 종료 모델의 존재 이유다.
💡 비유: 이 과정은 식당의 **"마감 시간 풍경"**과 완벽히 똑같습니다.
- CLOSE_WAIT: 영업시간 끝났다고 지배인이 입구 간판의 불을 껐습니다(상대의 FIN 수신). 하지만 아직 주방에서는 손님이 시킨 마지막 군만두(남은 데이터)를 요리 중입니다. 주방장은 군만두가 나올 때까지 주방 셔터를 붙잡고 버티고 섭니다(CLOSE_WAIT).
- LAST_ACK: 군만두를 손님상에 내고 "이제 저희 진짜 문 닫습니다(나의 FIN 발송)"라고 찐막 선언을 했습니다. 이제 손님이 카드 결제 사인을 해주기(마지막 ACK 수신)만을 **계산대 앞에서 멍하니 기다리는 상태(LAST_ACK)**입니다.

[TIME_WAIT 상태]
    │
    ▼
[CLOSE_WAIT / LAST_ACK 상태]
    │
    └──▶ [TCP 흐름 제어]

📢 섹션 요약 비유: ** CLOSE_WAIT은 헤어지자는 애인의 통보를 받고 일단 고개를 끄덕였지만, "그래도 내가 사준 플스는 돌려주고 가!"라며 바짓가랑이를 붙잡고 남은 짐(데이터)을 싸주는 질척거리는 시간이며, LAST_ACK는 짐을 다 싸주고 상대가 마지막으로 "잘 살아라(최종 ACK)" 하고 뒤돌아 걸어가는 모습을 눈으로 확인하기 전 1초의 찰나입니다.

Ⅱ. 아키텍처 및 핵심 원리

네트워크 실무에서 TIME_WAIT 못지않게 시스템 엔지니어의 피를 말리는 것이 바로 좀비처럼 쌓이는 CLOSE_WAIT 장애다.

1. 정상적인 흐름의 완벽한 복기

클라이언트 ── FIN ──▶ 서버 (수신!)
서버 OS: "어? 쟤가 끊재! 일단 알았다고 대답해 줘!"
- 서버 ── ACK ──▶ 클라이언트
- [서버 소켓 상태: CLOSE_WAIT 진입!]
서버 OS -> 서버 애플리케이션(예: Tomcat): "야 톰캣아! 저기 손님이 이제 그만 먹고 나가겠대! 넌 짐 빨리 다 싸고 입에 물고 있는 소켓 닫아(Close() 함수 호출)!"
서버 애플리케이션은 남은 파일을 싹 다 밀어낸 뒤, 마지막으로 OS에게 "그래, 나도 다 줬어. 셔터 닫아라!"라고 지시한다.
서버 OS: "오케이!"
- 서버 ── FIN ──▶ 클라이언트
- [서버 소켓 상태: LAST_ACK 진입!]
클라이언트 ── ACK (마지막 영수증) ──▶ 서버
[서버 소켓 상태: CLOSED (완전 소멸, 깔끔한 해피엔딩!)]

[TIME_WAIT 상태]
    │
    ▼
[CLOSE_WAIT / LAST_ACK 상태]
    │
    └──▶ [TCP 흐름 제어]

📢 섹션 요약 비유: CLOSE_WAIT / LAST_ACK 상태의 내부 원리는 기계의 톱니바퀴처럼 맞물려 돌아간다. 한 부분이 어긋나면 전체 효과가 떨어진다.

Ⅲ. 비교 및 연결

CLOSE_WAIT / LAST_ACK 상태를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. TIME_WAIT 상태가 기반 조건을 만든다면, CLOSE_WAIT / LAST_ACK 상태는 그 위에서 핵심 메커니즘을 구현하고, TCP 흐름 제어는 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 신뢰성과 지연에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	TIME_WAIT 상태의 기반 정리	CLOSE_WAIT / LAST_ACK 상태의 핵심 동작	TCP 흐름 제어의 확장 적용
자원 관점	기본 조건 확보	신뢰성 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: CLOSE_WAIT / LAST_ACK 상태는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

리눅스 서버에 접속해 netstat -ano를 쳤는데, 100개가 넘는 소켓이 CLOSE_WAIT 상태로 며칠째 사라지지 않고 썩어간다면? 이건 **네트워크 문제가 아니라 100% 개발자의 코딩 실수(애플리케이션 버그)**다.

원리: CLOSE_WAIT 상태는 OS가 "야, 상대방이 끊쟀어! 너 하던 거 빨리 마무리하고 소켓 닫아라!"라고 어플리케이션(개발자가 짠 코드)에게 통보한 상태다.
버그 발생: 그런데 미친 어플리케이션이 무한 루프에 빠졌거나, 개발자가 코드 맨 마지막에 socket.close() 라는 종료 함수를 깜빡하고 안 적어 놓았다!
결과: 앱은 "나 아직 안 끝났어!"라고 멍때리고, OS는 "앱이 아직 안 끝났다니까 셔터 못 내리겠네..." 하고 무한정 기다려준다(CLOSE_WAIT). 상대방은 이미 퇴근한 지 오렌지인데, 내 서버 혼자서 끝도 없이 메모리에 소켓을 붙잡고 있다가 결국 서버 램이 꽉 차서 죽어버린다.

 ┌─────────────────────────────────────────────────────────────┐
 │                CLOSE_WAIT 장애 시나리오의 완벽한 묘사              │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 1. 고객 PC ] "나 로그아웃함 ㅂㅂ" (FIN) ──▶ [ 2. 우리 회사 서버 OS ] │
 │                                              상태: CLOSE_WAIT     │
 │                                                             │
 │   [ 3. 회사 서버 OS ] "야 백엔드 프로그램아! 고객이 끊쟀어 문 닫아라!"    │
 │       │                                                     │
 │       ▼ (명령 하달)                                          │
 │                                                             │
 │   [ 4. 미친 백엔드 프로그램 ] (개발자가 버그 내서 무한 연산 도는 중)       │
 │      "...... (무응답, close() 함수 호출 안 함)"                │
 │                                                             │
 │   ▶ 결론: OS는 앱이 명령을 내릴 때까지 수동적으로 평생 CLOSE_WAIT 상태로│
 │           기다린다. 이건 네트워크나 방화벽 문제가 아니라 순전히 개발자  │
 │           가 코드를 X 같이 짜서 발생한 애플리케이션 찌꺼기 에러다!!    │
 └─────────────────────────────────────────────────────────────┘

실무 체크리스트

요구사항과 병목 지점을 먼저 수치화한다.
운영 복잡도와 도입 효과를 함께 검증한다.
인접 기술과의 연계를 배포 전에 점검한다.

📢 섹션 요약 비유: ** CLOSE_WAIT 좀비 현상은 식당 지배인(OS)이 손님이 나갔다고 주방장(어플리케이션)에게 마감하라고 소리쳤는데, 주방장이 이어폰을 끼고 노래를 들으며 영원히 설거지만 하고 있어서, 지배인이 주방장 눈치를 보며 차마 식당 문셔터를 내리지 못하고 평생 밤을 새우는 환장할 코미디입니다. 해결책은 주방장(개발자) 등짝을 때려서 설거지(버그)를 멈추게 하는 것뿐입니다.

Ⅴ. 기대효과 및 결론

CLOSE_WAIT / LAST_ACK 상태는 전송 계층을 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 신뢰성 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 TCP 흐름 제어, 적응형 저지연 전송, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 적응형 저지연 전송 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

📢 섹션 요약 비유: CLOSE_WAIT / LAST_ACK 상태는 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념	연결 포인트
TIME_WAIT 상태	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
세그먼트 (Segment)	전송 계층이 다루는 기본 단위다.
흐름 제어 (Flow Control)	수신자 처리 속도를 넘지 않게 조절한다.
TCP 흐름 제어	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: TIME_WAIT 상태]
    │
    ▼
[현재 개념: CLOSE_WAIT / LAST_ACK 상태]
    │
    ├──▶ [확장 A: TCP 흐름 제어]
    └──▶ [확장 B: 적응형 저지연 전송]

CLOSE_WAIT / LAST_ACK 상태는 TIME_WAIT 상태에서 출발해 현재 메커니즘을 정교화하고, 이후 TCP 흐름 제어와 적응형 저지연 전송 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

물건을 보낼 때 받는 사람이 너무 빨리 받으면 놓칠 수 있어요.
이 개념은 천천히 보낼지, 다시 보낼지, 길이 막히면 멈출지를 정해줘요.
그래서 멀리 보내도 덜 잃어버리고 더 안정적으로 도착해요.