AI 코딩 에이전트를 팀에 도입하려는 논의가 구체화될수록, 한 가지 장면이 반복적으로 등장한다. 개발자가 퇴근한 뒤에도 에이전트가 이슈를 처리하고, 출근하면 PR이 쌓여 있는 그림이다. 실제로 이런 방식으로 작동하는 도구들이 이미 존재하고, 기술적으로는 가능한 시나리오다.
문제는 이 그림이 절반만 맞다는 점이다. 에이전트가 PR을 만드는 것과, 그 PR이 프로덕션에 안전하게 합류할 수 있는 상태인지를 확인하는 것은 전혀 다른 일이다. 전자는 자동화할 수 있지만 후자는 아직 그렇지 않다.
에이전트가 실제로 하는 일과 하지 않는 일
AI 코딩 에이전트의 야간 실행을 지원하는 오케스트레이터 도구들은 대체로 비슷한 방식으로 작동한다. GitHub, Jira, Linear 같은 이슈 트래커에서 작업을 받아 에이전트에게 넘기고, 각 작업을 독립된 작업 디렉토리(worktree)에서 실행하며, 사전에 정의된 테스트가 통과하면 드래프트 PR을 생성한다.
여기서 '테스트 통과'의 의미를 정확히 이해해야 한다. 에이전트가 실행하는 검사는 팀이 미리 설정해 둔 것, 즉 npm test나 빌드 스크립트처럼 이미 존재하는 자동화된 검증에 한정된다. 테스트가 실패하면 그 결과가 에이전트에게 피드백으로 돌아가고 재시도가 일어나기도 하지만, 이것은 반복 실행이지 이해를 바탕으로 한 판단이 아니다.
에이전트가 하지 않는 것도 명확하다. 코드 변경이 기존 아키텍처 결정과 충돌하는지, 새로 추가된 의존성이 라이선스 정책이나 보안 기준을 만족하는지, 생성된 코드가 팀의 코딩 컨벤션을 따르는지는 자동화 검사의 범위 밖이다. 이 판단들은 PR을 검수하는 개발자에게 집중된다.
야간 실행 이후, 아침에 실제로 일어나는 일
에이전트가 밤새 4개의 PR을 만들었다고 가정하자. 각각 GitHub 이슈 처리, 의존성 업데이트, 불안정한 테스트 수정, 새 기능 작업이었다고 하면, 이 PR들의 성격은 제각각이다.
의존성 업데이트 PR은 테스트가 통과했더라도 실제로 어떤 패키지가 어떤 버전으로 바뀌었는지, 그 패키지에 알려진 취약점이 없는지, 변경이 간접 의존성까지 파급되지는 않는지를 사람이 확인해야 한다. 불안정한 테스트를 수정한 PR은 에이전트가 테스트 조건 자체를 완화하는 방식으로 문제를 '해결'하지 않았는지 살펴봐야 한다. 이런 패턴은 테스트 통과 기준만으로는 걸러지지 않는다.
여기서 팀이 미리 답해두지 않으면 아침마다 충돌이 생기는 질문이 있다. 이 PR들을 누가 검수하는가, 얼마나 빨리 해야 하는가, 검수를 완료하지 않은 채 다음 작업이 같은 코드베이스 위에서 시작되면 어떻게 할 것인가. 도구가 이 질문에 대신 답해주지는 않는다.
오버헤드가 늘어나는 세 가지 경로
팀 업무 흐름을 바꾸지 않고 AI 코딩 에이전트를 도입할 때 실제로 오버헤드가 늘어나는 경로는 크게 세 가지다.
첫째, PR 검수 부담의 비대칭적 집중. 에이전트는 작업을 병렬로 처리할 수 있지만 검수는 그렇지 않다. 특정 도메인에 익숙한 개발자 한 명이 여러 PR의 실질적인 검수자가 되는 상황이 생기기 쉽다. 이 병목은 에이전트가 많이 돌수록 악화된다.
둘째, 실패 대응의 책임 공백. 야간에 빌드가 실패하고 에이전트가 재시도를 반복하다 멈췄을 때, 다음 날 아침에 그 실패를 분석하고 방향을 정하는 것은 사람의 일이다. 누가 그 역할을 맡는지, 그 사람의 다른 업무에서 시간을 어떻게 확보할 것인지를 미리 정해두지 않으면 실패 분석이 계속 미뤄진다.
셋째, 보안 검토 기준의 부재. 에이전트가 생성한 코드에 외부 API 호출이 추가되거나 환경 변수 처리 방식이 달라졌을 때, 이것을 보안 관점에서 검토하는 기준이 PR 리뷰 절차에 포함되어 있지 않으면 빠르게 승인 압박이 생긴다. PR이 많이 쌓일수록 각각에 충분한 시간을 쓰기 어려워진다.
재설계 전에 먼저 정해야 할 것들
AI 코딩 에이전트 도입을 탐색하는 단계에서, 도구 선택보다 먼저 답해야 하는 질문들이 있다.
작업 유형 분류부터 시작한다. 에이전트에게 넘길 작업과 넘기지 않을 작업을 구분하는 기준이 필요하다. 의존성 업데이트나 포맷 수정처럼 변경 범위가 예측 가능한 작업과, 아키텍처 판단이 개입되는 작업은 같은 방식으로 다룰 수 없다. 이 분류가 없으면 에이전트는 팀이 감당하기 어려운 PR을 생성하는 방향으로도 작동한다.
PR 검수의 소유권을 명확히 한다. 에이전트가 생성한 PR과 개발자가 직접 작성한 PR의 검수 기준과 담당자를 같은 방식으로 정해둘 것인지, 별도로 가져갈 것인지를 결정해야 한다. 야간에 생성된 PR은 다음 날 오전 특정 시간 전에 검수해야 하는 SLA를 두는 팀도 있다.
실패 시나리오의 대응 절차를 도구 도입 전에 만든다. 빌드 실패, 에이전트 무한 재시도, 예상치 못한 외부 API 호출 같은 상황이 발생했을 때 누가 알림을 받고 어떤 순서로 대응하는지를 워크플로우에 명시한다. 이것은 에이전트가 많이 실행될수록 더 자주 필요해진다.
보안 검토 기준을 PR 체크리스트에 포함한다. 에이전트가 생성한 코드에 대해 새로운 외부 의존성 추가 여부, 인증 관련 코드 변경 여부, 민감한 데이터 처리 방식 변경 여부를 검수자가 확인하는 항목으로 명시하는 것이 낫다. 이 기준이 없으면 검수자의 판단이 매번 달라진다.
현재 확인할 수 있는 것과 아직 불확실한 것
AI 코딩 에이전트의 야간 실행이 기술적으로 가능하다는 것, 그리고 테스트 통과 여부로 자동 게이팅을 걸 수 있다는 것은 현재 확인 가능한 사실이다.
반면 에이전트가 생성한 코드가 평균적으로 어느 수준의 검수 시간을 요구하는지, 어떤 유형의 작업에서 재작업 비율이 높은지는 팀마다 다를 수밖에 없고, 지금은 각 팀이 직접 측정해야 알 수 있다. 에이전트 도입이 실제로 팀의 총 작업 시간을 줄이는지, 아니면 작업의 성격만 바꾸는지도 운용 결과를 보기 전에는 단정하기 어렵다.
도구가 '검수 없이 아무것도 병합되지 않는다'고 명시하더라도, 그것은 기술적 차단 장치의 존재를 말하는 것이지 검수의 질을 보장하는 것이 아니다. 검수의 질은 결국 검수자가 가진 시간과 맥락에 달려 있다.
