482. FTP (File Transfer Protocol) - 양방향 연결 (제어포트 21, 데이터포트 20)

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

본질: FTP(File Transfer Protocol)는 네트워크 인프라가 척박하던 시절 대용량 파일을 안정적으로 주고받기 위해, **명령어를 주고받는 제어 채널(포트 21)**과 **실제 파일 덩어리를 쏘는 데이터 채널(포트 20)**을 완벽히 이원화한 이중 소켓(Dual-Connection) 아키텍처다.

가치: HTTP가 헤더 오버헤드를 동반하며 무상태(Stateless)로 단건 전송에 치중할 때, FTP는 로그인 상태를 유지(Stateful)하며 대용량 바이너리 파일을 중단 없이 이어받기(Resume)하고 덩어리째 옮기는 짐마차 역할을 완벽히 수행했다.

융합: 아이디와 비밀번호, 심지어 파일 본문까지 스니핑 툴에 평문(Cleartext)으로 적나라하게 노출되는 치명적인 보안 결함 탓에, 현대 인프라에서는 자취를 감추고 SSH 기반의 SFTP(TCP 22)나 HTTPS 기반의 클라우드 스토리지 API로 100% 대체되었다.

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

개념: FTP(File Transfer Protocol)는 TCP/IP 네트워크(인터넷) 상에서 컴퓨터들이 파일을 교환하기 위해 만든 클라이언트-서버 모델 기반의 최상위 응답 계층(Application Layer) 표준 프로토콜이다.
필요성: 인터넷이 갓 태동하던 1970년대, 멀리 떨어진 메인프레임 컴퓨터 사이에 연구 자료(수십 MB)를 복사하는 것은 엄청난 고역이었다. 당시엔 이메일이나 웹 브라우저도 없었다. 폴더 목록을 조회하고, 다운로드를 걸어놓고, 중간에 끊기면 이어받아야 했다. 이를 위해 "명령어만 빠릿빠릿하게 치는 소켓" 하나와 "무식하게 파일 덩어리만 묵묵히 쏘는 소켓" 하나를 철저하게 나누어 역할 분담을 시키는 고효율의 투트랙(Two-Track) 전송 체계가 필요했다.
💡 비유: 일반 전화(단일 통신)로 이사를 하려면, 전화기에 대고 "TV 옮겨주세요~ 으라차차~ 침대 옮겨주세요~ 으라차차" 하며 말과 짐을 섞어 보내느라 숨이 넘어갑니다. FTP는 감독관이 무전기(제어 포트 21)로 "3번 방 짐 전부 트럭에 실어라!"라고 짧게 명령만 내리면, 밖에 대기하던 거대한 이삿짐센터 트럭(데이터 포트 20)이 무전기와는 완전히 다른 별도의 경로를 통해 짐 덩어리만 무식하게 실어 나르는 분업 시스템과 같습니다.
등장 배경:
1. TCP/IP 여명기의 산물: 1971년 Abhay Bhushan에 의해 초기 스펙(RFC 114)이 작성되어, HTTP(1989년)보다 무려 20년이나 일찍 태어난 인터넷의 조상 격 프로토콜이다.
2. 초기 네트워크의 취약성: 당시 네트워크는 매우 불안정해서 중간에 선이 끊기는 일이 다반사였다. 제어/데이터를 분리하여 데이터가 끊어져도 제어 채널은 살아있어 "어디까지 보냈어? 다시 거기로부터 보내"라는 이어받기 로직이 절실했다.
3. 평문 전송의 비극: 그 시절엔 보안 개념이 희박하여 아이디/패스워드 암호화라는 개념 자체가 설계도에 없었다. 이것이 훗날 FTP를 역사 속으로 사라지게 만든 결정적 아킬레스건이 된다.

