n8n 과 AI 에이전트로 에러 자동 수정, 라벨로 넘기는 법

사람이 몇 안 되는 팀에서 서비스를 여러 개 돌리면, 에러 알림과 지표 확인만으로 하루가 끝나기 쉬워요. 이 글은 그 반복 일을 AI 코딩 에이전트에게 나눠 맡기되, 사람이 놓치지 않고 언제든 끼어들 수 있게 흐름을 짜는 방법을 정리해요.

혹시 이런 고민 있으신가요?

• 에러 추적 도구에 알림이 쌓이는데, 들여다볼 시간이 없어 같은 에러가 며칠씩 남아 있어요.
• AI 에이전트에게 코드를 맡기고 싶지만, 무엇을 어디까지 하게 둘지 기준이 없어 불안해요.
• 자동화를 붙였더니 무엇이 끝났고 무엇이 남았는지 오히려 더 안 보여요.

이 글을 읽으면

• 에러와 일일 지표를 GitHub 이슈 하나로 모으는 파이프라인을 설계할 수 있어요.
• 시간대별로 역할이 다른 에이전트를 두고, 라벨로 일을 넘기는 규칙을 만들 수 있어요.
• 에이전트가 멈추고 사람에게 넘길 조건과, 모든 수정이 PR 과 CI 를 거치게 하는 이유를 설명할 수 있어요.

1단계. 할 일의 입구를 GitHub 이슈 하나로 모으기

먼저 용어부터 짚을게요. AX 는 AI 전환(AI Transformation)의 줄임말로, 사람이 하던 일의 흐름에 AI 를 끼워 넣어 일하는 방식 자체를 바꾸는 것을 말해요. n8n 은 여러 도구를 블록처럼 이어 "이 일이 생기면 저 일을 해라" 를 만드는 워크플로 자동화 도구예요. 에러 추적 도구는 서비스에서 난 예외를 모아 보여 주는 도구로, 저희는 Sentry 와 호환되는 GlitchTip 을 써요.

에이전트가 일을 하려면 할 일이 한곳에 있어야 해요. 알림이 채팅방, 메일, 대시보드에 흩어져 있으면 에이전트도 사람도 무엇을 먼저 할지 몰라요. 그래서 입구를 GitHub 이슈 하나로 정했어요. 이슈는 에이전트가 읽기 쉽고, 닫히는 순간 기록이 남고, PR 과 바로 이어져요.

저희 n8n 은 두 가지 일을 해요.

• 매일 한 번 일일 리포트 이슈를 열어요. 지표와 에러를 모아 할 일 목록으로 정리한 이슈예요.
• 10분마다 에러 추적 도구의 에러를 GitHub 이슈로 옮겨요. 에러 하나가 이슈 하나가 되고, 전용 라벨이 붙어요.

리포트의 숫자는 비즈니스 대시보드 도구인 Metabase 의 카드에서 가져와요. 카드는 저장해 둔 질문 하나예요. 대시보드와 리포트가 같은 카드를 읽으니 두 숫자가 어긋날 일이 없어요. 밖으로 보내는 것도 집계된 숫자뿐이에요.

리포트 이슈 본문은 에이전트가 읽기 좋게 칸을 나눠요. 아래는 그 모양을 일반화한 예시예요.

## 어제 지표(서비스별 방문, 퍼널 단계별 수, 새 에러 수) ## 오늘 할 일- [ ] 결제 화면에서 반복되는 에러를 고친다- [ ] 업로드 실패 버그를 고친다 ## 관망- 방문이 줄었지만 하루치라 판단을 미룬다 ## 개선 제안- 첫 화면의 시작 버튼 문구를 바꿔 본다

체크박스가 있는 줄만 일이 돼요. "관망" 칸에는 일부러 체크박스를 두지 않아요. 지켜보기만 할 것을 에이전트가 일로 오해하지 않게 하려는 장치예요.

2단계. 시간대마다 역할이 다른 에이전트 두기

입구가 생겼으면 일할 쪽을 정해요. 여기서 에이전트는 저장소를 읽고, 코드를 고치고, 테스트를 돌리고, PR 을 여는 AI 코딩 도구를 말해요. 정해진 시각에 저절로 실행되게 예약해 두는 것이 핵심이에요.

에이전트 하나에 모든 일을 맡기지 않고, 시간대마다 역할을 하나씩 줬어요. 역할이 좁을수록 지시가 짧아지고, 결과를 확인하기도 쉬워요.

순서에도 이유가 있어요. 밤에 고친 버그는 새벽에 도는 배포에 실려 아침에는 운영에 나가 있어요. 오전에 만든 기능은 다음 날 새벽에 나가요. 사람이 출근해서 보는 것은 이미 배포된 결과와, 에이전트가 넘긴 일뿐이에요.

