n8n 과 GitHub Actions 의 분리선

자동화 도구를 고를 때 흔히 하는 실수가 “하나로 다 하려는 것”이다. GitHub Actions로 배포도 하고 슬랙 알림도 보내고 데이터 정제도 하면 될 것 같다. n8n으로 API 연동도 하고 CI도 흉내낼 수 있을 것 같다. 실제로 해보면 두 도구 모두 억지로 쓰는 구간이 생긴다. 우리는 꽤 오랜 시행착오 끝에 분리선을 찾았다.

GitHub Actions 가 잘하는 것

GitHub Actions는 코드 저장소와 결합된 이벤트에 강하다. 커밋이 올라갔을 때, PR이 열렸을 때, 태그가 달렸을 때. 이 이벤트들에 반응해서 테스트를 돌리고, 빌드하고, 배포한다. 코드와 워크플로우가 같은 저장소에 있어서 이력 관리가 자연스럽고, 팀원 모두가 git을 통해 접근할 수 있다.

또한 Actions는 코드 변경에 의존적인 작업에 적합하다. 환경 변수를 시크릿으로 관리하고, 런너를 고르고, 캐시를 설정하는 방식이 개발자 친화적이다. 우리는 모든 배포 파이프라인을 Actions에 넣어두었다. 어떤 커밋이 어떤 배포를 트리거했는지 추적하기 쉽다.

n8n 이 잘하는 것

n8n은 코드 저장소 바깥의 이벤트와 서비스 연동에 강하다. 외부 API에서 데이터를 가져오는 것, 여러 SaaS 서비스 사이를 연결하는 것, 주기적으로 무언가를 실행하는 것. GitHub와 직접 관련 없는 자동화들이다.

우리의 경우 고객 이탈 감지 후 슬랙 알림 발송, 주간 지표 수집 및 리포트 생성, 특정 이벤트 발생 시 외부 서비스 호출 같은 작업들이 n8n에 있다. 이런 작업들을 Actions에 넣으면 저장소 구조가 지저분해지고, 코드와 무관한 변경이 git 이력을 오염시킨다.

분리선 기준

우리가 내린 기준은 간단하다.

코드 이벤트에 반응하거나, 배포와 연결된 것 → GitHub Actions
외부 서비스 연동이나, 코드와 무관한 주기적 작업 → n8n

경계가 모호한 작업도 있다. 배포 후 슬랙 알림 같은 경우가 그렇다. 우리는 이걸 Actions에 넣었다. 배포와 결합되어 있고, 배포 실패 여부를 함께 다뤄야 하기 때문이다.

반대로 매일 오전에 특정 데이터를 수집해서 슬랙에 올리는 작업은 n8n이다. Actions로도 가능하지만, 코드 저장소와 연관이 없는 스케줄 작업을 Actions에 두면 불필요한 의존성이 생긴다.

운영하며 느낀 것

분리선을 정하고 나서 두 도구 모두 더 단순하게 쓰게 됐다. 억지로 맞추려는 시도가 줄고, 각 도구의 장점만 활용하게 됐다. n8n의 비주얼 에디터는 비개발자도 워크플로우를 수정할 수 있다는 장점도 있다. Actions는 코드로 관리되어 리뷰가 가능하다는 장점이 있다. 역할을 나누고 나면 이 장점들이 서로 충돌하지 않는다.

— by slecs