토큰 격차를 재는 새로운 매트릭스

많이 쓴 사람이 아니라 잘 변환한 사람이 이긴다

토큰 격차를 단순히 "누가 더 많은 토큰을 쓸 수 있는가"로 재면 절반만 본 것이다. 그것은 전기요금 고지서를 보고 공장의 생산성을 판단하는 것과 같다. 전기를 많이 쓴 공장이 반드시 좋은 제품을 만든 것은 아니다. 토큰도 마찬가지다. 많이 썼다는 사실은 계산이 많이 일어났다는 뜻이지, 판단이 좋아졌다는 뜻이 아니다.

이제 질문을 바꿔야 한다.

"이 프로젝트는 몇 토큰을 썼는가?"가 아니라, "그 토큰은 무엇으로 변환되었는가?"라고 물어야 한다.

토큰은 크게 세 가지로 변환된다. 첫째, 사용자에게 전달되는 가치. 둘째, 오래 버티는 구조. 셋째, 빌더의 학습. 반대로 나쁜 토큰은 세 가지 쓰레기를 만든다. 불필요한 출력, 이해되지 않은 코드, 다음 수정 비용을 키우는 기술 부채다.

그래서 이 장에서 말하는 토큰 격차는 단순한 사용량 격차가 아니다. 더 정확히는 토큰 변환율의 격차다. 같은 1만 토큰을 써도 누군가는 화면에만 그럴듯한 데모를 얻고, 누군가는 검증된 기능과 재사용 가능한 구조, 다음 판단을 더 짧게 만드는 학습을 얻는다. 겉으로는 같은 소비지만, 남는 것은 완전히 다르다.

따라서 토큰 경제학의 다음 단계는 단순한 비용 절감이 아니다. 싼 모델을 쓰고, 답변 길이를 줄이고, 캐시를 붙이는 것만으로는 부족하다. 진짜 핵심은 어떤 토큰이 사고를 증폭했고, 어떤 토큰이 쓰레기를 만들었는지 구분하는 것이다.

AI 생성 이미지

총토큰만 보면 실패를 보지 못한다

프로젝트당 총토큰은 여전히 필요하다. 입력 토큰, 출력 토큰, 도구 호출, 재시도, 긴 컨텍스트 유지 비용을 합친 총량은 프로젝트의 연료 소비량이다. 그러나 총량은 시작점일 뿐이다. 총토큰만 보면 두 프로젝트가 같은 사람처럼 보인다.

A는 30만 토큰으로 로그인, 결제, 대시보드를 만들었다. 겉으로는 빠르다. 하지만 같은 인증 로직이 네 곳에 흩어져 있고, 작은 UI 수정에도 API와 상태 관리가 함께 흔들린다. 다음 주에 절반을 롤백한다.

B도 30만 토큰을 썼다. 그러나 초반 5만 토큰은 요구사항 정리와 실패 조건 검토에 쓰고, 이후에는 모듈 단위로 짧게 생성했다. 테스트가 붙어 있고, 결제 모듈은 다른 기능과 분리되어 있다. 다음 기능을 붙여도 기존 구조가 거의 흔들리지 않는다.

같은 30만 토큰이지만 경제적 의미는 완전히 다르다. A의 토큰은 속도를 빌려 기술 부채를 샀고, B의 토큰은 구조를 만들었다. 그래서 총토큰 옆에는 반드시 다음 네 지표가 붙어야 한다.

첫째, 재시도율이다. 같은 문제를 몇 번 다시 물었는가. 재시도 자체가 나쁜 것은 아니다. 초반 탐색에서는 필요하다. 그러나 동일한 에러를 이해하지 못한 채 "다시 고쳐줘"를 반복한다면, 재시도율은 학습이 아니라 사고 고착의 신호다.

둘째, 롤백률이다. AI가 만든 변경 중 실제로 되돌린 비율이다. 롤백률이 높다는 것은 모델이 실패했다는 뜻만이 아니다. 더 자주, 인간이 작업 범위와 검증 기준을 제대로 주지 못했다는 뜻이다. 즉, 프롬프트 이전 사고가 약했다는 증거다.

셋째, 중복 코드율이다. 같은 책임이 여러 파일, 여러 함수, 여러 컴포넌트에 반복되어 있는 정도다. AI는 국소적으로 그럴듯한 코드를 잘 만든다. 그러나 책임 경계가 없으면 같은 로직을 매번 새롭게 발명한다. 중복은 코드량의 문제가 아니라 시스템 기억의 붕괴다.

넷째, 수정당 영향 범위다. 작은 변경 하나가 몇 개의 파일, 몇 개의 모듈, 몇 개의 테스트를 흔드는가. 영향 범위가 넓다는 것은 결합도가 높다는 뜻이다. 엘리트 빌더는 변경의 힘을 좁은 공간에 가둔다. 바이브 코더는 작은 수정을 요청하다가 시스템 전체를 건드린다.

