Network Design Principle

네트워크 통신은 서로 다른 디바이스가 데이터를 주고받는 과정이다. 네트워크 통신이라는 거대하고 복잡한 문제를 한 번에 해결하는 것은 불가능 하다. 거대한 문제를 해결하기 위해서는 여러개의 작은 문제로 분해하여 해결해야 한다.

X -> Z 로 가는 복잡한 통신 과정을 잘 처리하기 위해서 작은 문제로 분해하면 X -> A … -> Z 와 같이 중간 계층이 생긴다. 즉, 큰 문제를 해결하기 위해 작은 문제로 분해하는 과정에서 LAYER 라는 개념이 자연스럽게 등장한다.

소프트웨어 엔지니어링에서 흔히 웹 애플리케이션을 개발하다보면 Layer 가 분리된 여러 Architectures 를 접하게 된다. Layer 를 어떤 기준으로 분리할까? 라는 고민을 자연스럽게 하다보면 각자의 관심사, 책임, 역할등 핵심적인 개념을 간추리게된다. 이 과정을 관심사의 분리(Separation of Concerns)와 ABSTRACTION 라고 한다.

추상화는 복잡성을 해결하는 데 있어 가장 핵심적인 원리이자 본질적인 개념이다.

Hides unnecessary details to Reduce complexity

거대한 문제(통신)를 작은 문제로 나누어 해결:

  • 1단계: "두 컴퓨터를 물리적으로 어떻게 연결할까?" (물리 계층)
  • 2단계: "같은 네트워크 안에서 옆 컴퓨터에게 데이터 조각을 어떻게 정확히 전달할까?" (데이터 링크 계층)
  • 3단계: "전 세계에 흩어진 컴퓨터들 사이에서 목적지까지 가는 최적의 경로를 어떻게 찾을까?" (네트워크 계층)
  • 4단계: "데이터가 순서대로 빠짐없이 도착했는지, 또는 빠르게 보내기만 할지 어떻게 보장할까?" (전송 계층)
  • 5단계: "이 데이터를 어떤 애플리케이션(웹 브라우저, 게임 등)이 사용하게 할까?" (애플리케이션 계층)

캡슐화(encapsulation)는 바로 이 분업을 위한 '업무 지시서'를 추가하는 과정이다.

각 계층의 전문가(프로토콜)는 바로 아래 계층의 전문가에게 일을 넘길 때, 자신이 처리한 내용과 다음 전문가가 처리해야 할 내용을 담은 '메모(헤더)'를 붙여서 넘기는 것과 같다.

  • L4 전문가: "이 데이터는 80번 포트(웹서버)로 가야 해. 순서는 3번이야." 라는 메모(TCP 헤더)를 붙여 L3 전문가에게 넘긴다.
  • L3 전문가: L4 전문가의 메모는 읽지 않는다. 그건 자기 관심사가 아니다. 그는 오직 "최종 목적지 IP 주소는 1.2.3.4야." 라는 메모(IP 헤더)만 새로 붙여서 L2 전문가에게 넘긴다.
  • L2 전문가: L3 전문가의 메모는 보지도 않는다. 그는 "일단 바로 옆에 있는 라우터(MAC 주소 AA:BB:CC)에게 전달해." 라는 메모(이더넷 헤더)만 붙여서 L1 전문가에게 보낸다.

이렇게 각 계층은 자신의 책임과 역할에만 완벽하게 집중한다. 다른 계층이 어떻게 동작하는지 알 필요가 없다. 이것이 바로 '관심사의 분리' 이다.

이러한 계층화 구조는 강력한 '추상화(abstraction)'를 제공한다. 예를 들어 웹 개발자(애플리케이션 계층) HTTP 프로토콜만 알면된다. 자신의 데이터가 Wi-Fi를 타는지, 광케이블을 타는지(L1), 중간에 어떤 라우터를 거치는지(L3) 전혀 신경 쓸 필요가 없다. 그냥 "이 데이터를 보내줘" 라고 요청하면, 하위 계층들이 알아서 목적지까지 전달해 줄 것이라고 믿고 맡기는 것이다.

이는 마치 우리가 자동차를 운전할 때, 엔진의 폭발 행정이나 변속기의 기어 원리를 몰라도 핸들과 페달 조작법만 알면 되는 것과 같다. 엔진과 변속기는 운전자에게 '추상화'되어 있는 것이다.

이러한 관심사 분리와 추상화가 잘되어있으면 유연성과 독립적인 확장이 가능하다.

  • Wi-Fi 기술(L2)이 아무리 발전해도 웹 브라우저(L7) 코드를 수정할 필요가 없다.
  • 새로운 라우팅 알고리즘(L3)이 나와도 카카오톡(L7)은 그대로 쓸 수 있다.

