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

2026년 3월 30일 · 18분 읽기 · 수정 2026년 3월 30일 초급

이 글의 핵심

HTTP vs FTP vs SSH — 계층·보안·전송 패턴을 비교하고 파일·API·관리에 맞게 고릅니다.

들어가며

HTTP는 웹과 API의 중심이고, FTP는 전통적인 파일 전송에 이름이 남아 있으며, SSH는 원격 셸과 파일 복사(scp/sftp)의 표준입니다. 세 프로토콜은 설계 목적이 다르고, “파일만 옮기면 된다”고 해서 아무거나 쓰면 보안·운영에서 발목을 잡을 수 있습니다.

아키텍처: 컴포넌트 관계를 한눈에

HTTP(S): 클라이언트가 요청하면 서버가 응답하는 무상태 모델입니다. 중간에 CDN·프록시·캐시가 끼어 동일 URL이라도 응답이 달라질 수 있습니다.
FTP/FTPS: 제어 채널(명령)과 데이터 채널(파일 바이트)이 분리됩니다. 방화벽은 두 종류의 포트를 함께 봐야 합니다.
SSH: 하나의 암호화 연결에 셸·SFTP·포워딩이 멀티플렉싱됩니다. 포트 22 하나로 보이지만, 권한 설계는 셸 포함으로 넓어질 수 있습니다.

왜 혼동하기 쉬운가요?

이름에 “전송”이 붙은 프로토콜이 여럿이라, 같은 ‘파일 복사’라도 HTTP 멀티파트, SFTP, FTPS는 보안 경계·포트·클라이언트가 모두 다릅니다. 새 구축은 가능한 한 HTTPS·SFTP처럼 단순한 방화벽 규칙에 맞추는 편이 운영 비용이 적습니다.

프로덕션에서 주의할 점

평문 FTP는 감사·규정에 걸리기 쉽습니다. FTPS·SFTP·객체 스토리지로의 이관을 로드맵에 둡니다.
SSH로 파일만 주고 싶다면 셸을 막고 SFTP만(chroot 등) 허용하는 패턴을 검토합니다.
공개 다운로드는 HTTPS + CDN이 캐시·브라우저·모바일과의 궁합이 좋습니다.

비유로 말씀드리면, HTTP는 가게 카운터에서 주문·결제하는 흐름, FTP는 창고 문 열고 상자 옮기기, SSH는 건물 관리실 열쇠로 들어가서 일하기에 가깝습니다. 파일만 옮기더라도 암호화·인증·방화벽 요구가 다릅니다.

언제 HTTP(S), 언제 FTP/FTPS, 언제 SSH(SFTP)를 쓰나요?

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

이 글을 읽으면

HTTP / FTP / SSH의 역할과 전형적인 포트·보안 모델을 구분하실 수 있습니다
파일 전송·API·서버 관리에 맞는 선택 기준을 잡으실 수 있습니다
curl, sftp, scp 등 실전 명령 예제를 익히실 수 있습니다
레거시 FTP를 대체할 때의 주의점을 이해하실 수 있습니다

1. 빠른 비교표

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

2. 각 프로토콜 상세

HTTP / HTTPS

특징: 요청-응답 모델입니다. REST·GraphQL·정적 파일·스트리밍까지 웹의 기본입니다. HTTPS(TLS)로 기밀성·무결성을 확보합니다.

장점

캐시·CDN·브라우저·모바일 SDK와 완벽한 궁합
인증·권한을 애플리케이션 레벨에서 세밀하게 설계 가능

단점

“서버 전체 파일 동기화” 같은 전통적 FTP 워크플로에는 직접적이지 않을 수 있음
대용량 업로드는 청크·재개 등을 앱에서 설계

코드 예제 (curl)

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는 2026년 기준 신규 구축에 비권장

예제 (안전한 대안 권장)

# 평문 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 등) 설계가 필요할 수 있음

코드 예제

# SCP
scp -i ~/.ssh/id_ed25519 ./local.tar.gz user@server:/var/backups/

# SFTP 대화형
sftp -i ~/.ssh/id_ed25519 user@server

Python (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()

3. 성능·운영 비교

관점	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 다운로드 vs scp는 CPU·암호 스위트에 따라 차이가 납니다. 병목은 보통 네트워크입니다.

4. 사용 시나리오별 추천

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

5. 마이그레이션 가이드

FTP → SFTP 또는 HTTPS

클라이언트가 SFTP(WinSCP, lftp, sftp) 지원하는지 확인.
서버는 OpenSSH의 Subsystem sftp + 필요 시 chroot.
자동화 스크립트는 키 인증으로 전환.

FTP → 객체 스토리지 + HTTPS

S3 호환 API 등으로 presigned URL 업로드.
CDN 앞단에 두어 대용량 배포 최적화.

주의: 평문 FTP를 끄기 전에 방화벽·모니터링으로 연결 주체를 확인하세요.

6. 실전 팁

혼합 사용

사용자 대면 다운로드: HTTPS + CDN.
운영자·CI 배포: SSH 키 + SFTP/rsync.
FTP가 남아 있으면: 최소 FTPS 또는 VPN 뒤로 이동.

폴백 전략

클라이언트가 SFTP만 되는 경우와 HTTP API만 되는 경우를 나누어 엔드포인트 제공.
레거시 FTP: 읽기 전용·별도 네트워크로 격리.

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

7. 흔한 질문

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는 관리 채널로 병행하는 것이 일반적입니다.

마무리

웹·API·공개 배포는 HTTPS가 중심입니다.
전통적 파일 서버는 평문 FTP를 지양하고 SFTP/FTPS/HTTPS로 옮기는 것이 안전합니다.
서버 관리·자동화는 SSH가 사실상 표준입니다.

한 줄 정리: 사용자와 API는 HTTPS, 운영자·백업은 SSH(SFTP), 레거시 FTP는 단계적으로 끕니다.

흔한 실수와 해결

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

HTTP 완벽 가이드
FTP 실전 가이드
SSH 보안 원격 가이드

키워드

HTTP, HTTPS, FTP, FTPS, SSH, SFTP, SCP, 네트워크, 보안, 비교