AI 토큰 사용량보다 중요한 신뢰할 수 있는 처리량 — Ironclad의 Mingsheng Hong

URL: https://www.youtube.com/watch?v=fOsLTMhjyMM 날짜: 2026-09-02 채널: Tech Bridge

---

메타데이터

• 원문 제목: [한영자막] AI 토큰을 많이 쓰는 것보다 중요한 것 — Ironclad Mingsheng Hong
• 발표자: Mingsheng Hong(Minshan), Ironclad AI 엔지니어링 담당 부사장(VP of Engineering, AI)
• 영상 길이: 약 22분 20초
• 주제: AI 토큰 비용 관리, 신뢰할 수 있는 처리량(Trusted Throughput), 코드 리뷰·CI 병목, 개발자 경험(Developer Experience)
• 처리 날짜: 2026-09-02
• 원문 URL: https://www.youtube.com/watch?v=fOsLTMhjyMM

---

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

AI 토큰 사용의 목표는 토큰 지출을 무조건 줄이는 긴축 정책(Austerity)이 아니라, 토큰 투입으로 얻는 **신뢰할 수 있는 처리량(Trusted Throughput)**과 투자수익률(ROI)을 높이는 데 있다. 사용량과 비용은 연기 감지기처럼 관찰하되 순위표로 만들지 말고, 가치·품질·고객 검증·개발 흐름을 함께 계측해야 한다.

• 팀과 개인별 토큰 사용량·비용 대시보드는 도입 격차와 이상 급증을 찾는 관찰 장치로 사용한다.
• AI 코드 생성이 늘면 병목은 코드 작성에서 코드 리뷰와 지속적 통합(CI)·병합으로 이동한다.
• 신뢰할 수 있는 처리량은 객관적 테스트·보안 검사, 인간의 코드·디자인 판단, 실제 고객 반응을 모두 통과한 결과물이다.
• 올바른 지표는 코드량이나 토큰량 자체가 아니라 가치가 반영된 병합 결과, 배포 신뢰성, PR 흐름, 고객 경험이어야 한다.

AI를 도입한 조직은 비용을 먼저 측정하되 곧바로 비용 삭감으로 가지 말고, 토큰을 태워 얻는 가치를 측정해 ROI를 이해해야 한다. 이후 코드 리뷰와 CI의 새로운 병목을 제거하고, 예산·할당량·이상 징후 알림·인간 검토·학습 루프를 연결해야 한다. AI를 더 많이 쓰는 조직이 자동으로 더 생산적인 조직이 되는 것이 아니라, 더 많은 AI 산출물을 안전하고 빠르게 제품과 고객에게 전달하는 조직이 성과를 만든다.

1. 토큰 사용량을 경쟁 지표로 만들지 않는 이유

토큰 사용량은 업무 성과가 아니라 비용과 활용 맥락을 해석하기 위한 관찰값이다.

1.1. 자극적인 사례가 보여주는 잘못된 인센티브

1. 아마존의 자발적 사용량 대시보드 사례

   1. 한 직원이 모든 구성원이 자신의 AI 토큰 사용량을 추적할 수 있도록 자발적으로 대시보드를 만들었다.
   2. 경영진이 명시적으로 권장했는지는 불확실하지만, 대시보드가 공개되자 일부 엔지니어가 토큰 사용량을 극대화해 소위 리더보드(Leaderboard) 상위권에 오르려고 서로 경쟁하기 시작했다.
   3. 사용량을 보여주는 도구가 성과 경쟁 도구로 해석되면, 실제 가치보다 토큰을 많이 소비하는 행동이 보상받는 구조가 생긴다.

2. 메타와 클로드 투자에 관한 언론 보도

   1. 메타에서도 비슷하게 AI 사용량을 둘러싼 경쟁 이야기가 나왔다.
   2. 더 자극적인 사례로 어떤 회사가 한 달 안에 클로드(Claude)에 5억 달러를 지출했다는 이야기가 제시된다.
   3. 이런 사례가 현재 모든 회사에서 벌어지는 것은 아니지만, 비용 폭증과 잘못된 인센티브라는 위협은 현실적인 운영 문제다.

3. 조직이 답해야 할 네 가지 질문

   1. AI 사용 정책을 어느 수준으로 정할지 결정해야 한다.
   2. 토큰 비용을 어떤 방식으로 측정할지 정해야 한다.
   3. 사용량 급증과 비정상적인 비용을 어떻게 해석할지 정해야 한다.
   4. 비용이 아니라 가치와 ROI를 높이는 방식으로 사용을 어떻게 통제하고 최적화할지 정해야 한다.

1.2. 대시보드는 리더보드가 아니라 연기 감지기다

1. 관찰 가능성은 필수다

   1. 모든 팀과 개인의 토큰 사용량과 비용을 추적하는 대시보드를 갖춰야 한다.
   2. 추적하지 않으면 도입률, 비용 분포, 특정 도구의 과도한 사용, 팀별 차이를 파악할 수 없다.

2. 낮은 사용량을 조사 신호로 해석한다

   1. 특정 팀이나 개인이 AI 토큰을 거의 사용하지 않는 지역적 집단(Local Pocket)이 있다면 도입에 어려움이 있는지 조사할 신호가 된다.
   2. 낮은 사용량 자체를 낮은 성과로 단정하지 말고, 도구 접근성·업무 성격·신뢰 수준·교육 부족 등 맥락을 확인해야 한다.

3. 사용량 극대화 인센티브를 제거한다

   1. 사용량 순위를 공개하거나 많이 쓴 사람에게 보상하면 토큰 소비가 목적이 된다.
   2. 대시보드의 목적은 문제를 조기에 감지하고 학습하는 것이지, 사람을 줄 세우거나 최대 사용량을 보상하는 것이 아니다.

