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

URL: https://www.youtube.com/watch?v=31XD1O74pks 날짜: 2026-10-07 채널: Tech Bridge 출연 조직: Cast AI 발표자: Laura(Cast AI 공동 창업자·CEO), Žilvinas(Cast AI 플랫폼 엔지니어링 책임자) 영상 길이: 17분 39초

---

메타데이터

• video_id: 31XD1O74pks
• title_original: [한영자막] 토큰 제한을 멈추세요: 하네스가 최적의 모델을 직접 고르게 해보세요
• source: Tech Bridge
• published_at: 2026-10-07
• 주제: 코딩 에이전트(Coding Agent), LLM 하네스(Harness), 작업당 비용(Cost per Task), 오픈소스 모델 라우팅, 원격 샌드박스
• 관련 프로젝트: Kimchi, Ferment, Kimchi Teleport, Kimchi Studio
• 관련 링크:
  • Kimchi: https://kimchi.dev/
  • GitHub: https://github.com/getkimchi/kimchi
  • Cast AI: https://cast.ai
  • AI Engineer: https://ai.engineer

---

📌 핵심 질문 / 이 발표가 던지는 핵심 논점

==개발자에게 제공할 것은 토큰 사용량 제한이 아니라, 결과 품질을 지키면서 작업마다 가장 적합한 모델을 고르는 하네스와 충분히 저렴한 실행 환경이어야 한다.==

• 토큰당 가격만 비교하면 모델 간 실제 작업 비용과 품질 차이를 놓치게 된다.
• Kimchi는 작업 결과를 채점하고 그 점수에 맞춰 여러 상용·오픈소스 모델을 자동 선택한다.
• 토큰 사용량은 늘어도 같은 품질의 결과를 더 낮은 클라우드 비용으로 얻을 수 있다.
• Ferment는 장시간 자율 코딩을 빌드·검증·수정·스테이징 배포 루프로 연결한다.
• Teleport와 Studio는 에이전트 세션을 원격에서 계속 실행하고 팀 단위로 공유·검토하게 한다.

토큰은 개발자의 활동을 막기 위한 예산 상한이 아니라 결과를 얻기 위한 입력 자원이다. 비용 관리의 단위도 토큰에서 작업(task)으로 옮겨야 한다. 하네스가 모델 선택, 품질 검증, 실행 환경, 협업 흐름을 함께 책임지면 개발자는 특정 모델의 토큰 한도에 맞춰 작업을 잘라내지 않아도 된다.

1. 토큰 비용 폭증과 잘못된 대응

1.1. 시장에서 드러난 토큰 사용량 문제

1. 대규모 사용 사례가 빠르게 나타남

   1. 인도의 한 회사가 Anthropic에 한 달 동안 수백만 달러 규모를 지출했다는 사례가 소개된다.
   2. 이 사례는 코딩 에이전트가 한 번의 질의가 아니라 장시간의 연속 작업을 수행할 때 토큰 비용이 얼마나 커질 수 있는지 보여준다.

2. 기업 예산이 짧은 기간에 소진됨

   1. Uber CTO의 유명한 게시물이 또 다른 사례로 언급된다.
   2. 1년 동안 쓸 예정이던 AI 예산을 불과 4개월 만에 모두 사용했다는 상황이 토큰 소비의 급격한 증가를 드러낸다.

1.2. 토큰 상한이 개발 경험을 훼손하는 이유

1. 토큰 제한은 노트북 사용 시간을 강제로 줄이는 것과 같음

   1. 개발자에게 토큰 개수를 제한하는 방식은 “노트북은 써도 되지만 배터리가 1시간뿐이고 하루에 한 번만 충전하라”고 말하는 것과 비슷하다.
   2. 개발자는 작업의 중요도나 결과 품질이 아니라 남은 토큰에 맞춰 에이전트의 행동을 멈추게 된다.

2. 관리자가 맡아야 할 문제의 방향

   1. Cast AI의 관리 책임은 개발자가 에이전트를 사용하는 것을 막는 일이 아니다.
   2. 개발자가 원하는 기간 동안 원하는 방식으로 에이전트를 사용하되, 결과는 동일한 수준으로 유지하고 토큰당 비용은 낮추는 환경을 제공하는 일이다.

3. 무제한성의 의미

   1. 여기서 무제한(unlimited)은 모델 하나에 무조건 많은 돈을 쓰겠다는 뜻이 아니다.
   2. 작업에 맞는 모델을 자동으로 고르고, 필요할 때 충분한 추론과 반복을 허용해 개발자의 작업을 중단시키지 않는다는 뜻이다.