┌─────────────────────────────────────────────────────────────┐
│          FTP 아키텍처: 제어 채널과 데이터 채널의 완벽한 분리        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [Client]                                         [FTP Server]│
│                                                             │
│  ====== 제어 채널 (Control Connection) - TCP 포트 21 ====== │
│  (명령어와 응답 코드만 가볍게 오가는 영구적인 텔레파시 통로)         │
│   │                                                 │       │
│   │ 1. USER admin / PASS 1234 ──────────────▶│       │
│   │ ◀────────────── 230 User logged in, proceed. │       │
│   │ 2. RETR secret_file.zip (다운로드 명령) ────────▶│       │
│                                                             │
│  ====== 데이터 채널 (Data Connection) - TCP 포트 20 ======= │
│  (실제 거대한 파일 덩어리가 폭풍처럼 쏟아지는 무식한 파이프.         │
│   파일 전송이 끝나면 이 파이프는 매번 생성되었다가 즉시 닫힘)         │
│   │                                                 │       │
│   │◀◀◀◀◀◀ [ 1GB짜리 zip 바이너리 파일 덩어리 전송 ] ◀◀◀◀◀◀│       │
│   │                                                 │       │
│  ====== 제어 채널 (Control Connection) ======               │
│   │ ◀────────────── 226 Transfer complete.       │       │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] FTP의 가장 독특한 설계 철학인 '이중 연결 구조(Dual Connection)'를 보여준다. 클라이언트가 FTP 클라이언트 프로그램(FileZilla 등)을 켜면, 서버의 21번 포트로 접속해 제어 채널을 연다. 이 채널은 로그아웃할 때까지 절대 끊어지지 않으며 오직 가벼운 텍스트 명령어(USER, PASS, CWD, RETR)만 주고받는다. 만약 클라이언트가 1GB짜리 파일을 다운로드해달라(RETR)고 명령하면, 서버와 클라이언트는 21번 포트가 아닌 **20번 포트(또는 임의의 포트)**를 통해 완전히 새로운 두 번째 파이프(데이터 채널)를 별도로 뚫는다. 이 파이프는 명령어나 헤더 찌꺼기 없이 100% 퓨어한 파일 조각들만 전송하고, 파일 하나가 다 옮겨지면 뒤도 안 돌아보고 끊어버린다.

📢 섹션 요약 비유: 사장님과 비서가 통화하는 '결재 내선 전화(21번 포트)'와, 실제 컨테이너 물건이 들어오는 '화물차 전용 고속도로(20번 포트)'를 완벽히 따로 만들어서 짐이 들어오느라 내선 전화가 먹통이 되는 일이 없도록 분리한 구조입니다.

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

구성 요소 (이중 채널 모델)

채널 구분	포트 번호	프로토콜 성격	상태 지속성 (State)	비유
Control Channel (제어 채널)	TCP 21번 (기본값)	Telnet 형식의 NVT(Network Virtual Terminal) ASCII 텍스트	지속 연결 (Stateful). 로그인 상태, 현재 디렉토리 위치 기억	관제탑 무전기
Data Channel (데이터 채널)	TCP 20번 (Active 모드 시)	순수 바이너리 조각 또는 ASCII 텍스트 파일 내용물	일회성 연결. 파일 하나 전송/디렉토리 목록 1번 출력 후 즉시 종료	컨테이너 화물선

대표적인 FTP 명령어와 상태 코드

제어 채널(포트 21)을 통해 오가는 통신은 컴퓨터가 텍스트를 주고받는 대화형(Interactive) 구조다. 클라이언트가 3~4글자의 대문자 명령을 쏘면, 서버는 3자리 숫자 상태 코드와 설명을 리턴한다. (이 구조가 훗날 HTTP 상태 코드 설계의 조상이 된다).

주요 명령어 (Client ➔ Server)
- USER / PASS : 인증 수행
- CWD (Change Working Directory) : 디렉토리 이동 (서버가 현재 위치를 기억하는 Stateful 특성)
- LIST : 현재 디렉토리의 파일 목록 조회 (흥미롭게도 목록 텍스트마저 제어 채널이 아닌 데이터 채널을 새로 뚫어서 전송받음)
- RETR (Retrieve) : 파일 다운로드
- STOR (Store) : 파일 업로드
- TYPE A / TYPE I : 전송 모드 변경. A(ASCII, 텍스트 줄바꿈 변환 적용), I(Image/Binary, 원본 바이트 유지). 바이너리를 A로 받으면 파일이 100% 깨짐.
주요 응답 코드 (Server ➔ Client)
- 2xx : 성공 (예: 230 User logged in, 226 Transfer complete)
- 3xx : 추가 정보 필요 (예: 331 User name okay, need password)
- 4xx : 일시적 에러 (예: 421 Service not available)
- 5xx : 영구적 에러 (예: 530 Not logged in)