2. AI 도입 단계와 신뢰 형성

비용 최적화는 AI 도입이 어느 정도 진행된 조직을 위한 주제이며, 도입 초기에는 사람의 저항과 업무 정체성부터 다뤄야 한다.

2.1. 도입 성숙도에 맞춰 대화를 시작한다

1. 대상 조직을 구분한다

   1. 이미 AI 도입이라는 초기 난관을 넘은 팀은 사용량·비용·가치·병목을 본격적으로 측정할 준비가 되어 있다.
   2. 아직 엔지니어가 쉽게 접근할 수 있는 환경을 만들거나 팀과 개인의 도입을 장려하는 단계라면, 비용 통제·최적화 아이디어를 바로 실행하기 어려울 수 있다.
   3. 초기 조직도 이 문제를 논의할 수 있지만, 도입을 막는 문제와 비용을 최적화하는 문제를 같은 순서로 처리해서는 안 된다.

2. 엔지니어링 리더가 처한 현실을 인정한다

   1. Ironclad도 지난 몇 분기 동안 AI 도입의 고비를 겨우 넘었다.
   2. AI 도입 이후 비용을 걱정하기 시작한 사람이 청중의 대략 절반이라는 반응은 조직들이 비슷한 전환점에 있다는 신호다.
   3. 이 전환점에서 필요한 것은 일방적인 비용 절감 명령이 아니라, 조직에 맞는 실행 방안을 함께 찾는 대화다.

2.2. 저항하는 사람의 업무 경험을 이해한다

1. 하향식 추진 뒤에 일대일 대화를 이어간다

   1. 리더십이 위에서 아래로 AI 도입을 밀어붙인 다음에는, 저항하거나 어려움을 겪는 개별 팀과 개인을 직접 만나야 한다.
   2. 도입을 거부하는 이유를 태도 문제로 단정하지 말고, 그 사람이 어떤 업무 경험과 전문적 자부심을 잃고 있는지 이해해야 한다.

2. 손으로 코드를 만드는 자부심을 다룬다

   1. 일부 엔지니어는 과거에 코드를 직접 공들여 만드는 일에서 큰 자부심과 즐거움을 느꼈다고 말한다.
   2. AI 도입 뒤에는 그 기쁨과 자부심이 줄어들고, AI가 생성한 코드를 검토하는 역할만 남은 것처럼 느낄 수 있다.
   3. AI 산출물의 단순 검수만 맡기면 업무가 만족스럽지 않다는 반응이 나올 수 있으므로, 고영향 엔지니어링 과제와 기술적 성장을 계속 제공해야 한다.

3. AI 시대의 성장 경로를 다시 설계한다

   1. 엔지니어가 단순히 AI 출력물을 승인하는 사람이 되지 않도록 고난도 설계, 아키텍처, 보안, 품질 판단에 집중하게 해야 한다.
   2. AI는 반복적이고 단순한 검사를 맡고, 사람은 시스템의 맥락과 장기적 결과를 판단하는 방식으로 역할을 재구성해야 한다.

3. Ironclad의 업무와 신뢰 중심 접근법

Ironclad의 법률 계약 도메인은 AI 결과물을 실제 업무에 쓰려면 먼저 신뢰를 시험하고 축적해야 한다는 원리를 보여준다.

3.1. 법률 계약을 빠르고 통제된 위험으로 처리한다

1. Ironclad의 제품 영역

   1. Ironclad는 법률 계약(Legal Contracting)을 위한 AI 회사다.
   2. 변호사, 조달·구매 담당자(Procurement), 기타 비즈니스 사용자가 새로운 계약을 더 빠르게 진행하도록 AI 기능과 네이티브 AI 제품을 만든다.
   3. 속도만 높이는 것이 아니라 위험을 통제한 상태에서 계약을 진행하는 것이 제품의 목표다.

2. 신뢰가 최우선인 이유

   1. 법률 계약 결과가 틀리면 비용과 법적 위험이 발생하므로, AI 제품 기능과 제품군에서 신뢰 구축이 최우선 과제다.
   2. 엔지니어링 AI 활용도 내부 엔지니어, 리더십, 외부 고객에게 신뢰를 얻는 일련의 단계를 거쳐야 높은 가치를 만든다.

3.2. 익숙한 데이터로 AI 결과를 검증한다

1. 대화형 검색으로 신뢰를 시험한다

   1. 법률가는 자신이 잘 아는 계약서 세트를 대화형 검색(Conversational Search)에 입력한다.
   2. 검색 결과가 자신의 기대와 맞는지 확인해 AI의 기본 성능을 시험한다.
   3. 익숙한 데이터에서 기대한 결과가 나오면, 결과를 신뢰할 수 있다는 초기 근거가 생긴다.

2. 검증된 뒤 업무 범위를 넓힌다

   1. 사용자는 자신이 모르는 내용을 검색하는 범위로 점차 확장한다.
   2. 계약서 레드라이닝(Redlining·수정안 검토), 이상 징후(Anomaly) 발견 등 다른 AI 워크플로도 적용한다.
   3. 신뢰는 한 번에 부여되는 속성이 아니라, 익숙한 사례의 검증에서 새로운 작업으로 확장되는 단계적 과정이다.

3. 엔지니어링 AI에도 같은 패턴을 적용한다

   1. 엔지니어도 AI가 높은 기술적 가치를 제공하는지 작은 범위에서 확인한 뒤 더 중요한 작업에 적용해야 한다.
   2. 내부 엔지니어의 신뢰, 리더십의 신뢰, 고객의 신뢰가 연결되어야 AI로 만든 코드가 실제 제품의 신뢰할 수 있는 처리량이 된다.

4. 토큰 절약이 아닌 토큰 ROI와 신뢰할 수 있는 처리량

