HTTP vs FTP vs SSH 프로토콜 비교 | 용도·보안·파일 전송 선택 가이드

작성 0xmote · 2026년 5월 16일 · 15분 읽기 · 수정 2026년 9월 29일 초급

이 글의 핵심

셋 다 파일을 주고받을 수 있어 혼동되지만, HTTP는 요청-응답과 캐시, FTP는 제어·데이터 채널 분리, SSH는 하나의 암호화 연결 위 다중화라는 전혀 다른 구조를 가집니다. 이 구조 차이가 방화벽 설정, 자격 증명 노출, 폴백 전략에 어떤 영향을 주는지 짚고, 운영 중인 FTP 서버를 옮길 때 먼저 할 일을 정리합니다.

들어가며

HTTP는 웹과 API의 중심이고, FTP는 전통적인 파일 전송 프로토콜로 여전히 여기저기 남아 있으며, SSH는 원격 셸과 파일 복사(scp/sftp)의 사실상 표준입니다. 세 프로토콜은 설계 목적이 다르기 때문에, 파일만 옮기면 된다는 생각으로 아무것이나 고르면 나중에 보안과 운영에서 발목을 잡힙니다.

구조 차이를 한눈에

HTTP(S): 클라이언트가 요청하면 서버가 응답하는 무상태 모델입니다. 중간에 CDN, 프록시, 캐시가 끼어 있어서 같은 URL이라도 응답이 달라질 수 있습니다.
FTP/FTPS: 명령을 주고받는 제어 채널과 파일 바이트가 흐르는 데이터 채널이 분리되어 있습니다. 그래서 방화벽은 두 종류의 포트를 함께 고려해야 합니다.
SSH: 하나의 암호화 연결 위에 셸, SFTP, 포트 포워딩이 다중화됩니다. 겉으로는 22번 포트 하나지만, 권한 설계를 잘못하면 셸 접근까지 열어 주게 됩니다.

왜 혼동하기 쉬운가

이름에 “전송”이 들어간 프로토콜이 여럿이라 같은 파일 복사라도 HTTP 멀티파트 업로드, SFTP, FTPS가 한데 묶여 이야기되곤 합니다. 하지만 셋은 보안 경계, 포트, 클라이언트가 모두 다릅니다. 새로 구축한다면 가능한 한 HTTPS나 SFTP처럼 방화벽 규칙이 단순한 쪽에 맞추는 편이 운영 비용이 적습니다.

비유하자면 HTTP는 가게 카운터에서 주문하고 받아 가는 흐름, FTP는 창고 문을 열어 두고 상자를 옮기는 일, SSH는 관리실 열쇠를 받아 건물 안에서 일하는 것에 가깝습니다. 파일만 옮기더라도 암호화, 인증, 방화벽 요구 사항이 서로 다릅니다.

운영 관점에서 먼저 짚어 둘 점은 세 가지입니다. 평문 FTP는 감사나 규정 점검에 걸리기 쉬우므로 FTPS, SFTP, 객체 스토리지로의 이관 계획을 세워 두는 것이 좋습니다. SSH로 파일만 주고받게 하려면 셸을 막고 SFTP만 허용하는 구성을 검토해야 합니다. 공개 다운로드는 캐시, 브라우저, 모바일 클라이언트와 잘 맞는 HTTPS와 CDN 조합이 무난합니다.

언제 무엇을 쓰나

관점	HTTP(S)	FTP / FTPS	SSH / SFTP·SCP
성능·패턴	요청-응답·캐시·CDN과 궁합	대량 파일·레거시 업로드	암호화 터널 안에서 파일·셸
사용성	브라우저·REST·도구가 가장 많음	클라이언트·패시브 모드 등 설정 이슈	키 관리·권한 설계 필요
적용 시나리오	API, 정적 배포, 객체 스토리지 연동	호스팅·구형 워크플로	서버 관리, 안전한 파일 전송

프로토콜 스택과 내부 메커니즘

HTTP(S): 요청-응답과 중간 캐시