┌─────────────────────────────────────────────────────────────┐
│              Wireshark로 들여다본 충격적인 FTP 스니핑           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [공격자 화면 (사내망 스위치 미러링)]                             │
│                                                             │
│ 192.168.0.10 ➔ 192.168.0.50 [TCP 포트 21 캡처]             │
│ Payload: USER administrator\r\n                             │
│                                                             │
│ 192.168.0.50 ➔ 192.168.0.10                                │
│ Payload: 331 User name okay, need password.\r\n             │
│                                                             │
│ 192.168.0.10 ➔ 192.168.0.50 [TCP 포트 21 캡처]             │
│ 💥 Payload: PASS top_secret_p@ssw0rd! 💥                   │
│                                                             │
│ 🌟 결과: 아무런 암호화 캡슐화(TLS) 없이 아이디와 최고관리자 비밀번호가   │
│ 알파벳 그대로 허공에 날아다닌다. 옆자리 동료가 Wireshark만 켜놓으면     │
│ 1초 만에 서버의 쉘 권한이 털리는 경악스러운 보안 수준.                │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 고전 FTP 프로토콜이 IT 업계에서 강제 퇴출당하게 된 가장 결정적인 원흉이다. FTP는 TLS/SSL이라는 암호화 개념이 발명되기 전에 설계되었다. 제어 채널로 날아가는 아이디와 패스워드는 물론이고, 데이터 채널(20번 포트)로 날아가는 사내 기밀문서 내용이나 소스 코드조차 아무런 변장 없이 1과 0의 민낯(Plain text/Cleartext)으로 전송된다. 네트워크 중간의 라우터, 스위치, 통신사에서 누구나 트래픽을 가로채서(Sniffing) 들여다볼 수 있다. 이를 보완하기 위해 나온 것이 FTPS(SSL 얹기)와 SFTP(SSH 터널링)다.

📢 섹션 요약 비유: 현관 비밀번호와 집안의 금괴를 택배로 부치는데, 내용물이 훤히 다 비치는 투명한 비닐봉지에 담아서 우체부 아저씨와 동네 사람들 누구나 쳐다볼 수 있게 배달시키는 것과 같은 최악의 보안 사고입니다.

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

비교 1: FTP vs HTTP (대용량 파일 전송 철학의 차이)

두 프로토콜 모두 파일을 다운로드할 수 있지만, 아키텍처 철학이 완전히 반대다.

항목	FTP	HTTP	트레이드오프 판단
상태 유지 (State)	Stateful. 한 번 접속하면 내가 어느 폴더에 있는지(CWD) 서버가 기억함	Stateless. 매 요청마다 어느 위치의 무슨 파일을 내놓을지 풀 경로를 말해야 함	연속적인 파일 탐색/작업에 유리한가
연결 채널	2개 (21번 제어 + 20번 데이터)	1개 (80/443 포트로 제어/데이터 믹스 전송)	방화벽 통과의 편의성
전송 오버헤드	데이터 채널엔 헤더가 일절 붙지 않는 순수 100% 페이로드. 극단적 효율	매 파일 조각마다 무거운 HTTP 헤더(수백 바이트)가 덕지덕지 붙음	100GB짜리 통파일 전송 시 압도적 승리
이어받기 (Resume)	네이티브 지원 (REST 명령어)	HTTP/1.1 `Range` 헤더로 흉내 내기 가능	네트워크 단절 환경에서의 신뢰성

과거에는 "웹페이지는 HTTP로 보고 대용량 파일 첨부는 무조건 FTP로 분리해라"가 국룰이었다. 그러나 HTTP/2와 클라우드 S3의 발전, 인터넷 속도의 상향 평준화로 인해 굳이 방화벽 세팅이 골치 아픈 FTP를 유지할 가성비가 떨어져 전부 HTTP 기반 파일 다운로드로 통합되었다.

과목 융합 관점

