AI 코딩 도구가 틀렸을 때 보는 모델·Effort 선택 가이드

AI 코딩 도구를 쓰다 보면 이런 순간이 옵니다.

분명히 버그를 고쳐달라고 했는데 관련 파일을 제대로 안 봅니다.
수정했다고 말했는데 테스트는 돌리지 않았습니다.
작은 변경인데 너무 비싼 모델을 쓰는 것 같기도 합니다.
반대로 싼 모델로 오래 붙잡고 있다가 작업이 더 꼬이기도 합니다.

이럴 때 우리는 보통 이렇게 생각합니다.

"더 좋은 모델을 써야 하나?"

그런데 항상 모델 문제가 아닙니다.

Claude가 최근 공개한 글 Choosing a Claude model and effort level in Claude Code는 이 문제를 꽤 실용적으로 설명합니다. 핵심은 단순합니다.

모델은 능력의 문제이고, effort는 작업 태도의 문제에 가깝습니다.

먼저 결론: 모델은 실력, Effort는 성실함

Claude Code에는 결과에 큰 영향을 주는 두 가지 선택지가 있습니다.

• 어떤 Claude 모델을 쓸 것인가
• effort level을 얼마나 높게 둘 것인가

둘 다 결과를 좋게 만들 수 있습니다. 하지만 역할은 다릅니다.

모델 선택은 "누구에게 일을 맡길 것인가"에 가깝습니다. 더 좋은 모델은 더 어려운 문제를 이해하고, 더 넓은 패턴을 떠올리고, 애매한 상황에서 더 나은 판단을 할 가능성이 높습니다.

Effort level은 "그 사람이 얼마나 꼼꼼히 일하게 할 것인가"에 가깝습니다. effort가 높으면 Claude는 더 많은 파일을 읽고, 더 많이 확인하고, 테스트를 돌리고, 여러 단계를 거쳐 작업을 끝내려는 경향이 강해집니다.

그래서 AI 코딩 도구가 틀렸을 때는 먼저 이 질문을 해야 합니다.

이건 몰라서 틀린 걸까?
아니면 충분히 안 해봐서 틀린 걸까?

모델을 바꿔야 하는 경우: 몰라서 틀린 것

먼저 모델을 올려야 하는 상황부터 보겠습니다.

Claude가 충분한 문맥을 받았습니다. 관련 파일도 읽었습니다. 테스트 결과도 봤습니다. 그런데도 계속 그럴듯하지만 틀린 답을 냅니다.

이럴 때는 effort를 더 올리는 것보다 더 좋은 모델을 쓰는 편이 낫습니다.

대표적인 상황은 이렇습니다.

• 낯선 도메인의 코드를 이해해야 할 때
• 복잡한 상태 관리나 비동기 흐름을 추적해야 할 때
• 여러 파일의 책임을 나누는 설계 판단이 필요할 때
• 단순 문법 문제가 아니라 구조적인 버그를 찾아야 할 때
• 작은 모델이 계속 자신 있게 틀린 설명을 할 때

예를 들어 결제 로직에서 특정 조건일 때만 쿠폰이 잘못 적용되는 문제가 있다고 해봅시다. 이 문제는 단순히 한 파일을 읽는다고 풀리지 않을 수 있습니다. 정책, 예외 조건, 데이터 흐름, 테스트 케이스를 함께 봐야 합니다.

이런 문제는 "더 오래 생각해"보다 "더 잘 이해하는 모델"이 필요할 가능성이 큽니다.

원문에서는 모델의 지식과 능력이 학습된 가중치에 들어 있다고 설명합니다. 프롬프트와 파일 문맥은 모델을 잘 유도할 수 있지만, 모델 자체의 능력을 바꾸지는 않습니다.

즉, 모델이 어떤 API를 계속 잘못 기억하거나, 구조적인 판단을 계속 놓친다면 같은 모델에서 effort만 높인다고 해결되지 않을 수 있습니다.

지금 당장 이렇게 하세요

