Loop Engineering에 대한 시각들
우버는 2026년 AI 예산을 1월부터 4월까지 4개월 만에 모두 썼다. 5000명 규모 엔지니어 조직에 Claude Code를 배포한 뒤, 2월 32%였던 에이전틱 사용률이 3월에는 84%로 올랐다. 봄이 되자 전체 엔지니어의 95%가 매달 AI 도구를 썼고, 커밋된 코드의 약 70%가 이 도구들에서 나왔다. 1인당 월평균 비용은 150-250달러 수준이었으며, 파워 유저는 500-2000달러까지 지출했다. 한 임원은 2시간 데모 세션에서 1200달러를 쓰기도 했다. 회사는 결국 도구당 월 1500달러 한도를 두는 것으로 대응했다.
이 지출은 단순한 방만이 아니었다. 우버는 사내 리더보드로 엔지니어를 Claude Code 사용량 순으로 줄 세웠다. 이 구조 자체가 사용을 부추기는 인센티브로 작동했다. 노리 에이전틱의 분석에 따르면 초기 토큰맥싱은 AI 도구에 저항하던 고급 인력을 끌어들이기 위한 강압적 방법이었다. 우버의 리더보드는 이 메커니즘을 그대로 따랐다.
겉으로 보이는 낭비의 상당 부분은 사실 채택을 유도하기 위한 비용이었다.
테슬라는 7월 6일부터 주당 200달러 한도를 걸었다. 한도를 넘기면 매니저 승인을 받아야 한다. 다만 xAI의 Grok과 Composer는 이 한도에서 제외됐다. 앤스로픽·오픈AI·구글 도구 지출만 제한을 받는다. 결과적으로 자사 에이전트는 통제 밖에 남고 경쟁사 도구만 규제하는 구조가 됐다. 예산 정책이 자사 생태계 쏠림을 유도할 수 있음을 보여주는 사례다.
팔란티어 CEO 알렉스 카프의 입장은 이들과 결이 달랐다. 그는 토큰을 낭비하는 엔지니어를 지적한 것이 아니라, 오픈AI와 앤스로픽의 토큰 과금 모델 자체를 문제 삼았다. 기업이 토큰에 돈을 쓰면서도 실질 가치를 얻지 못하고, 대신 자사 IP를 프론티어랩에 내준다는 것이다. 지출 규모가 곧 성과를 의미하지 않는다는 점을 강조했다. 우버가 사용량 자체를 성과로 착각한 것과 달리, 카프는 과금 구조의 근본적 한계를 지적한 셈이다.
앤스로픽은 7월 3일 Claude Enterprise에 관리 기능을 추가했다. 모델별 권한 설정, 지출 한도의 75%·90% 도달 시 관리자 알림, 사용자에게도 75%·95% 알림을 주는 체계와 SCIM 연동 대시보드를 제공한다. 같은 시기 리눅스재단은 액센츄어, 구글클라우드, IBM, JP모건체이스, 마이크로소프트, SAP 등이 참여하는 Tokenomics Foundation 출범을 준비 중이라고 밝혔다. FinOps재단과 손을 잡고 AI 비용을 클라우드 운영비처럼 계량 가능하게 만들겠다는 방향이다. 지출을 막는 대신 통제 가능하게 만드는 접근이다.
또한 한편에서는 토큰맥싱을 옹호하는 쪽도 있다. 핵심 주장은 이제는 패러다임이 바뀌었다는 것이다. 과거에는 모델 오류가 누적돼 장시간 실행이 손해였지만, 지금은 토큰을 더 쓸수록 결과가 좋아지는 구간에 들어섰다는 주장이다. 근거로 앤스로픽 레드팀 테스트를 든다. 시도당 1억 토큰, 1만2500달러 예산을 열 차례 투입해도 수익 체감 징후가 없었다는 것이다. 이 주장이 맞다면 루프형 실행은 줄여야 할 낭비가 아니라 정당하게 늘려야 할 지출이 된다.
그러나 Unknown Unknown은 여전히 풀리지 않는다
도널드 럼즈펠드는 2002년 2월 12일 국방부 브리핑에서 이라크의 대량살상무기 이전 증거를 묻는 질문에 이렇게 답했다. known knowns가 있다, 우리가 안다는 걸 아는 것들. known unknowns도 있다, 모른다는 걸 아는 것들. 그리고 unknown unknowns가 있다, 모른다는 것조차 모르는 것들이라고. 당시엔 궤변으로 조롱받았지만 이후 리스크·복잡계 이론에서는 무지를 종류별로 나누는 정당한 틀로 재평가됐다.
앤스로픽의 Fable 5 필드가이드도 비슷한 분류를 제시한다. 프롬프트에 명시한 것은 known known, 인식은 하지만 아직 풀지 못한 것은 known unknown, 너무 당연해서 적지 않았지만 보면 알 수 있는 것은 unknown known, 전혀 고려하지 않은 것은 unknown unknown이다. 가이드는 이를 맵과 영토의 차이로 설명한다. 프롬프트는 맵이고, 실제 코드베이스의 제약은 영토라는 것이다.
unknown unknown을 known unknown으로 바꾸는 유일한 경로는 실제로 코드를 돌려보고 어디서 깨지는지를 보는 것이다.
프롬프트를 아무리 자세히 써도 스스로 모르는 제약 조건을 모두 미리 명세에 담을 수는 없다. 그래서 탐색, 브레인스토밍, 프로토타이핑 단계가 필요하다. Fable 가이드 자체도 이 과정을 unknown을 찾아내는 작업으로 규정한다. 비싼 실패가 발생하기 전에 무엇을 몰랐는지를 저비용으로 드러내자는 취지다.
심리학의 의도적 연습 연구도 같은 메커니즘을 보여준다. 앤더스 에릭슨의 연구에서 핵심은 단순 반복 시간이 아니라, 매 회차 목표를 정하고 실행한 뒤 정확한 오류 지점을 피드백으로 교정하는 과정이다. 시간만 쌓는다고 실력이 늘지 않으며, 이전에 인식하지 못했던 구체적인 약점을 하나씩 드러내고 수정할 때에만 실력이 쌓인다. 반복 자체가 아니라 반복이 드러내는 unknown unknown을 잡아내는 메커니즘이 중요하다는 점에서 두 분야의 구조가 겹친다.
우리는 1만시간의 법칙을 중요시하지 않았던가.
이 구분이 루프 엔지니어링과 단순 재실행을 가른다. 피드백 신호 없이 그냥 다시 돌리는 루프는 저ROI 토큰맥싱과 다르지 않다. 반대로 Fable 가이드처럼 엣지케이스마다 보수적 선택을 하고 Deviations 섹션에 기록해 다음 회차가 참조하게 하는 것은 실제로 피드백이 걸린 반복이다. 의도적 연습에 더 가깝다.
앤스로픽의 Fable 5: Finding your unknowns 가이드
앤스로픽 엔지니어 타릭 시히파가 2026년 7월 6일 작성한 Fable 5 필드가이드는 에이전틱 코딩의 병목이 모델 성능이 아니라 사용자가 스스로 모르는 것의 양이라고 본다. 가이드는 구현 전·중·후에 걸쳐 unknown을 체계적으로 드러내고 기록하는 일련의 관행을 제시한다. 초점은 프롬프트를 정교하게 다듬는 데서 벗어나, 코드베이스와 모델 행동 사이의 정렬도를 높이는 데 있다.
가이드가 직접 사례로 든 작업은 Fable 런칭 영상을 처음부터 끝까지 편집한 과정이다. Whisper 자막 정확도와 ffmpeg 필러 단어 제거 가능성을 블라인드 스팟 패스로 먼저 확인했고, Remotion으로 자막 타이밍을 프로토타이핑했다. 특히 컬러 그레이딩이라는 개념 자체를 몰랐기 때문에, 그 개념을 배운 뒤에야 여러 변형을 시도할 수 있었다. 가이드의 문장을 그대로 옮기면 작업이 길어질수록 클로드가 마주치는 미지수도 늘어난다.
가이드가 실제로 제시한 프롬프트 표현은 다음과 같다.
블라인드 스팟 패스 “새 인증 제공자를 추가하려는데 이 코드베이스의 인증 모듈에 대해 아는 게 전혀 없어. 블라인드 스팟 패스를 해줘서 내 관련 unknown unknown을 찾아내고, 내가 더 나은 프롬프트를 쓸 수 있게 도와줄래?” “컬러 그레이딩이 뭔지 모르는데 이 영상에 그레이딩을 해야 해. 컬러 그레이딩에 대한 내 unknown unknown을 이해하도록 가르쳐줘서, 내가 더 나은 프롬프트를 쓸 수 있게 해줄래?”
브레인스토밍과 프로토타입 “이 데이터로 대시보드를 만들고 싶은데 내겐 비주얼 감각이 없고 뭐가 가능한지도 몰라. 완전히 다른 네 가지 디자인 방향의 HTML 페이지를 만들어줘, 내가 보고 반응할 수 있게.” “아무것도 연결하기 전에, 가짜 데이터로 새 에디터 툴바를 흉내낸 HTML 파일 하나를 먼저 만들어줘. 실제 앱을 건드리기 전에 레이아웃부터 보고 반응하고 싶어.” “대략적인 문제는 이거야: 온보딩 이후 사용자들이 이탈해. 코드베이스를 뒤져서 개입할 수 있는 지점 10곳을 가장 저렴한 것부터 가장 야심찬 것까지 브레인스토밍해줘. 어떤 게 와닿는지는 내가 말해줄게.”
인터뷰 “모호한 부분에 대해 한 번에 질문 하나씩 나를 인터뷰해줘. 내 답변이 아키텍처를 바꿀 만한 질문을 우선해줘.”
레퍼런스 “vendor/rate-limiter에 있는 이 Rust 크레이트가 내가 원하는 백오프 동작을 정확히 구현하고 있어. 이걸 읽고 우리 TypeScript API 클라이언트에 같은 시맨틱으로 재구현해줘.”
구현 노트(Deviations) “implementation-notes.md 파일을 계속 남겨줘. 계획에서 벗어날 수밖에 없는 엣지케이스를 만나면 보수적인 선택지를 고르고, 그걸 ‘Deviations’ 항목에 기록한 뒤 계속 진행해.”
퀴즈 “이 변경에서 일어난 모든 걸 내가 제대로 이해했는지 확인하고 싶어. 맥락과 직관, 무엇을 했는지 등을 담아 내가 읽고 이해할 수 있는 HTML 리포트를 만들어주고, 맨 아래에 반드시 통과해야 하는 퀴즈도 붙여줘.”
이 관행들이 가리키는 결론은 단순하다.
루프를 가장 많이 도는 사람이 최고의 에이전틱 코더가 아니다.
코드베이스와 모델 행동 사이에 이미 정렬이 잘 되어 있어 처음부터 unknown 자체가 적은 사람이 더 적은 루프로도 높은 결과를 낸다. 루프의 필요성을 인정하는 것과 루프를 무한정 늘리는 것 사이에는 이 차이가 있다.
그렇다면 예산은 어떻게 통제할 것인가?
사용량 순위나 주당 정액 한도는 투입량만 계량한다. 같은 예산이라도 회차마다 오류가 줄며 수렴하는 루프와, 개선 없이 재실행만 반복하는 루프는 가치가 다르다. 그러나 정액제는 이 차이를 구분하지 못한다.
필요한 것은 반복 횟수가 아니라, 회차마다 교정된 오류의 수나 구현 노트의 편차 항목이 줄어드는 속도를 재는 것이다. 앤스로픽의 지출 알림 체계나 Tokenomics Foundation의 벤치마크도 지출 가시성만 제공할 뿐, 그 지출이 수렴하는 루프였는지는 답하지 못한다. 판단 근거는 정액 숫자가 아니라 편차 곡선과 재작업 곡선이며, 이는 루프를 설계하고 소유한 엔지니어 또는 팀 단위에서 관찰해야 한다.
Loop Engineering은 필요하다. 다만 그 필요를 정당화하는 것은 반복 횟수가 아니라, 반복이 실제로 무지를 줄이고 있다는 증거다.
결국 문제는 루프를 돌릴 것이냐 말 것이냐가 아니다. 루프가 매 회차 실제로 무지를 줄이고 있는지, 그 증거를 조직이 볼 수 있는지 여부다. 지금의 예산 통제 체계는 그 증거를 볼 수 있는 장치를 갖추지 못했다. 편차가 줄어드는 곡선, 재작업이 감소하는 신호, unknown이 known으로 바뀌는 과정 — 이들을 보지 못하는 한, 어떤 한도를 걸든 어떤 인센티브를 주든 루프 엔지니어링은 비용만 드러내고 가치는 숨기는 구조로 남을 가능성이 크다.