운영체제 (OS): FTP는 유닉스 철학을 그대로 이식받았다. 파일을 전송할 때 TYPE A (ASCII) 모드로 설정하면, 서버와 클라이언트의 OS가 다를 때(Linux의 \n과 Windows의 \r\n) 생기는 줄바꿈 문자 충돌을 FTP 데몬(데몬 스레드)이 중간에서 자동으로 치환(Translation)해주어 텍스트 파일이 깨지는 것을 막아주는 마법을 부렸다.
클라우드 및 보안 (Security): AWS 환경에서 고전 FTP 서버를 EC2에 구축하려면 보안 그룹(Security Group) 포트를 20, 21번뿐만 아니라 데이터 연결을 위한 임의의 상위 포트(1024~65535) 수만 개를 전부 열어둬야(Passive 모드 시) 하는 끔찍한 방화벽 타공 지옥이 열린다. 클라우드 방화벽 아키텍처와 극단적으로 궁합이 맞지 않는 고전 유물이다.
📢 섹션 요약 비유: FTP가 옛날에 쓰던 무식하고 튼튼한 '짐 전용 이삿짐 트럭'이라면, HTTP는 에어컨도 나오고 대화도 편한 '다목적 SUV'입니다. 옛날엔 짐 트럭이 짱이었지만 요즘 SUV는 힘도 세지고 트렁크도 넓어져서 굳이 매연 뿜는 짐 트럭을 부를 필요가 없어진 셈입니다.

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

실무 시나리오

