토큰을 배급하지 말고 하네스가 모델을 고르게 하라

URL: https://www.youtube.com/watch?v=48YUYDjwfYY
날짜: 2026-10-03
채널: aiDotEngineer
발표: Laura(Cast AI 공동창업자·대표)와 Kimchi 엔지니어링 리드

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==개발자의 토큰 사용량을 억제할 것이 아니라, 작업 결과의 품질을 유지하면서 하네스(harness)가 작업마다 가장 경제적인 모델을 자동 선택하게 만들어 토큰을 사실상 무제한으로 제공할 수 있는가?==

• 기업의 LLM 비용 폭증은 개발자에게 토큰을 덜 쓰라고 말하는 방식으로 해결할 문제가 아니다.
• 토큰당 가격이 낮은 모델이 작업 전체 비용까지 낮다는 보장은 없으며, 같은 품질의 결과를 내는 데 필요한 작업 단위 비용을 비교해야 한다.
• Kimchi 하네스는 여러 모델을 시험하고 결과를 채점해, 품질 기준을 통과하는 범위에서 비용이 낮은 모델을 선택한다.
• 장시간 코딩 작업을 마일스톤 단위로 실행하고, 빌드·검증·재작업·스테이징 배포까지 연결하면 개발자는 노트북을 닫아도 작업을 계속 맡길 수 있다.

핵심은 “좋은 모델 하나를 고정해서 쓰자”가 아니라 “작업의 결과를 기준으로 매번 모델을 선택하자”는 운영 방식이다. Kimchi는 이 모델 라우팅을 장시간 실행 하네스, 원격 실행 환경 Teleport, 팀 협업 공간 Studio로 확장해 소프트웨어 개발 수명주기 전체를 자동화하려 한다.

1. 토큰을 제한하는 대신 사용량을 감당할 수 있게 만들기

토큰 비용이 커졌다는 이유로 개발자의 사용량을 막으면 생산성의 핵심 연료를 배급하는 꼴이 되므로, 관리자의 책임은 제한이 아니라 비용 구조의 최적화다.

1.1. 기업이 마주한 토큰 비용 폭발

1. 기업 규모에서 드러난 토큰 맥시멈(token maxing) 문제

   1. 인도 기업의 Anthropic 지출: 최근 한 인도 기업이 한 달에 Anthropic에만 5억 달러($500 million)를 썼다는 사례가 소개된다.
   2. Uber CTO의 연간 예산 소진: Uber CTO는 최근 4개월 동안 Anthropic의 1년치 예산 전체를 사용했다고 공개적으로 말했다.
   3. 공통된 의미: 모델을 많이 쓰는 기업에서는 토큰 비용이 단순한 API 요금이 아니라 클라우드 예산과 개발 조직 운영을 좌우하는 항목이 됐다.

2. 토큰 제한이 개발자에게 주는 감각

   1. 노트북 배터리 비유: 개발자에게 토큰을 제한하는 것은 배터리가 한 시간밖에 없는 노트북을 주고 하루에 한 번만 충전하게 하는 것과 같다.
   2. 생산성의 역전: 코딩 에이전트를 쓰지 못하게 막는 방식은 비용은 줄일 수 있어도 에이전트가 제공하는 반복 실행·탐색·검증 능력을 함께 줄인다.

1.2. 관리자의 역할을 다시 정의하기

1. 제한이 아닌 무제한에 가까운 사용 환경

   1. Kimchi가 세운 원칙은 개발자가 원하는 만큼, 원하는 시간 동안 코딩 에이전트를 사용할 수 있게 만드는 것이다.
   2. 관리자는 개발자의 에이전트 사용을 예방하는 사람이 아니라, 토큰을 무제한이고 저렴하게 만드는 사람이어야 한다.

2. Kimchi를 만든 배경

   1. Kimchi에는 직원 300명이 있고, 그중 약 3분의 2가 개발자다.
   2. 조직은 약 3개월 동안 자체 코딩 에이전트를 사용하면서 무엇을 만들었는지, 어떻게 만들었는지, 비용과 결과가 어떻게 변했는지를 측정했다.