Claude가 충분히 읽고 시도했는데도 틀렸다면 모델을 올리세요.

반대로 아직 관련 파일도 덜 읽었고, 테스트도 안 돌렸고, 한 가지 가설만 봤다면 모델을 올리기 전에 effort나 작업 지시를 먼저 조정하는 게 좋습니다.

Effort를 올려야 하는 경우: 안 해봐서 틀린 것

이번에는 effort 문제입니다.

Claude가 틀렸는데, 답변을 보면 이런 느낌이 듭니다.

• 관련 파일을 하나만 보고 결론을 냈다
• 테스트를 돌리지 않았다
• 타입 체크를 하지 않았다
• 에러 메시지를 끝까지 읽지 않았다
• 리팩토링을 하다가 일부만 고쳤다
• "아마 될 겁니다"처럼 확인 없이 마무리했다

이 경우는 모델이 몰라서 틀렸다기보다 충분히 작업하지 않아서 틀린 것에 가깝습니다.

Effort level은 단순히 "생각 시간"만 뜻하지 않습니다. 원문에 따르면 effort는 Claude가 한 요청에서 얼마나 많은 작업을 할지에 영향을 줍니다.

• 얼마나 많은 파일을 읽을지
• 얼마나 많이 검증할지
• 몇 단계까지 진행한 뒤 사용자에게 돌아올지
• 테스트나 확인 작업을 얼마나 적극적으로 할지

이 차이는 실무에서 꽤 큽니다.

예를 들어 "이 버그 고쳐줘"라고만 하면 Claude는 가장 눈에 띄는 파일 하나를 보고 바로 수정할 수 있습니다. 하지만 실제 버그는 다른 파일의 데이터 흐름에서 시작됐을 수도 있습니다.

이때 필요한 것은 더 천재적인 모델이 아니라, 더 꼼꼼한 작업 방식일 수 있습니다.

지금 당장 이렇게 하세요

Claude가 파일을 덜 읽거나 검증을 안 해서 틀렸다면 effort를 올리거나, 프롬프트에 검증 조건을 넣으세요.

관련 파일을 먼저 확인하고, 수정 후 테스트까지 실행해줘.
테스트가 실패하면 원인을 다시 분석하고 한 번 더 수정해줘.

또는 리팩토링이라면 이렇게 요청할 수 있습니다.

먼저 변경 계획을 세워줘.
동작은 바꾸지 말고 구조만 정리해줘.
수정 후 타입 체크와 기존 테스트를 실행해서 확인해줘.

핵심은 "고쳐줘"가 아니라 어디까지 확인해야 하는지를 알려주는 것입니다.

Effort는 어느 정도로 써야 할까?

Claude Platform 문서 기준으로 effort는 low, medium, high, xhigh, max처럼 단계로 나뉩니다. 사용하는 환경에 따라 보이는 이름은 조금 다를 수 있지만, 생각하는 방식은 비슷합니다.

중요한 점은 처음부터 항상 max로 시작할 필요는 없다는 것입니다. 대부분은 high, 즉 기본값에서 시작하고, 단순 작업은 낮추고, 긴 코딩 작업은 xhigh로 올리는 식이 현실적입니다.

프롬프트를 고칠 때와 Effort를 올릴 때

결과가 별로일 때 무조건 effort를 올릴 필요는 없습니다.

요청이 애매했다면 먼저 프롬프트를 고쳐야 합니다.

예를 들어 "잘 정리해줘", "깔끔하게 고쳐줘", "전체적으로 개선해줘" 같은 요청은 기준이 흐립니다. 이때는 effort를 올리기보다 결과물의 개수, 적용 범위, 검증 기준을 더 명확히 주는 것이 먼저입니다.

반대로 요청은 명확했는데 Claude가 관련 파일을 덜 읽거나 테스트를 안 돌렸다면 effort를 올리는 쪽이 맞습니다.

정리하면 이렇게 볼 수 있습니다.

