에이전트 루프는 토큰 문제가 아니라 피드백 문제다 — 비용을 결정하는 것은 검증 표면

본문

AI 코딩 분야에 'write loops, not prompts'라는 구호가 퍼지고 있습니다. 루프 기반 개발에서 에이전트는 시도 사이에 사람을 기다리지 않습니다. 작은 프로그램이 목표를 건네고, 결과물을 검사 세트에 돌리고, 실패를 피드백으로 되돌려주고, 검사가 통과하거나 한계에 닿을 때까지 반복합니다. 사람이 시도마다 조종하는 것보다 빠른 것이 이 패턴의 요점이지만, 저자는 이것이 정확히 지출 문제의 형태라고 지적합니다. 지난해 정액제 좌석이 종량제로 바뀌고 에이전트 제품에 사용량 상한이 생기는 등 토큰 지출의 첫 긴축이 있었지만, 그 청구서는 사람이 지켜보는 인터랙티브 세션에서 나온 것입니다. 루프는 설계상 그 사람을 제거하며, 같은 코드로 같은 레포를 돌려도 청구서가 달라지는 이유는 루프 자체가 아니라 루프가 자신이 바꾸는 시스템에 대해 무엇을 관찰할 수 있느냐에 있다고 말합니다.

비용은 합이 아니라 곱이다

프롬프트 주도 작업은 개발자가 매 반복 안에 있어 지출이 한 사람의 주의력에 묶여 있었고, Spec Kit·Kiro·OpenSpec 같은 스펙 주도 작업은 투자를 사전 명세로 옮겼으며, 루프 주도 작업은 개발자가 '일을 생성하고 검사하고 재시도하는 것' 자체를 작성하게 만듭니다. 루프를 쓸 가치 있게 하는 세 속성 — 무인이라 잘못된 수정으로 헤매도 알아채는 사람이 없고, 장시간 실행이라 지출 시계가 스스로 멈추지 않고, 병렬이라 한 루프의 비용을 여럿으로 지불한다 — 이 그대로 비용의 원인입니다. 대부분의 팀이 먼저 꺼내는 대응은 반복 상한, 진전 없음 감지, 지출 천장 같은 가드레일이지만, 이는 필요할 뿐 충분하지 않습니다. 상한은 낭비할 수 있는 양의 한계를 정할 뿐 루프를 덜 낭비하게 만들지 못합니다. 실제 청구서를 정하는 것은 검증된 결과까지 필요한 반복 횟수와 반복당 비용의 곱입니다. 곱이므로 둘을 절반으로 줄이면 청구서는 4분의 1이 되고, 어느 한 항의 하한은 어떤 가드레일로도 들어올릴 수 없는 총액의 하한이 됩니다.

피드백 품질이 두 항을 동시에 줄인다

빈 실패 신호만 받은 루프는 원인을 추측해 그럴듯한 것을 바꾸고 다시 돌리며, 다음 빈 실패는 그 추측이 근접했는지 거의 말해주지 않습니다. 반면 실제 시스템이 만들어낸 실제 오류를 결함을 국소화할 컨텍스트와 함께 받으면 진짜 문제를 고치고 넘어갑니다. 피드백 품질은 완성된 변경의 품질 상한이기도 합니다. 루프는 피드백이 볼 수 있는 것만 고칠 수 있으므로, 단위 테스트와 목만 주면 그것들이 통과하는 시점에 멈춥니다. 작동하는 변경과는 다른 것입니다. 반복당 비용에서 토큰 가격과 컨텍스트 크기는 루프 작성자가 조정할 부분이고, 플랫폼이 결정하는 부분은 각 반복이 답을 기다리는 시간과 그 뒤 환경의 비용입니다. 에이전트 세션이 끝난 뒤 CI에서 루프를 닫으면 매 사이클마다 파이프라인 실행과 다른 사람의 대기열이 붙어 케이던스가 분에서 시간 단위가 되고, 세션 안에서 에이전트가 직접 호출할 수 있는 런타임에 대해 닫으면 초 단위가 됩니다. 두 항은 독립적이지도 않습니다. 고충실도 피드백을 CI로 밀어내면 사이클이 비싸질 뿐 아니라 에이전트가 그 사이 부분 신호로 반복하게 만들어 반복 횟수마저 부풀립니다. 고충실도 피드백을 내부 루프로 끌어오는 것이 두 항을 동시에 압축하는 유일한 수단입니다.

클라우드 네이티브에서 트레이드오프가 무너지는 지점

