토큰 소모는 새로운 아키텍처 스멜(Architecture Smell)이다

AI 코딩에 대한 논의가 마침내 즐거운 단계를 지나고 있습니다.

한동안 질문은 단순했습니다. 에이전트(Agent)가 코드를 작성할 수 있는가? 이제 더 까다로운 질문은 이것입니다. 그 결과에 도달하기 위해 왜 그렇게 많은 토큰(Token)이 필요했는가?

이것은 마치 금융 이야기처럼 들리겠지만, 그렇지 않습니다. 이것은 아키텍처(Architecture)의 문제입니다.

코딩 에이전트가 방대한 양의 컨텍스트(Context), 재시도(Retries), 도구 호출(Tool calls), 그리고 절반만 맞은 수정 사항들을 소모할 때, 청구되는 비용은 측정하기 가장 쉬운 증상일 뿐입니다. 진짜 문제는 대개 시스템이 에이전트에게 방황할 수 있는 공간은 너무 많이 주고, 작업을 완료할 수 있는 구조는 너무 적게 주었다는 점입니다.

예산은 워크플로우(Workflow)의 누수 지점을 알려준다

최근 AI 코딩 에이전트를 둘러싼 비용 공포에서 흥미로운 점은 청구서에 찍힌 정확한 액수가 아닙니다. 대기업들은 온갖 종류의 엔지니어링 도구에 터무니없는 돈을 씁니다. 때로는 그것이 합리적일 수도 있습니다.

유용한 신호는 소모의 형태(Shape of the spend)에 있습니다.

만약 에이전트가 명확한 사양(Spec)에 따라 가치 있는 작업을 수행하느라 토큰 사용량이 늘어난 것이라면 괜찮습니다. 그것은 논리적으로 설명 가능한 비용 센터(Cost center)입니다. 하지만 에이전트가 저장소(Repo)를 계속 다시 읽고, 의도를 추측하며, 자신의 실수를 임시방편으로 수정(Patching)하고, 막힐 때마다 더 많은 컨텍스트를 요구하기 때문에 토큰 사용량이 늘어나는 것이라면, 그것은 "AI가 비싸다"는 문제가 아닙니다.

그것은 경계가 없는 루프(Unbounded loop)입니다.

개발자들은 이미 다른 형태의 이러한 스멜(Smell)을 알고 있습니다. 느린 빌드(Build)는 의존성 구조(Dependency structure)에 대해 무언가를 말해줍니다. 불안정한 테스트 스위트(Flaky test suite)는 격리(Isolation)에 대해 무언가를 말해줍니다. 걷잡을 수 없이 늘어난 클라우드 비용은 생명주기 제어(Lifecycle control)에 대해 무언가를 말해줍니다.

걷잡을 수 없는 토큰 소모도 같은 범주에 속합니다.

이는 에이전트 워크플로우에 유용한 중단 규칙(Stopping rule)이 없거나, 타이트한 작업 경계(Task boundary)가 없거나, 혹은 작업이 실제로 개선되고 있는지 결정할 저렴한 방법이 없음을 의미합니다.

80%의 문제는 토큰이 사멸하는 곳이다

에이전트 기반 코딩(Agentic coding)의 낙관적인 버전은 모델이 지루한 80%를 처리하고 인간이 흥미로운 20%를 처리한다는 것입니다.

그 생각은 위험할 정도로 실제와 비슷합니다.

첫 80%는 주로 프로덕션(production) 작업이기 때문에 비용이 저렴한 경우가 많습니다. 에이전트(agent)는 파일을 스캐폴딩(scaffold)하고, 패턴을 따르며, 명백한 글루 코드(glue code)를 채워 넣고, 그럴듯한 디프(diff)를 생성할 수 있습니다. 마지막 20%는 이해(comprehension)의 영역이기 때문에 비용이 많이 듭니다. 이것이 제품의 의도(product intent)와 일치하는가? 불변량(invariant)을 보존했는가? 아무도 언급하지 않은 지루한 경로를 조용히 망가뜨리지는 않았는가? 패치(patch)가 문제보다 더 작게 만들어졌는가, 아니면 단순히 리뷰를 위한 새로운 표면적(surface area)을 만들어냈는가?