2. 토큰당 가격이 아니라 작업당 비용을 최적화하기

동일한 품질의 결과를 만드는 작업을 기준으로 보면, 입력 토큰 단가가 싼 모델이 오히려 더 비싼 선택일 수 있다.

2.1. 같은 품질의 같은 작업으로 모델을 비교하기

1. 비교의 단위 바꾸기

   1. 발표에서 인용한 대학 연구의 그래프는 한쪽에 토큰당 비용(cost per token)을, 다른 쪽에 동일한 작업을 동일한 품질로 끝내는 데 드는 작업당 비용(cost per task)을 표시한다.
   2. 서로 다른 모델을 “사과와 사과(Apple with Apple)”처럼 비교하려면 토큰 단가가 아니라 같은 결과를 얻는 총비용을 봐야 한다.

2. Gemini 3 Flash 사례

   1. Gemini 3 Flash는 토큰 100만 개당 3.5달러 정도의 비교적 저렴한 모델로 보인다.
   2. 그러나 연구 시점의 혼합 평균 단가와 별개로, 같은 품질의 작업을 실제로 완료하는 비용은 약 75달러였다.
   3. 자막에는 이 수치가 잠시 305로 잘못 말해졌다가 곧바로 75달러로 정정되는 순간이 있다.

3. Minimax 2.7 사례

   1. Minimax 2.7은 토큰 단가가 1.5달러 수준으로 더 낮게 보인다.
   2. 하지만 작업 하나를 끝내는 비용은 148달러로, 토큰 단가만 보고 고르면 비싼 선택이 될 수 있다.

2.2. 결과를 보고 모델을 고르는 자동 하네스

1. 모델은 작업마다 다른 경제성을 가진다

   1. 모델마다 토큰 가격이 다를 뿐 아니라, 같은 작업을 완성하는 데 필요한 호출 횟수와 추론량도 다르다.
   2. 따라서 개발자가 모든 모델을 직접 테스트해 고정 모델을 고르는 대신, 자동화된 엔진이 작업 결과를 기준으로 모델을 선택해야 한다.

2. Kimchi Coding의 모델 선택 원리

   1. 하네스는 작업에 맞는 모델을 적절한 시점에 선택한다.
   2. 선택 기준은 모델의 명목 가격이 아니라 결과의 품질과 그 품질에 도달하기까지의 토큰 비용이다.
   3. 하네스는 새 모델이 등장했을 때 사람이 일일이 익숙해지고 테스트하기를 기다리지 않고, 결과 점수와 비용을 바탕으로 선택을 바꾼다.

3. 실제 사용 결과와 모델 선택의 변화

Kimchi는 모델 선택을 자동화한 뒤 토큰 사용량이 늘어나는 상황에서도 코딩 비용을 줄이고 같은 결과를 유지했다.

3.1. 3개월 운영에서 얻은 비용 결과

1. 클라우드 비용 절감

   1. 약 3개월 사용 결과, Kimchi는 비교 기준 대비 2.5배의 절감 효과를 얻었다.
   2. 그래프의 보라색 선은 자동 최적화가 없었다면 날짜별로 발생했을 클라우드 비용이고, 파란색 선은 실제 지불한 비용이다.
   3. 두 선의 차이는 결과를 유지하면서 모델 선택만으로 비용을 낮출 수 있음을 보여준다.

2. 토큰과 코딩 비용의 반대 방향

   1. 같은 기간 토큰 사용량은 1.5배 증가했다.
   2. 그런데 코딩 비용은 1.5배 감소했다.
   3. 발표자는 비용 증가율이 작업에 사용된 토큰 증가율보다 약 2.5배 낮아졌다고 표현하며, 이 구조가 개발자에게 사실상 무제한 사용 환경을 제공한다고 설명한다.

3.2. 하네스가 사람보다 빠르게 모델을 교체하는 이유

1. 시간에 따른 선택 모델의 이동

   1. 6월 초 그래프에는 주황색 모델이 많이 선택되고, 6월 말에는 노란색 모델이 많아진다.
   2. 이는 하네스가 단기간에 전혀 다른 모델을 주력으로 선택하게 됐다는 뜻이다.
   3. 변화의 전환점은 6월 12일로 표시된다.

