#Agent 효과는 모델이 전부 결정하는가 — 엔지니어링 상한

← 전체 목차 · 이전: Agent란 무엇인가 · 다음: Agent는 어떻게 설계하는가

똑같은 모델을 붙였는데 어떤 팀은 작업 완수율 80%를 넘기고, 어떤 팀은 40%에서 멈춘다. "기반모델이 약해서", "프롬프트를 못 써서"는 변수를 통제하는 순간 무너지는 설명이다. 같은 모델을 쓴다는 것은 이미 그 변수를 고정했다는 뜻이므로, 격차는 반드시 모델 바깥에서 왔다.

#Agent는 대형모델 없이 돌아갈 수 있는가 — 아니다

Agent의 계획 단계에서 목표를 쪼개는 것도, 도구를 부를 때 파라미터를 채우는 것도, 결과를 돌려받아 다음 행동을 정하는 것도 전부 모델의 언어 이해와 추론이다. 이걸 빼면 남는 것은:

• 미리 짜놓은 도구 인터페이스
• 미리 짜놓은 스크립트 로직

즉 자율성이 없는 전통적 자동화 스크립트로 퇴화한다. "대형모델은 결정 중추이지, 있어도 그만 없어도 그만인 부속품이 아니다"라는 명제는 이 지점에서 참이다.

#그러나 모델이 강하다고 Agent가 강한 것은 아니다

모델이 강한 것은 "두뇌의 추론력이 합격선"이라는 것만 보장한다. Agent 전체의 성패는 다음 세 가지 엔지니어링 지표에도 함께 달려 있다.

전형적 증상: 모델 단독 문답 성능은 훌륭한데, 같은 모델을 Agent로 감싸면 리포트 하나 제대로 못 만든다. 이럴 때 먼저 의심해야 할 것은 모델 교체가 아니라 도구 인터페이스 안정성·장기 기억·다단계 분기 처리다.

#진짜 병목: 유연성이 아니라 통제 가능성

Agent의 본질은 문답이 아니라 대형모델이 구동하는 자동화 흐름 시스템이다. 순수 모델 구동 방식 — 결정을 전부 모델의 자유 발휘에 맡기고, 흐름 제약도 상태 검증도 없는 구조 — 은 구조적으로 다음 결함을 안고 있다.

실제 업무의 세 가지 요구
  ├─ 엄격한 스텝 의존 관계
  ├─ 입출력 규격
  └─ 결과 검수 기준
        ↓ 제약 없이 모델의 자유 판단에 전부 위임
   매 스텝마다 미세한 편차 발생
        ↓ 여러 스텝을 거치며
      편차가 누적·증폭
        ↓
   목표에서 완전히 이탈

제약 없는 자유 발휘가 주는 것은 지능이 아니라 통제 불가능한 무작위성이다. 이것이 기반모델 능력 부족보다 훨씬 흔한 Agent 실패 원인이다. 업무가 복잡해지고 결과 재현성·비용 통제 요구가 높아질수록 이 병목은 더 빨리 드러난다 — 매 스텝을 최상위 모델로 처리할 수는 없기 때문에 비용 제약 자체가 "전부 강모델" 전략을 봉쇄한다.

#계층화 결정 + 흐름 관제: 실제로 격차를 만드는 것

산업 현장에서 완료율을 끌어올리는 것은 더 강한 모델이 아니라 다음 조합이다.

같은 모델을 그대로 둔 채 이 다섯 가지만 추가해도 완료율이 크게 뛴다 — 모델의 추론 능력은 그대로 활용하면서, 편차가 누적되기 전에 공정 곳곳에서 끊어내기 때문이다. 대형모델이 일시적으로 불안정하거나 응답에 실패하는 경우에도, 규칙 기반 라우팅으로 단순 요청을 먼저 흡수하고 다중 모델로 주 모델을 대체하도록 설계하면 Agent 전체가 즉시 멈추지 않는다 — 모델은 대체 불가능한 결정 중추이지만, 그 중추 하나가 시스템 전체의 단일 장애점이 되어서는 안 된다는 뜻이다.

#경계 짓기: 두 극단을 다 피할 것

"기반모델이 전부 결정한다"      ← 틀렸다. 엔지니어링 층이 실제 도달치를 정한다.
"기반모델은 중요하지 않다"      ← 이것도 틀렸다. 핵심 추론력은 여전히 모델이 쥐고 있다.

올바른 설명:
  상한은 모델이 긋고,
  그 상한에 얼마나 가까이 도달하는가는 엔지니어링이 결정한다.

흐름 관제와 상태 일관성을 다 잡아놓은 뒤에도 여전히 못 넘는 벽이 있다면, 그때 비로소 그것이 진짜 모델 추론력의 상한이다. 순서를 거꾸로 해서 모델부터 바꾸는 것은 비용은 선형으로 늘고 효과는 체감하는 비효율적 경로다.

#핵심 통찰

