144. 자료 흐름도 (DFD, Data Flow Diagram) - Process, Data Flow, Data Store, Terminator

핵심 인사이트 (3줄 요약)

본질: TFTP(Trivial File Transfer Protocol)는 FTP의 복잡성을 완전히 덜어내고, 연결 수립(Handshake)이 필요 없는 UDP(포트 69) 위에서 가장 단순한 형태(Trivial)로 파일을 읽고 쓰는 데 목적을 둔 초경량 프로토콜이다.

가치: 코드 크기가 극도로 작아 ROM이나 펌웨어에 박아넣기 유리하므로, 하드디스크나 OS가 없는 깡통 컴퓨터(라우터, 스위치, PXE 클라이언트)가 초기 부팅 시 운영체제 이미지를 네트워크로 다운로드할 때 구원자 역할을 한다.

융합: 보안 통제(인증) 기능이 아예 없고 에러 복구 로직이 빈약(Stop-and-Wait)하기 때문에, 인터넷(WAN) 구간이 아닌 안전한 사내 폐쇄망(LAN) 환경의 인프라 프로비저닝이나 펌웨어 자동화 파이프라인에서만 제한적으로 활용된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: TFTP(Trivial File Transfer Protocol)는 FTP(File Transfer Protocol)의 극단적인 경량화 버전이다. 복잡한 TCP 연결 상태 유지와 이중 채널 구조를 버리고 비연결형인 UDP(기본 포트 69) 위에서 구동되며, 인증(ID/PW)과 디렉토리 탐색 기능조차 제거된 순수한 "파일 읽기(RRQ)와 쓰기(WRQ)" 원툴 프로토콜이다.
필요성: 인터넷 초창기부터 깡통 상태의 컴퓨터나 네트워크 장비(라우터, 허브 등)를 켰을 때 OS나 펌웨어를 어디선가 가져와야 했다. 장비 안에는 겨우 수 킬로바이트(KB) 용량의 부트롬(Boot ROM)밖에 없었다. 이 좁은 공간에 복잡한 TCP 스택과 방대한 FTP 클라이언트 소스 코드를 구워 넣는 것은 불가능했다. "그냥 묻지도 따지지도 말고 저기 있는 파일 하나만 가볍게 내려받을 수 있는 가장 작고 무식한 프로토콜"이 인프라 엔지니어들에게 절대적으로 필요했다.
💡 비유: 일반 FTP가 택배 기사가 신분증(ID/PW)을 꼼꼼히 확인하고 인수증에 사인(TCP)을 받은 뒤 무거운 짐을 집 안까지 안전하게 날라주는 우체국 안심 택배라면, TFTP는 드라이브스루 창구에서 이름표 확인도 없이 그냥 종이봉투(UDP)를 던져주고 돈도 안 받고 차를 보내버리는 초간단 패스트푸드 픽업과 같습니다.
등장 배경:
1. 초창기 네트워크 부팅의 난관: 디스크 없는 터미널(Diskless Workstation)이 유행하던 시절, 네트워크 인터페이스 카드(NIC)만으로 서버에서 OS 이미지를 당겨와 부팅하는 PXE(Preboot Execution Environment) 생태계가 싹트기 시작했다.
2. 가벼움의 미학: 1981년 IETF(RFC 783)에서 TCP의 신뢰성과 FTP의 인증을 싹 다 덜어낸 TFTP 표준을 제정했다.
3. 인프라 자동화의 핵심: 라우터나 스위치에 펌웨어를 입히거나 백업 설정을 빼낼 때, 복잡한 인증 절차 없이 명령어 한 줄로 파일을 쏴버리는 용도로 네트워크 장비 벤더(Cisco 등)의 절대적 지지를 받으며 살아남았다.