HTTP는 기본적으로 무상태입니다. Keep-Alive로 TCP 연결을 재사용하고, TLS 1.3에서는 세션 재개로 핸드셰이크 비용을 줄입니다. CDN이나 리버스 프록시는 같은 URL에 대해 캐시 히트와 미스를 나누어 처리하므로, 같은 파일이라도 요청 헤더나 접속한 POP에 따라 응답이 달라질 수 있습니다. 업로드에서는 청크 전송 인코딩이나 멀티파트로 스트림을 나누고, 애플리케이션 쪽에서 재시도와 멱등 키를 설계해야 끊김에 안전합니다.

FTP/FTPS: 제어·데이터 채널 분리

FTP는 명령용 제어 연결과 바이트 스트림용 데이터 연결이 분리되어 있습니다. 패시브 모드에서는 서버가 데이터 포트를 알려 주고 클라이언트가 그 포트로 접속합니다. 방화벽이나 NAT 환경에서 이 포트 방향이 어긋나면 “로그인은 되는데 목록 조회나 전송이 안 된다”는 증상이 나타납니다. FTPS는 여기에 TLS를 얹은 것인데, 제어 채널이 암호화되면 방화벽이나 NAT 장비가 PASV 응답을 들여다보고 포트를 열어 주는 기능(FTP ALG)도 동작하지 않습니다. 채널 두 개에 TLS까지 겹치므로 443 하나로 끝나는 HTTPS보다 운영이 무거운 편입니다.

SSH: 전송 다중화와 SFTP

SSH는 하나의 암호화된 전송 계층 위에 여러 채널을 다중화합니다. 셸, sftp 서브시스템, 포트 포워딩이 모두 같은 TCP 22번(또는 지정한 포트)을 공유합니다. SFTP는 파일 전용 프로토콜처럼 보이지만 인증과 권한은 SSH의 것을 그대로 씁니다. 그래서 키가 유출되면 영향 범위가 넓고, 최소 권한, chroot, ForceCommand 같은 하드닝이 중요합니다.

트러블슈팅

증상	우선 의심	확인
FTP 디렉터리만 열리고 전송 실패	Passive/Active 포트·방화벽	`PASV` 응답 IP/포트, 보안 그룹
HTTPS 업로드 중 끊김	프록시 타임아웃, 멱등성 없음	청크·재개·클라이언트 타임아웃
SFTP는 되는데 배포 스크립트만 실패	키·권한·`chroot` 경로	`sshd -T`, 별도 배포용 키 분리
FTPS와 SFTP 혼동	클라이언트가 다른 포트/프로토콜 기대	문서에 스택 명시

빠른 비교표

특성	HTTP(S)	FTP / FTPS	SSH (SFTP/SCP 포함)
주 목적	문서·API·웹 리소스	파일 업/다운로드	암호화된 원격 셸 + 파일 전송
기본 포트	80 / 443(HTTPS)	21 (+ 데이터 채널), 암시적 FTPS는 990	22
전송 암호화	HTTPS(TLS)로 표준화	FTPS(TLS) 또는 평문(레거시)	전송 전체가 암호화(SSH)
인증	쿠키·Bearer·TLS 클라이언트 인증서 등	사용자/비밀번호(전통적)	키·비밀번호 등
방화벽 친화	매우 좋음(443 단일)	passive/active 이슈	22 단일(단, 정책에 따라 제한)
대표 단점	파일 전용 프로토콜은 아님	평문 FTP·패시브 모드 이슈	셸 접근 = 오남용 시 위험(권한 설계 필수)

각 프로토콜 상세

HTTP / HTTPS

요청-응답 모델로, REST, GraphQL, 정적 파일, 스트리밍까지 웹의 기본이 되는 프로토콜입니다. HTTPS(TLS)로 기밀성과 무결성을 확보합니다. 캐시, CDN, 브라우저, 모바일 SDK와 모두 잘 맞고, 인증과 권한을 애플리케이션 레벨에서 세밀하게 설계할 수 있다는 점이 강점입니다. 반면 “서버 디렉터리 전체 동기화” 같은 전통적인 FTP식 작업에는 바로 들어맞지 않고, 대용량 업로드는 청크 분할과 재개 기능을 애플리케이션에서 직접 설계해야 합니다.

curl -fsS -o file.zip https://cdn.example.com/releases/app.zip
curl -X POST https://api.example.com/upload -H "Authorization: Bearer $TOKEN" -F "[email protected]"

FTP / FTPS