2. 작업당 비용으로 바꾸는 모델 선택

2.1. Cast AI의 내부 사용 환경

1. 개발자 중심 조직에서 검증

   1. Cast AI에는 직원 약 300명이 있고, 그중 약 3분의 2가 개발자다.
   2. Žilvinas가 이 개발 환경을 관리하며, 팀은 약 3개월 동안 프로그래밍 에이전트를 실제 업무에 사용해 왔다.

2. 여러 모델을 하나의 실행 체계에 연결

   1. 내부 SDK에는 다섯 가지 모델이 연결되어 있다.
   2. 특정 모델을 모든 작업에 고정하지 않고, 오픈소스 모델의 장점과 상용 모델의 성능을 함께 활용하는 것이 목표다.

2.2. 토큰당 비용과 작업당 비용의 차이

1. 단가 비교만으로는 사과와 오렌지를 비교하게 됨

   1. 같은 작업을 여러 LLM 모델에 시켰을 때 모델마다 토큰당 가격이 다르다.
   2. 모델마다 한 작업을 완료하는 데 필요한 토큰 수와 결과 품질도 다르므로, 토큰당 가격만으로는 실제 비용을 비교할 수 없다.

2. 품질이 같은 결과를 기준으로 비교해야 함

   1. 합리적인 비교 단위는 같은 작업에서 충분히 좋은 결과를 얻기까지 들어간 비용이다.
   2. 따라서 ‘백만 토큰당 가격’보다 ‘작업 하나를 품질 기준까지 완료하는 비용(Cost per Task)’이 의사결정에 더 직접적이다.

3. 수치가 보여주는 차이

   1. Gemini 3 계열은 토큰당 약 3.50달러 수준으로 표시되지만, 실제 작업을 끝내는 비용은 약 705달러로 제시된다.
   2. MiniMax 2.7은 토큰당 약 1.5달러로 더 저렴해 보여도 작업당 비용은 약 148달러이며, 단가와 작업 비용의 순위가 일치하지 않는다.
   3. 같은 품질 기준을 통과하는지까지 포함해야 모델의 진짜 경제성을 알 수 있다.

2.3. 자동 모델 선택 하네스

1. 작업에 맞는 모델을 런타임에 선택

   1. Kimchi는 엔진이 작업을 보고 적절한 모델을 자동으로 선택하는 하네스다.
   2. 모델 선택 기준은 단순한 가격이 아니라 작업 결과의 품질과 그 결과를 얻는 시간·비용이다.

2. 인간의 모델 탐색을 자동화

   1. 사람은 새 모델을 발견할 때 직접 찾아보고, 이해하고, 시험하고, 마음에 드는지 판단해야 한다.
   2. 하네스는 이런 탐색을 지속적으로 자동화해 모델 생태계가 바뀔 때마다 실행 구성을 조정한다.

3. 모델 사용률은 고정되지 않음

   1. 6월 초에는 Kimi 2.6이 가장 인기 있는 선택지로 앞섰다.
   2. 6월 21일 무렵에는 MiniMax 3가 우세한 선택지로 바뀌었다.
   3. 사람은 짧은 기간에 이런 변화를 계속 따라가기 어렵지만, 하네스는 작업별 점수와 비용에 따라 선택을 바꿀 수 있다.

4. 자동 선택의 책임

   1. 개발자에게 같은 품질의 결과를 토큰당 적절한 비용으로 제공하는 책임이 하네스 운영자에게 있다.
   2. 오픈소스 모델을 포함한 여러 선택지를 뒤에서 비교하므로 개발자는 모델 이름과 가격표를 매 작업마다 직접 관리하지 않아도 된다.

3. Kimchi와 Ferment의 장시간 코딩 루프

3.1. Kimchi의 설계 배경과 오픈소스 방향

1. 클라우드 비용에서 출발

   1. 무제한에 가까운 에이전트 사용을 내부에서 허용하자 클라우드에 코드와 실행량이 쌓였고 비용도 함께 커졌다.
   2. 몇 달 뒤 청구액이 계속 커지는 상황을 확인한 뒤, 팀은 자체 실행 능력과 모델 선택 체계를 만들기 시작했다.

2. 다섯 모델과 오픈소스 하네스

   1. 내부 SDK에 연결된 다섯 모델을 활용하면서 특정 상용 모델 하나에 종속되지 않는 구조를 지향했다.
   2. 그 경험을 오픈소스 구성 요소로 다시 제공하고, 커뮤니티의 기여를 계속 받는 방향을 선택했다.

