팀에 AI 에이전트를 붙이고 나면 생산성이 오를 것 같은데, 막상 청구서를 보면 당혹스럽고, 머지된 PR을 보면 불안하다. 지시는 어떻게 내려야 하는지, 비용은 어디서 새는지, 리뷰는 누가 어떻게 해야 하는지—세 가지 모두 설계해놓지 않으면 에이전트는 그냥 비싼 자동완성이다. 최근 나온 세 가지 실증 데이터가 이 질문에 각각 다른 각도에서 답을 준다.
지시 설계: 태스크가 아니라 계약서를 써라
dev.to의 'Contracts, Not Tasks'는 불편한 사실 하나로 시작한다. 기능 하나를 잘게 쪼개는 데 수 시간을 쓴 팀 리드가 있었다. 어떤 파일을 수정하고, 어떤 메서드를 바꾸고, 어떤 순서로 진행할지—꼼꼼하게 써놓은 그 목록을, 개발자가 그대로 Claude에 붙여넣더라는 것이다. 당신이 몇 시간을 써서 만든 세부 태스크는, 에이전트가 코드 옆에서 몇 분 만에 다시 뽑아내는 구현 계획의 손으로 쓴 버전이었다.
이 중복이 단순한 비효율로 끝나지 않는 이유가 있다. 명세 작성이 구현보다 비싸지는 순간, 병목이 구조적으로 팀 리드 앞에 쌓인다. 더 꼼꼼하게 쪼갤수록 더 깊이 빠진다. '더 잘 분해하자'는 해법이 아니다. '덜 분해하고도 안전하게'가 목표여야 한다.
이 글이 제안하는 대안이 '계약(Contract)' 형태의 지시다. 같은 기능을 두 가지 방식으로 넘길 때 차이가 선명하게 드러난다.
태스크 목록 방식은 이렇다: "컬럼 추가하고, 핸들러 패치하고, 밸리데이션 확장하고, 마이그레이션 잊지 말고, 클라이언트 콜 업데이트해." 다섯 개의 방법 예측—전부 에이전트가 코드 옆에서 다시 유도할 수 있고, 내가 직접 확인할 수 없는 것들이다.
계약 방식은 이렇다: "이름 변경 작업이 존재한다. 중복 이름은 고유한 에러로 거부된다. 범위 소유자만 호출할 수 있다. 부모 객체가 삭제되면 레코드도 함께 삭제된다. 완료란 이 세 가지 체크가 통과되는 것이다." 다섯 개의 지켜야 할 약속—전부 검증 가능하고, 전부 내 추측이 아니다.
계약서에 들어가는 항목은 여섯 가지다: 인터페이스(완료 시 무엇이 존재하나), 동작(성공·실패·경계 케이스), 접근 권한(누가 호출할 수 있나—관리자 바이패스와 기계 ID까지), 생명주기(부모 삭제/수정 시 어떻게 되나), 수락 기준("완료"가 실행 가능한 체크를 통과한다는 뜻인가), 영향 범위(무엇이 깨지면 안 되는가). 계약에 의도적으로 빠지는 것이 있다: 파일 경로, 메서드 이름, SQL, 단계별 지시. 이것들은 에이전트의 영역이고, 코드 옆에서 더 잘 유도된다. 내가 쓴 줄은 두 번 쓴 줄이다.
이 방식이 위험하지 않으냐는 반론에 대해 저자는 '허용 가능한 단위의 크기는 수락 게이트의 강도에 반비례한다'는 원칙으로 답한다. 게이트가 강하면—시니어가 계약서 기준으로 리뷰하고, 저자가 테스트를 쓰고, 계약 구조를 체크하는 스크립트가 있으면—큰 덩어리를 한 번에 넘겨도 안전하다. 게이트가 약하면 세밀하게 쪼개야 한다. 단, 영원히가 아니라 게이트가 강해질 때까지만. 이 팀은 백엔드(강한 게이트)와 프론트엔드(아직 성장 중인 게이트)를 동시에 운용하며 이 법칙이 성립함을 직접 검증했다.
비용 설계: 무한 재시도를 허용하지 마라
지시를 잘 내려도, 에이전트가 어떻게 실행하는지 모르면 비용 구조가 무너진다. 681개 세션을 4개월간 직접 측정한 분석은 직관과 다른 결론을 내놓는다.
요청의 90%는 비용이 거의 없다. 구독료 대부분을 먹는 건 나머지 10%, 그 중에서도 특정 패턴—에이전트가 같은 파일을 멈추지 않고 반복 편집하는 순간이다. 같은 파일을 3번 이상 건드린 요청은 전체의 15%인데, 구독 비용의 41%를 차지한다. 5번 이상이면 8%가 21%를 잡아먹는다. 반복 편집 요청 하나가 정상 요청 30개 비용과 맞먹는다.
이 측정에서 반직관적인 발견이 하나 더 있다. 많은 사람이 컨텍스트 재설명 비용을 아끼려 하는데, 실제로는 거의 영향이 없다. 프로젝트 정보는 매 교환마다 재전송되지만 할인율이 적용된 가격으로 처리된다. 재설명은 시간을 잡아먹지, 돈을 잡아먹지 않는다. 측정하기 전에는 저자도 반대로 믿었다고 고백한다.
비용 출혈을 막는 신호는 하나다. 에이전트가 "이 파일에서 문제가 발생했습니다"라고 말하는 동안은 진짜 탐색 중이다. "다른 방법을 시도해볼게요"로 전환하는 순간—멈춰야 한다. 이미 찾은 해법을 순서만 바꿔 반복하는 중이다. 마지막 결과는 거의 항상 두 번째 시도에서 이미 나와 있었다.
실행 제어는 간단하다: 같은 문제에 2회 시도 제한을 지시 파일에 한 줄 써두는 것. "동일 파일을 두 번 이상 수정하면 멈추고 시도한 내용을 설명하라." 이 한 줄이 비용 41%를 먹는 패턴을 직접 겨냥한다.
리뷰 설계: 빠른 리뷰와 좋은 리뷰는 다르다
지시와 비용이 잡혀도, 리뷰를 어떻게 설계하느냐에 따라 품질이 갈린다. 207개 GitHub 프로젝트, 102만 개 PR을 분석한 연구(긱뉴스 보도)는 에이전트 도입이 리뷰 속도를 높일 수 있지만, 품질까지 함께 올라가지는 않는다는 것을 실증했다.
도입 방식에 따라 결과가 갈렸다. 점진적으로 AI를 확대한 프로젝트와 에이전트 단계에서 빠르게 도입한 프로젝트는 리뷰 속도가 개선됐다. 반면 초기부터 LLM 리뷰어를 모든 PR에 붙인 프로젝트는 속도도 나아지지 않고, 리뷰 안티패턴도 오히려 늘었다. 같은 AI 리뷰어 계정에 반복 의존하면서 리뷰 관점이 고정됐다는 게 연구진의 해석이다.
가장 눈에 띄는 수치는 'Review Buddies'—동일한 리뷰어 조합에 반복 의존하는 안티패턴이다. 사람만 참여한 리뷰에서는 약 16%. LLM이 참여한 패턴에서는 평균 60%로 뛴다. AI 리뷰어를 기본값으로 전 PR에 붙이는 순간, 리뷰 관점이 단일화되는 구조적 함정이 생긴다.
에이전트가 먼저 리뷰하고 사람이 판단하는 패턴은 속도 측면에서 유효했다. 에이전트가 변경을 요약하면 사람이 처음부터 전체를 파악하는 부담이 줄고, 75~95%의 케이스에서 이 흐름이 확인됐다. 그러나 '빠르게 결론에 도달했다'는 사실이 '충분히 검토됐다'는 의미는 아니다. 리뷰 속도와 코드 결함 감소는 이 연구에서 함께 증명되지 않았다.
연구진의 권고는 명확하다: AI 리뷰어를 전 PR에 일괄 적용하지 말 것. 단순 유지보수는 가벼운 LLM 요약, 저장소 탐색이 필요한 변경은 에이전트 검사, 크고 위험한 변경은 인간 주도 리뷰를 유지하는 방식으로 PR 유형에 따라 선택적으로 배치해야 한다. AI 리뷰어를 하나만 고정하면 계약서의 '수락 게이트'가 단일화되는 것과 같다—앞서 지시 설계에서 경고한 바로 그 함정이다.
세 가지를 하나의 운용 원칙으로
세 데이터가 각각 다른 문제를 다루지만, 결론은 하나의 방향을 가리킨다.
에이전트에게 내리는 지시는 방법이 아니라 약속이어야 한다. 실행 중 비용이 새는 지점은 반복 편집 패턴 하나이며, 2회 제한이라는 단 한 줄로 통제할 수 있다. 리뷰는 전수 자동화가 아니라 유형별 배치가 품질을 지킨다.
이 세 설계를 동시에 갖추지 않으면, 에이전트는 실제로 무엇을 만들어내고 있는지 팀 리드가 파악할 수 없는 블랙박스가 된다. 게이트를 강화하는 것이 프롬프트를 정교하게 다듬는 것보다 높은 레버리지를 가진다는 첫 번째 데이터의 통찰이, 리뷰 설계와 비용 제어에도 그대로 적용된다. 에이전트를 더 잘 통제하고 싶다면, 에이전트에게 더 정교한 지시를 내리기 전에 팀의 수락 게이트부터 점검해야 한다.