'복잡한 문제를 해결 가능한 작은 단위로 나누고, 각 단위는 자신의 역할에만 집중하며, 정해진 약속(인터페이스)을 통해 서로 통신하게 한다'는 본질을 실무에서도 동일하게 적용할 수 있다. 예를 들어 거대한 서비스를 구축함에 있어서 아키텍처를 구성하는 과정에서 서버를 새로 만들지 말지 등의 결정도 할 수 있다.

The Grand Design: Architecting Digital Highways for Data Packets

우리가 매일 사용하는 인터넷은 눈에 보이지 않는 거대한 도시와 같다. 그리고 이 도시의 도로 위를 쉴 새 없이 달리는 자동차가 바로 데이터 패킷(Data Packet)이다. 패킷 하나하나가 이메일, 동영상, 웹사이트의 조각을 싣고 목적지를 향해 달려간다.

그렇다면, 이 수십억 대의 자동차(패킷)들이 막힘없이, 길을 잃지 않고, 안전하게 목적지까지 도달하게 하는 이 거대한 교통 시스템은 어떤 철학으로 설계되었을까? 이것이 바로 네트워크 아키텍처의 핵심이며, 그 본질은 몇 가지 중요한 원칙으로 요약할 수 있다.

Layering: Separate highways, general roads, and alleys

현실의 도시가 기능에 따라 도로를 구분하듯, 잘 설계된 네트워크는 역할을 계층으로 나눈다. 이를 계층적 네트워크 모델(Hierarchical Network Model)이라고 부른다.

  • 코어 계층 (Core Layer - 대동맥/고속도로): 이 계층의 유일한 목표는 '속도'이다. 도시와 도시를 잇는 대동맥처럼, 어떠한 간섭이나 복잡한 정책 없이 대규모 데이터를 최대한 빠르게 전달하는 역할만 수행한다. 신호등 없는 고속도로를 생각하면 쉽다.
  • 분배 계층 (Distribution Layer - 주요 간선도로): 코어 계층과 아래의 액세스 계층을 연결하는 중간 지점이다. 이곳에서 중요한 '교통정리'가 이루어진다. 어떤 패킷을 어디로 보낼지 경로를 결정(Routing)하고, 보안 정책(ACLs)을 통해 허가되지 않은 차량을 통제하는 검문소 역할도 한다.
  • 액세스 계층 (Access Layer - 집 앞 골목길): 우리 집 컴퓨터, 스마트폰, 프린터 등 실제 장치들이 네트워크에 접속하는 최종 관문이다. 사용자가 네트워크에 들어올 자격이 있는지 인증하고, 골목길의 안전을 관리하는 역할을 담당한다.

이처럼 역할을 명확히 나누면 각 계층은 자신의 임무에만 집중해 효율이 극대화되고, 문제가 생겼을 때 "고속도로 문제"인지 "골목길 문제"인지 쉽게 파악할 수 있다.

Redundancy: Every road has a roundabout

A 도시에서 B 도시로 가는 유일한 다리가 무너진다면 어떻게 될까요? 모든 교통이 마비될 것이다. 이를 '단일 장애점(Single Point of Failure)'이라고 하며, 네트워크 설계에서 가장 피해야 할 대상이다.

이중화(redundancy)는 이 문제를 해결하는 철학이다.

  • 경로 이중화: 중요한 구간에는 항상 두 개 이상의 경로를 만든다. 하나의 회선에 문제가 생기면, 패킷들은 마치 내비게이션이 실시간으로 다른 길을 안내하듯, 즉시 우회로로 경로를 바꿔 목적지까지 도달한다.
  • 장비 이중화: 핵심적인 라우터나 스위치 같은 교통 경찰관을 항상 두 명 이상 배치하는 것과 같다. 한 명이 아프면 즉시 다른 한 명이 임무를 이어받아 교통 흐름이 끊기지 않게 한다.

"모든 것은 언젠가 고장 난다"는 현실을 인정하고, 어떤 상황에서도 길은 열려 있어야 한다는 안정성의 철학이다.

Scalability: Make a New Town Plan in 10 Years

작은 마을일 때는 간단한 도로 시스템으로 충분했지만, 도시가 성장하면서 교통 대란이 일어나는 것을 종종 본다. 네트워크도 마찬가지이다. 사용자가 100명에서 10,000명으로 늘어날 것을 예측하지 않고 설계했다면, 결국 전체 시스템을 재건축해야 하는 비극이 발생한다.

