[한영자막] 토큰 제한을 멈추세요: 하네스가 최적의 모델을 직접 고르게 해보세요

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

토큰 사용을 제한하기보다 하네스가 작업 결과의 품질과 비용을 평가해 적합한 모델을 고르게 하자는 것이 Kimchi의 제안이다.

📌 핵심 요점

1. 토큰 제한은 개발자의 코딩 에이전트 활용을 막는다. 발표자들은 사용량을 억제하기보다 같은 결과를 더 낮은 비용으로 얻는 구조가 필요하다고 주장한다.
2. 모델 비교의 기준은 토큰 단가뿐 아니라 동일한 품질의 작업을 완료하는 데 드는 비용이어야 한다. 낮은 토큰 단가가 낮은 작업 비용을 보장하지는 않는다.
3. Kimchi 하네스는 작업과 결과에 따라 모델을 자동 선택한다. 발표자들은 3개월간 사용하면서 토큰 사용량 증가와 비용 감소를 동시에 경험했다고 설명한다.
4. Ferment는 장시간 작업을 마일스톤으로 나누고, 빌드·수정·결과 평가를 반복한다. 완료 기준은 최소 B 등급이며, 현재 자동 배포는 스테이징에서 멈춘다.
5. Teleport는 원격 샌드박스에서 세션을 계속 실행하고, Studio는 팀이 계획·진행 상황·검토 요청을 공유하도록 한다. 모델 선택에서 실행 지속성과 협업까지 개발 흐름을 확장한 제품 구성이다.

🧩 배경과 문제 정의

Castai 공동창업자이자 사장이라고 소개한 Laura와 Kimchi 엔지니어링 담당자가 자사 코딩 플랫폼을 설명하는 발표다. 출발점은 코딩 에이전트 사용 확대에 따른 비용 증가와 이에 대응하는 기업의 토큰 제한이다. 발표자들은 제한이 개발자의 작업을 중단시키므로, 작업 결과의 품질을 유지하면서 비용을 줄이는 하네스가 필요하다고 주장한다.

발표는 일반 작업에 오픈소스 모델을 활용하고 예외적인 작업에는 독점 모델을 쓰는 방향을 제시한다. 이를 자동 모델 선택, 장시간 작업 평가, 원격 실행, 팀 협업으로 연결하며, 내부 사용 성과와 제품 기능을 소개한다. 성과 수치와 품질 설명은 발표자의 주장으로 구분해서 읽어야 한다.

🕒 시간순 섹션별 상세정리

1. 발표자 소개와 모델 활용 방향

• Laura는 Castai 공동창업자이자 사장으로 자신을 소개하고, Kimchi 코딩 플랫폼의 엔지니어링 담당자와 함께 발표한다. [00:27]
• 예외적인 작업과 나머지 작업에 서로 다른 모델군을 활용하는 접근을 소개하며, Kimchi에서 얻은 결과를 보여주겠다고 예고한다. [00:33]

2. 비용 급증에 대한 토큰 제한의 문제

• 인도 기업의 Anthropic 지출과 Uber CTO의 예산 관련 발언을 인용해 기업의 토큰 비용 부담을 보여준다. 인용 사례의 원문은 제공되지 않는다. [01:12]
• 개발자에게 토큰을 제한하는 상황을 하루 한 번만 충전할 수 있는 짧은 배터리 수명의 노트북에 비유한다. 관리자의 역할은 에이전트 활용을 가능하게 하는 것이라고 주장한다. [02:15]
• 직원 수는 처음 언급한 개발자 300명에서 직원 300명으로 정정하며, 그중 약 3분의 2가 개발자이고 코딩 에이전트를 3개월간 사용했다고 보여준다. [02:44]

3. 토큰 단가와 작업 완료 비용의 차이

• 대학 연구의 비교 자료라고 소개하며, 모델은 같은 작업과 같은 품질을 기준으로 비용을 비교해야 한다고 강조한다. [03:21]
• Gemini 3 Flash는 백만 토큰당 혼합 평균 3.5달러와 작업당 75달러를, Minimax 2.7은 토큰 단가 1.5와 작업당 148달러를 제시한다. 수치의 조건과 연구 출처는 상세히 설명하지 않는다. [03:59]
• 낮은 토큰 단가만으로 작업 비용을 판단할 수 없으므로, 작업과 결과에 맞춰 모델을 고르는 자동 하네스가 필요하다고 연결한다. [04:32]