3. 김치와 발효라는 이름

   1. Kimchi라는 이름은 장시간 작업을 거치며 결과가 성숙하는 ‘발효(fermentation)’의 이미지와 연결된다.
   2. 인간이 두세 시간마다 확인하는 동안 에이전트가 질문하고 실행하고 검증하는 장시간 작업에 적합하다는 의미가 담겼다.

3.2. Ferment의 자율 실행 구조

1. 두 시간 이상 이어지는 에이전트 작업

   1. Kimchi 하네스의 목표는 에이전트가 두 시간 넘게 코딩하며 사람의 짧은 개입 사이를 스스로 채우는 것이다.
   2. 인간은 보통 두세 시간마다 확인하거나 방향을 조정하고, 그 사이의 반복 실행은 에이전트가 맡는다.

2. 단계별 실행과 주기별 채점

   1. 큰 작업을 단계별로 쪼개고, 각 단계가 어떻게 구현됐는지 확인한다.
   2. 일정한 주기마다 결과에 점수를 매겨 현재 상태와 품질을 사람에게 보여준다.
   3. 점수는 어떤 모델을 다음 실행에 사용할지 결정하는 근거이자 작업이 계속 진행될 수 있는지 판단하는 품질 신호다.

3. 모델을 고르는 기준

   1. 하네스는 특정 모델을 영구적으로 고정하지 않고, 현재 작업에서 충분히 좋은 점수를 낼 모델을 선택한다.
   2. 결과가 기준을 충족하면 작업을 이어가고, 기준에 미달하면 다른 모델을 사용하거나 같은 작업을 다시 수행한다.

3.3. 소프트웨어 개발 수명주기(SDLC) 자동화

1. 변경 후 실행과 검증

   1. 에이전트가 코드를 변경하면 작성한 내용을 직접 실행해 오류가 있는지 검사한다.
   2. 실행이 실패하면 에이전트가 다시 수정하고 재컴파일하며, 수정과 실행의 순환을 계속한다.

2. 품질 기준과 스테이징 배포

   1. 모든 검사가 끝나면 결과를 점수화하고, 최소 B 등급을 품질 통과선으로 삼는다.
   2. 점수가 B 이상이면 결과를 완료로 간주하고 테스트 환경 또는 스테이징(staging) 환경에 배포한다.
   3. 결과가 충분하지만 문구나 세부 품질이 마음에 들지 않으면 다시 작업을 요청해 A 등급을 목표로 높일 수 있다.

3. Ferment의 핵심

   1. Kimchi가 모델을 고르는 하네스만 제공하는 데 비해 Ferment는 에이전트가 작업을 진행하고 검증하는 발효 루프에 초점을 둔다.
   2. 코드 작성, 실행, 오류 수정, 재컴파일, 결과 채점, 스테이징 배포를 하나의 지속적인 흐름으로 연결한다.

3.4. 현재 한계와 생산 환경으로의 확장

1. 현재는 테스트 단계에서 멈춤

   1. 현재 설계는 테스트 환경까지 자동화하고 생산 배포 직전에는 사람의 개입을 요구한다.
   2. 품질 기준과 승인 조건을 사람이 확인한 뒤에야 다음 단계로 넘어가는 안전장치가 남아 있다.

2. 생산 전 필요한 신호

   1. 생산 시스템으로 보내기 전에는 관찰 가능성(observability)과 SLO(Service Level Objective) 지표를 확인해야 한다.
   2. Kubernetes 환경에서는 파드가 막히거나 비정상 상태가 아닌지, 검사 결과와 애플리케이션 상태가 통과했는지 확인해야 한다.
   3. 이런 조건을 생산 배포 전에 자동으로 확인하는 것이 다음 단계의 목표다.

3. 생산 이후의 검증

   1. 장기적으로는 생산 환경에 들어간 뒤에도 동일한 관찰과 검증 루프가 계속 작동해야 한다.
   2. 단순히 코드가 컴파일됐다는 사실만으로는 운영 안정성과 사용자 영향까지 보장할 수 없기 때문이다.

4. 에이전트 시대의 코드 검토와 Kimchi Teleport

4.1. 코드 diff만으로 부족해지는 이유

1. 변경량의 급증

   1. 에이전트 기반 엔지니어링에서는 예전보다 코드 변경이 훨씬 자주, 많이 발생한다.
   2. 제품 관리자나 비개발 직군도 프로그래밍을 시작할 수 있어 작은 요구가 순식간에 약 2,000줄 규모의 변경으로 이어질 수 있다.