시나리오 — 구형 사내 망의 평문 FTP 탈취 사고: 공공기관에서 외주 개발업체들이 서버에 웹 소스를 올리기 위해 vsftpd 데몬을 21번 포트로 열어두고 FTP 클라이언트(알FTP)로 접속해 작업했다. 내부망 스위치에 악성 코드가 감염되어 패킷 스니핑이 발생, 개발자의 root 계정 비밀번호가 탈취당해 서버 데이터가 랜섬웨어에 감염되었다.
- 판단: 포트 21을 사용하는 고전 FTP는 즉각 폐기 처분해야 할 기술 부채(Technical Debt) 1순위다. 아키텍트는 방화벽에서 20, 21번 포트를 영구 차단하고, 리눅스 서버에 이미 깔려 있는 SSH 데몬을 재활용하여 포트 22번 하나만으로 암호화 통신과 파일 전송을 동시에 처리하는 SFTP(SSH File Transfer Protocol) 환경으로 100% 마이그레이션해야 한다.
시나리오 — 클라우드 환경(AWS)에서의 FTP 방화벽 붕괴 (Active 모드 이슈): SI 업체가 AWS EC2에 FTP 서버를 띄우고 보안 그룹(Security Group)의 인바운드 룰을 21번 포트 하나만 뚫어놨다. 사용자가 접속은 성공해서 아이디/비밀번호 로그인은 잘 되는데, 파일 목록(LIST)을 누르거나 다운로드를 누르면 화면이 멈추더니 수 분 뒤에 무한 로딩 타임아웃이 떨어졌다.
- 판단: FTP 최악의 약점인 **'Active 모드의 함정'**에 빠진 것이다. 제어 채널(21번)은 클라이언트가 서버로 문을 두드려 뚫고 들어가지만, Active FTP 모드에서는 데이터 채널(20번)을 뚫기 위해 **서버가 반대로 클라이언트의 PC(랜덤 포트)를 향해 역방향 연결(Reverse Connect)**을 시도한다. 클라이언트가 NAT(공유기) 뒤에 숨어 있거나 윈도우 방화벽이 켜져 있으면 서버가 치고 들어오는 이 역방향 연결이 100% 차단된다. 결국 연결이 성사되지 않아 무한정 대기하다 끊기는 것이다. 이를 해결하려면 클라이언트가 서버로 능동적으로 데이터 채널을 여는 Passive(패시브) 모드로 전환하고, 서버 쪽 클라우드 방화벽 랜덤 포트를 숭숭 뚫어주어야 한다. (이에 대한 딥다이브는 다음 개념에서 상세히 다룬다).

  ┌─────────────────────────────────────────────────────────────┐
  │      실무 아키텍처: FTP의 폐기와 안전한 대안(SFTP/HTTPS) 이주     │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [❌ 구식/위험 아키텍처: FTP (포트 21)]                         │
  │ - 제어 포트(21), 데이터 포트(20 또는 랜덤) 2개 구멍 다 뚫어야 함.  │
  │ - 평문 패스워드 허공에 노출.                                   │
  │ - 공유기/NAT 환경에서 포트포워딩 지옥 발생.                       │
  │                                                             │
  │ [✅ 모범 아키텍처 1: SFTP (SSH 기반, 포트 22)]                   │
  │ Client ──(SSH 터널링, 포트 22 하나만 씀!)──▶ [ Linux Server ]  │
  │ - 리눅스 기본 내장 기능으로 별도 데몬(vsftpd 등) 설치조차 불필요.      │
  │ - 강력한 RSA/ECDSA 키반환 인증 기반 + 이중화 채널도 터널 안에 캡슐화. │
  │                                                             │
  │ [✅ 모범 아키텍처 2: S3 Presigned URL (HTTP 기반)]               │
  │ Client ──(GET https://s3.aws.../?token=xyz)──▶ [ AWS S3 ]   │
  │ - 서버 자원 완전 분리, 서버 개입 없이 토큰만 받아 S3 엣지망으로 고속 다운로드.│
  │ - 웹 80/443 포트 그대로 쓰므로 방화벽 스트레스 0%.               │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 실무 시스템 아키텍트가 파일 서버 구축을 고민할 때 FTP는 아예 선택지 목록에서 지우는 것이 정석이다. 시스템 간 배치 연동(새벽에 정산 파일을 넘겨줄 때)에는 반드시 **SFTP(Secure FTP)**를 써서 22번 포트 하나로 암호화 파이프라인을 뚫는 것이 금융권/엔터프라이즈의 표준이다. 대민 서비스(고객이 첨부파일을 다운/업로드할 때)는 백엔드 서버를 거치지 않고, 서명된 암호화 URL(Presigned URL)을 클라이언트에 던져주어 AWS S3 같은 오브젝트 스토리지로 직접 HTTPS 통신을 쏘게 만드는 것이 서버 I/O 병목을 막는 클라우드 네이티브 파일 아키텍처의 끝판왕이다.

도입 체크리스트

기술적: (레거시 사유로 어쩔 수 없이 써야 한다면) FTP 데몬(vsftpd, proftpd) 설정에서 chroot_local_user=YES (감옥 가두기)가 켜져 있어, 계정이 털리더라도 해커가 /etc/passwd 같은 리눅스 루트 디렉토리 상위로 절대 올라가지(Directory Traversal) 못하게 막아두었는가?
운영·보안적: 익명 접속(Anonymous) 계정이 비활성화되어 있는가? (이를 열어두면 전 세계 해커들의 불법 소프트웨어 백업 창고로 내 서버의 하드디스크가 털리게 된다).

안티패턴

FTP over SSL(FTPS)의 맹신: 암호화를 한답시고 FTPS를 세팅했는데 묵시적(Implicit) 모드와 명시적(Explicit) 모드의 복잡성으로 인해 방화벽 세팅만 더 지옥이 되는 경우. SSH 인프라에 기생하는 SFTP와 달리 FTPS는 여전히 2개의 데이터 채널을 복잡하게 열어야 하므로 네트워크 엔지니어들의 혐오 대상 1호다.
📢 섹션 요약 비유: 열쇠 구멍이 2개(포트 2개)나 있고 투명한 문짝(평문 전송)을 달고 있던 구닥다리 금고(FTP)는 박물관으로 보내고, 최첨단 지문 인식과 강철 코팅이 된 비밀 금고(SFTP/S3)로 교체하는 것이 회사 재산을 지키는 유일한 정답입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	FTP 전송 아키텍처 (포트 21)	SFTP (포트 22) / HTTP 아키텍처	개선 효과
정량	패스워드 텍스트 도청률 100%	SSH 터널링을 통한 암호화	네트워크 스니핑 공격 방어율 100% 달성
정량	제어/데이터 방화벽 2~N개 타공	단일 포트(22 or 443) 통과	방화벽 정책 관리 및 NAT 포트포워딩 공수 수직 하락
정성	Active/Passive 모드 충돌 불만	단일 스트림으로 직관적 파일 I/O	방화벽 차단으로 인한 파일 I/O 연결 지연 및 CS 불만 제로화

미래 전망

역사 속으로의 퇴장 (Browser Deprecation): 2021년을 기점으로 구글 크롬(Chrome) 88 버전과 모질라 파이어폭스(Firefox) 브라우저에서 기본 내장되었던 FTP 기능(ftp://) 스펙 자체가 아예 삭제되었다. 웹 브라우저에서 FTP 링크를 클릭해도 더 이상 창이 열리지 않으며 전용 클라이언트(FileZilla 등)를 써야만 한다. 보안을 이유로 표준 생태계에서 완전히 사망 선고를 받은 것이다.
클라우드 스토리지 API와의 통합: 기업의 배치(Batch) 작업 파일 연동 역시 레거시 SFTP 망을 거치는 대신, AWS S3 나 GCP 버킷에 Access Key 기반의 REST API(AWS SDK)로 직접 쏘아 올리는 Data Lake 아키텍처로 100% 진화가 완료된 상태다.

참고 표준

RFC 959: File Transfer Protocol (1985년 스펙 확정, 원시 표준)
RFC 2228: FTP Security Extensions (FTPS 스펙)
RFC 4253: The Secure Shell (SSH) Transport Layer Protocol (SFTP의 근간)

FTP는 인터넷 초창기, 모든 자원과 대역폭이 귀중했던 시기에 "제어와 데이터 파이프의 철저한 분리"라는 놀랍도록 우아한 엔지니어링 통찰로 대용량 파일 전송의 제왕으로 군림했다. 그 직관적인 명령어 통신 체계와 에러 코드 3자리 설계는 HTTP를 비롯한 현대 프로토콜들의 유전자에 깊이 새겨졌다. 비록 보안이라는 시대적 파도를 넘지 못하고 도태되었으나, 네트워크 프로토콜 아키텍처의 교과서로서 그 가치는 영원히 기억될 것이다.

📢 섹션 요약 비유: 수백 년 전 튼튼한 마차(FTP)는 황무지를 뚫고 짐을 나르는 최고의 도구였지만, 사방에 매복한 산적(해커)을 피할 튼튼한 장갑(암호화)을 덧씌우지 못해 결국 역사의 뒤안길로 사라지고 튼튼한 장갑차(SFTP)에 자리를 내어준 노장입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Active / Passive Mode	FTP가 데이터 채널(20번 포트)을 열기 위해 서버와 클라이언트 중 누가 역방향 침투를 시도할지 결정하는 가장 치명적이고 골치 아픈 네트워크 연결 모드 쌍이다.
SFTP (SSH FTP)	FTP의 보안 결함을 덮기 위해 포트 21을 버리고, SSH(포트 22) 터널의 암호화된 단일 파이프라인 안에서 파일 전송까지 끝내버리는 현대 인프라의 마스터피스다.
TFTP (Trivial FTP)	대용량 전송인 TCP 기반 FTP와 달리, UDP 포트 69를 사용해 로컬 망 안에서 라우터 OS 부팅 이미지(PXE) 펌웨어를 던져주는 극도로 단순한 형제 프로토콜이다.
Stateful (상태 유지)	FTP가 로그인 직후부터 "사용자가 어느 폴더(CWD)에 진입해 있는지"를 메모리에 쭉 쥐고 있는 특징으로, HTTP의 Stateless 무상태성과 대비되는 핵심 철학이다.
NAT (Network Address Translation)	사설 IP를 쓰는 공유기 인프라로, FTP의 Active 모드 시 서버가 클라이언트 사설망으로 들어오지 못하게 철벽을 쳐버려 Passive 모드 탄생의 원인을 제공했다.

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

FTP는 커다란 짐(파일)을 인터넷으로 보내기 위해 옛날 옛적에 만든 이삿짐센터 시스템이에요.
사장님과 비서가 통화하는 전용 '내선 전화기(포트 21)'와 실제 짐만 무식하게 싣고 나르는 '대형 트럭(포트 20)'을 아예 따로 분리해서 짐 때문에 전화가 끊기는 일이 없게 똑똑하게 만들었죠.
하지만, 전화 내용이 밖으로 다 새어나가서 도둑(해커)이 내 집 비밀번호를 다 훔쳐 듣는 끔찍한 단점 때문에 요즘엔 아무도 안 쓰고 튼튼한 철갑 트럭(SFTP)으로 바꿨답니다!