┌─────────────────────────────────────────────────────────────┐
│          TFTP 통신 흐름도: Stop-and-Wait 메커니즘 (RRQ)         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [Client (깡통 라우터/PC)]                    [TFTP Server (69)] │
│         │                                         │         │
│         │ 1. Read Request (RRQ): "boot.img 줘!"   │         │
│         │────────────────────────────────────────▶│         │
│         │ (인증 절차 아예 없음! 그냥 파일 이름만 던짐)     │         │
│         │                                         │         │
│         │ 2. Data Block 1 (512 Bytes)             │         │
│         │◀────────────────────────────────────────│         │
│         │                                         │         │
│         │ 3. ACK 1 (1번 블록 잘 받았어!)            │         │
│         │────────────────────────────────────────▶│         │
│         │                                         │         │
│         │ 4. Data Block 2 (512 Bytes)             │         │
│         │◀────────────────────────────────────────│         │
│         │                                         │         │
│         │ 5. ACK 2 (2번 블록 잘 받았어!)            │         │
│         │────────────────────────────────────────▶│         │
│         │                 (중략)                    │         │
│         │ 6. Data Block N (500 Bytes) - 마지막 조각!│         │
│         │◀────────────────────────────────────────│         │
│         │                                         │         │
│  🌟 결과: 블록 크기가 512 바이트보다 작게 오면 "파일 끝(EOF)"으로 인식! │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] TFTP는 UDP를 쓴다. UDP는 패킷 유실을 복구해주지 않기 때문에 TFTP가 애플리케이션 레벨에서 가장 멍청하고 원시적인 핑퐁 게임인 Stop-and-Wait (정지 대기) 알고리즘을 사용한다. 서버가 512바이트짜리 데이터 블록(1번)을 던지면, 클라이언트가 "1번 잘 받았어(ACK)"라고 대답할 때까지 서버는 다음 블록(2번)을 절대 던지지 않고 멈춰 서서 기다린다. 만약 중간에 패킷이 유실되어 ACK가 안 오면 타임아웃을 걸고 똑같은 블록을 재전송한다. 512바이트씩 찔끔찔끔 보내고 멈추기를 반복하므로 대용량 전송 시 속도는 매우 처참하지만, 구현해야 할 소스 코드가 불과 수백 줄에 불과할 정도로 극단적으로 가볍다는 것이 최대 무기다. 마지막 블록이 512바이트 미만(예: 500바이트)으로 오면 클라이언트는 아! 이게 파일의 끝이구나! 하고 다운로드를 종료한다.

📢 섹션 요약 비유: TFTP는 물건을 한 번에 다 싣고 오는 게 아니라, 삽으로 모래를 한 삽 퍼서 주고(Data), "받았어?(ACK)" 확인한 뒤에야 다음 삽을 푸는 아주 답답하지만 절대 코드가 꼬일 일 없는 단순 노동과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

TFTP 메시지 포맷 (5가지 Opcode)

TFTP는 복잡한 텍스트 명령어를 쓰지 않고, 2바이트짜리 Opcode(명령 코드)로 자신의 의도를 나타내는 이진(Binary) 프로토콜이다.

Opcode	메시지 타입	설명
1	RRQ (Read Request)	파일 다운로드 요청. `[Opcode: 1][파일명][0][모드(netascii/octet)][0]` 형태
2	WRQ (Write Request)	파일 업로드 요청.
3	DATA	실제 파일 데이터. `[Opcode: 3][블록 번호 2바이트][데이터(최대 512바이트)]`
4	ACK (Acknowledgment)	데이터 수신 확인. `[Opcode: 4][블록 번호 2바이트]`
5	ERROR	에러 발생. 예: "File not found", "Access violation"

통신 포트 변경의 마법 (Ephemeral Port)

TFTP 서버는 기본적으로 UDP 69번 포트를 리스닝(Listening)하며 클라이언트의 RRQ/WRQ 요청을 기다린다. 하지만 실제 파일 전송(DATA와 ACK 교환)은 69번 포트에서 일어나지 않는다.

만약 69번 포트로 수천 대의 장비가 동시에 부팅 이미지를 달라고 몰려들면 하나의 포트로 패킷을 구분하기 어렵다. 따라서 클라이언트가 69번으로 첫 요청을 찌르면, 서버는 즉시 랜덤한 고포트(Ephemeral Port, 임시 포트)를 새로 하나 열어서 그 포트로 첫 번째 DATA 블록을 쏜다. 클라이언트는 이걸 눈치채고 이후부터는 69번이 아닌 그 새로운 임시 포트로 ACK를 쏘며 둘만의 독립적인 파일 전송 세션을 이어간다. 이것이 TFTP가 멀티플렉싱(다중 접속 처리)을 구현하는 가벼운 트릭이다.

📢 섹션 요약 비유: 은행 창구 69번(안내 데스크)에 가서 "돈 찾으러 왔어요"라고 말하면, 안내원이 69번 창구에서 바로 돈을 주지 않고 "자, 51000번 VIP 방으로 가시면 직원이 돈 뭉치 드릴 겁니다"라고 안내하는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: FTP vs TFTP 아키텍처 설계 사상

