AI에게 일의 힘을 조절해 쓰는 법

2026.10.03 · 작성: moonlang

AI의 effort는 한 작업에 얼마나 많은 생각과 검증을 들일지 조절하는 설정입니다. 모든 업무를 가장 높은 단계로 처리하기보다 초안·일상 업무·중요한 검증을 나누면 속도와 품질을 함께 관리할 수 있습니다.

설정 단계와 사용표를 왜 구분하나요?

비용 글 “What a task costs on Opus 5.5” 기준으로 Opus 5.5의 effort는 low, medium, high, xhigh 네 단계이고, 한 세션에서만 쓰는 max가 따로 있습니다. Opus 5.5의 기본값은 medium입니다. 모델마다 단계의 의미가 다를 수 있습니다. 글쓴이 Thariq의 사용 기준표는 low, medium, high, max 네 가지입니다. 설정 단계와 업무 기준표를 같은 것으로 읽지 않는 것이 좋습니다.

원문이 제안한 루틴은 다음과 같습니다. “AI가 나를 인터뷰해 스펙을 만들게 하고 → low로 구현 → 리뷰(필요하면 low로 반복) → high로 검증·테스트”. 먼저 무엇을 만들지 정리하고, 구현은 빠르게 진행한 뒤, 사람이 결과를 읽고 마지막 검증에 더 많은 생각을 배정하는 흐름입니다.

높은 effort는 빠져나갈 구멍이나 숨은 예외를 찾는 데 도움이 됩니다. 다만 접근 자체가 틀렸다면 생각을 더 오래 시켜도 올바른 방향으로 바뀌지 않습니다. 원문의 64%에서 87%로 오른 결과는 일반 업무 평균이 아니라 Fable 5.1의 Terminal-Bench 3.0 보안 범주에서 낮은 effort에서 최상위 effort로 올렸을 때의 내부 실행 결과입니다(원문 그림은 낮은 쪽은 가장 낮은 두 설정, 높은 쪽은 가장 높은 세 설정을 묶은 값으로 보여줍니다).

학원 업무에는 어떤 단계를 배정할까요?

상담 문의 초안은 low로 시작할 수 있습니다. 정해진 형식의 일상 안내문은 medium, 성적이나 학부모 안내처럼 사실과 표현을 함께 점검해야 하는 문서는 high로 검증합니다. 커리큘럼 설계처럼 여러 조건을 비교하고 오래 검토해야 하는 일은 max로 검토하되, 먼저 목표와 제약을 분명히 적어야 합니다. medium에서 막히면 high로 올리고, 처음부터 어려운 문제에는 xhigh를 검토할 수 있습니다. 다만 비용 글은 xhigh와 max를 효과를 확인한 일에 남겨 두라고 하고, xhigh에서도 같은 문제에 두 번 막히면 단계를 더 올리기보다 모델을 바꾸라고 권합니다.

이렇게 나누면 “항상 깊게”라는 막연한 지시 대신 업무 단계별 예산이 생깁니다. 낮은 단계에서 만든 초안도 검토 대상이고, 높은 단계는 잘못된 목표를 고치는 만능 버튼이 아니라 검증을 강화하는 도구라는 점을 기억해야 합니다.

학원 업무의 effort를 정하는 순서

• 업무를 초안·일상 처리·중요 검증·어려운 설계로 나누고 기본 effort를 정합니다.
• 상담 문의 초안은 low, 일상 안내문은 medium에서 먼저 시작합니다.
• 성적·학부모 안내는 high에서 사실·대상·예외를 다시 확인하게 합니다.
• 커리큘럼 설계는 max 검토 전에 목표, 제약, 완료 조건을 문장으로 적습니다.
• 낮은 단계의 결과를 사람이 리뷰하고, 필요한 경우 같은 단계로 반복합니다.
• 단계별 결과의 품질과 소요 시간을 기록해 다음 배정 기준을 조정합니다.

자주 묻는 질문

모든 일을 max로 처리하면 가장 좋지 않나요?

그렇지 않습니다. 더 오래 생각해도 입력된 목표나 접근이 틀렸다면 결과가 좋아지지 않으며, 속도와 비용은 커질 수 있습니다.

effort를 올리면 잘못된 접근도 고쳐지나요?

effort는 검토와 생각의 양을 늘리는 설정이지 문제 정의를 자동으로 다시 쓰는 장치가 아닙니다. 결과가 계속 빗나가면 먼저 요구사항과 완료 조건을 다시 정리해야 합니다.

작업 중간에 effort를 바꿀 수 있나요?

Claude Code에서는 대화 중에도 /effort high처럼 effort를 바꿀 수 있습니다. 비용 글 기준으로 API 키나 구독으로 쓰면 바꿔도 프롬프트 캐시가 유지됩니다. 클라우드 제공업체나 게이트웨이를 거친다면 작업이 끊기는 시점에 바꾸는 편이 낫습니다.

리뷰 후에도 같은 effort를 쓰는 이유는 무엇인가요?

리뷰에서 고칠 지점이 구현의 세부 문제라면 낮은 단계로 반복해도 충분할 수 있습니다. 마지막에 전체 요구사항과 예외를 확인할 때 높은 단계로 올리는 것이 원문이 제안한 흐름입니다.

출처

• Using Claude Code: Spending your effort — Thariq Shihipar (claude.dev, 2026-09-25) — https://claude.dev/blog/spending-your-effort/
• What a task costs on Opus 5.5 — Addy Osmani (claude.dev, 2026-09-25) — https://claude.dev/blog/what-a-task-costs-on-opus-5-5/

이 글은 claude.dev 원문을 학원 운영 관점에서 요약·해설한 글이며 번역이 아닙니다.