1. 변수 통제는 귀인 오류를 잘라내는 가장 날카로운 칼이다 — "같은 모델인데 결과가 다르다"는 한 문장이 "모델이 부족해서"라는 설명을 즉시 무효화한다. 어떤 요인을 주범으로 지목하기 전에 "그 요인이 같은데도 결과가 달랐던 사례가 있는가"를 먼저 확인하는 습관이 이 함정을 피하는 법이다.
2. "상한"과 "도달치"는 서로 다른 두 개의 양이다 — 모델은 상한을 긋고 엔지니어링은 그 상한에 얼마나 가까이 가는가를 정한다. 이 둘을 하나로 뭉뚱그리면 "모델이 전부"라거나 "모델은 상관없다"는 극단으로 미끄러진다.
3. 여러 스텝을 거치는 오차는 더해지는 것이 아니라 증폭된다 — 스텝마다 정확도가 높아도 여러 스텝을 지나며 편차가 누적·증폭되므로, 단일 스텝에서 훌륭한 모델도 장기 체인 작업에서는 무너질 수 있다. 이것이 "Agent는 문답이 아니라 흐름 시스템"이라는 정의가 갖는 실질적 의미다.
4. 자유도는 지능이 아니라 분산이다 — 제약 없는 모델의 자유 판단이 주는 것은 유연함이 아니라 통제 불가능한 무작위성이다. 엔지니어링의 역할은 추론력을 깎지 않으면서 이 분산을 줄이는 것이다.
5. 강모델을 전 구간에 쓰지 못하는 것은 안정성 문제이기 전에 비용 문제다 — 업무 복잡도와 스텝 수가 늘수록 전량 최상위 모델 호출은 경제적으로 성립하지 않는다. 계층화 결정(강모델 계획 + 경량모델 실행)은 성능과 비용을 동시에 만족시키는 필연적 설계다.
6. "기반모델부터 바꾸자"는 가장 쉬운 설명이자 가장 책임을 외부로 돌리기 좋은 설명이다 — 논리가 단순하고 책임을 벤더에게 넘길 수 있어 조직 내부에서 저항이 가장 적은 경로지만, 근본적인 안정성 상한을 갖고 있어 근본 해결책이 되지 못한다.
7. 모호한 작업 경계가 약한 모델보다 프로젝트를 더 자주 망가뜨린다 — 목표가 불명확하고 정량화된 성공 기준이 없고 열린 시나리오를 전부 처리하려는 시도, 이 세 가지가 모델 성능과 무관하게 시스템을 영구히 기준 미달 상태에 묶어둔다. 경계 정의는 최적화 이전의 전제조건이지 후속 개선 항목이 아니다.
8. 단일 장애점을 모델 하나에 두지 않는 것이 결정 중추를 부정하는 것과는 다르다 — 규칙 전치·다중 모델 대체·완료 경로 캐시는 "모델이 필요 없다"는 뜻이 아니라 "그 결정 중추가 죽었을 때 전체 시스템까지 같이 죽지 않게 한다"는 뜻이다. 이 둘을 혼동하면 안 된다.

#엔지니어링 실전 Tips

• 모델 교체 전에 반드시 변수를 통제해서 재현할 것. 같은 모델로 고정한 채 실패 사례를 모아, "모델이 아예 답을 못 낸다"와 "포맷이 틀렸다·중간에 표류했다·가끔 삐끗했다"를 구분하라. 후자는 전부 엔지니어링 층의 문제다.
• 스텝을 "핵심 계획"과 "단순 실행"으로 먼저 분류할 것. 전량 동일 모델을 쓰지 말고, 복잡한 추론이 필요한 스텝에만 강모델을 배정하라.
• 핵심 상태 전이 지점에는 상태머신으로 하드 제약을 걸 것. 어떤 상태에서 어떤 상태로만 갈 수 있는지 명시적으로 고정하고, 모델이 스텝을 건너뛰거나 되돌아가는 것을 허용하지 말 것.
• 매 스텝 출력에 포맷 검증과 합법성 판단을 둘 다 둘 것. 구조가 맞는 것과 값이 업무상 유효한 것은 서로 다른 검사이며 하나로 대체할 수 없다.
• 이상 분기에는 재시도와 하한 경로를 함께 준비할 것. 재시도만 있으면 지속적인 실패가 계속 재시도로 이어져 또 다른 무한루프가 되고, 하한 경로만 있으면 가용성이 너무 쉽게 깨진다.
• 작업 경계와 성공 기준을 먼저 문서로 확정할 것. 목표, 입출력 규격, 검수 기준, 처리하지 않을 시나리오를 미리 못 박지 않은 채 최적화에 들어가면 무엇을 개선해도 기준선 자체가 흔들린다.
• 모델 자체를 관측 가능한 하나의 컴포넌트로 다룰 것. 대형모델 호출 성공 여부를 헬스체크의 최상위 항목으로 두고, 장애 시 규칙 기반 경로나 보조 모델로 자동 전환되는지 주기적으로 점검할 것.