제어 채널(21번)과 데이터 채널이 분리된 오래된 프로토콜입니다. 평문 FTP는 비밀번호와 데이터가 그대로 네트워크에 흐르기 때문에 스니핑에 취약해서, FTPS나 SFTP로 대체하는 추세입니다. 레거시 시스템, 일부 NAS, 업계 전용 도구와의 호환성이 좋고 디렉터리 탐색이나 대량 전송 UI가 성숙하다는 장점은 여전히 있습니다. 하지만 방화벽과 NAT에서 패시브/액티브 모드 설정 문제가 반복되고, 평문 FTP를 새로 구축하는 것은 권하지 않습니다.

# 평문 FTP 대신 lftp 등으로 FTPS/SFTP 우선 검토
lftp -u user,pass -e "set ssl:verify-certificate yes; get -O /tmp/ remote.bin; bye" ftps://ftp.example.com

SSH (SFTP / SCP)

하나의 암호화된 연결 위에서 원격 셸, 포트 포워딩, SFTP(파일 조작), SCP(복사)를 모두 제공합니다. 파일 전송도 SSH 인증을 그대로 쓰므로 전송 구간이 기본적으로 암호화되고, 키 기반 인증과 authorized_keys로 자동화하기 좋습니다. 대신 셸 접근까지 함께 열리면 권한 범위가 커지므로, 파일 전송만 필요한 계정은 SFTP 전용으로 제한(chroot 등)하는 설계가 필요할 수 있습니다. 참고로 최신 OpenSSH(9.0 이상)의 scp는 내부적으로 SFTP 프로토콜을 사용합니다.

# SCP
scp -i ~/.ssh/id_ed25519 ./local.tar.gz user@server:/var/backups/
# SFTP 대화형
sftp -i ~/.ssh/id_ed25519 user@server

Python에서는 paramiko로 SFTP를 쓸 수 있습니다.

import paramiko
transport = paramiko.Transport(("server.example.com", 22))
transport.connect(username="user", pkey=paramiko.RSAKey.from_private_key_file("/path/id_rsa"))
sftp = paramiko.SFTPClient.from_transport(transport)
sftp.get("/remote/file.bin", "./file.bin")
sftp.close()
transport.close()

이 예제는 서버 호스트 키를 검증하지 않습니다. 실제 코드에서는 SSHClient와 load_system_host_keys()를 쓰거나 Transport.connect(hostkey=...)로 호스트 키를 확인해야 중간자 공격을 막을 수 있습니다.

성능·운영 비교

관점	HTTP(S)	FTP	SSH
대역폭 활용	CDN·병렬 연결·HTTP/2·3로 최적화 용이	구현·모드에 따라 편차	단일 스트림에 가깝지만 대부분 충분
연결 설정	TLS·Keep-Alive로 재사용	제어/데이터 채널 이중	SSH 핸드셰이크 1회 후 재사용 가능
운영 복잡도	낮음(443)	높음(포트·패시브)	중간(키·권한·제한)

용도 매핑

flowchart LR
  subgraph web[웹·API]
    H[HTTPS]
  end
  subgraph files[파일 교환]
    F[FTP/FTPS]
    S[SFTP]
  end
  subgraph admin[관리]
    SH[SSH]
  end
  web --> H
  files --> F
  files --> S
  admin --> SH

같은 링크에서 curl 다운로드와 scp를 비교하면 CPU 성능과 암호 스위트에 따라 차이가 날 수 있지만, 대부분의 환경에서 병목은 네트워크 쪽입니다. 다만 SSH는 채널 단위 흐름 제어 창이 있어서 지연이 큰 구간에서는 단일 스트림 처리량이 HTTP보다 낮게 나오기도 합니다.

사용 시나리오별 추천

시나리오	추천	이유
공개 파일·API	HTTPS	표준·캐시·보안
브라우저 업로드	HTTPS (multipart / S3 presigned 등)	FTP 플러그인 의존 제거
서버 간 백업	SFTP/rsync over SSH	암호화·키 인증
레거시 NAS 동기화	FTPS 또는 SFTP로 전환 검토	평문 FTP 지양
원격 명령 실행	SSH	파일 전용 프로토콜로는 부족

마이그레이션 가이드

FTP → SFTP 또는 HTTPS