이 다섯 지표, 즉 총토큰과 네 가지 질적 지표를 함께 보면 토큰 사용량의 표정이 바뀐다.

많이 썼지만 안정적인 프로젝트가 있고, 적게 썼지만 위험한 프로젝트도 있다. 중요한 것은 토큰의 양이 아니라 토큰이 지나간 뒤 시스템에 남은 형태다.

바이브 코더와 엘리트 빌더를 가르는 표준 매트릭스

토큰 격차를 제대로 보려면 사용자 유형을 도덕적으로 나누지 말고 작동 방식으로 나눠야 한다. 바이브 코더는 게으른 사람이 아니다. 많은 경우 그는 빠른 결과를 원하고, AI의 유창함에 끌려 판단을 외주화한 사람이다. 엘리트 빌더는 토큰을 안 쓰는 사람이 아니다. 그는 토큰이 들어갈 위치를 먼저 정하는 사람이다.

이 표에서 중요한 것은 어느 한쪽을 조롱하는 것이 아니다. 바이브 코딩은 초반 탐색과 프로토타입에는 강력하다. 문제는 그 방식을 시스템 중심부까지 끌고 들어갈 때 생긴다. 반대로 엘리트 방식도 무조건 우월하지 않다. 설계만 하다가 검증 가능한 산출물을 만들지 못하면, 그것 역시 다른 종류의 낭비다.

토큰 격차 매트릭스는 그래서 양쪽의 실패를 모두 잡아야 한다. 한쪽은 너무 많이 실행해서 망하고, 다른 한쪽은 너무 늦게 실행해서 망한다.

토큰당 가치를 어떻게 설계할 것인가

질적 지표는 완벽한 숫자가 될 수 없다. 그러나 불완전한 측정도 무측정보다 낫다. 특히 AI 빌딩에서는 "느낌상 잘됐다"가 가장 위험하다. 모델의 출력은 그럴듯하고, 데모는 움직이며, 사용자는 잠시 흥분한다. 숫자는 이 흥분을 식히기 위해 필요하다.

첫 번째 지표는 토큰당 가치다. 단순히 기능 개수를 총토큰으로 나누는 방식은 얕다. 기능이 많아도 사용자가 쓰지 않으면 가치가 아니다. 더 나은 방식은 검증된 가치 단위를 세는 것이다. 예를 들어 실제 사용자가 완료한 핵심 행동, 줄어든 수작업 시간, 해결된 고객 문제, 통과한 비즈니스 조건을 기준으로 삼는다.

토큰당 가치는 이렇게 물을 때 드러난다. "이 대화 이후 사용자가 할 수 있게 된 일이 무엇인가?" 답이 불분명하면 많은 토큰을 썼어도 가치 전환은 낮다.

두 번째 지표는 토큰당 구조 안정성이다. 이 지표는 생성된 코드가 얼마나 오래, 얼마나 조용히 버티는지를 본다. 테스트 통과 여부만으로는 부족하다. 다음 수정 때 기존 설계가 유지되는지, 예외 처리가 한곳에 모이는지, 새로운 기능이 기존 계약을 깨지 않는지 봐야 한다.

토큰당 구조 안정성이 높은 프로젝트는 이상한 특징을 보인다. 시간이 갈수록 더 빨라진다. 처음에는 느려 보이지만, 모듈과 규칙이 쌓인 뒤부터 AI에게 작은 단위로 정확히 일을 맡길 수 있다. 반대로 구조 안정성이 낮은 프로젝트는 시간이 갈수록 느려진다. 처음에는 빠르지만, 나중에는 모든 수정이 지뢰 제거가 된다.

세 번째 지표는 토큰당 학습량이다. 이 지표는 AI가 만든 결과물이 빌더의 내부 모델을 얼마나 개선했는지 묻는다. 작업이 끝난 뒤 빌더가 더 짧고 정확한 프롬프트를 쓸 수 있는가. 같은 버그를 다시 만나면 원인을 설명할 수 있는가. 다음 프로젝트에서 재사용할 설계 원칙이 남았는가.

토큰당 학습량이 낮은 사람은 매번 처음부터 AI에게 묻는다. 토큰당 학습량이 높은 사람은 AI와의 한 번의 대화가 다음 열 번의 대화를 짧게 만든다. 이것이 인지 증폭이다. AI가 답을 대신 낸 것이 아니라, 인간의 판단 구조를 더 촘촘하게 만든 것이다.

세 지표를 한 줄로 줄이면 다음과 같다.

이 표는 정교한 회계 장부라기보다 빌더의 거울에 가깝다. 숫자를 붙이는 목적은 남에게 자랑하기 위해서가 아니다. 자신이 지금 토큰을 가치로 바꾸고 있는지, 아니면 불안을 출력으로 덮고 있는지 보기 위해서다.

자본은 평균을 끌어올리지만 정상을 보장하지 않는다

