클로드 코드 effort 설정, 모델 바꾸기 전에 확인할 것

결과가 마음에 안 들면 일단 상위 모델로 바꾸고 보신 적 있으실 겁니다. 저도 리팩터링이 어중간하게 끝나면 반사적으로 모델부터 올렸어요. 그런데 다시 돌려도 비슷하게 끝나는 경우가 있습니다. 앤트로픽이 7월 초에 정리해 내놓은 설명을 보면 이때 손댈 곳은 모델이 아니라 노력 수준입니다. 클로드 코드의 effort 설정이 무엇을 조절하는지, 언제 모델을 올리고 언제 노력을 올려야 하는지 정리했습니다.

effort가 조절하는 건 무엇인가요

클로드가 답을 내놓기 전까지 하는 일의 양입니다. 얼마나 오래 생각하는지만이 아니라 파일을 몇 개나 읽는지, 테스트를 돌려 보는지, 결과를 다시 확인하는지, 여러 단계 작업을 어디까지 밀고 나간 뒤 사용자에게 돌아오는지가 함께 움직입니다.

그래서 노력을 올리면 대화가 뜸해지고 한 번에 처리되는 범위가 넓어집니다. 반대로 낮추면 자주 물어보는 대신 응답이 빨라져요. 같은 모델을 쓰면서도 작업 성격에 따라 성실도를 조절하는 손잡이라고 보면 이해가 빠릅니다.

모델을 바꿔야 할 때와 노력을 올려야 할 때

앤트로픽이 제시한 판단 기준이 명확합니다. 결과가 어긋났을 때 클로드가 몰라서 틀렸는지 덜 해서 틀렸는지를 먼저 구분하라는 겁니다.

• 필요한 맥락이 다 있었고 충분히 시도했는데도 틀렸다면 더 좋은 모델이 필요한 상황입니다.
• 파일 하나를 안 읽었거나 테스트를 안 돌렸거나 리팩터링을 하다 말았다면 노력 수준을 올릴 자리입니다.

저는 이 구분을 알기 전까지 두 번째 경우에도 모델부터 올렸습니다. 결과는 비슷한데 비용만 늘었죠. 지금은 실패 원인을 먼저 보고 손잡이를 고릅니다.

증상	원인	손댈 곳
관련 파일을 건너뛰고 수정함	확인을 덜 함	노력 상향
테스트를 안 돌리고 완료라고 함	행동을 덜 함	노력 상향
설계 자체가 틀림	판단 능력 부족	모델 상향
맥락을 줬는데도 오해함	이해 한계	모델 상향

이 구분이 유용한 이유는 대안이 서로 다르기 때문입니다. 모델 문제라면 돈을 더 쓰는 것 말고는 방법이 없지만, 노력 문제라면 지시를 구체적으로 바꾸거나 확인 절차를 넣는 것으로도 상당 부분 해결됩니다. 원인을 잘못 짚으면 해결책도 계속 빗나갑니다.

비용은 얼마나 차이 나나요

앤트로픽이 든 예시에서는 같은 프롬프트를 높은 노력으로 돌렸을 때 토큰이 약 7배까지 늘었습니다. 생각을 7배 오래 해서가 아니라 파일을 더 읽고 테스트를 더 돌리는 행동이 늘어난 결과입니다.

토큰이 실제 금액으로 얼마인지 감이 안 잡힌다면 AI 토큰 요금 계산기에 평소 사용량을 넣어 보면 기준이 잡힙니다. 그래서 모든 작업을 최대 노력으로 두는 건 낭비입니다. 오타 수정이나 문구 교체 같은 일에는 낮은 단계로 충분해요. 반대로 여러 파일에 걸친 리팩터링이나 원인이 안 잡히는 버그에는 높은 단계가 값을 합니다. 클로드 코드의 주간 한도를 신경 쓰는 상황이라면 이 조절이 곧 한도 관리이기도 합니다.

실제로 어떻게 쓰면 좋을까요

작업을 시작할 때 성격부터 분류하는 습관이 도움이 됩니다. 저는 대략 이렇게 나눕니다. 단순 수정과 문서 작업은 낮은 단계, 기능 추가처럼 파일 두세 개를 오가는 작업은 보통, 원인이 안 잡히는 버그와 구조 변경은 높은 단계로 두고 시작해요.

한 가지 더 유용한 건 도중에 바꾸는 것입니다. 낮은 단계로 시작해 상황 파악만 시키고, 고칠 지점이 정해지면 그때 올려서 밀어붙이는 방식이 토큰을 아낍니다. 처음부터 최대로 두면 탐색 단계에서 이미 많이 써 버리거든요.

검증 습관도 같이 가져가야 합니다. 노력을 올리면 클로드가 중간에 덜 물어보기 때문에 한 번에 바뀌는 범위가 커집니다. 커밋을 잘게 나누고 변경 내역을 눈으로 확인하는 절차가 없으면 되돌리기가 번거로워져요.

팀으로 쓴다면 기준을 맞춰 두는 것도 방법입니다. 어떤 작업에 어떤 단계를 쓰는지 사람마다 다르면 리뷰에 올라오는 변경 크기가 들쭉날쭉해집니다. 저장소 문서에 한 줄로 적어 두면 신규 합류자도 헤매지 않아요. 예를 들어 버그 수정은 보통, 마이그레이션은 높음처럼 작업 종류에 매칭해 두는 식입니다.

노력 설정을 켠 뒤에는 실패한 작업을 기록해 두면 판단이 정교해집니다. 무엇을 시켰고 어떤 단계였고 왜 어긋났는지 세 줄만 남겨도, 다음에 비슷한 작업에서 모델과 노력 중 무엇을 올릴지 훨씬 빨리 결정할 수 있습니다.

정리하면

모델과 노력은 서로 다른 문제를 푸는 손잡이입니다. 아는 게 부족한 상황과 성실함이 부족한 상황을 섞어서 다루면 비용만 늘고 결과는 그대로입니다. 토큰 단가가 내려가도 실제 청구액은 늘어나던 사례와 같은 이치로, 실제 지출을 좌우하는 건 단가보다 얼마나 많은 일을 시켰는지입니다.

개인적으로는 이 설정이 생기고 나서 상위 모델을 덜 쓰게 됐습니다. 대부분의 실패가 능력 부족이 아니라 확인 부족이었더라고요.