arrow_back필드 노트로 돌아가기
NETWORKING 게시됨 8 Aug 2026

네트워킹에서 End-to-End가 정확히 무엇을 의미하는가?

End-to-end 연결성의 실제 분석, 실제 네트워크에서 끊기는 이유, traceroute와 MTU 검사를 이용한 테스트 방법.

사람들이 연결이 "end to end"라고 할 때, 그것은 데이터가 원본 소스 애플리케이션에서 목적지 애플리케이션까지 경로상의 어떤 middlebox도 몰래 재작성하거나 종료하지 않고 이동한다는 의미다. 실제 패킷의 경로를 NAT, 방화벽, 로드 밸런서, 프록시를 통해 추적하기 시작할 때까지는 간단해 보인다.

end-to-end 원칙

이 아이디어는 Saltzer, Reed, Clark가 작성한 1984년 논문에서 나온 것인데, 안정성과 암호화 같은 특정 기능들이 네트워크의 중간이 아닌 끝점에 있어야 한다고 주장했다. 핵심 네트워크는 단지 패킷을 전달해야 한다. 끝점은 오류 검사, 재전송, 순서 지정을 처리한다.

TCP가 가장 명확한 예다. 중간의 라우터들은 시퀀스 번호를 추적하거나 세그먼트를 확인하지 않는다. 그것은 TCP 스택을 실행하는 두 호스트의 역할이다. 네트워크 계층(IP)은 단지 최선 전달을 하고, 각 끝의 TCP가 손실되거나 순서가 바뀐 것을 수정한다.

오늘날 end-to-end가 제대로 작동하지 않는 곳

현대 네트워크는 이 원칙을 상수적으로 위반한다. 보통은 좋은 운영상 이유 때문이다.

  • NAT는 발신지 IP와 포트를 재작성하므로, 서버가 보는 패킷은 클라이언트가 보낸 패킷이 아니다.
  • TLS-terminating 프록시와 로드 밸런서(AWS ALB나 nginx 역방향 프록시 같은)는 하나의 TCP/TLS 세션을 종료하고 새로운 세션을 시작한다. 클라이언트의 실제 끝점은 프록시이지, 앱 서버가 아니다.
  • Stateful 방화벽은 연결 상태를 추적하고 예상되는 시퀀스와 일치하지 않는 패킷을 버릴 수 있으며, 실제로 자신을 대화에 주입한다.
  • CGNAT는 ISP 네트워크에 있어서 많은 고객이 하나의 공개 IP를 공유하므로, IP가 하나의 호스트에 매핑된다는 가정을 깨뜨린다.

이것은 디버깅할 때 실제로 중요하다. 사용자가 "연결이 끊겼다"고 보고하면, 그것이 자신의 노트북, 홈 라우터, ISP, CDN 엣지 노드, 로드 밸런서 또는 원본 서버에서 끊겼는지 알아야 한다. End-to-end 사고방식은 자신의 서버 로그만 확인하는 대신 전체 체인을 추적하도록 강제한다.

end-to-end 연결성 테스트

성공/실패뿐 아니라 실제로 경로를 보여주는 몇 가지 도구:

# 홉별로 경로 추적
traceroute 8.8.8.8

# Linux에서 MTR은 홉당 지속적인 통계를 제공
mtr google.com

# 패킷을 조각내거나 조용히 버리는 MTU 문제 확인
ping -M do -s 1472 8.8.8.8

마지막 명령어는 잘 알아둘 가치가 있다. Path MTU discovery 실패는 고전적인 "end-to-end 연결성처럼 보이지만 실제로 아닌" 문제다. TCP SYN 같은 작은 패킷은 잘 통과하지만, 일단 전체 크기의 페이로드를 보내면, 경로상의 어떤 홉이 그것이 너무 크다고 생각하고 방화벽이 ICMP "fragmentation needed"를 차단하고 있어서 조용히 버린다. 연결이 멈추고 모두가 애플리케이션을 탓한다.

TCP의 경우, 양쪽 끝에서 tcpdumpss -ti를 실행하면 두 호스트가 실제로 열린 연결을 가지고 있다고 동의하는지 알려준다:

ss -ti dst 203.0.113.5

한쪽이 연결이 ESTABLISHED라고 생각하고 다른 쪽이 아무것도 표시하지 않으면, 중간의 무언가(보통 유휴 연결을 시간초과하는 방화벽)가 조용히 그것을 종료했다.

보안상 왜 이것이 중요한가

End-to-end 암호화는 같은 개념의 보안 관련 버전이다. 브라우저와 CDN 엣지 사이의 TLS는 브라우저와 원본 서버 사이의 TLS와 같지 않다. CDN이 TLS를 종료하고 평문(또는 새로운 TLS 연결)을 백엔드로 전달하면, 하나의 연속된 암호화된 채널이 아닌 두 개의 별개 암호화된 홉이 있다. 대부분의 사용 사례에는 괜찮지만, 민감한 것을 다루는 경우라면 정확히 어디서 복호화가 일어나고 각 홉에서 누가 평문을 볼 수 있는지 알아야 한다.

같은 논리가 VPN에도 적용된다. "full tunnel" VPN은 장치에서 VPN 출구 노드까지의 end-to-end 암호화를 제공하지만, 출구 노드에서 실제 목적지 서버로의 연결은 자신의 보안 속성을 가진 별개의 홉이다.

실무적 결론

누군가 네트워크 경로가 end to end라고 할 때, 정확히 어느 두 지점 사이의 end to end인지 물어보자. 클라이언트와 로드 밸런서 사이? 로드 밸런서와 앱 서버 사이? 실제 끝점을 명명하면 모호한 네트워킹 주장이 패킷 캡처로 테스트할 수 있는 것으로 바뀐다.

실제 트래픽 추적과 패킷 캡처 읽기에 대해 더 깊이 알아보고 싶다면, Korra Studio의 DEFENSE_GRID 플랫폼의 Wireshark와 TCP/IP fundamentals 섹션을 확인해보자.

AI 도움을 받아 작성했으며, Michal Pilch(CISSP), Korra Studio에서 검토 및 게시했어요.

더 나아가고 싶으신가요?

이것은 Korra Studio 나레지베이스의 한 노트예요. 플랫폼은 모든 주제를 1-to-1 멘토링과 함께 제공해요.

무료로 시작하기arrow_forward