심야, 단순한 typo 수정이 Opus의 xhigh로 실행되고 있었다

리뷰 대기 중인 PR이 좀처럼 끝나지 않는다. 로그를 살펴보니, 단순한 typo 수정을 위해 던졌을 서브 에이전트(sub-agent)가 태연하게 Opus의 xhigh를 사용하고 있었다.

• 내용은 몇 줄의 JSON 정렬이나 가벼운 문자열 치환뿐
• 그런데도 실행 시간과 비용은 무거운 판단 작업과 동일한 수준
• 게다가 나는 「effort 같은 건 지정하지 않았다」고 생각하고 있었다

원인은 단순했다. effort를 지정하는 것을 잊은 서브 에이전트는 알아서 가벼워져 주지 않는다.

「지정하지 않음」은 「가벼워짐」이 아니라 「상속」이다

Claude Code에서 서브 에이전트를 호출할 때, model과 effort를 생략해도 겉보기에는 작동한다. 에러도 발생하지 않는다. 그래서 생략하기 쉽다.

문제는 생략했을 때의 동작이다.

// Bad: 아무것도 지정하지 않음 → 부모 세션의 opus/xhigh를 그대로 상속함
{ "subagent_type": "general-purpose", "prompt": "이 JSON을 키 순서대로 정렬해줘" }
// Good: 가볍고 기계적인 작업임을 알고 있다면 명시함
...

부모 세션이 opus의 xhigh로 동작하고 있을 때, 포맷 변환과 같은 가벼운 처리를 「일단 던지면」, 서브 에이전트도 그대로 opus의 xhigh로 동작한다. 손톱깎이를 부탁했더니 전기톱을 건네받는 격이지만, 건네받은 쪽은 성실하게 전기톱으로 손톱을 깎으러 간다.

왜 이렇게 쓰는가

「생략하면 적당한 중간값이 되겠지」라고 처음에는 생각했다. 실제로는 반대로, 상속 대상은 안전한 쪽(가벼운 쪽)이 아니라 호출 측의 무게가 된다.

그래서 우리 팀의 오케스트레이션(orchestration) 운영에서는 「가볍고 기계적인 작업은 haiku+low, 무거운 판단만 opus+상위 effort」라는 원칙을, 단순히 선언하는 것에 그치지 않고 호출 측의 수고로써 운영에 포함시키고 있다. 원칙을 외치기만 해서는 상속 동작을 모르면 실천되지 않는다.

실전에서 깨달은 점: 명시했다고 생각한 typo도 놓칠 수 없다

명시하는 운영으로 전환해도, 다음에 겪는 것은 typo다. hihg라고 치든 xtrahigh라고 치든, 육안 리뷰로는 의외로 눈치채지 못한다. 인간의 눈은 「대충 맞는 문자열」을 알아서 보완해서 읽어버리는, 쓸데없이 우수한 기능을 가지고 있다.

이를 인간의 주의력에 의존하지 않고 기계적으로 걸러내기 위해, skill이나 agent의 frontmatter를 작성하기 직전에 검증하는 훅(hook)을 사용하고 있다. 내용은 심플한 폐쇄형 enum 체크다.

#!/usr/bin/env bash
# validate-effort.sh: 인자로 받은 effort 값을 폐쇄형 enum으로 검증한다
echo "$1" | grep -qE '^(low|medium|high|xhigh|max)$' && echo "OK: $1" || { echo "NG: '$1' is not a valid effort tier"; exit 1; }

bash validate-effort.sh xhigh # OK: xhigh
bash validate-effort.sh super-high # NG: 'super-high' is not a valid effort tier

상속 이야기는 「명시하지 않으면 무거워지는」 문제이고, 이쪽은 「명시했다고 생각한 것이 typo로 인해 무효화되는」 문제다. 둘 다 운영의 긴장이 풀리는 순간에 발생하므로, 어느 한쪽만 대처해서는 빈틈이 남는다.

요약: 나는 이렇게 사용하고 있다

effort는 「지능과 맞바꿔 비용과 시간을 사용하는 다이얼」이라는 심플한 설계지만, 서브 에이전트에게 위임하는 구성에서는 이야기가 한 단계 복잡해진다. 지정하지 않으면 가벼워지는 것이 아니라, 호출 측의 무게를 그대로 이어받는다. 그래서 나는 호출하는 측에서 매번 명시하는 운영과, 작성한 값이 망가지지 않았는지 기계적으로 확인하는 계층 양쪽을 세트로 준비하기로 했다. 한쪽만으로는 언젠가 똑같은 심야에 다시 똑같은 로그를 보게 될 것이다.

원문 기사

이 기사는 Claude Code의 effort 설정, 서브 에이전트(sub-agent)에게 맡기면 비용이 많이 드는 이유의 핵심 부분을 재구성한 것입니다. 원문 기사에서는 다음과 같은 내용을 추가로 다루고 있습니다:

effortLevel의 기본값을 실제로 높이거나 낮추기로 결정한 판단 근거, 그리고 포맷 변경에 의미 변경을 섞어서 실패했던 반성 - Codex CLI 등 다른 에이전트형 코딩 도구(agentic coding tools)와의 설정 명칭 대응표

• "높이면 안전하다"라는 주장에 대한 반증과 실무에서 사용할 수 있는 체크리스트

Discussion