같은 모델인데 결과가 다르다 — 에이전트 프레임워크 비교 실험에서 드러난 것들
똑같은 LLM 모델에 똑같은 프롬프트를 먹였는데, 프레임워크 하나 바꿨다고 토큰 요금과 자가수정 루프가 완전히 널을 뛴다? r/zaiglm에 올라온 한 개발자의 비교 실험 글을 보다가 뒤통수를 세게 맞았다(동시에 내 지난달 API 청구서가 스쳐 지나가며 등골이 서늘해졌다).
실험 세팅은 깔끔하다. GLM 5.3 Flash라는 동일한 모델을 딱 세워두고, 완전히 똑같은 4개의 작업 프롬프트를 던졌다. 다른 건 단 하나, 이를 굴리는 에이전트 프레임워크가 OpenClaw 2.0이냐 Hermes냐 뿐이었다. 모델 두뇌가 100% 동일하니, 성능이나 비용에서 차이가 난다면 그건 순전히 ‘프레임워크의 엔지니어링 설계’ 탓이라는 소리다. 그리고 그 결과는 꽤나 충격적이었다.
숫자부터 보자
결과 수치부터 까보자.
- OpenClaw 2.0: 토큰 2.1M, 비용 $4.50, 자가수정 10회
- Hermes: 토큰 2.9M, 비용 $4.00, 자가수정 20회
숫자를 언뜻 보면 고개가 갸우뚱해진다. 분명 Hermes 쪽이 토큰을 무려 38%(80만 토큰이나!) 더 썼는데, 정작 최종 청구된 비용은 $4.00으로 오히려 더 저렴했다. 토큰을 80만 개나 더 썼는데 돈이 덜 나온다고? 상식적으로 앞뒤가 안 맞아 보인다(버그인가 싶었다).
비밀은 ‘입력(Input) 토큰과 출력(Output) 토큰의 단가 차이’에 있었다. API 좀 만져본 개발자라면 알겠지만, LLM 과금 체계에서 출력 토큰은 입력 토큰보다 몇 배씩 비싸다(보통 3~5배 이상 차이 난다).
OpenClaw는 매 턴마다 이전 컨텍스트 전체를 무겁게 다시 밀어 넣는 구조라 비싼 출력보다는 상대적으로 저렴한 ‘입력 토큰’ 비중이 압도적으로 높았다. 반면 Hermes는 짧은 응답을 미친 듯이 여러 번 생성하며 비싼 출력 토큰을 야금야금 갉아먹었던 거다. 결국 총 토큰 숫자가 얼마냐가 아니라, ‘입력과 출력의 비율이 어떻게 쪼개지느냐’가 통장 잔고를 결정한다는 뼈아픈 교훈이다.
자가 검증 전략이 결과를 바꾼다
더 눈여겨봐야 할 대목은 자가수정(Self-Correction) 횟수다. Hermes는 무려 20번이나 코드를 고쳤고, OpenClaw는 딱 10번 만에 작업을 끝냈다. 왜 이런 두 배 차이가 났을까?
원인은 두 프레임워크가 “작업이 잘 끝났는가?”를 판정하는 ‘검증 전략’에 있었다.
Hermes는 화면 스크린샷의 픽셀 변화를 카운트해서 결과를 검증했다. 화면이 바뀌었는지만 세어보는 방식이다. 반면 OpenClaw는 테스트 셋을 직접 빌드해서 테스트 통과 여부로 결과를 판정했다.
픽셀 카운트는 가볍고 빠르지만 오탐(False Positive)이 어마어마하게 많다. 실제로는 코드가 개판인데 픽셀 몇 개 바뀌었다고 헤매거나, 반대로 잘 돌아가는데 픽셀 미세 차이로 틀렸다고 판단해 쓸데없는 수정 루프를 끝없이 뺑뺑이 돈 거다(인간 개발자도 이러면 야근 확정이다). 반면 테스트 셋을 구축하는 방식은 초반 토큰이 좀 들더라도 한 번 통과하면 군더더기 없이 끝난다. 20회 대 10회의 자가수정 차이는 결국 검증 기준이 얼마나 엄밀한가에서 갈린 셈이다.
에이전트가 “스스로 알아서 반성하고 고친다”는 말은 참 달콤하게 들린다. 하지만 검증 기준이 부실하면, 그건 자가수정이 아니라 그냥 혼자 토큰을 태우며 헛발질하는 것에 불과하다.
왜 주목할까
요즘 개발자 커뮤니티에서 코딩 에이전트 이야기를 꺼내면 열에 아홉은 “그래서 무슨 모델 쓰는데?”로 귀결된다. Claude냐, GPT냐, GLM이냐 벤치마크 랭킹만 뚫어져라 쳐다본다.
하지만 이번 실험은 모델을 완전히 고정해 둬도, 프레임워크의 오케스트레이션 설계에 따라 비용과 수정 루프가 두 배씩 벌어질 수 있음을 적나라하게 증명했다. 실무에서 에이전트를 조금이라도 길게 굴려본 사람이라면 격하게 공감할 거다. 시스템 프롬프트를 어떻게 쪼갰는지, 컨텍스트 캐싱을 얼마나 영리하게 쓰는지, 실패 판정을 유닛 테스트로 하는지 멍청한 정규식으로 하는지에 따라 하루 작업 생산성과 청구서가 완전히 갈린다.
어떤 모델을 쓸지 고민하는 시간의 딱 절반만 에이전트 프레임워크 설계에 투자해도 체감 성능은 훨씬 드라마틱하게 올라간다. 비싼 최신 모델 쓴다고 능사가 아니라는 뜻이다.
정리
모델 벤치마크 점수가 에이전트 완성도의 전부가 아니다. 이번 실험이 남긴 교훈은 명확하다.
- 총 토큰 숫자보다 입력/출력 비율이 청구서를 좌우한다.
- 검증 기준이 엉성한 자가수정은 그냥 토큰 화형식이다(안 하느니만 못하다).
- 이 모든 차이는 모델이 아니라 프레임워크 아키텍처에서 터져 나온다.
에이전트 도구를 고르거나 직접 파이프라인을 짤 때, “어떤 모델을 물릴까” 고민하기 전에 “컨텍스트를 어떻게 관리하고, 완료 조건을 어떻게 엄격하게 검증할 것인가”부터 챙기자. 개발자의 진짜 짬바는 바로 그 뼈대를 설계하는 데서 드러난다.