토큰 비용의 절대액을 줄이는 것보다 같은 투입에서 더 높은 가치와 더 안전한 배포 결과를 얻는 것이 핵심이다.

4.1. 긴축 정책과 ROI 개선을 구분한다

1. 목표는 토큰 지출 최소화가 아니다

   1. AI 토큰 지출을 최소화하거나 무조건 줄이는 것이 목표가 아니다.
   2. 비용을 줄이는 데만 초점을 맞추면 유용한 AI 사용까지 억제해 전체 생산성과 학습을 떨어뜨릴 수 있다.

2. 토큰 투자수익률을 높인다

   1. 토큰을 태워 얻는 가치가 얼마인지 측정해야 한다.
   2. 비용과 가치를 함께 측정하면 토큰 사용의 ROI를 이해할 수 있다.
   3. ROI가 낮아지는 원인이 비용 자체인지, 검토 지연·CI 대기·배포 실패 같은 병목인지 찾아 해결해야 한다.

4.2. Trusted Throughput을 정의한다

1. 신뢰할 수 있는 처리량의 기본 정의

   1. 신뢰할 수 있는 처리량은 내부에서 검토·검증된 코드가 최종적으로 고객 환경에 배포되어 다시 검증되는 결과물이다.
   2. 단순히 AI가 생성한 코드의 양이나 토큰 소비량이 아니라, 검토를 통과하고 고객에게 가치를 전달한 결과의 흐름을 측정한다.

2. ROI의 대리 지표로 사용한다

   1. AI가 만든 결과가 안전하게 병합되고 배포되는 속도와 품질은 토큰 투입의 실질적 ROI를 가늠하는 대리 지표(Proxy Metric)가 된다.
   2. 신뢰할 수 있는 처리량이 늘면 같은 토큰 비용으로 더 많은 가치가 고객에게 전달된다.

5. 비용을 측정하는 첫 단계와 대시보드 운영

비용 측정은 최적화의 출발점이지만, 측정 직후 비용 삭감으로 뛰어들면 가치 판단을 놓치게 된다.

5.1. 단일 도구와 복수 도구를 다르게 계측한다

1. 단일 도구를 사용하는 조직

   1. Claude Code(자막에는 Cloud Code로 표기)나 Codex처럼 하나의 코딩 도구를 쓰면 공급업체 대시보드에서 토큰·비용·사용 패턴에 관한 풍부한 분석을 얻을 수 있다.
   2. 먼저 공급업체가 제공하는 데이터를 활용해 팀과 개인의 사용량을 파악한다.

2. 복수 도구를 조합하는 조직

   1. Ironclad처럼 여러 코딩 도구를 쓰면 AI를 활용해 간단한 대시보드와 데이터 파이프라인을 구축하고 각 공급업체의 데이터를 추출한다.
   2. 도구별 데이터를 상호 연관(Cross-correlate)하고, 합산·분해해 전체 비용을 본다.
   3. 팀별·개인별로 모든 도구에서 발생한 비용과 사용량을 분해하면 조직의 실제 사용 분포를 파악할 수 있다.

5.2. 정기 검토의 목적을 명확히 한다

1. 도입 격차를 찾는다

   1. 특정 팀이나 개인 집단에 AI 도입 격차가 있는지 확인한다.
   2. 낮은 사용량이 도구 불신, 접근성 부족, 업무 부적합, 교육 부족 중 무엇에서 비롯됐는지 맥락을 조사한다.

2. 사용량 급증을 조사한다

   1. 갑작스러운 사용량 버스트(Burst)가 발생하면 무엇이 일어났는지 확인한다.
   2. 자동화 루프, 대규모 작업, 도구 변경, 실수 등 원인을 확인하고 정당한 사용인지 판단한다.

3. 팀을 맥락적으로 비교한다

   1. 플랫폼 인프라 팀의 AI 사용 방식과 가치는 UI 팀의 방식과 다를 수 있다.
   2. 동일한 사용량이나 비용을 동일한 성과로 해석하지 말고 업무 유형과 산출물의 차이를 함께 봐야 한다.

4. 대시보드를 학습 루프에 연결한다

   1. 검토·분석에서 얻은 교훈을 조직의 모범 사례(Institutional Best Practices)에 반영한다.
   2. 사람을 순위별로 세우거나 최대 사용량을 보상하는 스택 랭킹(Stack Ranking) 시스템으로 만들지 않는다.

6. 잘못된 생산성 지표에서 가치 중심 지표로

측정 가능한 숫자를 목표로 삼으면 숫자를 늘리는 행동이 실제 가치와 분리될 수 있으므로, 지표는 진화해야 한다.

6.1. LOC와 PR 개수의 한계를 이해한다

1. 코드 라인 수(LOC)의 한계

   1. 전통적인 엔지니어링 생산성 지표인 코드 라인 수(Lines of Code)는 추적할 수는 있지만 엔지니어링 속도나 가치의 핵심 목표로 삼기에는 부적절하다.
   2. 생산적이고 품질 높은 작업이라면 코드를 추가하는 대신 불필요한 코드를 제거하는 편이 더 나을 수도 있다.
   3. LOC는 중요한 관찰 지표일 수 있지만 직접 최적화할 목표는 아니며, 토큰 사용량과 지출도 같은 원칙을 따른다.

2. 열린 PR 개수로의 진화

   1. AI가 더 많은 코드를 만들면서 열린 PR(Open PR) 개수는 눈에 띄게 늘어날 수 있다.
   2. 열린 PR 개수를 측정하면 AI 도입 뒤 코드 생성량의 변곡점을 확인할 수 있다.
   3. 그러나 연구·개발 과정에서 시도만 하고 배포하지 않는 작업도 있으므로, 열린 PR만으로는 실제 성과를 판단할 수 없다.

