소켓 이론 2/3 · 연결 방향 — 아웃바운드 소켓의 원리

아웃바운드 소켓의 핵심은 연결을 누가 시작했는가입니다. 집이나 회사 안의 프로그램이 바깥 서버로 먼저 연결했다면 아웃바운드 연결입니다. 이 이름만 보고 데이터도 안에서 밖으로만 간다고 생각하기 쉽지만, 연결이 성립한 뒤에는 양쪽 모두 같은 소켓으로 데이터를 보낼 수 있습니다.

연결은 안에서 밖으로 시작하고, 성립한 소켓의 데이터는 양방향으로 오갑니다.

아웃바운드 연결 데모에서 안에서 먼저 연결을 재생하면 첫 CONNECT는 안쪽 PC에서 바깥 서버로 향합니다. 그 뒤 NOTICE는 반대 방향으로, STATUS는 다시 바깥 방향으로 이동합니다.

이번 편은 연결 원리까지만 다룹니다

앞의 소켓 완전 기초에서는 서버가 포트에서 기다리고 클라이언트가 connect()로 찾아가는 흐름을 배웠습니다. 이번 편은 그 연결이 방화벽과 NAT가 있는 네트워크 경계를 어떻게 지나가는지에 집중합니다.

이론 2/3에서 다루는 것	뒤의 응용 5단계에서 다루는 것
누가 새 연결을 시작하는가	메시지가 처리됐는지 어떻게 확인하는가
새 인바운드 연결과 기존 세션의 차이	끊긴 전송과 화면 상태를 어떻게 복구하는가
연결 뒤 데이터가 양방향인 이유	여러 서버와 지연이 있는 환경에서 어떻게 동작하는가

따라서 이 편에서는 재시도 횟수, 작업 체크포인트, 메시지 중복 제거 같은 운영 규칙을 설계하지 않습니다. 먼저 통로가 생기는 원리만 분명하게 구분합니다.

outbound는 연결 시작 방향입니다

안쪽 프로그램이 바깥 서버의 IP와 포트로 connect()를 호출한다고 생각해 봅시다.

연결 시작:  안쪽 프로그램 ── CONNECT ──▶ 바깥 서버
연결 성립:  안쪽 프로그램 ◀════ 데이터 ════▶ 바깥 서버

첫 줄이 outbound입니다. 두 번째 줄은 이미 성립한 연결의 데이터 흐름입니다. TCP 연결과 그 위의 WebSocket은 양쪽 프로그램 모두 읽고 쓸 수 있는 통로이므로, 서버가 데이터를 보낼 때마다 안쪽 PC로 새로 접속하는 것이 아닙니다.

질문	확인할 방향
누가 연결을 열었나?	안쪽 프로그램 → 바깥 서버
연결 뒤 누가 데이터를 보내나?	안쪽 프로그램 ⇄ 바깥 서버

연결 시작 방향과 send·receive 방향은 서로 다른 질문입니다.

새 인바운드 연결과 기존 세션은 다릅니다

집과 회사의 PC는 흔히 사설 주소를 사용하고 방화벽이나 NAT 뒤에 있습니다. 공개 주소, 포트 전달과 허용 규칙이 없는 상태에서 바깥 서버가 안쪽 PC로 새 연결을 바로 시작하면 도달하지 못합니다.

반대로 안쪽 프로그램이 먼저 바깥으로 연결하면 방화벽과 NAT는 그 연결에 필요한 상태를 관리할 수 있습니다. 이후 바깥 서버가 보내는 데이터는 별도의 새 인바운드 연결이 아니라, 이미 성립한 세션의 반대 방향 데이터입니다.

새 인바운드 연결: 바깥 서버 ── 새 CONNECT ──▶ 안쪽 PC  ✕
기존 세션의 데이터: 바깥 서버 ── DATA ───────▶ 안쪽 PC  ✓

두 번째가 가능하다고 해서 모든 목적지와 포트가 자동으로 허용되는 것은 아닙니다. 실제 환경에서는 조직의 아웃바운드 정책, 프록시와 목적지 허용 규칙을 별도로 확인해야 합니다.