입구는 이슈 하나, 역할은 시간대마다 하나

배포 담당은 코드를 고치지 않아요. 기본 브랜치에 새로 머지된 것이 없으면 아무것도 하지 않고 끝나요. 이 조건 덕분에 매일 새벽 도는 일이 헛배포를 만들지 않아요.

3단계. 라벨로 일을 넘기고 멈춤 조건 정하기

에이전트끼리, 그리고 에이전트와 사람 사이에는 대화 창이 없어요. 대신 라벨을 신호로 써요. 라벨은 이슈에 붙이는 이름표예요. 누가 그 이슈를 가져갈지, 가져가지 말지를 라벨 하나로 정해요.

아래는 저희가 쓰는 라벨을 여러분이 그대로 가져다 쓸 수 있게 일반화한 표예요.

뒤의 세 라벨이 멈춤 조건이에요. 에이전트가 판단할 수 있는 것과 판단하면 안 되는 것의 경계를 라벨로 적어 둔 셈이에요. 저희 규칙은 두 가지를 반드시 사람에게 넘기게 해요. 데이터를 지우거나 돈을 쓰는 단계, 그리고 선택지에 따라 다른 제품이 되는 결정이에요. 데이터베이스에서도 사람이 요청하지 않은 삭제나 조건 없는 변경은 실행하지 않아요.

반대로 사람에게 묻지 않고 가는 일도 정해 두었어요. 데이터베이스 마이그레이션이 필요한 수정은 마이그레이션 규칙을 지키는 한 그대로 진행해요. 마이그레이션은 표의 구조를 바꾸는 작업을 파일로 남겨 순서대로 적용하는 방식이에요. 멈출 이유가 없는 일에서 멈추면 에이전트가 할 일이 사람 책상으로 돌아와 버려요.

사람에게 넘길 정도는 아니지만 판단이 필요한 경우도 있어요. 이때는 에이전트가 방어할 수 있는 쪽을 고르고 계속하되, 결정 메모를 남기게 했어요. 메모는 네 칸으로 정해져 있어요. 결정, 근거, 되돌리는 법, 영향받는 파일이에요. 사람은 이 메모만 읽고 동의하지 않는 결정을 뒤집어요.

waiting 이 왜 필요한지는 실제 사례가 잘 보여 줘요. 한 서비스에서 리포트가 첫 화면의 주된 흐름이 아닌 다른 흐름의 숫자만 세고 있었어요. 방문이 있어도 그 단계가 0으로 나오니, 리포트는 그 버튼을 키우자는 제안을 되풀이했어요. 고칠 곳은 버튼이 아니라 측정이었어요. 그래서 리포트가 세는 퍼널을 실제 주된 흐름으로 바꿨어요. 근거가 약한 제안을 바로 만들지 않고 보류하는 칸이 있어야, 이런 잘못된 측정을 사람이 발견할 시간이 생겨요.

4단계. 모든 수정을 PR 과 CI 로 통과시키기

에이전트가 고친 코드는 기본 브랜치로 바로 들어가지 않아요. 모든 수정은 PR(Pull Request, 변경을 합치기 전에 검토받는 요청)을 거치고, CI(지속적 통합, 변경마다 테스트와 검사를 자동으로 돌리는 것)가 통과해야 머지돼요.

흐름은 이렇게 짰어요.

1. 리포트 이슈는 닫지 않고 둬요. 에이전트가 맡는 항목마다 리포트의 하위 이슈를 만들어요.
2. 버그는 수정용 브랜치에, 기능은 기능용 브랜치에서 작업해요. 브랜치 이름에 하위 이슈 번호를 넣어 어느 일인지 바로 보이게 해요.
3. PR 본문이 하위 이슈를 닫도록 연결하고, CI 가 통과하면 머지해요. 머지와 함께 하위 이슈가 닫혀요.

이렇게 하면 리포트 이슈의 하위 이슈 목록이 그대로 진행판이 돼요. 닫힌 것은 끝난 일, 열린 것은 남은 일이에요. 자동화를 붙였는데 무엇이 끝났는지 안 보이는 문제가 이 한 가지 규칙으로 풀려요.

모든 수정은 하위 이슈에서 시작해 머지로 닫혀요

PR 을 거치게 하는 이유는 세 가지예요. 첫째, 기본 브랜치에 직접 커밋하는 길을 아예 없애면 에이전트가 실수해도 운영 코드가 바로 망가지지 않아요. 저희는 이 규칙을 지시문에만 두지 않고, 기본 브랜치에서의 커밋과 강제 푸시를 막는 훅으로도 걸어 뒀어요. 훅은 도구가 실행되기 직전에 자동으로 끼어드는 검사예요. 둘째, CI 는 에이전트가 "고쳤어요" 라고 말하는 것과 실제로 고쳐진 것을 구분해 줘요. 셋째, PR 은 나중에 사람이 "왜 이렇게 바뀌었지" 를 물을 때 답이 남는 자리예요.