2. 구체적인 승자 교체

   1. 6월 3일에는 Kimi 2.6이 하네스에서 압도적으로 가장 많이 선택됐다.
   2. 6월 21일에는 Minimax 3이 가장 많이 선택되는 모델이 됐다.
   3. 사람은 새 모델을 발견하고 테스트하고 신뢰하기까지 시간이 걸리지만, 비용과 결과에 집착하는 자율 하네스는 선택 분포를 즉시 바꿀 수 있다.

4. Kimchi 하네스의 내부 구조와 장시간 코딩

Kimchi 하네스는 모델 라우터에 그치지 않고, 장시간 작업을 쪼개고 채점하고 다시 실행하는 자동화된 개발 루프를 제공한다.

4.1. 비용 폭증에서 자체 하네스로

1. 만들 수밖에 없었던 이유

   1. 무제한 토큰 사용은 기업 입장에서 더 이상 당연한 전제가 아니며, Kimchi 팀도 약 반년 전 클라우드 코드 사용량이 지나치게 커지는 상황을 경험했다.
   2. 클라우드 청구서가 급격히 상승하자 팀은 자체 하네스를 만들기 시작했다.

2. 오픈소스 기반의 접근

   1. 내부적으로는 Pono SDK를 사용하는 구조를 바탕으로 했다.
   2. Kimchi 팀은 자체 구현물을 다시 오픈소스에 기여하려고 하며, Kimchi 테마에 맞는 오픈소스 구성 요소를 제공한다.

4.2. Ferment의 장시간 작업 루프

1. 사람의 개입 주기를 전제로 한 설계

   1. 장시간 작업에서는 사람이 확인하거나 답할 수 있는 주기가 평균 2~3시간마다 한 번인 경우가 많다.
   2. Ferment라는 구성 요소는 이 간격을 전제로 2시간 이상 걸리는 코딩 작업을 자율적으로 실행한다.

2. 마일스톤 기반 실행

   1. Ferment 프로세스는 시작할 때 여러 질문을 사용자에게 묻고, 작업을 구현 가능한 마일스톤으로 나눈다.
   2. 각 마일스톤을 순서대로 실행한 뒤 사이클 마지막에 결과 점수를 계산한다.
   3. 사용자는 에이전트가 무엇을 했는지와 결과가 어느 정도인지 점수로 확인할 수 있다.

3. 모델 선택을 품질 점수로 검증하기

   1. 어떤 모델이 선택됐는지보다 중요한 것은 선택된 모델이 구현 결과에서 충분한 점수를 냈는지다.
   2. 하네스의 점수는 비용을 아끼기 위해 모델을 바꾸더라도 결과 품질이 유지됐다는 사실을 검증하는 장치다.

4.3. 변경부터 스테이징까지 이어지는 소프트웨어 개발 수명주기

1. 자동 반복 루프

   1. 사용자가 변경을 요청하면 Kimchi가 빌드를 실행하고, 무엇인가 깨졌는지 확인한다.
   2. 문제가 발견되면 다시 변경하고, 다시 빌드하고, 다시 검증한다.
   3. 이 반복이 Ferment가 장시간 작업을 처리하는 기본 방식이다.

2. 스테이징 배포와 완성 조건

   1. 작업이 완성되면 변경 사항은 스테이징 환경에 배포된다.
   2. 산출물은 채점 결과가 최소 B가 되어야 완료로 간주된다.
   3. 사용자가 B 점수에 만족하지 않으면 에이전트에게 다시 고치라고 요청해 A 점수를 목표로 재실행할 수 있다.

3. 상위 모델의 품질 감시

   1. Ferment는 작업 결과의 품질을 지속적으로 확인한다.
   2. 더 높은 수준의 모델이 코드를 평가하고 품질이 충분하지 않다고 판단하면 “다시 해라”라고 지시한다.
   3. 이 구조가 결과 품질을 기준으로 토큰을 최적화하는 핵심이다.

