네트워크란?

노드(Node)와 링크(Link)가 서로 연결되어 데이터를 주고받는 구조이다. 노드는 노트북, 서버, 라우터처럼 데이터를 보내거나 받거나 중계하는 장치이고, 링크는 유선·무선처럼 그 사이를 잇는 통신 경로다. 웹페이지를 열 때도 내 기기와 서버가 한 번에 직접 연결되는 것이 아니라 여러 노드와 링크를 거쳐 요청과 응답을 주고받는다.

flowchart LR
    A[클라이언트] -->|요청| B[공유기]
    B --> C[인터넷의 라우터]
    C --> D[서버]
    D -->|응답| C
    C --> B
    B --> A

이 그림은 경로를 단순화한 것이다. 실제 요청은 DNS 조회, 여러 라우터, 암호화 연결 등을 거칠 수 있다. 중요한 것은 전체 경로 중 한 구간의 병목이나 장애가 사용자가 느끼는 속도에 영향을 준다는 점이다.

처리량과 지연시간

네트워크 속도를 말할 때는 서로 다른 두 질문을 분리해야 한다. 얼마나 많은 데이터를 옮길 수 있는가는 처리량, 응답이 얼마나 늦게 도착하는가는 지연 시간이다. 전송량이 커야 하는 파일 다운로드와 즉각적인 반응이 필요한 화상 회의는 이 둘의 중요도가 다르다. 패킷 손실, 연결의 안정성, 보안도 함께 봐야 한다.

항목	뜻	예
대역폭(bandwidth)	링크가 이론적으로 제공할 수 있는 전송 용량	최대 100 Mbps 링크
처리량(throughput)	실제로 성공적으로 전달한 데이터의 양/시간	측정 시 65 Mbps
지연 시간(latency)	데이터가 목적지에 도달하는 데 걸리는 시간	요청 왕복 40 ms
패킷 손실(packet loss)	전송 중 목적지에 도착하지 못한 패킷의 비율	재전송·끊김의 원인 중 하나

대역폭은 도로의 차선 수, 처리량은 실제로 통과한 차량 수와 비슷하다. 차선이 많아도 차량이 몰리거나 다른 구간이 좁으면 실제 처리량은 낮을 수 있다. 이 비유에서 차량이 목적지에 도착하기까지 걸린 시간은 지연 시간에 해당한다.

처리량(Throughput)

일정 시간 동안 실제로 성공적으로 전달된 데이터 양이다. 단위로는 보통 bps(bits per second)를 쓴다. 링크의 명목 대역폭과 실제 애플리케이션 처리량은 같지 않다. 프로토콜 헤더, 다른 사용자와의 공유, 재전송, 서버의 처리 속도 등이 차이를 만든다.

예를 들어 10 MB 파일은 대략 80 Mb이다. 실제 처리량이 일정하게 10 Mbps라면 데이터 자체를 옮기는 데만 이론상 약 8초가 걸린다. 여기에 연결 설정과 요청·응답 지연, 프로토콜 오버헤드가 더해질 수 있다. 이 계산은 용량을 시간으로 환산한 예이지 실제 다운로드 시간을 보장하지 않는다.

트래픽(traffic)은 네트워크를 흐르는 데이터나 그 양을 가리킨다. 방문자가 많아 트래픽이 늘어도 병목 구간이 그대로라면 처리량은 일정 수준에서 더 늘지 않고 대기 시간이나 손실이 증가할 수 있다.

지연 시간(latency)

데이터가 보내진 뒤 상대에게 도착하기까지 걸리는 시간이다. 웹 개발에서 흔히 보는 RTT(Round-Trip Time)는 요청을 보낸 뒤 응답이 돌아오기까지의 왕복 시간이다. 한 방향 지연과 RTT를 혼동하면 안 된다. 또한 애플리케이션에서 측정한 응답 시간에는 네트워크 지연 외에 서버 처리 시간도 포함된다.

지연 시간은 대략 다음 요소가 합쳐져 만들어진다.

• 전파 지연: 신호가 물리적인 거리를 이동하는 시간
• 전송 지연: 패킷의 비트를 링크에 실어 보내는 시간
• 대기 지연: 라우터나 서버 앞에서 순서를 기다리는 시간
• 처리 지연: 장치가 패킷을 검사하고 다음 경로를 결정하는 시간

flowchart LR
    A[요청 생성] --> B[네트워크 이동]
    B --> C[서버 처리]
    C --> D[응답 이동]
    D --> E[클라이언트가 결과 표시]

예를 들어 작은 JSON 응답을 받는 데 500 ms가 걸렸다면 전송할 바이트 수만 줄여서는 충분하지 않을 수 있다. DNS·연결 설정, 네트워크 RTT, 서버의 데이터베이스 조회, 클라이언트 렌더링 중 어디에 시간이 쓰였는지 나누어 측정해야 한다. 반대로 큰 파일을 전송한다면 처리량이 더 큰 영향을 줄 수 있다.

측정할 때의 순서

1. 무엇을 재는지 정한다. 링크 속도, 파일 전송 처리량, HTTP 응답 시간은 서로 다른 값이다.
2. 같은 조건에서 반복 측정한다. 한 번의 측정에는 일시적인 혼잡이나 캐시 효과가 섞인다.
3. 끝에서 끝까지 확인한다. 클라이언트, 네트워크, 서버 중 어느 구간이 느린지 분리한다.
4. 평균과 느린 경우를 함께 본다. 평균이 빨라도 일부 요청이 오래 걸리면 사용자 경험은 나빠질 수 있다.

결국 좋은 네트워크는 처리량 숫자 하나로 설명되지 않는다. 서비스가 필요한 만큼의 데이터를 안정적으로 옮기면서, 사용자가 기다리는 시간을 허용 범위 안에 두는지 확인해야 한다.