항목	FTP (File Transfer Protocol)	TFTP (Trivial FTP)
전송 계층	TCP (신뢰성 있는 스트림)	UDP (비연결형 다이어그램)
포트 사용	제어(21) + 데이터(20/랜덤) 이중 채널	초기 접속(69) + 데이터(임시 랜덤) 단일 핑퐁
인증 (Authentication)	`USER/PASS` 필수	없음 (묻지도 따지지도 않음)
폴더 탐색 기능	`LIST`, `CWD` (폴더 이동/조회 가능)	없음 (정확한 파일 이름과 경로를 알아야만 받을 수 있음)
흐름 제어 / 혼잡 제어	TCP 슬라이딩 윈도우로 고속 펌핑	Stop-and-Wait (ACK 올 때까지 대기), 속도 극악
주 사용처	인터넷망 대용량 파일 송수신 (과거)	LAN 폐쇄망 내부 라우터/스위치 펌웨어 업데이트, PXE 부팅

과목 융합 관점

운영체제 (OS): 디스크 없는(Diskless) 환경에서 OS를 올리려면 DHCP, TFTP, BootP 프로토콜이 3인 1조로 융합되어 동작한다.
1. 클라이언트(깡통 PC)가 켜지면 NIC 롬(ROM)이 DHCP 브로드캐스트를 쏴서 IP를 받는다.
2. DHCP 서버는 IP뿐만 아니라 Option 66(TFTP 서버 IP)과 Option 67(부팅 파일 이름: pxelinux.0)을 같이 알려준다.
3. 클라이언트는 즉시 TFTP 서버로 달려가 이 부팅 파일을 다운로드받아 메모리(RAM)에 올려 OS 설치를 시작한다. 이것이 엔터프라이즈 데이터센터에서 수천 대의 서버를 한 방에 자동 포맷하고 리눅스를 까는 PXE (Preboot Execution Environment) 아키텍처의 심장부다.
보안 (Security): TFTP는 보안의 S자도 없는 위험한 프로토콜이다. 만약 TFTP 서버를 외부에 퍼블릭으로 열어둔다면 누구나 GET /etc/passwd 같은 요청을 날려 서버의 핵심 파일을 무단으로 빼갈 수 있다(Directory Traversal). 실무에서는 철저하게 방화벽(ACL)으로 감싸진 OOB(Out-of-Band) 관리망 안에서만 일시적으로 열어서 쓰고 닫아야 한다.
📢 섹션 요약 비유: FTP가 정식으로 서류 심사를 거쳐 짐을 싣는 거대한 이삿짐센터라면, TFTP는 서류 검사도 없이 "저기 있는 박스 줘" 하면 그냥 던져주는 무인 보관함입니다. 빠르고 편하지만 도둑이 들기 딱 좋은 시스템이죠.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 대규모 IDC 베어메탈 서버 프로비저닝 (PXE Boot) 자동화: 클라우드 인프라팀이 500대의 신규 블레이드 서버를 랙(Rack)에 꽂았다. 사람이 일일이 USB를 들고 가서 OS를 깔 수 없으므로, 사내 망에 DHCP와 TFTP 서버(dnsmasq, tftpd)를 구축했다. 서버 전원을 켜면 NIC가 알아서 TFTP를 통해 Ubuntu Kickstart 부트 이미지를 빨아들여 동시에 500대가 자동 포맷되고 OS 세팅이 완료되는 인프라 코드화(IaC) 파이프라인을 완성했다.
- 판단: TFTP는 비록 낡고 느리지만, 이 '최초 생명 부여(Bootstrapping)' 단계에서는 어떤 무거운 프로토콜도 이 가벼움을 이길 수 없다. 부트롬(Boot ROM)에 HTTP나 SSH 클라이언트 코드를 우겨넣는 것은 칩셋 단가 상승을 부르기 때문이다.
시나리오 — Cisco 라우터 설정 백업(Config Backup) 타임아웃 장애: 네트워크 엔지니어가 본사에서 지방 지사에 있는 Cisco 라우터에 접속해 명령어를 쳤다. copy running-config tftp://10.0.0.5/backup.cfg. 라우터 설정을 중앙 TFTP 서버로 덤프 뜨려는 시도였다. 하지만 파일 용량이 2MB가 넘었고 핑(Ping)이 50ms인 지방 WAN 구간이라, TFTP의 지독한 Stop-and-Wait 전송 속도 탓에 전송이 지연되다 결국 타임아웃으로 실패했다.
- 판단: TFTP의 기본 블록 크기(Block Size)는 512바이트다. 2MB를 보내려면 4,000번 왕복(RTT)을 해야 한다. WAN 구간처럼 지연(Latency)이 있는 곳에서는 최악이다. 실무에서는 RFC 2348 확장을 활용해 클라이언트와 서버가 사전에 blksize=8192 바이트 등으로 블록 크기 협상(Option Negotiation)을 거치도록 튜닝하거나, 라우터 백업 방식을 SCP(SSH 기반 복사)나 FTP로 업그레이드하는 것이 장애를 막는 정석이다.

  ┌─────────────────────────────────────────────────────────────┐
  │      실무 아키텍처: PXE Network Booting (TFTP 융합 아키텍처)      │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [디스크 없는 깡통 PC] (전원 ON!)                               │
  │   │                                                         │
  │   │ 1. DHCP 브로드캐스트 (나 IP 좀 줘! 부팅 파일 위치도!)             │
  │   │────────────────────────────────────────────────────────▶│
  │   │                                      [ DHCP 서버 ]       │
  │   │ 2. DHCP 응답 (IP: 192.168.1.10, TFTP IP: 192.168.1.100, │
  │   │              부트파일: pxelinux.0)                       │
  │   │◀────────────────────────────────────────────────────────│
  │                                                             │
  │   │ 3. TFTP RRQ (pxelinux.0 줘!)                            │
  │   │───────────────────────────────▶ [ TFTP 서버 (Port 69) ] │
  │   │ 4. TFTP DATA (부팅 커널 이미지 쪼개서 전송)                  │
  │   │◀───────────────────────────────                         │
  │                                                             │
  │ 🌟 결과: 하드디스크가 텅 비어있던 PC가 메모리에 OS 이미지를 적재하고    │
  │ 운영체제 부팅 스크린을 띄우며 마법처럼 깨어난다!                       │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드 인프라를 지탱하는 베어메탈 서버 자동화의 바이블이다. 이 시퀀스에서 TFTP가 빠지면 네트워크 부팅 자체가 성립되지 않는다. 아무것도 모르는 깡통(NIC)에게 가장 가벼운 언어(UDP)로 생명의 불씨(OS 커널)를 던져주어 일단 부팅을 시키고 나면, 그다음부터는 올라간 진짜 OS가 무겁고 튼튼한 TCP/HTTP 통신망을 잡고 나머지 설치 패키지를 고속으로 다운받는다. TFTP는 우주선이 궤도에 오를 때까지만 쓰고 버리는 '1단 로켓' 역할을 완벽히 수행한다.