고성능 모델, 긴 컨텍스트, 넉넉한 사용량은 분명 강력하다. 이것을 과소평가하면 안 된다. 자본은 평균 성과에 큰 영향을 준다. 초보자는 더 많이 물어볼 수 있고, 더 많은 예시를 볼 수 있으며, 실패를 여러 번 복구할 수 있다. 교육기관이나 조직이 프리미엄 AI 접근권을 제공하면 학습 속도와 실험 기회가 실제로 달라진다.

그러나 자본이 최상위 구조 설계 능력을 자동으로 만들지는 못한다. 이유는 단순하다. 구조 설계는 생성량이 아니라 선택 능력에 의존하기 때문이다. AI가 열 개의 대안을 만들 수는 있다. 하지만 무엇을 버릴지, 어떤 의존성을 끊을지, 어떤 규칙을 프로젝트의 헌법으로 삼을지는 인간이 판단해야 한다.

자본의 힘이 상대적으로 제한되는 조건은 분명하다. 문제가 작은 책임 단위로 분해될 수 있을 때, 테스트와 실패 기준이 명확할 때, 빌더가 도메인 지식을 가지고 있을 때, 변경을 점진적으로 검증할 수 있을 때다. 이런 조건에서는 무료 요금제나 제한된 호출량도 충분히 날카로운 결과를 낼 수 있다. 오히려 제한은 프롬프트 이전 사고를 강제한다.

반대로 자본의 힘이 크게 작동하는 영역도 있다. 대규모 데이터 처리, 긴 문서 검토, 고비용 평가, 보안 감사, 부하 테스트, 다양한 사용자 시나리오의 대량 검증이 필요한 경우다. 여기서 "사유만 깊으면 된다"고 말하는 것은 낭만이다. 엘리트 빌더는 자본의 힘을 부정하지 않는다. 다만 자본이 판단을 대신할 수 없다는 선을 분명히 긋는다.

분석 마비도 매트릭스에 넣어야 한다

이 책은 토큰 낭비를 비판하지만, 무사용을 찬양하지 않는다. 제로 토큰 엔진은 실행을 영원히 미루는 핑계가 아니다. 머릿속 시뮬레이션이 깊어질수록 한 가지 위험이 생긴다. 더 완벽한 구조를 찾느라 검증 가능한 산출물을 늦게 내는 것이다. 이것이 분석 마비다.

분석 마비는 엘리트 모델의 그림자다. 바이브 코더가 너무 빨리 AI에게 넘긴다면, 분석 마비에 빠진 빌더는 너무 오래 자신에게만 묻는다. 둘 다 현실의 피드백을 놓친다. 차이는 방향뿐이다.

그래서 매트릭스에는 첫 검증 산출물까지 걸린 시간이 들어가야 한다. 또한 의사결정 지연 시간도 봐야 한다. 설계 대안이 세 개 있을 때 며칠 동안 결정을 못 내리고 있다면, 그것은 신중함이 아니라 비용이다. 마지막으로 가설 유통기한을 봐야 한다. 머릿속에서 세운 가설은 일정 시간이 지나면 실제 사용자, 테스트, 로그, 코드 실행으로 검증되어야 한다.

이 세 지표는 엘리트 빌더에게 특히 중요하다.

엘리트 빌더는 토큰을 쓰지 않는 사람이 아니다. 그는 토큰을 너무 이르게 쓰지도, 너무 늦게 쓰지도 않는 사람이다. 좋은 매트릭스는 과소 실행과 과잉 실행을 동시에 잡아낸다.

프롬프트 전에 읽어야 할 계기판

새로운 토큰 격차 매트릭스는 복잡한 회계표가 아니다. 프롬프트를 쓰기 전에 잠깐 멈추게 만드는 계기판이다.

이번 요청이 만들 검증 가능한 가치는 무엇인가. 같은 문제를 몇 번 반복하고 있는가. 실패하면 무엇을 롤백할 것인가. 이 변경은 몇 개의 모듈을 건드려야 정상인가. AI가 만들면 안 되는 영역은 어디인가. 작업이 끝난 뒤 나는 무엇을 더 잘 설명할 수 있어야 하는가.

이 질문에 답하지 못한 채 쓰는 토큰은 대개 흐려진다. 반대로 이 질문에 답한 뒤 쓰는 토큰은 짧아도 강하다. 토큰 격차의 본질은 사용량의 차이가 아니라 변환율의 차이다. 같은 1만 토큰을 써도 누군가는 더 많은 혼란을 얻고, 누군가는 더 선명한 구조를 얻는다.

다음 시대의 빌더는 토큰을 자랑하지 않는다. 그는 토큰이 남긴 흔적을 본다. 가치가 남았는가. 구조가 남았는가. 학습이 남았는가. 이 세 가지가 없다면 수억 토큰도 연기일 뿐이다. 이 세 가지가 있다면 제한된 토큰도 충분히 무기가 된다.