AI 도입은 왜 토큰 절감부터 시작하면 안 될까 — 3S로 단계 나누기 1/2

TL;DR

• 초기 토큰 절감은 하네스 투자를 막을 수 있다.
• 3S는 연결·학습·재사용의 단계를 구분한다.
• 단계마다 투자와 평가 기준이 달라져야 한다.

시작하며

조직에서 AI 도입 이야기를 하다 보면 두 요구가 함께 나온다.

구성원에게는 AI를 더 많이 써보라고 한다. 동시에 토큰 사용량과 도구 비용은 빠르게 줄이라고 한다.

둘 다 필요한 요구다. 문제는 순서다.

AI를 업무에 연결하는 초기에는 실패를 많이 보고, 평가 사례와 도구를 만들고, 사람이 반복하던 판단을 규칙으로 옮겨야 한다. 이 과정에는 토큰뿐 아니라 도메인 전문가의 시간과 엔지니어링 비용이 든다.

처음부터 사용량 절감만 목표로 두면 구성원은 하네스를 만드는 대신 눈앞의 작업을 적은 토큰으로 끝내는 쪽을 택하기 쉽다. 개인에게는 합리적이지만 같은 실패가 다음 작업에서도 반복된다.

반대로 제한 없이 실험만 늘리면 리뷰, 재작업과 유지보수 비용이 커진다.

나는 이 사이에서 하나의 예산 원칙을 찾기보다, 현재 워크로드가 어느 단계에 있는지 먼저 구분하는 편이 낫다고 생각한다.

이 글에서는 그 단계를 Streamlining, Shape, Scale로 나눈다. AHEAD와 LEVER로 각 단계를 평가하는 방법은 2/2 글에서 이어서 다룬다.

1. 토큰은 전체 비용의 일부다

토큰 가격은 바로 보인다.

하지만 비즈니스 요구사항이 고객에게 도달하기까지는 모델 호출 외에도 도구 실행, 재시도, 사람의 검토, CI, 배포와 장애 대응이 필요하다.

AI가 코드를 빨리 만들수록 리뷰 대기열이 길어질 수도 있다. 구현에서 줄어든 인지부하가 리뷰 시점으로 이동하면 토큰 비용은 낮아 보여도 전체 전달 비용은 줄지 않는다.¹

그래서 토큰 사용량을 단독 목표로 두는 것은 위험하다.

같은 품질의 기능을 고객에게 전달하는 데 필요한 전체 투입이 줄었는지를 봐야 한다. CTS-SW 글에서 코드 생성량보다 고객에게 도달한 소프트웨어와 전체 비용을 연결해야 한다고 쓴 이유도 같다.²

다만 도입 초기부터 CTS-SW나 단기 ROI가 좋아질 것이라고 기대하는 것도 맞지 않는다.

데이터와 도구를 연결하고, 실패를 평가와 가드레일로 옮기는 동안에는 비용이 먼저 생긴다. 이 투자가 이후 워크로드에서 재사용되기 전까지 숫자만 보면 비효율처럼 보일 수 있다.

2. 하네스를 만들 여유가 필요하다

하네스는 Agent에게 긴 프롬프트를 주는 것보다 넓은 개념이다.

업무에 필요한 데이터와 도구, 품질 기준, 테스트, 권한, 관측성과 예외 처리 방식을 묶어 Agent가 같은 실패를 반복하지 않게 만드는 환경에 가깝다.³

하네스는 한 번에 완성되지 않는다.

Agent가 실패하면 원인을 보고 평가 사례를 추가한다. 리뷰에서 같은 지적이 반복되면 테스트나 아키텍처 규칙으로 옮긴다. 사람이 매번 판단하던 예외가 있다면 계약과 escalation 조건을 분명히 한다.

이 과정에서 토큰을 쓴 결과가 다음 실행에도 남아야 한다.

현재 작업 하나를 끝내기 위해 많은 토큰을 쓴 것과, 실패를 재현하고 하네스를 갱신하기 위해 쓴 것은 같은 비용으로 보기 어렵다. 후자는 다음 작업의 검토와 재작업을 줄일 가능성이 있기 때문이다.

