망각하는 에이전트에게 매번 다시 설명하기 위해 지불하던 고가의 비용을 중단한 이유
요약
AI 에이전트의 망각 문제와 높은 비용을 해결하기 위해, 모델의 성능에 의존하는 대신 결정론적인 스크립트를 통해 검증 프로세스를 구축하는 전략을 제안합니다. 고성능 모델로 기술을 설계한 뒤, 저렴한 모델과 외부 검증 스크립트를 조합하여 비용 효율적이고 신뢰할 수 있는 시스템을 만드는 방법론을 다룹니다.
핵심 포인트
- 에이전트의 망각은 모델 업그레이드가 아닌 외부 스크립트로 해결해야 함
- 확률론적 모델 대신 결정론적 코드로 제약 조건을 강제할 것
- 최고 사양 모델은 기술 설계 단계에서만 사용하고 실행은 저렴한 모델로 전환
- 결과물의 품질 검증 주체를 모델에서 외부 테스트 스크립트로 변경
최고의 모델을 사용하여 AI 기술(skill)을 한 번 구축하세요. 그다음, 다음 플래그십(flagship) 모델이 출시될 때까지 그 비용의 10분의 1 수준인 모델에서 실행하세요. 출력 결과는 떨어지지 않을 것입니다.
이것이 성능 저하(downgrade)처럼 들릴 수도 있습니다. 하지만 그렇지 않습니다. 이는 현재 AI 에이전트(agent)를 고통스럽게 만드는 두 가지 문제, 즉 '망각'과 '비싼 비용'을 해결합니다. 이 두 가지는 모두 동일한 지점에서 해결되며, 그 해결책은 당신이 선택하는 모델에 있지 않습니다.
목표를 설명하면 에이전트가 두 번은 완벽하게 해내다가, 세 번째 실행에서는 가장 중요한 제약 조건(constraint) 하나를 조용히 놓쳐버립니다. 모델을 업그레이드한다고 해서 이 문제가 해결되지는 않습니다. 단지 놓쳐버린 제약 조건에 더 많은 비용을 지불하게 만들 뿐입니다. 당신은 더 정중하게 잊혀지기 위해 프런티어(frontier) 가격을 지불하고 있는 셈입니다.
문제는 목표가 이를 유지할 수 없는 두 곳에 머물러 있다는 점입니다. 하나는 컨텍스트(context)가 길어지는 순간 정보가 부패하는 대화(conversation) 속이고, 다른 하나는 목표를 날카롭게 유지할 때마다 실행할 때마다 돈을 태워버리는 모델(model) 내부입니다.
화요일에 놓친 그 제약 조건은 스크립트(script)에 있어야 합니다
품질은 작업을 검증하는 무엇으로부터 나옵니다. 결과물을 만들어낸 모델은 거의 부차적인 문제입니다. 따라서 당신의 기술(skill) 각 단계에 대한 정확한 종료 기준(exit criteria)을 결정한 다음, 이를 강제하는 결정론적(deterministic) 스크립트를 작성하세요. 폴더가 존재하는가? 파일이 파싱(parse)되는가? 테스트가 통과하는가? 린트(lint)가 깨끗한가? 에이전트는 자신의 출력물을 스스로 채점하는 대신 스크립트의 판결을 읽어야 합니다.
스크립트는 목표를 잊을 수 없습니다. 그것이 핵심입니다. 당신의 에이전트가 제약 조건을 놓치는 이유는, 확률론적 시스템(probabilistic system)이 머릿속에 엄격한 요구 사항을 유지할 것이라고 믿었기 때문입니다. 요구 사항을 코드로 옮겨서, 요구 사항이 깨졌을 때 실행이 실패하도록 만드세요. 그러면 망각은 더 이상 불가능해집니다. 당신은 더 이상 같은 말을 반복할 필요가 없습니다. 테스트 하네스(harness)가 매 실행마다 당신을 대신해 정확하게 반복해주기 때문입니다.
비싼 모델이 실제로 제값을 하는 곳
이것이 프런티어 모델이 제값을 하는 유일한 곳입니다. 현재 당신이 가진 최고의 모델을 사용하여 기술(skill)을 최대한 정확하게 구축하세요. 단계를 명명하세요. 각 단계의 정확한 목표를 명시하세요. 종료 스크립트(exit scripts)를 제대로 만드세요. 그것은 어렵고 판단력이 많이 요구되는 작업이며, 당신은 그것을 단 한 번만 수행하면 됩니다.
그다음 모델을 교체하고 저렴한 모델로 해당 기술(skill)을 실행하세요. 터미널 대신 UI를 원한다면 opencode 데스크톱 앱을 통해 OpenRouter로 연결된 Gemini 2.5 Flash를 사용하면 됩니다. 저렴한 모델이 생성하고, 스크립트(scripts)가 검문합니다. 당신은 모델이 자신의 작업에 대해 내린 의견이 아니라, 스크립트의 출력값을 검토합니다.
저렴한 모델도 동일한 기준을 통과합니다. 왜냐하면 그 기준이 모델 외부에서 강제되기 때문입니다. 훨씬 적은 비용이 드는 모델이 당신이 신뢰할 수 있는 결과물을 만들어냅니다. 모델이 하룻밤 사이에 똑똑해진 것이 아닙니다. 작업물이 출시하기에 충분히 좋은지 결정하는 주체가 더 이상 모델이 아니게 된 것입니다.
프론티어 모델(Frontier model)은 출시일에 다시 고용하는 계약업체입니다
그 흐름은 다음과 같습니다. 새로운 플래그십(flagship) 모델이 출시됩니다. 당신은 단 한 가지 작업을 위해 모델을 불러옵니다. 새로운 기술(skills)을 구축하고, 새로운 성능 한계치(ceiling)에 맞춰 이미 실행 중인 모든 하네스(harness)를 재검증하는 것입니다. 그 작업이 끝나면 모델을 놓아줍니다. 다음 플래그십이 나올 때까지, 당신은 비용 효율성 측면에서 유리한 곳이라면 소형 언어 모델(SLM)을 포함하여 모든 것을 오직 저렴하고 로컬인 모델로만 실행합니다.
이는 모든 사람이 자신이 갇혀 있다고 가정하는 의존성을 뒤집는 것입니다. 당신은 제품이 유지되는 내내 프론티어 지능(frontier intelligence)을 빌려 쓰는 것이 아닙니다. 당신은 릴리스 사이클당 며칠 동안만 최고 요율을 지불하며, 한 달에 만 번 실행되는 것은 비용이 거의 들지 않는 소형 모델입니다. 스크립트가 목표를 보유하고 있기 때문에 망각(forgetting)은 사라집니다. 저렴한 모델이 스크립트를 통과하기 때문에 비용이 품질에 따라 비례하여 늘어나지 않습니다.
나는 이번 분기에 가장 똑똑한 모델을 출시하는 누군가에 대한 지속적인 의존성이 아니라, 하네스(harness)를 구축합니다.
당신이 마지막으로 논쟁했던 에이전트(agent)를 열어보세요. 그 대화 중 얼마나 많은 부분이 스크립트가 보유할 수 있었던 목표를 당신이 다시 설명하고 있었던 부분이었나요? 그리고 당신은 그 목표를 잊어버리는 대가로 어떤 모델에 비용을 지불하고 있었나요?
저는 실제 구축 사례, AI 통합, cron 기반 자동화, 그리고 프로덕션 환경에서 고장 나는 부분들에 대한 현장 노트를 작성합니다. 2주마다 새로운 포스트가 올라옵니다. 이 글이 유용했다면, 에이전트 플레이북(the agent playbook)이 함께 내려받을 수 있는 동반 자료입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기