확장성(scalability)은 미래의 성장을 미리 설계에 반영하는 원칙이다.

  • 주소 계획 (IP Addressing): 도시의 주소 체계를 무질서하게 만드는 것이 아니라, '강남구', '서초구'처럼 구역을 나누고 체계적으로 주소를 할당한다. 나중에 새로운 '동'이 생겨도 기존 주소 체계와 충돌 없이 쉽게 편입할 수 있다.
  • 모듈식 설계 (Modular Design): 거대한 하나의 네트워크 덩어리가 아니라, '주거 단지 블록', '산업 단지 블록'처럼 기능별로 독립적인 모듈을 만든다. 새로운 건물이 들어설 때 도시 전체를 뜯어고칠 필요 없이, 새로운 블록을 만들어 기존 도로망에 연결만 하면 되는 것과 같다.

The Anatomy of a Packet

디지털 세계에서는 데이터를 작은 조각(packet)으로 나눠 보낸다. 패킷(packet)은 제어 정보(control information)와 페이로드(payload, user data)로 구성되며 캡슐화된 전달 단위이다. 실제 전송 시에는 [L2 헤더 | L3 헤더 | L4 헤더 | 페이로드 | L2 트레일러]로 연속 배열되어 전선 위를 흐른다. 이 과정을 캡슐화(encapsulation)라 한다.

데이터는 애플리케이션 계층(L7)에서 시작하여 물리 계층(L1)으로 내려가며 각 계층이 필요한 '제어 정보'를 헤더(Header) 형태로 덧붙인다.

데이터
  ↓(L4) TCP/UDP 헤더 추가 → 세그먼트/데이터그램
  ↓(L3) IP 헤더 추가       → IP 패킷
  ↓(L2) Ethernet 헤더/트레일러 → 이더넷 프레임(실전송 단위)
  ↓(PHY) 전기/광 신호로 변환

L2 Header: Ethernet

L2 헤더 (이더넷): 지역 배송원의 운송장:

  • 이 패킷을 '바로 다음' 장비(같은 네트워크 내의 다른 컴퓨터 또는 라우터)로 전달하기 위한 물리 주소(MAC)이다.
  • 로컬 네트워크에서 통신이 안 될 때 가장 먼저 의심해야 할 부분이다. PC가 라우터의 MAC 주소를 모르면(ARP 실패), 패킷은 아예 동네 밖으로 나가지도 못한다. arp -a 명령어로 확인되는 이 테이블이 바로 패킷의 첫 여정을 결정한다.

L3 Header: IP

L3 헤더 (IP): 최종 목적지가 적힌 국제 소포 등기:

  • 전 세계 인터넷망에서 유일하게 식별 가능한 최종 목적지 주소(IP)와 함께, 중간 경로에서 문제가 생겼을 때를 대비한 규칙(TTL, Fragment Offset 등)을 담고 있다.
  • 차량 내 CAN 통신에서 메시지 ID와 같다. 수많은 ECU 중 이 메시지를 수신해야 할 대상을 명확히 지정한다. TTL(Time To Live)은 네트워크 루프에 빠져 패킷이 무한히 떠도는 것을 막는 안전장치로, 이는 차량 네트워크에서 특정 메시지가 네트워크를 마비시키는 'Broadcast Storm'을 방지하는 메커니즘과 철학적으로 동일합니다.

L4 Header: TCP/UDP

L4 헤더 (TCP/UDP): 수신 부서 및 처리 지침서:

  • 최종 컴퓨터(IP 주소)에 도착한 후, 어떤 애플리케이션(Port 번호)에 전달되어야 하는지와 데이터 처리 방식("신뢰성 있게, 순서대로, 확인 응답 필수" - TCP / "빠르게, 일단 보내기만" - UDP)을 명시한다.
  • 포트 80/443은 일반적으로 웹 서비스로 들어오는 정문이다. 방화벽이 이 포트를 막으면, 패킷은 건물 바로 앞에서 문이 잠겨 들어오지 못하는 것과 같다. 특히 TCP Flags(SYN, ACK, FIN)는 애플리케이션의 '대화법' 그 자체이다. 사용자가 접속이 느리다고 불평할 때, 패킷을 분석하여 비정상적인 TCP Retransmission 이나 Zero Window 가 보인다면, 이는 백엔드 서버의 문제가 아니라 네트워크 어딘가에서 패킷이 유실되거나 서버가 부하를 감당하지 못하고 있다는 명백한 증거이다.

Tracing the Packet's Journey

아래 Sequence Diagram 은 유저가 인터넷에 접속하여 www.youtube.com 을 입력하고 특정 동영상을 클릭해서 영상을 보기까지에 일어나는 일련의 과정을 나타낸다.