기존 클라이언트가 SFTP(WinSCP, lftp, sftp)를 지원하는지 확인합니다.
서버는 OpenSSH의 Subsystem sftp를 켜고, 필요하면 chroot로 접근 경로를 제한합니다.
자동화 스크립트는 비밀번호 대신 키 인증으로 전환합니다.

FTP → 객체 스토리지 + HTTPS

S3 호환 API 등으로 presigned URL을 발급해 업로드하게 합니다.
대용량 배포는 앞단에 CDN을 두어 원본 부하를 줄입니다.

어느 쪽이든 평문 FTP를 끄기 전에 방화벽 로그와 모니터링으로 실제 접속 주체를 먼저 확인해야 합니다. 잊혀진 배치 작업이나 외부 거래처 스크립트가 남아 있는 경우가 흔합니다.

혼합 사용과 폴백

실제 환경에서는 한 가지만 쓰기보다 역할을 나누는 경우가 많습니다. 사용자에게 보이는 다운로드는 HTTPS와 CDN으로, 운영자나 CI의 배포는 SSH 키와 SFTP/rsync로 처리합니다. FTP를 당장 없앨 수 없다면 최소한 FTPS로 바꾸거나 VPN 뒤로 옮기고, 읽기 전용으로 두어 별도 네트워크에 격리합니다. 클라이언트마다 지원하는 방식이 다르면 SFTP 엔드포인트와 HTTP API 엔드포인트를 따로 제공하는 것도 방법입니다.

# rsync over SSH (백업에 자주 사용)
rsync -avz -e "ssh -i ~/.ssh/id_ed25519" ./data/ user@server:/backups/data/

흔한 실수

실수	결과	해결
SFTP와 FTPS를 혼동해 포트만 22로 열기	클라이언트·방화벽 설정이 엇갈림	문서에 프로토콜 스택을 명시
HTTPS 업로드만 두고 재시도·중복 제거 미설계	네트워크 끊김 시 중복·누락 데이터	멱등 키·청크 업로드 패턴
SSH에 강한 키 + 넓은 셸 권한	키 유출 시 피해 확대	최소 권한·별도 배포 키

흔한 질문

Q1. HTTP로 파일을 올리면 FTP보다 느리지 않나요? 구현에 따라 다릅니다. 청크 업로드, 병렬 전송, CDN을 활용하면 HTTP 쪽이 더 효율적인 경우가 많습니다. FTP가 빠르다는 체감은 대개 레거시 환경에서 나온 것입니다.

Q2. SFTP와 FTPS 중 무엇을 써야 하나요? 둘 다 암호화되지만 프로토콜 스택이 다릅니다. SFTP는 SSH 위에서, FTPS는 FTP에 TLS를 얹어 동작합니다. 새로 구축한다면 포트가 하나뿐인 SFTP나 HTTPS가 더 단순한 경우가 많습니다.

Q3. SSH만 열어 두면 HTTP가 필요 없나요? 아닙니다. 웹과 모바일 클라이언트에는 HTTPS가 표준입니다. SSH는 운영과 백업 용도에 가깝습니다.

Q4. FTP 21번만 막으면 안전한가요? 평문 FTP는 데이터 채널에 다른 포트를 쓰고, 이미 노출된 자격 증명이 문제일 수도 있습니다. 포트 차단보다 프로토콜 전환이 근본적인 해결책입니다.

Q5. HTTP/3(QUIC)와 SSH는 같이 쓰이나요? 목적이 다릅니다. HTTPS는 서비스 트래픽에, SSH는 관리 채널에 쓰며 둘을 병행하는 것이 일반적입니다.

같이 보면 좋은 글

자주 묻는 질문 (FAQ)

Q. 운영 중인 FTP 서버를 SFTP로 옮길 때 무엇부터 해야 하나요?

A. 먼저 방화벽 로그와 모니터링으로 현재 FTP에 접속하는 클라이언트와 자동화 스크립트가 무엇인지 파악하고, 이들이 SFTP(WinSCP, lftp, sftp 등)를 지원하는지 확인합니다. 서버는 OpenSSH의 Subsystem sftp를 켜고 필요하면 chroot로 접근 경로를 제한하며, 자동화 스크립트는 비밀번호 대신 별도 배포용 키 인증으로 전환합니다. 모든 연결 주체가 옮겨 간 것을 확인한 뒤에 평문 FTP를 끄는 순서가 안전합니다.