코딩 에이전트 감독의 핵심 질문은 이제 “코드를 잘 짜는가”가 아니다. 더 중요한 질문은 “에이전트가 어디까지 스스로 움직이고, 어느 지점에서 사람이 개입하는가”다.
요즘 코딩 에이전트는 파일 수정, 패키지 설치, 테스트 실행, 브랜치 생성, PR 작성까지 수행할 수 있다. 자동 수락 설정까지 켜면 개발자 권한으로 거의 직접 행동한다.1 따라서 안전장치는 모델 성능 평가가 아니라 워크플로 설계 문제로 봐야 한다.
감독은 “누가 시작하고, 누가 승인하는가”에서 출발한다
PR 워크플로에서 가장 먼저 볼 축은 두 가지다. 누가 작업을 시작했는가, 그리고 누가 최종 병합을 승인했는가다.
최근 연구는 29,585개 PR 생명주기를 분석하며 Initiator x Approver 분류법을 사용했다. 이 관점은 AI 코딩 도구를 크게 Collaborator형과 Assistant형으로 나눈다.2
Collaborator형 도구는 에이전트가 브랜치를 열고 PR 작업을 진행하는 비중이 높다. 반대로 Assistant형 도구는 사람이 작업 방향을 주도하고, 에이전트는 제한된 지원을 제공한다.2 즉 같은 “AI 코딩 도구”라도 감독 방식은 도구가 워크플로에서 어떤 역할을 맡는지에 따라 달라져야 한다.
병합 권한이 사람에게 있어도 중간 과정은 남는다
연구에서 OpenAI, Copilot, Devin, Cursor, Claude Code의 병합 거버넌스는 대부분 인간 중심으로 유지됐다.2 Collaborator형 워크플로에서도 PR의 96% 이상이 에이전트에 의해 시작됐지만, 최종 병합 권한은 거의 전적으로 사람에게 남아 있었다.2
이 결과는 한편으로 안심할 만하다. 에이전트가 작업을 시작해도 마지막 승인자는 대체로 인간이기 때문이다. 하지만 “사람이 병합한다”는 사실만으로 감독이 충분하다고 보기는 어렵다.
위험은 병합 버튼을 누르기 전 과정에서 생긴다. 에이전트가 어떤 파일을 바꿨는지, 어떤 의존성을 추가했는지, 어떤 테스트를 실행했는지, 어떤 입력을 근거로 판단했는지가 이미 PR의 방향을 만든다. 최종 승인만 통제하면, 승인자는 에이전트가 만들어 놓은 흐름을 뒤늦게 검토하는 위치에 놓인다.
안전장치는 권한 통제와 관찰 가능성을 함께 요구한다
코딩 에이전트 감독은 에이전트를 단순한 자동완성 도구가 아니라 “행동 주체”로 보는 데서 시작해야 한다. 최소 권한, 승인 게이트, 감사 로그가 기본 안전장치가 되는 이유다.
특히 외부 문서, 이슈, PR 댓글, README는 에이전트에게 지시문처럼 작동할 수 있다.1 따라서 에이전트가 실행할 수 있는 명령뿐 아니라, 에이전트가 읽고 따를 수 있는 입력도 신뢰 경계 안에서 관리해야 한다.
실무적으로는 다음 세 가지를 확인해야 한다.
에이전트가 작업을 시작할 수 있는 범위는 어디까지인가
최종 병합 승인자는 사람으로 유지되는가
중간 행동과 근거가 감사 가능한 형태로 남는가
결론은 명확하다. 코딩 에이전트의 안전성은 “좋은 모델을 쓰는가”보다 “감독 가능한 워크플로를 갖췄는가”에 더 크게 달려 있다. 누가 시작했는지, 누가 승인했는지, 그 사이의 행동이 기록됐는지를 보면 안전장치가 실제로 작동하는지 판단할 수 있다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.