코인베이스 공동창업자 브라이언 암스트롱이 이런 말을 했대. "앞으로 12~18개월 안에 AI 워크로드의 80%가 지금보다 99% 더 저렴한 모델에서 돌 것"이라고. 숫자가 좀 과장된 것 같긴 해도, 이 예측이 던지는 방향성은 분명해 보이지 않아? 지금까지 AI 개발은 '가장 강력한 모델'을 쓰는 게 국룰처럼 여겨졌잖아. 그런데 이제 그 전제가 흔들리는 중이야.

무조건 최강 모델? 이제 흔들린다

그동안 AI 회사들은 대부분 품질로 경쟁했고, 그래서 제품 만들 때도 가장 좋은 모델을 붙이는 게 당연하게 느껴졌을 거야. 고객 입장에서도 마찬가지였고. 투자 보조금도 있고, 모델 가격 경쟁도 치열할 땐 굳이 작은 모델을 고를 이유가 없었거든. 같은 일을 시킨다면 GPT나 Claude의 가장 강한 모델을 쓰는 게 안전한 선택이었지.

하지만 이런 분위기 속에서 최근 흥미로운 사건이 있었어. LLMOps 오픈소스 플랫폼 TensorZero가 730만 달러 시드 투자를 유치한 지 얼마 안 돼서 갑자기 GitHub 저장소를 아카이브하고 서비스 중단을 발표했어. 이미 전 세계 LLM API 트래픽의 1%를 처리할 정도로 활발하게 사용되던 플랫폼인데 말이야. 공동 창업자 말로는 투자금의 절반도 채 안 썼다고 하니, 단순한 자금 문제는 아닌 것 같아. 단순히 좋은 기술과 막대한 트래픽만으로는 AI 비즈니스의 지속 가능성을 담보할 수 없다는 걸 보여주는 씁쓸한 사례가 아닐까 싶어. 결국 비용 효율성, 즉 수익성이 중요하다는 방증이겠지.

'품질'의 정의가 바뀌고 있다

그럼 '효율성'을 어떻게 확보할까? 법률 AI 회사 하비(Harvey) 사례를 봐봐. 하비는 파이어웍스 AI(Fireworks AI)와 함께 클로드 오푸스(Claude Opus) 같은 강한 모델과 GLM 5.1 같은 더 저렴한 모델을 섞어 썼대. 모든 작업에 비싼 모델을 쓰는 대신, 정말 어려운 작업에만 오푸스를 호출하는 방식으로. 결과는 어땠을까? 추론(inference) 비용을 약 3배나 낮추면서도 품질은 그대로 유지했어. 법률 업무가 품질 요구가 낮은 영역이 아니라는 걸 생각하면 대단한 결과지.

이 사례가 우리에게 시사하는 바가 커. '품질'의 정의가 "가장 강한 모델을 항상 쓰는 것"에서 "올바른 답을 가장 적절한 모델 조합으로 내는 것"으로 바뀌고 있다는 이야기야. 이제 AI 제품의 경쟁력은 무조건 최고 모델을 붙이는 능력만으로 설명되지 않아. 어떤 태스크에 어떤 지능을 배치하느냐가 새로운 경쟁력이 되는 시대가 온 거야.

프롬프트 대신 '루프'를 설계해야 하는 이유

그럼 이런 효율성은 단순히 모델 조합에서만 오는 걸까? 아니, 에이전트 개발 방식 자체도 변하고 있어. 클로드 코드(Claude Code)를 만든 보리스 체르니가 그러더라. "나는 더 이상 클로드에 프롬프트를 치지 않는다. 내 일은 루프를 짜는 것이다"라고. 오픈클로(OpenClaw) 피터 스타인버거도 비슷한 말을 했어. "코딩 에이전트에게 프롬프트를 치지 마라. 에이전트를 프롬프트하는 루프를 설계하라."

이 '루프 엔지니어링'이라는 게 뭐냐면, 사람이 일일이 프롬프트를 넣고 결과를 확인하고 다시 입력하는 방식에는 한계가 있잖아. 이걸 극복하려고 태스크 발견부터 분배, 실행, 검증, 다음 태스크 결정까지 에이전트가 자동으로 반복하도록 시스템을 만드는 거야. 일종의 '자동화된 AI 엔지니어'를 만드는 거지.

RLM이 제시하는 효율적인 에이전트 구조

이 루프 엔지니어링의 이론적 기반에는 RLM(Recursive Language Model)이라는 개념이 있어. 기존 LLM은 입력 전체를 컨텍스트 윈도우에 한꺼번에 올리잖아? 그런데 RLM은 달라. REPL(Read-Eval-Print Loop) 환경처럼 컨텍스트라는 변수가 있고, 에이전트가 필요한 부분만 골라 읽어. 불필요한 정보가 컨텍스트를 채우지 않도록 말이야.

이렇게 되면 여러 장점이 생겨. 서브 에이전트의 결과가 컨텍스트 전체가 아니라 파이썬 변수로 돌아와서, 상위 에이전트는 그 변수만 검증하고 최종 결과를 반환할 수 있어. 결과를 토큰 단위로 다시 생성할 필요가 없으니 출력 길이 제한도 사실상 없고, 무엇보다 기존 단일 컨텍스트 윈도우에서 생기던 에이전트의 '게으름(agentic laziness)', '자기편향(self-preferential bias)', '목표 이탈(goal drift)' 같은 문제를 구조적으로 차단할 수 있지.

그리고 비용 면에서도 유리해져. 서브 에이전트가 한 단계씩 작업할 때 시스템 프롬프트와 이전 메시지가 그대로 유지되니까, KV 캐시(cache) 히트 비율이 90%까지 올라갈 수 있대. 에이전트가 읽을 범위를 직접 결정해서 전체 프롬프트를 매번 스캔하는 비용도 줄어들고. 아직은 비용이 높은 부분이 있지만, 분명히 효율성을 향한 방향은 잡힌 거지.

우리에게 남겨진 질문

이제 우리 개발자나 스타트업 창업가들은 '어떤 모델이 가장 강한가?'가 아니라, '이 태스크에 어떤 모델 조합과 에이전트 설계가 가장 효율적인가?'를 고민해야 하는 시점에 온 것 같아. 단순히 프롬프트 엔지니어링을 넘어, 에이전트가 스스로 일할 수 있는 '루프'를 설계하는 능력, 그리고 다양한 모델을 조합해 최적의 효율을 뽑아내는 전략이 중요해진 거지.

너희 팀은 지금 AI 모델 선택이나 에이전트 설계에서 어떤 기준을 가장 중요하게 보고 있어?

참고

  • AI OSS tool repo goes archived over night after raising $7.3M Seed https://github.com/tensorzero/tensorzero
  • AI 최강 모델 시대 저물고, 효율성이 대세로 https://www.linkedin.com/feed/update/urn:li:activity:7470254660235247616/
  • 프롬프트에서 '루프 설계'로: RLM 기반 에이전트 진화 https://www.linkedin.com/feed/update/urn:li:activity:7469915687986098177/