---
title: "패킷의 앞은 도착했는데 뒤는 출발하지 못하는 이유"
author: "브레이브브라우저쓰자"
published_at: "2026-10-28T08:11:01.979Z"
updated_at: "2026-10-06T02:56:39.370Z"
tags: ["wormhole routing"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%ED%8C%A8%ED%82%B7%EC%9D%98-%EC%95%9E%EC%9D%80-%EB%8F%84%EC%B0%A9%ED%96%88%EB%8A%94%EB%8D%B0-%EB%92%A4%EB%8A%94-%EC%B6%9C%EB%B0%9C%ED%95%98%EC%A7%80-%EB%AA%BB%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0"
ai_assisted: true
---

# 패킷의 앞은 도착했는데 뒤는 출발하지 못하는 이유

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%ED%8C%A8%ED%82%B7%EC%9D%98-%EC%95%9E%EC%9D%80-%EB%8F%84%EC%B0%A9%ED%96%88%EB%8A%94%EB%8D%B0-%EB%92%A4%EB%8A%94-%EC%B6%9C%EB%B0%9C%ED%95%98%EC%A7%80-%EB%AA%BB%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0)

패킷의 앞부분이 목적지에 도착했는데 뒷부분은 아직 출발하지 못했다. 칩 내부 네트워크에서는 충분히 가능한 장면이다. wormhole routing은 라우터마다 패킷 전체를 저장하지 않고 작은 전송 단위들을 이어 보내기 때문이다. 이 방법이 지연과 버퍼를 줄이는 이유를 이해하려면, 앞부분이 빨리 가는 모습과 막혔을 때 남는 자원을 함께 봐야 한다.

## 패킷 전체를 기다리지 않고 길을 연다

패킷을 흐름 제어의 단위인 flit으로 나누자. 첫 flit인 head는 목적지와 경로 결정에 필요한 정보를 담는다. 이어지는 body flit들은 같은 패킷에 배정된 경로 상태를 따라가고, 마지막 tail은 그 패킷의 끝을 알린다. 하나의 flit이 물리 링크에서 여러 번에 걸쳐 전송되는 설계도 있으므로 flit 수와 실제 전송 횟수는 구별한다.

wormhole routing에서는 head가 다음 라우터의 자원을 얻으면 패킷 전체의 도착을 기다리지 않고 앞으로 보낸다. 중간 라우터에 몇 flit만 저장할 공간이 있어도 긴 패킷을 통과시킬 수 있다. Dally의 원문은 이러한 진행 방식과 자원이 없을 때 제자리에서 막히는 동작을 설명한다. [원문 PDF 4쪽, II-D절](https://groups.csail.mit.edu/cag/PSRG/papers/dally-ieee92.pdf)

여기서 ‘경로를 잡는다’는 말은 모든 전선의 대역폭을 패킷이 독점한다는 뜻으로 읽지 않는다. 여러 논리 대기열을 사용하는 라우터는 같은 물리 링크에서 다른 패킷의 flit도 중재할 수 있다. 어떤 버퍼와 패킷 상태가 유지되는지, 전송 기회는 어떻게 배정되는지가 실제 자원 계약이다.

## 세 링크를 통과하는 여섯 flit

자체 예제로 R0→R1→R2→R3의 세 링크를 정하자. 패킷은 H, B1, B2, B3, B4, T의 여섯 flit이다. 각 링크는 한 cycle에 한 flit을 보내고, 전송한 flit은 다음 cycle부터 다음 홉으로 갈 수 있다. 경로 계산과 중재에 추가 지연이 없고 수신기는 계속 받아 준다고 가정한다.

cycle 0에 H가 R0에서 R1로 이동한다. cycle 1에는 H가 R2로, B1이 R1로 간다. cycle 2에는 H가 R3에 도착한다. 이때 T는 아직 R0에 있다. 이후 각 링크가 매 cycle 한 flit씩 전달하면 T는 cycle 7에 도착한다. cycle 0부터 세면 총 8cycle이며, 이 단순 모델의 완료 시간은 `flit 수+홉 수−1`이다.

반대로 각 라우터가 여섯 flit을 전부 받은 후에만 다음 링크로 보내는 모델에서는 첫 링크가 cycle 0–5, 두 번째가 6–11, 세 번째가 12–17에 전송한다. 완료까지 18cycle이다. 이는 두 방식의 실제 제품 성능을 측정한 결과가 아니라, 전체 패킷을 기다리는 장벽이 만드는 차이를 분리한 계산이다.

실제 라우터에서는 경로 결정, 버퍼 읽기, 중재, 전선 지연이 들어간다. 무부하 head 지연과 패킷의 직렬화 시간을 분리해 더해야 하며, 단순한 8이라는 숫자를 모든 구현에 적용할 수는 없다.

## 앞이 막히면 뒤에서도 공간이 사라진다

같은 예에서 R1과 R2의 버퍼를 각각 두 flit으로 제한하자. R3는 cycle 3–5에만 수신을 거절한다. 이번 모델은 cycle 시작의 빈 공간으로 전송을 결정하며, 같은 cycle에 비워지는 슬롯을 미리 사용하지 않는다. 가능한 다른 구현보다 보수적인 규칙이다.

H는 이미 cycle 2에 목적지에 도착했다. cycle 3에는 R2에 B1과 B2가 쌓인다. cycle 4에는 R2가 가득 차서 R1의 B3가 전진하지 못하고, R1에는 B3와 B4가 남는다. cycle 5에는 두 중간 버퍼가 모두 가득 차므로 R0의 T도 출발할 수 없다. 목적지에서 앞부분을 받았다는 사실만으로 패킷의 뒤쪽이 계속 흐르지는 않는다.

R3가 cycle 6에 다시 받으면 R2가 먼저 비워진다. 보수적인 슬롯 규칙 때문에 R1의 전송은 cycle 7에 재개되고, T는 cycle 8에 R1로 출발하여 cycle 10에 R3에 도착한다. 목적지의 세 cycle 정지가 전체 완료 시간을 8에서 11cycle로 늘린다. 버퍼가 차는 동안에는 일부 flit이 움직이므로 모든 라우터가 즉시 동시에 정지한다고 해석하지 않는다.

## 작은 버퍼가 충분하다는 말의 범위

패킷 전체를 담지 않아도 된다는 장점은 패킷이 여러 라우터에 걸쳐 남을 수 있다는 성질과 맞물린다. 막힌 패킷이 유지하는 대기열과 경로 상태 때문에 다른 패킷도 기다릴 수 있다. tail을 보냈을 때 전송 측의 상태를 풀지, tail의 수신 확인까지 기다릴지도 구현에 따라 다르다. BookSim은 이 재할당 조건을 별도 옵션으로 둔다. [공식 설명의 Flow control](https://github.com/booksim/booksim2/blob/master/doc/manual.tex)

따라서 wormhole routing의 이점을 판단할 때는 패킷 길이보다 작은 버퍼만 보고 끝내지 않는다. 무부하에서는 head가 기다리는 장벽을 줄이고, 부하가 생기면 어떤 패킷이 어느 자원을 붙잡는지 추적한다. head의 빠른 도착과 tail의 완료를 구별하면, 적은 저장 공간으로 긴 데이터를 보내는 이 방식의 장점과 지연이 번지는 이유가 함께 보인다.