프로젝트 배경

응용프로그램 배포 업무를 인수인계받으면서 개선할 점을 발견했습니다. 응용프로그램 배포를 위해서는 윈도우 PC에서 압축 파일을 풀고, 새로운 응용프로그램을 넣어 다시 압축한 후 FileZilla로 윈도우 서버 FTP에 접속해서 업로드해야 했는데요, 업무 히스토리가 궁금해서 파악해본 결과, 맥과 윈도우의 호환성 문제로 인해 선택된 방법이었습니다. 하지만 몇 가지 문제점이 있었어요.

이런 방법은 휴먼 에러의 위험성도 크고, 무엇보다 시간이 너무 오래 걸려서 해결 방안에 대해 고민하게 되었어요.🤔 이런 비효율을 개선할 수 있다면 팀 전체의 생산성이 크게 향상될 것 같았습니다. 마침 최근 바이브 코딩으로 이것 저것 만들어 보고있었기에, 이를 자동화하는 도구를 만들어보기로 했습니다.

목표는 수동으로 처리하던 파일 압축, 해제, 관리 작업들을 웹 인터페이스를 통해 효율적으로 처리할 수 있는 도구를 만들어, 기존 1시간 업무를 5분으로 단축하기였어요.

AI로 빠르게 프로토타입 완성

개발은 생각보다 아주 순조로웠어요. 요구사항 프롬프트를 자세히 작성하니 클로드가 예쁘게 코드를 짜줬거든요. 윈도우 서버의 접근하기 위해 노드 FTP 클라이언트로 연결을 했고, 한두 시간 만에 원하는 요구사항으로 개발이 완료되었습니다.

로컬로 테스트를 했더니 압축과 풀기, 업로드, 재압축 모두 성공적이어서 주변 사람들에게 시연해주며 으쓱해있었죠.

그런데.. 배포를 했더니 문제가 발생하기 시작했습니다...

개발 과정에서 만난 문제들과 해결 과정

첫 번째 고난: FTP 연결 실패

로컬에서는 문제가 없었는데, 배포 후 FTP 연결이 계속 실패했습니다.

코드 문제보다는 서버 환경 문제일 것 같아 찾아보니 방화벽 설정이 원인이었습니다.

문제 상황:

• 로컬 환경(맥): FTP 정상 작동 ✅
• 배포 환경(리눅스): FTP 연결 실패 ❌

원인:

• 서버 방화벽에 아웃바운드 설정이 없어서 외부 FTP 서버로의 연결이 차단되고 있었습니다.
  해결:
• 클라우드 업체 설정에서 FTP 포트(21번)에 대한 아웃바운드 방화벽을 허용했습니다.

이제 배포된 사이트에서도 FTP 접속이 가능해졌습니다! 🎉

두번째 시련: FTP 연결은 성공했지만 데이터 불러오기실패

또 다른 문제가 발생했습니다.
아웃바운드 설정으로 FTP 연결에 성공해서 끝났다고 생각했지만, 데이터 조회가 되지 않았습니다. 😭
이 문제를 해결하려면 FTP의 동작 방식을 이해해야 했습니다.

제어 연결은 성공했지만, 데이터 연결에서 막힌 것이었어요.

"그럼 데이터 포트도 아웃바운드하면 되겠네?" 단순하게 생각했지만... 문제는 데이터 연결 포트가 랜덤 이라는 것이었습니다.

• 수백 개의 포트를 개별 등록? → 비현실적
• 포트 범위 전체 허용? → 클라우드 업체에서 단일 포트만 지원 (범위 지정 불가)

윈도우 서버에서 포트를 고정하는 방법도 있었지만, 보안상 위험 부담이 있었죠.

결과는... 실패!
FTP는 정말 구식 프로토콜이었습니다. 포트 구조도 복잡하고 방화벽 친화적이지도 않았죠.

이렇게 포기해야 하나 싶었는데, 팀장님이 힌트를 주셨습니다.

"SFTP를 찾아보세요."

세번째, FTP -> SFTP 전환하기

SFTP, 도대체 뭘까요? 🤔

우선 FTP와 SFTP의 차이점을 찾아봤습니다.

FTP (File Transfer Protocol)

• 포트: 21번(제어) + 랜덤 포트(데이터) ← 문제의 원인!
• 보안: 평문 전송
• 연결: 이중 연결 구조

SFTP (SSH File Transfer Protocol)

• 포트: 22번 하나만 ✨
• 보안: SSH 암호화 통신
• 연결: 단일 연결 구조

“포트 하나만 사용한다고?” 이거다!

SFTP는 랜덤 포트 문제를 완전히 해결할 수 있었습니다.
22번 포트 하나만 아웃바운드 허용하면 되는 것이죠!

SFTP 전환 작업

1. 1.라이브러리 교체