이 지점이 바로 가이드가 없는 에이전트들이 잘못 작성된 쿼리(query)처럼 비용을 쓰기 시작하는 곳입니다.

그들은 다시 검색합니다. 컨텍스트(context)를 확장합니다. 주변 코드를 다시 작성합니다. 현재의 형태가 혼란스럽게 느껴지기 때문에 추상화(abstraction)를 추가합니다. 테스트를 실행하고, 실패하면, 실패를 패치하고, 원래 설계가 옳았음을 증명하는 과정 없이 계속 진행합니다.

모델은 악의를 품고 있는 것이 아닙니다. 모델은 당신이 요청한 것, 혹은 당신의 워크플로우(workflow)가 의도치 않게 허용한 것을 수행하고 있을 뿐입니다.

이것이 바로 토큰 소모(token spend)가 사람들이 인정하고 싶어 하는 것보다 더 나은 진단 도구인 이유입니다. 토큰 소모는 당신의 지시사항이 어디서 모호한지, 리포지토리(repo)의 경계가 어디서 흐릿한지, 그리고 당신의 리뷰 프로세스가 얼마나 '느낌(vibes)'에 의존하고 있는지를 보여줍니다.

리뷰가 함께 확장되지 않는 한, "더 많은 에이전트"는 냄새를 더 악화시킨다

병렬 에이전트(Parallel agents)는 유용합니다. 저도 이 패턴을 사용합니다. 한 에이전트는 문서를 탐색하고, 다른 에이전트는 좁은 모듈을 패치하며, 또 다른 에이전트는 실패 모드(failure mode)를 확인합니다. 제대로 수행된다면, 이는 페어 프로그래밍(pair programming)이라기보다 판단력으로 구성된 작은 빌드 시스템(build system)을 운영하는 것에 가깝게 느껴집니다.

하지만 병렬성(parallelism)이 마법처럼 레버리지(leverage)를 만들어내지는 않습니다. 병렬성은 당신이 이미 가지고 있는 워크플로우를 배가시킬 뿐입니다.

만약 작업(task)이 불충분하게 명시되었다면(underspecified), 이제 당신은 세 개의 불충분하게 명시된 작업을 갖게 됩니다. 만약 리포지토리 컨텍스트가 너무 광범위하다면, 이제 세 명의 에이전트가 그 컨텍스트의 서로 다른 조각들을 자신들의 윈도우(window)로 끌어오게 됩니다. 만약 리뷰 표면(review surface)이 취약하다면, 이제 세 개의 디프(diff)가 인간의 주의력을 얻기 위해 경쟁하게 됩니다.

이것이 바로 디프 리뷰어(diff reviewers), 모델 비교, 스킬(skills), 그리고 오퍼레이터 스택(operator stacks)을 둘러싼 툴링(tooling) 트렌드가 데모 영상보다 더 중요한 이유입니다. 유용한 레이어는 "에이전트, 하지만 더 자율적인"이 아닙니다. 유용한 레이어는 라우팅(routing)입니다.

이것은 어떤 종류의 작업인가?

어떤 컨텍스트(context)가 허용되는가?

어떤 파일 경계(file boundary)가 소유되는가?

작업이 완료되었다고 간주하기 위해 어떤 증거가 필요한가?

또 다른 40,000 토큰의 즉흥 연주(improvisation)를 유도하는 대신, 어떤 실패 상황에서 실행을 중단해야 하는가?

이것이 바로 아키텍처(architecture)입니다. 지루하지만 필수적인 아키텍처 말입니다.

컨텍스트는 예산에 대한 공격 표면(attack surface)이다

사람들은 마치 리포지토리(repo) 컨텍스트는 많을수록 좋다는 듯이 이야기합니다. 채팅 데모에서는 그것이 말이 됩니다. 하지만 프로덕션 에이전트(production agent) 작업에서는 나쁜 기본 설정입니다.