3. 병합된 PR 개수로의 진화

   1. 장기적으로 조직은 실제로 출시하는 코드로 평가받으므로 열린 PR보다 병합된 PR(Merged PR) 개수가 더 나은 지표가 된다.
   2. 병합된 PR을 세는 것은 개선이지만, 모든 병합 PR의 가치가 같지는 않다는 문제가 남는다.

6.2. PR 복잡성 점수로 결과의 가중치를 부여한다

1. 작은 동시성 버그와 큰 보일러플레이트를 비교한다

   1. 코드가 10줄뿐인 PR도 오랜 시간을 들여 동시성 버그(Concurrency Bug)를 찾아 수정했다면 높은 가치를 가질 수 있다.
   2. 반대로 수천 줄의 보일러플레이트(Boilerplate) 코드는 생성·검토에 오래 걸려도 비즈니스 가치를 직접 더하지 않을 수 있다.
   3. 따라서 PR 개수나 LOC만 세면 복잡한 문제 해결과 반복 코드 생성을 구분하지 못한다.

2. Ironclad의 실용적 복잡성 태그

   1. Ironclad는 병합된 각 PR에 복잡성 점수(Complexity Score)를 나타내는 태그를 붙이기 시작했다.
   2. 복잡성에 관한 전통적인 단일 정의가 없어서 관련 문헌을 참고하되, 실용적인 접근법을 선택했다.
   3. 잘 만든 프롬프트로 AI에 PR을 입력하고, 한두 개의 LLM에 티셔츠 사이즈(T-shirt Size·예: S/M/L) 기준으로 복잡성을 평가하게 했다.

3. 복잡성 점수의 의미와 한계

   1. AI로 더 복잡한 PR을 생성했다면 더 큰 가치를 만들었다고 근사하고, 복잡성에 따라 병합 PR에 가중치를 부여한다.
   2. 이는 AI가 창출한 가치를 대략 측정하기 위한 지표이지, 완성된 표준은 아니다.
   3. 조직의 업무와 제품이 달라지므로 지표 정의는 계속 진화해야 하며, AI 가치의 근사치를 더 잘 만드는 방법을 함께 찾아야 한다.

7. Trusted Throughput의 질적 검증

신뢰할 수 있는 처리량은 내부 엔지니어링·리더십과 외부 고객이 모두 신뢰하는 고품질 산출물로 정의된다.

7.1. 세 가지 검증 버킷

1. 객관적 품질 지표

   1. 테스트 커버리지(Test Coverage)가 충분한지 확인한다.
   2. 사전에 정의한 보안 검사(Security Checks)가 모두 통과하는지 확인한다.
   3. 기능을 안전하게 출시하기 위해 정기적인 카나리 배포·테스트(Canary Practice)를 수행한다.

2. 주관적 인간 판단

   1. 코드 리뷰(Code Review)와 디자인 리뷰(Design Review)를 통해 사람이 코드 품질을 판단한다.
   2. 명확성(Clarity), 유지보수성(Maintainability), 아키텍처 적합성(Architecture Fit)처럼 자동화만으로 완전히 평가하기 어려운 속성을 검토한다.
   3. 객관적 지표가 통과해도 맥락에 맞지 않거나 장기적으로 유지하기 어려운 코드는 인간 판단에서 걸러야 한다.

3. 고객과 프로덕션의 검증

   1. 내부 검증을 통과한 변화가 실제 프로덕션에서 고객에게 어떻게 인식되는지 확인한다.
   2. 프로덕션 장애가 롤백(Rollback)으로 이어지는지 관찰한다.
   3. 사용성, 마찰(Friction), 버그에 관한 고객 불만과 지원 티켓을 확인한다.
   4. 객관적 검사, 인간의 판단, 고객 반응 세 버킷이 함께 엔지니어링의 Trusted Throughput을 구성한다.

8. AI 코드 생성이 만든 새로운 병목

AI는 코드 생성과 PR 작성을 풍부하게 만들지만, 소프트웨어 배포 수명주기 전체의 병목을 없애기보다 뒤쪽 단계로 이동시킨다.

8.1. 병목이 리뷰와 병합으로 이동한다

1. PR 생성량이 급증한다

   1. AI 코드 생성으로 PR을 더 많이 만들 수 있게 된다.
   2. 전체 소프트웨어 배포 수명주기에서 작성 단계의 처리 능력이 커지면, 병목은 PR 재검토와 이후 병합 단계로 이동한다.

2. 새로운 최적화 대상이 생긴다

   1. 코드 리뷰 프로세스가 늘어난 PR을 처리할 수 있는지 점검해야 한다.
   2. 지속적 통합(Continuous Integration, CI)과 지속적 배포(Continuous Delivery, CD) 프로세스가 병합량을 감당하는지 점검해야 한다.
   3. 토큰 사용량만 최적화하고 리뷰·CI를 방치하면 Trusted Throughput과 실제 ROI는 증가하지 않는다.

8.2. CI 과부하를 큰 PR로 해결하지 않는다

1. 안티 패턴: PR 분할을 중단한다

   1. CI 인프라가 과부하되면 엔지니어가 PR을 쪼개지 않고 큰 PR 하나를 제출하는 임시 해결책을 택할 수 있다.
   2. 전체 회귀 테스트를 실행하고 제출하는 데 한 시간이 걸린다면, PR을 10개로 나눌 때 10시간이 걸릴 수 있다는 계산이 큰 PR을 유혹한다.

2. 큰 PR이 만드는 위험

   1. 큰 PR은 인간 리뷰의 오버헤드를 키운다.
   2. 사람이 한 번에 검토해야 하는 범위가 넓어져 주의력이 분산되고 리뷰 품질이 낮아질 수 있다.
   3. CI 시간을 이유로 작은 PR을 포기하면 리뷰 가능성과 변경 추적성을 잃으므로, CI 자체를 개선해야 한다.