기존 fpt 라이브러리를 제거하고 ssh2-sftp-client를 설치했습니다.

1. 2.연결 설정 변경

// Before: FTP
const FtpClient = require('ftp');
const client = new FtpClient();

client.connect({
    host: 'windows-server.com',
    port: 21,
    user: 'username',
    password: 'password'
});

// After: SFTP
const SftpClient = require('ssh2-sftp-client');
const sftp = new SftpClient();

await sftp.connect({
    host: 'windows-server.com',
    port: 22,  // 단일 포트!
    username: 'username',
    password: 'password'
});

1. 3.API 메서드 변경

// Before: FTP
client.list('/', (err, list) => {
    client.put(localFile, remoteFile, callback);
});

// After: SFTP  
const fileList = await sftp.list('/');
await sftp.put(localFile, remoteFile);

네 번째: 데이터 불러오기는 성공했지만... 파일 업로드 실패

SFTP 접속과 데이터 조회까지는 성공했는데, 또 다른 문제가 발생했습니다.

파일을 업로드하니 파일은 생성되지만 0 byte로 만들어지면서 다음 에러가 발생했습니다.

Write stream error: Permission denied

윈도우 서버에 파일 권한 설정이 읽기 전용으로 되어있어서, 모든 권한을 허용하여 해결했습니다.

다섯 번째: nginx 파일 업로드 사이즈 제한

배포를 완료하고 본격적으로 사용하기 전 업로드 테스트를 진행했습니다. 100MB 이상 파일을 업로드하자 413 (Request Entity Too Large) 에러가 발생했습니다.

원인은 nginx의 기본 파일 업로드 사이즈 제한(1MB)을 초과했기 때문이었습니다.

server {
    server_name test.co.kr;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version  1.1;
        
        # 각종 프록시 설정들...
        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        # ... 기타 설정들
    }
    
    # SSL 설정들...
}

위 설정에서 client_max_body_size가 명시되지 않았기 때문에 Nginx의 기본값인 1MB가 적용되고 있었습니다.

client_max_body_size를 적절한 크기 제한을 설정하여 해결했습니다.

server {
    server_name test.co.kr;
    
    # 파일 업로드 크기 제한 설정
    client_max_body_size 100M;  # 100MB로 제한
    
    location / {
        proxy_pass http://localhost:3000;
        # ... 기타 설정들
    }
}

Nginx 설정 적용 방법

1. 설정 파일 문법 검사

sudo nginx -t

2. 설정 적용

# 무중단 설정 다시 로드
sudo systemctl reload nginx

자세한 해결 과정은 별도 포스팅에 정리했습니다.

최종 결과

FTP의 복잡한 포트 문제를 SFTP의 단일 포트(22번) 사용으로 깔끔하게 해결했습니다.

개선 효과:

• 배포 작업 시간: 60분 → 5분 (92% 단축)
• 보안 강화: 평문 전송(FTP) → SSH 암호화(SFTP)
• 접근성 향상: 특정 PC 필요 → 웹 브라우저만 있으면 OK

핵심 구현 기능

• SFTP 연결 및 인증
• 파일 업로드/다운로드 - 대용량 파일 처리 가능
• 서버 파일 조회
• 파일 존재 확인 - 중복 업로드 방지
• 파일 삭제 - 서버 파일 관리

운영팀과 회의

사용 가이드를 작성해 운영팀에 전달했고, 긍정적인 반응을 받았습니다!

과정은 힘들었지만, 이런 맛에 개발하는 거죠. 😊

현재 운영팀으로부터 추가 기능 요청을 받아 개선 작업을 진행 중입니다.

회고

자동화 목표는 상당 부분 달성했지만, 네트워크 환경과 보안 정책의 제약으로 완벽한 해결책을 찾기는 쉽지 않았습니다.

특히 FTP 프로토콜의 복잡성과 클라우드 업체의 방화벽 정책이 가장 큰 걸림돌이었습니다.

배운점

기술적 한계 인식

네트워크 문제는 AI 도구만으로는 해결할 수 없었습니다.
결국 FTP의 이중 포트 구조, 방화벽 정책, SFTP의 단일 포트 동작 방식 등
기본 CS 지식이 있어야 문제를 이해하고 해결할 수 있었죠.

문제 해결 과정에서

배포 과정에서 많은 시행착오가 있었지만, 그 과정에서 네트워크 프로토콜, 보안 정책, 인프라 설정에 대해 깊이 이해할 수 있었습니다.

현실적 타협의 중요성

때로는 기술적 완벽함보다 현실적 제약 안에서의 최선의 선택이 더 중요합니다.
FTP 포트 고정, SFTP 전환, 권한 설정 등 여러 선택지 중에서
가장 안전하고 실용적인 방법을 찾아가는 과정 자체가 값진 경험이었습니다.

힘들었지만 보람찬 프로젝트였습니다! 🚀