n8n 기반 배포 후 자동 스모크 테스트 구축기 with Solar Pro 3

작업 동기

배포는 자주 일어나지만, 배포 직후 “정말 서비스가 정상 동작하는지”를 확인하는 과정은 생각보다 자주 수동에 의존하게 된다.

특히 현재 프로젝트에서는 DEV 환경에서는 배포가 끝난 뒤 주요 기능을 직접 눌러보거나, 문제가 생기면 로그를 보면서 롤백 여부를 판단하는 식으로 운영되는 경우가 많았다.

얼마 전 있었던 일

 

얼마 전에도 Prod에 배포했는데, 테스트를 진행하지 않고 배포하다 보니 주요 기능에 문제가 발생한 경험이 있었다.

이번 작업에서는 이 과정을 조금 더 자동화했다. 목표는 다음과 같다.

• DEV 배포 직후 핵심 기능이 정상인지 자동으로 확인할 것
• 실패 시 어떤 기능이 깨졌는지 구조화해서 수집할 것
• 원인 후보와 추천 조치를 LLM이 요약할 것 (접근성)
• 운영자는 Discord에서 결과를 보고 다음 액션을 결정할 수 있게 할 것

즉, 배포 성공이 아니라 배포 후 실제 주요 기능까지 정상인지를 기준으로 운영 흐름을 자동화하는 작업이었다.

 

왜 n8n을 선택했는가?

처음에는 Lambda나 AWS 내부 구성만으로 끝낼 수 있을지 고민했다.

CodeDeploy 이벤트를 받고, 테스트를 실행하고, 결과를 수집하고, 필요하면 자동 롤백까지 할 수 있다.

 

하지만 이번 작업에서 중요했던 건 “사람이 중간에 판단하는 흐름”이었다.

실패 결과를 받고, 로그 링크를 보고, LLM이 정리해준 원인 후보를 참고한 뒤, 롤백 여부를 운영자가 결정하는 구조가 필요했다.

이 관점에서 보면 역할 분담이 명확해졌다.

• AWS: 배포, 테스트 실행, 로그/메타데이터 수집
• n8n: 결과 수신, 분기, LLM 분석, Discord 알림, 승인 대기

n8n은 긴 승인 대기, 웹훅 수신, Discord 연동, LLM 호출 같은 운영 오케스트레이션에 강하다.  반대로 k6 같은 테스트 실행기 자체를 n8n에 얹는 건 오히려 부자연스럽다.

그래서 테스트 실행은 AWS, 판단과 알림은 n8n이라는 혼합형 구조를 선택했다.

 

전체 구조

전체 흐름은 아래처럼 정리했다.

1. CodeDeploy로 DEV 환경 배포
2. 배포 후 스모크 테스트 실행
3. 실패 결과를 구조화된 JSON으로 정리
4. n8n이 해당 결과를 webhook으로 수신
5. LLM이 원인 요약과 추천 조치 생성
6. Discord로 성공/실패 결과 전송
7. 이후 필요하면 롤백/보류/재실행 흐름으로 확장

핵심은 실패했다는 데에서 끝나는 것이 아니라, 어떤 API가 왜 실패했는지까지 최대한 운영 친화적으로 보여주는 데 있다.

 

DEV 스모크 테스트 범위

스모크 테스트 범위는 실제 운영에서 중요한 기능 위주로 좁게 잡았다.

• GET /health/check
• 테스트 계정 로그인
• 게시글 리스트 조회
• 게시글 상세 조회
• 텍스트 게시글 생성
• presigned URL 발급 포함 첨부 게시글 생성
• 썸네일 생성 요청
• 썸네일 반영 확인
• 게시글 수정
• 게시글 삭제
• 출석 체크

출석 체크는 하루 1회만 가능하다는 특성이 있어서, 단순히 200만 보는 것이 아니라 오늘 이미 출석했는지를 먼저 확인한 뒤 200 또는 403을 기대값으로 검증하도록 구성했다.

 

기존에 이미지 기능 테스트용으로 쓰던 k6 스크립트가 이미 있었기 때문에 스모크 테스트 스크립트를 새로 만들기보다 DEV 스모크 테스트용 경량 시나리오로 분리했다.

실행은 run-smoke.sh를 통해 할 수 있도록 정리했고, 결과는 smoke-result.json으로 남기도록 했다.

 

실패 결과 포맷 정리

자동화에서 중요한 건 실패를 어떻게 표현할 것인가이다.

단순히 exit code만 보면 운영자가 판단하기 어려우므로 스모크 결과는 정해진 스키마로 고정했다.

 

