FTP vs 웹 파일 전송: 2026년 브라우저가 이기는 이유

브라우저 기반 웹 전송은 거의 모든 비레거시 워크플로우에서 FTP를 추월했습니다. RFC 959(1985년)에 정의된 FTP는 기본적으로 TCP 포트 21을 통해 자격증명과 파일 내용을 평문으로 전송합니다. 현대 웹 전송은 TLS 1.3을 통해 HTTPS로 실행되고, AES-256-GCM으로 클라이언트 측에서 페이로드를 암호화하며, 브라우저 외에 수신자에게 아무것도 설정이 필요 없습니다. FileZilla의 설치 카운터는 여전히 증가하고 있지만, 순수 FTP의 신규 엔터프라이즈 배포는 사실상 사라졌습니다. SFTP와 FTPS는 서버 간 자동화에 살아남았지만, 사람이 직접 하는 전송은 웹으로 이동했습니다.

FTP가 설계된 목적

FTP는 신뢰할 수 있는 네트워크를 전제로 했습니다. 1985년 4월의 RFC 959 스펙은 상업적 인터넷보다 앞서 나온 것으로, NSFNET은 1988년이 되어서야 공개되었습니다. 포트 21은 명령 채널을, 포트 20은 데이터를 운반했으며, 암호화 보호 없이 ASCII 또는 바이너리 모드로 모든 것이 흘렀습니다. NAT 통과는 나중에 "패시브 모드"가 필요하게 된 부차적 고려사항이었습니다.

프로토콜의 나이는 그 특이함에서 드러납니다. 액티브 vs 패시브 모드 혼란, 방화벽이 싫어하는 별도의 제어 및 데이터 연결, 평문 문자열로 전송되는 사용자명과 비밀번호, 기본 무결성 검사 없음. 오동작하는 라우터를 통한 단일 전송이 오류 없이 .zip 아카이브를 자동으로 손상시킬 수 있습니다.

순수 FTP가 사실상 더 이상 쓰이지 않는 이유

브라우저들은 단계적으로 FTP 지원을 제거했습니다. Chrome은 버전 95(2021년 10월)에서 제거했습니다. Firefox는 버전 90(2021년 7월)에서 종료했습니다. Safari는 대화형으로 지원한 적이 없습니다. 즉, ftp://files.example.com/report.zip 같은 링크는 대부분의 사용자에게 더 이상 작동하지 않습니다 — 파일 하나를 가져오기 위해 FileZilla, Cyberduck, 또는 WinSCP를 설치해야 합니다.

컴플라이언스 프레임워크가 마무리했습니다. PCI DSS 4.0 섹션 4.2.1은 공개 네트워크를 통한 카드 소지자 데이터 전송에 강력한 암호화를 요구합니다. HIPAA의 기술적 세이프가드(45 CFR 164.312(e)(1))는 ePHI의 암호화된 전송을 의무화합니다. 순수 FTP는 두 가지 모두 통과하지 못합니다. 감사관들은 즉시 플래그를 답니다.

SFTP와 FTPS는 다릅니다

사람들은 끊임없이 혼동합니다. SFTP(SSH File Transfer Protocol)는 SSH 포트 22를 통해 실행되고, SSH 인증을 사용하며, 이름에도 불구하고 FTP와 프로토콜적 관계가 없습니다. FTPS는 포트 990(암시적) 또는 AUTH TLS가 있는 포트 21(명시적)에서 TLS로 래핑된 FTP입니다. 둘은 각자 다른 장애 모드를 가진 다른 종류입니다.

SFTP는 자동화된 서버 간 전송에 더 나은 선택입니다 — 연결이 하나이고, 방화벽과 잘 맞으며, 팀이 인프라에 이미 사용하는 SSH 키 관리와 통합됩니다. FTPS는 여전히 두 연결과 NAT 복잡성에 시달리는 프로토콜에 TLS를 추가합니다.

웹 전송이 대체하는 것

현대 웹 전송 서비스는 FTP가 역사적으로 소유했던 사용 사례를 처리합니다.

• 고객에게의 일회성 파일 전달 (이전에는 공유 FTP 계정)
• 벤더 파일 드롭 (이전에는 쓰기 전용 수신 폴더가 있는 익명 FTP)
• 파트너 회사 간 대용량 파일 교환 (이전에는 VPN + FTP)
• 최종 사용자에게의 소프트웨어 배포 (이전에는 공개 FTP 미러)

차이점은 계정 프로비저닝 없음, 방화벽 규칙 없음, 클라이언트 소프트웨어 설치 없음, 그리고 기본적으로 종단 간 암호화입니다.

아키텍처 비교

| 차원 | FTP (순수) | FTPS | SFTP | 웹 전송 | |---|---|---|---|---| | 포트 | 21, 20 | 990 또는 21 | 22 | 443 | | 암호화 | 없음 | TLS | SSH | TLS 1.3 + 클라이언트 측 AES-256-GCM | | 필요한 클라이언트 | FileZilla/WinSCP | FileZilla/WinSCP | OpenSSH/WinSCP | 브라우저만 | | 방화벽 친화성 | 나쁨 (이중 채널) | 나쁨 | 좋음 | 좋음 | | 재시작 지원 | 다양함 | 다양함 | 있음 | 있음 (tus/청크) | | 인증 모델 | 사용자명/비밀번호 | 사용자명/비밀번호 + 인증서 | SSH 키 | 링크 + 선택적 비밀번호 | | 2026년 최적 용도 | 더 이상 사용 안 함 | 레거시 연동 | 서버 자동화 | 사람 간 파일 공유 |