추가되는 모든 파일은 주의를 분산시키는 요소가 될 수 있습니다. 모든 광범위한 지침은 허가증이 될 수 있습니다. 모든 모호한 요구사항은 에이전트가 코드 형태, 명명 규칙(naming conventions), 오래된 테스트, 오래된 주석, 그리고 컨텍스트 창(context window)에 들어가는 무엇이든으로부터 누락된 제품 결정을 추론하려고 시도하는 또 다른 루프(loop)로 변질될 수 있습니다.

정답은 모델을 굶기는 것이 아닙니다. 정답은 컨텍스트를 의존성(dependency)처럼 취급하는 것입니다.

에이전트에게 필요한 파일만 제공하십시오. 에이전트가 준수해야 할 계약(contract)을 제공하십시오. 산문(prose)보다 예시가 더 저렴할 때는 예시를 제공하십시오. 매번 동일한 프롬프트(prompt)를 다시 쓰는 대신, 내구성이 있는 워크플로(workflow) 규칙을 버전 관리되는 스킬 파일(skill files)이나 리포지토리 문서(repo docs)에 넣으십시오. 해피 패스(happy path)는 명확하게 만들고, 이탈 경로(off-ramp)는 명시적으로 만드십시오.

다시 말해, 컨텍스트를 거대한 양동이로 취급하는 것을 멈추고 인터페이스(interface)로 취급하기 시작하십시오.

이는 코드 외부에서도 적용됩니다. 만약 AI 이미지 워크플로가 아주 작은 아티팩트(artifact)를 수정하기 위해 계속해서 생성(generation)을 소모하고 있다면, 아키텍처 측면에서의 해결책은 대개 생성을 클린업(cleanup) 단계와 분리하는 것입니다. Gemini 이미지 출력의 경우, Gemini Watermark Cleaner와 같은 좁은 범위의 브라우저 측 클린업 단계는 모델이 모든 다운스트림(downstream) 문제를 해결하기 위한 망치로 사용되는 것을 방지하는 경계가 지정된 도구(bounded tool)의 일종입니다.

코딩 에이전트에게도 동일한 원칙이 적용됩니다. 생성이 실제로 작업인 곳에만 비용이 많이 드는 생성형 시스템을 사용하십시오. 반복 가능한 클린업, 검증(validation), 포맷팅(formatting), 그리고 리뷰(review)는 더 명확한 계약을 가진 더 작은 도구들로 밀어내십시오.

더 나은 에이전트 워크플로는 설계 단계에 예산을 포함한다

실질적인 해결책은 "토큰을 덜 사용하라"가 아닙니다. 그것은 데이터베이스 속도가 느린 사람에게 "쿼리를 덜 날려라"라고 말하는 것과 같습니다.

죄책감을 느끼는 것보다 더 나은 제약 조건(constraints)을 만드는 것이 효과적입니다.

먼저 작업의 형태(task shape)부터 시작하십시오. 좋은 에이전트 작업은 작은 소유 경계(ownership boundary), 알려진 성공 조건, 그리고 명확한 중단 이유를 가져야 합니다. "인증 흐름(auth flow)을 개선하라"는 안개 생성기(fog machine)와 같습니다. 반면 "기존 검증 헬퍼(validation helper)를 사용하도록 비밀번호 재설정 양식을 업데이트하고, API 계약(contracts)을 변경하지 않으며, 만료된 토큰에 대한 회귀 테스트(regression test)를 하나 추가하라"는 명확한 작업입니다.

그다음 컨텍스트(context)를 제어하십시오. 에이전트에게 파일 5개가 필요하다면, 전체 리포지토리(repo)를 통째로 넘겨주며 에이전트가 스스로 지혜를 발견하기를 바라지 마십시오. 디자인 시스템이 필요하다면 실제 컴포넌트 패턴을 가리켜 주십시오. 제품 의도(product intent)가 필요하다면, 인간이 검토할 수 있는 지속 가능한 파일에 그 의도를 담으십시오.

