커넥션 타임아웃

친구가 전화를 받지 않을 때 신호음이 무한정 울리도록 전화기를 붙잡고 있는 사람은 없어요. 일정 시간 신호음을 듣다가 응답이 없으면 결국 내가 먼저 전화를 끊죠. 만약 끝없이 신호음만 간다면 전화를 건 사람도 다음 일을 하지 못한 채 계속 멈춰 서 있게 될 거예요.

인터넷 세상에서도 똑같은 규칙이 매 순간 적용돼요. 스마트폰으로 특정 웹사이트나 모바일 앱에 접속할 때, 우리 기기는 먼저 목적지 서버 컴퓨터에 "지금 대화할 준비가 되었나요?"라는 인사 신호를 전송해요.

하지만 목적지 서버의 전원이 꺼져 있거나 전산망 케이블이 끊어졌다면 아무런 대답도 돌아오지 않아요. 응답 없는 서버를 너무 오래 기다리면 사용자는 로딩 화면만 하염없이 보게 되고, 기기의 자원도 그만큼 묶여요. 그래서 프로그램들은 미리 정해 둔 대기 시간까지만 기다린 뒤, 반응이 없으면 연결 시도를 깔끔하게 포기하도록 설계되어 있어요.

조금 더 정확히 말하면, 커넥션 타임아웃은 실제 데이터를 주고받는 과정에서 터지는 문제가 아니라 대화 통로를 처음 만드는 단계에서 발생해요.

인터넷에서 두 컴퓨터가 통신할 때는 '3단계 악수(3-Way Handshake)'라는 절차를 거쳐요. 내 스마트폰이 먼저 "연결해도 될까요?"라며 손을 내밀고(SYN), 서버가 "좋아요, 연결합시다"라고 대답하며(SYN-ACK), 다시 내 기기가 확인 신호(ACK)를 보내야 믿을 수 있는 연결 통로가 비로소 완성돼요.

그런데 서버 앞을 지키는 방화벽(보안 시스템)이 허락되지 않은 접근이라며 신호를 몰래 버리거나, 중간 네트워크 장비에서 데이터가 유실되면 첫 악수가 성립하지 않아요. 내 컴퓨터는 대답을 기다리며 정해진 타이머를 작동시키고, 약속된 초 단위 시간이 만료되는 순간 접속 실패 에러를 띄우게 돼요.

많은 분이 커넥션 타임아웃을 읽기 타임아웃(Read Timeout)과 자주 혼동하곤 해요. 두 현상은 에러가 발생하는 시점과 원인이 완전히 달라요. 식당에 빗대어 보면 이 차이를 아주 명쾌하게 이해할 수 있어요.

커넥션 타임아웃은 식당 문을 아무리 두드려도 안에서 아무 대답이 없어, 가게 안으로 발을 들이지도 못하고 문밖에서 서성이다 돌아가는 상황이에요. 만약 직원이 나와 "오늘은 영업 안 해요"라고 바로 알려 준다면, 그건 연결 거부(Connection Refused)라는 다른 오류예요. 대화 통로 자체가 열리지 않은 것이죠.

반면에 읽기 타임아웃은 식당 안에 정상적으로 입장해서 점원과 대화하고 음식 주문까지 끝마친 상태예요. 그런데 주방에서 주문이 너무 밀려 1시간이 지나도록 음식이 나오지 않아 손님이 결국 기다리다 지쳐 나가는 상황이에요.

따라서 커넥션 타임아웃 오류가 발생했다면 서버가 꺼져 있거나, 방화벽이 신호를 버리거나, 중간 경로에서 신호가 사라졌을 가능성이 크고, 읽기 타임아웃 오류가 떴다면 서버의 처리가 지연되고 있거나(과부하, 데이터베이스 조회 지연 등) 연결 이후 데이터 전달 과정이 막혔을 가능성이 높아요.