네트워크란 무엇인가

개발을 시작하면 API를 호출하고, 서버에 배포하고, 브라우저에서 결과를 확인합니다.

그런데 이 모든 과정의 뒤편에는 네트워크라는 보이지 않는 인프라가 동작하고 있습니다.

네트워크를 모르고 개발하는 것은, 도로 체계를 모르고 물류 사업을 운영하는 것과 비슷합니다.

보통 때는 괜찮지만 문제가 생기면 어디서부터 추적해야 할지조차 감이 잡히지 않습니다.

이 절에서는 네트워크가 정확히 무엇인지, 어떤 구성 요소로 이루어져 있는지, 그리고 왜 개발자도 반드시 이 개념을 이해해야 하는지를 살펴봅니다.

네트워크의 정의와 목적

네트워크(Network)란 둘 이상의 장치가 데이터를 주고받기 위해 연결된 시스템을 말합니다.

여기서 말하는 장치란 컴퓨터, 서버, 스마트폰, IoT 기기 등 통신이 가능한 모든 것을 포함합니다.

네트워크가 존재하는 이유는 단순합니다.

혼자서는 할 수 없는 일을 연결을 통해 가능하게 만드는 것입니다.

구체적으로 세 가지 핵심 목적이 있습니다.

• 자원 공유: 프린터, 파일 서버, 데이터베이스 등을 여러 사용자가 함께 사용합니다. 모든 사람이 각자의 프린터를 가질 필요가 없어지는 셈입니다.

• 통신: 이메일, 메신저, 영상 통화 등 사람과 사람 사이의 소통을 가능하게 합니다. 지구 반대편에 있는 동료와 실시간으로 협업할 수 있는 것도 네트워크 덕분입니다.

• 분산 처리: 하나의 작업을 여러 컴퓨터에 나누어 처리합니다. 빅데이터 분석, 머신러닝 학습처럼 하나의 컴퓨터로는 감당이 어려운 작업을 가능하게 만듭니다.

네트워크가 없었다면 모든 데이터는 USB 같은 물리적 매체로만 이동할 수 있었을 것입니다.

지금처럼 실시간 스트리밍, 클라우드 컴퓨팅, 글로벌 서비스가 가능한 이유는 전적으로 네트워크 기술 덕분입니다.

노드와 링크

네트워크를 구성하는 가장 기본적인 요소는 노드(Node)와 링크(Link)입니다.

마치 지도 위의 도시와 도로처럼, 이 두 가지만으로도 네트워크의 구조를 설명할 수 있습니다.

노드는 네트워크에 연결된 장치를 의미합니다.

여러분의 랩톱, 회사의 서버, 중간에서 데이터를 전달하는 라우터와 스위치 — 이 모든 것이 노드입니다.

링크는 노드와 노드를 연결하는 통신 경로입니다.

이더넷 케이블이나 광섬유 같은 유선 매체가 될 수도 있고, Wi-Fi나 블루투스처럼 눈에 보이지 않는 무선 전파가 될 수도 있습니다.

모든 네트워크는 결국 이 노드와 링크의 조합으로 이루어집니다.

인터넷이라는 거대한 시스템도 수억 개의 노드와 링크가 그물처럼 얽혀 있는 것뿐입니다.

네트워크 장비의 종류

각 노드는 역할에 따라 이름이 다릅니다.

허브는 현재 거의 사용되지 않습니다.

허브는 공유 매체의 충돌과 다른 포트로의 신호 노출 문제가 있어, 현대 Ethernet LAN에서는 보통 스위치를 사용합니다.

LAN, WAN, MAN 분류

네트워크는 커버하는 물리적 범위에 따라 분류합니다.

LAN(Local Area Network)은 건물 하나나 사무실 내부처럼 좁은 범위를 다루는 네트워크입니다.

회사의 사내망이나 가정에서 공유기에 연결된 기기들이 바로 LAN을 구성합니다.

