왜 프레임워크 시대에 소켓을 직접 배우는가

솔직한 질문부터 던져 보겠습니다. FastAPI로 API 서버를 만들고, Express로 웹 서버를 띄우고, 메시지는 WebSocket 라이브러리가 알아서 처리해 주는 시대입니다. 그런데 왜 굳이 한 단계 내려가서 socket()이니 recv()니 하는 저수준 함수를 직접 호출하는 법을 배워야 할까요. 이 질문에 답하지 못하면 이 책을 끝까지 읽을 동기가 생기지 않습니다. 그래서 먼저 답하겠습니다.

추상화는 새는 법이다

프레임워크는 소켓을 감싸서 편하게 만들어 줍니다. 하지만 그 추상화는 완벽하지 않습니다. 언젠가는 반드시 그 아래가 비집고 나옵니다. 서버가 갑자기 "Connection reset by peer"를 뱉으며 죽을 때, 응답이 중간에 잘려 도착할 때, 동시 접속이 1만 명을 넘자 서버가 멈출 때. 이런 문제는 프레임워크 문서 어디에도 답이 없습니다. 답은 그 아래, 소켓 계층에 있습니다. 소켓을 이해한 사람만이 이 문제를 디버깅할 수 있습니다.

프로토콜은 직접 설계해야 할 때가 온다

HTTP는 훌륭한 프로토콜이지만 모든 상황에 맞지는 않습니다. 게임 서버는 위치 정보를 초당 수십 번 주고받아야 하고, IoT 기기는 수 바이트짜리 메시지를 배터리를 아껴 가며 보내야 합니다. 이럴 때는 자신만의 통신 규약을 직접 설계하게 됩니다. 메시지의 경계를 어떻게 나눌지, 명령을 어떤 형식으로 실을지를 스스로 정해야 합니다. 이 책의 후반부에서 바로 그 일을 합니다.

복원력은 저수준에서 나온다

견고한 서버는 클라이언트가 갑자기 사라져도, 네트워크가 잠깐 끊겨도, 느린 클라이언트가 버퍼를 가득 채워도 무너지지 않습니다. 이런 복원력은 타임아웃을 어떻게 걸고, 부분 전송을 어떻게 처리하고, 자원을 어떻게 회수하는지에 달려 있습니다. 모두 소켓 계층의 이야기입니다.

그리고 면접

조금 현실적인 이유도 있습니다. 백엔드, 시스템, 게임, 임베디드 어느 분야든 기술 면접에서 소켓은 단골 주제입니다. TCP와 UDP의 차이, 블로킹과 논블로킹, select와 epoll, TIME_WAIT은 왜 생기는가. 이 질문들에 직접 짠 코드를 떠올리며 답할 수 있다면, 외워서 답하는 사람과는 분명히 다릅니다.

정리하면, 소켓을 배우는 것은 옛날 방식을 배우는 것이 아닙니다. 프레임워크가 서 있는 땅을 이해하는 일입니다. 땅을 아는 사람은 그 위에 무엇이든 더 단단하게 세울 수 있습니다.