HTTP vs FTP vs SSH 프로토콜 비교 | 용도·보안·파일 전송 선택 가이드
이 글의 핵심
HTTP, FTP, SSH의 목적·보안 모델·포트·인증 방식을 비교합니다. 웹 API·대량 파일·원격 관리에 맞는 프로토콜 선택과 curl·OpenSSH 예제를 정리했습니다.
들어가며
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를 대체할 때의 주의점을 이해하실 수 있습니다
프로토콜 스택과 내부 메커니즘
HTTP(S): 요청-응답과 중간 캐시
HTTP는 기본적으로 무상태입니다. Keep-Alive로 TCP 연결을 재사용하고, TLS 1.3에서는 핸드셰이크 비용을 줄이기 위해 세션 재개 등을 사용합니다. CDN·리버스 프록시는 동일 URL에 대해 캐시 히트/미스를 나누므로, “같은 파일”이라도 헤더·지역 POP에 따라 응답이 달라질 수 있습니다. 업로드 경로에서는 청크 전송 인코딩·멀티파트로 스트림을 쪼개고, 애플리케이션은 재시도·멱등 키를 설계해야 합니다.
FTP/FTPS: 제어·데이터 채널 분리
FTP는 제어 연결(명령)과 데이터 연결(바이트 스트림)이 분리되어 있습니다. 패시브 모드에서는 서버가 데이터 포트를 알려 주고 클라이언트가 연결합니다. 방화벽·NAT 환경에서 어느 방향으로 포트를 열지가 어긋나면 “로그인은 되는데 리스트/전송이 안 된다”는 증상이 납니다. FTPS는 이 위에 TLS를 얹지만, 채널 두 개 + TLS라서 단일 443 HTTPS보다 운영이 무거운 편입니다.
SSH: 전송 다중화와 SFTP
SSH는 하나의 암호화된 전송 위에 채널을 multiplexing합니다. 셸, 서브시스템(sftp), 포트 포워딩이 같은 TCP 22(또는 커스텀 포트)를 공유합니다. SFTP는 파일 전용 프로토콜처럼 보이지만, 하부는 SSH 인증·권한 모델을 그대로 씁니다. 그래서 키 유출 시 영향 범위가 넓고, 최소 권한·chroot·ForceCommand 같은 하드닝이 중요합니다.
트러블슈팅
| 증상 | 우선 의심 | 확인 |
|---|---|---|
| FTP 디렉터리만 열리고 전송 실패 | Passive/Active 포트·방화벽 | PASV 응답 IP/포트, 보안 그룹 |
| HTTPS 업로드 중 끊김 | 프록시 타임아웃, 멱등성 없음 | 청크·재개·클라이언트 타임아웃 |
| SFTP는 되는데 배포 스크립트만 실패 | 키·권한·chroot 경로 | sshd -T, 별도 배포용 키 분리 |
| FTPS와 SFTP 혼동 | 클라이언트가 다른 포트/프로토콜 기대 | 문서에 스택 명시 |
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.comSSH (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@serverPython (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, 네트워크, 보안, 비교
심화 부록: 구현·운영 관점
이 부록은 앞선 본문에서 다룬 주제(「HTTP vs FTP vs SSH 프로토콜 비교 | 용도·보안·파일 전송 선택 가이드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.
내부 동작과 핵심 메커니즘
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
sequenceDiagram participant C as 클라이언트/호출자 participant B as 경계(런타임·게이트웨이·프로세스) participant D as 의존성(API·DB·큐·파일) C->>B: 요청/이벤트 B->>D: 조회·쓰기·RPC D-->>B: 지연·부분 실패·재시도 가능 B-->>C: 응답 또는 오류(코드·상관 ID)
- 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
- 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.
프로덕션 운영 패턴
| 영역 | 운영 관점 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가 |
| 안전성 | 입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가 |
| 성능 | 캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가 |
| 용량 | 피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가 |
스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.
확장 예시: 엔드투엔드 미니 시나리오
앞선 본문 주제(「HTTP vs FTP vs SSH 프로토콜 비교 | 용도·보안·파일 전송 선택 가이드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.
- 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
- 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
- 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
- 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
- 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
ctx = newCorrelationId()
validated = validateSchema(request)
authorize(validated, ctx)
result = domainCore(validated)
persistOrEmit(result, idempotentKey)
recordMetrics(ctx, latency, outcome)
return result문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스, 타임아웃, 외부 의존성, DNS | 최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검 |
| 성능 저하 | N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납 | 상한·TTL·힙/FD 스냅샷 비교 |
| 빌드·배포만 실패 | 환경 변수, 권한, 플랫폼 차이, lockfile | CI 로그와 로컬 diff, 런타임·이미지 버전 핀 |
| 설정 불일치 | 프로필·시크릿·기본값, 리전 | 스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화 |
| 데이터 불일치 | 비멱등 재시도, 부분 쓰기, 캐시 무효화 누락 | 멱등 키·아웃박스·트랜잭션 경계 재검토 |
권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.
배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.
자주 묻는 질문 (FAQ)
Q. 이 내용을 실무에서 언제 쓰나요?
A. HTTP, FTP, SSH의 목적·보안 모델·포트·인증 방식을 비교합니다. 웹 API·대량 파일·원격 관리에 맞는 프로토콜 선택과 curl·OpenSSH 예제를 정리했습니다. 실전 예제와 코드로 개념부터 활용까지 정… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.
Q. 선행으로 읽으면 좋은 글은?
A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.
Q. 더 깊이 공부하려면?
A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- FTP 프로토콜 실전 활용 | Active·Passive·FTPS·SFTP와 파일 전송 운영
- 파일 전송 프로토콜 완벽 가이드 | FTP·SFTP·FTPS·SMB·NFS·SCP 비교
- SSH 프로토콜 보안 원격 접속 | 공개키·ProxyJump·포트 포워딩·OpenSSH 실전
이 글에서 다루는 키워드 (관련 검색어)
네트워크, HTTP, FTP, SSH, 비교, 보안, 용도 등으로 검색하시면 이 글이 도움이 됩니다.