결과에는 다음 정보가 포함되도록 했다.

• 실패한 체크 항목 이름
• 엔드포인트
• 기대값과 실제값
• 응답 코드
• 에러 본문 일부
• 로그 링크
• 환경 진단 정보

이렇게 구조화된 결과를 만들면, 후속 시스템인 n8n이 이를 그대로 받아 분석하고 알림 메시지로 재구성할 수 있다.

 

n8n 배포 방식

n8n은 별도 상시 인스턴스에 self-host 방식으로 구성했다.

비용을 최대한 낮추기 위해 기존에 사용 중이던 t2.micro 계열 EC2를 활용했고, 여기에 Docker Compose + Caddy + n8n + SQLite 조합으로 배포했다.

 

 

배포는 snorose-infra 레포에서 관리하도록 분리했다.

서버 애플리케이션 레포에는 스모크 테스트 자산을 두고, n8n 호스팅과 운영 오케스트레이션은 인프라 레포에서 관리하는 구조다.

 

또한 SSH 대신 AWS Systems Manager를 사용해 배포하도록 구성했다. 이 방식의 장점은 다음과 같다.

• 22번 포트를 열 필요가 없음
• GitHub Actions에서 SSM Run Command로 배포 가능
• 기존 EC2를 그대로 활용할 수 있음

 

n8n 워크플로우 구현

 

n8n 워크플로우는 아래 흐름으로 구성했다.

Webhook → Normalize Smoke Result → Is Failed → Analyze Failure → Discord

 

먼저 webhook이 스모크 결과를 받고, Normalize Smoke Result에서 payload를 정규화한다.

이후 Is Failed에서 성공/실패를 분기한다.

성공이면 간단히 성공 알림을 Discord로 보낸다. 실패이면 Analyze Failure 노드가 실행된다.

 

Analyze Failure 노드에서는 Upstage LLM API를 사용해 실패 결과를 분석한다. 여기서 중요한 점은 단순히 실패 항목 이름만 보내지 않았다는 것이다. LLM이 실제로 의미 있는 분석을 하려면 근거가 필요하기 때문이다. 그래서 다음과 같은 추가 정보를 함께 전달했다.

• failedChecks
• envDiagnostics
• applicationLogTail
• errorLogTail
• lambdaLogTail
• httpResponseSnippet
• cloudWatchLogUrl

이 정보를 기반으로 LLM은 다음 내용을 생성한다.

• 실패 요약
• 원인 후보
• 추천 조치
• 롤백 권장 여부와 사유

이 결과는 Discord 메시지에 함께 포함되며, 운영자는 단순히 실패했다는 사실이 아니라 왜 실패했을 가능성이 높은지를 바로 볼 수 있다.

 

테스트와 검증

워크플로우가 잘 동작하는지 확인하기 위해 단순한 성공/실패 payload뿐 아니라, 로그와 응답 조각까지 포함된 리치 테스트 payload도 만들었다. 이를 webhook으로 직접 전송해 Discord 출력 결과를 확인했다.

 

성공 시 메시지, 로그는 임의로 작성함

스모크 테스트 통과 성공 시에는 배포된 Artifact의 경로를 출력한다.

 

실패 시 메시지, 로그는 임의로 작성함

스모크 테스트 통과 실패 시에는 실패한 스모크 테스트와 함께 참고해야 하는 부분, 작업하면 좋을 내용들을 출력한다.

 

마무리

이번 작업으로 DEV 배포 후 스모크 테스트 결과를 자동으로 수집하고, 실패 시 원인 후보와 추천 조치를 정리해 Discord로 전달하는 흐름까지 구축했다.

아직 최종적으로는 Snorose-Server의 실제 배포 후 스모크 실행 결과를 n8n webhook으로 자동 전송하는 단계와, Discord 버튼 기반의 승인형 롤백 흐름이 남아 있다. 하지만 지금 시점에서도 최소한 다음은 가능해졌다.

• 배포 직후 핵심 기능 검증
• 실패 결과 구조화
• LLM 기반 원인 분석
• Discord를 통한 운영 가시성 확보

결국 이 작업의 핵심은 자동화 자체보다, 배포 이후의 운영 판단을 더 빠르고 명확하게 만드는 데 있었다.

배포 성공 여부만 보는 것이 아니라, 실제 주요 기능이 살아 있는지까지 자동으로 확인하는 흐름이 있어야 비로소 안전한 배포에 가까워질 수 있다고 느꼈다.