n8n 과 GitHub Actions 의 분리선

왜 결제·정산 현장에서 이 분리선의 실패 비용이 더 큰가

자동화 도구를 "하나로 다 하려는" 충동은 팀이 작을수록 강해진다. 관리 포인트를 줄이고 싶은 건 자연스러운 욕구다. 그런데 결제·정산 시스템을 운영하는 입장에서는 이 충동이 일반 서비스보다 훨씬 비싼 실패로 돌아온다. 우리 팀은 초기에 PG사 정산 데이터를 수집하는 파이프라인을 GitHub Actions cron으로 돌렸다. 저장소 시크릿이 교체되는 시점에 파이프라인이 조용히 멈췄고, 배포 이력에는 아무런 변화가 없었다. 이틀 뒤 수기 대조 과정에서 발견했을 때 이미 정산 불일치 3건이 발생한 상태였다.

코드 이벤트와 무관한 스케줄 작업을 Actions에 두면 이런 "조용한 실패"가 발생하기 쉽다. 결제 시스템의 특성상 "누가, 언제, 어떤 코드를 배포했는가"는 감사 추적의 핵심이다. GitHub Actions는 커밋 SHA, 배포 시각, 트리거 이벤트가 자동으로 기록된다. 반면 n8n 워크플로우 변경 이력은 별도로 관리하지 않으면 "누군가 노드를 바꿨는데 언제인지 모름" 상태가 된다. 분리선을 그어야 하는 이유가 단순한 도구 효율성이 아니라 운영 책임과 감사 가능성의 문제다.

GitHub Actions가 진짜 잘하는 것: 코드 변경과 결과의 인과관계

GitHub Actions의 핵심 강점은 "코드 변경과 그 결과를 추적 가능하게 묶는 것"이다. 커밋 a3f9c2b가 프로덕션 배포를 트리거했고, 그 배포 이후 오류율이 0.3% 상승했다는 연결고리를 Deployment 이벤트와 연계해서 볼 수 있다. 이 인과관계가 자연스럽게 기록되는 구조 자체가 핵심이다. 우리 팀의 경우 결제 게이트웨이 설정 변경, SDK 버전 업그레이드, 정산 계산 로직 수정은 모두 PR → 리뷰 → Actions 배포 플로우를 거친다.

.github/workflows/ 안에 있는 파일은 리뷰어가 diff를 볼 수 있고 배포 전 테스트가 자동 실행된다. "그 설정 언제 바뀐 거야?"라는 질문에 git blame으로 30초 안에 답할 수 있다는 것이 소규모 팀에게는 엄청난 안전망이다. 실제로 지난 분기에 PG사 수수료 계산 로직에서 소수점 처리 버그를 PR 단계에서 잡았는데, Actions CI가 edge case 테스트를 자동 실행해서 발견한 케이스였다. 해당 버그가 프로덕션에 올라갔다면 수십 건의 정산 오류가 발생했을 상황이었다.

n8n이 진짜 잘하는 것: 코드 저장소 바깥의 세계를 연결하기

n8n의 진짜 가치는 "코드를 모르는 팀원도 비즈니스 로직을 직접 조작할 수 있게 만드는 것"이다. 우리 팀에서 정산 담당자가 직접 n8n 워크플로우를 수정해서 특정 가맹점의 알림 조건을 바꾼 사례가 있다. 이를 GitHub Actions로 했다면 개발자에게 PR을 요청하고, 리뷰를 기다리고, 배포를 기다려야 했다. n8n에서는 15분 안에 조건식 노드 하나를 수정하고 테스트 실행까지 끝났다. 개발자의 컨텍스트 스위칭 비용도 0이다.

우리가 n8n에 두는 작업의 특징은 세 가지다: (1) 외부 SaaS API와의 연동—Slack, PG사 조회 API, 세금계산서 발행 API, (2) 시간 기반 스케줄—매일 오전 8시 전일 정산 불일치 감지 및 리포트 발송, (3) 비개발자가 조건을 조정해야 하는 비즈니스 규칙. 이 세 가지 중 하나라도 해당되면 n8n이다. Slack webhook 연동 하나를 Actions 커스텀 액션으로 만들려면 최소 30분이 걸리지만 n8n에서는 3분이다. 이 속도 차이가 누적되면 팀의 자동화 실행력 자체가 달라진다.