누가 푸시하는지도 고정했어요. 한 에이전트가 일을 여러 작업자로 나눌 때, 작업자는 커밋만 하고 푸시하지 않아요. 작업을 맡긴 쪽이 전부 끝난 뒤에 푸시해요. 두 에이전트가 한 브랜치를 두고 경쟁하는 일을 막기 위해서예요. 푸시 전에는 바뀐 패키지마다 타입 검사, 린트, 포맷 검사를 통과해야 해요.

5단계. 배포는 결과가 확인될 때만 기록하기

마지막은 배포예요. 머지는 배포가 아니에요. 저희는 기본 브랜치에 머지해도 아무것도 배포되지 않게 해 두었고, 배포는 사람이 배포하라고 말할 때와 배포 담당 에이전트가 돌 때만 시작돼요.

배포 워크플로는 버튼 하나로 도는 수동 실행 방식이에요. 순서는 이래요.

1. 다음 버전을 계산해요. 형식은 서울 날짜와 그날의 순번이에요. 같은 날 두 번째 배포면 순번이 2가 돼요.
2. 이미지를 빌드하고 간단한 동작 검사를 해요.
3. 배포를 요청하고, 끝날 때까지 기다린 뒤 공개 주소가 응답하는지 확인해요.
4. 여기까지 성공했을 때만 git 태그와 GitHub 릴리스를 만들어요. 릴리스 본문은 직전 릴리스 뒤에 머지된 PR 목록이에요.
5. 결과를 채팅 채널로 알려요. 실패하면 실패한 단계와 로그를 붙여요.

태그가 배포를 시작하는 게 아니라, 태그가 배포의 결과가 되게 한 거예요. 그래서 모든 버전 번호는 실제로 운영에서 돈 것만 가리켜요. 에이전트든 사람이든 태그나 릴리스를 손으로 만들지 않아요.

되돌리기도 같은 버튼에 있어요. 입력칸에 이전 버전을 넣으면 빌드 없이 그 버전의 이미지로 다시 배포해요. 다만 이미지 저장소에는 최근 두 버전만 남겨서, 빌드 없이 돌아갈 수 있는 것은 직전 버전까지예요.

자주 묻는 질문

Q1. 에이전트가 밤새 잘못 고치면 어떻게 하나요?

잘못된 수정도 PR 과 CI 를 거쳐야 기본 브랜치에 들어가고, 배포되더라도 릴리스 단위로 남아요. 문제가 보이면 이전 버전으로 되돌리는 버튼을 쓰고, 해당 하위 이슈에 waiting 이나 needs-human 을 붙여 다시 가져가지 못하게 하면 돼요.

Q2. 꼭 n8n 이어야 하나요?

아니에요. 필요한 것은 "정해진 시각에 지표를 모아 이슈를 연다" 와 "에러를 이슈로 옮긴다" 두 가지예요. GitHub Actions 의 예약 실행이나 다른 자동화 도구로도 같은 모양을 만들 수 있어요. 인증 정보가 이미 모여 있는 도구에서 시작하는 게 가장 덜 번거로워요.

Q3. 가격이나 로그인처럼 민감한 일은 왜 아예 빼나요?

잘못됐을 때의 비용이 코드 버그와 다르기 때문이에요. 가격은 사용자와의 약속이고, 로그인과 결제는 한 번 틀리면 되돌려도 피해가 남아요. 이런 일은 에이전트가 초안까지만 만들게 하거나 아예 라벨로 사람에게 넘기는 편이 안전해요.

정리

• 에러와 일일 지표를 GitHub 이슈 하나로 모으고, 체크박스가 있는 줄만 일로 삼아요.
• 시간대마다 역할이 하나뿐인 에이전트를 두고, 고치기, 배포, 기능 순서로 이어지게 배치해요.
• 라벨로 일을 넘기고, 보류와 사람 필요 라벨로 멈춤 조건을 적어 둬요.
• 모든 수정은 하위 이슈, 브랜치, PR, CI 를 거치고, 머지가 하위 이슈를 닫아 진행판이 되게 해요.
• 배포는 공개 주소가 응답한 뒤에만 버전과 릴리스로 남겨요.

에이전트에게 많이 맡기는 것보다, 에이전트가 멈출 자리를 먼저 정해 두는 쪽이 오래 가는 자동화를 만들어요.