FTP 프로토콜 실전 활용 | Active·Passive·FTPS·SFTP와 파일 전송 운영

들어가며

FTP(File Transfer Protocol)는 1970년대부터 쓰인 파일 전송 프로토콜로, 웹 이전 시대의 배치·레거시 시스템·대용량 교환에서 아직 흔히 등장합니다. 제어 채널과 데이터 채널이 분리되고, Active/Passive 모드에 따라 방화벽 규칙이 달라져 “로컬에선 되는데 운영만 안 된다”는 유형이 많습니다.

동시에 평문 인증이라는 근본적 약점 때문에, FTPS(FTP over TLS)나 SFTP(SSH 파일 전송)로 대체·병행하는 것이 2026년 기준 실무 표준에 가깝습니다. 이 글은 동작을 이해하고, 클라이언트·서버 설정과 보안 선택을 한 번에 정리합니다.

왜 아직 FTP를 다루나요?

신규 서비스의 기본 선택은 HTTPS·S3 API·SFTP 쪽으로 가는 편이지만, 은행·제조·장비 등에서는 여전히 FTP 연동 명세가 남아 있습니다. 문제는 프로토콜 자체가 아니라 평문·방화벽·NAT와의 조합이므로, 레거시를 유지하더라도 Active/Passive·FTPS·SFTP 이관 로드를 문서로 고정해 두어야 합니다.

프로덕션에서 주의할 점

• 평문 FTP는 자격 증명·파일 내용이 노출될 수 있으므로, 가능한 한 즉시 FTPS 또는 SFTP로 전환합니다.
• Passive 모드에서는 데이터 포트 범위가 방화벽·NAT와 한 세트로 관리되어야 합니다. 21만 열고 끝이면 실패가 납니다.
• 서버 공인 IP와 NAT 뒤 실제 IP가 다르면 pasv_address(또는 동등 설정)를 반드시 맞춥니다.

이 글을 읽으면

• 제어(21/tcp) vs 데이터 채널 역할을 구분할 수 있습니다
• Active/Passive 흐름과 방화벽·NAT 이슈를 설명할 수 있습니다
• 명령줄·GUI 클라이언트로 업로드·다운로드·재개를 수행할 수 있습니다
• FTPS vs SFTP를 보안·운영 관점에서 선택할 수 있습니다

---

목차

1. 프로토콜 개요
2. 동작 원리
3. 실전 사용
4. 보안 고려사항
5. 실무 활용 사례
6. 최적화 팁
7. 흔한 문제와 해결
8. 마무리

---

프로토콜 개요

역사 및 개발 배경

FTP는 RFC 114(1971) 시절부터 이어져 RFC 959(1985)가 사실상의 전통적 기준이었고, 이후 확장 명령·IPv6·보안 강화(FTPS)가 붙었습니다. HTTP·S3·클라우드 스토리지가 보급되면서 새 시스템의 기본 선택에서는 밀렸지만, 메인프레임·산업 장비·구형 MFT 등에서는 여전히 FTP 인터페이스가 남아 있습니다.

OSI 7계층에서의 위치

FTP는 응용 계층 프로토콜이며, 전송 계층에서는 일반적으로 TCP를 사용합니다(제어 21, 데이터는 모드에 따라 다름). SFTP는 이름이 비슷하지만 SSH 위의 별도 프로토콜입니다.

핵심 특징

특징	설명
이중 채널	명령·응답은 제어 연결, 실제 파일은 데이터 연결.
세션 상태	로그인·CWD 등 대화형 세션.
전송 모드	스트림·블록·압축(구현·용도별).
텍스트 명령	USER, PASS, RETR, STOR 등 명령어 문자열.

---

동작 원리

제어 채널과 데이터 채널

• 제어 채널(기본 21/tcp): 인증, 디렉터리 이동, 전송 준비 명령.
• 데이터 채널: 디렉터리 목록(LIST)·파일 내용 전송의 실제 바이트가 흐릅니다.

Active 모드

1. 클라이언트가 서버 21로 제어 연결.
2. 데이터 전송 시 클라이언트가 로컬 데이터 포트를 열고 서버에 알림(PORT).
3. 서버가 클라이언트 쪽으로 데이터 연결을 적극적으로 열음(서버가 “액티브”하게 연결).

클라이언트 방화벽 뒤에서 서버의 인바운드가 막히면 실패하기 쉽습니다.

Passive 모드

1. 제어 연결은 동일.
2. 클라이언트가 PASV(또는 EPSV)로 서버의 데이터 주소·포트를 받음.
3. 클라이언트가 서버의 데이터 포트로 연결(서버는 패시브로 대기).

서버 측 데이터 포트 범위가 방화벽에서 열려 있어야 합니다.

Passive 흐름을 한 줄로 보면 제어 21번으로 명령을 주고, PASV로 알려준 데이터 포트로 클라이언트가 붙어 파일 바이트를 주고받습니다.

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: 제어 연결
  C->>S: PASV
  S->>C: 데이터 주소 안내
  C->>S: 데이터 연결
  S->>C: 파일 전송

자주 쓰는 명령(개념)

명령	의미
USER / PASS	인증(평문—위험).
PWD / CWD	현재 경로·이동.
LIST / NLST	목록.
RETR	다운로드.
STOR / APPE	업로드·이어 붙이기.
TYPE	ASCII/IMAGE(바이너리) 등.
PASV / EPSV	패시브 모드.

---

실전 사용

명령줄 클라이언트(lftp 예—macOS/Homebrew 등)

lftp에서 패시브 모드 설정은 구현마다 옵션 이름이 다를 수 있어, 공식 문서·set -a 출력을 확인하세요.

# 대화형 세션
lftp -u username,password ftp.example.com
# 세션 안에서: ls, cd, get file.bin, put local.bin, mirror -R 등

