05. Other Protocols — FTP, SFTP, WebDAV, SCP, RSync
HTTP가 표준이 됐지만 세상의 파일 전송이 모두 HTTP는 아니다. FTP는 1971년부터 살아있고, SFTP는 은행이 쓴다, RSync는 백업의 왕이다. 이 문서는 “왜 거의 안 쓰이는데도 죽지 않았는가”를 정리한다.
한 줄 답
HTTP가 공개 웹의 전송을 가져갔지만, 방화벽 안의 B2B, 시스템 백업, 레거시 통합에서는 FTP/SFTP/RSync/WebDAV가 여전히 “그게 더 나은 도구”인 자리가 있다.
Why — HTTP가 다 가져갔는데도 왜 살아있나
| 프로토콜 | 살아있는 이유 |
|---|---|
| FTP | 1971년부터 존재. 레거시 ERP/방송국이 바꿀 동기가 없음. 새 도입은 거의 0 |
| FTPS | FTP에 TLS — 기존 FTP 클라이언트와 호환되면서 암호화 |
| SFTP | SSH 기반. 금융권/의료/정부의 사실상 표준 (FTP 대체) |
| WebDAV | HTTP 확장. macOS Finder, Windows 탐색기가 네이티브 지원 — NAS의 표준 |
| SCP | SSH 기반 단순 복사 — 개발자 일상 도구 (scp file user@host:) |
| RSync | 차이만 전송 — 백업의 사실상 표준 (Time Machine, GitHub Pages 빌드 등) |
How — 6개 프로토콜 핵심
FTP (File Transfer Protocol, RFC 959, 1985)
1971년 아이디어, 1985년 RFC. 가장 오래된 파일 전송 프로토콜.
동작
- 2개 채널: 명령(21번) + 데이터(20번 또는 동적 포트)
- 2개 모드: Active(서버→클라이언트 데이터 connection) / Passive(클라→서버) — Active는 NAT 뒤에선 못 씀
- 평문: 인증 비번까지 평문. 현대 환경에선 써선 안 되는 프로토콜
> ftp ftp.example.com
< 220 Welcome
> USER alice
> PASS hunter2 ← 평문
< 230 Login successful
> PASV
< 227 Entering Passive Mode (192,168,1,1,234,56)
> RETR /file.bin ← 데이터 채널로그래도 살아있는 이유
- 방송국, 신문사, 항공/물류 EDI 시스템 — 바꾸면 외부 파트너 100곳 다 깨짐
FTPS (FTP over TLS, RFC 4217)
- FTP의 명령/데이터 채널을 TLS로 감쌈
- Implicit FTPS (포트 990): 처음부터 TLS
- Explicit FTPS (
AUTH TLS): FTP로 시작 → 협상 후 TLS로 업그레이드 - 호환성 좋음 (기존 FTP 클라이언트 일부 지원)
- 단점: 데이터 채널의 동적 포트 협상이 NAT/방화벽과 자주 싸움
SFTP (SSH File Transfer Protocol)
이름은 비슷하지만 FTP와 완전히 다른 프로토콜. SSH(22번) 위에서 동작.
특징
- 단일 포트 22: 방화벽 친화적
- 암호화 + 인증: SSH의 키 인증 그대로 활용
- 재개 지원: 일부 클라이언트는 부분 전송 지원
- 권한 제어: chroot jail로 사용자별 격리 쉬움
사용처
- 금융기관 간 일배치 파일 교환 (대규모 CSV 송신)
- 의료 정보 공유 (HL7 메시지)
- AWS Transfer Family가 SFTP를 마운트형 S3로 제공 — 레거시 호환을 위한 “S3에 SFTP 달기”
# 사용 예
sftp user@host
> put file.bin
> get remote.txt
> byeWebDAV (RFC 4918)
HTTP의 쓰기 가능한 확장.
PROPFIND,MKCOL,MOVE,COPY,LOCK메서드 추가.
동작
PROPFIND /folder/ HTTP/1.1
Depth: 1
HTTP/1.1 207 Multi-Status
<?xml version="1.0"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/folder/file.txt</D:href>
<D:propstat>...</D:propstat>
</D:response>
</D:multistatus>사용처
- macOS Finder:
Finder → Go → Connect to Server → http://... - Windows 탐색기: 네트워크 드라이브 매핑
- Nextcloud, ownCloud: 셀프호스트 클라우드 스토리지
- Synology/QNAP NAS: 외부 접근 옵션
장점/단점
- 장점: 사용자가 파일 탐색기에서 그대로 씀, HTTP 위라 방화벽 친화
- 단점: 큰 파일 업로드는 약함, 동시 편집 충돌 처리 복잡
SCP (Secure Copy)
SSH 위의 명령 1줄 복사. 양방향, 단순.
# 로컬 → 원격
scp ./file.bin user@host:/tmp/
# 원격 → 로컬
scp user@host:/tmp/file.bin ./
# 디렉토리
scp -r ./project/ user@host:/srv/
# 점프 호스트 경유
scp -J jumphost ./file.bin user@inner:/tmp/한계
- 진행률 표시 약함, 재개 불가
- OpenSSH 9.0(2022)부터
scp기본 백엔드를 SFTP로 변경 — 사실상 SFTP의 CLI 래퍼가 됨
RSync (1996, Andrew Tridgell)
“차이만 전송”의 알고리즘. 같은 파일을 매번 전체 전송하지 않는다.
동작 원리 (rolling hash)
- 수신측이 파일을 고정 크기 블록으로 자른다
- 각 블록의 *약한 체크섬(Adler-32)*과 강한 체크섬(MD5) 계산
- 송신측이 이 정보를 받고 자신의 파일을 슬라이딩 윈도우로 스캔
- 같은 약한 체크섬을 발견하면 강한 체크섬으로 검증
- 다른 블록만 전송
→ 1GB 파일에서 10MB만 바뀌었으면 10MB 정도만 전송.
사용처
- 백업의 왕: macOS Time Machine, Linux 서버 백업
- GitHub Pages 빌드 배포: Jekyll → 변경된 파일만 push
- rsync.net 등 백업 전문 호스팅
- Static site deploy:
rsync -avz ./build/ server:/var/www/
옵션 cheat sheet
rsync -avz --delete --progress ./local/ user@host:/remote/
# -a: archive (권한, 시간 보존)
# -v: verbose
# -z: 압축
# --delete: 원격에서 사라진 파일 삭제 (mirror)
# --progress: 진행률What — 비교표
| 항목 | HTTP | FTP | FTPS | SFTP | WebDAV | SCP | RSync |
|---|---|---|---|---|---|---|---|
| 등장 | 1991 | 1971 | 1996 | 2001 | 1999 | 1995 | 1996 |
| 포트 | 80/443 | 21+20 | 990/990 | 22 | 80/443 | 22 | 22 (over SSH) |
| 암호화 | TLS | ✗ | TLS | SSH | TLS | SSH | SSH |
| 방화벽 | ★★★ | ★ | ★ | ★★★ | ★★★ | ★★★ | ★★★ |
| 재개 | △ (Range) | △ | △ | ✓ | △ | ✗ | ✓ (블록 단위) |
| 차이만 전송 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
| 디렉토리 | △ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 권한 | ✗ | △ | △ | ✓ | △ | ✓ | ✓ |
| 용도 | 웹·API | 레거시 | 레거시 보안 | B2B 배치 | NAS·문서 | 일상 복사 | 백업 |
| 새 시스템 적합도 | ★★★ | ✗ | ✗ | ★★ | ★ | ★★ | ★★★ |
What — 실전 결정 트리
의사결정 요약
| 상황 | 권장 |
|---|---|
| 사용자 업로드 (웹) | HTTP + S3 Multipart |
| 비디오 스트리밍 | HTTP + CDN + Signed URL |
| 은행/공공기관 배치 | SFTP (또는 AWS Transfer Family) |
| 사내 NAS | WebDAV (Finder/Explorer 마운트) |
| 서버 백업 | RSync over SSH |
| 신문사/방송국 EDI | FTP/FTPS (기존 시스템과 호환 위해) |
| Git LFS, GitHub Pages | HTTP + 자체 (RSync는 deploy 자동화 도구가 내부에서 사용) |
What-if — 흔한 함정
| 함정 | 결과 | 대응 |
|---|---|---|
| FTP를 평문으로 운영 | 비번/데이터 모두 도청 가능 | FTPS 또는 SFTP로 전환 |
| Active FTP를 NAT 환경에서 | 데이터 채널 연결 실패 | Passive 모드로 강제 |
| WebDAV에 큰 동영상 | 매크로하게 부적합 (메모리, 락 충돌) | HTTP + presigned PUT |
RSync --delete 잘못 씀 | 원본 파일 삭제 (백업이 역방향으로 동기화) | --dry-run 먼저 |
SCP로 디렉토리 보낼 때 trailing / 차이 | dir/ vs dir이 다른 결과 | 원본 끝 슬래시 의식 |
| SFTP with key + ssh-agent 안 띄움 | 매번 비번 묻기 | ssh-add ~/.ssh/id_ed25519 |
WebDAV 서버에 macOS Finder가 .DS_Store 1MB 토해냄 | 디렉토리마다 쓰레기 | 서버 측 ignore 설정 |
Insight — 흥미로운 이야기
“FTP가 1971년 발명, IP보다 오래됐다”
RFC 114 (1971년) 이 첫 FTP 사양이다. TCP/IP가 표준화된 게 1981년이니 FTP는 IP보다 10년 먼저 태어났다. 그래서 FTP 안에 IP 주소를 그대로 박는 디자인 흔적이 Passive 모드 협상 같은 곳에 남아 있다 (NAT와 싸우는 이유).
“RSync 알고리즘은 ‘확인 없는 검증’이라는 역설”
RSync는 송신측과 수신측이 서로의 파일 전체를 모르면서도 차이를 찾아낸다. 약한 체크섬(O(1) 슬라이딩)으로 후보를 빠르게 추리고, 강한 체크섬(MD5)으로 확정. 통신 비용은 줄이면서 검증 정확도는 보존하는 우아한 설계 — 1996년 박사 논문. Andrew Tridgell은 같은 사람이 Samba와 Git 객체 저장소 영감도 줬다.
“AWS Transfer Family는 SFTP의 SaaS화”
은행이 30년 된 SFTP 클라이언트를 못 바꾸지만 인프라는 클라우드로 가고 싶을 때, S3 위에 SFTP 엔드포인트를 마운트해주는 서비스. 시간당 ~$0.30. “표준은 못 바꾸는데 백엔드는 모던하게” — 이게 레거시 프로토콜이 살아남는 진짜 비즈니스 모델.
“WebDAV의 진짜 후예는 Notion/Dropbox”
WebDAV가 꿈꾼 “탐색기처럼 클라우드 파일 다루기”는 데스크탑 통합으로는 미완에 그쳤지만, 그 정신은 Dropbox 폴더, iCloud Drive, Google Drive 데스크탑에서 부활했다. 단지 프로토콜이 각자의 동기화 프로토콜로 대체됐을 뿐.
요약 + Mermaid
HTTP가 공개 웹의 전송을 가져갔지만, 방화벽 안 B2B(SFTP), 시스템 백업(RSync), NAS 마운트(WebDAV), 레거시 호환(FTPS) 자리는 여전히 다른 프로토콜이 차지한다. 새 시스템이라면 99% HTTP면 충분 — 단, 외부 파트너의 표준이 강제하는 경우만 예외. 그리고
scp는 OpenSSH 9.0부터 내부적으로 SFTP다.