9. 코드 리뷰에서 AI와 인간의 역할을 분리한다

AI는 인간 리뷰어를 없애는 도구가 아니라, 인간이 고차원적 판단에 집중하도록 만드는 1차 방어선이다.

9.1. AI를 첫 번째 방어선으로 둔다

1. 단순 검사를 AI에 위임한다

   1. AI 리뷰 도구를 코드 리뷰의 첫 번째 방어선으로 도입한다.
   2. 코딩 스타일 문제, 테스트 커버리지 누락처럼 비교적 단순한 문제를 AI가 먼저 찾고 처리하게 한다.
   3. AI가 인간 리뷰어를 완전히 대체하는 것은 아니며, 인간 리뷰어의 부담을 가능한 한 많이 덜어주는 것이 목적이다.

2. 인간 리뷰 전 선행 조건을 둔다

   1. 작성자가 AI 리뷰에서 발견된 문제를 모두 해결한 뒤에 PR을 인간 리뷰어에게 전달한다.
   2. 인간 리뷰어는 반복적인 지적을 되풀이하는 대신 코드의 목적과 구조를 깊이 판단할 수 있다.

9.2. 인간은 주관적이고 책임 있는 판단을 맡는다

1. 심층 판단의 대상

   1. 코드가 전반적으로 좋은지 판단한다.
   2. 아키텍처가 견고하고 장기적으로 유지 가능한지 판단한다.
   3. 코드가 보안 설계(Security Design)를 충족하는지 판단한다.
   4. 시스템 맥락과 제품 요구사항에 맞는지 판단한다.

2. 최종 책임은 엔지니어링 팀에 남긴다

   1. AI가 1차 필터를 통과시켜도 인간 엔지니어는 배포 결과에 최종 책임을 져야 한다.
   2. 인간의 깊은 판단과 팀의 책임성이 결합되어야 AI 산출물이 Trusted Throughput이 된다.

10. CI와 개발자 경험을 회사 차원에서 개선한다

AI 코드 생성으로 작고 많은 PR이 생기면 CI 부담은 개인의 문제가 아니라 회사 수준의 플랫폼 문제다.

10.1. 개인의 PR 보모 역할을 없앤다

1. CI 부담의 전파

   1. AI는 코드를 쉽게 만들고 변경을 더 작고 많은 PR로 나누게 하므로 CI에 훨씬 큰 압력을 가한다.
   2. 회사 차원에서 해결하지 않으면 개별 엔지니어가 PR이 병합될 때까지 사람 시간을 써서 감시해야 한다.

2. 플레이키 테스트의 비용

   1. 테스트가 플레이키(Flaky Test)하면 엔지니어가 수동으로 재실행 버튼을 눌러야 한다.
   2. 반복적인 대기는 매우 답답하고, 제품 기능을 만드는 대신 PR 통과를 돌보는 시간이 된다.
   3. AI 에이전트를 고용해 PR을 감시하고 반복 루프를 돌릴 수도 있지만, 그 과정이 AI 토큰을 추가로 낭비한다.
   4. 수동 재실행과 AI 에이전트 감시는 모두 임시방편일 뿐 완벽한 해결책이 아니며, 엔지니어의 사기와 만족도를 낮춘다.

3. Developer Experience 플랫폼에 투자한다

   1. 개발자 경험(Developer Experience, DevEx) 플랫폼 엔지니어링에 투자한다.
   2. 플레이키 테스트를 줄이고 제거한다.
   3. CI 인프라의 속도와 안정성을 개선해 작은 PR을 유지할 수 있게 한다.

10.2. CI 건강성과 개발 흐름을 측정한다

1. PR 준비부터 제출까지의 작업 시간을 잰다

   1. PR을 제출할 준비가 끝난 시점부터 실제 제출 시점까지 걸린 작업 시간을 기록한다.
   2. 일반적인 코드 리뷰(CR) 실행이 한 시간 걸린다고 할 때, PR 제출에 두세 시간이 걸린다면 CI·리뷰 흐름에 위험 신호가 있다는 뜻이다.

2. 테스트 재시도 횟수를 잰다

   1. PR이 테스트를 통과하기 위해 몇 번 재시도해야 하는지 측정한다.
   2. 재시도 횟수가 늘면 플레이키 테스트, 인프라 불안정, 불명확한 실패 처리 중 원인을 찾아야 한다.

3. DevEx 개선 팀이 지표를 사용한다

   1. PR 대기 시간과 재시도 횟수는 개발자 경험을 측정하는 핵심 지표다.
   2. 관련 플랫폼 팀은 이 지표와 현장 분석을 이용해 CI와 개발 흐름을 개선한다.

11. 토큰 사용을 측정·최적화하는 실용적 프레임워크

프레임워크는 가드레일, 사람의 정기 검토, 지속적인 학습 루프를 연결해 비용과 가치의 균형을 잡는다.

11.1. 가드레일을 설정한다

1. 예산과 할당량을 정한다

   1. 조직·팀·도구별 예산(Budget)과 할당량(Quota)을 설정한다.
   2. 사용자가 업무에 필요한 토큰을 쓸 수 있게 하면서도 무제한 사용이 방치되지 않도록 기준을 만든다.

2. 사용량과 이상 징후를 추적한다

   1. 실제 사용량을 지속적으로 추적한다.
   2. 정상 범위와 이상 징후(Anomaly)를 정의한다.
   3. 문제가 감지되면 사용자와 리더가 알림을 받을 수 있게 한다.

11.2. 자동 경보를 인간 검토와 결합한다

1. 자동화의 역할

   1. 예산 초과, 갑작스러운 버스트, 팀별 도입 격차를 빠르게 포착한다.
   2. 자동 알림은 사람이 모든 사용량을 매번 수동으로 검사하지 않아도 되는 조기 경보 장치다.

