Windows Server 2022 IIS FTP 설정: "데이터 포트 변경 후 재시작 필요" – 이게 버그인가요? (제어 포트 21번 기본, 일반 FTP)

지난 포스트에서 공유한 PASV 응답 오류( P1=237 고정)에 대해 "이게 FTP 서버의 버그 아닌가?"라는 댓글을 받았어요. 정말 좋은 질문이에요! 저도 처음 겪을 때 "왜 이렇게 불편하게 설계됐지?"라고 생각했지만, 깊이 파헤쳐 보니 버그가 아니라 의도된 동작이었어요. Microsoft 문서와 커뮤니티 경험을 바탕으로 왜 그런지, 그리고 어떻게 대처할지 자세히 설명할게요. 이 포스트로 의문이 풀리길 바래요!

버그인가? 아니, IIS FTP의 '설계된 특징'입니다

간단 답변: 버그 아님! 재시작이 표준 절차예요

• 왜 버그처럼 느껴질까? IIS Manager에서 "적용" 클릭 후 바로 테스트하면 변경이 안 먹히니, "설정이 제대로 안 돼!"라고 오해할 수 있어요. 하지만 이는 FTP 서비스(FTPSVC)의 런타임 캐싱 메커니즘 때문이에요. 설정 파일은 업데이트되지만, 실행 중인 서비스가 새 설정을 로드하려면 재시작이 필수죠.
• Microsoft의 공식 입장: 설정 변경(특히 데이터 채널 포트 범위) 후 FTP 서비스 재시작을 명시적으로 권장해요. 이는 성능 최적화(자주 재시작 피함)와 안정성을 위한 설계예요. 버그로 분류된 적 없고, 오히려 "재시작 잊지 마세요" 가이드가 많아요.
• 비슷한 사례: Windows Server 2022 사용자들 사이에서 흔한 이슈지만, 모두 재시작으로 해결. 예를 들어, Azure VM에서 포트 범위 설정 후 연결 실패한 케이스도 재시작으로 끝났어요.

왜 이런 설계일까? (깊이 있는 이유)

1. 서비스 아키텍처: IIS FTP는 FTPSVC.exe라는 독립 서비스로 동작해요. 이 서비스는 시작 시 applicationHost.config 파일을 메모리에 로드하고, 그 상태로 유지(캐싱). 변경 시 파일은 업데이트되지만, 메모리 반영은 재시작으로만 돼요. 이는 서버 부하를 줄이기 위한 Windows의 일반 패턴(예: IIS 앱 풀 재시작 필요성)예요.
2. 보안/성능 고려: FTP처럼 포트 할당이 동적인 서비스에서 실시간 변경은 포트 충돌이나 연결 끊김을 유발할 수 있어요. 그래서 "변경 → 재시작 → 테스트" 워크플로를 강제하는 거죠. 버그라면 패치로 고쳐졌을 텐데, 2025년 현재도 동일하게 유지돼요.
3. 알려진 이슈? Microsoft Answers나 ServerFault에서 검색해 봐도 "버그" 키워드는 없어요. 대신 "restart required" 팁이 쏟아져요. 만약 진짜 버그였다면 KB 아티클이나 핫픽스가 나왔을 거예요 – 하지만 없어요!

실제 대처: 버그처럼 느껴지지 않게 하려면?

이미 아시겠지만, 재시작으로 100% 해결돼요. 아래는 더 안전한 워크플로예요.

1. 설정 변경 후 즉시 재시작

• IIS Manager > FTP 사이트 > "FTP 방화벽 지원" > 데이터 포트 5000-5100 설정.
• services.msc > "Microsoft FTP Service" > Restart. (또는 PowerShell: Restart-Service FTPSVC)

2. 확인 체크리스트

• PASV 응답 로그: 클라이언트(FileZilla)에서 p1=19~20 확인 (5000/256 ≈ 19).
• 이벤트 뷰어: "Microsoft-Windows-IIS-FTP"에 오류 없음.
• 방화벽: 21번 + 5000-5100 열림.

3. 고급 팁: 스크립트로 자동화

PowerShell 스크립트로 설정 + 재시작 한 번에:

Import-Module WebAdministration
Set-ItemProperty -Path "IIS:\Sites\YourFTPSite" -Name "ftpServer.dataChannelPortRange" -Value "5000-5100"
Restart-Service FTPSVC

이렇게 하면 "버그 같은" 불편함 줄어요!

마무르기: 버그가 아닌 '학습 포인트'로 삼아요

이 현상은 IIS FTP의 "클래식 트랩"이에요 – 버그라기보단, Windows 서버 관리의 기본 원리(서비스 재시작 문화)를 상기시켜 주는 거죠.