코딩 에이전트에게 필요한 것은 더 많은 자율성이 아니라 관리자입니다

유능한 에이전트를 당신의 레포지토리(repo)에 투입합니다. 20분 동안은 정말 인상적입니다. 코드베이스를 읽고, 계획을 세우고, 작성하고, 테스트하고, 반복합니다. 그러다 21분쯤 되었을 때 이런 일이 발생합니다:

  // task: 이메일 클라이언트에 재시도 로직 추가
+ // ...또한 DI 컨테이너 등록을 다시 작성함
+ // ...IEmailGateway를 발명함 (다른 어디에도 존재하지 않음)
...

이제 브랜치(branch)는 직접 작업하는 것보다 리뷰하는 데 더 많은 비용이 드는 상태가 되었습니다. 모델이 멍청했던 것이 아닙니다. 관리되지 않았을(unmanaged) 뿐입니다.

우리는 지난 2년 동안 더 긴 컨텍스트(context), 더 나은 도구 사용(tool use), 다단계 계획(multi-step planning), 병렬 실행(parallel execution) 등 코딩 에이전트를 더 유능하게 만드는 데 시간을 보냈습니다. 우리가 만들지 못한 것, 그리고 이제 실제 병목 현상(bottleneck)이 된 것은 그 모든 능력을 실제 코드베이스에 안전하게 투입할 수 있게 만드는 계층입니다. 범위 경계(Scope boundaries), 준수 확인(Conformance checks), 격리된 리뷰(Isolated review). 인간이 업무를 수행할 때 당연하게 여기는 규율(discipline) 말입니다.

우리에게는 에이전트가 있습니다. 하지만 그들을 위한 운영 프로토콜(operating protocol)은 없습니다.

아무도 가격을 책정하지 않은 간극

대부분의 "자율 코딩(autonomous coding)" 데모가 작동하는 이유는 작업이 작고, 레포지토리가 깨끗하며, 영향 범위(blast radius)가 제로이기 때문입니다. 이 세 가지 중 어느 하나라도 규모가 커지면 동일한 에이전트가 부채(liability)가 됩니다. 에이전트가 더 멍청해져서가 아니라, 에이전트의 출력물과 main 사이에 '희망' 외에는 아무것도 없었기 때문입니다.

인간 주니어 엔지니어 역시 빠르고 지치지 않습니다. 우리는 그들에게 첫날부터 운영 환경(prod) 접근 권한을 주고 떠나지 않습니다. 우리는 그들에게 범위를 지정해주고, PR(Pull Request)을 리뷰하며, 선택 사항이 아닌 아키텍처 규칙을 강제하고, 시스템이 이를 포착하도록 설계되었기에 편차(drift)를 조기에 잡아냅니다. 이것은 관료주의가 아닙니다. 인원수(headcount)보다 더 빠르게 신뢰를 확장하는 방법입니다.

에이전트에게도 똑같은 것이 필요합니다. 능력은 여기에 있습니다. 제어(control)는 여기에 없습니다.

규율 계층(discipline layer)이 실제로 하는 일

그것이 바로 AOP — 에이전트 운영 프로토콜(Agent Operating Protocol) — 이 메우고자 하는 간극입니다. 모델을 더 똑똑하게 만드는 것이 아니라, 아직 완전히 신뢰할 수 없는 기여자에게 부과할 법한 규율로 모델을 감싸는 것입니다.

• 범위(Scope)의 강제. 에이전트가 무엇을 읽고, 만지고, 변경할 수 있는지는 사전에 정의되며 검증(checked) 됩니다. 위반 사항은 3번의 커밋이 지난 후에 발견되는 것이 아니라 즉시 포착됩니다.
• 실행 가능한 준수(Conformance). 당신의 아키텍처는 에이전트가 무시해도 되는 위키(wiki) 페이지가 아닙니다. 시스템을 정의하는 규칙들은 테스트 스위트(test suite)와 마찬가지로 에이전트의 출력물에 대해 실행됩니다.
• 격리된 검토(Review). 코드를 작성하는 주체와 이를 승인하는 주체는 동일해서는 안 됩니다. 직무 분리(Separation of duties)는 실수가 배포되기 전에 잡아내기 위해 우리가 가진 가장 오래된 기술입니다.
• 단계 간의 계약(Contracts). 작업은 하나의 길고 불투명한 독백 대신, 타입이 지정되고 검사 가능한 인계(handoffs)를 통해 흐릅니다. 따라서 문제가 발생했을 때 정확히 어디인지 확인할 수 있습니다.
• 감사 추적(Audit trail). 모든 결정은 사후에 읽을 수 있어야 합니다. "왜 그렇게 했는가?"라는 질문에 답이 있어야 합니다.

이 중 어느 것도 생소한 것이 아닙니다. 이것은 재능 있는 개인을 신뢰할 수 있는 팀으로 바꾸어 놓는, 지루하지만 핵심적인 규율(discipline)입니다. 우리는 단지 그 규율을 모델이라는 기여자에게 적용하고 있을 뿐입니다.

관점의 전환 (The reframe)

코딩 에이전트를 소원을 들어주다가 눈을 돌리는 순간 당신을 놀라게 하는 지니(genie)로 생각하는 것을 멈추십시오. 대신 당신이 고용한 가장 빠른 주니어 엔지니어(junior engineer)로 생각하십시오. 잠도 자지 않고, 불평도 하지 않지만, 반드시 가드레일(guardrails)이 필요한 존재 말입니다. 에이전트가 나쁘기 때문이 아닙니다. 빠르고 새로운 대상에 대해 신뢰를 확장하는 방법이 바로 그러하기 때문입니다.

에이전트 엔지니어링(agentic engineering)의 다음 단계를 승리로 이끌 팀은 가장 좋은 모델을 가진 팀이 아닐 것입니다. 그건 누구나 할 수 있는 일입니다. 그들은 그 능력을 통제된 상태에서 — 예측 가능하게, 검토 가능하게, 그리고 규모 있게(at scale) — 배포하는 방법을 알아낸 팀이 될 것입니다.

그것이 바로 구축할 가치가 있는 계층(layer)입니다.

AOP — 에이전트 운영 프로토콜(Agent Operating Protocol) — 이 곧 출시됩니다. 코딩 에이전트를 실제 엔지니어링 통제 하에 두기 위해 고군분투하고 있다면, aop.sh에서 알림을 받아보세요. 메시지 하나면 충분합니다.

현재 무엇이 가장 힘드신가요 — 범위 확장(scope creep), 검토 신뢰도, 아니면 아키텍처 드리프트(architectural drift)? 댓글로 남겨주세요.