분리선이 흔들리는 구간: "배포 후 외부 연동"을 어떻게 처리할 것인가

분리선이 모호해지는 가장 흔한 케이스는 "배포 후 후속 작업"이다. 배포 성공 시 Slack 알림은 어디에? 배포 완료 후 외부 캐시 퍼지는? 우리가 내린 최종 기준은 단순하다: "배포 실패 여부와 묶여야 하는가?" 성공/실패에 따라 알림이 달라져야 하고, 배포 컨텍스트—커밋 SHA, 브랜치명, 배포자—를 메시지에 담아야 한다면 Actions에 넣는다.

반면, "배포와 무관하게 매시간 서비스 헬스를 체크하고 Slack에 올리는" 작업은 n8n이다. 코드 변경 없이도 계속 실행되어야 하고, 임계값 조정을 비개발자가 해야 하기 때문이다. 우리는 배포 알림은 Actions, 정기 모니터링 알림은 n8n으로 분리했다. 처음에는 "둘 다 Slack 알림인데 굳이 나눠야 해?"라고 생각했는데, 분리하고 나서 Actions 워크플로우 파일이 약 30% 짧아지고, n8n에서 불필요한 git 이벤트 폴링 노드가 제거됐다. 두 도구 모두 더 읽기 쉬워졌다.

분리선 없이 운영했을 때의 실제 비용: 수치로 보기

"GitHub Actions로 다 하자"를 선택했을 때의 실제 비용을 정리하면: 스케줄 작업 20개를 Actions에 넣었을 때 월 실행 시간이 약 1,200분 소비됐다. GitHub 무료 플랜(2,000분/월)의 60%를 코드 배포와 무관한 스케줄 작업이 잡아먹은 것이다. n8n으로 이관 후 Actions 사용량은 280분으로 줄었다. 단순 비용 절감을 넘어서, 스케줄 작업 로그가 Actions 실행 로그에 섞이면서 실제 배포 관련 로그를 찾는 데 걸리는 시간이 평균 4분에서 12분으로 늘었다. 디버깅 비용이 3배가 된 셈이다.

반대로 "n8n으로 다 하자"의 실패도 직접 겪었다. n8n에서 결제 서비스 재시작 스크립트를 실행하는 워크플로우를 만들었는데, 누군가 노드를 수정해도 git 이력에 남지 않았다. 장애 발생 후 "워크플로우가 바뀐 게 원인이었는데 언제, 누가 바꿨는지 모름" 상황이 됐다. n8n Enterprise에는 workflow versioning이 있지만 우리가 사용하는 Self-hosted Community 버전에는 없다. 이 경험 이후 원칙을 세웠다: 코드 이벤트와 결합되거나 감사 이력이 필요한 작업은 반드시 git이 관리하는 Actions에 있어야 한다.

지금 바로 적용할 분리 체크리스트

이 분리선을 처음 그을 때 우리 팀이 사용한 체크리스트다. 자동화 작업 하나를 놓고 아래 질문에 답하면 된다.

→ GitHub Actions가 맞는 경우

• 이 작업은 코드 커밋/PR/태그에 의해 트리거되는가?
• 실패 시 배포 파이프라인 전체를 멈춰야 하는가?
• 나중에 "언제, 누가, 어떤 버전으로 실행했는지" 추적이 필요한가?
• 비개발자가 수정할 이유가 없고, 코드 리뷰가 필요한가?

→ n8n이 맞는 경우

• 이 작업은 시간 기반 스케줄이나 외부 웹훅으로 트리거되는가?
• 비개발자(정산팀, 운영팀)가 조건을 직접 수정해야 하는가?
• GitHub 저장소와 논리적 연관성이 없는가?
• 여러 외부 SaaS를 연결하는 것이 주 목적인가?

경계가 여전히 모호하다면 이 하나로 결론낸다: "이 작업이 잘못됐을 때 git blame으로 원인을 추적해야 하는가?" Yes면 Actions, No면 n8n이다. 지금 당장 현재 Actions 워크플로우 파일을 열고 schedule: 트리거로 실행되는 것 중 코드 변경과 무관한 항목을 목록화하라. 그 목록이 n8n 이관 1순위다. 우리는 이 작업을 한 번의 팀 미팅(45분) 안에 끝냈고, 이관에 걸린 총 시간은 이틀이었다.