그다음 리뷰(review)를 네이티브하게 만드십시오. 에이전트가 그럴듯한 코드를 빠르게 대량으로 생성할 수 있는 상황에서 디프(diff)만으로는 충분하지 않습니다. 무엇이 변경되었는지, 무엇이 의도적으로 변경되지 않았는지, 어떤 테스트가 실행되었는지, 그리고 에이전트가 어느 부분에서 불확실해하는지에 대한 짧은 요약이 필요합니다. 또한 증거가 부족할 때는 워크플로(workflow)가 중단되도록 해야 합니다.

마지막으로 작업 유형별 지출을 추적하십시오. 토큰 사용량 자체만 보는 것은 노이즈가 심합니다. 카테고리별 토큰 사용량은 유용합니다. 버그 수정(Bug fix), 리팩터링(Refactor), 테스트 복구(test repair), 탐색적 스파이크(exploratory spike), 의존성 업그레이드(dependency upgrade) 등입니다. 만약 특정 카테고리의 비용이 계속 높게 나온다면, 아마도 더 나은 지침(instructions), 더 작은 작업 단위(task slices), 또는 다른 도구가 필요하다는 신호일 것입니다.

높은 토큰 지출이 반드시 나쁜 것은 아니다

여기에는 성가신 예외 사항이 하나 있습니다. 비용이 많이 드는 일부 실행은 그만한 가치가 있다는 점입니다.

엉망인 레거시 코드베이스(legacy codebase) 전반에 걸친 심층적인 마이그레이션(migration)은 작은 버그 수정보다 더 많은 비용이 들 것입니다. 보안에 민감한 변경 사항은 읽고 검증하는 데 더 많은 시간을 소비해야 합니다. 깨끗하고, 검토되었으며, 가치가 높은 패치(patch)를 생성하는 장시간 실행되는 에이전트는 그것이 절약한 인간의 시간과 비교했을 때 저렴할 수 있습니다.

그러므로 목표는 아주 적은 토큰 청구서를 숭배하는 것이 아닙니다.

목표는 지출이 진전(progress)이 아닌 단순한 움직임(motion)만을 사고 있는 것은 아닌지 알아차리는 것입니다.

그 차이는 중요합니다. 움직임(Motion)은 에이전트(Agent)가 컨텍스트(Context)를 편집하고, 재시도하고, 요약하고, 확장하는 것입니다. 진전(Progress)은 시스템이 정확하고, 검토 가능하며, 소유 가능한 변경 사항에 더 가까워지는 것입니다.

만약 이 차이를 구분할 수 없다면, 당신의 아키텍처(Architecture)에는 계측(Instrumentation)이 누락된 것입니다.

진짜 운영 기술은 더 일찍 '아니오'라고 말하는 것이다

최고의 에이전트 운영자(Agent operator)는 모델이 영원히 실행되도록 내버려 두는 사람들이 아닙니다. 그들은 실행이 시작되기 전에 언제 실행을 제한해야 하는지 아는 사람들입니다.

그들은 더 날카로운 명세(Spec)를 작성합니다. 작업을 더 작은 단위로 나눕니다. 재사용 가능한 지침(Instruction)을 파일로 유지합니다. 증거를 요구합니다. 그들은 모델이 더 많은 토큰(Token)을 소비함으로써 불분명한 제품 사고(Product thinking)를 보완하게 두지 않습니다.

그것이 모든 "운영 스택(Operator stack)"에 관한 담론 뒤에 숨겨진 진짜 변화입니다. 스택은 단순히 Codex, Claude Code, 라우터(Router), 스킬(Skill), 디프 뷰어(Diff viewer), 그리고 다음 주에 출시될 무엇인가만을 의미하지 않습니다. 스택은 에이전트 작업(Agent work)을 검토 가능하게 만드는 방법입니다.

토큰 소모를 그런 방식으로 바라보기 시작하면, 청구서는 더 이상 놀라움의 대상이 아니라 프로파일러(Profiler)가 됩니다.

그리고 만약 프로파일러가 당신의 에이전트가 당신의 의도를 이해하려고 리포지토리(Repo)를 헤매는 데 실행 시간의 절반을 썼다고 말한다면, 해결책은 아마도 더 저렴한 모델이 아닐 것입니다.

해결책은 더 나은 경계(Boundary)를 설정하는 것입니다.

출처 노트