코딩 에이전트를 평가하는 엔지니어링 팀은 대개 잘못된 질문부터 시작합니다. 그들은 에이전트가 얼마나 자율적일 수 있는지 알고 싶어 합니다. 파이프라인의 어느 정도까지 에이전트가 맡을 수 있을까요? 누구의 방해도 받지 않고 사양을 작성하고, 저장소를 수정하며, 프로덕션에 배포할 수 있을까요? 데모 영상들은 이러한 집착을 부추기기 쉽습니다. 단 한 번의 프롬프트로 일련의 수정과 배포가 연쇄적으로 일어나는 매끄러운 워크플로우를 보면, 조직 내에서도 똑같은 역량을 구현하고 싶다는 본능이 생깁니다. 하지만 화려함은 형편없는 설계 원칙입니다. 더 나은 질문은 훨씬 덜 흥미롭습니다. 이 도구에 누가 권한을 부여했는가, 실제로 어떤 시스템에 접근할 수 있는가, 그리고 필연적으로 오류가 발생했을 때 어떤 일이 벌어지는가 하는 질문들입니다.
자율성의 함정
흥미로운 자율성은 함정입니다. 그것은 사양을 생성하고, 저장소를 수정하며, 작업이 완료되었다고 태연하게 주장하며 코드를 배포하는 봇을 찬양하도록 우리를 길들입니다. 그것은 엔지니어링이 아닙니다. 그것은 셸 액세스(shell access)를 맡긴 채 눈을 감고 뛰어내리는 신뢰 게임(trust fall)과 같습니다. 작업 자체는 생산하기에 너무 쉬워질 수 있습니다. 어떤 모델이든 몇 초 만에 코드, 문서 또는 아키텍처 계획을 뽑아낼 수 있습니다. 하지만 소프트웨어 개발에서 진짜 비용은 타이핑 속도가 아니었습니다. 그것은 언제나 검증과 리뷰, 그리고 '이것은 정확하며 배포하기에 안전하다'라고 결정하는 신중한 판단이었습니다. 생성된 작업은 저렴합니다. 승인은 비쌉니다. 승인 과정을 깔끔하고 일관되게 처리하는 방법을 깨닫는 기업만이 실제로 신뢰할 수 있는 시스템을 구축하게 될 것입니다.
셀프 리뷰가 실패하는 이유
위험은 예측 가능한 패턴으로 나타납니다. 모델이 계획을 초안하고, 그 계획이 괜찮은지 스스로 평가합니다. 에이전트가 코드베이스를 수정하고, 왜 자신의 변경 사항이 안전한지 설명합니다. 도구가 명령을 실행하고 허락 대신 용서를 구합니다. 이 각각은 동일한 핵심적 실패를 나타냅니다. 에이전트가 사양을 생성한다면, 그것이 사실로 확정되기 전에 에이전트 외부의 무언가가 승인해야 합니다. 에이전트가 코드를 수정한다면, 별도의 프로세스가 diff를 검사해야 합니다. 생성자가 스스로 검증자 역할을 하게 두는 것은 지름길이 아닙니다. 그것은 편의성이라는 옷을 입은 구조적 버그입니다.
프롬프트는 권한 시스템이 아니다
교묘한 문구로 에이전트를 보호할 수는 없습니다. 모델에게 주의를 기울이라거나 무언가를 삭제하기 전에 물어보라고 말하는 것은 경계를 만들지 못합니다. 프롬프트는 권한 시스템이 아닙니다. 에이전트를 프로덕션 근처에 두기 전에, 에이전트의 역량에 대한 정직한 목록을 작성해야 합니다. 전체 저장소를 읽을 수 있습니까? 셸 명령을 실행할 수 있습니까? 브라우저를 열 수 있습니까? 고객 데이터를 컨텍스트 윈도우(context window)로 가져올 수 있습니까? 대부분의 팀은 완전한 답을 알지 못합니다. 그들은 도구가 실제로는 핵심 경로에 쓰기 권한을 가지고 있음에도 불구하고 샌드박스에 갇혀 있다고 가정합니다. 먼저 접점(surface area)을 파악하십시오. 그런 다음 벽을 세우십시오.
계층적 제어 시스템 구축하기
에이전트가 무엇을 할 수 있는지 이해했다면, 위험도에 따라 제약(friction)을 조절하는 제어 시스템을 설계하십시오. 내부 문서를 업데이트하거나 일관된 코드 형식을 맞추는 것과 같은 저위험 작업은 자동으로 실행될 수 있습니다. 모듈을 리팩터링하거나 새로운 의존성을 추가하는 것과 같은 중위험 작업은 사람이나 검증된 테스트 스위트가 해당 작업을 확인하는 체크포인트를 거쳐야 합니다. 프로덕션 배포, 인프라 수정 또는 민감한 데이터 접근과 같은 고위험 작업은 생성 과정에 참여하지 않은 별도의 승인자가 필요합니다. 모든 단일 작업은 감사 추적(audit trail)을 남겨야 합니다. 어떤 파일이 읽혔고, 어떤 도구가 호출되었으며, 어떤 결정이 내려졌는지 정확히 재현할 수 있어야 합니다. 에이전트 기반 개발은 리뷰를 건너뛰어도 된다는 면죄부가 아닙니다. 지루한 제약은 기능(feature)입니다. 적절한 승인 게이트는 상황이 어긋나기 시작할 때 서킷 브레이커(circuit breaker) 역할을 합니다.
경계를 위험도에 맞추기
경계를 실제 위험에 맞춰 조정하십시오. 모든 마크다운 서식 수정을 준수 절차로 만드는 것은 팀의 발목을 잡을 것입니다. 하지만 에이전트가 자신만만해 보인다고 해서 중대한 작업을 무해한 것으로 취급하는 것 또한 어리석은 일입니다. 목표는 과장된 제한이 아니라 비례적인 제어입니다.
아티팩트를 작고 관찰 가능하게 유지하기
가장 유용한 에이전트 시스템은 거대한 자율 실행으로 당신을 놀라게 하려 하지 않습니다. 대신 검토 가능한 작은 결과