2. 정기 인간 검토의 역할

   1. 사람은 자동화가 놓칠 수 있는 흥미로운 패턴과 학습을 찾아낸다.
   2. 사용량이 많거나 적은 이유와 실제 가치가 있었는지 업무 맥락을 바탕으로 해석한다.
   3. 검토 결과를 조직의 지식 기반과 모범 사례에 다시 반영한다.

11.3. 리더십과 개인이 학습 루프를 닫는다

1. 가드레일을 공동 정의한다

   1. 리더십 팀은 개인과 협력해 가이드라인과 가드레일을 정의한다.
   2. 현장 엔지니어의 업무 특성을 반영해야 사용량 통제가 실제 업무를 방해하지 않는다.

2. 지표를 검토하고 개선한다

   1. 실제 지표를 검토한다.
   2. 잘못된 인센티브나 측정 누락을 발견하면 기준을 수정한다.
   3. 이렇게 정의→측정→검토→수정의 사이클을 반복해 학습 루프를 완성한다.

3. 팀과 개인이 새로운 활용법을 실험한다

   1. 엔지니어링 팀 및 개별 엔지니어와 함께 AI 사용 모범 사례를 계속 찾는다.
   2. 필요하면 제품 개발과 내부 업무에 AI를 쓰는 방법을 직접 혁신한다.
   3. 최적화는 비용 절감 규칙을 고정하는 일이 아니라, 더 높은 ROI를 만드는 사용 방식을 계속 배우는 과정이다.

12. 토큰 낭비를 줄이면서 품질을 높이는 구체적 기법

가드레일을 지키면서 토큰당 가치를 높이려면 에이전트 루프, 프롬프트 구조, 컨텍스트 수명을 설계해야 한다.

12.1. 에이전트 루프에 종료 조건을 둔다

1. 테스트 자동 수정 루프

   1. 일부 엔지니어는 Claude Code를 사용할 때 하네스(Harness)의 일부로 에이전트 루프(Agentic Loop)를 작성한다.
   2. AI가 초기 PR을 만든 뒤 테스트 집합을 통과하도록 반복 실행한다.
   3. 테스트가 통과하지 않으면 테스트나 코드를 자동으로 수정하고 다시 시도한다.

2. 루프 단계를 제한한다

   1. 테스트 실패가 계속되면 AI가 통제 불능 상태에서 무한히 토큰을 소비할 수 있다.
   2. 최대 루프 단계 수를 명시해 실패가 반복될 때 토큰 낭비를 차단한다.
   3. 자동화의 편리함과 비용 통제를 동시에 달성하려면 종료 조건과 수동 개입 지점을 설계해야 한다.

12.2. 프롬프트 캐싱을 고려한다

1. 같은 접두사를 재사용한다

   1. 상용 모델 공급업체는 동일한 프롬프트 접두사(Prefix)를 반복해서 보내면 접두사 처리 방식을 최적화할 수 있도록 프롬프트 캐싱(Prompt Caching)을 점점 더 널리 제공하고 있다.
   2. 반복되는 지침과 고정된 컨텍스트를 캐시에 맞게 구성하면 처리 효율을 높일 수 있다.

2. 고정 콘텐츠와 가변 콘텐츠를 분리한다

   1. 시스템 프롬프트(System Prompt)와 사용자 프롬프트(User Prompt)를 함께 쓴다면, 고정된 시스템 프롬프트를 위에 배치한다.
   2. 매 요청마다 달라지는 가변 콘텐츠는 아래에 배치한다.
   3. 이 구조는 동일한 접두사를 재사용해 캐싱 이점을 얻는 데 유리하다.

12.3. 긴 대화의 컨텍스트를 가지치기한다

1. 요약을 습관화한다

   1. 긴 채팅 세션에서 컨텍스트가 계속 쌓이면 사용자는 현재 맥락을 요약해 토큰 사용량을 효율적으로 유지해야 한다.
   2. 컨텍스트 가지치기(Context Pruning)는 오래되거나 중복된 정보가 매번 모델 입력에 따라붙지 않게 하는 방법이다.
   3. 이를 개인의 새로운 근육 기억(Muscle Memory)으로 만들면 장기 세션의 비용과 품질을 함께 관리할 수 있다.

2. 자동 압축 도구를 활용한다

   1. Claude Code처럼 컨텍스트를 자동으로 관리하고 압축(Compaction)하는 도구가 점점 늘고 있다.
   2. 컨텍스트를 효율적으로 유지하면 토큰 사용 효율뿐 아니라 AI 출력 품질도 높아진다.
   3. 수동 요약 습관과 자동 컨텍스트 관리 도구를 함께 사용해야 장기 에이전트 작업이 안정적으로 이어진다.

13. Build vs Buy와 내부 플레이북

모든 것을 직접 만드는 것이 정답은 아니며, 차별화되는 업무 지식과 반복 가능한 프롬프트 자산은 내부 역량으로 축적해야 한다.

13.1. 차별화되지 않는 기반은 구매한다

1. 구매할 대상

   1. IDE(Integrated Development Environment)와 CI 인프라처럼 많은 조직이 공통으로 필요로 하는 비차별화 영역은 구매하는 편이 낫다.
   2. 외부 공급업체가 이미 안정적인 기능과 운영 역량을 제공한다면, 내부 팀이 같은 기반을 다시 만드는 것은 차별화된 가치를 만들지 못할 수 있다.

2. 초기부터 Build vs Buy를 고민한다

   1. AI 도입이 시작되는 초기 단계부터 직접 구축할 영역과 구매할 영역을 구분한다.
   2. 이 선택을 늦추면 팀이 도구를 중복 개발하거나, 이후의 운영·확장 비용을 뒤늦게 떠안게 된다.

13.2. 조직 맥락에 특화된 자산은 만든다