4. 내부 비용 성과와 자동 모델 선택의 변화

• 3개월 사용 결과로 2.5배 절감 효과를 언급하고, 예상 비용과 실제 지출을 비교한 그래프에서 같은 결과를 얻었다고 보여준다. [05:04]
• 토큰 사용량은 1.5배 증가했고 코딩 비용은 1.5배 감소했다고 주장한다. 다만 지표별 기준과 계산식은 제시하지 않는다. [05:38]
• 6월 초와 하순의 모델 선택 비중이 크게 바뀐 사례를 보여주며, 사람이 매번 새 모델을 시험하는 대신 하네스가 선택을 조정한다고 보여준다. 이어 오픈소스 구현 소개로 넘긴다. [07:14]

5. 자체 하네스와 Ferment의 장시간 작업

• 엔지니어링 담당자는 약 반년 전 비용 급증을 경험한 뒤 자체 하네스를 만들었고, 오픈소스에 기여하는 방향으로 개발했다고 보여준다. [07:57]
• Ferment는 먼저 질문을 받고 작업을 마일스톤으로 나눠 두 시간 이상 자율 실행하는 구상이다. 사람의 개입 간격은 보통 두세 시간으로 추정한다고 드러낸다. [08:27]
• 작업 주기 끝에 결과를 채점하며, 선택한 모델이 해당 작업에서 충분한 품질을 내는지 확인하는 장치로 평가를 보여준다. [08:46]

6. 빌드·수정·평가를 묶은 완료 기준

• 코드 변경 뒤 빌드를 실행하고 문제가 있으면 수정과 빌드를 반복한다. 추가 수정이 필요하지 않으면 스테이징 환경에 배포한다. [09:17]
• 상위 모델이 코드 품질을 평가하고 부족하면 다시 작업하도록 하며, 결과 품질에 맞춰 토큰 사용을 최적화한다고 보여준다. [09:48]
• 산출물은 최소 B 등급을 받아야 완료로 간주한다. 사용자는 추가 수정을 요청해 A 등급을 목표로 삼을 수 있다. [10:05]

7. 프로덕션 배포의 한계와 검토 대상의 변화

• 현재 스테이징에서 멈추는 것은 의도한 설계다. 프로덕션에 보내기 전에는 사람의 개입이 필요하다고 보여준다. [10:16]
• 향후 자동 배포에서는 운영 지표와 관측 데이터, Kubernetes 파드 상태, 애플리케이션 헬스 체크 등을 확인하는 방향을 제시한다. [10:45]
• 에이전트가 생성하는 변경량이 커지면 코드 차이만 읽기 어려워진다. 2,000줄 PR 사례를 들어 작성 의도와 에이전트에 전달한 명세까지 검토해야 한다고 강조한다. [11:30]

8. Teleport의 원격 실행과 개입 알림

• Kimchi Teleport는 원격 샌드박스를 띄워 노트북을 닫아도 세션이 계속 실행되도록 한다. SaaS와 온프레미스 제공 가능성을 보여준다. [11:58]
• 노트북과 모바일에서 접근할 수 있으며, 작업 완료 또는 사람의 개입이 필요한 시점까지 실행을 이어간다고 드러낸다. [12:29]
• 명세를 명확히 해야 하는 상황에는 알림을 보내 사람이 다시 참여하도록 한다. [12:34]

9. Teleport의 개발 계기와 내부 활용

• 비행 중 코딩이 중단된 경험에서 기능이 나왔다고 설명하며, 중단 원인은 처음 말한 Wi-Fi에서 배터리 문제로 정정한다. [13:09]
• 로컬 환경을 원격 컨테이너와 동기화하고, 자사 사례에서는 Google의 Kubernetes 환경에서 노트북 종료 후에도 작업이 계속된다고 보여준다. [13:43]
• 최근 확인한 수치로 엔지니어의 62%가 코딩할 때 Teleport만 사용한다고 주장하며, 이동하거나 자리를 비워도 실행이 이어지는 장점을 강조한다. [14:09]

10. Studio를 통한 팀 계획 공유와 검토