아래 그림은 실측 결과가 아니라 이 관계를 표현한 개념도다.

왼쪽에서는 탐색과 검증을 시작할 여유가 부족하다. 오른쪽에서는 비즈니스 목표와 무관한 실험과 유지보수할 결과물이 늘어난다.

어느 지점이 적절한지는 업무의 위험과 복잡도, 현재 하네스의 성숙도에 따라 달라진다. 그래도 초기 투자와 운영 최적화를 같은 기준으로 평가하면 안 된다는 점은 분명하다고 생각한다.

3. 도입 단계를 3S로 나눈다

켄트 벡의 3X 모델은 제품 개발을 Explore, Expand, Extract로 나누고 단계마다 다른 전략이 필요하다고 설명한다.⁴

이 생각을 AI 도입에 적용해 Streamlining, Shape, Scale이라는 세 단계로 나눠봤다.

3S는 검증된 표준 모델이 아니다. 워크로드의 상태에 따라 투자와 평가 질문을 바꾸기 위한 내가 제안하는 렌즈다.

flowchart LR
    S1["Streamlining<br/>업무 경계와 도구 연결"] --> S2["Shape<br/>실패를 하네스에 반영"]
    S2 --> S3["Scale<br/>검증된 하네스 재사용"]
    S3 -. "새 업무 · 새 계약" .-> S1

Streamlining에서는 Agent가 업무를 끝까지 수행할 수 있는 환경을 만든다.

Shape에서는 실제 실패와 리뷰 피드백을 하네스에 반영한다.

Scale에서는 검증된 하네스를 다른 요구사항에 재사용해 전체 전달 비용과 시간을 줄인다.

이 단계는 조직 전체의 단일 성숙도 등급이 아니다.

한 팀 안에서도 주문 취소 자동화는 Scale에 있을 수 있고, 새로 시작한 정산 업무는 Streamlining에 있을 수 있다. 기존 워크로드도 데이터 계약이나 위험 기준이 바뀌면 앞 단계로 돌아간다.

4. Streamlining — 업무를 끝까지 수행할 수 있게 연결한다

Streamlining의 출발점은 모델이 아니라 업무다.

예를 들어 주문 취소를 자동화한다고 해보자.

취소 요청은 주문 시스템에 있고, 결제 취소는 결제팀 API를 거치며, 환불 정책은 CS 도구에 있을 수 있다. 팀별 시스템을 그대로 MCP로 감싸면 Agent는 여러 API 조각을 받지만 어떤 순서와 권한으로 조합해야 하는지는 알기 어렵다.

먼저 주문 취소라는 업무에 필요한 데이터, 규칙, 권한과 책임을 펼쳐봐야 한다.

Event Storming은 실제 업무 흐름과 bounded context를 찾는 데 사용할 수 있다.⁵ 조직도와 도메인 경계가 일치한다고 가정하지 않고, 함께 조회되고 변경되어야 할 내용을 확인하는 것이다.

그 다음 필요한 조회와 조작을 명시적인 계약으로 연결한다.

모든 데이터를 하나로 합칠 필요는 없다. Agent가 주문 상태를 확인하고 취소 가능 여부를 판단한 뒤, 허용된 범위에서 환불을 실행할 수 있으면 된다. 최소권한, 감사 기록과 사람에게 넘길 조건도 이때 정한다.

이 단계의 질문은 성과보다 준비 상태에 가깝다.

• 업무의 시작과 완료 조건이 분명한가
• 필요한 데이터와 도구에 접근할 수 있는가
• 권한과 책임 경계가 연결되어 있는가
• 현재 수작업의 시간·품질·비용 기준선이 있는가

이 조건이 없으면 Shape에서 실패를 관찰해도 모델 문제인지 환경 문제인지 구분하기 어렵다.

5. Shape — 반복되는 판단을 하네스로 옮긴다

Shape에서는 연결된 업무를 Agent에게 맡기고 실패를 본다.

처음부터 높은 자율성을 목표로 두기보다, 어떤 판단이 반복되고 어디에서 사람이 다시 코드를 읽는지 찾는다.