1. 내부 플레이북을 구축한다

   1. 작은 버그 수정에서 고품질 PR을 만드는 방법을 정한다.
   2. 리팩터링을 위해 새로운 UI 기능을 만드는 방법 등 조직의 맥락에 특화된 작업 방식을 정한다.
   3. 이런 지식은 잘 만든 AI 프롬프트 모음인 내부 플레이북(Internal Playbook)으로 축적한다.

2. 프롬프트를 공유하고 개선한다

   1. 검증된 프롬프트와 작업 절차를 저장해 팀 전체에 공유한다.
   2. 구성원이 반복 사용하면서 플레이북을 재사용하고 개선한다.
   3. 조직의 코드베이스와 리뷰 기준을 반영한 플레이북은 외부 IDE나 일반 CI 제품이 대신 제공하기 어려운 내부 차별화 자산이다.

13.3. 경계 사례는 실험하며 판단한다

1. Builder Agent를 검토한다

   1. Ironclad는 '빌더 에이전트(Builder Agent)'라고 부르는 것을 구축하려고 한다.
   2. 이는 클라우드 기반 코드 생성기가 Claude Code, Codex 등 코드 생성 도구와 코드 동작을 감싸는 형태다.

2. 모호한 영역을 열린 선택지로 둔다

   1. Builder Agent처럼 내부 구축과 외부 구매의 경계가 모호한 경우가 있다.
   2. 다른 공급업체도 계속 탐색하며, 어떤 기능이 차별화의 원천인지 판단해야 한다.
   3. build와 buy를 이분법으로 고정하지 말고, 내부 플레이북·통합·운영 경험이 실제 경쟁력이 되는지 실험해야 한다.

14. 마무리 교훈과 실행 시사점

AI 도입의 다음 단계는 더 많은 토큰이 아니라 더 신뢰할 수 있는 결과를 빠르게 전달하는 운영 체계를 만드는 일이다.

14.1. 세 가지 핵심 교훈

1. 학습한다

   1. 사용량·비용·가치·품질 지표를 운영하며 무엇이 실제 ROI를 만드는지 배운다.
   2. 자동 알림과 인간 검토를 이용해 새로운 패턴을 발견하고 조직 지식으로 축적한다.

2. 미리 계획한다

   1. AI 도입 초기부터 Build vs Buy를 고민한다.
   2. 코드 생성을 더 많이 장려할 때 코드 리뷰와 CI에 어떤 영향이 생길지 미리 계획한다.
   3. 새 병목이 생겼을 때 큰 PR 같은 안티 패턴에 의존하지 않고 플랫폼 개선으로 대응한다.

3. 다른 사람의 이야기와 실수에서 배운다

   1. 다른 팀의 사용량 경쟁, CI 과부하, 플레이키 테스트 문제에서 교훈을 얻는다.
   2. 이미 겪은 사례를 내부 정책과 플레이북에 반영해 시행착오를 줄인다.

14.2. 바로 적용할 운영 체크리스트

1. 관찰과 가치 측정

   1. 팀·개인·도구별 토큰 비용 대시보드를 만들되 리더보드로 운영하지 않는다.
   2. 비용과 함께 Trusted Throughput, 병합된 PR의 복잡성, 고객 티켓, 롤백을 측정한다.

2. 품질과 흐름 개선

   1. AI를 코드 리뷰의 1차 방어선으로 두고 인간이 설계·아키텍처·보안 판단에 집중하게 한다.
   2. 플레이키 테스트 제거, CI 안정화, PR 준비부터 제출까지의 시간 단축에 투자한다.
   3. 에이전트 루프의 최대 단계 수, 프롬프트 캐싱을 위한 고정 접두사, 컨텍스트 압축을 운영 규칙에 포함한다.

3. 학습과 자산화

   1. 예산·할당량·이상 징후 알림을 정기적인 인간 검토와 연결한다.
   2. 조직 맥락에 특화된 프롬프트와 작업 절차를 내부 플레이북으로 저장·공유·개선한다.
   3. 시스템을 계속 정의하고 계측해 CI 시스템의 건강성과 전체 개발자 경험을 측정한다.

14.3. 최종 결론

1. AI의 황금 시대는 토큰을 가장 많이 쓰는 팀의 시대가 아니다.
   1. 모든 팀의 성공 열쇠는 토큰 투자수익률을 극대화하는 것이다.
   2. 비용을 아끼는 것보다 신뢰할 수 있는 결과를 더 많이, 더 빠르게 고객에게 전달하는 것이 중요하다.
   3. 토큰 사용량을 비용·가치·품질·개발 흐름·고객 결과의 맥락에서 계측하면 AI 활용의 레버리지(Leverage)를 키울 수 있다.

주요 발언 모음

“대시보드는 리더보드가 아니라 연기 감지기처럼 생각해야 한다.”

“토큰 지출을 줄이는 것이 아니라 토큰 지출의 투자수익률(ROI)을 더 개선하는 것이 목표다.”

“신뢰할 수 있는 처리량은 코드가 내부에서 검토·검증되고, 궁극적으로 고객 배포 환경에서 검증되는 데서 나온다.”

“AI 코드 생성이 풍부해지면 압력은 코드 리뷰와 지속적 통합, 즉 코드 병합으로 내려간다.”

“AI 도구를 코드 리뷰의 첫 번째 방어선으로 활용하되 인간 리뷰어를 대체하지는 않는다.”

“학습하고, 미리 계획하고, 다른 사람들의 이야기와 실수에서 배우라.”

핵심 데이터 & 수치