물리적 거리가 짧기 때문에 관리 범위가 작고, 유선 LAN 기준으로는 1Gbps 이상 속도도 흔합니다.

MAN(Metropolitan Area Network)은 도시 규모의 네트워크입니다.

여러 LAN을 묶어 같은 도시 안에서 통신할 수 있게 합니다.

대학의 여러 캠퍼스를 연결하거나, 도시의 공공 Wi-Fi 네트워크가 MAN에 해당합니다.

WAN(Wide Area Network)은 국가나 대륙 단위의 광범위한 네트워크입니다.

인터넷이 가장 대표적인 WAN이죠.

ISP가 제공하는 회선을 통해 전 세계의 LAN을 연결합니다.

• PAN: 개인 주변의 저전력·근거리 연결. 예: 블루투스 이어폰.
• LAN: 집·사무실처럼 관리 범위가 비교적 작은 연결. 예: 가정·사무실 네트워크.
• MAN: 도시·캠퍼스의 여러 LAN을 연결하는 네트워크.
• WAN: 국가·대륙 범위에서 사업자·백본망을 거치는 연결. 예: 인터넷.

아래 함수의 거리 임계값은 분류 연습을 위한 임의 기준이며 표준상의 경계가 아닙니다.

def classify_network(distance_km):
    """거리 기반 네트워크 분류"""
    if distance_km < 0.01:
        return "PAN (Personal Area Network)"
    elif distance_km < 1:
        return "LAN (Local Area Network)"
    elif distance_km < 50:
        return "MAN (Metropolitan Area Network)"
    else:
        return "WAN (Wide Area Network)"

cases = [0.005, 0.1, 30, 5000]
for d in cases:
    print(f"{d}km → {classify_network(d)}")

네트워크 토폴로지

토폴로지(Topology)는 노드와 링크가 물리적·논리적으로 어떤 형태로 연결되어 있는지를 뜻합니다.

• 버스: 구축 비용이 낮지만 공유 케이블 장애가 전체에 영향을 줄 수 있습니다. 과거 Ethernet에서 사용했습니다.
• 스타: 중앙 장비를 통한 관리와 링크 장애 격리가 쉽지만, 중앙 장비 고장이 연결된 장치들에 영향을 줍니다. 현대 LAN에서 흔합니다.
• 링: 닫힌 고리로 연결합니다. 토큰 링의 충돌 회피는 토큰 접근 제어의 성질이며 링 모양 자체의 보장은 아닙니다. 단일 링의 링크 단절은 전체 통신에 영향을 줄 수 있습니다.
• 메시: 대체 경로를 둘 수 있지만 링크·운영 비용이 증가합니다. 인터넷 백본과 데이터센터에서 활용합니다.
• 트리: 계층적 확장이 쉽지만 상위 노드·링크 장애가 하위 연결에 영향을 줍니다. 기업 네트워크에서 활용합니다.

현재 대부분의 LAN은 스타 토폴로지를 사용합니다.

중앙 스위치에 모든 장비가 연결되어 관리가 편하고, 한 케이블이 끊어져도 다른 장비에 영향이 없습니다.

인터넷 백본에는 메시 형태의 연결이 많습니다. 장애 때 우회하려면 사용 가능한 대체 경로가 존재하고 라우팅이 그 경로로 수렴해야 합니다.

클라이언트-서버 모델 vs P2P 모델

네트워크에 연결된 장치들이 데이터를 주고받는 방식, 즉 통신 구조는 크게 두 가지 모델로 나뉩니다.

클라이언트-서버 모델(Client-Server Model)에서는 역할이 명확하게 나뉩니다.

서비스를 제공하는 쪽이 서버이고, 서비스를 요청하는 쪽이 클라이언트입니다.

웹 브라우저가 웹 서버에 페이지를 요청하는 것이 가장 전형적인 예입니다.