4.4. 프로덕션 배포에는 아직 사람을 남겨 두기

1. 현재는 스테이징에서 멈추는 이유

   1. Kimchi는 아직 프로덕션으로 자동 배포하지 않고 스테이징까지만 진행하도록 설계돼 있다.
   2. 최소한 현재 시점에는 프로덕션에 들어가기 전 작은 수준이라도 사람이 검토해야 한다는 판단 때문이다.

2. 향후 자동 배포에 필요한 검증

   1. 프로덕션에 배포한 뒤 메트릭과 관측성(observability) 데이터를 확인해야 한다.
   2. Kubernetes를 사용한다면 파드가 충돌하지 않는지, 애플리케이션 헬스 체크가 통과하는지 확인해야 한다.
   3. 이런 운영 신호까지 자동으로 점검한 뒤에야 프로덕션 배포를 자동화할 수 있으며, 이는 향후 확장 영역이다.

5. 코드만 읽는 리뷰에서 의도와 사양을 검증하는 리뷰로

에이전트가 만드는 변경량이 커질수록 사람이 코드 줄만 읽는 방식은 병목이 되므로, 요구사항과 의도를 함께 검토해야 한다.

5.1. 에이전틱 엔지니어링이 만든 리뷰 부담

1. 변경 세트의 폭증

   1. 바이브 엔지니어링(vibe engineering)과 에이전틱 엔지니어링(agentic engineering)을 많이 사용할수록 코드 변경량과 변경 세트가 커진다.
   2. 변경 세트가 계속 커지면 모든 코드를 읽는 일은 감당하기 어려워진다.

2. 비개발자도 코딩 에이전트를 쓰는 상황

   1. 제품 관리자가 직접 코딩하거나 비개발 직군이 파이프라인에 참여할 수 있다.
   2. 예시로 Laura가 코딩을 시작해 2,000줄짜리 PR을 만들면, 리뷰어는 단순히 diff를 확인하는 것을 넘어 무엇을 만들려 했는지와 에이전트에게 전달한 사양을 검토해야 한다.

5.2. 산출물보다 의도와 요구사항을 함께 검토하기

1. 리뷰의 대상 확장

   1. 좋은 리뷰는 코드가 바뀐 줄만 확인하는 것이 아니라 원래의 의도와 요구사항이 구현 결과에 반영됐는지 확인한다.
   2. Kimchi Studio는 에이전트가 실행하기 전에 계획을 공유해 이 검토를 앞당기는 방향으로 설계된다.

2. 잘못된 사양을 조기에 차단하기

   1. 터미널에서 프롬프트를 입력하고 곧바로 프로덕션에 실행한 다음에야 사양이 틀렸음을 발견하는 흐름은 피해야 한다.
   2. 계획과 진행 중인 작업을 동료와 먼저 공유하면 잘못된 요구사항과 원하지 않은 결과를 구현 초기에 발견할 수 있다.

6. Kimchi Teleport: 노트북을 닫아도 계속되는 에이전트

Teleport는 개인 개발 환경을 보안 원격 샌드박스로 옮겨, 장시간 에이전트 작업이 노트북 배터리·네트워크·사용자의 이동에 묶이지 않게 한다.

6.1. 원격 샌드박스와 배포 선택지

1. 로컬 환경을 원격 세션으로 이동하기

   1. 사용자가 노트북을 닫으면 Teleport가 원격 환경에 보안 샌드박스를 띄운다.
   2. 사용자는 SaaS 플랫폼에서 실행할 수도 있고, 금융 기술 기업처럼 온프레미스(on-premise) 배포가 필요한 조직에는 자체 환경에 설치할 수도 있다.

2. 세션 관리

   1. Kimchi가 에이전트 세션을 관리하고 세션이 계속 실행되도록 보장한다.
   2. 사용자는 노트북이나 모바일 기기에서 백그라운드 세션에 접근할 수 있다.
   3. 원격 환경은 적절한 크기와 보안 요구사항을 맞춰 구성되고, 작업이 끝나거나 사람의 개입이 필요할 때까지 계속 실행된다.
   4. 사양 확인이나 추가 설명이 필요하면 사람에게 알림을 보낸다.

