피터의 개발이야기

[바이브코딩] 04. AI에게도 SDLC가 필요하다 - ChatGPT, Claude, Codex를 팀처럼 일하게 만든 방법

기록하는 백엔드개발자 — Wed, 5 Aug 2026 22:17:51 +0900

AI는 혼자 일하는 도구가 아니라 역할을 나누어 협업하는 팀원이 될 수 있다.

ㅁ 들어가며

AI 코딩을 처음 시작하면 대부분 하나의 AI에게 모든 일을 맡긴다.

기획해줘.

설계해줘.

구현해줘.

리뷰해줘.

문서도 작성해줘.

처음에는 꽤 잘 동작한다.

하지만 프로젝트가 커질수록 이상한 점을 발견하게 된다.

AI가 자신이 만든 설계를 스스로 검토하고,

자신이 작성한 코드를 스스로 리뷰하며,

자신이 내린 결론을 다시 자신이 승인한다.

사람이라면 설계자와 개발자, 리뷰어를 분리하는데 AI에게는 모두 같은 역할을 맡기고 있었던 것이다.

이번 글에서는 ContextBase 프로젝트를 진행하면서 AI를 하나의 개발팀처럼 운영한 방법을 정리해 보려고 한다.

ㅁ 개발팀은 왜 역할을 나눌까?

실제 개발 조직을 생각해 보자.

기획자는 요구사항을 정의한다.

개발자는 코드를 작성한다.

리뷰어는 구현이 설계와 일치하는지 확인한다.

QA는 테스트를 수행한다.

모든 역할을 한 사람이 수행할 수도 있지만, 규모가 커질수록 역할을 분리하는 것이 품질과 생산성을 높인다.

AI도 마찬가지였다.

ㅁ AI도 역할을 나누기 시작했다

ContextBase에서는 AI를 세 명의 팀원처럼 사용했다.

ChatGPT
↓
Codex
↓
Claude

각 AI는 서로 다른 책임을 가진다.

ChatGPT

프로젝트 전체 이해
요구사항 분석
설계
다음 작업 계획
프롬프트 작성

즉, Technical Lead 역할이다.

Codex

설계 구현
테스트 작성
결과 문서 작성

즉, Senior Developer 역할이다.

Claude

구현하지 않는다.
설계를 변경하지 않는다.
코드 리뷰만 수행한다.

즉, Principal Reviewer 역할이다.

ㅁ ContextNote 활용기

Context Note — AI 대화의 컨텍스트는 왜 “쌓지 않고 구조화”해야 할까?
일전에 ChatGPT와 대화를 하면서 컨텍스트를 정리하기 위해 ContextNote만들었다.

대화를 진행하면서 중요한 컨텍스트는 문서로 정리하고, 문서의 일부를 선택하여 대화를 집중적으로 수행할 수 있었다.
말로 전하는 것보다 문서를 보면 맥락을 ChatGPT가 잘 알 수 있어서 대화가 딴방향으로 가는 것을 많이 막을 수 있었다.

무엇보다 대화 중 핵심내용을 정리하여 문서로 바로 옮길 수 있어서 편리하고 사용 중이다.

ChatGPT Atlas를 사용하고 있다. 웹과 함께 대화를 이어가면서 아이디어 구상, 작업 검토 등을 수행하였다.

실제로 프로젝트의 md파일들을 직접 contextNote에 연결하여 활용하면 claude와 codex의 지시사항을 문서로 바로 등록이 가능하였다.

무엇보다 이렇게 쓰는 이유는 chatGPT가 대화를 통해 활용하면 Token의 제약을 거의 받지 않기 때문이다.

아쉽게도 이 Atlas는 26.08.09에 종료된다.

ㅁ 처음에는 너무 느렸다

초기에는 품질을 높이기 위해 모든 단계를 검토했다.

Plan
↓
Plan Review
↓
Implementation
↓
Code Review
↓
Completion Report
↓
Document Alignment

품질은 매우 높았다.

하지만 기능 하나를 구현하는 데 AI가 여러 번 왕복하면서 개발 속도가 크게 떨어졌다.

처음에는 이것이 맞는 방식이라고 생각했다.

하지만 프로젝트가 진행될수록 병목이 보이기 시작했다.

ㅁ 중요한 것은 검증이 아니라 역할이었다

프로젝트가 P3, P4, P5를 거치면서 느낀 것은 의외였다.

문제는 AI의 성능이 아니었다.

문제는 같은 AI가 모든 역할을 수행하는 구조였다.

역할이 분리되자 각 AI는 자신의 책임에만 집중할 수 있었다.

ChatGPT는 설계를 고민하고,

Codex는 구현에 집중하며,

Claude는 객관적으로 리뷰한다.

사람의 개발 프로세스를 AI에게 그대로 적용한 셈이다.

ㅁ 그래서 개발 방식도 바뀌었다

현재는 훨씬 단순한 흐름을 사용한다.

설계
↓
구현
↓
최종 리뷰

ChatGPT가 설계를 확정한다.

Codex가 구현과 테스트를 수행한다.

Claude가 최종 승인한다.

불필요한 중간 검토를 줄이면서도 설계와 구현, 리뷰의 책임은 유지했다.

ㅁ AI에게도 SDLC가 필요했다

많은 사람들이 AI 활용 능력을 프롬프트 작성 능력이라고 생각한다.

하지만 프로젝트를 진행하면서 얻은 결론은 조금 달랐다.

AI가 아무리 뛰어나도 역할이 명확하지 않으면

설계와 구현, 리뷰가 서로 섞이기 시작한다.

결국 중요한 것은 프롬프트가 아니라 프로세스였다.

사람에게 SDLC가 필요하듯,

AI에게도 SDLC가 필요했다.

ㅁ 네트워크 비유로 생각해 보면

네트워크에서 TCP는 모든 일을 하나의 패킷이 처리하지 않는다.

전송은 Packet이 하고,

경로 선택은 Router가 하고,

오류 복구는 TCP가 담당한다.

각 계층이 자신의 역할만 수행하기 때문에 복잡한 네트워크도 안정적으로 동작한다.

AI 협업도 비슷하다.

ChatGPT는 설계를 담당하고,

Codex는 구현을 담당하며,

Claude는 검증을 담당한다.

역할이 명확해질수록 프로젝트는 더 안정적으로 진행된다.

ㅁ 핵심 정리

AI 하나에게 모든 역할을 맡기면 객관적인 검증이 어려워진다.
사람의 개발 조직처럼 AI도 역할을 분리할 수 있다.
ChatGPT는 설계, Codex는 구현, Claude는 리뷰를 담당했다.
프로젝트가 안정된 이후에는 Gate 기반으로 프로세스를 단순화했다.
중요한 것은 AI 모델이 아니라 역할과 책임을 정의하는 개발 프로세스였다.

[AWS] LG Uplus의 BSS 현대화를 위한 클라우드 마이그레이션 여정, DevOps 포인트

기록하는 백엔드개발자 — Tue, 4 Aug 2026 14:33:52 +0900

ㅁ 들어가며

AWS Summit Seoul 2024에서 공개된 LG Uplus의 BSS 현대화 사례를 보게 되었다.

예전에 LGUplus에서 일했을 때에 알고 있었던 UCube 시스템의 고도화 사례를 소개하고 있다.

복잡한 레거시 시스템을 DevOps관점에서 어떻게 바꾸었는지 기술적으로 배울점이 많아 정리해 보았다.

ㅁ BSS(Ucube)는 무엇?

https://www.youtube.com/watch?v=ZEJRN-p9QYw

BSS는 통신사의 고객, 계약, 과금, 청구를 담당하는 핵심 시스템이다.

LG Uplus의 BSS는 홈·기업·모바일 전 영역의 정보를 다루는 대형 기관계 시스템이고, 운영 규모도 상당하다.

매달 청구되는 휴대폰요금부터 시작해서 기업메시징 비용까지, 모든 계약과 요금들이 이 시스템을 통해 정산 청구된다.

통신사가 오래된 만큼 시 오래 운영된 시스템도 문제가 많았다.
오래된 UI 구조, 복잡한 분기 로직, 백엔드 중복 코드, DB 종속성 때문에 유지보수가 점점 어려워졌다고 한다.

하루 수천만 건 규모의 트랜잭션과 배치가 오가는 대형 시스템이다.

ㅁ 레거시에서 클라우드로 가는 문제점

대부분의 레거시 시스템은 대규모 DB의존적인 경우가 많다. 트래픽이 많지면서 컨넥션 갯수도 용량도 부족하게 된다.

문제는 과도한 트랜젝션은 감당하기 어려워 진다.

이처럼 느린 시스템보다 더 어려운 점은 바꾸기 어려운 시스템이라는 점이다.

메뉴가 약 2,500개, 화면이 4,000개...

기능 추가도 어려워지고, 변경 영향 범위가 크다. 점점 감당하기 어려운 파스타소스가 되어가는 것이다.

ㅁ 현대화의 방향

LG Uplus가 세운 현대화 전략은 크게 세 가지였다.

- 분리된 서비스는 비동기 방식으로 연결한다. => 소스를 쪼개고

- 서비스를 독립적으로 분리하고 CI/CD를 구축한다. => 민첩하게 배포하고

- 클라우드와 오픈 소스를 활용해 유연하고 효율적인 인프라를 만든다. => 확장가능한 인프라를 구축

MSA로 쪼개고, 비동기로 만들고, k8s로 배포의 용이성과 장애 대응을 이루는 목표이다.

ㅁ 적용 기술

적용기술을 보면서 사용하지 못한 기술들이 있어서 매우 흥미로웠다.

사실 내가 해보지 못한 고난이도의 트랜젝션 처리를 위한 SAGA와 이를 지원해주기 윈한 Eventuate가 그것이었다.


Agility 강화	Framework	Spring Boot Eventuate
	데이터베이스	Mysql(Aurora, MariaDB), Oracle
	CI/CD	Gitlab, Jenkins, Helm, ECR, Harbor, ArgoCD
서비스 안정성	Event Driven	Message Broker (kafka), Eventuate CDC
	Observability	WhaTap, Dynatrace, EFK
	컨테이너관리	Public: AWS EKS, Private: Openshift
	Service Mesh	Istio
자원사용 최적화	Virtual Machine	Public: AWS EC2, Private: VMware

ㅁ 서비스 분리 방식

모든 기능을 무조건 마이크로서비스로 나눈지는 않는다.

변경이 잦은 기능은 마이크로서비스로, 안정성과 일관성이 주용한 기능은 비교적 큰 단위로 분리 전략을 가졌다.

무조건 작은 서비스로 쪼개는 방식이 아니라,

변경 빈도와 중요도에 따라 마이크로/매크로로 나눴다는 점이 인상적이었다.

분산된 서비스에 대한 처리는 비동기 설계를 원칙으로 한다.

처리 영역에서 Message Broker를 적용하여 개별 Micro서비스의 장애 시에도 처리를 보장하고자 한다.

ㅁ 정합성은 어떻게 해결했나?

MSA의 경우 도메인별, 혹은 서비스별로 모듈화하여 빠르게 신규 서비스를 적용하고

서비스장애로부터 전체 시스템에게 영향력을 최소화한다.

하지만, 데이터의 분리로 인해 데이터 정합성을 위한 트렌젝션 처리는 난감해진다.

사실 이 부분은 예전부터 내가 가장 궁금했던 주제이기도 했다.

마이크로서비스는 서비스를 독립적으로 분리하지만, 그만큼 데이터도 분산된다.

서비스 간 결합도는 낮아지지만, 반대로 하나의 트랜잭션으로 처리하던 작업은

여러 서비스에 걸쳐 수행되어야 한다. 그러면 서로 다른 서비스에 저장된 데이터를 어떻게 일관성 있게 유지할 것인가?

이 고민 때문에 예전에도 MSA를 공부하면서
'12가지 마이크로서비스 패턴', '배민 마이크로서비스 여행기', 'CQRS 패턴' 등을 정리한 적이 있다.

특히 배민 사례에서는 변경이 잦은 영역과 안정성이 중요한 영역을 다르게 분리하는 전략을 소개했고,

CQRS는 읽기와 쓰기를 분리하여 서비스의 확장성과 성능을 확보하는 대신,

결국 데이터 정합성을 어떻게 유지할 것인지가 핵심 과제가 된다는 점을 설명하고 있었다.

결국 MSA의 핵심은 서비스를 잘게 나누는 것이 아니라,

분산된 데이터의 정합성과 장애를 어떻게 설계할 것인지에 있다는 점을 계속 고민해 왔다.

이번 LG U+ 사례는 그 고민에 대한 실제 운영 사례를 보여주었다.

단순히 CQRS를 적용하거나 이벤트를 사용하는 수준이 아니라,

Transactional Outbox, Saga, 시멘틱 락, Dead Letter Queue를 함께 활용하여

최종 일관성(Eventual Consistency)을 확보하는 방식을 선택한 것이다.

결국 MSA의 핵심은 서비스를 잘 나누는 것이 아니라,

분산된 데이터의 정합성과 장애를 어떻게 설계할 것인가에 있다는 점을 계속 고민해 왔다.

분산 환경에서 가장 어려운 건 결국 데이터 정합성이다.

이를 위해 Transactional Outbox, Saga 패턴, 락 전략, 재처리용 별도 서비스 등을 조합해 운영했다고 설명한다.

방식	설명
Transactional Outbox	데이터베이스 변경과 메시지 발행을 하나의 트랜잭션으로 묶어 원자성을 보장하는 설계 방식
Saga 패턴	마이크로서비스 아키텍처(MSA)에서 분산된 여러 서비스의 데이터 일관성을 유지하기 위해 사용하는 로컬 트랜잭션 연속 실행 및 보상 트랜잭션 관리 방식 단일 거대 트랜잭션 대신 각 서비스별로 DB를 업데이트하고 이벤트를 통해 다음 단계를 진행하며, 중간에 실패하면 보상 트랜잭션으로 이전 작업을 되돌려 최종 일관성(Eventual Consistency)을 보장
시멘틱 락	데이터베이스 수준의 락이 아니라 애플리케이션 수준에서 데이터에 플래그(표식)를 두어 아직 처리 중이거나 변경될 수 있는 상태임을 나타내는 동시성 제어 기법
Dead Letter Queue	메시지 큐 시스템에서 오류나 기타 이유로 정상 처리되지 못한 메시지들을 별도로 모아두는 특수한 대기열(토픽)

이 부분이 특히 인상적이었다.
MSA 전환은 “서비스를 쪼개는 일”처럼 보이지만, 실제로는 정합성을 어떻게 유지할지 결정하는 일에 더 중요하다.
기술적으로 멋진 구조보다, 장애 상황에서도 데이터가 틀어지지 않게 만드는 설계가 더 중요하다는 메시지가 분명했다.

특히 돈과 계약에 관련된 사안들은 더욱 그러하다.

ㅁ 데이터 마이그레이션과 검증

돈은 그래도 맞지 않는 경우가 발생한다. 이를 찾기 위해서 일일 대사를 비교하곤 하는데 그 작업이 쉬운게 아니다.

예전 전자결제팀에서 정산데이터를 다루는 SQL문을 함부로 돌릴 수도 없었다. 부하가 발생하기 때문이다.

AWS를 사용한다면, Read쪽에서 돌리던가, DB 인스턴스를 복제하여 부하로 인한 운영 영향력을 줄일 수 있다.

여기서 소개하는 것은 조금 다른 방법이었다.

방해한 로그를 S3에 적제하고 있었든데, 이를 Athena를 통해 특정 유입을 분석한 경험은 있었다.

하지만, 이를 정산 데이터에 적용한 부분은 AWS의 새로운 가능성을 제시해 준다고 생각한다.

방대한 데이터를 AWS DMS, Glue, S3, Athena, Lambda, EventBridge를 활용해 데이터 비교와 검증을 하였다.

요소	역할
AWS DMS	데이터베이스와 분석 시스템을 안전하고 빠르게 다른 곳으로 옮겨주는 ⁠AWS Database Migration Service 클라우드 서비스 원본 데이터베이스의 데이터를 손실 없이 대상 데이터베이스로 복제하며, 서비스 중단 시간을 최소화함.
AWS Glue	여러 소스의 데이터를 쉽게 검색, 준비, 이동, 통합할 수 있도록 돕는 서버리스 데이터 통합 서비스이자 완전 관리형 ETL(추출, 변환, 적재) 서비스
AWS Athena	표준 SQL을 사용해 ⁠Amazon S3에 저장된 데이터를 직접 분석할 수 있는 서버리스 대화형 쿼리 서비스
EventBridge	다양한 소스에서 발생한 이벤트를 받아 원하는 곳으로 전달해 주는 서버리스 이벤트 라우팅 서비스

구성은 다음과 같다.

- AWS DMS와 Glue로 검증 대상 데이터를 S3로 추출.
- Athena로 비교 검증.
- Lambda와 EventBridge로 전체 과정을 자동화.

이렇게 해서 사용자가 쉽게 활용할 수 있는 자동 데이터 검증 플랫폼을 만들었고,

이후에는 분산 서비스 간 대용량 데이터 추출과 배치 작업에도 활용하고 있다.

ㅁ 클라우드 전략과 마이그레이션

우선 AWS를 선정하고 인프라의 가용성과 효율성을 정하고 민감정보는 Private, 민첩성이 중요한 서비스는 퍼블릭에 둔 하이브리드 클라우드를 택하였다.

중요한 점은 기존 기능과 신규 기능을 BFF 레이어로 라우팅해서 점진적으로 페이드아웃시켰다.

신규 기능은 차세대 쪽으로, 기존 기능은 레거시 쪽으로 보내면서 사용자가 자연스럽게 전환되도록 한 구조이다.

기술	대상
BFF	Frontend를 위한 API
API Gateway	외부 요청의 입구 모든 API 요청이 먼저 Gateway를 통과 인증,권한 Routing, Load Balancing 처리 대표: Envoy
GraphQL	필요한 데이터만 조회는 API 조회 방식 REST라면 3번 호출할 것을 다음처럼 한번에 호출하는 API 형태이다. { user { name orders { product } }
Istio	서비스 간 통신 관리이다.

DAX 관점에서는

Client
  ↓
 BFF
  ↓
API Gateway
  ↓
Kubernetes
  ↓
Istio(Service Mesh)
  ↓
Microservices

ㅁ 기존 데이터와 신규 데이터를 어떻게 공존시켰나

레거시 모놀리스에서 신규 도메인을 분리할 때는 참조 관계가 가장 어렵다.

DB 스키마를 광범위하게 바꿔야 하므로,

이 팀은 전환 기간 동안 원본 스키마를 유지하면서 신규 스키마와 데이터를 동기화하는 방식을 사용했다.

구체적으로는 신규 도메인 서비스 영역을 읽기 전용처럼 두고, 갱신이 발생하면 그 변경을 모놀리스에 복제해 최신 상태를 유지하여,

기존 서비스와 신규 서비스 간 데이터 동화를 유지했다. 결국 이 영역은 전환이 끝나면 모놀리스와 함께 페이드아웃된다.

ㅁ 차세대 이후의 최적화

네트워크 개선

기존에는 중앙 집중식 네트워크에서 Direct Connect(전용선)를 타고 IDC의 시 서버를 경유해 인터넷으로 나가는 구조였는데,

이 방식은 EKS와 애플리케이션 각각에 별도 설정이 필요해 관리가 어려웠다.

이를 개선하기 위해 쉐어드 어카운트에 AWS Network Firewall을 두고 인터넷 통신 구조를 재설계했다.

이렇게 하면 각 계정마다 NAT Gateway나 IGW를 따로 만들지 않아도 되어,

공인 IP 사용을 줄이고 보안 정책에 맞는 도메인만 통신하도록 통제할 수 있다.

또한 기존 172 대역 24비트 CIDR의 IP 고갈 문제를 해결하려고, 10점대 16비트 CIDR을 적용한 새 VPC를 설계했다.

EKS 서비스가 기존 DB와 통신할 때는 VPC Peering을 쓰고,

IDC/온프레미스와는 Private NAT Gateway로 IP 변환 통신하게 개선했다.

나도 IP고갈문제로 인해 작성한 글이 있어서 공감되었다.

[AWS VPN] Amazon VPC의 CIDR 블록 IP 확장방법, AWS IP증설

코드 기반 인프라

기존에는 AWS 콘솔 작업이 많아서 생성·변경·삭제 이력이 추적하기 어려웠다.

이를 Terraform과 Atlantis로 가져가고 GitHub에서 관리해 히스토리 추적이 가능하게 만들었다.

배포도 Helm 명령에서 GitOps 방식으로 바꿔 Argo CD 멀티클러스터 구조로 관리한다.

CI/CD와 배포 가시성

예전에는 테스트와 CI/CD가 한 파이프라인에 있어 불필요한 테스트 코드 때문에 빌드와 배포가 느려졌다.

이를 분리해 테스트가 통과한 후 머지되면 빌드와 배포가 진행되도록 바꿨고,

배포된 앱의 상태는 Argo CD와 Git으로 관리한다.

접근제어

이전에는 VDI 환경에서 Bastion을 거쳐 EC2/EKS에 접근해야 했는데,

이제는 사내 SSO와 GitHub SSO, 그리고 Teleport를 활용해 접근 제어를 개선했다.

누가 어떤 세션으로 어떤 행위를 했는지 세션 레코딩도 가능해 보안성과 추적성이 좋아졌다.

배치 서버리스화

기존에는 EC2를 24시간 켜두고 에이전트가 배치를 실행하는 구조였는데,

이를 Jenkins와 CodeBuild 기반으로 바꿔 배치 잡이 실행될 때만 서버가 뜨고 끝나면 죽는 서버리스 형태로 개선했다.

여기에 Datadog, Sumo Logic으로 가시성도 확보했다.

ㅁ 마지막 메시지

Agility: 내부 개발자가 빠르게 비즈니스 로직을 바꿀 수 있어야 한다.
Continuity: 큰 변화 없이 지속적으로 개발·배포·모니터링·성능 개선을 이어가야 한다.
Optimization: 성능과 비용을 계속 최적화해야 한다.

이 팀이 원하는 방향은 단발성 대규모 전환이 아니라 지속적으로 진화하는 플랫폼화된 DevOps의 완전체이다.

발표의 마지막 인용문 “완벽함은 더할 것이 없을 때가 아니라 뺄 것이 남지 않을 때 완성된다”는,

복잡한 레거시를 계속 덧붙이는 게 아니라 불필요한 걸 줄이고 단순하게 만드는 현대화의 철학을 강조하면서도,

DevOps 가치를 강조하고 있다.

ㅁ 마무리

[DevOps] DevOps란 무엇입니까?에게 DevOps의 의미를 정리한 적이 있다.

DevOps는 기술적 스팩만을 말하는 것이 아니라 기술을 어떻게 고객의 요구상황에 맞게 빠르고 안전하게 실현하는데 있다. DevOps는 일종의 문화와 철학이며, 이를 이루기 위해 기술적이고 인프라차원의 환경이 필요한 것이다. 실질적인 공유와 협업의 정신을 무시하고 우선적으로 자신의 처지에만 취중할 때에 전체 조직의 퍼포먼스를 줄어들 수 밖에 없다. - 블로그 글 중 -

DevOps는 협업과 통합을 강조하는 개발 문화이자 운영 방식이다. 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

이 동영상에서는 BSS 현대화 과정에서 DevOps의 핵심 원칙과 조직 문화가 실제 업무에 어떻게 적용되는지 잘 보여준 발표였다.

서비스 요구사항을 빠르고 안정적으로 전달하기 위해 DevOps가 어떻게 활용되는지 확인할 수 있었다.

[독후감] 아주 작은 습관의 힘

기록하는 백엔드개발자 — Sun, 2 Aug 2026 23:33:51 +0900

ㅁ 작가에 대한 이해

제임스 클리어(James Clear)는 습관과 행동 변화에 대해 연구하는 작가이자 강연자이다.

그의 특징은 새로운 심리학 이론을 제시하는 사람이 아니라, 심리학·행동경제학·신경과학 등 여러 연구를 종합하여 누구나 실천할 수 있는 행동 시스템으로 정리하는 데 있다.

그가 가장 중요하게 생각하는 것은 목표(Goal)가 아니라 시스템(System)이다.

우리는 흔히 목표를 달성하면 성공한다고 생각하지만, 제임스 클리어는 목표는 방향을 정할 뿐이며 실제 결과를 만드는 것은 매일 반복하는 시스템이라고 말한다.

또 하나의 핵심은 정체성(Identity)이다.

좋은 습관은 억지로 행동을 바꾸는 것이 아니라, '나는 어떤 사람이 되고 싶은가'라는 정체성에서 시작된다. 행동은 정체성을 증명하는 과정이며, 반복될수록 그 정체성은 더욱 강해진다.

결국 제임스 클리어는 사람을 변화시키려는 사람이 아니라, 사람이 자연스럽게 변화할 수 있는 구조를 설계하는 사람에 가깝다.

그래서 이 책은 자기계발서라기보다 행동 설계 매뉴얼이라는 관점으로 읽는 것이 저자의 의도를 이해하는 데 도움이 된다.

ㅁ 이 책을 읽으며

처음에는 습관을 만드는 방법을 알려주는 교양서라고 생각했다.

하지만 구체적인 사례와 행동 변화의 법칙을 따라가며, 일상에서 바로 적용할 수 있는 실천적인 안내서로 읽게 되었다.

작가는 글의 시작에 일화를 예시로 사용하고 있다. 목차의 내용은 작가가 말하려고 하는 핵심적인 주제를 잘 나타내고 있다.
그리고 챕터 마지막에는 썸머리가 있어서 일화와 구체적인 서술, 근거로 이야기 하려던 내용을 한번 더 명확히 정리해 주고 있다.

ㅁ 아주 작은 습관의 힘이란?

'아주 작은 습관의 힘'이라는 제목을 처음 접했을 때는

규칙적인 생활 습관을 만들고, 좋은 습관을 유지하는 방법을 설명하는 교양서라고 생각했다.

하지만 책을 읽으며 생각이 바뀌었다.

제임스 클리어가 말하는 아주 작은 습관의 힘은 단순히 결과를 바꾸는 힘이 아니라, 정체성을 만들어 가는 힘이었다.

우리는 거대한 결심으로 변하는 것이 아니라, 매일 반복하는 작은 행동을 통해 스스로를 만들어 간다.

오늘의 작은 행동 하나가 내일의 정체성을 만들고, 그 정체성이 결국 나의 삶을 결정한다.

그 힘이 바로 아주 작은 습관의 힘이다.

ㅁ 책의 핵심내용 정리

Part 1. 아주 작은 습관이 만드는 극적인 변화

Chapter 01. 아주 작은 습관이 만드는 극적인 변화

핵심 내용

우리는 목표를 이루지 못하는 이유를 의지력이나 능력 부족에서 찾는 경우가 많다.

하지만 저자는 문제의 원인이 목표가 아니라 시스템에 있다고 말한다.

좋은 습관은 생산성을 높이고, 지식을 쌓으며, 더 나은 관계를 만든다.

반대로 나쁜 습관은 스트레스를 쌓고 부정적인 행동을 반복하게 만든다.

목표는 방향을 제시할 뿐 결과를 보장하지 않는다.

원하는 결과를 얻기 위해서는 목표보다 매일 반복할 수 있는 시스템을 만드는 것이 중요하다.

저자가 말하고 싶은 핵심

성공은 목표가 아니라 시스템의 결과다. 인생을 바꾸고 싶다면 목표보다 매일 반복하는 시스템을 먼저 바꿔야 한다.

Chapter 02. 정체성, 사람을 움직이는 가장 큰 비밀

핵심 내용

행동 변화에는 결과 변화, 과정 변화, 정체성 변화의 세 단계가 있다.

대부분의 사람은 결과를 바꾸려고 하지만, 저자는 진정한 변화는 정체성에서 시작된다고 설명한다.

습관은 단순히 행동을 반복하는 것이 아니라 '나는 어떤 사람인가'를 스스로에게 증명하는 과정이다.

반복되는 행동은 정체성을 만들고, 그 정체성은 다시 행동을 강화하는 선순환을 만든다.

습관의 진정한 가치는 더 나은 결과를 얻는 것이 아니라, 자신에 대한 믿음을 변화시키는 데 있다.

저자가 말하고 싶은 핵심

좋은 습관은 원하는 결과를 얻기 위한 수단이 아니라, 원하는 정체성을 만들어 가는 과정이다.

Chapter 03. 무엇이든 쉽게, 재밌게, 단순하게

핵심 내용

습관은 반복을 통해 자동화된 행동이다. 우리의 뇌는 반복되는 행동을 습관으로 만들어 적은 에너지로 문제를 해결하도록 진화했다.

모든 습관은 신호 → 열망 → 반응 → 보상이라는 동일한 과정을 거쳐 형성된다. 이 구조를 이해하면 좋은 습관은 강화하고, 나쁜 습관은 줄일 수 있다.

이후 책에서 설명하는 네 가지 행동 변화 법칙도 이러한 습관 형성 과정을 바탕으로 만들어진 원칙이다.

저자가 말하고 싶은 핵심

모든 습관은 같은 원리로 만들어진다. 그 원리를 이해하면 원하는 습관을 의도적으로 설계할 수 있다.

Part 2. 첫 번째 법칙, 분명해야 달라진다

Chapter 04. 인식해야 변화할 수 있다

핵심 내용

충분히 익숙해진 습관은 뇌가 특정한 결과를 가져올 신호를 자동으로 인식하면서 작동한다. 습관이 자동화되면 행동에 주의를 기울이지 않게 되므로, 변화를 시작하려면 먼저 자신이 어떤 행동을 반복하고 있는지 알아차려야 한다.

행동을 말로 표현하는 '확인하고 외치기'는 무의식적인 습관을 의식의 영역으로 끌어올려 인지 수준을 높여준다. 습관 점수표 역시 현재의 행동을 객관적으로 살펴보게 하는 간단하면서도 효과적인 방법이다.

저자가 말하고 싶은 핵심

좋은 습관을 만들기 위해서는 먼저 자신이 어떤 습관을 가지고 있는지 정확하게 인식해야 한다.

Chapter 05. 아주 구체적으로 쪼개고 붙여라

핵심 내용

첫 번째 행동 변화 법칙은 '분명하게 만들어라'이다. 새로운 습관을 만드는 가장 강력한 신호는 시간과 장소이므로, 실행 의도를 활용해 언제 어디서 무엇을 할지 구체적으로 정해야 한다. 실행 의도의 공식은 '나는 [언제] [어디서] [어떤 행동]을 할 것이다.'이다.

습관 쌓기는 기존 습관 뒤에 새로운 습관을 연결하는 전략이다. '[현재의 습관]을 하고 나서 [새로운 습관]을 할 것이다.'라는 공식으로 표현하면 새로운 행동을 일상의 흐름에 자연스럽게 결합할 수 있다.

저자가 말하고 싶은 핵심

좋은 습관은 막연한 의지가 아니라 구체적인 시간과 장소, 그리고 기존 습관과의 연결을 통해 만들어진다.

Chapter 06. 환경이 행동을 결정한다

핵심 내용

우리가 매일 하는 많은 행동은 목적이나 의지보다 눈에 보이는 환경의 영향을 더 크게 받는다. 습관은 신호에서 시작되므로, 만들고 싶은 습관과 관련된 신호가 눈에 띄지 않으면 행동으로 이어지기 어렵다. 좋은 습관의 신호를 자주 접할 수 있도록 배치하는 작은 환경 변화도 시간이 지나면 행동에 큰 차이를 만든다.

습관은 하나의 사물만이 아니라 행동을 둘러싼 전체 환경과 맥락 속에서 형성된다. 같은 장소도 개인의 기억과 경험에 따라 서로 다른 행동을 유도하며, 기존 신호가 사라진 새로운 환경에서는 새로운 습관을 만들기가 더 쉬워진다.

저자가 말하고 싶은 핵심

환경은 의지보다 강력하다. 행동을 바꾸고 싶다면 자신을 바꾸기보다 환경을 먼저 설계해야 한다.

Chapter 07. 나쁜 습관 피하기 기술

핵심 내용

첫 번째 행동 변화 법칙을 반대로 적용하면 '보이지 않게 하라.'가 된다. 한 번 형성된 습관은 쉽게 사라지지 않기 때문에 나쁜 습관을 유발하는 신호에 노출되는 일을 줄여야 한다.

자제력이 높은 사람은 유혹을 잘 참는 사람이 아니라 유혹이 적은 환경을 선택하는 사람이다. 자제력은 단기적인 전략일 뿐이므로, 장기적인 변화를 위해서는 유혹과 싸우기보다 환경을 바꾸는 편이 효과적이다.

저자가 말하고 싶은 핵심

나쁜 습관과 싸우기보다 나쁜 습관이 시작되는 환경과 신호를 제거하는 것이 훨씬 효과적이다.

Part 3. 두 번째 법칙, 매력적이어야 달라진다

Chapter 08. 왜 어떤 습관은 더 하고 싶을까

핵심 내용

습관은 단순히 행동의 반복으로 만들어지는 것이 아니라, 그 행동이 얼마나 매력적으로 느껴지는지에 따라 형성된다.

사람은 보상을 얻었을 때보다 보상을 기대할 때 더 큰 동기를 느낀다. 이러한 기대는 도파민 분비를 유도하고, 행동을 반복하도록 만든다.

좋은 습관을 만들고 싶다면 '해야 하는 일'을 '하고 싶은 일'과 연결해야 한다. 저자는 이를 유혹 묶기(Temptation Bundling) 전략이라고 설명한다.

저자가 말하고 싶은 핵심

사람은 필요한 행동보다 하고 싶은 행동을 선택한다. 좋은 습관도 매력적으로 느껴질 때 지속될 수 있다.

Chapter 09. 왜 주위 사람에 따라 내 습관이 변할까

핵심 내용

우리가 어떤 행동을 선택하는지는 개인의 의지보다 자신이 속한 문화와 집단의 영향을 크게 받는다.

사람은 가족과 친구, 자신이 속한 다수의 집단, 그리고 존경하는 사람들의 행동을 자연스럽게 모방한다.

좋은 습관을 만들고 싶다면 의지만 키우는 것이 아니라, 원하는 행동이 자연스러운 문화와 환경 속으로 들어가는 것이 중요하다.

저자가 말하고 싶은 핵심

습관은 혼자 만드는 것이 아니다. 내가 속한 환경과 문화가 결국 나의 행동을 결정한다.

Chapter 10. 나쁜 습관도 즐겁게 고칠 수 있을까

핵심 내용

나쁜 습관을 없애려면 두 번째 행동 변화 법칙을 반대로 적용해야 한다. 즉, 매력적이지 않게 만들어야 한다.

모든 행동은 표면적인 욕구보다 더 근본적인 욕망을 해결하기 위해 일어난다. 같은 욕망이라도 어떤 의미를 부여하느냐에 따라 좋은 습관이 될 수도, 나쁜 습관이 될 수도 있다.

나쁜 습관을 하지 않았을 때 얻는 이점을 떠올리고, 좋은 습관을 시작하기 전에 긍정적인 감정을 만들어 주는 의식을 더하면 행동을 지속하기 쉬워진다.

저자가 말하고 싶은 핵심

습관은 감정과 연결된다. 좋은 습관에는 긍정적인 의미를 부여하고, 나쁜 습관에는 부정적인 의미를 연결해야 행동이 변화한다.

Part 4. 세 번째 법칙, 쉬워야 달라진다

Chapter 11. 1만 시간의 법칙은 틀렸다

핵심 내용

우리는 흔히 많은 시간을 투자해야 습관이 만들어진다고 생각한다. 하지만 저자는 시간보다 반복 횟수가 더 중요하다고 말한다.

습관은 행동을 반복하는 과정에서 점차 자동화된다. 계획을 세우는 것보다 직접 실행하는 경험이 습관을 만드는 데 훨씬 효과적이다.

결국 습관은 얼마나 오래 했는지가 아니라, 얼마나 자주 반복했는지가 결정한다.

저자가 말하고 싶은 핵심

습관은 시간을 투자한다고 만들어지는 것이 아니라, 반복을 통해 몸에 익을 때 비로소 만들어진다.

Chapter 12. 웬만하면 쉽게 갑시다

핵심 내용

인간은 본능적으로 가장 적은 노력이 드는 선택을 한다. 따라서 좋은 습관도 어렵게 만들면 지속되기 어렵다.

좋은 습관을 만들고 싶다면 행동의 마찰을 줄이고, 나쁜 습관을 줄이고 싶다면 마찰을 늘려야 한다.

환경을 조금만 바꾸어도 원하는 행동을 훨씬 쉽게 반복할 수 있다.

저자가 말하고 싶은 핵심

의지력을 키우기보다 좋은 행동은 쉽게, 나쁜 행동은 어렵게 만드는 환경을 설계해야 한다.

Chapter 13. 변화를 위한 최소한의 시간

핵심 내용

큰 변화는 거창한 시작이 아니라 아주 작은 행동에서 시작된다.

저자는 새로운 습관을 시작할 때 2분 규칙을 제안한다. 어떤 습관이든 처음에는 2분 안에 끝낼 수 있을 만큼 작게 시작해야 한다.

작은 행동이라도 반복되면 습관이 되고, 그 습관이 더 큰 행동으로 자연스럽게 확장된다.

저자가 말하고 싶은 핵심

좋은 습관은 크게 시작하는 것이 아니라, 실패할 수 없을 만큼 작게 시작해야 오래 지속된다.

Chapter 14. 그들은 어떻게 나쁜 습관을 버리는가

핵심 내용

세 번째 행동 변화 법칙을 반대로 적용하면 '하기 어렵게 만들어라.'가 된다.

나쁜 습관을 없애기 위해서는 의지력보다 행동 자체를 어렵게 만드는 장치가 필요하다.

자동이체, 자동 저축처럼 한 번의 선택으로 미래의 행동을 자동화하면 좋은 습관은 유지되고 나쁜 습관은 줄어든다.

저자가 말하고 싶은 핵심

좋은 습관은 자동화하고, 나쁜 습관은 실행하기 어렵게 만들어야 행동이 자연스럽게 변화한다.

Part 5. 네 번째 법칙, 만족스러워야 달라진다

Chapter 15. 재미와 보상 두 마리 토끼를 잡는 법

핵심 내용

좋은 습관은 시작하는 것보다 계속 유지하는 것이 더 어렵다.

저자는 습관을 지속시키는 가장 중요한 요소를 즉각적인 만족감이라고 설명한다.

인간은 장기적인 보상보다 지금 당장의 보상을 우선하도록 진화했다.

따라서 좋은 습관도 즉시 성취감을 느낄 수 있어야 반복될 가능성이 높아진다.

보상은 습관을 시작하게 만들고, 정체성은 습관을 지속하게 만든다. 작은 성공을 자주 경험할수록 습관은 자연스럽게 삶의 일부가 된다.

저자가 말하고 싶은 핵심

좋은 습관은 미래의 보상만으로 유지되지 않는다. 지금 이 순간의 작은 만족감이 반복을 만든다.

Chapter 16. 어떻게 매일 반복할 것인가

핵심 내용

습관은 꾸준함에서 완성된다. 저자는 이를 위해 습관 추적(Habit Tracking)을 제안한다.

달력에 표시를 하거나 기록을 남기는 단순한 행동만으로도 자신의 성장을 눈으로 확인할 수 있고, 이는 반복하려는 동기가 된다.

완벽하게 지키는 것보다 중요한 것은 흐름을 끊지 않는 것이다.

하루를 놓쳤다면 가능한 한 빨리 원래의 습관으로 돌아와야 한다.

저자가 말하고 싶은 핵심

꾸준함은 완벽함에서 나오는 것이 아니라, 중단하더라도 다시 시작하는 데서 만들어진다.

Chapter 17. 누군가 당신을 지켜보고 있다

핵심 내용

네 번째 행동 변화 법칙을 반대로 적용하면 '불만족스럽게 만들어라.'가 된다.

나쁜 습관에 즉각적인 대가가 따른다면 그 행동은 자연스럽게 줄어든다.

습관 계약이나 책임 파트너처럼 자신의 행동을 다른 사람에게 공개하면 책임감이 생기고, 약속을 지키려는 동기가 커진다.

저자가 말하고 싶은 핵심

사람은 혼자 있을 때보다 누군가에게 책임을 질 때 행동을 더 잘 유지한다. 좋은 습관은 책임감을 통해 더욱 강해진다.

Part 6. 최고의 습관은 어떻게 만들어지는가

Chapter 18. 습관에도 적성이 있다

핵심 내용

좋은 습관이라고 해서 모두에게 같은 효과를 내는 것은 아니다. 자신의 성향과 강점에 맞는 습관을 선택해야 꾸준히 지속할 수 있다.

유전자는 바꿀 수 없지만, 자신에게 유리한 환경을 선택하는 것은 가능하다. 자신의 강점이 자연스럽게 발휘되는 분야를 선택하면 습관을 만드는 과정도 훨씬 수월해진다.

중요한 것은 다른 사람을 따라 하는 것이 아니라, 자신에게 가장 잘 맞는 방식을 찾는 것이다.

저자가 말하고 싶은 핵심

좋은 습관은 남을 따라 하는 것이 아니라, 자신의 강점과 환경에 맞게 선택할 때 가장 오래 지속된다.

Chapter 19. 계속 해내는 힘은 어디서 오는가

핵심 내용

습관을 오래 유지하는 가장 큰 적은 실패가 아니라 지루함이다.

사람은 자신의 능력보다 조금 어려운 과제를 수행할 때 가장 큰 동기를 느낀다. 이를 저자는 골디락스 법칙으로 설명한다.

전문가와 아마추어의 차이는 재능이 아니라, 흥미가 사라진 뒤에도 꾸준히 반복하는 능력에 있다.

저자가 말하고 싶은 핵심

누구나 의욕이 있을 때는 행동한다. 진짜 차이는 지루한 순간에도 계속 반복하는 사람에게서 만들어진다.

Chapter 20. 습관의 반격

핵심 내용

습관은 행동을 자동화한다는 장점이 있지만, 익숙함 때문에 자신의 행동을 돌아보지 않게 만든다는 단점도 있다.

습관만 반복한다고 성장하는 것은 아니다. 습관에 의도적인 연습과 성찰이 더해질 때 비로소 실력이 향상된다.

또한 하나의 정체성에만 지나치게 집착하면 새로운 변화와 성장을 받아들이기 어려워질 수 있다. 습관을 만들었다면 꾸준히 점검하고 수정하는 과정도 필요하다.

저자가 말하고 싶은 핵심

습관은 끝이 아니라 시작이다. 지속적인 성찰과 개선이 더해질 때 습관은 성장으로 이어진다.

ㅁ 좋은 습관을 만드는 4가지 법칙

(p268의 내용을 가져왔습니다.)

첫 번째 법칙 · 분명하게 만들어라

습관 점수표를 활용하여 현재 습관을 인식한다.
실행 의도를 사용한다.
습관 쌓기를 활용한다.
좋은 습관의 신호가 잘 보이도록 환경을 설계한다.

두 번째 법칙 · 매력적으로 만들어라

유혹 묶기를 활용한다.
원하는 행동을 주변의 일반적인 행동으로 만든다.
동기 부여 의식을 활용한다.

세 번째 법칙 · 하기 쉽게 만들어라

좋은 습관의 마찰을 줄인다.
좋은 습관이 일어나기 쉬운 환경을 만든다.
결정적 순간을 잘 활용한다.
2분 규칙으로 시작한다.
습관을 자동화한다.

네 번째 법칙 · 만족스럽게 만들어라

즉시 보상받을 수 있도록 만든다.
나쁜 습관을 피할 방법을 미리 준비한다.
습관 추적을 한다.
두 번 연속 거르지 않는다.

ㅁ 나쁜 습관을 버리는 4가지 법칙

첫 번째 법칙

보이지 않게 만들어라.

두 번째 법칙

매력적이지 않게 만들어라.

세 번째 법칙

하기 어렵게 만들어라.
이행 장치로 미래의 선택을 제한한다.

네 번째 법칙

불만족스러운 것으로 만들어라.
책임 파트너와 습관 계약을 활용한다.

ㅁ 마무리

『아주 작은 습관의 힘』은 단순히 좋은 습관을 만드는 방법을 설명하는 책이 아니었다.

처음에는 규칙적인 생활과 자기관리를 위한 교양서라고 생각했지만,

책을 읽을수록 저자가 말하고 싶은 핵심은 '어떤 사람이 될 것인가'라는 질문에 있다는 것을 알게 되었다.

제임스 클리어는 결과보다 시스템을, 시스템보다 정체성을 중요하게 생각한다.

작은 행동 하나가 반복되면 습관이 되고, 습관은 정체성을 만들며, 정체성은 결국 삶의 방향을 결정한다.

그래서 변화는 거대한 결심에서 시작되는 것이 아니라, 오늘 반복한 아주 작은 행동에서 시작된다.

또한 이 책은 의지력에만 의존하지 않는다.

환경을 설계하고, 행동의 마찰을 줄이며, 작은 성공을 반복할 수 있는 시스템을 만드는 것이 더 중요하다고 이야기한다.

결국 좋은 습관은 의지가 아니라 설계의 결과라는 점이 인상 깊었다.

책을 덮고 나니 '나는 어떤 습관을 가져야 하는가'보다 '나는 어떤 사람이 되고 싶은가'를 먼저 고민하게 되었다.

원하는 정체성이 분명해질수록 어떤 습관을 반복해야 하는지도 자연스럽게 결정될 것이라는 생각이 들었다.

결국 『아주 작은 습관의 힘』은 습관에 관한 책이 아니라,
반복되는 작은 행동을 통해 자신만의 정체성을 만들어 가고,
자신다운 삶을 살아가기 위한 행동 설계 매뉴얼이었다.

[생각] 공정은 법을 적용하는 것이 아니라 공동체를 살리는 것이다 - 아피케이아(Epieikeia)

기록하는 백엔드개발자 — Fri, 31 Jul 2026 20:41:40 +0900

ㅁ 들어가며

회사에서 윤리위원이라는 역할을 맡게 되면서 자연스럽게 '공정'이라는 단어를 다시 생각하게 되었다.

처음에는 공정이란 규정을 동일하게 적용하는 것이라고 생각했다.

누가 잘못했는지 판단하고,
규정에 맞게 결론을 내리는 것.

그것이 가장 공정한 일이라고 믿었다.

하지만 여러 철학과 사례를 접하면서 생각이 조금씩 바뀌기 시작했다.

과연 법을 가장 정확하게 적용하는 것이 공정일까.

아니면

공동체를 가장 건강하게 만드는 판단이 공정일까.

이 질문은 나를 아리스토텔레스의 아피케이아(Epieikeia)라는 개념으로 이끌었다.

ㅁ 아피케이아(Epieikeia)란 무엇인가

아리스토텔레스는 법이 아무리 잘 만들어져도 모든 상황을 예측할 수는 없다고 보았다.

법은 일반적인 상황을 기준으로 만들어진다.

그러나 현실은 언제나 예외로 가득하다.

그래서 그는 훌륭한 판단은 법을 무시하는 것이 아니라,

법이 존재하는 목적을 실현하는 것이라고 설명했다.

이것이 바로 아피케이아다.

아피케이아는 법을 약하게 만드는 개념이 아니다.

오히려 법을 인간답게 만드는 마지막 덕목이다.

ㅁ 법은 목적이 아니라 수단이다

우리는 종종 법과 규정을 절대적인 기준으로 생각한다.

물론 규정은 공동체를 유지하기 위한 최소한의 약속이다.

하지만 규정이 존재하는 이유는 사람을 지키기 위해서다.

규정을 지키는 것이 목적이 되어버리면,

어느 순간 공동체보다 절차가 중요해지고,

사람보다 규정이 우선하게 된다.

그때부터 공정은 정의가 아니라 형식이 된다.

ㅁ 윤리위원에게 필요한 것은 판단보다 지혜다

윤리위원의 역할은 법률가와 다르다.

법률은 위법 여부를 판단하지만,

윤리는 공동체가 앞으로 어떻게 살아갈 것인가를 고민한다.

그래서 윤리위원은 단순히

"누가 잘못했는가."

만을 묻는 사람이 아니라,

"왜 이런 일이 발생했는가."

그리고

"어떻게 하면 같은 일이 반복되지 않을 것인가."

를 함께 고민해야 한다.

징계가 필요한 경우도 있다.

하지만 모든 갈등의 해답이 징계일 수는 없다.

갈등의 원인을 제거하지 못한다면,

사람만 바뀔 뿐 같은 문제는 다시 발생한다.

ㅁ 공정은 공동체를 회복시키는 힘이다

성경 속 솔로몬의 재판은 유명하다.

사람들은 솔로몬이 어려운 판결을 내렸다고 기억하지만,

본질은 다른 곳에 있다.

솔로몬은 법 조항을 찾은 것이 아니라,

무엇이 생명을 살리는 판단인지를 보았다.

공정도 마찬가지다.

공정은 가장 엄격한 처벌을 내리는 능력이 아니다.

공동체의 신뢰를 회복하고,

사람들이 다시 함께 살아갈 수 있도록 만드는 판단이다.

그 과정에서 법은 중요한 기준이 된다.

그러나 법은 언제나 공동체를 위한 도구여야 한다.

ㅁ 마무리

오늘날 우리는 공정을 이야기할 때 너무 쉽게 '법대로'를 떠올린다.

하지만 법은 공정의 출발점일 뿐, 목적지는 아니다.

공정의 목적지는 공동체다.

공동체를 살리는 판단.

사람을 회복시키는 판단.

그리고 법이 만들어진 이유를 끝까지 지켜내려는 지혜.

나는 그것이 아리스토텔레스가 말한 아피케이아이며,

오늘날 윤리위원에게 가장 필요한 덕목이라고 생각한다.

결국 진정한 공정은
법을 가장 잘 적용하는 사람이 아니라,
공동체를 가장 오래 건강하게 만드는 사람이 만들어 가는 것인지도 모른다.

[Network] 27. 편지 한 통의 여정을 혼자 설명할 수 있을까?

기록하는 백엔드개발자 — Wed, 29 Jul 2026 22:27:43 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — 에필로그. 우리는 인터넷이 아니라 물류 시스템을 이해했다

ㅁ 들어가며

Browser의 주소창에 URL 하나를 입력했다.

https://server.example/orders

잠시 뒤 주문 목록이 화면에 나타났다.

우리는 흔히 이 짧은 사건을 이렇게 말한다.

Client가 Server에 접속했다.

그러나 그 한 문장 안에서는 수많은 결정이 일어났다.

이름을 어느 IP 주소로 바꿀지 정했다.
목적지가 같은 동네인지 다른 동네인지 판단했다.
다음 전달자의 MAC 주소를 알아냈다.
Switch와 Router가 각자의 표를 보고 다음 길을 골랐다.
사설 주소를 공인 주소와 Port의 조합으로 바꾸었다.
상대와 연결을 만들고, 암호화할 상대가 맞는지 확인했다.
사라진 Data를 다시 보내고, 받는 쪽과 길의 형편에 맞춰 속도를 조절했다.
돌아온 응답을 원래 요청한 Process와 Browser Tab에 전달했다.

이 가운데 어느 하나만 빠져도 화면에는 그저 timeout이나 연결 오류가 나타날 수 있다.

그렇다면 지금까지 배운 용어를 외우지 않고도, 이 편지 한 통의 여정을 처음부터 끝까지 자기 언어로 설명할 수 있을까?

이번 글에서는 새로운 Protocol을 배우지 않는다.

지금까지 흩어져 있던 DNS, ARP, Switch, Routing, TTL, MTU, NAT, Firewall, TCP, TLS, HTTP를 하나의 시간 순서로 다시 잇는다.

이 연재의 마지막 질문은 무엇이 동작했는가가 아니다.

각 기술이 왜 그 자리에 있어야 했는가다.

ㅁ 한 통의 편지를 끝까지 따라가기 위한 약속

하나의 흐름을 놓치지 않도록 다음 환경을 사용한다.

역할	값
Client	192.168.10.20
Client가 선택한 Source Port	51514
DNS Resolver	192.168.10.53
Default Gateway	192.168.10.1
NAT 장비의 공인 IP	203.0.113.5
NAT가 바꾼 Source Port	40001
Web Server	198.51.100.20
Web Service Port	443/TCP
URL	https://server.example/orders

192.168.10.0/24는 사설 주소 대역이고,

198.51.100.0/24와 203.0.113.0/24는 문서 예시를 위해 예약된 주소 대역이다.

실제 인터넷 Service를 뜻하지 않는다.

설명을 단순하게 만들기 위해 IPv4를 중심으로 따라간다.

IPv6에서는 Broadcast 기반 ARP 대신 ICMPv6의 Neighbor Discovery Protocol,

즉 NDP가 이웃과 Router를 찾고,

일반적으로 IPv4 주소 공유를 위한 NAT와는 다른 방식으로 주소를 사용한다.

또 하나 기억할 점이 있다.

Application은 처음부터 완성된 "편지 한 통"을 Network에 던지지 않는다.

각 계층은 자기 역할에 필요한 Header를 붙이고, 반대편은 이를 차례로 해석한다.

HTTP Message
  ↓ TLS로 보호
TLS Record
  ↓ TCP가 순서와 신뢰성 정보 추가
TCP Segment
  ↓ IP가 출발지와 최종 목적지 정보 추가
IP Packet
  ↓ Ethernet이 현재 Link의 전달자 정보 추가
Ethernet Frame
  ↓
Bit와 Signal

우편 비유의 편지는 하나처럼 보이지만,

실제 Network에는 계층별 Header와 여러 Packet이 있다.

DNS Query, ARP Request, TCP Handshake, TLS Handshake까지 포함하면

HTTP Request 하나를 보내기 전에도 이미 여러 번의 통신이 오간다.

ㅁ 1단계: Browser는 URL에서 먼저 무엇을 꺼낼까?

Browser가 받은 것은 IP 주소가 아니라 URL이다.

https://server.example/orders

Browser는 이 문자열을 적어도 다음 요소로 나눈다.

URL 요소	값	의미
Scheme	https	어떤 방식으로 통신할지
Host	server.example	어느 Host를 찾을지
Port	생략됨, 기본값 443	어느 Service와 대화할지
Path	/orders	Service 안의 어느 Resource를 요청할지

우편 주소로 보면 나라와 도시, 건물, 부서를 나누는 일과 비슷하다.

하지만 실제 기술에서 이 값들은 서로 다른 계층의 결정에 쓰인다.

Host 이름은 DNS 조회의 입력이 된다.
443은 TCP Destination Port가 된다.
/orders는 TCP 연결이 만들어지고 TLS가 준비된 뒤 HTTP Request에 담긴다.

즉 /orders를 Router가 보고 길을 고르는 것이 아니다.

Router는 일반적으로 URL Path를 알지 못하며 IP Header를 중심으로 전달을 결정한다.

첫 번째로 필요한 것은 server.example이라는 이름을 숫자 주소로 바꾸는 일이다.

ㅁ 2단계: 이름은 어떻게 `198.51.100.20`이 될까?

사람은 이름을 기억하기 쉽지만, IP 계층은 Destination IP 주소가 있어야 Packet을 보낼 수 있다.

그래서 Host는 먼저 가까운 기억을 확인한다.

Browser DNS Cache
    ↓ 없으면
Operating System Cache와 Hosts 설정
    ↓ 없으면
설정된 DNS Resolver

Cache에 유효한 Answer가 없다면 Client는 설정된 Resolver 192.168.10.53에 질문한다.

server.example의 A Record는 무엇입니까?

Resolver는 자신의 Cache를 확인하고, 필요하다면 DNS 계층을 따라 권한 있는 Name Server의 Answer를 찾아 다음과 같이 돌려준다.

server.example.  300  IN  A  198.51.100.20

여기서 300은 이 Answer를 무조건 영원히 기억하라는 뜻이 아니다.

TTL 300초 동안 Cache할 수 있다는 뜻이다. DNS의 TTL은 IP Header의 TTL과 이름은 같지만 역할이 다르다.

같은 이름	실제 역할
DNS TTL	Record를 Cache할 수 있는 시간
IP TTL	Packet이 통과할 수 있는 Router 수의 한계

A Record는 IPv4 주소를, AAAA Record는 IPv6 주소를 제공한다.

여러 주소가 돌아오면 Client는 주소 Family, 도달 가능성, 정책과 구현에 따라 연결 후보와 시도 순서를 정할 수 있다.

DNS는 공용 주소록과 닮았지만, 종이 주소록처럼 단순한 한 권의 책은 아니다.

분산된 권한과 Cache로 규모를 감당하는 이름 체계다.

그리고 DNS Query 자체도 Network Packet이다.

Resolver가 같은 Subnet에 있다면 곧 살펴볼 Route 판단과 ARP가 DNS Query를 보낼 때도 먼저 필요하다.

여정은 완전히 일직선인 목록이 아니라, 작은 여정이 큰 여정 안에 중첩된 구조다.

이 단계가 해결한 문제는 사람이 숫자 주소를 모두 기억하지 않고도 목적지를 찾는 확장성이다.

ㅁ 3단계: 목적지를 알았으면 어느 문으로 내보낼까?

이제 Operating System은 목적지 198.51.100.20을 안다.

하지만 IP 주소만 안다고 바로 Signal을 보낼 수 있는 것은 아니다. 먼저 자신의 Routing Table을 조회해야 한다.

간단한 Table이 다음과 같다고 해 보자.

192.168.10.0/24 dev eth0  src 192.168.10.20
default via 192.168.10.1 dev eth0

Operating System은 Destination과 가장 길게 일치하는 Prefix를 고른다.

이것이 Longest Prefix Match, 최장 접두사 일치다.

198.51.100.20은 192.168.10.0/24에 속하지 않는다.

더 구체적인 Route도 없으므로 default Route가 선택된다.

그 결과는 다음과 같다.

Source IP    192.168.10.20
Destination  198.51.100.20
Egress       eth0
Next Hop     192.168.10.1

여기서 중요한 구분이 생긴다.

최종 목적지 IP는 198.51.100.20이다.
지금 Link에서 건넬 상대는 Gateway 192.168.10.1이다.

먼 지역으로 가는 편지에도 봉투에는 최종 수신인의 주소를 쓴다.

다만 집 앞에서는 그 편지를 가까운 우체국에 맡긴다.

Default Gateway는 모든 목적지를 직접 아는 마법의 장비가 아니다.

더 구체적인 Route가 없을 때 선택한 다음 전달자다.

이 단계가 해결한 문제는 모든 Host가 인터넷의 모든 길을 기억하지 않고도 먼 목적지로 출발할 수 있게 하는 확장성이다.

ㅁ 4단계: Gateway의 IP만 알면 Frame을 보낼 수 있을까?

Ethernet Link에서 Frame을 보내려면 Destination MAC 주소가 필요하다.

Client는 자신의 Neighbor Table에서 192.168.10.1에 대응하는 MAC 주소를 찾는다.

유효한 항목이 없다면 ARP Request를 Broadcast한다.

누가 192.168.10.1을 사용하고 있습니까?
192.168.10.20에게 알려 주십시오.

같은 Broadcast Domain의 장비들은 Request를 받을 수 있지만, 192.168.10.1을 가진 Gateway가 Reply한다.

192.168.10.1은 02:00:00:00:10:01입니다.

Client는 이 대응 관계를 Neighbor Table에 일정 시간 저장한다.

192.168.10.1 → 02:00:00:00:10:01

이제 첫 Ethernet Frame의 주소를 채울 수 있다.

Header	출발지	목적지
Ethernet	Client MAC	Gateway MAC
IPv4	192.168.10.20	198.51.100.20
TCP	51514	443

Client는 먼 Server의 MAC 주소를 ARP로 묻지 않는다.

ARP는 같은 L2 범위에서 지금 직접 건넬 이웃을 찾기 때문이다.

우편 비유에서 ARP는 같은 동네의 실제 집을 찾는 주소 조회와 비슷하다.

그러나 실제 ARP는 사람의 이름을 IP로 바꾸는 DNS가 아니라,

같은 Link에서 Next-Hop IPv4 주소를 MAC 주소에 대응시키는 Protocol이다.

이 단계가 해결한 문제는 논리적 IP 목적지를 실제 Local Link 전달에 필요한 주소와 연결하는 일이다.

ㅁ 5단계: Switch는 Server까지의 길을 알고 있을까?

Client가 Frame을 내보내면 Switch가 받는다.

Switch는 Frame의 Source MAC을 보고 다음 사실을 학습한다.

Client MAC은 이 Port 뒤에 있다.

그리고 Destination MAC, 즉 Gateway MAC을 MAC Address Table에서 조회한다.

Entry가 있으면 해당 Port로 전달한다.
Entry가 없으면 같은 VLAN의 다른 Port로 Unknown Unicast Flooding한다.
Broadcast인 ARP Request는 같은 VLAN의 Broadcast Domain에 Flooding한다.

Switch는 198.51.100.20으로 가는 인터넷 Route를 고르는 장비가 아니다.

이 시점의 Switch가 관심을 갖는 주소는 현재 Ethernet Frame의 Destination MAC이다.

VLAN이 있다면 하나의 물리 Switch도 여러 Broadcast Domain으로 나뉜다.

서로 다른 VLAN 사이의 통신에는 L3 Routing이 필요하다.

또한 이중화 Link가 Layer 2에서 원을 만들면 Broadcast와 Unknown Unicast가 끝없이 복제될 수 있다.

STP 계열 Protocol은 일부 Link를 논리적으로 차단해 Loop 없는 전달 구조를 만든다.

Switch, VLAN, STP가 함께 해결한 문제는

하나의 가까운 길을 많은 장비가 공유하면서도 Frame을 필요한 방향으로 보내고 Loop를 막는 일이다.

ㅁ 6단계: Router는 봉투를 그대로 다음 우체국에 넘길까?

Gateway는 자신의 MAC 주소로 온 Frame을 받고 Ethernet Header를 벗겨 IP Packet을 확인한다.

Destination IP는 여전히 198.51.100.20이다.

Router는 자신의 Routing Table에서 다시 Longest Prefix Match를 수행해 다음 Hop과 Egress Interface를 선택한다.

이때 Router는 IP TTL을 1 줄인다.

TTL 64 → TTL 63

IPv4 Header가 바뀌었으므로 Header Checksum도 다시 계산한다.

TTL이 0이 되면 Router는 Packet을 폐기하고, 일반적으로 출발지에 ICMP Time Exceeded 메시지를 보낸다.

이것은 잘못된 Route가 원을 그릴 때 Packet이 Network 자원을 영원히 소비하지 않게 하는 안전장치다.

다음 Link로 내보낼 때 Router는 이전 Ethernet Frame을 그대로 재사용하지 않는다.

다음 Hop의 MAC 주소를 ARP로 확인한 뒤 새 Ethernet Header를 만든다.

첫 번째 Link
Client MAC → Gateway LAN MAC

두 번째 Link
Gateway WAN MAC → ISP Next-Hop MAC

우편 봉투를 통째로 새 봉투에 넣는다고 상상할 수 있지만, 비유의 경계를 분명히 해야 한다.

실제로는 각 L2 Link에 맞는 Frame Header가 매 Hop 새로 만들어지고, 그 안의 IP Packet은 Route를 따라 전달된다.

Router가 해결한 문제는 각 장비가 전체 경로가 아니라 다음 길만 골라도 멀리 확장할 수 있게 하는 일이다.

ㅁ 7단계: 소포가 다음 길보다 크다면 어떻게 될까?

Route가 있다고 모든 크기의 Packet이 그대로 지나갈 수 있는 것은 아니다.

각 Link에는 한 Frame이 실을 수 있는 IP Packet 크기의 한계인 MTU가 있다.

Ethernet에서 흔히 보는 값은 1500 bytes지만, Tunnel이나 다른 Link를 지나면 더 작을 수 있다.

IPv4 Packet이 Egress MTU보다 크면 조건에 따라 다음 중 하나가 일어난다.

Fragmentation이 허용되면 Router 또는 출발지가 Packet을 여러 Fragment로 나눈다.
DF, Don't Fragment가 설정되어 있으면 Router는 Packet을 버리고 ICMP Fragmentation Needed를 보낸다.

출발지는 이 정보를 이용해 경로에서 통과 가능한 크기를 알아내고 Packet 크기를 조절할 수 있다.

이것이 Path MTU Discovery, PMTUD다.

TCP는 보통 Interface MTU와 협상한 MSS를 고려해 Segment의 Payload 크기를 정한다.

MSS는 TCP Payload의 최대 크기에 관한 값이고, MTU는 Link가 실을 수 있는 IP Packet 전체 크기에 관한 값이다.

ICMP가 무조건 불필요한 Traffic이라며 중간에서 사라지면 작은 Request는 성공하지만

큰 TLS Record나 Response만 멈추는 PMTUD Black Hole이 생길 수 있다.

이 단계가 해결하려는 문제는 서로 다른 크기의 길을 지나는 동안 자원을 낭비하지 않고 전달 가능한 크기를 찾는 효율이다.

ㅁ 8단계: 사설 주소는 인터넷에서 어떻게 돌아올 주소가 될까?

Client의 Source IP 192.168.10.20은 사설 주소다.

Public Internet의 Router가 이 주소를 전 세계의 고유 목적지로 전달하지 않는다.

경계의 NAT 장비는 Packet이 밖으로 나갈 때 Source를 바꾼다.

변환 전
192.168.10.20:51514 → 198.51.100.20:443

변환 후
203.0.113.5:40001 → 198.51.100.20:443

주소뿐 아니라 Port까지 바꾸어 여러 내부 연결을 구분하는 동작을 흔히 NAPT 또는 PAT라고 부른다.

일상적으로는 이를 포함해 NAT라고 말하는 경우가 많다.

NAT 장비는 다음과 같은 Mapping State를 기억한다.

TCP 203.0.113.5:40001 ↔ 192.168.10.20:51514
Remote Peer: 198.51.100.20:443

IP 주소나 TCP Port가 바뀌면 해당 값을 포함해 계산한 Checksum도 맞게 갱신해야 한다.

Server의 Reply는 다음 주소로 돌아온다.

198.51.100.20:443 → 203.0.113.5:40001

NAT 장비는 저장한 State를 찾아 Destination을 원래 Client로 되돌린다.

198.51.100.20:443 → 192.168.10.20:51514

NAT는 여러 집이 하나의 공인 주소를 함께 쓰게 해 IPv4 주소 부족을 견디는 데 큰 역할을 했다. 이것은 공유의 해법이다.

그러나 NAT가 보안을 자동으로 완성하는 것은 아니다. State에 없는 외부 연결이 안쪽으로 들어오기 어려운 현상과 명시적인 Security Policy는 구분해야 한다.

또한 NAT가 있는 구간에서는 IP 주소와 Port가 End-to-End로 완전히 동일하게 유지되지 않는다. 장애를 분석할 때 안쪽 Capture와 바깥쪽 Capture의 5-Tuple이 달라지는 이유다.

ㅁ 9단계: Firewall은 주소만 보고 문을 열까?

경계에는 NAT와 별개로 Firewall Policy가 적용될 수 있다.

기본적인 Rule은 다음 정보를 기준으로 허용하거나 차단할 수 있다.

Source와 Destination IP
Protocol
Source와 Destination Port
Ingress와 Egress Interface 또는 Zone
연결 상태

Stateful Firewall은 TCP Packet 하나만 고립해서 보지 않고,

이 Packet이 새 연결을 시작하는지 이미 허용된 연결의 일부인지 추적한다.

Linux 환경에서는 이 상태 추적을 Conntrack과 연결해 관찰할 수 있다.

NEW → ESTABLISHED → FIN/종료 또는 Timeout

우편 보안실이 발신지와 수신 부서, 현재 진행 중인 방문인지 확인하는 모습과 닮았다.

하지만 Firewall이 443/TCP를 허용했다는 사실은 다음을 보장하지 않는다.

Server Process가 실제로 Listen 중인지
TLS Certificate가 올바른지
HTTP 요청 권한이 있는지
응답이 정상인지

Firewall은 통신을 허용할지 결정한다.

TLS는 상대와 내용의 신뢰를 다루고, Application 인증은 사용자가 무엇을 할 수 있는지 결정한다.

서로 다른 문이다.

ㅁ 10단계: TCP는 왜 Data부터 보내지 않을까?

Route와 Policy를 통과할 수 있게 되었지만, Client는 곧바로 HTTP Request부터 보내지 않는다.

Server의 443/TCP와 신뢰성 있는 Byte Stream을 만들기 위해 TCP Three-Way Handshake를 수행한다.

설명을 위해 Client의 초기 Sequence Number를 1000, Server의 초기 Sequence Number를 7000이라고 하자.

Client → Server  SYN      Seq=1000
Server → Client  SYN-ACK  Seq=7000 Ack=1001
Client → Server  ACK      Seq=1001 Ack=7001

세 번의 교환에는 각각 이유가 있다.

Client가 Server에 도달할 수 있고 연결 의사가 있음을 알린다.
Server가 Client의 요청을 받았고, 반대 방향으로도 도달할 수 있음을 알린다.
Client가 Server의 응답까지 받았음을 확인한다.

SYN과 FIN은 Sequence Number 공간에서 1을 소비한다. 그래서 SYN Seq=1000에 대한 확인은 Ack=1001이다.

TCP 연결은 단순히 "두 IP가 연결되었다"고만 구분하지 않는다. 일반적으로 다음 5-Tuple로 흐름을 식별한다.

Protocol, Source IP, Source Port, Destination IP, Destination Port

NAT 안쪽에서 보면 다음 흐름이다.

TCP, 192.168.10.20, 51514, 198.51.100.20, 443

NAT 바깥에서는 다음처럼 보인다.

TCP, 203.0.113.5, 40001, 198.51.100.20, 443

Port 덕분에 한 Host의 여러 Process와 여러 연결이 같은 IP 주소를 함께 쓸 수 있다.

이것도 제한된 주소와 경로를 함께 쓰는 공유의 장치다.

ㅁ 11단계: Handshake 뒤에는 무엇이 신뢰를 만들까?

TCP Handshake가 끝났다고 이후 Data가 사라지지 않는 것은 아니다.

IP Network는 Packet의 전달, 순서와 중복 제거를 완전히 보장하지 않는다.

TCP는 여러 약속을 조합해 Application에 순서 있는 Byte Stream을 제공한다.

ㅇ Sequence Number

각 Byte의 위치를 나타낸다. Segment가 순서가 바뀌어 도착해도 어느 자리에 놓을지 판단할 수 있다.

ㅇ Acknowledgment

수신자가 다음에 기대하는 Byte를 알린다. Ack=2501은 일반적으로 2500까지 연속해서 받았고 다음은 2501이라는 뜻이다.

ㅇ Retransmission

ACK가 정해진 시간 안에 오지 않거나 중복 ACK 같은 손실 단서가 생기면 필요한 Data를 다시 보낸다.

ㅇ Receive Window와 Flow Control

수신자가 감당할 수 있는 Buffer 범위를 광고한다. 빠른 Sender가 느린 Receiver를 압도하지 않게 한다.

ㅇ Congestion Control

Network 길 자체가 감당할 수 있는 양을 추정해 전송량을 조절한다.

Receiver의 여유와 Network의 여유는 다른 문제다.

실제 전송 가능량은 대략 다음 두 한계 가운데 더 작은 쪽의 영향을 받는다.

min(Receiver Window, Congestion Window)

TCP의 신뢰성은 Packet 하나에 붙은 특별한 도장 하나가 아니다.

순서 번호, ACK, Timer, 재전송, 흐름 제어와 혼잡 제어가 함께 만든 결과다.

이 단계가 해결한 문제는 손실과 지연이 있는 공유 길 위에서도 대화를 이어 가는 신뢰와 효율이다.

ㅁ 12단계: TCP 연결이 되면 상대를 믿어도 될까?

아직 아니다.

TCP 연결 성공은 198.51.100.20:443까지 Byte를 주고받을 수 있다는 뜻이다.

그 상대가 정말 server.example인지, 중간 누군가가 내용을 읽거나 바꾸지 않았는지는 말해 주지 않는다.

HTTPS에서는 TCP 위에서 TLS Handshake가 이어진다.

TLS 1.3의 세부 Message와 선택 사항은 상황에 따라 달라지지만, 큰 흐름은 다음과 같다.

ClientHello
  - 지원하는 TLS Version과 Cipher Suite
  - Key Share
  - SNI: server.example

ServerHello와 Server 인증 정보
  - 선택한 Parameter
  - Key Share
  - Certificate Chain
  - Certificate로 증명한 서명

양쪽의 Finished 검증
  - Handshake가 변조되지 않았는지 확인

Client는 Certificate를 받을 뿐 아니라 다음을 검증해야 한다.

신뢰하는 CA로 이어지는 Chain인가?
Certificate의 유효 기간 안인가?
접속한 Host 이름 server.example과 일치하는가?
필요한 사용 목적과 정책을 만족하는가?

그리고 Key Exchange 결과로 공유한 Secret에서 Traffic Key를 만들어 이후 TLS Record를 암호화하고 무결성을 보호한다.

우편 비유로는 봉투를 잠그고 수신인의 신분증을 확인하는 일과 닮았다.

그러나 실제 TLS는 모든 중간 Router를 신뢰해서 내용을 맡기는 방식이 아니다.

Endpoint끼리 암호학적으로 상대와 Message를 검증한다.

SNI나 IP·Port 같은 일부 Metadata는 구성과 TLS Version, 추가 보호 기술에 따라 여전히 관찰될 수 있다.

암호화는 Packet의 존재와 모든 Header를 사라지게 하지 않는다.

이 단계가 해결하는 문제는 믿을 수 없는 중간 경로에서도 상대와 내용에 대한 신뢰를 만드는 일이다.

ㅁ 13단계: 드디어 HTTP Request가 출발한다

TCP와 TLS가 준비된 뒤에야 Browser는 보호된 연결 안으로 HTTP 의미를 보낸다.

개념적으로는 다음과 같은 Request다.

GET /orders HTTP/1.1
Host: server.example
Accept: application/json

실제 Service는 HTTP/2나 HTTP/3를 사용할 수도 있다.

이 예시는 지금까지 따라온 TCP와 TLS의 연결을 분명하게 보기 위해 TCP 기반 HTTPS 흐름으로 단순화했다.

HTTP/3는 TCP 대신 QUIC을 UDP 위에서 사용하므로 Transport의 세부 여정이 달라진다.

Server 쪽에서는 역순으로 계층을 해석한다.

NIC가 Frame 수신
→ IP가 Local Destination 확인
→ TCP가 443 Port의 Socket과 연결 식별
→ TLS가 Record 복호화와 무결성 검증
→ HTTP Server가 Method, Host, Path 해석
→ Application이 주문 목록 처리

Server가 Request를 받았다는 사실과 업무가 성공했다는 사실도 다르다.

TCP ACK는 Byte 수신을 확인한다.
TLS는 보호된 Record의 무결성을 확인한다.
HTTP Status는 Request 처리 결과를 표현한다.
업무 Transaction과 Log는 Application 내부 결과를 보여준다.

예를 들어 HTTP 500은 Network 연결 실패가 아니라, Network와 TLS를 지나 Application이 오류 응답을 돌려준 증거다.

Server는 처리 결과를 HTTP Response로 만들고 TLS로 보호한 뒤 TCP Byte Stream에 실어 보낸다.

HTTP/1.1 200 OK
Content-Type: application/json

[{"orderId": 42, "status": "ready"}]

ㅁ 14단계: 응답은 왔던 길을 그대로 되돌아올까?

반드시 그렇지는 않다.

Internet Routing은 방향마다 독립적으로 결정될 수 있다.

요청이 A → B → C를 지났더라도 응답이 C → D → A로 돌아올 수 있다. 이를 Asymmetric Routing, 비대칭 경로라고 한다.

Server의 Reply는 Server 쪽 Routing Table부터 다시 조회한다.

NAT 바깥에서 Reply의 주소는 다음과 같다.

198.51.100.20:443 → 203.0.113.5:40001

경계 NAT 장비에 도착하면 기존 Mapping에 따라 다음처럼 복원된다.

198.51.100.20:443 → 192.168.10.20:51514

그 뒤 내부 Route와 Neighbor Table을 사용해 Client에 전달한다.

Stateful Firewall이나 NAT가 연결 상태를 기억한다면 Reply가 그 State를 볼 수 있는 경로로 돌아와야 한다.

비대칭 경로 자체는 IP Routing에서 가능하지만,

한 방향의 상태만 아는 장비를 우회하거나 다른 장비로 들어오면 정상 Reply도 새롭거나 알 수 없는 Traffic으로 판단될 수 있다.

Client에 도착한 TCP Segment는 5-Tuple과 Socket 상태를 바탕으로 원래 연결에 Demultiplexing된다.

TCP는 Sequence Number를 보고 Byte를 순서대로 조립하고, TLS는 Record를 검증해 복호화한다.

Browser는 HTTP Response를 원래 요청과 연결해 화면을 갱신한다.

돌아오는 길은 단순한 후일담이 아니다.

요청이 목적지에 도착했는데도 사용자가 실패를 보는 이유는 응답 Route, NAT State, Firewall Policy와 Client Socket까지 모두 이어져야 하기 때문이다.

ㅁ 한눈에 보면 무엇이 바뀌고 무엇이 남을까?

Packet을 분석할 때 모든 주소가 처음부터 끝까지 그대로라고 생각하면 NAT와 Router의 동작을 혼동한다.

반대로 Router가 모든 주소를 바꾼다고 생각해도 틀린다.

정보	일반적인 변화	이유
Ethernet Source/Destination MAC	L2 Link를 지날 때마다 바뀜	현재 Link의 Sender와 Next Hop을 가리킴
IP Source/Destination	Router를 지나도 보통 유지	최종 Endpoint를 표현함
IP Source/Destination의 예외	NAT 구간에서 변환될 수 있음	주소 공유 또는 주소 영역 연결
IP TTL	Router마다 1씩 감소	무한 Routing Loop 방지
IPv4 Header Checksum	TTL이나 주소가 바뀌면 갱신	변경된 Header의 오류 검출
TCP Source/Destination Port	보통 연결 동안 유지	Endpoint의 Socket과 Service 식별
TCP Port의 예외	NAPT에서 변환될 수 있음	하나의 공인 IP에서 연결 구분
TCP Sequence/Acknowledgment	Data 교환에 따라 계속 진행	Byte의 순서와 수신 범위 표현
TLS Application Payload	중간 구간에서 암호문으로 보임	내용의 기밀성과 무결성 보호

예시의 첫 Link에서는 다음과 같다.

Ethernet  Client MAC → Gateway MAC
IP        192.168.10.20 → 198.51.100.20, TTL=64
TCP       51514 → 443

NAT 바깥쪽 Link에서는 다음과 같이 보일 수 있다.

Ethernet  NAT WAN MAC → ISP Next-Hop MAC
IP        203.0.113.5 → 198.51.100.20, TTL=63
TCP       40001 → 443

Server 근처의 마지막 Link에서는 MAC 주소가 다시 달라지고 TTL은 더 줄어든다.

NAT가 추가로 없다면 IP와 TCP의 변환된 값은 유지된다.

Ethernet  Last Router MAC → Server MAC
IP        203.0.113.5 → 198.51.100.20, TTL=여러 Hop만큼 감소
TCP       40001 → 443

이 구분만 명확해도 Capture 지점에 따라 같은 연결이 왜 다른 모습으로 보이는지 설명할 수 있다.

ㅁ 우편 비유를 실제 용어로 되돌려 놓기

비유는 출발점이지 기술 정의가 아니다.

마지막에는 각 장면을 실제 용어로 다시 말할 수 있어야 한다.

우편 이야기	실제 핵심 용어	정확한 역할
이름을 숫자 주소로 찾는 주소록	DNS, A, AAAA, Resolver, Cache TTL	Domain Name을 IP 주소 정보로 해석
같은 동네인지 판단	Subnet Mask, Prefix, Routing Table	Destination과 Route Prefix를 비교
가까운 우체국에 맡김	Default Gateway, Next Hop	직접 연결되지 않은 목적지의 다음 L3 전달자
같은 동네의 실제 집 찾기	ARP, Neighbor Table, IPv6 NDP	Next-Hop IP와 Link-Layer 주소 연결
동네 안의 분류소	Switch, MAC Address Table	L2 Frame을 적절한 Port로 전달
동네 경계 나누기	VLAN, Broadcast Domain	하나의 L2 기반을 논리적으로 분리
순환 도로 일부를 닫기	STP	L2 Loop와 Frame 증폭 방지
지역 간 중계소	Router, Routing Table, Longest Prefix Match	Destination Prefix에 맞는 Next Hop 선택
최대 중계 횟수	IP TTL, Hop Limit	Routing Loop의 자원 낭비 제한
좁은 길에 맞는 소포 크기	MTU, MSS, PMTUD, ICMP	경로가 전달 가능한 Packet 크기 조절
한 공인 주소를 여러 집이 사용	NAT, NAPT/PAT, Mapping	IPv4 주소와 Port를 변환하고 연결 State 유지
출입 정책을 확인하는 보안실	Firewall, Stateful Inspection, Conntrack	정해진 통신 Policy와 연결 상태 적용
건물 안의 담당 창구	Port, Socket, Demultiplexing	한 Host의 올바른 Process와 연결 식별
접수와 수령 확인	TCP SYN, ACK, Sequence Number	연결 의사와 Byte 수신 범위 확인
분실물 재발송	Retransmission, RTO, Duplicate ACK	손실로 추정한 Data를 다시 전송
수신 창고의 남은 공간	Receive Window, Flow Control	Receiver 처리 능력에 Sender 속도 조절
도로 전체의 혼잡	Congestion Window, Congestion Control	Network가 감당할 수 있는 전송량 추정
봉인을 하고 수신인을 확인	TLS, Certificate, Hostname Verification, Traffic Key	상대 인증과 Data 기밀성·무결성 보호
편지 안의 업무 요청	HTTP Method, Host, Path, Status	Application 요청과 처리 결과 표현

우편 비유로 설명한 뒤 이 표의 오른쪽 문장으로 돌아올 수 있다면, 비유가 개념을 가린 것이 아니라 이해를 도운 것이다.

ㅁ 화면에 `timeout` 하나만 보인다면 어디부터 볼까?

같은 오류 문구도 멈춘 단계는 다를 수 있다. 그래서 도구부터 고르는 대신 여정의 순서대로 질문한다.

단계	먼저 물을 질문	남을 수 있는 증거와 도구
Local Link	Interface가 올라와 있고 주소가 있는가?	ip link, ip addr, Interface Counter
이름	Host 이름은 어떤 주소와 RCODE를 받는가?	dig, Resolver Log, DNS Cache
Route	어떤 Source, Interface, Next Hop이 선택되는가?	ip route get
Neighbor	Next Hop의 MAC을 알아냈는가?	ip neigh, ARP/NDP Capture
L2 전달	Frame이 올바른 VLAN과 Port로 가는가?	Switch MAC Table, VLAN/STP 상태, tcpdump -e
L3 경로	Packet이 어느 구간까지 가는가?	ping, traceroute, Router Route와 Counter
MTU	작은 Data는 되고 큰 Data만 멈추는가?	tracepath, 크기를 바꾼 ping, ICMP Capture
NAT/Firewall	변환 State와 허용 Rule에 일치하는가?	NAT/Conntrack Table, Rule Counter와 Log
TCP Port	SYN과 SYN-ACK가 오가는가?	nc, ss, tcpdump의 TCP Flag
TLS	Certificate와 Hostname 검증이 성공하는가?	openssl s_client, TLS Alert, Server Log
HTTP/Application	어떤 Status와 처리 결과가 돌아오는가?	curl -v, Access/Error Log, Trace와 Metric

관찰 결과의 의미도 넘겨짚지 않아야 한다.

ㅇ dig가 성공했다

이름을 주소로 바꿨다는 뜻이다. 해당 Web Port가 열려 있거나 Application이 정상이라는 뜻은 아니다.

ㅇ ping이 실패했다

ICMP Echo Reply를 받지 못했다는 뜻이다. 정책상 ICMP만 차단했을 수 있으므로 HTTPS도 실패했다고 단정할 수 없다.

ㅇ traceroute에 *가 보인다

해당 Probe의 응답을 받지 못했다는 뜻이다. 그 Router가 모든 Transit Traffic을 버렸다는 직접 증거는 아니다.

ㅇ SYN은 나가는데 SYN-ACK가 없다

Client가 응답을 받지 못했다는 뜻이다. SYN의 전방 손실, Server/Port 문제, SYN-ACK의 역방향 손실 가운데 어디인지 한 지점의 Capture만으로 구분할 수 없다.

ㅇ TCP Handshake가 성공했다

Transport 연결이 되었다는 뜻이다. TLS 검증이나 HTTP 업무 성공은 아직 별개의 단계다.

ㅇ Server NIC에서 Request가 보인다

Frame 또는 Packet이 Capture 지점까지 왔다는 뜻이다. Process가 read()했고 업무 Transaction을 완료했다는 뜻은 아니므로 Socket과 Application Log를 함께 봐야 한다.

진단은 "무엇이 고장 났을까?"라는 추측 대회가 아니다.

마지막으로 확인된 정상 사건과 처음 사라진 실패 사건 사이로 범위를 줄이는 일이다.

ㅁ 직접 관찰하기: URL 한 번의 여정 기록표 만들기

새로운 복잡한 Lab을 만들지 않아도 한 번의 접속을 단계별로 관찰할 수 있다.

자신이 관리하거나 점검 허가를 받은 HTTPS Host를 하나 선택한다.

아래 명령은 Linux 기준이며 운영체제에 따라 Option과 출력 형식이 다를 수 있다.

먼저 변수에 Host 이름을 넣는다.

HOST=your-authorized-host.example

ㅇ 1. DNS Answer를 기록한다

dig "$HOST" A
dig "$HOST" AAAA

status, ANSWER SECTION, Record Type과 DNS TTL을 적는다.

여러 IP가 있다면 이번에 관찰할 IPv4 주소 하나를 선택한다.

IP=$(dig +short A "$HOST" | awk '/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/ { print; exit }')
printf 'selected_ip=%s\n' "$IP"

빈 값이라면 다음 단계로 넘어가지 말고 DNS Answer와 입력한 Host부터 확인한다.

ㅇ 2. Kernel의 Route 결정을 묻는다

ip route get "$IP"

출력에서 다음 값을 기록한다.

선택한 Source IP
Egress Interface
via가 있다면 Next Hop
일치한 Route에 관한 정보

문서에 적힌 Route를 추측하지 말고 실제 Kernel이 내린 결정을 기준으로 삼는다.

ㅇ 3. Neighbor State를 확인한다

먼 Host라면 Neighbor는 Server IP가 아니라 Route가 선택한 Gateway다.

ip neigh show

Gateway 항목의 MAC 주소와 REACHABLE, STALE, DELAY, INCOMPLETE, FAILED 같은 State를 확인한다. Entry가 없으면 실제 Traffic을 한 번 발생시킨 뒤 다시 비교할 수 있다.

ㅇ 4. TCP와 TLS를 분리해 확인한다

TCP Port 도달 여부를 먼저 살펴본다.

nc -vz -w 3 "$HOST" 443

그다음 TLS에서 SNI와 Hostname 검증을 명시한다.

openssl s_client \
  -connect "$HOST:443" \
  -servername "$HOST" \
  -verify_hostname "$HOST" \
  -brief </dev/null

TCP 성공과 Certificate 검증 성공을 한 칸에 뭉뚱그리지 않고 따로 기록한다.

ㅇ 5. HTTP 결과를 확인한다

curl -v --connect-timeout 5 "https://$HOST/" -o /dev/null

Verbose 출력에는 DNS 후보, 연결한 IP와 Port, TLS 정보, HTTP Status 같은 단서가 나타날 수 있다. Version과 Build Option에 따라 표현은 달라질 수 있다.

ㅇ 6. 필요한 범위에서 Packet을 함께 본다

자신에게 Capture 권한이 있는 Host와 Interface에서만 수행한다.

인증 정보와 개인정보가 포함될 수 있으므로 수집 범위를 최소화한다.

sudo tcpdump -ni any "host $IP and tcp port 443"

다른 Terminal에서 curl을 한 번 실행하고 Capture를 종료한다. 다음 사건이 실제로 보이는지 확인한다.

SYN → SYN-ACK → ACK
TLS Handshake Data
Application Data
FIN 또는 다른 종료 방식

TLS가 적용되었다면 HTTP Path와 Body가 평문으로 보이지 않는 것이 정상이다. 또한 any Capture와 NIC Offload 때문에 중복처럼 보이는 Packet, Wire와 다른 크기, 잘못된 것처럼 보이는 Checksum이 나타날 수 있다.

ㅇ 7. 자기 언어로 한 문단을 완성한다

다음 빈칸을 실제 관찰값으로 채운다.

나는 ______라는 이름을 DNS Resolver ______에 물어 ______를 받았다.
Kernel은 Source ______, Interface ______, Next Hop ______를 선택했다.
Local Link에서는 Next Hop의 MAC ______를 사용했다.
TCP는 Local Port ______에서 Remote Port 443으로 Handshake를 만들었다.
TLS는 Hostname ______와 Certificate Chain을 검증했다.
HTTP는 Status ______를 돌려주었다.
내가 직접 확인하지 못한 중간 단계는 ______이며, 이를 단정하지 않는다.

마지막 문장이 특히 중요하다.

Client 한 대의 명령으로 ISP Router의 NAT Table이나 Server Process 내부 처리를 직접 보았다고 말할 수는 없다.

관찰한 사실, 다른 증거로 추론한 내용, 아직 모르는 영역을 나누는 것이 Network를 정확히 설명하는 방법이다.

ㅁ 네 가지 질문으로 다시 보면 기술은 따로 떨어져 있지 않다

긴 여정을 용어 목록으로 다시 흩뜨리지 않으려면 각 기술이 해결한 제약을 묻는다.

ㅇ 공유: 제한된 것을 어떻게 함께 쓸까?

Switch는 하나의 L2 기반을 여러 장비가 함께 사용하게 한다.
Port는 하나의 IP 주소에서 여러 Process와 연결을 구분한다.
NAT/NAPT는 하나의 공인 IPv4 주소를 여러 내부 연결이 함께 쓰게 한다.

ㅇ 확장: 모두가 모든 것을 알지 않고도 어떻게 커질까?

VLAN과 Subnet은 가까운 전달 범위를 나눈다.
Default Gateway와 Routing은 각 Node가 다음 길 중심으로 판단하게 한다.
DNS는 분산된 권한과 Cache로 이름 체계를 확장한다.

ㅇ 효율: 한정된 길과 처리 능력을 어떻게 낭비하지 않을까?

Switch의 학습은 불필요한 Flooding을 줄인다.
TTL은 Loop Packet이 자원을 영원히 소비하지 않게 한다.
MTU, MSS와 PMTUD는 경로에 맞는 크기를 찾는다.
TCP Flow Control과 Congestion Control은 Receiver와 Network 상태에 맞춰 속도를 조절한다.

ㅇ 신뢰: 손실과 믿을 수 없는 길에서도 어떻게 대화할까?

TCP의 Sequence, ACK와 Retransmission은 순서 있는 Byte Stream을 만든다.
Firewall은 허용한 통신의 경계를 세운다.
TLS는 상대를 검증하고 내용의 기밀성과 무결성을 보호한다.
계층별 관찰과 Log는 문제가 생겼을 때 추측을 증거로 바꾼다.

새로운 Network 기술을 만났을 때도 이름부터 외울 필요는 없다.

먼저 물으면 된다.

이 기술은 무엇을 함께 쓰게 하는가?

어디까지 확장하기 위해 생겼는가?

어떤 낭비를 줄이는가?

누구와 무엇을 신뢰하게 만드는가?

ㅁ 이제 혼자 설명할 수 있을까?

처음의 URL로 돌아가 보자.

https://server.example/orders

이제 "Client가 Server에 접속했다"라는 한 문장을 더 정확하게 펼칠 수 있다.

Browser는 URL에서 Scheme, Host, Port와 Path를 구분했다.
DNS Cache와 Resolver를 통해 Host 이름의 A 또는 AAAA 주소를 얻었다.
Kernel은 Routing Table에서 Longest Prefix Match로 Source, Interface와 Next Hop을 골랐다.
같은 Link의 Next Hop MAC을 ARP 또는 NDP와 Neighbor Table로 알아냈다.
Switch는 MAC Table과 VLAN 범위 안에서 Frame을 Gateway 방향으로 전달했다.
Router들은 Destination Prefix에 맞는 다음 Hop을 선택하고 TTL을 줄이며 새 L2 Frame을 만들었다.
출발지는 MTU와 PMTUD의 단서를 바탕으로 경로가 감당할 크기에 맞췄다.
경계 NAT/NAPT는 사설 Source IP와 Port를 공인 IP와 Port로 Mapping했다.
Firewall은 주소, Port, 방향과 연결 상태를 Policy에 따라 판단했다.
TCP는 5-Tuple로 연결을 구분하고 Three-Way Handshake를 만들었다.
Sequence, ACK, 재전송, Flow Control과 Congestion Control이 Byte Stream의 신뢰와 효율을 지켰다.
TLS는 Certificate와 Hostname을 검증하고 이후 Data를 암호화해 보호했다.
HTTP Server와 Application이 /orders를 처리해 Status와 Body를 만들었다.
응답은 독립적인 Return Route를 따라와 NAT State를 거쳐 원래 Socket과 Browser 요청에 전달되었다.

그리고 문제가 생겼다면 이렇게 말할 수 있다.

DNS Answer까지는 확인했다.
Route와 Neighbor도 정상이다.
Client의 SYN은 Router Ingress에서 보이지만 Egress에서는 보이지 않는다.
따라서 Server가 죽었다고 단정하지 않고, 두 Capture 지점 사이의 Forwarding,
Firewall Rule과 Counter를 확인하겠다.

이 문장에는 모든 장비의 모든 정보를 안다는 허세가 없다.

대신 어디까지 확인했고, 어느 구간이 아직 설명되지 않았으며, 다음에 어떤 증거를 볼지가 있다.

그것이 이 연재에서 만들고 싶었던 Network 이해다.

ㅁ 핵심 정리

URL 접속은 DNS, Route 선택, Neighbor 확인, L2 전달, Routing, NAT, TCP, TLS와 HTTP가 시간 순서로 이어진 결과다.
DNS Query 자체도 Route와 ARP/NDP가 필요한 작은 Packet Journey이며, 단계들은 상황에 따라 Cache되거나 중첩된다.
Destination이 다른 Subnet이면 Host는 최종 Server IP를 유지한 채 Ethernet Frame을 Default Gateway MAC으로 보낸다.
Switch는 현재 L2 Frame의 MAC을 보고, Router는 IP Destination의 Longest Prefix Match로 다음 Hop을 고른다.
Ethernet MAC 주소는 Link마다 바뀌고, IP 주소는 보통 End-to-End로 유지되지만 NAT에서 바뀔 수 있으며 TTL은 Router마다 감소한다.
NAPT는 공인 IP와 Port의 Mapping State를 기억해 Reply를 원래 사설 Client 연결로 돌려보낸다.
Firewall의 통신 허용, TLS의 상대·내용 보호, Application의 사용자 권한은 서로 다른 문제다.
TCP 신뢰성은 Handshake 하나가 아니라 Sequence, ACK, Timer, 재전송, Flow Control과 Congestion Control의 조합이다.
MTU와 PMTUD가 깨지면 작은 통신은 되는데 큰 Data만 멈출 수 있다.
Request Route와 Return Route는 다를 수 있으며, Stateful 장비가 있다면 Reply가 필요한 State를 만날 수 있어야 한다.
TCP ACK, TLS 성공, HTTP Status와 업무 Transaction은 각각 다른 단계의 성공을 뜻한다.
진단은 마지막으로 확인한 정상 사건과 처음 사라진 기대 사건 사이를 Route, Capture, Counter와 Log로 좁히는 일이다.
하나의 관찰 지점에서 보이지 않았다는 사실을 Network 전체에 존재하지 않았다는 뜻으로 확대하지 않는다.
새 기술은 공유, 확장, 효율, 신뢰 가운데 어떤 제약을 해결하려는지 물을 때 기존 기술과 연결된다.

핵심 용어: URL, DNS, A, AAAA, Resolver, DNS Cache, Subnet, Routing Table, Longest Prefix Match, Default Gateway, Next Hop, ARP, NDP, Neighbor Table, Ethernet Frame, MAC Address Table, VLAN, STP, Router, TTL, MTU, MSS, PMTUD, ICMP, NAT, NAPT, PAT, 5-Tuple, Firewall, Stateful Inspection, Conntrack, TCP Three-Way Handshake, Sequence Number, Acknowledgment, Retransmission, Receive Window, Congestion Window, TLS, Certificate, Hostname Verification, HTTP, Asymmetric Routing, Socket, Demultiplexing, Evidence-Based Troubleshooting

인터넷은 편지를 한 번에 목적지로 보내는 거대한 장치가 아니다.
제한된 길과 주소를 함께 쓰면서,
각 지점이 자신이 맡은 작은 결정을 이어 붙여 결과적으로 한 통의 편지를 도착시키는 물류 시스템이다.

ㅁ 연재를 마치며

처음에는 ARP, Switch, Router, TTL, NAT, DNS와 TCP가 서로 떨어진 용어처럼 보였다.

이제는 하나가 빠질 때 다음 질문이 생긴다.

DNS가 주소를 알려 주어도 누가 같은 Link의 Next Hop을 찾을까?
ARP가 Gateway MAC을 알려 주어도 누가 먼 지역의 다음 길을 고를까?
Route가 있어도 주소가 부족하면 여러 사용자가 어떻게 Public Internet을 함께 쓸까?
Packet이 도착해도 손실과 순서 뒤바뀜 속에서 어떻게 대화를 이어 갈까?
TCP가 Byte를 전달해도 믿을 수 없는 중간 길에서 상대와 내용을 어떻게 지킬까?
모든 계층을 거쳤어도 업무가 실패하면 어느 증거부터 거꾸로 따라갈까?

기술은 앞선 기술이 틀려서 생긴 것이 아니다.

더 많은 사람이

길을 공유하고,

더 먼 곳까지 확장하고,

한정된 자원을 효율적으로 쓰며,

불완전한 길 위에서도 신뢰를

만들기 위해 필요한 선택이 하나씩 더해졌다.

이제 Packet을 볼 때 Header의 숫자만 보지 않았으면 한다.

그 숫자가 어떤 문제를 해결하기 위해 그 자리에 놓였는지,

왜 그 다음 길을 선택했는지, 어디에서 처음 기대한 사건이 사라졌는지를 이야기할 수 있다면 충분하다.

우리는 인터넷의 용어를 모두 외운 것이 아니다.

편지 한 통이 목적지까지 가는 이유를 이해했다.

[Network] 26. 패킷을 직접 보면 모든 원인을 알 수 있을까?

기록하는 백엔드개발자 — Tue, 28 Jul 2026 22:26:06 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

장애가 생기면 Wireshark를 열고 Packet부터 보고 싶어진다.

Packet은 추측보다 강한 증거다.

SYN을 실제로 보냈다.
SYN-ACK이 실제로 돌아왔다.
DNS가 NXDOMAIN을 응답했다.
Router가 ICMP Unreachable을 보냈다.
같은 TCP Sequence가 재전송됐다.

하지만 Capture 화면은 Network 전체를 내려다보는 CCTV가 아니다.

어느 Host의
어느 Interface에서
어느 방향을
어느 시간 동안
어떤 Filter와 크기로
수집했는가?

이 조건 안에서 보인 Packet만 기록한다.

Client Capture에 SYN이 없다고 Server가 받지 않았음을 증명하는 것이 아니다.

잘못된 Interface를 봤거나 Capture가 늦게 시작됐거나 BPF Filter가 제외했을 수 있다.

SYN이 보인다고 NIC를 떠나 Wire에 실렸다는 뜻도 아닐 수 있다.

Capture 위치가 NIC Offload 이전일 수 있기 때문이다.

Packet Capture는 답을 자동으로 주는 도구가 아니라 가설을 관찰 가능한 사건으로 바꾸는 도구다.

이번 글에서는 ip, dig, ping, traceroute, nc, curl, openssl, tcpdump, Wireshark와 Log를

계층별 질문에 연결하고 Multi-point Capture로 원인 범위를 줄이는 방법을 정리한다.

ㅁ 도구를 열기 전에 어떤 질문을 써야 할까?

“Network가 안 된다”는 질문은 너무 크다.

다음처럼 관찰 가능한 질문으로 나눈다.

Hostname이 어느 Address로 해석되는가?
Kernel은 어느 Route와 Source Address를 선택하는가?
Next-Hop MAC Address를 알고 있는가?
TCP SYN이 Host를 떠나는가?
SYN-ACK 또는 RST가 돌아오는가?
TLS ClientHello 뒤에 ServerHello가 오는가?
HTTP Request가 Server Process까지 도착하는가?
Server가 Reply를 만들고 어느 Route로 보내는가?

질문이 달라지면 필요한 증거와 Capture 지점도 달라진다.

DNS 질문에 TCP Retransmission Filter만 봄
→ 필요한 증거를 놓침

Application 500 오류에 ARP만 봄
→ 계층이 맞지 않음

도구보다 질문을 먼저 정하면 수많은 Packet에서 무엇을 찾아야 하는지 분명해진다.

ㅁ Packet Capture는 어떤 문장으로 읽어야 할까?

다음 두 문장은 범위가 다르다.

Packet이 없다.

10:30:00부터 10:30:15까지 Client의 eth0 Ingress와 Egress를
Snaplen 0, TCP 443 Filter로 Capture했지만
198.51.100.20을 향한 SYN을 관찰하지 못했다.

두 번째 문장은 다음 확인점을 남긴다.

시간 범위가 맞는가?
실제 Traffic이 eth0을 사용했는가?
IPv4와 IPv6 Address가 맞는가?
Port가 정말 443인가?
Capture Process가 Packet을 Drop하지 않았는가?

Capture의 부재는 정의한 관찰 창 안에서 보이지 않았다는 뜻이다.

관찰 조건을 기록하지 않은 “없음”은 약한 증거다.

ㅁ 가장 먼저 Packet을 잡아야 할까?

Packet Capture 전에 Local State를 확인하면 더 빠르게 범위를 줄일 수 있다.

Interface가 Down
Route 없음
잘못된 DNS Answer
Service가 Listen하지 않음

이런 상태는 Packet 수천 개를 읽지 않고도 확인할 수 있다.

일반적인 순서는 다음과 같다.

1. 증상과 시간, Source·Destination 정의
2. Local Interface와 Address 확인
3. Route와 Neighbor 확인
4. DNS Answer 확인
5. 실제 Transport와 Application Probe
6. 필요한 지점에서 Packet Capture
7. Firewall Counter, Conntrack와 Application Log 대조

순서는 고정된 의식이 아니다. 이미 장애 시간의 PCAP만 남았다면 Capture부터 볼 수 있다.

핵심은 한 도구의 결과를 전체 원인처럼 확대하지 않는 것이다.

ㅁ `ip link`는 무엇을 묻는가?

Linux에서 Interface 상태와 Counter를 확인한다.

ip -s link

확인할 항목은 다음과 같다.

Interface UP / DOWN
Carrier 상태
MTU
RX / TX Packet과 Byte
Error와 Drop Counter

Interface가 UP이라고 Cable, Switch Port, VLAN, Routing과 Remote Host가 모두 정상이라는 뜻은 아니다.

반대로 RX Drop Counter가 증가해도 곧바로 Network 손실 원인을 확정할 수 없다.

Driver Queue, Buffer, Offload와 Counter 정의를 확인해야 한다.

ip link 증거
→ Local Interface 상태와 Counter

증명하지 않는 것
→ End-to-End Service 정상

ㅁ `ip addr`는 무엇을 확인할까?

ip addr show

다음 질문에 답한다.

기대한 IPv4 또는 IPv6 Address가 있는가?
Prefix Length가 맞는가?
어느 Interface에 연결되어 있는가?
Address가 Tentative, Deprecated 같은 상태인가?

Address가 있다고 해당 Source로 Packet이 나간다고 보장할 수는 없다.

Route Selection이 다른 Interface와 Source를 선택할 수 있다.

Container, Pod, VRF와 Network Namespace마다 별도 Address와 Interface가 있으므로

실제 Application의 Network Context에서 실행한다.

ㅁ `ip route get`은 왜 유용할까?

Routing Table 전체를 보는 것보다 특정 Destination에 대한 Kernel의 결정을 직접 묻는다.

ip route get 198.51.100.20

환경에 따라 다음 정보가 보일 수 있다.

Selected Route
Next Hop
Outgoing Interface
Preferred Source Address
Route Table과 Metric 관련 정보

Source를 지정해 Policy Routing 차이를 볼 수도 있다.

ip route get 198.51.100.20 from 10.0.0.10

ip route get 결과는 현재 Kernel Route Lookup의 증거다.

Packet이 이후 Firewall, Tunnel과 Neighbor Resolution을 모두 통과했다는 증거는 아니다.

Policy Routing을 사용하면 다음도 함께 본다.

ip rule show
ip route show table all

ㅁ `ip neigh`는 어느 단계의 장부일까?

같은 Link의 Destination이나 Default Gateway로 Frame을 보내려면 Next-Hop IP에 대응하는 MAC Address가 필요하다.

ip neigh show

Neighbor Entry는 다음 상태를 가질 수 있다.

REACHABLE
STALE
DELAY
PROBE
INCOMPLETE
FAILED

INCOMPLETE나 FAILED가 반복되면 ARP Request 또는 IPv6 Neighbor Solicitation에 응답이 없는 이유를 조사한다.

VLAN 불일치
Switch Port 문제
잘못된 Subnet
Gateway Down
L2 Security Policy

STALE은 곧 장애라는 뜻이 아니다.

필요할 때 다시 Reachability를 확인할 수 있는 정상 상태다.

ㅁ macOS와 다른 운영체제에서는 무엇을 사용할까?

명령 이름은 달라도 질문은 같다.

Interface와 Address
→ ifconfig, ipconfig 등

Route
→ route, netstat, Get-NetRoute 등

Neighbor
→ arp, ndp, Get-NetNeighbor 등

출력 Field와 State 의미는 운영체제마다 다르다.

Linux 명령을 외우는 것보다 “현재 Source에서 어느 Interface와 Next Hop을 선택했는가?”라는 질문을 유지한다.

ㅁ `dig`는 무엇을 분리해 줄까?

Hostname 장애는 Network 연결 전에 시작될 수 있다.

dig server.example A
dig server.example AAAA

특정 Resolver에 직접 물어 비교한다.

dig @192.0.2.53 server.example A +time=2 +tries=1

응답을 다음처럼 구분한다.

NOERROR + Answer
→ 해당 Resolver가 Address Answer를 제공

NXDOMAIN
→ 이름이 존재하지 않는다는 DNS 응답

SERVFAIL
→ Resolver가 질의를 완료하지 못함

Timeout
→ 정해진 시간 안에 DNS 응답을 관찰하지 못함

dig가 받은 Answer는 Cache에서 왔을 수도 있다.

Authoritative Server의 현재 Zone을 직접 읽었다고 자동으로 가정하지 않는다.

DNSSEC 검증, Search Suffix와 Application 내부 Resolver처럼

실제 Application과 dig의 조회 경로가 다를 수도 있다.

ㅁ DNS Packet은 어디에서 확인할까?

sudo tcpdump -nn -i eth0 -s 0 \
  'port 53'

다음 흐름을 확인한다.

Query가 Host를 떠나는가?
어느 Resolver로 보내는가?
UDP인가 TCP인가?
Response가 돌아오는가?
Transaction ID와 질문이 맞는가?
Response Code와 Answer는 무엇인가?

DoH와 DoT를 사용하는 Application은 일반 UDP/TCP 53 Filter에 DNS 이름이 보이지 않을 수 있다.

port 53에 Packet 없음
≠ Application이 DNS를 전혀 사용하지 않음

실제 Resolver 경로와 암호화 방식을 확인해야 한다.

ㅁ `nc`는 어떤 범위까지 시험할까?

TCP Port 연결 가능성을 빠르게 시험할 수 있다.

nc -v -w 3 198.51.100.20 443

성공하면 해당 Source에서 TCP Handshake가 완료되었다는 단서를 얻는다.

nc TCP 연결 성공
≠ TLS 성공
≠ HTTP 정상
≠ 업무 처리 성공

실패 모습도 나눈다.

Timeout
→ SYN 또는 Reply Drop, 경로, Policy 등 여러 가능성

Connection Refused
→ RST를 받음, Listener 부재 또는 중간 장비 Reject 가능

nc Option은 구현마다 다르며 UDP Mode는 TCP처럼 Handshake 성공을 확인하지 못한다.

ㅁ `curl`은 어느 계층까지 올라갈까?

curl -v --connect-timeout 3 https://server.example/

Verbose 출력에서 다음 단계를 나눌 수 있다.

DNS Address 선택
TCP Connection
TLS Handshake와 Certificate 검증
HTTP Request
HTTP Status와 Header
Response Body

curl 성공은 실행한 URL과 Method, 해당 시점의 Response에 대한 증거다.

다른 API, 사용자 권한, Backend와 전체 Service가 정상이라는 뜻은 아니다.

-k로 Certificate 검증을 끄면 TLS Identity 문제를 숨길 수 있으므로 진단의 기본 해결책으로 사용하지 않는다.

ㅁ `openssl s_client`는 무엇을 보여줄까?

openssl s_client \
  -connect server.example:443 \
  -servername server.example \
  -verify_hostname server.example \
  -verify_return_error

다음 정보를 확인할 수 있다.

TLS Version과 Cipher
Server Certificate Chain
Hostname과 Trust 검증 결과
ALPN 협상
TLS Alert

-servername을 빠뜨리면 Virtual Host가 다른 Certificate를 보낼 수 있다.

TCP 연결 Timeout과 Certificate Verification Error를 같은 “TLS 실패”로 묶지 않는다.

ㅁ tcpdump를 시작할 때 무엇을 정해야 할까?

설명용 Capture 명령은 다음과 같다.

sudo tcpdump \
  -nn \
  -i eth0 \
  -s 0 \
  -B 4096 \
  -w incident-20260715.pcap \
  'host 198.51.100.20 and tcp port 443'

Option의 목적을 나누어 보자.

-nn
→ Hostname과 Service Name 변환을 하지 않고 숫자로 표시

-i eth0
→ Capture할 Interface 선택

-s 0
→ 구현이 허용하는 전체 Packet을 자르지 않고 저장

-B 4096
→ Capture Buffer 크기 지정

-w file.pcap
→ 화면 해석 대신 원본 Packet을 파일로 저장

BPF 표현식
→ 수집할 Traffic 범위를 Capture 단계에서 제한

Option 의미와 단위는 tcpdump Version과 운영체제에 따라 확인한다.

Capture 파일 이름에는 시간, Host와 Interface 같은 Context를 넣으면 여러 지점 자료를 맞추기 쉽다.

ㅁ Capture Filter와 Display Filter는 같은 문법일까?

같지 않다.

Capture Filter는 Packet을 저장하기 전에 어떤 Traffic을 수집할지 정한다.

tcpdump와 Wireshark Capture 단계에서 BPF 문법을 사용할 수 있다.

host 198.51.100.20 and tcp port 443

Display Filter는 이미 Capture된 Packet 중 화면에 무엇을 보여 줄지 정한다.

ip.addr == 198.51.100.20 && tcp.port == 443

차이는 중요하다.

Capture Filter에서 제외
→ PCAP에 저장되지 않음, 나중에 복구 불가

Display Filter에서 숨김
→ PCAP에는 남아 있어 Filter를 바꾸면 다시 볼 수 있음

원인을 아직 모를 때 Capture Filter를 지나치게 좁히면 ARP, DNS, ICMP 오류와 다른 Address Family를 놓칠 수 있다.

Storage와 Privacy를 고려하면서 가설에 필요한 범위를 잡는다.

ㅁ BPF Filter는 어떻게 조합할까?

대표적인 Capture Filter는 다음과 같다.

특정 Host
host 198.51.100.20

특정 방향
src host 10.0.0.10 and dst host 198.51.100.20

특정 Network
net 10.0.0.0/8

TCP Service
tcp port 443

DNS와 ICMP
port 53 or icmp or icmp6

복합 조건
host 198.51.100.20 and (tcp port 443 or icmp)

and, or, not의 우선순위를 오해하지 않도록 괄호를 사용한다.

Filter를 본 Capture 전에 작은 Sample로 검증한다.

sudo tcpdump -nn -i eth0 -c 10 \
  'host 198.51.100.20 and (tcp port 443 or icmp)'

Capture Filter가 실제 장애 Traffic의 IPv4·IPv6, NAT 전후 Tuple과 Port를 포함하는지 확인한다.

ㅁ Snaplen이 작으면 무엇을 잃을까?

Snapshot Length(Snaplen)는 Packet마다 저장할 최대 Byte 수다.

Snaplen이 Header보다 충분히 크지만 Payload보다 작으면 주소와 Port는 볼 수 있어도 Application Data 뒤는 잘린다.

Wire Packet 1500바이트
Snaplen 96바이트
→ 앞 96바이트만 PCAP에 저장

Wireshark는 Packet size limited during capture 같은 표시를 할 수 있다.

잘린 Byte는 Display Filter나 재분석으로 되살릴 수 없다.

전체 Payload가 필요한지, Header만으로 충분한지와 민감 정보 수집 위험을 함께 고려한다.

-s 0은 분석에는 편리하지만 Password, Cookie와 개인정보까지 저장할 수 있다.

ㅁ Capture Process도 Packet을 놓칠 수 있을까?

Traffic 속도가 Disk, CPU와 Buffer 처리 능력보다 빠르면 Capture Tool이 Packet을 Drop할 수 있다.

tcpdump 종료 통계에는 환경에 따라 다음 Counter가 보일 수 있다.

packets captured
packets received by filter
packets dropped by kernel

dropped by kernel이 증가했다면 PCAP의 Packet 부재를 Network Drop으로 해석하기 전에 Capture 누락을 고려한다.

완화 방법은 다음과 같다.

BPF로 필요한 Traffic 범위 제한
Capture Buffer 조정
빠른 Storage 사용
화면 출력 대신 -w로 저장
여러 CPU Queue와 전용 Capture 장비 사용
Ring Buffer로 파일 Rotation

Capture Drop Counter 자체도 플랫폼별 정의를 확인해야 한다.

ㅁ 긴 장애를 파일 하나에 계속 저장해도 될까?

오래 기다려야 재현되는 장애는 PCAP가 매우 커질 수 있다.

tcpdump는 크기나 시간 기준으로 파일을 나눌 수 있다.

설명용 예시는 다음과 같다.

sudo tcpdump -nn -i eth0 -s 0 \
  -C 100 -W 10 \
  -w incident.pcap \
  'host 198.51.100.20'

일반적인 tcpdump에서 -C 100은 파일이 약 100 million bytes에 도달하기 전에 다음 파일로 전환하고, -W 10은 파일 수를 제한하는 데 사용된다. 정확한 단위와 이름 규칙은 해당 Version의 Manual을 확인한다.

Ring Buffer는 Disk 고갈을 막지만 오래된 증거를 덮어쓴다.

Alarm 시각과 보존 범위를 맞추고 필요한 PCAP를 즉시 별도 보관한다.

ㅁ Promiscuous Mode면 Switch의 모든 Packet이 보일까?

Promiscuous Mode는 NIC가 자신에게 전달된 Frame 중

Destination MAC이 자신의 것이 아닌 Frame도 Host에 넘기도록 할 수 있다.

그러나 Switch가 해당 Port로 Frame을 보내지 않았다면 NIC가 받을 수 없다.

다른 두 Host의 Unicast Traffic
→ Switch가 그 둘의 Port로만 Forward
→ 내 Capture Port에는 도착하지 않음

다른 Link의 Traffic을 관찰하려면 다음 같은 구성이 필요할 수 있다.

Switch SPAN 또는 Port Mirroring
Network TAP
Router·Firewall 자체 Capture
Virtual Switch Mirror
Endpoint Capture

SPAN Port도 과부하되면 Packet을 놓치거나 Timing 특성이 바뀔 수 있다.

TAP과 Mirror의 방향, VLAN Tag 보존과 Capacity를 확인한다.

ㅁ `any` Interface에서 같은 Packet이 두 번 보일 수 있을까?

Linux의 tcpdump -i any는 여러 Interface를 함께 관찰한다.

Router가 Packet을 한 Interface로 받고 다른 Interface로 내보내면

같은 논리적 Packet이 Ingress와 Egress에서 각각 Capture될 수 있다.

eth0 Ingress  → Packet 한 번 관찰
eth1 Egress   → 같은 Packet 다시 관찰

Bridge, veth, Container와 Host Capture를 겹치면 더 많은 복사본처럼 보일 수 있다.

이를 실제 Network Duplicate로 단정하지 않는다.

Capture Interface ID, Direction, TTL 변화, MAC Header와 Timestamp를 비교한다.

ㅁ Checksum이 Bad라고 정말 Wire에서 손상됐을까?

TX Checksum Offload가 활성화된 Host에서는

Kernel Capture 시점에 TCP·UDP Checksum 계산이 아직 NIC에 맡겨진 상태일 수 있다.

Kernel이 Packet을 Capture
→ Checksum이 아직 완성되지 않음
→ NIC가 Wire 전송 전에 계산

Host Capture에서는 Bad Checksum처럼 보여도 실제 Wire Packet은 정상일 수 있다.

반대로 RX Offload와 Capture 위치도 해석에 영향을 준다.

Sender Host에서만 Bad Checksum
수신 Host에서는 정상 수신
→ TX Offload 가능성

다른 지점 Capture와 NIC Offload 설정을 함께 확인한다.

Checksum 경고 한 줄만으로 Link 손상을 확정하지 않는다.

ㅁ MTU보다 큰 TCP Packet이 보이면 Jumbo Frame일까?

TSO와 GSO는 Host 내부에서 큰 TCP Data 단위를 NIC나 하위 계층에 넘긴 뒤 실제 Wire 크기로 나눌 수 있다.

GRO와 LRO는 받은 여러 Packet을 Host 내부에서 합쳐 큰 단위로 상위 계층에 전달할 수 있다.

TSO / GSO
→ 분할 전 큰 Packet처럼 Capture 가능

GRO / LRO
→ 병합 후 큰 Packet처럼 Capture 가능

Host PCAP에서 32KB TCP Packet이 보였다고 Wire에 32KB Ethernet Frame 하나가 존재했다고 단정할 수 없다.

Capture 지점과 Offload 전후를 구분하고 필요하면 SPAN/TAP에서 Wire Traffic을 확인한다.

ㅁ VLAN Tag가 안 보이면 Untagged였을까?

NIC가 VLAN Tag를 Hardware에서 제거한 뒤 Kernel에 Metadata로 전달할 수 있다.

Host Capture 위치에 따라 Packet Byte에는 802.1Q Header가 보이지 않을 수 있다.

반대로 Trunk SPAN에서는 VLAN Tag가 보일 수 있다.

Host Capture에서 Tag 없음
≠ Wire에서 반드시 Untagged

NIC Offload, Driver와 Mirror 설정을 확인한다.

VLAN 문제는 Switch Port의 Access/Trunk Policy와 양쪽 Capture를 함께 봐야 한다.

ㅁ Wireshark의 분석 표시는 Packet Header일까?

Wireshark는 Packet Header뿐 아니라 Capture 순서와 시간 관계를 분석해 편리한 표시를 만든다.

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.zero_window

이 값은 Wire에 들어 있는 독립적인 TCP Flag가 아니다.

Capture가 연결 중간부터 시작되거나 한 방향 Packet이 빠졌거나 Capture Drop이 있으면 분석 결과도 달라질 수 있다.

Wireshark가 Retransmission으로 표시
→ Capture 관점에서 같은 Sequence 범위를 다시 관찰
→ 왜 원본이 확인되지 않았는지는 별도 조사

편리한 Expert Info를 결론이 아니라 가설 생성 도구로 사용한다.

ㅁ Display Filter로 대화를 어떻게 좁힐까?

이미 저장한 PCAP에서 다음처럼 범위를 줄일 수 있다.

특정 Address
ip.addr == 198.51.100.20

특정 TCP Port
tcp.port == 443

특정 TCP Stream
tcp.stream eq 3

SYN
tcp.flags.syn == 1

RST
tcp.flags.reset == 1

DNS
dns

ICMP 오류
icmp || icmpv6

재전송 분석
tcp.analysis.retransmission

tcp.stream 번호는 해당 Capture 파일에서 Wireshark가 부여한 분석 번호다.

다른 PCAP의 같은 실제 Flow가 같은 번호를 갖는 것은 아니다.

NAT 양쪽에서는 5-Tuple이 달라지므로 Sequence Number, 시간과 변환 Table을 이용해 연결한다.

ㅁ TCP SYN만 반복되면 어디가 문제일까?

Client Capture에서 다음 흐름이 보인다고 하자.

Client → Server : SYN
Client → Server : SYN Retransmission
Client → Server : SYN Retransmission

이 Capture 하나로 알 수 있는 것은 다음이다.

Client TCP가 SYN을 만들었다.
Client Capture 지점에서 SYN을 관찰했다.
Client가 SYN-ACK 또는 유효한 응답을 받지 못해 재전송했다.

다음은 아직 모른다.

원래 SYN이 Wire를 떠났는가?
Forward Path 어디에서 Drop됐는가?
Server가 SYN을 받았는가?
Server가 SYN-ACK을 보냈는가?
SYN-ACK이 Return Path에서 Drop됐는가?

Client PCAP의 SYN Retransmission은 손실의 존재를 암시하지만 Drop 위치를 알려 주지 않는다.

ㅁ RST가 보이면 원인을 확정할 수 있을까?

SYN 뒤에 RST가 돌아오면 Silent Timeout보다 정보가 많다.

Client → Server : SYN
Server → Client : RST, ACK

Destination Host의 닫힌 Port가 RST를 보냈을 수 있다.

하지만 Firewall, Load Balancer와 Proxy가 Reject Policy로 RST를 생성할 수도 있다.

RST의 Source Address, TTL, Sequence와 Capture 지점을 비교한다.

Server Capture에 SYN이 없는데 Client가 RST를 받았다면 중간 장비가 생성했을 가능성을 조사한다.

RST 수신
→ 누군가 TCP 연결을 명시적으로 거절
→ 누가 생성했는지는 추가 증거 필요

ㅁ 3-Way Handshake 뒤 Data가 멈추면 무엇을 볼까?

SYN
SYN-ACK
ACK
Client Data
Client Data Retransmission

TCP 연결은 성립했지만 Data나 ACK가 진행하지 않는다.

다음 항목을 확인한다.

Data Packet 크기와 DF, ICMP Too Big 여부
Server Capture에 Data가 도착하는가?
Server가 ACK를 보내는가?
ACK가 Client에 도착하는가?
Advertised Window가 0인가?
TLS ClientHello 뒤 응답이 있는가?
Application Process가 Socket을 읽는가?

Handshake 성공만으로 큰 Data, TLS와 Application까지 정상이라고 판단하지 않는다.

ㅁ TLS Capture에서 평문이 없으면 분석할 수 없을까?

TLS 1.3 PCAP을 Session Key 없이 보면 ClientHello와 ServerHello 이후

대부분의 Handshake와 Application Payload가 암호화되어 있다.

내용을 읽지 못해도 다음은 관찰할 수 있다.

TCP Handshake 성공 여부
ClientHello 전송 여부
ServerHello 또는 Alert 존재 여부
Record 크기와 방향
Retransmission과 Timeout
Connection 종료 시점

그러나 HTTP URL, Header와 Body는 보이지 않을 수 있다.

TLS Key Log로 Lab Traffic을 복호화할 수 있는 환경도 있지만 Key Log는 보호된 평문을 드러낼 수 있는 민감 정보다.

Production에서 임의로 수집하거나 공유하지 않는다.

암호화된 Payload 문제는 Endpoint의 TLS Log와 Application Log가 더 강한 증거가 될 수 있다.

ㅁ Server Capture에 Request가 보이면 Application도 받았을까?

Server NIC 근처 Capture에 TCP Data가 보였다고 Application의 read()가 성공했다는 뜻은 아니다.

NIC / Driver
→ IP Stack
→ Host Firewall
→ TCP Reassembly
→ Socket Receive Buffer
→ Application read()

중간 단계에서 Checksum 검증, Firewall, Socket 상태와 Buffer 문제가 생길 수 있다.

TCP ACK가 돌아왔다면 Server TCP Stack이 Byte를 수신했다는 강한 단서지만 Application 업무 처리 완료는 아니다.

Application Access Log, Error Log와 Trace ID를 함께 봐야 한다.

ㅁ Application Log만 보면 Network는 알 수 없을까?

Application Log도 중요한 관찰 지점이다.

Packet Capture
→ Network와 Transport에서 무엇이 오갔는가?

Application Log
→ Process가 어떤 요청을 해석하고 어떤 결과를 만들었는가?

Server Access Log에 Request가 없다면 다음 가능성이 남는다.

Request가 Network에서 도착하지 않음
TLS Proxy나 Load Balancer에서 종료됨
Host Firewall 또는 Kernel에서 Drop
Application Log 조건에서 제외
Log Buffer와 수집 Pipeline 문제

Log 부재도 Capture 부재처럼 관찰 조건을 확인해야 한다.

Packet, Conntrack, Proxy Log와 Application Trace를 동일한 시간축과 Request ID로 연결한다.

ㅁ 두 Capture의 Clock이 다르면 무엇이 꼬일까?

Client와 Server PCAP를 비교할 때 Timestamp가 정확해야 한다.

Client Clock가 실제보다 500ms 빠름
Server Clock가 실제보다 300ms 느림

화면상 차이 800ms
→ Network Delay로 오해 가능

NTP나 PTP로 Clock을 동기화하고 Capture Host의 Timestamp Source와 정밀도를 기록한다.

동기화가 완벽하지 않다면 TCP Sequence, IP ID, Payload Length와 사건 순서로 상대적인 Offset을 추정할 수 있다.

정확한 One-Way Delay를 주장하려면 Capture Timestamp 정확도와 Clock Error 범위를 함께 제시한다.

ㅁ Multi-point Capture는 무엇을 추가할까?

같은 Flow를 여러 지점에서 동시에 관찰한다.

Client
  │ Capture A
  ▼
Firewall Ingress
  │ Capture B
Firewall Egress
  │ Capture C
  ▼
Server
  │ Capture D

SYN의 관찰 결과를 비교하면 Drop 범위를 좁힐 수 있다.

Client Egress	Firewall Ingress	Firewall Egress	Server Ingress	해석 가능한 범위
보임	안 보임	안 보임	안 보임	Client Capture 이후와 Firewall Ingress 사이 또는 Capture 누락
보임	보임	안 보임	안 보임	Firewall 내부 Policy·Routing·Processing 범위 우선 확인
보임	보임	보임	안 보임	Firewall Egress 이후와 Server Ingress 사이 또는 Capture 누락
보임	보임	보임	보임	Forward SYN 전달 확인, Server Host와 Reply 생성·Return Path 조사

표의 어느 행도 단일 원인을 자동 확정하지 않는다.

Firewall Ingress에는 보이고 Egress에는 없더라도

Rule Drop, Local Routing, Inspection, Queue Drop와 Capture 설정이 후보로 남는다.

Rule Counter, Drop Log와 장비 내부 Trace로 한 단계 더 좁힌다.

ㅁ Forward Path만 Capture하면 절반만 보는 이유

Request가 Server에 도착하고 Reply가 돌아오지 않는 장애가 있다.

Forward Path Capture: Request 정상
Return Path Capture : Reply가 중간에서 Drop

Forward 방향만 보면 Server나 Application을 의심하기 쉽다.

양방향 Filter와 Return Route를 확인한다.

Original Tuple
Client:53000 → Server:443

Reply Tuple
Server:443 → Client:53000

NAT가 있으면 Capture 지점마다 Tuple이 달라진다.

Stateful Firewall과 Load Balancer가 있다면 Return Packet이 같은 State Owner를 지나는지도 확인한다.

ㅁ Capture에서 Packet이 사라진 경계를 찾으면 원인이 끝날까?

Client와 Firewall Ingress에는 SYN이 있고 Firewall Egress에는 없다고 하자.

원인 범위는 Firewall 내부로 크게 줄었다.

하지만 정확한 이유는 여전히 여러 가지다.

Firewall Policy Drop
No Route 또는 Wrong VRF
NAT Resource Exhaustion
Inspection Engine Drop
State Table Full
Egress Queue Drop
Capture Hook 위치 차이

다음 증거를 이어 본다.

Rule Hit Counter
Drop Log와 Reason Code
Routing/VRF Lookup
NAT와 Conntrack Entry
Interface Error/Drop Counter
장비 CPU와 Session Capacity

Multi-point Capture는 원인 위치 범위를 줄이고 장비 State가 원인 이유를 설명한다.

ㅁ SPAN Capture에서 Packet이 없으면 Source가 안 보냈을까?

SPAN 구성도 검증해야 한다.

올바른 Source Port 또는 VLAN을 Mirror했는가?
Ingress와 Egress 방향이 모두 포함됐는가?
SPAN Destination Port가 과부하되지 않았는가?
Encapsulation과 VLAN Tag를 보존했는가?

Mirror Traffic 합계가 Capture Port 용량을 넘으면 SPAN에서 Packet이 Drop될 수 있다.

SPAN PCAP의 부재를 실제 Data Plane 부재로 해석하기 전에 Mirror Counter와 구성을 확인한다.

ㅁ PCAP는 왜 민감한 정보일까?

Packet Capture에는 다음 정보가 들어갈 수 있다.

내부 IP와 Network 구조
DNS Query
평문 HTTP Header와 Body
Cookie와 Token
Email, File과 개인정보
TLS Handshake Metadata
취약한 Protocol의 Credential

장애 분석이라는 이유로 필요 이상 Traffic을 장시간 수집하면 새로운 보안 위험을 만든다.

최소 범위 Capture
접근 권한 제한
암호화된 저장과 전송
보존 기간과 안전한 삭제
공유 전 Redaction
감사 기록

Session Key Log와 복호화된 PCAP는 특히 더 엄격하게 다룬다.

Production Capture는 조직의 승인과 개인정보 정책을 따라야 한다.

ㅁ 좋은 장애 기록은 무엇을 포함할까?

다음 Context를 함께 남긴다.

Incident 시간과 Timezone
Source Host, Namespace, Address와 Port
Destination Name, Address와 Port
IPv4 또는 IPv6
실제 Application 요청과 Error
Capture Host, Interface, Direction
Capture 시작·종료 시각
Capture와 Display Filter
Snaplen과 Packet Drop Counter
Offload와 SPAN 구성
관련 Rule ID, Conntrack와 Log

PCAP 파일만 전달하면 다음 분석자가 관찰 범위를 다시 추측해야 한다.

증거를 재현 가능한 문장과 함께 전달한다.

ㅁ 계층별 질문과 도구를 연결하면

질문	먼저 볼 State·도구	Packet에서 찾을 증거	아직 증명하지 않는 것
Interface가 준비됐나?	ip -s link, ip addr	ARP/NDP와 실제 TX/RX	End-to-End Route
어느 길로 나가나?	ip route get, ip rule	Source, Next Hop, TTL	중간 Router의 전체 경로
Next Hop을 찾았나?	ip neigh	ARP Request/Reply, NDP	Remote Service 상태
이름이 맞나?	dig	DNS Query/Response, RCODE	선택된 Address의 Service
ICMP 왕복이 되나?	ping	Echo Request/Reply	TCP·TLS·Application
중간 응답은 어디까지인가?	traceroute	TTL Probe, Time Exceeded	고정된 전체 경로
TCP Port가 연결되나?	nc, ss	SYN/SYN-ACK/ACK 또는 RST	TLS와 업무 처리
TLS Identity가 맞나?	openssl, curl -v	ClientHello, ServerHello, Alert	Application Authorization
HTTP가 응답하나?	curl, Access Log	TLS Record와 Connection 종료	모든 API와 Backend Health
어디에서 Packet이 사라지나?	Multi-point tcpdump	동일 Flow의 지점별 존재	장비 내부 Drop Reason

도구 하나가 다음 계층의 질문까지 대신하지 않는다.

ㅁ 가설 기반 진단은 어떻게 반복할까?

1. 관찰된 증상을 한 문장으로 제한
2. 가능한 원인을 계층별로 나눔
3. 후보를 구분할 가장 싼 증거 선택
4. 명령 또는 Capture 실행
5. 결과가 증명한 범위 기록
6. 남은 후보로 다음 질문 이동

예를 들어 HTTPS Timeout을 보자.

가설 A: DNS가 잘못된 Address 반환
→ dig와 Application Resolver 결과 비교

가설 B: TCP SYN이 Drop
→ Client와 Firewall 양쪽 Capture

가설 C: TLS Certificate 문제
→ TCP 성공 후 openssl 검증 결과

가설 D: HTTP Backend 지연
→ TLS 성공, Access Log와 Trace 확인

처음부터 모든 Packet을 읽지 않고 각 증거가 후보를 어떻게 나누는지 설계한다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 진단 State와 증거로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
우리 건물의 문과 주소 확인	Interface / Address State	Local Link와 IP 설정 확인
어떤 우체국에 맡길지 조회	Route Lookup	Next Hop, Interface와 Source 선택
옆 우체국의 실제 위치 장부	ARP / NDP Neighbor Table	Next-Hop IP를 Link Address에 연결
수신인 이름을 주소록에서 찾음	DNS Query	Name을 A·AAAA 등 Resource Record로 해석
창구가 열렸는지 시험	TCP Probe	SYN Handshake 또는 RST 관찰
봉인과 신분증을 확인	TLS Probe	Certificate, Hostname, Cipher와 Alert 검증
길목마다 설치한 관찰소	Multi-point Capture	같은 Flow의 지점별 Packet 존재 비교
관찰소가 기록한 봉투 일부	PCAP	특정 Interface·시간·Filter에서 수집한 Packet
우체국 내부 처리 장부	Firewall / Conntrack / Application Log	Packet 밖의 Policy와 Process State 제공
관찰 카메라 자체가 놓친 장면	Capture Drop	Buffer·CPU·SPAN 한계로 PCAP에서 누락
포장 전후 크기가 다르게 보임	NIC Offload	Capture 위치 때문에 Wire와 다른 Packet 표현
봉인된 편지의 겉면만 관찰	Encrypted Payload	Metadata는 보이지만 Application 평문은 숨겨짐

진단 흐름을 한 장면으로 모으면 다음과 같다.

Configuration State
ip link / addr / route / neigh
            ↓
Name과 Protocol Probe
dig / ping / traceroute / nc / curl / openssl
            ↓
Packet Evidence
Client ─ Firewall In ─ Firewall Out ─ Server
            ↓
Internal State와 의미
Rule Counter / Conntrack / TLS / Application Log
            ↓
가설 제거와 다음 관찰

ㅁ 격리된 Linux 환경에서 Multi-point Evidence를 만들기

다음 실습은 ip, iptables, tcpdump, python3, curl, timeout이 있는 개인 Linux VM에서 수행한다.

새 Network Namespace 안에서만 TCP 8080을 Drop한다.

cap-client                 cap-router                 cap-server
10.26.1.2 ────────── 10.26.1.1 | 10.26.2.1 ──────── 10.26.2.2

Namespace와 가상 Link를 만든다.

sudo ip netns add cap-client
sudo ip netns add cap-router
sudo ip netns add cap-server

sudo ip link add veth-cc type veth peer name veth-cri
sudo ip link add veth-cro type veth peer name veth-cs

sudo ip link set veth-cc netns cap-client
sudo ip link set veth-cri netns cap-router
sudo ip link set veth-cro netns cap-router
sudo ip link set veth-cs netns cap-server

Address와 Interface를 설정한다.

sudo ip -n cap-client addr add 10.26.1.2/24 dev veth-cc
sudo ip -n cap-router addr add 10.26.1.1/24 dev veth-cri
sudo ip -n cap-router addr add 10.26.2.1/24 dev veth-cro
sudo ip -n cap-server addr add 10.26.2.2/24 dev veth-cs

sudo ip -n cap-client link set lo up
sudo ip -n cap-router link set lo up
sudo ip -n cap-server link set lo up
sudo ip -n cap-client link set veth-cc up
sudo ip -n cap-router link set veth-cri up
sudo ip -n cap-router link set veth-cro up
sudo ip -n cap-server link set veth-cs up

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n cap-client route add default via 10.26.1.1
sudo ip -n cap-server route add default via 10.26.2.1
sudo ip netns exec cap-router \
  sysctl -w net.ipv4.ip_forward=1

Server Terminal에서 HTTP Server를 실행한다.

sudo ip netns exec cap-server \
  python3 -m http.server 8080 --bind 10.26.2.2

Router가 Client에서 Server로 가는 TCP 8080을 Drop하게 한다.

sudo ip netns exec cap-router \
  iptables -I FORWARD 1 \
  -i veth-cri -o veth-cro \
  -p tcp --dport 8080 -j DROP

ㅁ 세 지점에서 동시에 Capture하기

각 명령을 별도 Terminal에서 시작한다. 15초 뒤 자동 종료되므로 모두 시작한 직후 Client 요청을 실행한다.

Client Capture:

sudo ip netns exec cap-client \
  timeout 15 tcpdump -nn -i veth-cc -s 0 \
  -w /tmp/cap-client-drop.pcap 'tcp port 8080'

Router Capture:

sudo ip netns exec cap-router \
  timeout 15 tcpdump -nn -i any -s 0 \
  -w /tmp/cap-router-drop.pcap 'tcp port 8080'

Server Capture:

sudo ip netns exec cap-server \
  timeout 15 tcpdump -nn -i veth-cs -s 0 \
  -w /tmp/cap-server-drop.pcap 'tcp port 8080'

Client에서 HTTP 요청을 보낸다.

sudo ip netns exec cap-client \
  curl --connect-timeout 3 http://10.26.2.2:8080/

예상 관찰은 다음과 같다.

Client PCAP
→ SYN과 Retransmission 보임

Router PCAP
→ veth-cri Ingress의 SYN 보임
→ veth-cro Egress에는 SYN 없음

Server PCAP
→ SYN 없음

Router Rule Counter를 확인한다.

sudo ip netns exec cap-router \
  iptables -L FORWARD -n -v --line-numbers

이 증거는 Router의 FORWARD Drop Rule과 Match했다는 범위까지 강하게 좁힌다.

PCAP만으로 Rule ID를 알게 된 것이 아니라 Rule Counter를 함께 확인했기 때문에 Policy 이유를 연결할 수 있다.

ㅁ 저장한 PCAP를 Command Line에서 비교하기

sudo tcpdump -nn -r /tmp/cap-client-drop.pcap 'tcp port 8080'
sudo tcpdump -nn -r /tmp/cap-router-drop.pcap 'tcp port 8080'
sudo tcpdump -nn -r /tmp/cap-server-drop.pcap 'tcp port 8080'

다음 표를 직접 채운다.

관찰 지점	SYN	SYN-ACK	Retransmission	해석
Client	보임	없음	보임	응답을 받지 못해 재시도
Router Ingress	보임	없음	보임	Client에서 Router까지 도착
Router Egress	없음	없음	없음	Router 내부에서 전달되지 않음
Server	없음	없음	없음	Server 도착 전 범위에서 중단

any PCAP에서는 Interface ID를 확인해 Ingress와 Egress를 분리한다.

ㅁ Drop Rule을 제거한 뒤 성공 흐름과 비교하기

Drop Rule을 제거한다.

sudo ip netns exec cap-router \
  iptables -D FORWARD \
  -i veth-cri -o veth-cro \
  -p tcp --dport 8080 -j DROP

같은 세 Capture를 새 파일 이름으로 다시 실행한다.

/tmp/cap-client-ok.pcap
/tmp/cap-router-ok.pcap
/tmp/cap-server-ok.pcap

Client에서 curl을 다시 실행한다.

sudo ip netns exec cap-client \
  curl --connect-timeout 3 http://10.26.2.2:8080/

성공 PCAP에서는 다음 흐름을 기대할 수 있다.

SYN
SYN-ACK
ACK
HTTP Request Data
HTTP Response Data
FIN 또는 Connection 종료

실패와 성공 Capture를 비교하면 정상 기준선에서 사라진 첫 사건을 찾기 쉽다.

Server Terminal의 HTTP Server를 Ctrl+C로 종료한 뒤 Namespace를 삭제한다.

sudo ip netns del cap-client
sudo ip netns del cap-router
sudo ip netns del cap-server

timeout, iptables와 tcpdump Option은 Linux 배포판과 Version에 따라 다를 수 있다.

실제 Host Firewall을 실습용으로 바꾸지 않는다.

PCAP에는 HTTP Directory Listing 같은 Payload가 포함될 수 있으므로 /tmp 파일도 실습 후 조직 정책에 맞게 삭제한다.

ㅁ 핵심 정리

Packet Capture는 특정 Host·Interface·방향·시간·Filter에서 관찰한 사실이며 Network 전체의 전지적 기록이 아니다.
도구를 열기 전에 Source, Destination, Protocol과 관찰할 사건을 질문으로 정의해야 한다.
ip link, ip addr, ip route get, ip neigh는 Local Interface, Source·Route와 Next-Hop State를 Packet보다 먼저 확인한다.
dig는 DNS Answer와 RCODE를, nc는 Transport 연결을, curl과 openssl은 TLS·Application 단계를 분리한다.
Capture Filter는 저장 전 Packet을 제외하고 Display Filter는 저장된 Packet의 화면만 좁힌다.
Snaplen, Capture Buffer, CPU·Disk와 SPAN Capacity 때문에 PCAP 자체에서 Packet이 누락될 수 있다.
Promiscuous Mode는 Switch가 해당 Port로 보내지 않은 Unicast Traffic까지 가져오지 못한다.
any Interface, Bridge와 veth Capture는 같은 논리적 Packet을 여러 번 보여 줄 수 있다.
Checksum Offload는 Host Capture의 Bad Checksum을, TSO/GSO/GRO/LRO는 Wire와 다른 Packet 크기를 만들 수 있다.
Wireshark의 tcp.analysis.*는 Header Flag가 아니라 Capture 관점의 분석 결과다.
Client의 SYN Retransmission은 응답 부재를 보여 주지만 Forward Packet과 Return Reply 중 어디에서 Drop됐는지 말하지 않는다.
Server NIC Capture에 Data가 보이는 것과 Application이 읽고 업무를 처리한 것은 다른 사건이다.
Multi-point Capture는 Packet이 마지막으로 보인 지점과 처음 사라진 지점 사이로 위치 범위를 줄인다.
정확한 Drop 이유는 Rule Counter, Conntrack, Route, Interface Counter와 Application Log를 추가로 연결해야 한다.
여러 PCAP의 One-Way 시간을 비교하려면 Clock Synchronization과 Timestamp 정확도가 필요하다.
PCAP와 TLS Key Log는 Credential과 개인정보를 포함할 수 있으므로 최소 수집, 접근 통제와 보존 정책이 필요하다.

핵심 용어: Evidence-Based Troubleshooting, Interface State, Route Lookup, Neighbor Table, dig, netcat, curl, openssl s_client, tcpdump, Wireshark, Packet Capture, PCAP, Capture Point, Capture Filter, Berkeley Packet Filter, BPF, Display Filter, Snaplen, Capture Drop, Promiscuous Mode, SPAN, Network TAP, Checksum Offload, TSO, GSO, GRO, LRO, Expert Info, Multi-point Capture, Clock Synchronization, NTP, PTP, Rule Counter, Conntrack, Application Log

Packet은 거짓말하지 않는다고 말하지만, Capture는 모든 Packet을 보지 않는다.
어느 지점에서 무엇을 보았고 무엇은 보지 못했는지 관찰 범위를 적을 때 PCAP는 추측을 줄이는 증거가 된다.

ㅁ 다음 이야기

이제 이름, Route, Neighbor, Transport, TLS와 Application을 계층별로 확인하고 Packet이 사라진 구간을 증거로 좁힐 수 있다.

마지막으로 편지 한 통의 전체 여정을 처음부터 끝까지 다시 연결할 차례다.

Browser에 URL을 입력한 순간부터 DNS, ARP, Switch, Gateway, Routing, NAT, TCP, TLS와 HTTP Response까지 어떤 순서로 움직일까? 중간 한 단계가 빠지면 어떤 증거가 남을까?

다음 글에서는 「편지 한 통의 여정을 혼자 설명할 수 있을까?」라는 질문으로 지금까지의 기술을 하나의 Packet Journey와 진단 Checklist에 연결한다.

[Network] 25. traceroute는 보이지 않는 길을 어떻게 보여줄까?

기록하는 백엔드개발자 — Mon, 27 Jul 2026 22:25:29 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

ping은 Destination까지 Echo가 왕복했는지 알려 준다.

하지만 중간에 어느 Router를 지났는지는 보여 주지 않는다.

그렇다면 traceroute는 Router의 Routing Table을 차례로 읽어 오는 것일까?

그렇지 않다.

Source는 Internet의 전체 지도를 요청할 수 없다.

대신 수명이 짧은 Probe를 보내 일부러 첫 Router에서 끝나게 하고, 다음 Probe는 두 번째 Router에서 끝나게 한다.

TTL 1인 Probe → 첫 번째 Router에서 만료
TTL 2인 Probe → 두 번째 Router에서 만료
TTL 3인 Probe → 세 번째 Router에서 만료

각 Router가 돌려준 ICMP 오류를 모으면 지나간 경로의 일부를 역으로 추론할 수 있다.

중요한 단어는 “조회”가 아니라 추론이다.

Router가 답하지 않을 수도 있고,

Probe마다 다른 길을 갈 수도 있으며,

ICMP Reply가 돌아오는 길도 Forward Path와 다를 수 있다.

이번 글에서는 TTL/Hop Limit, ICMP Time Exceeded, UDP·ICMP·TCP Probe, Hop RTT, Asymmetric Routing, ECMP, Rate Limiting, Paris Traceroute를 통해 결과가 보여 주는 범위와 빈칸의 의미를 살펴본다.

ㅁ traceroute는 왜 일부러 Packet을 만료시킬까?

IPv4 Packet의 TTL은 Router를 통과할 때마다 줄어든다.

Source가 TTL 3으로 전송
R1이 3 → 2
R2가 2 → 1
R3이 1 → 0

TTL이 0이 되면 R3은 Packet을 다음 Hop으로 전달하지 않고 폐기한다.

R3은 Source에 다음 ICMP 오류를 보낼 수 있다.

ICMP Time Exceeded
Type 11, Code 0
TTL Exceeded in Transit

Source는 오류를 보낸 Address를 보고 “TTL 3인 Probe가 이 지점에서 끝났다”는 단서를 얻는다.

traceroute는 정상 Packet의 TTL 만료를 기다리는 것이 아니라

TTL을 1부터 의도적으로 늘려 이 안전장치를 관찰 도구로 사용한다.

ㅁ 첫 번째 Hop은 어떻게 나타날까?

Source가 TTL 1인 Probe를 보낸다.

Source ── TTL 1 ──> R1

R1은 Forwarding 과정에서 TTL을 줄인다.

TTL 1 → 0

Probe는 R1을 넘어가지 못한다.

R1이 ICMP Time Exceeded를 보내면 traceroute의 첫 줄에 R1의 응답 Address와 RTT가 표시된다.

1  10.25.1.1  0.401 ms

여기서 1은 Router의 고유 번호가 아니다.

TTL 1인 Probe에 응답한 Hop이라는 뜻이다.

ㅁ 두 번째와 세 번째 Hop은 어떻게 찾을까?

다음 Probe의 TTL을 2로 설정한다.

Source ── TTL 2 ──> R1 ── TTL 1 ──> R2

R2에서 TTL이 0이 되고 Time Exceeded가 돌아오면 두 번째 Hop을 얻는다.

TTL 3도 같은 방식이다.

Source ── TTL 3 ──> R1 ── TTL 2 ──> R2 ── TTL 1 ──> R3

출력은 다음처럼 쌓인다.

1  10.25.1.1     0.401 ms
2  10.25.2.2     0.612 ms
3  10.25.3.2     0.811 ms

각 줄은 하나의 Packet이 모든 Hop을 지나며 남긴 흔적이 아니다.

TTL이 서로 다른 별개의 Probe와 Reply를 모은 결과다.

Hop 1 결과 → TTL 1 Probe
Hop 2 결과 → TTL 2 Probe
Hop 3 결과 → TTL 3 Probe

측정 도중 Route가 바뀌면 한 화면에 서로 다른 순간의 경로가 섞일 수 있다.

ㅁ Router는 원래 Probe의 무엇을 돌려줄까?

ICMP Time Exceeded에는 문제가 된 원래 IP Header와 상위 Protocol을 식별할 수 있는 원래 Packet 일부가 인용된다.

ICMP Time Exceeded
└─ Original Probe의 IP Header와 일부 Payload

traceroute는 인용된 정보를 보고 어느 TTL과 어느 Probe에 대한 응답인지 연결한다.

Probe 방식에 따라 다음 값이 단서가 될 수 있다.

UDP Source와 Destination Port
ICMP Identifier와 Sequence Number
TCP Source와 Destination Port 및 Sequence 관련 정보

ICMP 오류가 도착했다는 사실만 보는 것이 아니라

내가 보낸 어느 Probe의 오류인가를 맞추는 과정이 필요하다.

NAT나 Firewall이 Tuple을 바꾸거나 인용 영역을 충분히 전달하지 않으면 매칭이 어려워질 수 있다.

ㅁ Destination에 도착한 Probe는 왜 끝나지 않을까?

TTL이 충분히 커지면 Probe는 Destination에 도착한다.

이제 TTL이 만료되지 않으므로 Destination이 다른 방식으로 최종 응답을 보내야 한다.

종료 응답은 Probe Protocol에 따라 다르다.

Classic UDP Probe
→ 닫힌 높은 UDP Port
→ ICMP Destination Unreachable, Port Unreachable

ICMP Echo Probe
→ ICMP Echo Reply

TCP SYN Probe
→ SYN-ACK 또는 RST

IPv4 UDP Port Unreachable은 일반적으로 다음 값이다.

ICMP Type 3, Code 3

목적지의 닫힌 Port 응답은 실패가 아니라 “Probe가 Destination까지 도착했다”는 종료 신호로 사용된다.

TCP Probe도 Port가 열려 있으면 SYN-ACK, 닫혀 있으면 RST가 돌아올 수 있다.

둘 다 Destination 도달의 단서가 된다.

ㅁ traceroute는 왜 운영체제마다 다르게 보일까?

전통적인 Unix 계열 traceroute는 높은 Destination Port의 UDP Probe를 사용하는 경우가 많다.

Windows tracert는 일반적으로 ICMP Echo Probe를 사용한다.

Linux의 여러 traceroute 구현은 Option으로 ICMP 또는 TCP Probe를 선택할 수 있다.

traceroute 기본값
→ 구현에 따라 UDP 등

tracert 기본값
→ ICMP Echo 계열

TCP traceroute
→ 선택한 TCP Port로 SYN Probe

같은 Source와 Destination이라도 Probe Protocol과 Port가 다르면

Firewall Policy와 ECMP Hash가 달라져 결과도 바뀔 수 있다.

“내 traceroute와 상대의 traceroute가 다르다”는 사실을 비교하려면

먼저 사용한 Protocol, Port, Address Family와 Source Address를 맞춰야 한다.

ㅁ 세 개의 시간은 같은 Packet을 세 번 측정한 것일까?

기본 출력에서 한 Hop에 세 개의 RTT가 보일 수 있다.

5  192.0.2.5  12.1 ms  13.4 ms  11.9 ms

일반적으로 같은 TTL을 가진 Probe를 세 번 따로 보내고 각 Reply 시간을 표시한 것이다.

TTL 5, Probe 1 → 12.1 ms
TTL 5, Probe 2 → 13.4 ms
TTL 5, Probe 3 → 11.9 ms

세 Probe가 반드시 같은 Route를 통과한다고 보장할 수 없다.

ECMP가 Transport Header를 Hash에 사용하면 Probe마다 Port가 달라져 다른 Next Hop을 선택할 수도 있다.

한 줄에 서로 다른 Router Address가 나타나는 이유가 될 수 있다.

5  192.0.2.5  12.1 ms  192.0.2.9  13.4 ms  192.0.2.5  11.9 ms

ㅁ Hop의 RTT는 어느 구간의 지연일까?

Hop 5의 12 ms는 Hop 4에서 Hop 5로 가는 Link가 12ms라는 뜻이 아니다.

Source
→ TTL 5 Probe가 Hop 5까지 이동
→ Hop 5가 ICMP를 생성·처리
→ ICMP가 Return Path로 Source까지 이동

즉, 해당 Probe의 Source부터 응답 Router까지의 왕복 시간이다.

다음 요소가 섞인다.

Forward Path의 모든 Link와 Queue
Router Control Plane의 ICMP 처리와 Scheduling
ICMP Reply의 Return Path
Source의 송수신 Scheduling

Hop 4가 10ms이고 Hop 5가 30ms라고 다음처럼 단정하면 안 된다.

Hop 4 → Hop 5 Link Delay = 30 - 10 = 20ms  (확정 불가)

각 Hop의 ICMP Reply가 다른 Return Path와 우선순위를 사용할 수 있기 때문이다.

ㅁ 중간 Hop만 느리고 뒤 Hop은 빠를 수 있을까?

다음 결과를 보자.

4  192.0.2.4  8 ms
5  192.0.2.5  80 ms
6  192.0.2.6  10 ms
7  198.51.100.20  11 ms

Hop 5가 지나가는 Data Packet을 80ms씩 늦췄다면 뒤 Hop도 누적된 지연의 영향을 받을 가능성이 크다.

그런데 Hop 6과 Destination RTT는 다시 10~11ms다.

이 패턴은 Hop 5가 Transit Forwarding은 빠르게 하면서 자신에게 향한 ICMP 생성만 낮은 우선순위로 처리했을 가능성을 보여 준다.

중간 Hop의 높은 RTT
+ 이후 Hop의 정상 RTT
→ 해당 Router의 ICMP Control Plane 우선순위 가능성

중간 한 줄의 큰 숫자만 보고 병목이라고 결론 내리지 않는다. 지연이 뒤 Hop과 Destination까지 지속되는지 함께 본다.

ㅁ 별표 하나는 무엇을 뜻할까?

정해진 시간 안에 해당 Probe의 응답을 받지 못하면 *가 표시될 수 있다.

5  *  *  *

별표가 직접 증명하는 것은 다음뿐이다.

해당 TTL의 Probe에 대응하는 응답을 Timeout 안에 관찰하지 못했다.

가능한 원인은 여러 가지다.

Probe가 Forward Path에서 Drop
Router가 Time Exceeded를 만들지 않음
ICMP 생성이 Rate Limit
ICMP Reply가 Return Path에서 Drop
Firewall이 특정 Protocol이나 ICMP를 차단
Reply가 Timeout 뒤 늦게 도착
traceroute가 Reply를 원래 Probe와 매칭하지 못함

*는 Router가 없다는 표시도, 그 Router가 Down이라는 표시도 아니다.

ㅁ 별표 뒤에 다음 Hop이 다시 나타날 수 있을까?

가능하다.

4  192.0.2.4       8 ms
5  * * *
6  192.0.2.6      10 ms
7  198.51.100.20  11 ms

TTL 5인 Probe는 다섯 번째 Router에서 만료되었다. 그 Router가 Time Exceeded에 응답하지 않아 별표가 생겼다.

TTL 6인 다음 Probe는 다섯 번째 Router를 TTL이 남은 상태로 통과한다.

TTL 5 Probe
→ Hop 5에서 만료, ICMP 응답 없음

TTL 6 Probe
→ Hop 5 통과
→ Hop 6에서 만료, ICMP 응답 있음

Hop 5가 Transit Packet을 전달하지 못했다면 뒤 Hop도 보이기 어렵다.

뒤 Hop이 나타난다는 사실은 해당 지점이 Forwarding은 했지만 자신이 응답하지 않았을 가능성을 보여 준다.

ㅁ 모든 별표 뒤가 비어 있으면 어디가 끊겼을까?

다음 결과를 보자.

1  10.0.0.1       1 ms
2  192.0.2.1      5 ms
3  * * *
4  * * *
5  * * *
...

마지막 응답 Hop 다음에서 Data Forwarding이 실패했을 수 있다.

하지만 다음 가능성도 남는다.

그 뒤 경로 전체가 ICMP Time Exceeded를 차단
Probe Protocol 자체가 Firewall에서 차단
Return Path의 ICMP가 Source로 오지 못함
Destination까지 전달되지만 종료 응답이 차단
Maximum Hop 안에 Destination에 도달하지 못함

“마지막으로 보인 Router가 문제”라고 단정하면 안 된다.

마지막 응답 Router는 자신이 응답할 수 있었다는 증거일 뿐, 바로 다음 Link에서 Drop했음을 증명하지 않는다.

ㅁ Forward Path와 ICMP Return Path는 같을까?

TTL 5 Probe가 Router R5에서 만료되었다.

Probe Forward Path
Source → R1 → R2 → R3 → R4 → R5

R5의 ICMP Time Exceeded는 별도의 IP Packet이다. Source로 돌아가기 위해 R5의 Routing Table을 사용한다.

ICMP Return Path
R5 → X3 → X2 → X1 → Source

traceroute 한 줄의 Address는 Forward Probe가 만료된 지점의 응답 Source다.

그러나 RTT에는 Probe의 Forward Path와 ICMP의 Return Path가 함께 들어 있다.

화면에 보이는 Hop 목록
≠ Reply Return Path까지 모두 펼친 지도

Destination에서 Source 방향으로 실행한 Reverse Traceroute도 원래 Return Path와 같다고 보장할 수 없다. Source Address, Policy와 ECMP Hash가 달라질 수 있다.

ㅁ 응답 Address는 Router의 어느 Interface일까?

Router에는 여러 Interface Address가 있다.

R5
├─ Probe가 들어온 Interface Address
├─ Probe가 나가려던 Interface Address
├─ ICMP가 Source로 돌아갈 Interface Address
└─ Loopback Address

ICMP Time Exceeded의 Source Address 선택은 구현과 Route에 따라 달라질 수 있다.

출력된 Address가 반드시 Probe가 들어온 Interface이거나 Source와 직접 연결된 Link Address라고 단정할 수 없다.

Router의 한 Address만 보고 장비 위치와 소유자를 확정하기 어려운 이유다.

ㅁ 이름이 보이면 Router의 정체를 알 수 있을까?

기본 traceroute는 응답 IP의 Reverse DNS(PTR)를 조회해 이름을 표시할 수 있다.

5  edge-seoul.example.net (192.0.2.5)  12 ms

PTR 이름은 운영자가 붙인 Label이다.

유용한 단서가 될 수 있지만 물리 위치, 장비 역할과 소유권을 암호학적으로 증명하지 않는다.

Reverse DNS 조회가 느리거나 실패하면 traceroute 출력 자체가 늦게 보일 수도 있다.

숫자 Address만 빠르게 보려면 구현에 따라 -n Option을 사용한다.

traceroute -n 198.51.100.20

Windows에서는 tracert -d처럼 다른 Option을 사용한다.

ㅁ ECMP는 한 Hop에 여러 주소를 어떻게 만들까?

Router가 같은 Destination Prefix로 비용이 같은 Next Hop을 여러 개 가지고 있다고 하자.

            ┌→ Path A
Source → R1 ┤
            └→ Path B

ECMP는 일반적으로 Flow의 5-Tuple 같은 Header 값을 Hash해 한 Flow의 Next Hop을 선택한다.

Classic UDP traceroute가 Probe마다 Destination Port를 바꾸면 ECMP Hash도 달라질 수 있다.

TTL 5 Probe 1, UDP Dst Port 33450 → Path A
TTL 5 Probe 2, UDP Dst Port 33451 → Path B
TTL 5 Probe 3, UDP Dst Port 33452 → Path A

한 번의 출력에 실제로 동시에 사용되지 않은 여러 Flow의 경로가 섞일 수 있다.

Paris Traceroute 계열의 접근은 Flow Identifier를 일정하게 유지하면서 Probe를 구분해 Per-Flow Load Balancing이 만든 경로 혼합을 줄이려 한다.

그래도 Per-Packet Load Balancing, Route 변화와 Reply Path 차이까지 모두 제거하는 것은 아니다.

ㅁ 실제 HTTPS와 같은 길을 시험하려면 TCP 443이면 충분할까?

UDP traceroute가 차단되고 TCP 443은 허용되는 Network가 있다.

TCP Probe를 Destination Port 443으로 보내면 실제 HTTPS와 더 비슷한 Firewall Policy와 ECMP 입력을 사용할 수 있다.

Linux 구현의 예시는 다음과 같다.

sudo traceroute -T -p 443 -n server.example

하지만 완전히 같은 Flow라고 보장할 수는 없다.

Source Port가 실제 Application 연결과 다를 수 있다.
Probe의 TCP Flag와 Option이 실제 TLS 연결과 다르다.
Route가 측정 사이에 바뀔 수 있다.
Load Balancer가 Application 상태에 따라 다른 Backend를 선택할 수 있다.
Destination의 SYN-ACK 또는 RST Policy가 다를 수 있다.

Probe Protocol을 실제 Traffic과 가깝게 맞추는 것은 가설을 개선하지만 실제 Application Packet의 완전한 복제는 아니다.

ㅁ UDP, ICMP, TCP 결과가 다르면 어느 것이 맞을까?

세 결과가 서로 다를 수 있다.

UDP traceroute  → Hop 4부터 별표
ICMP traceroute → Destination까지 표시
TCP 443 trace   → Destination까지 표시

이는 하나가 거짓이고 하나가 참이라는 뜻이 아니다.

각 Probe가 다른 Policy와 Hash 조건을 통과했을 수 있다.

UDP 결과
→ UDP Probe의 관찰 경로와 응답 정책

ICMP 결과
→ ICMP Echo Probe의 관찰 경로와 응답 정책

TCP 결과
→ 해당 TCP Port Probe의 관찰 경로와 응답 정책

문제가 HTTPS라면 TCP 443 결과에 더 무게를 둘 수 있지만 실제 curl과 Packet Capture 증거를 함께 봐야 한다.

ㅁ MPLS와 Tunnel은 Hop을 숨길 수 있을까?

IP Packet이 MPLS나 Tunnel 구간을 지날 때 내부 Hop의 TTL 또는 Hop Limit이

외부 Header와 어떻게 연동되는지는 구성에 따라 다르다.

IP Router → Tunnel Ingress ═════ Tunnel Egress → IP Router
                         내부 Hop 여러 개

Tunnel 내부 Router가 traceroute에 모두 나타날 수도 있고 하나의 긴 구간처럼 숨을 수도 있다.

MPLS Label 정보가 ICMP Extension으로 보이는 환경도 있지만 모든 장비가 제공하는 것은 아니다.

따라서 Hop 수가 적다고 물리 장비와 전달 단계가 반드시 적은 것은 아니다.

Overlay Network에서는 Virtual Router와 Underlay Router의 경로를 별도로 관찰해야 할 수 있다.

ㅁ NAT를 지나면 Probe 연결 정보는 어떻게 달라질까?

NAT는 Probe의 Source Address와 UDP/TCP Port, ICMP Identifier를 바꿀 수 있다.

Return ICMP에는 변환 전후 Tuple을 연결할 State가 필요하다.

내부 Probe
10.0.0.10:33450
        ↓ NAT
203.0.113.5:40001

정상적인 Stateful NAT는 ICMP 오류에 인용된 외부 Tuple을 내부 Probe와 연결해 Source로 돌려줄 수 있다.

하지만 Fragment, 짧은 ICMP 인용, Timeout과 비대칭 경로 때문에 매칭이 실패할 수 있다.

일부 NAT 경계가 Hop으로 보이거나 내부 Address가 ICMP Payload에 남는 등 구현별 결과도 나타날 수 있다.

ㅁ Routing Loop는 어떤 모습으로 나타날까?

R1과 R2가 Destination Route를 서로에게 가리킨다고 하자.

TTL을 늘린 Probe는 두 Router 사이에서 반복해서 만료된다.

4  192.0.2.1
5  192.0.2.2
6  192.0.2.1
7  192.0.2.2
8  192.0.2.1

같은 Address가 번갈아 반복되는 패턴은 Routing Loop의 강한 단서다.

그러나 Address 반복 하나만으로 확정하지 않는다.

ICMP Source Address 선택 때문에 같은 Address가 여러 위치처럼 보일 수 있다.
ECMP Probe가 서로 다른 Path를 오갈 수 있다.
NAT와 Tunnel이 Address 표시를 바꿀 수 있다.

실제 Router의 Route Lookup, TTL별 Capture와 Interface Counter로 확인해야 한다.

TTL을 크게 늘리는 것은 Loop를 고치지 않고 Packet이 더 오래 돌게 할 뿐이다.

ㅁ 경로가 실행할 때마다 바뀌면 장애일까?

Internet Routing과 Load Balancing은 동적이다.

첫 실행: A → B → C → Destination
다음 실행: A → D → E → Destination

변화 가능한 원인은 다음과 같다.

ECMP Hash 입력 변화
BGP 또는 IGP Route 변화
Anycast Site 선택 변화
Link 장애와 Convergence
Traffic Engineering Policy
Mobile과 VPN 경로 전환

경로가 다르다는 사실만으로 장애라고 할 수 없다.

변화 시점과 Packet Loss, Destination RTT, Application Error가 함께 발생했는지 시간축으로 연결한다.

ㅁ `!H`, `!N`, `!X` 같은 표시는 무엇일까?

일부 traceroute 구현은 ICMP 오류 Code를 짧은 기호로 표시한다.

!N  Network Unreachable
!H  Host Unreachable
!P  Protocol Unreachable
!X  Communication Administratively Prohibited
!F  Fragmentation Needed 관련 표시 가능

정확한 기호와 의미는 구현마다 다르다.

이 표시는 응답 장비가 명시적인 오류를 보냈다는 단서다.

오류를 보낸 Source Address와 인용된 Probe, Type과 Code를 Capture에서 확인한다.

!H가 보였다고 반드시 최종 Destination Host가 자신이 Down이라고 답한 것은 아니다. 중간 Router가 다음 Hop에 전달하지 못해 오류를 만들 수 있다.

ㅁ IPv6 traceroute는 무엇을 바꿀까?

IPv6에서는 TTL 대신 Hop Limit을 사용한다.

Hop Limit이 Transit 중 0이 되면 Router는 다음 ICMPv6 오류를 보낼 수 있다.

ICMPv6 Time Exceeded
Type 3, Code 0
Hop Limit Exceeded in Transit

UDP Probe가 IPv6 Destination의 닫힌 Port에 도착하면 ICMPv6 Destination Unreachable, Port Unreachable을 받을 수 있다.

IPv4와 IPv6 Route, Firewall, Source Address가 다르므로 결과도 별도로 확인한다.

traceroute -4 server.example
traceroute -6 server.example

일부 운영체제는 traceroute6나 다른 Option을 사용한다.

IPv6에 필요한 ICMPv6를 일괄 차단하면 Hop 관찰뿐 아니라 PMTUD 같은 정상 기능도 깨질 수 있다.

ㅁ traceroute의 Maximum Hop은 경로의 끝일까?

도구는 무한히 TTL을 늘리지 않는다.

Maximum Hop Limit에 도달하면 Destination 응답이 없어도 측정을 끝낸다.

30  * * *
traceroute 종료

이는 Destination이 정확히 30 Hop 밖에 있다는 뜻이 아니다.

실제 경로가 더 길 수 있다.
Routing Loop로 Destination에 도달하지 못할 수 있다.
Destination 종료 응답이 차단될 수 있다.
중간부터 모든 ICMP가 보이지 않을 수 있다.

Maximum Hop과 Timeout은 측정의 종료 조건이지 Network의 물리적 경계를 선언하는 값이 아니다.

ㅁ traceroute와 mtr은 무엇이 다를까?

traceroute는 TTL을 늘린 Probe를 일정 횟수 보내 한 시점의 경로 단서를 얻는다.

mtr 계열 도구는 traceroute와 반복 측정을 결합해 Hop별 응답률과 RTT 변화를 시간에 따라 보여 줄 수 있다.

traceroute
→ 짧은 경로 Snapshot

mtr
→ 반복 Probe를 통한 변화 관찰

하지만 중간 Router의 ICMP Rate Limiting 문제는 mtr에서도 남는다.

중간 Hop Loss 80%
뒤 Hop과 Destination Loss 0%
→ 중간 Router의 ICMP 응답 제한 가능성

중간 Hop의 Loss가 뒤 Hop에 이어지지 않으면 Transit Data Loss로 곧바로 해석하지 않는다.

반복 Probe는 장비에 부담을 줄 수 있으므로 횟수와 간격을 제한하고 허가된 대상에서 사용한다.

ㅁ traceroute 결과를 어떻게 문장으로 남길까?

관찰보다 넓은 결론을 피한다.

Hop 8부터 별표다.
→ Hop 8 Router가 Down이다.  (근거 부족)

증거 범위에 맞는 기록은 다음과 같다.

10:30 KST, Client 10.0.0.10에서 Destination 198.51.100.20으로
UDP 기반 traceroute를 실행했다.
TTL 1~7 Probe에는 ICMP Time Exceeded가 돌아왔고
TTL 8 이후에는 Timeout 안에 대응 응답을 관찰하지 못했다.
같은 Source의 TCP 443 연결은 성공했다.
UDP Probe 또는 ICMP Reply Policy 차이를 우선 비교한다.

다음 정보도 함께 기록한다.

Source Host와 Address
Destination Name과 실제 선택된 Address
IPv4 또는 IPv6
Probe Protocol과 Destination Port
Probe 수, Timeout과 Maximum Hop
실행 시각
실제 Application의 성공 여부

도구 출력만 붙이지 말고 어떤 질문으로 실행했는지 남긴다.

ㅁ 진단할 때 어떤 순서로 비교할까?

DNS가 선택한 Destination Address를 확인한다.
Local Routing Table과 실제 Source Address를 확인한다.
숫자 출력으로 Reverse DNS 지연을 분리한다.
기본 UDP, ICMP, 실제 Service와 가까운 TCP Probe를 비교한다.
별표가 뒤 Hop까지 계속되는지, 다음 Hop이 다시 보이는지 확인한다.
중간 Hop의 높은 RTT와 Loss가 Destination까지 이어지는지 본다.
반대 방향 Host에서도 측정하되 원래 Return Path와 같다고 가정하지 않는다.
문제가 발생한 시각의 Route 변화와 Application Error를 연결한다.
필요한 지점에서 Packet Capture와 Router Counter를 확인한다.

traceroute는 원인을 확정하는 마지막 명령이 아니라 Capture할 지점과 비교할 Protocol을 정하는 도구다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Probe와 응답으로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
중계 가능 횟수를 1로 적은 시험 편지	TTL 1 Probe	첫 Router에서 수명이 끝나도록 전송
중계 가능 횟수를 하나씩 늘림	Incrementing TTL	각 Hop에서 차례로 Probe를 만료시킴
수명이 끝났다는 반송 안내	ICMP Time Exceeded	IPv4 Type 11 Code 0 또는 ICMPv6 Type 3 Code 0
반송장에 포함된 원래 봉투 일부	Quoted Original Packet	응답을 특정 Probe와 연결할 Header 정보
해당 중계소까지 갔다 돌아온 시간	Hop RTT	Probe Forward Path와 ICMP Return Path의 왕복 시간
반송 안내가 오지 않은 칸	* Timeout	해당 Probe의 응답을 시간 안에 관찰하지 못함
같은 횟수 편지가 서로 다른 길로 감	ECMP	Flow Hash에 따라 여러 Next Hop 중 하나를 선택
접수 번호를 고정해 길 혼합을 줄임	Paris Traceroute	Flow Identifier 변화를 줄여 Per-Flow ECMP 영향 완화
목적지의 닫힌 창구 반송	UDP Port Unreachable	Classic UDP Probe가 Destination에 도착한 종료 신호
실제 서비스 창구로 보내는 시험	TCP Traceroute	선택한 TCP Port와 유사한 Policy 경로를 관찰
안내가 돌아오는 별도 길	Asymmetric Return Path	ICMP Reply가 Probe Forward Path와 다른 Route 사용 가능

traceroute가 만드는 지도는 다음처럼 이해해야 한다.

TTL 1 Probe + Reply ─┐
TTL 2 Probe + Reply ─┤
TTL 3 Probe + Reply ─┼─> 서로 다른 관찰을 한 화면에 조합
TTL 4 Probe + Reply ─┤
...                  ┘

결과
→ 각 TTL에서 응답한 지점의 단서
→ Router의 전체 Routing Table이나 고정된 물리 지도는 아님

ㅁ Packet Capture에서 직접 확인해 보기

Classic UDP traceroute를 Capture하면 TTL이 증가하는 Probe와 ICMP Reply를 함께 볼 수 있다.

Wireshark Display Filter 예시는 다음과 같다.

icmp.type == 11 || udp.dstport >= 33434

TCP Probe를 함께 본다면 다음처럼 좁힐 수 있다.

icmp || tcp.port == 443

확인할 Field는 다음과 같다.

ip.ttl 또는 ipv6.hlim
icmp.type와 icmp.code
icmpv6.type와 icmpv6.code
인용된 Original IP Header
UDP 또는 TCP Source / Destination Port
Probe와 Reply Timestamp
ICMP Reply Source Address

한 Router에서 Capture한 Probe의 수신 TTL과 다음 Interface로 Forward된 TTL도 비교할 수 있다.

ICMP Reply는 별도의 Packet이므로 새로운 TTL, Source와 Destination, Return Route를 갖는다는 점을 확인한다.

ㅁ 격리된 Linux 환경에서 3-Hop 경로를 만들어 보기

다음 실습은 ip, iptables, tcpdump, traceroute가 있는 개인 Linux VM에서 수행한다. 네 개의 Network Namespace와 가상 Link만 사용한다.

trace-client       trace-r1          trace-r2        trace-server
10.25.1.2 ── 10.25.1.1 | 10.25.2.1 ── 10.25.2.2 | 10.25.3.1 ── 10.25.3.2

Namespace와 세 가상 Link를 만든다.

sudo ip netns add trace-client
sudo ip netns add trace-r1
sudo ip netns add trace-r2
sudo ip netns add trace-server

sudo ip link add veth-tc type veth peer name veth-r1c
sudo ip link add veth-r1r2 type veth peer name veth-r2r1
sudo ip link add veth-r2s type veth peer name veth-ts

sudo ip link set veth-tc netns trace-client
sudo ip link set veth-r1c netns trace-r1
sudo ip link set veth-r1r2 netns trace-r1
sudo ip link set veth-r2r1 netns trace-r2
sudo ip link set veth-r2s netns trace-r2
sudo ip link set veth-ts netns trace-server

Address를 설정한다.

sudo ip -n trace-client addr add 10.25.1.2/24 dev veth-tc
sudo ip -n trace-r1 addr add 10.25.1.1/24 dev veth-r1c
sudo ip -n trace-r1 addr add 10.25.2.1/24 dev veth-r1r2
sudo ip -n trace-r2 addr add 10.25.2.2/24 dev veth-r2r1
sudo ip -n trace-r2 addr add 10.25.3.1/24 dev veth-r2s
sudo ip -n trace-server addr add 10.25.3.2/24 dev veth-ts

Loopback과 Interface를 올린다.

sudo ip -n trace-client link set lo up
sudo ip -n trace-r1 link set lo up
sudo ip -n trace-r2 link set lo up
sudo ip -n trace-server link set lo up

sudo ip -n trace-client link set veth-tc up
sudo ip -n trace-r1 link set veth-r1c up
sudo ip -n trace-r1 link set veth-r1r2 up
sudo ip -n trace-r2 link set veth-r2r1 up
sudo ip -n trace-r2 link set veth-r2s up
sudo ip -n trace-server link set veth-ts up

Route를 설정한다.

sudo ip -n trace-client route add default via 10.25.1.1
sudo ip -n trace-r1 route add 10.25.3.0/24 via 10.25.2.2
sudo ip -n trace-r2 route add 10.25.1.0/24 via 10.25.2.1
sudo ip -n trace-server route add default via 10.25.3.1

두 Router Namespace에서 IPv4 Forwarding을 활성화한다.

sudo ip netns exec trace-r1 \
  sysctl -w net.ipv4.ip_forward=1

sudo ip netns exec trace-r2 \
  sysctl -w net.ipv4.ip_forward=1

Capture Terminal에서 R1을 지나는 Probe와 Reply를 저장한다.

sudo ip netns exec trace-r1 \
  tcpdump -n -vv -i any -s 0 -w /tmp/traceroute-lab.pcap \
  'icmp or udp or tcp port 8080'

Client에서 숫자 출력과 Probe 하나씩으로 Classic UDP traceroute를 실행한다.

sudo ip netns exec trace-client \
  traceroute -n -q 1 -w 1 10.25.3.2

환경이 정상이라면 R1, R2와 Destination의 응답을 차례로 기대할 수 있다.

1  10.25.1.1
2  10.25.2.2
3  10.25.3.2

ICMP Source Address 선택에 따라 표시 Address가 달라질 수 있으므로 Capture와 함께 확인한다.

ㅁ 응답하지 않는 Hop 뒤가 보이는 장면을 만들기

R2가 자신이 생성한 ICMP Time Exceeded만 Drop하게 한다.

sudo ip netns exec trace-r2 \
  iptables -I OUTPUT 1 \
  -p icmp --icmp-type time-exceeded -j DROP

같은 traceroute를 다시 실행한다.

sudo ip netns exec trace-client \
  traceroute -n -q 1 -w 1 10.25.3.2

예상 결과는 다음과 같다.

1  10.25.1.1
2  *
3  10.25.3.2

TTL 2 Probe는 R2에서 만료되지만 Time Exceeded가 R2의 OUTPUT Rule에서 Drop된다.

TTL 3 Probe는 R2를 통과해 Server에 도착하고 Server의 UDP Port Unreachable이 돌아오므로 Destination은 표시될 수 있다.

Rule Counter를 확인한다.

sudo ip netns exec trace-r2 \
  iptables -L OUTPUT -n -v --line-numbers

Rule을 제거한다.

sudo ip netns exec trace-r2 \
  iptables -D OUTPUT \
  -p icmp --icmp-type time-exceeded -j DROP

ㅁ TCP Probe와 비교해 보기

Server Terminal에서 TCP 8080을 Listen한다. nc Option은 구현마다 다를 수 있다.

sudo ip netns exec trace-server nc -l 8080

Client에서 TCP SYN Probe를 사용한다. 이 Option은 Linux traceroute 구현 기준이다.

sudo ip netns exec trace-client \
  traceroute -T -p 8080 -n -q 1 -w 1 10.25.3.2

UDP 결과와 TCP 결과의 Hop과 종료 응답을 Capture에서 비교한다.

UDP Destination 종료: ICMP Port Unreachable
TCP Open Port 종료   : SYN-ACK

TCP traceroute가 SYN-ACK을 받은 뒤 연결을 완성하지 않고 정리하는 방식은 구현에 따라 달라질 수 있다.

Server Application이 반드시 accept()까지 완료했다는 뜻은 아니다.

실습을 마치면 Namespace를 삭제한다.

내부 Firewall Rule과 가상 Interface도 함께 제거된다.

sudo ip netns del trace-client
sudo ip netns del trace-r1
sudo ip netns del trace-r2
sudo ip netns del trace-server

실제 Internet Host에 많은 Probe를 반복하지 않는다.

traceroute Option과 기본 Protocol은 운영체제와 구현마다 다르므로 Manual을 확인한다.

ㅁ 핵심 정리

traceroute는 Router의 지도를 읽는 것이 아니라 TTL 또는 Hop Limit이 다른 Probe의 만료 응답을 모아 경로를 추론한다.
IPv4 Router는 Transit 중 TTL이 끝나면 ICMP Type 11 Code 0 Time Exceeded를 보낼 수 있다.
Destination의 종료 응답은 UDP Port Unreachable, ICMP Echo Reply, TCP SYN-ACK 또는 RST처럼 Probe 방식에 따라 다르다.
한 Hop의 여러 RTT는 같은 TTL의 별도 Probe 결과이며 서로 다른 ECMP 경로를 탈 수 있다.
Hop RTT는 앞 Hop과의 Link 지연이 아니라 Source에서 해당 Router까지 갔다가 ICMP가 돌아온 왕복 시간이다.
중간 Hop만 느리고 뒤 Hop이 정상이라면 해당 Router의 ICMP Control Plane 우선순위 차이일 수 있다.
*는 해당 Probe의 응답을 Timeout 안에 보지 못했다는 뜻이며 Router Down이나 Forwarding 실패를 직접 증명하지 않는다.
응답하지 않는 Hop도 Transit Packet은 전달할 수 있으므로 별표 뒤의 Hop과 Destination이 다시 나타날 수 있다.
ICMP Reply는 별도 Return Route를 사용하므로 출력과 RTT에는 Asymmetric Path가 영향을 준다.
ECMP와 Probe Port 변화는 한 실행에 여러 Flow의 경로를 섞을 수 있고 Paris Traceroute는 이를 줄이려 한다.
UDP, ICMP와 TCP Probe는 Firewall Policy와 Hash가 달라 서로 다른 결과를 만들 수 있다.
MPLS, Tunnel, NAT와 ICMP Source Address 선택 때문에 실제 장비와 출력 Hop이 1:1로 보이지 않을 수 있다.
Reverse DNS 이름과 ICMP Address는 물리 위치와 장비 소유권의 확정적인 증명이 아니다.
IPv6에서는 Hop Limit과 ICMPv6 Type 3 Code 0 Time Exceeded를 사용한다.
traceroute는 원인을 확정하는 마지막 명령이 아니라 다음 Capture 지점과 비교할 Protocol을 정하는 도구다.

핵심 용어: traceroute, tracert, TTL, Hop Limit, Probe, Hop, ICMP Time Exceeded, ICMP Type 11 Code 0, ICMPv6 Type 3 Code 0, Quoted Packet, UDP Port Unreachable, ICMP Echo Probe, TCP SYN Probe, Hop RTT, Timeout, Rate Limiting, Control Plane, Data Plane, Asymmetric Routing, ECMP, Flow Hash, Paris Traceroute, Reverse DNS, MPLS, Tunnel, Maximum Hop, mtr

traceroute가 보여 주는 것은 고정된 길의 사진이 아니다.
서로 다른 수명의 Probe가 각 지점에서 돌려준 응답을 시간 순서로 이어 붙인 추론이다.
빈칸과 RTT도 그 응답이 보이지 않거나 늦었다는 범위 안에서 해석해야 한다.

ㅁ 다음 이야기

ping과 traceroute는 Endpoint와 중간 Router가 돌려준 응답으로 Network를 간접 관찰한다.

더 자세히 보려면 Interface를 지나는 실제 Frame과 Packet을 Capture해야 한다.

그렇다면 Wireshark에 Packet이 보이기만 하면 원인을 모두 알 수 있을까? Capture 지점 밖에서 일어난 Drop, 암호화된 Payload, Offload와 누락된 Packet은 어떻게 구분할까?

다음 글에서는 「패킷을 직접 보면 모든 원인을 알 수 있을까?」라는 질문을 통해

ip, dig, curl, nc, tcpdump, Wireshark를 계층별 질문에 연결하고

Multi-point Evidence로 원인 범위를 줄이는 방법을 살펴본다.

[바이브코딩] 03. Claude 5는 왜 Context Engineering을 이야기할까? - Prompt에서 Context로

기록하는 백엔드개발자 — Mon, 27 Jul 2026 20:28:56 +0900

TL;DR

Anthropic은 Claude 5 세대 모델을 소개하며 새로운 방향을 제시한다.

Claude Code의 시스템 프롬프트를 대폭 줄였지만 성능 저하는 크지 않았다고 설명한다.

예전에는 규칙을 많이 적을수록 AI가 안정적으로 동작했다.

Claude 5는 다른 방향을 제시한다.

규칙보다 컨텍스트가 중요하다.

이번 글에서는 AI 개발 방식이 Prompt Engineering에서 Context Engineering으로 바뀌는 이유를 정리한다.

ㅁ 이전 글에서 이야기한 Context Engineering

Context Engineering은 이번에 처음 등장한 개념이 아니다.

이전 글에서도 프롬프트의 한계와 컨텍스트의 중요성을 여러 관점에서 정리했다.

ㅇ Context Engineering 관련 글 모아보기

Prompt Engineering에서 Context Engineering으로 발전하는 과정
문서 기반 개발과 Context Engineering의 관계
SSOT, MECE를 활용한 컨텍스트 구조화
Garbage Context와 Context Pollution을 줄이는 방법
Context를 넘어 Harness Engineering으로 발전하는 과정

바이브코딩 시리즈에서도 같은 내용을 이어서 다뤘다.

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까?

PRD, UX, 기술 스택, 데이터베이스, 도메인, API의 역할을 구분한다.
하나의 결정은 하나의 문서에서 관리한다.
SSOT와 MECE를 통해 사람과 AI가 같은 기준을 보게 한다.
문서를 이전 작업의 결과이자 다음 작업의 컨텍스트로 사용한다.

ㅇ [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까?

하나의 대화에서는 하나의 주제에 집중한다.
현재 주제에 맞는 역할과 작업 범위를 지정한다.
이미 확정된 문서를 현재 작업의 기준으로 제공한다.
Plan Mode에서 방향을 논의한 뒤 결정된 내용만 문서로 남긴다.
완성한 문서를 다음 대화의 컨텍스트로 사용한다.

기존 글의 핵심은 명확하다.

좋은 프롬프트를 반복해서 작성하는 것보다 AI가 참고할 기준을 구조화하는 일이 중요하다.

지금까지는 내가 AI와 협업하며 발견한 필요성을 중심으로 Context Engineering을 정리했다.

이번에는 Claude 5를 만든 Anthropic이 같은 문제를 어떻게 바라보고 있는지 살펴본다.

ㅁ Claude 5에서 달라진 것은 무엇일까?

Claude 5가 Context Engineering이라는 새로운 개념을 만든 것은 아니다.

달라진 점은 모델의 능력이 발전하면서 컨텍스트를 구성하는 방법도 바뀌었다는 것이다.

Anthropic은 Claude 5 세대 모델을 적용하며 Claude Code의 시스템 프롬프트를 80% 이상 제거했다고 설명한다.

기존에는 모델의 실수를 막기 위해 많은 규칙을 미리 넣었다.

항상 테스트를 작성한다.
코드 리뷰 절차를 따른다.
작업 후 검증한다.
문서를 임의로 변경하지 않는다.
불필요한 주석을 작성하지 않는다.

이런 규칙은 각각 필요할 수 있다.

하지만 모든 작업에 항상 필요한 것은 아니다.

규칙이 많아지면 서로 충돌하기도 한다.

현재 작업과 무관한 정보가 컨텍스트를 차지하기도 한다.

Claude 5에서는 모든 규칙을 앞에 넣는 대신, 모델이 주변 코드와 현재 작업을 보고 판단하게 한다.

검증이 필요한 순간에는 검증 절차를 불러온다.

코드 리뷰가 필요한 순간에는 코드 리뷰 Skill을 불러온다.

배포 작업에서는 배포 문서와 설정을 확인한다.

기존 방식

모든 규칙
    ↓
모든 문서
    ↓
사용자 요청
    ↓
작업 수행

Claude 5 방식

사용자 요청
    ↓
현재 작업 판단
    ↓
필요한 문서와 Skill 선택
    ↓
작업 수행

중요한 변화는 컨텍스트의 양이 아니다.

컨텍스트를 불러오는 시점과 구조다.

ㅁ 모든 것을 제공하는 방식에서 필요한 것을 찾는 방식으로

기존 Context Engineering에서는 AI에게 충분한 정보를 제공하는 일이 중요했다.

Claude 5에서는 여기서 한 단계 더 나아간다.

모든 정보를 한 번에 제공하지 않는다.

AI가 현재 작업에 필요한 정보를 선택적으로 찾게 한다.

Anthropic은 이를 Progressive Disclosure라고 설명한다.

Progressive Disclosure는 필요한 정보를 필요한 시점에 점진적으로 공개하는 방식이다.

예를 들어 API를 구현할 때는 다음 정보를 확인한다.

CLAUDE.md
    ↓
PRD
    ↓
API 문서
    ↓
Backend Convention
    ↓
관련 코드와 테스트

배포를 검증할 때는 다른 정보를 확인한다.

CLAUDE.md
    ↓
Verification Skill
    ↓
배포 문서
    ↓
CI/CD 설정
    ↓
테스트 결과

API 구현에 배포 절차 전체를 넣을 필요는 없다.

문서 검수에 데이터베이스 운영 규칙을 모두 넣을 필요도 없다.

현재 작업에 필요한 컨텍스트만 선택한다.

내가 이전 글에서 이야기한 내용은 다음과 같다.

문서를 다음 대화의 컨텍스트로 사용한다.

Claude 5가 추가로 강조하는 내용은 다음과 같다.

그 문서를 모두 제공하지 않고, 현재 작업에 필요한 문서만 불러온다.

Context Engineering의 방향이 바뀐 것은 아니다.

적용 방법이 더 구체적으로 발전했다.

ㅁ 필요한 정보를 불러온다는 것은 무엇일까?

필요한 정보를 불러온다는 것은 모든 문서를 항상 기억하게 만드는 것이 아니다.

프로젝트 문서를 목적별로 나눈다.

현재 작업과 관련된 문서만 찾아 읽게 한다.

예를 들어 다음처럼 구성할 수 있다.

project/
├── CLAUDE.md
├── docs/
│   ├── product/
│   │   └── PRD.md
│   ├── architecture/
│   │   ├── SYSTEM.md
│   │   └── DATABASE.md
│   ├── development/
│   │   ├── BACKEND.md
│   │   └── FRONTEND.md
│   └── operations/
│       └── DEPLOYMENT.md
└── .claude/
    └── skills/
        ├── code-review/
        ├── document-review/
        └── release-check/

이 구조에서 CLAUDE.md는 모든 내용을 설명하지 않는다.

어디에서 어떤 정보를 찾아야 하는지 알려준다.

ㅁ CLAUDE.md는 규칙집이 아니라 지도다

많은 사람이 CLAUDE.md에 모든 규칙을 넣는다.

하지만 파일이 커지면 문제가 생긴다.

현재 작업과 무관한 정보까지 포함된다.
중요한 규칙과 사소한 규칙이 섞인다.
오래된 내용이 현재 기준과 충돌한다.
같은 내용이 여러 문서에 중복된다.
유지보수가 어려워진다.

Claude 5에서 CLAUDE.md는 백과사전이 아니다.

프로젝트의 지도다.

프로젝트의 목적
    ↓
공통 작업 원칙
    ↓
문서의 위치
    ↓
작업별 Skill 안내

상세 내용은 각 문서가 담당한다.

CLAUDE.md
    ↓
PRD.md
    ↓
DOMAIN.md
    ↓
API.md
    ↓
DATABASE.md
    ↓
DEPLOYMENT.md

CLAUDE.md는 모든 내용을 담지 않는다.

필요한 컨텍스트로 이동하게 한다.

ㅁ 문서는 SSOT가 되어야 한다

Context Engineering이 제대로 동작하려면 문서를 신뢰할 수 있어야 한다.

같은 요구사항이 여러 문서에 다르게 적혀 있으면 문제가 생긴다.

AI는 무엇을 기준으로 판단해야 할지 알기 어렵다.

그래서 문서는 SSOT 역할을 해야 한다.

예를 들어 다음처럼 기준을 정한다.

제품 요구사항      → PRD.md
사용자 흐름        → UX.md
도메인 규칙        → DOMAIN.md
API 계약           → API.md
데이터 구조        → DATABASE.md
배포 절차          → DEPLOYMENT.md

하나의 정보는 하나의 기준 문서에서 관리한다.

다른 문서에서는 링크로 참조한다.

이 방식은 SSOT와 MECE 원칙과 연결된다.

문서가 중복되지 않아야 한다.

역할도 명확하게 나뉘어야 한다.

그래야 AI도 필요한 컨텍스트를 정확하게 찾는다.

ㅁ Skill은 특정 작업을 위한 절차서다

문서는 프로젝트 정보를 설명한다.

Skill은 특정 작업을 수행하는 방법을 설명한다.

코드 리뷰 Skill에는 다음 절차를 넣을 수 있다.

1. 변경된 파일을 확인한다.
2. 관련 요구사항 문서를 읽는다.
3. 기존 코드 패턴과 비교한다.
4. 오류 가능성과 영향 범위를 확인한다.
5. 테스트 누락 여부를 검토한다.
6. 결과를 정해진 형식으로 작성한다.

배포 검증 Skill에는 다른 절차를 넣는다.

1. 변경 범위를 확인한다.
2. 테스트 결과를 확인한다.
3. 환경 변수를 점검한다.
4. 마이그레이션 여부를 확인한다.
5. 롤백 절차를 확인한다.
6. 배포 가능 여부를 판단한다.

이 절차를 매번 프롬프트에 입력할 필요는 없다.

Skill로 분리한다.

필요한 순간에만 불러온다.

Skill은 AI를 위한 표준 작업 절차서다.

ㅁ Prompt보다 중요한 것은 프로젝트 구조다

AI가 장기 프로젝트를 이해하려면 한 번의 멋진 문장으로는 부족하다.

AI가 정보를 찾을 수 있는 구조가 필요하다.

사람이 새로운 프로젝트에 들어가면 다음 순서로 이해한다.

프로젝트 소개를 읽는다.
시스템 구조를 본다.
필요한 문서를 찾는다.
관련 코드를 확인한다.
작업 절차를 따른다.

AI도 크게 다르지 않다.

좋은 프롬프트 하나로 모든 문제를 해결하려 하면 안 된다.

AI가 필요한 정보를 찾아갈 수 있는 환경을 만들어야 한다.

다음처럼 정리할 수 있다.

Prompt
    ↓
현재 요청을 전달한다.

Context
    ↓
요청을 이해하는 정보를 제공한다.

Structure
    ↓
정보를 찾을 수 있게 한다.

Skill
    ↓
작업 수행 절차를 제공한다.

ㅁ Claude 5는 하나의 모델이 아니다

Anthropic의 글 제목은 The New Rules of Context Engineering for Claude 5 Generation Models이다.

여기서 나는 "Claude 5"를 하나의 모델 이름으로 이해하였다.

하지만 Anthropic이 말하는 Claude 5는 특정 모델 하나가 아니다.

5세대 모델군(Generation Models) 을 의미한다.

현재 기준으로는 다음 모델이 여기에 포함된다.

Sonnet 5
Fable 5

즉, Context Engineering에 대한 새로운 권장 사항은 Claude 5 세대 전체를 대상으로 설명하는 내용이다.

반면 Opus 4.8과 Haiku 4.5는 각각 다른 계열의 모델이다.

물론 이 모델들도 Context Engineering을 활용할 수 있다.

하지만 Anthropic이 이야기하는 새로운 설계 철학은 Claude 5 세대를 중심으로 설명된다.

예를 들어 Claude Code에서 모델을 선택하면 다음과 같은 목록을 볼 수 있다.

Sonnet 5
Fable 5
Opus 4.8
Haiku 4.5

여기서 Sonnet 5와 Fable 5가 같은 세대에 속한다.

ㅁ Claude 5에서는 모델 선택도 영향을 줄까?

Context Engineering 원칙은 Claude 5 세대 모델을 중심으로 설명한다.

현재 기준으로 Sonnet 5와 Fable 5가 해당한다.

모델마다 긴 작업과 컨텍스트 탐색 능력에 차이가 있다.

Sonnet 5는 일반 개발과 문서 작업에 적합하다.

코드 수정과 일상적인 작업에 효율적이다.

Fable 5는 많은 문서와 코드를 장시간 검토하는 작업에 적합하다.

대규모 리팩터링과 긴 작업에 유리하다.

Opus 4.8과 Haiku 4.5도 컨텍스트를 활용한다.

다만 Claude 5의 새로운 작업 방식은 Sonnet 5와 Fable 5를 중심으로 이해하는 것이 자연스럽다.

모델이 좋아도 문서 구조는 필요하다.

모델의 능력이 좋아질수록 규칙을 더 많이 줄 필요는 없다.

판단에 필요한 근거와 구조를 제공해야 한다.

ㅁ AI와 오래 협업하려면 무엇이 필요할까?

AI와 한두 번 대화하는 것은 어렵지 않다.

같은 프로젝트에서 며칠이나 몇 달 동안 협업하는 것은 다르다.

안정적인 작업 흐름이 필요하다.

Plan
    ↓
작업 범위와 방향을 정한다.

Document
    ↓
결정한 내용을 문서에 반영한다.

Implement
    ↓
문서를 기준으로 구현한다.

Verify
    ↓
구현 결과를 검증한다.

Update
    ↓
변경 내용을 다시 문서에 반영한다.

이 과정에서 문서는 단순한 기록이 아니다.

사람과 AI가 함께 보는 기준이다.

대화에서 결정한 내용을 문서에 반영하지 않으면 다음 세션에서 다시 설명해야 한다.

문서로 남기면 모델이나 세션이 바뀌어도 작업을 이어갈 수 있다.

ㅁ 앞으로의 AI 개발자는 무엇을 잘해야 할까?

예전에는 코드를 많이 작성하는 사람이 생산성이 높았다.

생성형 AI가 등장한 뒤에는 좋은 프롬프트 작성 능력이 중요해졌다.

앞으로는 프로젝트 구조와 컨텍스트 설계 능력이 더 중요해질 수 있다.

사람의 역할은 단순히 명령을 작성하는 것이 아니다.

판단 기준을 정한다.
정보를 기록할 위치를 정한다.
문서 사이의 관계를 설계한다.
작업 절차를 정의한다.
검증 기준을 제공한다.

Prompt Engineer를 넘어 Context Architect의 역할이 필요하다.

ㅁ 마무리

Claude 5가 말하는 Context Engineering은 새로운 프롬프트 작성법이 아니다.

AI와 일하는 방식의 변화다.

예전에는 AI에게 더 많은 규칙을 주는 것이 중요했다.

이제는 AI가 필요한 정보를 찾고 판단할 수 있도록 프로젝트를 구조화해야 한다.

CLAUDE.md는 거대한 규칙집이 아니다.

프로젝트의 지도다.

PRD, UX, 도메인, 데이터베이스, API 문서는 각각 SSOT 역할을 해야 한다.

코드 리뷰, 문서 검수, 배포 확인 같은 반복 작업은 Skill로 분리한다.

좋은 AI 협업은 좋은 프롬프트 하나에서 시작하지 않는다.

잘 정리된 문서와 프로젝트 구조에서 시작한다.

필요한 순간에 적절한 정보를 제공하는 컨텍스트 설계가 필요하다.

앞선 글에서 이야기한 SSOT, MECE, Plan Mode, 문서화는 독립된 개념이 아니다.

모두 AI와 오래 협업하기 위한 Context Engineering의 구성 요소다.

ㅁ 참고 자료

ㅇ Anthropic, The New Rules of Context Engineering for Claude 5 Generation Models

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트

ㅇ [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트

[Network] 24. ping이 실패하면 정말 서버가 죽은 것일까?

기록하는 백엔드개발자 — Sun, 26 Jul 2026 22:24:42 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

서비스에 접속되지 않을 때 가장 먼저 떠올리는 명령이 있다.

ping server.example

응답이 오면 “Network는 정상”이라고 말하고, 응답이 없으면 “Server가 죽었다”고 말하기 쉽다.

하지만 ping이 묻는 질문은 그보다 좁다.

이 Destination을 향한 ICMP Echo Request가 전달되고
누군가 Echo Reply를 만들며
그 Reply가 다시 이 Host까지 돌아올 수 있는가?

HTTP Port가 열려 있는지, TLS Certificate가 유효한지, Application이 요청을 처리할 수 있는지는 묻지 않는다.

반대로 Echo Reply가 없다고 Destination Host가 반드시 꺼져 있는 것도 아니다.

Firewall이 ICMP만 차단하거나 Reply의 Return Path가 끊겼을 수 있다.

진단 도구의 결과를 정확히 쓰려면 “무엇을 증명했는가?”와 “무엇은 아직 모르는가?”를 함께 적어야 한다.

이번 글에서는

ICMP Echo Request/Reply, Identifier, Sequence Number, Round-Trip Time(RTT), Packet Loss, TTL/Hop Limit, Destination Unreachable을 따라가며 ping의 관찰 범위를 정리한다.

ㅁ ping은 어느 Protocol로 대화할까?

일반적인 ping은 Internet Control Message Protocol(ICMP)의 Echo Message를 사용한다.

IPv4에서는 다음 Type과 Code를 사용한다.

Echo Request
Type 8, Code 0

Echo Reply
Type 0, Code 0

IPv6에서는 ICMPv6의 Type이 다르다.

ICMPv6 Echo Request
Type 128, Code 0

ICMPv6 Echo Reply
Type 129, Code 0

TCP나 UDP처럼 Destination Port를 지정하지 않는다.

ping 198.51.100.20:443  (X)

ping은 Host의 특정 Web Service가 아니라 IP 계층의 ICMP 응답 가능성을 관찰한다.

ㅁ Echo Message에는 무엇이 들어 있을까?

ICMP Echo Message의 대표적인 Field는 다음과 같다.

Type
Code
Checksum
Identifier
Sequence Number
Data

ㅇ Identifier

한 Host에서 여러 ping Process가 동시에 실행될 때 Request와 Reply를 구분하는 단서로 사용할 수 있다.

운영체제와 구현에 따라 Process ID나 별도 값에서 정할 수 있지만 항상 Process ID와 같다고 단정할 수는 없다.

ㅇ Sequence Number

각 Echo Request의 순서를 표시한다.

icmp_seq=1
icmp_seq=2
icmp_seq=3

어느 Request의 Reply가 사라졌거나 순서가 바뀌었는지 확인하는 데 도움이 된다.

TCP Sequence Number처럼 Byte Stream의 위치를 나타내는 번호는 아니다.

ㅇ Data

크기와 Pattern을 조절할 수 있는 Payload다. 일부 구현은 전송 시각을 넣어 RTT 계산에 사용할 수 있다.

ㅇ Checksum

전송 오류를 탐지한다. 공격자가 다시 계산할 수 있으므로 TLS 같은 암호학적 Integrity나 상대 Authentication을 제공하지 않는다.

ㅁ Hostname을 ping하면 ICMP부터 보낼까?

ping server.example처럼 이름을 사용하면 먼저 이름을 IP Address로 바꿔야 한다.

1. Resolver가 server.example 조회
2. A 또는 AAAA Address 선택
3. 선택한 Address로 ICMP Echo Request 전송

DNS가 실패하면 Echo Request 자체를 한 번도 보내지 못한다.

ping: unknown host
ping: cannot resolve

이 결과는 Destination이 ICMP에 응답하지 않았다는 뜻이 아니다.

Hostname ping 실패
→ DNS 단계 또는 Address 선택 문제 가능

IP Address ping 성공
→ ICMP 경로는 되지만 이름 조회 문제 가능

진단할 때 이름과 IP를 나누어 시험하는 이유다.

dig server.example
ping 198.51.100.20
ping server.example

명령과 Option은 운영체제에 따라 다를 수 있다.

ㅁ Echo Request가 나가기 전에도 여러 단계가 필요하다

Destination Address를 알았다고 Packet이 즉시 Wire로 나가는 것은 아니다.

Host는 다음 과정을 거친다.

Destination이 같은 Subnet인가?
        ↓
Routing Table에서 Route 선택
        ↓
Outgoing Interface와 Next Hop 결정
        ↓
ARP 또는 NDP로 Next-Hop Link Address 확인
        ↓
ICMP Echo Request를 Frame에 실어 전송

따라서 ping 실패는 Destination Host 하나만의 문제가 아닐 수 있다.

Local Interface가 Down
Address나 Subnet Mask 오류
Route 없음
Default Gateway 오류
ARP/NDP 실패
Local Firewall의 Outbound Drop
Network Namespace나 VRF를 잘못 선택

Echo Request가 Local Host를 실제로 떠났는지 Capture로 확인해야 원격 Host를 의심할 근거가 생긴다.

ㅁ Echo Reply가 오려면 어떤 길이 완성되어야 할까?

Echo Request는 Forward Path를 지나 Destination에 도착한다.

Destination IP Stack이 Echo Reply를 만들면 Reply는 Return Path를 따라 돌아온다.

Source
  │ Echo Request
  ▼
Forward Path
  │
  ▼
Destination
  │ Echo Reply
  ▼
Return Path
  │
  ▼
Source

Forward Path가 정상이어도 Return Route가 없으면 Source는 Reply를 받지 못한다.

Request는 Destination 도착
Reply는 Return Path에서 Drop
Source에서 본 결과: Timeout

한쪽에서 응답이 없다는 사실만으로 어느 방향이 끊겼는지 알 수 없다.

양 Endpoint와 중간 지점의 Capture가 필요한 이유다.

ㅁ ping 성공은 정확히 무엇을 증명할까?

ping Reply 하나를 받았다면 최소한 다음 사실의 증거가 생긴다.

선택한 Source에서 Echo Request를 보낼 수 있었다.
Request가 해당 Address에 응답하는 지점까지 도달했다.
그 지점이 Echo Reply를 생성했다.
Reply가 Source까지 돌아왔다.
해당 시점의 ICMP 왕복이 완료됐다.

그러나 다음까지 증명하지는 않는다.

TCP 443이 열려 있다.
TLS Handshake가 성공한다.
Certificate가 유효하다.
HTTP가 200을 응답한다.
Database와 Dependency가 정상이다.
사용자 요청의 업무 처리가 성공한다.
다음 Packet도 반드시 같은 경로로 성공한다.

ping 성공은 ICMP Reachability의 긍정적인 증거이지 모든 Layer의 Health Check가 아니다.

ㅁ 누가 Echo Reply를 보냈는지도 항상 단순할까?

Destination IP가 하나의 물리 Server만을 가리킨다고 보장할 수 없다.

Anycast Address를 여러 지점이 광고할 수 있다.
Load Balancer나 Network Appliance가 Address를 소유할 수 있다.
High Availability 전환으로 응답 장비가 바뀔 수 있다.
NAT와 Tunnel 때문에 실제 Application Server와 ICMP 응답 지점이 다를 수 있다.

VIP가 ping에 응답
≠ 뒤의 모든 Backend가 정상

Echo Reply의 Source IP와 Capture 위치, 실제 Service Architecture를 함께 확인해야 한다.

ICMP Echo 자체에는 TLS Certificate 같은 암호학적 상대 인증이 없다.

공격자가 Packet을 위조할 수 있는 환경에서는 Reply를 받았다는 사실만으로 응답 주체의 강한 Identity까지 증명하지 못한다.

ㅁ ping 실패는 무엇을 의미할까?

Echo Reply를 받지 못했다면 다음 중 하나 이상일 수 있다.

Echo Request를 보내지 못함
Echo Request가 Forward Path에서 Drop
Destination이 Echo Request를 무시
Destination가 Down
Echo Reply가 Return Path에서 Drop
ICMP가 Rate Limit
응답이 Timeout보다 늦게 도착
Packet 크기가 Path MTU 문제를 만남

ping 실패가 증명하는 것은 좁다.

정해진 시간과 조건 안에서 기대한 Echo Reply를 관찰하지 못했다.

“Server Down”은 가능한 가설 중 하나일 뿐이다.

ㅁ Firewall이 ICMP만 막을 수 있을까?

Firewall은 Protocol과 ICMP Type별로 다른 Policy를 적용할 수 있다.

TCP 443                 ALLOW
ICMP Echo Request       DROP
ICMP Fragmentation Needed ALLOW
ICMP Time Exceeded      Rate Limit

이 환경에서는 HTTPS가 정상이어도 ping은 실패할 수 있다.

ping 실패
curl 성공

반대로 ICMP Echo를 허용하고 TCP 443을 차단할 수도 있다.

ping 성공
curl Timeout

“ICMP 허용 여부”와 “Application Service 허용 여부”는 별도의 Firewall Rule이다.

ㅁ ICMP를 모두 막는 것이 안전할까?

ICMP에는 Echo 외에도 IP 전달에 필요한 오류와 제어 메시지가 있다.

Destination Unreachable
Fragmentation Needed
Time Exceeded
Parameter Problem

IPv6에서는 Neighbor Discovery와 Packet Too Big 같은 ICMPv6 기능이 정상 동작에 중요하다.

Echo Request에 응답하지 않겠다는 Policy와 모든 ICMP를 Drop하는 Policy는 다르다.

ICMP Echo를 제한
≠ ICMP 전체를 차단

Type, Code, Direction, Rate와 관련 Connection State를 기준으로 필요한 Control Traffic을 구분해야 한다.

ㅁ ping 출력의 한 줄은 무엇을 뜻할까?

Linux 계열의 설명용 출력은 다음처럼 보일 수 있다.

64 bytes from 198.51.100.20: icmp_seq=1 ttl=52 time=18.4 ms

각 항목을 나누어 보자.

64 bytes
→ 구현이 보고한 ICMP Message 크기

from 198.51.100.20
→ Echo Reply의 Source Address

icmp_seq=1
→ 어느 Echo Request에 대한 Reply인지 나타내는 Sequence

ttl=52
→ Reply가 Source에 도착했을 때 남은 IPv4 TTL

time=18.4 ms
→ Request 전송부터 Reply 수신까지 측정한 RTT

출력 형식과 Byte 계산은 구현마다 다르다.

예를 들어 Linux의 일반적인 기본값에서 ICMP Data 56바이트에 ICMP Header 8바이트를 더해 64 bytes라고 표시할 수 있고, IPv4 Header 20바이트까지 포함한 IP Packet은 84바이트가 될 수 있다.

ICMP Data   56
ICMP Header  8
IPv4 Header 20
----------------
IP Total    84

Ethernet Frame 전체 크기는 여기에 Link Layer Header와 Trailer가 더 필요하다.

ㅁ RTT는 어디까지의 시간일까?

Round-Trip Time(RTT)은 Source에서 Request를 보내고 Reply를 받을 때까지의 왕복 시간이다.

RTT
= Forward Path 전송과 Queue 대기
+ Destination 처리 시간
+ Return Path 전송과 Queue 대기
+ 양 Endpoint의 Scheduling 영향

RTT 20ms라고 Forward와 Return이 각각 10ms였다고 단정할 수 없다.

Forward  3ms + Return 17ms = RTT 20ms
Forward 15ms + Return  5ms = RTT 20ms

일반 ping의 RTT만으로 One-Way Delay와 어느 방향의 지연인지 분리할 수 없다.

One-Way Delay를 정확히 비교하려면 양 Endpoint의 Clock Synchronization과 별도 측정 설계가 필요하다.

ㅁ 첫 번째 Reply만 느리면 Network가 불안정할까?

명령 실행 후 첫 결과가 나오기 전에는 다음 준비가 추가로 필요할 수 있다.

DNS Cache Miss
ARP 또는 NDP Neighbor Resolution
Route와 Neighbor Cache 생성
무선 절전 상태 해제
방화벽이나 Tunnel의 초기 State 생성

DNS Resolution 시간은 일반적으로 각 Echo Reply 줄의 time=으로 표시되는 ICMP RTT에 포함되지 않지만,

사용자가 명령을 실행한 뒤 첫 결과를 보기까지의 시간에는 영향을 준다.

첫 Echo Request 자체는 ARP/NDP와 State 준비 때문에 대기할 수 있으며

정확히 어느 시간이 RTT에 포함되는지는 구현과 측정 지점에 따라 확인해야 한다.

이후 Packet은 이미 만들어진 Cache와 State를 사용할 수 있어 더 빨라질 수 있다.

icmp_seq=1 time=25 ms
icmp_seq=2 time=3 ms
icmp_seq=3 time=3 ms

첫 값 하나만으로 지속적인 Network 지연이라고 결론 내리지 않는다.

반대로 첫 Packet을 항상 버리고 나머지만 평균 내면 실제 사용자가 겪는 Connection Setup 비용을 놓칠 수 있다.

측정 목적에 따라 Cold Start와 Steady State를 구분한다.

ㅁ Packet Loss는 어떻게 계산할까?

ping은 보낸 Echo Request 수와 받은 Echo Reply 수로 Loss 비율을 계산한다.

5 packets transmitted
4 packets received

Packet Loss = (5 - 4) ÷ 5 × 100
            = 20%

이 결과는 보낸 ICMP Echo Sample 중 Reply를 받지 못한 비율이다.

같은 시간의 TCP Application Packet도 정확히 20% 손실되었다는 뜻은 아니다.

Router와 Host는 Control Plane 보호를 위해 ICMP Echo를 Rate Limit하거나 낮은 우선순위로 처리할 수 있다.

ICMP Echo Loss 20%
TCP Service Traffic 정상

가능한 장면이다.

반대로 ICMP는 잘 통과하지만 특정 Queue, DSCP Class, Tunnel 또는

큰 Packet에서 Application Traffic만 손실될 수도 있다.

ㅁ 평균 RTT만 보면 충분할까?

설명용 통계가 다음과 같다고 하자.

min/avg/max/mdev = 10.1/20.0/80.2/15.4 ms

min: 관찰한 Sample 중 가장 작은 RTT
avg: 산술 평균 RTT
max: 가장 큰 RTT
mdev 또는 stddev: RTT 변동 폭을 나타내는 통계

평균이 같아도 사용자 경험은 다를 수 있다.

경로 A: 19, 20, 21ms
경로 B: 5, 5, 50ms

평균은 비슷할 수 있지만 변동성은 다름

실시간 음성과 Game은 평균 RTT뿐 아니라 변동, 흔히 Jitter라고 부르는 현상과 Loss에 민감하다.

다만 ping 출력의 mdev와 Application이 정의하는 Jitter 지표가 항상 같은 계산은 아니다.

Sample 수와 간격, 크기, 시간대를 함께 기록해야 비교가 의미 있다.

ㅁ Reply의 TTL로 Router 수를 정확히 알 수 있을까?

출력의 ttl=52는 Reply가 Source에 도착했을 때 남은 TTL이다.

Destination이 처음 설정한 Initial TTL을 알면 지나온 Hop 수를 추정할 수 있다.

가정한 Initial TTL 64
- 도착 TTL 52
= 약 12 Hop

그러나 Initial TTL은 운영체제와 설정에 따라 64, 128, 255 등 다를 수 있다.

중간 Tunnel과 장비가 TTL 처리에 영향을 줄 수도 있다.

도착 TTL만 알고 Initial TTL은 모름
→ 정확한 Hop 수를 확정할 수 없음

TTL 값으로 운영체제나 경로 길이를 추측할 수는 있지만 확정적인 Identity 증명으로 사용하면 안 된다.

각 Hop을 관찰하려는 질문은 다음 글의 traceroute가 더 직접적으로 다룬다.

ㅁ Sequence가 빠지거나 순서가 바뀌면 무엇을 볼까?

다음 Reply를 받았다고 하자.

icmp_seq=1
icmp_seq=3
icmp_seq=2

2번이 늦게 도착해 Reply 순서가 바뀌었다.

가능한 원인은 다음과 같다.

ECMP나 경로 변화
서로 다른 Queue 지연
Wireless 재전송
Endpoint Scheduling

같은 Sequence의 Reply가 여러 번 오면 Duplicate Packet이나 중복 응답일 수 있다.

한 번의 Reordering만으로 Routing Loop나 심각한 장애를 단정하지 않는다.

Capture에서 IP ID, ICMP Identifier, Sequence, 시간과 경로 변화를 함께 본다.

ㅁ Timeout과 Unreachable은 같은 실패일까?

응답이 전혀 없으면 ping은 Timeout처럼 보일 수 있다.

Request timeout

이는 Request 또는 Reply가 사라졌다는 뜻일 뿐 Drop 위치와 이유를 알려 주지 않는다.

반면 Host나 Router가 명시적인 ICMP 오류를 돌려줄 수도 있다.

Destination Network Unreachable
Destination Host Unreachable
Communication Administratively Prohibited

오류 문장만 보지 말고 누가 ICMP 오류를 보냈는지 확인한다.

Local Host가 Network Unreachable 생성
→ Local Route 문제 가능

First-Hop Router가 Host Unreachable 생성
→ 다음 Hop의 ARP 실패나 Route 문제 가능

중간 Firewall이 Administratively Prohibited 생성
→ 해당 정책 지점에서 거절 가능

ICMP 오류도 잘못 생성되거나 중간에서 바뀌고 차단될 수 있으므로 Source Address와 인용된 원래 Packet을 확인한다.

명시적인 오류는 Silent Timeout보다 원인 범위를 줄이는 강한 단서지만 최종 판결은 아니다.

ㅁ Destination Host Unreachable이면 Destination이 답했을까?

이 문장은 실제 Destination Host가 보냈다는 뜻이 아닐 수 있다.

같은 Subnet의 Destination MAC Address를 찾지 못한 Source가 오류를 만들 수도 있고,

중간 Router가 다음 Hop으로 전달하지 못해 만들 수도 있다.

From 10.22.1.1 Destination Host Unreachable

이 경우 10.22.1.1이 오류 생성 지점이라는 단서다.

원래 ping 대상과 오류 메시지의 Source를 구분해서 읽어야 한다.

ㅁ IPv4와 IPv6 중 어느 쪽을 시험했을까?

Hostname에 A와 AAAA Record가 모두 있으면

ping 구현과 운영체제 정책에 따라 IPv4 또는 IPv6 Address를 선택할 수 있다.

IPv4 ping 성공
IPv6 ping 실패

또는

IPv6 ping 성공
IPv4 ping 실패

한쪽 결과로 Dual-Stack 전체를 판단하면 안 된다.

환경에 따라 다음처럼 Address Family를 명시할 수 있다.

ping -4 server.example
ping -6 server.example

일부 운영체제는 ping6 같은 별도 명령을 사용하며 Option이 다를 수 있다.

IPv6 Link-Local Address는 어느 Interface의 Scope인지 함께 지정해야 할 수 있다.

fe80::1%eth0

같은 Address 문자열이라도 Source Address, Interface와 Network Namespace가 다르면 경로가 달라진다.

ㅁ Source Address를 바꾸면 결과가 달라질까?

Interface가 여러 개인 Host는 Destination Route에 따라 Source Address와 Outgoing Interface를 선택한다.

Firewall, Policy Routing과 Return Route는 선택한 Source에 따라 다르게 동작할 수 있다.

Source 10.0.0.10 → 성공
Source 192.168.0.10 → Return Route 없어 실패

Linux 계열에서는 환경에 따라 -I로 Interface나 Source Address를 지정할 수 있다.

ping -I eth0 198.51.100.20
ping -I 10.0.0.10 198.51.100.20

권한과 Option은 구현마다 다르다.

Container, Pod, VRF와 Network Namespace 안에서 발생한 장애라면

Host Shell이 아니라 실제 Traffic이 시작되는 Network Context에서 시험해야 한다.

Host에서 ping 성공
≠ Container에서도 같은 Route와 Policy로 성공

ㅁ 작은 ping은 되는데 큰 ping만 실패할 수 있을까?

Echo Data 크기를 늘리면 IP Packet 전체 크기도 커진다.

Ethernet MTU 1500, IPv4 Header 20바이트, ICMP Header 8바이트를 가정하면 다음과 같다.

ping Data 1472
+ ICMP Header 8
+ IPv4 Header 20
= IP Packet 1500

DF가 설정된 1501바이트 Packet은 PMTU 1500 경로에서 전달되지 못한다.

기본 크기 ping 성공
큰 DF ping 실패
→ Path MTU와 ICMP Fragmentation Needed 경로 조사

Linux의 설명용 명령은 다음과 같다.

ping -M do -c 2 -s 1472 198.51.100.20

-M과 -s의 의미는 운영체제마다 다르므로 해당 시스템의 Manual을 확인한다.

큰 Ping 실패가 곧 일반적인 작은 TCP Segment 실패는 아니지만 MTU Black Hole 가설을 시험하는 단서가 된다.

ㅁ ping이 느리면 Application도 같은 만큼 느릴까?

ICMP RTT는 Network 지연의 한 Sample이다.

Application 응답 시간에는 더 많은 단계가 포함된다.

DNS Resolution
+ TCP/QUIC Handshake
+ TLS Handshake
+ Request 전송
+ Server Queue와 업무 처리
+ Database와 외부 API
+ Response 전송
= 사용자가 느끼는 전체 시간

반대로 Network 장비가 ICMP를 낮은 우선순위로 처리하면

ping RTT만 높고 Application Traffic은 정상일 수 있다.

Service Latency를 측정하려면 실제 Protocol과 요청을 사용해야 한다.

curl -v --connect-timeout 3 https://server.example/
openssl s_client -connect server.example:443 -servername server.example

ICMP와 Application 측정을 경쟁시키는 것이 아니라 서로 다른 계층의 증거로 조합한다.

ㅁ 어디부터 ping해야 할까?

무작정 먼 Destination부터 시험하기보다 범위를 단계적으로 넓힌다.

ㅇ 1. Loopback

ping 127.0.0.1

Local IP Stack의 기본 동작을 본다. 성공해도 NIC와 외부 Network는 지나지 않았다.

ㅇ 2. 자신의 Interface Address

ping 10.22.1.2

Local Address 설정을 확인한다. 이 역시 Packet이 실제 Link를 왕복했다고 보장하지 않는다.

ㅇ 3. 같은 Link의 Default Gateway

ping 10.22.1.1

Local Interface, VLAN, ARP/NDP와 첫 Hop까지의 단서를 얻는다. Gateway가 Echo를 차단하면 실패할 수 있다.

ㅇ 4. Remote Address

ping 198.51.100.20

Routing된 ICMP 왕복을 시험한다.

ㅇ 5. Hostname

ping server.example

DNS Resolution과 선택된 Address까지 포함해 비교한다.

각 단계의 성공과 실패 경계가 원인 범위를 줄인다.

다만 중간 장비가 ICMP를 차단하면 그 경계가 실제 Data Path 장애 위치와 같지는 않을 수 있다.

ㅁ Service 상태는 무엇으로 확인할까?

ICMP 다음에는 실제 Service와 같은 Protocol을 시험한다.

질문: TCP Port가 열려 있는가?
도구: nc, telnet, TCP SYN 관찰

질문: TLS가 성공하는가?
도구: openssl s_client, curl -v

질문: HTTP가 정상 응답하는가?
도구: curl, Application Health Endpoint

질문: 업무 기능이 정상인가?
도구: 실제 Transaction과 Server Log

Linux와 macOS의 nc Option은 구현마다 다르지만 다음처럼 TCP 연결을 시험할 수 있다.

nc -v -w 3 198.51.100.20 443

TCP 연결 성공은 TLS와 HTTP 성공을 보장하지 않는다. 계층마다 다음 질문으로 한 단계씩 올라간다.

ㅁ 진단 결과를 어떻게 문장으로 써야 할까?

좋지 않은 결론은 관찰보다 범위가 넓다.

ping 실패
→ Server Down이다.  (근거 부족)

증거 범위에 맞는 문장은 다음과 같다.

10:30부터 10:35까지 Client A에서 198.51.100.20으로
IPv4 ICMP Echo Request 20개를 보냈지만 Echo Reply를 받지 못했다.
같은 시각 TCP 443 연결은 성공했다.
따라서 Host 전체 장애보다 ICMP Policy 또는 Echo 처리 차이를 우선 조사한다.

또 다른 예시다.

ICMP Echo Reply는 RTT 3ms로 돌아왔다.
TCP 443 SYN에는 응답이 없었다.
따라서 IP/ICMP 왕복 경로는 확인했지만 TCP 443 Policy와 Service 상태는 미확인이다.

도구 이름이 아니라 Source, Destination, Address Family, Protocol, 시간과 관찰 결과를 기록한다.

ㅁ Monitoring에서 ping 하나만 사용하면 무엇을 놓칠까?

ICMP Monitor는 가볍고 많은 Host의 기본 Reachability와 RTT 변화를 보기 좋다.

하지만 다음 장애를 놓칠 수 있다.

Web Process Down
TLS Certificate 만료
Database Dependency 장애
특정 API의 권한 또는 업무 오류
큰 Response에서만 발생하는 MTU 문제
DNS가 잘못된 Address를 반환하는 문제

반대로 Echo Rate Limit 때문에 Service가 정상인데 ICMP Monitor만 Alarm을 낼 수도 있다.

ICMP Check
+ TCP Port Check
+ TLS Certificate Check
+ HTTP Health Check
+ 실제 업무 Synthetic Transaction

여러 Layer의 Monitor를 조합하고 각 Alarm이 의미하는 범위를 분리한다.

ㅁ ping을 많이 보내면 더 정확해질까?

Sample이 늘면 일시적인 변동과 지속적인 현상을 구분하는 데 도움이 된다.

그러나 높은 빈도와 큰 Payload로 무제한 Probe를 보내면 Network와 Destination의 Control Plane에 부담을 준다.

ping -f 같은 Flood Option은 권한이 필요할 수 있으며 운영 Network와 허가받지 않은 Host에서 사용하면 안 된다.

관찰 목적에 맞는 간격, 횟수, Payload를 사용한다.

진단 목적: 짧은 구간에서 제한된 Sample
Monitoring : 합의된 주기와 Rate Limit
Load Test  : 별도 승인과 전용 도구

ICMP Rate Limit이 있는 환경에서는 Probe 빈도를 높일수록 오히려 인위적인 Loss를 만들 수 있다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Message와 관찰 범위로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
답장을 요청하는 빈 엽서	ICMP Echo Request	IPv4 Type 8 또는 ICMPv6 Type 128의 도달성 Probe
받은 엽서를 되돌려 보냄	ICMP Echo Reply	IPv4 Type 0 또는 ICMPv6 Type 129의 응답
여러 시험 엽서를 구분하는 접수표	Identifier	같은 ping Session의 Request와 Reply를 연결하는 단서
몇 번째 시험인지 적은 번호	ICMP Sequence Number	Loss, Reordering과 Duplicate Reply를 구분
보내고 답장을 받기까지 걸린 시간	RTT	Forward와 Return Path를 합친 왕복 시간
보냈지만 돌아오지 않은 엽서 비율	Packet Loss	관찰한 Echo Sample 중 Reply가 없던 비율
답장에 남은 중계 횟수	Reply TTL / Hop Limit	Reply가 Source에 도착했을 때 남은 수명 값
배달할 수 없다는 반송 안내	ICMP Destination Unreachable	Host나 Router가 전달 실패 이유를 알리는 오류
답장을 하지 않는 접수 정책	ICMP Filtering / Rate Limiting	Service 상태와 무관하게 Echo 응답을 제한할 수 있음
작은 엽서는 되지만 큰 엽서는 실패	Path MTU 문제	Packet 크기에 따라 전달 결과가 달라짐

ping 결과의 논리적 범위를 한 그림으로 모으면 다음과 같다.

Echo Reply 수신
        ↓
해당 Source·Destination·Address Family에서
그 시점의 ICMP 왕복은 확인
        ↓
TCP Port, TLS, HTTP, 업무 Health는 별도 확인

Echo Reply 미수신
        ↓
정해진 조건에서 Reply를 관찰하지 못함
        ↓
Local 전송, Forward Path, ICMP Policy,
Destination, Return Path 중 어디인지는 추가 증거 필요

ㅁ Packet Capture에서 직접 확인해 보기

IPv4 Echo Message를 보는 Wireshark Display Filter는 다음과 같다.

icmp.type == 8 || icmp.type == 0

ICMPv6 Echo는 다음과 같다.

icmpv6.type == 128 || icmpv6.type == 129

Command Line에서는 Interface를 지정해 관찰할 수 있다.

sudo tcpdump -n -vv -i eth0 'icmp or icmp6'

다음 Field를 비교한다.

Source / Destination IP
ICMP Type / Code
Identifier
Sequence Number
IPv4 TTL 또는 IPv6 Hop Limit
Packet Length
Request와 Reply의 Timestamp 차이

Source에서 Request만 보이고 Reply가 없다면

Source가 Packet을 보냈다는 증거는 생겼지만 Destination 도착 여부는 아직 모른다.

Destination Capture에서 Request가 보이면 Forward Path는 좁혀지고,

Reply도 보냈는데 Source에 없으면 Return Path를 조사한다.

ㅁ 격리된 Linux 환경에서 두 반례를 만들어 보기

다음 실습은 ip, iptables, tcpdump, python3, curl이 있는 개인 Linux VM에서 수행한다.

실제 Host Firewall이 아니라 새 Network Namespace 안에서만 ICMP를 차단한다.

ping-client                ping-router               ping-server
10.24.1.2 ────────── 10.24.1.1 | 198.51.100.1 ──── 198.51.100.2

Namespace와 가상 Link를 만든다.

sudo ip netns add ping-client
sudo ip netns add ping-router
sudo ip netns add ping-server

sudo ip link add veth-pc type veth peer name veth-pri
sudo ip link add veth-pro type veth peer name veth-ps

sudo ip link set veth-pc netns ping-client
sudo ip link set veth-pri netns ping-router
sudo ip link set veth-pro netns ping-router
sudo ip link set veth-ps netns ping-server

Address와 Interface를 설정한다.

sudo ip -n ping-client addr add 10.24.1.2/24 dev veth-pc
sudo ip -n ping-router addr add 10.24.1.1/24 dev veth-pri
sudo ip -n ping-router addr add 198.51.100.1/24 dev veth-pro
sudo ip -n ping-server addr add 198.51.100.2/24 dev veth-ps

sudo ip -n ping-client link set lo up
sudo ip -n ping-router link set lo up
sudo ip -n ping-server link set lo up
sudo ip -n ping-client link set veth-pc up
sudo ip -n ping-router link set veth-pri up
sudo ip -n ping-router link set veth-pro up
sudo ip -n ping-server link set veth-ps up

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n ping-client route add default via 10.24.1.1
sudo ip -n ping-server route add default via 198.51.100.1
sudo ip netns exec ping-router \
  sysctl -w net.ipv4.ip_forward=1

Router Capture Terminal에서 ICMP와 HTTP Traffic을 저장한다.

sudo ip netns exec ping-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/ping-scope.pcap \
  'icmp or tcp port 8080'

Server Terminal에서 간단한 HTTP Server를 실행한다.

sudo ip netns exec ping-server \
  python3 -m http.server 8080 --bind 198.51.100.2

정상 상태에서 Client가 ICMP와 HTTP를 각각 시험한다.

sudo ip netns exec ping-client \
  ping -c 2 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

두 요청이 모두 성공하는지 확인한다.

ㅁ ping 실패와 Service 성공을 만들어 보기

Router가 Client에서 Server로 가는 ICMP Echo Request만 Drop하게 한다.

sudo ip netns exec ping-router \
  iptables -I FORWARD 1 \
  -i veth-pri -o veth-pro \
  -p icmp --icmp-type echo-request -j DROP

다시 두 명령을 실행한다.

sudo ip netns exec ping-client \
  ping -c 2 -W 1 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

예상 관찰은 다음과 같다.

ping: Echo Reply 없음
curl: HTTP Response 수신

Rule Counter를 확인한다.

sudo ip netns exec ping-router \
  iptables -L FORWARD -n -v --line-numbers

ICMP Drop Rule을 제거한다.

sudo ip netns exec ping-router \
  iptables -D FORWARD \
  -i veth-pri -o veth-pro \
  -p icmp --icmp-type echo-request -j DROP

ㅁ ping 성공과 Service 실패를 만들어 보기

Server Terminal의 python3 -m http.server를 Ctrl+C로 종료한다.

Client에서 다시 시험한다.

sudo ip netns exec ping-client \
  ping -c 2 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

예상 관찰은 다음과 같다.

ping: Echo Reply 수신
curl: TCP RST 또는 Connection Refused

Host의 IP Stack과 ICMP는 동작하지만 TCP 8080에 Listening Socket이 없기 때문이다.

Capture에서 Echo Reply와 TCP SYN 뒤의 RST를 비교한다.

실습을 마치면 Namespace를 삭제한다. 내부 Firewall Rule과 가상 Interface도 함께 제거된다.

sudo ip netns del ping-client
sudo ip netns del ping-router
sudo ip netns del ping-server

ping -W Option의 단위와 지원 여부는 구현마다 다르다. 실제 운영 Network에 ICMP 차단 Rule을 추가하지 않는다.

ㅁ 핵심 정리

IPv4 ping은 ICMP Type 8 Echo Request와 Type 0 Echo Reply를 사용하고 IPv6에서는 Type 128과 129를 사용한다.
ICMP Echo에는 Port가 없으며 Identifier와 Sequence Number로 Request와 Reply를 구분한다.
Hostname을 ping할 때 DNS가 실패하면 Echo Request를 보내기 전 단계에서 멈춘다.
Echo Request 전에도 Route, Outgoing Interface와 ARP/NDP Neighbor Resolution이 필요하다.
Echo Reply는 Forward Path와 Return Path가 모두 성립하고 ICMP Policy가 허용되어야 Source에 도착한다.
ping 성공은 해당 시점의 ICMP 왕복 증거이며 TCP Port, TLS, HTTP와 업무 처리를 보장하지 않는다.
ping 실패는 정해진 조건에서 Reply를 보지 못했다는 뜻이며 Host Down, 경로, Firewall, Rate Limit과 Return Path가 모두 후보다.
RTT는 양방향 지연과 처리 시간을 합친 값이므로 One-Way Delay를 직접 분리하지 못한다.
ICMP Packet Loss와 Application Traffic의 Loss는 Policy와 Queue가 달라 같지 않을 수 있다.
Reply TTL은 남은 값이며 Initial TTL을 모르면 정확한 Hop 수를 확정할 수 없다.
Timeout과 명시적인 Destination Unreachable은 제공하는 정보량이 다르고 오류의 Source를 확인해야 한다.
IPv4와 IPv6, Source Address, Interface, Namespace가 달라지면 같은 Destination도 결과가 달라질 수 있다.
작은 Echo와 큰 DF Echo의 결과 차이는 Path MTU 문제의 단서가 된다.
진단은 Loopback, Local Address, Gateway, Remote IP, Hostname과 실제 Service 순서로 증거 범위를 넓힌다.
Monitoring은 ICMP뿐 아니라 TCP, TLS, HTTP와 업무 Transaction Check를 계층별로 조합해야 한다.

핵심 용어: ping, Internet Control Message Protocol, ICMP, ICMPv6, Echo Request, Echo Reply, ICMP Type 8, ICMP Type 0, ICMPv6 Type 128, ICMPv6 Type 129, Identifier, ICMP Sequence Number, Round-Trip Time, RTT, Packet Loss, Jitter, TTL, Hop Limit, Destination Unreachable, Request Timeout, ICMP Filtering, Rate Limiting, Path MTU, Source Address, Address Family

ping은 Server의 생사를 판정하는 망치가 아니다. 특정 Source에서 특정 Address로 보낸 ICMP Echo가 왕복했는지 묻는 작은 질문이다. 답이 오든 오지 않든 그 범위를 넘어선 결론에는 다른 계층의 증거가 필요하다.

ㅁ 다음 이야기

ping은 Destination까지의 ICMP 왕복 여부와 시간을 보여 주지만 중간에 어떤 Router를 지났는지는 알려 주지 않는다.

어느 Hop까지 Packet이 갔는지 보려면 일부러 TTL이 작은 Probe를 보내 중간 Router에서 수명을 끝내야 한다.

그런데 traceroute의 * * *는 그 Router가 고장 났다는 뜻일까?

화면에 보이는 경로는 Forward Path 그 자체일까?

다음 글에서는 「traceroute는 보이지 않는 길을 어떻게 보여줄까?」라는 질문을 통해

TTL, ICMP Time Exceeded, UDP·ICMP·TCP Probe, Asymmetric Path와 Rate Limiting을 살펴본다.

[바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트

기록하는 백엔드개발자 — Sun, 26 Jul 2026 07:41:50 +0900

TL;DR

AI와 긴 프로젝트를 진행할 때는 전체 작업을 한꺼번에 맡기지 않는다.

하나의 대화에서는 하나의 주제만 다루고, AI에게 그 주제에 맞는 역할을 부여한다.

이미 확정된 문서를 컨텍스트로 제공한 뒤 Plan Mode에서 범위와 결과물을 먼저 정리한다.

AI의 제안과 사용자의 결정을 구분하고, 대화 전체가 아니라 확정된 내용만 문서로 남긴다.

그 문서를 다음 대화의 컨텍스트로 사용하는 반복 과정이 컨텍스트 엔지니어링이다.

AI가 지금 무엇을 위해, 어떤 역할로, 어떤 정보를 참고하고, 어디까지 작업해야 하는지를 명확하게 준비하는 과정이다.

ㅁ 들어가며

AI와 짧은 작업을 할 때는 한 번의 요청만으로도 충분할 수 있다.

문장을 다듬거나 작은 아이디어를 정리하는 일이라면 결과를 바로 확인하고 수정하면 된다.

하지만 하나의 서비스를 만드는 일은 다르다.

여러 번의 대화가 이어지고, 결정해야 할 주제가 계속 바뀐다.

서비스의 목적을 정한 사람과 화면을 설계하는 AI가 같은 기준을 보지 않으면 프로젝트는 쉽게 흔들린다.

이럴 때 필요한 것은 더 화려한 프롬프트가 아니라 대화를 결정으로 바꾸고, 그 결정을 다음 대화에 전달하는 반복 방식이다.

하나의 주제 선택
      │
      ▼
페르소나 지정
      │
      ▼
기존 문서 제공
      │
      ▼
Plan Mode 토론
      │
      ▼
불필요한 확장 제거
      │
      ▼
핵심 결정
      │
      ▼
문서화
      │
      ▼
다음 단계의 컨텍스트로 사용

이 흐름을 차례로 살펴보자.

ㅁ AI에게 모든 일을 한꺼번에 맡기면 왜 흔들릴까?

긴 프로젝트에는 서로 다른 종류의 질문이 들어 있다.

어떤 서비스를 만들 것인지 정하는 질문,

사용자가 무엇을 보게 될지 정하는 질문,

어떤 기술적 방향이 적합한지 검토하는 질문,

어떤 정보를 관리할지 정하는 질문

은 서로 연결되어 있지만 같은 질문은 아니다.

이 모든 것을 한 번에 요청하면 AI는 빈칸을 채우기 위해 범위를 넓히기 쉽다.

사용자가 지금 원하는 것은 서비스의 목적을 정하는 일인데, AI는 화면과 기술, 데이터 구조, 향후 기능까지 한꺼번에 제안할 수 있다.

많은 답을 받는다고 프로젝트가 더 선명해지는 것은 아니다.

현재 결정할 주제와 나중에 다룰 주제가 섞이면 오히려 무엇부터 선택해야 할지 어려워진다.

AI와의 협업은 “전체 프로젝트를 알아서 완성해 달라”고 맡기는 방식보다,

한 번에 하나의 결정을 함께 완성하는 방식에 가깝다.

ㅁ 하나의 대화에서는 왜 하나의 주제만 다뤄야 할까?

대화를 시작하기 전에 먼저 이번에 결정할 주제를 하나 고른다.

서비스의 목적을 정하는 대화라면 화면의 색상이나 개발 방법으로 넘어가지 않는다.

사용자 경험을 정하는 대화라면 이미 확정된 목적을 기준으로 사용자가 어떤 순서로 행동하는지에 집중한다.

예를 들어 프로젝트의 주제를 다음처럼 나눌 수 있다.

서비스의 목적
사용자 경험
기술적 방향
데이터 구조
기능 인터페이스
작업 계획

이 목록은 모든 프로젝트가 반드시 따라야 할 고정된 절차가 아니다.

중요한 것은 서로 다른 종류의 결정을 구분하는 것이다.

한 단계의 결과를 문서로 확정한 뒤, 그 문서를 들고 다음 주제로 이동한다.

식당을 준비하는 과정으로 생각하면 더 쉽다.

지금 식당의 콘셉트를 정하고 있다면 메뉴판 디자인이나 주방 설비를 함께 결정하지 않는다.

콘셉트가 정해진 뒤에야 다음 담당자가 그 기준을 이어받을 수 있다.

ㅁ AI에게 역할을 부여하면 무엇이 달라질까?

주제를 골랐다면 AI에게 현재 작업에 맞는 역할을 부여한다.

역할을 부여하는 이유는 AI에게 더 많은 권한을 주기 위해서가 아니다.

오히려 생각할 관점을 제한하기 위해서다.

같은 식당을 보더라도 메뉴 기획자, 주방 설계자, 요리사, 운영 담당자가 집중하는 부분은 다르다.

현재 주제	AI에게 부여할 역할
서비스 목적	서비스 기획자
사용자 흐름	UX 설계자
기술 방향	기술 책임자
블로그 재구성	기술 콘텐츠 에디터

역할과 함께 제외할 범위도 알려 주면 관점이 더 분명해진다.

너는 지금 서비스 기획자다.
Speed Quiz의 목적과 핵심 사용자 경험만 정리한다.
기술 구현이나 화면 세부 내용은 확장하지 않는다.

이 요청에서 중요한 부분은 “서비스 기획자”라는 이름보다 “무엇에 집중하고 무엇을 확장하지 않는가”라는 경계다.

좋은 페르소나는 AI를 더 자유롭게 만드는 것이 아니라 현재 주제에 머물게 한다.

ㅁ 기존 문서를 왜 먼저 제공해야 할까?

새 대화를 시작할 때마다 이전 과정을 처음부터 설명할 필요는 없다.

이미 확정된 문서를 제공하면 된다.

예를 들어 서비스의 목적과 요구사항이 PRD에 정리되어 있다면, 사용자 경험을 논의할 때 그 PRD를 먼저 제공한다.

AI는 “어떤 서비스를 만들고 있는가”를 다시 추측하지 않고, 확정된 목적을 기준으로 다음 질문에 집중할 수 있다.

이때 관련 문서를 모두 한꺼번에 넣는 것이 항상 좋은 것은 아니다.

현재 작업에 필요한 기준만 선택해야 한다.

화면 흐름을 논의하는데 검토 중인 기술 아이디어나 오래된 메모까지 함께 주면 어떤 정보가 우선인지 다시 모호해질 수 있다.

문서를 제공할 때는 세 가지를 분명히 한다.

이 문서가 현재 작업의 기준이라는 점
문서에서 이미 확정된 내용을 임의로 바꾸지 않는다는 점
문서에 없는 내용은 추측하지 않고 필요한 경우 질문한다는 점

문서는 AI가 모든 것을 기억하게 만드는 장치가 아니다.

지금 필요한 기억을 정확히 선택해 주는 장치다.

ㅁ Plan Mode에서는 무엇을 확인해야 할까?

기존 문서를 제공했다면 바로 최종 결과를 만들기보다 Plan Mode에서 이번 작업의 경계를 확인한다.

Plan Mode는 단순히 실행을 늦추는 단계가 아니다.

결과를 만들기 전에 무엇을 결정해야 하는지 함께 검토하고, 잘못된 방향으로 빠르게 달려가는 일을 줄이는 과정이다.

이때 다음 다섯 가지를 확인한다.

이번에 결정할 내용은 무엇인가?
이미 확정된 내용은 무엇인가?
아직 결정되지 않은 내용은 무엇인가?
이번 단계에서 제외할 내용은 무엇인가?
최종 결과물은 어떤 형태인가?

AI가 너무 많은 내용을 제시하면 범위를 다시 줄인다.

- 지금은 화면 구성만 다룬다. 기술 구현은 다음 단계에서 정리한다.
- 현재 목적에 필요한 내용만 남긴다. 확장 아이디어는 이번 문서에 포함하지 않는다.

충분히 논의한다는 것은 아이디어를 끝없이 늘린다는 뜻이 아니다.

어떤 선택지가 있는지 살펴보고, 지금 필요한 것만 남기는 일이다.

ㅁ AI의 제안과 사용자의 결정은 어떻게 구분할까?

AI가 제시한 내용은 검토할 수 있는 제안이다.

그럴듯하고 구체적으로 보이더라도 사용자가 채택하기 전까지는 확정된 요구사항이 아니다.

이 구분이 없으면 대화 중 잠깐 나온 아이디어가 다음 단계에서 반드시 구현해야 할 기능처럼 바뀔 수 있다.

AI는 자신이 앞서 제안한 내용을 문맥의 일부로 보고 계속 발전시킬 수 있기 때문이다.

따라서 대화 중에는 상태를 명확하게 표시한다.

제안: 검토 중이며 아직 채택하지 않은 내용
확정: 사용자가 선택했고 다음 작업의 기준이 되는 내용
제외: 이번 범위에서 다루지 않기로 한 내용

AI의 역할은 선택지를 정리하고 놓친 관점을 보여 주는 것이다.

무엇을 채택할지는 사용자가 결정한다.

바이브 코딩은 AI가 방향을 대신 정하는 과정이 아니라, 사용자가 AI의 도움을 받아 결정을 더 빠르게 구체화하는 과정이다.

ㅁ 왜 대화 전체를 문서로 남기면 안 될까?

하나의 대화에는 최종 결정만 들어 있지 않다.

질문, 중간 아이디어, 잘못 이해한 내용, 제외하기로 한 제안도 함께 남아 있다.

이 대화 전체를 다음 단계의 기준으로 사용하면 AI는 다시 무엇이 중요한지 해석해야 한다.

검토만 했던 기능을 확정된 요구사항으로 받아들이거나, 이미 수정한 내용을 이전 답변에서 다시 가져올 수도 있다.

대화가 끝나면 다음 순서로 정리한다.

이번 대화에서 결정한 내용을 고른다.
목적과 맞지 않는 제안은 제외한다.
결정된 내용을 짧고 명확하게 다시 쓴다.
아직 검토 중인 내용은 확정된 결정과 구분한다.
하나의 주제에 맞는 문서로 저장한다.

문서는 대화의 요약본과도 조금 다르다.

대화에서 무슨 말을 했는지를 줄이는 것이 아니라, 다음 작업에 필요한 결정만 남기는 것이 목적이다.

이 과정을 거치면 대화는 사라져도 결정은 남는다.

사용자는 프로젝트의 방향을 계속 통제할 수 있고, AI는 다음 작업에서 참고할 명확한 기준을 얻는다.

ㅁ 문서를 다음 대화의 컨텍스트로 어떻게 사용할까?

확정된 문서는 다음 대화의 출발점이 된다.

서비스 목적을 정리한 문서는 UX를 논의할 때 사용하고, 확정된 UX 문서는 기술적 방향을 검토할 때 참고한다.

각 문서는 이전 단계의 결정을 보존하면서 다음 단계가 임의로 출발하지 않게 한다.

이때 다음 대화에는 긴 이전 대화 대신 필요한 문서와 현재 작업의 지시를 제공한다.

이 PRD는 확정된 기준이다.
너는 UX 설계자의 관점에서 사용자가 보게 될 화면과 이용 순서만 검토한다.
기술 선택과 구현 방법은 이번 범위에서 제외한다.
먼저 결정할 내용과 확인이 필요한 내용을 정리한다.

이것은 특별한 프롬프트 문법이 아니다.

목적, 역할, 기준 문서, 작업 범위, 기대 결과물을 분명히 전달한 예시다.

문서를 다음 컨텍스트로 사용하는 순간, 문서는 단순한 기록이 아니라 사람과 AI 사이의 공통 기억이 된다.

ㅁ 이 반복 과정은 왜 컨텍스트 엔지니어링일까?

컨텍스트 엔지니어링이라는 말은 어렵게 들리지만, 핵심은 간단하다.

AI가 지금 무엇을 위해, 어떤 역할로, 어떤 정보를 참고하고, 어디까지 작업해야 하는지를 명확하게 준비하는 과정이다.

이를 다섯 가지 요소로 정리할 수 있다.

요소	확인할 질문
목적	이번 작업을 왜 하는가?
역할	AI는 어떤 관점으로 검토해야 하는가?
참고 문서	무엇이 이미 확정된 기준인가?
작업 범위	이번에는 어디까지 다루는가?
기대 결과물	대화, 초안, 확정 문서 중 무엇을 만드는가?

컨텍스트 엔지니어링은 프롬프트를 길게 쓰는 기술만을 뜻하지 않는다.

좋은 기준 문서를 만들고, 현재 작업에 필요한 문서만 고르고, AI가 집중할 범위와 역할을 제공하는 전체 과정에 가깝다.

여기에 SSOT와 MECE 원칙을 적용하면 기준은 더 선명해진다.

하나의 결정은 하나의 문서에서 관리하고, 각 문서는 겹치지 않는 역할을 맡되 필요한 내용은 빠짐없이 담는다.

그러면 AI가 충돌하는 정보를 임의로 조합하거나 비어 있는 부분을 추측할 가능성을 줄일 수 있다.

물론 구조화된 컨텍스트가 AI의 오류나 할루시네이션을 완전히 없애 주는 것은 아니다.

다만 어떤 정보를 우선해야 하는지 분명하게 만들고, 불필요한 추측이 필요한 상황을 줄여 준다.

ㅁ Speed Quiz에는 이 방식을 어떻게 적용했을까?

Speed Quiz는 이 협업 방식을 설명하기 위한 사례다.

중요한 것은 어떤 기능을 어떤 코드로 만들었는지가 아니라, 하나의 서비스를 만들기 위한 결정을 어떻게 나누고 연결했는가다.

먼저 “어떤 서비스를 만들 것인가”라는 주제를 다루고 그 결과를 PRD로 남겼다.

다음 대화에서는 PRD를 기준으로 사용자가 보게 될 흐름을 정리했다.

그 다음에는 확정된 목적과 경험을 바탕으로 기술적 방향을 검토했다.

각 단계에서 AI에게 현재 주제에 맞는 역할을 부여했고, 이번에 다루지 않을 범위를 함께 정했다.

AI가 제시한 모든 내용을 요구사항으로 채택하지 않고, 필요한 결정만 골라 문서에 남겼다.

그렇게 만들어진 문서가 다음 단계의 컨텍스트가 되었다.

Speed Quiz의 사례를 한 줄로 정리하면 다음과 같다.

하나의 주제를 논의한다 → 결정만 문서로 남긴다 → 그 문서로 다음 주제를 시작한다.

이 방식이라면 사용자가 처음부터 모든 개발 지식을 알고 있을 필요는 없다.

지금 결정할 질문을 분명하게 만들고, AI와 함께 선택지를 검토하고, 확정된 결과를 다음 단계에 전달하면 된다.

ㅁ 마무리 — 대화는 사라져도 결정은 남아야 한다

AI와 긴 프로젝트를 시작하기 전에 다음 내용을 확인해 보자.

지금 대화에서 다룰 주제는 하나인가?
AI에게 현재 주제에 맞는 역할을 주었는가?
이미 확정된 문서를 기준으로 제공했는가?
이번 단계에서 제외할 범위를 밝혔는가?
AI의 제안과 사용자의 결정을 구분했는가?
대화 전체가 아니라 확정된 내용만 문서로 남겼는가?
그 문서를 다음 대화의 컨텍스트로 사용할 수 있는가?

이 질문에 답할 수 있다면 프로젝트 전체를 한꺼번에 지시하지 않아도 된다.

사용자는 매 단계에서 하나의 결정에 집중하고, AI는 현재 역할과 범위에 집중할 수 있다.

바이브 코딩의 핵심은 AI에게 모든 일을 맡기는 것이 아니다.

사용자가 목적과 범위를 결정하고, AI가 그 결정을 구체화하도록 돕고, 문서가 다음 협업을 이어 주게 만드는 것이다.

처음부터 완벽한 문서를 만들 필요도 없다.

지금 결정한 내용을 분명하게 남기고, 다음 대화에서 그 문서를 정확한 기준으로 사용하는 것부터 시작하면 된다.

그렇게 쌓인 문서는 어느 순간 하나의 서비스를 만들기 위한 설계가 되어 있을 것이다.

ㅁ 함께 읽으면 좋은 글

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트

- PRD부터 API까지 문서의 역할과 SSOT·MECE 원칙

ㅇ Context Note — AI 대화의 컨텍스트는 왜 “쌓지 않고 구조화”해야 할까?

- ChatGPT와 함께 컨텍스트를 문서 중심으로 관리하기 위해 만든 도구이다.

- GPT Atlas에서 트리 구조의 노트, 마크다운 편집기, ChatGPT 대화창을 함께 사용하며 필요한 컨텍스트를 구조화할 수 있다.

[Network] 23. 우체부를 믿지 않고도 편지 내용을 지킬 수 있을까?

기록하는 백엔드개발자 — Sat, 25 Jul 2026 22:23:26 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 7. 인터넷의 주소를 함께 쓰고 경계를 지키는 법

ㅁ 들어가며

Firewall이 HTTPS 통신을 허용했다.

Packet은 집의 Router와 ISP, 여러 중간 Router를 지나 Server에 도착한다.

그 경로의 모든 장비를 믿어야만 Password와 결제 정보를 보낼 수 있다면 인터넷은 안전한 업무 공간이 되기 어렵다.

경로에서 일어날 수 있는 위협을 세 가지로 나누어 보자.

도청
→ 편지 내용을 몰래 읽음

변조
→ 전달 중 내용을 바꿈

사칭
→ 공격자가 진짜 Server인 척함

암호화 하나만으로 세 문제를 모두 해결할 수는 없다.

Confidentiality
→ 허가되지 않은 사람이 내용을 읽지 못하게 함

Integrity
→ 전달 중 내용이 바뀌었는지 확인함

Authentication
→ 통신 상대의 Identity를 확인함

Transport Layer Security(TLS)는 이 속성을 결합해 신뢰할 수 없는 Network 위에 보호된 Application Channel을 만든다.

이번 글에서는 TLS 1.3의 ClientHello, ServerHello, Key Exchange, Certificate Chain, CertificateVerify, Finished, AEAD, Session Resumption을 따라가며 HTTPS가 해결하는 문제와 해결하지 않는 문제를 구분한다.

ㅁ 자물쇠만 채우면 상대를 믿을 수 있을까?

Client와 공격자가 암호화된 연결을 만들었다고 하자.

그 연결 안의 내용은 중간의 다른 사람에게 보이지 않을 수 있다.

하지만 Client가 공격자를 진짜 Bank Server로 착각했다면 안전한 암호화가 공격자와의 비밀 통로를 만들어 준 셈이다.

Client ↔ 암호화 ↔ Attacker

Encryption 성공
Server Authentication 실패

반대로 진짜 Server의 Certificate를 확인했지만 Application Data를 평문으로 보내면 경로에서 내용이 노출될 수 있다.

TLS가 여러 단계를 사용하는 이유다.

상대가 제시한 Public Key는 누구의 것인가?
그 Public Key에 대응하는 Private Key를 실제로 가지고 있는가?
양쪽이 만든 Session Key가 같은가?
Handshake 메시지가 중간에서 바뀌지 않았는가?
이후 Application Data를 안전하게 보호할 수 있는가?

하나의 자물쇠가 아니라 서로 다른 증명을 연결해야 한다.

ㅁ HTTPS는 HTTP와 다른 Transport Protocol일까?

일반적인 HTTP/1.1과 HTTP/2의 HTTPS 연결은 TCP 위에 TLS를 놓고 그 안에 HTTP를 전달한다.

HTTP Application Message
        ↓
TLS Record
        ↓
TCP Byte Stream
        ↓
IP Packet

연결 순서는 다음과 같다.

1. DNS로 Server Address 확인
2. TCP 3-Way Handshake
3. TLS Handshake
4. 보호된 HTTP Request와 Response

TCP Handshake 성공은 TLS 성공이 아니고, TLS 성공은 HTTP 요청 처리 성공이 아니다.

TCP 성공 + TLS 인증서 오류
→ Port와 경로는 열렸지만 보안 연결 실패

TLS 성공 + HTTP 500
→ 보호된 Channel은 생겼지만 Application 처리 실패

HTTP/3는 TCP 대신 UDP 기반 QUIC을 사용하고 TLS 1.3 Handshake를 QUIC 연결 설정에 통합한다.

계층의 배치는 다르지만 상대 인증, Key 합의와 보호된 Application Data라는 목표는 같다.

ㅁ TLS는 왜 비대칭키와 대칭키를 함께 사용할까?

Public Key Cryptography는 상대 인증과 Key Agreement에 유용하다.

하지만 대용량 Application Data를 모두 Public Key 연산으로 처리하는 것은 비효율적이다.

대칭키 암호는 같은 Secret Key를 공유한 뒤 많은 Data를 빠르게 보호하는 데 적합하다.

TLS는 역할을 나눈다.

Public Key Cryptography
├─ Certificate의 Signature 검증
├─ Server의 Private Key 소유 증명
└─ Ephemeral Key Agreement와 인증 연결

Symmetric Cryptography
├─ Handshake Message 보호
└─ Application Data의 Encryption과 Integrity

Certificate가 Web Page 전체를 직접 암호화하는 것도 아니고,

Server Private Key가 매 TCP Segment를 암호화하는 것도 아니다.

Handshake에서 공유 Secret을 만들고 그로부터 방향별 Traffic Key를 파생한 뒤 대칭키로 TLS Record를 보호한다.

ㅁ TLS Handshake 전에 TCP는 무엇을 끝냈을까?

TCP 기반 TLS를 가정하자.

먼저 TCP 연결이 만들어진다.

Client → Server : SYN
Server → Client : SYN-ACK
Client → Server : ACK

이 단계가 확인하는 것은 TCP Endpoint와 양방향 Byte Stream이다.

아직 다음은 확인하지 않았다.

Server Certificate가 유효한가?
접속한 Hostname과 Certificate가 일치하는가?
Application Data를 암호화할 Key가 있는가?
HTTP Message가 보호되는가?

TCP 연결 위에서 TLS Handshake가 별도로 시작되는 이유다.

ㅁ 첫 번째 보안 인사 — ClientHello

Client는 ClientHello로 자신이 지원하는 조건과 Key Agreement 재료를 보낸다.

TLS 1.3의 대표적인 내용은 다음과 같다.

ClientHello
├─ Supported Versions
├─ Cipher Suites
├─ Supported Groups
├─ Signature Algorithms
├─ Key Share
├─ Server Name Indication(SNI)
├─ Application-Layer Protocol Negotiation(ALPN) 제안
└─ Random과 Extension

ㅇ Supported Versions

Client가 사용할 수 있는 TLS Version을 알린다.

ㅇ Cipher Suites

TLS 1.3 Cipher Suite는 주로 Application Data를 보호할 AEAD 알고리즘과 Hash 조합을 나타낸다.

TLS 1.2 시대의 이름처럼 Certificate Signature와 Key Exchange 방식까지 Cipher Suite 이름 하나에 모두 넣는 구조로 이해하면 안 된다. Supported Groups와 Signature Algorithms 같은 Extension이 별도로 역할을 나눈다.

ㅇ Key Share

Client가 Ephemeral Diffie-Hellman 계열 Key Agreement에 사용할 Public 값을 보낸다.

Private 값 자체를 Network로 보내는 것은 아니다.

ㅇ SNI

하나의 IP Address에서 여러 Domain을 서비스할 때 Client가 원하는 Server Name을 알릴 수 있다.

일반적인 ClientHello의 SNI는 중간 장비에 보일 수 있다. Encrypted ClientHello(ECH)를 사용하는 구성에서는 ClientHello의 민감한 부분을 암호화할 수 있지만 지원과 구성에 따라 관찰 가능성은 달라진다.

ㅇ ALPN

Client가 h2, http/1.1처럼 TLS 위에서 사용할 Application Protocol 후보를 제안한다.

Port 443만으로 HTTP Version을 결정하는 것이 아니다.

ㅁ 두 번째 보안 인사 — ServerHello

Server는 Client가 제시한 조건에서 사용할 Version, Cipher Suite와 Key Share를 선택해 ServerHello를 보낸다.

ServerHello
├─ Selected TLS Version
├─ Selected Cipher Suite
├─ Server Key Share
└─ Random 등

Client와 Server는 상대의 Public Key Share와 자신의 Ephemeral Private 값을 이용해 같은 Shared Secret을 계산할 수 있다.

Client가 계산한 Shared Secret
= Server가 계산한 Shared Secret

Network로 Shared Secret 자체를 전송하지 않음

공격자가 Public Key Share를 Capture해도 Ephemeral Private 값을 모르면 같은 Secret을 계산하기 어렵도록 설계한다.

TLS 1.3에서는 ServerHello 뒤의 Handshake Message가 파생된 Handshake Traffic Key로 보호되기 시작한다.

Passive Capture에서 TLS 1.3 Certificate가 평문으로 보이지 않을 수 있는 이유다.

ㅁ Server가 선택한 Application Protocol은 어디에서 알릴까?

Server는 EncryptedExtensions에서 ClientHello의 여러 Extension에 대한 선택 결과를 전달한다.

예를 들어 ALPN으로 선택한 Application Protocol이 들어갈 수 있다.

ClientHello ALPN Offer
├─ h2
└─ http/1.1

EncryptedExtensions ALPN Selection
└─ h2

TLS 1.3에서는 EncryptedExtensions가 ServerHello 이후 암호화된 Handshake 영역에 있다.

Client가 HTTP/2를 원했다고 항상 h2가 선택되는 것은 아니다.

양쪽이 공통으로 지원하고 Server Policy가 허용한 결과가 선택된다.

ㅁ Certificate에는 무엇이 들어 있을까?

Server는 자신의 Identity와 Public Key를 연결한 X.509 Certificate와 필요한 Chain을 보낸다.

Leaf Certificate의 대표 정보는 다음과 같다.

Subject 또는 Identity 정보
Subject Alternative Name(SAN)
Public Key
Issuer
Serial Number
Validity: Not Before / Not After
Key Usage와 Extended Key Usage
Issuer의 Digital Signature

Certificate에는 Server의 Public Key가 들어 있다.

Server의 Private Key는 들어 있지 않으며 외부로 보내면 안 된다.

Certificate 배포 가능
Private Key 비밀 유지

Certificate 파일과 Private Key 파일을 같은 것으로 생각하면 안 된다.

ㅁ 인증서 체인은 왜 여러 장일까?

Web PKI의 일반적인 Chain은 다음과 같다.

Root CA Certificate
        ↓ 서명
Intermediate CA Certificate
        ↓ 서명
Server Leaf Certificate

Client는 Server가 보낸 Leaf와 Intermediate를 따라가며 자신이 이미 신뢰하는 Root CA에 도달할 수 있는지 확인한다.

Server는 보통 Leaf와 필요한 Intermediate를 보내고 Root Certificate는 보내지 않거나 보내도 신뢰의 근거가 되지 않는다.

Root를 신뢰하는 이유는 Network에서 방금 받았기 때문이 아니라

Client 운영체제나 Browser의 Trust Store에 미리 신뢰 대상으로 설치되어 있기 때문이다.

Server가 Root를 함께 보냄
≠ Client가 그 Root를 자동 신뢰

누구나 자기 이름으로 Root와 Certificate를 만들 수 있다.

중요한 것은 Client가 어떤 Trust Anchor를 어떤 절차로 신뢰하도록 구성했는가다.

ㅁ Certificate Signature는 무엇을 증명할까?

Intermediate CA가 Server Certificate의 내용을 자신의 Private Key로 서명했다고 하자.

Client는 Intermediate Certificate의 Public Key로 Signature를 검증한다.

검증이 성공하면 다음을 확인할 수 있다.

Certificate 내용이 서명 후 바뀌지 않았다.
해당 Intermediate의 Private Key 소유자가 이 Certificate를 발급했다.

그러나 Signature 하나만 맞는다고 검증이 끝나지 않는다.

Issuer Chain이 신뢰하는 Root까지 이어지는가?
CA Certificate가 Certificate 발급 용도로 허용되어 있는가?
Name Constraints와 Policy가 적용되는가?
Certificate가 현재 유효 기간 안에 있는가?
Server Authentication 용도로 사용할 수 있는가?
접속한 Hostname과 SAN이 일치하는가?
폐기된 Certificate인지 확인할 정책은 무엇인가?

Certificate Validation은 “서명 수학 한 번”이 아니라 여러 조건을 함께 검증하는 과정이다.

ㅁ Hostname은 Certificate의 어디와 비교할까?

Client가 https://shop.example에 접속했다고 하자.

Certificate가 신뢰되는 CA에서 발급되었어도 bank.example만을 위한 Certificate라면 사용할 수 없다.

Client는 자신이 접속하려던 Reference Hostname을 Certificate의 Subject Alternative Name(SAN)과 비교한다.

접속 Hostname: shop.example

SAN: DNS:shop.example
→ 일치 가능

SAN: DNS:bank.example
→ 불일치

오래된 Common Name만 보는 방식에 의존하지 않고 SAN을 기준으로 검증하는 것이 현대적인 동작이다.

Wildcard에도 범위가 있다.

*.example.com
→ api.example.com에는 일치 가능
→ deep.api.example.com까지 모두 일치한다고 단정할 수 없음

DNS가 공격받아 다른 IP로 연결되더라도 공격자가 해당 Hostname에 유효한 Certificate와 Private Key를 제시하지 못하면 TLS Hostname 검증에서 막을 수 있다.

ㅁ 유효 기간과 Clock은 왜 중요할까?

Certificate에는 Not Before와 Not After가 있다.

현재 시각 < Not Before
→ 아직 유효하지 않음

현재 시각 > Not After
→ 만료됨

Client System Clock이 크게 틀리면 정상 Certificate도 아직 유효하지 않거나 만료된 것으로 판단할 수 있다.

인증서 오류를 조사할 때 Server 설정뿐 아니라 Client의 시간 동기화도 확인해야 하는 이유다.

유효 기간이 남았어도 Private Key 유출이나 잘못된 발급 때문에 Certificate를 조기에 폐기해야 할 수 있다. CRL과 OCSP 같은 Revocation 메커니즘이 있지만 Client Policy, Network 도달성과 실패 처리 방식이 달라 단순한 한 단계로 끝나지 않는다.

ㅁ Certificate만 보내면 Private Key 소유를 증명할까?

Certificate는 Public 정보이므로 누구나 복사할 수 있다.

공격자가 진짜 Server의 Certificate 파일만 복사해 보내는 것을 막으려면 대응하는 Private Key를 가지고 있음을 증명해야 한다.

TLS 1.3의 CertificateVerify가 이 역할을 한다.

Server는 지금까지의 Handshake Transcript에 관련된 값을 자신의 Certificate Private Key로 서명한다.

Client는 Certificate의 Public Key로 Signature를 검증한다.

Certificate 복사본만 가진 공격자
→ Private Key가 없어 유효한 CertificateVerify 생성 불가

Certificate Chain 검증은 “이 Public Key가 해당 Hostname과 연결되어 신뢰되는가?”를 확인하고,

CertificateVerify는 “상대가 그 Public Key에 대응하는 Private Key를 실제로 가지고 있는가?”를 확인한다.

ㅁ Finished는 무엇을 마지막으로 확인할까?

Server와 Client는 지금까지 주고받은 Handshake Message의 Transcript Hash와

파생된 Secret을 이용해 Finished Message를 만든다.

상대가 Finished를 올바르게 검증하면 다음 단서를 얻는다.

상대도 올바른 Handshake Secret을 계산했다.
Handshake Transcript가 양쪽에서 동일하다.
중간에서 Version, Cipher, Key Share 등이 몰래 바뀌지 않았다.

Server의 Certificate Signature만 검증하고 Finished를 생략하면

Key Agreement와 전체 Handshake의 무결성을 끝까지 묶을 수 없다.

단순화한 TLS 1.3 Handshake는 다음과 같다.

Client                                             Server

ClientHello
Key Share, Version, Cipher, SNI, ALPN ----------->

                                      ServerHello
                            Selected Key Share <---

                          EncryptedExtensions <---
                                 Certificate <---
                           CertificateVerify <---
                                    Finished <---

Certificate Chain, Hostname,
CertificateVerify, Finished 검증

Finished ---------------------------------------->

<========== Protected Application Data ==========>

실제 Handshake에는 선택한 인증 방식, Resumption과 Client Authentication 등에 따라 Message가 달라질 수 있다.

ㅁ 중간 공격자가 Key Share를 바꾸면 어떻게 될까?

공격자가 ClientHello와 ServerHello 사이에 들어와 서로 다른 Key Agreement를 만들려 한다고 하자.

Client ↔ Attacker ↔ Server

Key Agreement만 있고 Authentication이 없다면 Client와 Server가 각각 공격자와 Secret을 만들 위험이 있다.

TLS는 Server Certificate의 Private Key로 Handshake Transcript에 서명하고

Finished로 전체 Transcript와 파생 Secret을 검증한다.

공격자가 Key Share나 선택 Parameter를 바꾸면 유효한 CertificateVerify와 Finished를 함께 만들어야 한다.

진짜 Server의 Private Key와 Handshake Secret이 없으면 검증을 통과시키기 어렵다.

Key Agreement
+ Certificate Authentication
+ Transcript Integrity
= Active Man-in-the-Middle 방어

각 기능이 따로가 아니라 하나의 Handshake Transcript에 묶이는 것이 중요하다.

ㅁ Forward Secrecy는 무엇을 지킬까?

TLS 1.3의 일반적인 Ephemeral Diffie-Hellman Key Agreement에서는 연결마다 일시적인 Private 값을 만든다.

Handshake가 끝난 뒤 이 Ephemeral Secret을 안전하게 폐기했다고 하자.

나중에 Server Certificate의 장기 Private Key가 유출되어도

과거에 Capture한 Session의 Key를 장기 Key만으로 복원하기 어렵게 한다.

이를 Forward Secrecy라고 한다.

장기 Certificate Private Key
→ Server Identity 서명에 사용

연결별 Ephemeral Key
→ Session Shared Secret 생성

Forward Secrecy가 Endpoint Memory 탈취, Session Key Log 유출과 Application 평문 저장까지 막아 주는 것은 아니다.

Ephemeral Key 생성과 폐기, Random Number 품질과 Endpoint 보안이 함께 필요하다.

ㅁ Application Data는 어떤 방식으로 보호할까?

Handshake가 끝나면 양쪽은 파생된 방향별 Application Traffic Key로 TLS Record를 보호한다.

TLS 1.3은 Authenticated Encryption with Associated Data(AEAD) 알고리즘을 사용한다.

대표적인 역할은 다음과 같다.

Plaintext
        ↓ Encryption
Ciphertext

Record Metadata와 Ciphertext
        ↓ Authentication Tag 검증
변조 여부 확인

AES-GCM이나 ChaCha20-Poly1305 같은 AEAD 방식은 기밀성과 무결성 보호를 결합한다.

공격자가 Ciphertext의 Bit를 바꾸면 Receiver의 Authentication Tag 검증이 실패하고 정상 Application Data로 전달되지 않는다.

TCP Checksum도 전송 오류를 탐지하지만 공격자가 다시 계산할 수 있으므로 암호학적 무결성을 제공하지 않는다.

TLS Integrity는 Secret Key를 모르는 공격자가 유효한 Record를 위조하기 어렵게 만든다.

ㅁ TLS Record와 TCP Segment는 같은 크기일까?

TLS는 TCP의 Byte Stream 위에서 자체 Record를 만든다.

HTTP Message
→ TLS Record 하나 또는 여러 개
→ TCP Segment 하나 또는 여러 개
→ IP Packet

하나의 TLS Record가 여러 TCP Segment에 나뉠 수 있고

여러 작은 Record가 전송 과정에서 하나의 큰 Host Buffer처럼 관찰될 수도 있다.

TLS Record Boundary
≠ TCP Segment Boundary
≠ HTTP Message Boundary

Packet Capture에서 TCP 한 줄과 TLS Message 하나를 1:1로 대응시키면 안 된다.

TCP는 순서 있는 Byte를 전달하고 TLS Record Layer가

그 Byte에서 Record를 복원해 인증한 뒤 Application에 평문을 제공한다.

ㅁ Client도 Certificate를 보여줄 수 있을까?

일반적인 Web HTTPS에서는 Server가 Certificate로 자신을 인증하고

사용자는 그 뒤 Password, Cookie, Token 등으로 Application 인증을 수행한다.

TLS는 Client Certificate를 요청해 양쪽을 인증할 수도 있다.

이를 Mutual TLS(mTLS)라고 한다.

Server Certificate
→ Client가 Server Identity 검증

Client Certificate
→ Server가 Client Identity 검증

mTLS에서 Client도 Certificate Chain과 Private Key 소유를 증명한다.

그러나 Certificate가 곧 최종 업무 권한은 아니다.

mTLS Authentication
→ 연결 주체 확인

Application Authorization
→ 해당 주체가 어떤 API와 Data를 사용할 수 있는지 결정

인증과 권한 부여를 구분해야 한다.

ㅁ 한 번 연결할 때마다 전체 Handshake를 반복할까?

TLS는 이전 Session에서 만든 정보를 이용해 다음 연결을 더 빠르게 시작할 수 있다.

TLS 1.3의 Session Resumption은 Server가 제공한 Ticket과 PSK(Pre-Shared Key) 관련 정보를 사용할 수 있다.

첫 연결
→ Full Handshake와 Server Certificate 검증
→ Resumption 정보 획득

다음 연결
→ PSK 기반 Resumed Handshake 가능

Resumption도 새 연결의 Key를 파생하고 Handshake 무결성을 확인한다.

과거 Application Traffic Key를 그대로 계속 재사용한다는 뜻은 아니다.

Ticket의 수명, Server Key Rotation, Cluster 간 State와 Client Cache 정책이 Resumption 가능 여부에 영향을 준다.

ㅁ 0-RTT Data는 왜 모든 요청에 쓰면 안 될까?

TLS 1.3 Resumption에서는 조건이 맞으면 Client가 Handshake 완료 전에 Early Data, 즉 0-RTT Data를 보낼 수 있다.

지연을 줄일 수 있지만 Replay 위험이 있다.

공격자가 Capture한 Early Data를 Server나 Cluster의 다른 Node에 다시 전달할 수 있다.

GET /static-image
→ 반복되어도 영향이 작도록 설계 가능

POST /transfer-money
→ Replay되면 업무가 중복 실행될 위험

0-RTT를 사용하려면 Application 요청의 Idempotency와 Anti-Replay 설계를 함께 고려해야 한다.

TLS가 Record를 암호화했다는 사실만으로 업무 요청이 Exactly-Once 실행되는 것은 아니다.

ㅁ TLS가 있어도 Replay와 중복 처리가 남을까?

정상적인 TLS Record Layer는 연결 안의 Record 순서와 무결성을 보호한다.

그러나 사용자가 응답을 받지 못해 Application 요청 전체를 새 연결에서 다시 보내는 문제는 별도다.

Client가 결제 요청 전송
Server가 처리 후 응답
응답이 Client에 도착하기 전 연결 종료
Client가 새 연결에서 재시도

두 TLS 연결이 모두 안전해도 결제가 두 번 처리될 수 있다.

Application은 Request ID, Idempotency Key, Transaction 상태로 중복 실행을 제어해야 한다.

TLS의 Integrity와 Application의 Exactly-Once 의미를 혼동하면 안 된다.

ㅁ TLS를 종료하는 Load Balancer 뒤도 계속 암호화될까?

TLS는 두 TLS Endpoint 사이의 구간을 보호한다.

Load Balancer나 Reverse Proxy가 TLS를 종료하면 Client가 만든 보호 구간은 그 장비에서 끝난다.

Client
  ║ TLS 보호 구간 1
Load Balancer
  │ Plain HTTP 또는
  ║ 새 TLS 보호 구간 2
Application Server

Backend로 평문을 보내면 Client와 Load Balancer 사이만 TLS로 보호된다.

Backend에도 TLS를 사용하면 별도의 Certificate, Key, Trust와 관찰 지점을 가진 두 보안 연결이 생긴다.

End-to-End라는 표현
→ 실제 TLS Endpoint가 어디인지 확인해야 함

TLS Inspection Proxy도 Client와 원래 Server 사이의 하나의 TLS Channel을 그대로 들여다보는 것이 아니다.

Client 쪽 연결을 종료하고 자신의 Certificate를 제시한 뒤 Server와 새 TLS 연결을 만드는 방식이 일반적이다.

Client가 조직의 Inspection CA를 신뢰하도록 구성되어 있어야 하며 Proxy가 평문과 Private Key 관련 책임을 갖게 된다.

ㅁ TLS가 숨기지 못하는 정보는 무엇일까?

TLS는 Application Payload와 보호 대상 Handshake Message를 암호화하지만
Packet 전달에 필요한 모든 Metadata를 없애지는 않는다.

중간 Network에서 일반적으로 관찰 가능한 정보가 있다.

Source와 Destination IP
TCP 또는 UDP Port
Packet 크기와 방향
전송 시간과 연결 지속 시간
TLS 사용 사실과 일부 Handshake Metadata

일반적인 TLS ClientHello의 SNI와 ALPN Offer도 보일 수 있다.

ECH가 적용된 구성에서는 ClientHello 내부 정보의 노출 범위가 달라진다.

DNS 질의를 평문으로 보냈다면 접속 전에 조회한 Domain도 Network에서 관찰될 수 있다.

TLS와 DNS Privacy는 별도의 구간과 Protocol 문제다.

Traffic Analysis까지 완전히 막는 익명화 Protocol로 TLS를 이해하면 안 된다.

ㅁ TLS가 해결하지 않는 문제는 무엇일까?

HTTPS가 성공해 Browser에 자물쇠가 보인다고 Site의 모든 행동이 안전하다는 뜻은 아니다.

TLS가 해결하지 않는 대표 문제는 다음과 같다.

Server Application의 SQL Injection과 권한 검증 오류
사용자가 공격자의 유사 Domain을 직접 방문한 Phishing
Client나 Server Endpoint의 Malware와 Memory 탈취
Server가 받은 평문 Data의 안전하지 않은 저장
인증된 사용자의 과도한 권한
DDoS와 Service Availability
Traffic 크기와 시간 같은 Metadata 노출
안전하게 처리되지 않은 Application 재시도

공격자도 자신이 소유한 Domain에 유효한 Certificate를 발급받을 수 있다.

Certificate 유효
→ 그 Domain과 Public Key의 연결이 검증됨

Certificate 유효
≠ 그 Site가 선하거나 업무상 승인됨

TLS는 보호된 Channel의 속성을 제공하고 Application의 신뢰성과 업무 판단은 별도 계층에서 해결한다.

ㅁ Certificate 오류는 무시해도 될까?

TLS Client가 경고를 내는 이유를 구분해야 한다.

Unknown CA
→ Chain이 신뢰하는 Root로 이어지지 않음

Hostname Mismatch
→ 접속 Hostname이 SAN과 일치하지 않음

Expired / Not Yet Valid
→ Certificate 유효 기간 또는 Client Clock 문제

Incomplete Chain
→ 필요한 Intermediate를 Server가 보내지 않음

Signature / Key Usage 오류
→ Chain이나 Certificate 용도 검증 실패

개발 환경의 Self-Signed Certificate라고 Browser 경고를 습관적으로 무시하면 실제 Man-in-the-Middle과 단순한 Local 설정을 구분하는 검증 절차가 사라진다.

개발용 CA나 Certificate를 해당 환경의 Trust Store에 명시적으로 제한해 설치하고 Production Trust와 분리한다.

--insecure 같은 검증 비활성화 Option은 암호화된 상대가 누구인지 확인하지 않게 만들므로 정상 운영 해결책이 아니다.

ㅁ Private Key가 유출되면 무엇을 해야 할까?

Certificate 파일은 배포할 수 있지만 Private Key는 Server Identity 증명의 핵심 비밀이다.

Private Key가 유출되면 공격자가 해당 Key로 Server를 사칭할 수 있는 위험이 생긴다.

대응에는 다음이 포함될 수 있다.

노출된 Key의 사용을 즉시 중단한다.
새 Private Key를 안전한 환경에서 생성한다.
새 Certificate를 발급하고 배포한다.
기존 Certificate의 폐기 절차를 수행한다.
Key가 사용된 시스템과 Log를 조사한다.
자동화 Token과 Backup 등 추가 유출 경로를 제거한다.

파일 권한만으로 끝나는 문제가 아니다.

HSM이나 Key Management System, 접근 통제, Rotation과 Audit가 운영 설계에 포함될 수 있다.

Forward Secrecy는 과거 Session 일부를 보호하는 데 도움이 되지만 유출된 장기 Key로 앞으로의 사칭을 막아 주지는 않는다.

ㅁ TLS 실패를 어느 단계에서 나눠 볼까?

“HTTPS가 안 된다”는 한 문장에는 여러 단계가 숨어 있다.

1. DNS Resolution
2. Route와 ARP/NDP
3. TCP 또는 QUIC 연결
4. TLS Version과 Cipher 협상
5. Certificate Chain과 Hostname 검증
6. Finished 검증과 Key 확정
7. HTTP Request 전송
8. Application Response

증상도 다를 수 있다.

TCP SYN Timeout
→ TLS ClientHello도 보내지 못함

TLS Alert: unknown_ca
→ TCP는 연결됐지만 Trust 검증 실패

TLS Alert: handshake_failure
→ Version, Algorithm, Client 인증 등 협상 문제 가능

HTTP 403
→ TLS는 성공했고 Application이 요청을 거절

하나의 Error String만으로 원인을 확정하지 말고 Packet Capture, TLS Client 출력, Server Log와 Certificate 내용을 함께 본다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 TLS Message와 검증으로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
사용할 자물쇠 방식과 재료를 제안	ClientHello	Version, Cipher, Key Share, SNI, ALPN 등을 제시
사용할 방식과 Server 재료를 선택	ServerHello	TLS Version, Cipher Suite와 Server Key Share 선택
공인된 신분증과 Public Key	Certificate Chain	Host Identity를 Public Key와 신뢰 체인에 연결
신분증 이름과 방문 주소 비교	Hostname Verification	접속 Hostname을 SAN과 검증
신분증 주인의 비밀 서명	CertificateVerify	Server가 Certificate Private Key를 소유했음을 Transcript 서명으로 증명
인사 내용 전체의 봉인 확인	Finished	Handshake Secret과 Transcript의 일치 및 무결성 확인
양쪽만 계산한 일회용 자물쇠 재료	Ephemeral Key Exchange	Shared Secret을 Network로 직접 보내지 않고 합의
이후 편지의 잠금과 변조 봉인	AEAD Record Protection	Application Data의 Confidentiality와 Integrity 제공
미리 신뢰하도록 설치한 발급 기관	Trust Store / Root CA	Certificate Chain 검증의 Local Trust Anchor
양쪽 모두 신분증 제시	mTLS	Server와 Client Certificate Authentication 수행
이전 접수표로 빠르게 재연결	Session Resumption	PSK와 Ticket으로 Handshake 비용을 줄임
확인 전 먼저 보내는 재배송 가능 편지	0-RTT Early Data	지연을 줄이지만 Replay 위험을 고려해야 함

TLS 1.3의 핵심 증명을 모으면 다음과 같다.

Certificate Chain + Hostname
→ 이 Public Key가 접속하려던 이름과 신뢰 체인에 연결되는가?

CertificateVerify
→ 상대가 그 Public Key의 Private Key를 실제로 소유하는가?

Ephemeral Key Exchange
→ 양쪽이 연결별 Shared Secret을 만들었는가?

Finished
→ Handshake Transcript와 파생 Secret이 양쪽에서 일치하는가?

AEAD
→ 이후 Record가 읽히거나 바뀌지 않도록 보호되는가?

ㅁ Packet Capture에서는 무엇이 보일까?

TLS 1.3 연결을 암호 해제 Key 없이 Capture하면 일반적으로 다음 흐름을 볼 수 있다.

TCP 3-Way Handshake
ClientHello
ServerHello
암호화된 Handshake와 Application Data
TCP 연결 종료

TLS 1.3에서는 ServerHello 뒤의 Certificate와 CertificateVerify도 암호화되므로

Passive Capture만으로 Certificate 내용을 읽을 수 없을 수 있다.

Wireshark Display Filter 예시는 다음과 같다.

tls || tcp.port == 443

확인할 항목은 다음과 같다.

ClientHello가 실제로 전송되었는가?
ServerHello 또는 TLS Alert가 돌아왔는가?
선택한 TLS Version은 무엇인가?
TCP Retransmission 때문에 Handshake가 지연되는가?
TLS 성공 뒤 Application Data Record가 이어지는가?

TLS Key Log를 Client가 명시적으로 제공하면 Wireshark가 Lab Traffic을 복호화할 수 있는 환경도 있다.

Session Key Log는 보호된 내용을 평문으로 드러낼 수 있는 민감 정보이므로 Production에서 수집하거나 공유하면 안 된다.

ㅁ OpenSSL로 Certificate 내용을 확인해 보기

Certificate 파일이 있다면 다음처럼 주요 Field를 확인할 수 있다.

openssl x509 -in server.crt -noout \
  -subject -issuer -serial -dates \
  -ext subjectAltName \
  -fingerprint -sha256

출력에서 다음 질문을 확인한다.

Subject와 Issuer가 누구인가?
SAN에 접속할 DNS Name이나 IP가 있는가?
Not Before와 Not After 사이에 현재 시간이 있는가?
SHA-256 Fingerprint가 배포 문서와 일치하는가?

Fingerprint 비교는 신뢰할 수 있는 별도 Channel에서 기대값을 얻었을 때 의미가 있다.

공격자가 Certificate와 Fingerprint를 같은 Channel에서 함께 바꾸면 독립적인 검증이 아니다.

ㅁ Local TLS Server를 직접 만들어 보기

다음 실습은 개인 Computer의 Loopback에서만 수행한다.

openssl, curl, tcpdump가 필요하며 외부 Server나 저장소를 사용하지 않는다.

먼저 실습 Directory를 만들고 Private Key 파일의 기본 권한을 제한한다.

mkdir tls-local-lab
cd tls-local-lab
umask 077

하루 동안만 사용할 Self-Signed Certificate와 Private Key를 만든다.

openssl req -x509 -newkey rsa:2048 -sha256 -nodes \
  -keyout server.key \
  -out server.crt \
  -days 1 \
  -subj '/CN=localhost' \
  -addext 'subjectAltName=DNS:localhost,IP:127.0.0.1' \
  -addext 'basicConstraints=critical,CA:TRUE'

이 실습에서는 하나의 Self-Signed Certificate를 Server Certificate이자 Local Trust Anchor로 명시적으로 사용한다.

실제 Public Web PKI의 Root–Intermediate–Leaf 구성을 재현한 것은 아니다.

-nodes는 Private Key를 Password로 암호화하지 않는다는 뜻이다.

자동 실행을 단순화한 Local Lab 설정이며 파일을 외부에 공유하거나 운영 Server에 그대로 적용하지 않는다.

Certificate Field를 확인한다.

openssl x509 -in server.crt -noout \
  -subject -issuer -dates \
  -ext subjectAltName \
  -fingerprint -sha256

첫 번째 Terminal에서 TLS Server를 실행한다.

openssl s_server \
  -accept 8443 \
  -cert server.crt \
  -key server.key \
  -www

두 번째 Terminal에서 Certificate를 Local Trust Anchor로 지정하고 Hostname을 검증한다.

openssl s_client \
  -connect 127.0.0.1:8443 \
  -servername localhost \
  -CAfile server.crt \
  -verify_hostname localhost \
  -verify_return_error

출력에서 다음을 확인한다.

Protocol
Cipher
Peer Certificate
Verification: OK 또는 Verify return code: 0

OpenSSL Version에 따라 출력 표현은 달라질 수 있다.

curl로 HTTPS 요청을 보낸다.

curl --cacert server.crt https://localhost:8443/

--cacert는 이 명령에서 신뢰할 Certificate를 명시한다. 검증을 끄는 -k와 다르다.

ㅁ Hostname 검증 실패를 비교해 보기

같은 Certificate를 신뢰하더라도 접속하려는 이름이 SAN과 다르면 검증이 실패해야 한다.

openssl s_client \
  -connect 127.0.0.1:8443 \
  -servername wrong.example \
  -CAfile server.crt \
  -verify_hostname wrong.example \
  -verify_return_error

이 명령은 실패를 관찰하기 위한 것이다.

Trust Anchor 일치
+ Certificate Signature 검증 가능
+ Hostname 불일치
= 전체 Identity 검증 실패

“Certificate를 신뢰한다”와 “이 Certificate가 지금 접속한 이름에 유효하다”는 별도 조건임을 확인한다.

ㅁ TLS Packet을 Capture해 보기

Server를 실행한 상태에서 세 번째 Terminal로 Loopback Packet을 저장한다.

Linux에서는 보통 lo, macOS에서는 보통 lo0를 사용한다.

sudo tcpdump -n -i lo -s 0 -w tls-local.pcap \
  'tcp port 8443'

그 뒤 curl이나 openssl s_client를 다시 실행한다.

Wireshark에서 다음 순서를 확인한다.

TCP SYN, SYN-ACK, ACK
TLS ClientHello
TLS ServerHello
암호화된 TLS Record
TCP FIN 또는 RST

Capture에 HTTP 응답 본문이 평문으로 보이지 않는지 확인한다.

ClientHello의 SNI, ALPN Offer와 ServerHello 뒤 암호화 범위도 비교한다.

OpenSSL과 curl의 Option, TLS Version에 따라 실제 Extension은 달라질 수 있다.

실습이 끝나면 Server를 종료하고 Private Key를 포함한 파일을 안전하게 삭제한다.

rm -f server.key server.crt tls-local.pcap
cd ..
rmdir tls-local-lab

실제 업무 Certificate와 Private Key를 실습 파일처럼 삭제하거나 공유하지 않는다.

ㅁ 핵심 정리

TLS는 도청, 변조, 사칭에 대응하기 위해 Confidentiality, Integrity, Authentication을 결합한다.
TCP Handshake, TLS Handshake와 HTTP 처리는 서로 다른 단계다.
TLS는 Public Key Cryptography로 Identity와 Key Agreement를 연결하고 대칭키로 대량의 Record를 보호한다.
ClientHello는 Version, Cipher, Key Share, SNI와 ALPN 후보를 제시하고 ServerHello는 사용할 조건과 Server Key Share를 선택한다.
TLS 1.3에서는 ServerHello 뒤의 Handshake Message가 암호화되므로 Passive Capture에 Certificate가 보이지 않을 수 있다.
Certificate Chain은 Public Key와 Host Identity를 Trust Store의 Root에 연결한다.
Client는 Chain Signature뿐 아니라 SAN Hostname, 유효 기간, Key Usage와 Trust Policy를 함께 검증한다.
CertificateVerify는 Server가 Certificate Public Key에 대응하는 Private Key를 소유했음을 Handshake Transcript 서명으로 증명한다.
Finished는 양쪽의 Handshake Secret과 Transcript가 일치하는지 확인한다.
Ephemeral Key Exchange와 안전한 Secret 폐기는 장기 Private Key 유출이 과거 Session에 미치는 영향을 줄이는 Forward Secrecy를 제공한다.
AEAD는 TLS Record의 Encryption과 암호학적 Integrity를 함께 제공한다.
TLS Record, TCP Segment와 HTTP Message의 Boundary는 서로 같지 않다.
mTLS의 Client Authentication과 Application Authorization은 별도 단계다.
Session Resumption은 연결 비용을 줄이지만 0-RTT Early Data는 Replay 위험 때문에 요청 의미를 고려해야 한다.
TLS는 IP·Port·Traffic 크기와 시간까지 모두 숨기지 않으며 Endpoint 침해와 Application 취약점을 해결하지 않는다.
Self-Signed Certificate 경고를 무시하기보다 제한된 Trust Anchor와 Hostname 검증을 명시적으로 구성해야 한다.

핵심 용어 : Transport Layer Security, TLS 1.3, HTTPS, Confidentiality, Integrity, Authentication, ClientHello, ServerHello, EncryptedExtensions, SNI, ALPN, Cipher Suite, Key Share, Ephemeral Diffie-Hellman, Certificate, X.509, Certificate Chain, Root CA, Intermediate CA, Leaf Certificate, Trust Store, Subject Alternative Name, Hostname Verification, CertificateVerify, Finished, Handshake Transcript, Traffic Key, AEAD, Forward Secrecy, mTLS, Session Resumption, PSK, 0-RTT, Replay, TLS Termination

TLS는 우체부를 믿게 만드는 기술이 아니다. 우체부가 편지를 운반할 수는 있어도 내용을 읽거나 몰래 바꾸기 어렵게 만들고, 받은 편지가 신뢰한 상대와 합의한 Key로 보호되었는지 Endpoint가 직접 검증하게 한다.

ㅁ 다음 이야기

지금까지 편지는 주소를 찾고, 경로를 지나고, 크기를 조절하고, 허용된 문을 통과해 암호화된 Channel 안에서 전달되었다.

이제 실제 장애를 만났다고 하자. 가장 먼저 실행하기 쉬운 명령은 ping이다.

하지만 Echo Reply가 오지 않는다는 사실만으로 Server가 꺼졌다고 말할 수 있을까? 반대로 ping이 성공하면 HTTPS와 Application도 정상이라고 말할 수 있을까?

다음 글에서는 「ping이 실패하면 정말 서버가 죽은 것일까?」라는 질문을 통해 ICMP Echo, RTT, Packet Loss, Firewall Policy와 Layer별 진단 범위를 살펴본다.

[바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트

기록하는 백엔드개발자 — Sat, 25 Jul 2026 13:00:12 +0900

TL;DR

좋은 문서는 대화를 보관하는 기록이 아니라, 다음 대화를 더 정확하게 만드는 컨텍스트다.

AI와 긴 프로젝트를 진행할 때 결과가 흔들리는 이유는 코딩 능력만의 문제가 아니다.

서비스의 목적, 사용자 경험, 기술, 데이터, 기능을 한꺼번에 다루면 제안과 결정이 섞이고 무엇이 기준인지 모호해진다.

PRD, UX, 기술 스택, 데이터베이스, 도메인, API는 서로 다른 결정을 나누어 담는 문서다.

이 문서들을 SSOT와 MECE 원칙으로 정리하면 사람과 AI가 같은 기준을 볼 수 있다.

문서가 할루시네이션을 완전히 제거하지는 않지만, 충돌하는 정보와 불필요한 추측이 발생할 가능성을 줄여 준다.

ㅁ 들어가며

AI를 활용 방법에 대한 질문을 많이 받는다.

단순히 AI에게 아이디어를 설명하고 “서비스로 만들어 줘”라고 요청하면 처음에는 놀라울 만큼 빠르게 결과가 나온다.

화면도 생기고, 기능도 붙고, 미처 생각하지 못했던 아이디어까지 제안받는다.

그런데 대화가 길어질수록 이상한 일이 생긴다.

처음에 중요하다고 했던 목적이 흐려지고, 잠깐 검토했던 아이디어가 꼭 필요한 기능처럼 바뀐다.

화면 이야기를 하다가 데이터 저장 방식이 등장하고, 기술을 정하다가 서비스의 대상 사용자까지 다시 바뀌기도 한다.

이 문제를 줄이려면 프롬프트를 무조건 길게 써야 할까?

꼭 그렇지는 않다. 긴 프로젝트에서 더 중요한 것은 결정을 주제별로 나누고, 확정된 내용을 문서로 남기는 일이다.

서비스를 만드는 일은 식당을 준비하는 일과 비슷하다.
각 문서는 서로 다른 결정을 담당하고, 확정된 문서는 다음 작업의 기준이 된다.

이 글에서는 개발 문서를 식당을 준비하는 과정에 비유해 살펴본다.

ㅁ AI에게 서비스를 한 번에 맡기면 왜 흔들릴까?

“친구들과 할 수 있는 게임 서비스를 만들어 줘.”

이 한 문장에는 아직 정해지지 않은 것이 많다.

누구를 위한 게임인지, 어떤 상황에서 사용하는지, 사용자는 어떤 화면을 보게 되는지, 어떤 정보를 저장해야 하는지 알 수 없다.

AI는 대답을 만들기 위해 비어 있는 부분을 추측하거나 여러 가능성을 한꺼번에 제안할 수밖에 없다.

제안 자체가 문제는 아니다. 문제는 제안과 결정이 섞이는 순간 시작된다.

사용자가 선택하지 않은 아이디어가 다음 대화에서 확정된 요구사항처럼 쓰이고,

서로 다른 단계의 이야기가 한 문서에 들어가면 무엇이 기준인지 알기 어려워진다.

그래서 서비스를 만드는 과정을 몇 개의 문서로 나눈다.

PRD, UX, 기술 스택, 데이터베이스, 도메인, API

문서를 많이 만들기 위해서가 아니라, 지금 어떤 질문에 답하고 있는지를 분명히 하기 위해서다.

개별 문서들이 왜 필요한지, 무엇을 위해 필요한지 이해를 돕기 위해 음식점에 비유를 들어 보았다.

ㅁ 서비스를 만드는 것은 왜 식당을 준비하는 일과 비슷할까?

식당을 준비한다고 생각해 보자.

“식당 하나 만들어 주세요”라는 말만으로는 바로 문을 열 수 없다.

먼저 어떤 손님을 위한 어떤 식당인지 정해야 한다.

손님이 보게 될 메뉴판과 주문 순서를 생각하고, 어떤 방식으로 요리할지 선택한다.

재료를 보관할 창고와 분류 기준을 만들고, 메뉴마다 레시피도 정해야 한다.

서비스도 마찬가지다.

개발 문서는 어려운 기술 용어를 늘어놓기 위한 설명서가 아니다.

서로 다른 종류의 결정을 나누어 담는 그릇이다.

어떤 식당인가?
      │
      ▼
손님은 어떻게 이용하는가?
      │
      ▼
어떤 방식으로 요리하는가?
      │
      ▼
재료를 어떻게 보관하고 분류하는가?
      │
      ▼
메뉴별로 어떻게 처리하는가?

서비스 문서	식당을 준비하는 일
PRD	어떤 식당을 만들 것인가
UX	손님에게 보여 줄 메뉴판과 음식 사진
기술 스택	한식·중식·일식과 같은 조리 방식
데이터베이스	음식 재료 창고
도메인	재료를 종류별로 정리한 공간
API	메뉴별 레시피

이 대응 관계를 알면 개발 지식이 많지 않아도 각 문서가 왜 필요한지 이해할 수 있다.

ㅇ PRD — 어떤 식당을 만들 것인가?

PRD는 어떤 식당을 만들지 정하는 문서다.

누구를 위한 식당인지, 어떤 음식을 제공할지, 손님에게 어떤 경험을 주고 싶은지를 먼저 정한다. 가족이 편하게 식사하는 한식당과 빠르게 한 끼를 해결하는 분식점은 메뉴와 공간, 운영 방식이 모두 다르다.

서비스도 목적과 대상 사용자가 먼저 정해져야 한다. Speed Quiz를 예로 들면, 중요한 질문은 어떤 기술을 쓸지가 아니다. “누가, 어떤 상황에서, 무엇을 더 편하게 하려고 이 서비스를 사용하는가?”가 먼저다.

PRD가 정리되지 않은 상태에서 화면이나 기술부터 결정하면 멋진 결과는 나올 수 있어도 처음 해결하려던 문제와는 멀어질 수 있다. PRD는 이후의 모든 판단이 돌아와 확인할 출발점이다.

ㅇ UX — 손님에게 무엇을 보여 줄 것인가?

식당의 방향을 정했다면 이제 손님이 무엇을 보고 어떻게 이용할지를 생각한다. 메뉴판은 어디에 있는지, 주문은 어떤 순서로 하는지, 음식이 나오기까지 손님은 무엇을 보게 되는지 정하는 일이다.

이것이 UX의 역할이다. UX는 화면을 예쁘게 꾸미는 일에만 머물지 않는다. 사용자가 서비스를 처음 만난 순간부터 목적을 달성할 때까지 어떤 행동을 하고 어떤 안내를 받는지 그려 보는 과정이다.

PRD가 “어떤 식당인가”에 답한다면 UX는 “손님이 그 식당을 어떻게 경험하는가”에 답한다. 이 단계에서는 조리도구나 재료 창고까지 결정하지 않는다. 손님의 경험이라는 한 가지 주제에 집중한다.

ㅇ 기술 스택 — 어떤 방식으로 요리할 것인가?

기술 스택은 음식을 만드는 조리 방식과 비슷하다.

한식, 중식, 일식은 필요한 도구와 재료를 다루는 방식이 다르다. 그렇다고 식당의 목적을 정하기도 전에 조리 방식부터 고르는 것은 자연스럽지 않다. 어떤 손님에게 무엇을 제공할지 정한 다음, 그 목적을 실현하기에 알맞은 방식을 선택해야 한다.

서비스에서도 기술은 목적을 이루기 위한 수단이다.

유행하는 기술을 먼저 선택한 뒤 서비스의 모습을 거기에 맞추는 것이 아니라,

만들고 싶은 경험이 정해진 뒤 그에 맞는 기술적 방향을 고른다.

비개발자가 모든 기술을 직접 비교할 필요는 없다.

다만 “왜 이 방식이 지금 만들려는 서비스에 맞는가?”라는 질문은 놓치지 않아야 한다.

ㅇ 데이터베이스 — 재료를 어디에 보관할 것인가?

데이터베이스는 식당에서 사용하는 재료를 보관하는 창고와 같다.

재료를 아무 곳에나 쌓아 두지 않고, 필요한 순간에 찾고 사용할 수 있도록 정해진 기준에 따라 보관한다.

서비스에도 계속 기억해야 하는 정보가 있다.

누가 참여했는지, 어떤 게임방인지, 어떤 문제가 나왔는지, 점수가 얼마인지 같은 정보다.

이런 정보를 어떤 형태로 저장하고 관리할지 정하는 것이 데이터베이스의 역할이다.

ㅇ 도메인 — 재료를 어떻게 분류할 것인가?

도메인은 창고 안의 재료를 성격에 따라 나누는 기준과 비슷하다.

채소, 고기, 해산물, 양념을 구분해 두면 필요한 재료를 쉽게 찾을 수 있다.

예를 들어, Speed Quiz에서도 사용자, 게임방, 문제, 점수처럼 서로 관련 있는 정보를 묶어서 생각할 수 있다.

데이터베이스가 “정보를 보관하는 곳”이라면 도메인은 “그 정보를 어떤 의미의 묶음으로 이해할 것인가”에 가깝다.

두 개념을 구분하면 저장할 정보와 서비스가 다루는 대상을 더 명확하게 바라볼 수 있다.

ㅇ API — 메뉴별 레시피

API는 메뉴별 레시피와 비슷하다.

주문이 들어오면 어떤 재료를 사용하고, 어떤 순서로 처리해, 어떤 결과를 내놓을지 정해져 있어야 한다. 같은 메뉴를 주문할 때마다 전혀 다른 음식이 나온다면 식당을 안정적으로 운영할 수 없다.

서비스의 기능도 비슷하다. 게임방 만들기, 참가하기, 게임 시작하기처럼 어떤 요청이 들어왔을 때 무엇을 확인하고 어떤 결과를 돌려줄지 약속이 필요하다. API는 기능들이 서로 요청과 결과를 주고받는 방식을 정리한다.

여기서 구체적인 규격이나 구현법까지 알 필요는 없다. API가 메뉴별 레시피처럼 기능의 동작을 일정하게 이어 주는 약속이라는 점을 이해하면 충분하다.

ㅁ 문서는 왜 다음 작업의 기준이 될까?

문서는 회의나 대화를 기록해 두는 메모에 그치지 않는다.

확정된 문서는 다음 작업이 시작될 기준이 된다.

식당의 콘셉트가 정리되어 있다면 메뉴판을 만드는 사람도, 주방을 설계하는 사람도 같은 식당을 상상할 수 있다.

담당자가 바뀌더라도 매번 “어떤 식당을 만들고 있었지?”라고 처음부터 추측할 필요가 없다.

AI와 일할 때도 마찬가지다. 문서는 다음과 같은 역할을 한다.

결정된 내용을 대화 밖에 보존한다.
사람과 AI가 같은 기준을 보게 한다.
다음 대화에서 다시 사용할 컨텍스트가 된다.
현재 작업의 범위를 분명하게 한다.
프로젝트가 임의로 확장되는 일을 줄인다.

따라서 문서는 이전 작업의 결과인 동시에 다음 작업의 입력이다. 한 단계에서 만든 문서가 다음 단계의 출발점이 된다.

ㅁ SSOT와 MECE는 왜 필요할까?

문서를 만든다고 해서 언제나 기준이 선명해지는 것은 아니다.

같은 결정을 여러 문서에 조금씩 다르게 적거나, 서로 다른 주제를 한 문서에 모두 넣으면 오히려 혼란이 커질 수 있다.

그래서 문서를 정리할 때 SSOT와 MECE라는 두 가지 원칙을 사용한다.

ㅇ SSOT — 하나의 결정은 하나의 기준에서 관리한다

SSOT(Single Source of Truth)는 하나의 사실과 결정을 하나의 기준 문서에서 관리한다는 뜻이다. 식당의 콘셉트를 메뉴 기획 문서와 주방 문서에서 서로 다르게 정하지 않고, 하나의 확정된 기준을 함께 보는 것과 같다. 서비스의 목적과 요구사항은 PRD에서 관리하고, 다른 문서는 그 내용을 다시 정의하기보다 기준으로 삼는다.

ㅇ MECE — 역할은 겹치지 않게, 내용은 빠짐없이 정리한다

MECE(Mutually Exclusive, Collectively Exhaustive)는 역할은 겹치지 않게 나누되 필요한 내용은 빠짐없이 담는다는 뜻이다.

PRD는 목적과 요구사항, UX는 사용자의 경험, 기술 문서는 기술적 선택을 맡는다.

동시에 각 문서 안에서는 그 주제를 이해하고 다음 작업을 진행하는 데 필요한 내용이 빠지지 않도록 정리한다.

이 원칙은 AI에게 매우 중요하다.

기준이 하나면 충돌하는 정보 중 무엇을 따라야 할지 해석하는 부담이 줄어든다.

역할이 나뉘고 필요한 내용이 갖춰져 있으면, 누락된 부분을 임의로 추측하거나 여러 문서의 내용을 억지로 결합할 가능성도 낮아진다.

다만 SSOT와 MECE가 할루시네이션을 완전히 제거하는 것은 아니다.

AI는 여전히 잘못 이해하거나 틀린 답을 만들 수 있다.

두 원칙은 AI가 참고할 기준을 더 선명하게 만들어 불필요한 추측과 정보 충돌의 가능성을 줄이는 방법이다.

ㅁ 좋은 문서는 왜 좋은 컨텍스트가 될까?

AI와 나눈 긴 대화에는 여러 종류의 정보가 섞여 있다.

확정된 결정도 있지만, 잠깐 검토한 아이디어와 제외하기로 한 제안, 중간에 잘못 이해한 내용도 들어 있다.

대화 전체를 다음 단계에 넘기면 AI는 그중 무엇이 진짜 기준인지 다시 추측해야 한다.

반대로 확정된 내용만 역할에 맞는 문서로 정리하면 다음 대화의 출발점이 분명해진다.

문서는 이전 결정을 보존하는 기억이 되고, 다음 작업의 범위를 알려 주는 안내판이 되며, 사람과 AI가 함께 보는 공통 기준이 된다.

ㅁ 마무리 — 좋은 문서는 다음 대화를 만든다

바이브 코딩에서 중요한 것은 처음부터 모든 개발 지식을 아는 것이 아니다.

지금 결정해야 할 주제를 구분하고, 그 결정을 문서로 남겨 다음 작업에 사용하는 것이다.

좋은 문서는 대화를 보관하는 기록이 아니라, 다음 대화를 더 정확하게 만드는 컨텍스트다.

그렇다면 이 문서를 실제 AI 협업에서는 어떻게 사용해야 할까?

다음 글에서는 하나의 주제를 선택하고, 역할을 부여하고, Plan Mode에서 논의한 뒤,

확정된 내용만 다음 컨텍스트로 넘기는 방법을 살펴본다.

ㅁ 함께 읽으면 좋은 글

ㅇ [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트

- 하나의 주제, 페르소나, Plan Mode, 문서화를 반복하는 방법

ㅇ Context Note — AI 대화의 컨텍스트는 왜 “쌓지 않고 구조화”해야 할까?

- ChatGPT와 함께 컨텍스트를 문서 중심으로 관리하기 위해 만든 도구이다.

- GPT Atlas에서 트리 구조의 노트, 마크다운 편집기, ChatGPT 대화창을 함께 사용하며 필요한 컨텍스트를 구조화할 수 있다.

[Network] 22. 방화벽은 편지의 무엇을 보고 문을 열어줄까?

기록하는 백엔드개발자 — Fri, 24 Jul 2026 22:22:44 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 7. 인터넷의 주소를 함께 쓰고 경계를 지키는 법

ㅁ 들어가며

Network 경계에 경비실을 세웠다고 하자.

경비원에게 “좋은 편지는 통과시키고 나쁜 편지는 막아 달라”고 말하면 Policy가 완성될까?

Packet에는 발신자의 의도가 적혀 있지 않다.

방화벽이 직접 관찰할 수 있는 것은 다음과 같은 정보다.

어느 Interface와 Zone에서 들어왔는가?
Source와 Destination IP는 무엇인가?
TCP, UDP, ICMP 중 어떤 Protocol인가?
Source와 Destination Port는 무엇인가?
TCP Flag와 연결 상태는 무엇인가?
기존에 허용한 대화의 응답인가?

방화벽은 이 증거를 미리 정의한 Rule과 비교해 ALLOW, DROP, REJECT 같은 결정을 내린다.

따라서 방화벽의 핵심은 “많이 막기”가 아니다.

누가
어디에서 어디로
어떤 Protocol과 Service를
어느 방향으로
왜 사용해야 하는가?

이 질문에 답할 수 있을 만큼 필요한 흐름을 정확히 정의하는 것이 핵심이다.

이번 글에서는 5-Tuple, Stateless ACL, Stateful Firewall, Connection Tracking, NEW, ESTABLISHED, RELATED, INVALID, Default Deny, Least Privilege를 하나의 TCP 연결로 추적한다.

ㅁ 방화벽은 Packet의 어느 층까지 볼까?

모든 방화벽이 같은 정보를 보는 것은 아니다.

단순한 Packet Filter는 주로 Network Layer와 Transport Layer Header를 본다.

Layer 3
├─ Source IP
├─ Destination IP
└─ IP Protocol

Layer 4
├─ Source Port
├─ Destination Port
└─ TCP Flag 등

장비가 배치된 위치에 따라 Incoming Interface, Outgoing Interface, VLAN과 Security Zone도 판단 기준이 된다.

더 높은 계층을 이해하는 Proxy, Web Application Firewall, IDS/IPS는 HTTP Method, URL, Protocol 문법 같은

Application 정보까지 분석할 수 있다.

Network Firewall
→ 주소, Protocol, Port, State 중심

Application-Aware Firewall / Proxy / WAF
→ Application Protocol과 요청 의미까지 추가 분석 가능

“방화벽”이라는 이름만으로 어떤 Field를 어디까지 해석하는지 단정할 수 없다.

제품의 처리 계층, 암호화 상태와 배치 방식을 확인해야 한다.

ㅁ 5-Tuple은 어떤 대화를 가리킬까?

Client가 Web Server에 연결한다고 하자.

Client 10.22.1.2:53000
Server 198.51.100.2:443
Protocol TCP

Flow를 구분하는 5-Tuple은 다음과 같다.

Source IP        10.22.1.2
Source Port      53000
Destination IP   198.51.100.2
Destination Port 443
Protocol         TCP

Return Packet에서는 Source와 Destination이 뒤집힌다.

Source IP        198.51.100.2
Source Port      443
Destination IP   10.22.1.2
Destination Port 53000
Protocol         TCP

두 Packet은 방향별 5-Tuple이 다르지만 하나의 양방향 대화다.

Stateful Firewall은 Original Direction과 Reply Direction을 하나의 Connection Tracking Entry로 연결한다.

ㅁ Stateless ACL은 어떻게 판단할까?

Stateless Access Control List(ACL)은 각 Packet을 독립적으로 Rule과 비교한다.

현재 Packet의 Header
        ↓
Rule 목록과 비교
        ↓
Permit 또는 Deny

이전에 Client의 SYN을 허용했다는 사실을 다음 SYN-ACK 판단에 자동으로 기억하지 않는다.

Client에서 Server의 HTTPS로 나가는 Rule을 생각해 보자.

Permit TCP
Source      10.22.1.0/24
Destination 198.51.100.2
Destination Port 443

이 Rule은 Client의 요청 방향에 맞는다.

그러나 Server의 응답은 다음과 같다.

TCP 198.51.100.2:443
→   10.22.1.2:53000

응답을 받으려면 반대 방향 Rule도 필요하다.

Permit TCP
Source      198.51.100.2
Source Port 443
Destination 10.22.1.0/24
Destination Port Ephemeral Range

Client의 Ephemeral Port가 연결마다 달라지므로 Stateless Rule은 Return 범위를 넓게 열거나

TCP Flag 같은 추가 조건을 사용할 수 있다.

각 방향을 명시적으로 설계한다는 장점이 있지만,

복잡한 동적 연결에서 Rule 범위가 커지고 요청과 응답의 관계를 정확히 표현하기 어려울 수 있다.

ㅁ ACK Flag만 있으면 정상 응답이라고 믿어도 될까?

과거의 단순한 Stateless Rule은 TCP ACK가 설정된 Packet을 “이미 만들어진 연결의 응답”처럼 허용하기도 했다.

TCP ACK=1
→ Established Traffic으로 간주

하지만 Packet Header의 ACK Bit는 누구나 만들어 보낼 수 있다.

방화벽이 실제 3-Way Handshake를 관찰하지 않았다면

해당 ACK가 정상 연결에 속하는지 ACK Flag 하나만으로 확정할 수 없다.

ACK Flag 존재
≠ 방화벽이 확인한 기존 Connection 존재

TCP Flag 검사는 유용한 조건이지만 Connection Tracking State를 그대로 대신하지는 못한다.

ㅁ Stateful Firewall은 무엇을 기억할까?

Stateful Firewall은 허용된 새 Flow의 Packet을 관찰하고 Connection Tracking State를 만든다.

Client의 SYN이 통과했다고 하자.

Original Direction
TCP 10.22.1.2:53000 → 198.51.100.2:443

Expected Reply Direction
TCP 198.51.100.2:443 → 10.22.1.2:53000

설명용 State Table은 다음처럼 보일 수 있다.

Protocol	Original Tuple	Reply Tuple	State
TCP	10.22.1.2:53000 → 198.51.100.2:443	198.51.100.2:443 → 10.22.1.2:53000	SYN 관찰

Server의 SYN-ACK이 돌아오면 Firewall은 5-Tuple을 뒤집어 기존 Entry의 Reply Direction과 맞는지 확인한다.

기존 요청의 정상 Reply로 확인
→ 별도의 넓은 Inbound Ephemeral Port Rule 없이 허용 가능

마지막 ACK와 Data, FIN/RST를 관찰하면서 State와 Timeout을 갱신할 수 있다.

ㅁ Conntrack의 NEW와 TCP의 SYN-SENT는 같은 상태일까?

Linux Netfilter 같은 환경에서는 Packet을 다음 Conntrack State로 분류할 수 있다.

NEW
ESTABLISHED
RELATED
INVALID

이 이름을 TCP State Machine의 SYN-SENT, ESTABLISHED, TIME-WAIT와 그대로 같은 것으로 이해하면 안 된다.

TCP State
→ Endpoint TCP Stack의 연결 상태

Conntrack State
→ 중간 장비가 관찰한 Packet 관계 상태

Firewall이 모든 Packet을 보지 못했거나 Timeout과 구현 방식이 다르면 두 상태가 일치하지 않을 수 있다.

ㅁ NEW는 반드시 첫 SYN만 뜻할까?

NEW는 기존 Conntrack Entry에 속하지 않으면서 새 Flow를 만들 수 있는 Packet을 뜻한다.

정상적인 TCP 연결의 시작에서는 보통 다음 SYN이다.

SYN=1, ACK=0
Conntrack State=NEW

하지만 구현과 Tracking 설정에 따라 SYN이 아닌 TCP Packet이 NEW로 분류될 수도 있다.

따라서 Internet에서 내부 Server로 들어오는 새 TCP 연결을 허용할 때 다음처럼 의도를 더 구체적으로 표현할 수 있다.

Protocol TCP
Destination Server와 Port 일치
Conntrack State NEW
TCP SYN 조건

NEW라는 이름만 보고 “정상적인 Handshake가 이미 검증됐다”고 생각하면 안 된다.

ㅁ ESTABLISHED는 Application 인증까지 끝났다는 뜻일까?

Conntrack의 ESTABLISHED는 일반적으로 양방향 Packet이 관찰되어 기존 Flow의 일부로 인식된다는 뜻이다.

Client SYN 통과
Server SYN-ACK 관찰
→ Reply Direction 확인
→ ESTABLISHED로 분류 가능

이는 다음 사실을 보장하지 않는다.

TLS 인증서 검증 완료
사용자 Login 성공
Application 요청이 안전함
Database 작업 성공

Firewall의 ESTABLISHED와 Endpoint TCP의 ESTABLISHED, Application Session의 인증 완료는 서로 다른 계층의 상태다.

Stateful Rule의 ESTABLISHED는 “이 Packet이 이미 추적 중인 양방향 Flow에 속한다”는 의미로 읽어야 한다.

ㅁ RELATED는 어떤 Packet을 가리킬까?

RELATED는 새 Flow 또는 Control Packet이 기존 Conntrack Entry와 관련된 것으로 식별된 상태다.

대표적인 예는 기존 Flow의 Packet을 인용한 ICMP 오류다.

기존 TCP Packet
→ Router에서 MTU 초과
→ ICMP Fragmentation Needed
→ 원래 Flow와 RELATED

Stateful Firewall은 ICMP 안에 인용된 원래 Header를 보고 기존 Flow와 연결해 필요한 오류를 허용할 수 있다.

일부 Protocol Helper는 Control Connection 안에서 협상된 별도 Data Connection을 RELATED로 연결할 수도 있다.

그러나 Helper가 Payload를 해석하고 동적으로 Pin Hole을 여는 기능은 공격 표면도 늘릴 수 있다.

필요한 Protocol에만 제한하고 암호화된 Payload에서는 해석할 수 없다는 점도 고려해야 한다.

ㅁ INVALID는 무조건 공격 Packet일까?

INVALID는 정상적으로 추적할 수 없거나 기대한 Connection State와 맞지 않는 Packet을 뜻할 수 있다.

가능한 원인은 다양하다.

기존 Conntrack Entry가 Timeout으로 사라진 뒤 늦게 온 Packet
비정상적인 TCP Flag 또는 Sequence 관계
Fragment Reassembly나 Tracking에 필요한 정보 부족
Asymmetric Path 때문에 Firewall이 한 방향만 관찰
손상되거나 해석할 수 없는 Packet

INVALID를 Drop하는 Policy는 흔하지만 INVALID라는 결과만으로 외부 공격이라고 단정하면 안 된다.

정상 Traffic이 INVALID로 분류되면 Path Symmetry, State Timeout, Fragment와 장비 Capacity를 함께 조사해야 한다.

ㅁ UDP에는 연결 상태가 없는데 Stateful Firewall은 어떻게 할까?

UDP Protocol에는 TCP Handshake와 FIN이 없다.

그래도 Stateful Firewall은 UDP Tuple과 시간을 바탕으로 임시 State를 만들 수 있다.

Client 10.22.1.2:54000
→ DNS Server 198.51.100.53:53

State 생성
Expected Reply
198.51.100.53:53
→ 10.22.1.2:54000

반대 방향 Packet이 일정 시간 안에 오면 기존 UDP Flow의 Reply로 허용할 수 있다.

Traffic이 없으면 UDP State는 Idle Timeout 후 사라진다.

UDP Conntrack State
≠ UDP Protocol이 TCP처럼 연결을 맺음

중간 장비가 편의를 위해 만든 Pseudo-State다.

Application의 응답이 NAT·Firewall Timeout보다 늦으면 정상 Reply도 새롭거나 Invalid한 Traffic처럼 처리될 수 있다.

ㅁ ICMP는 Port가 없는데 무엇으로 판단할까?

ICMP에는 TCP·UDP Port가 없다.

방화벽은 ICMP Type, Code, Source와 Destination, 인용된 원래 Packet과 Conntrack 관계를 사용할 수 있다.

Echo Request / Reply
Destination Unreachable
Time Exceeded
Fragmentation Needed

모든 ICMP를 하나의 Protocol 번호만 보고 허용하거나 차단하면 필요한 제어 기능까지 함께 영향을 받는다.

예를 들어 PMTUD에 필요한 Fragmentation Needed를 차단하면 MTU Black Hole이 생길 수 있다.

ICMP Type과 Code, 방향과 관련 State를 기준으로 필요한 메시지를 구분해야 한다.

ㅁ Rule은 어떤 순서로 읽힐까?

많은 ACL과 Firewall Rule Set은 위에서 아래로 평가해 처음 일치한 Action을 적용한다.

1. Allow TCP from Any to Server Port 443
2. Deny TCP from 203.0.113.0/24 to Server Port 443

첫 Rule이 먼저 일치하면 두 번째의 구체적인 Deny는 도달하지 못한다.

이를 Rule Shadowing이라고 한다.

더 구체적인 Rule과 예외를 앞에 두고 넓은 Rule을 뒤에 두는 방식이 흔한 이유다.

1. Deny 예외 Source
2. Allow 승인된 Source 범위
3. Default Deny

다만 모든 플랫폼이 단순한 First Match 방식인 것은 아니다. Cloud Security Group처럼 여러 Allow Rule을 합산하거나 별도의 우선순위를 사용하는 제품도 있다.

사용 중인 Policy Engine의 평가 순서와 기본 Action을 확인해야 한다.

ㅁ Default Deny는 왜 마지막에 필요할까?

필요한 Traffic을 하나씩 정의한 뒤 나머지를 허용하면 Policy의 빈틈을 예측하기 어렵다.

Default Deny는 명시적으로 허용하지 않은 Traffic을 기본적으로 차단하는 원칙이다.

Allow: 내부 Client → 승인된 DNS Resolver TCP/UDP 53
Allow: 내부 Client → Web Proxy TCP 443
Allow: 기존 Flow의 ESTABLISHED, RELATED Reply
Deny : 그 밖의 Traffic

새 Service가 생기면 자동으로 열리는 것이 아니라 필요성과 범위를 검토한 뒤 Allow Rule을 추가한다.

Default Deny가 곧 좋은 Policy를 보장하는 것은 아니다. Allow Any Any가 앞에 있으면 마지막 Deny는 의미가 없다.

기본 Action과 실제 Allow 범위를 함께 봐야 한다.

ㅁ 최소 권한은 Port 하나만 좁히는 것일까?

Principle of Least Privilege는 업무에 필요한 최소 범위만 허용하는 원칙이다.

다음 차원을 함께 좁힌다.

Source
Destination
Protocol
Destination Port
Direction
Interface 또는 Zone
Connection State
필요한 시간과 운영 주체

예를 들어 “Database Port 5432 허용”만으로는 부족하다.

Source      Application Subnet
Destination Database Server
Protocol    TCP
Port        5432
Direction   App → DB
State       NEW 허용, Return ESTABLISHED

필요한 Flow를 문장으로 설명할 수 있어야 Rule의 목적과 삭제 조건도 관리할 수 있다.

ㅁ Port 443이면 항상 HTTPS일까?

Port Number는 Application을 배치하는 관례이자 Socket 식별 정보다.

어떤 Application도 TCP 443에서 Listen할 수 있다.

Destination Port 443
≠ Payload가 반드시 정상 HTTPS
≠ 상대가 반드시 신뢰할 수 있는 Web Server

Layer 4 Firewall이 Port 443을 허용한다는 것은 해당 TCP Endpoint로 연결할 수 있게 한다는 뜻이다.

HTTP 문법, URL, 사용자 권한과 악성 Payload까지 검증하려면 Application 계층의 추가 통제가 필요하다.

Port 기반 Rule은 중요한 경계이지만 Application Identity의 완전한 증명은 아니다.

ㅁ Source IP를 알면 사용자를 믿을 수 있을까?

Source IP는 Routing과 Policy의 중요한 단서다.

하지만 사용자 Identity와 같지는 않다.

NAT 뒤에서는 여러 사용자가 하나의 Public IP를 공유할 수 있다.
DHCP와 이동 환경에서는 한 사용자의 IP가 바뀔 수 있다.
내부 Network에서도 Source Address Spoofing 가능성을 고려해야 한다.
Proxy와 Load Balancer가 있으면 Server가 직접 보는 Source가 중간 장비일 수 있다.

Source IP Allowlist는 범위를 줄일 수 있지만 강한 사용자 인증을 대신하지 않는다.

서비스 계정, 인증서, Token, Application Authorization 같은 상위 계층 통제가 별도로 필요하다.

ㅁ DROP과 REJECT는 어떻게 다르게 보일까?

Policy에 맞지 않는 Packet을 조용히 버리면 DROP이다.

Client → Firewall : SYN
Firewall          : DROP
Client            : 응답을 기다리고 재전송
최종 결과         : Timeout 가능

거절 사실을 응답으로 알리면 REJECT다.

TCP 연결에는 RST를, 다른 Traffic에는 적절한 ICMP 오류를 돌려보낼 수 있다.

Client → Firewall : SYN
Firewall → Client : TCP RST
최종 결과         : Connection Refused처럼 빠른 실패 가능

REJECT 응답도 Return Route가 없거나 중간에서 차단되면 Client에 도착하지 않는다.

DROP이 항상 더 안전하고 REJECT가 항상 위험하다는 단순한 규칙은 없다.

내부 운영 환경에서는 빠른 REJECT가 장애 진단과 재시도 제어에 도움이 될 수 있다.
외부 경계에서는 정보 노출, 응답 증폭, 운영 요구를 고려해 DROP을 선택할 수 있다.
PMTUD 같은 필요한 ICMP 오류까지 조용히 버리면 정상 통신이 깨진다.

Policy 목적과 Protocol 동작을 함께 봐야 한다.

ㅁ Ingress와 Egress Policy는 왜 둘 다 필요할까?

네트워크에서 Ingress(인그레스)는 외부에서 시스템 내부로 들어오는 트래픽(인바운드)을 의미하며,

Egress(이그레스)는 내부에서 외부로 나가는 트래픽(아웃바운드)을 뜻한다.

Ingress Filtering은 경계로 들어오는 Traffic을 통제한다.

Egress Filtering은 내부에서 외부로 나가는 Traffic을 통제한다.

외부 공격만 생각하고 Egress를 모두 허용하면 다음 문제를 놓칠 수 있다.

침해된 Host가 외부 Command Server에 연결
Data Exfiltration
허가되지 않은 외부 DNS나 SMTP 사용
내부 Source Address를 위조한 Packet의 유출

Ingress: 외부에서 무엇이 들어올 수 있는가?
Egress : 내부에서 무엇이 나갈 수 있는가?

둘 다 Default Deny로 시작할 수 있지만 운영에 필요한 Update, DNS, NTP, Monitoring과 제어 Protocol을 정확히 식별해야 한다.

ㅁ Host Firewall과 Network Firewall은 무엇이 다를까?

Network Firewall은 여러 Network나 Zone의 경계에서 Transit Traffic을 통제한다.

Host Firewall은 개별 Server나 Client의 Network Stack 가까이에서 해당 Host의 Traffic을 통제한다.

Internet
   │
Network Firewall
   │
Server Network
   │
Host Firewall
   │
Application

Network 경계를 통과한 뒤 같은 Subnet의 다른 Host에서 오는 Traffic은 경계 Firewall을 다시 지나지 않을 수 있다.

Host Firewall은 최종 Workload 단위의 Policy를 추가한다.

한쪽이 다른 쪽을 무조건 대체하는 것이 아니라 서로 다른 관찰 위치에서 방어 계층을 만든다.

ㅁ NAT와 Firewall Rule은 어느 주소를 볼까?

같은 장비가 NAT와 Firewall을 모두 수행하면 Packet이 어느 처리 단계에서 Rule과 만나는지가 중요하다.

DNAT 전 Destination: 203.0.113.5:8443
DNAT 후 Destination: 192.168.10.50:443

Firewall Rule이 NAT 전 Public Tuple을 기준으로 쓰이는지,

변환 후 Private Tuple을 기준으로 쓰이는지는 플랫폼과 Hook 위치에 따라 달라질 수 있다.

Policy에는 Public IP를 적었는데 실제 Rule은 DNAT 후 Address를 평가
→ 예상과 다른 Match

Packet Processing Order를 확인하지 않고

NAT와 Firewall Rule을 별개 화면으로만 보면 허용과 차단 원인을 잘못 해석할 수 있다.

Capture도 NAT 전후 Interface에서 함께 해야 한다.

ㅁ Return Path가 다른 Firewall로 가면 어떻게 될까?

Stateful Firewall A가 Client의 SYN을 보고 State를 만들었다.

Forward: Client → Firewall A → Server

Routing이 비대칭이라 SYN-ACK이 Firewall B로 돌아온다고 하자.

Return: Server → Firewall B → Client

Firewall B가 A의 State를 공유하지 않으면 Reply Packet을 기존 Connection과 연결하지 못할 수 있다.

Firewall A: State 있음, Reply는 오지 않음
Firewall B: State 없음, SYN-ACK 도착
→ INVALID 또는 허용되지 않은 NEW처럼 처리 가능

고가용성 Firewall Cluster는 State Synchronization을 제공할 수 있지만

모든 State와 전환 순간이 완벽히 동기화된다고 가정하면 안 된다.

Stateful Middlebox가 있는 경로에서는 Routing Symmetry와 State Ownership이 설계 조건이 된다.

ㅁ State Table도 가득 찰 수 있을까?

Stateful Firewall은 Flow마다 Memory와 Timer를 사용한다.

동시 Connection 증가
Half-Open TCP 증가
UDP Mapping 증가
긴 Timeout
Fragment State 증가
→ State Table 자원 소비

State Table이 가득 차면 기존 Flow는 동작하지만 새 Connection이 실패하거나 장비 처리 성능이 급격히 떨어질 수 있다.

SYN Flood처럼 마지막 ACK를 보내지 않는 요청은 Half-Open State를 쌓을 수 있다.

Capacity Planning에는 최대 동시 Connection 수뿐 아니라

초당 새 Connection 수, Timeout, 평균 Flow 수명과 Failover 동기화 비용도 포함해야 한다.

Stateful이 항상 Stateless보다 우월하다는 뜻은 아니다. 필요한 Policy 표현력과 State 비용을 함께 고려한다.

ㅁ Fragment는 Port Rule을 어떻게 어렵게 할까?

IPv4 Fragment의 첫 조각에는 TCP 또는 UDP Header가 있지만 뒤 Fragment에는 Transport Port가 없을 수 있다.

Fragment 1: IP Header + TCP Header + Data
Fragment 2: IP Header + Data
Fragment 3: IP Header + Data

Port 기반 Rule이 뒤 Fragment만 독립적으로 보면 어느 Service에 속하는지 알기 어렵다.

Stateful Firewall은 Fragment를 추적하거나 Reassembly한 뒤 검사할 수 있지만 Memory와 처리 비용이 필요하다.

비정상 Offset과 겹치는 Fragment는 보안 장비와 Endpoint의 해석 차이를 만들 수 있어 엄격하게 차단될 수 있다.

“첫 Fragment가 허용됐으니 모든 뒤 Fragment도 무조건 안전하다”는 단순한 결론을 피해야 한다.

ㅁ 암호화된 Packet에서 방화벽은 무엇을 볼까?

TLS로 Application Payload가 암호화되면 중간의 일반 Network Firewall은 HTTP 본문과 Password를 읽을 수 없다.

그래도 다음 Metadata는 관찰할 수 있다.

Source와 Destination IP
TCP/UDP Port
Packet 크기와 시간
Connection State
일부 암호화되지 않았거나 별도로 노출되는 Handshake Metadata

TLS Inspection Proxy가 연결을 중간에서 종료하고 다시 암호화하면 Application 내용을 검사할 수 있지만 인증서 신뢰, Privacy, 성능과 Key 관리라는 새로운 책임이 생긴다.

방화벽이 허용한 경로의 내용을 누가 읽을 수 있고 상대를 어떻게 믿을지는 다음 글의 TLS에서 이어진다.

ㅁ IPv4 Rule을 만들면 IPv6도 함께 보호될까?

플랫폼에 따라 IPv4와 IPv6 Rule Set, Address Object와 처리 도구가 분리될 수 있다.

IPv4 Inbound Default Deny 구성 완료
≠ IPv6 Inbound도 같은 Policy 적용 완료

Host와 Network에 IPv6 Address와 Route가 있는데 IPv6 Policy를 확인하지 않으면 의도하지 않은 별도 경로가 열릴 수 있다.

반대로 IPv4에서 사용한 “ICMP는 모두 차단” 같은 Rule을 그대로 복사하면 IPv6의 정상 동작을 깨뜨릴 수 있다.

IPv6는 다음과 같은 ICMPv6 기능에 의존한다.

Neighbor Discovery의 Neighbor Solicitation과 Advertisement
Router Solicitation과 Advertisement
Path MTU Discovery의 Packet Too Big
Time Exceeded와 Parameter Problem 같은 오류 보고

각 메시지가 필요한 위치와 방향은 다르다.

예를 들어 Neighbor Discovery는 같은 Link의 Neighbor를 찾는 Control Traffic이고

Router를 넘어 그대로 Forward하는 일반 Application Traffic이 아니다.

IPv6 Firewall도 Default Deny와 최소 권한을 적용하되,

Protocol이 정상 동작하는 데 필요한 ICMPv6 Type과 Scope를 구분해 허용해야 한다.

ㅁ Logging은 모든 진실을 남길까?

Firewall Log는 Rule Match와 진단에 중요한 증거다.

유용한 항목은 다음과 같다.

Timestamp
Action
Rule ID
Ingress / Egress Interface 또는 Zone
Source / Destination IP와 Port
Protocol
Conntrack State
Packet와 Byte Counter

하지만 모든 Packet을 무제한 기록하면 Log 처리 자체가 병목과 저장 비용을 만든다.

공격자가 많은 Drop Packet을 보내 Logging 자원을 소모하게 할 수도 있다.

Rate Limiting, Flow 단위 Log, Sampling과 중앙 수집을 목적에 맞게 사용한다.

Log가 없다고 Packet이 통과했다는 뜻은 아니고, Log가 있다고 Endpoint Application이 처리했다는 뜻도 아니다.

Rule Counter, Multi-point Capture, Conntrack State와 Application Log를 함께 연결해야 한다.

ㅁ Policy를 작성할 때 어떤 질문을 남겨야 할까?

Rule 한 줄마다 다음 질문에 답할 수 있어야 한다.

어떤 업무 Flow를 위해 필요한가?
Source와 Destination을 더 좁힐 수 있는가?
TCP와 UDP 중 어떤 Protocol인가?
새 연결과 Return Traffic을 어떻게 구분하는가?
ICMP와 DNS 같은 보조 Flow도 필요한가?
Rule의 우선순위와 앞뒤 Shadowing은 없는가?
언제 검토하고 삭제할 것인가?
Drop 시 어떤 Log와 Counter로 검증할 것인가?

좋은 Firewall Policy는 Rule 수가 많은 Policy가 아니다.

업무의 필요한 통신을 최소 범위로 설명하고, 나머지 Traffic이 왜 허용되지 않는지 예측할 수 있는 Policy다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Header와 State로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
봉투마다 주소표만 보고 독립 심사	Stateless ACL	이전 Packet을 기억하지 않고 현재 Header를 Rule과 비교
발신·수신 주소와 창구 번호	5-Tuple	Protocol과 양쪽 IP·Port로 Flow를 구분
처음 접수한 대화의 왕복표	Connection Tracking	Original과 Reply Tuple, State와 Timeout 저장
새 배송 요청	NEW	기존 Entry에 속하지 않는 새 Flow 후보
이미 왕복이 확인된 배송	ESTABLISHED	Conntrack이 양방향 Flow의 일부로 인식
기존 배송에서 생긴 반송 안내	RELATED	기존 Flow와 관련된 ICMP 오류나 보조 Flow
장부와 맞지 않는 봉투	INVALID	정상적인 State로 추적할 수 없는 Packet
명시하지 않은 배송은 기본 거절	Default Deny	Allow Rule에 없는 Traffic을 차단
필요한 주소와 창구만 최소 개방	Least Privilege	업무에 필요한 Source·Destination·Protocol 범위만 허용
말없이 편지를 폐기	DROP	응답 없이 Packet을 버려 Sender가 Timeout을 겪을 수 있음
거절 안내를 돌려보냄	REJECT	TCP RST나 ICMP 오류로 거절을 알림
앞의 넓은 규칙에 뒤 규칙이 가려짐	Rule Shadowing	평가 순서 때문에 뒤 Rule이 Match되지 않음
들어오는 문과 나가는 문을 따로 관리	Ingress / Egress Filtering	양방향 Traffic Policy를 각각 통제

TCP 연결 하나를 Stateful Policy로 판단하는 흐름은 다음과 같다.

Client SYN
NEW + 승인된 Destination:443
        ↓ Allow, State 생성

Server SYN-ACK
기존 Entry의 Reply Tuple + ESTABLISHED
        ↓ Allow

Client ACK와 Data
기존 Entry의 Original Tuple + ESTABLISHED
        ↓ Allow

FIN/RST 또는 Timeout
        ↓ State 정리

그 밖의 새 Inbound Packet
명시적 Allow 없음
        ↓ Default Deny

ㅁ Packet과 State를 직접 관찰해 보기

Wireshark나 tcpdump에서는 Firewall이 통과시키기 전과 후의 Packet을 비교한다.

Client 쪽 Capture : SYN 전송 확인
Firewall 입구     : SYN 도착 확인
Firewall 출구     : SYN 전달 여부
Server 쪽 Capture : SYN 수신 여부

한 지점에서 Packet이 보이지 않는다는 사실만으로 바로 그 지점이 Drop했다고 단정하지 않는다.

앞 구간에서 도착했는지 먼저 확인한다.

Linux에서 Rule과 Counter는 환경에 따라 다음처럼 확인할 수 있다.

sudo iptables -L FORWARD -n -v --line-numbers

Conntrack 도구가 있다면 다음처럼 State를 확인한다.

sudo conntrack -L -p tcp
sudo conntrack -L -p udp

Rule Counter가 증가하면 해당 Rule에 Packet이 Match됐다는 증거다.

그 뒤 Packet이 Destination Application에서 정상 처리됐다는 증거는 아니다.

ㅁ 격리된 Linux 환경에서 Stateful Policy를 관찰해 보기

다음 실습은 ip, iptables, tcpdump, nc가 있는 개인 Linux VM에서 수행한다. 실제 Host Firewall이 아니라 새 Network Namespace 안의 FORWARD Policy만 바꾼다.

fw-client                  fw-router                  fw-server
10.22.1.2 ────────── 10.22.1.1 | 198.51.100.1 ───── 198.51.100.2

Namespace와 가상 Link를 만든다.

sudo ip netns add fw-client
sudo ip netns add fw-router
sudo ip netns add fw-server

sudo ip link add veth-fc type veth peer name veth-fwi
sudo ip link add veth-fwo type veth peer name veth-fs

sudo ip link set veth-fc netns fw-client
sudo ip link set veth-fwi netns fw-router
sudo ip link set veth-fwo netns fw-router
sudo ip link set veth-fs netns fw-server

Address와 Interface를 설정한다.

sudo ip -n fw-client addr add 10.22.1.2/24 dev veth-fc
sudo ip -n fw-router addr add 10.22.1.1/24 dev veth-fwi
sudo ip -n fw-router addr add 198.51.100.1/24 dev veth-fwo
sudo ip -n fw-server addr add 198.51.100.2/24 dev veth-fs

sudo ip -n fw-client link set lo up
sudo ip -n fw-router link set lo up
sudo ip -n fw-server link set lo up
sudo ip -n fw-client link set veth-fc up
sudo ip -n fw-router link set veth-fwi up
sudo ip -n fw-router link set veth-fwo up
sudo ip -n fw-server link set veth-fs up

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n fw-client route add default via 10.22.1.1
sudo ip -n fw-server route add default via 198.51.100.1
sudo ip netns exec fw-router \
  sysctl -w net.ipv4.ip_forward=1

새 Namespace의 FORWARD Chain을 비우고 Default Policy를 DROP으로 설정한다.

sudo ip netns exec fw-router iptables -F FORWARD
sudo ip netns exec fw-router iptables -P FORWARD DROP

INVALID를 차단하고, 기존 Flow의 ESTABLISHED·RELATED Packet을 허용한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -m conntrack --ctstate INVALID -j DROP

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Client Network에서 Server의 TCP 8080으로 시작하는 새 연결만 허용한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -i veth-fwi -o veth-fwo \
  -s 10.22.1.0/24 -d 198.51.100.2 \
  -p tcp --syn --dport 8080 \
  -m conntrack --ctstate NEW -j ACCEPT

Rule 순서와 Counter를 확인한다.

sudo ip netns exec fw-router \
  iptables -L FORWARD -n -v --line-numbers

Capture Terminal에서 Firewall 양쪽 Packet을 저장한다.

sudo ip netns exec fw-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/firewall-state.pcap \
  'tcp port 8080 or tcp port 9090'

Server Terminal에서 8080을 Listen한다.

sudo ip netns exec fw-server nc -l 8080

Client Terminal에서 연결한다.

sudo ip netns exec fw-client nc 198.51.100.2 8080

Client의 SYN은 NEW Allow Rule과 Match한다.

Server의 SYN-ACK은 Source Port 8080에서 Client의 임시 Port로 돌아오지만

기존 Entry의 ESTABLISHED Reply이므로 허용된다.

conntrack이 설치되어 있다면 연결 중 Tuple과 State를 확인한다.

sudo ip netns exec fw-router conntrack -L -p tcp

ㅁ DROP과 REJECT를 같은 경로에서 비교해 보기

8080 연결을 종료한 뒤 Server가 9090에서 Listen하더라도 현재 Allow Rule에는 9090이 없다.

Server Terminal:

sudo ip netns exec fw-server nc -l 9090

Client에서 연결을 시도한다. nc Timeout Option은 구현마다 다를 수 있다.

sudo ip netns exec fw-client \
  nc -v -w 3 198.51.100.2 9090

SYN이 Default DROP에 걸리면 응답이 없어 재전송 후 Timeout으로 보일 수 있다.

이번에는 9090을 명시적으로 REJECT하는 Rule을 추가한다.

sudo ip netns exec fw-router \
  iptables -A FORWARD \
  -i veth-fwi -o veth-fwo \
  -p tcp --dport 9090 \
  -j REJECT --reject-with tcp-reset

같은 Client 명령을 다시 실행하면 Firewall이 보낸 RST 때문에 더 빠르게 실패할 수 있다.

Capture에서 다음 차이를 확인한다.

DROP   : Client SYN 반복, 응답 없음
REJECT : Client SYN 뒤 TCP RST 응답

Rule Counter와 순서도 다시 확인한다.

sudo ip netns exec fw-router \
  iptables -L FORWARD -n -v --line-numbers

실습을 마치면 Namespace를 삭제한다. 내부 Conntrack State와 Firewall Rule도 함께 제거된다.

sudo ip netns del fw-client
sudo ip netns del fw-router
sudo ip netns del fw-server

실제 Host의 기본 Firewall Policy를 실습 목적으로 바꾸지 않는다.

ㅁ 핵심 정리

방화벽은 Packet의 의도를 직접 아는 것이 아니라 Header, 방향, Zone, State를 Policy와 비교한다.
5-Tuple은 Protocol과 Source·Destination IP 및 Port로 Flow를 구분한다.
Stateless ACL은 각 Packet을 독립적으로 판단하므로 요청과 Return Traffic을 양방향 Rule로 표현해야 한다.
TCP ACK Flag 하나는 방화벽이 관찰한 기존 Connection의 증거를 대신하지 못한다.
Stateful Firewall은 Original Tuple과 Reply Tuple, State, Timeout을 Connection Tracking Entry로 기억한다.
Conntrack의 NEW·ESTABLISHED는 Endpoint TCP State나 Application 인증 상태와 같은 개념이 아니다.
RELATED는 기존 Flow에 관련된 ICMP 오류나 보조 Flow를 표현할 수 있고 INVALID는 정상 추적이 어려운 Packet이다.
UDP Conntrack은 Handshake가 아니라 Tuple과 Timeout을 바탕으로 만든 중간 장비의 Pseudo-State다.
Default Deny는 명시적인 Allow가 없는 Traffic을 차단하며 Least Privilege는 필요한 Source·Destination·Protocol 범위를 최소화한다.
Rule 순서와 평가 방식에 따라 넓은 Rule이 구체적인 Rule을 가리는 Shadowing이 생길 수 있다.
DROP은 응답 없이 버려 Timeout을 만들 수 있고 REJECT는 RST나 ICMP로 빠르게 거절을 알릴 수 있다.
NAT, Firewall, Application 인증과 TLS는 각각 주소 변환, 통신 허용, 사용자 권한, 내용 보호라는 다른 문제를 해결한다.
Stateful 장비는 Asymmetric Path, State Table 고갈, Fragment와 Timeout의 영향을 받는다.
Firewall Log와 Rule Counter는 Match 증거이며 Destination Application의 처리 완료 증거는 아니다.
IPv6에서는 Address 공유 NAT가 없어도 Firewall Policy가 필요하고 필수 ICMPv6까지 IPv4 Rule처럼 일괄 차단하면 안 된다.

핵심 용어: Firewall, Packet Filter, Access Control List, ACL, Stateless Firewall, Stateful Firewall, 5-Tuple, Connection Tracking, Conntrack, NEW, ESTABLISHED, RELATED, INVALID, Default Deny, Principle of Least Privilege, Rule Order, Rule Shadowing, ALLOW, DROP, REJECT, Ingress Filtering, Egress Filtering, Host Firewall, Network Firewall, State Table, Asymmetric Routing

방화벽은 좋은 의도를 판별하는 심판이 아니다. 관찰 가능한 주소·Port·방향·연결 상태를 명확한 Policy와 비교하는 장치다. 그래서 보안은 “무엇을 막을까”보다 “어떤 업무 흐름을 왜 허용해야 하는가”를 설명하는 일에서 시작한다.

ㅁ 다음 이야기

Firewall은 필요한 통신 경로를 선택적으로 열었다.

그러나 통과가 허용된 Router와 ISP, Wi-Fi 운영자가 Packet 내용을 읽거나 바꾸지 않을 것이라고 믿을 수는 없다.

주소와 Port를 허용하는 것만으로 상대가 진짜 Server인지, 전달 중 내용이 바뀌지 않았는지 어떻게 확인할까?

다음 글에서는 「우체부를 믿지 않고도 편지 내용을 지킬 수 있을까?」라는 질문을 통해 TLS Handshake, Certificate, Authentication, Key Exchange, Encryption과 Integrity가 서로 다른 문제를 어떻게 함께 해결하는지 살펴본다.

[Container] Kubernetes에서 Docker 이미지 빌드는 왜 어려울까? - Daemon, Root, Privileged의 차이

기록하는 백엔드개발자 — Fri, 24 Jul 2026 16:26:10 +0900

TL;DR

Docker 이미지를 빌드하는 작업은 단순히 파일을 압축하는 과정이 아니다.

Dockerfile의 명령을 실행하고, 파일시스템의 변경 사항을 추적하며, 이를 이미지 레이어로 만드는 작업이 필요하다.

전통적인 docker build에서는 이 작업을 Docker Daemon이 담당한다.

하지만 Docker Daemon은 일반적으로 호스트에서 root 권한으로 실행되고,

Kubernetes Pod 안에서 실행하려면 privileged 권한까지 요구하는 경우가 많다.

따라서 Kubernetes 환경에서는 Docker Daemon을 Pod 안에 실행하는 DinD보다,

제한된 권한으로 이미지를 만들 수 있는 전용 이미지 빌더가 필요하다.

ㅁ 들어가며

이전 [Container] Harbor와 Kaniko는 왜 함께 사용할까? - 이미지는 만들고, 저장하고, 배포한다 글에서는

컨테이너 이미지가 다음 세 단계를 거친다고 정리했다.

Build
  │
  ▼
Store
  │
  ▼
Deploy

Kaniko는 이미지를 만드는 Builder이고,

Harbor는 생성된 이미지를 저장하는 Registry이다.

이 과정에서 다음과 같이 간략히 설명했다.

Kubernetes에서는 Docker Daemon을 실행하지 않는 환경이 많다.

그렇다면 Kubernetes에서는 왜 Docker Daemon을 실행하기 어려울까?

단순히 Docker가 설치되어 있지 않기 때문일까?

이 문제를 이해하려면 먼저 docker build 명령 뒤에서 실제로 어떤 일이 일어나는지 살펴봐야 한다.

ㅁ docker build는 누가 실행할까?

개발자는 이미지를 만들 때 다음 명령을 실행한다.

docker build -t my-app:1.0 .

겉으로 보면 Docker CLI가 Dockerfile을 읽고 이미지를 만드는 것처럼 보인다.

하지만 Docker CLI는 실제 빌드를 직접 수행하지 않는다.

Docker CLI는 Docker Daemon에 빌드를 요청하는 클라이언트이다.

사용자
  │
  ▼
Docker CLI
  │
  │ Build 요청
  ▼
Docker Daemon
  │
  ├─ Dockerfile 해석
  ├─ Base Image 다운로드
  ├─ RUN 명령 실행
  ├─ COPY 파일 반영
  ├─ 파일시스템 변경 추적
  └─ Image Layer 생성

즉, 일반적인 docker build 구조는 다음과 같이 정리할 수 있다.

구성 요소	역할
Docker CLI	사용자의 명령을 Docker Daemon에 전달
Docker Daemon	컨테이너와 이미지 빌드 작업 수행
Docker Registry	생성된 이미지를 저장하고 전달

Docker CLI는 요청만 전달하고, 실제 이미지 생성은 Docker Daemon이 담당한다.

ㅁ 이미지 빌드는 단순한 파일 압축이 아니다

Docker 이미지는 여러 개의 읽기 전용 레이어로 구성된다.

Dockerfile의 명령어가 실행될 때마다 파일시스템이 변경되고, 그 변경 사항이 새로운 레이어로 저장된다.

예를 들어 다음 Dockerfile이 있다고 가정해보자.

FROM ubuntu:24.04

RUN apt-get update
RUN apt-get install -y curl

COPY app.sh /app/app.sh

CMD ["/app/app.sh"]

빌드 과정에서는 다음과 같은 일이 발생한다.

ubuntu:24.04
      │
      ▼
apt-get update 실행
      │
      ▼
변경된 파일을 Layer로 저장
      │
      ▼
curl 설치
      │
      ▼
변경된 파일을 Layer로 저장
      │
      ▼
app.sh 복사
      │
      ▼
변경된 파일을 Layer로 저장

특히 RUN 명령은 단순한 문자열이 아니다.

실제로 명령을 실행할 수 있는 격리 환경을 만들고, 실행 결과로 변경된 파일을 찾아야 한다.

이미지 빌더는 이 과정에서 다음과 같은 작업을 수행한다.

프로세스 실행
파일시스템 마운트
파일 생성과 삭제
소유권과 권한 변경
네트워크 접근
이미지 레이어 생성
레이어 압축 및 저장

따라서 이미지 빌드는 일반 애플리케이션 실행보다 운영체제와 파일시스템에 더 가까운 작업이다.

ㅁ Docker Daemon은 왜 root 권한으로 실행될까?

Docker Daemon은 컨테이너를 만들고 실행하기 위해 Linux 커널의 여러 기능을 사용한다.

대표적으로 다음 기능들이 있다.

커널 기능	역할
Namespace	프로세스, 네트워크, 파일시스템 격리
cgroup	CPU와 메모리 등 자원 제한
OverlayFS	이미지 레이어와 컨테이너 파일시스템 구성
Capability	root 권한을 세분화하여 제공
Virtual Network	컨테이너 네트워크와 브리지 생성

이러한 기능 중 일부는 일반 사용자 권한으로 사용할 수 없거나 추가적인 설정이 필요하다.

그래서 전통적인 Docker Daemon은 호스트에서 root 권한으로 실행된다.

Host OS
  │
  └─ Docker Daemon
       └─ root 권한

Docker Daemon이 root 권한을 갖는다는 것은 Docker Daemon을 제어할 수 있는 사용자도 매우 강한 권한을 가질 수 있다는 의미이다.

ㅁ Docker Socket은 왜 위험할까?

Docker CLI는 일반적으로 Unix Socket을 통해 Docker Daemon과 통신한다.

/var/run/docker.sock

호스트에서 다음 명령을 실행하면 Docker Socket의 위치를 확인할 수 있다.

ls -l /var/run/docker.sock

Kubernetes Pod 안에서 Docker 명령을 사용하기 위해 호스트의 Docker Socket을 마운트하는 방식이 있다.

이를 DooD(Docker out of Docker)라고 부른다.

apiVersion: v1
kind: Pod
metadata:
  name: docker-builder
spec:
  containers:
    - name: docker
      image: docker:cli
      volumeMounts:
        - name: docker-sock
          mountPath: /var/run/docker.sock  <== host docker 통신경로

  volumes:
    - name: docker-sock
      hostPath:
        path: /var/run/docker.sock

구조는 다음과 같다.

Kubernetes Pod
      │
      ▼
/var/run/docker.sock
      │
      ▼
Host Docker Daemon
      │
      ▼
Host Container Runtime

Pod 내부의 Docker CLI는 Pod 안에서 명령을 실행하지만, 실제 작업은 호스트의 Docker Daemon이 수행한다.

문제는 Docker Socket에 접근할 수 있는 프로세스가 호스트 Docker Daemon을 사실상 모두 제어할 수 있다는 점이다.

예를 들어 호스트 파일시스템을 컨테이너에 마운트할 수도 있다.

docker run \
  --rm \
  -it \
  -v /:/host \
  alpine \
  chroot /host

이 명령을 실행할 수 있다면 컨테이너 내부에서 호스트 파일시스템에 접근할 수 있다.

따라서 Docker Socket을 Pod에 마운트하는 것은 단순한 파일 공유가 아니다.

호스트 Docker Daemon의 관리 권한을 Pod에 넘기는 것에 가깝다.

ㅁ DooD와 DinD는 무엇이 다를까?

Kubernetes 환경에서 Docker 이미지를 빌드할 때 자주 등장하는 방식은 DooD와 DinD이다.

DooD: Docker out of Docker

DooD는 Pod 안에서 호스트의 Docker Daemon을 사용한다.

Pod
 │
 ├─ Docker CLI
 │
 └─ Host Docker Socket Mount
          │
          ▼
    Host Docker Daemon

장점은 구조가 단순하고 기존 Docker 명령을 그대로 사용할 수 있다는 점이다.

하지만 Pod가 호스트 Docker Daemon을 직접 제어하기 때문에 보안 위험이 크다.

DinD: Docker in Docker

DinD는 Pod 안에 별도의 Docker Daemon을 실행한다.

Pod
 │
 ├─ Jenkins Agent
 │
 └─ Docker Daemon
       │
       └─ Build Container

호스트 Docker Socket을 직접 공유하지 않는다는 점에서는 DooD와 다르다.

하지만 Pod 내부에서 Docker Daemon이 컨테이너와 파일시스템을 제어하려면 강한 권한이 필요하다.

일반적으로 다음 설정이 필요하다.

securityContext:
  privileged: true

DinD는 호스트 Docker Daemon을 공유하지 않지만, 대신 Pod의 격리 수준을 크게 낮추는 문제가 생긴다.

ㅁ Root와 Privileged는 같은 권한일까?

컨테이너 보안을 이해할 때 가장 혼동하기 쉬운 개념이 root와 privileged이다.

둘은 같은 의미가 아니다.

컨테이너 내부 Root

컨테이너 내부에서 UID 0으로 실행되는 상태이다.

securityContext:
  runAsUser: 0

컨테이너 내부에서는 파일 소유권 변경이나 패키지 설치 같은 작업을 수행할 수 있다.

하지만 일반적인 컨테이너 격리가 유지된다면 호스트 전체를 직접 제어할 수 있는 것은 아니다.

Privileged 컨테이너

Privileged 컨테이너는 일반 컨테이너에 적용되는 여러 보안 제한을 해제한다.

securityContext:
  privileged: true

Privileged 모드에서는 다음과 같은 권한이 확대될 수 있다.

대부분의 Linux Capability 사용
호스트 장치 접근
파일시스템 마운트
네트워크 설정 변경
커널 기능 접근
보안 프로파일 제한 완화

차이를 정리하면 다음과 같다.

구분	컨테이너 내부 Root	Privileged
UID	0	일반적으로 0
컨테이너 격리	유지 가능	크게 완화
Host Device 접근	제한됨	광범위하게 가능
커널 기능 사용	제한됨	대부분 허용
보안 위험	상대적으로 제한적	매우 높음

따라서 다음 문장은 정확하지 않다.

Root 컨테이너와 Privileged 컨테이너는 같다.

더 정확하게 표현하면 다음과 같다.

Privileged 컨테이너는 보통 root로 실행되지만,
컨테이너 내부에서 root로 실행된다고 해서 모두 Privileged 컨테이너인 것은 아니다.

ㅁ DinD는 왜 Privileged 권한을 필요로 할까?

DinD의 Docker Daemon은 Pod 안에서 다시 컨테이너를 생성해야 한다.

이를 위해서는 다음과 같은 작업이 필요하다.

Namespace 생성
cgroup 제어
OverlayFS 마운트
컨테이너 네트워크 생성
iptables 설정
프로세스 격리
파일시스템 레이어 관리

하지만 일반적인 Kubernetes Pod는 이러한 커널 기능을 자유롭게 사용할 수 없다.

그래서 DinD는 보통 다음과 같이 구성된다.

apiVersion: v1
kind: Pod
metadata:
  name: dind-builder
spec:
  containers:
    - name: docker
      image: docker:dind
      securityContext:
        privileged: true

이 설정을 사용하면 Docker Daemon은 동작하기 쉬워진다.

대신 Kubernetes가 제공하는 컨테이너 격리의 상당 부분을 포기하게 된다.

즉, DinD의 문제는 Docker Daemon이 Pod 안에 있다는 사실만이 아니다.

Docker Daemon을 실행하기 위해 Pod에 과도한 권한을 부여해야 한다는 점이 더 큰 문제이다.

ㅁ Kubernetes의 보안 정책과 충돌한다

Kubernetes에는 Pod가 사용할 수 있는 권한을 제한하기 위한 Pod Security Standards가 있다.

대표적인 보안 수준은 다음과 같다.

정책	설명
Privileged	대부분의 권한 허용
Baseline	일반적인 위험 설정 차단
Restricted	최소 권한 원칙을 강하게 적용

DinD에서 사용하는 privileged: true 설정은 Baseline과 Restricted 정책에서 허용되지 않는다.

예를 들어 Namespace에 Restricted 정책이 적용되어 있다면 다음과 같이 설정할 수 있다.

apiVersion: v1
kind: Namespace
metadata:
  name: ci
  labels:
    pod-security.kubernetes.io/enforce: restricted

이 Namespace에 Privileged DinD Pod를 생성하면 Pod 자체가 거부될 수 있다.

Error from server (Forbidden):
pod violates PodSecurity "restricted":
privileged container is not allowed

보안 정책이 강화된 Kubernetes에서는 DinD 파이프라인이 실패하는 이유가 Docker 명령 오류가 아닐 수도 있다.

빌드가 시작되기 전에 Pod 생성 단계에서 거부될 수 있다.

ㅁ Rootless와 Daemonless도 구분해야 한다

이미지 빌드 도구를 비교할 때 다음 세 가지 표현이 자주 등장한다.

Daemonless
Rootless
Unprivileged

비슷해 보이지만 서로 다른 개념이다.

Daemonless

상주하는 Docker Daemon 없이 이미지를 빌드한다.

Dockerfile
   │
   ▼
Builder Process
   │
   ▼
Container Image

Rootless

빌드 프로세스나 관련 런타임을 비root 사용자로 실행한다.

User ID != 0

Unprivileged

Kubernetes Pod에 privileged: true를 설정하지 않고 실행한다.

securityContext:
  privileged: false

차이를 정리하면 다음과 같다.

개념	의미
Daemonless	상주하는 Docker Daemon 없이 빌드
Rootless	비root 사용자 권한으로 실행
Unprivileged	Privileged 컨테이너 없이 실행

Daemonless라고 해서 반드시 Rootless인 것은 아니다.

Root로 실행되더라도 Privileged 권한이나 호스트 Docker Socket 없이 동작하는 빌더가 있을 수 있다.

따라서 이미지 빌더를 선택할 때는 단순히 “Docker Daemon을 사용하지 않는다”는 설명만 확인해서는 부족하다.

다음 항목을 함께 확인해야 한다.

컨테이너 내부에서 root로 실행되는가?
privileged: true가 필요한가?
호스트 Socket을 마운트하는가?
HostPath를 사용하는가?
Linux Capability를 추가하는가?
Seccomp와 AppArmor를 비활성화하는가?

ㅁ Kaniko는 무엇을 바꿨을까?

Kaniko는 Docker Daemon 없이 Dockerfile을 해석하고 컨테이너 이미지를 생성하는 빌더이다.

전통적인 Docker 빌드 구조는 다음과 같다.

Docker CLI
    │
    ▼
Docker Daemon
    │
    ▼
Build Container
    │
    ▼
Container Image

Kaniko의 구조는 다음과 같다.

Dockerfile
    │
    ▼
Kaniko Executor
    │
    ├─ Base Image 추출
    ├─ Dockerfile 명령 실행
    ├─ 파일시스템 변경 탐색
    ├─ Image Layer 생성
    └─ Registry Push

Kaniko는 각 Dockerfile 명령이 실행된 후 파일시스템의 변경 사항을 탐색한다.

변경된 파일을 기준으로 스냅샷을 생성하고, 이를 이미지 레이어로 만든다.

이 과정에서는 Docker Daemon을 실행하지 않는다.

따라서 다음과 같은 구성이 필요하지 않다.

securityContext:
  privileged: true

또한 호스트 Docker Socket을 마운트할 필요도 없다.

/var/run/docker.sock

Kaniko가 Kubernetes CI/CD 환경에서 사용된 핵심 이유는 단순히 Docker 명령을 대체했기 때문이 아니다.

Docker Daemon과 Privileged 권한에 의존하던 이미지 빌드 구조를 변경했기 때문이다.

ㅁ Kaniko가 Root 권한 문제를 모두 해결한 것은 아니다

Kaniko를 설명할 때 다음과 같이 표현하기도 한다.

Kaniko는 Rootless 이미지 빌더이다.

하지만 이 표현은 주의해서 사용해야 한다.

Kaniko의 핵심은 다음 두 가지이다.

Docker Daemon을 요구하지 않는다.
Privileged 컨테이너를 요구하지 않는다.

그러나 Dockerfile에 따라 컨테이너 내부에서 root 권한이 필요한 작업은 여전히 존재할 수 있다.

예를 들어 다음 명령은 파일의 소유권이나 시스템 경로를 변경할 수 있다.

RUN apt-get update
RUN apt-get install -y curl
RUN chown -R app:app /app

따라서 Kaniko의 특징은 다음처럼 표현하는 것이 더 정확하다.

Kaniko는 Docker Daemon과 Privileged 컨테이너 없이 이미지를 빌드할 수 있도록 설계된 이미지 빌더이다.

중요한 것은 컨테이너 내부의 UID가 항상 0이 아닌가가 아니라,

빌드 컨테이너가 호스트 커널과 런타임에 어느 정도의 권한을 갖는가이다.

ㅁ 빌드 방식별 권한 비교

Kubernetes 환경에서 사용할 수 있는 대표적인 빌드 구조를 비교하면 다음과 같다.

방식	Docker Daemon	Docker Socket	Privileged	주요 위험
Host Docker	필요	로컬 사용	Host root	빌드 서버 자체 권한
DooD	Host Daemon 사용	필요	보통 불필요	Host Docker 제어
DinD	Pod 내부 실행	불필요	일반적으로 필요	Pod 격리 약화
Daemonless Builder	불필요	불필요	일반적으로 불필요	빌더별 권한 검토 필요
Rootless Builder	도구에 따라 다름	불필요	불필요	커널과 파일시스템 호환성

단순히 Docker Socket을 제거했다고 보안 문제가 모두 해결되는 것은 아니다.

반대로 Docker Daemon을 사용한다고 해서 모든 구성이 동일하게 위험한 것도 아니다.

중요한 것은 다음 세 가지이다.

Daemon이 어디에서 실행되는가?
          │
          ▼
어떤 사용자 권한으로 실행되는가?
          │
          ▼
Host 자원에 얼마나 접근할 수 있는가?

ㅁ Kubernetes 이미지 빌더를 선택하는 기준

Kubernetes에서 이미지 빌더를 선택할 때는 기능과 성능뿐 아니라 권한 모델을 함께 확인해야 한다.

확인 항목	질문
Daemon	별도의 빌드 Daemon이 필요한가?
Root	비root 사용자로 실행할 수 있는가?
Privileged	privileged: true가 필요한가?
Socket	Host Docker Socket을 마운트하는가?
Storage	OverlayFS나 FUSE 같은 기능이 필요한가?
Security Profile	Seccomp와 AppArmor를 유지할 수 있는가?
Cache	원격 캐시를 사용할 수 있는가?
Registry	결과 이미지를 직접 Registry에 Push할 수 있는가?
Compatibility	기존 Dockerfile을 그대로 사용할 수 있는가?
Maintenance	현재도 유지보수되고 있는 도구인가?

결국 이미지 빌더의 선택은 “어떤 도구가 가장 빠른가?”만의 문제가 아니다.

보안 정책, 빌드 속도, Dockerfile 호환성, 캐시 구조, 운영 난이도를 함께 고려해야 한다.

ㅁ Dockerfile은 같은데 빌드 방식은 달라질 수 있다

이미지 빌더가 달라지더라도 Dockerfile은 동일하게 사용할 수 있는 경우가 많다.

FROM eclipse-temurin:21-jre

COPY app.jar /app/app.jar

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

그러나 Dockerfile을 실행하는 방식은 서로 다를 수 있다.

Docker
  └─ Docker Daemon이 Dockerfile 실행

DinD
  └─ Pod 내부 Docker Daemon이 Dockerfile 실행

Kaniko
  └─ Executor가 Dockerfile 실행 후 Snapshot 생성

BuildKit
  └─ LLB 그래프로 변환하여 빌드 작업 실행

Buildah
  └─ OCI 기반 도구로 컨테이너와 이미지를 구성

즉, Dockerfile은 이미지의 조립 방법을 정의하는 문서이고,

어떤 빌더가 그 문서를 실행하는지는 별도의 문제이다.

ㅁ 마무리 — 문제는 Docker 명령이 아니라 권한 구조다

Kubernetes에서 Docker 이미지 빌드가 어려운 이유는 docker build 명령을 사용할 수 없기 때문이 아니다.

이미지 빌드는 다음과 같은 시스템 작업을 포함하기 때문이다.

프로세스 실행
파일시스템 마운트
레이어 생성
네트워크 접근
파일 권한 변경
컨테이너 격리 환경 구성

전통적인 Docker는 이러한 작업을 root 권한의 Docker Daemon에 맡겼다.

개발자 PC나 전용 빌드 서버에서는 이 구조가 자연스럽게 동작한다.

하지만 Kubernetes에서는 빌드 작업도 일반적인 Pod로 실행된다.

Pod 안에서
다시 Docker Daemon을 실행하려면 Privileged 권한이 필요하고,

호스트 Docker Socket을 공유하면 호스트 제어 권한이 노출될 수 있다.

전통적인 방식

Docker CLI
    │
    ▼
Root Docker Daemon
    │
    ▼
Container Image

Kubernetes에서 필요한 방향

Build Pod
    │
    ▼
제한된 권한의 Image Builder
    │
    ▼
Container Registry

따라서 Kubernetes 이미지 빌드의 핵심 질문은 다음과 같다.

Docker Daemon을 사용할 것인가?

보다 더 정확한 질문은 다음과 같다.

이미지 빌드에 필요한 권한을 어떤 프로세스에, 어느 범위까지 허용할 것인가?

Kaniko와 같은 빌더가 필요했던 이유도 여기에 있다.

Docker Daemon을 단순히 다른 위치로 옮긴 것이 아니라, Kubernetes의 보안 모델에 맞게 이미지 빌드 방식을 다시 설계한 것이다.

ㅁ 함께 보면 좋은 사이트

ㅇ 오픈소스컨설팅 기술 블로그 글 보기

- 컨테이너 이미지 빌드 방식 비교

- 보안 • 성능 • 운영 관점에서 Kaniko를 권장하는 이유

ㅇ 컨테이너 빌드 도구 선택을 위한 특성 및 성능 비교 (Kaniko, Buildah, Buildkit)

[Network] 21. 여러 집이 하나의 공인 주소를 함께 쓸 수 있을까?

기록하는 백엔드개발자 — Thu, 23 Jul 2026 22:21:12 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 7. 인터넷의 주소를 함께 쓰고 경계를 지키는 법

ㅁ 들어가며

집 안에는 Phone, Notebook, TV, Game Console처럼 많은 기기가 있다.

각 기기는 서로 다른 IPv4 주소를 사용한다.

Phone       192.168.10.10
Notebook    192.168.10.20
TV          192.168.10.30
Game Console 192.168.10.40

그런데 인터넷에서 이 집을 바라보면 여러 연결이 하나의 공인 IPv4 주소에서 온 것처럼 보일 수 있다.

Internet에서 보이는 Source IP
203.0.113.5

서로 다른 내부 주소가 어떻게 하나의 외부 주소를 동시에 사용할 수 있을까?

주소만 똑같이 바꾸면 답장이 왔을 때 어느 기기로 돌려줘야 하는지 구분할 수 없다.

203.0.113.5로 답장이 도착
→ Phone의 대화인가?
→ Notebook의 대화인가?
→ TV의 대화인가?

가정용 Router가 흔히 수행하는 기능은 주소만 바꾸는 단순한 NAT가 아니다. Address와 Transport Port를 함께 바꾸고 그 대응 관계를 기억하는 NAPT, 또는 PAT다.

이번 글에서는 Private IPv4 Address, NAT, NAPT/PAT, SNAT, DNAT, Translation Table, Connection Tracking, Port Forwarding, CGNAT를 실제 왕복 Packet으로 추적한다.

ㅁ 모든 기기에 전 세계 고유 주소를 줄 수 없었을까?

IPv4 Address는 32비트다.

2^32 = 4,294,967,296

약 43억 개의 Bit Pattern이 있지만 전부 일반 Host에 자유롭게 배정할 수 있는 것은 아니다. Network 운영과 특수 목적을 위한 범위가 있고, Internet에 연결되는 장비와 서비스는 계속 늘어났다.

IPv4 주소 부족을 완화하기 위해 내부 Network에서는 전 세계적으로 유일하지 않아도 되는 Private Address를 사용할 수 있다.

RFC 1918에서 정의한 범위는 다음과 같다.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

서로 다른 집과 회사가 똑같이 192.168.10.10을 사용해도 내부 Network가 분리되어 있으면 충돌하지 않는다.

집 A의 Notebook  192.168.10.10
집 B의 Notebook  192.168.10.10

각자 내부에서는 서로 다른 Network

하지만 Private Address는 공용 Internet에서 전역적으로 Route되는 주소로 사용하지 않는다.

내부 Host가 Internet Server와 통신하려면 경계 장비가 외부에서 Route 가능한 주소로 바꾸는 과정이 필요하다.

ㅁ 공인 주소와 사설 주소는 보안 등급일까?

Public Address는 공용 Internet에서 전역적으로 Route할 수 있도록 배정·광고되는 주소를 뜻한다.

Private Address는 제한된 내부 Network에서 재사용하도록 예약한 범위다.

Public / Private
→ Routing Scope의 차이
→ 신뢰도나 암호화 등급의 차이가 아님

Public Address가 있다고 누구나 해당 Host에 접속할 수 있는 것은 아니다.

Firewall Policy와 Service Listen 상태가 별도로 허용되어야 한다.

Private Address를 사용한다고 Packet 내용이 자동으로 암호화되거나 내부 Host가 안전해지는 것도 아니다.

이 글의 예시에 사용하는 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24는 문서 예시용 주소 범위다.

실제 공인 주소처럼 인터넷 서비스에 사용하기 위한 값은 아니다.

ㅁ NAT는 정확히 무엇을 바꿀까?

Network Address Translation(NAT)은 경계 장비가 IP Packet의 Address를 다른 Address로 바꾸는 기능을 넓게 가리킨다.

가장 단순한 형태는 하나의 내부 주소를 하나의 외부 주소에 대응시키는 1:1 변환이다.

내부 10.0.0.10
↔ 외부 203.0.113.10

Address Pool에서 사용할 외부 주소를 동적으로 배정할 수도 있다.

내부 Host 여러 개
↔ 외부 Address Pool 여러 개

하지만 하나의 공인 IPv4 Address를 여러 내부 Host가 동시에 공유하려면 IP Address만으로는 부족하다.

Transport Port까지 함께 사용해야 한다.

ㅁ NAT와 NAPT, PAT는 같은 말일까?

Network Address and Port Translation(NAPT)은 IP Address와 TCP·UDP Port를 함께 변환한다.

Port Address Translation(PAT) 또는 Port Overload라고 부르기도 한다.

NAT
└─ Address 변환을 가리키는 넓은 표현

NAPT / PAT
└─ Address와 Port를 함께 변환해 다수 연결을 공유

가정용 Router에서 흔히 “NAT를 한다”고 말할 때 실제 동작은 NAPT인 경우가 많다.

용어를 지나치게 엄격히 나누지 않는 제품도 있지만,

여러 Host가 하나의 공인 주소를 어떻게 동시에 쓰는지 설명하려면 Port 변환을 빼놓을 수 없다.

ㅁ 내부 Client 한 대가 HTTPS 연결을 시작하면

Notebook이 외부 Web Server의 443 Port로 TCP 연결을 시작한다고 하자.

Notebook
192.168.10.20:51514

NAT Router의 Public Address
203.0.113.5

Web Server
198.51.100.20:443

NAT 전 내부 Packet의 5-Tuple은 다음과 같다.

Protocol        TCP
Source IP       192.168.10.20
Source Port     51514
Destination IP  198.51.100.20
Destination Port 443

NAT Router는 외부에서 사용할 Source Port 40001을 배정했다고 하자.

많은 구현은 먼저 원래 Source Port 51514를 그대로 쓰려고 시도하고,

같은 공인 주소에서 그 Port가 이미 다른 연결에 쓰이는 등 충돌이 있을 때만 40001처럼 다른 Port로 재배정한다.

이 글에서는 설명을 위해 바뀐 경우를 예로 든다.

변환 전: 192.168.10.20:51514
변환 후: 203.0.113.5:40001

외부로 나가는 Packet은 다음처럼 보인다.

TCP 203.0.113.5:40001
→   198.51.100.20:443

Destination은 그대로이고 Source Address와 Source Port가 바뀌었다.

이를 Source 기준으로 보면 Source NAT(SNAT)다.

여기서는 Address뿐 아니라 Source Port까지 함께 바꾸므로, 앞서 정의한 NAPT/PAT에도 해당한다.

두 이름은 층위가 다르다.

SNAT는 어느 쪽 주소를 바꾸는가(방향)를, NAPT는 Port까지 바꿔 다수 연결을 공유하는가(기법)를 가리킨다.

ㅁ Router는 답장을 위해 무엇을 기억할까?

NAT Router는 변환하면서 대응 관계를 상태로 저장한다.

설명용 Translation Table의 한 행은 다음과 같다.

Protocol	내부 Endpoint	외부에서 보이는 Endpoint	Remote Endpoint
TCP	192.168.10.20:51514	203.0.113.5:40001	198.51.100.20:443

실제 NAT가 Mapping을 구분하는 범위는 구현과 동작 방식에 따라 다를 수 있다.

Protocol, 내부 Endpoint, Remote Endpoint, Connection State 등이 함께 사용될 수 있다.

핵심은 외부 Tuple을 원래 내부 Tuple로 되돌릴 정보를 기억한다는 점이다.

203.0.113.5:40001로 돌아온 TCP 응답
→ 192.168.10.20:51514로 복원

이 상태가 없으면 공인 주소만 보고 어느 내부 Host와 Socket에 답장을 전달할지 알 수 없다.

ㅁ Server의 답장은 어떻게 원래 Notebook으로 돌아갈까?

Web Server는 자신이 본 Source로 응답한다.

TCP 198.51.100.20:443
→   203.0.113.5:40001

Packet이 NAT Router에 도착하면 Translation Table을 조회한다.

Protocol TCP
Destination 203.0.113.5:40001

Mapping 발견
→ 내부 192.168.10.20:51514

변환된 내부 방향 Packet은 다음과 같다.

TCP 198.51.100.20:443
→   192.168.10.20:51514

나갈 때 Source를 바꾼 것이 SNAT였다면,

돌아올 때는 저장해 둔 대응 관계로 Destination을 원래 내부 Endpoint로 되돌린다.

방향으로 보면 이쪽은 목적지를 바꾸는 변환(Destination NAT, DNAT에 해당)이다.

하나의 연결에서 나갈 때와 돌아올 때가 서로 대칭을 이룬다.

왕복 흐름을 한 번에 보면 다음과 같다.

Notebook                 NAT Router                   Web Server

192.168.10.20:51514
        ────────────────> 203.0.113.5:40001
                              ───────────────────────> 198.51.100.20:443

                              <─────────────────────── 198.51.100.20:443
        <──────────────── 203.0.113.5:40001
192.168.10.20:51514

외부 Server는 원래 Private Address를 보지 않는다.

NAT Router의 Public Address와 변환된 Port를 Client Endpoint로 인식한다.

ㅁ 두 Client가 같은 Source Port를 사용하면 충돌하지 않을까?

Phone과 Notebook이 우연히 같은 Source Port 51514를 사용해 같은 Web Server에 연결한다고 하자.

Phone    192.168.10.10:51514 → 198.51.100.20:443
Notebook 192.168.10.20:51514 → 198.51.100.20:443

NAT Router는 외부 Port를 다르게 배정할 수 있다.

내부 Endpoint	외부에서 보이는 Endpoint	Remote Endpoint
192.168.10.10:51514	203.0.113.5:40001	198.51.100.20:443
192.168.10.20:51514	203.0.113.5:40002	198.51.100.20:443

Server의 응답 Destination Port가 40001이면 Phone으로, 40002이면 Notebook으로 복원한다.

203.0.113.5라는 Address는 공유
40001과 40002라는 Port로 Mapping을 구분

NAPT가 하나의 Public Address를 다수의 동시 Flow로 확장하는 핵심 원리다.

NAT가 항상 원래 Source Port를 바꾸는 것은 아니다.

충돌이 없고 정책이 허용하면 같은 Port를 보존할 수 있으며 필요할 때 다른 Port를 선택할 수 있다.

ㅁ Address와 Port를 바꾸면 Checksum은 어떻게 될까?

IPv4 Header의 Source 또는 Destination Address가 바뀌면 IPv4 Header Checksum도 다시 맞아야 한다.

TCP와 0이 아닌 UDP Checksum 계산에는 IP Source와 Destination을 포함한 Pseudo Header가 관여한다.

Port까지 바뀌므로 Transport Checksum도 영향을 받는다.

NAT가 바꾸는 값
├─ IPv4 Source 또는 Destination Address
├─ TCP/UDP Source 또는 Destination Port 가능
├─ IPv4 Header Checksum 갱신
└─ TCP/UDP Checksum 갱신

실제 구현은 전체를 처음부터 다시 계산하거나 변경분을 이용해 효율적으로 갱신할 수 있다.

IPv4 UDP에서 Checksum Field가 0이면 Checksum을 사용하지 않는다는 특별한 의미이므로 별도로 처리된다.

NAT는 Packet 겉면만 별도의 표에 기록하는 장치가 아니다. 전달 중인 Packet Header를 실제로 수정한다.

그래서 암호학적으로 Header 변경까지 보호하는 Protocol이나

Payload 안에 Address를 직접 넣는 Application은 NAT와 추가 조정이 필요할 수 있다.

ㅁ Translation Table은 언제 만들어지고 사라질까?

동적인 NAPT Mapping은 영구히 남지 않는다.

TCP에서는 SYN, ACK, FIN, RST 같은 Flag와 Connection State를 관찰해 Mapping의 수명을 관리할 수 있다.

TCP SYN 관찰
→ 새 Mapping 생성

ESTABLISHED Traffic
→ State 갱신

FIN/RST 또는 긴 Idle
→ 일정 조건 후 Mapping 제거

UDP에는 TCP Handshake와 FIN이 없다.

NAT는 같은 Tuple의 Packet이 일정 시간 보이지 않으면 UDP Mapping을 만료시키는 식으로 상태를 관리할 수 있다.

UDP Packet 관찰
→ Mapping 생성

Idle Timeout 경과
→ Mapping 제거

구체적인 Timeout은 장비, Protocol, Connection State와 정책에 따라 다르다.

Application이 NAT Mapping을 오래 유지하려고 Keepalive를 사용할 수 있지만 지나치게 잦은 Keepalive는 Battery, Traffic, NAT State를 소비한다.

ㅁ NAT Rule과 Connection Tracking은 같은 표일까?

Linux 같은 Stateful NAT 구현을 생각해 보자.

NAT Rule은 어떤 Traffic을 어떤 방식으로 변환할지 정한다.

내부 Prefix에서 외부 Interface로 나가는 Packet
→ 외부 Address로 Source NAT

첫 Packet이 Rule과 Connection Tracking을 통해 Mapping을 만들면

같은 Flow의 뒤 Packet과 Return Packet에는 저장된 상태가 일관되게 적용된다.

NAT Rule
→ 변환 정책

Conntrack Entry
→ 현재 Flow의 원래 Tuple, 응답 Tuple, State와 변환 관계

NAT Rule 목록의 Packet Counter만 보고 현재 활성 Mapping을 모두 알 수 있는 것은 아니다.

Linux에서는 환경에 따라 conntrack 도구로 활성 Connection Tracking Entry를 관찰할 수 있다.

ㅁ Port도 유한하다면 무한히 공유할 수 있을까?

TCP와 UDP Port Field는 각각 16비트다.

0부터 65,535까지의 값

모든 값을 동적 변환에 자유롭게 사용하는 것도 아니며 이미 사용 중인 Mapping, 예약 범위와 정책이 있다.

하나의 Public Address가 만들 수 있는 동시 Mapping에는 한계가 있다.

내부 Client 수 증가
× Client당 동시 Connection 증가
× 목적지와 Protocol 조합
→ NAT State와 외부 Port 소비 증가

사용 가능한 외부 Port와 Connection Tracking 자원이 부족해

새 Mapping을 만들지 못하는 상황을 Port Exhaustion 또는 NAT Resource Exhaustion이라고 한다.

증상은 기존 연결은 유지되지만 새로운 연결만 간헐적으로 실패하는 모습으로 나타날 수 있다.

장비는 Public Address Pool을 늘리거나 Mapping 재사용 정책, Timeout, Port Block 할당과 Capacity를 조정할 수 있다.

단순히 “Public IP 하나면 내부 Host 수가 무한해진다”는 뜻은 아니다.

ㅁ 외부에서 먼저 연결하면 왜 내부 Host를 찾지 못할까?

외부 Client가 다음 Packet을 보냈다고 하자.

Destination 203.0.113.5:8080

NAT Router에 해당 Port의 기존 Mapping도, 정적인 변환 Rule도 없다.

203.0.113.5:8080
→ 어느 내부 Address와 Port인가?
→ 알 수 없음

동적인 NAPT는 보통 내부에서 먼저 시작한 Flow를 보며 Mapping을 만든다.

외부에서 갑자기 도착한 Packet은 원래 내부 목적지를 복원할 근거가 없다.

내부 Server를 외부에 공개하려면 명시적인 정적 Mapping을 만들 수 있다.

Public 203.0.113.5:8443
→ Private 192.168.10.50:443

이를 Port Forwarding이라고 흔히 부른다.

외부 Packet의 Destination을 내부 Address와 Port로 바꾸므로 Destination NAT(DNAT)의 한 형태다.

외부 Client → 203.0.113.5:8443
NAT Router  → 192.168.10.50:443으로 DNAT

Port Forwarding Rule이 있어도 Firewall이 Forward Traffic을 허용하고

내부 Server가 Listen하며 Return Route가 성립해야 실제 연결이 된다.

ㅁ SNAT와 DNAT는 방향 이름일까?

SNAT와 DNAT는 단순히 “밖으로 나감”과 “안으로 들어옴”의 이름이라기보다 어느 Address Field를 바꾸는지에 초점을 둔다.

SNAT
→ Source Address를 변환

DNAT
→ Destination Address를 변환

일반적인 Internet Access에서는 내부 Packet의 Source를 Public Address로 바꾸는 SNAT가 사용된다.

Port Forwarding이나 Load Balancing에서는 외부 Packet의 Destination을 내부 Server로 바꾸는 DNAT가 사용될 수 있다.

Return Traffic에는 저장된 State에 따라 반대 변환이 적용된다.

Forward 방향 SNAT
↔ Return 방향에서 Destination 복원

Forward 방향 DNAT
↔ Return 방향에서 Source 복원

Packet 방향만 보고 SNAT와 DNAT를 외우기보다 바뀌는 Header Field를 확인하는 편이 정확하다.

ㅁ 내부 Host가 Public Address로 자기 Server에 접속하면

내부 DNS나 설정이 Server의 Public Address 203.0.113.5:8443을 알려 준다고 하자.

내부 Client가 그 주소로 접속하면 Packet이 NAT Router에 갔다가 다시 내부 Server로 돌아와야 한다.

192.168.10.20
→ 203.0.113.5:8443
→ NAT Router
→ 192.168.10.50:443

이를 Hairpin NAT, NAT Loopback, NAT Reflection이라고 부른다.

장비가 해당 동작을 지원하고 DNAT와 Return Path를 일관되게 처리해야 한다.

지원하지 않으면 외부에서는 Public Address로 접속되지만 같은 내부 Network에서는 실패할 수 있다.

내부 DNS가 내부 Address를 따로 응답하는 Split DNS도 한 가지 설계 방법이다.

ㅁ NAT가 있으면 Firewall은 필요 없을까?

동적 NAPT는 Mapping이 없는 외부 Packet을 어느 내부 Host로 보낼지 모른다.

이 특성 때문에 외부에서 먼저 시작한 연결이 자연스럽게 제한되는 경우가 많다.

하지만 NAT와 Firewall은 목적이 다르다.

NAT
→ Address와 Port를 변환

Firewall
→ Policy에 따라 Traffic을 허용하거나 차단

NAT Rule이 곧 보안 허용 Rule인 것도 아니고,

주소를 변환하지 않는 Routed Network에서도 Stateful Firewall을 사용할 수 있다.

반대로 잘못된 Port Forwarding과 넓은 Firewall 허용 Rule이 있으면 NAT 뒤의 Service도 외부에 노출될 수 있다.

NAT가 있으니 안전하다  (X)
Private Address이니 신뢰해도 된다  (X)

다음 글에서는 Firewall이 Packet의 어떤 정보를 보고 별도의 허용 결정을 내리는지 살펴본다.

ㅁ NAT가 내용을 숨겨 주는 암호화일까?

외부 Server는 내부 Private Address 대신 공유 Public Address를 본다.

그렇다고 Packet 내용이 암호화되는 것은 아니다.

NAT가 숨기는 것
→ 외부 Packet Header에서 원래 Private Address

NAT가 숨기지 않는 것
→ 암호화되지 않은 Application Payload
→ 접속한 Destination
→ Traffic 크기와 시간
→ Cookie와 계정 같은 Application 식별자

하나의 Public Address를 공유한다고 사용자들이 서로 암호학적으로 익명화되는 것도 아니다.

내용의 기밀성, 상대 인증과 무결성은 TLS 같은 별도 보안 Protocol이 맡는다.

ㅁ NAT는 End-to-End 모델을 어떻게 바꿨을까?

원래 IP의 기본 모델에서는 두 Endpoint가 서로 Route 가능한 Address를 사용해 직접 Packet을 주고받는 모습을 생각할 수 있다.

NAPT가 중간에 들어오면 Address와 Port가 경계에서 바뀌고 Mapping State가 생긴다.

End Host ── Stateful NAT ── End Host
              │
              └─ Translation State 필요

이 변화는 여러 문제를 만든다.

외부 Peer가 내부 Host로 먼저 연결하기 어렵다.
Return Traffic이 Mapping을 가진 NAT로 돌아와야 한다.
Mapping Timeout보다 긴 Idle Connection은 끊길 수 있다.
Payload 안에 IP와 Port를 기록하는 Protocol은 Header 변환만으로 동작하지 않을 수 있다.
Fragment의 뒤 조각에는 Transport Port가 없어 상태 연결이 복잡하다.
NAT가 여러 겹이면 어느 경계에서 Mapping이 만들어졌는지 추적하기 어렵다.

일부 Protocol은 Application Layer Gateway(ALG), Port Mapping, STUN, TURN, ICE 같은

보조 기술로 NAT Traversal을 시도한다.

NAT는 IPv4 주소 공유를 가능하게 했지만 중간 Network가 End-to-End 대화 상태를 기억하게 만들었다.

ㅁ CGNAT를 지나면 무엇이 하나 더 생길까?

CGNAT(Carrier-Grade NAT)는 인터넷 서비스 제공업체(ISP)가 부족한 공인 IPv4 주소를 아끼기 위해,

여러 명의 사용자에게 하나의 공인 IP를 공유하게 만드는 대규모 네트워크 주소 변환 기술이다.

가정이나 사무실에서 공유기가 사설 IP를 할당하듯, 통신사(ISP)가 한 번 더 사설 IP를 할당하여 인터넷으로 내보낸다.

가정 Router가 한 번 NAT하고 Internet Service Provider가 다시 NAT할 수 있다.

Home Private Address
        ↓ Home NAT
ISP Shared Address
        ↓ Carrier-Grade NAT
Public Internet Address

이를 Carrier-Grade NAT(CGNAT) 또는 Large Scale NAT라고 부른다.

CGNAT 내부에서 사용할 수 있도록 100.64.0.0/10 Shared Address Space가 예약되어 있다.

이 범위는 RFC 1918 Private Address 세 범위에 포함되지 않으며 일반 Public Internet용 주소도 아니다.

CGNAT 환경에서는 다음 제약이 커질 수 있다.

사용자가 ISP NAT의 Port Forwarding을 직접 설정하기 어렵다.
하나의 Public Address를 더 많은 가입자가 공유해 Port 자원이 제한될 수 있다.
장애와 Abuse 추적에는 Public IP뿐 아니라 Source Port와 정확한 시간이 함께 필요하다.
VPN, Game, P2P와 Inbound Service가 NAT Traversal에 더 의존한다.

Public Address만 기록하면 어느 가입자의 어느 Mapping인지 구분하지 못할 수 있다.

ㅁ IPv6에도 주소 공유 NAT가 꼭 필요할까?

IPv6는 매우 큰 Address Space를 제공하므로 IPv4 주소 부족 때문에

여러 Host가 하나의 주소와 Port를 공유해야 했던 이유가 약해진다.

각 Host가 전역적으로 Route 가능한 IPv6 Address를 가질 수 있다.

그렇다고 Firewall이 불필요해지는 것은 아니다.

Address 공유 필요 감소
≠ 모든 Inbound Traffic 허용

Stateful Firewall은 NAT 없이도 내부에서 시작한 Flow의 Return Traffic을 허용하고

외부의 새 연결을 Policy로 제한할 수 있다.

NAT66 같은 IPv6 Address 변환도 존재하지만 IPv4 주소 고갈 완화를 위한 NAPT와 같은 필요성으로 이해하면 안 된다.

Addressing, Routing, Security Policy는 서로 다른 문제다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Header와 State로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
건물 안에서만 사용하는 호수	Private IPv4 Address	내부 Network에서 재사용하는 RFC 1918 주소
외부 우편망에서 보이는 대표 주소	Public IPv4 Address	공용 Internet에서 Route 가능한 주소
봉투의 주소를 대표 주소로 교체	NAT	IP Source 또는 Destination Address 변환
대표 주소와 접수 번호를 함께 교체	NAPT / PAT	Address와 TCP·UDP Port를 함께 변환
발신 주소를 외부 주소로 변경	SNAT	Packet의 Source Address 변환
수신 주소를 내부 Server로 변경	DNAT	Packet의 Destination Address 변환
원래 세대와 외부 접수 번호의 대응표	Translation Table	외부 Tuple을 내부 Tuple로 복원할 Mapping State
외부 창구 번호를 내부 Server에 고정 연결	Port Forwarding	Public Address와 Port를 Private Endpoint로 DNAT
답장이 같은 번역소로 돌아옴	Path Symmetry	Mapping State가 있는 NAT가 Return Traffic 처리
외부 접수 번호가 모두 사용됨	Port Exhaustion	새 동적 Mapping에 사용할 Port나 State 부족
통신사가 한 번 더 대표 주소로 변환	CGNAT	다수 가입자가 ISP의 Public Address Pool을 공유
같은 건물에서 외부 주소로 되돌아 접속	Hairpin NAT	내부 Client가 NAT의 Public Endpoint를 통해 내부 Server 접속

핵심 왕복을 한 번 더 정리하면 다음과 같다.

내부에서 나감
192.168.10.20:51514
        ↓ SNAT + Port Translation
203.0.113.5:40001
        ↓
198.51.100.20:443

외부에서 돌아옴
198.51.100.20:443
        ↓
203.0.113.5:40001
        ↓ Translation State 조회
192.168.10.20:51514

ㅁ Packet Capture에서 무엇을 비교할까?

NAT 장비의 내부와 외부 Interface를 동시에 Capture하면 같은 Flow의 변환 전후를 비교할 수 있다.

Inside Capture
192.168.10.20:51514 → 198.51.100.20:443

Outside Capture
203.0.113.5:40001 → 198.51.100.20:443

확인할 Field는 다음과 같다.

ip.src
ip.dst
tcp.srcport 또는 udp.srcport
tcp.dstport 또는 udp.dstport
ip.checksum
tcp.checksum 또는 udp.checksum

Wireshark의 tcp.stream은 하나의 Capture 안에서 관련 TCP Packet을 따라가는 데 유용하지만

NAT 양쪽 Capture를 별도로 열면 같은 End-to-End 대화가 서로 다른 Tuple로 보일 수 있다.

양쪽 Capture의 시간, TCP Sequence Number, Flag와 Payload 길이를 함께 비교한다.

Router에서 any Interface로 Capture하면 같은 Packet이 변환 전후 Interface에서 두 번 보일 수 있다.

이를 Packet 복제로 오해하지 않고 Capture Interface 정보와 Tuple을 확인한다.

ㅁ 격리된 Linux 환경에서 NAT를 관찰해 보기

다음 실습은 ip, iptables, tcpdump, nc가 있는 개인 Linux VM에서 수행한다.

Documentation Address와 Network Namespace만 사용하므로 실제 Network의 Address나 Firewall을 바꾸지 않는다.

nat-client                nat-router                 nat-server
10.21.0.2 ───────── 10.21.0.1 | 198.51.100.1 ───── 198.51.100.2

Namespace와 가상 Link를 만든다.

sudo ip netns add nat-client
sudo ip netns add nat-router
sudo ip netns add nat-server

sudo ip link add veth-nc type veth peer name veth-nri
sudo ip link add veth-nro type veth peer name veth-ns

sudo ip link set veth-nc netns nat-client
sudo ip link set veth-nri netns nat-router
sudo ip link set veth-nro netns nat-router
sudo ip link set veth-ns netns nat-server

Address와 Interface를 설정한다.

sudo ip -n nat-client addr add 10.21.0.2/24 dev veth-nc
sudo ip -n nat-router addr add 10.21.0.1/24 dev veth-nri
sudo ip -n nat-router addr add 198.51.100.1/24 dev veth-nro
sudo ip -n nat-server addr add 198.51.100.2/24 dev veth-ns

sudo ip -n nat-client link set lo up
sudo ip -n nat-router link set lo up
sudo ip -n nat-server link set lo up
sudo ip -n nat-client link set veth-nc up
sudo ip -n nat-router link set veth-nri up
sudo ip -n nat-router link set veth-nro up
sudo ip -n nat-server link set veth-ns up

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n nat-client route add default via 10.21.0.1
sudo ip -n nat-server route add default via 198.51.100.1
sudo ip netns exec nat-router \
  sysctl -w net.ipv4.ip_forward=1

내부 Prefix에서 외부 Interface로 나가는 Traffic에 MASQUERADE를 적용한다.

sudo ip netns exec nat-router \
  iptables -t nat -A POSTROUTING \
  -s 10.21.0.0/24 -o veth-nro -j MASQUERADE

Router Capture Terminal에서 변환 전후를 함께 저장한다.

sudo ip netns exec nat-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/nat-translation.pcap \
  'tcp port 8080 or tcp port 18080'

Server Terminal에서 Listen한다.

sudo ip netns exec nat-server nc -l 8080

Client Terminal에서 연결하고 짧은 문장을 입력한다.

sudo ip netns exec nat-client nc 198.51.100.2 8080

Capture에서 다음 두 Source를 비교한다.

Router Inside Interface : 10.21.0.2:<client-port>
Router Outside Interface: 198.51.100.1:<translated-port>

원래 Port를 그대로 유지할 수도 있으므로 항상 Port가 달라질 것이라고 가정하지 않는다.

NAT Rule Counter를 확인한다.

sudo ip netns exec nat-router \
  iptables -t nat -L POSTROUTING -n -v

conntrack 도구가 설치되어 있다면 활성 Flow의 원래 Tuple과 응답 Tuple을 확인한다.

sudo ip netns exec nat-router conntrack -L -p tcp

NAT Rule 목록과 Conntrack Entry가 서로 다른 정보를 보여 주는지 비교한다.

ㅁ 같은 환경에서 Port Forwarding을 관찰해 보기

이번에는 외부 nat-server가 NAT Router의 18080 Port로 연결하면 내부 nat-client의 8080 Port로 전달되게 한다.

DNAT Rule을 추가한다.

sudo ip netns exec nat-router \
  iptables -t nat -A PREROUTING \
  -i veth-nro -p tcp --dport 18080 \
  -j DNAT --to-destination 10.21.0.2:8080

내부 Client Terminal에서 Server처럼 Listen한다.

sudo ip netns exec nat-client nc -l 8080

외부 Terminal에서 NAT Router의 외부 Address로 연결한다.

sudo ip netns exec nat-server nc 198.51.100.1 18080

Capture에서 Destination이 어떻게 바뀌는지 확인한다.

변환 전 Destination: 198.51.100.1:18080
변환 후 Destination: 10.21.0.2:8080

실제 운영 환경에서는 DNAT뿐 아니라 Forward Chain의 Firewall 허용 Rule도 필요할 수 있다.

이 Namespace는 기본 Policy가 ACCEPT라는 전제의 관찰용 구성이다.

실습을 마치면 Namespace를 삭제한다. 내부 NAT Rule, Conntrack State와 가상 Interface도 함께 제거된다.

sudo ip netns del nat-client
sudo ip netns del nat-router
sudo ip netns del nat-server

실제 Host의 Firewall이나 NAT Rule을 실습용으로 바꾸지 않는다.

ㅁ 핵심 정리

RFC 1918 Private IPv4 범위는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이다.
Public과 Private은 Routing Scope의 차이이며 보안 등급이나 암호화 여부가 아니다.
NAT는 IP Address 변환을 넓게 가리키고 NAPT/PAT는 Address와 TCP·UDP Port를 함께 변환한다.
가정용 Router가 하나의 Public Address를 여러 Host에 공유할 때 실제 핵심은 Port Mapping이다.
Translation Table과 Connection Tracking State는 외부 Tuple을 원래 내부 Tuple로 복원한다.
NAT는 Address와 Port 변경에 맞춰 IPv4와 TCP·UDP Checksum도 갱신해야 한다.
Dynamic Mapping은 TCP State나 UDP Idle Timeout에 따라 생성되고 만료될 수 있다.
SNAT는 Source Address를, DNAT는 Destination Address를 바꾸며 Return Traffic에는 State에 따른 역변환이 적용된다.
Port Forwarding은 Public Endpoint를 내부 Server에 연결하는 정적 DNAT의 한 형태다.
NAT의 외부 Port와 Connection Tracking 자원은 유한하므로 Port Exhaustion이 생길 수 있다.
NAT는 주소를 변환하고 Firewall은 Policy로 허용 여부를 결정하므로 같은 기능이 아니다.
CGNAT는 ISP 경계에서 가입자들이 Public Address를 다시 공유하며 100.64.0.0/10 Shared Address를 사용할 수 있다.
NAT는 Payload를 암호화하거나 사용자를 익명화하지 않으며 End-to-End 연결에 Mapping State와 Traversal 문제를 추가한다.
IPv6에서 Address 공유 필요가 줄어도 Stateful Firewall Policy는 별도로 필요하다.

핵심 용어: IPv4 Address Exhaustion, RFC 1918, Private Address, Public Address, Network Address Translation, NAT, Network Address and Port Translation, NAPT, Port Address Translation, PAT, SNAT, DNAT, Translation Table, Connection Tracking, Conntrack, Port Mapping, Port Forwarding, MASQUERADE, Hairpin NAT, Port Exhaustion, Carrier-Grade NAT, CGNAT, 100.64.0.0/10, NAT Traversal, End-to-End Principle

여러 Host가 하나의 공인 IPv4 주소를 공유할 수 있는 이유는 대표 주소 하나만 붙였기 때문이 아니다.
외부 Port까지 나누어 쓰고, 그 번호가 어느 내부 Socket의 대화인지 Stateful Translation Table에 기억하기 때문이다.

ㅁ 다음 이야기

NAT Router는 주소와 Port의 변환 관계를 기억한다.

하지만 Mapping이 있다는 사실과 Packet을 보안 정책상 허용해야 한다는 판단은 같은 문제가 아니다.

외부에서 온 새 연결과 내부 요청의 정상 응답은 어떻게 구분할까? Source Address와 Destination Port만 보면 충분할까?

다음 글에서는 「방화벽은 편지의 무엇을 보고 문을 열어줄까?」라는 질문을 통해 Stateless ACL, Stateful Firewall, 5-Tuple, Connection State, Default Deny와 최소 권한 원칙을 살펴본다.

[Container] Harbor와 Kaniko는 왜 함께 사용할까? - 이미지는 만들고, 저장하고, 배포한다

기록하는 백엔드개발자 — Thu, 23 Jul 2026 20:55:26 +0900

TL;DR

컨테이너 이미지를 운영하는 과정은 크게 빌드(Build), 저장(Store), 배포(Deploy) 의 세 단계로 나뉜다.

Kaniko는 Docker 이미지를 생성하는 Builder이고,

Harbor는 생성된 이미지를 저장하는 Registry이다.

둘은 경쟁 관계가 아니라 서로 역할이 다른 프로젝트이며, 함께 사용할 때 가장 큰 효과를 얻을 수 있다.

ㅁ 들어가며

Docker를 처음 공부하면 자연스럽게 다음 명령어를 사용하게 된다.

docker build
docker push
docker pull

하지만 Kubernetes 환경에서는 이야기가 조금 달라진다.

빌드 서버에는 Docker Engine이 없을 수도 있고, 보안상 Docker Daemon을 실행하기 어려운 환경도 많다.

그렇다면 Docker 이미지는 어떻게 만들고 어디에 저장할까?

이 문제를 해결하기 위해 등장한 대표적인 오픈소스가 Kaniko와 Harbor이다.

ㅁ 컨테이너 이미지는 세 단계를 거친다

컨테이너 이미지는 다음과 같은 흐름으로 관리된다.

Source Code
      │
      ▼
Image Build
      │
      ▼
Image Registry
      │
      ▼
Kubernetes

각 단계는 서로 다른 책임을 가진다.

단계	역할
Build	Dockerfile을 이용하여 이미지 생성
Store	생성된 이미지를 저장 및 관리
Deploy	저장된 이미지를 실행

ㅁ Kaniko는 이미지를 만드는 역할

Kaniko는 Dockerfile을 읽어 Docker 이미지를 생성하는 Image Builder이다.

기존에는 Docker 이미지를 만들기 위해 Docker Daemon이 반드시 필요했다.

docker build

하지만 Kubernetes에서는 Docker Daemon을 실행하지 않는 환경이 많다.

Kaniko는 Docker Daemon 없이도 이미지를 생성할 수 있기 때문에 Kubernetes 환경에서 널리 사용된다.

Kaniko의 주요 역할

기능	설명
Dockerfile 실행	Dockerfile 기반 이미지 생성
Docker Daemon 불필요	별도의 Docker Engine 없이 빌드
Kubernetes 실행	Pod 내부에서 이미지 빌드 가능
CI/CD 연동	Jenkins, GitLab CI, Tekton 등과 연계

즉, Kaniko는 이미지를 만드는 것(Build) 에만 집중한다.

ㅁ Harbor는 이미지를 저장하는 역할

이미지가 만들어졌다면 저장할 공간이 필요하다.

Harbor는 Docker Hub를 직접 구축하는 것과 같은 Private Container Registry이다.

Harbor의 주요 역할

기능	설명
이미지 저장	Private Registry 제공
프로젝트 관리	Repository 및 권한 관리
이미지 복제	Registry 간 Replication
취약점 검사	Trivy 기반 이미지 스캔
이미지 서명	Cosign / Notary 지원
웹 UI	이미지 관리 및 검색

즉, Harbor는 이미지를 저장하고 관리하는 것(Store) 에 집중한다.

ㅁ Harbor와 Kaniko는 어떻게 함께 사용할까?

실제 CI/CD에서는 다음과 같은 구조를 많이 사용한다.

Git Repository
        │
        ▼
     Jenkins
(GitLab CI / Tekton)
        │
        ▼
      Kaniko
 (Docker Image Build)
        │
        ▼
      Harbor
 (Image Registry)
        │
        ▼
   Kubernetes
 (Image Pull & Run)

역할을 비교하면 더욱 명확하다.

프로젝트	담당 역할
Kaniko	Dockerfile을 읽어 이미지 생성
Harbor	생성된 이미지 저장 및 관리
Kubernetes	Harbor에서 이미지를 내려받아 실행

ㅁ 왜 역할을 분리할까?

결국 이유는 하나다.

관심사의 분리(Separation of Concerns)

Kaniko는 "어떻게 이미지를 만들 것인가?" 를 책임진다.

Harbor는 "어떻게 이미지를 안전하게 저장하고 관리할 것인가?"를 책임진다.

Kubernetes는 "어떻게 이미지를 실행할 것인가?" 를 책임진다.

각 시스템이 하나의 책임만 가지기 때문에 유지보수가 쉬워지고 확장성도 높아진다.

ㅁ 마무리 — 컨테이너 플랫폼의 핵심 흐름

컨테이너 플랫폼은 단순히 Docker 이미지를 만드는 것으로 끝나지 않는다.

이미지를 빌드(Build) 하고,

안전하게 저장(Store) 하며,

필요한 환경에서 배포(Deploy) 하는

전 과정을 하나의 파이프라인으로 관리해야 한다.

Kaniko와 Harbor는 이 과정에서 각각 Builder와 Registry라는 역할을 맡아 컨테이너 플랫폼의 핵심 기반을 구성한다.

[Search] 검색 미들서버 앞에 Gateway가 필요한 이유 - 검색은 검색만 잘하면 된다

기록하는 백엔드개발자 — Thu, 23 Jul 2026 06:51:00 +0900

TL;DR

검색 미들서버(SMS)의 역할은 좋은 검색 결과를 만드는 것이다.

하지만 실제 서비스에서는 검색과 관계없는 운영 기능이 훨씬 많다.

그래서 대규모 검색 시스템은 SMS 앞단에 Gateway(Reverse Proxy) 를 두고,

요청 분산, 장애 대응, 캐시, 인증 등을 Gateway가 담당하도록 설계한다.

결국 Gateway의 존재 이유는 검색 미들서버가 검색 로직에만 집중하도록 만드는 것이다.

ㅁ 들어가며

어제 회의에서 들었던 검색미들을 위한 Gateway의 역할에 대해서 알게 되었다.

검색 시스템을 처음 접하면서 자연스럽게 이런 생각을 하게 된다.

검색 미들서버가 요청을 받아 검색하고 결과를 돌려주면 되는 것 아닌가?

나 역시 처음에는 그렇게 생각했다.

하지만 실제 서비스에서는 검색보다 운영을 위한 기능이 훨씬 많이 필요하다.

예를 들어 이런 상황을 생각해 보자.

검색 서버가 50대라면 어느 서버로 요청을 보낼까?
특정 서버가 장애가 나면 어떻게 할까?
동일한 검색어는 다시 검색해야 할까?
비정상적인 요청은 어떻게 막을까?
모든 요청 로그는 어디에서 관리할까?

이런 기능을 모두 검색 미들서버가 담당한다면 검색 로직과 운영 로직이 하나의 시스템 안에 뒤섞이게 된다.

ㅁ 검색 미들서버는 검색만 잘하면 된다

검색 미들서버(SMS)의 가장 중요한 역할은 검색이다.

즉,

검색어 분석
검색 정책 적용
랭킹 계산
검색 결과 생성

처럼 검색 품질과 직접 관련된 기능에 집중해야 한다.

반면 운영을 위한 기능은 성격이 전혀 다르다.

Load Balancing
Cache
Authentication
Rate Limiting
Retry
Failover
Logging

이 기능들은 검색 알고리즘과는 아무런 관련이 없다.

그래서 대규모 서비스는 자연스럽게 역할을 분리하게 된다.

ㅁ Gateway가 맡는 역할

검색 시스템은 보통 다음과 같이 구성된다.

Gateway는 검색과 관계없는 공통 기능을 담당한다.

Gateway의 역할	설명
요청 분산	여러 SMS에 트래픽을 균등하게 분배
장애 우회	장애가 발생한 SMS를 자동 제외
캐시	동일 요청을 재사용하여 응답 속도 향상
인증	사용자 인증 및 권한 확인
요청 제한	과도한 요청 차단
로그 수집	모든 요청과 응답 기록
Retry / Timeout	네트워크 오류 자동 처리

반면 SMS는 검색에만 집중한다.

SMS의 역할

검색어 분석

검색 정책 적용

랭킹 계산

검색 결과 생성

ㅁ 대표적인 Gateway 오픈소스

Gateway는 특정 제품이 아니라 역할이다.

대표적으로 다음과 같은 오픈소스가 많이 사용된다.

프로젝트	특징	적합한 환경
Envoy	고성능 L7 Proxy, 동적 라우팅, Observability	Kubernetes, MSA
Apache Traffic Server	HTTP Cache와 Reverse Proxy에 특화	포털, CDN, 검색 서비스
NGINX	범용 Reverse Proxy	대부분의 웹 서비스
HAProxy	초고성능 Load Balancer	금융, 대규모 트래픽

Envoy

https://gateway.envoyproxy.io/

Envoy는 CNCF 프로젝트이며 현재 클라우드 네이티브 환경에서 가장 많이 사용하는 Gateway 중 하나이다.

특히

Service Discovery
Retry
Circuit Breaker
Observability

기능이 뛰어나 Kubernetes 환경에서 사실상의 표준으로 자리 잡았다.

Apache Traffic Server

https://trafficserver.apache.org/

Apache Traffic Server(ATS)는 Yahoo!가 개발한 HTTP Reverse Proxy이다.

특히

HTTP Cache
대규모 트래픽 처리
Reverse Proxy

성능이 뛰어나 CDN과 검색 서비스에서 오랫동안 활용되어 왔다.

검색 시스템에서는 인기 검색어를 캐시하여 검색 미들서버의 부하를 줄이는 데 큰 장점을 가진다.

ㅁ 왜 이렇게 분리할까?

결국 이유는 하나다.

관심사의 분리(Separation of Concerns)

Gateway는

"요청을 안정적으로 전달하는 책임" 을 가진다.

Search Middleware는

"가장 좋은 검색 결과를 만드는 책임" 을 가진다.

각자의 책임이 명확해질수록 시스템은 단순해지고 유지보수는 쉬워진다.

ㅁ 마무리 — 검색 시스템이 커질수록 Gateway의 가치가 커진다

검색 서비스는 규모가 커질수록 검색 알고리즘보다 운영 복잡도가 더 빠르게 증가한다.

이때 Gateway는 검색과 무관한 공통 기능을 모두 흡수하여 검색 미들서버를 단순하게 만든다.

결국 검색 미들서버는 "어떻게 요청을 받을 것인가" 를 고민하는 것이 아니라,

"어떻게 더 좋은 검색 결과를 만들 것인가" 에만 집중할 수 있게 된다.

아마 이것이 대규모 검색 시스템에서 Gateway를 두는 가장 큰 이유일 것이다.

[Network] 20. 가장 좁은 길의 크기를 출발지에서 어떻게 알 수 있을까?

기록하는 백엔드개발자 — Wed, 22 Jul 2026 22:20:32 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 6. 너무 큰 소포와 좁은 길의 문제

ㅁ 들어가며

Source는 자신이 연결된 첫 Link의 MTU를 알 수 있다.

하지만 Destination까지 이어지는 모든 Link의 MTU를 처음부터 알고 있지는 않다.

Source ── 1500 ── R1 ── 1400 ── R2 ── 1280 ── Destination

이 경로에서 단편화 없이 보낼 수 있는 최대 IP Packet은 1280바이트다.

그렇다고 Source가 통신을 시작할 때 모든 Router에 전화를 걸어 MTU를 조사하는 것은 아니다.

Route가 바뀌면 가장 좁은 Link도 달라질 수 있다.

Source는 Packet을 보내고, 전달할 수 없는 Router가 돌려주는 제어 메시지를 단서로 크기를 조절한다.

이 과정이 Path MTU Discovery(PMTUD)다.

문제는 “너무 크다”는 안내가 돌아오지 않을 때 생긴다.

TCP Handshake 성공
작은 요청 성공
큰 Data Packet은 Drop
ICMP 안내도 Drop

→ 연결은 살아 있는 것처럼 보이지만 Data가 멈춤

이번 글에서는

Path MTU, ICMP Fragmentation Needed, ICMPv6 Packet Too Big,

PMTU Cache, MTU Black Hole, MSS Clamping, Packetization Layer PMTUD(PLPMTUD)를

하나의 전달 과정으로 연결한다.

ㅁ Link MTU와 Path MTU는 무엇이 다를까?

Link MTU는 하나의 Link에서 단편화 없이 운반할 수 있는 IP Packet 크기다.

Path MTU는 Source에서 Destination으로 가는 한 방향 경로에 있는 Link MTU 중 가장 작은 값이다.

Link MTU
→ 한 구간의 한계

Path MTU
→ 경로 전체의 최소 한계

다음 경로를 보자.

Source
  │ MTU 1500
  ▼
R1
  │ MTU 1450
  ▼
R2
  │ MTU 1280
  ▼
Destination

계산은 단순하다.

PMTU = min(1500, 1450, 1280)
     = 1280

하지만 실제 인터넷에서는 Source가 이 목록을 직접 가지고 있지 않다.

Forward Path와 Return Path가 다를 수도 있으므로 반대 방향 PMTU도 같다고 보장할 수 없다.

A → B PMTU = 1280
B → A PMTU = 1500

PMTU는 두 Host 사이의 영구적인 고정 속성이 아니라 특정 방향과 현재 경로에 대한 상태다.

ㅁ IPv4 PMTUD는 왜 DF Flag를 사용할까?

IPv4 Router가 큰 Packet을 자동으로 Fragmentation하면 Source는 경로가 좁다는 사실을 모른 채 계속 큰 Packet을 보낼 수 있다.

중간 Fragmentation을 피하려면 Source가 IPv4 Packet에 Don't Fragment(DF) Flag를 설정한다.

Source가 DF=1 Packet 전송
        ↓
Router의 Outgoing MTU 안에 들어감
        ↓
계속 전달

어느 Router에서 Packet이 Outgoing MTU보다 커지면 조건이 달라진다.

Packet Length: 1500
Outgoing MTU : 1400
DF           : 1

→ Router가 Fragmentation할 수 없음
→ Packet Drop
→ Source에 ICMP 오류 전송 가능

DF는 단순히 “조각내지 마라”는 금지 표시에 그치지 않는다.

큰 Packet을 그대로 보내 보고, 지나갈 수 없는 지점에서 명시적인 오류를 받게 만들어 Source가 경로의 한계를 학습하도록 돕는다.

ㅁ Router는 너무 크다는 사실을 어떻게 알릴까?

IPv4 Router는 DF가 설정된 큰 Packet을 전달할 수 없을 때 일반적으로 다음 ICMP 메시지를 만든다.

ICMP Destination Unreachable
Type 3
Code 4
Fragmentation Needed and DF Set

현대적인 형식의 메시지에는 다음 Hop이 받아들일 수 있는 MTU, 즉 Next-Hop MTU가 포함될 수 있다.

Router → Source

이 Packet은 1500바이트다.
다음 Link는 1400바이트까지만 전달할 수 있다.
더 작게 만들어 다시 보내라.

ICMP 오류에는 문제가 된 원래 IP Header와 상위 계층을 식별할 수 있는 원래 Packet의 일부가 인용된다.

Source는 인용된 주소와 Protocol, Port 등의 정보를 이용해 어느 통신에 대한 오류인지 연결할 수 있다.

ICMP 메시지도 새로운 IP Packet이므로 Source로 돌아오는 Route와 정책이 필요하다.

ㅁ Source는 ICMP를 받으면 무엇을 바꿀까?

Source가 Next-Hop MTU 1400이라는 ICMP를 받았다고 하자.

운영체제는 해당 Destination 또는 Route와 관련된 PMTU 상태를 갱신할 수 있다.

기존 추정 PMTU: 1500
ICMP가 알린 MTU: 1400
새 추정 PMTU  : 1400

TCP라면 IP Packet 전체가 새 PMTU 안에 들어가도록 Segment의 Data 크기를 줄인다.

IPv4 Header 20바이트, TCP Header 20바이트만 있다고 가정하면 다음과 같다.

PMTU 1400
- IPv4 Header 20
- TCP Header 20
= TCP Data 최대 1360바이트

Header Option이 있으면 한 Packet에 넣을 Data는 더 작아질 수 있다.

큰 TCP Segment 재전송
→ PMTU에 맞는 더 작은 IP Packet
→ 중간 Fragmentation 없이 전달

PMTUD는 Application의 File 크기를 줄이는 과정이 아니다.

같은 Byte Stream을 더 작은 Packet 단위로 나누어 보내는 과정이다.

ㅁ ICMP 하나를 받으면 경로의 모든 MTU를 알게 될까?

한 번의 오류는 현재 막힌 Link의 한계를 알려 줄 뿐이다.

경로 뒤에 더 좁은 Link가 있을 수 있다.

처음 Packet 1500
→ MTU 1400 Link에서 Drop
→ PMTU를 1400으로 낮춤

다시 Packet 1400
→ MTU 1280 Link에서 Drop
→ PMTU를 1280으로 낮춤

Source는 오류를 받을 때마다 추정치를 더 낮출 수 있다.

따라서 PMTUD는 모든 Link를 먼저 열람해 정답을 한 번에 얻는 절차가 아니다.

보냄
→ 너무 크다는 응답
→ 크기를 줄임
→ 다시 보냄
→ 전달 가능한 크기에 도달

경로가 바뀌거나 PMTU 상태의 유효 시간이 지나면 운영체제가 다시 더 큰 크기를 탐색할 수 있다.

ㅁ PMTU Cache는 왜 영원히 믿을 수 없을까?

매 Packet마다 처음부터 크기를 다시 찾으면 비효율적이다.

운영체제는 발견한 PMTU를 Destination이나 Route 상태와 연관해 일정 시간 기억할 수 있다.

이를 PMTU Cache라고 부른다.

Destination A → PMTU 1500
Destination B → PMTU 1280
Destination C → PMTU 1420

하지만 인터넷 Route는 변한다.

이전 경로: 최소 MTU 1280
새 경로  : 최소 MTU 1500

오래된 작은 값만 영원히 사용하면 전달은 되더라도 필요 이상으로 작은 Packet을 계속 보내 효율이 떨어진다.

반대로 새 경로가 더 좁아졌는데 오래된 큰 값을 믿으면 다시 ICMP 오류나 손실을 만난다.

그래서 PMTU 정보는 구현별 유효 시간과 재검증 과정을 가진 동적인 추정값이다.

Cache의 범위와 갱신 방식은 운영체제마다 다를 수 있다.

ㅁ TCP MSS와 PMTU는 같은 값일까?

둘은 관련 있지만 같은 계층의 값은 아니다.

PMTU
→ 경로가 허용하는 IP Packet 전체 크기

MSS
→ TCP Segment에 담을 Data의 최대 크기

TCP Endpoint는 Handshake의 MSS Option으로 자신이 받을 수 있는 TCP Data 크기를 상대에게 알린다.

Server SYN-ACK: MSS=1460

이는 Server 쪽 Interface 조건을 반영할 수 있지만, 경로 중간의 Tunnel이나 더 작은 Link를 모두 알고 광고한 값이라고 보장할 수 없다.

상대가 광고한 MSS: 1460
중간 경로 PMTU   : 1280
IPv4/TCP 기본 Header 기준 안전한 Data: 1240

Sender는 상대 MSS와 자신이 발견한 PMTU, Header 크기 등을 함께 고려해야 한다.

Handshake가 끝난 뒤 PMTU가 더 작다는 사실을 발견해도 기존 TCP 연결은 더 작은 Segment로 조정할 수 있다. MSS Option을 다시 협상하는 새 Handshake가 필요한 것은 아니다.

ㅁ 왜 TCP Handshake는 되는데 큰 Data만 멈출까?

TCP SYN과 순수 ACK는 Payload가 거의 없어서 IP Packet도 작다.

SYN        : 작은 Packet → 통과
SYN-ACK    : 작은 Packet → 통과
ACK        : 작은 Packet → 통과

큰 Data Segment: PMTU 초과 → Drop

따라서 3-Way Handshake 성공은 큰 Packet도 전달된다는 증거가 아니다.

예를 들어 다음 현상이 나타날 수 있다.

SSH Login과 짧은 명령은 되지만 큰 출력에서 멈춤
작은 HTTP 응답은 되지만 큰 응답이나 Upload가 정체됨
TLS 연결 중 작은 ClientHello는 가지만 큰 인증서 메시지 부근에서 멈춤
VPN 연결 후 일부 Site만 열리지 않음
ping 기본 크기는 성공하지만 큰 DF Probe는 실패

Application 문제처럼 보이지만 Packet 크기 경계가 원인일 수 있다.

ㅁ MTU Black Hole은 어떻게 만들어질까?

다음 경로를 생각해 보자.

Source ── MTU 1500 ── Router ── MTU 1200 ── Destination

Source가 1500바이트 DF Packet을 보낸다.

Router는 1200바이트 Link로 내보낼 수 없어 Packet을 버리고 ICMP Fragmentation Needed를 만든다.

그런데 Firewall이 ICMP Type 3 Code 4를 차단한다.

Source → Router : 큰 DF Packet
Router          : Packet Drop
Router → Source : ICMP Fragmentation Needed
Firewall        : ICMP Drop

Source가 보는 장면은 단순하다.

Packet을 보냈다.
ACK가 오지 않는다.
왜 사라졌는지는 모른다.
같은 크기로 재전송한다.
다시 사라진다.

명시적인 오류도 없고 Data도 앞으로 가지 않는 경로를 PMTU Black Hole 또는 MTU Black Hole이라고 한다.

“ICMP는 ping에만 쓰이니 모두 막아도 된다”는 정책이 정상 TCP 전달을 깨뜨릴 수 있는 대표적인 이유다.

ㅁ 모든 ICMP를 무조건 허용해야 할까?

ICMP가 PMTUD에 필요하다는 사실과 모든 ICMP Packet을 아무 검증 없이 신뢰해야 한다는 말은 다르다.

가짜 ICMP 오류로 PMTU를 불필요하게 낮추려는 입력도 생각할 수 있다.

Host와 Firewall은 다음 정보를 이용해 ICMP 오류가 실제 Flow와 관련되는지 검증할 수 있다.

ICMP에 인용된 원래 Source와 Destination
원래 IP Protocol
인용된 TCP 또는 UDP Port와 Sequence 관련 정보
현재 연결과 Route 상태

네트워크 정책은 필요한 ICMP 오류 종류를 허용하면서 Rate Limiting과 Stateful Validation을 적용할 수 있다.

핵심은 다음 두 극단을 피하는 것이다.

ICMP는 위험하니 전부 Drop       (X)
ICMP라고 표시되면 전부 무조건 신뢰 (X)

정상 전달에 필요한 Control Plane 메시지의 역할과 검증 범위를 함께 설계해야 한다.

ㅁ IPv6 PMTUD는 무엇이 다를까?

IPv6 Router는 지나치게 큰 Packet을 중간에서 Fragmentation하지 않는다.

Outgoing Link로 전달할 수 없으면 Packet을 버리고 Source에 다음 메시지를 보낸다.

ICMPv6 Packet Too Big
Type 2, Code 0
MTU 값 포함

Source는 알려진 MTU에 맞춰 Packet을 더 작게 만들어야 한다.

필요하다면 IPv6 Source가 Fragment Extension Header를 사용해 Fragment할 수 있지만 Router가 대신 나누지는 않는다.

IPv6가 모든 Link에서 기대하는 최소 MTU는 1280바이트다. 1280보다 작은 Link 기술은 IPv6 계층 아래에서 Fragmentation과 Reassembly 같은 적응을 제공해야 한다.

IPv4 PMTUD
→ DF Packet + ICMP Type 3 Code 4

IPv6 PMTUD
→ Router Fragmentation 없음
→ ICMPv6 Type 2 Packet Too Big

ICMPv6 Packet Too Big을 차단하면 IPv6의 정상적인 크기 조절도 깨질 수 있다.

ㅁ ICMP가 오지 않아도 크기를 알아낼 수 있을까?

전통적인 PMTUD는 Router가 보내는 ICMP 오류에 크게 의존한다.

그러나 ICMP가 차단되거나 장비가 올바른 MTU를 알리지 않는 경로도 있다.

Packetization Layer Path MTU Discovery(PLPMTUD)는

TCP 같은 Packetization Layer가 여러 크기의 Probe를 보내고 End-to-End 전달 결과로 사용할 크기를 탐색하는 접근이다.

작은 크기: 전달 성공
조금 큰 Probe: 전달 성공
더 큰 Probe: 응답 없음

→ 확인된 크기와 실패한 크기 사이에서 안전한 값 탐색

PLPMTUD의 핵심은 ICMP만을 유일한 진실로 기다리지 않는 데 있다.

ACK가 돌아온 Probe 크기는 End-to-End로 전달됐음을 확인한다.
큰 Probe가 실패해도 작은 Packet으로 연결 상태를 계속 확인할 수 있다.
ICMP 정보가 도착하면 추가 단서로 활용할 수 있다.

단순한 Data Loss와 크기 때문에 발생한 Loss를 구분하는 일은 쉽지 않다.

그래서 Probe 식별, 재시도, 확인된 Base 크기 같은 상태가 필요하다.

TCP 구현은 반복 재전송에서 Black Hole을 의심해 Segment 크기를 낮추는 완화 동작을 제공할 수도 있다.

구체적인 탐색과 Fallback 방식은 Protocol과 운영체제 구현에 따라 달라진다.

ㅁ PMTUD와 PLPMTUD는 무엇을 관찰할까?

구분	전통적인 PMTUD	PLPMTUD
주요 단서	Router의 ICMP Too Big 오류	End-to-End Probe의 성공과 실패
IPv4 출발점	DF가 설정된 Packet	Packetization Layer가 크기별 Probe 관리
장점	Router가 정확한 Next-Hop MTU를 알려 줄 수 있음	ICMP가 사라져도 탐색 가능
어려움	ICMP 차단 시 Black Hole	Loss 원인이 MTU인지 혼잡인지 구분 필요
상태 위치	IP/Route PMTU 상태	TCP·QUIC 같은 Packetization Layer 상태
공통 목표	중간 Fragmentation 없이 경로가 운반할 수 있는 Packet 크기 사용	같은 목표

두 방식을 서로 완전히 배타적인 선택으로 볼 필요는 없다.

구현은 ICMP 오류를 받아 빠르게 줄이면서 End-to-End Probe로 전달 여부를 검증할 수 있다.

ㅁ MSS Clamping은 무엇을 바꿀까?

Tunnel이나 Firewall 장비가 TCP SYN의 MSS Option을 더 작은 값으로 바꾸는 구성이 있다.

이를 TCP MSS Clamping이라고 한다.

Client SYN MSS=1460
        ↓ Tunnel Gateway가 조정
상대가 보는 MSS=1360

상대는 처음부터 더 작은 TCP Segment를 보내므로 Tunnel 내부에서 PMTU를 넘는 Packet이 생길 가능성을 줄일 수 있다.

MSS Clamping은 다음 상황에서 실용적인 완화책이 될 수 있다.

Tunnel Overhead 때문에 내부 PMTU가 줄어듦
제어할 수 없는 경로에서 ICMP가 잘못 차단됨
TCP 연결이 큰 Segment에서 반복적으로 멈춤

하지만 한계도 분명하다.

TCP SYN의 MSS만 조정하므로 UDP와 다른 Protocol 문제는 해결하지 않는다.
잘못된 값을 사용하면 필요 이상으로 작은 Segment를 만들어 효율이 떨어진다.
ICMP 차단이나 MTU 구성 오류라는 근본 원인을 숨길 수 있다.
이미 성립한 연결의 SYN을 과거로 돌아가 바꾸지는 못한다.

MSS Clamping은 “모든 MTU 문제의 정답”이 아니라 관리 경계에서 신중하게 사용하는 보완책이다.

ㅁ 큰 ping 하나로 PMTU를 확정할 수 있을까?

DF가 설정된 ICMP Echo Request의 크기를 바꾸며 성공 경계를 찾는 방법은 유용한 진단 단서다.

IPv4 Header Option이 없고 ICMP Header가 8바이트라면 다음처럼 계산한다.

추정 PMTU = ping Data 크기 + IPv4 Header 20 + ICMP Header 8

예를 들어 Linux에서 다음 Probe를 사용할 수 있다.

ping -M do -c 1 -s 1472 192.0.2.10

1472 + 20 + 8 = 1500

Data 크기를 1473으로 늘리면 IPv4 Packet은 1501바이트가 된다.

하지만 이 결과 하나만으로 모든 Application의 PMTU를 확정하면 안 된다.

ping Option과 크기 의미는 운영체제마다 다르다.
ICMP Echo만 정책적으로 차단될 수 있다.
ECMP 때문에 Flow별 경로가 다를 수 있다.
반대 방향 PMTU가 다를 수 있다.
Tunnel과 Header Option이 실제 Application Packet 크기를 바꿀 수 있다.

ping은 경계 가설을 시험하는 도구이지 모든 Protocol과 경로의 절대적인 증명서는 아니다.

ㅁ tracepath는 무엇을 보여줄까?

Linux의 tracepath는 Hop을 관찰하면서 PMTU 변화 단서를 표시할 수 있다.

tracepath 192.0.2.10

출력에는 환경에 따라 다음과 같은 정보가 보일 수 있다.

pmtu 1500
...
pmtu 1400

tracepath도 경로 장비의 ICMP 응답, Return Path, 정책의 영향을 받는다.

응답이 없거나 일부 Hop이 보이지 않는다고 해당 Link가 존재하지 않는 것은 아니다.

표시된 PMTU 역시 관찰한 Probe에 기반한 결과다.

권한과 설치 여부, Option은 운영체제와 배포판에 따라 다를 수 있다.

ㅁ Packet Capture에서는 무엇을 찾아야 할까?

IPv4 PMTUD 문제를 조사할 때 다음 흐름을 함께 본다.

큰 TCP Data Packet
→ 같은 Sequence Number의 Retransmission
→ ICMP Type 3 Code 4 존재 여부
→ 재전송 Packet 크기 변화 여부

Wireshark Display Filter 예시는 다음과 같다.

icmp.type == 3 && icmp.code == 4

IPv6 Packet Too Big은 다음처럼 찾을 수 있다.

icmpv6.type == 2

함께 확인할 Field는 다음과 같다.

IPv4: ip.len, ip.flags.df, icmp.type, icmp.code, icmp.mtu
IPv6: ipv6.plen, icmpv6.type, icmpv6.mtu
TCP : tcp.seq, tcp.len, tcp.analysis.retransmission

Capture 지점이 중요하다.

Router 앞에서 큰 Packet 확인
Router 뒤에서 Packet 없음
Source 쪽에서 ICMP 없음

→ Router Drop과 ICMP Return Path를 나누어 조사

NIC Offload 때문에 Host Capture에서 MTU보다 큰 TCP 단위가 보일 수 있으므로 Wire Packet 크기와 혼동하지 않는다.

ㅁ MTU 문제를 진단하는 순서는 무엇일까?

“작은 것은 되고 큰 것은 안 된다”는 증상만으로 곧바로 MTU 문제라고 단정할 수는 없다.

다음 순서로 가설을 좁힐 수 있다.

DNS와 Route, TCP Handshake가 실제로 성공하는지 확인한다.
실패가 전체 연결인지 특정 크기 이후인지 확인한다.
양 Endpoint에서 Packet 크기, DF, Retransmission을 Capture한다.
ICMP Fragmentation Needed 또는 Packet Too Big이 생성되는지 확인한다.
생성된 ICMP가 Source까지 돌아오는지 각 정책 지점을 확인한다.
Interface와 Tunnel MTU, Encapsulation Overhead를 계산한다.
TCP라면 SYN의 MSS와 실제 Segment Payload 크기를 비교한다.
DF Probe와 tracepath 결과를 보조 단서로 사용한다.
임시 MSS Clamping 전에 ICMP와 MTU 구성의 근본 원인을 확인한다.

관찰의 핵심은 실패한 Application만 보는 것이 아니라

큰 Packet이 마지막으로 보인 지점과 ICMP가 마지막으로 보인 지점을 따로 찾는 것이다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Protocol과 상태로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
경로 전체에서 가장 작은 소포 규격	Path MTU	한 방향 경로의 Link MTU 중 최솟값
소포에 나누지 말라는 표시	IPv4 DF Flag	중간 Router의 Fragmentation을 금지
다음 길에는 너무 크다는 반송 안내	ICMP Type 3 Code 4	DF Packet이 Outgoing MTU를 넘었음을 알림
반송장에 적힌 허용 크기	Next-Hop MTU	다음 Link가 전달할 수 있는 Packet 크기
목적지별로 기억한 포장 규격	PMTU Cache	발견한 PMTU를 Route 상태와 연관해 임시 저장
반송 안내가 사라지는 구간	MTU Black Hole	큰 Packet과 ICMP 오류가 모두 전달되지 않아 정체
IPv6의 너무 큰 소포 안내	ICMPv6 Packet Too Big	IPv6 Router가 Source에 MTU 한계를 통보
크기를 조금씩 바꿔 시험 배송	PLPMTUD	End-to-End Probe 성공 여부로 안전한 크기를 탐색
접수 시 소포 본문 한도를 줄임	MSS Clamping	TCP SYN의 MSS 값을 관리 장비가 조정
터널 포장 때문에 줄어든 내부 공간	Encapsulation Overhead	Outer Header만큼 내부에서 쓸 크기가 감소

전체 흐름은 다음과 같다.

Source가 큰 DF Packet 전송
            ↓
     Router의 MTU 초과
            ↓
       Packet Drop
            ↓
ICMP Too Big이 Source에 도착하는가?
       ┌────┴────┐
      Yes        No
       │          │
 PMTU 갱신     같은 크기 재전송
 Packet 축소    ACK 진전 없음
       │          │
 전달 재개     MTU Black Hole

ㅁ 격리된 Linux 환경에서 Black Hole을 관찰해 보기

다음 실습은 ip, iptables, tcpdump, nc가 있는 개인 Linux VM에서만 수행한다.

모든 정책과 MTU 변경은 세 Network Namespace 안에 격리한다.

pmtu-client ── MTU 1500 ── pmtu-router ── MTU 1200 ── pmtu-server

Server Interface는 1500을 유지하고 Router의 Server 방향 Outgoing Interface만 1200으로 설정한다.

이 차이 때문에 Server가 광고한 TCP MSS만으로는 중간의 작은 MTU를 알 수 없다.

Namespace와 가상 Link를 만든다.

sudo ip netns add pmtu-client
sudo ip netns add pmtu-router
sudo ip netns add pmtu-server

sudo ip link add veth-pc type veth peer name veth-prc
sudo ip link add veth-prs type veth peer name veth-ps

sudo ip link set veth-pc netns pmtu-client
sudo ip link set veth-prc netns pmtu-router
sudo ip link set veth-prs netns pmtu-router
sudo ip link set veth-ps netns pmtu-server

Address와 Interface를 설정한다.

sudo ip -n pmtu-client addr add 10.20.1.2/24 dev veth-pc
sudo ip -n pmtu-router addr add 10.20.1.1/24 dev veth-prc
sudo ip -n pmtu-router addr add 10.20.2.1/24 dev veth-prs
sudo ip -n pmtu-server addr add 10.20.2.2/24 dev veth-ps

sudo ip -n pmtu-client link set lo up
sudo ip -n pmtu-router link set lo up
sudo ip -n pmtu-server link set lo up
sudo ip -n pmtu-client link set veth-pc up
sudo ip -n pmtu-router link set veth-prc up
sudo ip -n pmtu-router link set veth-prs up mtu 1200
sudo ip -n pmtu-server link set veth-ps up mtu 1500

Route와 Forwarding을 설정한다.

sudo ip -n pmtu-client route add default via 10.20.1.1
sudo ip -n pmtu-server route add default via 10.20.2.1
sudo ip netns exec pmtu-router \
  sysctl -w net.ipv4.ip_forward=1

Client Terminal에서 Packet을 Capture한다.

sudo ip netns exec pmtu-client \
  tcpdump -n -vv -i veth-pc -s 0 -w /tmp/pmtu-blackhole.pcap \
  'icmp or tcp port 8080'

먼저 Router가 생성한 ICMP Fragmentation Needed를 Router 안에서만 버린다.

sudo ip netns exec pmtu-router \
  iptables -I OUTPUT -p icmp \
  --icmp-type fragmentation-needed -j DROP

Server Terminal에서 TCP 수신을 시작한다. nc Option은 구현마다 다를 수 있다.

sudo ip netns exec pmtu-server nc -l 8080 > /dev/null

Client Terminal에서 충분히 큰 Data를 보낸다.

dd if=/dev/zero bs=1M count=4 | \
  sudo ip netns exec pmtu-client nc 10.20.2.2 8080

다음을 관찰한다.

3-Way Handshake는 작은 Packet이라 성공하는가?
큰 TCP Data Packet의 DF가 설정되어 있는가?
같은 Sequence 범위가 재전송되는가?
Client Capture에 ICMP Type 3 Code 4가 보이지 않는가?

일부 TCP 구현은 반복 손실 후 Black Hole Fallback으로 Segment 크기를 낮춰 스스로 회복할 수 있다.

따라서 “영원히 멈춤” 대신 긴 정체 후 회복으로 보일 수도 있다.

전송이 정체된 동안 Router의 Drop Rule을 제거한다.

sudo ip netns exec pmtu-router \
  iptables -D OUTPUT -p icmp \
  --icmp-type fragmentation-needed -j DROP

다음 큰 재전송에서 Router의 ICMP가 Client에 도착하면 PMTU가 갱신되고 더 작은 TCP Segment로 전송이 재개되는지 확인한다.

별도의 DF Probe로 1200바이트 경계를 확인할 수도 있다.

Linux의 -M probe는 권한이 필요하며 Kernel의 기존 PMTU 확인을 우회해 Probe를 보낸다.

sudo ip netns exec pmtu-client \
  ping -M probe -c 1 -s 1172 10.20.2.2

sudo ip netns exec pmtu-client \
  ping -M probe -c 1 -s 1173 10.20.2.2

1172 + IPv4 20 + ICMP 8 = 1200 → 경계 안
1173 + IPv4 20 + ICMP 8 = 1201 → 경계 초과

iptables가 없거나 nftables Backend 정책이 다른 환경에서는 명령을 그대로 사용할 수 없을 수 있다.

실제 Host Firewall에 Drop Rule을 추가하지 말고 Namespace 내부에서만 실습한다.

실습을 마치면 Namespace를 삭제한다. 내부 Firewall Rule과 가상 Interface도 함께 제거된다.

sudo ip netns del pmtu-client
sudo ip netns del pmtu-router
sudo ip netns del pmtu-server

ㅁ 핵심 정리

Link MTU는 한 Link의 크기 한계이고 Path MTU는 한 방향 경로에 있는 Link MTU의 최솟값이다.
IPv4 PMTUD는 DF Packet이 너무 클 때 Router가 보내는 ICMP Type 3 Code 4를 이용해 PMTU를 낮춘다.
Source는 PMTU에서 IP와 Transport Header를 제외한 크기로 TCP Segment Data를 조절한다.
ICMP 한 번이 경로의 모든 Link를 알려 주는 것은 아니며 더 좁은 Link에서 다시 오류를 받을 수 있다.
PMTU Cache는 Route 변화 때문에 영구적인 정답이 아니며 유효 시간과 재탐색이 필요하다.
TCP MSS는 TCP Data 크기이고 PMTU는 IP Packet 전체 크기이므로 같은 값이 아니다.
TCP Handshake와 작은 Packet이 성공해도 큰 DF Data Packet은 중간 MTU에서 실패할 수 있다.
필요한 ICMP Too Big 오류가 차단되면 Source가 Packet을 줄이지 못하는 MTU Black Hole이 생긴다.
IPv6 Router는 Fragmentation하지 않고 ICMPv6 Type 2 Packet Too Big으로 MTU를 알린다.
PLPMTUD는 End-to-End Probe의 성공과 실패를 이용해 ICMP에만 의존하지 않고 크기를 탐색한다.
MSS Clamping은 TCP의 실용적인 완화책일 수 있지만 UDP를 해결하지 못하고 근본 MTU 오류를 숨길 수 있다.
진단할 때 큰 Packet의 마지막 관찰 지점과 ICMP 오류의 Return Path를 분리해서 확인해야 한다.

핵심 용어: Link MTU, Path MTU, PMTU, Path MTU Discovery, PMTUD, DF, ICMP Type 3 Code 4, Fragmentation Needed, Next-Hop MTU, PMTU Cache, Maximum Segment Size, MSS, MTU Black Hole, ICMPv6 Packet Too Big, Packetization Layer PMTUD, PLPMTUD, MSS Clamping, Encapsulation Overhead

PMTUD는 출발 전에 모든 길의 규격을 읽는 절차가 아니다.
큰 Packet을 보낸 뒤 돌아오는 “이 길에는 너무 크다”는 제어 메시지와 End-to-End 전달 결과로
현재 경로의 한계를 계속 학습하는 과정이다.

ㅁ 다음 이야기

이제 Source는 경로가 허용하는 크기에 맞춰 Packet을 보낼 수 있다.

그러나 IPv4에는 또 다른 한계가 있다. 인터넷에 연결하려는 기기는 계속 늘어났지만 전 세계에서 고유하게 사용할 수 있는 IPv4 주소의 수는 제한되어 있다.

집 안의 여러 Computer와 Phone이 하나의 공인 IPv4 주소로 동시에 인터넷을 사용하는 것은 어떻게 가능할까?

다음 글에서는 「여러 집이 하나의 공인 주소를 함께 쓸 수 있을까?」라는 질문을 통해 Private Address, NAT, NAPT/PAT, Translation Table과 End-to-End 연결의 변화를 살펴본다.

[Network] 19. 작은 편지는 가는데 큰 소포만 멈추는 이유는 무엇일까?

기록하는 백엔드개발자 — Tue, 21 Jul 2026 22:19:12 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 6. 너무 큰 소포와 좁은 길의 문제

ㅁ 들어가며

같은 Server에 연결했는데 짧은 요청은 성공하고 큰 Data를 보낼 때만 멈추는 경우가 있다.

주소도 맞고 Route도 있으며 작은 Packet은 왕복한다. 그렇다면 연결 전체가 끊긴 것은 아니다.

문제는 “얼마나 많이 보내는가”가 아니라 “한 Packet에 얼마나 크게 담았는가”일 수 있다.

전송량의 문제
→ 한동안 몇 Byte를 길 위에 둘 것인가?
→ rwnd, cwnd

Packet 크기의 문제
→ 한 번에 몇 Byte를 한 Link에 실을 수 있는가?
→ MTU

앞 글의 Window는 이동 중인 Data의 총량을 제한했다.

MTU(Maximum Transmission Unit)는 네트워크를 통해 한 번에 전송할 수 있는 최대 데이터 패킷 크기(바이트 단위)를 말한다.

다시 말해, MTU은 한 Link에서 하나의 Network Layer Packet을 단편화 없이 운반할 수 있는 크기를 제한한다.

큰 Packet이 좁은 Link를 만나면 작게 나누거나, 보내지 못한다는 안내를 Source로 돌려보내야 한다.

이번 글에서는

Ethernet MTU, IPv4 Fragmentation, Identification, DF/MF Flag, Fragment Offset, Reassembly, TCP MSS를 실제 Byte 계산으로 살펴본다.

ㅁ 큰 파일과 큰 패킷은 같은 말일까?

1GB 파일을 보낸다고 1GB짜리 IP Packet 하나가 만들어지는 것은 아니다.

Application Data는 여러 계층을 지나며 작은 전송 단위로 나뉜다.

1GB File
   ↓ Application이 Stream에 기록
TCP Segment 여러 개
   ↓
IP Packet 여러 개
   ↓
각 Link의 Frame 여러 개

TCP는 Byte Stream을 MSS에 맞는 Segment로 나누어 보내는 것이 일반적이다.

반대로 Application이 큰 UDP Datagram 하나를 만들면 IP 계층에 큰 Packet 하나로 전달될 수 있고,

경로 조건에 따라 IP Fragmentation이 필요해질 수 있다.

따라서 다음 문장은 구분해야 한다.

큰 파일을 전송한다
≠ 큰 IP Packet 하나를 전송한다

큰 Application Message
≠ 항상 큰 IP Packet 하나

문제의 기준은 전체 업무 Data 크기가 아니라 각 IP Packet이 다음 Link의 MTU 안에 들어가는가다.

ㅁ MTU는 Frame 전체 크기일까?

Ethernet에서 흔히 보는 MTU는 1500바이트다.

이를 “Ethernet Frame 전체가 1500바이트”라고 이해하면 계층의 크기가 섞인다.

일반적인 Ethernet MTU 1500은 Ethernet Payload로 단편화 없이 실을 수 있는 IP Packet의 최대 크기를 뜻한다.

Ethernet Frame
├─ Ethernet Header
├─ Payload: IP Packet, 최대 1500바이트
└─ Frame Check Sequence 등

Ethernet Header와 FCS까지 포함한 실제 Frame은 1500바이트보다 크다.

VLAN Tag, Preamble, Inter-Frame Gap을 어느 계산에 포함하는지도 목적에 따라 달라진다.

Ethernet MTU 1500
→ “선 위의 모든 Byte를 합친 크기”가 아님
→ Layer 3 Packet을 실을 수 있는 Payload 한계

MTU는 Interface와 Link 기술마다 다를 수 있다.

일반 Ethernet에서 흔한 값: 1500
Tunnel 내부에서 Overhead를 고려해 더 작게 설정한 값
모든 구간이 지원하도록 구성한 Jumbo Frame 환경의 더 큰 값
PPP 계열이나 특수 Link의 다른 값

“인터넷의 모든 MTU는 1500”이라는 규칙은 없다.

ㅁ Router는 어느 MTU를 확인할까?

Host A에서 Host B까지 세 Link를 지난다고 하자.

Host A ── MTU 1500 ── R1 ── MTU 1200 ── R2 ── MTU 1500 ── Host B

Host A가 1400바이트 IPv4 Packet을 만들면 첫 Link에는 들어간다.

하지만 R1이 다음 Hop으로 내보낼 Interface의 MTU는 1200이다.

들어온 Packet: 1400바이트
나갈 Link MTU: 1200바이트

1400 > 1200

Router가 확인하는 핵심 한계는 Outgoing Interface의 MTU다.

어떤 Link에서 들어올 수 있었다는 사실이 다음 Link에도 같은 크기로 나갈 수 있음을 보장하지 않는다.

경로 전체에서 가장 작은 MTU를 Path MTU(PMTU)라고 한다.

PMTU = min(경로를 이루는 각 Link의 MTU)

위 경로의 PMTU는 1200이다. Source가 이를 아직 모르면 중간 Router에서 큰 Packet 문제를 처음 만날 수 있다.

ㅁ IPv4 Router는 큰 Packet을 어떻게 나눌까?

IPv4 Packet이 Outgoing MTU보다 크고 Don't Fragment(DF) Flag가 설정되지 않았다면 Router가 Packet을 여러 Fragment로 나눌 수 있다.

원래 IPv4 Packet
        ↓ Fragmentation
Fragment 1
Fragment 2
Fragment 3

각 Fragment는 독립적으로 전달되는 IPv4 Packet이다.

각 Fragment
├─ 자체 IPv4 Header
├─ 원래 Payload의 일부
└─ 같은 원본임을 나타내는 Fragment 정보

한 Frame을 조각내 이어 붙여 보내는 것이 아니다. 원래 IPv4 Payload를 나누고 각 조각 앞에 IPv4 Header를 새로 붙인다.

따라서 Fragmentation은 Header 수와 처리해야 할 Packet 수를 늘린다.

ㅁ 조각은 서로 같은 원본임을 어떻게 알까?

IPv4 Header에는 Fragmentation과 Reassembly에 필요한 Field가 있다.

Identification
Flags
├─ DF: Don't Fragment
└─ MF: More Fragments
Fragment Offset
Total Length

ㅇ Identification

같은 원래 Datagram에서 만들어진 Fragment들이 공유하는 식별값이다.

Destination은 Source Address, Destination Address, Protocol, Identification 같은 정보를 함께 사용해 어느 Fragment가 같은 원본에 속하는지 구분한다.

ㅇ DF — Don't Fragment

DF=1이면 Router가 IPv4 Packet을 단편화하지 말라는 뜻이다.

Packet이 Outgoing MTU보다 크면 Router는 그대로 전달하거나 나눌 수 없으므로 Packet을 버리고 오류를 알릴 수 있다.

ㅇ MF — More Fragments

MF=1이면 이 Fragment 뒤에 원래 Datagram의 조각이 더 있다는 뜻이다.

마지막 Fragment는 MF=0이다.

ㅇ Fragment Offset

이 Fragment의 Payload가 원래 IPv4 Payload에서 어디부터 시작하는지 나타낸다.

Header에는 8바이트 단위로 저장된다.

실제 Payload 시작 위치 = Fragment Offset 값 × 8바이트

마지막을 제외한 Fragment의 Payload 크기를 8바이트 배수로 맞추는 이유가 여기에 있다.

ㅇ Total Length

각 Fragment 자신의 IPv4 Header와 Payload를 합한 전체 길이다.

모든 Fragment의 Total Length가 원래 Packet 길이와 같지는 않다.

ㅁ 4000바이트 Packet은 MTU 1500에서 어떻게 나뉠까?

IPv4 Option이 없는 20바이트 Header를 가정하자.

원래 IPv4 Total Length: 4000바이트
IPv4 Header           :   20바이트
원래 IPv4 Payload     : 3980바이트
Outgoing MTU          : 1500바이트

Fragment 하나에도 20바이트 IPv4 Header가 필요하다.

한 Fragment에 실을 수 있는 최대 Payload는 다음처럼 계산한다.

1500 - 20 = 1480바이트

1480은 8바이트로 나누어떨어진다.

1480 ÷ 8 = 185

첫 번째 Fragment는 원래 Payload의 앞 1480바이트를 담는다.

Fragment 1
Payload 범위 : [0, 1480)
Payload 길이 : 1480
Total Length : 20 + 1480 = 1500
Offset Field : 0 ÷ 8 = 0
MF           : 1

두 번째 Fragment는 그다음 1480바이트를 담는다.

Fragment 2
Payload 범위 : [1480, 2960)
Payload 길이 : 1480
Total Length : 20 + 1480 = 1500
Offset Field : 1480 ÷ 8 = 185
MF           : 1

남은 Payload는 1020바이트다.

3980 - 1480 - 1480 = 1020

세 번째 Fragment가 마지막 조각을 담는다.

Fragment 3
Payload 범위 : [2960, 3980)
Payload 길이 : 1020
Total Length : 20 + 1020 = 1040
Offset Field : 2960 ÷ 8 = 370
MF           : 0

표로 모으면 다음과 같다.

Fragment	Payload 범위	Payload 길이	Total Length	Offset Field	MF
1	[0, 1480)	1480	1500	0	1
2	[1480, 2960)	1480	1500	185	1
3	[2960, 3980)	1020	1040	370	0

세 Fragment의 Payload를 합하면 원래 Payload와 같아야 한다.

1480 + 1480 + 1020 = 3980

각각 새 IPv4 Header를 가지므로 Link를 지나는 IP Byte 수는 늘어난다.

1500 + 1500 + 1040 = 4040바이트

원래 4000바이트보다 40바이트가 늘었다.

원래 하나였던 IPv4 Header가 세 개가 되면서 Header 두 개가 추가된 결과다.

IPv4 Header에 Option이 있으면 Header 길이와 Fragment 계산도 달라질 수 있다.

ㅁ Fragment Offset은 왜 8바이트 단위일까?

IPv4 Header의 Fragment Offset Field는 13비트다.

Byte 단위로만 표현하면 약 8KB 위치까지만 가리킬 수 있다.

8바이트 단위로 해석하면 제한된 Bit로 IPv4 최대 길이 범위의 위치를 나타낼 수 있다.

Offset Field 185
→ 원래 Payload의 185 × 8
→ 1480바이트 위치부터 시작

Packet Capture 도구는 Offset Field의 원래 단위 값이나 Byte로 환산한 위치를 표시할 수 있다.

숫자를 볼 때 도구가 어느 단위를 보여 주는지 함께 확인해야 한다.

핵심은 Offset이 “두 번째 조각” 같은 Fragment 순번이 아니라 원래 Payload 안의 시작 위치라는 점이다.

ㅁ 조각은 중간 Router에서 다시 합칠까?

일반적인 IPv4 Forwarding에서 Router가 만든 Fragment는 최종 Destination에서 Reassembly된다.

Source
  │ 원래 Packet
  ▼
Router R1
  │ Fragmentation
  ├─ F1 ───────────────┐
  ├─ F2 ───────────────┼─> Destination에서 Reassembly
  └─ F3 ───────────────┘

다음 Router가 조각을 다시 합쳐 원본으로 만든 뒤 전달하는 방식이 아니다.

Fragment들은 서로 다른 Queue와 경로를 거칠 수도 있고 순서가 바뀌어 도착할 수도 있다.

Destination은 Fragment Offset을 이용해 제자리를 맞춘다.

도착 순서: F2 → F1 → F3
재조립 결과: F1 + F2 + F3

Destination은 모든 조각이 도착할 때까지 Reassembly 상태와 Buffer를 유지해야 한다.

ㅁ 조각 하나만 사라지면 나머지는 사용할 수 있을까?

원래 IPv4 Packet의 Fragment 세 개 중 두 개만 도착했다고 하자.

F1 도착
F2 손실
F3 도착

IP는 F1과 F3만으로 원래 Payload를 상위 Protocol에 전달할 수 없다.

Reassembly Timer 안에 필요한 Fragment가 모두 모이지 않으면 Destination은 미완성 상태를 버린다.

Fragment 하나 손실
→ 원래 IPv4 Datagram 전체 재조립 실패

IPv4 자체에는 “F2만 다시 보내 달라”는 End-to-End 재전송 기능이 없다.

TCP Data였다면 TCP가 ACK와 Timer로 손실을 감지해 해당 Byte 범위를 재전송할 수 있다.
UDP Datagram이었다면 UDP가 자동으로 원본 Datagram을 재전송하지 않는다.

하나의 큰 Packet이 여러 Fragment로 나뉘면 그중 하나라도 손실될 표면이 커진다.

조각 수가 많을수록 Reassembly 실패 가능성과 처리 비용도 커진다.

ㅁ Fragmentation은 왜 가능하면 피하려 할까?

IPv4 Fragmentation은 서로 다른 MTU를 가진 Link를 이어 주는 호환 장치다.

그러나 비용이 있다.

ㅇ Packet과 Header가 늘어난다

각 Fragment에 IPv4 Header가 필요하므로 전송 Byte와 Packet 처리 횟수가 늘어난다.

ㅇ Fragment 하나의 손실이 원본 전체에 영향을 준다

상위 계층은 완성되지 않은 원래 Datagram을 받지 못한다.

ㅇ Destination의 Reassembly 자원을 사용한다

미완성 Fragment를 일정 시간 기억해야 하므로 Memory와 상태가 필요하다.

ㅇ 중간 장비의 처리가 어려워진다

TCP와 UDP Port는 일반적으로 첫 Fragment의 Transport Header에만 있다.

첫 Fragment
├─ IP Header
├─ TCP/UDP Header
└─ Data 일부

뒤 Fragment
├─ IP Header
└─ Data의 나머지

Firewall이나 NAT가 Transport Port를 기준으로 판단할 때 뒤 Fragment만 보고는 같은 정보를 바로 확인하기 어렵다. 장비는 Fragment 상태를 추적하거나 정책에 따라 Fragment를 제한할 수 있다.

ㅇ 보안 검사가 복잡해진다

비정상적인 Offset이나 겹치는 Fragment는 Reassembly 해석 차이를 악용할 수 있다. 운영체제와 보안 장비는 이런 입력을 엄격하게 처리할 수 있다.

이 때문에 현대의 일반적인 End-to-End 통신은 Source가 Path MTU에 맞는 Packet을 만들어 중간 Router의 Fragmentation을 피하는 방향을 선호한다.

ㅁ DF가 설정된 큰 Packet은 어떻게 될까?

IPv4 Packet이 Outgoing MTU보다 큰데 DF=1이라고 하자.

Router는 Packet을 나눌 수 없다.

Packet 1400바이트
Outgoing MTU 1200
DF=1

→ Fragmentation 금지
→ Packet Drop

Router는 일반적으로 Source에 다음 ICMP 오류를 보낼 수 있다.

ICMP Destination Unreachable
Type 3, Code 4
Fragmentation Needed and DF Set

오류 정보에는 다음 Hop에서 허용되는 MTU 값이 포함될 수 있다.

Source는 이 안내를 바탕으로 더 작은 Packet을 만들어 다시 시도할 수 있다.

하지만 ICMP가 정책으로 차단되거나 Return Path에서 사라지면 Source는 “작게 보내라”는 정보를 얻지 못한다.

작은 Packet → MTU 안에 들어가 성공
큰 Packet   → DF 때문에 Drop
ICMP 안내   → 차단

결과: 연결은 되는 것처럼 보이지만 큰 Data에서 멈춤

이 현상을 Path MTU Black Hole이라고 부른다. Source가 경로의 가장 작은 MTU를 알아내고 이에 대응하는 과정은 다음 글에서 자세히 다룬다.

ㅁ TCP는 큰 Data를 보낼 때 항상 IP Fragmentation을 만들까?

일반적으로는 그렇지 않도록 설계한다.

TCP Handshake에서 Endpoint는 자신이 받을 수 있는 최대 TCP Payload 크기를

Maximum Segment Size(MSS)로 알릴 수 있다.

Ethernet MTU 1500, Option 없는 IPv4 Header 20바이트, 기본 TCP Header 20바이트를 가정하면 다음과 같다.

1500 - IPv4 Header 20 - TCP Header 20
= TCP Payload 1460바이트

따라서 흔히 보는 IPv4 TCP MSS가 1460이다.

IPv6 기본 Header 40바이트를 가정하면 다음과 같다.

1500 - IPv6 Header 40 - TCP Header 20
= TCP Payload 1440바이트

Header Option이나 Extension Header가 있으면 실제 한 Packet에 담을 TCP Data 크기는 더 작아질 수 있다.

TCP는 Application이 수 MB를 한 번에 write()해도 적절한 Segment로 나누어 보낸다.

Application write: 1MB
        ↓
TCP Segment: 대략 MSS 이하의 Payload 여러 개
        ↓
MTU 이하의 IP Packet 여러 개

MSS는 TCP Payload 기준이고 MTU는 IP Packet 전체 기준이라는 차이를 기억해야 한다.

MSS만으로 경로 중간의 더 작은 MTU를 항상 알 수 있는 것은 아니다.

상대가 광고한 MSS는 주로 상대 Interface 쪽 수신 조건을 반영하며,

중간 Tunnel이나 더 좁은 Link는 별도로 발견해야 할 수 있다.

ㅁ UDP와 ping의 크기는 어떻게 계산할까?

IPv4 Option이 없고 MTU가 1500이라고 하자.

하나의 IPv4 Packet에 단편화 없이 담을 수 있는 UDP Payload의 단순 최대값은 다음과 같다.

1500 - IPv4 Header 20 - UDP Header 8
= UDP Payload 1472바이트

ICMP Echo Request의 ping -s 값도 많은 Linux 구현에서 ICMP Data 크기를 뜻한다.

IPv4 Header 20
+ ICMP Header 8
+ ping Data 1472
= IPv4 Total Length 1500

따라서 Ethernet MTU 1500 경로에서 IPv4 ping -s 1472가 경계 확인 예시로 자주 사용된다.

하지만 IP Option, Tunnel, 다른 Link MTU, 명령 구현 차이에 따라 숫자는 달라진다.

ping -s가 항상 IP Packet 전체 크기라는 뜻도 아니다.

UDP API는 1472보다 큰 Datagram을 만들 수 있지만,

그것이 Ethernet MTU 1500 경로에서 하나의 IP Packet으로 그대로 전달된다는 뜻은 아니다.

IPv4 Fragmentation이나 오류가 발생할 수 있다.

ㅁ IPv6 Router도 큰 Packet을 나눌까?

IPv6에서는 중간 Router가 Packet을 Fragmentation하지 않는다.

Router가 다음 Link로 전달하기에 너무 큰 IPv6 Packet을 받으면 Packet을 버리고

Source에 ICMPv6 Packet Too Big 메시지를 보낸다.

IPv4
→ 조건에 따라 Router Fragmentation 가능

IPv6
→ Router Fragmentation 없음
→ Source만 Fragment Header를 사용해 Fragment 가능

따라서 IPv6에서는 Source가 경로의 MTU를 알고 Packet 크기를 조절하는 과정이 필수적이다.

ICMPv6 Packet Too Big을 무조건 차단하면 큰 Packet 전달이 멈출 수 있다.

ICMP가 단순한 진단용 부가 기능이 아니라 정상적인 전달 과정의 제어 메시지이기도 한 이유다.

ㅁ Tunnel을 지나면 왜 MTU가 더 작아질까?

VPN이나 Overlay Tunnel은 원래 Packet 바깥에 새로운 Header를 붙일 수 있다.

Outer IP Header
Tunnel Header
Inner IP Packet

물리 Link가 허용하는 전체 크기는 그대로인데 바깥 Header가 공간을 차지하면 내부 Packet에 사용할 수 있는 크기는 줄어든다.

물리 Link MTU 1500
- Tunnel Overhead
= Tunnel 내부에서 안전한 Packet 크기

Tunnel Endpoint가 내부 Interface MTU를 줄이거나 TCP MSS를 조정하는 이유가 여기에 있다.

반대로 양 끝 Host만 Jumbo Frame을 지원한다고 중간 모든 Link에서 큰 Packet이 통과하는 것도 아니다.

같은 Layer 2 구간과 경로 장비 전체가 해당 크기를 일관되게 지원해야 한다.

ㅁ Capture에서 Fragment를 어떻게 알아볼까?

Wireshark에서 IPv4 Fragment 관련 Field를 확인한다.

ip.id
ip.len
ip.flags.df
ip.flags.mf
ip.frag_offset

IPv4 Fragment를 좁혀 보는 Display Filter는 다음과 같다.

ip.flags.mf == 1 || ip.frag_offset > 0

같은 원래 Datagram의 Fragment에서는 다음을 비교한다.

ip.id가 같은가?
ip.len은 각 Fragment의 Total Length와 맞는가?
마지막을 제외한 Fragment에 MF=1이 있는가?
Offset을 따라 Payload 범위가 이어지는가?
Reassembly 결과가 표시되는가?

뒤 Fragment에는 Transport Header가 없으므로 Wireshark가

첫 Fragment와 Reassembly 상태를 보지 못하면 TCP나 UDP로 완전히 해석하지 못할 수 있다.

ㅁ 큰 Packet처럼 보이는데 실제 Link에도 나갔을까?

Host 내부에서 Packet Capture를 보면 Interface MTU보다 큰 TCP Packet처럼 보일 때가 있다.

Network Interface Card와 Kernel은 CPU 비용을 줄이기 위해 여러 최적화를 사용할 수 있다.

TSO / GSO
→ Kernel에서 큰 단위로 넘기고 NIC 또는 하위 계층에서 실제 전송 크기로 분할

GRO / LRO
→ 받은 여러 Packet을 Host 내부에서 큰 단위로 합쳐 상위 계층에 전달

Capture 지점이 분할 전이거나 병합 후이면 실제 Wire에 존재하지 않았던 큰 단위가 보일 수 있다.

Host Capture에서 32KB로 보임
≠ Wire에 32KB Ethernet Frame 하나가 나감

정확한 Wire 크기를 확인하려면 Offload 영향을 이해하고,

가능하면 다른 장비의 Mirror Port나 적절한 Capture 지점에서 관찰해야 한다.

MTU 문제를 분석할 때 Capture 화면의 한 줄만 보고 “Jumbo Packet이 전송됐다”고 결론 내리면 안 된다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Header와 동작으로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
한 도로가 운반할 수 있는 소포 크기	Link MTU	해당 Link에서 단편화 없이 실을 수 있는 IP Packet 한계
전체 경로에서 가장 좁은 소포 규격	Path MTU	Source와 Destination 경로의 최소 MTU
큰 소포를 여러 상자로 나눔	IPv4 Fragmentation	원래 IP Payload를 나누고 각 조각에 IPv4 Header를 부착
같은 주문의 상자 번호표	Identification	같은 원래 IPv4 Datagram의 Fragment를 연관시킴
절대 나누지 말라는 표시	DF Flag	Router Fragmentation을 금지
뒤에 상자가 더 있다는 표시	MF Flag	마지막이 아닌 Fragment임을 표시
원래 내용에서 조각의 위치	Fragment Offset	8바이트 단위로 Payload 시작 위치 표현
목적지에서 모든 상자를 다시 맞춤	Reassembly	Fragment를 원래 IPv4 Datagram으로 복원
TCP 한 봉투에 넣을 본문 한계	MSS	TCP Segment의 최대 Data 크기
너무 크니 줄여 달라는 반송 안내	ICMP Fragmentation Needed	DF Packet이 MTU를 넘었음을 Source에 알림
포장지가 차지하는 공간	Tunnel Overhead	Outer Header 때문에 내부 Packet 가용 크기가 감소

크기 관계를 한 번 더 정리하면 다음과 같다.

Application Data
       ↓ TCP가 MSS를 고려해 나눔
TCP Header + TCP Data
       ↓ IP Header를 붙임
IP Packet ≤ Path MTU가 되도록 조절
       ↓ Link Header와 Trailer를 붙임
Link Frame

ㅁ 격리된 Linux 환경에서 직접 관찰해 보기

다음 실습은 ip, ping, tcpdump가 있는 개인 Linux VM에서 수행한다. 세 Network Namespace 안에만 가상 경로를 만들며 실제 Interface MTU는 바꾸지 않는다.

mtu-client ── MTU 1500 ── mtu-router ── MTU 1200 ── mtu-server

Namespace와 가상 Link를 만든다.

sudo ip netns add mtu-client
sudo ip netns add mtu-router
sudo ip netns add mtu-server

sudo ip link add veth-c type veth peer name veth-rc
sudo ip link add veth-rs type veth peer name veth-s

sudo ip link set veth-c netns mtu-client
sudo ip link set veth-rc netns mtu-router
sudo ip link set veth-rs netns mtu-router
sudo ip link set veth-s netns mtu-server

Address와 Interface를 설정한다.

sudo ip -n mtu-client addr add 10.19.1.2/24 dev veth-c
sudo ip -n mtu-router addr add 10.19.1.1/24 dev veth-rc
sudo ip -n mtu-router addr add 10.19.2.1/24 dev veth-rs
sudo ip -n mtu-server addr add 10.19.2.2/24 dev veth-s

sudo ip -n mtu-client link set lo up
sudo ip -n mtu-router link set lo up
sudo ip -n mtu-server link set lo up
sudo ip -n mtu-client link set veth-c up
sudo ip -n mtu-router link set veth-rc up
sudo ip -n mtu-router link set veth-rs up mtu 1200
sudo ip -n mtu-server link set veth-s up mtu 1200

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n mtu-client route add default via 10.19.1.1
sudo ip -n mtu-server route add default via 10.19.2.1
sudo ip netns exec mtu-router \
  sysctl -w net.ipv4.ip_forward=1

Capture Terminal에서 Router의 모든 Interface를 관찰한다.

sudo ip netns exec mtu-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/mtu-fragments.pcap \
  'icmp or (ip[6:2] & 0x3fff != 0)'

첫 번째 실험은 DF를 사용하지 않아 Router가 Fragmentation할 수 있게 한다. Linux ping의 -s는 ICMP Data 크기다.

sudo ip netns exec mtu-client \
  ping -M dont -c 1 -s 1400 10.19.2.2

IPv4 Header 20바이트와 ICMP Header 8바이트를 더하면 1428바이트다. 첫 Link의 MTU 1500에는 들어가지만 Router의 다음 Link MTU 1200은 넘는다.

Capture에서 같은 ip.id를 가진 Fragment와 MF, Offset을 확인한다.

두 번째 실험은 DF를 설정한다.

sudo ip netns exec mtu-client \
  ping -M do -c 1 -s 1400 10.19.2.2

Router는 1428바이트 Packet을 MTU 1200 Link로 내보내기 위해 나눌 수 없으므로 Drop하고 ICMP Fragmentation Needed를 돌려보낼 수 있다.

세 번째 실험은 전체 IPv4 Packet을 정확히 1200바이트에 맞춘다.

IPv4 Header 20 + ICMP Header 8 + Data 1172 = 1200

sudo ip netns exec mtu-client \
  ping -M do -c 1 -s 1172 10.19.2.2

DF가 있어도 Packet이 Path MTU 안에 들어가므로 정상 Echo Reply를 기대할 수 있다.

Linux ping -M 동작과 출력은 iputils 버전에 따라 다를 수 있다. 이 실습은 IPv4 기본 Header를 가정하며 Offload와 Kernel 설정에 따라 Capture 표현이 조금 달라질 수 있다.

실습을 마치면 Namespace를 삭제한다. 가상 Interface와 MTU 설정도 함께 제거된다.

sudo ip netns del mtu-client
sudo ip netns del mtu-router
sudo ip netns del mtu-server

공용 Server에 큰 Probe를 반복해서 보내지 않는다. MTU 변경과 고의적인 Fragmentation은 개인 격리 환경에서만 관찰한다.

ㅁ 핵심 정리

큰 파일과 큰 IP Packet은 같은 개념이 아니며 TCP는 큰 Byte Stream을 여러 Segment로 나눈다.
일반적인 Ethernet MTU 1500은 Ethernet Frame 전체가 아니라 Frame Payload로 실을 수 있는 IP Packet 크기 기준이다.
Router는 Packet을 내보낼 Outgoing Interface의 MTU와 IPv4 DF Flag를 확인한다.
IPv4에서 DF가 없으면 Router가 큰 Packet의 Payload를 여러 Fragment로 나눌 수 있다.
같은 원본의 Fragment는 Identification을 공유하고 MF와 Fragment Offset으로 끝과 위치를 나타낸다.
Fragment Offset Field는 8바이트 단위이며 마지막을 제외한 Fragment Payload는 8바이트 배수로 구성된다.
IPv4 Fragment는 일반적으로 최종 Destination에서 Reassembly된다.
Fragment 하나가 손실되면 원래 Datagram 전체를 재조립할 수 없으며 IPv4가 조각만 재전송하지는 않는다.
DF Packet이 Outgoing MTU보다 크면 Router는 Drop하고 ICMP Type 3 Code 4를 보낼 수 있다.
MSS는 TCP Payload 크기이고 MTU는 IP Packet 전체 크기라는 차이가 있다.
IPv6 Router는 Fragmentation하지 않으며 너무 큰 Packet에 ICMPv6 Packet Too Big으로 응답한다.
Tunnel Header와 Offload는 Capture에서 보이는 크기와 실제 Link 크기를 해석할 때 함께 고려해야 한다.

핵심 용어: Maximum Transmission Unit, MTU, Path MTU, IPv4 Fragmentation, Identification, Don't Fragment, DF, More Fragments, MF, Fragment Offset, Total Length, Reassembly, Reassembly Timer, Maximum Segment Size, MSS, ICMP Fragmentation Needed, IPv6 Packet Too Big, Tunnel Overhead, TSO, GSO, GRO, LRO

MTU는 한 번의 배송에 담을 수 있는 IP Packet의 크기다. 큰 Packet을 억지로 조각내면 전달은 이어질 수 있지만, 조각 수와 Header, 손실 표면, 재조립 상태가 함께 늘어난다.

ㅁ 다음 이야기

중간 Router가 큰 IPv4 Packet을 Fragmentation할 수 있다는 것은 알게 되었다.

그러나 현대 네트워크는 중간 Fragmentation을 피하고 Source가 처음부터 경로에 맞는 크기로 보내는 방식을 선호한다.

Source는 아직 가 보지 않은 경로의 가장 작은 MTU를 어떻게 알 수 있을까?

그리고 “너무 크다”는 ICMP 안내가 Firewall에서 사라지면 왜 Handshake와 작은 Data는 되는데 큰 Data만 멈출까?

다음 글에서는 「가장 좁은 길의 크기를 출발지에서 어떻게 알 수 있을까?」라는 질문을 통해 Path MTU Discovery, ICMP Fragmentation Needed, ICMPv6 Packet Too Big, PLPMTUD와 MTU Black Hole을 살펴본다.

[Network] 18. 받는 사람이 감당하지 못할 만큼 보내면 어떻게 될까?

기록하는 백엔드개발자 — Mon, 20 Jul 2026 20:18:37 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 5. 믿을 수 없는 길 위에서 믿을 수 있게 보내기

ㅁ 들어가며

TCP는 잃어버린 Byte를 찾아 다시 보낼 수 있다.

그렇다고 확인 응답이 오기 전에 Data를 무제한으로 보내도 되는 것은 아니다.

받는 Application이 천천히 읽으면 Receiver의 Memory Buffer가 가득 찬다.

양쪽 Computer가 충분히 빨라도 중간 Router로 Packet이 한꺼번에 몰리면 Queue가 넘친다.

겉으로는 둘 다 “Sender가 너무 빨리 보냈다”는 문제처럼 보인다. 그러나 보호해야 할 대상이 다르다.

Receiver가 감당하지 못함
→ Flow Control
→ Receive Window(rwnd)

Network가 감당하지 못함
→ Congestion Control
→ Congestion Window(cwnd)

우편으로 말하면 하나는 수신 창고의 남은 공간이고, 다른 하나는 도시 전체 도로의 혼잡도다.

창고가 넓어도 도로가 막힐 수 있고, 도로가 비어 있어도 창고가 가득 찰 수 있다. TCP는 두 한계를 동시에 지켜야 한다.

이번 글에서는

Receive Buffer, Advertised Window, Sliding Window,

Zero Window, Persist Timer, Congestion Window, Slow Start, Congestion Avoidance를

실제 Byte 수로 연결해 살펴본다.

ㅁ TCP 연결에는 두 개의 대기실이 있다

Application이 TCP를 사용하는 장면을 단순화하면 다음과 같다.

Sending Application
        │ write()
        ▼
   Send Buffer
        │ TCP 전송
        ▼
      Network
        │ TCP 수신
        ▼
  Receive Buffer
        │ read()
        ▼
Receiving Application

Sending Application이 write()한 Data가 즉시 Network로 모두 나가는 것은 아니다.

먼저 운영체제의 Send Buffer에 들어갈 수 있다.

Receiver에서도 Packet이 도착했다고 곧바로 Application 처리가 끝난 것은 아니다.

TCP가 순서를 맞춘 Byte는 Receive Buffer에 머물다가 Application의 read()로 소비된다.

Network 도착 속도 > Application 읽기 속도
→ Receive Buffer 사용량 증가
→ 남은 공간 감소

Receiver가 남은 공간을 Sender에게 알리지 않으면 Sender는 Buffer가 넘칠 때까지 계속 보낼 수 있다.

이 문제를 막는 것이 TCP Flow Control, 흐름 제어다.

ㅁ Receiver는 남은 공간을 어떻게 알릴까?

TCP Header에는 16비트 Window Field가 있다.

Receiver는 ACK를 보낼 때 자신이 추가로 받아들일 수 있는 Byte 범위를 이 값으로 광고한다.

이를 Advertised Receive Window, 보통 rwnd라고 부른다.

ACK=5001, Window=4000

단순화하면 다음 뜻이다.

5000번 Byte까지 연속으로 받았다.
다음에는 5001번을 기다린다.
5001번부터 추가로 4000바이트를 받을 공간이 있다.

Sender가 보낼 수 있는 수신 창의 범위는 다음과 같다.

[5001, 9001)

Byte 5001부터 9000까지
총 4000바이트

Window의 오른쪽 끝은 대략 ACK Number + rwnd로 이해할 수 있다.

Receiver가 Application의 읽기 속도와 Buffer 상태를 바탕으로 Window를 광고하고,

Sender는 그 범위를 넘는 새 Data를 보내지 않는다.

ㅁ Sliding Window는 무엇이 미끄러진다는 뜻일까?

Sender가 ACK를 기다릴 때마다 한 Segment씩 멈춘다면 긴 경로를 효율적으로 사용할 수 없다.

TCP는 Window 안에서 여러 Byte를 연속으로 보낸 뒤 누적 ACK를 받을 수 있다.

처음 허용된 범위가 다음과 같다고 하자.

ACK=5001, rwnd=4000
허용 범위: [5001, 9001)

Sender가 5001부터 7000까지 2000바이트를 이미 보냈지만 아직 ACK를 받지 못했다.

허용 Window  : [5001, 9001)  4000바이트
In-flight    : [5001, 7001)  2000바이트
추가 전송 가능: [7001, 9001)  2000바이트

이후 Receiver가 앞의 2000바이트를 읽고 다음 ACK를 보냈다고 하자.

ACK=7001, rwnd=4000
새 허용 범위: [7001, 11001)

확인된 Byte만큼 Window의 왼쪽과 오른쪽 경계가 앞으로 이동했다.

이전: [5001 -------- 9001)
이후:       [7001 -------- 11001)

이것이 Sliding Window다.

실제 구현은 Sequence Number, ACK, Buffer 상태, 손실 복구를 함께 관리하지만

핵심은 확인되지 않은 Data의 양을 제한하면서 ACK가 전진할 때 새 Byte를 보낼 공간도 함께 앞으로 이동시키는 데 있다.

ㅁ Window는 왜 줄어들기도 할까?

Receiver TCP가 Data를 받는 속도보다 Application이 읽는 속도가 느리다고 하자.

Receive Buffer 전체: 8000바이트

처음 사용 중: 2000바이트 → 남은 공간 6000
추가 수신 후: 5000바이트 → 남은 공간 3000
추가 수신 후: 8000바이트 → 남은 공간 0

Receiver가 보내는 Window도 작아질 수 있다.

Window=6000
Window=3000
Window=0

Flow Control은 Receiver Application을 빠르게 만드는 기술이 아니다.

Receiver가 느릴 때 Sender가 그 사실을 모르고 Receive Buffer를 넘치게 하지 않도록 압력을 Sender 방향으로 되돌려 보내는 Backpressure다.

이 압력은 결국 Sending Application에도 전달될 수 있다.

Send Buffer까지 가득 차면 send()나 write()가 기다리거나,

Non-blocking Socket에서는 지금 당장 쓸 수 없다는 결과를 돌려줄 수 있다.

TCP가 느려진 것이 아니라 전체 처리 사슬이 가장 느린 소비자의 속도에 맞춰진 것이다.

ㅁ Window가 0이면 연결이 끊긴 것일까?

Receiver Buffer에 여유가 없으면 ACK에 Zero Window를 광고할 수 있다.

Receiver → Sender
ACK=9001, Window=0

이는 오류나 연결 종료가 아니다.

지금까지의 Byte는 받았다.
하지만 새 Data를 받을 공간이 현재는 없다.
잠시 멈춰 달라.

Sender는 새 Data 전송을 멈춘다.

이후 Receiver Application이 Buffer를 읽으면 Receiver는 더 큰 Window를 알리는 Window Update를 보낼 수 있다.

Receiver Application read()
→ Buffer 공간 생성
→ Window Update: Window=4096
→ Sender 전송 재개

그런데 Window Update Packet이 돌아오는 길에서 사라지면 어떻게 될까?

Sender   : Window가 여전히 0이라고 생각
Receiver : 공간이 생겼지만 Update가 손실됨

양쪽이 영원히 기다리는 상황을 막기 위해 Sender는 Persist Timer를 사용한다.

Timer가 만료되면 작은 Zero Window Probe를 보내 Receiver가 현재 ACK와 Window 정보를 다시 알리게 한다.

Probe의 구체적인 구성과 간격은 구현에 따라 다를 수 있다.

중요한 역할은 “공간이 생겼다는 안내 하나가 손실되어 연결이 영원히 멈추는 것”을 방지하는 데 있다.

ㅁ Header의 16비트 Window로 충분할까?

TCP Header의 Window Field는 16비트이므로 원래 값만 사용하면 최대 65,535까지 표현할 수 있다.

2^16 - 1 = 65,535바이트

고속이면서 RTT가 긴 경로에서는 이 크기가 너무 작을 수 있다.

예를 들어 100Mbps 경로의 RTT가 40ms라고 하자.

100,000,000 bit/s × 0.040s = 4,000,000 bit
4,000,000 bit ÷ 8 = 500,000 byte

경로를 계속 채우려면 단순 계산으로 약 500,000바이트가 이동 중일 수 있어야 한다.

65,535바이트 Window만으로는 ACK를 기다리는 동안 Link가 비게 될 수 있다.

대역폭과 왕복 시간의 곱을 Bandwidth-Delay Product(BDP)라고 한다.

BDP = Bandwidth × RTT

TCP는 Handshake의 Window Scale Option으로 Header의 Window 값을 왼쪽으로 몇 Bit 이동해 해석할지 협상할 수 있다.

Header Window 값: 32,768
Window Scale     : 4

실제 Window = 32,768 × 2^4
            = 524,288바이트

각 Endpoint는 자신이 보낼 Receive Window 값을 상대가 어떻게 확장해 해석할지 SYN에서 알린다.

Scale은 방향별일 수 있으며 SYN과 SYN-ACK의 Window 값 자체에는 확장 해석을 적용하지 않고

이후 Segment의 Window Field에 사용한다.

Window Scale은 Receive Buffer 공간을 실제로 만들어 주는 기술이 아니다.

큰 Buffer와 긴 경로를 활용할 수 있도록 더 큰 Window를 Header에서 표현하게 해 준다.

ㅁ Receiver가 충분히 빠르면 마음껏 보내도 될까?

이번에는 Receiver Application이 매우 빠르고 rwnd도 충분히 크다고 하자.

하지만 여러 Sender의 Packet이 하나의 느린 Link로 몰린다.

Sender A ─┐
Sender B ─┼─> Router Queue ─> 좁은 Link
Sender C ─┘

들어오는 속도가 나가는 속도보다 빠르면 Router Queue가 쌓인다.

Queue 여유 있음 → 잠시 대기 후 전달
Queue 증가      → 지연 증가
Queue 가득 참   → Packet Drop

Receiver의 rwnd는 이 Router Queue 상태를 나타내지 않는다.

수신 창고가 비어 있다는 사실만 믿고 모두가 최대 속도로 보내면 중간 길이 무너질 수 있다.

네트워크가 감당할 것으로 추정되는 In-flight Data의 양을 Sender가 제한하는 값이 Congestion Window, cwnd다.

ㅁ cwnd는 Packet Header에서 누가 알려줄까?

rwnd는 Receiver가 TCP Header의 Window Field로 광고한다.

반면 cwnd는 일반적으로 Receiver나 Router가 “현재 32KB로 하라”고 직접 보내는 Header Field가 아니다.

Sender의 TCP Stack이 ACK 도착, 손실, RTT, ECN 같은 신호를 관찰해 내부적으로 관리한다.

rwnd
├─ Receiver가 계산
├─ TCP Window Field로 광고
└─ Receiver Buffer 보호

cwnd
├─ Sender가 추정·관리
├─ 일반 TCP Window Field로 직접 전송되지 않음
└─ Network 혼잡 완화

Packet Capture만 보고 현재 cwnd를 정확히 읽을 수 없는 이유가 여기에 있다. Capture에서는 ACK, 손실, 전송 간격을 관찰할 수 있지만 cwnd 자체는 Sender 운영체제의 내부 상태다.

ㅁ 실제로 보낼 수 있는 양은 어느 Window를 따를까?

TCP Sender는 rwnd와 cwnd 중 더 작은 한계를 넘어 새 Data를 In-flight 상태로 만들 수 없다.

단순화한 계산은 다음과 같다.

전송 Window = min(rwnd, cwnd)

추가 전송 가능량
= 전송 Window - 현재 In-flight Data

예를 들어 다음 상태를 보자.

rwnd      = 64KB
cwnd      = 24KB
In-flight = 16KB

계산하면 다음과 같다.

min(64KB, 24KB) - 16KB = 8KB

Receiver에는 64KB 공간이 있지만 Network 한계 추정치가 더 작으므로 새로 8KB 정도만 보낼 수 있다.

반대 상황도 가능하다.

rwnd      = 12KB
cwnd      = 40KB
In-flight = 8KB

min(12KB, 40KB) - 8KB = 4KB

Network는 더 받을 수 있을 것으로 보이지만 Receiver 공간이 작아 4KB만 추가할 수 있다.

실제 전송량에는 Application이 준비한 Data, Send Buffer, MSS, Pacing, 손실 복구 상태 같은 조건도 관여한다. min(rwnd, cwnd)는 두 핵심 Window의 관계를 이해하기 위한 중심 식이다.

ㅁ 처음 만난 길의 수용량은 어떻게 알까?

새 TCP 연결이 시작될 때 Sender는 경로의 정확한 가용 용량을 알지 못한다.

처음부터 매우 많은 Packet을 보내면 좁은 Link의 Queue를 한꺼번에 넘칠 수 있다. 반대로 지나치게 조심하면 빠른 경로를 오랫동안 활용하지 못한다.

TCP의 전통적인 접근은 작은 Initial Congestion Window에서 시작해 ACK가 정상적으로 돌아오는 동안 전송량을 빠르게 늘려 보는 것이다.

이를 Slow Start라고 한다.

이름과 달리 매 RTT마다 cwnd가 대략 두 배로 커질 수 있어 성장 속도는 빠르다.

설명용 예시

시작      : cwnd 10 MSS
약 1 RTT 후: cwnd 20 MSS
약 2 RTT 후: cwnd 40 MSS
약 3 RTT 후: cwnd 80 MSS

ACK 하나가 도착하면 일부 Data가 Network를 빠져나갔다는 단서가 되고,

Sender는 Window를 열어 새 Data를 보낸다. 이 흐름을 ACK Clocking이라고 설명하기도 한다.

초기 cwnd의 정확한 크기와 증가 방식은 TCP 구현과 알고리즘에 따라 달라질 수 있다. 위 숫자는 “ACK가 돌아오면 빠르게 탐색한다”는 원리를 보기 위한 예시다.

ㅁ 빠르게 늘리기만 하면 결국 다시 넘치지 않을까?

맞는 이야기다.

Slow Start의 지수적 성장을 계속하면 언젠가 병목을 만날 가능성이 크다.

TCP는 Slow Start Threshold, ssthresh를 기준으로 더 조심스럽게 늘리는 Congestion Avoidance 단계로 전환할 수 있다.

전통적인 Reno 계열의 원리를 단순화하면 다음과 같다.

Slow Start
→ ACK가 돌아오는 동안 빠르게 증가

Congestion Avoidance
→ 대략 RTT당 1 MSS 수준으로 완만하게 증가

Congestion 신호
→ cwnd를 줄이고 다시 탐색

이를 흔히 Additive Increase, Multiplicative Decrease(AIMD)라는 방향으로 설명한다.

손실 신호의 강도도 같지 않다.

Duplicate ACK와 Fast Retransmit는 뒤의 Packet이 계속 도착한다는 단서가 있다.
RTO는 한동안 ACK 진전이 없었다는 더 강한 신호다.

전통적인 알고리즘은 두 상황에서 cwnd를 다르게 줄일 수 있다.

다만 모든 현대 TCP가 Reno의 숫자를 그대로 쓰는 것은 아니다.

CUBIC처럼 Window 성장 곡선을 다르게 설계한 알고리즘도 있고,

BBR처럼 전달률과 RTT 모델을 중심으로 경로를 추정하는 접근도 있다.

공통된 목적은 하나다.

경로가 감당할 수 있는 양을 알 수 없으므로 관찰하면서 탐색하고, 혼잡 신호가 보이면 물러난다.

ㅁ Packet Drop만 혼잡 신호일까?

전통적인 Loss-based Congestion Control은 Packet Drop을 중요한 혼잡 신호로 사용한다.

하지만 Queue가 가득 찰 때까지 기다려 Packet을 버리는 것만이 방법은 아니다.

Router가 혼잡해지기 시작할 때 Packet을 버리지 않고 IP Header에 혼잡 표시를 하고,

Receiver가 이를 TCP ACK로 되돌려 줄 수 있다. 이를 Explicit Congestion Notification(ECN)이라고 한다.

Router: 혼잡 조짐을 ECN으로 Mark
Receiver: 혼잡 표시를 ACK로 전달
Sender: cwnd와 전송 동작 조정

ECN은 양 Endpoint와 경로 장비가 관련 기능을 지원하고 협상해야 사용할 수 있다.

또한 일부 Congestion Control은 RTT 증가를 Queue가 쌓이는 단서로 활용한다.

어떤 신호를 얼마나 반영하는지는 알고리즘마다 다르다.

ㅁ Queue가 크면 Packet을 버리지 않아 더 좋을까?

큰 Queue는 순간적인 Burst를 흡수할 수 있다.

하지만 지나치게 큰 Queue가 계속 가득 차면 Packet Loss는 줄어 보여도 대기 시간이 매우 길어진다.

전송 시간 자체는 짧음
+ Router Queue 대기 수백 ms 또는 수초
= 사용자가 느끼는 큰 지연

이를 Bufferbloat라고 한다.

대용량 다운로드 중 작은 SSH 입력이나 음성 통화가 갑자기 느려지는 현상으로 나타날 수 있다.

좋은 네트워크는 Packet을 하나도 버리지 않는 네트워크만을 뜻하지 않는다.

처리량, 지연, 공정성 사이의 균형이 필요하다.

Active Queue Management와 ECN은 Queue가 완전히 가득 차기 전에 혼잡 신호를 주어 긴 지연을 줄이는 데 활용될 수 있다.

ㅁ 혼잡 제어는 왜 인터넷 전체의 약속일까?

여러 Sender가 하나의 병목 Link를 함께 쓴다고 하자.

병목 용량: 100Mbps

Sender A가 100Mbps를 계속 차지
Sender B도 100Mbps를 계속 시도
Sender C도 100Mbps를 계속 시도

각자가 손실 때마다 더 빠르게 재전송하면 Queue와 Drop이 늘고 유효하게 도착하는 Data는 오히려 줄 수 있다.

Congestion Control은 자신의 연결 하나만 빠르게 만드는 기능이 아니다.

혼잡 신호에 반응해 여러 Flow가 공유 자원을 지속해서 사용할 수 있게 하는 협력 규칙이다.

그렇다고 모든 Flow가 언제나 정확히 같은 대역폭을 얻는다는 뜻은 아니다.

RTT, Congestion Control 알고리즘, 연결 수, 병목 구조, Application 동작이 다르면 분배도 달라진다.

핵심은 네트워크의 상태와 무관하게 무제한 전송하는 것을 피한다는 데 있다.

ㅁ Flow Control과 Congestion Control을 다시 구분하면

구분	Flow Control	Congestion Control
보호 대상	Receiver의 Receive Buffer	Network의 Link와 Router Queue
핵심 값	rwnd	cwnd
누가 관리하나	Receiver가 계산해 Sender에 광고	Sender TCP가 신호를 보고 추정
어디에서 보이나	TCP Header의 Window Field	보통 Sender Kernel 내부 상태
주요 신호	Application 읽기와 Buffer 여유	ACK, Loss, RTO, ECN, RTT 등
한계가 작아지면	새 Data를 덜 보내거나 Zero Window에서 정지	In-flight Data를 줄이고 천천히 재탐색
해결하지 않는 문제	중간 Network의 혼잡	느린 Receiver Buffer 보호 자체

둘은 독립적인 질문에 답한다.

rwnd: 받는 쪽에 놓을 자리가 있는가?
cwnd: 가는 길에 이만큼 올려도 되는가?

Sender는 둘 중 하나만 선택하지 않는다. 더 엄격한 한계를 동시에 따른다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Packet과 운영체제 상태로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
수신 창고	Receive Buffer	도착했지만 Application이 아직 읽지 않은 Byte를 보관
창고의 남은 공간 안내	Advertised Window, rwnd	Receiver가 추가로 받을 수 있다고 광고한 Byte 범위
처리될수록 앞으로 움직이는 접수 범위	Sliding Window	ACK 진전에 따라 허용되는 Sequence 범위가 이동
창고가 가득 차 접수 중지	Zero Window	현재 새 Data를 받을 공간이 없음을 광고
접수 재개 여부를 다시 묻는 확인	Persist Timer / Probe	Window Update 손실로 영구 정지하는 상황 방지
먼 길에 맞는 큰 접수표	Window Scale	16비트 Window Field를 더 큰 값으로 해석
도로에 올려도 될 우편물의 추정량	Congestion Window, cwnd	Sender가 허용하는 Network 내 미확인 Data 한도
처음 길을 빠르게 탐색	Slow Start	ACK가 돌아오면 cwnd를 빠르게 증가
혼잡 근처에서 조심스럽게 탐색	Congestion Avoidance	가용 용량을 더 완만하게 탐색
도로가 막혔다는 표시	Loss / ECN / RTT 증가	Congestion Control이 반응할 수 있는 Network 신호
큰 대기 창고 때문에 늦어지는 배송	Bufferbloat	과도한 Queue 체류가 큰 지연을 생성

전체 전송 결정은 다음 그림으로 모을 수 있다.

Receiving Application 읽기 속도
              ↓
       Receive Buffer 여유
              ↓
        rwnd를 ACK로 광고 ───┐
                           │
Network의 ACK·Loss·ECN·RTT  │
              ↓            │
       Sender가 cwnd 계산 ───┤
                           ▼
                    min(rwnd, cwnd)
                           ↓
                 현재 In-flight를 제외
                           ↓
                   새로 보낼 수 있는 양

ㅁ Packet Capture에서는 무엇을 볼 수 있을까?

Wireshark에서 다음 Field를 확인한다.

tcp.ack
tcp.window_size_value
tcp.window_size_scalefactor
tcp.window_size

tcp.window_size_value는 Header에 기록된 원래 16비트 값이다.
tcp.window_size_scalefactor는 협상된 Scale 해석에 관련된 값이다.
tcp.window_size는 Wireshark가 Scale을 반영해 계산한 Window 크기다.

Window 관련 상황은 다음 Display Filter로 좁혀 볼 수 있다.

tcp.analysis.zero_window ||
tcp.analysis.window_full ||
tcp.analysis.window_update

tcp.analysis.*는 TCP Header의 독립 Flag가 아니라 Wireshark가 Capture를 분석해 붙인 결과다.

중요한 제한도 있다.

Packet Capture에서 직접 관찰 가능: Receiver가 광고한 rwnd
Packet Capture에서 직접 읽기 어려움: Sender 내부의 cwnd

cwnd는 Sender Host에서 운영체제 상태를 함께 봐야 한다.

ㅁ Linux에서 연결 상태를 관찰해 보기

Linux에서는 전송 중인 TCP 연결을 다음처럼 관찰할 수 있다.

ss -tin

환경과 Kernel 버전에 따라 다음과 같은 정보가 보일 수 있다.

rtt
cwnd
ssthresh
unacked
bytes_acked
bytes_received
rcv_space
rwnd_limited

cwnd는 보통 MSS 단위로 표시될 수 있으며,

rcv_space 같은 진단 값이 곧 Capture 시점의 Advertised Window와 완전히 같은 의미라고 단정하면 안 된다.

각 값의 단위와 의미는 사용 중인 ss와 Kernel 문서를 함께 확인한다.

전송이 매우 짧으면 상태가 빠르게 사라진다.

큰 Data를 전송하는 동안 다음처럼 반복 관찰하면 변화가 더 잘 보인다.

watch -n 0.2 'ss -tin'

macOS에서는 netstat, lsof, Packet Capture 등으로 Socket과 Window를 관찰할 수 있지만 Linux ss와 출력 항목이 같지는 않다.

ㅁ 느린 Receiver로 Flow Control을 관찰해 보기

다음 실습은 개인 Computer의 Loopback에서만 실행한다. 특정 외부 저장소나 공용 Server를 사용하지 않는다.

Receiver는 한 번에 1KB만 읽고 잠시 쉰다.

slow_receiver.py:

import socket
import time

with socket.socket() as server:
    server.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4096)
    server.bind(("127.0.0.1", 8080))
    server.listen(1)
    conn, address = server.accept()

    total = 0
    with conn:
        while True:
            data = conn.recv(1024)
            if not data:
                break
            total += len(data)
            time.sleep(0.01)

    print(f"received={total}")

Sender는 큰 Byte Stream을 가능한 만큼 Socket에 쓴다.

fast_sender.py:

import socket
import time

payload = b"x" * (1024 * 1024)

with socket.create_connection(("127.0.0.1", 8080)) as sock:
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 8192)
    started = time.monotonic()
    sock.sendall(payload)
    sock.shutdown(socket.SHUT_WR)
    elapsed = time.monotonic() - started

print(f"sendall elapsed={elapsed:.3f}s")

Receiver를 먼저 실행하고 Sender를 시작한다.

python3 slow_receiver.py

python3 fast_sender.py

동시에 Packet을 관찰한다. Interface 이름은 Linux에서 보통 lo, macOS에서 보통 lo0다.

sudo tcpdump -n -i lo -s 0 -w tcp-flow-control.pcap \
  'tcp port 8080'

Wireshark에서 다음 질문을 확인한다.

Receiver가 광고하는 계산된 Window는 시간에 따라 어떻게 변하는가?
Sending Application의 sendall()이 즉시 끝나지 않는 이유는 무엇인가?
Zero Window 또는 Window Update가 관찰되는가?
ACK는 전진하는데 전송 속도는 왜 Receiver의 읽기 속도에 가까워지는가?

운영체제의 Buffer Auto-tuning, Loopback 최적화, Socket Buffer 계산 방식에 따라 Zero Window가 나타나지 않을 수도 있다. SO_RCVBUF=4096이 Capture에서 정확히 4096바이트 Window를 뜻하는 것도 아니다.

따라서 이 실습의 목표는 특정 숫자를 강제로 재현하는 것이 아니라

느린 소비가 Send Buffer와 Advertised Window를 거쳐 Sender에 Backpressure로 전달되는 흐름을 관찰하는 것이다.

ㅁ 핵심 정리

TCP Flow Control은 Receiver의 Receive Buffer를 보호하고 Congestion Control은 Network의 Link와 Router Queue를 보호한다.
Receiver는 ACK의 Window Field로 추가 수신 가능한 rwnd를 광고한다.
Sliding Window는 ACK가 전진할 때 확인된 범위만큼 새 Data를 보낼 Sequence 범위를 앞으로 이동시킨다.
Receiver 공간이 없으면 Zero Window를 광고하고, Persist Timer와 Probe는 Window Update 손실로 영구 정지하는 것을 막는다.
Window Scale은 16비트 Window Field보다 큰 Receive Window를 표현하게 한다.
BDP가 큰 경로를 채우려면 충분한 Window와 Buffer가 필요하다.
cwnd는 Sender가 ACK, 손실, RTO, ECN, RTT 같은 신호를 바탕으로 관리하는 내부 Congestion Control 상태다.
새 Data의 핵심 전송 한도는 min(rwnd, cwnd)이며 이미 In-flight인 Byte를 제외해야 한다.
Slow Start는 모르는 경로의 용량을 빠르게 탐색하고 Congestion Avoidance는 혼잡 근처에서 더 조심스럽게 탐색한다.
실제 TCP 알고리즘은 Reno, CUBIC, BBR 등에서 증가와 감소 방식이 다를 수 있다.
큰 Queue는 Loss를 늦출 수 있지만 긴 지연을 만드는 Bufferbloat를 일으킬 수 있다.
Packet Capture에서는 rwnd를 볼 수 있지만 cwnd는 일반적으로 Sender 운영체제의 내부 상태를 함께 확인해야 한다.

핵심 용어: Send Buffer, Receive Buffer, Flow Control, Advertised Window, Receive Window, rwnd, Sliding Window, Zero Window, Window Update, Persist Timer, Window Scale, Bandwidth-Delay Product, Congestion Control, Congestion Window, cwnd, In-flight Data, Slow Start, ssthresh, Congestion Avoidance, ACK Clocking, AIMD, ECN, Bufferbloat

TCP가 보내는 양은 하나의 속도계로 결정되지 않는다.
받는 쪽의 빈자리인 rwnd와 길이 감당할 것으로 추정한 양인 cwnd 중 더 작은 한계를 따라야 대화와 길이 함께 살아남는다.

ㅁ 다음 이야기

TCP는 Receiver와 Network가 감당할 수 있는 전송량을 조절한다.

하지만 전송량을 적절히 줄였어도 Packet 하나의 크기가 다음 Link가 운반할 수 있는 한계보다 크면 그대로 지나갈 수 없다.

큰 소포는 누가, 어디에서 나누어야 할까? 그리고 일부 조각만 사라지면 원래 Packet 전체에는 어떤 일이 생길까?

다음 글에서는

「작은 편지는 가는데 큰 소포만 멈추는 이유는 무엇일까?」라는 질문을 통해

MTU, IP Fragmentation, DF Flag, Fragment Offset과 재조립 비용을 살펴본다.

[Network] 17. 편지가 사라졌다는 사실은 어떻게 알아챌까?

기록하는 백엔드개발자 — Mon, 20 Jul 2026 20:17:10 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 5. 믿을 수 없는 길 위에서 믿을 수 있게 보내기

ㅁ 들어가며

TCP 연결이 만들어졌다고 해서 길이 안전해지는 것은 아니다.

IP는 여전히 Best-Effort 방식으로 Packet을 전달한다.

중간 Router의 Queue가 가득 차거나, 전송 중 Bit가 손상되거나, 경로가 순간적으로 바뀌면 TCP Segment가 사라질 수 있다.

그런데 네트워크에는 분실 신고서가 항상 도착하는 것도 아니다.

Sender가 알 수 있는 것
├─ 어떤 Byte를 보냈는가
├─ Receiver가 다음에 어떤 Byte를 기다리는가
└─ 응답이 언제, 어떤 순서로 돌아왔는가

Sender가 직접 볼 수 없는 것
├─ 어느 Router에서 Segment가 버려졌는가
├─ Data Segment가 사라졌는가
└─ ACK가 돌아오는 길에서 사라졌는가

TCP는 “이 Segment가 몇 번째 Router에서 분실됐다”는 확정 통보를 기다리지 않는다.

대신 Sequence Number, Acknowledgment Number, Timer를 단서로 손실을 추론하고 필요한 Byte를 다시 보낸다.

이번 글에서는 실제 Byte 번호를 따라가며

Cumulative ACK, Retransmission Timeout(RTO),

Duplicate ACK, Fast Retransmit, Selective Acknowledgment(SACK)가

어떻게 서로 다른 방식으로 손실을 발견하고 복구하는지 살펴본다.

ㅁ TCP는 편지 봉투가 아니라 바이트 장부를 본다

Application이 TCP Socket에 3,000바이트를 썼다고 하자.

TCP는 이를 여러 Segment로 나누어 보낼 수 있다.

여기서는 설명을 위해 1,000바이트씩 나뉘었다고 가정한다.

Handshake에서 SYN이 Sequence Number 하나를 소비했고, 첫 Data Byte의 번호가 1001이라고 하자.

Segment A: Seq=1001, Length=1000  → Byte [1001, 2001)
Segment B: Seq=2001, Length=1000  → Byte [2001, 3001)
Segment C: Seq=3001, Length=1000  → Byte [3001, 4001)

[1001, 2001)은 1001부터 2000까지, 모두 1,000바이트라는 뜻이다.

TCP의 Sequence Number는 Segment의 순번이 아니라 Byte Stream에서 첫 Data Byte가 놓인 위치를 가리킨다.

Seq=2001, Length=1000

의미:
이 Segment에는 2001번부터 3000번까지의 Byte가 들어 있다.

따라서 Segment 크기가 달라져도 Receiver는 각 Byte가 Stream의 어디에 들어갈지 알 수 있다.

우편 비유에서 TCP는 소포에 1번, 2번, 3번을 붙이는 것보다.

각 소포 겉면에 “문서 1001쪽부터 2000쪽까지”라고 적어 보내는 방식에 가깝다.

ㅁ ACK 번호는 무엇을 확인할까?

Receiver가 Segment A를 정상적으로 받았다.

Receiver가 보내는 ACK는 다음과 같다.

ACK=2001

이 번호는 “2001번 Byte를 받았다”는 뜻이 아니다.

ACK=2001

의미:
2000번까지 연속해서 받았고
다음에는 2001번 Byte를 기다린다.

Acknowledgment Number는 다음에 기대하는 Byte 번호다.

Segment B까지 연속으로 받으면 ACK는 3001이 된다.

Segment A 수신 → ACK=2001
Segment B 수신 → ACK=3001
Segment C 수신 → ACK=4001

TCP ACK는 일반적으로 지금까지 끊김 없이 받은 범위를 한 번에 확인한다.

이를 Cumulative Acknowledgment, 누적 확인 응답이라고 한다.

ㅁ ACK 하나가 Segment 하나의 영수증은 아니다

ACK=4001이 도착했다면 Sender는 다음 사실을 알 수 있다.

Byte 1001부터 4000까지 연속 수신 완료
Receiver가 다음에 기다리는 Byte는 4001

중간의 ACK=2001과 ACK=3001이 돌아오는 길에서 사라졌더라도 마지막 ACK=4001이 도착하면 앞선 범위까지 함께 확인된다.

Sender                                      Receiver
  Seq=1001, Len=1000 ---------------------->
                            <---- ACK=2001  (손실)
  Seq=2001, Len=1000 ---------------------->
                            <---- ACK=3001  (손실)
  Seq=3001, Len=1000 ---------------------->
                            <---- ACK=4001

Sender는 ACK=4001을 보고 세 Segment의 Byte가 모두 도착했음을 안다.

따라서 ACK 하나가 보이지 않는다고 곧바로 Data를 재전송하지 않는다.

뒤의 누적 ACK가 더 넓은 범위를 확인할 수 있기 때문이다.

이 방식은 모든 Segment에 독립적인 영수증을 붙이는 비용을 줄인다.

ㅁ 가운데 편지만 사라지면 ACK는 어디에서 멈출까?

이번에는 Segment B가 중간에서 사라졌다고 하자.

Segment A: Byte [1001, 2001)  → 도착
Segment B: Byte [2001, 3001)  → 손실
Segment C: Byte [3001, 4001)  → 도착

Receiver는 A를 받고 ACK=2001을 보낸다.

그 뒤 C가 도착했지만 2001부터 시작하는 B가 비어 있다.

받은 범위: [1001, 2001), [3001, 4001)
빈 범위  : [2001, 3001)
다음 기대: 2001

따라서 Receiver는 ACK 번호를 4001로 올릴 수 없다.

Sender                                      Receiver
  Seq=1001, Len=1000 ---------------------->
                            <---- ACK=2001
  Seq=2001, Len=1000 --------X  손실
  Seq=3001, Len=1000 ---------------------->
                            <---- ACK=2001

두 번째 ACK=2001은 “A를 또 받았다”는 뜻이 아니다.

뒤의 Data가 도착했지만 여전히 2001번 Byte부터 기다리고 있다는 뜻이다.

같은 Acknowledgment Number가 반복되므로 이를 Duplicate ACK, 중복 ACK라고 부른다.

ㅁ 중복 ACK는 왜 손실의 단서가 될까?

Sender가 Segment를 더 보냈다고 하자.

Segment C: Seq=3001
Segment D: Seq=4001
Segment E: Seq=5001

B가 빠진 상태에서 C, D, E가 차례로 도착할 때마다 Receiver는 여전히 ACK=2001을 보낸다.

최초 ACK       : ACK=2001
C 도착 후      : ACK=2001  → Duplicate ACK 1
D 도착 후      : ACK=2001  → Duplicate ACK 2
E 도착 후      : ACK=2001  → Duplicate ACK 3

여기서 “3개의 중복 ACK”는 최초 ACK를 제외하고 같은 ACK가 세 번 더 도착했다는 뜻이다.

Sender 입장에서 이 패턴은 중요한 단서다.

뒤의 Segment들은 Receiver까지 계속 도착하고 있다.
그런데 ACK가 2001에서 전진하지 않는다.
그러면 2001부터 시작하는 구간에 빈틈이 있을 가능성이 높다.

전통적인 TCP 동작에서는 보통 3개의 Duplicate ACK를 받으면

RTO가 만료되기 전에 빠진 Segment를 재전송한다.

이를 Fast Retransmit라고 한다.

Sender                                      Receiver
  Seq=2001, Len=1000 재전송 ---------------->
                            <---- ACK=6001

Receiver가 C, D, E를 Out-of-Order Buffer에 보관하고 있었다면 B가 채워지는 순간 Byte 6000까지 연속 범위가 완성된다.

ACK는 누적되어 6001로 한 번에 전진할 수 있다.

ㅁ 중복 ACK가 곧 손실의 확정 증거일까?

반드시 그렇지는 않다.

네트워크에서 Packet 순서가 바뀔 수도 있다.

보낸 순서: A → B → C
도착 순서: A → C → B

C가 먼저 도착하면 Receiver는 B를 기다리며 Duplicate ACK를 보낸다.

조금 뒤 B가 도착하면 빈틈이 채워지고 ACK가 전진한다.

즉, 소수의 Duplicate ACK는 다음과 같은 이유로도 생길 수 있다.

경로 변화에 따른 Packet Reordering
Segment 복제
Receiver의 ACK 생성 방식

TCP가 첫 번째 Duplicate ACK만 보고 즉시 재전송하면 단순한 순서 변경에도 불필요한 복사본을 보낼 수 있다.

여러 Duplicate ACK를 기다리는 기준은 빠른 복구와 불필요한 재전송 사이의 절충이다.

실제 운영체제의 최신 TCP 구현은 SACK, Reordering 관찰, 시간 기반 손실 탐지 등 추가 정보를 함께 사용할 수 있다. “항상 정확히 세 번만 세는 단순한 기계”로 이해하면 안 된다.

ㅁ 뒤따르는 편지가 없다면 무엇을 기다려야 할까?

Fast Retransmit에는 빠진 Segment 뒤로 도착하는 Data가 필요하다.

마지막 Segment 하나만 보냈는데 그것이 사라졌다고 하자.

Sender → Receiver : Seq=2001, Len=1000  X

뒤따르는 Data 없음
Duplicate ACK도 없음

Receiver는 받지 못한 Segment에 대해 ACK를 만들 수 없다. Sender에게는 아무 응답도 오지 않는다.

이때 필요한 두 번째 단서가 시간이다.

Sender는 확인되지 않은 가장 오래된 Data에 Retransmission Timer를 둔다. 일정 시간이 지나도록 ACK가 전진하지 않으면 해당 Data를 다시 보낸다.

이 만료 시간을 Retransmission Timeout(RTO)이라고 한다.

Data 전송
   ↓
ACK 기다림
   ↓
RTO 만료
   ↓
확인되지 않은 Data 재전송

RTO 기반 재전송은 뒤따르는 Data가 없어 Duplicate ACK를 만들 수 없는 상황에서도 동작한다.

ㅁ Timeout은 왜 고정된 숫자일 수 없을까?

서울 안의 짧은 경로와 대륙을 건너는 경로의 왕복 시간은 다르다.

RTO를 항상 너무 짧게 잡으면 ACK가 정상적으로 오고 있는데도 재전송한다.

실제 RTT 200ms
고정 RTO 100ms

100ms: Timeout, 불필요한 재전송
200ms: 원래 ACK 도착

반대로 RTO가 지나치게 길면 실제 손실을 복구하기까지 오래 기다린다.

TCP는 보낸 시점과 ACK가 돌아온 시점의 차이로 Round-Trip Time(RTT) Sample을 얻고, 경로의 평균적인 지연과 변동 폭을 추정한다.

대표적인 개념은 다음과 같다.

SRTT   : 평활화한 RTT 추정값
RTTVAR : RTT 변동 폭의 추정값
RTO    : SRTT와 RTTVAR를 바탕으로 정한 재전송 대기 시간

정확한 하한과 Timer 정밀도는 운영체제 구현에 따라 달라질 수 있다. 중요한 원리는 RTO가 단순한 고정 상수가 아니라 관찰한 왕복 지연과 그 흔들림을 반영한다는 점이다.

ㅁ 재전송했는데도 ACK가 오지 않으면 어떻게 할까?

혼잡한 길에서 같은 간격으로 계속 재전송하면 이미 막힌 Queue를 더 채울 수 있다.

RTO가 반복해서 만료될 때 TCP는 일반적으로 대기 시간을 늘린다.

첫 번째 Timeout  → 재전송, 다음 대기 증가
두 번째 Timeout  → 재전송, 다음 대기 더 증가
세 번째 Timeout  → 재전송, 다음 대기 더 증가

이를 Exponential Backoff라고 한다.

길이 혼잡할 가능성이 큰 상황에서 무작정 같은 속도로 재촉하지 않고 한 걸음 물러나는 것이다.

Timeout은 단순한 분실 복구 신호에 그치지 않는다. TCP는 이를 네트워크가 전송량을 감당하지 못한다는 강한 혼잡 신호로도 다룬다.

전송 속도를 어떻게 줄이는지는 다음 글의 Congestion Control에서 이어서 살펴본다.

ㅁ 재전송한 Segment의 RTT는 왜 계산하기 어려울까?

같은 Byte 범위를 두 번 보냈다고 하자.

t0: 원본 Segment 전송
t1: RTO 만료, 같은 범위 재전송
t2: ACK 도착

t2에 도착한 ACK가 원본에 대한 늦은 응답인지, 재전송본에 대한 빠른 응답인지 ACK 번호만으로는 구분하기 어렵다.

이를 Retransmission Ambiguity, 재전송 모호성이라고 한다.

모호한 Sample로 RTT를 계산하면 RTO 추정이 흔들릴 수 있다. 전통적으로 TCP는 재전송된 Segment의 모호한 RTT Sample을 피하는 Karn's Algorithm과 Timeout 시 Backoff를 사용해 이 문제를 완화한다.

TCP Timestamp Option이 협상된 연결에서는 Timestamp 정보가 RTT 측정에 추가 단서를 제공할 수 있다.

ㅁ SACK은 누적 ACK의 빈틈을 어떻게 보완할까?

누적 ACK만 보면 Receiver가 ACK 번호 뒤의 어떤 구간을 이미 보관하고 있는지 자세히 알 수 없다.

다음 상태를 보자.

연속 수신: [1001, 2001)
손실 구간: [2001, 3001)
추가 수신: [3001, 5001)

Cumulative ACK: 2001

ACK=2001은 연속 범위의 끝을 정확히 알려 주지만, [3001, 5001)도 도착했다는 사실은 표현하지 못한다.

Handshake에서 양쪽이 SACK Permitted Option으로 지원 여부를 알렸다면

Receiver는 ACK의 SACK Option에 불연속적으로 받은 Byte Block을 표시할 수 있다.

ACK=2001
SACK Block=[3001, 5001)

의미는 다음과 같다.

다음에 기다리는 연속 Byte는 2001이다.
하지만 3001부터 5000까지는 이미 따로 보관하고 있다.

SACK은 Cumulative ACK를 대체하지 않는다.

ACK Number는 연속해서 받은 범위의 끝을 나타낸다.
SACK Block은 그 뒤에 따로 도착한 범위를 추가로 알려 준다.

여러 구간이 손실되었을 때 Sender는 SACK 정보를 이용해 이미 도착한 범위를 피하고 실제 빈 구간을 더 효율적으로 재전송할 수 있다.

ㅁ Receiver는 순서가 바뀐 Data를 Application에 바로 줄까?

TCP가 Application에 약속한 것은 순서 있는 Byte Stream이다.

B가 빠지고 C가 먼저 도착했을 때 Receiver TCP는 C를 Buffer에 보관할 수 있지만, 일반적으로 B보다 앞서 C의 Byte를 Application Stream으로 넘기지 않는다.

네트워크 도착: A → C → B
TCP 재조립   : A → B → C
Application  : A → B → C

빈 구간이 채워질 때까지 뒤의 Data 전달이 기다리는 현상은 TCP의 Head-of-Line Blocking이다.

재전송은 단순히 사라진 봉투를 한 번 더 보내는 기능이 아니다. Receiver가 순서 있는 Stream을 다시 완성할 수 있도록 Byte의 빈칸을 채우는 과정이다.

ㅁ 같은 Byte가 두 번 도착하면 Application도 두 번 받을까?

원본 Segment가 늦게 도착한 상태에서 재전송본까지 도착할 수 있다.

원본 Seq=2001   → 늦게 도착
재전송 Seq=2001 → 함께 도착

TCP는 Sequence Number를 이용해 이미 받은 Byte 범위를 식별하고 중복 Data를 제거한다.

정상적인 TCP Byte Stream에서는 같은 Byte를 Application에 두 번 전달하지 않는다.

하지만 여기서 범위를 정확히 구분해야 한다.

TCP가 제공하는 것
└─ 연결 안에서 순서 있는 Byte Stream과 중복 Byte 억제

TCP가 보장하지 않는 것
├─ 상대 Application이 업무 처리를 끝냈는가
├─ Database Transaction이 한 번만 Commit되었는가
└─ 연결이 끊긴 뒤 재요청까지 포함한 Exactly-Once 처리

TCP ACK는 Receiver의 TCP Stack이 해당 Byte를 받았다는 뜻이지, 주문이나 결제가 한 번만 처리되었다는 뜻은 아니다.

Application 수준의 재시도와 중복 방지는 별도의 요청 ID나 Idempotency 설계가 필요하다.

ㅁ ACK가 늦는 것과 손실된 것은 어떻게 구분할까?

Sender가 기다리는 동안에는 확실히 구분할 수 없다.

Data가 손실됐을 수도 있고, ACK가 손실됐을 수도 있으며, 단지 Queue에서 오래 기다리는 중일 수도 있다.

Receiver는 ACK Traffic을 줄이기 위해 상황에 따라 짧게 기다렸다가 여러 Segment를 누적 확인하는 Delayed ACK를 사용할 수도 있다.

따라서 다음 식은 성립하지 않는다.

ACK가 즉시 안 보임 = Data 손실 확정  (X)

TCP는 관찰 가능한 신호를 조합한다.

같은 ACK가 반복됨
→ 뒤의 Data는 도착했지만 앞에 빈칸이 있을 가능성

RTO 동안 ACK가 전진하지 않음
→ 확인되지 않은 Data 또는 그 ACK가 손실·지연됐을 가능성

SACK Block이 보임
→ 누적 ACK 뒤에 실제로 도착한 불연속 범위 확인

손실 복구는 네트워크 내부를 모두 보고 내리는 판결이 아니라 End Host가 제한된 단서로 내리는 합리적인 추론이다.

ㅁ Checksum 오류도 Sender에게는 손실처럼 보일까?

TCP Segment가 전송 중 손상되어 Checksum 검증에 실패하면 Receiver는 해당 Segment를 정상 Data로 받아들이지 않는다.

Sender에게 “Checksum 오류가 났다”는 TCP ACK가 반드시 돌아오는 것은 아니다.

그 결과 Sender 관점에서는 다음 상황이 비슷하게 보일 수 있다.

Router Queue에서 Drop
Link에서 손상되어 폐기
Data는 도착했지만 ACK가 Drop

모두 ACK의 정체나 Timeout으로 나타날 수 있다.

TCP의 End-to-End 복구가 특정 Link의 오류 원인을 직접 고치는 것은 아니다. 원인을 알 수 없어도 Stream의 빈 Byte 범위를 다시 보내 대화를 이어가게 한다.

ㅁ 손실 복구는 혼자 동작하지 않는다

Sender가 확인되지 않은 Data를 무제한으로 쏟아낼 수 있다면 Duplicate ACK와 재전송만으로는 길을 안정시킬 수 없다.

TCP가 실제로 보낼 수 있는 양에는 두 종류의 창이 관여한다.

Receiver가 받을 수 있는 양 → Receive Window, rwnd
Network가 감당할 것으로 추정한 양 → Congestion Window, cwnd

손실은 재전송할 Byte를 알려 주는 동시에 Congestion Control이 전송량을 줄이는 신호가 될 수 있다.

이번 글에서는 “무엇을 다시 보낼 것인가”에 집중했다. “한 번에 얼마나 보내도 되는가”는 다음 글에서 다룬다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유는 흐름을 이해하는 출발점일 뿐이다. 실제 Packet에서 확인할 용어로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
문서의 쪽 번호	Sequence Number	Segment에 담긴 첫 Data Byte의 Stream 위치
다음에는 2001쪽을 보내 달라는 회신	ACK=2001	2000번까지 연속 수신했고 2001번을 기대함
지금까지 받은 쪽을 한 번에 확인	Cumulative ACK	연속 수신한 전체 Byte 범위를 누적 확인
같은 빈 쪽 번호를 반복해서 요청	Duplicate ACK	뒤 Data가 왔지만 다음 기대 Byte가 바뀌지 않음
세 차례 반복 요청 후 바로 재발송	Fast Retransmit	RTO 전에 손실 가능성이 큰 Segment를 재전송
영수증을 기다리는 제한 시간	RTO	ACK 진전이 없을 때 재전송을 시작하는 Timeout
재촉할수록 기다리는 간격을 늘림	Exponential Backoff	반복 Timeout 때 재전송 대기 시간을 증가
따로 도착해 보관 중인 쪽 목록	SACK Block	누적 ACK 뒤에서 수신한 불연속 Byte 범위
순서가 맞을 때까지 보관하는 선반	Out-of-Order Buffer	빈 구간 뒤에 도착한 Data를 재조립용으로 보관
빠진 쪽 때문에 뒤 문서를 못 읽음	Head-of-Line Blocking	앞 Byte가 복구될 때까지 뒤 Byte 전달이 지연

핵심 흐름을 한 장면으로 모으면 다음과 같다.

Sender                                             Receiver
Seq=1001, Len=1000 ------------------------------->
                                      <----- ACK=2001

Seq=2001, Len=1000 -----------X  손실
Seq=3001, Len=1000 -------------------------------> 보관
                                      <----- ACK=2001, SACK=[3001,4001)
Seq=4001, Len=1000 -------------------------------> 보관
                                      <----- ACK=2001, SACK=[3001,5001)
Seq=5001, Len=1000 -------------------------------> 보관
                                      <----- ACK=2001, SACK=[3001,6001)

같은 ACK가 세 번 추가로 도착
→ Fast Retransmit

Seq=2001, Len=1000 재전송 ------------------------>
                                      <----- ACK=6001

ㅁ Packet Capture에서 직접 확인해 보기

실제 연결에서는 Capture 도구가 Sequence Number를 읽기 쉬운 상대 번호로 표시할 수 있다.

Wireshark의 기본 설정에서 첫 Data Byte가 Seq=1처럼 보이더라도

실제 Header의 ISN이 0이나 1이라는 뜻은 아닐 수 있다.

필요하면 TCP Protocol 설정의 Relative Sequence Number 표시 여부를 확인한다.

Capture에서 다음 필드를 함께 본다.

tcp.seq       : Segment의 첫 Byte 위치
tcp.len       : TCP Payload 길이
tcp.ack       : 다음에 기대하는 Byte 위치
tcp.options.sack : 선택 확인된 Byte Block

Wireshark가 분석한 재전송 후보는 다음 Display Filter로 좁혀 볼 수 있다.

tcp.analysis.retransmission ||
tcp.analysis.fast_retransmission ||
tcp.analysis.duplicate_ack ||
tcp.options.sack

tcp.analysis.*는 Packet Header에 적힌 Flag가 아니라 Wireshark가 Capture 순서와 시간을 바탕으로 계산한 분석 결과다.

Capture 시작 시점이 늦거나 Packet이 누락되면 판단도 달라질 수 있다.

Command Line에서는 다음처럼 TCP Packet을 저장할 수 있다.

Interface 이름은 Linux에서 보통 lo, macOS에서 보통 lo0이며 실제 환경에 맞게 바꾼다.

sudo tcpdump -n -i lo -s 0 -w tcp-loss.pcap 'tcp port 8080'

정상적인 Loopback 통신은 손실이 거의 없어 재전송이 보이지 않는 것이 자연스럽다. 재전송을 만들기 위해 공용 서비스에 부하나 고의적인 손실을 주면 안 된다.

ㅁ 격리된 Linux 환경에서 손실을 관찰해 보기

다음 실습은 ip, tc, tcpdump, nc가 있는 개인 Linux VM에서만 수행한다.

두 Network Namespace와 가상 Link를 만들기 때문에 일반 Network Interface에는 손실을 적용하지 않는다.

가상 Client와 Server를 만든다.

sudo ip netns add tcp-client
sudo ip netns add tcp-server
sudo ip link add veth-c type veth peer name veth-s
sudo ip link set veth-c netns tcp-client
sudo ip link set veth-s netns tcp-server

sudo ip -n tcp-client addr add 10.17.0.1/24 dev veth-c
sudo ip -n tcp-server addr add 10.17.0.2/24 dev veth-s
sudo ip -n tcp-client link set lo up
sudo ip -n tcp-server link set lo up
sudo ip -n tcp-client link set veth-c up
sudo ip -n tcp-server link set veth-s up

Client가 보내는 Packet의 일부만 가상 Link에서 임의로 버린다.

sudo ip netns exec tcp-client \
  tc qdisc add dev veth-c root netem loss 10%

Server Terminal에서 수신을 시작한다. nc Option은 구현마다 다를 수 있다.

sudo ip netns exec tcp-server nc -l 8080 > /dev/null

Capture Terminal에서 Packet을 저장한다.

sudo ip netns exec tcp-client \
  tcpdump -n -i veth-c -s 0 -w /tmp/tcp-loss.pcap 'tcp port 8080'

Client Terminal에서 충분한 Data를 보낸다.

dd if=/dev/zero bs=1M count=10 | \
  sudo ip netns exec tcp-client nc 10.17.0.2 8080

전송과 Capture를 종료한 뒤 /tmp/tcp-loss.pcap을 Wireshark에서 열어 다음 질문을 확인한다.

재전송 Segment의 Seq와 Len은 어느 Byte 범위인가?
Duplicate ACK의 Ack 값은 어디에서 멈췄는가?
SACK Block은 누적 ACK 뒤의 어떤 범위를 가리키는가?
Fast Retransmission과 RTO 기반 Retransmission은 시간 간격이 어떻게 다른가?

실습을 마치면 Namespace를 삭제한다.

Namespace 삭제와 함께 내부 가상 Interface와 netem 설정도 제거된다.

sudo ip netns del tcp-client
sudo ip netns del tcp-server

임의 손실이므로 한 번의 Capture에 모든 현상이 나타난다고 보장할 수는 없다.

손실률을 지나치게 높이면 Handshake 자체가 지연되고 흐름을 읽기 어려워진다.

ㅁ 핵심 정리

TCP Sequence Number는 Segment 번호가 아니라 Byte Stream에서 첫 Data Byte의 위치다.
ACK 번호는 마지막으로 받은 Byte가 아니라 다음에 기대하는 Byte 번호다.
Cumulative ACK는 끊김 없이 받은 전체 범위를 한 번에 확인한다.
누적 ACK 뒤의 Data가 먼저 도착하면 같은 ACK 번호가 반복되는 Duplicate ACK가 생길 수 있다.
전통적으로 3개의 Duplicate ACK는 RTO 전에 빠진 Segment를 보내는 Fast Retransmit의 단서가 된다.
Packet Reordering도 Duplicate ACK를 만들 수 있으므로 하나의 중복 ACK가 곧 손실 확정은 아니다.
뒤따르는 Data가 없으면 Duplicate ACK가 생기지 않으므로 RTO가 마지막 복구 수단이 된다.
RTO는 관찰한 RTT와 변동 폭을 반영하며 반복 Timeout에서는 Exponential Backoff가 적용된다.
SACK은 Cumulative ACK 뒤에 이미 받은 불연속 Byte Block을 알려 효율적인 재전송을 돕는다.
Receiver TCP는 중복 Byte를 제거하고 빈 구간을 채운 뒤 순서 있는 Stream을 Application에 제공한다.
TCP ACK는 상대 TCP Stack의 수신 확인이며 Application 업무의 Exactly-Once 처리를 보장하지 않는다.
Sender는 손실 지점을 직접 보는 것이 아니라 ACK의 진행, 반복, 시간이라는 End-to-End 단서로 손실을 추론한다.

핵심 용어: Sequence Number, Acknowledgment Number, Byte Stream, Cumulative ACK, Duplicate ACK, Fast Retransmit, Retransmission Timer, Retransmission Timeout, RTT, SRTT, RTTVAR, Exponential Backoff, Retransmission Ambiguity, Karn's Algorithm, SACK, Out-of-Order, Head-of-Line Blocking

TCP는 사라진 Packet을 직접 목격하지 않는다. 다음에 기다리는 Byte 번호가 멈추고 같은 ACK가 반복되거나 시간이 지나도 ACK가 전진하지 않는 모습을 보고 빈칸을 추론한다.

ㅁ 다음 이야기

손실된 Byte를 찾아 다시 보내는 방법은 알게 되었다.

하지만 Sender가 Receiver의 처리 속도보다 빠르게 보내면 Receiver Buffer가 가득 찬다.

반대로 Receiver가 충분히 빨라도 중간 Network가 감당하지 못하면 Router Queue가 넘친다.

받는 사람의 한계와 길 전체의 한계는 어떻게 구분해야 할까?

다음 글에서는 「받는 사람이 감당하지 못할 만큼 보내면 어떻게 될까?」라는 질문을 통해 Receive Window, Sliding Window, Window Scaling, Congestion Window와 Flow Control·Congestion Control의 차이를 살펴본다.

[Network] 16. 대화를 시작하기 전에 왜 세 번이나 인사할까?

기록하는 백엔드개발자 — Sun, 19 Jul 2026 20:16:55 +0900

TCP/IP를 우편 시스템으로 이해하기 — Part 5. 믿을 수 없는 길 위에서 믿을 수 있게 보내기

ㅁ 들어가며

TCP는 Application에 순서 있는 신뢰 가능한 Byte Stream을 제공한다.

그러려면 양쪽이 각 Byte의 위치를 알아야 한다.

Client가 보낸 첫 Byte와 Server가 보낸 첫 Byte는 서로 다른 Sequence Space에서 시작한다.

데이터를 보내기 전에 다음 질문에 답해야 한다.

상대가 해당 IP와 Port에서 연결을 받을 준비가 되었는가?
Client가 사용할 초기 Sequence Number는 무엇인가?
Server가 사용할 초기 Sequence Number는 무엇인가?
양쪽 방향의 패킷과 응답이 도달할 수 있는가?
어떤 TCP Option을 사용할 수 있는가?

TCP는 3-Way Handshake로 이 정보를 교환한다.

Client → Server : SYN
Server → Client : SYN-ACK
Client → Server : ACK

세 줄만 외우면 동작의 모양은 기억할 수 있다.

하지만 왜 세 번째 ACK가 필요한지,

SYN이 Sequence Number 하나를 소비한다는 것이 무엇인지 설명하기는 어렵다.

이번 글에서는

Initial Sequence Number(ISN), SYN, SYN-ACK, ACK, TCP State, MSS, Window Scale, SACK Permitted를

실제 숫자로 추적하고 Handshake 실패가 Timeout과 Refused로 다르게 보이는 이유를 살펴본다.

ㅁ 전화 연결보다 두 개의 등기 장부에 가깝다

TCP 연결을 전화 통화에 비유하면 서로 연결한 뒤 대화한다는 점은 이해하기 쉽다.

하지만 TCP는 양쪽 방향의 Byte를 각각 번호로 관리한다.

Client가 보내는 Byte의 번호와 Server가 보내는 Byte의 번호는 별도다.

Client → Server Sequence Space: Client ISN에서 시작
Server → Client Sequence Space: Server ISN에서 시작

두 사람이 각자 발송 장부를 하나씩 갖고 있다고 생각해 보자.

Client는 “나는 번호 1000부터 보내겠다”고 알리고,

Server는 “나는 번호 5000부터 보내겠다”고 알린다.

상대는 다음에 받을 번호를 ACK로 확인한다.

Client의 장부 시작 번호를 Server가 확인
Server의 장부 시작 번호를 Client가 확인

한 방향의 번호만 맞춰서는 양방향 Byte Stream을 만들 수 없다.

3-Way Handshake는 연결 가능성 확인과 함께 서로 독립적인 두 Sequence Space의 시작점을 동기화하는 과정이다.

ㅁ Handshake 전 양쪽은 어떤 상태일까?

Server Application은 Local Address와 Port에 Bind하고 Listen한다.

Server: 203.0.113.20:443
TCP State: LISTEN

Client는 연결 전 Socket에서 Server Endpoint로 Active Open을 시도한다.

Client: 192.0.2.10:52000
Server: 203.0.113.20:443

TCP 연결을 구분하는 4-Tuple은 다음과 같다.

Source IP       192.0.2.10
Source Port     52000
Destination IP  203.0.113.20
Destination Port 443

Client가 connect()를 호출하면 운영체제의 TCP Stack이 Handshake를 시작한다.

Application이 SYN Packet을 직접 만드는 것이 아니다. 일반적인 Socket API에서는 Kernel TCP Stack이 상태와 재전송을 관리한다.

ㅁ 첫 번째 인사 — SYN

Client는 자신의 Initial Sequence Number를 선택한다.

설명을 위해 Client ISN을 1000이라고 가정하자.

Client → Server
Flags: SYN
Sequence Number: 1000

Client의 TCP State는 일반적으로 다음처럼 바뀐다.

CLOSED → SYN-SENT

SYN은 다음 의미를 전달한다.

이 Endpoint와 TCP 연결을 시작하고 싶다.
내 Sequence Space의 시작점은 1000이다.
내가 지원하거나 제안하는 TCP Option은 이것이다.

SYN Segment에 Application Data가 없어도 SYN Flag 자체는 Sequence Number 하나를 소비한다.

따라서 Server가 정상적으로 SYN을 받았다면 다음에 기대하는 번호는 1001이다.

Client SYN seq 1000
→ Server가 기대하는 다음 번호 1001

SYN과 FIN이 Sequence Space에서 하나를 소비하기 때문에 연결 제어도 ACK로 명확하게 확인할 수 있다.

ㅁ 두 번째 인사 — SYN-ACK

Server의 Port 443에 Listening Socket이 있고 SYN을 받아들일 수 있다고 하자.

Server도 자신의 ISN을 선택한다. 설명을 위해 5000이라고 가정한다.

Server가 보내는 Segment는 두 역할을 함께 한다.

Server → Client
Flags: SYN, ACK
Sequence Number: 5000
Acknowledgment Number: 1001

ㅇ ACK 1001의 의미

Client의 SYN seq 1000을 받았다.
다음에는 seq 1001부터 보내 달라.

ㅇ SYN seq 5000의 의미

나도 연결할 준비가 되었다.
내 Sequence Space의 시작점은 5000이다.

Server는 연결 정보를 만들고 일반적으로 다음 상태로 이동한다.

LISTEN → SYN-RECEIVED

아직 Server 입장에서 Handshake가 완전히 끝난 것은 아니다.

Client가 Server의 SYN-ACK을 실제로 받았는지 확인하지 못했기 때문이다.

ㅁ 세 번째 인사 — ACK

Client가 SYN-ACK을 받으면 다음 사실을 알 수 있다.

처음 보낸 SYN이 Server에 도착했다.
Server의 응답이 Client로 돌아오는 경로도 동작했다.
Server가 Port에서 연결을 받을 준비가 있다.
Server의 ISN은 5000이다.

Client는 Server의 SYN을 확인하는 ACK를 보낸다.

Client → Server
Flags: ACK
Sequence Number: 1001
Acknowledgment Number: 5001

ACK 5001의 의미는 다음과 같다.

Server의 SYN seq 5000을 받았다.
다음에는 seq 5001부터 보내 달라.

Client는 SYN-ACK을 받고 ACK를 보낸 시점에 일반적으로 ESTABLISHED 상태가 된다.

Client: SYN-SENT → ESTABLISHED

Server가 마지막 ACK를 받으면 자신의 SYN이 Client에 도착했음을 확인하고 ESTABLISHED 상태가 된다.

Server: SYN-RECEIVED → ESTABLISHED

이제 양쪽은 서로의 Sequence Space 시작점을 확인했다.

Client의 다음 Data seq: 1001
Server의 다음 Data seq: 5001

세 번째 ACK는 TCP Header만 있는 순수 ACK일 수 있고 Client의 첫 Application Data를 함께 실을 수도 있다.

ㅁ 왜 두 번으로 끝낼 수 없을까?

SYN과 SYN-ACK까지만 교환했다고 생각해 보자.

Client는 Server의 SYN-ACK을 받았으므로 양방향 경로가 동작하고 Server의 ISN이 5000이라는 사실을 안다.

하지만 Server는 자신의 SYN-ACK이 Client에게 도착했는지 알 수 없다.

Client → Server : SYN 도착
Server → Client : SYN-ACK 전송
                 실제 도착 여부를 Server는 모름

SYN-ACK이 중간에서 사라졌는데 Server가 연결을 완성했다고 판단하면

Client는 Server ISN을 모르는 상태인데 Server만 연결됐다고 생각할 수 있다.

세 번째 ACK가 Server에 도착해야 Server는 다음을 확인한다.

Server → Client 방향으로 보낸 SYN이 도착했다.
Client가 Server의 Sequence Number를 받았다.
Client → Server 방향의 ACK도 돌아왔다.

세 메시지는 각 방향의 ISN을 알리고 상대가 그 ISN을 받았다는 확인을 완성한다.

이를 단순히 “양쪽이 송신과 수신을 모두 할 수 있는지 세 번 확인한다”고 표현할 수 있지만

핵심은 두 개의 독립적인 Sequence Space를 양쪽 모두가 확인하는 데 세 번째 ACK가 필요하다는 점이다.

ㅁ Initial Sequence Number는 왜 0부터 시작하지 않을까?

실제 ISN은 예제처럼 항상 1000이나 5000으로 시작하지 않는다.

TCP Stack은 연결마다 변하는 32비트 ISN을 선택한다.

ISN을 변화시키는 이유는 다음과 같다.

이전 연결에서 늦게 도착한 Segment와 새로운 연결의 Segment를 구분하는 데 도움을 준다.
Sequence Number를 쉽게 예측해 위조 Segment를 삽입하는 공격을 어렵게 한다.

Packet Capture 도구는 읽기 쉽게 실제 Sequence Number를 0부터 시작하는 Relative Sequence Number로 표시할 수 있다.

실제 Client ISN: 2873459012
Capture 표시    : Seq=0
다음 표시       : Seq=1

Wireshark에서 Seq=0, Ack=1이 보인다고 실제 TCP Header의 ISN이 0이라는 뜻은 아닐 수 있다.

Raw Sequence Number와 Relative Sequence Number를 구분해야 한다.

ㅁ Handshake에서는 어떤 TCP Option을 나눌까?

SYN과 SYN-ACK에는 연결에서 사용할 기능과 한계를 알리는 TCP Option이 들어갈 수 있다.

ㅇ MSS — Maximum Segment Size

수신 측이 하나의 TCP Segment에서 받을 수 있는 TCP Payload 크기를 알린다.

각 방향에서 상대가 광고한 MSS를 고려해 Segment 크기를 정한다.

MSS는 Ethernet Frame 전체 크기나 IP Packet 전체 크기가 아니라 TCP Data 크기 기준이다.

ㅇ Window Scale

TCP Header의 16비트 Window Size만으로 큰 대역폭·지연 경로의 수신 Window를 충분히 표현하기 어려울 때 배율을 협상한다.

Window Scale Option은 SYN 교환 시 알려야 연결에서 사용할 수 있다.

ㅇ SACK Permitted

수신 측이 Selective Acknowledgment(SACK)을 지원함을 알린다.

연속되지 않은 여러 수신 구간을 알려 손실 복구를 더 효율적으로 할 수 있다.

ㅇ Timestamps

RTT 측정과 오래된 중복 Segment 구분 등에 사용할 Timestamp 정보를 교환할 수 있다.

SYN Option 교환
├─ MSS
├─ Window Scale
├─ SACK Permitted
└─ Timestamps

Handshake는 연결을 열기만 하는 과정이 아니라 이후 Byte Stream을 운영할 조건도 준비한다.

양쪽 SYN에 어떤 Option이 있었는지 확인하면 성능 문제와 중간 장비의 Option 제거 문제를 조사하는 데 도움이 된다.

ㅁ SYN에 응답이 없으면 무엇을 알 수 있을까?

Client가 SYN을 보냈지만 아무 응답도 받지 못했다고 하자.

Client는 SYN이 손실되었는지, Server가 응답했지만 Return Path에서 손실되었는지 알 수 없다.

일정 Timer 뒤 SYN을 재전송한다.

Client → Server : SYN
                  응답 없음
Client → Server : SYN Retransmission
                  응답 없음
...
Client           : Connect Timeout

가능한 원인은 다양하다.

Forward Path에서 SYN Drop
Firewall의 Silent Drop
Server 또는 Network 장애
Return Path에서 SYN-ACK Drop
Stateful 장비의 비대칭 경로 문제
잘못된 IP 또는 Port

SYN 재전송만으로 어느 지점이 범인인지 확정할 수 없다.

Client, Server, 중간 지점의 Packet Capture를 함께 봐야 한다.

ㅁ RST가 바로 돌아오면 무엇이 다를까?

SYN이 Server Host에 도착했지만 해당 Destination Port에 Listening Socket이 없다고 하자.

Server의 TCP Stack은 일반적으로 RST가 포함된 응답을 보낼 수 있다.

Client → Server : SYN
Server → Client : RST, ACK

Client에서는 다음과 같이 즉시 보일 수 있다.

Connection refused

Timeout과 비교하면 중요한 단서가 있다.

Timeout : SYN 또는 응답이 보이지 않음 — 여러 Drop 가능성
Refused : TCP 응답이 돌아옴 — Host 도달 후 Listener 부재 가능성

중간 Firewall이 Reject 정책으로 RST를 대신 보낼 수도 있다.

RST가 왔다는 사실만으로 반드시 Server Application이 직접 거절했다고 단정할 수는 없다.

RST Packet의 Source 위치와 TTL, 여러 지점의 Capture를 함께 확인해야 한다.

ㅁ 마지막 ACK가 사라지면 어떻게 될까?

Client가 SYN-ACK을 받고 마지막 ACK를 보냈지만 ACK가 중간에서 손실되었다고 하자.

Client → Server : SYN
Server → Client : SYN-ACK
Client → Server : ACK  손실

Client는 SYN-ACK을 정상적으로 받았으므로 ESTABLISHED로 이동했을 수 있다.

Server는 마지막 ACK를 받지 못해 SYN-RECEIVED에 남는다. Timer가 만료되면 SYN-ACK을 재전송할 수 있다.

Server → Client : SYN-ACK Retransmission
Client → Server : ACK 재응답

Client TCP는 이미 받은 SYN에 대한 재전송임을 알고 ACK를 다시 보낼 수 있다. 일시적 손실이라면 Handshake가 회복될 수 있다.

마지막 ACK 하나가 손실되었다고 연결이 반드시 영구 실패하는 것은 아니다. TCP의 재전송과 상태 처리가 연결 설정에도 적용된다.

Client의 첫 Data Segment가 ACK Flag와 함께 도착하면 Server가 Handshake 완료를 확인하는 데 기여할 수도 있다.

ㅁ Handshake가 끝나면 Application도 준비된 것일까?

TCP Handshake는 Kernel의 TCP Stack 사이에서 완료된다.

Server Process가 Listen하고 있고 Kernel Queue가 연결을 받아들일 수 있으면 Handshake가 완료될 수 있다.

하지만 다음 사실까지 보장하지 않는다.

Server Application이 연결을 즉시 accept()했다.
Worker Thread가 요청을 처리할 여유가 있다.
Database와 외부 API가 정상이다.
TLS Handshake가 성공했다.
HTTP 요청에 정상 응답할 수 있다.

TCP Connect 성공
≠ TLS 성공
≠ HTTP 성공
≠ Application 업무 처리 성공

TCP 연결 성공은 Transport Layer의 준비가 완료되었다는 뜻이다.

Application Health를 확인하려면 실제 Protocol 요청과 응답까지 관찰해야 한다.

ㅁ SYN이 너무 많이 오면 어떻게 될까?

Server가 SYN을 받으면 완성되지 않은 연결 상태를 일정 시간 유지한다.

공격자가 많은 SYN을 보내고 마지막 ACK를 보내지 않으면 SYN Backlog가 가득 차 정상 Client의 연결을 방해할 수 있다.

이를 SYN Flood 공격이라고 한다.

공격자 → Server : SYN 다수
Server → 공격자 : SYN-ACK
공격자           : 마지막 ACK 없음
Server           : Half-Open Connection 상태 누적

운영체제는 Backlog 크기 조절, SYN-ACK 재시도 제한, Rate Limiting, SYN Cookies 같은 방어 기법을 사용할 수 있다.

SYN Cookies는 초기 SYN 상태의 일부를 Server에 저장하는 대신 Sequence Number에 검증 가능한 정보를 인코딩해 마지막 ACK가 돌아왔을 때 상태를 복원하는 방식이다.

정확한 동작과 사용 조건, Option 처리 영향은 운영체제 구현에 따라 다르다.

ㅁ TCP Handshake와 TLS Handshake는 같은 것일까?

HTTPS 연결에서는 여러 단계가 이어진다.

일반적인 TCP 기반 HTTPS 흐름을 단순화하면 다음과 같다.

1. DNS Lookup
2. TCP 3-Way Handshake
3. TLS Handshake
4. HTTP Request / Response

TCP Handshake는 Transport 연결과 Sequence Space를 준비한다.

TLS Handshake는 암호화 Parameter를 합의하고 인증서를 통해 Server Identity를 확인하며 Session Key를 만든다.

두 Handshake는 계층과 목적이 다르다.

HTTP/3는 QUIC을 사용하므로 TCP 3-Way Handshake 없이 UDP 위의 QUIC/TLS 연결 설정을 수행한다.

“Handshake 실패”라고만 말하지 말고 TCP, TLS, Application 중 어느 단계인지 구분해야 한다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
연결을 시작하겠다는 첫 등기	SYN	Client ISN과 TCP Option을 알리는 연결 요청
요청 확인과 Server 장부 번호 안내	SYN-ACK	Client SYN을 ACK하고 Server ISN을 알리는 응답
Server 번호를 받았다는 최종 확인	ACK	Server SYN의 수신을 확인해 Handshake 완성
양쪽 발송 장부의 첫 번호	Initial Sequence Number	각 방향 TCP Sequence Space의 시작점
창구가 연결 요청을 기다림	LISTEN	Server Socket이 새 연결을 받을 준비 상태
첫 확인 답장을 기다림	SYN-SENT	Client가 SYN 전송 후 응답을 기다리는 상태
마지막 확인을 기다림	SYN-RECEIVED	Server가 SYN-ACK 후 최종 ACK를 기다리는 상태
양쪽 장부가 동기화됨	ESTABLISHED	TCP Data를 주고받을 수 있는 연결 상태
처리 가능한 소포 크기 안내	MSS	상대에게 받을 수 있는 TCP Payload 크기를 광고
미완성 접수 대기 줄	SYN Backlog	Handshake가 끝나지 않은 연결 요청을 관리하는 Queue

Sequence Number를 포함한 Handshake는 다음처럼 정리할 수 있다.

Client                                      Server
SYN-SENT                                    LISTEN
  SYN, Seq=1000 -------------------------->
                          <---- SYN-ACK, Seq=5000, Ack=1001
  ACK, Seq=1001, Ack=5001 ---------------->
ESTABLISHED                                 ESTABLISHED

ㅁ 직접 Handshake를 관찰해 보기

Linux에서 TCP Handshake를 Packet Capture로 관찰할 수 있다.

첫 번째 Terminal에서 개인 개발 환경의 TCP Port를 Listen한다. nc 구현에 따라 옵션 문법이 다를 수 있다.

nc -l 8080

두 번째 Terminal에서 접속한다.

nc -v 127.0.0.1 8080

세 번째 Terminal에서 Loopback Traffic을 Capture한다.

sudo tcpdump -n -i lo -vv 'tcp port 8080'

macOS에서는 Loopback Interface가 일반적으로 lo0다.

출력에서 다음 Flag 순서를 찾는다.

Flags [S]   : SYN
Flags [S.]  : SYN-ACK
Flags [.]   : ACK

Wireshark에서는 다음 Display Filter로 SYN이 포함된 Segment를 볼 수 있다.

tcp.flags.syn == 1

TCP State를 운영체제에서 확인한다.

ss -tn state syn-sent
ss -tn state syn-recv
ss -tn state established

정상 Handshake는 매우 빠르게 끝나므로 SYN 상태를 명령으로 포착하기 어려울 수 있다.

Packet Capture가 상태 전이 순서를 확인하는 데 더 적합하다.

공용 Server에 반복 SYN을 보내거나 SYN Flood를 재현하는 행위는 서비스에 영향을 줄 수 있다.

개인 Loopback 또는 허가된 격리 환경에서 정상 연결 한 건만 관찰한다.

ㅁ 핵심 정리

TCP 3-Way Handshake는 연결 가능성을 확인하고 양방향 Sequence Space의 시작점을 동기화한다.
Client는 SYN에 자신의 ISN을 담고 SYN-SENT 상태로 이동한다.
Server는 SYN-ACK으로 Client ISN을 확인하고 자신의 ISN을 알리며 SYN-RECEIVED가 된다.
Client의 마지막 ACK가 Server ISN 수신을 확인해야 Server도 ESTABLISHED가 된다.
SYN은 Application Data가 없어도 Sequence Number 하나를 소비한다.
실제 ISN은 연결마다 변하며 Capture 도구는 Relative Sequence Number로 표시할 수 있다.
SYN Option으로 MSS, Window Scale, SACK Permitted, Timestamp 등을 알릴 수 있다.
응답 없는 SYN은 Timeout을, Listener 없는 Port의 RST는 Refused를 만들 수 있지만 중간 장비도 응답을 생성할 수 있다.
마지막 ACK가 손실되어도 SYN-ACK 재전송과 ACK 재응답으로 회복될 수 있다.
TCP Handshake 성공은 TLS와 Application의 정상 동작을 보장하지 않는다.
SYN Flood는 Half-Open Connection 상태를 쌓으며 SYN Cookies 등이 완화에 사용될 수 있다.

핵심 용어: TCP 3-Way Handshake, SYN, SYN-ACK, ACK, Initial Sequence Number, Sequence Space, Relative Sequence Number, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, MSS, Window Scale, SACK Permitted, Timestamp, SYN Backlog, SYN Flood, SYN Cookies, RST

세 번째 ACK는 형식적인 마지막 인사가 아니다. Server의 Sequence Number도 Client에게 도착했다는 사실을 확인해 양방향 장부를 완성한다.

ㅁ 다음 이야기

Handshake가 끝나 양쪽의 Sequence Space가 준비되었다.

이제 Client가 여러 TCP Segment에 Byte를 나누어 보낸다. 그런데 중간에서 Segment 하나가 사라지면 Sender는 무엇을 보고 손실을 알아챌까?

ACK가 오지 않는 시간과 같은 ACK가 반복되는 현상은 각각 어떤 단서가 될까?

다음 글에서는 「편지가 사라졌다는 사실은 어떻게 알아챌까?」라는 질문을 통해 Cumulative ACK, Retransmission Timeout, Duplicate ACK, Fast Retransmit와 SACK을 살펴본다.

[Network] 15. 모든 편지에 수령 확인이 필요할까?

기록하는 백엔드개발자 — Sun, 19 Jul 2026 20:15:10 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 4. 이름을 주소로 바꾸고 대화를 시작하기

ㅁ 들어가며

IP Address와 Port Number를 알면 어느 Host의 어떤 Application으로 데이터를 보낼지 표현할 수 있다.

이제 남은 질문은 어떻게 보낼 것인가다.

은행 송금 요청처럼 빠짐없이 순서대로 전달되어야 하는 데이터가 있다.

한 부분이라도 사라지면 전체 의미가 달라질 수 있다.

반면 실시간 음성처럼 조금 손실되더라도 오래된 데이터를 기다리는 것보다

최신 데이터를 제때 전달하는 편이 나은 경우도 있다.

모든 데이터를 확인하고 다시 보낼 것인가?
아니면 필요한 정보만 담아 바로 보낼 것인가?

Transport Layer의 대표적인 두 선택이 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)다.

흔히 TCP는 느리지만 안전하고 UDP는 빠르지만 불안전하다고 설명한다.

하지만 이 표현만으로는

HTTP/3가 UDP 위의 QUIC을 사용하는 이유,

DNS가 UDP와 TCP를 모두 사용하는 이유,

Application이 UDP 위에서 신뢰성을 구현할 수 있는 이유를 설명하기 어렵다.

이번 글에서는

Byte Stream, Datagram, Reliability, Ordering, Message Boundary, Overhead, Head-of-Line Blocking을 중심으로 TCP와 UDP가 각각 무엇을 제공하고 무엇을 Application에 맡기는지 살펴본다.

ㅁ IP는 배달을 어디까지 약속할까?

IP는 패킷을 목적지 주소 방향으로 전달하는 Best-Effort 서비스다.

경로 중 Packet Loss, 순서 변경, 중복, 지연이 발생할 수 있다.

보낸 순서: Packet 1 → Packet 2 → Packet 3

가능한 도착:
Packet 1 → Packet 3 → Packet 2
Packet 1 → Packet 3
Packet 1 → Packet 2 → Packet 2 → Packet 3

IP 자체는 다음을 End-to-End로 보장하지 않는다.

모든 Packet의 도착
보낸 순서와 같은 도착 순서
중복 없는 전달
Application이 데이터를 처리했다는 확인

Transport Protocol은 이 불완전한 IP 위에서 Application이 원하는 통신 모델을 제공한다.

TCP는 순서 있는 신뢰 가능한 Byte Stream을 제공하려 한다.

UDP는 최소한의 Transport 정보로 독립적인 Datagram을 전달하고 추가 동작을 Application에 맡긴다.

ㅁ 일반 우편과 등기우편으로만 나누면 충분할까?

우편 비유에서는 UDP를 일반 우편, TCP를 등기우편에 자주 비유한다.

일반 우편은 보내고 끝나며 등기우편은 접수와 수령 과정을 확인한다고 설명하기 쉽다.

하지만 실제 TCP는 편지 한 통씩 수령증을 붙이는 방식과 다르다.

TCP는 Application Message가 아니라 연속된 Byte Stream을 다룬다.
여러 Byte 범위를 묶어 누적 ACK할 수 있다.
전송량을 수신자의 여유와 네트워크 혼잡에 맞춘다.
손실된 범위를 추론해 재전송한다.

UDP도 무조건 확인할 수 없는 우편은 아니다.

Application이 Sequence Number, ACK, 재전송, 오류 복구를 직접 추가할 수 있다. QUIC이 UDP 위에서 연결과 신뢰성, 혼잡 제어를 구현하는 것이 대표적인 사례다.

따라서 우편 비유의 핵심은 다음 정도로 두는 것이 정확하다.

TCP: 운송 체계가 순서와 재전송을 관리하는 연속 배송 서비스
UDP: 독립된 봉투를 전달하고 추가 규칙은 이용자가 정하는 배송 서비스

ㅁ UDP는 무엇을 담아 보낼까?

UDP는 Application Data를 Datagram 단위로 전달한다.

UDP Header의 기본 크기는 8바이트이며 네 필드로 이루어진다.

필드	크기	역할
Source Port	16비트	보내는 Endpoint의 Port
Destination Port	16비트	받을 Endpoint의 Port
Length	16비트	UDP Header와 Data의 전체 길이
Checksum	16비트	전송 중 손상 탐지

UDP Header에는 다음 기능을 위한 필드가 없다.

연결 설정 Handshake
Sequence Number
Acknowledgment Number
Receiver Window
Protocol 자체의 재전송 Timer

UDP는 Datagram을 IP에 넘기고 도착 여부를 기본적으로 추적하지 않는다.

이 단순함은 Header와 상태 관리 부담을 줄이지만, 필요한 신뢰성을 Application이 결정해야 한다는 뜻이기도 하다.

ㅁ UDP Checksum이 있으면 신뢰할 수 있는 것 아닐까?

Checksum은 데이터가 전송 중 손상되었는지 탐지하는 데 도움을 준다.

하지만 Checksum이 다음을 제공하는 것은 아니다.

손상된 Datagram의 자동 복구
사라진 Datagram의 재전송
Datagram 순서 정렬
중복 Datagram 제거
보낸 상대의 신원 인증

Checksum 검증에 실패하면 Datagram은 폐기될 수 있지만 UDP가 새 Datagram을 요청하지는 않는다.

IPv4 UDP에서는 Checksum 값 0으로 미사용을 표현할 수 있다.

IPv6 UDP Checksum은 일반적으로 필수이며 일부 제한적인 예외는 별도 규격과 환경에 따른다.

TCP와 UDP의 Checksum도 암호학적 무결성과 인증을 제공하는 기능이 아니다.

의도적인 변조와 도청을 막으려면 TLS, DTLS, QUIC 같은 보안 계층이 필요하다.

ㅁ Datagram은 편지 한 통의 경계를 기억한다

Application이 UDP Socket에 세 번 데이터를 보냈다고 하자.

send: "ABC"
send: "DEFG"
send: "HI"

UDP는 각각을 독립된 Datagram으로 다룬다.

정상 도착했다면 수신 Application은 세 Datagram의 경계를 구분해 받을 수 있다.

recv: "ABC"
recv: "DEFG"
recv: "HI"

이를 Message Boundary를 보존한다고 표현한다.

다만 수신 Buffer가 Datagram보다 작으면 나머지 부분이 잘리거나 API별 동작이 달라질 수 있다. 큰 UDP Datagram은 IP Fragmentation과 손실 위험도 키울 수 있다.

각 Datagram은 독립적이므로 다음처럼 도착할 수 있다.

"DEFG" → "ABC" → "HI"

또는 하나가 사라질 수 있다.

"ABC" → "HI"

UDP Protocol은 이를 원래 순서로 재배치하거나 누락을 자동으로 채우지 않는다.

ㅁ TCP는 편지보다 긴 종이 두루마리에 가깝다

TCP는 Application에 Ordered Byte Stream을 제공한다.

Application이 다음처럼 데이터를 써도 수신 측의 읽기 단위가 그대로 일치한다고 보장하지 않는다.

Sender write 1: "ABC"
Sender write 2: "DEFG"

가능한 Receiver read:
"ABCDEFG"

또는
"AB"
"CDE"
"FG"

TCP는 Byte의 순서는 보존하지만 Application Message의 경계는 보존하지 않는다.

따라서 TCP 위의 Application Protocol은 메시지 경계를 스스로 표현해야 한다.

고정 길이 Header
Length Prefix
줄바꿈이나 특정 Delimiter
HTTP처럼 Header와 Content-Length, Chunked Encoding 등의 규칙

TCP를 사용한다고 Application Message가 자동으로 한 번의 read에 온전히 도착하는 것은 아니다.

이 점을 놓치면 TCP Stream에서 Message가 합쳐지거나 나뉘는 현상을 Packet 오류로 오해할 수 있다.

ㅁ TCP Header에는 어떤 약속이 들어 있을까?

Option이 없는 TCP Header의 최소 크기는 20바이트다.

대표적인 필드는 다음과 같다.

필드	역할
Source / Destination Port	양쪽 Application Endpoint 식별
Sequence Number	Byte Stream에서 Segment Data의 위치 표현
Acknowledgment Number	다음에 받기를 기대하는 Byte 위치 표현
Data Offset	TCP Header 길이 표시
Flags	SYN, ACK, FIN, RST 등 연결 상태 제어
Window Size	수신 가능한 Byte 범위 광고
Checksum	Header와 Data 손상 탐지
Options	MSS, Window Scale, SACK 관련 정보 등

TCP는 이 정보를 사용해 다음 기능을 제공한다.

Connection Establishment와 종료
Byte 순서 정렬
ACK와 재전송을 통한 신뢰성
중복 Byte 처리
Receiver 능력에 맞춘 Flow Control
Network 혼잡에 맞춘 Congestion Control

이 기능들은 Header 12바이트 차이만의 문제가 아니다.

양 끝이 Connection State, Buffer, Timer, Sequence Space와 혼잡 상태를 관리해야 한다.

TCP의 Overhead는 Packet Header 크기뿐 아니라 연결 설정과 상태 관리, ACK, 재전송, 제어 알고리즘을 포함한다.

ㅁ TCP의 신뢰성은 무엇을 보장할까?

TCP가 신뢰 가능하다는 말은 일반적으로 다음 의미다.

연결이 유지되는 동안
상대 TCP가 전달한 Byte를
중복 없이 순서대로
Application이 읽을 수 있는 Stream에 제공한다.

그러나 TCP ACK가 다음 사실까지 보장하는 것은 아니다.

사용자가 화면에서 내용을 보았다.
Server Application이 업무 처리를 완료했다.
Database Transaction이 Commit되었다.
요청이 정확히 한 번만 비즈니스에 반영되었다.

TCP ACK는 Transport Layer의 수신 상태를 나타낸다.

Application 처리 완료 확인이 아니다.

예를 들어 결제 요청의 Byte가 Server에 도착한 뒤 응답 전에 연결이 끊기면 Client는 결제가 처리되었는지 알기 어렵다.

무작정 재시도하면 중복 결제가 생길 수 있다.

이 문제는 Application Protocol의 응답, Idempotency Key, Transaction 상태 조회 같은 별도의 설계로 해결해야 한다.

TCP Reliability ≠ Exactly-Once Business Processing

ㅁ UDP는 빠르고 TCP는 느리다는 말은 항상 맞을까?

UDP에는 TCP Handshake와 기본 재전송, 순서 정렬, Flow/Congestion Control이 없다.

작은 질의 하나를 즉시 보내는 상황에서는 적은 제어 절차가 장점이 될 수 있다.

하지만 UDP를 사용한다고 Application이 자동으로 빨라지는 것은 아니다.

신뢰성, 혼잡 제어, 보안을 Application이 모두 구현해야 한다면 복잡성과 제어 Traffic이 다시 생긴다.

TCP도 이미 연결된 상태에서는 지속적으로 데이터를 효율적으로 전송할 수 있고 운영체제에 오랫동안 최적화되어 있다.

실제 성능은 다음 요소의 영향을 받는다.

연결이 새로 필요한가, 재사용할 수 있는가?
손실률과 RTT는 얼마인가?
데이터 크기와 메시지 빈도는 어떤가?
순서 보장이 필요한가?
Application이 재전송과 혼잡 제어를 어떻게 구현했는가?
TLS와 Protocol Handshake가 몇 번 필요한가?
Kernel과 NIC Offload가 어떤 처리를 지원하는가?

따라서 선택 기준은 단순한 속도 서열이 아니다.

TCP: 공통 신뢰성과 Stream 모델을 Transport가 제공
UDP: 최소 Datagram 모델 위에서 Application이 필요한 기능을 선택

ㅁ 한 조각이 사라지면 뒤의 데이터도 기다려야 할까?

TCP는 Byte를 순서대로 Application에 제공한다.

다음 Segment 중 두 번째가 사라졌다고 하자.

Segment 1 도착
Segment 2 손실
Segment 3 도착
Segment 4 도착

수신 TCP는 뒤의 Byte를 Buffer에 보관할 수 있지만 빠진 Byte가 복구되기 전에는 순서대로 Application에 전달하지 못할 수 있다.

이를 TCP Stream의 Head-of-Line(HOL) Blocking이라고 한다.

하나의 TCP 연결 위에서 여러 논리적 요청을 Multiplexing하는 Protocol은

앞선 Byte 손실 때문에 뒤의 응답도 영향을 받을 수 있다.

QUIC은 UDP 위에서 신뢰성, 암호화, 혼잡 제어와 여러 독립 Stream을 구현한다.

하나의 QUIC Stream에서 손실이 발생해도 다른 Stream의 Application Data 전달까지 TCP 연결 전체처럼 막지 않도록 설계되었다.

다만 QUIC도 손실된 Packet에 있던 해당 Stream Data를 복구해야 하며,

네트워크 혼잡과 재전송의 영향이 사라지는 것은 아니다.

UDP가 해결한 것이 아니라 UDP의 최소 기능 위에서 QUIC이 다른 신뢰성 모델을 구현한 것이다.

ㅁ 어떤 Application이 UDP를 선택할까?

UDP가 어울릴 수 있는 상황은 다음과 같다.

ㅇ 작은 질문과 짧은 응답

전통적인 DNS 질의처럼 작은 Request와 Response가 중심인 경우 연결 설정을 줄일 수 있다. 다만 DNS도 큰 응답과 Zone Transfer 등에서는 TCP를 사용한다.

ㅇ 최신 데이터의 시간이 중요한 실시간 통신

Voice와 Video에서 너무 늦게 도착한 오래된 Frame은 재생 가치가 낮을 수 있다. Application은 일부 손실을 허용하고 Jitter Buffer, 선택적 복구, Codec의 오류 은폐를 사용할 수 있다.

ㅇ Application이 독자적인 신뢰성 모델을 원하는 경우

QUIC은 UDP 위에서 Stream별 신뢰성, 연결 이동, 혼잡 제어를 구현한다.

ㅇ Multicast 또는 Broadcast가 필요한 경우

UDP는 IP Multicast와 Broadcast Datagram에 사용할 수 있다. TCP는 두 Endpoint 사이의 연결 기반 Unicast Protocol이다.

UDP 사용이 곧 Packet Loss를 무시한다는 뜻은 아니다.

Application이 자신의 목적에 맞는 손실 처리와 혼잡 제어를 책임진다는 뜻이다.

ㅁ 어떤 Application이 TCP를 선택할까?

TCP가 어울릴 수 있는 상황은 다음과 같다.

ㅇ 모든 Byte를 순서대로 받아야 하는 경우

파일 전송, 원격 터미널, 일반적인 Database 연결처럼 누락된 Byte를 그대로 허용하기 어려운 통신이다.

ㅇ 공통의 재전송과 혼잡 제어를 활용하려는 경우

Application마다 신뢰성과 네트워크 공정성을 새로 구현하지 않고 운영체제의 TCP Stack을 사용할 수 있다.

ㅇ Stream 기반 Protocol인 경우

HTTP/1.1, HTTP/2, TLS 기반의 많은 Application Protocol이 TCP Byte Stream 위에서 동작한다.

TCP를 선택해도 Application Timeout, 요청 재시도, 업무 중복 방지, 보안은 별도로 설계해야 한다.

Transport가 제공하는 신뢰성과 Application이 필요로 하는 신뢰성의 범위를 구분해야 한다.

ㅁ TCP와 UDP는 보안을 제공할까?

TCP의 연결과 ACK는 상대의 Application 신원을 인증하거나 내용을 암호화하지 않는다.

UDP의 Checksum도 공격자에 의한 변조를 막는 암호학적 보호가 아니다.

TCP/UDP가 제공하지 않는 것
├─ 기밀성
├─ 상대 신원 인증
└─ 암호학적 무결성

TCP 위에서는 TLS를, UDP Datagram 기반 Application에서는 DTLS를 사용할 수 있다.

QUIC은 TLS 1.3 Handshake를 통합해 보안 연결을 만든다.

Port 443을 사용하거나 TCP로 연결되었다는 사실만으로 Traffic이 안전하다고 판단할 수 없다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
독립된 봉투 한 장	UDP Datagram	Message Boundary가 있는 독립적인 전송 단위
이어 붙인 긴 종이 두루마리	TCP Byte Stream	Message Boundary 없이 순서 있는 Byte의 흐름
봉투 번호와 수령 확인	Sequence Number / ACK	Byte 위치와 수신 범위를 추적하는 TCP 정보
사라진 내용을 다시 발송	Retransmission	손실로 판단한 Data를 다시 보내는 동작
받는 창구의 남은 공간 안내	Flow Control	Receiver Buffer에 맞춰 전송량을 조절
도로 혼잡에 맞춘 발송량 조절	Congestion Control	Network 상태에 맞춰 In-flight Data를 조절
앞의 종이가 빠져 뒤도 읽지 못함	Head-of-Line Blocking	손실된 Byte 복구 전 뒤의 Stream 전달이 지연
필요한 배송 규칙을 이용자가 직접 추가	Application-Level Reliability	UDP 위에서 ACK·재전송 등을 Application이 구현

TCP와 UDP의 기본 차이는 다음처럼 정리할 수 있다.

항목	TCP	UDP
통신 모델	Connection-oriented Byte Stream	Connectionless Datagram
Message Boundary	보존하지 않음	보존
순서 보장	Byte 순서 제공	Protocol이 제공하지 않음
손실 복구	ACK와 재전송 제공	Protocol이 제공하지 않음
Flow/Congestion Control	제공	Application에 맡김
기본 Header	최소 20바이트	8바이트
Multicast/Broadcast	지원하지 않음	가능

ㅁ 직접 Header와 전달 단위를 관찰해 보기

Linux에서 TCP와 UDP Socket을 구분해 본다.

ss -tn
ss -uan

Packet Capture에서 두 Protocol의 Header를 비교할 수 있다.

sudo tcpdump -n -vv -i eth0 'tcp or udp'

특정 Port만 보고 싶다면 다음처럼 Filter를 좁힌다.

sudo tcpdump -n -vv -i eth0 'tcp port 8080 or udp port 8081'

TCP 출력에서는 다음 항목을 찾아본다.

Flags, Sequence Number, Acknowledgment, Window, Options

UDP 출력에서는 다음 항목을 비교한다.

Source Port, Destination Port, Length, Checksum

개인 개발 환경에서 nc로 UDP Datagram을 주고받을 수 있다.

구현마다 Listen 옵션 문법이 다를 수 있다.

수신 Terminal:

nc -u -l 8081

송신 Terminal:

nc -u 127.0.0.1 8081

UDP는 TCP처럼 Handshake로 연결 상태를 만들지 않는다는 점을 ss -uan과 Packet Capture에서 확인한다.

운영체제 Socket API에서 connect한 UDP Socket은 Peer가 표시될 수 있지만 TCP Handshake가 수행되었다는 뜻은 아니다.

Loopback Interface를 관찰할 때 Linux에서는 보통 lo, macOS에서는 보통 lo0를 사용한다.

실제 Interface 이름은 시스템에서 확인한다.

ㅁ 핵심 정리

IP는 Packet의 도착, 순서, 중복 없는 전달을 End-to-End로 보장하지 않는 Best-Effort Protocol이다.
UDP는 8바이트 Header로 독립된 Datagram을 전달하고 Message Boundary를 보존한다.
UDP Protocol은 연결 설정, 순서 정렬, ACK, 재전송, Flow/Congestion Control을 기본 제공하지 않는다.
TCP는 연결 상태를 관리하며 순서 있는 신뢰 가능한 Byte Stream을 제공한다.
TCP는 Byte 순서는 보존하지만 Application Message Boundary는 보존하지 않는다.
TCP ACK는 상대 Application의 업무 처리 완료나 Exactly-Once 처리를 보장하지 않는다.
UDP라고 항상 빠르고 TCP라고 항상 느린 것은 아니며 필요한 기능과 환경을 함께 비교해야 한다.
TCP Stream은 손실된 Byte 때문에 뒤의 Data 전달도 지연되는 HOL Blocking을 겪을 수 있다.
QUIC은 UDP 위에서 필요한 신뢰성, 보안, 혼잡 제어와 독립 Stream을 구현한다.
TCP와 UDP의 Checksum은 암호화나 신원 인증을 제공하지 않는다.

핵심 용어: Best-Effort, TCP, UDP, Byte Stream, Datagram, Message Boundary, Sequence Number, Acknowledgment, Retransmission, Reliability, Ordering, Flow Control, Congestion Control, Head-of-Line Blocking, QUIC, TLS, DTLS

TCP와 UDP의 차이는 안전과 속도의 단순한 선택이 아니다.
공통 신뢰성을 Transport가 맡을지, 목적에 맞는 규칙을 Application이 선택할지의 차이다.

ㅁ 다음 이야기

TCP는 Byte Stream의 순서와 손실 복구를 관리한다.

하지만 데이터를 보내기 전에 양쪽이 서로 보내고 받을 준비가 되었는지, Sequence Number를 어디에서 시작할지 합의해야 한다.

왜 두 번이 아니라 세 번의 메시지가 필요할까?

다음 글에서는 「대화를 시작하기 전에 왜 세 번이나 인사할까?」라는 질문을 통해

TCP State, SYN, SYN-ACK, ACK, Initial Sequence Number와 3-Way Handshake를 살펴본다.

[Network] 14. 한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?

기록하는 백엔드개발자 — Sun, 19 Jul 2026 20:14:09 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 4. 이름을 주소로 바꾸고 대화를 시작하기

ㅁ 들어가며

DNS를 통해 Server의 IP 주소를 알아냈다.

example.com → Server IP Address

IP 주소를 알면 패킷을 어느 컴퓨터까지 보낼지는 정할 수 있다.

하지만 한 컴퓨터에서는 여러 프로그램이 동시에 네트워크를 사용한다.

Server 한 대
├─ Web Server
├─ SSH Server
├─ DNS Server
└─ Database Server

패킷이 Server의 Network Interface에 도착한 뒤 운영체제는 데이터를 어느 프로그램에 전달해야 할까?

IP 주소만으로는 컴퓨터 안의 수신 프로그램을 구분할 수 없다.

그래서 TCP와 UDP Header에는 Port Number가 있다.

IP 주소가 건물을 찾는 주소라면 Port Number는 그 안에서 서비스를 접수하는 창구 번호다.

그러나 Port를 프로그램에 붙은 고정 번호라고만 이해하면

같은 Web Server가 수천 명의 Client 연결을 동시에 처리하는 이유를 설명할 수 없다.

이번 글에서는 Transport Layer, Port Number, Socket, Listen, Ephemeral Port, 4-Tuple, 5-Tuple을 통해

운영체제가 여러 프로그램과 연결을 어떻게 구분하는지 살펴본다.

ㅁ IP 주소가 건물이라면 Port는 창구다

하나의 우체국 건물 안에 여러 창구가 있다고 생각해 보자.

우체국 주소: 서울시 어느 거리 10

1번 창구: 일반 우편
2번 창구: 국제 우편
3번 창구: 소포
4번 창구: 등기

건물 주소만 적으면 우편물은 우체국까지 도착할 수 있다.

그러나 어느 업무 창구에서 처리해야 할지는 알 수 없다.

네트워크에서도 IP Layer는 패킷을 목적지 Host까지 전달한다.

그 안의 TCP 또는 UDP는 Destination Port를 보고 해당 데이터를 기다리는 Socket으로 전달한다.

이 과정을 Demultiplexing이라고 한다.

반대로 여러 Application의 데이터를 Transport Layer가 Port 정보와 함께

네트워크로 내보내는 것을 Multiplexing 관점으로 볼 수 있다.

송신 Host
여러 Application → Socket/Port → TCP·UDP → IP

수신 Host
IP → TCP·UDP → Destination Port/Socket → 해당 Application

Port는 네트워크 패킷이 Host 안의 올바른 통신 끝점으로 전달되게 하는 식별자다.

ㅁ TCP Port와 UDP Port는 같은 공간일까?

Port Number는 TCP와 UDP Header에 각각 존재하는 16비트 값이다.

표현 가능한 범위는 다음과 같다.

0 ~ 65535

TCP와 UDP는 서로 다른 Transport Protocol이므로 Port 공간도 별도로 구분된다.

따라서 한 Host에서 다음 두 Socket이 동시에 존재할 수 있다.

TCP Port 53
UDP Port 53

DNS Server가 UDP 53과 TCP 53을 모두 사용하는 것이 대표적인 예다.

Firewall Rule에서도 Protocol을 생략하고 “Port 53을 허용한다”고만 생각하면 한쪽만 허용하거나 필요 이상의 트래픽을 열 수 있다.

UDP/53과 TCP/53은 서로 다른 Endpoint다.

Port Number만으로 통신을 완전히 식별할 수 없는 첫 번째 이유다.

ㅁ Port 번호는 누가 정할까?

IANA의 Service Name and Transport Protocol Port Number Registry에서는 Port 범위를 다음과 같이 구분한다.

범위	이름	일반적인 용도
0~1023	System Ports 또는 Well-Known Ports	널리 알려진 표준 Service
1024~49151	User Ports 또는 Registered Ports	등록된 Application과 일반 Service
49152~65535	Dynamic/Private Ports	동적으로 선택하거나 사적으로 사용

대표적으로 잘 알려진 Port는 다음과 같다.

Service	Transport	기본 Port
SSH	TCP	22
DNS	UDP/TCP	53
HTTP	TCP	80
HTTPS (HTTP/1.1·HTTP/2)	TCP	443
HTTP/3 (QUIC)	UDP	443

하지만 Port Number가 그 Application을 강제로 보장하는 것은 아니다.

Web Server를 TCP 8080에서 실행할 수 있다.
TCP 443에서 HTTPS가 아닌 임의의 Protocol을 실행할 수도 있다.
아무 Process도 TCP 80에서 기다리지 않을 수 있다.

Port는 관례와 설정으로 Service에 연결된다.

TCP 443이 열려 있음 ≠ 반드시 올바른 HTTPS Service

실제 Protocol이 맞는지는 Application Layer의 대화까지 확인해야 한다.

ㅁ URL에 Port를 적지 않아도 되는 이유는 무엇일까?

브라우저에 다음 주소를 입력한다.

https://example.com/

URL에 Port가 보이지 않지만 https Scheme에는 기본 Port 443이 정의되어 있다.

HTTP/1.1과 HTTP/2는 일반적으로 TCP 443을 사용하고, HTTP/3는 QUIC을 통해 UDP 443을 사용한다.

http://example.com/  → 기본 Port 80
https://example.com/ → 기본 Port 443

다른 Port를 사용하려면 URL에 명시할 수 있다.

https://example.com:8443/

DNS는 example.com의 IP 주소를 찾는다.

일반적인 A/AAAA 조회가 Service Port까지 알려 주는 것은 아니다.

DNS   : 어느 Host IP로 갈 것인가?
Scheme와 설정: 어느 Transport와 Port를 사용할 것인가?

Service Discovery를 위해 SRV, HTTPS 같은 DNS Record Type을 활용하는 경우도 있지만

일반적인 URL 연결의 기본 Port 선택과는 구분해서 이해해야 한다.

ㅁ Server는 창구를 어떻게 열까?

Server Application이 TCP 8080에서 Client를 기다리는 과정을 단순화해 보자.

1. Socket을 만든다.
2. Local IP Address와 Port 8080에 Bind한다.
3. TCP Socket을 Listen 상태로 만든다.
4. Client의 연결 요청을 Accept한다.

ㅇ Socket을 만든다

Application은 운영체제에 사용할 Address Family와 Transport Protocol에 맞는 Socket을 요청한다.

Socket은 Application이 Network Stack과 데이터를 주고받는 운영체제 객체 또는 통신 끝점으로 이해할 수 있다.

ㅇ Bind한다

어느 Local Address와 Port에서 데이터를 받을지 연결한다.

127.0.0.1:8080
192.168.10.20:8080
0.0.0.0:8080

이 세 설정은 의미가 다르다.

ㅇ Listen한다

TCP Server는 해당 Socket을 Client의 연결 요청을 받을 수 있는 Listening 상태로 둔다.

Port가 방화벽에서 허용되어 있어도 Listen하는 Socket이 없다면 Application은 연결을 받을 수 없다.

ㅁ 127.0.0.1과 0.0.0.0은 무엇이 다를까?

Server가 어느 Local Address에 Bind했는지는 외부 접근 가능성에 영향을 준다.

ㅇ 127.0.0.1:8080

IPv4 Loopback Address에만 Bind한다.

같은 Host 안에서는 접속할 수 있지만 다른 컴퓨터에서 Server의 LAN IP로 접속할 수 없다.

같은 Host → 127.0.0.1:8080 가능
외부 Host → 192.168.10.20:8080 불가

ㅇ 192.168.10.20:8080

특정 Interface의 주소에 Bind한다.

그 주소로 들어오는 연결은 받을 수 있지만 다른 Local IP로 들어오는 연결은 별개다.

ㅇ 0.0.0.0:8080

일반적으로 Host의 모든 IPv4 Local Address에서 Port 8080을 받는 Wildcard Bind를 뜻한다.

IPv6의 :: Wildcard Bind와 IPv4 동시 처리 관계는 운영체제와 IPV6_V6ONLY 설정에 따라 다를 수 있다.

“Process가 실행 중이다”라는 사실만으로 외부에서 접속할 수 있다고 판단하면 안 된다.

다음 세 조건을 나누어 확인해야 한다.

Process가 실행 중인가?
원하는 IP와 Port에 Listen하는가?
경로와 Firewall이 외부 연결을 허용하는가?

ㅁ Client도 Port가 필요할까?

Client는 Server의 Destination Port를 알고 접속한다.

Server: 203.0.113.20:443

그렇다면 Server가 응답을 돌려줄 Client의 창구도 필요하다.

Client 운영체제는 연결을 시작할 때 사용 가능한 임시 Source Port를 선택한다.

이를 Ephemeral Port라고 한다.

Client: 192.0.2.10:53124
Server: 203.0.113.20:443

요청 Segment의 주소는 다음과 같다.

Source Port      : 53124
Destination Port : 443

Server의 응답에서는 방향이 바뀐다.

Source Port      : 443
Destination Port : 53124

Client Port 덕분에 운영체제는 돌아온 데이터를 연결을 시작한 Browser Socket에 전달할 수 있다.

Ephemeral Port의 실제 할당 범위와 선택 알고리즘은 운영체제와 설정에 따라 다르다.

IANA Dynamic/Private 범위가 49152~65535라고 해서 모든 운영체제가 반드시 그 범위만 사용하는 것은 아니다.

Linux에서는 다음 값으로 로컬 Ephemeral Port 범위를 확인할 수 있다.

sysctl net.ipv4.ip_local_port_range

ㅁ Server Port 하나로 여러 Client를 받을 수 있을까?

수천 명의 Client가 모두 같은 Web Server의 TCP 443에 연결할 수 있다.

Port 443 하나뿐인데 운영체제는 각 연결을 어떻게 구분할까?

TCP 연결은 다음 네 값을 함께 사용해 구분할 수 있다.

Source IP
Source Port
Destination IP
Destination Port

이를 4-Tuple이라고 한다.

세 Client가 같은 Server에 접속하는 예를 보자.

192.0.2.10:51001 → 203.0.113.20:443
192.0.2.11:51002 → 203.0.113.20:443
192.0.2.12:51003 → 203.0.113.20:443

Destination IP와 Port는 같지만 Source IP 또는 Source Port가 다르므로 서로 다른 연결이다.

Transport Protocol까지 포함하면 흔히 5-Tuple이라고 한다.

Protocol
Source IP
Source Port
Destination IP
Destination Port

TCP, 192.0.2.10, 51001, 203.0.113.20, 443
TCP, 192.0.2.11, 51002, 203.0.113.20, 443

Firewall, NAT, Load Balancer도 Flow를 구분할 때 이 5-Tuple을 중요한 기준으로 사용한다.

하나의 Listening Port가 하나의 연결만 의미하지 않는다.

Listening Socket은 새로운 연결 요청을 받는 창구이고,

Accept된 각 TCP 연결은 서로 다른 4-Tuple을 가진 연결 Socket으로 관리된다.

ㅁ Listening Socket과 연결 Socket은 어떻게 다를까?

TCP Server의 상태를 단순화하면 두 종류의 Socket을 볼 수 있다.

ㅇ Listening Socket

Local Address : 0.0.0.0:443
State         : LISTEN

새로운 Client의 연결 요청을 받기 위한 Socket이다. 아직 특정 Remote IP와 Port 하나에 연결되지 않았다.

ㅇ Established Socket

Local  : 203.0.113.20:443
Remote : 192.0.2.10:51001
State  : ESTABLISHED

특정 Client와 연결된 통신 Socket이다.

다른 Client가 접속하면 같은 Local Port 443을 사용하면서 Remote Endpoint가 다른 Established Socket이 추가된다.

LISTEN 0.0.0.0:443
├─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.10:51001
├─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.11:51002
└─ ESTABLISHED 203.0.113.20:443 ↔ 192.0.2.12:51003

이 구조가 Server Port 하나로 많은 Client 연결을 동시에 처리할 수 있게 한다.

ㅁ Port는 Process ID일까?

Port Number와 Process ID는 다른 개념이다.

하나의 Process가 여러 Port에 Listen할 수 있다.
Process가 재시작되면 PID가 바뀌어도 같은 Port에 다시 Bind할 수 있다.
하나의 Process가 여러 Socket과 연결을 가질 수 있다.
운영체제 기능과 설정에 따라 여러 Worker가 같은 Port를 공유할 수도 있다.

운영체제는 Socket과 Process의 관계를 관리한다.

Port는 Network Stack이 데이터를 전달할 Endpoint를 찾는 정보이지 운영체제 Process 자체의 고유 번호가 아니다.

Port가 사용 중이라는 오류가 발생하면 같은 Local Address, Port, Protocol 조합에 이미 충돌하는 Bind가 있는지 확인해야 한다.

SO_REUSEADDR, SO_REUSEPORT, Wildcard Bind 같은 옵션은

Bind 충돌과 공유 방식에 영향을 주지만 운영체제마다 세부 동작이 다를 수 있다.

ㅁ TCP와 UDP는 Socket을 같은 방식으로 구분할까?

TCP는 연결을 설정하고 각 연결의 상태를 관리한다.

Listening Socket에서 Accept된 연결은 4-Tuple로 구분된다.

UDP는 TCP와 같은 Handshake와 Connection State를 기본적으로 제공하지 않는다.

하나의 UDP Socket이 여러 Remote Endpoint에서 오는 Datagram을 받을 수 있다.

Application은 수신 API가 제공하는 Source IP와 Source Port를 보고 누구에게 응답할지 결정할 수 있다.

UDP Socket도 운영체제 API에서 connect할 수 있지만 이는 TCP Handshake를 만든다는 뜻이 아니다.

기본 Remote Endpoint를 지정하고 다른 Source의 Datagram 처리나 오류 전달 방식을 제한하는 로컬 Socket 설정에 가깝다.

TCP Socket : 연결 상태와 Byte Stream을 관리
UDP Socket : 독립적인 Datagram 송수신 Endpoint

Port Number는 두 Protocol에 모두 있지만 통신 의미는 다르다.

ㅁ Port가 닫혀 있으면 어떤 응답이 올까?

Host까지 IP Packet이 정상적으로 도착했지만 Destination Port에서 기다리는 Application이 없을 수 있다.

ㅇ TCP Port에 Listener가 없음

운영체제는 일반적으로 TCP RST로 연결을 거절할 수 있다.

Client에서는 다음과 같은 즉시 오류가 보일 수 있다.

Connection refused

이는 Server Host까지의 경로가 살아 있고 해당 Port에 Listener가 없다는 강한 단서가 될 수 있다.

ㅇ Firewall이 Packet을 조용히 Drop

Client의 SYN이 폐기되고 오류 응답도 없다면 재전송 뒤 Timeout이 발생할 수 있다.

Connection timed out

ㅇ UDP Port에 Listener가 없음

운영체제는 ICMP Destination Unreachable, Port Unreachable을 보낼 수 있다.

하지만 ICMP 정책과 Application API에 따라 Client가 이를 바로 확인하지 못할 수 있다.

오류 메시지는 환경과 정책에 따라 달라질 수 있다.

Refused  : Host 응답은 왔지만 TCP Listener가 없을 가능성
Timeout  : 경로, Firewall, Server 무응답 등 여러 가능성

Port 상태만으로 전체 Application의 정상 동작까지 보장되지는 않는다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
우체국 건물 주소	IP Address	Network에서 Host 또는 Interface를 식별하는 주소
건물 안 업무 창구 번호	Port Number	Host 안의 Transport Endpoint를 구분하는 16비트 값
창구를 열고 기다림	Bind / Listen	Local Address와 Port에서 연결 요청을 받을 준비
사용자가 잠시 배정받은 답장 창구	Ephemeral Port	Client가 연결 Source에 동적으로 사용하는 Port
창구와 Application을 잇는 접점	Socket	Application과 Network Stack 사이의 통신 Endpoint
여러 창구의 우편을 한 운송망에 실음	Multiplexing	여러 Application Traffic을 Transport/IP로 전달
도착 우편을 알맞은 창구로 분류	Demultiplexing	Header 정보를 보고 올바른 Socket에 전달
보내는 곳과 받는 곳의 네 주소	4-Tuple	Source/Destination IP와 Port로 TCP 연결 구분
운송 방식까지 포함한 주소표	5-Tuple	Protocol과 Source/Destination IP·Port로 Flow 구분

Application 연결 준비의 흐름은 다음처럼 정리할 수 있다.

1. DNS로 Server IP Address를 찾는다.
2. Scheme과 Application 설정으로 Transport Protocol과 Destination Port를 정한다.
3. Client OS가 Source IP와 Ephemeral Port를 선택한다.
4. Server의 Listening Socket에 연결을 시도한다.
5. 운영체제가 5-Tuple을 기준으로 Traffic을 해당 Socket에 전달한다.

ㅁ 직접 Port와 Socket을 관찰해 보기

Linux에서 Listening TCP Socket을 확인한다.

ss -lnt

주요 옵션은 다음과 같다.

-l : Listening Socket
-n : Service Name 대신 숫자로 표시
-t : TCP

UDP Listening Endpoint를 확인한다.

ss -lnu

Process 정보까지 보려면 권한이 필요할 수 있다.

sudo ss -lntup

현재 TCP 연결의 Local과 Peer Address를 본다.

ss -tn

macOS에서는 lsof로 Listening TCP Socket을 확인할 수 있다.

lsof -nP -iTCP -sTCP:LISTEN

간단한 TCP Listener를 개인 환경에서 열어 볼 수 있다. nc 구현에 따라 옵션 문법이 다를 수 있다.

첫 번째 Terminal:

nc -l 8080

두 번째 Terminal:

nc -v 127.0.0.1 8080

연결한 상태에서 ss -tn 또는 lsof -nP -iTCP:8080을 실행해 다음을 확인한다.

Server의 Listening Port 8080
Client가 선택한 Ephemeral Port
Local Address와 Peer Address가 뒤바뀐 양쪽 Socket

TCP 1024 미만의 System Port에 Bind하려면 운영체제에서 높은 권한이 필요할 수 있다.

관찰 실습에는 일반 사용자로 열 수 있는 8080 같은 높은 Port를 사용한다.

공유 Server에서 임의의 Listener를 열면 정책 위반이나 Port 충돌이 생길 수 있으므로 개인 개발 환경에서만 수행한다.

ㅁ 핵심 정리

IP Address만으로는 Host 안의 여러 Application을 구분할 수 없어 Transport Port가 필요하다.
TCP와 UDP Port는 각각 16비트이며 Protocol별로 별도의 Endpoint 공간을 갖는다.
Port 범위는 System 0~~1023, User 1024~~49151, Dynamic/Private 49152~65535로 등록상 구분된다.
Well-Known Port는 관례이며 그 Port에서 실제로 어떤 Application Protocol이 동작하는지 보장하지 않는다.
Server는 Local Address와 Port에 Bind하고 TCP에서는 Listen해 연결 요청을 기다린다.
Loopback, 특정 IP, Wildcard Address 중 어디에 Bind했는지에 따라 접근 범위가 달라진다.
Client는 응답을 받을 Source Endpoint에 Ephemeral Port를 사용한다.
같은 Server Port의 여러 TCP 연결은 Source/Destination IP와 Port의 4-Tuple로 구분된다.
Protocol까지 포함한 5-Tuple은 Firewall, NAT, Load Balancer의 Flow 구분에도 사용된다.
Port는 Process ID가 아니며 Socket과 Process의 관계는 운영체제가 관리한다.
TCP Refused와 Timeout은 실패한 단계가 다를 수 있다.

핵심 용어: Transport Layer, Port Number, TCP Port, UDP Port, Well-Known Port, Registered Port, Dynamic/Private Port, Ephemeral Port, Socket, Bind, Listen, Accept, Loopback, Wildcard Address, Multiplexing, Demultiplexing, 4-Tuple, 5-Tuple, LISTEN, ESTABLISHED, RST

Port는 프로그램의 이름표가 아니다. 하나의 Host에서 수많은 통신 흐름을 올바른 Socket으로 나누기 위한 Transport Layer의 창구 번호다.

ㅁ 다음 이야기

IP Address와 Port Number를 정하면 어느 Host의 어떤 Application과 통신할지 표현할 수 있다.

이제 데이터를 어떤 규칙으로 보낼지 선택해야 한다.

모든 메시지에 연결 준비, 순서 확인, 수령 확인과 재전송이 필요할까? 아니면 일부 메시지는 빠르게 보내고 Application이 필요한 신뢰성을 직접 결정하는 편이 나을까?

다음 글에서는 「모든 편지에 수령 확인이 필요할까?」라는 질문을 통해 TCP와 UDP의 Header, Byte Stream과 Datagram, Reliability, Ordering, Overhead를 비교한다.

[Network] 13. 우리는 왜 숫자 대신 이름으로 접속할까?

기록하는 백엔드개발자 — Sun, 19 Jul 2026 20:13:41 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 4. 이름을 주소로 바꾸고 대화를 시작하기

ㅁ 들어가며

라우터는 Destination IP를 보고 패킷의 다음 길을 선택한다.

그런데 사용자는 웹사이트에 접속할 때 IP 주소를 직접 입력하지 않는다.

https://example.com

사람은 example.com이라는 이름을 기억한다.

실제 IP Packet을 보내려는 운영체제는 목적지 IP 주소가 필요하다.

사람이 아는 정보 : example.com
네트워크가 필요한 정보 : IPv4 또는 IPv6 Address

이름과 주소 사이에는 누군가 답해야 할 질문이 있다.

example.com은 어느 IP 주소에 있는가?

이 질문을 전 세계에서 하나의 서버가 모두 처리한다면 그 서버의 장애와 부하가 인터넷 전체에 영향을 준다.

모든 이름을 한 파일에 저장해 배포해도 변경 사항을 빠르게 반영하기 어렵다.

DNS는 이름 공간을 계층적으로 나누고, 각 영역의 관리 권한을 위임하고, 반복되는 답은 일정 시간 캐시하는 방식으로 이 문제를 해결한다.

이번 글에서는

Stub Resolver, Recursive Resolver, Root Name Server, TLD Name Server, Authoritative Name Server를

거치는 흐름과 주요 DNS Record, Cache TTL, 그리고 이름 조회 실패가 어떤 모습으로 나타나는지 살펴본다.

ㅁ 인터넷 주소록은 한 권일까?

동네의 모든 집 주소를 한 사람이 관리할 수는 있다.

하지만 전 세계의 사람과 조직, 서비스 이름을 한 권의 주소록에 넣는다면 다음 문제가 생긴다.

새로운 이름을 등록할 때마다 중앙 관리자가 수정해야 한다.
모든 조회가 한 장소로 몰린다.
주소록 한 권이 고장 나면 누구도 이름을 찾지 못한다.
서로 다른 조직이 자신의 이름을 독립적으로 관리하기 어렵다.

DNS는 이름을 오른쪽에서 왼쪽으로 이어지는 계층으로 구성한다.

www.example.com.
│   │       │  └─ Root
│   │       └──── Top-Level Domain: com
│   └──────────── Domain: example
└──────────────── Host 또는 Service Label: www

마지막의 점은 DNS 계층의 Root를 나타낸다.

www.example.com.처럼 Root까지 모두 적은 이름을 FQDN(Fully Qualified Domain Name)이라고 한다.

일상에서는 마지막 점을 생략한 www.example.com을 주로 사용한다.

각 점 사이의 문자열을 Label이라고 한다.

상위 영역은 하위 영역의 모든 레코드를 직접 관리하는 대신 관리 권한을 위임할 수 있다.

Root는 com의 위치를 안내
com은 example.com의 권한 서버를 안내
example.com의 권한 서버가 www의 실제 Record를 답변

한 권의 주소록이 아니라 여러 관리자가 맡은 계층적인 주소 체계다.

ㅁ 애플리케이션은 누구에게 이름을 물을까?

브라우저가 www.example.com에 접속하려고 한다.

브라우저 또는 애플리케이션은 일반적으로 Root Server부터 직접 찾아가지 않는다. 운영체제의 이름 해석 기능을 호출한다.

호스트 안에서 애플리케이션의 요청을 받아 DNS 질의를 시작하는 구성 요소를 Stub Resolver라고 한다.

Stub Resolver는 시스템에 설정된 Recursive Resolver에게 질문한다.

Application
    ↓ 이름 해석 요청
Stub Resolver
    ↓ Recursive Query
Recursive Resolver

Recursive Resolver는 가정용 공유기, 인터넷 사업자, 회사 내부 DNS, 또는 공개 DNS 서비스일 수 있다. DHCP나 수동 설정을 통해 주소를 받을 수 있다.

Stub Resolver가 기대하는 것은 보통 다음과 같다.

필요한 곳에 대신 물어보고 최종 답이나 실패 결과를 돌려 달라.

그래서 Recursive라는 이름을 사용한다.

ㅁ Recursive Resolver는 먼저 기억을 확인한다

Resolver는 외부에 질문하기 전에 Cache를 확인한다.

www.example.com A Record가 Cache에 있는가?
├─ 있다 → 남은 TTL과 함께 즉시 응답
└─ 없다 → DNS 계층에 질의 시작

캐시된 답이 있으면 Root, TLD, Authoritative Server에 다시 질의할 필요가 없다.

이는 두 가지 효과를 만든다.

사용자에게 더 빠르게 답할 수 있다.
DNS 계층 서버의 반복 조회 부하를 줄인다.

DNS가 인터넷 규모로 확장될 수 있었던 중요한 이유는 계층 구조와 Cache가 함께 있기 때문이다.

Cache Miss라면 Resolver는 답을 찾기 위한 과정을 시작한다.

ㅁ Root Server는 모든 IP 주소를 알고 있을까?

Recursive Resolver가 www.example.com의 A Record를 찾는 흐름을 단순화해 보자.

ㅇ 1단계: Root Name Server에 묻는다

Resolver는 Root Name Server에 질문한다.

www.example.com의 A Record는 무엇인가?

Root Server는 보통 www.example.com의 IP 주소를 직접 답하지 않는다.

대신 .com을 담당하는 TLD Name Server의 위치를 안내한다.

나는 최종 답을 갖고 있지 않다.
com 영역은 이 Name Server들에게 물어보라.

이처럼 다음 권한 영역을 안내하는 답을 Referral이라고 한다.

ㅇ 2단계: TLD Name Server에 묻는다

Resolver는 .com TLD Name Server에 같은 질문을 한다.

TLD Server도 보통 www의 A Record를 직접 관리하지 않는다. 대신 example.com을 담당하는 Authoritative Name Server의 NS Record를 안내한다.

example.com은 이 Authoritative Name Server들에게 물어보라.

ㅇ 3단계: Authoritative Name Server에 묻는다

Resolver는 example.com의 권한 서버에 질문한다.

이 서버가 해당 Zone의 Record를 관리하고 있다면 최종 답을 제공한다.

www.example.com A <IPv4 Address>
TTL <seconds>

ㅇ 4단계: 답을 Cache하고 Stub Resolver에 돌려준다

Recursive Resolver는 받은 Record를 TTL 범위 안에서 Cache하고 Client에게 응답한다.

Stub → Recursive → Root → TLD → Authoritative
Stub ← Recursive ← 최종 답과 TTL

Root와 TLD는 모든 Host의 IP 주소를 저장하지 않는다.

다음 관리 영역을 찾을 수 있도록 위임 정보를 제공한다.

이 분산 위임 구조가 각 조직이 자신의 Domain을 독립적으로 관리하면서도 하나의 전역 이름 공간을 사용할 수 있게 한다.

ㅁ Recursive Query와 Iterative Query는 무엇이 다를까?

Stub Resolver는 Recursive Resolver에게 최종 답을 요청한다.

Recursive Query:
“대신 끝까지 찾아서 답을 달라.”

Recursive Resolver가 DNS 계층을 따라갈 때는 각 서버가 자신이 아는 최선의 정보나 다음 서버를 안내하는 방식의 질의를 사용한다.

Iterative Resolution:
Root          → com Server를 안내
com Server    → example.com Server를 안내
Authoritative → 최종 Record 응답

실제 Resolver 구현은 위임 정보와 NS 주소도 Cache하고,

여러 Authoritative Server 중 응답 가능한 서버를 선택하며,

DNSSEC 검증 같은 추가 작업을 수행할 수 있다.

입문 단계에서 핵심 차이는 다음과 같다.

Stub은 Recursive Resolver에게 최종 답을 맡긴다.
Recursive Resolver는 여러 DNS Server의 안내를 따라 답을 찾는다.

ㅁ 이름 하나에는 어떤 Record가 있을까?

DNS는 이름을 IP 주소로만 바꾸는 시스템이 아니다.

이름에 관한 여러 종류의 정보를 Resource Record(RR)로 저장한다.

Record Type	역할
A	이름을 IPv4 주소에 연결
AAAA	이름을 IPv6 주소에 연결
CNAME	한 이름을 다른 Canonical Name의 별칭으로 연결
NS	Zone의 Authoritative Name Server를 지정
MX	Domain의 Mail Exchanger를 지정
TXT	정책 검증 등 다양한 Text 정보를 저장
SOA	Zone의 시작과 관리·갱신 관련 기본 정보를 표현
PTR	IP 주소에 대응하는 이름을 찾는 Reverse DNS에 사용

브라우저가 접속할 주소를 찾을 때 A와 AAAA Record를 함께 질의할 수 있다.

CNAME을 만나면 별칭이 가리키는 이름의 A 또는 AAAA Record를 다시 찾아야 할 수 있다.

www.example.com CNAME service.example.net
service.example.net A <IPv4 Address>

MX Record는 Mail Server의 이름을 알려 주며,

그 이름에 대한 A 또는 AAAA 조회가 추가로 필요할 수 있다.

Record Type마다 질문과 답의 의미가 다르다.

“DNS가 된다”는 표현보다 어떤 이름의 어떤 Record를 조회했는가를 명확히 하는 것이 좋다.

ㅁ DNS TTL은 패킷의 TTL과 같은 것일까?

DNS Record에도 TTL(Time To Live)이 있다.

이름은 IPv4 Header의 TTL과 같지만 목적은 다르다.

구분	IP TTL	DNS TTL
위치	IPv4 Header	DNS Resource Record
단위·동작	Router Hop마다 감소	Cache가 답을 보관할 수 있는 시간(초)
목적	Packet의 무한 Routing Loop 제한	DNS 답의 재사용 기간 제한
만료 결과	Packet 폐기와 ICMP 가능	다음 조회에서 새 DNS 질의 필요

DNS TTL이 300이면 Resolver는 일반적으로 해당 Record를 최대 300초 동안 재사용할 수 있다.

Cache에서 응답할 때는 남은 TTL이 줄어든 모습으로 보일 수 있다.

권한 서버 응답 TTL : 300
100초 뒤 Cache 응답: 남은 TTL 약 200
TTL 만료 후         : 권한 계층에 다시 질의

DNS TTL은 변경 사항이 전 세계에 “전파되는 속도”를 직접 지시하는 값이라기보다

각 Cache가 기존 답을 언제까지 재사용할 수 있는지를 제한하는 값이다.

ㅁ 서버 주소를 바꿨는데 왜 예전 주소로 갈까?

서비스 운영자가 A Record를 새 IP 주소로 변경했다고 하자.

이전 A Record: Old IP, TTL 3600
새 A Record  : New IP

권한 서버에서는 새 주소를 답하지만 변경 전에 Old IP를 받은 Resolver는 남은

TTL 동안 기존 답을 사용할 수 있다.

다음과 같은 여러 Cache 계층도 영향을 줄 수 있다.

애플리케이션 또는 브라우저 Cache
운영체제 Resolver Cache
로컬 네트워크의 DNS Forwarder
Recursive Resolver Cache

그래서 같은 시간에도 사용자가 사용하는 Resolver와 기존 Cache 시점에 따라 서로 다른 IP 주소를 받을 수 있다.

주소 변경을 계획할 때는 일반적으로 다음 흐름을 고려한다.

1. 변경 전 충분한 시간에 TTL을 낮춘다.
2. 기존의 긴 TTL Cache가 만료될 시간을 기다린다.
3. A/AAAA Record를 새 주소로 변경한다.
4. 이전 주소도 전환 기간 동안 요청을 처리할 수 있게 유지한다.
5. 안정화 후 TTL을 운영 값으로 조정한다.

이미 Cache된 답의 TTL을 권한 서버에서 나중에 낮춰도 기존 Cache의 남은 시간을 즉시 줄일 수는 없다.

DNS 변경은 Record 한 줄을 수정하는 순간보다 Cache에 남아 있는 이전 답이 사라지는 기간까지 포함해 계획해야 한다.

ㅁ 없는 이름도 Cache할까?

Resolver는 성공한 답만 Cache하는 것이 아니다.

존재하지 않는 이름이라는 답도 일정 시간 Cache할 수 있다. 이를 Negative Caching이라고 한다.

예를 들어 잘못된 이름을 조회해 NXDOMAIN을 받은 직후 Record를 생성해도

일부 Resolver는 이전의 부정 응답을 잠시 재사용할 수 있다.

Negative Cache 기간은 Zone의 SOA 정보와 Resolver 정책 등의 영향을 받는다.

Positive Cache : “이 이름의 A Record는 이 주소다.”
Negative Cache : “이 이름은 존재하지 않는다.”

새 Record를 만들었는데도 일부 환경에서 NXDOMAIN이 계속 보인다면 성공 응답 Cache뿐 아니라 Negative Cache도 확인해야 한다.

ㅁ 주소가 여러 개면 어느 서버로 갈까?

하나의 이름에 여러 A 또는 AAAA Record가 있을 수 있다.

service.example.com A 192.0.2.10
service.example.com A 192.0.2.20

DNS Server와 Resolver는 답의 순서를 바꾸거나 여러 주소를 함께 전달할 수 있다.

Client는 자신의 주소 선택과 연결 로직에 따라 하나를 사용한다.

이를 단순한 부하 분산에 활용할 수 있지만 DNS Record가 있다는 사실이 Server의 상태를 자동으로 보장하지는 않는다.

두 주소 중 하나의 Server가 죽었는데 DNS 답에 계속 포함되어 있으면 사용자에게 다음과 같이 보일 수 있다.

어떤 연결은 빠르게 성공
어떤 연결은 Timeout 후 다른 주소로 시도
환경에 따라 일부 요청은 그대로 실패

Client의 재시도 방식, DNS 기반 Health Check, Load Balancer 구성에 따라 결과는 달라진다.

“DNS에 IP가 여러 개 있으니 자동으로 장애 조치된다”고 가정하면 안 된다.

ㅁ DNS가 실패했다는 말은 무엇을 뜻할까?

이름 해석 실패도 여러 상태로 나뉜다.

ㅇ NXDOMAIN

질의한 Domain Name이 존재하지 않는다는 권한 있는 부정 응답이다.

오타, Record 생성 전, 잘못된 Search Domain 등이 원인일 수 있다.

ㅇ NOERROR지만 원하는 Answer가 없음

이름은 존재하지만 요청한 Record Type의 데이터가 없을 수 있다. 이를 흔히 NODATA 상황으로 설명한다.

예를 들어 이름에는 A Record가 있지만 AAAA Record가 없을 수 있다.

ㅇ SERVFAIL

Resolver가 질의를 처리했지만 정상적인 답을 만들지 못했다.

권한 서버 실패, DNSSEC 검증 실패, 위임 문제 등 여러 원인이 있을 수 있다.

ㅇ Timeout

정해진 시간 안에 DNS 응답을 받지 못했다.

Resolver까지의 경로, UDP/TCP 53 정책, 서버 과부하, Packet Loss 등을 확인해야 한다.

ㅇ REFUSED

DNS Server가 정책상 해당 질의를 처리하지 않겠다고 응답할 수 있다.

NXDOMAIN : 이름이 없다는 답을 받음
NODATA   : 이름은 있지만 요청 Type의 답이 없음
SERVFAIL : 서버가 정상 답을 만들지 못함
Timeout  : 응답 자체를 받지 못함
REFUSED  : 정책상 질의를 거부함

모두 애플리케이션에서는 “이름 해석 실패”로 보일 수 있지만 조사할 계층은 다르다.

ㅁ DNS는 UDP만 사용할까?

전통적인 DNS 질의는 주로 UDP Port 53을 사용한다.

UDP는 연결 설정 없이 질문과 답을 주고받을 수 있어 작은 DNS 메시지에 효율적이다.

그러나 DNS는 TCP Port 53도 사용한다.

UDP 응답이 잘려 TC(Truncated) Flag가 설정되면 Client가 TCP로 다시 질의할 수 있다.
큰 DNSSEC 응답 등에서 TCP가 필요할 수 있다.
Zone Transfer는 일반적으로 TCP를 사용한다.
Resolver와 Server 구현은 필요에 따라 TCP를 직접 사용할 수 있다.

EDNS를 사용하면 UDP에서 더 큰 메시지 크기를 협상할 수 있지만 경로 MTU와 Fragment 처리 문제도 고려해야 한다.

따라서 Firewall에서 UDP 53만 허용하고 TCP 53을 모두 차단하면 작은 질의는 되지만 특정 큰 응답만 실패하는 장애가 생길 수 있다.

ㅁ DoH와 DoT는 무엇을 바꿀까?

전통적인 DNS는 질의 이름이 네트워크에서 평문으로 보일 수 있다.

암호화된 Resolver 전송 방식으로 다음 기술을 사용할 수 있다.

DoT(DNS over TLS): DNS 메시지를 TLS로 보호하며 일반적으로 전용 Port 853 사용
DoH(DNS over HTTPS): DNS 메시지를 HTTPS 위에서 전달

DoH와 DoT는 Client와 선택한 Resolver 사이의 DNS 전송을 암호화한다.

반면 DNSSEC은 DNS 데이터가 권한 있는 출처에서 왔고 중간에 변조되지 않았는지 검증하기 위한 서명 체계다.

DoH / DoT : DNS 질의 전송의 기밀성과 보호
DNSSEC    : DNS 데이터의 출처 인증과 무결성 검증

DNSSEC이 질의 내용을 암호화하는 것은 아니며,

DoH/DoT가 모든 DNS Record의 권한 체인을 자동으로 검증한다는 뜻도 아니다.

서로 다른 문제를 해결한다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
사용자가 주소 찾기를 요청하는 창구	Stub Resolver	애플리케이션의 이름 해석 요청을 DNS Resolver로 전달
여러 주소록을 대신 찾아보는 안내소	Recursive Resolver	Cache를 확인하고 필요한 DNS 계층 질의를 수행
최상위 분류 안내	Root Name Server	TLD Name Server로 가는 위임 정보를 제공
com, net 같은 구역 안내	TLD Name Server	하위 Domain의 권한 서버를 안내
해당 조직이 관리하는 공식 주소록	Authoritative Name Server	Zone의 권한 있는 Record를 응답
이름에 연결된 정보 한 줄	Resource Record	A, AAAA, CNAME, NS 등 DNS 데이터
답을 다시 사용해도 되는 기간	DNS TTL	Cache가 Record를 보관할 수 있는 시간
다음 주소록 담당자를 안내	Referral	하위 위임 영역의 NS 정보를 제공하는 응답
존재하지 않는 이름도 잠시 기록	Negative Caching	NXDOMAIN 같은 부정 응답을 Cache

일반적인 DNS 조회 흐름은 다음처럼 정리할 수 있다.

1. Application이 Stub Resolver에 이름 해석을 요청한다.
2. Stub은 설정된 Recursive Resolver에 질의한다.
3. Resolver는 먼저 Cache를 확인한다.
4. Cache Miss이면 Root → TLD → Authoritative 순으로 답을 찾는다.
5. Resource Record와 TTL을 Cache한다.
6. A/AAAA 주소를 Application에 돌려준다.
7. Application이 받은 IP 주소로 실제 연결을 시작한다.

ㅁ dig로 주소록의 답을 읽어 보기

DNS 진단 도구인 dig로 A Record를 조회한다.

dig example.com A

출력에서 다음 구역을 살펴본다.

HEADER     : Status, Flag, 질의 ID
QUESTION   : 물어본 이름과 Record Type
ANSWER     : 최종 Resource Record와 TTL
AUTHORITY  : 권한 또는 위임 관련 정보
ADDITIONAL : 관련 주소나 EDNS 정보

AAAA Record도 별도로 확인한다.

dig example.com AAAA

특정 Recursive Resolver에 직접 질의하려면 @Resolver-IP 형식을 사용한다.

dig @SERVER_IP example.com A

SERVER_IP는 확인하려는 Resolver의 실제 IP 주소로 바꾼다. 로컬 시스템이 사용하는 Resolver와 다른 서버에 물으면 Cache와 정책이 달라 결과도 다를 수 있다.

DNS 계층을 따라가는 모습을 확인한다.

dig +trace example.com

+trace는 dig가 Root부터 위임을 따라 직접 질의한다.

회사 방화벽이 외부 DNS Server로의 직접 질의를 막거나 네트워크 정책이 특정 Resolver만 허용하면 실패할 수 있다.

Linux에서 Resolver 설정을 확인한다.

cat /etc/resolv.conf
resolvectl status

systemd-resolved를 사용하지 않는 환경에서는 resolvectl이 없을 수 있다.

/etc/resolv.conf도 로컬 Stub 주소만 가리키고 실제 Upstream Resolver는 별도 서비스 설정에 있을 수 있다.

macOS에서는 다음 명령으로 DNS Resolver 구성을 볼 수 있다.

scutil --dns

평문 DNS Packet을 관찰하려면 다음처럼 캡처할 수 있다.

sudo tcpdump -n -i eth0 'port 53'

DoH를 사용하는 애플리케이션의 질의는 HTTPS Traffic으로 보이므로 이 Filter에서 DNS 이름이 보이지 않을 수 있다.

ㅁ 핵심 정리

DNS는 계층적 이름 공간, 권한 위임, Cache를 사용해 인터넷 규모의 이름 조회를 제공한다.
애플리케이션은 Stub Resolver를 통해 Recursive Resolver에 최종 답을 요청한다.
Cache Miss이면 Resolver는 Root, TLD, Authoritative Name Server의 위임을 따라 답을 찾는다.
A와 AAAA는 주소, CNAME은 별칭, NS는 권한 서버 등 Record Type마다 역할이 다르다.
DNS TTL은 Cache 보관 시간이며 IPv4 Packet의 TTL과 다른 개념이다.
이미 Cache된 이전 답은 권한 Record를 수정해도 남은 TTL 동안 사용될 수 있다.
존재하지 않는다는 답도 Negative Caching의 대상이 될 수 있다.
여러 A/AAAA Record가 있다고 자동으로 Health Check와 완전한 장애 조치가 보장되지는 않는다.
NXDOMAIN, NODATA, SERVFAIL, Timeout, REFUSED는 서로 다른 실패다.
DNS는 UDP 53뿐 아니라 TCP 53도 사용한다.
DoH/DoT는 전송 암호화에, DNSSEC은 DNS 데이터의 출처 인증과 무결성에 초점을 둔다.

핵심 용어: DNS, FQDN, Label, Zone, Delegation, Stub Resolver, Recursive Resolver, Root Name Server, TLD Name Server, Authoritative Name Server, Referral, Resource Record, A, AAAA, CNAME, NS, MX, SOA, PTR, DNS TTL, Negative Caching, NXDOMAIN, SERVFAIL, DoH, DoT, DNSSEC

DNS는 이름을 주소로 바꾸는 한 대의 서버가 아니다. 권한을 나누고 답을 캐시해 전 세계가 함께 사용하는 분산 주소 체계다.

ㅁ 다음 이야기

DNS를 통해 example.com의 IP 주소를 알아냈다.

하지만 하나의 Server에서는 Web Server, SSH Server, Database처럼 여러 프로그램이 동시에 통신할 수 있다.

IP 주소가 건물을 찾았다면 그 안의 어느 창구에 데이터를 건네야 할까?

다음 글에서는 「한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?」라는 질문을 통해 Transport Layer, Port Number, Socket, Well-Known Port, Ephemeral Port와 5-Tuple을 살펴본다.

[Network] 12. 길이 바뀌면 지도는 어떻게 새로 그려질까?

기록하는 백엔드개발자 — Thu, 16 Jul 2026 20:12:07 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

Routing Loop가 생겨도 TTL은 한 패킷이 영원히 돌지 않도록 끝을 만든다.

하지만 TTL은 잘못된 Route를 고치지 않는다.

다음 패킷도 같은 Loop에 들어가 TTL이 끝날 때까지 네트워크 자원을 사용한다.

근본적인 해결은 라우터들이 실제 연결 상태에 맞는 경로를 갖는 것이다.

라우터가 세 대뿐이라면 관리자가 Static Route를 직접 수정할 수 있다.

R1 ── R2 ── R3

그러나 라우터가 수백 대이고 링크가 계속 생기고 사라진다면 어떻게 될까?

장애가 날 때마다 모든 장비에 접속해 경로를 고치는 동안 네트워크는 오래 멈춰 있을 것이다.

서로 다른 관리자가 동시에 수정하면 경로가 일치하지 않아 Loop가 생길 수도 있다.

라우터들이 이웃과 도달 가능한 네트워크 정보를 교환하고, 변화가 생기면 각자의 Routing Table을 다시 계산할 방법이 필요하다.

이를 Dynamic Routing이라고 한다.

이번 글에서는 Static Routing과 Dynamic Routing의 차이, 한 조직 안에서 지도를 공유하는 OSPF, 조직 사이에서 도달 경로와 정책을 교환하는 BGP, 변화 후 네트워크가 다시 안정되는 Convergence를 살펴본다.

ㅁ 손으로 적은 배송표는 언제 유용할까?

Static Route는 관리자가 Destination Prefix와 Next Hop을 직접 지정한 경로다.

10.30.0.0/24 via 192.0.2.2

작은 지점 네트워크처럼 출구가 하나뿐이라면 단순하고 예측하기 쉽다.

ㅇ Static Routing의 장점

경로가 관리자의 의도 없이 바뀌지 않는다.
라우팅 프로토콜을 위한 제어 트래픽과 계산이 필요 없다.
작은 토폴로지에서는 동작과 장애 범위를 이해하기 쉽다.
기본 경로, 특정 관리망, 의도적인 Blackhole처럼 명확한 목적에 적합하다.

ㅇ Static Routing의 한계

링크 장애를 발견해도 대체 경로로 자동 변경되지 않는다.
네트워크가 커질수록 장비마다 설정해야 할 Route가 늘어난다.
추가·삭제 작업의 누락과 잘못된 Next Hop이 장애를 만들 수 있다.
여러 관리자가 가진 네트워크 지식을 일관되게 유지하기 어렵다.

Static Routing은 오래된 방식이라서 나쁜 것이 아니다.

변화가 적고 경로가 단순한 곳에서는 여전히 적절하다.

문제는 사람이 관리해야 하는 변화의 수가 감당할 수 있는 범위를 넘어설 때다.

ㅁ Dynamic Routing은 패킷을 대신 배달할까?

Dynamic Routing Protocol은 애플리케이션의 데이터 패킷을 직접 운반하는 프로토콜이 아니다.

라우터들이 다음 정보를 서로 교환하기 위한 Control Plane Protocol이다.

어떤 Prefix에 도달할 수 있는가?
그 Prefix는 어느 이웃을 통해 배웠는가?
경로의 비용과 속성은 무엇인가?
기존 경로가 사라졌는가?

라우터는 받은 정보와 자신의 연결 상태를 바탕으로 최적 경로를 계산해 RIB에 반영하고, 실제 전달에 사용할 경로를 FIB에 설치한다.

Routing Protocol Message
        ↓
경로 학습과 선택 — Control Plane / RIB
        ↓
전달 정보 설치 — FIB
        ↓
일반 IP Packet 전달 — Data Plane

동적 라우팅은 모든 패킷에 길을 물어보는 방식이 아니다.

Control Plane에서 미리 지도를 만들고, Data Plane은 그 결과를 사용해 패킷을 빠르게 전달한다.

ㅁ 경로가 바뀌면 어떤 일이 일어날까?

다음처럼 두 개의 경로가 있는 네트워크를 생각해 보자.

        R2
       /  \
Client R1  R4 Server
       \  /
        R3

평상시에는 R1-R2-R4 경로의 비용이 더 낮아 사용한다고 하자.

R2와 R4 사이의 링크가 끊어지면 라우팅 프로토콜은 대략 다음 과정을 거친다.

1. 링크 또는 이웃의 장애를 감지한다.
2. 기존 경로가 더 이상 유효하지 않다는 정보를 전파한다.
3. 각 Router가 대체 경로를 계산한다.
4. 새로운 Route를 RIB와 FIB에 반영한다.
5. R1-R3-R4 경로로 Packet을 전달한다.

변화를 감지한 순간부터 관련 라우터들이 일관된 새 경로를 사용하기까지의 과정을 Convergence라고 한다.

Convergence 중에는 모든 라우터가 같은 순간에 정보를 갱신하지 않는다.

일부 라우터는 이전 경로를 사용할 수 있다.
일부 라우터는 새 경로를 이미 설치했을 수 있다.
짧은 Packet Loss나 일시적 Routing Loop가 생길 수 있다.
Stateful Session은 경로 변경의 영향을 받을 수 있다.

따라서 동적 라우팅의 목표는 단지 변화를 알아내는 것이 아니다.

변화를 빠르고 안정적으로 공유해 다시 일관된 전달 상태에 도달하는 것이다.

ㅁ 모든 라우터가 같은 방식으로 지도를 만들까?

Dynamic Routing Protocol은 네트워크의 범위와 해결하려는 문제에 따라 나뉜다.

ㅇ 한 관리 영역 안의 경로 — IGP

하나의 조직이 관리하는 네트워크 내부에서 사용하는 프로토콜을 IGP(Interior Gateway Protocol)라고 한다.

대표적으로 OSPF, IS-IS, RIP 등이 있다.

조직은 내부 링크의 상태와 비용을 바탕으로 빠르게 경로를 계산하려 한다.

ㅇ 서로 다른 관리 영역 사이의 경로 — EGP

인터넷처럼 서로 다른 조직의 네트워크가 연결될 때는 단순한 내부 최단거리만으로 경로를 정할 수 없다.

각 조직은 비용, 계약, 보안, 트래픽 엔지니어링 정책에 따라 어떤 경로를 받아들이고 알릴지 결정한다.

현재 인터넷의 대표적인 Inter-domain Routing Protocol은 BGP(Border Gateway Protocol)다.

각 관리 영역을 AS(Autonomous System)라고 하고 번호인 ASN(Autonomous System Number)으로 식별한다.

AS 65001 ── BGP ── AS 65002 ── BGP ── AS 65003

OSPF와 BGP는 둘 다 경로를 동적으로 교환하지만 문제의 범위와 판단 기준이 다르다.

ㅁ OSPF는 동네의 도로 상태를 함께 그린다

OSPF(Open Shortest Path First)는 Link State 방식의 IGP다.

라우터는 단순히 “이 목적지는 나를 통해 가라”고만 알리지 않는다.

자신의 링크와 이웃 상태를 나타내는 정보를 공유하고,

같은 OSPF Area의 라우터들이 공통된 토폴로지 지도를 만들도록 한다.

OSPF의 기본 흐름을 살펴보자.

ㅇ 1단계: 이웃을 발견한다 — Hello

OSPF Router는 Hello Packet을 교환해 같은 Link에 있는 OSPF 이웃을 찾고 설정이 맞는지 확인한다.

Area, Hello/Dead Timer, 인증과 네트워크 설정 등 중요한 조건이 맞지 않으면 정상적인 Neighbor 관계를 만들지 못할 수 있다.

OSPF는 TCP나 UDP Port를 사용하지 않고 IP Protocol Number 89를 사용한다.

ㅇ 2단계: 필요한 이웃과 인접 관계를 만든다 — Adjacency

라우터들은 Link State Database를 동기화하기 위한 Adjacency를 형성한다.

Broadcast Network에서는 모든 Router가 서로 완전한 Adjacency를 맺어 교환량이 커지지 않도록 DR과 BDR을 선출하는 구조를 사용할 수 있다.

ㅇ 3단계: 링크 상태를 알린다 — LSA

라우터는 자신의 연결 정보와 도달 가능한 Prefix 등을 LSA(Link-State Advertisement)로 알린다.

LSA는 필요한 범위에 Flooding되어 같은 Area의 라우터들이 Link State 정보를 공유하도록 한다.

ㅇ 4단계: 공통 지도를 만든다 — LSDB

라우터들은 받은 LSA를 LSDB(Link-State Database)에 저장한다.

같은 Area의 정상적으로 수렴한 Router들은 해당 Area에 대해 일관된 Link State 정보를 갖는 것을 목표로 한다.

ㅇ 5단계: 자신을 기준으로 최단 경로를 계산한다 — SPF

각 Router는 자신의 LSDB에 SPF(Shortest Path First) 알고리즘을 적용한다. 흔히 Dijkstra Algorithm으로 설명한다.

링크의 OSPF Cost를 바탕으로 각 목적지까지 가장 낮은 비용의 경로를 계산하고 Routing Table에 반영한다.

Hello → Neighbor / Adjacency
LSA Flooding → LSDB 동기화
SPF Calculation → Best Route
RIB / FIB Install → Packet Forwarding

라우터들은 같은 지도를 공유하지만 출발점이 서로 다르므로 각자 자신의 위치를 기준으로 경로를 계산한다.

ㅁ OSPF Area는 왜 필요할까?

모든 Router가 모든 Link 변화를 하나의 거대한 LSDB에 담으면 규모가 커질수록 Flooding과 SPF 계산 부담도 커진다.

OSPF는 네트워크를 Area로 나눠 Link State 정보의 범위를 계층화할 수 있다.

Area 1 ── Area 0 ── Area 2

Area 0은 Backbone Area 역할을 한다.

다른 일반 Area 사이의 연결은 기본적으로 Backbone을 중심으로 설계한다.

Area 경계의 Router는 영역 사이의 경로 정보를 전달하고 Summary를 적용할 수 있다.

Area를 나누면 다음 효과를 기대할 수 있다.

Link 변화의 Flooding 범위를 제한한다.
Router가 유지할 LSDB와 SPF 계산 범위를 줄인다.
주소 Summary를 통해 Route 수를 줄일 수 있다.

하지만 Area 설계가 복잡하거나 연결 규칙을 어기면 도달성 문제와 비효율적인 경로를 만들 수 있다.

작은 네트워크에서는 무리하게 여러 Area로 나누는 것보다 단순한 Area 0 구성이 이해하기 쉬울 수 있다.

ㅁ BGP는 전체 도로 지도를 공유할까?

인터넷을 연결하는 조직들은 내부의 모든 Router와 Link 상태를 서로 공개하지 않는다.

대신 다음과 같은 도달 가능성을 알린다.

203.0.113.0/24 Prefix는
AS 65003, AS 65002를 거쳐 도달할 수 있다.

BGP는 Prefix와 함께 경로 속성을 전달하는 Path Vector Protocol로 설명한다.

BGP Update에는 도달 가능한 Prefix 정보인 NLRI(Network Layer Reachability Information)와

경로 선택에 사용하는 여러 Path Attribute가 포함될 수 있다.

대표적인 속성은 다음과 같다.

속성	역할
AS_PATH	목적지 Prefix 광고가 거쳐 온 AS 번호의 경로
NEXT_HOP	해당 BGP Route를 전달할 다음 홉 주소
LOCAL_PREF	한 AS 내부에서 외부로 나갈 경로의 선호도를 표현
MED	이웃 AS에 여러 진입점의 상대적 선호를 제안
ORIGIN	경로 정보가 BGP에 들어온 기원을 표현

BGP Router는 단순히 물리적 거리가 가장 짧은 경로를 고르지 않는다.

조직의 Import/Export Policy와 Path Attribute를 바탕으로 경로를 선택하고 광고한다.

OSPF의 중심 질문: 내부 토폴로지에서 비용이 낮은 길은 무엇인가?
BGP의 중심 질문 : 어떤 경로를 받아들이고 선택하고 이웃에게 알릴 것인가?

정확한 BGP Best Path 선택 순서와 기본 정책은 구현 및 설정에 따라 차이가 있다.

입문 단계에서는 BGP가 인터넷 조직 사이의 정책 기반 도달성 교환이라는 점이 중요하다.

ㅁ BGP의 AS_PATH는 Loop를 어떻게 발견할까?

Prefix 광고가 AS를 지날 때 eBGP Router는 일반적으로 자신의 ASN을 AS_PATH에 추가한다.

AS 65003에서 시작
AS_PATH: 65003

AS 65002를 통과
AS_PATH: 65002 65003

AS 65001에 도착
AS_PATH: 65002 65003

AS 65001이 이 경로를 다시 광고하면 자신의 ASN이 추가될 수 있다.

어떤 AS가 받은 광고의 AS_PATH에서 자신의 ASN을 발견하면 해당 경로가 자신을 거쳐 되돌아온 것으로 판단해 일반적으로 거부한다.

이는 AS 수준의 Routing Loop를 막는 BGP의 핵심 장치다.

하지만 AS_PATH가 없애는 것은 BGP 경로 광고의 AS Loop다.

잘못된 Static Route, Route Redistribution, 내부 Policy로 생기는

모든 Data Plane Loop까지 자동으로 해결하는 것은 아니다.

ㅁ BGP Session이 연결되면 경로도 자동으로 생길까?

BGP Peer는 TCP Port 179를 사용해 Session을 맺는다.

Session 상태가 Established라면 두 Router 사이의 BGP 메시지 교환 채널이 준비되었다는 뜻이다.

그러나 Established가 곧 원하는 Route가 Routing Table에 있다는 뜻은 아니다.

다음 단계가 각각 성립해야 한다.

1. 광고할 Prefix가 BGP에 들어와 있는가?
2. Export Policy가 이웃에게 광고를 허용하는가?
3. Peer가 Update를 수신했는가?
4. Import Policy가 경로를 허용하는가?
5. NEXT_HOP에 도달할 수 있는가?
6. Best Path로 선택되었는가?
7. RIB와 FIB에 설치될 조건을 만족하는가?

그래서 BGP 장애는 다음처럼 나누어 확인해야 한다.

TCP/Peer Session 문제
→ Route Advertisement 문제
→ Policy Filtering 문제
→ Best Path Selection 문제
→ Next-Hop Resolution 문제
→ RIB/FIB Install 문제

“BGP가 Established인데 통신이 안 된다”는 상황은 모순이 아니다. 제어 채널 뒤의 경로 처리 단계가 별도로 남아 있다.

ㅁ eBGP와 iBGP는 무엇이 다를까?

서로 다른 AS 사이의 BGP Session을 eBGP(External BGP)라고 한다.

AS 65001 ── eBGP ── AS 65002

같은 AS 안에서 BGP Route를 공유하는 Session을 iBGP(Internal BGP)라고 한다.

AS 65001 내부
Router A ── iBGP ── Router B

BGP가 EGP 역할을 한다고 해서 모든 BGP Session이 AS 경계를 넘는 것은 아니다.

외부에서 받은 경로를 조직 내부의 BGP Router에 전달하기 위해 iBGP를 사용한다.

대규모 iBGP에서는 모든 Router 사이의 Full Mesh 부담을 줄이기 위해 Route Reflector 같은 구조를 사용할 수 있다.

OSPF와 iBGP도 경쟁 관계로만 볼 수 없다.

OSPF는 AS 내부의 Router와 BGP NEXT_HOP에 도달할 기반 경로를 제공할 수 있다.
iBGP는 외부 Prefix와 정책 정보를 AS 내부에 전달한다.

서로 다른 문제를 맡아 함께 동작할 수 있다.

ㅁ 빠르게 바뀌는 지도가 항상 좋은 것일까?

링크 장애를 빨리 감지하고 새 경로를 빨리 설치하면 Packet Loss 시간을 줄일 수 있다.

하지만 지나치게 민감하면 짧은 흔들림에도 경로가 계속 바뀌는 Route Flapping이 발생할 수 있다.

경로 변화마다 다음 작업이 반복될 수 있다.

Neighbor 상태 변경
Update 또는 LSA 전파
Best Path 또는 SPF 재계산
RIB/FIB 갱신
Stateful Flow의 경로 변화

네트워크 규모가 클수록 변화의 파급도 커질 수 있다.

따라서 Dynamic Routing은 속도와 안정성 사이의 균형을 다룬다.

장애 감지를 빠르게 하는 Timer와 BFD
변화가 연속될 때 계산을 조절하는 SPF Throttling
Route Flapping의 영향을 제한하는 정책
Summary와 Area로 변화 범위를 줄이는 설계

구체적인 기본값과 적절한 조정 값은 프로토콜, 장비, 토폴로지에 따라 다르다.

단순히 Timer를 가장 짧게 만드는 것이 항상 좋은 설계는 아니다.

ㅁ Dynamic Routing을 사용하면 Static Route는 사라질까?

실제 네트워크에서는 여러 경로 출처를 함께 사용할 수 있다.

Connected Route : 인터페이스에 직접 연결된 네트워크
Static Route    : 관리자가 명시한 특별 경로
OSPF Route      : 조직 내부에서 동적으로 학습한 경로
BGP Route       : 다른 AS 또는 BGP Peer에서 학습한 경로
Default Route   : 더 구체적인 경로가 없을 때 사용할 출구

지점 Router는 내부 Prefix를 OSPF로 배우고 인터넷 방향은 Static Default Route를 사용할 수 있다.

경계 Router는 BGP로 외부 경로를 받고 내부에는 Default Route만 알릴 수도 있다.

문제는 서로 다른 출처의 Route를 아무 계획 없이 재배포할 때 생긴다.

Route Redistribution은 한 Routing Domain의 경로를 다른 Protocol에 넣는 기능이다.

연결에는 유용하지만 경로 출처가 흐려지고 Metric 변환, Loop, 피드백 문제가 생길 수 있다.

OSPF Route를 BGP로 재배포
       ↓
BGP Route를 다시 OSPF로 재배포
       ↓
원래 경로가 다른 출처로 되돌아올 위험

Tagging, Filtering, Summary와 명확한 단방향 정책 없이 재배포하면 Control Plane Loop 또는 잘못된 우선순위를 만들 수 있다.

동적 라우팅은 자동이지만 설계 의도까지 자동으로 만들어 주지는 않는다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
관리자가 손으로 적은 배송표	Static Route	운영자가 Destination과 Next Hop을 직접 지정한 경로
우체국끼리 자동으로 변경 정보를 교환	Dynamic Routing	Protocol로 도달성과 경로 변화를 학습하는 방식
한 조직 내부의 배송 체계	IGP	하나의 관리 영역 안에서 사용하는 Routing Protocol 범주
내부 도로 상태를 함께 그린 지도	OSPF Link State	LSA와 LSDB를 이용해 내부 토폴로지를 공유하는 방식
서로 다른 물류 회사의 관리 영역	Autonomous System	하나의 Routing Policy 아래 관리되는 네트워크 집합
회사 사이의 배송 가능 지역과 정책 교환	BGP Path Vector	Prefix와 Path Attribute를 교환하는 Inter-domain 방식
바뀐 길을 모두 반영해 다시 안정됨	Convergence	변화 후 일관된 새 Forwarding 상태에 도달하는 과정
계속 생겼다 사라지는 배송 안내	Route Flapping	경로가 반복해서 광고되고 철회되는 현상
서로 다른 지도 체계 사이에 경로 전달	Route Redistribution	한 Protocol의 Route를 다른 Protocol로 주입하는 기능

Dynamic Routing의 전체 흐름은 다음처럼 정리할 수 있다.

1. Neighbor 또는 Peer 관계를 만든다.
2. Prefix와 Topology 또는 Path 정보를 교환한다.
3. Protocol별 규칙과 Policy로 Best Path를 선택한다.
4. 선택 경로를 RIB와 FIB에 반영한다.
5. 변화가 생기면 정보를 갱신하고 다시 Converge한다.

ㅁ 직접 지도의 변화를 따라가 보기

다음 OSPF 토폴로지를 종이에 그려 보자.

R1에서 R4까지 두 후보를 계산한다.

R1 → R2 → R4 = 10 + 10 = 20
R1 → R3 → R4 = 30 + 30 = 60

정상 상태에서는 비용 20인 R2 경로가 선택된다.

R2-R4 링크가 끊어지면 다음 질문을 순서대로 생각해 보자.

어떤 Router가 Link Down을 먼저 감지하는가?
변경된 Link State는 어떤 이웃에게 전달되는가?
각 Router의 LSDB는 어떻게 바뀌는가?
R1의 SPF 결과는 어느 경로로 바뀌는가?
FIB가 갱신되기 전까지 어떤 Packet Loss가 생길 수 있는가?

Linux에서는 Kernel Routing Table의 경로 출처와 Next Hop을 관찰한다.

ip -4 route show
ip route get 203.0.113.10

FRRouting이 이미 구성된 개인 실습 환경이라면 읽기 명령으로 Control Plane 상태를 볼 수 있다.

sudo vtysh -c 'show ip ospf neighbor'
sudo vtysh -c 'show ip ospf database'
sudo vtysh -c 'show ip route'
sudo vtysh -c 'show bgp summary'

각 명령은 다음 질문에 답한다.

OSPF Neighbor : 이웃 관계가 형성되었는가?
OSPF Database : Link State 정보가 동기화되었는가?
IP Route      : Best Route가 선택되었는가?
BGP Summary   : Peer Session과 받은 Prefix 상태는 어떤가?

FRRouting이 설치·구성되지 않은 일반 호스트에서는 명령이 없거나 결과가 비어 있는 것이 정상이다.

관찰을 위해 OSPF/BGP Timer, Route Redistribution, BGP Policy를 운영 장비에서 변경하면

광범위한 경로 장애를 만들 수 있으므로 읽기 명령으로만 상태를 확인한다.

ㅁ 핵심 정리

Static Route는 단순하고 예측 가능하지만 변화가 생겨도 자동으로 갱신되지 않는다.
Dynamic Routing Protocol은 Control Plane에서 경로 정보를 교환하고 RIB/FIB를 갱신한다.
장애 감지부터 새 경로가 안정적으로 사용되기까지의 과정을 Convergence라고 한다.
OSPF는 IGP이며 Hello, Adjacency, LSA, LSDB, SPF를 통해 Link State 경로를 계산한다.
OSPF Area는 Link State 정보와 계산 범위를 계층화하며 Area 0이 Backbone 역할을 한다.
BGP는 Prefix와 AS_PATH, NEXT_HOP 같은 Path Attribute를 교환하는 정책 기반 Path Vector Protocol이다.
BGP Established는 메시지 채널이 준비되었다는 뜻이며 원하는 Route의 광고·선택·설치를 보장하지 않는다.
eBGP는 AS 사이에, iBGP는 같은 AS 안에서 BGP Route를 교환한다.
빠른 장애 감지와 안정적인 Control Plane 사이에는 균형이 필요하다.
Dynamic Route, Static Route, Default Route는 설계 목적에 따라 함께 사용될 수 있다.
Route Redistribution은 유용하지만 출처와 Loop를 통제할 명확한 정책이 필요하다.

핵심 용어: Static Routing, Dynamic Routing, Control Plane, Data Plane, Convergence, IGP, OSPF, Hello, Adjacency, LSA, LSDB, SPF, Area 0, AS, ASN, BGP, NLRI, AS_PATH, Path Attribute, eBGP, iBGP, Route Flapping, Route Redistribution

동적 라우팅은 정답 지도를 한 번 배포하는 기술이 아니다. 계속 변하는 연결 상태를 공유하고 각 라우터가 다시 길을 계산하게 하는 약속이다.

ㅁ 다음 이야기

이제 편지는 같은 동네의 MAC 주소를 찾고, Gateway를 지나, 여러 Router가 계산한 경로를 따라 원격 네트워크까지 갈 수 있다.

하지만 사용자는 웹사이트에 접속할 때 203.0.113.10 같은 숫자 주소를 입력하지 않는다.

example.com이라는 이름만 알고도 실제 IP 주소를 어떻게 찾을까?

다음 글에서는 「우리는 왜 숫자 대신 이름으로 접속할까?」라는 질문을 통해 DNS Stub Resolver, Recursive Resolver, Root·TLD·Authoritative Name Server, Record와 Cache TTL을 살펴본다.

[Network] 11. 길을 잃은 편지가 영원히 돌면 어떻게 될까?

기록하는 백엔드개발자 — Thu, 16 Jul 2026 20:11:40 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

경로가 없으면 라우터는 패킷을 더 이상 전달할 수 없다.

하지만 잘못된 경로가 있으면 패킷은 멈추지 않고 엉뚱한 방향으로 갈 수 있다.

R1은 목적지로 가려면 R2에게 보내야 한다고 생각하고,

R2는 같은 목적지로 가려면 R1에게 보내야 한다고 생각해 보자.

Destination Network: 10.30.0.0/24

R1 Route: 10.30.0.0/24 via R2
R2 Route: 10.30.0.0/24 via R1

패킷은 두 라우터 사이를 오간다.

R1 → R2 → R1 → R2 → R1 → ...

IP Packet에는 요청이 지나온 경로 목록이 없으므로 라우터는 “아까 본 패킷”이라는 이유만으로 전달을 멈추지 않는다.

그렇다면 패킷은 영원히 네트워크 자원을 점유할까?

IPv4 Header에는 TTL(Time To Live)이라는 안전장치가 있다.

라우터를 지날 때마다 값이 줄고, 더 이상 전달할 수 없는 순간에는 ICMP Time Exceeded가 패킷의 수명이 끝났음을 알린다.

이번 글에서는 Routing Loop, TTL, Hop Limit, ICMP Time Exceeded를 살펴보고,

traceroute가 이 안전장치를 이용해 보이지 않는 라우터를 발견하는 원리를 알아본다.

ㅁ 두 우체국이 서로를 다음 배송지로 가리킨다

민수의 편지가 제주도로 가야 한다고 생각해 보자.

서울 우체국의 안내표에는 다음과 같이 적혀 있다.

제주도 편지 → 대전 우체국으로

그런데 대전 우체국의 안내표에는 반대로 적혀 있다.

제주도 편지 → 서울 우체국으로

서울은 대전으로 보내고 대전은 다시 서울로 보낸다.

두 우체국 모두 자신의 안내표를 정상적으로 따르고 있지만 편지는 제주도에 가까워지지 않는다.

네트워크에서도 각 라우터의 Route Entry가 서로를 Next Hop으로 가리키면 Routing Loop가 생긴다.

다음 토폴로지를 보자.

Client ── R1 ── R2
          ↑     │
          └─────┘

목적지: 10.30.0.10

R1과 R2가 가진 경로가 다음과 같다고 하자.

R1: 10.30.0.0/24 via R2
R2: 10.30.0.0/24 via R1

R1은 Routing Table Lookup 결과에 따라 R2로 보낸다.

R2도 같은 목적지 주소를 보고 자신의 테이블에 따라 R1로 돌려보낸다.

각 결정만 보면 규칙에 맞지만 두 결정을 연결하면 원이 된다.

ㅁ L2 Loop와 Routing Loop는 무엇이 다를까?

앞에서 스위치 사이의 L2 Loop도 살펴보았다.

두 루프는 경로가 원을 만든다는 점은 같지만 영향을 만드는 방식이 다르다.

구분	L2 Loop	L3 Routing Loop
전달 단위	Ethernet Frame	IP Packet
대표 원인	스위치 사이의 순환 링크	라우터의 잘못되거나 수렴 중인 경로 정보
수명 제한	일반 Frame에 스위치 홉 TTL 없음	IPv4 TTL 또는 IPv6 Hop Limit 있음
대표 증상	Broadcast Storm, MAC Flapping	반복되는 Router Hop, TTL Exceeded
대표 방지·완화	STP/RSTP로 논리적 루프 제거	경로 설계·프로토콜 루프 방지와 TTL

L2 Loop에서는 브로드캐스트 프레임이 여러 포트로 복제되며 급격히 늘어날 수 있다.

Routing Loop에서는 일반적으로 하나의 IP Packet이 라우터 사이를 반복해 이동한다.

각 라우터가 링크에 맞는 새 L2 Frame을 만들지만 안쪽 IP Packet의 목적지는 그대로다.

TTL이 있으므로 한 패킷이 영원히 돌지는 않는다.

그러나 새로운 패킷이 계속 들어오면 각 패킷은 TTL이 소진될 때까지 반복 전달되므로 링크와 라우터 자원을 계속 낭비할 수 있다.

TTL은 Routing Loop의 원인을 고치는 기능이 아니다.

루프가 생겼을 때 한 패킷의 피해를 유한하게 만드는 최후의 안전장치다.

ㅁ TTL은 시간일까, 횟수일까?

TTL의 이름은 Time To Live, 즉 살아 있을 시간이다.

하지만 일반적인 IP Forwarding에서 관찰하는 핵심 동작은 라우터를 통과할 때마다 값이 최소 1씩 감소하는 것이다.

Source에서 TTL 64로 전송
Router 1 통과 후 TTL 63
Router 2 통과 후 TTL 62
Router 3 통과 후 TTL 61

실질적으로 패킷이 통과할 수 있는 Router Hop의 수를 제한한다.

IPv4 TTL 필드는 8비트이므로 0부터 255까지 표현할 수 있다.

송신 운영체제가 초기값을 정하며 흔히 64, 128, 255 같은 값을 볼 수 있지만 시스템과 프로토콜에 따라 달라질 수 있다.

초기 TTL을 보고 운영체제를 추측하는 기법도 있지만

중간 장비와 설정이 값을 바꿀 수 있으므로 확정적인 식별 방법은 아니다.

IPv6에서는 같은 목적의 필드를 Hop Limit이라고 부른다.

이름이 실제 동작을 더 직접적으로 표현한다.

IPv4 : TTL
IPv6 : Hop Limit

ㅁ 라우터는 TTL을 언제 줄일까?

라우터가 IPv4 Packet을 전달할 때의 흐름을 단순화하면 다음과 같다.

1. Ethernet Frame을 수신한다.
2. 안쪽 IPv4 Packet을 확인한다.
3. TTL을 감소시킨다.
4. TTL이 유효한지 확인한다.
5. Routing Table을 조회하고 다음 Link로 전달한다.

TTL이 감소해 0이 되면 라우터는 패킷을 다음 홉으로 전달하지 않고 폐기한다.

TTL은 IPv4 Header의 일부다.

값이 바뀌면 IPv4 Header Checksum도 갱신해야 한다.

Payload의 내용이나 Destination IP가 TTL 감소 때문에 바뀌는 것은 아니다.

바뀌는 값: TTL, IPv4 Header Checksum, 다음 링크의 L2 Header
유지되는 값: 일반 라우팅에서 Source IP, Destination IP, Payload

IPv6 기본 Header에는 IPv4와 같은 Header Checksum이 없으므로

Hop Limit 감소 때문에 IP Header Checksum을 다시 계산하는 과정은 없다.

ㅁ TTL 4인 패킷이 루프에 들어가면 어떻게 될까?

Client가 초기 TTL 4로 패킷을 보냈다고 하자.

Client → R1 → R2 → R1 → R2

각 라우터에서 보이는 값을 따라가 보자.

순서	패킷을 받은 라우터	수신 시 TTL	전달 시 TTL	결과
1	R1	4	3	R2로 전달
2	R2	3	2	R1로 전달
3	R1	2	1	R2로 전달
4	R2	1	0	폐기

패킷은 목적지에 도착하지 못하지만 네 번째 라우터 처리에서 수명이 끝난다.

초기 TTL이 64라면 더 오래 순환하고, 255라면 더 많은 라우터 처리를 거칠 수 있다. 그래도 한 패킷의 순환 횟수는 유한하다.

라우터는 수명이 끝난 사실을 Source에게 알리기 위해 ICMP 메시지를 만들 수 있다.

ㅁ 수명이 끝난 편지는 어떤 답장을 보낼까?

IPv4 Router는 Forwarding 중 TTL이 만료된 패킷을 폐기하고

일반적으로 ICMP Time Exceeded 메시지를 Source로 보낸다.

IPv4 ICMP에서는 다음 값으로 표현한다.

Type 11 : Time Exceeded
Code 0  : Time to Live exceeded in transit

ICMP 메시지에는 문제가 발생한 원래 IP Header와 상위 계층을 식별하는 데 필요한 원래 패킷의 일부가 포함된다.

Source는 어떤 전송에 대한 오류인지 연결할 수 있다.

Router → Source
ICMP Time Exceeded
“이 패킷은 전달 중 TTL이 끝났다.”

하지만 ICMP 메시지도 새로운 IP Packet이다.

Source로 돌아가는 Route가 없거나 Firewall이 ICMP를 차단하면 Source는 Time Exceeded를 받지 못할 수 있다.

TTL은 원래 패킷을 폐기하는 안전장치로는 동작하지만, 오류 메시지가 반드시 송신자에게 보인다고 보장하지는 않는다.

IPv6에서는 ICMPv6 Time Exceeded가 Hop Limit 만료를 알린다.

ㅁ traceroute는 일부러 수명이 짧은 패킷을 보낸다

traceroute는 TTL 만료를 장애가 아니라 관찰 도구로 이용한다.

먼저 TTL 1인 Probe Packet을 보낸다.

TTL 1
Source → R1

R1이 TTL을 0으로 만들고 ICMP Time Exceeded를 돌려준다.

Source는 첫 번째 Hop이 R1이라는 단서를 얻는다.

다음에는 TTL 2인 Probe를 보낸다.

TTL 2
Source → R1 → R2

R1을 지나 TTL 1이 되고 R2에서 0이 된다. R2가 ICMP Time Exceeded를 보내면 두 번째 Hop을 알 수 있다.

이 과정을 TTL 3, 4, 5로 늘려 반복한다.

TTL 1 → 첫 번째 Router 응답
TTL 2 → 두 번째 Router 응답
TTL 3 → 세 번째 Router 응답
...

목적지에 도착하면 Probe 방식에 따라 다른 종료 응답을 받는다.

전통적인 UDP Probe는 닫힌 높은 Port에 도착해 ICMP Port Unreachable을 받을 수 있다.
ICMP Echo Probe는 Echo Reply를 받을 수 있다.
TCP Probe는 SYN-ACK 또는 RST 같은 TCP 응답을 받을 수 있다.

운영체제와 traceroute 구현, 옵션에 따라 사용하는 Probe Protocol은 다르다.

traceroute는 라우터가 가진 전체 지도를 읽어 오는 명령이 아니다.

서로 다른 TTL의 Probe를 보내고 각 수명이 끝난 위치에서 돌아온 응답을 모아 경로를 추론하는 명령이다.

ㅁ Routing Loop는 traceroute에서 어떻게 보일까?

R1과 R2 사이에 Loop가 있으면 Hop 목록에서 같은 주소가 반복될 수 있다.

1  192.0.2.1   R1
2  192.0.2.2   R2
3  192.0.2.1   R1
4  192.0.2.2   R2
5  192.0.2.1   R1
6  192.0.2.2   R2

TTL을 늘린 Probe가 같은 두 라우터에서 번갈아 만료되므로 반복 패턴이 나타난다.

하지만 주소 반복만으로 모든 Routing Loop를 완벽히 증명할 수 있는 것은 아니다.

ECMP 때문에 Probe마다 다른 경로를 사용할 수 있다.
라우터가 ICMP 응답에 사용하는 Source IP가 예상과 다를 수 있다.
ICMP Rate Limiting 때문에 일부 Hop이 *로 보일 수 있다.
Firewall이 특정 Probe 또는 응답을 차단할 수 있다.
Forward Path와 ICMP Return Path가 서로 다를 수 있다.

traceroute의 반복 패턴은 강한 단서다.

실제 각 라우터의 Route Lookup과 인터페이스 캡처를 함께 확인해야 원인을 확정할 수 있다.

ㅁ TTL을 크게 늘리면 통신이 될까?

Routing Loop에서 TTL이 만료되므로 TTL을 크게 설정하면 목적지에 도착할 것처럼 생각할 수 있다.

하지만 경로 정보가 서로를 가리키는 한 패킷은 목적지 방향으로 나아가지 않는다. TTL을 늘리면 더 오래 순환할 뿐이다.

TTL 64  → Loop를 64 Hop 이내에서 종료
TTL 255 → 더 오래 순환한 뒤 종료

TTL을 높이는 것은 Routing Loop의 해결책이 아니다.

고쳐야 하는 것은 잘못된 Route Entry다.

잘못된 상태
R1: 10.30.0.0/24 via R2
R2: 10.30.0.0/24 via R1

해결 방향 예시
R2: 10.30.0.0/24를 실제 목적지 Interface 또는 올바른 Next Hop으로
R1: R2를 통해 정상 경로 사용

모르는 목적지를 서로의 Default Route로 넘기는 구조도 Loop를 만들 수 있다.

경로를 삭제하는 것과 Blackhole 또는 Unreachable Route로 명시적으로 종료하는 것 가운데

어떤 방법이 적절한지는 설계 목적에 따라 달라진다.

ㅁ Routing Loop는 왜 생길까?

Routing Loop는 여러 상황에서 발생할 수 있다.

ㅇ 잘못된 Static Route

두 라우터가 특정 Prefix 또는 Default Route를 서로에게 향하도록 설정할 수 있다.

ㅇ 경로가 바뀌는 동안의 정보 불일치

링크 장애 뒤 일부 라우터는 새 상태를 알고 다른 라우터는 이전 상태를 유지할 수 있다. 네트워크가 아직 Convergence하지 않은 순간에 임시 Loop가 생길 수 있다.

ㅇ Route Redistribution과 Summary 설계 오류

여러 Routing Protocol 사이에 경로를 재배포하거나 넓은 Summary Route를 만들 때 경로의 출처와 실제 도달성을 잘못 표현하면 패킷이 되돌아올 수 있다.

ㅇ 잘못된 Policy Routing

일반 Destination Route와 별도로 Source, Mark, Interface에 따른 정책이 서로 충돌해 예상하지 못한 순환을 만들 수 있다.

동적 라우팅 프로토콜은 Loop를 줄이기 위한 여러 장치를 갖는다.

Distance Vector 계열의 Split Horizon과 Route Poisoning
Link State 계열의 공통 Topology Database와 SPF 계산
BGP의 AS_PATH를 이용한 Autonomous System Loop 탐지

하지만 잘못된 설정과 정책까지 모든 Loop를 자동으로 막아 주는 것은 아니다.

이 장치들은 다음 글의 동적 라우팅에서 더 자세히 살펴본다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
두 우체국이 서로를 다음 배송지로 가리킴	Routing Loop	Route Entry가 순환하는 Next Hop을 만드는 상태
봉투에 적힌 남은 중계 횟수	TTL	IPv4 Packet이 통과할 수 있는 Router Hop을 제한하는 필드
IPv6 봉투의 남은 중계 횟수	Hop Limit	IPv6에서 TTL과 같은 역할을 하는 필드
횟수가 끝난 편지를 폐기	TTL Expiration	TTL 감소 결과가 0이 되어 Forwarding을 중단하는 동작
수명이 끝났다는 반송 안내	ICMP Time Exceeded	TTL 만료를 Source에 알리는 제어 메시지
짧은 수명의 편지를 차례로 보냄	traceroute	TTL을 증가시키며 각 Hop의 응답을 수집하는 경로 추론
모든 우체국이 같은 새 지도를 갖게 됨	Convergence	경로 변화 후 Routing 정보가 안정된 상태

Routing Loop 안에서 한 Packet이 끝나는 과정은 다음과 같다.

1. Source가 초기 TTL을 설정해 Packet을 보낸다.
2. 각 Router는 Forwarding 전에 TTL을 감소시킨다.
3. 잘못된 Route 때문에 Packet이 같은 Router들을 반복한다.
4. TTL이 0이 된 Router가 Packet을 폐기한다.
5. 가능하면 ICMP Time Exceeded를 Source로 보낸다.

ㅁ 직접 관찰해 보기

먼저 일반적인 경로를 숫자 주소로 확인한다.

traceroute -n 8.8.8.8

최대 Hop 수를 작게 제한해 관찰할 수도 있다.

traceroute -n -m 5 8.8.8.8

Linux의 tracepath가 설치되어 있다면 권한 없이 경로와 PMTU 정보를 함께 관찰할 수 있다.

tracepath -n 8.8.8.8

Linux ping 구현에서는 TTL을 작게 설정한 Echo Request를 보낼 수 있다.

ping -c 1 -t 1 8.8.8.8

첫 Router가 ICMP Time Exceeded를 보내고 Return Path와 정책이 허용한다면 응답을 볼 수 있다.

macOS ping에서는 TTL 지정 옵션이 다를 수 있으므로 해당 시스템의 man ping을 확인한다.

ICMP 메시지와 IP TTL을 패킷 수준에서 보려면 다음처럼 캡처할 수 있다.

sudo tcpdump -n -vv -i eth0 icmp

인터페이스 이름과 권한은 환경에 맞게 조정한다.

공용 목적지에 대한 경로는 네트워크 정책, VPN, 방화벽, ECMP에 따라 달라진다.

반복되는 Hop이나 *를 발견해도 운영 환경의 Routing Loop라고 즉시 단정하지 않는다.

의도적으로 잘못된 Route를 추가해 Loop를 만드는 실험은 공유 네트워크와 운영 장비에 영향을 줄 수 있다. 격리된 개인 실습 환경이 아니라면 읽기와 패킷 관찰만 수행한다.

ㅁ 핵심 정리

Routing Loop는 여러 Router의 Route Entry가 Packet을 순환시키는 상태다.
L2 Loop의 일반 Ethernet Frame과 달리 IP Packet에는 TTL 또는 Hop Limit이 있다.
IPv4 TTL은 Router를 통과할 때마다 감소하며 0이 되면 Packet을 폐기한다.
TTL 변경 시 IPv4 Header Checksum도 갱신된다.
Router는 TTL 만료를 ICMP Type 11 Code 0 Time Exceeded로 알릴 수 있다.
ICMP 응답도 Return Route와 정책이 필요하므로 Source에 반드시 도착하는 것은 아니다.
traceroute는 TTL을 1부터 늘린 Probe의 만료 응답을 모아 Hop을 추론한다.
TTL을 크게 설정해도 잘못된 Route는 고쳐지지 않고 Packet이 더 오래 순환할 뿐이다.
동적 Routing Protocol은 여러 Loop 방지 장치를 갖지만 잘못된 정책과 설정까지 모두 막지는 못한다.

핵심 용어: Routing Loop, TTL, Hop Limit, TTL Expiration, ICMP Time Exceeded, ICMP Type 11 Code 0, traceroute, Router Hop, Convergence, Split Horizon, Route Poisoning, AS_PATH

TTL은 패킷을 목적지로 안내하지 않는다. 잘못된 안내가 네트워크 자원을 영원히 점유하지 못하게 끝을 정한다.

ㅁ 다음 이야기

Static Route만 사용하는 작은 네트워크에서는 관리자가 잘못된 경로를 직접 찾아 고칠 수 있다.

하지만 수백, 수천 개의 라우터가 연결된 네트워크에서 링크가 바뀔 때마다 모든 Routing Table을 사람이 수정할 수는 없다.

라우터들은 새로운 길과 사라진 길을 어떻게 서로 알릴까?

다음 글에서는 「길이 바뀌면 지도는 어떻게 새로 그려질까?」라는 질문을 통해

Static Routing과 Dynamic Routing의 차이, OSPF의 Link State, BGP의 Path Vector와 Convergence를 살펴본다.

[Network] 10. 가는 길이 있으면 돌아오는 길도 있는 것일까?

기록하는 백엔드개발자 — Thu, 16 Jul 2026 20:10:46 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

라우터는 Destination IP와 Routing Table을 비교해 다음 경로를 선택한다.

한 라우터가 내린 결정은 다음 라우터에 전달되는 여행 계획이 아니다.

각 라우터는 자신에게 도착한 패킷의 목적지를 보고 독립적으로 다음 홉을 고른다.

요청 패킷이 서버에 도착했다고 생각해 보자.

Client ── R1 ── R2 ── Server
          요청 도착 성공

이제 서버가 응답하면 요청이 지나온 길을 거꾸로 돌아갈 것처럼 보인다.

하지만 IP 패킷에는 “지나온 라우터 목록”이 일반적으로 기록되지 않는다.

응답 패킷은 Client의 IP 주소를 새로운 Destination으로 삼고 다시 Routing Table Lookup을 거친다.

가는 길과 오는 길은 서로 다른 두 번의 결정이다.

요청이 도착했다는 사실은 응답이 돌아갈 경로까지 존재한다는 뜻이 아니다.

이번 글에서는 Forward Path, Return Path, Missing Route, Asymmetric Routing을 살펴보고,

Stateless한 IP 전달에서는 가능한 비대칭 경로가 Stateful Firewall과 NAT를 만나면 왜 장애가 될 수 있는지 알아본다.

ㅁ 편지에는 지나온 우체국 목록이 적히지 않는다

민수가 다른 지역의 영희에게 편지를 보냈다고 생각해 보자.

편지는 여러 우체국을 거쳐 영희에게 도착한다.

민수 → 우체국 A → 우체국 B → 영희

영희가 답장을 쓸 때 원래 봉투를 뒤집어 같은 길로 보내는 것은 아니다.

새 봉투의 받는 사람에 민수의 주소를 적고 자신의 동네 우체국에 맡긴다. 답장을 받은 우체국들은 민수의 주소를 기준으로 각자의 배송표를 조회한다.

영희 → 우체국 C → 우체국 D → 민수

요청과 답장의 경로가 같을 수도 있고 다를 수도 있다.

IP Routing도 같은 원리다.

Client에서 Server로 가는 경로를 Forward Path라고 한다.
Server에서 Client로 돌아오는 경로를 Return Path라고 한다.

두 경로는 각 방향의 Destination IP와 Routing Table에 의해 별도로 결정된다.

TCP가 연결 상태를 관리하더라도 라우터가 요청 경로를 기억해 응답을 되돌려 주는 것은 아니다.

TCP의 상태와 IP Routing의 경로 선택은 서로 다른 계층의 문제다.

ㅁ 요청은 도착했는데 응답은 길을 잃을 수 있다

다음 네트워크를 살펴보자.

Client LAN              Transit              Server LAN
10.1.0.0/24          192.0.2.0/30           10.2.0.0/24

Client ── R1 ───────────────── R2 ── Server
10.1.0.10  .1   .1             .2   .1  10.2.0.20

주소를 조금 더 명확히 적으면 다음과 같다.

Client       : 10.1.0.10/24, Gateway 10.1.0.1
R1 Client IF : 10.1.0.1/24
R1 Transit IF: 192.0.2.1/30
R2 Transit IF: 192.0.2.2/30
R2 Server IF : 10.2.0.1/24
Server       : 10.2.0.20/24, Gateway 10.2.0.1

R1에는 Server LAN으로 가는 경로가 있다.

R1: 10.2.0.0/24 via 192.0.2.2

Forward Path는 성립한다.

Client 10.1.0.10
  → Gateway R1
  → R2
  → Server 10.2.0.20

Server는 요청을 받고 응답을 만든다.

Source IP      : 10.2.0.20
Destination IP : 10.1.0.10

Client는 다른 네트워크에 있으므로 Server는 응답을 Gateway R2에 보낸다.

그런데 R2에 10.1.0.0/24로 가는 경로가 없다고 하자.

R2 Routing Table
├─ 10.2.0.0/24 dev server-if
├─ 192.0.2.0/30 dev transit-if
└─ 10.1.0.0/24 경로 없음

Default Route도 없다면 R2는 응답을 전달할 수 없다. Return Path가 끊어진 것이다.

Forward Path : Client → R1 → R2 → Server  성공
Return Path  : Server → R2 → ?             실패

서버의 네트워크 로그나 패킷 캡처에는 요청 패킷이 들어온 흔적이 남을 수 있다.

하지만 Client는 응답을 받지 못해 타임아웃을 경험한다.

ㅁ TCP에서는 어떤 모습으로 보일까?

Client가 Server의 TCP Port에 접속한다고 하자.

첫 번째 SYN은 Forward Path를 따라 Server에 도착한다.

Client → Server : SYN

Server는 SYN을 받고 SYN-ACK을 보낸다.

Server → Client : SYN-ACK

하지만 Return Path가 없으면 SYN-ACK은 Client에 도착하지 않는다.

Client는 서버가 SYN을 받았는지 알 수 없으므로 일정 시간 뒤 SYN을 재전송한다.

Client → Server : SYN
Client → Server : SYN 재전송
Client → Server : SYN 재전송
...
Client           : Connection timeout

관찰 위치에 따라 서로 다른 장면이 보인다.

관찰 위치	보이는 패킷
Client	반복되는 SYN, SYN-ACK 없음
Server	SYN 수신, SYN-ACK 전송 반복
R1의 Client 방향	SYN 통과, SYN-ACK 없음
R2의 Server 방향	SYN과 SYN-ACK 모두 보일 수 있음

Client의 캡처만 보면 서버나 방화벽이 SYN을 버린 것처럼 보일 수 있다.

Server의 캡처를 함께 보면 요청이 도착했고 응답도 생성되었다는 사실을 알 수 있다.

두 지점의 증거를 맞춰야 Return Path 문제로 범위를 좁힐 수 있다.

UDP처럼 연결 설정과 재전송을 프로토콜이 보장하지 않는 통신은 단순히 응답 없는 타임아웃으로 보일 수 있다.

ICMP Echo Request가 도착해도 Echo Reply의 Return Path가 없으면 ping은 실패한다.

ping 성공 여부는 단방향 도달이 아니라 왕복이 모두 성립했는지를 보여준다.

ㅁ 경로가 없으면 항상 오류를 돌려줄까?

R2가 목적지 경로를 찾지 못하면 ICMP Destination Unreachable 메시지를 생성할 수 있다.

그런데 이 오류 메시지도 IP 패킷이다.

Client에게 도착하려면 R2에서 10.1.0.10으로 가는 경로가 필요하다.

문제의 원인이 Return Route 부재라면 오류조차 Client에게 돌아가지 못할 수 있다.

방화벽이 ICMP를 차단하거나 장비가 오류 생성을 제한하는 경우도 있다.

그래서 Client에서는 명확한 “경로 없음” 오류 대신 조용한 Timeout만 보일 수 있다.

네트워크가 실패 이유를 알고 있어도, 그 이유를 알려 줄 돌아오는 길이 없으면 사용자는 침묵만 보게 된다.

ㅁ 왕복 경로가 꼭 같아야 할까?

Forward Path와 Return Path가 다른 것을 Asymmetric Routing이라고 한다.

Forward Path : Client → R1 → R3 → Server
Return Path  : Server → R2 → R4 → Client

비대칭 경로 자체는 IP Routing에서 잘못이 아니다.

인터넷에서는 각 네트워크의 정책과 연결 상태가 다르므로 요청과 응답이 서로 다른 사업자와 라우터를 지날 수 있다.

다음 조건을 만족하면 비대칭 경로에서도 통신할 수 있다.

Forward Path의 모든 라우터가 Server 방향 경로를 안다.
Return Path의 모든 라우터가 Client 방향 경로를 안다.
양쪽 경로의 MTU와 정책이 트래픽을 허용한다.
중간 장비가 반대 방향 트래픽을 반드시 같은 장비에서 보도록 요구하지 않는다.

따라서 다음 두 상황을 구분해야 한다.

Asymmetric Routing + 양방향 경로와 정책 정상 → 통신 가능
Asymmetric Routing + Return Route/State 누락 → 통신 실패

문제는 경로가 다르다는 사실이 아니라, 돌아오는 경로가 없거나 중간 장비의 상태와 맞지 않는다는 점이다.

ㅁ Stateful Firewall은 왜 양방향을 함께 보려 할까?

Stateless Router는 각 패킷의 Destination IP를 보고 독립적으로 전달할 수 있다.

하지만 Stateful Firewall은 요청과 응답을 하나의 연결로 묶어 판단한다.

Client의 SYN이 Firewall A를 지나면 A는 다음과 같은 상태를 만든다.

Client IP:Port → Server IP:Port, TCP SYN 관찰

SYN-ACK이 같은 Firewall A로 돌아오면 기존 연결에 대한 정상 응답으로 허용할 수 있다.

그러나 Return Path가 Firewall B를 지나고 A와 B가 상태를 공유하지 않는다면

B는 SYN-ACK에 대응하는 요청을 본 적이 없다.

Forward : Client → Firewall A → Server  상태는 A에 생성
Return  : Server → Firewall B → Client  B에는 상태 없음

Firewall B는 이 패킷을 비정상적인 새 연결이나 Invalid State로 판단해 차단할 수 있다.

경로는 양쪽 모두 존재하지만 Stateful Policy 때문에 통신이 실패한 것이다.

고가용성 방화벽은 상태 동기화를 사용하기도 하지만 동기화 범위와 장애 전환 동작은 제품과 구성에 따라 다르다.

ㅁ NAT를 지나간 응답은 왜 같은 번역소로 돌아와야 할까?

NAT도 요청을 보면서 주소와 포트의 변환 관계를 기억한다.

내부 10.1.0.10:50000
       ↓ NAT A에서 변환
공인 203.0.113.10:40000

Server의 응답이 NAT A로 돌아오면 저장된 변환 정보를 사용해 원래 내부 주소로 복원할 수 있다.

하지만 응답이 상태를 공유하지 않는 NAT B로 가면 B는 203.0.113.10:40000을 어느 내부 연결로 되돌려야 하는지 모른다.

Forward : Client → NAT A → Server  변환 상태는 A에 있음
Return  : Server → NAT B → Client  B에는 변환 상태 없음

이 때문에 Stateful Firewall, NAT, Load Balancer가 있는 구간에서는 Path Symmetry가 중요한 설계 조건이 될 수 있다.

항상 물리적으로 같은 모든 링크를 거쳐야 한다는 뜻은 아니다.

필요한 연결 상태를 가진 장비 또는 상태가 동기화된 장비를 Return Traffic이 지나야 한다는 뜻이다.

NAT의 주소 변환 과정은 뒤의 Part에서 자세히 다룬다.

ㅁ Source Validation도 비대칭 경로를 막을 수 있다

일부 시스템은 패킷이 들어온 인터페이스가 Source IP로 돌아갈 최적 경로와 맞는지 확인한다.

Linux의 Reverse Path Filtering(rp_filter)이 대표적인 예다.

엄격한 검사에서는 다음과 같이 판단할 수 있다.

패킷 Source IP로 돌아가는 최적 경로는 eth0
그런데 패킷은 eth1으로 들어옴
→ 비정상 Source로 판단해 Drop 가능

이는 Source Address Spoofing을 줄이는 데 도움이 되지만 정상적인 Asymmetric Routing 환경에서는 올바른 패킷을 차단할 수 있다.

Reverse Path 검사에는 엄격한 방식과 느슨한 방식이 있으며 운영체제와 설정에 따라 동작이 다르다.

비대칭 경로를 사용하는 환경에서는 라우팅 정책과 Source Validation 설정을 함께 확인해야 한다.

Linux에서 현재 값을 읽을 수 있다.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

인터페이스별 값도 별도로 존재할 수 있다.

보안 의미를 이해하지 않고 이 값을 끄는 것은 적절한 진단 방법이 아니다.

ㅁ ECMP는 응답도 같은 길로 보내 줄까?

ECMP는 같은 비용의 여러 Next Hop 사이에 트래픽을 분산한다.

라우터는 보통 Source/Destination IP와 Port 같은 Flow 정보를 해시해 하나의 방향에서

같은 Flow가 같은 Next Hop을 사용하도록 한다.

하지만 반대 방향에서는 Source와 Destination이 서로 바뀐다.

장비의 해시 방식과 토폴로지에 따라 Return Path가 다른 링크나 장비를 선택할 수 있다.

Stateless한 네트워크에서는 문제가 없을 수 있지만 특정 Stateful Middlebox를 반드시 통과해야 한다면

정책 기반 라우팅, 상태 동기화, 대칭 해시 설계 같은 추가 고려가 필요하다.

ECMP가 곧 비대칭 장애를 뜻하지는 않는다. 여러 경로와 상태 의존 장비가 만날 때 설계를 확인해야 한다는 뜻이다.

ㅁ 어디에서 사라졌는지 어떻게 찾을까?

왕복 장애는 한 지점의 ping만으로 원인을 확정하기 어렵다.

패킷의 여정을 여러 지점에서 나누어 관찰해야 한다.

ㅇ Client에서 확인한다

Client가 요청을 실제로 내보내는지, 응답이 돌아오는지 본다.

sudo tcpdump -n -i eth0 host 10.2.0.20

ㅇ Server에서 확인한다

요청이 도착했는지, Server가 응답을 생성하는지 본다.

sudo tcpdump -n -i eth0 host 10.1.0.10

ㅇ 각 Router에서 양쪽 인터페이스를 확인한다

요청과 응답이 어느 인터페이스까지 보이는지 비교한다.

sudo tcpdump -n -i any 'host 10.1.0.10 and host 10.2.0.20'

-i any는 어느 인터페이스에서 관찰되었는지 출력과 캡처 형식이 환경에 따라 다를 수 있다. 정확한 입출력 구분이 필요하면 각 인터페이스에서 별도로 캡처한다.

ㅇ 양쪽에서 경로를 조회한다

Client에서 Server 방향을 확인한다.

ip route get 10.2.0.20

Server 또는 Return Router에서 Client 방향을 확인한다.

ip route get 10.1.0.10

한쪽의 ip route get만으로 왕복 경로를 증명할 수 없다. 방향마다 Destination과 Source가 달라지므로 양 끝과 관련 라우터에서 각각 확인해야 한다.

ㅇ Stateful 상태를 확인한다

Firewall과 NAT가 있다면 연결 상태가 어느 장비에 생성되었는지 확인한다. Linux 환경에서는 권한과 구성에 따라 conntrack 도구로 상태를 볼 수 있다.

sudo conntrack -L

이 명령은 연결 수가 많은 운영 장비에서 출력과 부하가 클 수 있다.

실제 환경에서는 주소와 프로토콜 필터를 사용하고 장비별 운영 절차를 따라야 한다.

ㅁ traceroute는 Return Path도 보여 줄까?

traceroute는 목적지 방향으로 TTL을 다르게 한 Probe를 보내고 중간 라우터가 돌려주는 ICMP 응답을 모아 경로를 추정한다.

화면에 표시되는 각 홉의 응답도 다시 관찰자에게 돌아와야 한다.

따라서 traceroute 결과는 순수하게 Forward Path만 복사해 보여 주는 기록이 아니다.

Probe가 나가는 길과 ICMP 응답이 돌아오는 길, 중간 장비의 응답 정책이 함께 영향을 준다.

어떤 홉이 *로 표시된다고 그 지점에서 Forwarding이 반드시 실패했다고 단정할 수 없다.

해당 라우터가 응답하지 않거나 Return Path에서 응답이 사라질 수도 있다.

traceroute는 유용한 단서지만 왕복 경로 전체를 한 번에 증명하는 도구는 아니다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
민수에서 영희로 가는 배달길	Forward Path	요청 패킷이 Source에서 Destination으로 가는 경로
영희에서 민수로 오는 답장길	Return Path	응답 패킷이 원래 Source로 돌아오는 경로
답장 주소에 대한 안내가 없음	Missing Return Route	응답 목적지로 가는 Route가 없는 상태
요청과 답장이 서로 다른 우체국을 지남	Asymmetric Routing	양방향 패킷이 서로 다른 네트워크 경로를 사용
요청을 본 경비실만 답장을 허용	Stateful Firewall	연결 상태를 기준으로 응답 트래픽을 판단하는 장비
번역표를 가진 우체국으로 답장이 돌아옴	NAT State	주소와 Port 변환 관계를 저장한 상태 정보
발신 지역과 들어온 문을 대조	Reverse Path Filtering	Source IP 경로와 수신 인터페이스를 검증하는 기능
여러 길에 같은 흐름을 나누어 배정	ECMP Hashing	Flow 정보를 사용해 여러 Next Hop을 선택하는 방식

왕복 통신의 확인 순서는 다음과 같다.

1. Forward Path에서 요청이 각 구간을 통과하는지 확인한다.
2. Destination이 요청을 받고 응답을 생성하는지 확인한다.
3. Return Path의 각 장비가 Source Network로 가는 Route를 갖는지 확인한다.
4. Firewall, NAT, Load Balancer의 State가 Return Traffic과 일치하는지 확인한다.
5. Source Validation과 정책이 비대칭 경로를 허용하는지 확인한다.

ㅁ 직접 경로를 복원해 보기

다음 캡처 결과를 보고 패킷이 멈춘 위치를 추정해 보자.

Client capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request
10.1.0.10 → 10.2.0.20  ICMP Echo Request

Server capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request
10.2.0.20 → 10.1.0.10  ICMP Echo Reply

R2 transit-side capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request

확인할 수 있는 사실은 다음과 같다.

Echo Request는 Server까지 도착했다.
Server는 Echo Reply를 생성했다.
Reply는 R2의 Server 쪽으로 나왔지만 Transit 쪽에서는 보이지 않는다.
R2의 Client Network Route, Forwarding Policy, Firewall을 우선 확인해야 한다.

이 증거만으로 R2의 Missing Route라고 단정할 수는 없다.

R2 내부의 Firewall이나 Source Validation이 Reply를 Drop했을 가능성도 있기 때문이다.

관찰은 범인을 바로 지목하는 일이 아니라 가능한 실패 범위를 줄이는 일이다.

ㅁ 핵심 정리

Forward Path와 Return Path는 서로 독립적인 Routing Table Lookup 결과다.
요청이 Destination에 도착해도 Return Route가 없으면 통신은 완성되지 않는다.
TCP에서는 SYN이 도착하고 SYN-ACK이 돌아오지 않아 Client가 SYN을 재전송할 수 있다.
ICMP 오류 메시지도 돌아올 경로가 없으면 Client에 도착하지 않는다.
Asymmetric Routing 자체는 IP 네트워크에서 정상적으로 동작할 수 있다.
Stateful Firewall과 NAT는 요청을 본 장비에 상태가 있으므로 Return Path가 달라지면 Drop할 수 있다.
Reverse Path Filtering은 Source Spoofing을 줄이지만 정상 비대칭 경로에 영향을 줄 수 있다.
양 끝과 중간 지점의 캡처 및 양방향 Route Lookup을 함께 봐야 패킷 여정을 복원할 수 있다.
ping과 traceroute 한 가지 결과만으로 단방향 성공과 실패 위치를 확정할 수 없다.

핵심 용어: Forward Path, Return Path, Return Route, Missing Route, Asymmetric Routing, Path Symmetry, Stateful Firewall, NAT State, Reverse Path Filtering, rp_filter, ECMP Hashing, Multi-point Capture

통신은 요청이 도착하는 사건이 아니다. 서로 독립적으로 선택된 가는 길과 오는 길이 모두 이어지는 사건이다.

ㅁ 다음 이야기

경로가 없으면 패킷은 목적지에 도착하지 못한다.

그런데 잘못된 경로가 존재하면 더 이상한 일이 생길 수 있다.

R1은 R2를 가리키고 R2는 다시 R1을 가리키면 패킷은 두 라우터 사이를 계속 맴돈다.

IP 패킷은 이 순환에서 어떻게 빠져나올까?

다음 글에서는 「길을 잃은 편지가 영원히 돌면 어떻게 될까?」라는 질문을 통해

Routing Loop, TTL, ICMP Time Exceeded와 traceroute가 경로를 드러내는 원리를 살펴본다.

[Network] 09. 라우터는 수많은 목적지의 길을 어떻게 고를까?

기록하는 백엔드개발자 — Thu, 16 Jul 2026 20:09:04 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

호스트는 다른 네트워크로 가는 패킷을 Default Gateway에 맡긴다.

라우터는 프레임에서 IP Packet을 꺼내 Destination IP를 확인한다.

이제 패킷을 어느 인터페이스와 Next Hop으로 보낼지 결정해야 한다.

라우터의 Routing Table에 다음 경로가 있다고 생각해 보자.

0.0.0.0/0       → 우체국 A
10.0.0.0/8      → 우체국 B
10.20.0.0/16    → 우체국 C
10.20.30.0/24   → 우체국 D

목적지 10.20.30.40은 네 경로와 모두 일치한다.

그렇다면 어느 길을 선택해야 할까?

가까운 라우터를 선택할까? 먼저 등록된 경로를 선택할까?

Metric이 가장 작은 경로를 선택할까?

라우팅에서 첫 번째 기준은 따로 있다.

목적지와 가장 길게 일치하는 Prefix, 즉 가장 구체적인 경로를 선택한다.

이를 Longest Prefix Match(LPM)라고 한다.

이번 글에서는 Routing Table의 Route Entry가 어떤 정보를 담는지,

LPM이 왜 먼저 적용되는지, 같은 Prefix 후보 사이에서 경로 출처의 선호도와 Metric은 어떤 역할을 하는지 살펴본다.

ㅁ 라우팅 테이블은 전체 여행 경로일까?

우편집중국에는 목적지 지역별로 다음 배송처를 적은 표가 있다.

서울 강남구 → 수도권 남부 집중국
서울 전체   → 수도권 집중국
그 밖의 지역 → 중앙 집중국

이 표는 편지가 최종 목적지까지 거칠 모든 우체국을 순서대로 기록한 여행 계획이 아니다.

현재 우체국이 다음으로 어디에 넘길지를 결정하는 표다.

Routing Table도 마찬가지다.

일반적인 Route Entry에는 다음과 같은 정보가 들어 있다.

정보	의미
Destination Prefix	이 경로가 적용되는 목적지 주소 범위
Next Hop	패킷을 다음으로 전달할 라우터 주소
Outgoing Interface	패킷을 내보낼 인터페이스
Route Source	Connected, Static, OSPF, BGP 등 경로를 알게 된 출처
Preference / Distance	같은 Prefix의 여러 출처 중 어떤 경로를 신뢰할지 판단하는 값
Metric	한 출처 또는 프로토콜 안에서 더 좋은 경로를 비교하는 비용

모든 운영체제와 라우터가 이 정보를 같은 이름과 형식으로 보여 주는 것은 아니다. 하지만 핵심 질문은 같다.

이 목적지 범위의 패킷을 어느 인터페이스와 Next Hop으로 보낼 것인가?

라우터는 패킷마다 Destination IP를 이 표와 비교한다.

ㅁ 하나의 주소가 여러 구역에 포함될 수 있다

10.20.30.40이라는 목적지를 구역별로 살펴보자.

0.0.0.0/0       : 모든 IPv4 주소                → 일치
10.0.0.0/8      : 10으로 시작하는 주소          → 일치
10.20.0.0/16    : 10.20으로 시작하는 주소       → 일치
10.20.30.0/24   : 10.20.30으로 시작하는 주소    → 일치
10.20.30.40/32  : 정확히 10.20.30.40 하나       → 일치

큰 배송 구역 안에 더 작은 구역이 겹쳐 있는 모습이다.

모든 지역 /0
└─ 10 지역 /8
   └─ 10.20 지역 /16
      └─ 10.20.30 지역 /24
         └─ 10.20.30.40 한 주소 /32

목적지 주소는 이 모든 범위에 포함될 수 있다.

이때 /32가 가장 길게 일치하고 가장 구체적이다. /24, /16, /8, /0 순으로 범위가 넓어진다.

Longest Prefix Match는 일치하는 Route Entry 가운데 Prefix Length가 가장 긴 경로를 선택한다.

목적지	선택되는 가장 구체적인 경로
10.20.30.40	10.20.30.40/32
10.20.30.50	10.20.30.0/24
10.20.40.50	10.20.0.0/16
10.30.40.50	10.0.0.0/8
192.0.2.10	0.0.0.0/0

라우터는 테이블의 첫 줄부터 읽고 처음 일치한 경로를 고르는 것이 아니다.

구현 내부에서는 효율적인 검색 구조를 사용할 수 있지만,

외부에서 보이는 선택 결과는 가장 긴 Prefix Match를 따라야 한다.

ㅁ 더 구체적인 안내가 먼저인 이유는 무엇일까?

우편 안내판에 다음 두 문장이 있다고 생각해 보자.

서울로 가는 모든 편지 → 수도권 집중국
서울 강남구 역삼동 편지 → 강남 지역 우체국

역삼동 편지는 두 규칙에 모두 해당한다. 하지만 역삼동을 정확히 가리키는 안내가 서울 전체를 가리키는 안내보다 구체적이다.

네트워크에서도 넓은 범위를 하나의 경로로 묶어 표현하면서 일부 목적지만 예외 경로로 보낼 수 있어야 한다.

10.0.0.0/8      → 기본적으로 Router B
10.20.30.0/24   → 이 구역만 Router D

LPM이 없다면 /8과 /24 가운데 무엇을 먼저 적용할지 테이블 순서나 별도 규칙에 의존해야 한다.

LPM은 Prefix의 구체성이라는 일관된 기준으로 예외 경로를 표현한다.

이 구조 덕분에 다음 두 목표를 함께 달성할 수 있다.

넓은 주소 범위는 Summary Route 하나로 줄여 Routing Table을 작게 유지한다.
특별한 처리가 필요한 작은 범위는 More Specific Route로 덮어쓴다.

이를 Route Aggregation과 More Specific Route의 관계로 볼 수 있다.

ㅁ Default Route는 왜 항상 마지막 후보일까?¡

IPv4 Default Route는 0.0.0.0/0이다.

Prefix Length가 0이므로 모든 IPv4 주소와 일치한다. 동시에 가능한 경로 가운데 가장 덜 구체적이다.

10.20.30.0/24와 일치 → /24 선택
10.20.0.0/16과만 일치 → /16 선택
구체적 경로가 없음   → /0 선택

Default Route가 Routing Table의 위에 표시되더라도 더 구체적인 경로보다 먼저 선택되지 않는다.

Default Route는 다른 길을 모두 이기는 최우선 경로가 아니다.

더 정확한 안내가 없을 때 사용하는 마지막 포괄 경로다.

ㅁ Metric이 낮으면 무조건 선택될까?

다음 두 경로를 보자.

10.0.0.0/8      via Router A metric 10
10.20.30.0/24   via Router B metric 100

목적지 10.20.30.40에는 /8과 /24가 모두 일치한다.

/8의 Metric이 10으로 더 낮지만 /24가 더 긴 Prefix다. 따라서 먼저 /24 경로가 선택된다.

1차 기준: Longest Prefix Match → /24 승리
Metric 비교: 서로 다른 Prefix라면 먼저 비교할 기준이 아님

Metric은 보통 같은 Destination Prefix로 가는 후보 경로를 비교할 때 의미가 있다.

10.20.30.0/24 via Router B metric 100
10.20.30.0/24 via Router C metric 20

경로 출처와 정책 조건이 같다면 더 낮은 Metric의 Router C 경로를 선호할 수 있다.

Metric이 표현하는 의미는 프로토콜마다 다르다.

OSPF는 링크 Cost를 합산한다.
RIP은 Hop Count를 사용한다.
BGP는 단일한 최단거리 Metric보다 여러 Path Attribute와 정책을 비교한다.
운영체제의 Static Route Metric은 경로 우선순위를 나타내는 방식으로 사용될 수 있다.

그래서 서로 다른 프로토콜의 Metric 숫자를 단순 비교해 “20이 100보다 작으니 더 좋다”고 판단할 수는 없다.

ㅁ 서로 다른 출처가 같은 길을 알려 주면 누구를 믿을까?

같은 10.20.30.0/24 경로를 Static Route와 OSPF가 동시에 알려 줄 수 있다.

10.20.30.0/24 → Static Route
10.20.30.0/24 → OSPF Route

Prefix Length는 같다. 하지만 두 경로는 서로 다른 방식으로 학습되었다.

라우팅 시스템은 어떤 출처를 더 선호할지 나타내는 값을 사용할 수 있다. 네트워크 장비에서는 이를 흔히 Administrative Distance(AD) 또는 Route Preference라고 부른다.

일반적으로 값이 낮을수록 더 선호하도록 구현하는 플랫폼이 많지만 기본값과 명칭, 비교 순서는 제조사와 운영체제에 따라 다르다.

중요한 것은 AD와 Metric의 역할을 구분하는 것이다.

Route Preference / AD : 서로 다른 경로 출처 중 무엇을 신뢰할지 비교
Metric                : 선택된 출처나 프로토콜 안에서 어느 경로가 더 좋은지 비교

이를 모든 플랫폼에 동일하게 적용되는 하나의 고정 공식으로 외우면 안 된다.

Linux, 라우터 운영체제, 각 동적 라우팅 프로토콜은 경로를 설치하는 절차와 표시 방식이 다를 수 있다.

공통적으로 기억할 안전한 순서는 다음과 같다.

패킷 전달 시 Destination IP와 가장 길게 일치하는 Prefix를 찾는다.
같은 Prefix의 후보 가운데 정책과 경로 출처의 선호도를 적용한다.
같은 조건의 후보 사이에서 Metric과 프로토콜별 규칙을 적용한다.

ㅁ 비용이 같으면 한 길만 사용해야 할까?

같은 Prefix로 가는 두 경로의 비용이 같을 수 있다.

10.20.30.0/24 via Router B metric 20
10.20.30.0/24 via Router C metric 20

장비와 설정이 지원한다면 두 경로를 모두 활성화할 수 있다.

이를 ECMP(Equal-Cost Multi-Path)라고 한다.

ECMP는 여러 Next Hop에 트래픽을 분산해 링크를 함께 사용하고 하나의 경로에 장애가 생겼을 때 대체 경로를 제공할 수 있다.

패킷을 단순히 한 장씩 번갈아 보내면 순서가 바뀔 수 있으므로 실제 장비는

보통 Source/Destination IP, Port 같은 흐름 정보를 해시해 같은 Flow가 같은 Next Hop을 사용하도록 한다.

정확한 해시 필드와 분산 방식은 장비와 설정에 따라 다르다.

ECMP가 있다고 해서 모든 링크에 정확히 같은 양의 트래픽이 흐르는 것은 아니다.

Flow의 수와 크기가 다르면 분포도 달라질 수 있다.

ㅁ Next Hop도 찾아갈 수 있어야 한다

Route Entry에 Next Hop 주소가 적혀 있다고 해서 바로 프레임을 만들 수 있는 것은 아니다.

다음 경로를 보자.

10.20.30.0/24 via 192.0.2.2 dev eth0

라우터는 192.0.2.2의 MAC 주소를 알아내야 한다.

그러려면 Next Hop이 eth0에서 On-link이거나, Next Hop 자체로 가는 경로를 다시 찾을 수 있어야 한다.

이를 Recursive Next-Hop Resolution이라고 한다.

목적지 10.20.30.40
   ↓ Route Lookup
10.20.30.0/24 via 192.0.2.2
   ↓ Next Hop Resolution
192.0.2.0/24 dev eth0
   ↓ Neighbor Resolution
192.0.2.2의 MAC을 ARP로 조회

Destination Prefix는 맞지만 Next Hop으로 가는 경로가 없다면 해당 Route를 실제 전달에 사용할 수 없다.

Routing Table을 볼 때 목적지 경로뿐 아니라 Next Hop이 어느 인터페이스에서 해결되는지도 함께 확인해야 한다.

ㅁ 더 구체적인 경로가 오히려 편지를 사라지게 할 수 있다

LPM은 일관된 규칙이지만 경로 정보가 올바르다는 사실까지 보장하지는 않는다.

다음 테이블을 보자.

10.20.30.0/24    via 정상 Router
10.20.30.40/32   blackhole

10.20.30.50은 /24 경로를 따라 정상적으로 전달된다.

하지만 10.20.30.40은 더 구체적인 /32 Blackhole Route와 일치하므로 폐기된다.

10.20.30.40 → /32 Blackhole 선택 → 폐기
10.20.30.50 → /24 정상 경로 선택 → 전달

주변 주소는 모두 되는데 특정 IP 하나만 통신되지 않는다면 More Specific Route를 의심할 수 있다.

Blackhole Route는 트래픽을 의도적으로 조용히 폐기한다.

반복되는 잘못된 트래픽을 막거나 경로 루프를 방지하는 용도로 사용할 수 있지만, 잘못 설정하면 찾기 어려운 장애를 만든다.

운영체제에 따라 unreachable, prohibit 같은 경로 유형도 있으며

패킷을 폐기하면서 호출자에게 돌려주는 오류가 다를 수 있다.

LPM은 가장 올바른 경로가 아니라 가장 구체적으로 일치하는 경로를 고른다.

ㅁ RIB와 FIB는 무엇이 다를까?

라우팅 프로토콜과 정적 설정을 통해 여러 후보 경로가 들어오면 제어 영역은 최적 경로를 선택한다.

이 경로 정보를 다루는 논리적인 테이블을 흔히 RIB(Routing Information Base)라고 한다.

실제 패킷을 빠르게 전달하기 위해 선택된 경로는 전달에 적합한 형태로 FIB(Forwarding Information Base)에 반영된다.

Connected / Static / OSPF / BGP
              ↓
       RIB에서 경로 선택
              ↓
       FIB에 전달 정보 반영
              ↓
    Packet별 빠른 Forwarding Lookup

장비와 운영체제에 따라 테이블 구조와 이름은 다르지만 개념적인 역할은 구분할 수 있다.

Control Plane은 경로를 학습하고 최적 경로를 계산한다.
Data Plane은 선택된 정보를 사용해 실제 패킷을 전달한다.

Routing Table이라는 표현이 문맥에 따라 RIB 또는 사용자에게 보이는 선택 경로를 포괄해 사용되기도 한다.

입문 단계에서는 경로를 만드는 과정과 패킷을 전달하는 과정을 나누어 이해하는 것이 중요하다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
목적지 지역별 다음 배송처 표	Routing Table	Destination Prefix와 Next Hop, Interface를 연결한 정보
배송 구역 한 줄	Route Entry	특정 Prefix에 적용되는 하나의 경로 항목
가장 상세한 주소 안내를 우선	Longest Prefix Match	일치하는 경로 중 Prefix Length가 가장 긴 항목 선택
전국 단위의 포괄 안내	Summary Route	여러 작은 주소 범위를 하나로 묶은 경로
특정 동네만 다른 길로 보내는 예외	More Specific Route	더 긴 Prefix로 일부 목적지를 별도 처리하는 경로
안내 정보의 출처 신뢰도	Administrative Distance / Preference	같은 Prefix의 서로 다른 출처를 비교하는 기준
같은 방식의 길 가운데 드는 비용	Metric	프로토콜 안에서 경로 품질을 비교하는 값
비용이 같은 여러 배송길	ECMP	같은 비용의 여러 Next Hop을 함께 사용하는 방식
의도적으로 폐기하는 주소 안내	Blackhole Route	일치하는 패킷을 전달하지 않고 폐기하는 경로
경로 후보를 관리하는 지도	RIB	제어 영역의 라우팅 정보 기반
실제 분류 창구가 사용하는 지도	FIB	패킷 전달에 사용하는 Forwarding 정보 기반

경로 선택의 핵심 흐름은 다음과 같다.

1. Destination IP와 일치하는 Prefix를 모두 찾는다.
2. Longest Prefix Match로 가장 구체적인 Prefix를 선택한다.
3. 같은 Prefix 후보에 경로 출처의 Preference와 정책을 적용한다.
4. 같은 조건의 후보를 Metric과 프로토콜 규칙으로 비교한다.
5. 선택된 Next Hop과 Outgoing Interface로 패킷을 전달한다.

ㅁ 직접 경로를 골라 보기

다음 Routing Table을 보고 각 목적지에 선택될 경로를 찾아보자.

0.0.0.0/0        via A
172.16.0.0/12    via B
172.16.0.0/16    via C
172.16.10.0/24   via D
172.16.10.128/25 via E

목적지	일치하는 가장 긴 Prefix	선택 Next Hop
8.8.8.8	0.0.0.0/0	A
172.20.1.1	172.16.0.0/12	B
172.16.200.1	172.16.0.0/16	C
172.16.10.20	172.16.10.0/24	D
172.16.10.200	172.16.10.128/25	E

/12의 범위는 두 번째 옥텟 기준으로 16~31이므로 172.20.1.1도 포함한다.

Linux에서는 Main Routing Table을 확인할 수 있다.

ip -4 route show table main

특정 목적지에 실제 선택되는 경로를 확인한다.

ip route get 8.8.8.8
ip route get 172.16.10.200

출력에서 via, dev, src를 살펴본다.

via : 선택된 Next Hop
dev : Outgoing Interface
src : 패킷에 사용할 Source IP

현재 테이블에 예제 Prefix가 없다면 실제 결과는 예제 표와 다르다. 명령의 목적은 시스템이 가진 경로에서 특정 Destination IP에 어떤 Route를 선택하는지 확인하는 것이다.

라우팅 설정을 추가하거나 Blackhole Route를 만드는 작업은 실제 통신을 끊을 수 있으므로 운영 환경에서는 읽기 명령으로만 관찰한다.

ㅁ 핵심 정리

Routing Table의 Route Entry는 Destination Prefix, Next Hop, Interface, Source와 비용 정보를 담는다.
하나의 Destination IP는 여러 Prefix와 동시에 일치할 수 있다.
라우터는 가장 긴 Prefix가 일치하는 경로를 먼저 선택한다.
Default Route /0은 모든 주소와 일치하지만 가장 덜 구체적인 마지막 후보다.
서로 다른 Prefix에서는 Metric이 낮다는 이유로 더 구체적인 경로를 이길 수 없다.
같은 Prefix 후보 사이에서는 경로 출처의 Preference, 정책, Metric과 프로토콜 규칙이 적용된다.
동일 비용 경로는 장비와 설정에 따라 ECMP로 함께 사용할 수 있다.
Next Hop 자체도 연결된 경로나 다른 Route를 통해 해결할 수 있어야 한다.
잘못된 More Specific Route는 특정 목적지만 사라지는 장애를 만들 수 있다.
RIB는 경로 학습과 선택에, FIB는 실제 Packet Forwarding에 초점을 둔다.

핵심 용어: Routing Table, Route Entry, Destination Prefix, Longest Prefix Match, Summary Route, More Specific Route, Administrative Distance, Route Preference, Metric, ECMP, Recursive Next-Hop Resolution, Blackhole Route, RIB, FIB, Control Plane, Data Plane

라우터는 가장 가까워 보이는 길을 고르지 않는다. 목적지 주소와 가장 구체적으로 일치하는 안내를 먼저 따른다.

ㅁ 다음 이야기

라우터는 Longest Prefix Match를 사용해 요청 패킷의 다음 길을 선택했다.

그렇다면 요청이 목적지에 도착한 순간 통신도 성공한 것일까?

응답 패킷은 요청이 지나온 길을 기억해 그대로 되돌아가는 것이 아니다.

목적지 호스트와 각 라우터는 응답의 Destination IP를 기준으로 새로운 경로 선택을 수행한다.

다음 글에서는 「가는 길이 있으면 돌아오는 길도 있는 것일까?」라는 질문을 통해

Forward Path, Return Path, Asymmetric Routing과 Missing Route가 만드는 장애를 살펴본다.

[Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까?

기록하는 백엔드개발자 — Thu, 16 Jul 2026 20:08:05 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 2. 편지에 두 종류의 주소가 필요한 이유

ㅁ 들어가며

호스트는 Subnet Mask와 라우팅 테이블을 사용해 목적지가 같은 네트워크인지 판단한다.

같은 네트워크의 On-link 목적지라면 상대의 MAC 주소를 ARP로 찾고 직접 프레임을 보낼 수 있다.

하지만 목적지가 다른 네트워크에 있다면 이야기가 달라진다.

PC A
IP 192.168.10.10/24

목적지
IP 192.168.20.20

PC A는 192.168.20.20이 자신의 네트워크인 192.168.10.0/24 밖에 있다는 사실은 안다.

그러나 목적지까지 이어지는 모든 라우터와 링크를 알지는 못한다.

그렇다면 첫 프레임을 누구에게 맡겨야 할까?

우리가 다른 지역으로 편지를 보낼 때 전국의 모든 배달길을 직접 고르지 않는 것과 같다.

주소를 적은 편지를 동네 우체국에 맡기면 우체국이 다음 지역으로 전달한다.

네트워크에서 이 첫 번째 우체국 역할을 하는 장비가 Default Gateway다.

이번 글에서는 Default Route, Next Hop, ARP, IP Forwarding이 어떻게 연결되는지,

그리고 라우터를 지날 때 IP 패킷과 Ethernet Frame 중 무엇이 유지되고 무엇이 바뀌는지 살펴본다.

ㅁ 모든 목적지의 길을 호스트가 알아야 할까?

인터넷에는 수많은 네트워크가 있다.

PC가 각 네트워크로 가는 경로를 모두 저장해야 한다면 다음과 같은 지도가 필요하다.

192.168.20.0/24는 Router A로
172.16.0.0/16은 Router B로
10.20.30.0/24는 Router C로
그 밖의 수많은 네트워크는 ...

일반 호스트가 인터넷 전체의 경로를 알고 관리하는 것은 비효율적이다.

호스트가 꼭 알아야 하는 것은 더 단순하다.

직접 연결된 네트워크는 자신의 인터페이스로 보낸다.
나머지 목적지는 동네 밖 출구에 맡긴다.

이때 “더 구체적인 경로가 없는 모든 목적지”에 사용하는 경로가 Default Route다.

IPv4에서는 다음 Prefix로 표현한다.

0.0.0.0/0

Prefix Length가 0이라는 것은 어떤 목적지 주소와도 일치할 수 있다는 뜻이다.

Linux 라우팅 테이블에서는 다음과 같이 보일 수 있다.

default via 192.168.10.1 dev eth0

이를 풀어 쓰면 다음과 같다.

더 구체적인 경로가 없는 목적지는
eth0 인터페이스를 통해
다음 홉 192.168.10.1로 보내라.

여기서 192.168.10.1이 PC A의 Default Gateway다.

ㅁ Default Gateway와 Default Route는 같은 말일까?

두 용어는 밀접하지만 가리키는 대상이 다르다.

ㅇ Default Route는 경로 규칙이다

특정 목적지와 일치하는 더 구체적인 경로가 없을 때 사용할 라우팅 테이블의 항목이다.

Destination Prefix : 0.0.0.0/0
Next Hop           : 192.168.10.1
Output Interface   : eth0

ㅇ Default Gateway는 다음으로 넘겨받을 장비다

Default Route가 선택되었을 때 패킷을 전달받는 현재 링크의 라우터다.

Default Route   : 모르는 목적지에 적용할 규칙
Default Gateway : 그 규칙이 가리키는 다음 라우터

일상에서는 두 표현을 비슷하게 사용하지만 장애를 분석할 때는 구분하는 것이 좋다.

Default Route 자체가 없을 수 있다.
Route는 있지만 잘못된 Gateway를 가리킬 수 있다.
Gateway IP는 맞지만 ARP로 MAC 주소를 찾지 못할 수 있다.
Gateway까지는 전달되지만 라우터가 다음 경로를 모를 수 있다.

“게이트웨이 문제”라는 한 문장 안에도 서로 다른 실패 지점이 있다.

ㅁ 게이트웨이는 어디에 있어야 할까?

PC A가 Default Gateway 192.168.10.1에게 Ethernet Frame을 보내려면

게이트웨이의 MAC 주소를 알아야 한다.

ARP는 같은 Broadcast Domain 안에서만 동작한다.

따라서 일반적인 구성에서 Default Gateway의 IP 주소는

호스트가 직접 도달할 수 있는 On-link Network에 있어야 한다.

PC A       : 192.168.10.10/24
Gateway    : 192.168.10.1/24
같은 Subnet: 192.168.10.0/24

PC A는 다음 ARP Request를 보낼 수 있다.

Who has 192.168.10.1?
Tell 192.168.10.10

게이트웨이가 다음처럼 응답한다고 하자.

192.168.10.1 is at 11:11:11:11:11:01

이제 PC A는 원격 목적지로 가는 첫 프레임을 만들 수 있다.

Default Gateway가 꼭 .1 주소일 필요는 없다.

.254나 다른 사용 가능한 주소도 될 수 있다.

중요한 것은 관습적인 숫자가 아니라 호스트의 라우팅 설정이 가리키는 On-link 라우터라는 점이다.

가정이나 사무실에서는 DHCP의 Router Option을 통해 Default Gateway 주소를 자동으로 받는 경우가 많다.

정적으로 설정할 수도 있다.

ㅁ 최종 목적지는 서버인데 왜 프레임은 게이트웨이에게 보낼까?

PC A가 PC B로 보내는 패킷을 살펴보자.

PC A
IP  : 192.168.10.10/24
MAC : AA:AA:AA:AA:AA:AA

Router R1 - 왼쪽 인터페이스
IP  : 192.168.10.1/24
MAC : 11:11:11:11:11:01

Router R1 - 오른쪽 인터페이스
IP  : 192.168.20.1/24
MAC : 11:11:11:11:11:02

PC B
IP  : 192.168.20.20/24
MAC : BB:BB:BB:BB:BB:BB

전체 구조는 다음과 같다.

PC A ── 192.168.10.0/24 ── R1 ── 192.168.20.0/24 ── PC B

PC A가 만드는 IP Packet의 목적지는 처음부터 PC B다.

IP Header
├─ Source IP      : 192.168.10.10
└─ Destination IP : 192.168.20.20

그러나 현재 Ethernet Link에서 직접 프레임을 받을 장비는 R1이다.

Ethernet Header
├─ Source MAC      : AA:AA:AA:AA:AA:AA
└─ Destination MAC : 11:11:11:11:11:01

두 목적지는 서로 다르다.

IP Destination       : 전체 여정의 최종 목적지 PC B
Ethernet Destination : 현재 링크의 다음 홉 R1

우편 봉투에는 최종 수신인의 주소를 적지만, 현재 배달 단계에서는 동네 우체국이 편지를 먼저 넘겨받는 것과 같다.

ㅁ 라우터는 받은 프레임을 그대로 넘길까?

PC A가 보낸 Ethernet Frame은 R1의 왼쪽 인터페이스에 도착한다.

R1은 목적지 MAC 주소가 자신의 인터페이스 주소이므로 프레임을 받아들인다.

그 뒤 다음 순서로 처리한다.

ㅇ 1단계: Ethernet Header를 벗긴다

현재 링크에서 사용한 Ethernet Header와 Trailer를 처리하고 안쪽의 IP Packet을 확인한다.

[Ethernet Header][IP Packet][Ethernet Trailer]
        ↓ 제거          ↓
                  [IP Packet]

ㅇ 2단계: Destination IP를 확인한다

Destination IP 192.168.20.20은 라우터 자신의 주소가 아니다.

R1은 이 패킷을 다른 인터페이스로 전달해야 하는지 판단한다.

ㅇ 3단계: TTL을 1 줄인다

라우터는 IPv4 Header의 TTL 값을 1 감소시킨다. TTL이 0이 되면 패킷을 폐기한다.

TTL이 변경되므로 IPv4 Header Checksum도 다시 계산해야 한다.

ㅇ 4단계: 라우팅 테이블을 조회한다

R1은 Destination IP와 일치하는 경로를 찾는다.

192.168.20.0/24 dev eth1

목적지가 오른쪽 인터페이스에 직접 연결되어 있음을 알 수 있다.

ㅇ 5단계: 다음 L2 수신인의 MAC을 찾는다

PC B의 MAC 주소가 Neighbor Table에 없다면 R1은 오른쪽 네트워크에서 192.168.20.20을 ARP로 찾는다.

192.168.20.20 → BB:BB:BB:BB:BB:BB

ㅇ 6단계: 새 Ethernet Frame을 만든다

R1은 같은 IP Packet을 오른쪽 링크에 맞는 새 Ethernet Frame에 넣는다.

Ethernet Header
├─ Source MAC      : 11:11:11:11:11:02
└─ Destination MAC : BB:BB:BB:BB:BB:BB

IP Header
├─ Source IP      : 192.168.10.10
└─ Destination IP : 192.168.20.20

새 프레임의 FCS도 해당 링크에서 전송할 내용에 맞게 만들어진다.

라우터는 PC A의 Ethernet Frame을 그대로 연장하지 않는다.

IP Packet을 꺼내 다음 경로를 판단한 뒤, 새 링크의 Source MAC과 Destination MAC으로 다시 캡슐화한다.

ㅁ 주소는 여정에서 어떻게 바뀔까?

PC A에서 R1을 거쳐 PC B까지의 주소를 표로 비교해 보자.

구간	Source MAC	Destination MAC	Source IP	Destination IP
PC A → R1	PC A MAC	R1 왼쪽 MAC	PC A IP	PC B IP
R1 → PC B	R1 오른쪽 MAC	PC B MAC	PC A IP	PC B IP

MAC 주소는 링크마다 바뀐다.

IP 주소는 일반적인 라우팅 과정에서 최종 목적지까지 유지된다.

다만 TTL과 IPv4 Header Checksum 같은 헤더 값은 라우터를 지날 때 바뀐다.

MAC Address : Hop-by-Hop
IP Address  : End-to-End 목적지 표현

이 차이를 이해하면 “원격 서버의 MAC 주소를 왜 내 PC에서 볼 수 없는가?”라는 질문에도 답할 수 있다.

내 PC가 알아야 하는 것은 원격 서버의 MAC 주소가 아니라 현재 링크에서 첫 프레임을 받을 Default Gateway의 MAC 주소다.

ㅁ 라우터는 왜 패킷을 전달할 수 있을까?

IP 주소를 가진 모든 장비가 자동으로 라우터가 되는 것은 아니다.

라우터 역할을 하려면 보통 다음 조건이 필요하다.

둘 이상의 네트워크에 연결된 인터페이스가 있다.
목적지에 맞는 라우팅 정보가 있다.
인터페이스 사이의 IP Forwarding이 활성화되어 있다.
방화벽과 정책이 해당 전달을 허용한다.

일반 호스트는 자신의 IP를 목적지로 하는 패킷을 처리하지만 다른 호스트의 패킷을 인터페이스 사이로 넘기지 않는 것이 기본인 경우가 많다.

Linux에서는 IPv4 Forwarding 상태를 다음과 같이 읽을 수 있다.

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 0  → IPv4 Forwarding 비활성
net.ipv4.ip_forward = 1  → IPv4 Forwarding 활성

Forwarding이 활성화되어 있어도 경로나 방화벽 정책이 올바르지 않으면 패킷은 전달되지 않는다.

Default Gateway는 단순히 IP 주소가 하나 더 설정된 장비가 아니라, 다른 네트워크로 패킷을 전달할 준비가 된 라우터여야 한다.

ㅁ 기본 경로가 없으면 어떤 일이 생길까?

PC A의 라우팅 테이블에 직접 연결된 경로만 있다고 하자.

192.168.10.0/24 dev eth0

목적지 192.168.20.20은 이 경로에 포함되지 않는다.

Default Route도 없다면 운영체제는 패킷을 어느 인터페이스와 Next Hop으로 보낼지 결정할 수 없다.

애플리케이션에서는 다음과 같은 즉시 오류를 볼 수 있다.

Network is unreachable

이 오류는 패킷이 먼 네트워크에서 사라졌다는 뜻이 아니다.

로컬 호스트가 보낼 경로를 찾지 못해 출발조차 하지 못했을 가능성을 나타낸다.

반면 Default Route는 있지만 Gateway의 MAC 주소를 ARP로 찾지 못하는 경우에는

ARP 재시도 뒤 지연되거나 Host Unreachable 계열 오류가 나타날 수 있다.

Default Route 없음
→ 경로 선택 실패
→ 출발 전 즉시 오류 가능

Default Route 있음, Gateway ARP 실패
→ 링크에서 이웃 탐색 재시도
→ 지연 후 실패 가능

겉으로는 모두 “인터넷이 안 된다”지만 실패한 단계는 다르다.

ㅁ Default Route가 여러 개일 수도 있을까?

노트북에 유선과 무선이 함께 연결되거나 라우터에 여러 인터넷 회선이 있으면 Default Route가 여러 개 존재할 수 있다.

default via 192.168.10.1 dev eth0 metric 100
default via 192.168.30.1 dev wlan0 metric 600

같은 목적지 Prefix에 여러 경로가 있을 때 운영체제는 Metric과 정책 같은 정보를 사용해 경로를 선택할 수 있다.

Metric이 낮은 경로를 더 선호하는 구성이 흔하지만 정확한 선택 규칙은 운영체제, 라우팅 프로토콜, 정책 라우팅 구성에 따라 달라질 수 있다.

Default Route는 반드시 하나뿐이라는 규칙이 아니다.

또한 Default Route보다 더 구체적인 목적지 경로가 있으면 구체적인 경로가 우선한다.

10.20.0.0/16 via 192.168.10.2
default       via 192.168.10.1

목적지 10.20.30.40은 /16 경로를 사용하고, 일치하는 구체적 경로가 없는 다른 목적지는 Default Route를 사용한다.

왜 구체적인 경로가 먼저 선택되는지는 다음 글의 Longest Prefix Match에서 자세히 살펴본다.

ㅁ 편지가 도착하면 통신이 끝난 것일까?

PC A의 패킷이 R1을 거쳐 PC B에 도착했다.

그러나 통신이 완성되려면 PC B의 응답도 PC A로 돌아와야 한다.

PC B 역시 192.168.10.10이 자신의 네트워크 밖에 있다는 것을 판단하고 자신의 Default Gateway인 192.168.20.1로 답장을 보낸다.

이 예제에서는 같은 R1이 양쪽 네트워크에 직접 연결되어 있으므로 돌아오는 경로도 알고 있다.

실제 네트워크에서는 요청 경로와 응답 경로가 서로 별개의 라우팅 결정이다. 가는 길이 존재한다고 돌아오는 길이 자동으로 보장되는 것은 아니다.

이 문제는 Part 3의 「가는 길이 있으면 돌아오는 길도 있는 것일까?」에서 더 자세히 다룬다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
동네 밖 편지를 맡기는 우체국	Default Gateway	구체적인 경로가 없는 원격 패킷을 처음 전달받는 라우터
모르는 모든 지역에 적용할 규칙	Default Route	IPv4에서는 0.0.0.0/0으로 표현하는 기본 경로
편지를 다음으로 넘겨받는 우체국	Next Hop	현재 장비가 패킷을 전달할 다음 라우터 또는 이웃
우체국까지의 현재 배달 봉투	Ethernet Frame	한 링크 안에서 다음 L2 수신인에게 전달하는 단위
봉투 안의 최종 주소가 적힌 편지	IP Packet	여러 네트워크를 지나 최종 목적지를 나타내는 단위
편지를 꺼내 새 봉투에 넣음	Re-encapsulation	라우터가 다음 링크의 L2 헤더로 패킷을 다시 감싸는 과정
다른 지역으로 편지를 넘김	IP Forwarding	수신한 IP 패킷을 다른 인터페이스로 전달하는 기능
지금 구간의 배달 주소	Hop-by-Hop MAC Address	링크마다 바뀌는 Source와 Destination MAC 주소

호스트에서 라우터를 거쳐 목적지까지의 흐름은 다음과 같다.

1. Destination IP에 대해 Routing Table을 조회한다.
2. Default Route가 선택되면 Next Hop인 Gateway를 확인한다.
3. Gateway MAC을 Neighbor Table에서 찾거나 ARP로 조회한다.
4. IP Packet을 Gateway MAC 목적지의 Ethernet Frame에 넣어 보낸다.
5. Router는 L2 Header를 벗기고 TTL을 줄인 뒤 경로를 조회한다.
6. 다음 링크의 MAC 주소로 새 Frame을 만들어 전달한다.

ㅁ 직접 확인해 보기

Linux에서 현재 라우팅 테이블을 확인한다.

ip -4 route show

다음과 같은 항목을 찾는다.

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 scope link src 192.168.10.10

특정 원격 목적지에 선택되는 Gateway, Interface, Source IP를 확인한다.

ip route get 8.8.8.8

예상 결과의 핵심은 다음과 같다.

8.8.8.8 via 192.168.10.1 dev eth0 src 192.168.10.10

게이트웨이의 MAC 주소가 이웃 테이블에 있는지도 살펴본다.

ip neigh show 192.168.10.1

첫 홉을 숫자 주소로 확인하려면 다음 명령을 사용할 수 있다.

traceroute -n 8.8.8.8

환경에 따라 traceroute가 설치되어 있지 않거나 방화벽과 ICMP 정책 때문에 일부 홉이 응답하지 않을 수 있다.

첫 홉이 항상 화면에 보인다고 보장할 수는 없다.

macOS에서는 다음 명령으로 기본 경로와 목적지 경로를 확인할 수 있다.

route -n get default
route -n get 8.8.8.8

운영 중인 환경에서 Default Route를 삭제하거나 Gateway를 변경하면

현재 연결이 즉시 끊어질 수 있으므로 읽기 명령으로 상태만 관찰한다.

ㅁ 핵심 정리

호스트는 모든 인터넷 경로를 저장하지 않고 구체적 경로가 없는 목적지를 Default Route로 보낸다.
IPv4 Default Route는 0.0.0.0/0으로 표현한다.
Default Gateway는 Default Route가 가리키는 현재 링크의 Next Hop 라우터다.
일반적으로 Gateway는 호스트가 ARP로 MAC 주소를 찾을 수 있는 On-link Network에 있어야 한다.
원격 통신에서 IP Destination은 최종 서버지만 첫 Ethernet Destination은 Gateway MAC이다.
라우터는 L2 Header를 벗기고 TTL을 줄인 뒤 경로를 조회해 다음 링크의 새 Frame으로 Re-encapsulation한다.
MAC 주소는 링크마다 바뀌고 IP Source와 Destination은 일반적인 라우팅 중 유지된다.
IP 주소가 여러 개 있다고 자동으로 라우터가 되는 것은 아니며 IP Forwarding, 경로, 정책이 필요하다.
Default Route가 없을 때와 Gateway ARP가 실패할 때는 장애가 발생하는 단계가 다르다.

핵심 용어: Default Gateway, Default Route, 0.0.0.0/0, Next Hop, Routing Table, ARP, IP Forwarding, Re-encapsulation, Hop-by-Hop, TTL, IPv4 Header Checksum, Metric

Default Gateway는 최종 목적지를 대신하는 주소가 아니다.
호스트가 모르는 먼 길을 처음 맡아 줄 수 있는 같은 동네의 라우터다.

ㅁ 다음 이야기

호스트는 자신이 모르는 목적지를 Default Gateway에 맡겼다.

이제 라우터는 Routing Table에서 패킷을 보낼 다음 길을 선택해야 한다.

그런데 하나의 Destination IP가 여러 경로 Prefix와 동시에 일치하면 어느 길을 선택해야 할까?

다음 글에서는 「라우터는 수많은 목적지의 길을 어떻게 고를까?」라는 질문을 통해 Routing Table, Route Entry, Longest Prefix Match, Administrative Distance와 Metric의 역할을 구분해 본다.

[Network] 07. 같은 동네와 다른 동네는 누가 판단할까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 23:37:33 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 2. 편지에 두 종류의 주소가 필요한 이유

ㅁ 들어가며

앞의 글에서 ARP는 IPv4 주소에 대응하는 MAC 주소를 찾는다고 했다.

하지만 ARP Request는 같은 Broadcast Domain 안에서만 전달된다.

라우터는 일반적으로 이 브로드캐스트를 다른 네트워크로 넘기지 않는다.

PC A가 다음 목적지로 데이터를 보낸다고 생각해 보자.

내 IP 주소 : 192.168.10.70
목적지 A   : 192.168.10.120
목적지 B   : 192.168.10.130

세 주소가 모두 192.168.10으로 시작한다. 그러면 둘 다 같은 동네일까?

주소의 겉모습만으로는 알 수 없다.

PC는 패킷을 보내기 전에 먼저 다음 결정을 내려야 한다.

같은 네트워크라면 → 목적지의 MAC 주소를 ARP로 찾는다.
다른 네트워크라면 → 기본 게이트웨이의 MAC 주소를 ARP로 찾는다.

이 경계를 알려 주는 정보가 Subnet Mask이며, 이를 간단히 표현하는 방법이 Prefix Length다.

이번 글에서는 IPv4 주소의 비트 구조, /24의 의미, Network Address를 계산하는 AND 연산, On-link와 Off-link 판단을 살펴본다.

ㅁ 주소만 적으면 동네의 경계를 알 수 있을까?

192.168.10.70이라는 IPv4 주소를 보자.

사람이 읽기 쉽게 점으로 나뉜 네 개의 숫자로 표시하지만, 컴퓨터는 32개의 비트로 처리한다.

192        168        10         70
11000000 . 10101000 . 00001010 . 01000110

이 32비트 안에는 네트워크를 나타내는 부분과 그 네트워크 안의 호스트를 나타내는 부분이 함께 있다.

[ Network Portion ][ Host Portion ]

문제는 IP 주소만 봐서는 두 부분의 경계가 어디인지 알 수 없다는 점이다.

같은 192.168.10.70이라도 다음처럼 해석할 수 있다.

192.168.10.70/24 → 앞 24비트가 Network Portion
192.168.10.70/26 → 앞 26비트가 Network Portion

주소는 같지만 /24와 /26은 서로 다른 크기의 동네를 만든다.

IP 주소와 Prefix Length는 함께 있어야 완전한 네트워크 주소 정보를 표현할 수 있다.

ㅁ Subnet Mask는 경계선을 그린다

Subnet Mask도 IPv4 주소와 같은 32비트다.

네트워크 부분에는 연속된 1, 호스트 부분에는 연속된 0을 둔다.

IP Address  : 11000000.10101000.00001010.01000110
Subnet Mask : 11111111.11111111.11111111.00000000

Subnet Mask를 십진수로 표현하면 다음과 같다.

255.255.255.0

앞에서부터 1인 비트가 24개이므로 더 간단히 /24라고 쓴다.

이를 CIDR Prefix Length라고 한다.

255.0.0.0       = /8
255.255.0.0     = /16
255.255.255.0   = /24
255.255.255.192 = /26

Prefix Length가 길수록 네트워크 부분이 많고 호스트 부분은 적어진다. 따라서 하나의 서브넷에 포함되는 주소의 수는 줄어든다.

/24 → Host bit 8개  → 2^8  = 256개 주소
/26 → Host bit 6개  → 2^6  = 64개 주소
/30 → Host bit 2개  → 2^2  = 4개 주소

과거의 Class A, B, C 방식보다 필요한 크기에 맞춰 Prefix Length를 정하는 CIDR(Classless Inter-Domain Routing) 방식이 현재 주소 표현과 라우팅의 기본이다.

ㅁ 동네 이름은 어떻게 계산할까?

호스트가 속한 네트워크를 나타내는 주소를 Network Address라고 한다.

IP 주소와 Subnet Mask를 비트 단위 AND 연산하면 Network Address를 구할 수 있다.

AND 연산은 두 비트가 모두 1일 때만 결과가 1이다.

192.168.10.70/24를 계산해 보자.

IP Address   11000000.10101000.00001010.01000110
Subnet Mask  11111111.11111111.11111111.00000000
             ----------------------------------- AND
Network      11000000.10101000.00001010.00000000

십진수로 바꾸면 다음과 같다.

192.168.10.0/24

Subnet Mask의 1 영역은 IP 주소의 네트워크 비트를 남기고, 0 영역은 호스트 비트를 모두 0으로 만든다.

그래서 Network Address는 해당 서브넷 자체를 나타낸다.

일반적인 IPv4 서브넷에서는 호스트 인터페이스에 Network Address를 할당하지 않는다.

ㅁ 목적지에도 내 마스크를 적용한다

PC가 목적지를 같은 네트워크로 판단할 때 목적지의 Subnet Mask를 물어보는 것은 아니다.

송신자는 자신의 인터페이스에 설정된 Prefix를 기준으로 목적지 주소가 연결된 네트워크에 포함되는지 판단한다.

다음 설정을 보자.

내 IP Address : 192.168.10.70
Subnet Mask   : 255.255.255.192
Prefix Length : /26

/26의 마지막 옥텟 마스크는 192, 이진수로 11000000이다.

먼저 자신의 Network Address를 계산한다.

70    = 01000110
192   = 11000000
        -------- AND
64    = 01000000

따라서 자신의 네트워크는 192.168.10.64/26이다.

목적지 192.168.10.120에도 같은 /26 마스크를 적용한다.

120   = 01111000
192   = 11000000
        -------- AND
64    = 01000000

결과가 자신의 Network Address와 같은 192.168.10.64다.

따라서 같은 네트워크의 이웃, 즉 On-link Destination으로 판단한다.

이번에는 목적지 192.168.10.130을 계산한다.

130   = 10000010
192   = 11000000
        -------- AND
128   = 10000000

결과는 192.168.10.128이다.

자신의 Network Address인 192.168.10.64와 다르다.

따라서 192.168.10.130은 직접 연결된 네트워크 밖의 Off-link Destination으로 판단한다.

주소 앞부분이 192.168.10으로 같아 보여도 /26 경계에서는 서로 다른 동네다.

ㅁ /26은 동네를 어떻게 나눌까?

192.168.10.0/24를 /26으로 더 작게 나누면 64개 주소씩 네 개의 서브넷이 생긴다.

서브넷	Network Address	일반 호스트 범위	Broadcast Address
첫 번째	192.168.10.0/26	192.168.10.1~62	192.168.10.63
두 번째	192.168.10.64/26	192.168.10.65~126	192.168.10.127
세 번째	192.168.10.128/26	192.168.10.129~190	192.168.10.191
네 번째	192.168.10.192/26	192.168.10.193~254	192.168.10.255

각 서브넷에서 호스트 비트가 모두 0이면 Network Address다.

호스트 비트가 모두 1이면 해당 서브넷의 모든 호스트를 대상으로 하는 Directed Broadcast Address다.

일반적인 호스트 주소로는 사용하지 않는다.

그래서 전통적인 일반 IPv4 서브넷에서는 전체 주소 수에서 Network Address와 Broadcast Address를 제외해

사용 가능한 호스트 주소 수를 계산한다.

/26 전체 주소 64개
일반 호스트 주소 62개

다만 모든 Prefix에 이 공식을 기계적으로 적용하면 안 된다. /31은 점대점 링크에서 두 주소를 모두 사용할 수 있도록 정의되어 있고, /32는 하나의 호스트 또는 경로를 나타내는 데 사용한다.

기본 계산법을 이해하되 실제 사용 방식에는 예외가 있다는 점을 함께 기억해야 한다.

ㅁ 같은 동네라면 누구의 MAC 주소를 찾을까?

Network Address 비교가 끝나면 실제 전달 대상이 결정된다.

ㅇ On-link Destination

목적지가 같은 네트워크에 있으면 목적지 호스트의 MAC 주소를 ARP로 찾는다.

IP Destination  : 192.168.10.120
ARP Target IP   : 192.168.10.120
Ethernet Target : 목적지 호스트의 MAC

ㅇ Off-link Destination

목적지가 다른 네트워크에 있으면 호스트가 직접 목적지 MAC을 찾지 않는다.

대신 라우팅 테이블에서 다음 홉을 찾고, 보통 기본 게이트웨이의 MAC 주소를 ARP로 조회한다.

IP Destination  : 192.168.10.130
ARP Target IP   : 기본 게이트웨이 IP
Ethernet Target : 기본 게이트웨이 MAC

IP 패킷의 Destination IP는 원래 목적지를 유지하지만 현재 이더넷 프레임은 게이트웨이에게 전달한다.

즉, Subnet Mask는 주소 범위를 설명하는 숫자에 그치지 않는다.

ARP로 누구를 찾을지 결정하는 경계선이다.

ㅁ 운영체제는 매번 직접 AND 계산을 할까?

개념적으로는 IP 주소와 마스크를 AND 연산해 같은 네트워크인지 판단한다고 설명할 수 있다.

실제 운영체제는 인터페이스 주소와 Prefix가 설정될 때 직접 연결된 네트워크에 대한 경로를 라우팅 테이블에 만든다.

예를 들어 다음 주소가 설정되어 있다고 하자.

192.168.10.70/26 dev eth0

라우팅 테이블에는 다음과 같은 Connected Route가 생길 수 있다.

192.168.10.64/26 dev eth0 scope link

목적지 192.168.10.120은 이 경로에 포함되므로 eth0에서 직접 찾는다.

192.168.10.130은 포함되지 않으므로 다른 경로나 기본 경로를 찾아야 한다.

목적지 IP
   ↓
Routing Table Lookup
   ↓
Connected Route와 일치 → On-link → 목적지 ARP
Gateway Route와 일치   → Off-link → Next-hop ARP

사용자가 비트 AND를 직접 수행하지 않더라도 Prefix를 기반으로 만들어진 라우팅 정보가 같은 판단을 수행한다.

ㅁ Subnet Mask를 잘못 적으면 어떤 일이 생길까?

IP 주소와 게이트웨이가 맞아 보여도 Subnet Mask가 틀리면 호스트가 목적지의 위치를 잘못 판단한다.

ㅇ 실제보다 넓게 설정한 경우

호스트의 실제 네트워크가 192.168.10.0/24인데 실수로 /16을 설정했다고 하자.

호스트는 192.168.20.10도 같은 네트워크에 있다고 판단할 수 있다. 게이트웨이로 보내지 않고 직접 ARP Request를 반복한다.

하지만 ARP 브로드캐스트는 라우터를 넘지 못하므로 대상의 MAC 주소를 얻지 못한다.

잘못된 판단: 같은 동네 → 목적지 ARP 반복 → 응답 없음

ㅇ 실제보다 좁게 설정한 경우

실제 네트워크가 /24인데 호스트만 /25로 설정했다고 하자.

같은 L2 네트워크의 192.168.10.200을 다른 네트워크로 판단해 게이트웨이로 보내려 한다.

게이트웨이 설정과 네트워크 기능에 따라 우회 통신이 되거나, 비효율적인 경로를 사용하거나, 통신이 실패할 수 있다. 중요한 것은 물리적으로 가까운 목적지를 호스트가 직접 이웃으로 판단하지 못한다는 점이다.

Subnet Mask 불일치는 “같은 스위치에 연결되어 있는데 왜 통신이 안 되지?”라는 장애를 만들 수 있다.

ㅁ VLAN과 Subnet은 같은 것일까?

VLAN은 L2 Broadcast Domain을 나누고 Subnet은 IP 주소의 L3 범위를 정의한다.

서로 다른 계층의 개념이다.

VLAN  : Ethernet Broadcast의 경계
Subnet: IP Address와 On-link 판단의 경계

실무에서는 하나의 VLAN에 하나의 IP Subnet을 대응시키는 구성이 일반적이다.

VLAN 10 ↔ 192.168.10.0/24
VLAN 20 ↔ 192.168.20.0/24

이렇게 하면 L2 브로드캐스트 범위와 L3 On-link 범위가 일치해 이해하고 운영하기 쉽다.

하지만 두 개념이 자동으로 같은 것은 아니다.

같은 Subnet이라고 설정했지만 서로 다른 VLAN에 있으면 ARP Request가 경계를 넘지 못해 직접 통신할 수 없다.
같은 VLAN에 있어도 서로 다른 Subnet으로 설정하면 호스트는 상대를 Off-link로 판단해 게이트웨이를 찾는다.

물리적인 연결, VLAN, IP Prefix가 함께 맞아야 “같은 동네”라는 판단과 실제 전달 범위가 일치한다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
전체 주소	IPv4 Address	32비트로 표현하는 논리 주소
동네와 집 번호의 경계선	Subnet Mask	Network Portion과 Host Portion을 구분하는 32비트 값
앞에서부터 동네에 사용하는 비트 수	Prefix Length	/24, /26처럼 네트워크 비트 수를 표현
동네 자체의 이름	Network Address	IP 주소와 Subnet Mask를 AND한 결과
동네 모든 집을 부르는 주소	Broadcast Address	호스트 비트가 모두 1인 IPv4 주소
같은 동네의 목적지	On-link	직접 연결된 네트워크 안에 있는 목적지
다른 동네의 목적지	Off-link	라우터 또는 다음 홉을 거쳐야 하는 목적지
주소와 마스크를 겹쳐 보는 계산	Bitwise AND	Network Address를 구하는 비트 연산
현재 인터페이스에 직접 붙은 동네 지도	Connected Route	Prefix 설정으로 생성되는 직접 연결 경로

호스트의 판단 순서는 다음처럼 정리할 수 있다.

1. 자신의 IP Address와 Prefix로 Connected Network를 구한다.
2. 목적지 IP가 Connected Route에 포함되는지 확인한다.
3-1. 포함되면 On-link로 판단하고 목적지 IP를 ARP로 찾는다.
3-2. 포함되지 않으면 Off-link로 판단하고 다른 경로 또는 Gateway를 찾는다.

ㅁ 직접 계산하고 확인해 보기

다음 호스트를 기준으로 목적지가 On-link인지 Off-link인지 계산해 보자.

Host: 10.10.10.100/27

/27은 마지막 옥텟에서 앞 3비트가 네트워크 부분이므로 블록 크기는 32다.

서브넷 경계: 0, 32, 64, 96, 128, 160, 192, 224

10.10.10.100은 10.10.10.96/27에 속한다. 일반 호스트 범위는 .97~.126, Broadcast Address는 .127이다.

따라서 다음과 같이 판단할 수 있다.

Linux에서는 인터페이스의 IPv4 주소와 Prefix를 확인할 수 있다.

ip -4 address show

Connected Route와 기본 경로를 확인한다.

ip -4 route show

특정 목적지를 운영체제가 어떻게 판단하는지 확인한다.

ip route get 10.10.10.110
ip route get 10.10.10.130

On-link 목적지는 일반적으로 dev <interface>가 직접 표시되고,

게이트웨이를 사용하는 경로에는 via <gateway>가 나타난다.

정책 라우팅과 여러 인터페이스가 있는 환경에서는 결과가 더 복잡할 수 있다.

macOS에서는 다음 명령으로 인터페이스와 특정 목적지의 경로를 볼 수 있다.

ifconfig
route -n get 10.10.10.130

명령 결과에서 주소만 보지 말고 Prefix, 출력 인터페이스, Gateway가 함께 어떻게 선택되는지 살펴보자.

ㅁ 핵심 정리

IPv4 주소는 32비트이며 Network Portion과 Host Portion을 함께 담는다.
Subnet Mask는 연속된 1과 0으로 두 부분의 경계를 나타낸다.
Prefix Length는 /24, /26처럼 네트워크 비트 수를 표현한다.
IP 주소와 Subnet Mask를 Bitwise AND하면 Network Address를 구할 수 있다.
호스트는 자신의 Prefix를 기준으로 목적지가 On-link인지 Off-link인지 판단한다.
On-link 목적지는 목적지 MAC을 ARP로 찾고 Off-link 목적지는 다음 홉의 MAC을 찾는다.
실제 운영체제는 Prefix에서 만들어진 Connected Route를 포함한 라우팅 테이블을 조회한다.
VLAN은 L2 경계이고 Subnet은 L3 주소 경계이며, 둘은 관련되지만 같은 개념이 아니다.
잘못된 Subnet Mask는 ARP 대상과 Gateway 선택을 바꿔 통신 장애를 만든다.

핵심 용어: IPv4 Address, Subnet Mask, Prefix Length, CIDR, Network Portion, Host Portion, Network Address, Broadcast Address, Bitwise AND, On-link, Off-link, Connected Route

Subnet Mask는 주소를 보기 좋게 나누는 숫자가 아니다. 목적지에게 직접 물을지, 우체국에 맡길지를 결정하는 경계선이다.

ㅁ 다음 이야기

호스트는 Subnet Mask와 라우팅 테이블을 사용해 목적지가 다른 네트워크에 있다는 사실을 알아냈다.

하지만 목적지까지의 모든 길을 알고 있는 것은 아니다.

동네 밖으로 나가는 편지를 처음 누구에게 맡겨야 할까?

다음 글에서는 「다른 동네의 편지는 누구에게 맡겨야 할까?」라는 질문을 통해 Default Gateway, Default Route, Next Hop, IP Forwarding과 라우터를 지날 때 프레임이 어떻게 바뀌는지 살펴본다.

[Network] 06. IP 주소만 알면 바로 편지를 건넬 수 있을까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:06:27 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 2. 편지에 두 종류의 주소가 필요한 이유

ㅁ 들어가며

VLAN은 하나의 물리적인 스위치 안에 여러 Broadcast Domain을 만든다.

이제 같은 VLAN 10에 연결된 두 컴퓨터가 통신한다고 생각해 보자.

PC A ─ Access VLAN 10 ─ Switch ─ Access VLAN 10 ─ PC B

PC A가 알고 있는 정보는 다음과 같다.

내 IP 주소     : 192.168.10.10
상대의 IP 주소 : 192.168.10.20

애플리케이션은 상대의 IP 주소를 목적지로 데이터를 보낸다.

그런데 스위치는 IP 주소가 아니라 이더넷 프레임의 목적지 MAC 주소를 보고 출력 포트를 고른다.

PC A가 프레임을 만들려면 다음 빈칸을 채워야 한다.

Source MAC      : PC A의 MAC 주소
Destination MAC : ???

IP 주소는 알고 있지만 MAC 주소는 모른다.

그렇다면 첫 프레임은 누구에게 보내야 할까?

IPv4 네트워크는 ARP(Address Resolution Protocol)를 사용해 이 질문에 답한다.

“192.168.10.20을 사용하는 장비는 자신의 MAC 주소를 알려 달라.”

이번 글에서는 IP 주소와 MAC 주소가 왜 함께 필요한지,

ARP Request와 ARP Reply가 어떤 순서로 오가는지,

알아낸 결과를 ARP Cache에 왜 저장하는지 살펴본다.

ㅁ 주소가 하나면 더 간단하지 않을까?

우편물을 보낼 때는 도시와 도로를 따라 목적지 지역을 찾아갈 주소가 필요하다.

목적지 동네에 도착한 뒤에는 그 동네 안에서 실제 수신인의 문까지 전달할 방법도 필요하다.

네트워크에서는 IP 주소와 MAC 주소가 서로 다른 범위의 문제를 맡는다.

ㅇ IP 주소는 목적지가 어디에 속하는지 나타낸다

IP Address는 논리적인 주소다.

네트워크의 경계를 표현하고 라우터가 서로 다른 네트워크 사이에서 다음 경로를 선택할 때 사용한다.

장비가 다른 네트워크로 이동하면 일반적으로 그 네트워크에 맞는 IP 주소를 사용해야 한다.

ㅇ MAC 주소는 현재 이더넷 구간에서 프레임을 전달한다

MAC Address는 이더넷 인터페이스를 식별하는 L2 주소다.

같은 이더넷 구간에서 스위치는 목적지 MAC 주소를 보고 프레임을 전달한다.

IP Address  : 목적지 호스트를 논리적으로 식별하고 경로 선택에 사용
MAC Address : 현재 이더넷 링크에서 다음 수신 인터페이스에 프레임 전달

두 주소는 같은 대상을 표현하는 중복 정보가 아니다.

IP 주소는 전체 여정의 목적지를 나타내고, MAC 주소는 현재 구간에서 프레임을 누구에게 건넬지 나타낸다.

라우터를 지날 때마다 이더넷 프레임은 새 구간에 맞게 다시 만들어지므로 출발지와 목적지 MAC 주소도 바뀐다.

반면 IP 패킷의 출발지와 목적지 주소는 일반적인 라우팅 과정에서는 유지된다.

NAT처럼 IP 주소를 변경하는 기능은 뒤의 글에서 별도로 다룬다.

ㅁ 이름은 아는데 어느 집인지 모른다

PC A가 192.168.10.20으로 IP 패킷을 보내려고 한다.

이 글에서는 PC A가 목적지를 같은 네트워크의 이웃이라고 이미 판단했다고 가정한다.

어떤 기준으로 같은 네트워크와 다른 네트워크를 구분하는지는 다음 글에서 서브넷 마스크와 함께 살펴본다.

PC A가 만들 IP 패킷은 다음과 같다.

Source IP      : 192.168.10.10
Destination IP : 192.168.10.20

이 패킷을 이더넷으로 보내려면 프레임 안에 넣어야 한다.

Ethernet Frame
├─ Source MAC      : AA:AA:AA:AA:AA:AA
├─ Destination MAC : 아직 모름
└─ Payload         : IP Packet
   ├─ Source IP      : 192.168.10.10
   └─ Destination IP : 192.168.10.20

PC A는 먼저 자신이 기억하고 있는 이웃 정보에서 192.168.10.20의 MAC 주소를 찾는다.

정보가 없다면 ARP Request를 보낸다.

ㅁ 모르는 집을 찾으려면 동네 전체에 묻는다

PC A는 누가 192.168.10.20을 사용하는지 모른다.

특정 장비의 MAC 주소를 모르므로 그 장비에게만 질문을 보낼 수도 없다.

그래서 같은 Broadcast Domain의 모두에게 ARP Request를 보낸다.

이더넷 프레임은 다음 목적지 MAC 주소를 사용한다.

Destination MAC : FF:FF:FF:FF:FF:FF

이는 Ethernet Broadcast Address다.

ARP Request의 핵심 내용은 다음과 같다.

보내는 사람의 MAC : AA:AA:AA:AA:AA:AA
보내는 사람의 IP  : 192.168.10.10
찾는 대상의 IP     : 192.168.10.20

질문: 192.168.10.20을 가진 장비는 MAC 주소를 알려 달라.

스위치는 브로드캐스트 프레임을 VLAN 10의 다른 포트로 플러딩한다.

PC A ─ ARP Request ─ Switch ┬─ PC B
                            ├─ PC C
                            └─ PC D

같은 VLAN의 PC B, C, D가 모두 요청을 받는다.

하지만 각 장비는 ARP 메시지의 Target Protocol Address, 즉 찾는 대상 IP를 확인한다.

PC C의 IP가 192.168.10.30이면 자신의 요청이 아니므로 응답하지 않는다.
PC D의 IP가 192.168.10.40이면 자신의 요청이 아니므로 응답하지 않는다.
PC B의 IP가 192.168.10.20이면 자신의 주소이므로 응답한다.

질문은 모두에게 전달되지만 답할 장비는 IP 주소의 주인 하나다.

ㅁ 주소의 주인은 자신의 MAC 주소를 답한다

PC B는 PC A에게 ARP Reply를 보낸다.

192.168.10.20은
BB:BB:BB:BB:BB:BB에 있다.

PC B는 ARP Request 안에 들어 있던 PC A의 IP 주소와 MAC 주소를 이미 알고 있다.

따라서 ARP Reply는 일반적으로 PC A의 MAC 주소를 목적지로 하는 유니캐스트 프레임으로 보낼 수 있다.

Ethernet
├─ Source MAC      : BB:BB:BB:BB:BB:BB
└─ Destination MAC : AA:AA:AA:AA:AA:AA

ARP Reply
├─ Sender IP  : 192.168.10.20
├─ Sender MAC : BB:BB:BB:BB:BB:BB
├─ Target IP  : 192.168.10.10
└─ Target MAC : AA:AA:AA:AA:AA:AA

스위치는 앞에서 배운 MAC Address Table을 사용해 이 답장을 PC A가 있는 포트로 전달한다.

PC A는 이제 빈칸을 채울 수 있다.

192.168.10.20 → BB:BB:BB:BB:BB:BB

그리고 원래 보내려던 IP 패킷을 이더넷 프레임에 넣는다.

Ethernet Frame
├─ Source MAC      : AA:AA:AA:AA:AA:AA
├─ Destination MAC : BB:BB:BB:BB:BB:BB
└─ Payload         : IP Packet
   ├─ Source IP      : 192.168.10.10
   └─ Destination IP : 192.168.10.20

이제 스위치는 목적지 MAC 주소 BB:...를 보고 PC B 방향으로 프레임을 전달한다.

ARP는 데이터를 전달하는 대신, 데이터를 담을 첫 이더넷 프레임의 목적지 주소를 준비한 것이다.

ㅁ 매번 동네 전체에 물어봐야 할까?

PC A가 패킷을 보낼 때마다 ARP Request를 브로드캐스트하면 같은 질문이 계속 반복된다.

그래서 운영체제는 알아낸 IP 주소와 MAC 주소의 관계를 잠시 저장한다.

이를 흔히 ARP Cache라고 한다.

Linux에서는 IPv4 ARP 정보와 IPv6 Neighbor Discovery 정보를 함께 다루는 Neighbor Table이라는 표현과 명령을 사용한다.

IP Address       MAC Address          Interface
192.168.10.20    BB:BB:BB:BB:BB:BB    eth0

다음 전송에서는 이 항목을 사용해 ARP Request 없이 바로 프레임을 만들 수 있다.

캐시를 영원히 유지하지는 않는다.

장비가 교체되거나 네트워크 인터페이스가 바뀌면 같은 IP 주소가 다른 MAC 주소를 사용할 수 있다.

오래된 정보를 계속 믿으면 잘못된 장비로 프레임을 보낼 수 있다.

따라서 동적으로 학습한 이웃 정보에는 상태와 유효 시간이 있다.

운영체제는 일정 시간이 지나거나 통신 가능성을 확인할 필요가 생기면 이웃 정보를 다시 검증한다.

Linux의 Neighbor Unreachability Detection 상태에서는 다음과 같은 표현을 볼 수 있다.

REACHABLE: 최근 통신 가능하다고 확인된 이웃
STALE: 정보는 있지만 최근 도달 가능성은 확인되지 않은 상태
DELAY, PROBE: 도달 가능성을 다시 확인하는 과정
INCOMPLETE: 주소 확인을 시도 중이지만 아직 MAC 주소를 얻지 못함
FAILED: 주소 확인 또는 도달 가능성 확인에 실패함

모든 운영체제가 같은 이름과 상태 전이를 그대로 보여 주는 것은 아니다.

핵심은 ARP 결과가 영구적인 정답이 아니라 현재 링크의 이웃에 대한 임시 정보라는 점이다.

ㅁ ARP는 어디까지 질문할 수 있을까?

ARP Request는 Ethernet Broadcast Frame으로 전달된다.

라우터는 일반적으로 이 L2 브로드캐스트를 다른 네트워크로 전달하지 않는다.

VLAN도 Broadcast Domain을 분리하므로 ARP Request는 같은 VLAN 범위 안에 머문다.

VLAN 10 ─ ARP Request ─X─ Router ─ VLAN 20

목적지 IP가 인터넷의 원격 서버라면 PC가 그 서버의 MAC 주소를 ARP로 찾는 것은 아니다.

원격 목적지로 가는 첫 번째 L2 수신인은 같은 네트워크에 있는 기본 게이트웨이다.

이 경우 PC는 게이트웨이 IP 주소에 대응하는 MAC 주소를 ARP로 찾고, 이더넷 프레임을 게이트웨이에게 보낸다.

IP Packet의 목적지 IP       : 원격 서버 IP
첫 Ethernet Frame의 목적지 MAC : 기본 게이트웨이 MAC

IP 목적지와 현재 프레임의 MAC 목적지가 서로 다를 수 있다는 점이 중요하다.

ARP는 전 세계의 주소록이 아니다.

현재 L2 링크에서 다음으로 프레임을 받을 이웃을 찾는 방법이다.

어떤 경우에 상대 호스트를 직접 찾고 어떤 경우에 게이트웨이를 찾아야 하는지는

다음 두 글에서 서브넷 마스크와 기본 게이트웨이로 이어진다.

ㅁ ARP 메시지 안에는 무엇이 들어 있을까?

패킷 캡처 도구에서 ARP를 열어 보면 다음 필드를 볼 수 있다.

필드	의미
Hardware Type	사용하는 L2 기술의 종류이며 이더넷은 일반적으로 1
Protocol Type	해석하려는 상위 프로토콜이며 IPv4는 0x0800
Hardware Address Length	MAC 주소 길이이며 이더넷은 6바이트
Protocol Address Length	IPv4 주소 길이인 4바이트
Opcode	Request는 1, Reply는 2
Sender Hardware Address	보내는 장비의 MAC 주소
Sender Protocol Address	보내는 장비의 IPv4 주소
Target Hardware Address	대상 장비의 MAC 주소이며 Request에서는 아직 모를 수 있음
Target Protocol Address	찾으려는 대상의 IPv4 주소

이더넷 헤더의 EtherType에는 ARP임을 나타내는 0x0806이 사용된다.

모든 필드를 외우는 것보다 다음 네 가지를 읽을 수 있으면 동작을 추적하기 쉽다.

누가 묻는가?       Sender IP / Sender MAC
누구를 찾는가?      Target IP
요청인가 답변인가?   Opcode
누구에게 전달되는가?  Ethernet Destination MAC

ㅁ 주소를 묻는 답변을 믿어도 될까?

기본 ARP에는 답변자의 신원을 인증하는 절차가 없다.

같은 L2 네트워크의 공격자가 “게이트웨이 IP 주소는 내 MAC 주소에 있다”고 거짓 ARP 정보를 보내면

다른 장비의 ARP Cache가 잘못 갱신될 수 있다.

이를 ARP Spoofing 또는 ARP Poisoning이라고 한다.

공격자는 트래픽을 자신에게 우회시켜 내용을 엿보거나 변경하고, 전달하지 않아 통신을 끊을 수 있다.

스위치 환경에서 ARP의 신뢰를 보완하기 위해 DHCP Snooping 정보와 연계한 Dynamic ARP Inspection 같은 기능을 사용할 수 있다. 정적 ARP 항목도 특정 환경에서는 도움이 되지만 규모가 커지면 관리가 어렵다.

이 글에서 기억해야 할 점은 ARP가 편리한 자동 주소 조회인 동시에, 같은 L2 네트워크의 답변을 기본적으로 신뢰하도록 설계된 프로토콜이라는 사실이다.

ㅁ Gratuitous ARP는 묻지 않았는데 왜 답할까?

장비가 자신의 IP와 MAC 주소 관계를 요청 없이 네트워크에 알리는 ARP를 Gratuitous ARP라고 한다.

다음과 같은 상황에서 활용할 수 있다.

IP 주소가 새 MAC 주소로 이동했음을 주변 장비에 알릴 때
고가용성 구성에서 활성 장비가 바뀌어 이웃 캐시를 갱신할 때
같은 IP 주소를 다른 장비가 사용하고 있는지 중복 가능성을 확인할 때

Gratuitous ARP의 구체적인 패킷 형태와 운영체제 동작에는 차이가 있을 수 있다.

핵심은 다른 장비가 먼저 질문하기를 기다리지 않고 자신의 IPv4 주소와 MAC 주소 관계를 같은 L2 영역에 알린다는 점이다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
도시와 동네를 포함한 논리 주소	IP Address	호스트와 네트워크를 식별하고 라우팅에 사용하는 주소
현재 동네에서 실제 문을 찾는 주소	MAC Address	이더넷 구간에서 인터페이스를 식별하는 L2 주소
“이 IP 주소의 주인은 누구인가?”	ARP Request	IPv4 주소에 대응하는 MAC 주소를 묻는 브로드캐스트
“이 IP는 이 MAC에 있다”	ARP Reply	요청한 주소의 대응 관계를 알려 주는 응답
동네 전체에 묻는 공지	Ethernet Broadcast	목적지 MAC FF:FF:FF:FF:FF:FF로 전달하는 프레임
잠시 적어 둔 이웃 주소록	ARP Cache / Neighbor Table	IP와 MAC 주소의 대응 관계를 임시 저장한 정보
요청 없이 새 위치를 알림	Gratuitous ARP	자신의 IP와 MAC 관계를 주변에 알리는 ARP
거짓 주소 안내	ARP Spoofing	잘못된 IP-MAC 관계를 학습시키는 공격

ARP의 전체 동작은 다음처럼 정리할 수 있다.

1. 목적지 또는 다음 홉 IPv4 주소를 결정한다.
2. Neighbor Table에서 대응하는 MAC 주소를 찾는다.
3. 정보가 없으면 ARP Request를 Broadcast한다.
4. 주소의 주인이 ARP Reply로 자신의 MAC 주소를 알린다.
5. 결과를 Cache에 저장한다.
6. 알아낸 MAC 주소로 Ethernet Frame을 만들어 전송한다.

ㅁ 직접 관찰해 보기

같은 IPv4 네트워크에 있는 장비의 주소를 알고 있다면 ARP 동작을 직접 확인할 수 있다.

Linux에서 현재 이웃 테이블을 확인한다.

ip neigh show

같은 네트워크의 아직 통신하지 않은 주소로 ping을 보내기 전과 후의 결과를 비교해 보자.

ping -c 1 192.168.10.20
ip neigh show 192.168.10.20

실제 인터페이스가 eth0이라면 다른 터미널에서 ARP 패킷을 관찰할 수 있다.

sudo tcpdump -n -e -i eth0 arp

출력에서는 다음과 비슷한 흐름을 찾는다.

ARP, Request who-has 192.168.10.20 tell 192.168.10.10
ARP, Reply 192.168.10.20 is-at bb:bb:bb:bb:bb:bb

macOS에서는 이웃 정보를 다음 명령으로 볼 수 있다.

arp -a

운영체제, 권한, 네트워크 캐시 상태에 따라 ARP Request가 바로 보이지 않을 수 있다.

이미 캐시된 항목이 있다면 운영체제가 그 정보를 사용하기 때문이다.

운영 중인 시스템에서 캐시를 강제로 삭제하면 짧은 통신 단절이나 예상하지 못한 재조회가 발생할 수 있으므로,

관찰을 위해 무리하게 상태를 변경하지 않는다.

IPv6에서는 ARP를 사용하지 않고 ICMPv6 기반의 Neighbor Discovery Protocol(NDP)을 사용한다.

따라서 IPv6 트래픽만 있는 환경에서 ARP가 보이지 않는 것은 정상이다.

ㅁ 핵심 정리

IP 주소는 논리적인 목적지를 나타내고 MAC 주소는 현재 이더넷 구간의 수신 인터페이스를 나타낸다.
같은 IPv4 네트워크에서 목적지 MAC 주소를 모르면 ARP Request를 브로드캐스트한다.
대상 IP 주소의 주인은 ARP Reply로 자신의 MAC 주소를 알린다.
알아낸 IP-MAC 관계는 ARP Cache 또는 Neighbor Table에 임시로 저장된다.
ARP Request는 라우터를 넘어가지 않으며 같은 Broadcast Domain 안에서 동작한다.
원격 목적지에는 서버의 MAC이 아니라 현재 링크의 다음 홉인 기본 게이트웨이 MAC으로 프레임을 보낸다.
ARP에는 기본 인증 절차가 없어 ARP Spoofing의 대상이 될 수 있다.
IPv6는 ARP 대신 ICMPv6 기반 NDP를 사용한다.

핵심 용어: IP Address, MAC Address, ARP, ARP Request, ARP Reply, Ethernet Broadcast, ARP Cache, Neighbor Table, Opcode, Gratuitous ARP, ARP Spoofing, NDP

ARP는 최종 목적지를 찾는 프로토콜이 아니다. 현재 이더넷 구간에서 다음으로 프레임을 받을 이웃의 MAC 주소를 찾는 프로토콜이다.

ㅁ 다음 이야기

ARP를 사용하면 IP 주소에 대응하는 MAC 주소를 알아낼 수 있다.

하지만 ARP Request는 같은 Broadcast Domain 안에서만 전달된다.

따라서 PC는 ARP를 보내기 전에 목적지가 같은 동네에 있는지, 라우터 너머의 다른 동네에 있는지 먼저 판단해야 한다.

IP 주소만 보고 그 경계를 어떻게 알 수 있을까?

다음 글에서는 「같은 동네와 다른 동네는 누가 판단할까?」라는 질문을 통해

IPv4 Address, Subnet Mask, Prefix Length, Network Address와 AND 연산을 살펴본다.

[Network] 05. 한 건물을 여러 동네로 나눌 수 있을까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:05:14 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

스위치는 MAC 주소를 학습해 이미 아는 목적지의 프레임을 필요한 포트로만 보낸다.

STP는 스위치 사이의 순환 경로를 막아 브로드캐스트 프레임이 끝없이 복제되지 않게 한다.

이제 하나의 L2 네트워크를 안전하게 운영할 수 있을 것처럼 보인다.

그런데 회사가 커져 한 스위치에 개발팀, 인사팀, 방문객용 장비가 함께 연결되면 어떻게 될까?

개발팀에서 보낸 브로드캐스트가 인사팀과 방문객에게도 전달된다. 조직과 목적이 다르지만 스위치 입장에서는 모두 같은 동네의 주민이다.

각 조직을 나누기 위해 스위치를 따로 구매할 수도 있다.

개발팀 ─ 개발팀 전용 스위치
인사팀 ─ 인사팀 전용 스위치
방문객 ─ 방문객 전용 스위치

하지만 부서가 생기거나 자리를 옮길 때마다 장비와 배선을 다시 구성해야 한다. 포트가 남아 있어도 다른 조직은 사용할 수 없다.

물리적인 스위치 한 대를 사용하면서도 서로 다른 동네처럼 나눌 수는 없을까?

이번 글에서는 Broadcast Domain, VLAN, Access Port, Trunk, IEEE 802.1Q Tag가 이 문제를 어떻게 해결하는지 살펴본다.

ㅁ 같은 방송을 듣는 범위가 하나의 동네다

앞의 글에서 브로드캐스트 프레임의 목적지 MAC 주소는 다음과 같다고 했다.

FF:FF:FF:FF:FF:FF

스위치는 이 프레임을 들어온 포트를 제외한 같은 L2 영역의 다른 포트로 전달한다.

브로드캐스트 프레임이 도달할 수 있는 범위를 Broadcast Domain이라고 한다.

개발자 PC ─┐
인사팀 PC ─┼─ Switch ─ 같은 Broadcast Domain
방문객 PC ─┘

이 구조에서 개발자 PC가 브로드캐스트를 보내면 인사팀 PC와 방문객 PC가 연결된 방향으로도 전달된다.

장비 수가 적을 때는 큰 문제가 아닐 수 있다. 하지만 하나의 Broadcast Domain이 커지면 다음 문제가 생긴다.

브로드캐스트를 확인해야 하는 장비가 늘어난다.
장애나 잘못된 트래픽의 영향 범위가 커진다.
서로 다른 조직과 용도의 장비가 같은 L2 영역을 공유한다.
주소 정책과 접근 정책을 조직별로 나누기 어려워진다.

스위치가 유니캐스트 전달을 효율화해도 브로드캐스트의 목적은 모두에게 전달하는 것이다.

MAC 주소 학습만으로는 이 범위를 줄일 수 없다.

따라서 네트워크에는 어디까지를 같은 동네로 볼 것인가를 정하는 새로운 경계가 필요하다.

ㅁ 건물은 하나지만 출입 구역은 나눌 수 있다

하나의 큰 건물에 여러 회사가 입주해 있다고 생각해 보자.

건물과 엘리베이터는 함께 사용하지만 각 회사의 사무실과 우편함은 분리되어 있다.

물리적인 건물 한 채
├─ 10번 구역: 개발팀
├─ 20번 구역: 인사팀
└─ 30번 구역: 방문객

10번 구역의 공지는 10번 구역 안에서만 전달된다. 20번과 30번 구역에는 들리지 않는다.

스위치에서도 이와 같은 논리적인 구역을 만들 수 있다.

이를 VLAN(Virtual Local Area Network)이라고 한다.

Port 1 ─ 개발자 PC ─ VLAN 10
Port 2 ─ 개발자 PC ─ VLAN 10
Port 3 ─ 인사팀 PC ─ VLAN 20
Port 4 ─ 방문객 PC ─ VLAN 30

물리적으로는 같은 스위치에 연결되어 있지만 논리적으로는 서로 다른 세 개의 L2 네트워크다.

VLAN 10에서 발생한 브로드캐스트는 VLAN 10에 속한 포트로만 전달된다. VLAN 20과 VLAN 30은 별도의 Broadcast Domain이므로 같은 프레임을 받지 않는다.

VLAN이 만드는 가장 중요한 변화는 다음과 같다.

물리적인 연결 위치와 논리적인 네트워크의 경계를 분리한다.

조직이 다른 층으로 이동해도 포트가 속한 VLAN을 바꾸면 같은 논리적 네트워크를 유지할 수 있다.

하나의 스위치 자원을 여러 조직이 나누어 쓰면서도 브로드캐스트 범위는 분리할 수 있다.

ㅁ 일반 컴퓨터는 VLAN 번호를 알아야 할까?

개발자 PC가 연결된 포트가 VLAN 10에 속한다고 하자.

일반적인 PC는 자신이 VLAN 10에 연결되었다는 사실을 알 필요가 없다.

평소처럼 태그가 없는 이더넷 프레임을 보낸다.

스위치는 프레임이 들어온 포트의 설정을 보고 VLAN 10의 프레임으로 분류한다.

PC가 보낸 Untagged Frame
          ↓
VLAN 10으로 설정된 스위치 포트
          ↓
스위치 내부에서 VLAN 10 소속으로 처리

이처럼 보통 하나의 VLAN에 속한 단말을 연결하는 포트를 Access Port라고 한다.

Access Port의 기본 역할은 다음과 같다.

단말에서 들어온 태그 없는 프레임을 지정된 VLAN에 소속시킨다.
같은 VLAN에서 단말로 나가는 프레임을 일반적으로 태그 없이 전달한다.
단말이 802.1Q 태그를 직접 처리하지 않아도 VLAN을 사용할 수 있게 한다.

우편 비유로 보면 각 출입문에 구역 번호가 정해져 있는 것과 같다.

방문자가 번호표를 붙이지 않아도 어느 출입문으로 들어왔는지 보고 구역을 정한다.

장비와 설정 방식에 따라 Access VLAN, Port VLAN ID, PVID 같은 표현을 볼 수 있다.

세부 동작과 용어는 장비마다 차이가 있지만, 태그 없는 입력 프레임을 어느 VLAN에 넣을 것인가를 결정한다는 기본 목적은 같다.

ㅁ 스위치가 두 대라면 구역마다 선이 필요할까?

한 층에 있는 Switch A와 다른 층의 Switch B에 개발팀과 인사팀 장비가 나뉘어 연결되어 있다고 하자.

개발팀 A ─ VLAN 10 ─ Switch A
인사팀 A ─ VLAN 20 ─ Switch A

개발팀 B ─ VLAN 10 ─ Switch B
인사팀 B ─ VLAN 20 ─ Switch B

두 스위치의 VLAN 10끼리 연결하고 VLAN 20끼리도 연결하려면 VLAN마다 별도의 물리적 링크를 둘 수 있다.

Switch A ══ VLAN 10 전용 링크 ══ Switch B
Switch A ══ VLAN 20 전용 링크 ══ Switch B

VLAN이 늘어날 때마다 스위치 사이의 선도 늘어난다면 물리적 자원을 아끼기 위해 VLAN을 만든 의미가 줄어든다.

그래서 여러 VLAN의 프레임을 하나의 링크로 운반하는 방법이 필요하다.

이 역할을 하는 포트를 Trunk Port라고 한다.

              VLAN 10, 20, 30
Switch A ═══════ Trunk ═══════ Switch B

하나의 트렁크 링크에는 서로 다른 VLAN의 프레임이 함께 지나간다.

그렇다면 Switch B는 도착한 프레임이 VLAN 10의 것인지 VLAN 20의 것인지 어떻게 구분할까?

프레임에 VLAN 번호가 적힌 꼬리표를 붙인다.

ㅁ 802.1Q 태그는 봉투에 붙인 구역 번호다

이더넷 프레임에 VLAN 정보를 표시하는 표준이 IEEE 802.1Q다.

스위치는 트렁크로 프레임을 보낼 때 이더넷 헤더에 4바이트의 802.1Q Tag를 추가할 수 있다.

일반 Ethernet Frame
[Destination MAC][Source MAC][EtherType][Payload][FCS]

802.1Q Tagged Frame
[Destination MAC][Source MAC][802.1Q Tag][EtherType][Payload][FCS]

태그 안에는 어떤 VLAN의 프레임인지 나타내는 VLAN ID(VID)가 들어 있다.

VLAN 10 Frame → Tag: VID 10
VLAN 20 Frame → Tag: VID 20

Switch B는 태그의 VLAN ID를 읽고 프레임을 해당 VLAN 안에서만 처리한다.

VLAN 10의 브로드캐스트 프레임이 트렁크를 지나더라도 Switch B의 VLAN 10 포트로만 전달된다.

VLAN 20 포트에는 전달되지 않는다.

802.1Q 태그의 주요 필드는 다음과 같다.

필드	크기	역할
TPID	16비트	802.1Q 태그가 있음을 표시하며 일반적으로 0x8100 사용
PCP	3비트	프레임 우선순위를 표현하는 데 사용
DEI	1비트	혼잡 시 폐기 가능성을 표시하는 데 사용
VLAN ID	12비트	프레임이 속한 VLAN을 식별

VLAN ID는 12비트이므로 0부터 4095까지 표현할 수 있다.

이 가운데 0과 4095는 특별한 용도로 예약되어 일반적인 VLAN 식별에는 보통 1~4094를 사용한다.

입문 단계에서 모든 비트를 외울 필요는 없다.

핵심은 다음 한 문장이다.

트렁크에서는 여러 VLAN의 프레임이 같은 선을 사용하므로, 802.1Q 태그로 소속을 구분한다.

ㅁ 프레임 한 장의 이동을 따라가 보자

VLAN 10의 PC A가 다른 스위치에 연결된 VLAN 10의 PC B에게 프레임을 보낸다고 하자.

PC A ─ Access VLAN 10 ─ Switch A
                         ║
                    802.1Q Trunk
                         ║
PC B ─ Access VLAN 10 ─ Switch B

프레임은 다음 순서로 이동한다.

ㅇ 1단계: PC A가 태그 없는 프레임을 보낸다

일반 단말인 PC A는 평소처럼 Untagged Frame을 보낸다.

ㅇ 2단계: Switch A가 VLAN 10으로 분류한다.

프레임이 들어온 Access Port가 VLAN 10으로 설정되어 있으므로 스위치는 이 프레임을 VLAN 10에 소속시킨다.

MAC 주소 학습도 VLAN의 범위 안에서 이루어진다.

같은 MAC 주소라도 VLAN이 다르면 별개의 논리적 영역으로 다룰 수 있다.

ㅇ 3단계: 트렁크에서 VLAN 10 태그를 붙인다

Switch A는 프레임을 트렁크로 보내면서 VLAN ID 10을 나타내는 802.1Q Tag를 추가한다.

ㅇ 4단계: Switch B가 태그를 읽는다

Switch B는 VLAN ID 10을 확인하고 프레임을 자신의 VLAN 10 영역에서 처리한다.

ㅇ 5단계: PC B에는 태그 없이 전달한다

PC B가 연결된 Access Port로 프레임을 내보낼 때 스위치는 일반적으로 802.1Q Tag를 제거한다.

PC B는 태그 없는 원래 형태의 이더넷 프레임을 받는다.

Untagged → VLAN 10으로 분류 → Tagged VID 10 → VLAN 10 확인 → Untagged

Access Port와 Trunk Port가 서로 다른 역할을 맡기 때문에 단말은 VLAN 태그를 몰라도 되고,

스위치 사이는 여러 VLAN을 하나의 링크로 운반할 수 있다.

ㅁ Native VLAN은 무엇일까?

802.1Q 트렁크에서는 특정 VLAN의 프레임을 태그 없이 운반하도록 구성할 수 있다.

이런 VLAN을 흔히 Native VLAN이라고 한다.

한쪽 스위치는 태그 없는 프레임을 VLAN 10으로 해석하고,

반대쪽 스위치는 VLAN 20으로 해석한다면 같은 프레임을 서로 다른 구역의 것으로 판단할 수 있다.

이를 Native VLAN Mismatch라고 부른다.

Native VLAN의 기본값과 처리 방식은 장비 및 설정에 따라 다를 수 있다.

따라서 트렁크 양쪽의 태그 정책과 허용 VLAN 목록을 명확히 맞춰야 한다.

기초 원리는 간단하다.

Tagged Frame은 VLAN ID로 소속을 판단한다.
Untagged Frame을 어느 VLAN으로 볼지는 포트 설정에 달려 있다.

ㅁ VLAN이 다르면 스위치로 통신할 수 있을까?

VLAN 10과 VLAN 20은 서로 다른 Broadcast Domain이다.

스위치는 같은 VLAN 안에서 MAC 주소를 기준으로 프레임을 전달하지만, VLAN의 경계를 넘어 프레임을 그대로 전달하지 않는다.

VLAN 10 ─X─ VLAN 20
       L2 경계

서로 다른 VLAN 사이에서 통신하려면 IP 주소를 기준으로 두 네트워크 사이를 중계하는 L3 Routing이 필요하다.

라우터의 물리 인터페이스를 사용하거나 L3 스위치의 SVI(Switched Virtual Interface)를 게이트웨이로 구성할 수 있다. 이를 Inter-VLAN Routing이라고 한다.

VLAN 10 ─ Gateway / Routing ─ VLAN 20

VLAN은 네트워크를 분리하지만 그 자체가 완전한 보안 정책은 아니다. 라우팅을 허용한 뒤 어느 통신을 통과시킬지는 방화벽이나 ACL 같은 별도의 정책으로 결정해야 한다.

따라서 다음 두 문장을 구분해야 한다.

VLAN은 L2 Broadcast Domain을 나눈다.
보안 정책은 나뉜 영역 사이에 어떤 통신을 허용할지 정한다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
같은 공지를 받는 동네	Broadcast Domain	하나의 브로드캐스트 프레임이 도달하는 L2 범위
건물 안의 논리적인 구역	VLAN	하나의 물리 네트워크를 나눈 논리적 L2 네트워크
한 구역의 일반 출입문	Access Port	보통 하나의 VLAN에 단말을 연결하는 포트
여러 구역이 함께 쓰는 통로	Trunk Port	여러 VLAN의 프레임을 하나의 링크로 운반하는 포트
봉투에 붙인 구역 번호	802.1Q Tag	트렁크에서 프레임의 VLAN 소속을 표시하는 정보
구역 번호	VLAN ID	VLAN을 식별하는 12비트 값
번호표가 붙은 봉투	Tagged Frame	802.1Q VLAN 정보가 포함된 프레임
번호표가 없는 봉투	Untagged Frame	802.1Q VLAN 정보가 없는 프레임
다른 구역으로 넘기는 우체국	Inter-VLAN Routing	서로 다른 VLAN 사이의 L3 통신

VLAN의 전체 동작은 다음처럼 정리할 수 있다.

Access Port : 태그 없는 단말 프레임을 특정 VLAN에 소속시킨다.
Switch 내부 : VLAN마다 학습과 전달 범위를 구분한다.
Trunk Port  : 802.1Q 태그로 여러 VLAN을 한 링크에 실어 보낸다.
L3 Gateway  : 서로 다른 VLAN 사이의 통신을 라우팅한다.

ㅁ 직접 확인해 보기

다음 구조에서 브로드캐스트 프레임이 어디까지 전달되는지 생각해 보자.

PC A ─ Access VLAN 10 ─ Switch A
PC C ─ Access VLAN 20 ─ Switch A
                           ║ Trunk: VLAN 10, 20 허용
PC B ─ Access VLAN 10 ─ Switch B
PC D ─ Access VLAN 20 ─ Switch B

PC A가 브로드캐스트를 보내면 다음과 같이 동작한다.

1. Switch A는 프레임을 VLAN 10으로 분류한다.

2. VLAN 10을 허용하는 트렁크에 VID 10 태그를 붙여 전달한다.

3. Switch B는 VLAN 10 프레임으로 처리해 PC B 방향으로 전달한다.

4. VLAN 20에 속한 PC C와 PC D에는 전달하지 않는다.

Linux 브리지가 VLAN 필터링을 사용하는 환경에서는 다음 명령으로 포트별 VLAN 정보를 확인할 수 있다.

bridge vlan show

VLAN 인터페이스가 구성되어 있다면 다음 명령으로 VLAN ID와 부모 인터페이스를 볼 수 있다.

ip -details link show type vlan

출력에서 vlan id, PVID, Egress Untagged 같은 항목을 찾아보자. 표시 내용은 실제 구성과 iproute2 버전에 따라 다르며, VLAN이나 브리지가 구성되지 않은 일반 호스트에서는 결과가 비어 있을 수 있다.

운영 중인 스위치의 VLAN 설정을 관찰 목적만으로 변경하면 네트워크가 즉시 단절될 수 있으므로 읽기 명령으로 현재 상태만 확인한다.

ㅁ 핵심 정리

Broadcast Domain은 하나의 브로드캐스트 프레임이 도달하는 L2 범위다.
VLAN은 하나의 물리적인 스위치를 여러 논리적 Broadcast Domain으로 나눈다.
Access Port는 일반적으로 하나의 VLAN에 단말을 연결하며 태그 없는 프레임을 처리한다.
Trunk Port는 여러 VLAN의 프레임을 하나의 물리 링크로 운반한다.
IEEE 802.1Q Tag의 VLAN ID가 트렁크에서 프레임의 소속을 구분한다.
Native VLAN과 Untagged Frame 처리 정책은 트렁크 양쪽에서 일치해야 한다.
서로 다른 VLAN 사이의 통신에는 Inter-VLAN Routing이 필요하다.
VLAN 분리와 접근 제어 정책은 같은 개념이 아니다.

핵심 용어: Broadcast Domain, VLAN, Access Port, Trunk Port, IEEE 802.1Q, VLAN ID, Tagged Frame, Untagged Frame, PVID, Native VLAN, Inter-VLAN Routing, SVI

VLAN은 스위치를 물리적으로 나누지 않고도, 브로드캐스트가 머무는 논리적인 동네의 경계를 만든다.

ㅁ 다음 이야기

VLAN을 사용하면 하나의 건물 안에 여러 동네를 만들 수 있다.

이제 VLAN 10 안의 PC A가 같은 동네에 있는 PC B에게 데이터를 보내려고 한다.

PC A는 애플리케이션이 알려 준 B의 IP 주소를 알고 있다.

하지만 스위치가 실제 프레임을 전달할 때 확인하는 것은 IP 주소가 아니라 목적지 MAC 주소다.

IP 주소는 아는데 MAC 주소를 모르면 첫 프레임은 누구에게 보내야 할까?

다음 글에서는 「IP 주소만 알면 바로 편지를 건넬 수 있을까?」라는 질문을 통해 IP Address와 MAC Address의 역할, ARP Request, ARP Reply, ARP Cache를 살펴본다.

[Network] 04.길이 원을 그리면 편지는 왜 끝없이 늘어날까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:04:40 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

앞의 글에서 스위치는 출발지 MAC 주소를 보고 장비의 위치를 학습한다고 했다.

목적지를 알면 해당 포트로만 프레임을 전달하고, 모르면 들어온 포트를 제외한 다른 포트로 플러딩한다. 덕분에 허브처럼 모든 프레임을 항상 모든 방향으로 보낼 필요가 없어졌다.

그런데 스위치 사이의 길이 끊어지면 어떻게 될까?

하나뿐인 연결이 끊어지면 그 뒤의 네트워크는 통신할 수 없다. 그래서 관리자는 스위치 사이에 여분의 링크를 하나 더 연결하고 싶어진다.

Switch A ───── Switch B
    └─────────┘
       여분의 길

한 길이 끊어져도 다른 길을 사용할 수 있으니 더 안전해 보인다.

하지만 두 길을 동시에 열어 두면 경로가 원을 만든다. 그리고 이 원 안으로 브로드캐스트 프레임 한 장이 들어오면, 처음 보낸 사람의 손을 떠난 뒤에도 계속 복제되어 돌아다닐 수 있다.

왜 스위치는 같은 편지가 계속 돌고 있다는 사실을 알아채지 못할까?

이번 글에서는 L2 Loop, Broadcast Storm, MAC Flapping이 발생하는 이유와, STP가 여분의 길을 버리지 않고도 순환을 막는 방법을 살펴본다.

ㅁ 배달길은 많을수록 좋은 것 아닐까?

세 개의 동네 우체국이 있다고 생각해 보자.

처음에는 일렬로 연결되어 있다.

우체국 A ───── 우체국 B ───── 우체국 C

A와 B 사이의 길이 끊어지면 A는 나머지 지역과 고립된다. 이를 막기 위해 C와 A 사이에 여분의 길을 만든다.

          우체국 A
         /        \
   우체국 B ───── 우체국 C

이제 어느 한 길이 끊어져도 우회할 수 있다.

물리적인 이중화 측면에서는 더 안전해졌다. 문제는 세 길이 모두 열려 있을 때다.

민수가 동네의 모든 사람에게 전달할 공지 편지를 우체국 A에 맡겼다고 하자. A는 모두에게 전달하기 위해 B와 C 양쪽으로 편지를 복사한다.

B가 받은 편지는 A에서 들어왔으므로 A를 제외한 C 방향으로 전달한다. C도 A에서 받은 편지를 B 방향으로 전달한다.

A → B → C → A → B → C → ...
A → C → B → A → C → B → ...

각 우체국은 도착한 공지를 다시 다른 길로 보낸다. 원래 한 장이었던 공지는 순환하면서 여러 장으로 늘어난다.

여분의 길이 장애를 피하기 위한 안전장치에서, 편지를 끝없이 복제하는 순환로로 바뀐 것이다.

ㅁ L2 프레임에는 남은 중계 횟수가 없다

라우터가 전달하는 IP 패킷에는 TTL(Time To Live)이라는 값이 있다. 라우터를 지날 때마다 값이 줄고, 0이 되면 패킷을 폐기한다.

그러나 같은 LAN 안에서 스위치가 전달하는 일반적인 이더넷 프레임에는 라우터의 TTL과 같은 중계 횟수 제한이 없다.

IP Packet       : TTL이 있어 L3 순환을 끝낼 수 있음
Ethernet Frame  : 스위치 홉마다 줄어드는 TTL이 없음

스위치는 프레임이 몇 번째로 자신을 방문했는지 기록하지 않는다. 같은 내용의 프레임이 다시 들어와도 새로 들어온 프레임처럼 처리한다.

특히 브로드캐스트 프레임의 목적지 MAC 주소는 다음과 같다.

FF:FF:FF:FF:FF:FF

스위치는 이 프레임을 들어온 포트를 제외한 같은 브로드캐스트 도메인의 다른 포트로 플러딩한다.

순환 경로가 있으면 다른 포트로 보낸 프레임이 또 다른 스위치를 지나 원래 스위치의 다른 포트로 돌아온다.

스위치는 돌아온 프레임을 다시 플러딩한다.

멈출 TTL도 없고, 이미 처리한 프레임인지 판별하는 일반적인 중복 제거 장치도 없다.

그래서 L2 Loop는 스스로 끝나지 않는다.

ㅁ 한 장의 공지가 동네 전체를 마비시킨다

순환하는 브로드캐스트 프레임은 각 스위치에서 다시 복제된다.

프레임의 수는 링크가 감당할 수 있는 한계까지 빠르게 증가한다.

이를 Broadcast Storm이라고 한다.

폭풍이 시작되면 네트워크에서는 다음과 같은 일이 함께 나타난다.

ㅇ 링크 대역폭이 소진된다

반복되는 브로드캐스트 복사본이 링크를 채운다.

정상적인 유니캐스트 프레임이 지나갈 자리가 줄어들고 응답 지연과 손실이 발생한다.

ㅇ 스위치와 호스트의 처리 부담이 커진다

스위치는 프레임을 계속 수신하고 복제해야 한다. 같은 브로드캐스트 도메인의 호스트도 쏟아지는 프레임을 받아 확인해야 한다.

ㅇ 정상 통신도 함께 느려지거나 멈춘다

브로드캐스트를 발생시킨 하나의 장비만 문제가 되는 것이 아니다.

같은 L2 네트워크를 공유하는 여러 장비가 영향을 받는다.

ㅇ 장애가 매우 빠르게 확산된다

루프는 새로운 트래픽을 만들기 위해 사용자를 기다리지 않는다.

이미 들어온 프레임을 계속 순환하고 복제하기 때문에 짧은 시간 안에 링크를 포화시킬 수 있다.

공유된 네트워크에서는 한 장의 공지가 모두의 길을 점유할 수 있다.

ㅁ 스위치의 주소 장부도 흔들린다

브로드캐스트 스톰만 문제가 되는 것은 아니다.

앞의 글에서 스위치는 출발지 MAC 주소가 들어온 포트를 보고 FDB를 학습한다고 했다.

정상적인 환경에서 A의 프레임이 1번 포트로 들어오면 다음처럼 기억한다.

MAC A → Port 1

하지만 루프가 있으면 A가 보낸 같은 프레임이 다른 스위치를 돌아 2번 포트로 다시 들어올 수 있다.

처음 관찰 : MAC A → Port 1
다시 관찰 : MAC A → Port 2
또 관찰   : MAC A → Port 1

스위치 입장에서는 A가 어느 포트에 있는지 계속 바뀌는 것처럼 보인다.

따라서 MAC 주소와 포트의 대응 관계가 짧은 시간에 반복해서 변경된다.

이를 MAC Flapping 또는 MAC Address Flapping이라고 한다.

MAC Flapping이 발생하면 목적지가 있는 포트를 안정적으로 선택하기 어렵다.

유니캐스트 프레임도 잘못된 방향으로 전달되거나 플러딩이 증가할 수 있다.

현장에서 같은 MAC 주소가 여러 포트 사이를 빠르게 이동한다는 로그가 보인다면 실제 장비 이동뿐 아니라

L2 Loop 가능성도 살펴봐야 한다.

ㅁ 여분의 길을 없애면 해결될까?

가장 단순한 해결책은 여분의 링크를 뽑는 것이다.

          Switch A
         /        X
   Switch B ───── Switch C

원이 끊어지므로 프레임이 계속 순환하지 않는다.

하지만 처음에 여분의 길을 만든 이유도 사라진다. 사용 중인 링크 하나가 고장 나면 다시 네트워크가 분리된다.

우리가 원하는 상태는 다음 두 조건을 함께 만족하는 것이다.

정상 상태에서는 프레임이 순환하지 않아야 한다.
사용 중인 길이 끊어지면 여분의 길을 사용할 수 있어야 한다.

물리적인 링크는 남겨 두되, 논리적으로는 원이 없는 하나의 경로만 사용해야 한다.

이 문제를 해결하기 위해 등장한 것이 STP(Spanning Tree Protocol)다.

ㅁ STP는 길을 없애지 않고 잠시 쉬게 한다

Spanning Tree는 모든 지점을 연결하면서 순환은 없는 나무 모양의 구조를 뜻한다.

STP를 사용하는 스위치들은 서로 BPDU(Bridge Protocol Data Unit)를 주고받는다. BPDU에는 어떤 스위치를 중심으로 삼을지, 그 중심까지 어느 경로가 더 좋은지 판단하는 정보가 들어 있다.

스위치들은 이 정보를 비교해 다음 순서로 루프 없는 길을 만든다.

ㅇ 중심이 될 스위치를 정한다 — Root Bridge

스위치들은 Bridge ID를 비교한다. Bridge ID는 우선순위 값과 스위치를 식별하는 MAC 주소 정보를 바탕으로 구성된다.

가장 낮은 Bridge ID를 가진 스위치가 Root Bridge가 된다.

          Root Bridge
          Switch A
         /        \
   Switch B ───── Switch C

ㅇ 중심으로 가는 가장 좋은 길을 고른다 — Root Port

Root Bridge가 아닌 각 스위치는 루트까지 가는 비용을 비교한다. 자신에게 가장 좋은 경로가 되는 포트를 Root Port로 선택한다.

ㅇ 각 구간에서 전달을 담당할 포트를 고른다 — Designated Port

각 링크 구간에서는 루트 방향으로 더 좋은 경로를 제공하는 포트가 Designated Port가 되어 프레임을 전달한다.

ㅇ 남은 중복 경로는 전달하지 않게 한다

루프를 만드는 나머지 포트는 일반 데이터 프레임을 전달하지 않는 상태가 된다. 고전적인 STP에서는 이를 Blocking 상태로 설명한다.

오늘날 많이 사용하는 RSTP(Rapid Spanning Tree Protocol)에서는 역할과 상태 표현이 조금 다르다. 중복 경로의 포트가 Alternate Port 역할을 맡고 Discarding 상태에 있을 수 있다.

입문 단계에서 중요한 원리는 같다.

물리적인 링크는 연결된 채로 두고, 논리적인 전달 경로 하나를 쉬게 해 원을 끊는다.

ㅁ 사용 중인 길이 끊어지면 어떻게 될까?

정상 상태에서 세 스위치는 다음처럼 동작할 수 있다.

          Switch A
         /        \
   Switch B ──X── Switch C
          차단된 경로

B와 C 사이의 물리적인 링크는 살아 있지만 일반 데이터 프레임을 전달하지 않는다. 논리적인 구조는 A를 중심으로 한 나무가 된다.

이후 A와 C 사이의 사용 중인 링크가 끊어졌다고 하자.

          Switch A
         /        X
   Switch B ───── Switch C
          새 전달 경로

스위치들은 토폴로지 변화를 감지하고 경로를 다시 계산한다. 쉬고 있던 B-C 구간이 전달 가능한 상태로 바뀌면 C는 B를 거쳐 A와 통신할 수 있다.

이처럼 장애 뒤에 새로운 루프 없는 구조를 만드는 과정을 Convergence라고 한다.

STP는 여분의 길을 제거하는 프로토콜이 아니다.

평상시에는 루프를 막고, 장애가 생기면 남겨 둔 길을 새로운 전달 경로로 사용할 수 있게 하는 프로토콜이다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
우체국 사이의 원형 배달길	L2 Loop	스위치 사이에 순환 가능한 전달 경로가 생긴 상태
끝없이 복제되는 공지 편지	Broadcast Storm	브로드캐스트 프레임이 급증해 네트워크를 점유하는 현상
한 사람의 위치가 계속 바뀌는 주소 장부	MAC Flapping	같은 MAC 주소가 여러 포트에서 반복 학습되는 현상
남은 중계 횟수가 없는 봉투	No TTL at L2	이더넷 프레임에 스위치 홉 수를 제한하는 TTL이 없음
우체국이 주고받는 경로 정보	BPDU	STP 계산을 위해 스위치가 교환하는 제어 프레임
기준이 되는 중앙 우체국	Root Bridge	STP 트리의 기준점으로 선출된 스위치
중심까지 가는 가장 좋은 길	Root Port	비루트 스위치가 루트로 가기 위해 선택한 최적 포트
쉬게 한 여분의 길	Blocking / Discarding	루프를 막기 위해 일반 프레임을 전달하지 않는 상태
장애 뒤 새 길을 정하는 과정	Convergence	토폴로지 변화 뒤 전달 구조를 다시 안정화하는 과정

STP가 해결하는 문제를 한 문장으로 정리하면 다음과 같다.

물리적 이중화(Redundancy)는 유지하고 논리적 토폴로지에서는 순환을 제거한다.

ㅁ 직접 따라가 보기

다음 삼각형 구조를 종이에 그려 보자.

          Switch A
         /        \
   Switch B ───── Switch C

ㅇ STP가 없을 때

A가 브로드캐스트 프레임을 B와 C로 보낸다.
B는 C로, C는 B로 프레임을 보낸다.
B와 C가 받은 복사본은 다시 A 방향으로 전달될 수 있다.
프레임을 폐기할 TTL이 없으므로 순환과 복제가 계속된다.

각 단계마다 프레임이 어느 링크로 이동하는지 화살표로 그려 보면 한 장의 프레임이 왜 여러 복사본으로 늘어나는지 확인할 수 있다.

ㅇ STP가 있을 때

A를 Root Bridge라고 가정한다.
B와 C는 A로 직접 연결된 포트를 Root Port로 선택한다.
B-C 링크의 한쪽 포트가 일반 프레임을 전달하지 않는 상태가 된다.
논리적인 전달 구조에서 원이 사라진다.

Linux 브리지를 사용하는 환경이라면 다음 명령으로 브리지와 포트 정보를 확인할 수 있다.

ip -details link show type bridge
bridge -details link show

출력에서 브리지의 stp_state와 포트의 state, priority, cost 등을 살펴볼 수 있다.

시스템과 iproute2 버전에 따라 출력 형식은 다를 수 있다.

단순 호스트에 Linux 브리지가 구성되어 있지 않다면 결과가 비어 있어도 정상이다.

실제 운영 네트워크에서 STP를 켜거나 끄는 변경은 전체 L2 통신에 영향을 줄 수 있으므로 관찰 목적만으로 설정을 변경해서는 안 된다.

ㅁ 핵심 정리

여분의 링크는 가용성을 높이지만 동시에 L2 Loop를 만들 수 있다.
이더넷 프레임에는 라우터의 TTL과 같은 중계 횟수 제한이 없다.
루프 안의 브로드캐스트는 반복해서 복제되어 Broadcast Storm을 만들 수 있다.
같은 출발지 MAC 주소가 여러 포트로 돌아오면 MAC Flapping이 발생한다.
STP는 BPDU를 교환하고 Root Bridge를 기준으로 루프 없는 논리적 트리를 만든다.
중복 링크는 평상시에 전달을 쉬고, 장애 시 재수렴을 거쳐 새로운 경로가 될 수 있다.
STP와 RSTP는 포트 역할과 상태 표현에 차이가 있지만 루프를 제거한다는 목적은 같다.

핵심 용어: Redundancy, L2 Loop, Broadcast Storm, MAC Flapping, BPDU, Bridge ID, Root Bridge, Root Port, Designated Port, Blocking, Discarding, STP, RSTP, Convergence

좋은 네트워크는 여분의 길을 없애지 않는다. 평상시에는 순환하지 않게 하고, 필요할 때만 새 길로 바꾼다.

ㅁ 다음 이야기

STP는 스위치 사이의 길이 원을 그리지 않도록 만들어 하나의 L2 네트워크를 안전하게 유지한다.

하지만 조직이 커지면 또 다른 문제가 생긴다.

회사 전체가 하나의 동네라면 한 부서의 브로드캐스트도 다른 모든 부서에 전달된다.

서로 다른 조직과 보안 구역을 나누려면 스위치를 물리적으로 따로 사야 할까?

다음 글에서는 「한 건물을 여러 동네로 나눌 수 있을까?」라는 질문을 통해

Broadcast Domain, VLAN, Access Port, Trunk와 802.1Q Tag가 필요한 이유를 살펴본다.

[Network] 03. 스위치는 어떻게 편지가 갈 길을 기억할까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:03:19 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

앞의 글에서는 여러 컴퓨터가 하나의 통신 매체를 공유할 때 생기는 문제를 살펴보았다.

허브는 한 포트에서 받은 신호를 다른 모든 포트로 반복한다. 누구에게 가는 데이터인지 판단하지 않기 때문에 하나의 충돌 도메인을 모두가 공유한다.

그렇다면 중간 장치가 편지의 목적지를 읽고 필요한 방향으로만 보내면 어떨까?

문제는 중간 장치가 처음부터 각 컴퓨터의 위치를 알지 못한다는 점이다.

새 컴퓨터는 언제든 연결될 수 있고, 다른 포트로 옮겨질 수도 있다.

모든 주소와 위치를 사람이 미리 입력하는 방식은 불편하고 확장하기 어렵다.

스위치는 이 문제를 의외로 단순한 방법으로 해결한다.

편지를 보낸 사람의 위치를 보고 길을 배운다.

이번 글에서는 스위치가 MAC 주소를 학습하고, 목적지를 아는 프레임과 모르는 프레임을 어떻게 다르게 처리하는지 살펴본다.

ㅁ 우체국에 주소별 창구가 생겼다

네 집이 하나의 동네 우체국에 연결되어 있다고 생각해 보자.

민수의 집 ── 1번 길 ─┐
영희의 집 ── 2번 길 ─┤
                      동네 우체국
철수의 집 ── 3번 길 ─┤
지수의 집 ── 4번 길 ─┘

이 우체국에는 네 개의 배달길이 있지만 처음에는 어느 길 끝에 누가 사는지 모른다.

민수가 영희에게 편지를 보낸다.

편지는 1번 길을 통해 우체국에 들어온다. 봉투에는 두 가지 정보가 적혀 있다.

보낸 사람: 민수
받는 사람: 영희

우체국은 아직 영희가 어느 길에 있는지 모른다.

하지만 한 가지는 새로 알게 되었다.

민수의 편지가 1번 길에서 들어왔으니, 민수에게 가는 길은 1번이다.

우체국은 이 정보를 주소 장부에 적는다.

사람	연결된 길
민수	1번

스위치의 MAC 주소 학습도 이 장면과 같다.

ㅁ 스위치는 받는 사람이 아니라 보낸 사람을 보고 배운다

이더넷에서 데이터는 프레임(Ethernet Frame)이라는 단위로 전달된다.

프레임의 헤더에는 대표적으로 다음 두 주소가 들어 있다.

Source MAC Address      : 보낸 장비의 MAC 주소
Destination MAC Address : 받을 장비의 MAC 주소

스위치는 프레임이 들어오면 먼저 출발지 MAC 주소(Source MAC Address)를 확인한다.

그리고 다음 관계를 기록한다.

이 프레임의 출발지 MAC 주소는 이 포트 방향에 있다.

예를 들어 다음 프레임이 1번 포트로 들어왔다고 하자.

Source MAC      AA:AA:AA:AA:AA:AA
Destination MAC BB:BB:BB:BB:BB:BB
Ingress Port    1

스위치는 주소 테이블에 다음 정보를 추가한다.

MAC 주소	포트
AA:AA:AA:AA:AA:AA	1

여기서 중요한 점이 있다.

스위치는 목적지 주소 BB:...를 보고 B가 있는 포트를 배우지 않는다. 목적지 주소에는 B가 실제로 어느 포트에 있는지 증명할 정보가 없기 때문이다.

반면 출발지 A의 프레임이 1번 포트로 직접 들어왔다는 사실은 A가 1번 포트 방향에 있다는 관찰 결과다.

그래서 스위치는 출발지 주소로 위치를 학습하고, 목적지 주소로 보낼 길을 결정한다.

ㅁ 목적지를 모르면 어떻게 해야 할까?

스위치는 A의 위치를 배웠지만 아직 B의 위치는 모른다.

그렇다고 프레임을 버리면 첫 통신은 영원히 시작할 수 없다.

스위치는 프레임이 들어온 포트를 제외한 나머지 모든 포트로 복사해 보낸다.

             ┌─ 2번 포트로 전송
1번 포트 ── 스위치 ─ 3번 포트로 전송
             └─ 4번 포트로 전송

이를 Unknown Unicast Flooding이라고 한다.

Unicast는 한 수신인에게 보내는 프레임이라는 뜻이다.
Unknown은 목적지 MAC 주소가 테이블에 없다는 뜻이다.
Flooding은 들어온 포트를 제외한 같은 네트워크의 다른 포트로 프레임을 보내는 동작이다.

B가 3번 포트에 연결되어 있다면 B는 프레임을 받아들인다. 목적지 주소가 자신과 다른 C와 D는 프레임을 받아들이지 않는다.

허브와 결과가 비슷해 보이지만 차이가 있다.

허브는 주소를 이해하지 못해 항상 신호를 반복한다. 스위치는 주소를 확인했지만 아직 목적지를 배우지 못했기 때문에 일시적으로 플러딩한다.

허브는 몰라도 계속 모두에게 보내고, 스위치는 모를 때만 모두에게 묻는다.

ㅁ 답장이 돌아오면 길이 완성된다

B가 A에게 답장을 보낸다.

답장 프레임은 3번 포트로 스위치에 들어온다.

Source MAC      BB:BB:BB:BB:BB:BB
Destination MAC AA:AA:AA:AA:AA:AA
Ingress Port    3

스위치는 출발지 B의 주소를 보고 새로운 정보를 학습한다.

MAC 주소	포트
AA:AA:AA:AA:AA:AA	1
BB:BB:BB:BB:BB:BB	3

이번에는 목적지 A의 주소가 테이블에 있다.

따라서 답장 프레임을 1번 포트로만 보낸다. 2번과 4번 포트에는 전달하지 않는다.

이 동작을 Known Unicast Forwarding이라고 한다.

B의 답장 → 3번 포트 → 스위치 → 1번 포트 → A

첫 편지에서는 목적지를 몰라 여러 방향으로 보냈지만, 한 번의 왕복이 일어난 뒤에는 A와 B의 위치를 모두 알게 되었다.

이후 두 장비 사이의 프레임은 필요한 포트로만 전달할 수 있다.

ㅁ 스위치의 주소 장부는 무엇일까?

스위치가 MAC 주소와 포트의 관계를 저장하는 장부를 보통 MAC Address Table이라고 한다.

환경과 문서에 따라 다음 이름도 사용한다.

FDB(Forwarding Database): 프레임을 어느 포트로 전달할지 판단하는 데이터베이스
CAM Table: 스위치가 주소 검색에 사용하는 메모리 방식에서 유래한 표현

세 용어는 문맥에 따라 조금씩 강조점이 다르지만, 입문 단계에서는 다음 장부를 가리킨다고 이해해도 충분하다.

MAC Address                    Port
AA:AA:AA:AA:AA:AA              1
BB:BB:BB:BB:BB:BB              3
CC:CC:CC:CC:CC:CC              2

스위치는 이 테이블을 사용해 목적지 MAC 주소가 어느 포트에 있는지 찾는다.

이 장부는 관리자가 모든 항목을 직접 작성하지 않아도 된다. 스위치가 실제 프레임을 관찰하며 동적으로 채운다.

이것이 MAC Learning이다.

ㅁ 장부를 영원히 믿어도 될까?

컴퓨터의 위치는 바뀔 수 있다.

노트북이 다른 포트에 연결될 수도 있고, 가상 머신이 다른 호스트로 이동할 수도 있다. 그런데 스위치가 예전 정보를 영원히 기억한다면 프레임을 잘못된 포트로 보낼 수 있다.

그래서 동적으로 학습한 MAC 주소 항목에는 유효 시간이 있다.

일정 시간 동안 해당 출발지에서 프레임이 들어오지 않으면 스위치는 오래된 항목을 삭제한다. 이를 Aging이라고 한다.

프레임 관찰
   ↓
MAC 주소와 포트 학습
   ↓
일정 시간 동안 다시 관찰되지 않음
   ↓
테이블에서 제거

삭제된 주소가 다시 통신하면 처음처럼 출발지 주소를 보고 새 위치를 학습한다.

이미 등록된 MAC 주소가 다른 포트에서 들어오면 스위치는 최신 관찰에 맞춰 포트 정보를 갱신할 수 있다.

스위치의 테이블은 고정된 주소록이 아니다.

현재 관찰한 네트워크의 모습을 잠시 기억한 지도에 가깝다.

ㅁ 브로드캐스트는 알고 있어도 모두에게 보낸다

Unknown Unicast는 목적지를 모르기 때문에 여러 포트로 보낸다.

하지만 처음부터 모두에게 전달하기 위한 프레임도 있다. 목적지 MAC 주소가 다음과 같은 Broadcast Address인 경우다.

FF:FF:FF:FF:FF:FF

스위치는 브로드캐스트 프레임을 들어온 포트를 제외한 같은 브로드캐스트 도메인의 다른 포트로 전달한다.

여기서 Unknown Unicast와 Broadcast의 차이를 구분해야 한다.

구분	여러 포트로 보내는 이유
Unknown Unicast	한 수신인에게 보내려 하지만 그 위치를 모름
Broadcast	처음부터 같은 네트워크의 모두에게 보내려 함

스위치가 MAC 주소를 모두 학습해도 브로드캐스트를 특정 포트 하나로만 보낼 수는 없다. 모든 장비에게 전달하는 것이 프레임의 목적이기 때문이다.

즉, 스위치는 불필요한 유니캐스트 전달을 줄이지만 브로드캐스트의 범위까지 자동으로 나누지는 않는다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 동작을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
봉투	Ethernet Frame	이더넷 구간에서 전달되는 데이터 단위
보낸 사람 주소	Source MAC Address	스위치가 장비의 위치를 학습하는 주소
받는 사람 주소	Destination MAC Address	스위치가 출력 포트를 결정할 때 조회하는 주소
편지가 들어온 길	Ingress Port	프레임이 스위치로 들어온 포트
주소별 배달 장부	MAC Address Table / FDB	MAC 주소와 포트의 대응 관계
보낸 사람의 위치 기록	MAC Learning	출발지 MAC 주소를 수신 포트와 연결해 저장하는 동작
모르는 주소를 여러 길로 전달	Unknown Unicast Flooding	목적지 항목이 없을 때 다른 포트로 전송하는 동작
아는 주소의 길만 선택	Known Unicast Forwarding	테이블에 있는 목적지 포트로만 전달하는 동작
오래된 주소 기록 삭제	Aging	일정 시간 사용되지 않은 동적 항목을 제거하는 동작

스위치의 전체 판단 순서는 다음과 같이 정리할 수 있다.

1. 프레임을 받는다.
2. Source MAC Address를 Ingress Port와 함께 학습한다.
3. Destination MAC Address를 FDB에서 찾는다.
4-1. 목적지를 알면 해당 포트로 Forwarding한다.
4-2. 목적지를 모르면 들어온 포트를 제외하고 Flooding한다.

이 다섯 단계가 스위치의 기본 동작을 이해하는 뼈대다.

ㅁ 직접 따라가 보기

다음과 같이 세 장비가 스위치에 연결되어 있다고 가정해 보자.

A(AA:AA) ── Port 1
B(BB:BB) ── Port 2 ── Switch
C(CC:CC) ── Port 3

처음에는 FDB가 비어 있다. 아래 프레임이 차례로 들어올 때 테이블과 출력 포트가 어떻게 바뀌는지 적어 보자.

순서	들어온 포트	출발지	목적지
1	1	AA:AA	BB:BB
2	2	BB:BB	AA:AA
3	3	CC:CC	AA:AA

정답은 다음과 같다.

ㅇ 첫 번째 프레임

AA:AA → Port 1을 학습한다.
BB:BB는 아직 모르므로 Port 2와 Port 3으로 플러딩한다.

ㅇ 두 번째 프레임

BB:BB → Port 2를 학습한다.
AA:AA는 Port 1에 있으므로 Port 1로만 전달한다.

ㅇ 세 번째 프레임

CC:CC → Port 3을 학습한다.
AA:AA는 Port 1에 있으므로 Port 1로만 전달한다.

Linux가 브리지로 동작하는 환경이라면 다음 명령으로 커널의 FDB를 볼 수 있다.

bridge fdb show

특정 브리지의 항목만 보고 싶다면 다음처럼 확인한다.

bridge fdb show br br0

표시 형식과 지원 옵션은 Linux 및 iproute2 버전에 따라 다를 수 있다.

일반 PC가 단순한 호스트로만 동작하고 브리지가 없다면 학습된 FDB가 보이지 않는 것이 정상이다.

ㅁ 핵심 정리

스위치는 출발지 MAC 주소와 프레임이 들어온 포트를 연결해 학습한다.
목적지 MAC 주소는 전달할 출력 포트를 결정하는 데 사용한다.
목적지를 알면 해당 포트로만 Known Unicast Forwarding한다.
목적지를 모르면 들어온 포트를 제외한 다른 포트로 Unknown Unicast Flooding한다.
Broadcast Frame은 처음부터 모두에게 보내는 프레임이므로 학습이 끝나도 여러 포트로 전달된다.
동적으로 학습한 항목은 Aging을 통해 오래된 정보가 되기 전에 제거된다.

핵심 용어: Ethernet Frame, Source MAC, Destination MAC, Ingress Port, MAC Address Table, FDB, CAM Table, MAC Learning, Forwarding, Flooding, Aging

스위치는 목적지를 보고 배우지 않는다. 출발지를 보고 길을 배우고, 목적지를 보고 그 길을 선택한다.

ㅁ 다음 이야기

스위치는 프레임을 관찰하며 주소와 포트를 학습한다.

덕분에 이미 아는 목적지의 프레임은 필요한 길로만 보낼 수 있다.

그렇다면 스위치 사이에 여분의 길을 하나 더 만들면 더 안전해질까?

한 길이 끊어졌을 때 다른 길을 사용할 수 있으니 좋아 보인다.

하지만 두 길이 원을 만들면 브로드캐스트 프레임은 어느 지점에서 멈춰야 할까?

다음 글에서는 「길이 원을 그리면 편지는 왜 끝없이 늘어날까?」라는 질문을 통해 L2 Loop, Broadcast Storm, MAC Flapping과 STP가 필요한 이유를 살펴본다.

[Network] 02. 모두가 동시에 말하면 누가 들을 수 있을까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:01:07 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

앞의 글에서는 모든 컴퓨터를 서로 직접 연결하는 방식의 한계를 살펴보았다.

컴퓨터가 N대라면 모든 컴퓨터를 직접 연결하는 데 필요한 선은 N × (N - 1) ÷ 2개까지 늘어난다.

그래서 각 컴퓨터를 공통의 중간 지점에 연결해 길을 함께 쓰는 구조를 생각했다.

선의 수는 크게 줄었다.

그런데 이번에는 다른 문제가 생긴다.

하나의 길을 모두가 함께 사용하는데 두 컴퓨터가 동시에 데이터를 보내면 어떻게 될까?

회의실에서 여러 사람이 동시에 말하면 누구의 말도 제대로 알아듣기 어려운 것처럼, 공유된 통신 매체에서도 신호가 겹칠 수 있다.

이번 글의 질문은 단순하다.

길을 공유하면서도 서로의 말을 방해하지 않으려면 어떤 질서가 필요할까?

ㅁ 하나의 배달 통로를 여러 집이 함께 쓴다면

네 집이 하나의 긴 배달 통로를 공유한다고 생각해 보자.

민수의 집 ──┬── 영희의 집 ──┬── 철수의 집 ──┬── 지수의 집
             하나의 공유된 배달 통로

민수가 영희에게 편지를 보내기 위해 통로에 운반 상자를 밀어 넣는다.

이 통로는 모든 집 앞을 지나므로 철수와 지수도 상자를 볼 수 있다.

하지만 봉투에 적힌 수신인이 영희라면 영희만 편지를 받고 나머지는 지나가게 둔다.

초기의 공유형 이더넷도 이와 비슷한 성격을 가졌다.

하나의 통신 매체에 연결된 장비들은 그 매체를 함께 사용했다.

한 장비가 프레임을 보내면 같은 구간의 다른 장비도 신호를 접할 수 있었고,

각 장비는 목적지 MAC 주소를 확인해 자신에게 온 프레임인지 판단했다.

이 구조에서는 한 번에 한 장비가 말할 때는 문제가 없다.

문제는 두 장비가 거의 같은 순간에 전송을 시작할 때다.

ㅁ 두 개의 상자가 좁은 통로에서 부딪혔다

민수와 철수가 동시에 통로로 상자를 밀었다고 생각해 보자.

민수의 상자 ─────→  충돌  ←───── 철수의 상자

상자가 부딪히면 어느 쪽도 목적지까지 온전하게 갈 수 없다.

공유된 전기적 통신 매체에서도 두 신호가 동시에 전송되면 신호가 겹쳐 원래 데이터를 해석할 수 없게 된다.

이를 충돌(Collision)이라고 한다.

충돌이 발생하면 두 프레임 가운데 하나를 골라 전달할 수 있는 것이 아니다.

충돌한 전송은 실패한 것으로 보고 다시 보내야 한다.

이때 같은 통신 매체에서 서로의 전송과 충돌할 수 있는 범위를 충돌 도메인(Collision Domain)이라고 한다.

허브에 여러 컴퓨터가 연결된 환경을 생각하면 이해하기 쉽다.

컴퓨터 A ─┐
컴퓨터 B ─┼─ 허브
컴퓨터 C ─┤
컴퓨터 D ─┘

허브는 들어온 신호를 이해해 목적지를 고르는 장치가 아니다.

한 포트로 들어온 신호를 나머지 포트로 반복해 내보낸다.

따라서 허브에 연결된 장비들은 하나의 공유된 길을 사용한다. A와 C가 동시에 전송하면 서로의 신호가 충돌할 수 있다.

네 대가 연결되어 있어도 동시에 자유롭게 사용할 수 있는 네 개의 길이 생긴 것은 아니다.

하나의 길을 네 대가 나누어 쓰는 것이다.

ㅁ 먼저 듣고, 비어 있으면 말한다

사람들이 회의실에서 대화할 때는 보통 다른 사람이 말하고 있는지 먼저 듣는다. 아무도 말하지 않을 때 말을 시작한다.

공유형 이더넷에도 이와 비슷한 규칙이 있었다. 바로 CSMA/CD다.

이름은 길지만 동작은 네 단계로 나누어 생각할 수 있다.

ㅇ 먼저 듣는다 — Carrier Sense

장비는 전송하기 전에 통신 매체에 다른 신호가 흐르고 있는지 확인한다.

누군가 사용 중이면 기다린다.

ㅇ 모두 같은 길을 사용할 수 있다 — Multiple Access

하나의 전송 매체를 여러 장비가 공동으로 사용한다. 특정 장비가 길을 영구히 소유하지 않는다.

ㅇ 비어 있으면 보낸다

다른 전송이 들리지 않으면 프레임을 보내기 시작한다.

ㅇ 충돌을 알아채면 멈춘다 — Collision Detection

전송 중 충돌을 감지하면 계속 보내지 않는다. 충돌 사실을 같은 구간에 알리고 전송을 중단한다.

이후 각 장비는 임의의 시간 동안 기다렸다가 다시 시도한다. 이를 임의 대기(Random Backoff)라고 한다.

듣기 → 비어 있으면 전송 → 충돌 감지 → 임의 시간 대기 → 재전송

여기서 임의로 기다린다는 점이 중요하다.

충돌한 두 장비가 똑같은 시간에 다시 보내면 또 충돌한다.

서로 다른 시간만큼 기다리면 다음 시도에서는 한 장비가 먼저 보낼 가능성이 커진다.

충돌이 반복될수록 기다릴 수 있는 시간의 범위도 넓어진다.

길이 혼잡할 때 모두가 계속 달려드는 대신 전송 시도를 늦추는 것이다.

ㅁ 규칙이 있어도 사람이 많아지면 느려진다

CSMA/CD는 충돌을 없애는 규칙이 아니다.

충돌 가능성이 있는 공유 매체에서 충돌을 다루는 규칙이다.

사용자가 적고 전송이 드물면 대부분 매체가 비어 있으므로 바로 보낼 수 있다.

그러나 사용자가 많아지고 전송량이 늘면 상황이 달라진다.

누군가 전송 중이라 기다리는 시간이 늘어난다.
비슷한 시점에 전송을 시작할 가능성이 커진다.
충돌한 프레임을 다시 보내느라 같은 데이터를 반복해서 전송한다.
재시도가 늘면서 실제 데이터가 사용할 수 있는 시간은 줄어든다.

도로를 여러 사람이 공유하면서 사고가 날 때마다 출발지로 돌아가 다시 출발하는 것과 비슷하다.

사람이 많을수록 길의 운송 능력보다 충돌과 대기에 더 많은 시간을 쓰게 된다.

연결되어 있다는 사실은 변하지 않는다. 모든 컴퓨터는 여전히 같은 매체에 연결되어 있다.

하지만 연결되어 있다고 해서 항상 효율적으로 통신할 수 있는 것은 아니다.

공유는 자원을 절약하지만, 공유 범위가 커질수록 서로 기다리고 충돌을 복구하는 비용도 커진다.

ㅁ 모든 사람이 모든 편지를 보게 되는 문제

공유 매체에는 충돌 외에 또 하나의 비효율이 있다.

허브는 목적지를 판단하지 않으므로 들어온 신호를 연결된 다른 포트로 내보낸다. 영희에게 보내는 프레임도 철수와 지수 쪽으로 전달된다.

각 컴퓨터는 목적지 MAC 주소를 보고 자신에게 온 프레임이 아니라면 받아들이지 않는다.

그러나 신호가 불필요한 방향으로 전달되는 것 자체는 피할 수 없다.

여기서 두 현상을 구분해야 한다.

충돌: 여러 장비가 공유 매체에서 동시에 전송해 신호가 겹치는 현상
브로드캐스트: 송신자가 같은 네트워크의 모든 장비에게 전달해 달라고 보낸 프레임

허브가 모든 포트로 신호를 반복하는 것과, 송신자가 의도적으로 모두에게 브로드캐스트하는 것은 같은 말이 아니다.

다만 허브 환경에서는 일반적인 단일 목적지 프레임도 다른 장비가 연결된 방향까지 퍼진다.

목적지를 아는 중간 장치가 없기 때문이다.

그렇다면 자연스럽게 다음 질문이 생긴다.

중간 장치가 수신인의 위치를 기억해서 필요한 길로만 보내면 되지 않을까?

ㅁ 오늘날에도 이더넷 충돌이 자주 일어날까?

현대의 일반적인 유선 LAN에서는 충돌을 거의 보지 않는다.

컴퓨터는 보통 허브가 아니라 스위치의 독립된 포트에 연결된다. 각 포트는 다른 포트와 분리된 전송 구간을 만들고, 송신과 수신을 동시에 할 수 있는 전이중(Full Duplex) 방식으로 동작한다.

컴퓨터 A ←──── 송신과 수신 ────→ 스위치
컴퓨터 B ←──── 송신과 수신 ────→ 스위치

A와 B는 스위치까지 각자의 링크를 사용하므로 과거의 허브처럼 하나의 전기적 매체에서 경쟁하지 않는다. 전이중 링크에서는 CSMA/CD를 사용하지 않으며 정상적인 상황에서 충돌도 발생하지 않는다.

그래서 CSMA/CD는 최신 LAN의 사용법이라기보다, 공유 매체가 가진 한계와 스위치가 필요해진 이유를 이해하는 열쇠에 가깝다.

무선 LAN은 여전히 공기라는 매체를 여러 장비가 공유한다. 다만 전송하면서 충돌을 감지하기 어려워 충돌을 피하려는 CSMA/CA 계열의 방법을 사용한다. 공유 자원에는 여전히 질서가 필요하다는 원리는 남아 있다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

이 글에서 살펴본 장면을 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
여러 집이 함께 쓰는 통로	Shared Medium	여러 장비가 하나의 전송 매체를 공유하는 구조
들어온 상자를 모든 방향으로 전달	Hub / Repeater	신호를 해석하지 않고 다른 포트로 반복하는 장치
좁은 통로에서 상자가 부딪힘	Collision	동시 전송된 신호가 겹쳐 프레임이 손상되는 현상
서로 부딪힐 수 있는 배달 구역	Collision Domain	같은 충돌의 영향을 받는 네트워크 범위
한쪽이 말할 때 다른 쪽은 기다림	Half Duplex	송신과 수신을 동시에 수행하지 못하는 통신 방식
먼저 듣고 충돌하면 다시 시도	CSMA/CD	공유형 이더넷에서 매체 접근과 충돌을 처리하는 방식
양방향 전용 통로	Full Duplex	송신과 수신을 동시에 수행하는 통신 방식

허브 기반 이더넷은 하나의 Shared Medium과 Collision Domain을 여러 장비가 공유하는 Half Duplex 환경이다.

이 환경에서는 누군가 전송 중일 때 다른 장비가 기다려야 하며, 동시 전송이 발생하면 CSMA/CD로 충돌을 처리한다.

스위치는 포트마다 충돌 도메인을 분리한다.

여기에 Full Duplex가 사용되면 송신 경로와 수신 경로가 분리되므로 충돌을 조정하기 위한 CSMA/CD도 필요하지 않다.

즉, 허브에서 스위치로의 변화는 단순히 더 빠른 장비로 교체한 것이 아니다.

하나의 충돌 도메인을 모두가 공유하던 구조에서, 장비마다 독립된 통신 구간을 사용하는 구조로 바뀐 것이다.

ㅁ 직접 관찰해 보기

현대의 Linux 컴퓨터에서는 현재 링크가 전이중으로 동작하는지 확인해 볼 수 있다.

먼저 인터페이스 이름을 찾는다.

ip -brief link

유선 인터페이스가 eth0이라면 다음과 같이 링크 정보를 확인한다.

sudo ethtool eth0

출력에서 다음 항목을 살펴본다.

Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Duplex: Full은 송신과 수신이 분리된 전이중 링크라는 뜻이다.

인터페이스의 통계도 확인할 수 있다.

ip -s link show eth0

현대적인 스위치 환경이라면 충돌 수치는 보통 0이다. 드라이버와 운영체제에 따라 충돌 통계를 표시하는 위치나 지원 여부는 다를 수 있다.

중요한 것은 충돌을 억지로 재현하는 일이 아니다.

지금 충돌이 보이지 않는 이유가 스위치와 전이중 링크가 공유 매체의 충돌 범위를 없앴기 때문이라는 점을 확인하는 것이다.

ㅁ 핵심 정리

공유형 통신 매체에서는 여러 장비의 동시 전송이 충돌할 수 있다.
허브는 목적지를 판단하지 않고 들어온 신호를 다른 포트로 반복한다.
CSMA/CD는 먼저 듣고 전송하며, 충돌하면 임의의 시간 뒤 다시 시도하는 규칙이다.
참여자와 전송량이 늘면 대기, 충돌, 재전송 비용도 커진다.
충돌과 브로드캐스트는 서로 다른 현상이다.
현대의 스위치 기반 전이중 이더넷에서는 일반적으로 CSMA/CD와 충돌이 발생하지 않는다.

핵심 용어: Shared Medium, Hub, Repeater, Collision, Collision Domain, Half Duplex, CSMA/CD, Random Backoff, Full Duplex

하나의 길을 공유하는 것만으로는 충분하지 않았다. 누구에게 가는 데이터인지 알고, 필요한 길로만 보내는 장치가 필요했다.

ㅁ 다음 이야기

허브는 데이터를 받으면 연결된 모든 방향으로 신호를 보낸다.

하지만 동네 우체국은 모든 편지를 모든 집에 배달하지 않는다. 어느 집이 어느 방향에 있는지 알고 필요한 배달길을 선택한다.

네트워크의 중간 장치도 수신인의 위치를 기억할 수 있을까?

다음 글에서는 「스위치는 어떻게 편지가 갈 길을 기억할까?」라는 질문을 통해 MAC 주소 학습과 전달, 그리고 목적지를 모를 때의 플러딩을 살펴본다.

[Network] 01. 컴퓨터 두 대를 연결하면 끝이 아니었을까?

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:00:36 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

컴퓨터 두 대가 있다.

두 컴퓨터 사이에 선을 하나 연결하면 데이터를 주고받을 수 있다. 한쪽에서 보낸 신호는 그 선을 따라 다른 쪽에 도착한다.

그렇다면 네트워크는 이것으로 완성된 것 아닐까?

두 대만 생각하면 그렇다. 문제는 세 번째 컴퓨터가 들어오는 순간 시작된다.

이 글에서는 스위치나 라우터의 동작부터 설명하지 않는다. 그보다 먼저, 왜 컴퓨터를 직접 연결하는 방식만으로는 충분하지 않았는지를 살펴보려고 한다.

네트워크의 첫 번째 문제는 연결할 수 있는가가 아니었다.

늘어나는 연결을 감당할 수 있는가였다.

ㅁ 두 사람이라면 전용 배달길 하나로 충분하다

두 집에 사는 사람이 서로 편지를 주고받는다고 생각해 보자.

두 집 사이에 전용 배달길을 하나 만들면 된다.

민수의 집 ───────── 영희의 집

이 길에는 두 사람의 편지만 다닌다.

어느 길로 보내야 할지 고민할 필요가 없다.
다른 사람의 편지와 섞이지 않는다.
길을 사용하는 사람도 두 명뿐이다.

컴퓨터 두 대의 직접 연결도 이와 비슷하다. 두 장비 사이에 전용 통신 경로가 있으면 목적지는 명확하다.

이런 방식을 점대점 연결(Point-to-Point)이라고 한다. 지금도 장비와 장비를 직접 연결하거나 특정 두 지점을 잇는 구간에서 유용하게 사용한다.

그러니 점대점 연결 자체가 잘못된 것은 아니다.

다만 모든 컴퓨터를 서로 직접 연결하려 할 때 문제가 생긴다.

ㅁ 세 번째 집이 생기면 길도 하나만 늘어날까?

철수가 이 동네로 이사 왔다.

세 사람이 누구와도 직접 편지를 주고받으려면 어떻게 해야 할까?

        민수의 집
       /         \
영희의 집 ───── 철수의 집

필요한 길은 세 개다.

한 명이 더 이사 와서 네 명이 되면 길은 여섯 개가 필요하다. 다섯 명이면 열 개다.

사람은 한 명씩 늘어나지만 길은 훨씬 빠르게 늘어난다.

모든 사람이 서로 전용길을 가져야 한다면, 사람이 N명일 때 필요한 길의 수는 다음과 같다.

필요한 길의 수 = N × (N - 1) ÷ 2

컴퓨터 수	필요한 전용 연결 수
2대	1개
3대	3개
5대	10개
10대	45개
100대	4,950개

100대의 컴퓨터를 모두 직접 연결하려면 4,950개의 선이 필요하다. 컴퓨터 한 대마다 다른 99대와 연결할 단자도 있어야 한다.

새 컴퓨터 한 대를 추가할 때도 기존의 모든 컴퓨터까지 새 선을 연결해야 한다.

연결은 가능하다.

그러나 확장할 수 없다.

ㅁ 선만 늘어나는 것이 아니다

전용 연결이 늘어나면 선의 개수만 문제가 되는 것은 아니다.

ㅇ 연결할 자리가 필요하다

각 컴퓨터는 상대마다 별도의 통신 인터페이스를 가져야 한다. 사람이 늘어날수록 컴퓨터 한 대에 필요한 단자도 함께 늘어난다.

ㅇ 새로운 참여자를 추가하기 어렵다

새 컴퓨터 한 대를 연결하려면 기존의 모든 컴퓨터에 손을 대야 한다. 참여자가 많아질수록 한 대를 추가하는 작업도 커진다.

ㅇ 고장 지점이 많아진다

선이 많으면 끊어질 수 있는 지점도 많아진다. 통신이 되지 않을 때 수많은 전용선 가운데 어느 길이 문제인지 찾아야 한다.

ㅇ 남는 길을 함께 쓰기 어렵다

민수와 영희가 대화하지 않는 동안에도 두 사람의 전용길은 다른 사람에게 도움이 되지 않는다.

자원이 비어 있어도 그 길의 주인이 아니면 사용할 수 없다.

전용길은 단순하고 명확하지만, 참여자가 많아질수록 비싼 방식이 된다.

우리가 해결해야 할 문제도 조금 달라진다.

어떻게 더 많은 선을 연결할까?

가 아니라

어떻게 적은 수의 선을 더 많은 사람이 함께 사용할까?

가 된다.

ㅁ 모든 집을 우체국에 연결하면 무엇이 달라질까?

이번에는 집과 집 사이에 전용 배달길을 만들지 않고, 각 집이 동네 우체국 하나와 연결되어 있다고 생각해 보자.

민수의 집 ─┐
영희의 집 ─┼─ 동네 우체국
철수의 집 ─┤
지수의 집 ─┘

새로운 사람이 이사 오면 기존의 모든 집에 길을 만들 필요가 없다. 새 집과 우체국 사이의 길 하나만 추가하면 된다.

전용 연결 방식: 새 집과 기존의 모든 집을 연결
중간 지점 방식: 새 집과 중간 지점만 연결

열 명이 서로 직접 연결하려면 45개의 길이 필요하지만,

열 명이 하나의 중간 지점에 연결되면 각 사람에게 하나씩, 10개의 길로 시작할 수 있다.

중간 지점은 편지를 받아 알맞은 목적지 쪽으로 넘겨준다. 여러 사람이 배달 시설과 길을 함께 사용하게 된 것이다.

네트워크에서도 비슷한 역할을 하는 장치가 필요해졌다.

오늘날의 LAN에서는 보통 컴퓨터를 서로 전부 직접 연결하지 않는다. 각 컴퓨터를 스위치에 연결하고, 스위치가 데이터를 목적지 방향으로 전달한다.

컴퓨터 A ─┐
컴퓨터 B ─┼─ 스위치
컴퓨터 C ─┤
컴퓨터 D ─┘

여기서 중요한 것은 아직 스위치라는 장비의 이름이 아니다.

핵심은 연결 구조가 바뀌었다는 것이다.

모든 상대와 전용선을 만드는 구조에서
공통의 중간 지점을 함께 사용하는 구조로 바뀌었다.

네트워크는 이렇게 연결을 계속 늘리는 대신, 연결과 전달 자원을 공유하는 방향으로 확장할 수 있게 되었다.

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 이야기를 실제 네트워크 용어로 옮기면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
두 집을 전용길로 연결	Point-to-Point	두 장비 사이에 직접 통신 경로를 만드는 연결 방식
모든 집을 서로 연결	Full Mesh Topology	모든 장비가 다른 모든 장비와 직접 연결된 구조
여러 집이 중앙 우체국에 연결	Star Topology	각 장비가 중앙 장치를 통해 연결되는 구조
동네 우체국	Switch	LAN에서 프레임을 목적지 방향으로 전달하는 중앙 장치
사람이 늘어도 감당할 수 있는가	Scalability	참여자와 트래픽이 증가해도 구조를 확장할 수 있는 성질

Topology는 장비와 링크가 어떤 모양으로 연결되어 있는지를 뜻한다.

모든 장비를 직접 잇는 Full Mesh는 특정 장비 사이에 전용 경로를 제공하지만, 장비 수가 증가하면 링크와 인터페이스가 빠르게 늘어난다.

반면 Star Topology에서는 각 장비가 중앙의 스위치에 연결되므로 새로운 장비를 추가하기 쉽다.

이 차이를 설명하는 핵심 용어가 확장성(Scalability)이다.

확장성은 단순히 장비를 더 연결할 수 있다는 뜻이 아니다.

사용자가 늘어날 때 필요한 비용과 작업, 복잡도가 감당할 수 있는 범위에서 증가해야 한다는 뜻이다.

따라서 이 글의 질문은 네트워크 용어로 다음과 같이 바꿀 수 있다.

Full Mesh Topology의 확장성 문제를 어떻게 해결할 것인가?

LAN에서는 여러 장비를 스위치 중심의 Star Topology로 연결하는 것이 대표적인 답이 되었다.

ㅁ 그렇다면 공유하면 모든 문제가 해결될까?

아직 그렇지 않다.

모두가 같은 배달 시설을 사용하면 새로운 질문이 생긴다.

여러 사람이 동시에 데이터를 보내면 어떻게 될까?
받은 데이터가 누구의 것인지 어떻게 구분할까?
중간 장치는 목적지가 어느 방향에 있는지 어떻게 알까?
한 사람의 통신이 다른 사람의 통신을 방해하지 않을까?

전용길에서는 생각하지 않아도 되었던 문제다.

공유는 연결 수를 줄여 주었지만, 그 대신 질서가 필요해졌다.

네트워크의 여러 기술은 바로 이 지점에서 등장한다. 누가 말할 차례인지 정하고, 목적지를 구분하고, 필요한 방향으로만 데이터를 전달해야 한다.

즉, 공유는 문제의 끝이 아니라 네트워크 설계의 시작이다.

ㅁ 직접 생각해 보기

종이 한 장에 컴퓨터를 점으로 표시하고 모든 컴퓨터가 서로 직접 연결되도록 선을 그어 보자.

컴퓨터 2대, 3대, 5대일 때 각각 몇 개의 선이 필요한가?
컴퓨터를 한 대 추가할 때 새로 그어야 하는 선은 몇 개인가?
가운데에 공통 연결 지점 하나를 두면 선의 수는 어떻게 달라지는가?

계산할 때는 다음 두 식을 비교하면 된다.

모두 직접 연결: N × (N - 1) ÷ 2
중간 지점에 연결: N

이 작은 그림만으로도 네트워크가 왜 “더 많은 연결”보다 “공유할 수 있는 구조”를 선택했는지 확인할 수 있다.

다만 실제 네트워크에서는 중간 장치도 처리 용량과 포트 수의 한계가 있다.

규모가 커지면 여러 스위치를 계층적으로 연결하고 경로를 나눈다.

하나의 장치가 세상 모든 컴퓨터를 연결하는 것은 아니다.

ㅁ 핵심 정리

컴퓨터 두 대의 점대점 연결은 단순하고 유용하다.
모든 컴퓨터를 서로 직접 연결하면 연결 수가 N × (N - 1) ÷ 2로 증가한다.
참여자가 늘수록 선, 인터페이스, 추가 작업, 장애 지점도 빠르게 늘어난다.
중간 지점을 함께 사용하면 새 참여자는 연결 하나만 추가해 통신망에 들어올 수 있다.
네트워크가 해결해야 했던 첫 번째 과제는 연결 자체보다 연결 자원의 공유였다.

네트워크는 선을 많이 연결해서 커진 것이 아니라, 하나의 길을 함께 쓰는 방법을 찾아서 커졌다.

ㅁ 다음 이야기

공유할 중간 지점을 만들었으니 연결 문제는 해결된 것처럼 보인다.

그런데 여러 컴퓨터가 같은 길에서 동시에 말하면 어떻게 될까?

한 사람의 신호와 다른 사람의 신호가 겹친다면, 중간에서는 누구의 데이터를 들어야 할까?

다음 글에서는 「모두가 동시에 말하면 누가 들을 수 있을까?」라는 질문을 통해 공유된 통신 매체와 충돌의 문제를 살펴본다.

[Network] TCP/IP를 우편 시스템으로 이해하기

기록하는 백엔드개발자 — Wed, 15 Jul 2026 20:00:07 +0900

편지 한 통의 여정으로 이해하는 네트워크의 기본 원리

편지를 보내려면 주소만 적으면 될까?

두 사람이 편지를 주고받는 일은 간단하다. 하지만 수많은 사람이 같은 길을 나눠 쓰고, 도시와 나라의 경계를 넘어, 사라진 편지는 다시 보내면서도 제때 도착하게 하려면 이야기가 달라진다. 스위치와 라우터, TCP와 DNS는 그 문제를 하나씩 해결하며 만들어졌다.

이 연재는 용어를 외우는 순서가 아니다. 공유, 확장, 효율, 신뢰라는 네 가지 질문을 따라 편지 한 통이 목적지에 도착하는 과정을 이해하는 이야기다. 설명은 공개 표준과 일반적인 TCP/IP 원리를 바탕으로 하며, 예시와 관찰 활동은 연재를 위해 독립적으로 구성한다.

ㅁ 프롤로그. 우리는 편지를 보내고 있을 뿐이다

00. 인터넷은 왜 거대한 우체국이 되었을까?

컴퓨터 두 대를 선으로 연결하는 일에서 시작해 수많은 사람이 하나의 통신망을 나눠 쓰는 일까지 나아간다. 네트워크를 장비와 프로토콜의 목록이 아니라, 제한된 길을 함께 쓰기 위해 발전한 물류 시스템으로 바라본다.

먼저 읽기: 00. 네트워크 이해를 위한 우체국 편지 비유

ㅁ Part 1. 모두가 하나의 길을 함께 쓰려면

처음에는 컴퓨터끼리 선을 직접 연결하면 충분해 보였다. 그러나 연결할 사람이 늘자 선의 수와 충돌도 함께 늘었다. 이 Part에서는 하나의 길을 여러 사람이 안전하고 효율적으로 공유하기 위해 어떤 장치가 필요했는지 살펴본다.

첫 번째 문제: 공유 — 모두가 같은 길을 쓰면서도 서로 방해하지 않을 수 있을까?

01. 컴퓨터 두 대를 연결하면 끝이 아니었을까?

두 대를 잇는 전용선은 단순하지만 참여자가 늘어날수록 필요한 선이 폭발적으로 증가한다. 점대점 연결의 한계에서 네트워크가 왜 공동의 길을 필요로 했는지 출발한다.

[Network] 01. 컴퓨터 두 대를 연결하면 끝이 아니었을까?

02. 모두가 동시에 말하면 누가 들을 수 있을까?

하나의 통신 매체를 공유하면 신호가 충돌하고 불필요한 데이터까지 모두에게 전달된다. 허브와 공유 매체의 한계를 통해 “연결되어 있다”와 “효율적으로 통신한다”의 차이를 이해한다.

[Network] 02. 모두가 동시에 말하면 누가 들을 수 있을까?

03. 스위치는 어떻게 편지가 갈 길을 기억할까?

스위치는 지나가는 프레임의 발신 MAC 주소를 보고 어느 포트에 누가 있는지 학습한다. 목적지를 알면 필요한 길로만 보내고, 모르면 모두에게 묻는 학습·전달·플러딩의 원리를 살펴본다.

[Network] 03. 스위치는 어떻게 편지가 갈 길을 기억할까?

04. 길이 원을 그리면 편지는 왜 끝없이 늘어날까?

스위치 사이에 순환 경로가 생기면 브로드캐스트는 사라지지 않고 계속 복제된다. 브로드캐스트 스톰을 통해 여분의 길이 언제 안전장치가 아니라 위험이 되는지, STP가 왜 일부 길을 쉬게 하는지 알아본다.

[Network] 04.길이 원을 그리면 편지는 왜 끝없이 늘어날까?

05. 한 건물을 여러 동네로 나눌 수 있을까?

규모가 커지면 모든 사람이 모든 소식을 들을 필요가 없다. VLAN은 하나의 물리적인 스위치를 여러 방송 구역으로 나누고, 트렁크는 여러 구역의 데이터를 한 길로 운반한다.

[Network] 05. 한 건물을 여러 동네로 나눌 수 있을까?

ㅁ Part 2. 편지에 두 종류의 주소가 필요한 이유

네트워크에는 가까운 거리에서 실제로 전달할 때 쓰는 주소와 멀리 떨어진 목적지를 찾을 때 쓰는 주소가 함께 존재한다. 이 Part에서는 MAC 주소와 IP 주소가 역할을 나누는 이유와, 주소 범위가 네트워크의 경계를 만드는 과정을 따라간다.

두 번째 문제: 확장 — 가까운 이웃을 찾는 방법만으로 전 세계까지 갈 수 있을까?

06. IP 주소만 알면 바로 편지를 건넬 수 있을까?

IP 주소는 목적지를 설명하지만 같은 네트워크에서 실제 프레임을 전달하려면 MAC 주소가 필요하다. ARP가 “이 IP 주소를 가진 사람은 누구인가?”라고 묻고 답을 잠시 기억하는 과정을 살펴본다.
[Network] 06. IP 주소만 알면 바로 편지를 건넬 수 있을까?

07. 같은 동네와 다른 동네는 누가 판단할까?

서브넷 마스크는 IP 주소를 네트워크 부분과 호스트 부분으로 나눈다. 송신자는 이를 이용해 목적지가 가까운 이웃인지, 라우터에게 맡겨야 할 먼 곳인지 먼저 판단한다.

[Network] 07. 같은 동네와 다른 동네는 누가 판단할까?

08. 다른 동네의 편지는 누구에게 맡겨야 할까?

기본 게이트웨이는 동네 밖으로 나가는 편지를 처음 맡는 우체국이다. 호스트가 모든 목적지의 길을 알지 않아도 하나의 출구를 통해 더 큰 네트워크로 나갈 수 있는 이유를 이해한다.

[Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까?

ㅁ Part 3. 수많은 길 가운데 다음 길을 고르는 법

동네를 벗어난 편지는 여러 라우터를 거쳐 목적지로 간다. 각 라우터는 전체 여정을 지휘하지 않고 자신이 알고 있는 정보로 다음 구간만 선택한다. 이 단순한 결정이 반복되어 인터넷 규모의 배송이 완성된다.

확장의 핵심: 모든 길을 알지 않고도 다음 길을 올바르게 선택할 수 있을까?

09. 라우터는 수많은 목적지의 길을 어떻게 고를까?

라우팅 테이블은 목적지 주소 범위와 다음 홉을 연결한 지도다. 여러 경로가 일치할 때 더 구체적인 주소 범위를 우선하는 최장 접두사 일치의 기본 원리를 살펴본다.

[Network] 09. 라우터는 수많은 목적지의 길을 어떻게 고를까?

10. 가는 길이 있으면 돌아오는 길도 있는 것일까?

요청과 응답은 서로 독립적으로 경로를 선택한다. 편지가 목적지에 도착했더라도 답장이 돌아올 경로가 없다면 통신은 완성되지 않는다. 네트워크를 항상 왕복 여정으로 봐야 하는 이유를 확인한다.

[Network] 10. 가는 길이 있으면 돌아오는 길도 있는 것일까?

11. 길을 잃은 편지가 영원히 돌면 어떻게 될까?

잘못된 경로 정보가 서로를 가리키면 패킷은 라우터 사이를 맴돈다. TTL은 라우터를 지날 때마다 줄어들어 하나의 실수가 네트워크 자원을 영원히 차지하지 못하도록 막는다.

[Network] 11. 길을 잃은 편지가 영원히 돌면 어떻게 될까?

12. 길이 바뀌면 지도는 어떻게 새로 그려질까?

작은 네트워크에서는 경로를 직접 적을 수 있지만 규모가 커지면 자동으로 정보를 나눠야 한다. 정적 라우팅과 동적 라우팅의 차이를 통해 OSPF와 BGP가 해결하려는 문제를 개념 수준에서 이해한다.

[Network] 12. 길이 바뀌면 지도는 어떻게 새로 그려질까?

ㅁ Part 4. 이름을 주소로 바꾸고 대화를 시작하기

사람은 숫자 주소보다 이름을 기억하고, 하나의 컴퓨터에서는 여러 프로그램이 동시에 통신한다. 이 Part에서는 DNS가 목적지 주소를 찾고 포트가 받을 프로그램을 구분한 뒤, UDP와 TCP가 서로 다른 방식으로 데이터를 전달하는 과정을 살펴본다.

전달의 시작: 누구에게, 어떤 프로그램으로, 어떤 방식으로 보낼 것인가?

13. 우리는 왜 숫자 대신 이름으로 접속할까?

DNS는 사람이 기억하는 이름을 IP 주소로 바꾼다. 계층적으로 답을 찾아가는 과정과 캐시가 반복 조회를 줄이는 이유, 오래된 캐시가 때로는 장애를 만드는 이유를 알아본다.

[Network] 13. 우리는 왜 숫자 대신 이름으로 접속할까?

14. 한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?

IP 주소가 건물을 찾는 주소라면 포트 번호는 그 안의 수신 창구와 같다. 클라이언트와 서버, 잘 알려진 포트와 임시 포트의 역할을 통해 하나의 호스트가 여러 대화를 구분하는 법을 이해한다.

[Network] 14. 한 컴퓨터의 여러 프로그램은 편지를 어떻게 나눠 받을까?

15. 모든 편지에 수령 확인이 필요할까?

UDP는 확인 절차를 줄여 빠르고 단순하게 전달하고, TCP는 순서와 도착 여부를 관리한다. 어느 하나가 항상 우월한 것이 아니라 애플리케이션이 원하는 효율과 신뢰에 따라 선택이 달라진다는 점을 살펴본다.

[Network] 15. 모든 편지에 수령 확인이 필요할까?

ㅁ Part 5. 믿을 수 없는 길 위에서 믿을 수 있게 보내기

IP는 패킷의 도착을 보장하지 않는다. TCP는 연결을 확인하고, 잃어버린 데이터를 다시 보내고, 받는 쪽과 네트워크가 감당할 수 있는 속도에 맞춘다. 이 Part에서는 신뢰가 한 번의 기능이 아니라 여러 약속의 조합임을 이해한다.

세 번째 문제: 신뢰 — 사라지고 늦고 순서가 바뀌는 길에서 어떻게 대화를 이어갈까?

16. 대화를 시작하기 전에 왜 세 번이나 인사할까?

TCP 3-way handshake는 양쪽이 보내고 받을 준비가 되었는지 확인하고 초기 순서 번호를 맞춘다. SYN, SYN-ACK, ACK가 각각 무엇을 확인하는지 편지를 주고받는 장면으로 살펴본다.

[Network] 16. 대화를 시작하기 전에 왜 세 번이나 인사할까?

17. 편지가 사라졌다는 사실은 어떻게 알아챌까?

TCP는 순서 번호와 ACK로 받은 범위를 알리고, 응답이 없거나 빠진 구간이 확인되면 재전송한다. 타임아웃과 중복 ACK가 손실을 알아채는 서로 다른 단서가 되는 이유를 이해한다.

[Network] 17. 편지가 사라졌다는 사실은 어떻게 알아챌까?

18. 받는 사람이 감당하지 못할 만큼 보내면 어떻게 될까?

흐름 제어는 수신자의 처리 능력에 맞추고, 혼잡 제어는 네트워크 전체의 상태에 맞춰 전송량을 조절한다. 빠르게 보내는 것보다 모두가 길을 지속해서 공유하는 것이 중요한 이유를 살펴본다.
[Network] 18. 받는 사람이 감당하지 못할 만큼 보내면 어떻게 될까?

ㅁ Part 6. 너무 큰 소포와 좁은 길의 문제

모든 네트워크 구간에는 한 번에 운반할 수 있는 크기의 한계가 있다. 패킷이 너무 크면 나누거나 더 작게 다시 보내야 하고, 이 사실을 알려주는 제어 메시지도 필요하다. 이 Part에서는 제한된 길을 효율적으로 사용하는 방법을 살펴본다.

네 번째 문제: 효율 — 길마다 다른 한계에 맞춰 얼마만큼씩 보내야 할까?

19. 작은 편지는 가는데 큰 소포만 멈추는 이유는 무엇일까?

MTU는 한 구간에서 전달할 수 있는 프레임의 최대 크기다. IP 단편화가 큰 패킷을 나누는 방식과, 단편화가 처리 비용과 손실 위험을 키우는 이유를 이해한다.

[Network] 19. 작은 편지는 가는데 큰 소포만 멈추는 이유는 무엇일까?

20. 가장 좁은 길의 크기를 출발지에서 어떻게 알 수 있을까?

Path MTU Discovery는 경로에서 처리할 수 없는 크기를 ICMP 메시지로 알린다. 안내 메시지를 무조건 차단했을 때 작은 데이터만 되고 큰 데이터는 멈추는 MTU 블랙홀이 생기는 이유를 살펴본다.

[Network] 20. 가장 좁은 길의 크기를 출발지에서 어떻게 알 수 있을까?

ㅁ Part 7. 인터넷의 주소를 함께 쓰고 경계를 지키는 법

인터넷에 연결되는 기기는 빠르게 늘었지만 IPv4 주소는 한정되어 있다. NAT는 여러 내부 기기가 하나의 공인 주소를 나눠 쓰게 했고, 방화벽은 통신의 경계를 만들었다. 마지막으로 TLS가 전달 경로를 믿지 않고도 내용을 보호하는 방법을 살펴본다.

공유와 신뢰의 타협: 주소는 아끼면서 필요한 통신만 안전하게 허용할 수 있을까?

21. 여러 집이 하나의 공인 주소를 함께 쓸 수 있을까?

NAT는 내부 주소와 포트를 외부 주소와 포트로 바꾸고 그 대응 관계를 기억한다. 사설 주소가 인터넷으로 나가는 기본 과정과, 주소 공유가 종단 간 연결에 가져온 변화를 이해한다.

[Network] 21. 여러 집이 하나의 공인 주소를 함께 쓸 수 있을까?

22. 방화벽은 편지의 무엇을 보고 문을 열어줄까?

방화벽은 주소와 포트, 프로토콜, 연결 상태를 기준으로 통신을 허용하거나 차단한다. 무조건 막는 것이 아니라 필요한 흐름을 명확히 정의하는 것이 보안의 출발점임을 살펴본다.

[Network] 22. 방화벽은 편지의 무엇을 보고 문을 열어줄까?

23. 우체부를 믿지 않고도 편지 내용을 지킬 수 있을까?

TLS는 암호화로 내용을 숨기고, 인증서로 상대의 신원을 확인하며, 무결성 검증으로 전송 중 변경을 알아챈다. HTTPS가 해결하는 문제와 해결하지 않는 문제를 구분한다.

[Network] 23. 우체부를 믿지 않고도 편지 내용을 지킬 수 있을까?

ㅁ Part 8. 편지가 멈춘 곳을 찾는 법

네트워크 장애는 종종 같은 얼굴, 즉 타임아웃으로 나타난다. 그래서 추측보다 여정의 각 단계에서 증거를 모아야 한다. 이 Part에서는 도구 이름을 외우는 대신 질문을 세우고 관찰 범위를 좁히는 기본 진단법을 정리한다.

네 원리를 잇는 마지막 능력: 패킷이 어디까지 갔는지 증거로 설명할 수 있을까?

24. ping이 실패하면 정말 서버가 죽은 것일까?

ping은 ICMP 응답 여부와 왕복 시간을 보여주지만 서비스의 정상 동작까지 보장하지 않는다. 응답이 없을 때 호스트 장애, 경로 문제, 정책 차단을 성급히 단정하지 않는 법을 배운다.

[Network] 24. ping이 실패하면 정말 서버가 죽은 것일까?

25. traceroute는 보이지 않는 길을 어떻게 보여줄까?

traceroute는 TTL을 조금씩 늘리며 각 구간에서 돌아오는 ICMP 메시지를 모은다. 경로가 일부만 보이거나 응답이 없을 때 그 결과가 의미하는 범위와 한계를 이해한다.

[Network] 25. traceroute는 보이지 않는 길을 어떻게 보여줄까?

26. 패킷을 직접 보면 모든 원인을 알 수 있을까?

ip와 dig로 설정과 이름을 확인하고, curl과 netcat으로 애플리케이션 연결을 시험한다. 마지막에는 tcpdump와 Wireshark로 실제 패킷을 관찰한다. 한 도구의 결과가 아니라 여러 계층의 증거를 맞추는 순서를 정리한다.

[Network] 26. 패킷을 직접 보면 모든 원인을 알 수 있을까?

ㅁ 에필로그. 우리는 인터넷이 아니라 물류 시스템을 이해했다

27. 편지 한 통의 여정을 혼자 설명할 수 있을까?

이름을 주소로 바꾸고, 같은 동네의 수신인을 찾고, 게이트웨이에 편지를 맡긴다. 라우터는 다음 길을 선택하고, NAT는 주소를 나눠 쓰게 하며, TCP는 대화를 신뢰할 수 있게 만든다. 문제가 생기면 여정의 각 지점에 남은 증거를 거꾸로 따라간다.

ARP, Routing, NAT, DNS는 더 이상 따로 외워야 할 용어가 아니다. 모두 공유, 확장, 효율, 신뢰를 지키면서 편지 한 통을 목적지까지 보내기 위해 생겨난 선택이다.

[Network] 27. 편지 한 통의 여정을 혼자 설명할 수 있을까?

이 시리즈를 모두 읽으면

MAC 주소와 IP 주소가 왜 함께 필요한지 설명할 수 있다.
패킷이 왜 특정 게이트웨이와 다음 홉을 선택했는지 이해할 수 있다.
DNS, TCP, NAT, MTU가 편지의 여정에서 맡은 역할을 연결할 수 있다.
같은 타임아웃에서도 이름, 경로, 포트, 전송 문제를 순서대로 구분할 수 있다.
새로운 네트워크 기술을 만났을 때 무엇을 공유하고, 어디까지 확장하며, 무엇을 효율화하고, 어떤 신뢰를 보장하려는지 질문할 수 있다.

결국 얻게 되는 것은 용어 목록이 아니다. 편지가 왜 그 길을 선택했고 어디에서 멈췄는지를 자기 언어로 설명하는 힘이다.

[Network] 00. 네트워크 이해를 위한 우체국 편지 비유

기록하는 백엔드개발자 — Wed, 15 Jul 2026 00:40:09 +0900

목차: [Network] TCP/IP를 우편 시스템으로 이해하기

ㅁ 들어가며

이 글은 만화 주인공 같은 크루가 (GitHub)network-fundamentals-lab의 내용을 보고 설명을 요청하면서 작성하였다.

이 network-fundamentals-lab 프로젝트는 네트워크 실습 프로젝트을 위한 튜토리얼이다. 보며 다시 생각한 TCP/IP의 본질

이 프로젝트는 단순히 TCP/IP 개념을 설명하는 것이 아니라, 의도적으로 네트워크를 고장 낸 뒤 그 장애를 직접 관찰하고 해결하는 방식으로 구성되어 있다.

ARP, VLAN, Routing, NAT, TCP, MTU, DNS, Dynamic Routing까지...

총 17개의 실습을 통해 실제 네트워크에서 발생하는 문제를 재현하고, tcpdump, traceroute, ip route 같은 도구로

원인을 추적해 보는 상당히 잘 만들어진 교육용 저장소였다.

프로젝트를 살펴보면서 한 가지 생각이 들었다.

"네트워크를 기술 용어로 설명하기보다, 우편 시스템으로 설명하면 훨씬 이해하기 쉽지 않을까?"

TCP/IP는 많은 사람이 어렵다고 느끼는 분야다.

ARP, MAC Address, Routing, TTL, MTU…

용어 하나하나를 이해하려고 하다 보면 금세 길을 잃는다.

하지만 조금만 시선을 바꾸면 네트워크는 우리가 이미 매일 경험하고 있는 시스템과 매우 닮아 있습니다.

바로 우편 시스템이다.

ㅁ 우리는 매일 편지를 보내고 있다

친구에게 편지를 보낸다고 생각해 보자.

편지를 봉투에 넣고 주소를 적은 뒤 우체통에 넣는다.

그 이후의 과정은 어떻게 될까요?

나
 │
우체통
 │
집배원
 │
동네 우체국
 │
우편집중국
 │
지역 우체국
 │
집배원
 │
상대방

우리는 이 과정을 자세히 알지 못한다. 편지가 도착하기만 하면 되기 때문이다.

인터넷도 마찬가지. 웹사이트에 접속하고, 메신저를 보내고, AI에게 질문을 던지는 순간에도

데이터는 이와 비슷한 과정을 거쳐 목적지까지 이동한다.

우리는 결과만 사용할 뿐, 그 내부에서 어떤 일이 일어나는지는 거의 의식하지 않는다.

ㅁ 네트워크의 시작은 '연결'이 아니라 '공유'였다

여기서 한 가지 질문이 생긴다.

왜 이렇게 복잡한 우편 시스템이 만들어졌을까?

처음에는 사람 두 명만 편지를 주고받으면 된다.

나 ───────── 친구

직접 전달하면 끝이다.

하지만 사람이 열 명, 백 명, 천 명으로 늘어나면 이야기가 달라진다.

모든 사람이 서로 직접 편지를 전달하려면 연결은 기하급수적으로 증가하고, 결국 아무도 감당할 수 없게 된다.

그래서 우리는 우체국이라는 중간 시스템을 만들었다.

집배원을 공유하고,

우편차를 공유하고,

우편집중국을 공유하면서,

수많은 사람이 하나의 우편 시스템을 함께 사용할 수 있게 되었다.

인터넷도 완전히 같은 원리다.

컴퓨터 두 대를 연결하는 것은 어렵지 않다.

하지만 수십억 대의 컴퓨터가 하나의 네트워크를 함께 사용하려면

연결을 늘리는 것보다 자원을 효율적으로 공유하는 방법이 필요했다.

그 결과 스위치가 생기고, 라우터가 생기고, DNS가 생기고, NAT가 생기고, TCP가 만들어졌다.

이 기술들은 새로운 기능을 추가하기 위해 만들어진 것이 아니다.

한정된 네트워크 자원을 더 많은 사람이 안정적으로 함께 사용할 수 있도록 발전해 온 설계 원칙이다.

이 관점으로 바라보면 TCP/IP는 어려운 기술들의 집합이 아니다.

'데이터를 목적지까지 효율적으로 전달하기 위해 만들어진 거대한 물류 시스템'이라고 이해하는 것이 더 자연스럽다.

이렇게 하면 글의 전체 구조도 더 단단해집니다.

들어가며
    ↓
우리는 매일 편지를 보내고 있다
    ↓
네트워크의 시작은 '공유'였다   ← 추가
    ↓
하지만 DevOps 엔지니어는 다르다
    ↓
그래서 우편 시스템으로 설명하려고 한다

이후 시리즈에서는 자연스럽게 "이 공유 시스템을 구현하기 위해 어떤 기술이 등장했는가"라는 관점으로 ARP → Routing → TTL → NAT → DNS를 연결할 수 있습니다. 독자는 각각의 기술을 암기하는 대신, 하나의 설계 철학 안에서 이해하게 됩니다.

ㅁ 하지만 DevOps엔지니어 혹은 네트워크 엔지니어는 다르다

문제가 생기는 순간 이야기가 달라진다.

사용자는 말한다.

"인터넷이 안 됩니다."

우편으로 바꾸면 이렇다.

"편지가 도착하지 않았습니다."

그 순간부터는 내부 과정을 하나씩 확인해야 합니다.

우체통에서는 정상적으로 수거되었는가?
집배원이 제대로 전달했는가?
어느 우체국까지는 도착했는가?
주소를 잘못 적은 것은 아닌가?
우편집중국에서 다른 지역으로 잘 전달되었는가?
혹시 같은 우체국을 계속 돌고 있는 것은 아닌가?

네트워크 엔지니어도 같은 질문을 한다.

패킷이 어디까지 도착했는지,

어디에서 사라졌는지,

왜 목적지까지 가지 못했는지를 추적하는 것이 네트워크의 본질이다.

ㅁ 마무리

network-fundamentals-lab을 보면서 가장 인상 깊었던 점은 고장을 통해 네트워크를 이해하도록 만든 교육 철학이었다.

나 역시 이 프로젝트를 따라가며 각 장을 정리해 볼 생각이다.

다만 조금 다른 방식으로 접근해 보려고 합니다.

기술 용어를 먼저 설명하는 것이 아니라, 우편 시스템에 비유하여 왜 이런 기술이 필요한지를 먼저 이야기하려고 한다.

이 관점으로 보면 각 기술의 존재 이유도 자연스럽게 연결된다.

ARP : 같은 동네에서 정확한 집을 찾기 위한 주소 조회
Switch : 한 통신선을 여러 장비가 공유하기 위한 장치
Router : 지역 간 우편을 효율적으로 전달하기 위한 중계소
TTL : 네트워크 자원이 무한 루프에 낭비되지 않도록 붙여 놓은 '최대 중계 횟수' 안전장치
NAT : 하나의 공인 IP를 여러 사용자가 공유하기 위한 기술
DNS : 숫자 주소를 모두 외우지 않도록 하는 공용 주소록
TCP : 신뢰성을 확보하면서도 네트워크를 효율적으로 사용하는 전송 규칙

이렇게 바라보면 TCP/IP는 개별 기술들의 집합이 아니라,

한 통의 편지가 목적지까지 안전하게 전달되기 위해 만들어진 거대한 물류 시스템이라는 사실을 자연스럽게 이해할 수 있다.

RONCO 모션데스크 메모리형 리모컨 사용방법

기록하는 백엔드개발자 — Tue, 14 Jul 2026 22:32:11 +0900

듀얼플러스 모션데스크 조립설명서.pdf

3.41MB

[AI] 448MB가 113MB 되는 길 — ONNX INT8 양자화 실전

기록하는 백엔드개발자 — Tue, 14 Jul 2026 21:07:43 +0900

ㅁ 들어가며

엣지 RAG의 임베딩 모델은 폰 안에 들어가야 한다.
그런데 HuggingFace에서 받은 원본은 448MB다.
113MB에 맞춰야 APK 크기도 살고, 메모리도 산다.

이 글은 multilingual-e5-small-ko-v2를 ONNX INT8로 줄이고, 품질이 얼마나 보존되는지 테스트한 기록이다.
파이프라인은 네 단계. 코드는 거의 한 줄씩이다.

ㅁ 양자화가 하는 일 — float32 → int8

예전에 "LLM 양자화 & 로컬 추론 최적화"를 언젠가 제대로 다룰 주제로 적어둔 적이 있다.
파라미터가 GPT-3의 10배로 뛰던 시대(관련 글: [AI] 최근 대규모 언어 모델(LLM)의 급격한 성장 이유)의 반대편에,

이 글이 그 숙제를 실전으로 꺼내온다.

ㅇ 버리는 것과 지키는 것
양자화의 이론적 배경은 [LLM System Lab의 Quantization 토픽]에 더 깊게 정리해두었다.

이 글은 그 위에서 실전 파이프라인에 집중한다.

모델 파라미터는 기본적으로 float32로 저장된다.
한 숫자에 4바이트를 쓴다.
양자화는 이걸 int8(1바이트)로 압축한다 — 용량 1/4.

단순히 "0~255 범위로 잘라 넣기"는 아니다.
각 레이어의 가중치 범위를 측정해서 scale과 zero point로 매핑한다.
쉽게 말하면 - scale은 float 값을 INT8 범위(-128~127)에 얼마나 압축할지의 비율,
zero point는 float의 0이 INT 축 위 어디에 놓이는지의 기준점이다.
1바이트 정수 하나를 "원래 float의 근사치"로 되돌릴 수 있게.

→ 정보가 일부 손실된다.
하지만 자연어 임베딩은 상대적 유사도만 보존하면 되므로 손실이 뒤쪽까지 잘 이어지지 않는다.

ㅇ 동적 양자화 vs 정적 양자화

방식	가중치	활성화	필요한 것
Dynamic	INT8 저장	추론 시 동적 계산	없음 — 한 줄로 끝
Static	INT8 저장	INT8 사전 계산	calibration 데이터셋
QAT (훈련 중 양자화)	INT8	INT8	재학습 필요

이번에 쓴 건 Dynamic.
이유: calibration 데이터셋 준비 비용이 크고, 임베딩 모델은 activation 분포가 비교적 고른편이라 정적까지 안 가도 품질이 유지된다.

ㅁ 실전 파이프라인 4단계

ㅇ 1. PyTorch → ONNX export
HuggingFace `optimum` CLI 한 줄로 끝.

optimum-cli export onnx \
  --model dragonkue/multilingual-e5-small-ko-v2 \
  --task feature-extraction \
  ./e5-ko-v2-onnx/

결과:
- model.onnx — 448MB (float32)
- tokenizer.json — 16MB
- 메타 파일들 (config, tokenizer_config 등)

이 단계만으로도 이미 추론은 가능하다.
PyTorch 없이 ONNX Runtime만으로 돌릴 수 있어 크로스 플랫폼 의존성이 사라진다.

ㅇ 2. INT8 동적 양자화
Python 몇 줄.

from onnxruntime.quantization import quantize_dynamic, QuantType

quantize_dynamic(
    model_input="e5-ko-v2-onnx/model.onnx",
    model_output="model_int8.onnx",
    weight_type=QuantType.QInt8,
)

결과: 112.6MB (원본의 25%).

weight_type은 INT8/UINT8 둘 다 가능.
QInt8는 부호 있는 정수 — 음수 가중치가 있는 일반적인 선택.

ㅇ 3. 품질 검증
양자화로 얼마나 망가졌는지 실제로 재본다.
원본 모델과 INT8 모델을 같은 텍스트에 돌려 cosine similarity를 잰다.

# 원본
ref = sentence_transformer.encode("query: 쿠버네티스 헬스체크")

# INT8 ONNX
onnx_vec = onnx_session.run(...)

# 두 벡터 사이 cosine
sim = cosine(ref, onnx_vec)  # 0.97~0.98

0.97 이상이면 실용 OK.
1.0에서 멀어진 만큼 두 벡터가 달라진 건 맞다.
하지만 검색은 절대 거리가 아니라 상대 순위로 동작한다

원본이 뽑는 Top-3 문서와 양자화 모델이 뽑는 Top-3 문서가 같은 순서로 나오면 사용자 경험은 구별되지 않는다.
0.97은 경험상 이 "순위 보존" 조건을 거의 항상 충족하는 값이다.

ㅇ 4. 모바일 assets 배치
Android 앱의 `assets/` 폴더에 두 파일을 넣는다.

mobile/app/src/main/assets/
├── model.onnx      (113MB)
└── tokenizer.onnx  (5MB, ORT-extensions)

토크나이저는 `tokenizer.json`(16MB) 대신 ONNX 그래프로 변환(5MB)해서 넣었다.
이유는 아래 "짚어볼 것들"에서 설명한다.

ㅁ 품질은 어디까지 떨어졌나

한국어 쿼리 5개로 검색 품질을 실제 측정했다.

쿼리	원본 Top-1 distance	INT8 Top-1 distance	일치
쿠버네티스 헬스체크	0.412	0.415	✓ 동일 문서
APM 모니터링	0.337	0.340	✓
RAG 시스템	0.289	0.295	✓
graceful shutdown	0.356	0.361	✓
prometheus pull	0.421	0.427	✓

거리 값이 0.003~0.006 증가했지만 Top-1 문서는 모두 동일.

ㅁ 짚어볼 것들

ㅇ 동적 양자화는 가중치만 — 활성화는 그대로다

"INT8 모델"이라고 하면 모든 연산이 8비트로 도는 것처럼 들린다.
하지만 동적 양자화는 가중치만 INT8로 저장하고, 실제 행렬곱은 INT8↔float 변환이 섞인다.
CPU에서는 작은 연산이라 큰 문제가 없지만, NPU/GPU 가속이 필요할 땐 한계가 된다.

→ 모바일 NPU를 최대 활용하려면 정적 양자화나 QAT로 가야 한다.
정적 양자화는 activation의 scale까지 사전에 고정해 추론 내내 INT8로만 돈다.

QAT(훈련 중 양자화)는 훈련 때부터 양자화 오차를 학습에 반영해 품질 손실을 더 줄인다.
둘 다 NPU가 INT8 연산만 빠르게 처리하는 특성에 맞춘 최적화다.
이번엔 CPU 추론이 목표라 동적이 충분했다.

ㅇ 토크나이저도 배포에 포함해야 한다 (함정 1)

모델만 양자화하면 끝이 아니다.
임베딩 전에 텍스트를 토큰 ID로 바꾸는 토크나이저가 필요하다.
tokenizer.json(16MB)은 HuggingFace 표준이지만, Android에서 쓰려면 별도 라이브러리(DJL 등)가 필요했다.

DJL이 Android arm64 네이티브 바이너리를 공식 배포하지 않는다는 사실을 뒤늦게 확인했다.

대안:

onnxruntime-extensions의 SentencepieceTokenizer를 ONNX 그래프로 뽑아 model.onnx 옆에 tokenizer.onnx로 동봉.

→ 양자화 파이프라인의 출력물은 모델 하나가 아니라 모델 + 토크나이저 세트다.

ㅇ 품질 검증은 벤치마크가 아니라 "내 쿼리"로 한다

MTEB 같은 공개 벤치마크 점수는 참고용이다.
양자화 전후 내가 실제로 쓸 쿼리로 Top-1이 유지되는지 재보는 게 더 중요하다.
118 청크 규모에선 5~10개 대표 쿼리로도 충분히 의사결정할 수 있다.

→ "벤치마크 점수가 0.85에서 0.83으로 떨어졌다"보다 "내 실제 쿼리 5개가 전부 같은 문서를 뽑는다"가 더 믿음직하다.

ㅇ INT4, BF16, Matryoshka — 다음 선택지

INT8에서 멈출 이유는 없다.

선택	크기	품질	비용
INT4	~56MB	약간 손실 더	도구는 성숙, 검증 필요
BF16	~224MB	거의 무손실	CPU 지원 고르지 않음
Matryoshka 차원 절단	비례	점진적 손실	모델이 지원해야 함

→ 앞으로 실험할 방향.
특히 Matryoshka는 양자화와 차원 절단이 독립이라 둘을 곱해 쓸 수 있다.

ㅁ 마무리

원본 448MB와 INT8 113MB는 **같은 지식을 담은 서로 다른 그릇**이다.
손실은 분명히 있지만, Top-1 검색 관점에서는 눈에 띄지 않는다.
덕분에 모델이 **주머니에 들어갔다.**

→ 양자화는 모델을 작게 만드는 게 아니라, **쓸모의 모양을 맞추는 과정**이다.

ㅁ 함께 보면 좋은 사이트

ㅇ 양자화 도구
- HuggingFace Optimum (ONNX export): https://huggingface.co/docs/optimum
- ONNX Runtime Quantization: https://onnxruntime.ai/docs/performance/model-optimizations/quantization.html
- onnxruntime-extensions (tokenizer as ONNX): https://github.com/microsoft/onnxruntime-extensions

ㅇ 모델
- dragonkue/multilingual-e5-small-ko-v2: https://huggingface.co/dragonkue/multilingual-e5-small-ko-v2
- MTEB 벤치마크: https://huggingface.co/spaces/mteb/leaderboard

ㅇ 더 공부하기 — LLM System Lab
- Quantization (이론 심화): https://llm-study-web.vercel.app/topic/quantization
- Embedding: https://llm-study-web.vercel.app/topic/embedding
- Embedding Space (인터랙티브 Lab): https://llm-study-web.vercel.app/labs/embedding-space

ㅇ 연관된 이전 글 (양자화 흐름)
- LLM 파라미터가 커지던 시대: https://peterica.tistory.com/762
- RAG/Agent/Infra 엔지니어의 지식 정리법 (양자화 관심 주제로 등록): https://peterica.tistory.com/997

ㅇ 시리즈
- [AI] 1,000개 블로그 글 Wiki에 로컬 RAG 챗봇 붙이기 — peterica-blog-chat
- [AI] sqlite-vec vs ANN: 왜 지금은 KNN이 더 적합한가: qlite-vec 선택 이유
- [온디바이스AI] 내 폰으로 나만의 RAG 만들기(온디바이스 RAG 최소 아키텍처)

[Gradle] compileOnly는 "배포 안 함"이 아니다 — AAR과 POM은 서로 다른 것을 배포한다

기록하는 백엔드개발자 — Fri, 10 Jul 2026 23:35:10 +0900

ㅁ 들어가며

라이브러리를 만들어 Maven에 올려본 적이 있다면 compileOnly를 한 번쯤 써봤을 것이다.

"컴파일할 때만 필요하고 배포물에는 안 들어간다"는 설명은 어디에나 있다. 맞는 말이다.

그런데 이 문장에는 숨은 주어가 있다. 누가 배포하지 않는다는 것인가?

compileOnly가 보장하는 건 "내 바이너리에 안 들어간다"이지, "내 소비자의 바이너리에 안 들어간다"가 아니다.

그리고 이 둘 사이를 갈라놓는 것이 POM이다.

라이선스 이슈를 대응하기 위해 내 AAR에는 안 넣되고, 소비자에게는 전달하고 싶은 경우 사용할 수 있는 방법이다.

ㅁ 라이브러리는 두 개를 배포한다

Maven 저장소에 올라가는 것을 뜯어보자.

com/example/mylib/1.0.0/
├── mylib-1.0.0.aar      ← 바이너리 (코드)
├── mylib-1.0.0.pom      ← 메타데이터 (의존성 선언)
└── mylib-1.0.0.module   ← Gradle Module Metadata (선택)

- AAR은 "내가 무엇을 담고 있는가"를 말한다.
- POM은 "나를 쓰려면 무엇이 더 필요한가"를 말한다.

소비자의 Gradle이 implementation 'com.example:mylib:1.0.0'을 만나면,

AAR을 다운로드하기 전에 POM부터 읽는다.

거기 적힌 <dependency>들을 의존성 그래프에 편입시키고, 함께 다운로드한다.

즉 POM은 실행 가능한 지시문이다. 단순한 설명서가 아니다.

ㅁ 각 스코프는 POM에 어떻게 기록되는가

Gradle 스코프	내 컴파일	내 런타임	POM 기록	소비자 컴파일	소비자 런타임
api	O	O	compile	O	O
implementation	O	O	runtime	X	O
compileOnly	O	X	없음	X	X
compileOnlyApi	O	X	compile	O	X
runtimeOnly	X	O	runtime	X	O

- implementation은 POM에 runtime 스코프로 기록된다. 소비자의 컴파일 클래스패스에는 안 올라가지만 APK에는 들어간다. 캡슐화는 되지만 배포는 된다.

- compileOnly만이 유일하게 POM에 아무 흔적도 남기지 않는다. Gradle의 apiElements/runtimeElements 어느 configuration에도 속하지 않기 때문이다. maven-publish 플러그인이 POM을 만들 때 참조하는 게 바로 이 configuration들이다.

- compileOnlyApi는 헷갈리기 쉽다. 이름은 compileOnly 계열이지만 POM에는 compile로 기록된다. 소비자의 컴파일 클래스패스에 전파된다. 어노테이션 라이브러리처럼 "소비자도 컴파일 시점엔 필요하지만 런타임엔 없어도 되는" 것에 쓴다. AGP(Android Gradle Plugin)에서의 지원 여부는 버전마다 다르니 확인이 필요하다.

여담으로, Maven에는 Gradle의 compileOnly에 정확히 대응하는 스코프가 없다. 가장 가까운 건 provided인데, 이건 "런타임 환경이 제공해줄 것"이라는 의미라 뉘앙스가 다르다. maven-publish는 provided를 생성하지 않는다.

ㅁ 번들과 전파를 구분하라

여기서 두 개념을 분리해야 한다. 실무에서 가장 많이 섞이는 지점이다.

번들 (bundling)
  내 AAR의 classes.jar 안에 서드파티 .class 파일이 물리적으로 들어감
  → "내 바이너리가 그 코드를 담고 있다"

전파 (propagation)
  내 POM의 dependency 선언 때문에 소비자 빌드에 자동 유입됨
  → "내 바이너리엔 없지만, 내 선언 때문에 소비자가 받아간다"

	번들	전파
어디에 기록	AAR classes.jar, libs/	POM <dependencies>
확인 방법	jar tf	cat *.pom
compileOnly	X	X
implementation	X	O
shadow/fat-jar	O	X

일반적인 Gradle 라이브러리는 번들하지 않는다. implementation으로 선언해도 상대 라이브러리의 클래스가 내 jar에 복사되지는 않는다. 복사는 Shadow 플러그인 같은 걸 명시적으로 써야 일어난다.

그래서 "우리 AAR에 그 코드 없습니다"는 대부분의 경우 참이지만, 동시에 대부분의 경우 의미 없는 문장이다.

원래 없다. 중요한 건 전파 여부다.

ㅁ 그래서 build.gradle과 publish.gradle은 무엇을 하는가

build.gradle    → "내가 어떻게 컴파일되는가"를 정의
publish.gradle  → "내가 어떻게 배포되는가"를 정의

- 이상적인 세계에서는 후자가 전자로부터 자동 유도된다. AGP 7.0부터는 이렇게 쓴다.

// build.gradle
android {
    publishing {
        singleVariant("release") {
            withSourcesJar()
        }
    }
}

// publish.gradle
afterEvaluate {
    publishing {
        publications {
            release(MavenPublication) {
                from components.release   // ← 여기가 핵심
                groupId = 'com.example'
                artifactId = 'mylib'
                version = '1.0.0'
            }
        }
    }
}

- from components.release가 하는 일이 중요하다.

이건 AGP가 만들어준 SoftwareComponent를 publication에 연결하는 것이다.

그 컴포넌트는 apiElements와 runtimeElements를 알고 있고,

maven-publish는 그걸 읽어서 POM의 <dependencies>를 자동 생성한다.

api 선언 → <scope>compile</scope>
implementation 선언 → <scope>runtime</scope>
compileOnly 선언 → 아무것도 안 나옴

진실의 원천이 하나다. build.gradle만 고치면 POM이 따라온다.

ㅁ pom.withXml — 수동으로 POM을 조작하기

publishing {
    publications {
        release(MavenPublication) {
            // from components.release 가 없다!
            def output = variant.getPackageLibraryProvider().get().getArchivePath()
            artifact(output) {
                builtBy variant.getAssembleProvider().get()
            }

            pom.withXml {
                Node dependenciesNode = asNode().appendNode('dependencies')
                def addDependencyNode = { group, name, ver ->
                    Node d = dependenciesNode.appendNode('dependency')
                    d.appendNode('groupId', group)
                    d.appendNode('artifactId', name)
                    d.appendNode('version', ver)
                    d.appendNode('scope', 'compile')
                }
                addDependencyNode('org.jetbrains.kotlin', 'kotlin-stdlib', kotlinVersion)
                addDependencyNode('com.android.installreferrer', 'installreferrer', '1.0')
            }
        }
    }
}

여기서 from components.release 대신 artifact(output)으로 AAR 파일을 raw로 붙였다.

SoftwareComponent가 없으니 maven-publish는 의존성 정보를 알 방법이 없다.

POM의 <dependencies>는 텅 비어서 나온다.

그래서 pom.withXml로 직접 XML 노드를 박아 넣는다.

asNode()가 POM의 루트를 반환하고, 거기에 <dependencies>를 통째로 만들어 붙이는 것이다.

ㅁ 왜 이렇게 하는가

주로 세 가지 이유다.

하나. 레거시. AGP 3.x 시절에는 components.release가 없었다. pom.withXml이 유일한 방법이었고, 그 코드가 살아남았다.

둘. compileOnly로 선언한 것을 POM에는 넣고 싶을 때. 내 AAR에는 안 넣되, 소비자에게는 전달하고 싶은 경우다. Gradle 스코프만으로는 이 조합이 안 나온다.

셋. 세밀한 제어. 버전 범위, optional, exclusions 등을 직접 쓰고 싶을 때.

ㅁ 영향도

pom.withXml로 scope=compile을 박아 넣으면 어떻게 되는가.

build.gradle:   compileOnly 'com.android.installreferrer:installreferrer:1.0'
                → 내 AAR에 없음. 내 컴파일에만 쓰임.

publish.gradle: <dependency>
                  <groupId>com.android.installreferrer</groupId>
                  <artifactId>installreferrer</artifactId>
                  <version>1.0</version>
                  <scope>compile</scope>        ← Maven compile = transitive
                </dependency>
                → 소비자가 자동으로 받아감. APK에 들어감.

- 같은 라이브러리가 이중생활을 한다.

내 빌드에서는 compileOnly, 소비자 빌드에서는 compile. 번들은 아니지만 전파는 된다.

- 의도한 것이라면 정당한 설계다.

특히 재배포 제한이 있는 라이브러리(Google Play Services 계열 등)를 fat-jar로 번들하지 않으면서

소비자에게 필요한 의존성을 알려주는 방법이 된다.

번들하면 라이선스 위반 소지가 있지만, POM 선언은 "Google Maven에서 직접 받아가세요"라는 안내에 불과하다.

문제는 의도하지 않았을 때 이 구조가 조용하다는 점이다.

ㅁ pom.withXml의 함정 다섯 가지

진실의 원천이 두 개가 된다

build.gradle에서 의존성 버전을 올려도 publish.gradle의 하드코딩된 문자열은 그대로다.

실제로 이런 어긋남을 자주 본다.

// build.gradle
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.22"

// publish.gradle
addDependencyNode('org.jetbrains.kotlin', 'kotlin-stdlib', kotlinVersion)
//                                         ^^^^^^^^^^^^^ 아티팩트 이름이 다름

내가 컴파일한 것과 소비자가 받아가는 것이 다르다.

Gradle Module Metadata가 있으면 POM이 무시된다

.module 파일이 함께 발행되면, Gradle 소비자는 POM이 아니라 .module을 읽는다.

POM은 Maven 소비자용 폴백이 된다.

즉 from components.release와 pom.withXml을 동시에 쓰면,

pom.withXml로 추가한 의존성이 Gradle 사용자에게는 보이지 않는다.

Maven 사용자에게만 보인다. 재현하기 까다로운 종류의 버그다.

앞의 예제 코드처럼 artifact(output)만 쓰면 SoftwareComponent가 없어 .module이 생성되지 않으므로 이 문제는 안 생긴다. 대신 다른 것들을 다 잃는다.

의존성 관리 기능이 죽는다

.module이 없으면 Gradle이 제공하는 것들이 함께 사라진다.

variant-aware 의존성 해석
platform() / BOM을 통한 버전 정렬
능력(capability) 기반 충돌 감지
rich version constraint (strictly, prefer, reject)

툴이 못 본다

의존성 스캐너, SBOM 생성기, 라이선스 검증 도구는 대개 build.gradle의 선언을 파싱하거나 Gradle 의존성 그래프를 조회한다.

pom.withXml 클로저 안에서 Groovy 코드로 만들어지는 노드는 빌드를 실행해야만 알 수 있다.

./gradlew dependencies에도 안 나온다. 그 태스크는 configuration을 보지, POM을 보지 않는다.

scope=compile은 생각보다 강하다

Maven의 compile 스코프는 전파된다. 소비자의 컴파일 클래스패스와 런타임 클래스패스에 모두 올라가고, 그 소비자의 소비자에게까지 전파된다.

대부분의 경우 runtime이 더 적절하다. 소비자가 그 API를 직접 호출할 게 아니라면.

ㅁ 어떻게 쓸 것인가

원하는 것	쓸 것
내 구현에만 필요, 소비자는 몰라도 됨	implementation
소비자가 내 API를 쓰려면 타입이 필요	api
컴파일에만 필요, 런타임엔 없어도 됨 (어노테이션 등)	compileOnly
위와 같지만 소비자 컴파일에도 필요	compileOnlyApi
선택적 기능. 쓰려면 소비자가 직접 추가	compileOnly + 리플렉션 + 문서화
내 바이너리엔 없지만 소비자는 반드시 받아야 함	implementation 또는 명시적 POM 선언

마지막 줄이 pom.withXml이 필요해지는 지점이다. 그리고 그때조차, 가능하면 이렇게 쓰는 게 낫다.

// pom.withXml 대신
publishing {
    publications {
        release(MavenPublication) {
            from components.release
            pom {
                withXml {
                    // 정말 불가피한 경우에만
                }
            }
        }
    }
}

from components.release로 기본 의존성을 자동 생성시키고, 정말 예외적인 항목만 손대는 것이다.
그리고 pom.withXml을 썼다면 README에 반드시 적어야 한다. 코드를 읽는 사람도, 스캐너도 그 안을 들여다보지 못한다.

ㅁ 마무리

하나. compileOnly가 보장하는 건 "내 바이너리에 없다"이지 "소비자에게 안 간다"가 아니다. 그 차이를 POM이 만든다.

둘. 번들과 전파는 다른 문제다. 일반적인 Gradle 라이브러리는 애초에 번들하지 않으므로, "우리 AAR에 없습니다"는 대개 참이면서 동시에 무의미한 문장이다.

셋. pom.withXml은 build.gradle과 별개의 진실을 만든다. 강력하지만, 그 강력함이 정확히 위험한 이유다.

배포되는 것을 알고 싶으면 build.gradle이 아니라 POM을 열어보면 된다. 5초면 끝난다.

[온디바이스AI] 로컬 LLM에서 중요한 것은 CPU가 아니라 메모리다 - 맥미니와 모델 크기의 관계

기록하는 백엔드개발자 — Wed, 20 May 2026 11:20:07 +0900

TL;DR

로컬 LLM 환경에서 가장 먼저 부딪히는 벽은 연산 성능보다 메모리다.

작은 모델은 “문장을 생성”하지만,
큰 모델은 “컨텍스트를 유지하며 추론”한다.

결국 로컬 AI 머신의 핵심은 CPU 속도가 아니라,
얼마나 큰 모델과 Context를 메모리에 안정적으로 올릴 수 있는가에 가깝다.

ㅁ 들어가며

오늘 한 크루가 맥미니를 구매해서 로컬 LLM 기반 서비스를 직접 만들어 보고 싶다고 이야기했다.

그러면서 자연스럽게 이런 질문이 나왔다.

“맥미니를 산다면 CPU가 중요할까, GPU가 중요할까?”

처음에는 보통 코어 수나 GPU 성능을 먼저 보게 된다.

그런데 실제로 로컬 LLM을 구성해보면 병목은 생각보다 다른 곳에서 먼저 나타난다.

좀 더 자세한 글) [AI] GPU vs PIM vs NPU - 내 시스템의 병목은 연산인가, 메모리인가

모델이 커질수록 가장 먼저 부족해지는 것은 연산 성능보다 메모리다.

특히 Apple Silicon은 통합 메모리 구조이기 때문에 이 특징이 더 강하게 드러난다.

ㅁ 로컬 LLM은 왜 메모리를 많이 먹는가

일반적인 PC에서는 CPU 메모리와 GPU VRAM이 분리되어 있다.

하지만 Apple Silicon은 다르다.

CPU, GPU, Neural Engine이 모두 같은 메모리를 공유한다.

즉 로컬 LLM을 실행할 때 메모리는 단순히 “프로그램 실행 공간”이 아니다.

다음 요소들이 모두 메모리를 사용한다.

모델 가중치(weight)
KV Cache
Context Window
Embedding
Attention 중간 상태
RAG 데이터 처리

문제는 모델이 커질수록 단순히 저장 공간만 늘어나는 것이 아니라,
“계속 읽어와야 하는 데이터”가 급격히 증가한다는 점이다.

특히 추론(decode) 단계에서는:

이전 토큰 상태를 계속 참조하고
KV Cache를 반복적으로 읽고
긴 Context를 유지해야 한다.

즉 AI 추론은 생각보다 “계산”보다 “메모리 접근” 비용이 더 커진다.

그래서 로컬 LLM에서는 CPU 성능보다 메모리 용량과 대역폭이 훨씬 중요하게 체감된다.

ㅁ 작은 모델은 왜 쉽게 맥락을 잃는가

처음 로컬 LLM을 접하면 7B~8B 모델만으로도 꽤 놀랍다.

번역도 되고,
요약도 되고,
코드도 어느 정도 작성한다.

하지만 조금만 복잡한 작업을 시키면 한계가 드러난다.

예를 들면:

이전 조건을 잊는다
긴 문서를 읽다가 핵심을 놓친다
여러 제약을 동시에 유지하지 못한다
Agent 흐름이 쉽게 무너진다

처음에는 “프롬프트를 잘못 준 것 아닐까?”라고 생각했는데, 계속 사용하다 보니 단순 프롬프트 문제가 아니었다.

작은 모델은 “문장을 생성”하는 능력은 괜찮지만, 긴 흐름을 유지하며 추론하는 능력은 제한적이다.

즉 말은 자연스럽지만, 생각의 지속성이 약하다.

ㅁ 모델 크기가 커질수록 달라지는 점

14B~16B 정도부터는 확실히 느낌이 달라진다.

이 구간부터는:

여러 조건을 동시에 유지하고
문서 구조를 이해하려 하고
이전 Context를 덜 잊는다.

특히 RAG와 연결했을 때 차이가 크다.

7B에서는 검색된 문서 일부만 참고하다가 핵심을 놓치는 경우가 많았는데,
16B급부터는 “문서를 기반으로 답하려는 느낌”이 생긴다.

그리고 32B 구간부터는 체감이 더 커진다.

이 시점부터는:

장기 Context 유지
설계 reasoning
Multi-Agent 흐름
코드 구조 이해

같은 작업이 꽤 안정적으로 동작한다.

개인적으로는 이 구간부터 로컬 LLM이 단순 장난감이 아니라 “도구”처럼 느껴진다.

실사용 관점으로 정리하면 대략 이런 느낌이다.

모델급	권장 메모리	체감 능력
7B~8B	16GB	번역, 요약, 단순 코드 보조, 짧은 질답	추론 깊이가 얕음. 긴 대화에서 맥락 손실 잦음
14B~16B	24~32GB	간단한 추론, 문서 구조 이해, 기본 Agent 가능	여러 조건 비교/장기 계획 약함
32B	64GB	“생각하는 느낌”이 생김. RAG 활용 안정화	복합 추론에서 아직 실수 존재
70B	128GB+	클라우드 모델에 가까운 품질 체감	비용/속도 부담 큼
MoE 대형 모델	128GB~256GB	특정 영역 매우 강력	로컬 운영 난이도 매우 높음

ㅁ 결국 맥미니에서 중요한 것은 메모리다

흥미로운 점은 로컬 LLM 환경에서는 CPU 업그레이드보다 메모리 업그레이드 체감이 훨씬 크다는 점이다.

실제로는 다음처럼 느껴진다.

여기서 중요한 점은 “실행 가능”과 “안정적으로 운용 가능”은 완전히 다르다는 것이다.

메모리가 부족하면 일부 데이터를 SSD swap으로 넘기게 되는데, 이 순간부터 응답 속도가 급격히 느려진다.

그리고 단순히 느려지는 것을 넘어서, 추론 흐름 자체가 끊기는 느낌이 발생한다.

ㅁ 마무리 — 로컬 LLM의 병목은 결국 메모리다

처음에는 로컬 AI 머신이라고 하면 CPU나 GPU 성능을 먼저 떠올리게 된다.

하지만 실제로 계속 실험해보면 생각보다 더 중요한 것은

“얼마나 큰 모델과 Context를 메모리에 안정적으로 유지할 수 있는가”

였다.

결국 로컬 LLM 환경에서 중요한 것은 단순 FLOPS가 아니라,
Context를 잃지 않고 계속 유지할 수 있는 메모리 구조에 더 가까운 것 같다.

[독후감] 협상의 기술

기록하는 백엔드개발자 — Sun, 10 May 2026 00:25:26 +0900

https://product.kyobobook.co.kr/detail/S000000597965

ㅁ 들어가며

예전에 읽었던 세이노의 가르침에서 추천했던 책이다.
나는 책을 읽을 때 단순히 내용을 따라가기보다, 작가와 대화하듯 읽으려고 한다. 그래서 먼저 작가가 어떤 사람인지 이해하고, 어떤 경험과 관점으로 자신의 생각을 전달하려 하는지 살펴본다. 그리고 각 챕터가 그 핵심적인 생각을 어떤 방식으로 풀어내고 있는지 작가의 입장에서 따라가며 읽으려 노력한다.

ㅁ ChatGPT 작가의 사고방식을 이해하며 읽기

허브 코헨을 이해하기 위해 단순히 책의 내용만 따라가지는 않았다.

책을 읽다가 생기는 궁금한 점이나 이해되지 않는 관점들을 계속 정리하며, 작가가 왜 이런 사례를 들었는지, 결국 어떤 생각을 전달하려 하는지 스스로 해석해보려 했다.

특히 허브 코헨은 일반적인 자기계발서처럼 핵심 이론을 먼저 설명하는 방식으로 글을 쓰지 않는다. 오히려 다양한 사례를 먼저 보여주고, 독자가 그 안에서 스스로 핵심을 발견하도록 유도하는 방식에 가깝다. 그래서 처음에는 “이 사례는 왜 등장했을까?”, “결국 무엇을 말하려는 걸까?”라는 생각이 자주 들었다.

하지만 이런 흐름을 따라가다 보니, 허브 코헨은 단순히 협상 기술을 설명하려는 사람이 아니라, 독자가 기존의 고정된 사고방식을 다시 바라보게 만드는 사람이라는 점을 조금씩 이해하게 되었다. 그는 정답을 직접 설명하기보다, 사례를 통해 독자의 생각을 흔들고 스스로 깨닫게 만드는 방식으로 글을 전개하고 있었다.

이런 흐름을 더 깊게 이해하기 위해, 나는 ChatGPT에게 허브 코헨의 관점과 말하는 방식을 함께 분석하여 작가처럼 답변해달라고 요청했다. 단순히 내용을 요약해달라는 것이 아니라, 마치 허브 코헨 작가와 대화하듯 “왜 이런 사례를 들었는가”, “이 상황에서 무엇을 말하려는 것인가”를 계속 질문하며 읽었다.

특히 이해가 어려웠던 부분은 『세상에 불가능한 협상은 없다』 챕터였다. 사례는 계속 이어지는데 명확한 결론이 바로 드러나지 않아 처음에는 흐름을 따라가기 어려웠다. 하지만 대화를 이어가며, 허브 코헨은 협상 기술 자체를 설명하려는 사람이 아니라 독자의 고정된 사고방식을 흔들고 새로운 관점으로 상황을 바라보게 만드는 사람이라는 점을 조금씩 이해하게 되었다.

이 과정은 단순히 책 내용을 정리하는 것과는 달랐다. 오히려 작가의 머릿속 사고 흐름을 따라가며 “왜 이런 생각을 했는가”를 추적하는 경험에 가까웠다. 덕분에 책의 내용을 외우기보다, 허브 코헨이 세상을 바라보는 방식을 조금 더 이해하며 읽을 수 있었다.

ㅁ 작가에 대한 이해

허브 코헨(Herb Cohen)(1931~2015)은 50년 넘게 미국 대통령, 법무부, FBI, CIA 등에서 협상 자문을 맡아온 세계적인 실전 협상 전문가이다.

그의 특징은 협상을 비즈니스 기술서가 아니라 일상 인간관계의 본질로 본다는 점이다.

여러분 각자 자신의 자리와 신념의 체계 안에서 자신만의 고유한 요구를 바탕으로 자신이 원하는 것을 얻는 방법을 깨닫기 바란다.
머릿말, p9

그는 협상을 기술적이나 법률적으로 설명하지 않고, 일상에 포함한 인간 행동의 문제로 설명한다.

그래서 책에서도 법칙이나 이론보다 실제 사례와 심리 묘사가 많다.

그의 문체 특징도 뚜렷하다.
- 이론보다 이야기 중심
- 우화·실화·농담이 많음
- 상대 심리를 해석하는 방식
- 독자에게 “세상은 이렇게 돌아간다”를 체험시키는 구조
그래서 책을 읽다 보면 “논리적으로 설명한다”기보다, 마치 경험 많은 협상가가 옆에서 사례를 들려주는 느낌이 강하다.

허브 코헨의 핵심 관점은 크게 세 가지로 정리된다.
협상은 정보, 시간, 힘의 게임이다. p22

협상 능력이란 행동에 영향을 미치는 정보, 시간, 힘을 분석하여 요구가 자신이 원하는 방식대로 이루어지도록 만드는 것이다. p23

협상은 한계를 넘어서는 힘인 것이다. 하지만 그것이 윤리적 판단은 중립적이다.

협상가로서 위험을 감수하고, 과거의 경험에서 벗어나 자신이 세운 가정에 도전하고, 목표 수준을 높이고, 기대치를 높여야한다. p33

그래서 그의 글에는 극단적인 초기 입장, 허세, 시간 끌기, 애매한 표현, 심리 압박 같은 요소가 자주 등장한다.

내가 책을 읽으면서 불편함을 느꼈던 부분도 바로 이런 지점이었다.

현대 기준에서는 다소 공격적이거나 조작적으로 보일 수 있는 사례도 많아 비도덕적으로 느껴진다. 예로 말보로 담배 한개비 p78

힘이 그 자체로 좋거나 나쁘지는 않다. 도덕적이거나 비도덕적이지도 않다. 윤리적인 것도 비윤리적인 것도 아니다. 힘은 중립적이다. p73
가능한 여러 목표에 따라 힘을 나눠보면 목표는 유쾌하게 '좋은 것' 또는 가증스럽게 '나쁜 것'일 수 있지만, 그 목표를 달성하는 데 사용하는 힘은 전기나 바람처럼 중립적이다. p74
합당한 범위 내에서, 자신이 가진 옵션에 대해 알고 있고, 자신이 세운 가정을 시험해보고, 확실한 정보를 기반으로 계산한 위험을 감수하고, 자신이 힘을 가지고 있다고 믿는다면 당신은 자신이 원하는 것을 얻을 수 있다. p78

다만 허브 코헨은 협상이 단순히 속이는 기술을 말하려는 사람은 아니다.

오히려 인간 사회 자체가 완전히 합리적이지 않다는 현실을 인정하고, 그 현실 속에서 손해 보지 않기 위한 관찰력을 강조한다.

윤리적인 윈윈 협상가

작가는 이상적인 윤리만으로는 실제 협상에서 밀릴 수 있다는 현실주의적 시각이 강하다. 일반적으로 협상이라고 하면 자신의 이익을 얻기 위한 기술을 떠올리기 쉽지만, 작가는 오히려 상대를 억압하거나 파괴하지 않고 사람들의 사고방식 자체를 변화시키려 했던 인물들을 예로 들고 있다.

두 사람은 초라한 옷을 입고 돌아다니며 사람들에게 질문하며 정보를 수집했다. 1명은 삼단논법을, 다른 1명은 비유를 사용했다. 그들에게는 목표와 기준이 있었다. 그들은 기꺼이 위험을 감수했다. ~중간생략~
그 두 사람은 예수 그리스도와 소크라테스다. 내가 보기에 그 둘은 협상가였다. 그들은 윤리적인 윈윈 협상가들이었고, 힘을 가진 사람들이었다. p23

예수님는 비도더적인 상황에서 십자가에 못박혀 돌아가셨다. 하지만 그의 협상가로서 성경을 통해 오늘도 그 힘은 영향력을 가지고 있다.

소크라테스도 당시 아테네 사회의 기존 가치와 권위에 계속 질문을 던졌고, 결국 많은 사람들에게 불편한 존재가 되었다. 특히 젊은이들을 타락시킨다는 혐의와 신을 부정했다는 이유로 재판에 넘겨졌고, 끝내 사형 선고를 받아 독배를 마시고 죽었다.

예수는 사랑과 용서를 통해 사람들의 삶의 방향을 바꾸려 했고, 소크라테스는 질문과 대화를 통해 스스로 생각하게 만들려 했다. 둘 다 강압적으로 상대를 이기려 하지 않았고, 오히려 사람들에게 새로운 관점을 제시하며 스스로 깨닫게 만들었다는 공통점이 있다.

하지만 현실 세계에서 도덕적 방식은 언제나 환영받는 것은 아니었다. 기존 질서와 사고방식을 흔드는 사람은 결국 불편한 존재가 되기 쉽기 때문이다.

그래서 허브 코헨이 말하는 “윤리적인 윈윈 협상가”라는 표현은 단순히 착하고 부드러운 사람이라는 뜻이 아니라, 자신의 기준과 가치관을 유지하면서도 사람들의 생각과 선택을 변화시키려 했던 사람들에 더 가까워 보였다.

권력에 의지하기 위해 폭력적이 될 필요는 없고,
양심적으로 말하기 위해 온순할 필요는 없다.
가장 효과적인 행동은 권력에 의지하면서
양심적으로 행동하는 것이다. (바바라 데밍) p369

내가 이해한 작가가 말하고자 하는 협상가는 상대를 이기려는 단일 목적이 아니라, 사람들에게 새로운 관점을 제시하여 상생하는 윈윈 협상가이다. 다만 그 협상은 한계를 넘어서기 위해서 자신의 힘, 시간, 정보를 기반으로 합당한 범위 내에서 위험을 감수해야 한다. 작가는 이를 설명하기 위해 이 책에서 법칙이나 이론보다 실제 사례와 심리 묘사로 스스로 해석하게 하였다.

ㅁ 협상으로 이루어진 세상

1. 협상이란 무엇인가

허브 코헨은 협상을 단순한 대화 기술이 아니라, 상대의 선택과 행동을 변화시키는 과정으로 설명한다.
특히 협상은 특별한 상황이 아니라 인간관계 속에서 이미 매일 반복되고 있는 일상적인 구조라고 바라본다.

인상적이었던 점은 협상을 “이기는 기술”보다 “원하는 결과를 얻기 위한 조율 과정”으로 설명한다는 점이었다.
결국 협상은 말을 잘하는 능력보다, 사람과 상황을 어떻게 이해하고 움직이느냐의 문제에 가까워 보였다.

2. 세상에 불가능한 협상은 없다

이 챕터는 처음 읽을 때 가장 이해하기 어려웠던 부분이었다.
사례는 계속 이어지는데 명확한 결론이 바로 드러나지 않았기 때문이다.

하지만 계속 읽다 보니 허브 코헨은 “불가능한 협상은 없다”는 말을 낙관적으로 사용하는 것이 아니었다.
오히려 사람들이 스스로 조건을 고정된 것으로 생각하기 때문에 협상이 막히는 것이며, 관점을 바꾸면 새로운 선택지가 보일 수 있다는 점을 말하려 했던 것 같다.

결국 이 챕터의 핵심은 협상 기술보다, 기존 사고방식을 흔드는 데 있었다.

3. 협상의 세계에 발 들여놓기

허브 코헨은 협상을 거창한 비즈니스 기술이 아니라, 이미 우리의 삶 전체에 포함된 구조로 설명한다.
가족, 친구, 직장, 식당 주문처럼 아주 작은 선택과 조율 속에서도 협상은 계속 일어난다.

이 챕터를 읽으며 느꼈던 것은, 협상을 특별한 능력으로 바라보기보다 인간관계를 이해하는 관점 자체로 받아들이고 있다는 점이었다. 경쟁을 붙이기, 필요 충족하기, 할인 중 등 직원과의 관계에서 안될 것 같은 협상에 정말 다양한 대안을 제시하고 있다.

ㅁ 협상을 좌우하는 3가지 변수

허브 코헨는 협상의 흐름을 결정하는 핵심 요소로

- 힘(당신에게 힘이 있다는 사실을 인지하라),

- 시간(협상은 인내심 싸움이다),

- 정보(상대가 말하지 않는 정보까지 캐내라)

를 제시한다.

그리고 협상은 결국 이 세 가지 변수를 얼마나 잘 이해하고 활용하느냐에 따라 결과가 달라진다고 설명한다.

특히 인상적이었던 점은, 이 요소들이 단순히 객관적인 사실만으로 작동하지 않는다는 점이었다.

실제 힘보다 “힘이 있다고 믿게 만드는 인식”이 더 중요하기도 하고,

시간 자체보다 “누가 더 조급한가”가 협상의 흐름을 결정하기도 한다.

결국 협상은 논리만의 문제가 아니라 인간 심리와 상황 인식의 문제에 더 가까워 보였다.

작가는 힘을 매우 현실적으로 바라본다.
힘은 선하거나 악한 것이 아니라 목표를 이루기 위해 사용하는 중립적인 도구라고 설명한다.

“힘은 그 자체로 좋거나 나쁘지 않다. 힘은 결과가 아니라 수단이다.” p73~76

그래서 책 속에서는 경쟁 유도, 시간 끌기, 애매한 표현, 심리 압박 같은 현실적인 사례들도 자주 등장한다. 처음에는 이런 방식들이 다소 불편하게 느껴졌다. 하지만 허브 코헨은 이를 단순한 속임수로 설명하기보다, 현실 사회가 실제로 어떻게 움직이는지를 보여주려 했던 것 같다.

결국 이 챕터에서 가장 중요하게 느껴졌던 부분은, 협상은 말을 잘하는 사람이 유리한 게임이 아니라는 점이었다. 상대가 무엇을 원하고 있는지, 누가 더 급한지, 어떤 정보와 선택지를 가지고 있는지를 얼마나 잘 이해하느냐가 협상의 흐름을 결정하고 있었다.

ㅁ 2가지 협상 스타일

허브 코헨은 협상 방식을 크게 두 가지 스타일로 나누어 설명한다.

7. “무슨 수를 써서라도 이긴다” 소련 스타일

첫 번째는 상대를 이겨야만 성공이라고 생각하는 “소련 스타일”이다. 이 방식은 극단적인 요구, 심리 압박, 시간 끌기, 허세 같은 방법을 적극적으로 사용한다. 협상을 서로의 조율 과정이 아니라 승패의 문제로 바라보며, 상대보다 우위를 점하는 것 자체를 중요하게 생각한다.

처음에는 이런 방식이 다소 공격적이고 비도덕적으로 느껴졌다. 하지만 허브 코헨은 이런 사례들을 단순히 따라 하라고 설명하기보다, 현실 사회에서는 실제로 이런 방식으로 움직이는 사람들도 존재한다는 점을 보여주려 했던 것 같다. 결국 이런 스타일을 이해해야 상대의 전략에 휘둘리지 않을 수 있기 때문이다.

8. “협상은 쌍방을 위한 것” 윈윈 스타일

반면 작가가 궁극적으로 지향하는 방식은 “윈윈 스타일”이다. 이 방식은 상대를 무너뜨리는 것이 아니라, 서로가 원하는 것을 조율하며 함께 만족할 수 있는 결과를 찾는 협상에 가깝다.

흥미로웠던 점은 허브 코헨이 단순히 착하고 양보하는 태도를 윈윈이라고 설명하지 않는다는 점이었다. 오히려 자신의 힘과 정보, 기준을 명확히 이해한 상태에서 상대와 현실적인 균형점을 찾는 과정을 더 중요하게 바라본다.

9. 상호 만족을 위한 협상의 기술

이 챕터에서는 실제로 어떻게 서로 만족할 수 있는 협상을 만들어가는지 설명한다.

특히 책 초반에 예수와 소크라테스를 “윤리적인 윈윈 협상가”로 설명한 부분이 인상적이었다. 두 사람 모두 상대를 강압적으로 이기려 하기보다, 질문과 대화를 통해 사람들의 사고방식 자체를 변화시키려 했기 때문이다.

나는 유혹이나 사기 게임에 대해 말하는 것이 아니다. 협력적인 셥셩에서는 음해, 위협, 수작을 부리기 위한 유려한 말솜씨, 조작, 허튼소리, 수완이나 흥정이 필요없다.
반대로 지속적인 관계를 만들고 유지하는 방향으로 전략을 수립하기 제안한다. 신뢰하는 당사자들은 동증하며 상호 간에 이익을 취할 수 있는 방향으로 문제를 해결하기 위해 에너지를 쏟아붓는다. p303
승리란 자신의 신념과 가치에 맞게 당신의 요구를 충족시키는 것을 의미한다. 승리는 상대측이 정말로 원하는 것을 아라내고 그들에게 당신이 원하는 것을 얻을 방법을 보여주는 것을 의미한다. p308

결국 이 챕터를 읽으며 느꼈던 것은, 허브 코헨이 말하는 좋은 협상가는 단순히 말을 잘하거나 상대를 이기는 사람이 아니라는 점이었다. 자신의 기준과 가치관을 유지하면서도, 사람들의 선택과 생각을 긍정적인 방향으로 움직일 수 있는 사람이 더 이상적인 협상가에 가까워 보였다.

ㅁ 어디서나, 누구와도 협상하기

허브 코헨은 마지막 파트에서 협상을 단순한 이론이 아니라, 현실 속 인간관계와 실제 상황에서 어떻게 적용해야 하는지 설명한다.
특히 이 챕터에서는 협상이 결국 사람 사이에서 이루어지는 일이라는 점을 반복해서 강조한다.

10. 비대면 전화 협상에서 합의 각서는 필수
허브 코헨은 전화 협상이나 비대면 협상에서는 특히 기록과 문서가 중요하다고 설명한다.
대면 상황에서는 표정과 분위기, 관계를 통해 어느 정도 의도가 전달되지만, 전화나 문서 중심 협상에서는 작은 표현 차이도 오해로 이어질 수 있기 때문이다.
그래서 그는 협상이 끝난 뒤 반드시 합의 내용을 정리하고 확인하는 과정을 중요하게 본다.
특히 기억에 의존하지 말고, 서로가 이해한 내용을 문서로 남겨야 이후의 갈등과 책임 문제를 줄일 수 있다고 말한다.

이 부분은 확실히 공감이 되는 부분인데, 나 또한 회의록을 중요시 여기기 때문이다.

간단한 구두 내용이라도 메신저에 짧게 공유하려고 한다.

읽으며 느꼈던 점은, 협상은 단순히 말을 잘하는 기술이 아니라 결국 신뢰와 책임의 문제라는 점이었다.
좋은 협상은 상대를 설득하는 데서 끝나는 것이 아니라, 이후에도 서로 같은 이해를 유지할 수 있도록 구조를 만드는 과정에 가까워 보였다.

11. 결정권자와 협상하라
이 챕터에서 허브 코헨은 매우 현실적인 이야기를 한다.
아무리 좋은 협상을 해도, 실제 결정을 내릴 수 없는 사람과 이야기하고 있다면 결과는 바뀌지 않을 수 있다는 점이다.

당연한 부분이다.

실무자와 긴 시간 대화를 나누더라도, 결국 최종 승인권자가 따로 있다면 협상 내용이 뒤집히거나 처음부터 다시 시작되는 경우가 많다. 그래서 작가는 협상 초반부터 “누가 실제 결정권자인가”를 파악하는 것을 매우 중요하게 설명한다.

이 부분을 읽으며 협상은 단순히 논리의 문제가 아니라 구조의 문제라는 생각이 들었다.
무엇을 말할 것인가도 중요하지만, 누구와 이야기하고 있는가 역시 협상의 중요한 변수였다.

12. 사람 대 사람으로 협상하라
허브 코헨이 마지막까지 강조하는 것은 결국 협상은 사람과 사람 사이의 관계라는 점이었다.

회사, 조직, 계약이라는 형식을 이야기하고 있지만, 실제로는 결국 감정을 가진 사람들이 선택하고 판단한다. 그래서 그는 지나치게 형식적이거나 딱딱한 태도보다, 인간적으로 관계를 만들고 상대를 이해하려는 태도를 더 중요하게 바라본다.

특히 인상적이었던 부분은, 사람들은 논리만으로 움직이지 않는다는 점이었다.

협상의 터닝 포인트(p375)
1. 경찰관의 고나심을 교통 위반 딱지에서 다른 곳으로 돌린다.
2. 경찰관이 당신을 개인적인 대상으로 인식하게 한다.
3. 경찰관이 교통 위반 딱지에 볼펜을 갖다 대는 것을 막거나 적어도 지연시킨다.

존중받고 있다고 느끼는가, 자신의 입장이 이해받고 있다고 느끼는가 같은 감정적인 요소들도 협상 결과에 큰 영향을 미친다.

결국 허브 코헨이 말하는 좋은 협상가는 단순히 말을 잘하거나 상대를 압박하는 사람이 아니었다. 상대를 하나의 인간으로 이해하고, 서로의 관계 속에서 현실적인 합의점을 만들어갈 수 있는 사람이 더 좋은 협상가에 가까워 보였다.

ㅁ 마무리

『협상의 기술』은 단순히 협상 기술을 설명하는 책이 아니었다.

사실 이 책을 읽으며 힘들었던 점은, 허브 코헨이 정답을 직접 설명하기보다 사례를 통해 그 의도 스스로 깨닫게 만든다는 점이었다. 그래서 이 책은 읽는 과정에서 중심 과제를 놓치게 되는 경향이 있었다. 작가의 핵심 의도를 먼저 파악하는게 중요하였다.

처음에는 말 잘하는 방법이나 설득 기술에 대한 이야기라고 생각했지만, 읽을수록 인간의 심리와 관계, 그리고 사람들이 어떻게 선택하고 움직이는지를 관찰하는 책에 더 가까웠다. 다시 말하지만, 중간 결론이 없어 ??만 남았지만 말이다.

특히 허브 코헨은 협상을 단순한 승패의 문제로 바라보지 않았다. 현실적으로는 힘, 시간, 정보 같은 요소들이 매우 중요하게 작동하지만, 궁극적으로는 상대를 무너뜨리는 것이 아니라 서로가 원하는 방향을 조율하며 함께 살아가는 과정으로 협상을 바라보고 있었다.

물론 책 속 일부 사례들은 지금 기준에서 다소 공격적이거나 불편하게 느껴지기도 했다. 하지만 그런 부분들조차 현실 사회가 실제로 어떻게 움직이는지를 보여주기 위한 관찰의 과정이라고 생각하니, 단순히 기술을 배우는 느낌보다는 세상을 바라보는 새로운 관점을 배우는 경험에 가까웠다.

결국 내가 이해한 허브 코헨의 핵심 메시지는 단순히 “잘 협상하는 법”이 아니었다. 사람과 상황을 더 넓게 이해하고, 자신의 기준을 유지하면서도 서로가 함께 살아갈 수 있는 방향을 찾는 것. 그것이 그가 말하는 궁극적인 윈윈 협상가의 모습에 더 가까워 보였다.

[AI] GPU vs PIM vs NPU - 내 시스템의 병목은 연산인가, 메모리인가

기록하는 백엔드개발자 — Sat, 2 May 2026 07:10:11 +0900

TL;DR

GPU와 PIM은 같은 축의 다음 세대가 아니라, 서로 다른 병목을 푸는 도구다.

GPU는 FLOPS를 늘리고, PIM은 Byte 이동을 줄인다 — 경쟁재가 아니라 조합재.

ㅁ 들어가며

[AI] 인공지능에 대한 이해(2017에 정리한 리포트)에서 PIM을 언급하고,

[AI] PIM(Processing In Memory)란?에서 PIM을 단독으로 정리한 적이 있다.

이번에는 GPU·NPU와 함께 놓고 '병목 위치' 관점에서 다시 본다.

AI 모델에 GPU를 쓰는 이유에 대한 글을 읽다가 자연스럽게 PIM(Processing In Memory)이 떠올랐다.

처음에는 "GPU 다음 세대" 정도로 막연하게 묶어 두고 있었는데,
정리하다 보니 둘은 같은 축이 아니었다.

결론부터 말하면 GPU는 연산을 빠르게 하는 구조, PIM은 데이터 이동을 줄이는 구조다.
같은 문제의 다른 단계를 푸는 도구다. 이 글은 그 차이를 병목 위치 관점에서 정리한다.

ㅁ 연산이 아니라 데이터 이동이 비싸졌다

GPU의 강점은 분명하다.

대규모 병렬 행렬·벡터 연산. 딥러닝의 핵심 연산 — 행렬 곱, 벡터 누적 은 GPU의 SIMT 구조와 정확히 맞아떨어진다.

문제는 모델이 커지면서 병목 위치가 이동했다는 점이다. 파라미터, activation, batch가 늘어나면 다음 증상이 나타난다.

메모리 대역폭이 먼저 포화된다
GPU 코어는 대기 상태인데 데이터가 도착하지 않는다
전력의 상당 부분이 "연산"이 아니라 "이동"하는데 쓰인다

연산은 점점 싸지고, 데이터 이동이 비싸지는 방향으로 비용 구조가 뒤집혔다. 이 지점에서 PIM이 등장한다.

ㅁ GPU vs PIM — 두 구조의 핵심 차이

축	GPU	PIM
설계 목표	FLOPS 극대화	Byte 이동 최소화
연산 위치	코어에서 (DRAM에서 로드 후 계산)	메모리 내부 (in-situ)
강점 워크로드	compute-bound (조밀 행렬곱)	memory-bound (attention, embedding lookup)
약점	메모리 대역폭에 종속	일반 연산 유연성이 낮음
비유	빠른 셰프, 식재료는 매번 멀리서 옮겨 옴	식재료 옆에서 바로 손질하는 작은 부엌

표를 한 줄로 압축하면 -

GPU는 "FLOPS를 늘리는 전략",

PIM은 "Byte 이동을 깎는 전략"이다.

둘은 경쟁재가 아니라 다른 층의 병목을 푸는 조합재다.

ㅁ AI 워크로드는 왜 memory-bound 인가

[온디바이스AI] 내 폰으로 나만의 RAG 만들기(온디바이스 RAG 최소 아키텍처)를 진행하면서 흥미로운 차이를 확인했다.

맥미니 M1(8GB)과 갤럭시 S23 Ultra(12GB)에서 동일 모델을 실행했을 때,

일반적으로는 CPU 성능이 더 좋은 맥이 빠를 것으로 예상했지만 실제 응답 속도는 메모리가 더 큰 갤럭시가 더 빨랐다.

이 결과는 연산 성능보다 메모리 접근이 병목이 되는 상황을 잘 보여준다.

모델 추론 과정에서는 단순한 계산보다, 큰 파라미터와 KV 캐시를 반복적으로 읽어오는 비용이 더 크게 작용한다.

이 말을 풀어서 보면, AI 모델은 “계산을 많이 하는 것”보다 “필요한 데이터를 계속 가져오는 것”에 더 많은 시간을 쓴다.

대표적으로 두 가지 작업이 있다.

첫 번째는 Attention이다.
모델이 문장을 이해하거나 다음 단어를 예측할 때, 앞에서 나온 단어들을 다시 참고하는 과정이다.
이때 이전에 계산해 둔 값(KV 캐시)을 계속 읽어와야 하는데, 문장이 길어질수록 이 데이터 양이 빠르게 증가한다.
즉, 계산 자체보다 “과거 정보를 다시 가져오는 비용”이 더 커진다.

두 번째는 Embedding lookup이다.
단어를 숫자로 바꾸는 과정이라고 보면 된다.
모델은 “사전”처럼 아주 큰 테이블(차원)을 가지고 있고, 각 단어마다 대응되는 벡터가 저장되어 있다.
특정 단어가 들어오면 이 테이블에서 해당 위치를 찾아 값을 꺼내는데, 문제는 이 접근이 랜덤하게 일어난다는 점이다.
그래서 CPU나 GPU의 캐시가 잘 활용되지 않고, 결국 메모리에서 직접 데이터를 가져오는 비용이 커진다.

결국 두 경우 모두 공통점은 하나다.
계산이 복잡해서 느린 것이 아니라, 필요한 데이터를 계속 불러오느라 시간이 걸린다는 점이다.

그래서 AI 워크로드는 “compute-bound”가 아니라 “memory-bound”라고 말한다.

ㅁ 온디바이스/엣지에서 더 명확해진다

모바일과 엣지로 가면 제약이 세 가지로 좁혀진다.

전력, 메모리 대역폭, 발열.

데이터 센터에서는 보조적이던 제약이 여기서는 1차 제약으로 올라온다.

다음 다이어그램은 방향성을 보여 주는 도식이다.

PIM은 아직 데이터센터·온디바이스 모두에서 초기 단계이며, 표준화된 프로그래밍 모델은 자리잡는 중이다.

  워크로드 진화               하드웨어 진화
───────────────       ──────────────────────
순차 알고리즘       ──→         CPU
대규모 병렬 학습     ──→         GPU
거대 모델 추론      ──→          ?    ← bandwidth wall
온디바이스 추론     ──→     NPU + PIM (memory-centric)

NPU는 연산 패턴을 좁혀 와트당 효율을 끌어올리는 쪽이고,

PIM은 이동 비용 자체를 깎는 쪽이다.

둘은 서로를 대체하지 않는다.

같은 디바이스 안에서도 어떤 연산은 NPU로,
어떤 접근은 메모리 근처에서 처리하는 식으로 역할이 갈린다.

여기서 자연스럽게 따라오는 질문이 있다

— GPU는 언제 안 쓰는가?

데이터 이동 전력이 워크로드 본체 전력을 넘기 시작할 때,

그리고 모델이 한 번에 계산하는 방식이 아니라,

단어를 하나씩 생성(decode)하면서 이전에 저장해 둔 값을 계속 꺼내 쓰고(lookup), 그 과정이 반복되는 형태일 때다.

데이터 센터의 학습은 여전히 GPU의 무대지만, 엣지의 추론은 그렇지 않다.

ㅁ 마무리 — 내 시스템의 병목은 연산인가, 메모리인가

GPU와 PIM은 경쟁 관계가 아니다. 같은 문제의 다른 층을 푸는 도구다.

선택의 기준은 "더 좋은 칩"이 아니라 "내 워크로드의 병목이 어디인가"다.

ㅁ 함께 보면 좋은 사이트

ㅇ llm-study-web : LLM 시스템의 전체 흐름을 개념학습, 시스템 맵, 인터랙티브 실험으로 배우는 교육 플랫폼

ㅇ peterica-website: 기록하는 백엔드개발자 피터 포트폴리오 웹사이트

ㅇ

[독후감] 죽을 때 후회하는 스물다섯 가지

기록하는 백엔드개발자 — Sat, 2 May 2026 01:00:39 +0900

https://www.yes24.com/product/goods/124988906

ㅁ 들어가며

나는 중학교 시절에 죽음에 대한 깊은 고민에 빠진 적이 있다. 이 물음에서 나는 인생의 중요한 선택인 수도자의 길을 선택하게 되었다.

죽음은 끝이 아니라 과정일 뿐이며, 살아있는 동안 어떻게 살아가느냐가 행복의 중요한 덕목이라고 생각했다.

이 책을 읽으며 느낀 것은, 이 책이 죽음 자체를 이야기하는 것이 아니라 결국 "어떻게 살아야 하는가"를 이야기하고 있다는 점이었다.

특히 이 책은 성공하는 법이나 행복해지는 방법을 설명하지 않는다. 대신 삶의 마지막 순간을 맞이한 사람들이 실제로 어떤 후회를 남겼는지를 보여준다.

나는 책을 읽을 때 단순히 내용을 따라가기보다 작가가 왜 이런 이야기를 하는지, 어떤 관점으로 세상을 바라보는지를 이해하려고 노력한다.

ㅁ 작가에 대한 이해

오츠 슈이치는 일본의 종양 전문의로, 오랜 시간 말기 환자들을 진료하며 수많은 사람들의 마지막 순간을 지켜본 의사이다.

그는 환자들이 죽음을 앞두고 남긴 이야기들을 기록하면서 흥미로운 사실을 발견한다.

사람들은 죽음을 앞두고 자신이 이루지 못한 성공이나 더 벌지 못한 돈보다, 삶 속에서 놓쳐버린 관계와 선택들에 대해 더 많이 후회한다는 점이었다.

그래서 이 책은 죽음 자체를 설명하는 철학서라기보다, 삶을 다시 한번 돌아보게 만든다.

나와 같은 생각으로 작가도 사람들에게 죽음이 끝이 아니기 때문에 죽음을 두려워하라고 말하지 않는다.

오히려 죽음 앞에서 반복적으로 나타나는 후회를 통해, 지금 무엇을 중요하게 생각하며 살아야 하는지를 질문한다.

"어느 순간 나는 많은 사람의 마지막을 지켜보면서 누구나 느끼는 후회, 인생에서 풀지 못한 숙제에 공통분모가 있다는 사실을 깨달았다. 지금부터 그 공통분모를 여러 사람과 나누고자 한다." p13

ㅁ 작가가 발견한 후회의 공통점

책에 등장하는 스물다섯 가지 후회는 나다움, 관계, 현재를 살지 못하는 삶이라는 공통된 주제로 모인다.

첫 번째는 자신답게 살지 못한 삶이다.

남의 기대에 맞추어 살거나, 실패가 두려워 도전하지 못했던 일들이 후회로 남았다. 특히 하고 싶었던 일을 미루다가 결국 시도조차 하지 못한 경우가 많았다.

두 번째는 관계이다.

많은 사람들은 사랑하는 사람에게 더 표현하지 못한 것을 후회했다. 가족과 더 많은 시간을 보내지 못한 것, 고마움을 전하지 못한 것, 화해하지 못한 것이 마지막 순간에 남는다고 한다.

세 번째는 현재를 살지 못한 삶이다.

사람들은 미래를 위해 현재를 희생하며 살아가지만, 정작 마지막 순간에는 그 미래를 충분히 누리지 못한 경우가 많았다.

결국 작가가 이야기하는 후회는 '잘못한 일'에 대한 반성보다 '하지 못한 일'에 대한 안타까움이었다.

ㅁ 내가 인상 깊게 느낀 점

이 책을 읽으며 가장 인상 깊었던 점은, 후회가 특별한 사건에서 생기는 것이 아니라는 점이었다.

실제로 25가지 내용은 대부분의 후회는 아주 평범한 일상 속에서 만들어지고 있었다.

- 가족에게 한 번 더 전화할 수 있었던 순간,

- 고맙다고 말할 수 있었던 순간,

- 도전해볼 수 있었던 순간,

잠시 쉬어갈 수 있었던 순간들을 지나치며 살아간 결과가 마지막에 후회로 남고 있었다.

특히 사람들은 돈을 더 벌지 못한 것보다, 시간을 어떻게 사용했는지에 대해 더 많이 이야기했다.

그 모습을 보며 나 역시 지금 중요하다고 생각하는 일들이 정말 중요한 것인지 다시 생각하게 되었다.

ㅁ 이 책이 내게 던진 질문

이 책은 정답을 알려주지 않는다.

대신 한 가지 질문을 남긴다.

"만약 지금 삶이 끝난다면, 나는 무엇을 가장 후회할 것인가?"

나는 그 질문에 쉽게 답할 수 없었다.

하지만 분명한 것은, 후회 없는 삶이란 미래 어느 날 완성되는 것이 아니라 지금의 선택 속에서 만들어진다는 점이었다.

죽음은 언젠가 찾아오는 특별한 사건이 아니라, 오늘의 삶을 비추어 보는 거울에 가까워 보였다.

사실 나에게 중요한 선택이 필요한 시기이다.

아이들과 가정을 위해 육아휴직을 사용하려는 시기에 지금의 선택이 미래를 위한 더 큰 의미를 만들어 준다고 생각한다.

ㅁ 마무리

『죽을 때 후회하는 스물다섯 가지』는 죽음을 준비하는 책이 아니다.

오히려 삶의 우선순위를 다시 점검하게 만드는 책에 가까웠다.

사람들은 마지막 순간에 더 많은 돈이나 더 높은 지위를 이야기하지 않았다.

대신 사랑, 관계, 용기, 그리고 미루어 두었던 선택들에 대해 이야기했다.

결국 내가 이해한 작가의 핵심 메시지는 단순했다.

후회 없는 죽음을 준비하는 가장 좋은 방법은, 후회 없는 오늘을 살아가는 것이다.

나에겐 가족과 아이들의 관계성을 다시금 생각할 수 있었던 시간이었다.

어디서든 브라우저 VS Code로 마크다운만 떨어뜨리면 LLM 이 개인 위키로 자동 정리 - silva-omnium

기록하는 백엔드개발자 — Tue, 28 Apr 2026 01:42:56 +0900

ㅁ 들어가며

ㅇ 언제 어디서든 브라우저 VS Code로 정보를 입력하면, 모든 것이 쌓이는 개인 지식 숲을 만들었습니다.

노트는 한 번만 작성합니다. 분류·요약·교차참조·인용 부착·모순 표시는 LLM 이 알아서 — 영속 위키에 계속 누적되도록.

ㅁ 문제: 매번 0 부터 발견

LLM 으로 문서를 다루는 가장 흔한 패턴 — PDF 나 노트를 챗 인터페이스에 붙여 넣고 질문, 답을 받고, 닫는다. 다음에 같은 주제가 또 떠오르면 같은 문서를 다시 붙이고, 같은 추론을 다시 하게 시킨다.

같은 자료에 10번 질문하면 LLM 은 그 자료를 10번 처음부터 발견한다. 토큰값과 시간이 든다. 더 큰 문제는 이전에 얻은 통찰이 어디에도 누적되지 않는다는 것이다. 다음에 비슷한 주제를 마주쳐도 처음 만나는 것과 같다.

ㅁ 발상: 한 번만 발견하고 위키에 쌓자

소스를 LLM 에 한 번만 읽게 한다. LLM 은:

그 소스를 영속 위키 페이지로 종합한다
기존 페이지와 연관 있으면 합치거나 모순을 표시한다
모든 사실에 원본을 가리키는 각주를 단다
카테고리·태그·별칭 같은 메타데이터를 채운다

다음에 같은 주제가 또 들어오면 LLM 은 새 raw 만 보면 된다. 위키는 이미 그 주제의 누적 종합이다.

10번째 질문 즈음이면 위키가 이미 답을 갖고 있다.

ㅁ 이름은 왜 silva-omnium 인가?

라틴어로 "사물의 숲". 두 가지 계보를 합쳤다:

Andrej Karpathy 의 LLM Wiki 패턴 — 본인 노트를 LLM 으로 정리해 자기만의 위키를 만드는 디자인 원형.
폴란드-리투아니아 연합의 silva rerum — 17~18세기 가문 대대로 이어 쓴 잡록. 일기·계약서·시·여행기·조리법 다 들어가는 두꺼운 한 권. 후손이 이어 쓰면서 가문의 기억이 책 자체에 누적된다.

여기에 Vannevar Bush 의 Memex (1945) — "기억의 확장 장치" 개념 — 도 함께 둔다. 50년 후 하이퍼링크로 절반 정도 구현된 그 아이디어를, LLM 이 나머지 절반을 채워줄 수 있다고 생각했다.

ㅁ 어떻게 동작하는가?

raw/ ──(watcher / make ingest)──▶ wiki/ ──(make build)──▶ 정적 사이트 + Obsidian 그래프

사람: raw/ 디렉토리에 노트를 떨어뜨린다. 형식 자유. 원본은 절대 수정 안 함 (불변).

LLM (Ollama 또는 Claude): 새 raw 가 생기면 읽고, 위키에 어떻게 통합할지 결정한다 — 새 페이지 만들기 / 기존 페이지에 붙이기 / 모순 표시 — 그리고 frontmatter (title, category, tags, src 인용) 까지 채운다.

위키: 시간에 따라 쌓인다. Astro Starlight 로 빌드하면 검색 가능한 사이트가 되고, 같은 디렉토리를 Obsidian vault 로 열면 그래프 뷰가 된다.

핵심은 raw 와 wiki 의 분리다. raw 는 사용자의 원본 흐름 — Obsidian 클리핑이든, 블로그 즐겨찾기든, 회의록이든. wiki 는 LLM 이 그 흐름을 종합한 영속층. 둘 다 마크다운 파일이라 어떤 도구로도 열 수 있다.

ㅁ 작은 설계 결정들

1. 인용 강제

LLM 이 만든 위키 페이지의 모든 사실은 [^src-2026-04-27-tailscale-funnel] 같은 각주를 달고, 페이지 끝에 정의가 붙는다. prompt 에 hard rule 로 박았다. 안 그러면 LLM 이 자기 사전 지식과 raw 의 사실을 섞어 출력한다 — 위키가 LLM 의 환각을 누적하는 도구가 되어버린다.

2. 모순 callout

raw 의 사실이 기존 위키 페이지와 충돌하면 "병합" 하지 않는다. 기존 페이지에 > [!conflict] ... 형태의 callout 으로 양쪽을 다 적는다. 사용자가 직접 판단할 수 있게 — 어느 쪽이 더 최신인지, 더 신뢰할 출처인지.

3. provider 플러그형

scripts/llm_providers/ 에 ollama, claude (Anthropic SDK), claude-cli (claude -p subprocess) 3개.

같은 인터페이스, 다른 백엔드. ingest 명령 하나로 전환:

make ingest                  # default = claude-cli
make ingest-ollama           # 로컬 Ollama (오프라인)
make ingest-claude           # Anthropic API key

처음엔 ollama qwen2.5:3b 로 시작했는데, 8GB RAM 환경에서 큰 raw 가 timeout 났다.

작은 모델은 instruction following 이 약해 카테고리·슬러그도 흔들렸다.

claude-cli 로 default 를 바꾸니 같은 prompt 인데 분류 정확도가 눈에 띄게 좋아졌다.

토큰 비용은 구독 안에 들어가서 추가 청구 없음.

ㅁ 자체호스팅 (선택)

상시 켜져 있는 머신 (예: Mac mini) 에 띄우면 어디서든 브라우저로 편집·열람·AI 협업이 가능하다. 구성:

code-server (VS Code in browser) — 트리·에디터·미리보기·통합 터미널·claude 명령 사전 설치
Caddy — 정적 위키 서빙 + /edit/* 를 code-server 로 reverse_proxy
Tailscale Funnel — 공개 URL (<host>.<tailnet>.ts.net) 자동 발급. 도메인·포트포워딩 불필요. 무료
fswatch + launchd — raw/ 변경 감지 → make ingest && make build 자동 트리거

호스트는 ollama 만 native, 나머지는 Docker로 구성하였다. 다른 프로젝트와 brew 의존이 섞이지 않도록 말이다.

브라우저로 같은 URL 을 열면 mini 의 code-server 가 그대로 뜬다. AI 호출과 git push 모두 mini 의 네트워크에서 발생한다.

ㅁ 한계 — 솔직하게

며칠 운영하며 드러난 것들:

Watcher race condition — raw 여러 파일이 한 번에 도착하면 (예: git pull) 디바운스가 진행 중인 ingest 를 kill 해
부분 누락 가능. lockfile 또는 더 큰 latency 필요.
Funnel + 단일 비밀번호 — code-server 가 password 만으로 보호. 추측 어려운 24자 비밀번호긴 하지만,
다음 단계로 Caddy basic_auth 추가 또는 Cloudflare Access 전환 후보.
Ollama 11434 외부 노출 — OLLAMA_HOST=0.0.0.0 로 두면 같은 LAN 의 다른 디바이스가 인증 없이 접근 가능.
categories.yaml 일관성 — 작은 모델로 ingest 시 새 카테고리 만들고 yaml 등록 안 함. claude-cli 전환으로 거의 해결됐지만 완벽하진 않음.

이런 결함들도 위키에 페이지로 들어간다 — 자기 자신을 자료 삼아 누적되는 게 silva rerum 의 정신.

ㅁ 코드 + 셋업

GitHub: https://github.com/peterica/silva-omnium

Quick start (1분):

git clone https://github.com/peterica/silva-omnium.git
cd silva-omnium
make setup

mkdir -p raw/2026
echo "# 첫 노트" > raw/2026/test.md

make ingest && make build && make dev
# → http://localhost:4321

자체호스팅까지 셋업하려면 infra/README.md 의 1회 부트스트랩 스크립트 실행.

ㅁ 마무리

기억을 쌓는 도구가 결국 자기 자신을 자료로 쌓는다는 게 흥미롭다. 다음 글에선 ingest 파이프라인의 내부 구조 (provider 추상화, 인용 강제 prompt, frontmatter 스키마) 를 더 자세히 다루겠습니다.

[온디바이스AI] 청크는 쌓는 게 아니라 덜어내는 일 — 약한 청크 25개를 덜어내 MRR이 0.15 올랐다

기록하는 백엔드개발자 — Thu, 23 Apr 2026 23:00:10 +0900

ㅁ TL;DR

약한 청크 = moc/·entities/·concepts/의 "관련 포스트", "주요 태그", 연도 그룹, 순수 링크 목록
본문 없고 키워드만 풍부 → 임베딩 유사도가 가짜로 높게 나온다
해법: 경로·헤딩 한 줄 필터 (새 모델·인덱스·리랭커 0개)
실측 기준:
- 청크 수: 118 → 93 (-25, -21%)
- MRR(Mean Reciprocal Rank): 0.794 → 0.947 (+0.15)
- R@3(Recall@3): 0.933 → 1.000
결론: 모델을 바꾸기 전에 청크를 봐야 한다

ㅁ 왜 이 문제를 발견했나

폰에서 "쿠버네티스에서 graceful shutdown이란?"을 물었다.
top-3에 정답 블로그 183번 글과 함께, MOC 파일의 "관련 포스트" 링크 목록이 두 개 섞여 들어왔다.

그 목록 청크의 본문을 열어봤다.

실제 내용 거의 없음
"kubernetes, graceful shutdown, pod, deployment..." 키워드만 나열

링크 목록이 본문보다 먼저 검색된다는 건 설계 실패에 가깝다.
모델을 바꿀까 생각하다가 멈췄다 — 이건 모델 문제가 아니라 청크 문제였다.

ㅁ 약한 청크의 정체

MOC(Map of Content)·entity·concepts 경로의 파일은 원래 지식의 허브 역할이다.

하지만 그 안의 일부 섹션은 검색 관점에서 본문이라고 부를 수 없다.

"관련 포스트" 링크 목록
"주요 태그" 나열
연도 그룹 헤딩 ("2024년", "2023년 작성 글")
반복되는 테이블

정답 본문은 없고 관련 키워드만 모인 청크라서, 임베딩 벡터가 주변 문서들의 키워드 평균처럼 형성된다.
본문이 없으니 구체성은 없는데, 키워드 밀도가 높아 유사도가 가짜로 높게 나온다.

결과:

사용자 쿼리가 어느 주제든 이 청크들이 top-k에 쉽게 얹힌다
정답 본문이 top-3 밖으로 밀려나는 경우가 생긴다
LLM은 근거로 받은 "키워드 목록"으로 답을 짜야 해서 대답이 빈약해진다

ㅁ 해법은 한 번의 경로·헤딩 필터

chunk.py에 경로+헤딩 매칭 필터 한 규칙을 넣었다.

경로: moc/, entities/, concepts/ 중 하나에 속하면
헤딩 또는 섹션 내용이 "관련 포스트", "주요 태그", 연도 그룹, 순수 링크 목록에 해당하면
청크 생성에서 제외

그 외에는 건드리지 않는다.

모델 그대로
차원 그대로
검색 알고리즘 그대로
인덱스 그대로

배포 구성이나 검색 스택을 바꾸지 않는, 데이터 단계의 단일 개입이다.

ㅁ 실측 — 22 쿼리 평가 하네스

변경 전후를 같은 쿼리 세트로 비교해야 의미가 있다.
한국어 22 쿼리(DevOps·RAG·K8s·모니터링)에 정답 청크를 라벨링해 둔 평가 하네스(server/scripts/embed_eval.py)로 돌렸다.

지표필터 전필터 후변화

청크 수	118	93	-25 (-21%)
MRR	0.794	0.947	+0.153
R@3	0.933	1.000	+0.067

모델·차원·검색 알고리즘은 전혀 건드리지 않은 결과다.
이번 실험에서는 모델을 바꾸지 않고도, 데이터 정리만으로 MRR이 0.153 올랐다.

청크 필터 case 문서

ㅁ 운영 — ETag로 자동 재동기화

필터 규칙이 바뀌면 폰의 로컬 DB도 최신으로 맞춰야 한다.

ETag에 chunker_version을 포함시켜, 필터 규칙이 바뀌면 폰 DB가 자동 재동기화되게 했다.
필터 변경 없는 날은 304 — 전송량 0.

청크 필터는 단순 규칙 + 단순 동기화로 운영 복잡도도 거의 없다.

ㅁ 왜 이 결정이 "최소 구현"에 맞는가

추가 인프라 0 — 새 모델·인덱스·리랭커 없음. 데이터 정리 한 번.
평가 하네스가 증거 — 22 쿼리 전후 비교가 의사결정을 대신한다.
단순한 규칙 — 경로·헤딩 매칭만으로 동작. 새 위키 구조에 이식하기 쉽다.
확장 여지 유지 — 청크가 수만 개가 되면 정답 라벨 쿼리 평가를 다시 돌려 필터를 진화시키면 된다.
"덜"이 정당성 — 최소 구현이 "덜 넣는" 쪽으로 편향되는 근거가 됐다.

ㅁ 내가 바꾼 생각

처음에는 이렇게 접근했다.

문서를 많이 쌓자
임베딩만 좋으면 품질은 따라온다

지금은 이렇게 바뀌었다.

문서는 선별해서 쌓자
품질은 모델보다 데이터가 결정한다

결론:

RAG 품질을 올리는 가장 빠른 길은 모델 교체가 아니라, 잘못 넣은 청크를 덜어내는 것이다.

ㅁ 참고

이 프로젝트 문서

청크 필터 case 문서 — 초기 가정·실험 설계·재검토 트리거
임베딩 벤치마크 case — 모델 선택 근거
최소 구현 가이드 — 8단계 파이프라인
문서 허브 — 독자 유형별 읽기 경로

ㅁ 한 줄 정리

청크는 쌓는 작업이 아니라 덜어내는 작업이다. 잘 섞지 않는 것도 엔지니어링이다.

[AI] RTK — AI 에이전트 터미널 출력을 60~90% 압축하는 CLI 프록시

기록하는 백엔드개발자 — Thu, 23 Apr 2026 20:44:55 +0900

ㅁ TL;DR

RTK는 github.com/rtk-ai/rtk 의 실존 OSS다. 아키텍처 개념이 아니라 단일 Rust 바이너리로 배포되는 CLI 프록시.
AI 에이전트(Claude Code, Cursor, Gemini CLI 등)가 실행한 터미널 명령 출력을 가로채, 60~90% 압축한 뒤 LLM에 전달한다.
동작 방식은 shell hook 이 git status 를 rtk git status 로 자동 치환. 에이전트 코드 수정 없이 붙는다.
오버헤드는 <10ms, 공식 지원 서브커맨드 30+ (git, test, jest, vitest, tsc, next, docker, kubectl 등). Apache-2.0 / MIT.

ㅁ 왜 이게 필요한가

AI 코딩 에이전트는 매 작업마다 아래를 실행한다.

npm install
pytest
git status
docker build .

출력은 대부분 진행바, 다운로드 로그, 성공 라인 이다. LLM은 이 노이즈를 전부 context window 에 싣고 추론한다.

결과:

컨텍스트 창이 빠르게 소진된다
토큰 과금이 불필요하게 증가한다
attention 이 노이즈에 분산돼 판단이 무뎌진다

ㅁ RTK 가 실제로 하는 일

공식 문서 기준 12가지 최적화 전략을 사용한다. 핵심만 추리면:

전략	동작
Stats Extraction	git status 의 수십 줄 → 3 modified, 1 added, 1 untracked 한 줄로 요약
Failure Focus	테스트 러너의 통과 로그는 버리고, 실패 블록만 남김
Grouping	TypeScript 에러를 파일별로 묶어 TS2322 (5x) 식으로 집계
Deduplication	동일한 연속 로그는 카운터로 접음
Progress Filtering	ANSI escape, 다운로드 진행바 제거
Three-Tier JSON Parsing	full → partial → passthrough 순서로 JSON 보존
Tree Compression	디렉토리 구조는 20 dir / 10 file 단위로 요약

나머지 5종: NDJSON Streaming, Block-Based State Machine, Language-Aware Code Stripping, JSON Object Extraction, Economic Metrics Tracking.

즉, 단순 텍스트 trim 이 아니라 의미 단위 재구성이다.

ㅁ 설치와 동작 방식

macOS 기준 Homebrew 가 가장 깔끔하다 (공식 formula, Apache-2.0).

# 설치
brew install rtk
# 또는 공식 install.sh (linux/macOS 공용)
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# 버전 확인
rtk --version   # → rtk 0.37.2 (2026-04 기준)

# 수동 호출
rtk git status
rtk ls -la
rtk tree -L 2

여기서 끝이면 에이전트가 매번 rtk 를 prefix 해야 한다.

핵심은 shell auto-rewrite hook 이다.

rtk init -g   # 전역 hook 설치

hook 을 활성화하면, 에이전트가 git status 를 보내도 shell 이 내부적으로 rtk git status 로 치환한다.

에이전트 코드 수정 0줄, 설정 변경 0줄로 적용된다.

지원 확인된 에이전트:

Claude Code, Cursor, GitHub Copilot (VS Code / CLI)
Gemini CLI, Codex, Windsurf, Cline / Roo Code
OpenCode, OpenClaw, Kilo Code, Google Antigravity

ㅁ Before / After 예시

아래는 이 블로그를 쓰는 리포지토리 (peterica-blog) 에서 rtk 0.37.2 로 직접 측정한 결과다.

git status 비교

Before — 원본 git status (705 bytes)

On branch main
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   CLAUDE_CODE_PROJECT_SETUP_PROMPT.md
    new file:   README.md
    new file:   writing/0415/idea.md
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   CLAUDE_CODE_PROJECT_SETUP_PROMPT.md
    ...
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .gitignore
    PRD.md
    ...

After — rtk git status (475 bytes, 44.1% 절감)

* No commits yet on main
+ Staged: 3 files
   CLAUDE_CODE_PROJECT_SETUP_PROMPT.md
   README.md
   writing/0415/idea.md
~ Modified: 3 files
   CLAUDE_CODE_PROJECT_SETUP_PROMPT.md
   ...
? Untracked: 10 files
   .gitignore
   PRD.md
   ...

사라진 것: (use "git rm --cached ..." to unstage) 류의 도움말 라인 전부. 사람에겐 유용하지만 LLM 에겐 노이즈.

rtk find — 99.8% 절감의 정체

원본 find . -type f 는 2,309 라인을 모두 출력한다 (374KB). rtk find 는 이걸 이렇게 바꾼다:

2309F 26D:

./ PRD.md README.md requirements.txt
data/ posts.jsonl posts_wiki.jsonl reclassify_llm.json urls.txt wiki_id_to_stem.json
data/shards/ 0001.jsonl 0001.raw.jsonl 0001.txt 0002.jsonl ... 0014.txt
+2259 more

ext: .md(2203) .jsonl(42) .py(26) .txt(22) .sh(5)

핵심 변환:

전체 카운트 (2309F 26D) 를 맨 위에 배치
디렉토리별로 파일을 한 줄에 묶음
일정 수 이후는 +2259 more 로 생략
맨 아래 확장자별 통계를 집계 — "이 프로젝트는 md 2203 개가 주류" 를 LLM 이 즉시 파악

단순 truncation 이 아니라 "이 디렉토리가 어떤 곳인지"를 압축해서 보여주는 설계다.

ㅁ 왜 Rust 인가

엔지니어링 관점에서 Rust 선택은 합리적이다.

단일 바이너리: 런타임·인터프리터 없음. 어떤 환경에도 copy & run.
stdin/stdout 스트림 처리: 블로킹 없는 파이프 중계.
<10ms 오버헤드: 매 명령마다 프록시를 통과해도 체감되지 않는다.

단, Rust 는 수단이다. Go 나 Zig 로도 동일 요구사항을 만족할 수 있다. 본질은 터미널 출력 스트림을 낮은 오버헤드로 중간 가공하는 파이프 레이어 라는 구조다.

ㅁ 한계와 주의점

RTK 를 무작정 켜기 전에 알아야 할 것.

exit code 는 보존되지만, 일부 CI 파서는 깨질 수 있다. 에이전트 용 프록시지 CI 용이 아니다.
100+ 명령 외는 passthrough 되거나 압축률이 낮다. 지원 목록 확인 필요.
로그 기반 디버깅이 필요한 순간엔 명령 앞의 `rtk` 를 떼고 원본 출력을 그대로 받아야 한다.
shell hook 방식은 사용자의 shell rc 파일을 수정한다. 팀 환경 배포 시 주의.

ㅁ 유사 제품 비교

RTK 만 있는 건 아니다. 같은 문제를 다른 각도로 푸는 도구들이 있다.

도구	위치	특징
RTK	터미널 출력 단	shell hook, Rust 바이너리, 60~90%
Tamp	에이전트 ↔ API 중간	tool result 분류 후 압축, 60~70%
LeanCTX	파일 read 단	intent-aware, 재읽기 캐시 시 99%

RTK 는 쉘 레이어, Tamp 는 API 레이어, LeanCTX 는 파일 read 레이어 로 삽입 지점이 다르다.

조합해서 써도 된다.

ㅁ 마무리

RTK 는 "AI 에이전트용 로그 전처리 프록시"다. 추상 개념이 아니라 실제로 설치·실행 가능한 OSS.
적용 지점은 shell hook, 효과는 60~90% 토큰 절감, 오버헤드는 <10ms.
단순 길이 축소가 아니라 12가지 의미 단위 재구성 전략을 적용한다.
장기적으로는 RAG 전처리, 온디바이스 LLM 입력 최적화에도 같은 구조가 쓰인다.

에이전트가 느리거나 컨텍스트가 빨리 차는 팀이라면, 붙여보고 rtk gain 으로 실측하는 것이 빠르다.

ㅁ 참고

rtk-ai/rtk — https://github.com/rtk-ai/rtk
DeepWiki: Token Optimization Strategies — https://deepwiki.com/rtk-ai/rtk/3.2-token-optimization-strategies
Tamp (비교군) — https://github.com/sliday/tamp

ㅁ 함께 보면 좋은 사이트

ㅇ 모델

ㅇ 도구

Google AI Edge Gallery: https://github.com/google-ai-edge/gallery
minja (llama.cpp 내장 Jinja2): https://github.com/google/minja
LiteRT: https://ai.google.dev/edge/litert
sqlite-vec: https://github.com/asg017/sqlite-vec

ㅇ 더 공부하기 — LLM System Lab

LLM 시스템의 전체 흐름을 개념학습, 시스템 맵, 인터랙티브 실험으로 배우는 교육 플랫폼
RAG Pipeline: https://llm-study-web.vercel.app/topic/rag-pipeline
Embedding: https://llm-study-web.vercel.app/topic/embedding
Production RAG 사례: https://llm-study-web.vercel.app/case-studies/production-rag-system

ㅇ 이전 글

peterica-website: 기록하는 백엔드개발자 피터 포트폴리오 웹사이트
Mac Mini RAG 구축기: https://peterica.tistory.com/1064
sqlite-vec 선택 이유: https://peterica.tistory.com/1065

[온디바이스AI] LiteRT-LM — 온디바이스 LLM을 실제로 “돌리게” 만드는 런타임

기록하는 백엔드개발자 — Thu, 23 Apr 2026 00:00:58 +0900

[AI] Peterica의 AI공부와 비젼 정리

ㅁ 들어가며

ㅇ LiteRT-LM — 온디바이스 LLM을 실제로 “돌리게” 만드는 런타임

ㅁ TL;DR

LiteRT-LM = 온디바이스 LLM 추론 런타임
핵심 차별점: .litertlm (모델 + 토크나이저 + 템플릿 번들)
서버 런타임(vLLM/Ollama)은 모바일에 그대로 못 옮긴다
실제 기준:
- Galaxy S23 Ultra
- Gemma 4 E2B
- 약 40초/응답
- 모델 크기 약 2.4GB
결론: 모델만큼 런타임 선택이 초기에 결정된다

ㅁ 왜 LiteRT-LM까지 오게 됐는가

Gemma 4 E2B를 폰에서 돌리는 데 48시간을 썼다.
시간의 대부분은 모델이 아니라 런타임에서 막혔다.

llama.cpp → Android NDK / NPU 활용 제한
서버 구조(vLLM/Ollama) → 모바일 이식 불가
tokenizer / ABI / 메모리 문제 반복

결국 문제는 하나였다.

“모델이 아니라 실행 계층이 없다.”

ㅁ LiteRT-LM의 핵심 역할 (고유성)

:contentReference[oaicite:0]{index=0}은 단순한 추론 엔진이 아니다.

핵심은 이 포맷이다.

.litertlm

하나의 파일에 포함:

모델 weight
토크나이저
chat template
실행 설정

결과:

별도 tokenizer 배포 불필요
프롬프트 포맷 일관성 유지
모바일 배포 단순화

이게 다른 런타임과의 결정적 차이다.

ㅁ 서버 런타임이 그대로 안 되는 이유

서버 기준 사고:

Docker
GPU
Python runtime

모바일 현실:

arm64 + NDK
제한된 메모리
NPU delegate (Hexagon 등)
앱 내 실행

문제:

cross compile 필요
tokenizer 네이티브 의존성
GPU 대신 NPU 경로 필요

그래서 구조가 바뀐다.

“모델 서버” → “앱 내 추론 시스템”

ㅁ 실제 실행 흐름 (LiteRT-LM 기준)

일반적인 LLM 흐름과 다르게, LiteRT-LM은 이 단계가 핵심이다.

HuggingFace 모델 준비
.litertlm 포맷으로 변환 (핵심 단계)
앱 assets 또는 외부 저장소 배치
LiteRT-LM 런타임 로딩
delegate 선택 (CPU / GPU / NPU)
프롬프트 입력 → 토큰 생성

차이:

tokenizer 별도 로딩 없음
prompt template 내장
디바이스 최적화 포함

ㅁ 실제 측정 기준 (내 환경)

Device: Galaxy S23 Ultra
Model: Gemma 4 E2B
Size: 약 2.4GB
Latency: 약 40초 / 응답
Acceleration: Hexagon NPU

이 수치가 의미하는 건 하나다.

“돌아간다”와 “쓸 수 있다”는 다르다.

ㅁ 내가 바꾼 생각

처음에는 이렇게 접근했다.

어떤 모델이 좋을까

지금은 이렇게 바뀌었다.

어떤 런타임으로 돌릴 수 있을까

결론:

모델을 고르는 문제만큼,
런타임을 고르는 문제도 초기에 결정된다.

ㅁ 참고

LiteRT-LM GitHub
Gemma 4 E2B 실행 케이스 (Galaxy S23)
온디바이스 RAG 전체 구조

ㅁ 한 줄 정리

LiteRT-LM은 “모델을 실행 가능한 형태로 바꾸는 계층”이다.

ㅁ 함께 보면 좋은 사이트

ㅇ llm-study-web : LLM 시스템의 전체 흐름을 개념학습, 시스템 맵, 인터랙티브 실험으로 배우는 교육 플랫폼

ㅇ LiteRT-LM — 온디바이스 LLM을 실제로 “돌리게” 만드는 런타임

피터의 개발이야기

[바이브코딩] 04. AI에게도 SDLC가 필요하다 - ChatGPT, Claude, Codex를 팀처럼 일하게 만든 방법

ㅁ 들어가며

ㅁ 개발팀은 왜 역할을 나눌까?

ㅁ AI도 역할을 나누기 시작했다

ㅁ ContextNote 활용기

ㅁ 처음에는 너무 느렸다

ㅁ 중요한 것은 검증이 아니라 역할이었다

ㅁ 그래서 개발 방식도 바뀌었다

ㅁ AI에게도 SDLC가 필요했다

ㅁ 네트워크 비유로 생각해 보면

ㅁ 핵심 정리

[AWS] LG Uplus의 BSS 현대화를 위한 클라우드 마이그레이션 여정, DevOps 포인트

ㅁ 들어가며

ㅁ BSS(Ucube)는 무엇?

ㅁ 레거시에서 클라우드로 가는 문제점

ㅁ 현대화의 방향

ㅁ 적용 기술

ㅁ 서비스 분리 방식

ㅁ 정합성은 어떻게 해결했나?

ㅁ 데이터 마이그레이션과 검증

ㅁ 클라우드 전략과 마이그레이션

ㅁ 기존 데이터와 신규 데이터를 어떻게 공존시켰나

ㅁ 차세대 이후의 최적화

ㅁ 마지막 메시지

ㅁ 마무리

[독후감] 아주 작은 습관의 힘

ㅁ 작가에 대한 이해

ㅁ 이 책을 읽으며

ㅁ 아주 작은 습관의 힘이란?

ㅁ 책의 핵심내용 정리

Chapter 01. 아주 작은 습관이 만드는 극적인 변화

Chapter 02. 정체성, 사람을 움직이는 가장 큰 비밀

Chapter 03. 무엇이든 쉽게, 재밌게, 단순하게

Chapter 04. 인식해야 변화할 수 있다

Chapter 05. 아주 구체적으로 쪼개고 붙여라

Chapter 06. 환경이 행동을 결정한다

Chapter 07. 나쁜 습관 피하기 기술

Chapter 08. 왜 어떤 습관은 더 하고 싶을까

Chapter 09. 왜 주위 사람에 따라 내 습관이 변할까

Chapter 10. 나쁜 습관도 즐겁게 고칠 수 있을까

Chapter 11. 1만 시간의 법칙은 틀렸다

Chapter 12. 웬만하면 쉽게 갑시다

Chapter 13. 변화를 위한 최소한의 시간

Chapter 14. 그들은 어떻게 나쁜 습관을 버리는가

Chapter 15. 재미와 보상 두 마리 토끼를 잡는 법

Chapter 16. 어떻게 매일 반복할 것인가

Chapter 17. 누군가 당신을 지켜보고 있다

Chapter 18. 습관에도 적성이 있다

Chapter 19. 계속 해내는 힘은 어디서 오는가

Chapter 20. 습관의 반격

ㅁ 좋은 습관을 만드는 4가지 법칙

ㅁ 나쁜 습관을 버리는 4가지 법칙

ㅁ 마무리

[생각] 공정은 법을 적용하는 것이 아니라 공동체를 살리는 것이다 - 아피케이아(Epieikeia)

ㅁ 들어가며

ㅁ 아피케이아(Epieikeia)란 무엇인가

ㅁ 법은 목적이 아니라 수단이다

ㅁ 윤리위원에게 필요한 것은 판단보다 지혜다

ㅁ 공정은 공동체를 회복시키는 힘이다

ㅁ 마무리

[Network] 27. 편지 한 통의 여정을 혼자 설명할 수 있을까?

ㅁ 들어가며

ㅁ 한 통의 편지를 끝까지 따라가기 위한 약속

ㅁ 1단계: Browser는 URL에서 먼저 무엇을 꺼낼까?

ㅁ 2단계: 이름은 어떻게 198.51.100.20이 될까?

ㅁ 3단계: 목적지를 알았으면 어느 문으로 내보낼까?

ㅁ 4단계: Gateway의 IP만 알면 Frame을 보낼 수 있을까?

ㅁ 5단계: Switch는 Server까지의 길을 알고 있을까?

ㅁ 6단계: Router는 봉투를 그대로 다음 우체국에 넘길까?

ㅁ 7단계: 소포가 다음 길보다 크다면 어떻게 될까?

ㅁ 8단계: 사설 주소는 인터넷에서 어떻게 돌아올 주소가 될까?

ㅁ 9단계: Firewall은 주소만 보고 문을 열까?

ㅁ 10단계: TCP는 왜 Data부터 보내지 않을까?

ㅁ 11단계: Handshake 뒤에는 무엇이 신뢰를 만들까?

ㅁ 12단계: TCP 연결이 되면 상대를 믿어도 될까?

ㅁ 13단계: 드디어 HTTP Request가 출발한다

ㅁ 14단계: 응답은 왔던 길을 그대로 되돌아올까?

ㅁ 한눈에 보면 무엇이 바뀌고 무엇이 남을까?

ㅁ 우편 비유를 실제 용어로 되돌려 놓기

ㅁ 2단계: 이름은 어떻게 `198.51.100.20`이 될까?

ㅁ 화면에 `timeout` 하나만 보인다면 어디부터 볼까?

ㅁ `ip link`는 무엇을 묻는가?

ㅁ `ip addr`는 무엇을 확인할까?

ㅁ `ip route get`은 왜 유용할까?

ㅁ `ip neigh`는 어느 단계의 장부일까?

ㅁ `dig`는 무엇을 분리해 줄까?

ㅁ `nc`는 어떤 범위까지 시험할까?

ㅁ `curl`은 어느 계층까지 올라갈까?

ㅁ `openssl s_client`는 무엇을 보여줄까?

ㅁ `any` Interface에서 같은 Packet이 두 번 보일 수 있을까?