2. 검토 대상의 확장

   1. 줄 단위 diff만 읽어서는 변경의 실제 의도와 요구사항 충족 여부를 판단하기 어렵다.
   2. 검토자는 무엇을 바꾸었는지뿐 아니라 어떤 목표를 이루려 했는지, 에이전트에 어떤 사양(specification)을 전달했는지까지 확인해야 한다.

3. 사양과 결과의 연결

   1. 구현 결과가 요구사항과 다르게 보인다면 코드 한 줄의 문법보다 전체 작업의 의도와 실행 맥락을 다시 살펴야 한다.
   2. 에이전트가 만든 계획과 실행 기록을 함께 공유해야 동료·제품 관리자·다른 이해관계자가 결과를 제대로 평가할 수 있다.

4.2. Teleport의 원격 샌드박스

1. 노트북을 닫아도 계속되는 세션

   1. Kimchi Teleport는 원격 테스트 환경을 만들고 에이전트 세션을 그곳으로 옮긴다.
   2. 세션은 노트북이 아니라 원격 환경에서 실행되므로 노트북을 닫거나 이동 중이어도 작업이 계속된다.

2. 안전한 격리 환경

   1. 원격 공간은 안전한 샌드박스(sandbox)이며, 작업이 로컬 시스템을 직접 오염시키지 않도록 격리된다.
   2. SaaS 형태로 사용할 수도 있고, 금융기술 회사처럼 자체 인프라가 필요한 조직은 로컬 구현을 선택할 수 있다.

3. 접근성과 인간 개입

   1. 마련된 에이전트 세션은 노트북뿐 아니라 모바일 기기에서도 확인할 수 있다.
   2. 인간은 작업이 진행되는 동안 계속 화면 앞에 있을 필요가 없고, 보통 두세 시간 간격으로 알림이나 상태를 확인하고 사양 관련 결정을 내린다.

4.3. Teleport의 실행 인프라

1. 원격으로 환경을 이동

   1. Teleport는 작업 대상과 실행 환경을 원격으로 순간 이동시키듯 구성한다.
   2. 백그라운드에서 가상 머신(VM)이 시작되고, 에이전트는 해당 환경 안에서 계속 작업한다.

2. 컨테이너·클러스터와 동기화

   1. 주변 실행 환경 전체를 제어하고 컨테이너와 동기화한다.
   2. Cast AI의 경우 컨테이너가 Google의 하이퍼스케일러 인프라 안에서 실행되며, Kubernetes 클러스터에 연결된다.

3. 로컬과 원격의 사용감

   1. 로컬 노트북에서는 평소와 거의 같은 사용감을 유지한다.
   2. 실제 프로그램 실행은 노트북 내부가 아니라 Google 환경의 컨테이너와 클러스터에서 이뤄지므로 노트북을 닫아도 프로세스가 멈추지 않는다.

4. Wi-Fi보다 배터리가 문제였던 사례

   1. 비행 중 Wi-Fi가 끊기면 코딩이 중단될 것처럼 보이지만 원격 세션은 계속 실행된다.
   2. 실제로 실패한 원인은 Wi-Fi가 아니라 노트북 배터리였고, 원격 실행 구조가 네트워크 단절과 로컬 전원 문제를 분리해 준다는 점이 강조된다.

5. 내부 채택률

   1. 마지막으로 확인한 시점에 Cast AI 엔지니어의 약 62%가 Teleport만 사용하고 있었다.
   2. 집에 돌아간 뒤에도, 이동 중에도, 휴가 중에도 백그라운드 작업이 계속된다는 점이 높은 사용률의 이유로 제시된다.

5. Kimchi Studio와 팀 단위 에이전트 협업

5.1. Studio의 역할

1. 개인용 Teleport를 팀용 공간으로 확장

   1. Kimchi Studio는 Teleport의 팀·회사 버전처럼 동작한다.
   2. 개인 세션을 감추지 않고 팀 보드(board)에 올려 진행 중인 작업, 계획, 검토 상태를 함께 볼 수 있게 한다.

2. 작업의 시각화

   1. Teleport 샌드박스 안에서 실행되는 세션을 브라우저 화면에 표시한다.
   2. Kimchi 코드 모델이 만든 계획과 현재 실행 상황을 한 곳에서 확인할 수 있어 터미널이나 CLI를 공유하는 부담이 줄어든다.