리뷰에서 같은 import 방향을 계속 지적한다면 아키텍처 테스트로 옮긴다. 같은 요구사항을 매번 확인한다면 계약과 테스트 케이스로 만든다. 증거가 부족해 사람이 전체 코드를 읽어야 했다면 다음 실행에서 계약별 검증 결과를 남기게 한다.¹

내가 생각하는 Shape의 산출물은 자동화율이 아니다.

같은 실패가 다시 나왔을 때 더 빨리 발견하거나, 아예 발생하지 않게 만드는 하네스다. 사람이 맡던 판단을 무조건 없애는 대신 반복 가능한 판단과 고위험 예외를 구분하는 과정이기도 하다.

이 단계에서는 도메인 전문가와 하네스 엔지니어가 함께 일해야 한다.

도메인 전문가는 무엇이 올바른 결과인지, 어떤 예외가 위험한지 정한다. 하네스 엔지니어는 이를 평가 사례, 도구, 계약과 가드레일로 옮긴다. 보안과 법무 판단이 필요한 정책은 해당 조직이 계속 소유한다.

하네스 엔지니어가 영구적으로 모든 도메인에 상주할 필요는 없다.

초기에는 공통 기반과 피드백 순환을 만들고, 도메인팀이 직접 실패를 분류하고 하네스를 고칠 수 있게 되면 다음 워크로드로 이동하는 편이 낫다. 하네스가 조직 역량이 되려면 도메인팀이 운영 책임을 넘겨받아야 한다.

6. Scale — 앞선 투자를 다음 요구사항에 재사용한다

Scale에서는 새 요구사항이 들어올 때마다 환경과 평가 기준을 처음부터 만들지 않는다.

검증된 데이터 계약, 커넥터, 테스트, 가드레일과 관측성을 재사용한다. Agent가 정상 경로는 스스로 닫고, 새 계약이나 확인하지 못한 위험만 사람에게 올릴 수 있어야 한다.

이때부터 앞선 투자가 전체 전달 비용의 감소로 이어지는지 볼 수 있다.

코드 생성 시간이 아니라 요구사항이 고객에게 도달하는 시간, 사람의 검토와 대기, 배포와 운영 비용을 함께 본다. CTS-SW 같은 지표는 이 구간에서 같은 팀의 추세를 확인하는 데 사용할 수 있다.²

Scale이 비용 절감만 뜻하는 것은 아니다.

같은 인원으로 더 많은 고객 요구를 처리하거나, 사고 위험을 낮추거나, 이전에는 경제성이 없던 작은 업무를 자동화할 수도 있다. 무엇을 가치로 볼지는 워크로드를 시작할 때 정해야 한다.

모델과 Agent를 바꾸는 결정도 이 단계에서 평가 없이 해서는 안 된다고 생각한다.

나도 Cursor에 맞춰 만든 하네스가 Claude Code에서 그대로 작동하지 않아 한동안 전환하지 못했다. 모델과 도구가 바뀌면 컨텍스트 사용법과 실패 형태도 달라질 수 있다.

공통 자산으로 남길 계약과 평가 사례, 특정 Agent에 맞출 도구를 구분해두면 교체 전후를 같은 기준으로 비교할 수 있다.

마치며

AI 도입 초기에는 토큰 사용량이 늘어날 수 있다.

데이터와 도구를 연결하고, 실패를 재현하고, 사람이 반복하던 판단을 하네스로 옮기는 비용이 먼저 들기 때문이다.

그렇다고 초기 투자를 무제한으로 허용하자는 뜻은 아니다.

Streamlining에서는 업무와 기준선을 만들고, Shape에서는 실패가 하네스에 남는지 확인한다. Scale에 들어간 워크로드에서 전체 전달 비용과 비즈니스 성과를 본다.

3S는 조직에 성숙도 점수를 붙이기 위한 모델보다, 지금 이 워크로드에 무엇을 투자하고 무엇을 묻지 말아야 하는지 구분하는 렌즈에 가깝다.

다음 2/2 글에서는 Shape의 하네스 학습과 리뷰 부담을 AHEAD로, Scale의 전체 전달 비용과 가치 회수를 LEVER로 어떻게 볼지 정리한다.

• #ai
• #agent
• #agentic-development
• #harness-engineering
• #organization
• #token-economics