# 패시브 모드(구현별 옵션명 확인)
lftp -e 'set net:max-retries 2; ls' -u username,password ftp.example.com

curl로도 제한적 다운로드가 가능합니다.

curl -u user:pass 'ftp://ftp.example.com/pub/readme.txt' -o readme.txt

vsftpd 설정 예시(개념)

/etc/vsftpd.conf (배포판별 경로 상이)

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=50100
# pasv_address=공인IP   # NAT 뒤 서버일 때 중요
ssl_enable=YES        # FTPS

• listen=YES: 독립 데몬 모드로 자체 포트에서 수신합니다(배포판·설정에 따라 listen_ipv6 등과 함께 씀).
• anonymous_enable=NO: 익명 로그인을 끕니다. 공개 미러가 아니라면 보통 NO입니다.
• local_enable=YES / write_enable=YES: 로컬(시스템) 사용자로 로그인·업로드를 허용합니다. 쓰기 범위는 OS 권한·chroot와 함께 최소화합니다.
• local_umask=022: 업로드 파일의 기본 권한 마스크입니다(너무 느슨하면 안 됩니다).
• pasv_enable=YES: Passive 모드를 켭니다. 클라이언트가 방화벽 뒤인 경우가 많아 실무에서 자주 사용합니다.
• pasv_min_port / pasv_max_port: Passive 데이터 채널에 쓸 포트 범위입니다. 방화벽에서 이 구간을 인바운드 허용해야 합니다.
• pasv_address: 클라이언트가 PASV 응답으로 받을 공인 IP입니다. NAT 뒤에서 내부 IP가 노출되면 연결이 실패합니다.
• ssl_enable=YES: FTPS(TLS)를 켭니다. 인증서·프로토콜 버전은 별도 TLS 설정과 함께 관리합니다.

방화벽에서 21/tcp와 pasv_min/max 포트를 허용해야 Passive가 안정적입니다.

Chroot·권한

• 전용 시스템 사용자·chroot jail로 업로드 루트를 제한합니다.
• 쓰기 가능 디렉터리만 최소 권한으로 엽니다.

---

보안 고려사항

평문 FTP의 위험

기본 FTP는 자격 증명·파일 내용이 암호화되지 않습니다. 공용 Wi‑Fi·중간 경로에서 스니핑에 노출됩니다.

FTPS(FTP over TLS)

명시적 FTPS: 제어 채널에서 AUTH TLS 후 암호화. 암시적 시작(레거시 990)은 피하는 추세입니다. 인증서 관리·TLS 버전을 최신으로 유지합니다.

SFTP(SSH)

SFTP는 FTP가 아닙니다. SSH 세션 위에서 동작하며, 키 기반 인증·암호화가 일관됩니다. 새로 구축할 때 SFTP가 선택지로 자주 올라옵니다.

구분	FTPS	SFTP
기반	FTP + TLS	SSH
포트	21(+데이터) / 방화벽 복잡	22(기본) 단순한 편
레거시 호환	기존 FTP 툴	SSH 클라이언트 필요

---

실무 활용 사례

시나리오	설명
레거시 연동	은행·제조 배치 파일 교환, 오래된 MFT 규격.
대용량 파일	재개(resume)·병렬이 구현된 클라이언트(lftp mirror 등)로 이전.
익명 배포	공개 미러(보안·악용 방지 정책 필수).
장비 펌웨어	일부 장비는 FTP만 제공—격리 네트워크·FTPS로 보완.

---

최적화 팁

• 병렬 전송: lftp의 mirror -P N 등으로 다중 파일 동시 처리.
• 재개: 전송 중단 시 REST/RETR 또는 클라이언트의 resume 지원 확인.
• 바이너리 모드: 이미지·zip은 TYPE I(IMAGE)로 손상 방지.
• 근접 배치: 지리적으로 가까운 중계 서버로 RTT를 줄입니다.

---

흔한 문제와 해결

증상	점검
Passive에서 타임아웃	서버 PASV 범위 방화벽 개방, NAT 뒤 IP(pasv_address) 설정.
Active만 안 됨	클라이언트 데이터 포트 인바운드 차단—Passive 전환.
목록은 되고 전송만 실패	데이터 채널 방화벽, TLS 데이터 채널(FTPS) 설정 불일치.
한글 파일명 깨짐	클라이언트 UTF-8 옵션, 서버 OPTS UTF8 ON 지원 여부.

흔한 실수와 해결

실수	결과	해결
제어(21)만 열고 데이터 포트는 미개방	목록·전송 단계에서 타임아웃	Passive 포트 범위를 방화벽에 명시
pasv_address를 내부 IP로 둠	클라이언트가 잘못된 주소로 데이터 연결	공인 IP 또는 NAT 외부 주소로 수정
평문 FTP로 유지	스니핑·자격 증명 유출 위험	FTPS 또는 SFTP로 이관 계획
FTPS와 SFTP를 동일시	포트·방화벽·클라이언트 설정이 엇갈림	스택이 다르다는 점을 문서에 명시

---

마무리

FTP는 제어·데이터 분리와 Active/Passive라는 독특한 구조 때문에 방화벽·NAT와 동행해 왔고, 평문이라는 레거시 부채도 함께 안고 있습니다. FTPS로 전송 계층을 보강하거나, 가능하면 SFTP·객체 스토리지 API로 이관하는 것이 현대적 운영 방향입니다.

추천 시나리오: 레거시 FTP 연동 유지보수, Passive 포트·NAT 문제 해결, 보안 강화 로드맵(FTPS/SFTP) 수립이 필요할 때 이 글의 점검표를 활용하세요.

---

참고

• RFC 959, RFC 4217(FTPS)
• man lftp, OpenSSH SFTP 문서