5.2. 계획과 검토의 협업 흐름

1. 작업을 계획부터 공유

   1. 엔지니어가 과제를 만들고 실행을 시작한 뒤 에이전트에게 계획을 요청한다.
   2. 생성된 계획은 동료 엔지니어, 제품 관리자, 다른 이해관계자가 검토할 수 있는 형태로 제시된다.

2. 팀원이 세션을 인계

   1. 팀원은 보드에서 작업을 발견하고 “제가 처리하겠습니다”라고 맡을 수 있다.
   2. 한 사람이 검토 중인 상태를 남기면 다음 담당자가 이어서 작업하거나 수정 요청을 할 수 있다.

3. 반복 검토와 상태 공유

   1. 결과에 대한 질문과 답변이 기록되고, 다음 검토가 진행될 때까지 상태가 유지된다.
   2. 한 팀에서 여러 작업을 동시에 실행하고, 각 세션의 담당자·진행 상태·검토 여부를 구분할 수 있다.

5.3. 칸반형 운영과 팀 규모

1. 칸반 보드

   1. Studio는 진행 중(in progress), 검토 중(in review) 같은 상태를 칸반 스타일로 보여준다.
   2. 한 작업이 검토 중일 때 다른 팀원은 밀린 새 작업을 시작해 병렬로 처리할 수 있다.

2. 피자 팀 단위 협업

   1. 약 5~10명 규모의 작은 팀, 이른바 피자 팀(pizza team)을 하나의 작업 공간으로 생각할 수 있다.
   2. 각 팀은 개인 터미널에 흩어진 세션을 찾는 대신 공유 보드에서 작업을 나누고 서로의 결과를 검토한다.

3. 에이전트 엔지니어링의 새로운 기본 단위

   1. 에이전트가 코드를 쓰는 능력만으로는 팀의 생산성이 완성되지 않는다.
   2. 계획·실행·검토·재작업·공유를 같은 흐름으로 묶는 팀 인터페이스가 있어야 에이전트 작업을 조직의 일상적인 개발 방식으로 만들 수 있다.

5.4. 오픈소스 접근과 사용 방법

1. 대부분의 구성 요소 공개

   1. Kimchi 하네스의 대부분은 오픈소스로 제공되며, 하네스 전체도 오픈소스 방향을 유지한다.
   2. Kimchi 웹사이트와 GitHub에서 프로젝트와 관련 자료를 확인할 수 있다.

2. 설치와 계정

   1. Studio와 Teleport에는 Google 계정이 필요해 설정이 약간 복잡할 수 있다.
   2. 설치 자체는 약 5분 정도이며, 설치 뒤에는 원하는 방식으로 Teleport 세션을 구성할 수 있다.

3. 팀 공유

   1. 세션을 동료와 공유해 Kimchi Studio의 협업 보드에 연결할 수 있다.
   2. 관심 있는 팀은 Cast AI 측에 연락해 사용 방식을 논의할 수 있다.

주요 발언 모음

“토큰 사용을 제한하는 것은 개발자에게 배터리가 한 시간뿐인 노트북을 하루에 한 번만 충전하라고 말하는 것과 같다.”

“우리의 임무는 개발자가 에이전트를 사용하는 것을 막는 일이 아니다.”

“같은 작업에서 같은 품질의 결과를 얻는다면, 토큰당 가격보다 작업당 비용을 봐야 한다.”

“하네스는 그 작업에 맞는 모델을 적절한 시간과 비용으로 자동 선택한다.”

“사람은 새로운 모델을 찾고, 이해하고, 시도하고, 마음에 드는지 느껴봐야 하지만 하네스는 그 일을 자동화한다.”

“Kimchi의 핵심은 하네스만 제공하는 것이 아니라 소프트웨어 개발 수명주기의 완전한 루프를 제공하는 것이다.”

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

“Wi-Fi 문제가 아니라 배터리 문제였고, Teleport의 작업은 계속됐다.”

“코드 변경만 읽는 것으로는 충분하지 않다. 실제 의도와 에이전트에 준 사양을 봐야 한다.”

핵심 데이터 & 수치