• 약 22분 20초: 전체 발표 길이.
• 5억 달러: 한 회사가 한 달 안에 클로드에 지출했다는 자극적인 사례로 언급된 금액.
• 대략 절반: 초기 AI 도입 단계를 끝내고 비용을 걱정하기 시작한 청중의 손들기 반응.
• 10줄: 동시성 버그를 해결하는 데 오랜 시간이 걸릴 수 있는 작은 PR의 예시.
• 수천 줄: 직접적인 비즈니스 가치가 낮을 수 있는 보일러플레이트 PR의 예시.
• 1시간과 2~3시간: 일반적인 코드 리뷰 실행이 1시간인데 PR 제출까지 2~3시간 걸리면 위험 신호라는 예시.
• 10시간: 회귀 테스트와 제출이 PR 하나당 1시간일 때 10개로 분할하면 걸릴 수 있는 시간의 예시.
• 1개 또는 2개 LLM: 병합 PR의 복잡성을 티셔츠 사이즈로 평가하는 실용적 방식.
• 3개 버킷: 객관적 지표, 인간의 주관적 판단, 고객·프로덕션 반응으로 Trusted Throughput을 검증하는 구조.
• 3가지 프레임워크 축: 가드레일 설정, 인간 검토와 지식화, 리더십·개인의 학습 루프.

결론 및 시사점

1. 토큰 비용 대시보드는 사용량을 경쟁시키는 리더보드가 아니라 도입 격차와 이상 징후를 알려주는 연기 감지기로 운영한다.
2. 비용을 측정한 직후 삭감하지 말고 토큰으로 얻은 가치와 Trusted Throughput을 함께 측정해 ROI를 계산한다.
3. AI 코드 생성이 늘수록 코드 리뷰와 CI·병합이 새 병목이 되므로, 작은 PR을 포기하지 않고 플랫폼 차원에서 병목을 해결한다.
4. AI는 스타일·테스트 누락을 먼저 처리하고, 인간 엔지니어는 품질·아키텍처·보안·고객 영향을 판단하며 최종 책임을 진다.
5. 예산·할당량·이상 징후 알림, 인간 검토, 학습 루프를 연결해 정책을 고정하지 않고 계속 개선한다.
6. 에이전트 루프는 자동 수정의 편리함을 주지만 최대 단계 수를 제한해야 토큰이 통제 불능으로 소모되지 않는다.
7. 프롬프트 캐싱을 위해 고정 시스템 프롬프트를 앞에 두고 가변 콘텐츠를 뒤에 배치하며, 긴 대화는 요약·컨텍스트 압축으로 관리한다.
8. IDE·CI처럼 비차별화된 기반은 구매하고, 조직 특화 프롬프트·작업 절차·Builder Agent 같은 차별화 자산은 내부에서 구축한다.
9. AI 활용의 성과는 토큰 사용량이나 코드량이 아니라 안전하게 검증되고 고객에게 전달된 결과의 양과 질로 판단한다.
10. AI의 황금 시대를 여는 핵심은 더 많은 토큰이 아니라 모든 팀의 토큰 ROI를 극대화하는 운영 체계다.

핵심 요약 (20줄)

1. AI 토큰 사용량은 성과 순위가 아니라 비용과 활용 맥락을 파악하는 관찰값이다.

2. 팀과 개인별 사용량 대시보드는 리더보드가 아닌 연기 감지기처럼 운영해야 한다.

3. AI 사용량이 유난히 낮은 집단은 성과가 낮다는 증거가 아니라 조사할 신호일 수 있다.

4. 토큰을 많이 쓰는 행동에 보상을 주면 실제 가치보다 소비량을 키우는 경쟁이 발생한다.

5. AI 도입 초기에는 비용 최적화보다 저항하는 엔지니어의 업무 경험과 성장 경로를 이해해야 한다.

6. Ironclad는 계약 업무에서 익숙한 데이터로 AI 결과를 검증한 뒤 더 어려운 워크플로로 확장한다.

7. 토큰 지출의 목표는 절대 비용을 줄이는 긴축 정책이 아니라 투자수익률을 높이는 것이다.

8. 신뢰할 수 있는 처리량은 내부 검증과 고객 환경 검증을 모두 통과한 고품질 결과를 뜻한다.

9. 단일 도구는 공급업체 대시보드로, 복수 도구는 AI로 만든 통합 파이프라인으로 비용을 측정할 수 있다.

10. 비용을 측정한 뒤에는 토큰을 태워 얻은 가치와 병목을 함께 측정해야 ROI를 이해할 수 있다.

11. AI 코드 생성이 늘면 소프트웨어 수명주기의 병목은 작성에서 코드 리뷰와 PR 병합으로 이동한다.

12. CI가 느리다고 PR을 큰 단위로 합치면 인간 리뷰 부담과 주의력 분산으로 품질이 떨어질 수 있다.

13. AI 리뷰는 스타일과 테스트 누락을 먼저 처리하고 인간 리뷰어는 설계·아키텍처·보안을 판단해야 한다.

14. 플레이키 테스트와 불안정한 CI를 개인의 수동 재실행이나 AI 감시 루프로 해결하면 시간과 토큰을 낭비한다.

15. PR 준비부터 제출까지의 시간과 테스트 재시도 횟수는 개발자 경험의 핵심 지표다.

16. Trusted Throughput은 객관적 검사, 인간 판단, 고객·프로덕션 반응이라는 세 버킷으로 검증한다.

17. LOC나 열린 PR보다 복잡성 가중치를 적용한 병합 PR이 AI가 만든 가치에 더 가까운 지표가 될 수 있다.

18. 예산·할당량·이상 징후 알림은 정기적인 인간 검토와 조직 학습 루프에 연결해야 한다.

19. 에이전트 루프의 단계 제한, 프롬프트 캐싱, 컨텍스트 가지치기는 토큰 효율과 출력 품질을 함께 높인다.

20. 모든 팀의 성공 열쇠는 토큰을 가장 많이 쓰는 것이 아니라 토큰 ROI를 극대화하는 것이다.