WSS 연결에서는 무엇이 차례로 생길까요

데모는 wss://control.example.com/agent로 연결하는 상황을 단순화했습니다.

안쪽 프로그램이 바깥 서버로 TCP 연결을 시작합니다.
TLS handshake로 암호화된 통로를 만듭니다.
WebSocket handshake가 끝나면 지속해서 쓸 세션이 성립합니다.
프로그램이 열린 세션 안에서 자신을 식별합니다.
이후 양쪽이 같은 세션으로 데이터를 보냅니다.

wss는 WebSocket 통신을 TLS로 보호한다는 뜻입니다. 실제 제품에서는 서버 인증서 검증과 프로그램 인증도 필요하지만, 아웃바운드라는 방향 이름 자체가 인증이나 권한을 보장하지는 않습니다.

같은 원리는 여러 프로그램에서 보입니다

장비가 먼저 연결해 지표를 보내고 설정 알림을 받는 상태 수집
데스크톱 프로그램이 먼저 연결해 진행 상황을 주고받는 원격 작업
기기가 먼저 연결해 승인된 설정을 받는 장비 관리
브라우저가 WebSocket을 열고 서버 알림을 받는 실시간 화면

여기서 공통점은 구체적인 작업 내용이 아니라 안쪽 프로그램이 연결을 먼저 열고, 바깥 서버가 그 세션을 통해 반대 방향 데이터도 보낸다는 연결 구조입니다.

응용 규칙은 이론 3/3을 마친 뒤 이어집니다

아웃바운드 연결은 통로만 제공합니다. 그 통로를 운영하려면 데이터 성격에 따라 서로 다른 규칙이 필요합니다.

아래 5개는 언어별 소켓 런타임까지 이론 3단계를 마친 뒤 진행하는 응용 과정입니다.

전달 보장 — ACK·메시지 ID·재시도로 중복 부작용을 막습니다.
흐름 제어 — 느린 수신자 앞에서 멈추고 파일을 이어받습니다.
상태 동기화 — 버전과 스냅숏으로 놓친 화면 상태를 맞춥니다.
서버 확장 — 브로커와 저장소로 여러 서버 사이를 잇습니다.
지연 대응 — 늦게 온 과거 상태를 버리고 화면을 부드럽게 표시합니다.

이 문제들은 아웃바운드 연결에서만 생기는 것이 아닙니다. 인바운드로 받아들인 소켓, 브라우저 WebSocket과 다른 실시간 연결에서도 각각 설계해야 하는 응용 계층의 규칙입니다.

데모에서 볼 순서

안에서 먼저 연결에서 첫 CONNECT 화살표가 안쪽에서 바깥으로 가는지 봅니다.
세션이 성립한 뒤 NOTICE와 STATUS 화살표가 서로 반대인지 확인합니다.
밖에서 직접 연결로 바꿔 새 인바운드 연결이 차단되는지 봅니다.
안쪽 프로그램이 아웃바운드 연결을 열면 세션이 생기는지 확인합니다.
인바운드 포트는 닫힌 상태에서도 기존 세션의 데이터가 양방향인지 봅니다.

요약

outbound는 데이터를 보내는 방향이 아니라 새 연결을 시작한 방향입니다.
새 인바운드 연결과 이미 성립한 세션의 반대 방향 데이터는 다릅니다.
방화벽 안쪽 프로그램이 먼저 연결하면 공개 인바운드 포트 없이 지속 세션을 만들 수 있습니다.
전달 보장·이어받기·상태 복구·확장·지연 처리는 별도의 응용 규칙입니다.

다음 이론 편에서는 같은 소켓 서버를 Python·Node.js·Go·Rust가 어떻게 다르게 처리하는지 언어별 소켓 런타임으로 이어집니다.

자료: RFC 9293 — Transmission Control Protocol, RFC 6455 — The WebSocket Protocol, RFC 5382 — NAT Behavioral Requirements for TCP