대부분의 사람들이 놓치는 지연 시간 이야기

FTP는 일부 클라이언트에서 다운로드 시 파일당 TCP 연결을 엽니다. FTP를 통해 10,000개의 소형 파일을 전송하는 것은 10,000번의 TCP 핸드셰이크를 의미합니다. 그것이 .git 저장소를 FTP로 백업하면 느리고, HTTP/2 멀티플렉싱을 통하면 같은 데이터가 훨씬 빨리 끝나는 이유입니다.

HTTP/2 또는 HTTP/3(QUIC)을 사용하는 HTTPS는 단일 연결로 많은 파일 페치를 멀티플렉싱하여 왕복 오버헤드를 대폭 줄입니다. tus.io 같은 프로토콜을 사용하는 청크 업로드를 가진 웹 전송 서비스는 연결이 끊어진 정확한 지점에서 재개하며, 순수 FTP는 서버마다 일관성 없이 이를 처리합니다.

FTP가 완고하게 살아남는 곳

방송 자동화 시스템은 Grass Valley나 Ross Video 같은 벤더의 플레이아웃 박스가 FTP 시대에 설계되었기 때문에 FTP를 통해 계열사에 콘텐츠를 계속 푸시합니다. 레거시 소매 시스템은 FTPS를 통해 본사에 야간 .csv 재고 덤프를 푸시합니다. 학술 기관은 소프트웨어 아카이브용 익명 FTP 미러를 운영합니다(대부분은 HTTPS 기반으로 마이그레이션했지만).

서버 간 자동화는 특히 SFTP에서 이점이 있습니다. SSH 키 인증이 있는 강화된 SFTP 잠금 영역에 야간 백업을 드롭하는 예약 작업은 2026년에도 여전히 좋은 아키텍처입니다. 사람이 직접 중재하는 FTP가 사라지고 있는 것입니다.

웹 전송이 명확히 이기는 경우

기술적이지 않은 수신자가 관련된 모든 것. 고객은 FileZilla를 설치하지 않을 것입니다. 외부 감사관은 FTPS 설정을 구성하지 않을 것입니다. 규제 기관은 영수증과 링크 기반 전달을 원합니다. PR 에이전시가 보도 자료 키트를 보내거나, 법무법인이 발견 문서를 교환하거나, 디자인 스튜디오가 고객에게 .psd 파일을 배송하는 경우, 브라우저의 링크가 IT 지원 티켓 없이 작동하는 유일한 전달 방법입니다.

HexaTransfer는 이 전환을 대표합니다 — 최대 10 GB 파일을 업로드하고, 링크를 공유하고, 수신자는 브라우저를 통해 다운로드합니다. 프로비저닝하거나 취소할 FTP 자격증명이 없습니다.

보안 태세

순수 FTP는 네트워크의 모든 수동 관찰자에게 자격증명을 노출합니다 — 공항 Wi-Fi, 호텔 네트워크, 공유 사무실 인프라. FTPS와 SFTP는 전송을 수정하지만 파일 내용은 엔드포인트에서 복호화되면 서버 운영자에게 평문 액세스를 허용합니다.

제로 지식 암호화가 있는 웹 전송 서비스는 파일이 브라우저를 떠나기 전에 클라이언트 측에서 암호화합니다. 서버는 암호문만 저장합니다. 서버 전체가 침해되더라도 URL 프래그먼트에 있는 파일별 키 없이는 유용한 것이 노출되지 않습니다. 이는 FTPS가 제공할 수 있는 것보다 실질적으로 더 강력한 태세입니다. GDPR, HIPAA, 개인정보 보호법(PIPA) 모두 전송 데이터의 암호화를 요구하며, 제로 지식 접근방식은 이러한 요건을 가장 효율적으로 충족시킵니다.

마이그레이션 경로

외부 파일 전달에 여전히 FTP를 실행하고 있다면 마이그레이션은 보통 간단합니다. 워크플로우(클라이언트 전달, 벤더 수신, 파트너 교환)를 식별하고, 크기 및 컴플라이언스 프로필에 맞는 웹 전송 서비스를 선택하고, 트래픽이 줄어들면 FTP 서버를 폐기합니다. 자동화된 서버 작업은 SSH 키 인증과 함께 SFTP로 이동합니다 — 그 전환에서 살아남습니다.

결론

FTP는 40년을 달렸습니다. 웹 프로토콜 스택이 FTP가 해결한 모든 문제를 해결한 다음 암호화, 방화벽 친화성, 그리고 이미 모든 기기에 탑재된 브라우저를 통한 범용 클라이언트 지원을 추가했기 때문에 패배했습니다. 새로운 대화형 파일 공유에는 웹을 사용하세요. 자동화된 서버 파이프라인에는 SFTP를 사용하세요. 팩스 기계 옆에 순수 FTP를 남겨두세요.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.