더 많은 전력, 더 적은 빛

토큰 소모 (Token burn)와 비즈니스 결과는 상관관계가 없습니다. 더 많은 소모는 더 많은 가치가 아니라, 더 많은 비효율을 의미합니다.

전력 문제

어두운 방에 들어가는 상황을 상상해 보세요. 불을 켜면 앞을 보는 데 도움이 됩니다. 하지만 건물 안의 모든 불을 다 켠다고 해서 더 잘 보이게 되는 것은 아닙니다. 방은 여전히 똑같은 방입니다. 이제 모든 표면이 똑같이 밝아져 대비 (contrast)가 사라지고, 당신은 사용하지도 않은 전력에 대한 비용을 지불하게 됩니다.

토큰도 마찬가지입니다. 명확한 범위 (scope)를 가진 집중된 프롬프트 (prompt)는 당신의 책상 위에 있는 단 하나의 전등과 같습니다. 무제한의 탐색을 허용하는 방대한 프롬프트는 건물 안의 모든 전등과 같습니다. 당신은 통찰 (insight)을 만들어내는 것이 아니라 전력을 태우고 있는 것입니다.

토큰은 전력이지, 결과물 (output)이 아닙니다. 더 높은 처리량 (throughput)이 더 많은 가치를 의미하지는 않습니다.

저는 할당량을 다 써버리고 나서 돌아봤을 때, 구체적인 결과물이 아무것도 없었던 주간들을 경험했습니다. 작동은 하지만 사용되지 않는 코드, 막다른 길로 끝난 탐색적 브랜치 (exploratory branches), 첫 검토를 통과하지 못한 그럴싸해 보이는 결과물만 생성하는 에이전트 (agents)들까지. 많은 움직임이 있었지만, 진전은 거의 없었습니다.

사용 한도 (ceiling)는 당신이 무한정 그렇게 행동하는 것을 막아줍니다. 그것은 성찰의 순간을 강제합니다: 이 소모가 실질적인 무언가를 만들어냈는가? 만약 대답이 '아니오'라면, 해결책은 더 많은 용량이 아니라 더 많은 규율 (discipline)입니다.

이제 제가 대신 사용하는 세 가지 패턴

저는 실제로 출시되는 것 (ships)과 단순히 컨텍스트 (context)만 태우는 것 사이의 차이에 주의를 기울이기 시작했습니다. 스스로를 더 빨리 제어할 수 있도록 이 패턴들에 이름을 붙였습니다:

RTK — Read The Knowledgebase (지식 베이스 읽기). 코드베이스를 15분 동안 집중적으로 읽어 정확한 파일과 정확한 변경 사항을 식별하는 방식입니다. 이는 탐색 과정에서 발생하는 20만 개 이상의 토큰 낭비를 줄여줍니다. 에이전트는 작업의 형태를 탐색하는 것이 아니라, 이미 알려진 형태를 바탕으로 실행합니다.
Caveman — 프롬프트를 입력하기 전에 압축하라. 인사말, 불필요한 미사여구 ("제 생각에는", "기본적으로", "이해가 되는지 알려주세요"), 그리고 끝인사 등을 제거하세요. 프롬프트의 모든 단어는 모든 응답 토큰에 걸쳐 배수로 작용합니다. 입력값의 군더더기가 적을수록 출력값의 군더더기도 줄어듭니다.
Ponytail — 최소 실행 가능한 솔루션을 명세하라. "견고한(Robust)", "확장 가능한(Scalable)", "엔터프라이즈급(Enterprise-grade)", "포괄적인(Comprehensive)" — 이러한 단어들은 범위 확장(Scope creep)을 유발합니다. 작동하는 가장 단순한 것을 명시하세요: "Redis가 아니라 TTL이 있는 Map으로 구현해줘." 명확한 제약 조건이 주어진 에이전트는 과잉 엔지니어링(Over-engineer)을 허용받은 에이전트보다 더 빠르게 결과물을 전달합니다.