6.2. 비행기에서 시작된 단순한 아이디어

1. 문제의 출발점

   1. 팀원 한 명이 비행기에서 코딩하다가 연결이 끊기거나 배터리가 다해 작업이 멈춘 경험이 아이디어의 출발점이 됐다.
   2. 발표 중에는 Wi-Fi가 끊긴 것이었는지 배터리가 나간 것이었는지를 두고 짧은 농담이 오간다.

2. Teleport의 작동 방식

   1. 노트북의 개발 환경을 하이퍼스케일러 내부의 컨테이너와 동기화한다.
   2. Kimchi의 경우 Google 환경의 Kubernetes 클러스터 안에서 컨테이너가 실행된다.
   3. 로컬에서 쓰는 것과 느낌은 같지만 실제 에이전트 프로세스는 노트북 안이 아니라 원격 컨테이너에서 동작한다.
   4. 노트북을 닫아도, 이동 중이어도, 휴가 중이어도 컨테이너가 작업을 계속 실행한다.

3. 사용 확산 수치

   1. 발표 시점에 Kimchi 엔지니어의 62%가 코딩할 때 Teleport를 사용하고 있었다.
   2. 팀은 단순하지만 개발 흐름을 끊는 배터리와 이동 문제를 제거한 것이 Teleport의 가장 큰 장점이라고 평가한다.

7. Kimchi Studio: 개인 세션을 팀의 작업 보드로

Studio는 개인용 Teleport를 팀·엔터프라이즈 협업으로 확장해, 실행 중인 에이전트 세션과 계획을 브라우저에서 공유하게 한다.

7.1. 개인용 Teleport와 팀용 Studio의 차이

1. 팀의 공유 보드

   1. Teleport가 개인 사용자를 위한 원격 실행 환경이라면, Studio는 팀을 위한 Teleport라고 볼 수 있다.
   2. Studio는 보안 Teleport 샌드박스 위에서 실행되며, 작업·진행 중인 결과·계획을 팀 보드처럼 보여준다.

2. 모델 선택의 개방성

   1. Kimchi 코딩 하네스는 오픈소스 모델과 proprietary 모델을 모두 사용할 수 있다.
   2. 팀은 특정 모델 이름을 공유하는 것보다 각 작업의 계획과 진행 상태, 결과를 함께 검토하는 데 집중한다.

7.2. 계획을 먼저 공유하는 에이전틱 협업

1. 계획 리뷰 흐름

   1. 엔지니어가 작업을 시작하고 에이전트에게 계획을 요청하면 그 계획을 동료 엔지니어, 제품 관리자, 관련 이해관계자가 검토할 수 있다.
   2. 잘못된 요구사항을 프로덕션에 실행한 뒤 뒤늦게 발견하는 대신, 계획 단계에서 방향을 수정한다.

2. CLI 공유 문제의 해결

   1. 터미널이나 CLI만 있으면 다른 사람이 그 세션을 보거나 이어받기 어렵고, 세션을 먼저 어딘가에 띄워 두어야 한다.
   2. Teleport가 실행 기반을 제공하고 Studio가 그 위에서 세션을 시각화한다.
   3. 검토가 필요한 세션을 팀원이 선택해 질문에 답하면, 세션은 다시 진행 중 상태로 돌아가고 다음 검토 시점까지 계속된다.

3. 칸반식 작업 관리

   1. 브라우저의 그래픽 화면에서 리뷰 대기, 진행 중, 백로그에 있는 작업을 확인할 수 있다.
   2. 5~10명 규모의 이른바 피자 팀(pizza team)이 여러 세션을 공유하고 각자 작업을 인수할 수 있다.
   3. 한 사람이 노트북을 닫아도 원격 세션은 계속 실행된다.

7.3. 공개와 설치 방식

1. 오픈소스 범위

   1. Kimchi 하네스는 전부 오픈소스로 공개돼 있다.
   2. Studio와 Teleport도 제품으로 제공되며, 사용하려면 Google 계정이 필요하다.

