Postiz n8n Docker 셀프호스팅 완전 가이드 — OOM 크래시부터 OAuth 삽질까지 7단계 해결기

Docker Compose 파일 하나 복붙하면 끝날 줄 알았습니다. 그런데 2분 만에 SSH조차 안 되는 서버 먹통을 경험했습니다. Postiz n8n Docker 셀프호스팅을 AWS Lightsail 2GB 서버에서 시도하면서 겪은 OOM 크래시, 버전 다운그레이드, X OAuth 설정까지 — 삽질의 전 과정과 해결법을 공유합니다.

왜 Postiz + n8n 조합인가 — 36개 SNS 계정 자동화의 시작

운영 중인 프로젝트들의 SNS 계정이 36개까지 늘어나면서 수동 발행은 더 이상 현실적이지 않았습니다. AI 봇이 콘텐츠를 생성하고, Notion과 NAS에 저장한 뒤, 자동으로 모든 계정에 발행하는 파이프라인이 필요했습니다.

Postiz는 Buffer, Hootsuite 같은 SaaS를 대체할 수 있는 오픈소스 셀프호스팅 SNS 스케줄러입니다. 36개 소셜 플랫폼을 지원하고 REST API를 제공하기 때문에 n8n 자동화 워크플로우와 연동이 가능합니다. 이미 n8n이 돌고 있는 AWS Lightsail 서버에 함께 올리면 추가 인프라 비용 없이 전체 파이프라인을 완성할 수 있다는 계산이었습니다.

AI 봇 (콘텐츠 생성)
    ↓
Notion / NAS (콘텐츠 저장 및 승인)
    ↓
n8n (자동화 워크플로우)
    ↓
Postiz (소셜 미디어 스케줄러)
    ↓
36개 SNS 계정 자동 발행

실패 1: Temporal 포함 8컨테이너 → 2분 만에 서버 먹통

동료에게 받은 docker-compose.yml 파일에는 Temporal 워크플로우 엔진의 전체 스택이 포함되어 있었습니다. Postiz 본체, PostgreSQL, Redis에 더해 Elasticsearch, Temporal Server, Temporal PostgreSQL, Temporal Admin Tools, Temporal UI까지 총 8개 컨테이너였습니다.

별생각 없이 docker compose up -d를 실행했습니다. 약 2분 후 SSH 연결이 끊겼고, 다시 접속을 시도했지만 타임아웃만 반복됐습니다. AWS Lightsail 콘솔에서 인스턴스를 강제 재부팅해야 했습니다.

OOM 원인 분석

서버 스펙은 AWS Lightsail 2GB RAM, 2 vCPU입니다. 각 컨테이너의 메모리 사용량을 추정해보면 문제가 명확해집니다.

• temporal-elasticsearch: ~1.0 GB (Elasticsearch 기본 힙 사이즈가 큼)
• temporal + temporal-postgresql + temporal-ui: ~500 MB
• postiz + postiz-postgres + postiz-redis: ~400 MB
• 합계: ~1.9 GB → 2GB 서버에서 OOM(Out of Memory) 직행

Docker 컨테이너가 가용 메모리를 모두 소진하면 Linux OOM Killer가 프로세스를 종료시키는데, 이 과정에서 SSH 데몬까지 죽어버리면 원격 접속 자체가 불가능해집니다. 콘솔 재부팅 외에는 방법이 없는 상황이 됩니다.

Temporal이란 무엇이고, 왜 소규모 셀프호스팅에서는 불필요한가

Temporal은 대규모 분산 시스템을 위한 워크플로우 오케스트레이션 엔진입니다. 수천 명의 유저가 수백 개의 SNS 계정을 운영하는 SaaS 규모에서 작업 큐 관리, 재시도 로직, 상태 추적 등을 안정적으로 처리하기 위해 설계됐습니다.

하지만 1인 또는 소규모 팀이 셀프호스팅하는 환경에서는 Postiz의 기본 내장 스케줄러와 Redis 조합으로 충분합니다. Temporal의 Elasticsearch만 1GB를 차지하는데, 36개 계정의 예약 발행을 처리하는 데 그 정도 인프라는 과잉입니다.

해결: 3컨테이너 경량 Docker Compose 구성

기존 n8n 서버의 스냅샷을 이용해 새 2GB 인스턴스를 생성했습니다. 기존 서버는 그대로 두고 새 서버에서 작업하는 방식으로 리스크를 최소화했습니다. n8n이 이미 돌고 있는 docker-compose.yml에 Postiz 관련 서비스 3개만 추가했습니다.