서버 쪽에 관리·보안 정책을 모으기 쉽습니다. 여기서 서버는 역할을 뜻하며 여러 물리 장비로 복제·분산할 수 있습니다. 단일 서버에만 의존하면 그 장애가 서비스 중단으로 이어질 수 있습니다.

P2P 모델(Peer-to-Peer)에서는 참여자가 자원을 요청하면서 자신이 가진 자원을 다른 참여자에게 제공할 수 있습니다.

토렌트(BitTorrent)가 대표적입니다.

파일을 다운로드하면서 동시에 다른 사용자에게 업로드합니다.

블록체인도 P2P 모델의 변형입니다.

• 관리: 클라이언트-서버는 서비스 제공자에 정책을 모으기 쉽고, P2P는 참여자 사이에 책임이 분산됩니다.
• 확장: 클라이언트-서버는 서버 증설·분산이 필요합니다. P2P는 참여자가 자원을 더할 수 있지만 업로드 용량·복제 상태·참여자 이탈에 따라 효과가 달라집니다.
• 장애: 단일 서버 의존은 중단 위험이 있습니다. P2P의 내결함성도 필요한 자원의 복제와 연결 상태에 달려 있습니다.
• 보안: 중앙 통제는 정책 적용이 쉽고, 분산 참여자는 신뢰·접근 통제가 더 복잡할 수 있습니다.
• 예시: 클라이언트-서버: 웹·API·DB. P2P 요소: 토렌트·블록체인·WebRTC.

실무에서는 대부분 클라이언트-서버 모델을 기반으로 시스템을 설계합니다.

하지만 WebRTC를 이용한 실시간 화상 통화나, 분산 시스템의 일부 컴포넌트에서는 P2P적 요소를 채택하기도 합니다.

개발자가 네트워크를 알아야 하는 이유

프레임워크가 다 해주는데 네트워크를 왜 알아야 하나요?라는 질문은 자연스러운 의문입니다.

실제로 대부분의 프레임워크는 네트워크의 복잡성을 매우 잘 숨겨줍니다.

fetch()를 호출하면 응답이 돌아오고, Next.js에서 API 라우트를 만들면 서버가 알아서 동작합니다.

하지만 네트워크 지식이 반드시 필요한 순간은 문제가 발생했을 때 찾아옵니다.

이런 상황에서 네트워크 기초가 없으면 문제의 원인이 어느 계층에 있는지조차 판단할 수 없습니다.

코드를 아무리 뒤져도 답이 나오지 않는 이유는, 문제가 코드 밖 — 네트워크 레벨에 있기 때문입니다.

아래는 해당 도구가 설치된 Linux/macOS 계열 환경의 진단 예시입니다. api.example.com은 예시 주소이며 출력 관측을 제시한 것이 아닙니다. ICMP 응답 실패만으로 TCP 연결 실패를 확정할 수 없고, traceroute의 각 홉 RTT도 그 링크만의 지연은 아닙니다.

# 1. DNS 확인 — 도메인이 IP로 변환되는가?
nslookup api.example.com

# 2. 연결 확인 — 서버까지 도달하는가?
ping -c 4 api.example.com

# 3. 포트 확인 — 서비스가 열려있는가?
nc -zv api.example.com 443

# 4. 경로 확인 — 어디서 느려지는가?
traceroute api.example.com

# 5. HTTP 확인 — 응답이 올바른가?
curl -v https://api.example.com/health

네트워크를 이해하면 이런 문제를 계층별로 분리해서 체계적으로 진단할 수 있게 됩니다.

DNS 문제인가, TCP 연결 문제인가, HTTP 헤더 문제인가?를 구분하는 것만으로도 해결 속도가 근본적으로 달라집니다.

이 교재 전체를 관통하는 목표가 바로 이것입니다.

네트워크 용어를 외우는 것이 아니라, 문제를 계층별로 나눠서 생각하는 능력을 기르는 것입니다.