2. 설치와 데모 안내

   1. Google 계정 기반 설치는 조금 더 복잡하지만 약 5분이면 끝난다.
   2. 설치 후 Google 계정 안에서 원하는 만큼 Teleport 세션을 만들고 동료와 Kimchi Studio로 공유할 수 있다.
   3. 발표자들은 행사장 U4 부스에서 제품을 직접 확인할 수 있다고 안내하며 발표를 마무리한다.

주요 발언 모음

“우리의 일은 개발자가 코딩 에이전트를 쓰지 못하게 막는 것이 아니라, 원하는 만큼 오래 완전히 무제한으로 쓰게 하는 것이다.”

“토큰당 비용이 아니라 같은 결과를 얻는 작업당 비용을 봐야 한다. 그렇지 않으면 사과와 사과를 비교할 수 없다.”

“사람은 새 모델을 찾아 테스트하고 익숙해질 수 있지만, 비용에 집착하는 자율 하네스는 바로 그렇게 할 것이다.”

“산출물은 채점 결과가 최소 B가 되어야 완료로 간주된다. 점수가 마음에 들지 않으면 에이전트에게 다시 고쳐 A를 시도하게 할 수 있다.”

“노트북을 닫아도 계속된다.”

핵심 데이터 & 수치

• 5억 달러: 한 인도 기업이 한 달 동안 Anthropic에만 사용한 것으로 소개된 금액이다.
• 4개월: Uber CTO가 Anthropic의 1년 예산 전체를 소진했다고 말한 기간이다.
• 직원 300명: Kimchi 조직 규모이며, 약 3분의 2가 개발자다.
• 3개월: Kimchi 코딩 에이전트를 실제로 사용해 결과를 측정한 기간이다.
• $3.5/100만 토큰과 약 $75/작업: Gemini 3 Flash의 토큰 단가와 같은 품질 작업을 끝내는 비용의 대비다.
• $1.5/토큰과 $148/작업: Minimax 2.7의 토큰 단가와 작업 단위 비용의 대비다.
• 2.5배 절감: 약 3개월 동안 Kimchi가 얻었다고 제시한 비용 절감 결과다.
• 토큰 1.5배 증가, 코딩 비용 1.5배 감소: 사용량을 제한하지 않고 모델 선택을 최적화한 결과다.
• 6월 3일과 6월 21일: 주력 선택 모델이 Kimi 2.6에서 Minimax 3으로 바뀐 사례의 비교 시점이다.
• 2~3시간: 장시간 작업에서 사람이 확인하거나 개입하는 평균 간격이다.
• B와 A: Ferment 산출물의 최소 완료 점수와 사용자가 재작업으로 목표할 수 있는 점수다.
• 2,000줄: 비개발자도 코딩 에이전트를 사용하면 생성될 수 있다고 든 PR 규모의 예시다.
• 62%: 발표 당시 코딩에 Teleport를 사용하는 Kimchi 엔지니어의 비율이다.
• 5분: Google 계정 기반 Teleport 설치에 걸리는 대략적인 시간이다.
• 5~10명: Studio가 협업 대상으로 상정한 피자 팀의 규모다.

결론 및 시사점