도입 체크리스트

기술적: 대용량 펌웨어(수백 MB)를 전송해야 할 경우, 기본 512바이트 블록 제한에 걸려 전송 속도가 나락으로 떨어지지 않도록 TFTP 서버 설정에서 Tsize(파일 전체 크기) 및 Blksize(블록 크기) 옵션 협상 확장이 켜져 있는가?
운영·보안적: 사내 망에 임시로 띄워둔 tftpd 데몬이 실수로 0.0.0.0 (모든 인터페이스) 바인딩으로 열려있어, 외부망 인터넷에서 내부 스크립트 파일을 몰래 RRQ로 훔쳐갈 수 있는 보안 구멍이 방치되지 않았는가?

안티패턴

대용량 파일 배포망으로의 남용: "설정도 없고 포트도 하나만 열면 되니 너무 편하네!"라는 이유로 사내 망의 수 기가바이트(GB)짜리 로그 파일 동기화 시스템을 TFTP 파이프라인으로 짜버리는 대형 사고. Stop-and-Wait의 저주에 걸려 대역폭 1Gbps 네트워크 위에서 고작 1Mbps 속도를 내며 시스템이 병목에 질식사하게 된다.
📢 섹션 요약 비유: TFTP는 아기에게 처음 떠먹이는 이유식(부팅 커널) 같은 겁니다. 소화(로직)가 아주 쉬워서 깡통 상태의 갓난아기(장비)도 금방 먹을 수 있지만, 다 큰 어른(대용량 데이터 전송)에게 하루 종일 이유식만 먹이려 들면 답답해서 병이 납니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	USB 기반 수동 인프라 셋업	TFTP + PXE 부팅 자동화	개선 효과
정량	서버 100대 OS 수동 설치 50시간 소요	TFTP 브로드캐스팅 10분 동시 설치	인프라 프로비저닝 (Time-to-Value) 99% 단축
정량	펌웨어 ROM에 무거운 TCP/FTP 스택 탑재	롬 용량 수 KB의 TFTP 코드만 삽입	임베디드 및 네트워크 장비 메모리 원가 절감
정성	복잡한 설정 파일 연동 과정	스위치 CLI 명령어 한 줄 백업 완료	네트워크 장비 엔지니어 관리 편의성 극대화

