AI 에이전트 이슈 자동 처리 구축기

이슈 링크 세 개를 채팅창에 붙여 넣고 “이것들 처리해줘” 라고 적은 뒤, 나는 자리를 비웠다. 잠시 뒤 돌아와 이슈 트래커를 열었더니 세 건 각각에 처리 결과를 설명하는 코멘트와 테스트 서버 배포 경로가 달려 있었다. 두 건은 검증만 하면 닫아도 될 상태였고, 한 건은 요청 자체가 모호해 판단을 보류한 채 그 사유가 적혀 있었다.

이 글은 그 파이프라인을 어떻게 짰고, 어디까지 위임이 되었으며, 어디서부터는 여전히 사람이 필요한지에 대한 기록이다.

이슈 하나를 닫는다는 것

이슈 하나를 처리한다고 할 때 우리는 흔히 ‘코드를 고치는 일’ 만 떠올린다. 그러나 실제로 이슈가 닫히기까지의 경로는 길다. 이슈를 읽고 의도를 해석하고, 코드를 고치고, 빌드하고, 어딘가에 배포하고, 동작을 확인하고, 결과를 보고하고, 추적 가능하도록 기록을 남긴다. 코드 수정은 이 사슬의 한 마디일 뿐이다.

자동화가 어려웠던 이유도 여기에 있다. 사슬의 마디마다 다른 시스템이 끼어든다. 이슈 트래커, 빌드 도구, 배포 서버, 메신저 알림. 사람은 이 사이를 손으로 오가며 맥락을 이어붙인다. 그 이어붙이는 노동이 사실상 이슈 처리의 본체다.

API 를 스킬로 굳히다

시작은 사내 이슈 보고 시스템의 API 를 확보하는 일이었다. 이슈를 조회하고, 상태를 바꾸고, 코멘트를 다는 엔드포인트를 추렸다. 인증 정보는 코드에 박지 않고 환경 변수로 분리했다. 위임의 첫 전제는 자격 증명을 안전하게 다루는 것이고, 이 분리는 나중에 처리 과정을 CI 로 옮길 때도 그대로 쓰인다.

그 위에 스킬을 하나 얹었다. 하는 일은 단순하다. 이슈 링크를 받으면 내용을 분석하고, 처리한 뒤 완료 큐에 등록하고, 이슈에 남길 코멘트를 작성해 둔다.

# issue-handler skill — one issue link in, a structured outcome out
1. fetch issue by link (analyze title / body / labels)
2. resolve the change (code / config / investigation)
3. enqueue to the done-queue
4. draft a result comment on the issue

핵심은 이 스킬이 ‘코멘트를 자동으로 단다’ 가 아니라, ‘처리 결과를 구조화된 형태로 남긴다’ 는 데 있다. 사람이 나중에 그 코멘트만 훑어도 무엇을 왜 그렇게 처리했는지 따라갈 수 있어야 한다. 코멘트는 결과물이자 감사 추적(audit trail)이다.

큐 단위로, 워크트리로 격리한다

여러 이슈를 한꺼번에 던지면 각 이슈는 서로를 오염시키지 않아야 한다. 그래서 이슈 처리를 요청하면 건마다 별도 브랜치와 git 워크트리로 작업을 분리한다. 큐에 들어온 건들이 각자의 워크트리에서 독립적으로 처리되고, 한 건의 실패가 다른 건으로 번지지 않는다.

이 격리는 보안 쪽 사고방식과 닮아 있다. 작업 단위를 샌드박스로 가두고, 경계를 넘는 영향을 차단한다. 이슈 A 의 변경이 이슈 B 의 빌드에 끼어들 여지를 구조적으로 없애는 것이다.

완료는 배포까지다

처리가 끝났다고 곧장 이슈를 닫지 않는다. 완료 보고 시점에 빌드된 결과가 테스트 서버로 자동 배포된다. 그리고 검증은 내가 한다. 배포된 화면을 직접 열어 요청이 의도대로 반영됐는지 확인하는 단계는 의도적으로 사람에게 남겨두었다.

내 확인이 끝나면 그때 완료 처리를 명령한다. 빌드·배포 스크립트가 돌고, 배포가 끝나면 구글 챗 업무 톡방으로 웹훅 알림이 전달된다. 마지막으로 이슈 처리 스킬에게 완료를 지시하면, 각 이슈에 처리 결과 코멘트와 배포 경로 코멘트가 분리되어 등록된다. 무엇을 했는지와 어디에 올라갔는지를 따로 적어, 나중에 추적할 때 섞이지 않게 했다.

단순하지 않은 건, 직접 확인하게 한다

처음 수동으로 굴려본 첫 묶음은 세 건이었다. 그중 두 건은 정확히 처리됐고, 한 건은 요청 자체가 모호해 판단을 보류했다. 모호한 요청을 억지로 처리하지 않고 사유를 남긴 채 멈춘 것은, 오히려 신뢰할 만한 행동이다.

이어서 들어온 두 건은 결이 달랐다. 코드 한 줄을 고치는 단순 처리로는 끝나지 않고, 실제 화면 동작을 확인해야 검증되는 건이었다. 여기서 Playwright 를 붙였다. 브라우저를 자동으로 띄워 시나리오를 재현하고, 기대한 동작이 나오는지 스스로 검증하는 과정을 처리 흐름에 끼워 넣었다. 결국 그 건도 해결까지 도달했다.

그리고 그 해결 방식을 문서로 정리해 다시 스킬 자산으로 등록했다. 한 번 푼 문제를 다음에 또 손으로 풀지 않기 위해서다. 이 부분이 중요하다. 자동화는 한 번의 처리가 아니라, 처리의 패턴이 축적될 때 비로소 복리로 작동한다.

마무리

지금 이 파이프라인은 아직 수동 검토 단계에 있다. 모든 배포는 내 눈을 거치고, 완료 명령도 내가 내린다. 그러나 한 묶음을 굴려본 것만으로도 다음 단계의 윤곽이 보인다.

검증의 신뢰도가 쌓이면 사람이 개입하는 지점은 점점 뒤로 밀린다. 이슈 처리 현황을 보여주는 대시보드를 붙이고, 일정 단위의 이슈를 청크로 묶어 자동 처리하게 하면, 관리자의 역할은 ‘모든 이슈를 처리하는 사람’ 에서 ‘잘못 처리됐거나 다른 방향이 필요한 이슈만 골라내는 사람’ 으로 바뀐다. 전부를 보는 일에서, 예외만 보는 일로.

이것이 자동화의 진짜 방향이라고 생각한다. 사람을 사슬에서 들어내는 것이 아니라, 사람이 서 있는 자리를 실행에서 감독으로 옮기는 것이다. 이슈 링크를 던지고 결과 코멘트만 확인하는 지금의 작은 루프는, 그 이동의 첫 칸이다.