이것들은 편법(Hacks)이 아닙니다. 제약 조건이 실재함을 인정하고, 더 많은 여유를 요구하기 전에 그 안에서 작동하는 법을 배우는 과정입니다.

한계(Ceiling)가 당신에게 강요하는 질문

비즈니스 관점에서 질문은 "토큰을 얼마나 사용했는가"나 "코드를 얼마나 생성했는가"가 아닙니다. 질문은 "그렇지 않았다면 출시되지 못했을 것 중 무엇이 출시되었는가, 그리고 그것이 비용을 들일 가치가 있었는가?"입니다.

만약 답이 불분명하다면, 더 많은 용량(Capacity)도 문제를 해결해주지 못할 것입니다. 낭비를 위한 예산이 늘어난다는 것은 단지 더 많은 것을 더 빠르게 낭비하게 된다는 의미일 뿐입니다.

진정한 질문: 만약 내일 당신에게 무제한의 토큰이 주어진다면, 무엇을 다르게 하겠습니까? 만약 당신이 구체적인 답변 — "더 빠르게 출시한다"가 아니라 "지금은 출시할 수 없는 '무엇'을 출시한다" — 을 명확히 말할 수 없다면, 더 많은 용량을 확보하는 것은 단지 더 많은 낭비에 비용을 지불하는 것과 같습니다.

두 가지 관점, 동일한 인물

에이전트를 매일 운영하는 사람으로서, 저는 그 한계를 체감합니다. 탐색을 중단하기 전에 더 오랫동안 탐색을 허용할 수 있는 더 많은 여유 공간이 있었으면 좋겠습니다. 그것은 솔직한 심정입니다.

실제로 제품을 출시하는 책임을 지는 사람으로서, 저에게는 한계(ceiling)가 존재해야 합니다. 한계는 무제한의 용량(unlimited capacity)이 결코 만들어낼 수 없는 규율을 강제합니다. 그것은 "모든 것을 시도하라"를 "올바른 것을 시도하라"로 바꿉니다. 움직임을 방향성으로 전환합니다.

이 두 가지 관점은 충돌하는 것이 아닙니다. 그것은 서로 다른 줌 레벨(zoom levels)을 가진 동일한 인물입니다. 엔지니어로서의 자아는 여유 공간(headroom)을 원합니다. 비즈니스 측면의 자아는 그 여유 공간이 가치를 창출한다는 증거를 원합니다. 둘 다 옳습니다. 그들 사이의 긴장감이 바로 핵심입니다.

모든 팀이 한계를 높일 필요는 없습니다. 어떤 팀들은 진정으로 필요로 하기도 합니다. 많은 병렬 실험(parallel experiments)을 수행하고, 신속한 프로토타이핑(rapid prototyping)을 하며, 여러 접근 방식을 탐색하는 팀들 말입니다. 그런 팀들에게는 더 높은 처리량(throughput)이 측정 가능한 가치를 만들어낼 것입니다. 하지만 대부분의 팀은 그렇지 않습니다. 대부분의 팀은 현재 상태로도 충분합니다. 그들의 현재 출력(output)은 현재의 요구 사항을 충족합니다. 한계는 기본적으로 해결해야 할 문제가 아니라 하나의 신호입니다. 질문을 던져야 할 순간입니다: 이 제약이 가치 있는 것을 막고 있는가, 아니면 그저 바쁜 것(something busy)을 막고 있는가?

실제적인 기술

저는 대부분의 주마다 한계에 부딪힙니다. 때로는 작업이 모든 토큰(token)의 가치를 정당화했기 때문이고, 때로는 제가 에이전트(agent)가 비효율적인 프롬프트(prompt)로 너무 오래 실행되도록 내버려 두었기 때문입니다.

더 많은 전력이 더 밝은 빛을 의미하지는 않습니다. 더 많은 토큰이 더 나은 결과(outcomes)를 의미하지도 않습니다. 기술이란 그 차이를 아는 것입니다.