n8n을 활용한 이미지 서비스

n8n을 활용한 이미지 서비스

2025-07-13
수정

최근 클라우드 비용 절감과 개인 인프라 구축에 관심이 많아지면서, 기존의 클라우드 서비스를 개인 서버로 마이그레이션하는 시도가 늘고 있습니다. 이 글에서는 기존 GCP(Google Cloud Platform)에서 운영하던 이미지 저장 및 리사이징 서비스를 개인 미니 PC 서버로 옮기고, n8n을 활용하여 구축한 경험을 공유하고자 합니다.

왜 클라우드에서 개인 서버로?

클라우드 서비스는 편리하지만 비용이 지속적으로 발생합니다. 특히 S3나 Cloud Storage와 같은 스토리지 서비스, Lambda나 Cloud Functions와 같은 서버리스 기능을 사용하면 트래픽에 따라 비용이 증가할 수 있습니다. 소규모 프로젝트나 개인 프로젝트에서는 이러한 비용 부담이 상당할 수 있습니다.

또한 PlanetScale과 같은 서비스에서 Hobby 플랜이 갑자기 중단된 경험이나, 카카오와 AWS의 서비스 장애를 경험하면서 클라우드 서비스에 대한 의존도를 낮추고 직접 제어할 수 있는 인프라를 구축하고자 했습니다.

아키텍처 개요

본 이미지 서비스는 다음과 같은 구성요소로 이루어져 있습니다:

  • MinIO: S3 호환 오브젝트 스토리지로, 이미지 파일을 저장합니다.
  • n8n: 워크플로우 자동화 도구로, 이미지 업로드 및 리사이징 로직을 처리합니다.
  • Nginx: 리버스 프록시로 사용하여 보안 및 캐싱을 관리합니다.

MinIO 설정

Docker Compose를 사용하여 MinIO를 설정했습니다. 아래는 기본 설정입니다:

networks:
  okdohyuk_storage_network:
    driver: bridge

services:
  # MinIO Object Storage (S3 호환)
  minio:
    image: minio/minio:latest
    container_name: okdohyuk-storage
    restart: unless-stopped
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: your-username
      MINIO_ROOT_PASSWORD: your-password
      MINIO_SERVER_URL: http://localhost:9000
      MINIO_BROWSER_REDIRECT_URL: http://localhost:9001
      # S3 호환성 비활성화
      MINIO_DISABLE_S3_COMPAT: "true"
      # API 요청 제한 설정
      MINIO_API_REQUESTS_MAX: 10000
      MINIO_API_REQUESTS_DEADLINE: 10s
    volumes:
      - /path/to/storage/data:/data
    command: server /data --console-address ":9001"
    networks:
      - okdohyuk_storage_network
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 20s
      retries: 3

MinIO 설정 후에는 웹 콘솔(기본적으로 9001 포트)에 접속하여 버킷을 생성하고 접근 권한을 설정해야 합니다.

n8n 워크플로우 구성

CleanShot 2025-07-13 at 15.00.41@2x.pngCleanShot 2025-07-13 at 15.00.41@2x.png

n8n은 노드 기반 워크플로우 자동화 도구로, 코드 작성 없이도 복잡한 자동화 작업을 구성할 수 있습니다. 이미지 서비스를 위한 워크플로우는 다음과 같이 구성했습니다:

1. 이미지 업로드 워크플로우

  • 웹훅 노드: 이미지 업로드 요청을 받는 엔드포인트를 생성합니다.
  • 파일명 생성 노드: UUID나 해시를 사용하여 고유한 파일명을 생성합니다.
  • MinIO 업로드 노드: http 노드를 사용하여 MinIO에 이미지를 업로드합니다.
  • 응답 노드: 업로드 성공 및 이미지 URL을 반환합니다.

2. 이미지 리사이징 워크플로우

  • 웹훅 노드: 리사이징 요청을 받는 엔드포인트를 생성합니다.
  • 파라미터 검증 노드: 요청된 크기 및 형식이 유효한지 확인합니다.
  • MinIO 다운로드 노드: 원본 이미지를 불러옵니다.
  • Sharp 노드: Code 노드에서 Sharp 라이브러리를 사용하여 이미지를 리사이징합니다.
  • 캐시 확인 노드: 이미 리사이징된 이미지가 있는지 확인합니다.
  • MinIO 업로드 노드: 리사이징된 이미지를 저장합니다.
  • 응답 노드: 리사이징된 이미지 URL을 반환합니다.

보안 고려사항

개인 서버에서 서비스를 운영할 때는 보안에 특히 신경써야 합니다:

  • 2단계 인증(2FA): n8n과 MinIO 모두 2FA를 지원하므로 반드시 활성화하세요.
  • 정기적인 업데이트: 모든 서비스와 라이브러리를 최신 버전으로 유지하여 보안 취약점을 방지합니다.
  • 접근 제한: 필요한 포트만 외부에 노출하고, 가능하면 VPN이나 SSH 터널을 통한 접근을 고려하세요.
  • 로깅 및 모니터링: 비정상적인 접근이나 사용 패턴을 감지할 수 있도록 로깅을 설정하세요.
  • 백업: 정기적인 백업을 통해 데이터 손실을 방지하세요.

성능 최적화

개인 서버의 제한된 리소스에서 최적의 성능을 얻기 위한 몇 가지 팁입니다:

  • 이미지 최적화: WebP 같은 현대적인 포맷을 사용하고, 적절한 압축 설정을 적용하세요.
  • 캐싱: Nginx에서 캐싱을 활성화하여 자주 요청되는 이미지에 대한 부하를 줄이세요.
  • CDN 고려: 트래픽이 많아진다면 Cloudflare와 같은 무료 CDN을 연동하는 것도 좋은 옵션입니다.
  • 리소스 제한: Docker 컨테이너에 적절한 리소스 제한을 설정하여 한 서비스가 전체 시스템 자원을 독점하지 않도록 합니다.

결론

n8n과 MinIO를 활용한 개인 이미지 서비스는 클라우드 서비스 대비 몇 가지 장단점이 있습니다:

장점

  • 비용 절감: 월별 클라우드 비용이 발생하지 않습니다.
  • 커스터마이징: 필요에 따라 서비스를 자유롭게 수정할 수 있습니다.
  • 데이터 소유권: 모든 데이터가 내 서버에 저장되어 데이터 주권을 확보할 수 있습니다.
  • 서비스 의존성 감소: 클라우드 제공업체의 정책 변경이나 서비스 중단에 영향을 받지 않습니다.

단점

  • 속도: 엣지 로케이션을 제공하는 CDN에 비해 지리적으로 멀리 떨어진 사용자에게는 느릴 수 있습니다.
  • 유지보수: 시스템 업데이트와 보안 관리를 직접 해야 합니다.
  • 확장성: 급격한 트래픽 증가에 대응하기 어려울 수 있습니다.

소규모 프로젝트나 개인 웹사이트의 경우, 이러한 단점보다 비용 절감과 직접 제어의 이점이 더 크다고 판단됩니다. 물론 프로젝트가 성장하면 언제든 클라우드로 마이그레이션할 수 있는 유연성을 갖추는 것이 중요합니다.

이 글이 비슷한 고민을 하는 분들에게 도움이 되길 바랍니다.