8B 모델로 99% 성공률? 에이전트 AI의 진짜 해법은 '크기'가 아니었습니다

요즘 AI 에이전트 이야기 정말 많이 들으시죠. 그런데 막상 써보면 “와 신기하다"와 “이거 왜 또 멈췄지” 사이를 오갑니다. 왜 에이전트는 데모에서는 그럴듯한데 실전에서는 자꾸 무너질까요. 최근 Forge라는 프레임워크가 내놓은 답이 흥미롭습니다. 8B짜리 작은 모델의 에이전트 성공률을 53%에서 99%로 끌어올렸다는 건데요. 비결이 모델 크기가 아니라는 점이 핵심입니다.

왜 에이전트는 자꾸 실패할까요

LLM 에이전트의 가장 큰 약점은 누적 오차입니다. 단일 질문에 답하는 거라면 작은 모델도 잘합니다. 그런데 에이전트는 다릅니다. 도구를 부르고, 결과를 해석하고, 다음 단계를 결정하고, 다시 도구를 부르는 과정을 수십 번 반복합니다.

각 단계의 정확도가 95%라고 해도, 20단계를 거치면 0.95의 20제곱, 즉 약 36%까지 떨어집니다. 작은 모델일수록 단계별 정확도가 낮으니 멀티스텝 태스크에서는 거의 무용지물이 되어버리는 거죠. 그래서 다들 GPT-4급 거대 모델로 달려갔습니다.

Forge가 던진 질문

Forge 팀의 접근은 달랐습니다. “모델을 더 크게 만들지 말고, 모델이 실수할 여지를 줄이자”는 발상이었습니다. 8B 모델 — 그러니까 우리가 흔히 보는 Llama 3 8B나 Mistral 7B급의 가벼운 모델을 그대로 두고, 그 주변을 둘러싸는 가드레일을 짰습니다.

이 가드레일의 핵심은 세 가지입니다. 첫째, 구조화된 출력 강제입니다. 모델이 자유 형식으로 답하게 두지 않고, 미리 정의된 스키마 안에서만 응답하도록 묶어둡니다. 잘못된 형식이 나오면 즉시 재시도시킵니다.

둘째, 중간 검증입니다. 각 단계의 출력이 다음 단계로 넘어가기 전에 자동 검증을 거칩니다. 예를 들어 “파일 경로를 반환했는데 실제로 존재하는가” 같은 체크를 코드 레벨에서 처리합니다. 모델이 헛소리하면 그 자리에서 잡아냅니다.

셋째, 도구 호출의 결정론적 라우팅입니다. 모델이 “이 도구를 부를까 저 도구를 부를까” 망설일 여지 자체를 줄입니다. 컨텍스트에 따라 호출 가능한 도구를 미리 좁혀놓는 거죠.

53%에서 99%로, 숫자가 말하는 것

벤치마크 결과는 인상적이었습니다. 동일한 8B 모델을 가드레일 없이 돌렸을 때 에이전트 태스크 성공률은 53%. 가드레일을 씌우자 같은 모델이 99%를 기록했습니다. 모델의 파라미터는 단 하나도 바뀌지 않았는데 말입니다.

이게 무슨 의미일까요. 그동안 우리가 “AI 에이전트가 안 되는 이유"라고 믿었던 것 중 상당 부분이 사실은 모델의 한계가 아니라 엔지니어링의 부재였다는 뜻입니다. 모델은 충분히 똑똑한데, 그 똑똑함을 시스템이 받쳐주지 못했던 거죠.

비용과 속도의 게임 체인저

이게 왜 중요하냐면, 비용과 지연시간이 완전히 달라지기 때문입니다. 8B 모델은 한 장의 소비자용 GPU에서도 돌아갑니다. GPT-4급 모델을 API로 호출하는 것과 비교하면 비용은 수십 배, 응답 속도는 몇 배 차이가 납니다.

특히 에이전트는 호출 횟수 자체가 많습니다. 한 번의 사용자 요청에 모델을 30번, 50번 부르는 일이 흔합니다. 여기서 모델당 비용 차이가 곱연산으로 누적되면 서비스 운영의 게임 자체가 바뀝니다. 작은 모델로 99% 성공률이 나온다면, 굳이 거대 모델을 쓸 이유가 사라지는 셈입니다.

그래서 우리는 무엇을 배우나요

이 사례가 흥미로운 건 단순히 “작은 모델도 잘한다"가 아닙니다. AI 시스템의 병목이 모델이 아닐 수 있다는 메시지입니다. 지난 2-3년간 업계는 “모델만 더 크면 다 해결된다"는 분위기였습니다. 그런데 이제 그 가정에 균열이 가고 있습니다.

여러분이 만약 에이전트 제품을 만들고 있다면, 한 번쯤 물어볼 만한 질문이 생긴 셈입니다. 우리가 지금 GPT-5를 기다리는 게 정말 답일까요, 아니면 우리 시스템의 가드레일을 다시 짜는 게 답일까요. Forge의 53→99 점프는 후자의 손을 들어준 사건입니다.