비용 관점: 항상 큰 모델이 비싼 건 아니다

AI 모델을 고를 때 비용도 중요합니다.

일반적으로 큰 모델은 토큰당 비용이 더 비쌉니다. 그래서 단순 작업에 항상 큰 모델을 쓰면 낭비가 될 수 있습니다.

예를 들어 버튼 문구를 바꾸거나, 타입 이름을 수정하거나, 반복되는 import를 정리하는 작업이라면 작은 모델과 기본 effort로도 충분합니다.

하지만 어려운 작업에서는 이야기가 달라집니다.

작은 모델이 문제를 제대로 이해하지 못하면 여러 번 시도하고, 잘못 고치고, 다시 되돌리고, 더 많은 토큰을 쓰게 됩니다. 반면 더 좋은 모델은 처음부터 문제의 구조를 더 잘 잡아서 전체 작업 비용이 오히려 낮아질 수 있습니다.

정리하면 이렇습니다.

비용을 줄이는 가장 좋은 방법은 무조건 싼 모델을 쓰는 게 아닙니다. 작업 난이도에 맞는 모델과 effort를 고르는 것입니다.

그래서 나는 지금 당장 뭘 하면 되나?

이 글에서 가장 중요한 부분입니다.

다음에 Claude Code나 다른 AI 코딩 도구를 쓸 때는 아래 기준으로 시작해보세요.

1. 작업이 단순한지 복잡한지 먼저 나누기

문구 변경, 작은 스타일 수정, 단순 타입 수정처럼 결과가 명확한 작업은 작은 모델이나 기본 모델로 충분합니다.

반대로 버그 원인이 애매하거나, 여러 파일을 함께 봐야 하거나, 설계 판단이 필요하면 좋은 모델을 쓰는 편이 낫습니다.

2. 검증이 필요한 작업인지 확인하기

버그 수정, 리팩토링, 의존성 변경, API 변경은 검증이 필요합니다.

이런 작업에서는 처음부터 "수정 후 테스트 실행", "타입 체크 실행", "실패하면 다시 분석" 같은 조건을 넣어주세요.

3. 결과가 틀렸을 때 실패 원인 구분하기

AI가 틀렸다면 바로 모델을 바꾸지 말고 먼저 원인을 봅니다.

파일을 덜 읽었거나 테스트를 안 했다면 effort 문제일 수 있습니다.

충분히 읽고 확인했는데도 판단 자체가 틀렸다면 모델 문제일 가능성이 큽니다.

4. 다음 요청에서 조정하기

안 해봐서 틀린 경우에는 effort를 올리거나 검증 지시를 추가합니다.

몰라서 틀린 경우에는 더 좋은 모델로 바꿉니다.

실무에서는 이렇게 맡기세요

AI 코딩 도구에 일을 맡길 때 가장 흔한 실수는 바로 구현부터 시키는 것입니다.

작은 수정은 괜찮습니다. 하지만 버그 수정, 리팩토링, 설계 변경처럼 영향 범위가 있는 작업은 바로 고치라고 하면 결과가 흔들릴 수 있습니다.

저는 실무 작업에서는 아래 흐름을 추천합니다.

1. 먼저 읽게 하기

바로 수정하지 말고 관련 파일과 흐름을 먼저 파악하게 합니다.

관련 코드를 먼저 읽고 현재 구조와 데이터 흐름을 요약해줘.
아직 파일은 수정하지 마.

2. 원인 또는 선택지 좁히기

버그라면 가능한 원인을 좁히고, 기능 구현이라면 접근 방식을 비교하게 합니다.

가능한 원인을 가능성이 높은 순서로 3개만 정리해줘.
각 원인을 확인하려면 어떤 파일이나 테스트를 봐야 하는지도 알려줘.

3. 변경 범위 제한하기

AI가 관련 없는 리팩토링까지 벌이지 않도록 범위를 정합니다.

가장 가능성이 높은 원인만 먼저 수정해줘.
기존 구조를 최대한 유지하고, 관련 없는 리팩토링은 하지 마.