자기완결 프로그램에서는 두 수치가 거의 공짜입니다. 노트북에서 테스트가 몇 초에 돌고 전체 시스템이 노트북에 있으므로 보고되는 것이 완전한 답이며, 설득력 있는 루프 데모가 단일 레포 프로젝트인 이유입니다. 마이크로서비스 변경은 다릅니다. 정확성이 호출 대상이 반환하는 것, 쓰기 대상인 큐와 데이터스토어의 동작, 앞단의 라우팅·정책 계층에 달려 있기 때문입니다. 몇 초 안에 닿는 피드백인 로컬 테스트와 목은 서비스 경계 안쪽만 커버하는 저충실도이고, 통합 테스트가 통과해도 스테이징이 깨지는 것이 정확히 이 이유입니다. 그것을 잡아낼 피드백은 프로덕션 충실도를 가지며, 전통적으로 CI와 공유 스테이징에 있어 매 실행이 다른 사람 뒤에서 기다립니다. 지금까지의 선택지는 '빠르고 저충실도' 대 '고충실도고 느림'의 정면충돌이었고, 루프는 두 항을 모두 지불하므로 어느 쪽도 부족합니다. 필요한 것은 상충하지 않는 옵션, 즉 루프가 세션 안에서 닿을 수 있는 프로덕션 충실도 환경입니다.

루프가 매 반복 통과하는 네 계층

첫째, 런타임입니다. 프로덕션처럼 동작하되 프로덕션 비용이 들지 않는 환경이 필요하며, 공유 클러스터 위의 경량 임시 환경이 답입니다. 변경이 닿는 서비스만 배포하고 요청 라우팅으로 루프의 트래픽을 그 서비스들과 나머지 전체의 안정된 공유 배포로내면, 환경은 몇 초에 뜨고 한계 비용은 전체 스택이 아니라 바꾼 파드 기준으로 따라갑니다. 반복당 비용에 대한 플랫폼 팀의 레버이자 충실도의 출처입니다. 둘째, 검증 워크플로입니다. 에이전트는 대시보드를 클릭하지 않고 통과 기준을 스스로 발명해서도 안 되므로, 변경이 만족해야 할 검사는 플랫폼 팀이 작성·버전 관리하는 선언적 워크플로로 두고 에이전트에게 공인된 증명 수단으로 건넵니다. 리뷰어는 에이전트의 말이 아니라 어떤 검사가 돌았는지의 기록을 받으며, 이것이 루프가 언제 멈춰도 되는지를 알려줍니다. 셋째, 피드백 신호입니다. 반복 횟수의 레버로, 단순 pass/fail은 다시 시도하라고만 할 뿐 무엇을 바꿀지 말하지 않습니다. 런타임은 어떤 검사가 실패했는지, 이 루프가 직접 낸 요청에 한정된 로그와 트레이스, 경계에서 깨진 동작 변경 같은 구조화된 결과를 반환해야 합니다. 정밀도 한 단계가 추측 하나를 없애고, 없앤 추측은 일어나지 않는 지출입니다. 넷째, 가드레일과 기록입니다. 예산, 반복 천장, 정체 감지, 모든 검사와 결과의 내구적 기록은 두 항을 줄이지 않지만 곱에 하드 천장을 두어, 한 루프를 불안하게 감독하는 대신 수백 개를 돌리고 계획에 숫자를 넣을 수 있게 합니다.

역할 분담과 시사점

역할 분담은 비용 구조에서 따라 나옵니다. 애플리케이션 개발자는 무엇을 만들지와 루프가 스스로 검사할 수 있는 형태의 목표를 정하고, 플랫폼 엔지니어는 루프가 통과하는 모든 것 — 어떤 검사가 어디서 돌고, 루프가 얼마를 쓸 수 있고, 출력에 어떤 증거가 붙는지 — 을 소유합니다. 이는 조직의 모든 루프에 걸쳐 성립해야 하며 루프마다 재발명되어서는 안 됩니다. CI/CD가 팀마다 직접 연결하던 것에서 소유자와 계약이 있는 공유 시스템으로 넘어갔듯, 루프의 검증 계층도 같은 전환이지만 PR이 존재하기 전 작성 중에, 루프가 만들어내는 동시성에서 작동해야 한다는 새 요구사항이 붙습니다. 저자는 나머지 셋이 그 위에 서므로 런타임부터 시작하라고 권하며, 이 계층이 Signadot이 만드는 것 — 경량 임시 환경과 거버닝된 검증 워크플로를 갖춘 Kubernetes 네이티브 검증 플랫폼 — 이라고 밝힙니다. 에이전트가 팀이 검증할 수 있는 속도보다 빨리 변경을 만들어내고 있다면, 다음 청구서의 크기는 토큰 가격이 아니라 피드백 표면이 이미 결정했다는 것이 글의 결론입니다.

원문: dev.to / 번역·요약: Trawling