• 영상 길이: 17분 39초다.
• Cast AI 직원 수: 약 300명이다.
• 개발자 비중: 전체 직원의 약 3분의 2다.
• 내부 검증 기간: 프로그래밍 에이전트를 약 3개월 사용했다.
• 연결 모델 수: 내부 SDK에 다섯 가지 모델을 연결했다.
• Gemini 3 계열 예시: 토큰당 약 3.50달러, 작업당 약 705달러로 제시됐다.
• MiniMax 2.7 예시: 토큰당 약 1.5달러, 작업당 약 148달러로 제시됐다.
• 토큰 사용량 변화: 동일 품질 결과를 얻는 동안 토큰 수가 약 1.5배 늘었다.
• 클라우드 비용 변화: 하네스 적용 뒤 클라우드 비용이 약 1.5배 줄었다.
• 비용 성과: 설명 자료의 핵심 성과는 3개월 만에 비용을 약 2.5배 절감한 것이다.
• Ferment 자율 실행: 인간 확인 간격이 보통 2~3시간이고 2시간 이상 코딩하는 작업을 목표로 한다.
• 품질 게이트: 결과를 최소 B 등급 이상으로 채점한 뒤 다음 단계로 보낸다.
• 현재 자동화 범위: 테스트 및 스테이징까지 자동화하고 생산 배포 전에는 사람의 승인을 둔다.
• 변경 규모 예시: 제품 관리자 등이 작업을 시작하면 약 2,000줄의 변경이 발생할 수 있다.
• Teleport 채택률: 마지막 확인 시점에 Cast AI 엔지니어의 약 62%가 Teleport만 사용했다.
• 팀 규모 예시: Studio 협업 단위는 약 5~10명의 피자 팀이다.
• 설치 시간: Google 계정 설정 뒤 기본 설치는 약 5분이다.

결론 및 시사점

1. 토큰 상한은 비용을 통제하는 가장 단순한 방법이지만, 에이전트가 충분히 생각하고 검증할 기회를 빼앗는다.
2. 관리자는 토큰을 줄이는 대신 작업당 비용과 결과 품질을 함께 측정해야 한다.
3. 모델의 토큰 단가가 낮아도 작업당 완료 비용이 높을 수 있으므로 실제 성공 결과를 기준으로 비교해야 한다.
4. 하네스는 여러 모델의 품질·시간·비용을 런타임에 비교해 작업마다 적절한 모델을 선택한다.
5. 모델 선택은 시장 변화에 맞춰 계속 바뀌며, Kimi 2.6과 MiniMax 3의 선택 비중 변화가 그 사례다.
6. Ferment는 코드 작성만이 아니라 실행, 오류 수정, 재컴파일, 채점, 스테이징 배포를 하나의 루프로 묶는다.
7. 최소 B 등급 품질 게이트와 재작업을 통해 값싼 모델 선택이 결과 품질 저하로 이어지지 않게 한다.
8. 생산 배포에는 관찰 가능성, SLO, Kubernetes 상태, 애플리케이션 검사 같은 운영 신호를 추가해야 한다.
9. 에이전트가 만드는 변경량이 커질수록 diff보다 작업 의도와 사양을 함께 검토해야 한다.
10. Teleport는 실행을 원격 샌드박스로 옮겨 노트북을 닫거나 이동해도 장시간 작업을 유지한다.
11. 원격 컨테이너와 Kubernetes 클러스터를 사용하면 로컬 노트북의 배터리와 실행 안정성을 분리할 수 있다.
12. Cast AI 내부 엔지니어의 약 62%가 Teleport만 사용하는 수치는 원격 실행의 실용성을 보여준다.
13. Studio는 개인 세션을 팀 보드로 확장해 계획, 담당자, 검토 상태를 공유하게 한다.
14. 5~10명 규모의 작은 팀은 칸반 보드에서 여러 에이전트 작업을 병렬로 배분할 수 있다.
15. 팀원은 다른 사람의 세션을 인계하고, 질문과 검토 결과를 남기며, 필요하면 다음 실행을 요청할 수 있다.
16. 터미널과 CLI에 흩어진 작업을 브라우저 기반 보드로 모으면 에이전트 개발 흐름이 조직의 공용 업무가 된다.
17. Kimchi, Ferment, Teleport, Studio는 모델 선택, 장시간 실행, 원격 인프라, 팀 협업을 각각 연결한다.
18. 오픈소스 하네스는 상용 모델 하나에 종속되지 않고 변화하는 모델 생태계를 활용할 여지를 만든다.
19. Google 계정이 필요하고 설치가 약간 복잡해도 기본 설치는 약 5분이며 동료와 세션을 공유할 수 있다.
20. 개발 생산성의 핵심은 토큰을 아끼는 것이 아니라 같은 품질의 작업을 가장 적절한 모델과 비용으로 끝내는 것이다.