services:
  # 기존 n8n 서비스 (변경 없음)
  n8n:
    image: n8nio/n8n
    # ...

  # Postiz 서비스 (3개만 추가)
  postiz:
    image: ghcr.io/gitroomhq/postiz-app:v2.11.3
    container_name: postiz
    restart: unless-stopped
    environment:
      MAIN_URL: "https://postiz.yourdomain.com"
      FRONTEND_URL: "https://postiz.yourdomain.com"
      NEXT_PUBLIC_BACKEND_URL: "https://postiz.yourdomain.com/api"
      JWT_SECRET: "${POSTIZ_JWT_SECRET}"
      DATABASE_URL: "postgresql://postiz:${POSTIZ_DB_PASSWORD}@postiz-db:5432/postiz"
      REDIS_URL: "redis://postiz-redis:6379"
      BACKEND_INTERNAL_URL: "http://localhost:3000"
      IS_GENERAL: "true"
      STORAGE_PROVIDER: "local"
      UPLOAD_DIRECTORY: "/uploads"
      NEXT_PUBLIC_UPLOAD_STATIC_DIRECTORY: "/uploads"
      TEMPORAL_ADDRESS: ""
    volumes:
      - postiz_uploads:/uploads
    ports:
      - "5000:5000"
    depends_on:
      postiz-db:
        condition: service_healthy
      postiz-redis:
        condition: service_healthy

  postiz-db:
    image: postgres:17-alpine
    container_name: postiz-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: postiz
      POSTGRES_USER: postiz
      POSTGRES_PASSWORD: "${POSTIZ_DB_PASSWORD}"
    volumes:
      - postiz_db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postiz -d postiz"]
      interval: 10s
      timeout: 5s
      retries: 5

  postiz-redis:
    image: redis:7.2
    container_name: postiz-redis
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

Caddy 리버스 프록시 설정도 간단합니다. Caddyfile에 도메인과 포트 매핑 한 줄만 추가하면 HTTPS 인증서 발급과 갱신까지 자동으로 처리됩니다.

# Caddyfile
n8n.yourdomain.com {
    reverse_proxy n8n:5678
}

postiz.yourdomain.com {
    reverse_proxy postiz:5000
}

메모리 사용량 실측 결과

docker stats --no-stream로 확인한 실제 메모리 사용량입니다.

CONTAINER       CPU %   MEM USAGE / LIMIT     MEM %
postiz          0.5%    280MiB / 1.953GiB     14.0%
postiz-db       0.1%    85MiB / 1.953GiB      4.2%
postiz-redis    0.1%    8MiB / 1.953GiB       0.4%
n8n             0.2%    120MiB / 1.953GiB     6.0%
caddy           0.0%    15MiB / 1.953GiB      0.7%
합계: ~508MiB / 2GB — 충분한 여유 확보

8컨테이너 구성에서 ~1.9GB를 차지하던 것이 5컨테이너(n8n + Caddy 포함) ~500MB로 줄었습니다. 서버 안정성과 응답 속도 모두 만족스러운 수준입니다.

실패 2: Postiz latest 태그의 함정 — Temporal 필수화 문제

경량 구성으로 컨테이너를 올렸는데 Postiz가 계속 재시작 루프에 빠졌습니다. 로그를 확인하니 원인이 명확했습니다.

docker logs postiz --tail 50

# Error: TEMPORAL_ADDRESS is required
# Failed to connect to Temporal server at :7233
# Connection refused

Postiz v2.12.0부터 Temporal이 기본 의존성으로 변경됐습니다. TEMPORAL_ADDRESS를 빈 문자열로 설정해도, latest 이미지는 무조건 Temporal 연결을 시도합니다. 환경변수로 우회하는 방법은 없습니다.

v2.11.3 버전 고정으로 해결

Postiz GitHub 리포지토리의 릴리즈 노트를 확인한 결과, v2.11.3이 Temporal 없이 정상 동작하는 마지막 안정 버전입니다.

# docker-compose.yml 수정
postiz:
  # 변경 전
  image: ghcr.io/gitroomhq/postiz-app:latest

  # 변경 후 — 버전 고정 필수
  image: ghcr.io/gitroomhq/postiz-app:v2.11.3

# 이미지 교체 후 재실행
docker compose pull postiz
docker compose up -d postiz

이후 docker logs postiz --tail 20에서 “Server is running on port 5000” 메시지를 확인하면 정상 가동된 것입니다.

X(Twitter) OAuth 설정 — Native App vs Web App의 결정적 차이

