TCP/IP

인터넷에서 데이터는 하나의 덩어리로 안전하게 이동하지 않습니다. 패킷은 중간 라우터를 지나며 순서가 바뀌거나, 일부가 사라지거나, 중복으로 도착할 수 있습니다. 그런데 사용자는 웹 페이지가 절반만 로드되거나, 파일이 중간에 잘리거나, 데이터베이스 쿼리 결과가 뒤섞이는 상황을 받아들이지 않습니다. 각 애플리케이션이 이런 문제를 매번 직접 처리하게 두면 구현은 중복되고, 조금만 실수해도 데이터 무결성이 무너집니다. TCP는 이 신뢰성 문제를 애플리케이션 밖의 공통 전송 계층에서 한 번 해결하려고 만들어진 약속입니다.

1970년대 패킷 교환 네트워크가 등장했을 때, 끝단 애플리케이션은 큰 불확실성을 떠안아야 했습니다. 네트워크는 패킷을 흘려보내지만 그 패킷이 언제, 어떤 순서로, 얼마나 완전하게 도착할지는 따로 보장하지 않았습니다. 이 상태에서는 새로운 애플리케이션을 만들 때마다 자체적인 오류 복구 규칙을 다시 설계해야 했고, 상호 운용성도 나빠졌습니다. TCP가 중요했던 이유는 인터넷을 단순히 연결된 망이 아니라, 신뢰성 있는 종단 간 통신을 제공하는 공통 기반으로 바꿨기 때문입니다. 이 공통 기반 위에서 웹, 이메일, 파일 전송이 각자 신뢰성 로직을 재발명하지 않고 사용할 수 있게 됐습니다.

TCP는 먼저 3-way 핸드셰이크로 양쪽이 통신할 준비가 됐는지 확인하며 연결을 세웁니다. SYN을 보내고 SYN-ACK를 받고 ACK를 돌려주는 세 단계로 서로의 존재와 준비 상태를 확인합니다. 연결이 맺어지면 데이터를 세그먼트로 나누고 순번을 붙여 보내기 때문에, 받는 쪽은 빠진 조각이 있는지와 순서가 어긋났는지를 알 수 있습니다. 수신 측은 ACK로 어디까지 정상적으로 받았는지 알려주고, 송신 측은 일정 시간 안에 ACK가 오지 않으면 해당 구간을 다시 보냅니다. 여기에 수신자가 감당할 수 있는 속도에 맞추는 흐름 제어와, 네트워크 혼잡이 심할 때 전송량을 줄이는 혼잡 제어가 더해져 연결 전체의 안정성을 관리합니다.

TCP와 UDP는 둘 다 IP 위에서 동작하며 애플리케이션 데이터를 네트워크로 실어 나른다는 점에서 같습니다. 차이는 무엇을 우선하느냐에 있습니다. TCP는 연결 수립, 순서 보장, 재전송, 흐름 제어를 통해 결과의 정확성을 우선하고, 그만큼 헤더와 왕복 확인 과정이 늘어납니다. UDP는 이런 확인 절차를 줄여 빠르게 보내는 대신 손실과 순서 어긋남을 애플리케이션이 감수하거나 별도로 처리해야 합니다. 거래 기록, 로그인, 파일 전송처럼 틀리면 안 되는 통신에는 TCP가 맞고, 몇 프레임이 빠져도 전체 경험이 무너지지 않으면서 수십 밀리초 단위 지연이 중요한 상황에서는 UDP가 더 적합합니다.

TCP는 웹 요청과 응답, 파일 전송, 이메일, 데이터베이스 세션처럼 데이터가 정확하게 도착해야 하는 업무용 통신의 기본 선택지입니다. 클라이언트와 서버가 상태를 맞춰 가며 긴 대화를 이어가야 할 때도 TCP의 연결 모델이 유리합니다. 반대로 몇 개 패킷이 빠져도 전체 경험이 크게 무너지지 않고 반응 속도가 우선인 경우에는 TCP의 확인 절차가 부담이 될 수 있습니다. TCP를 쓸지 결정할 때 가장 먼저 따져야 할 질문은 '빠른가'가 아니라 '잃어버리거나 뒤섞여도 되는가'입니다. 신뢰성이 우선인 시스템을 설계할 때 TCP를 기본 가정으로 두면, 애플리케이션은 비즈니스 로직에 더 집중할 수 있습니다.