내가 사용한 n8n

소프트웨어 마에스트로에서 n8n을 적용한 후기

 

n8n을 선택하게 된 배경

요구사항

우리 서비스의 핵심 기능인 '토픽 타임라인'과 '후속기사 알림'을 구현하기 위해서는 여러가지 작업들이 필요했다.

• 전처리: RSS 피드 크롤링, 뉴스 기사 요약, 텍스트 임베딩, AI 이미지 생성
• 라우팅: 뉴스 클러스터링, 토픽 저장, FCM 알림 푸시, Discord 알림

 

기존 아키텍처의 문제점

EventBridge로 Trigger 설정, Lambda로 Task 처리

 

이 방식의 한계는 여러 단계를 거치는 프로세스를 관리하기 어렵다는 점이었다.

특히 중간에 실패할 경우 어느 지점에서, 어떤 이유로 멈췄는지 파악하는 데 비용이 컸다.

 

Cloud Watch에서 Payload를 확인하고 Lambda에서 다시 동일한 결과가 나오는지 재현하는 과정을 반복했다.

개발 과정에서 이러한 방식에 피로함을 느끼고 긴 프로세스를 시각적으로 확인하고, 단계별 상태를 추적할 수 있는 도구가 필요했다.

 

다른 선택지와의 비교

여러 가지 선택지 중에서 n8n을 선택한 이유는 낮은 기술 진입장벽, 외부 서비스와의 호환성 때문이다.

드래그 앤 드롭 방식으로 워크플로우를 구성하고 API Token이나 Web Hook만 발급받으면 별도의 설치없이 외부 서비스를 사용할 수 있다는 점이 매력적이었다.

 

- AWS Step Function: AWS 서비스와 결합하기에 좋음, 하지만 외부서비스(GPT, Discord)를 연동하려면 복잡함 존재
- Airflow: 코드레벨에서 워크플로우 설정가능, 대규모 워크플로우를 구성하기 좋지만 높은 기술 진입장벽 존재

 

n8n 적용하기

n8n 아키텍처

 

n8n은 AWS 기반의 서버리스 환경에서 최소 비용과 단순한 구조를 목표로 구성하였다.

• Route53으로 CNAME 레코드를 적용하여 도메인으로 접속할 수 있도록 구성
• vCPU 0.5, Memory 1GB로 설정하여, 최소한의 비용 지출 지향
• PostgreSQL을 사용하여 Workflow 로그, 계정 정보 등 저장

 

# Fargate에서 n8n 운영 시 주의할 점

Fargate 환경에서 n8n을 운영할 경우, 컨테이너 재시작 시 데이터 유실이 발생할 수 있다.

 

n8n은 기본적으로 SQLite를 사용하며, 해당 DB는 컨테이너 내부에 저장된다.

이로 인해 컨테이너가 재시작되면 워크플로우와 계정 정보를 포함한 모든 데이터가 삭제된다.

 

이를 방지하기 위해 PostgreSQL과 같은 외부 DB를 사용해야 하며,
DB_POSTGRESDB_* 환경변수를 설정해 외부 DB를 연동하면 재시작 이후에도 데이터를 유지할 수 있다.

 

 

n8n 사용방식

Crawling Workflow(왼쪽), Routing Workflow(오른쪽)

 

n8n을 사용하면서 느낀점

n8n은 활용도가 높은 자동화 도구라고 느꼈고, 특히 비효율적인 업무 흐름을 개선하는 데 유용했다.

 

나 또한 프로젝트 과정에서 Supabase와 n8n을 이용해 가설 검증을 빠르게 하기 위한 자동화를 적용했고,
앞으로도 자동화를 통해 팀의 생산성을 높일 수 있는 지점을 고민하는 개발자가 되고자 한다.