X Developer Portal에서 앱을 생성할 때 설정 하나를 잘못 선택하면 OAuth 인증이 아예 작동하지 않습니다. 가장 중요한 선택지는 App Type입니다.

• Native App 선택 (정답): OAuth 1.0a 방식으로 설정되며, Consumer Key / Consumer Secret을 발급받습니다. Postiz가 요구하는 인증 방식입니다.
• Web App 선택 (함정): OAuth 2.0 방식으로 고정되며, Client ID / Client Secret이 발급됩니다. Postiz와 호환되지 않습니다.

Callback URI는 https://postiz.yourdomain.com/integrations/social/x로 설정하고, App Permissions는 반드시 Read and write로 지정해야 합니다. Read only로 설정하면 포스팅이 불가능합니다.

X API 과금 모델 (2026년 기준)

X API는 Pay-Per-Use 모델로 전환됐습니다. 트윗 발행 1건당 $0.01, 최소 충전 $5입니다. 월 100건 발행 기준 약 $1 수준으로 부담이 없습니다. 무료 플랜은 일부 읽기 전용 API만 제공하고 쓰기(포스팅) API는 유료입니다.

Sean’s Take: 28년차 엔지니어가 배운 셀프호스팅의 원칙

28년간 음악·오디오·테크 업계에서 일하면서 하나 확실히 배운 게 있습니다. 인프라든 스튜디오 장비든, 스펙시트만 보고 세팅하면 반드시 예상 못 한 문제가 터진다는 것입니다. 이번 Postiz + n8n 셀프호스팅도 정확히 같은 패턴이었습니다.

Docker 이미지 하나의 메모리 사용량까지 직접 계산해야 한다는 건, Pro Tools 세션에서 플러그인 하나하나의 CPU 사용량을 체크하는 것과 본질적으로 같습니다. 리소스에는 항상 한계가 있고, 그 한계를 넘는 순간 시스템은 예고 없이 멈춥니다. 서버가 먹통이 되든, DAW가 드롭아웃을 뿜든 말입니다.

또한 이번 경험에서 가장 인상적이었던 건 오픈소스 프로젝트의 버전 관리 리스크입니다. Postiz가 v2.12.0에서 Temporal을 필수로 만든 건 SaaS 사업자 입장에서는 합리적인 결정이지만, 소규모 셀프호스팅 사용자에게는 갑작스러운 breaking change입니다. :latest 태그를 쓰면 이런 변경에 즉시 노출됩니다. 프로덕션 환경에서는 반드시 버전을 고정하세요. 스튜디오에서 안정적으로 돌아가는 DAW 버전을 섣불리 업데이트하지 않는 것과 같은 이치입니다.

최종 구성 요약 + 향후 계획

AWS Lightsail (2GB / 2 vCPU / 서울 리전)
├── Caddy (리버스 프록시 + HTTPS 자동 관리)
├── n8n (자동화 워크플로우)
├── Postiz v2.11.3 (SNS 스케줄러)
├── postiz-db (PostgreSQL 17)
└── postiz-redis (Redis 7.2)

메모리 사용: ~450-500 MB / 2 GB
도메인: n8n.yourdomain.com, postiz.yourdomain.com

현재 구성의 한계는 분명합니다. v2.11.3은 보안 패치와 최신 기능이 빠져 있습니다. 장기적으로는 Oracle Cloud Always Free 티어(ARM 4 OCPU, 24GB RAM, 200GB 스토리지, 영구 무료)로 이전한 뒤 Temporal 포함 전체 스택으로 업그레이드할 계획입니다. 24GB라면 Elasticsearch까지 포함해도 여유가 넘칩니다.

핵심 교훈 5가지

1. docker-compose 파일을 받으면 메모리부터 계산하라 — Elasticsearch 하나가 1GB를 먹습니다
2. 소규모 셀프호스팅에서 Temporal은 불필요 — 기본 스케줄러 + Redis면 충분합니다
3. Postiz는 v2.11.3으로 버전 고정 — Temporal 없이 운영 시 필수
4. X 앱 타입은 반드시 Native App — Web App 선택 시 OAuth 1.0 연동 실패
5. Oracle Cloud 무료 티어가 장기적 최선 — 24GB RAM으로 전체 스택 운영 가능

Postiz n8n Docker 셀프호스팅은 분명 삽질이 많지만, 한번 안정화되면 월 $10(Lightsail 비용)으로 36개 SNS 계정의 자동 발행 파이프라인을 완성할 수 있습니다. Buffer나 Hootsuite의 월 수십만 원 구독료와 비교하면 압도적인 비용 효율입니다.

---

---