1. 토큰 제한을 비용 관리의 기본값으로 삼지 말아야 한다: 개발자의 사용량을 억누르면 에이전트의 탐색·반복·검증 능력도 함께 줄어드므로, 작업당 품질과 비용을 측정해 무제한에 가까운 사용 환경을 만드는 편이 생산적이다.
2. 모델 라우팅의 목표는 최저 단가가 아니라 최저 작업 비용이다: 싼 토큰을 쓰는 모델이 긴 출력과 재시도를 요구하면 전체 작업은 비싸질 수 있으므로, 결과 점수와 총비용을 함께 평가해야 한다.
3. 자동 하네스에는 품질 게이트가 필요하다: Ferment처럼 마일스톤, 빌드 검증, 재작업, 점수 판정을 연결하면 모델 선택이 비용 절감 때문에 품질을 희생하는지 확인할 수 있다.
4. 스테이징까지의 자동화와 프로덕션 이전의 운영 검증을 분리해야 한다: 현재는 사람이 메트릭·관측성·Kubernetes 헬스 상태를 확인한 뒤 배포하고, 향후 이 신호들을 자동화해 프로덕션까지 확장한다.
5. 에이전트 시대의 코드 리뷰는 의도 리뷰가 되어야 한다: 변경량이 2,000줄까지 커질 수 있는 환경에서는 diff만 읽는 대신 계획·사양·제품 의도가 맞는지 먼저 검토해야 한다.
6. 원격 실행은 장시간 에이전트의 전제 조건이다: Teleport처럼 세션을 보안 컨테이너로 옮기면 배터리, Wi-Fi, 이동 시간에 관계없이 에이전트가 작업을 계속한다.
7. 팀 협업은 프롬프트 공유가 아니라 상태와 계획 공유로 확장된다: Studio는 리뷰 대기·진행 중·백로그를 보여주고 팀원이 세션을 인수하게 해 에이전틱 엔지니어링을 조직 프로세스에 연결한다.
8. 오픈소스 하네스와 선택 가능한 모델 조합이 확장성을 만든다: 하네스가 특정 모델에 고정되지 않으면 새 모델의 비용·품질 변화가 선택 정책에 자동으로 반영될 수 있다.

핵심 요약 (20줄)

기업의 LLM 비용 폭증은 개발자에게 토큰을 덜 쓰라고 지시하는 방식만으로 해결되지 않는다. 토큰을 제한하는 일은 한 시간짜리 배터리를 하루에 한 번만 충전하게 하는 것처럼 개발자의 작업 흐름을 끊는다. 관리자의 책임은 코딩 에이전트 사용을 막는 것이 아니라 토큰을 무제한에 가깝고 저렴하게 만드는 것이다. Kimchi는 직원 300명과 약 3분의 2의 개발자로 구성된 조직에서 자체 코딩 에이전트를 3개월간 운영했다. 같은 품질의 작업을 비교하면 토큰당 가격이 낮은 모델이 작업당 비용까지 낮다는 보장은 없다. Gemini 3 Flash는 토큰 단가는 약 3.5달러지만 같은 품질의 작업을 끝내는 비용은 약 75달러로 제시됐다. Minimax 2.7은 토큰 단가가 약 1.5달러여도 작업당 비용은 148달러가 될 수 있다. Kimchi 하네스는 작업 결과의 품질과 총비용을 보고 적절한 모델을 자동으로 선택한다. 모델 선택은 6월 초 Kimi 2.6에서 6월 말 Minimax 3으로 빠르게 이동할 수 있었다. 사람이 새 모델을 시험하고 신뢰하는 동안 비용에 집착하는 자율 하네스는 선택을 즉시 바꾼다. 약 3개월의 운영에서 토큰 사용량은 1.5배 늘었지만 코딩 비용은 1.5배 줄었다. Kimchi는 모델 선택 최적화로 비교 기준 대비 2.5배의 비용 절감 효과를 제시했다. Ferment는 질문과 마일스톤을 바탕으로 2시간 이상 걸리는 장시간 코딩 작업을 자율 실행한다. Ferment는 빌드와 검증을 반복하고 품질이 부족하면 상위 모델의 판단에 따라 코드를 다시 작성한다. 산출물은 최소 B 점수를 받아야 완료되며 사용자는 A 점수를 목표로 재작업을 요청할 수 있다. 현재 자동화는 스테이징에서 멈추고 프로덕션 배포 전에는 메트릭과 Kubernetes 상태를 사람이 확인한다. 에이전트가 만드는 변경량이 커지면서 코드 diff뿐 아니라 구현 의도와 원래 사양을 검토해야 한다. Teleport는 개발 환경을 Google Kubernetes 클러스터의 보안 컨테이너로 옮겨 노트북을 닫아도 작업을 계속한다. Kimchi 엔지니어의 62%는 이동이나 휴가 중에도 에이전트를 실행하기 위해 Teleport를 사용한다. Studio는 팀이 리뷰 대기·진행 중·백로그 세션을 공유하고 작업을 인수하게 하는 브라우저 기반 협업 공간이다.