AI 에이전트는 왜 모델보다 effort를 먼저 봐야 하는가

Lead: AI 에이전트를 고를 때 우리는 너무 자주 모델 이름부터 본다. 하지만 실제 성능을 가르는 건 종종 모델 자체가 아니라, 그 모델이 얼마나 깊게 읽고, 얼마나 많이 검증하고, 얼마나 멀리 밀고 나가도록 허용됐는지다. 같은 모델이어도 effort가 다르면 완전히 다른 제품이 된다.

TL;DR

모델은 잠재력이고, effort는 실제 작업 예산이다.
effort는 생각 시간만 뜻하지 않는다. 파일을 더 읽고, 더 검증하고, 더 끝까지 밀어붙이는 범위까지 포함한다.
좋은 AI 운영자는 모든 작업에 최강 모델을 붙이지 않는다. 작업 난이도와 위험도에 따라 모델과 effort를 같이 배분한다.
작은 AI 유틸이나 에이전트 제품도 이 원리를 그대로 쓸 수 있다. 핵심은 더 큰 모델이 아니라 더 정확한 라우팅이다.

왜 지금 중요한가

AI 제품은 빠르게 상향 평준화되고 있다. 비슷한 프롬프트, 비슷한 모델, 비슷한 자동화 문구가 피드에 넘친다. 그런데 사용자는 점점 더 똑똑해진다. 이제는 “어느 모델이냐”보다 다음 질문을 먼저 던진다.

이 에이전트는 얼마나 깊게 파고드나?
중간에 얼마나 검증하나?
실패했을 때 스스로 얼마나 더 해보나?
어디서 멈추고 사람에게 넘기나?

이번 inbox에서 들어온 신호도 같은 방향을 가리킨다.

Claude Code 관련 메모는 model과 effort가 전혀 다른 레버라고 말한다.
Fable 5 프롬프트 가이드는 장기 실행과 업데이트된 스캐폴딩 패턴을 강조한다.
루프 엔지니어링 영상은 반복보다 목표, 검증, 종료 조건을 더 중요하게 본다.

이 셋을 합치면 결론은 분명하다. 에이전트 성능은 모델 랭킹이 아니라 작업 예산 설계에서 나온다.

핵심 흐름

좋은 에이전트는 아래 순서로 이해하면 쉽다.

flowchart LR
    A[Task] --> B[Choose model]
    B --> C[Set effort budget]
    C --> D[Read / Act / Verify]
    D --> E[Stop or Escalate]

여기서 핵심은 모델과 effort가 같은 것이 아니라는 점이다.

1) 모델은 “얼마나 똑똑할 수 있는가”를 정한다

모델은 기본 능력치를 정한다. 복잡한 추론, 코드 이해, 긴 문맥 처리, 도구 사용 안정성 같은 상한이 다르다. 그래서 모델 선택이 의미 없다는 말은 틀렸다.

하지만 모델만으로는 충분하지 않다. 같은 모델이라도 다음이 달라지면 결과가 달라진다.

읽는 파일 수
검증 횟수
재시도 범위
중간 체크인 시점
끝까지 밀어붙이는 정도

즉, 모델은 가능성이고 effort는 실행량이다.

2) effort는 “얼마나 많은 일을 시킬 것인가”를 정한다

Claude Code 관련 메모에서 중요한 포인트는 effort가 단순한 “생각 시간”이 아니라는 점이다. effort는 대체로 이런 것들을 함께 바꾼다.

얼마나 오래 생각하는가
얼마나 많은 파일을 읽는가
얼마나 자주 검증하는가
얼마나 복잡한 step을 스스로 넘는가
언제 사람에게 물어보는가

이건 제품 관점에서 아주 중요하다. 같은 모델을 써도 effort가 낮으면 금방 질문을 던지고, effort가 높으면 더 많이 시도하고 더 많이 확인한다.

3) effort가 높은 작업은 결국 “완료 계약”이 필요하다

루프 엔지니어링이 흥미로운 이유도 여기에 있다. 반복을 많이 돌리는 게 핵심이 아니라, 무엇이 완료인지, 어디서 멈출지, 실패하면 어디로 돌아갈지를 정하는 것이 핵심이다.

그래서 좋은 effort 설계는 보통 아래 5개를 포함한다.

목표
검증 기준
중간 상태 기록
사람 개입 지점
재시도 한계

이게 없으면 effort는 낭비가 된다. 반대로 이게 있으면 effort는 에이전트를 앞으로 밀어주는 힘이 된다.

실제 사례 / 원문에서 본 신호

Claude Code 메모가 보여준 것