미래 전망

UEFI와 HTTP 부팅의 추격: 최근 서버 메인보드의 진화로 기존 레거시 BIOS를 엎어버리고 UEFI가 대세가 되면서, 메인보드 펌웨어 자체에 HTTP 스택과 인증(TLS) 모듈을 욱여넣어 TFTP를 버리고 곧바로 안전한 HTTP/HTTPS 부팅(HTTP Boot)을 때리는 시대가 도래하고 있다.
제한된 갈라파고스에서의 생존: 범용 파일 전송 생태계에서는 이미 멸종했지만, 낡은 시스코(Cisco) 스위치 환경, 공장 자동화 라인의 소형 PLC 장비, IP 폰(VoIP) 설정 파일 배포 등 극한의 경량화와 하위 호환성이 요구되는 OT(Operational Technology) 및 임베디드 폐쇄망에서는 앞으로도 영원히 수명을 다하지 않고 생존할 좀비 프로토콜이다.

참고 표준

RFC 1350: The TFTP Protocol (Revision 2) - 가장 널리 쓰이는 표준 명세서
RFC 2347 / 2348: TFTP Option Extension / Blocksize Option (512바이트 한계 돌파를 위한 확장)

"완벽함이란 더 이상 보탤 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 완성된다." 생텍쥐페리의 이 격언은 TFTP 아키텍처에 완벽하게 부합한다. 상태 제어, 에러 복구, 슬라이딩 윈도우, 인증 등 네트워크 프로토콜이 가질 수 있는 모든 군더더기를 가차 없이 베어낸 이 무식한 핑퐁 게임은, 역설적이게도 그 텅 빈 가벼움 덕분에 네트워크 장비가 숨을 쉬기 위한 최초의 호흡(Booting)을 40년 넘게 도맡아올 수 있었다. 가장 원시적이지만 가장 치명적인 인프라의 마중물이다.

📢 섹션 요약 비유: TFTP는 건물을 지을 때 가장 먼저 박아넣고 콘크리트가 굳으면 버려지는 뼈대(비계)와 같습니다. 예쁘지도 튼튼하지도 않지만, 이 뼈대가 없으면 거대한 마천루(클라우드 인프라)는 애초에 올라갈 시도조차 할 수 없는 근본적인 기초 공사입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
UDP (User Datagram Protocol)	TFTP가 의존하는 비연결형 전송 계층으로, 핸드셰이크의 지연을 날려버려 극단적 가벼움을 획득한 핵심 배경이다.
PXE (Preboot Execution Environment)	디스크 없는 깡통 PC가 네트워크 부팅을 하기 위한 룰 규격으로, DHCP와 TFTP의 환상적인 콤비 플레이에 의해 완성된다.
Stop-and-Wait ARQ	UDP의 패킷 유실을 애플리케이션 레벨에서 극복하기 위해 TFTP가 채택한 극악무도하게 느리고 안정적인 "1개 보내고 1개 답장받기" 에러 제어 흐름이다.
FTP (File Transfer Protocol)	TFTP의 형님 격으로, 복잡한 명령어 체계와 TCP 이중 소켓을 가져 펌웨어 롬에 탑재되기엔 너무 비만했던 경쟁 프로토콜이다.
Out-of-Band (OOB) 관리망	보안 기능이 전무한 TFTP가 털리지 않게 안전하게 숨어 지낼 수 있는 데이터센터 내부의 장비 관리 전용 폐쇄 네트워크다.

👶 어린이를 위한 3줄 비유 설명

일반 FTP가 우체국 아저씨가 신분증 검사 다 하고 무거운 짐을 집 안까지 튼튼한 수레(TCP)로 옮겨주는 거라면요.
TFTP는 이름 검사도 없이, 작은 삽(512바이트)으로 모래(데이터)를 한 번 푸고 "받았어?(ACK)" 확인하면 다시 한 삽 푸는 **초간단 노가다(UDP)**예요.
무식하게 느리지만 룰이 너무나 단순해서, 복잡한 생각을 할 수 없는 깡통 로봇(공장 초기화된 라우터)한테 처음으로 밥(OS 이미지)을 떠먹일 때 무조건 써야 하는 1등 공신이랍니다!