• Kimchi Studio를 팀과 기업을 위한 Teleport로 보여준다. 원격 샌드박스에서 실행하는 작업·진행 상황·계획을 팀에 공유하는 보드를 제공한다. [14:41]
• 동료 엔지니어와 제품 담당자가 계획을 검토하게 해, 잘못된 요구 사항을 구현 후에 발견하는 상황을 줄이려는 목적을 보여준다. [15:14]
• 팀원이 검토 요청을 맡아 답하면 작업이 다시 진행된다. 브라우저에서 백로그·진행·검토 상태를 공유하고 작업을 이어받을 수 있다고 보여준다. [16:43]

11. 공개 범위와 설치 안내로 마무리

• 발표를 마치며 부스 방문을 안내하고, 하네스는 전부 오픈소스라고 다시 보여준다. [17:10]
• Teleport와 Studio에는 Google 계정이 필요하며 약 5분 설치를 언급한다. 계정 안에 여러 세션을 만들고 Studio로 동료와 공유할 수 있다고 안내한다. [17:28]
• 추가 대화를 권하고 두 발표자가 감사 인사로 발표를 마친다. [17:36]

🧾 결론

• 발표의 핵심은 토큰을 적게 쓰는 것 자체보다 요구한 품질의 결과를 경제적으로 얻는 데 있다.
• 자동 모델 선택의 효과를 판단하려면 결과 평가와 재작업 과정까지 함께 살펴봐야 한다.
• 원격 실행과 팀 검토 기능은 장시간 에이전트 작업을 실제 개발 조직의 업무 흐름에 연결한다.
• 비용 절감 수치와 품질 보장은 공급자의 내부 사례로 제시됐다. 일반적인 효과로 받아들이기 전에 산정 기준과 적용 조건을 확인해야 한다.

📈 투자·시사 포인트

• 기업의 AI 비용 관리에서는 토큰 단가 외에 완료 작업당 비용을 측정하는 역량이 중요해질 수 있다.
• 모델 선택이 자동화되면 특정 모델의 우위가 고정되기보다 작업 결과와 비용에 따라 이용 비중이 이동할 수 있다. 발표의 6월 모델 선택 변화가 이를 보여주는 내부 사례다.
• 하네스의 경쟁력을 평가할 때는 모델 연결 수뿐 아니라 결과 평가, 재시도, 빌드 검증, 배포 연결 기능을 함께 볼 필요가 있다.
• 장시간 원격 실행과 팀 협업은 코딩 에이전트 도입 범위를 넓힐 수 있지만, 발표만으로 수익성이나 시장 규모를 판단할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 인도 기업의 월 5억 달러 지출과 Uber의 연간 예산 조기 소진 사례는 발표자의 인용이다. 원문과 지출 범위가 제공되지 않아 사실관계 확인이 필요하다.
• 모델별 비용 비교에 사용한 대학 연구의 제목, 작업 종류, 품질 기준, 가격 적용 시점이 제시되지 않았다. Gemini 3 Flash와 Minimax 2.7의 수치를 현재 가격이나 일반적인 성능 비교로 확대할 수 없다.
• ‘2.5배 절감’, ‘토큰 1.5배 증가’, ‘코딩 비용 1.5배 감소’의 기준과 계산식이 설명되지 않았다. 예상 청구액과 실제 청구액의 비교 조건도 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 대표 코딩 작업을 정하고, 동일한 품질 기준 아래 단일 모델 사용과 자동 모델 선택의 완료 작업당 비용을 비교한다.
• 비용 집계에 재시도와 평가 호출을 포함하고, Teleport를 사용할 경우 원격 실행 비용도 함께 측정한다.
• Ferment의 점수 기준과 빌드 검증 방식을 확인하고, 사람이 검토한 결과와 평가 등급이 얼마나 일치하는지 점검한다.
• 하네스의 저장소·라이선스와 Teleport·Studio의 설치 조건, Google 계정 요구 사항, 온프레미스 지원 범위를 확인한다.

❓ 열린 질문

• 하네스는 어떤 작업 특성과 결과 지표를 이용해 모델을 선택하며, 새 모델의 품질을 어떻게 검증하는가?
• 최소 B 등급은 기능 정확성·유지보수성·보안 가운데 무엇을 어느 수준까지 보장하는가?
• 모델 선택과 재작업에 필요한 추가 비용을 포함해도 발표의 절감 효과가 다른 개발 조직에서 재현되는가?