n8n으로 CI/CD를 만들었다”는 이야기가 아니라, 왜 기존 방식이 불편했고, 그래서 이 구조를 선택했는지에 대한 기록이다.
“PR이 merge되면 자동 배포되는 구조가 정말 안전한가?”
GitHub Actions, GitOps, Argo CD를 써도 결국 배포는 기계적인 이벤트 트리거에 의해 일어난다.
하지만 실제 운영에서 배포는 항상 이런 질문을 동반한다.
- 이 변경이 위험한가?
- 지금 배포해도 되는가?
- 누가 이 변경을 승인했는가?
- 어떤 파일이 얼마나 바뀌었는가?
기존 CI/CD는 이 질문을 거의 다 무시한다.
왜 n8n이었나
n8n을 선택한 이유는 n8n은 CI 도구가 아니라 워크플로우 엔진이기 때문이다.
GitHub Actions는:
“이 이벤트가 발생하면 이 스크립트를 실행해라”
n8n은:
“이 이벤트가 발생하면, 이 데이터를 가져와서, 이 판단을 하고,
이 사람에게 보여주고, 승인되면 다음으로 가라”
라는 흐름을 자연스럽게 만든다.
즉, 배포를 파이프라인이 아니라 의사결정 흐름으로 만들 수 있다.
Structure
- GitHub Pull Request → Slack 승인 → Docker Build → ECR → EC2 배포 → Health Check → Release Note → Confluence 자동 기록
GitHub는 코드를 관리하고, EC2는 실행하고, n8n이 그 사이의 모든 판단을 맡는다.
// docker-compose.yml
version: "3.8"
services:
n8n:
image: n8nio/n8n:latest
container_name: n8n
ports:
- "5678:5678"
environment:
- TZ=Asia/Seoul
- N8N_HOST=12.12.123.4
- N8N_PORT=5678
- N8N_PROTOCOL=http
- WEBHOOK_URL=http://123.123.123.123:5678
- N8N_SECURE_COOKIE=false
- N8N_WEBHOOK_SECRET=my-secret
- N8N_BLOCK_ENV_ACCESS_IN_NODE=false
volumes:
- n8n_data:/home/node/.n8n
- /var/run/docker.sock:/var/run/docker.sock
restart: always
redis:
image: redis:7
container_name: n8n-redis
command: redis-server --appendonly yes
volumes:
- ./redis_data:/data
web:
image: 1234.dkr.ecr.eu-north-1.amazonaws.com/n8n_client:${IMAGE_TAG}
container_name: web
ports:
- "80:80"
restart: always
volumes:
n8n_data:Flow
1. GitHub → n8n: PR이 병합되었을 때 트리거
1) GitHub Webhook 설정:
Event: pull_request
Action: closed2) n8n Webhook Node:
POST /webhook/github-pr-mergedpull_request.merged === true
base.ref === "master"
2. GitHub API로 변경 내용 수집
1) PR Commit 목록
GET /repos/{owner}/{repo}/pulls/{pr_number}/commits2) PR 변경 파일
GET /repos/{owner}/{repo}/pulls/{pr_number}/files
3. AI가 변경 요약을 생성
// Prompt
[PR 제목]
{{ pull_request_title }}
[변경된 파일 요약]
{{ file_summaries }}
[커밋 메시지]
{{ commit_message }}
[코드 변경 일부]
{{ patches }}
변경 목적과 배포 위험도를 3~5줄로 요약하라.- Slack으로 생성된 Summary를 전달하여 Approve Response 대기 후 Approve인 경우 다음 단계로 진행
4. GitHub Actions 트리거
1) n8n → GitHub API:
POST /repos/{owner}/{repo}/actions/workflows/build-and-push.yml/dispatches2) payload
{
"ref": "master",
"inputs": {
"image_tag": "79f62e",
"callback_url": "http://n8n/deploy-callback",
"deployment_id": "PR-123"
}
}
5. GitHub Actions → ECR → n8n Callback
1) GitHub Actions:
docker build -t myapp:${IMAGE_TAG}
docker push ECR/myapp:${IMAGE_TAG}
curl -X POST $CALLBACK_URL \
-d '{"status":"success","image_tag":"79f62e","deployment_id":"PR-123"}'- n8n Webhook /deploy-callback 이 이 요청을 받는다.
6. Redis Lock & Metadata 저장
redis-cli SET deployment:PR-123 '{"pull_request_title":"...","patches":"..."}'
redis-cli SETNX deploy_lock 1- 이 데이터는 중복 배포 방지 및 Release Note 생성에 사용된다.
7. EC2에서 최신 이미지로 배포
1) Health Check
curl -s -o /dev/null -w "%{http_code}" http://localhost/health2) Redis에서 PR 데이터를 불러와 AI에게 전달
// Prompt
당신은 프로덕션 배포 이후에 기록될 공식 Release Note를 작성하는 시니어 엔지니어입니다.
아래에 제공된 Pull Request 정보와 변경 내역을 바탕으로,
운영 및 협업에 도움이 되는 구조화된 Release Note를 작성하세요.
반드시 아래 형식을 따르세요.
1. 요약 (Summary)
이번 배포의 목적과 핵심 변경 사항을 2~3줄로 간결하게 작성
2. 변경 사항 (Changes)
주요 변경 내용을 불릿 포인트로 정리
기능 추가 / 수정 / 설정 변경 중심으로 작성
변경점에 대한 부분을 리스트 형식으로 디테일하게 나열
3. 영향도 (Impact)
사용자에게 미치는 영향
시스템/운영 측면에서의 영향
영향이 없다면 "사용자 영향 없음"과 같이 명시
4. 리스크 및 참고 사항 (Risk & Notes)
배포 시 고려해야 할 잠재적 리스크
설정 변경 또는 주의해야 할 사항
문제가 발생할 경우 롤백 시 참고할 포인트
추측이나 제공되지 않은 정보에 기반한 내용은 작성하지 마세요.
명확하고 전문적인 톤으로 작성하세요.
[PR 제목]
{{ $json.pull_request_title }}
[변경된 파일 요약]
{{ $json.file_summaries }}
[커밋 메시지]
{{ $json.commit_message }}
[코드 변경 일부]
{{ $json.patches }}
9. Confluence에 자동 업로드
POST /wiki/rest/api/content
{
"type": "page",
"title": "[Release] 2026-01-12 – Web – 79f62e",
"space": { "key": "DEV" },
"ancestors": [{ "id": "1234" }],
"body": {
"storage": {
"value": "<h2>🚀 Release Note</h2><p>...</p>",
"representation": "storage"
}
}
}
10. Redis 정리 & Lock 해제
redis-cli DEL deployment:PR-123
redis-cli DEL deploy_lock결론
이 시스템의 핵심은 자동 배포가 아니다.
배포를 “사건”이 아니라 “의사결정 과정”으로 바꾼 것
n8n은 CI/CD 도구가 아니라 배포를 통제하는 컨트롤 플레인이 된다.