4. 검증 결과 받기

마지막에는 무엇을 확인했고, 무엇을 확인하지 못했는지 나눠서 받습니다.

수정 후 가능한 검증을 실행해줘.
통과한 항목과 확인하지 못한 항목을 나눠서 알려줘.

이 흐름을 쓰면 AI가 "그럴듯한 수정"에서 끝나는 일이 줄어듭니다. 특히 3단계와 4단계가 중요합니다. 실무에서는 정답을 내는 것만큼, 변경 범위를 통제하고 검증 결과를 남기는 것이 중요하기 때문입니다.

실패했을 때 다시 요청하는 법

AI가 한 번에 잘못 고쳤을 때도 바로 처음부터 다시 시작할 필요는 없습니다.

실패 원인을 보고 다음 요청을 다르게 주면 됩니다.

이때 좋은 재요청은 이런 식입니다.

방금 수정은 원하는 결과가 아니야.

다시 진행하기 전에 먼저 정리해줘.
1. 네가 확인한 사실
2. 아직 추측인 부분
3. 이전 접근이 실패했을 가능성
4. 다음에 시도할 접근 2가지

아직 코드는 수정하지 마.

이 프롬프트는 꽤 유용합니다. AI가 틀렸을 때 바로 다시 고치게 하면 같은 방향으로 한 번 더 틀릴 수 있습니다. 먼저 실패를 분석하게 하면 다음 시도가 훨씬 안정됩니다.

상황별로 바로 쓰는 프롬프트

아래 문장들은 그대로 복사해서 써도 됩니다.

단순 수정

이 컴포넌트의 버튼 문구만 바꿔줘.
관련 없는 리팩토링은 하지 말고, 변경 파일을 최소화해줘.

이런 작업은 큰 모델이 꼭 필요하지 않습니다. 범위를 좁혀주는 게 더 중요합니다.

버그 수정

이 버그의 원인을 먼저 찾아줘.
관련 파일을 확인하고, 가능한 원인을 2~3개로 좁힌 뒤 수정해줘.
수정 후 테스트나 타입 체크를 실행해서 확인해줘.

버그 수정에서는 "바로 고쳐줘"보다 "원인을 먼저 찾아줘"가 좋습니다. 그래야 AI가 한 파일만 보고 성급하게 수정할 가능성이 줄어듭니다.

리팩토링

먼저 리팩토링 계획을 제안해줘.
동작은 바꾸지 말고, 책임 분리와 중복 제거만 해줘.
수정 후 기존 테스트를 실행하고, 실패하면 원인을 분석해줘.

리팩토링은 effort가 중요한 작업입니다. 코드를 많이 바꾸기 때문에, 마지막 검증까지 포함해야 합니다.

설계 판단

이 기능을 구현하는 방법을 2~3가지로 비교해줘.
각 방식의 장단점, 유지보수성, 확장성을 기준으로 추천안을 골라줘.
아직 코드는 수정하지 마.

설계 작업에서는 바로 구현시키지 않는 게 좋습니다. 먼저 선택지를 비교하게 하고, 그다음 구현으로 넘어가세요.

마무리: 좋은 AI 사용자는 모델보다 실패 원인을 먼저 본다

AI 코딩 도구를 잘 쓰는 사람은 무조건 가장 비싼 모델을 고르지 않습니다.

대신 결과가 별로였을 때 이렇게 묻습니다.

이건 모델이 몰라서 틀린 걸까?
아니면 충분히 안 읽고, 안 돌려보고, 안 확인해서 틀린 걸까?

이 질문 하나만 해도 사용 방식이 달라집니다.

몰라서 틀렸다면 더 좋은 모델을 쓰세요.
안 해봐서 틀렸다면 effort를 올리거나 검증 지시를 넣으세요.
작업이 단순하다면 작은 모델과 기본 effort로 빠르게 처리하세요.

자주 묻는 질문