핵심은 명확하다. model이 더 낫다고 effort를 무시하면 안 된다. 더 좋은 모델이 더 많은 일을 잘할 수는 있지만, 실제 제품에서는 “얼마나 많은 일을 시킬지”가 따로 필요하다.

이건 코딩 에이전트뿐 아니라 문서 요약, 리서치, 운영 자동화에도 그대로 적용된다.

Fable 5 프롬프트 가이드가 보여준 것

장기 실행 작업일수록 스캐폴딩이 중요해진다. 한 번에 답을 내는 프롬프트보다, 중간 점검과 업데이트를 고려한 구조가 더 강하다.

즉, 고급 모델이 중요한 게 아니라 길게 달리도록 설계된 harness가 중요하다.

루프 엔지니어링 영상이 보여준 것

반복은 곧 자동화가 아니다. 반복이 제품이 되려면 검증이 있어야 한다.

무엇을 반복할지
얼마나 자주 반복할지
어떤 결과를 성공으로 볼지
언제 멈출지

이 질문이 없으면 반복은 그냥 비용이다. effort를 높이는 일도 마찬가지다. 검증 없이 effort만 올리면 토큰만 더 쓰고 끝난다.

실전 활용 팁: [독자 행동]

AI 유틸이나 에이전트 제품을 만드는 팀이라면, 모델 선택표보다 먼저 effort 정책표를 만들어야 한다.

1) 작업을 위험도별로 나눠라

저위험: 요약, 초안, 가벼운 검색
중위험: 코드 수정, 문서 정리, 구조 변경
고위험: 배포, 결제, 권한, 데이터 이동

고위험일수록 모델보다 effort와 검증을 먼저 올려야 한다.

2) low-effort 기본값을 무조건 두지 마라

기본값이 너무 낮으면 에이전트는 자주 멈춘다. 사용자는 그걸 “빠르다”고 느끼지 않고 “덜 해준다”고 느낀다.

좋은 기본값은 다음 중 하나다.

빠른 초안 + 강한 검증
중간 effort + 명시적 체크포인트
고위험 작업만 높은 effort

3) effort를 “더 오래 생각하기”로만 정의하지 마라

진짜 차이는 읽기와 검증에 있다.

필요한 파일을 더 읽는가
불확실하면 더 확인하는가
중간 결과를 비교하는가
실패해도 한 번 더 밀어붙이는가

이것이 실제 품질을 만든다.

4) 모델과 effort를 분리해서 기록하라

작업 로그에는 최소한 이 항목이 있어야 한다.

선택한 모델
effort 수준
읽은 파일 수
검증 단계
재시도 횟수
최종 종료 사유

이 기록이 쌓이면 다음부터는 더 싸게, 더 빨리, 더 정확하게 돌릴 수 있다.

5) 사용자에게는 모델보다 결과 경로를 보여줘라

사용자는 모델 이름보다 다음을 더 잘 믿는다.

무엇을 읽었는가
무엇을 확인했는가
어디서 멈췄는가
실패하면 어떻게 되는가

AI 제품의 신뢰는 결국 설명 가능한 경로에서 나온다.

바로 해볼 실험

오늘 만드는 AI 기능 하나만 골라서 같은 작업을 세 가지로 돌려보면 된다.

낮은 effort + 현재 모델
높은 effort + 현재 모델
더 강한 모델 + 보통 effort

그리고 아래를 비교한다.

읽은 컨텍스트의 깊이
수정 횟수
검증 횟수
최종 품질
사람 개입 횟수

이 실험의 목적은 “무슨 모델이 더 똑똑한가”를 가리는 게 아니다. 어떤 조합이 실제로 끝까지 일을 마치는가를 보는 것이다.

리스크 / 반론

물론 effort를 올리는 게 항상 답은 아니다.

너무 높이면 비용이 커진다.
너무 낮으면 검증이 부족하다.
사용자가 knob를 너무 많이 보면 오히려 복잡해진다.
모든 작업에 고정 effort를 주면 라우팅 이점이 사라진다.

그래서 정답은 단순하다. 모델은 능력치를, effort는 작업량을, 검증은 종료 조건을 담당하게 분리하는 것이다.

결론

AI 에이전트의 핵심 질문은 이제 “어느 모델이 최고인가”가 아니다.

이 작업에 어떤 모델을 붙이고, 얼마나 깊게 읽히고, 얼마나 많이 검증하게 하고, 어디서 멈추게 할 것인가?

그 질문에 답할 수 있는 팀이 에이전트를 제품으로 바꾼다. 답할 수 없는 팀은 계속 모델 뉴스만 따라가게 된다.

AI 서비스나 작은 유틸을 만든다면, 다음부터는 모델 이름보다 effort 정책부터 적어라. 그게 실제 운영을 바꾸는 첫 버튼이다.