비싼 AI 모델은 어려운 부분만, 저렴한 모델은 나머지를 처리하면 비용이 굳을 것 같습니다. 시니어가 설계하고 주니어가 구현하는 구조를 그대로 옮긴 셈이죠.

AI 코딩 도구 회사 Stencil이 이 직관을 실제로 측정해봤습니다. 결과는 반대였습니다. 비싼 모델이 설계만 하고 저렴한 모델이 실행하는 방식, 오히려 14% 더 비쌌습니다.

출처: You only need the frontier model for one single edit – Stencil

비용은 편집이 아니라 읽기에서 나온다

Stencil이 실제 코딩 작업에서 에이전트가 쓴 토큰을 전부 뜯어봤습니다. 전체 토큰 중 실제로 코드를 쓰거나 고치는 데 쓰인 건 9%뿐이었습니다. 나머지 91%는 읽는 데 들어갔죠.

특정 모델이나 도구만의 얘기가 아니었습니다. 어떤 에이전트, 어떤 모델, 어떤 스캐폴딩을 쓰든 비용은 결국 읽은 양에 비례한다는 게 Stencil의 설명입니다. 파일을 열어보고, 테스트 코드를 훑고, 관련 함수를 검색하고. 이 과정이 쌓여서 청구서가 됩니다. 정작 코드를 고치는 작업 자체는 비용에서 큰 비중을 차지하지 않는다는 겁니다.

계획 문서는 이해가 아니라 엽서였다

그렇다면 왜 “비싼 모델이 설계만, 저렴한 모델이 실행”하는 방식이 돈을 아끼지 못했을까요. 답은 방금 확인한 비용 구조에 있습니다.

비싼 모델이 코드를 읽고 쌓은 이해는 수십만 토큰 분량의 맥락 속에 있습니다. 어떤 파일을 열었는지, 어떤 가설을 세웠다가 버렸는지, 어떤 시도가 통했는지. 이 전부가 그 맥락 안에 녹아 있는 겁니다. 하지만 넘겨주는 계획 문서는 이걸 2천 토큰 남짓으로 압축한 요약본에 불과합니다. Stencil은 이걸 “여행을 다녀오지 않은 사람에게 보내는 엽서”라고 부릅니다.

문제는 여기서 시작됩니다. 엽서를 받은 저렴한 모델은 그 안에 담기지 않은 나머지 맥락을 다시 확보해야 합니다. 계획서만 보고는 무슨 파일을 왜 그렇게 고쳐야 하는지 확신할 수 없거든요. 그래서 같은 파일들을 처음부터 다시 읽습니다. 비싼 모델이 한 번 읽은 값을 비싼 가격에 지불하고, 저렴한 모델이 또 한 번 같은 내용을 읽으면서 두 번째 비용이 붙는 구조입니다. 아끼려던 지점이 오히려 중복 지출이 되어버린 셈이죠.

문서 대신 맥락 자체를 넘긴다

Stencil이 찾은 대안은 발상이 조금 다릅니다. 계획을 문서로 정리해 넘기는 대신, 프론티어 모델이 탐색하며 쌓아온 맥락, 대화의 흐름 자체를 그대로 이어받게 하는 방식입니다.

Stencil이 prewalk라 부르는 이 방식은 이렇게 흘러갑니다. 먼저 프론티어 모델이 과제를 시작하면서 깊이 탐색하고 계획을 세웁니다. 그 계획을 할 일 목록으로 정리하고요. 첫 편집이 실제로 이뤄지는 순간, 그러니까 모델이 충분히 확신을 갖고 행동에 나선 바로 그 지점에서 저렴한 모델로 전환합니다. 이때 “계획을 세우라”던 원래 지시는 맥락에서 지워버립니다.

그러면 저렴한 모델 입장에서는 자신이 처음부터 탐색하고 계획도 세운 뒤 실행에 들어간 것처럼 보입니다. 이미 유효한 편집 하나를 실행해본 상태로 시작하는 셈이니, 맥락 안에 공짜 예시까지 하나 딸려 오는 셈이고요.

결과는 이렇습니다. 프론티어 모델 성능의 97% 수준을 유지하면서 비용은 41% 낮아졌습니다. 완료 속도는 1.9배 빨라졌고, 부정확한 답을 그럴듯하게 포장하는 경향(치팅)도 약 3분의 1로 줄었네요.

이건 우연히 나온 결과가 아닙니다. 프론티어 모델로 작업을 시작했다가 몇 턴 지나면 다른 모델로 바꾸던 개발자들의 습관, 그 경험적 직감을 Stencil이 정식으로 검증한 겁니다. 에이전트 비용을 줄이려 할 때 먼저 물어야 할 건 “누가 어떤 일을 맡을까”가 아니라 “누가 무엇을 다시 읽게 되는가”였던 셈입니다.