Effort

모듈 축소와 추론 강도 조절을 통해 낭비되는 토큰을 줄이고 효율을 높이는 구조

Effort는 한 작업에 모델의 추론을 얼마나 할당할지 정하는 설정이다. 기본값에서 시작하고, 작업의 난도와 필요한 확인 수준을 보고 올린다.

기준일: 2026-09-30

작업에 맞춰 강도 정하기

가벼운 수정이나 범위가 뚜렷한 작업은 낮은 단계로도 충분하다. 일상적인 구현은 중간 단계에서 시작하고, 복잡한 디버깅이나 엣지 케이스 검토에는 높은 단계를 고려한다. 오래 걸리는 설계나 어려운 문제에는 가장 높은 단계를 쓸 수 있지만, 항상 결과가 좋아지는 것은 아니다.

경험에서 얻은 대략적인 출발점은 다음과 같다.

모델 유형	시작 범위	적용 예
프론티어 모델	medium~high	기능 구현은 medium, 원인 찾기와 예외 검토는 high
가성비 프론티어·오픈웨이트	high~max	답이 불안정한 복잡한 작업에서 한 단계씩 올림

이 표는 경험에서 나온 휴리스틱이다. 모델이나 작업마다 적정 단계가 다르므로 고정 규칙으로 삼지 않는다. 설정을 바꾼 뒤에는 성공률, 필요한 수정 횟수, 응답 시간과 사용량을 함께 살핀다. FrontierCode 같은 지표를 참고하거나, 작고 비교 가능한 작업으로 직접 확인할 수 있다.

필요한 만큼만 올리기

먼저 기본값으로 작업을 시작하고, 결과가 자주 빠뜨리는 부분을 구체적으로 확인한다. 테스트가 놓치는 경계 조건이 반복되거나 복잡한 원인을 충분히 좁히지 못할 때만 단계를 올린다. 반대로 출력이 길어지고 작업 시간이 늘었는데 결과가 달라지지 않으면 기본값으로 되돌린다.

작업의 크기보다 불확실성을 기준으로 삼으면 조절하기 쉽다. 파일 하나의 분명한 문구 수정은 범위가 작고 결과도 바로 확인할 수 있다. 여러 모듈을 가로지르는 간헐적 오류는 원인이 여러 곳에 있을 수 있어 더 깊은 분석이 도움이 될 수 있다.

문구 수정
→ 기본값 또는 낮은 단계

실패가 재현되지 않는 동시성 버그 조사
→ 높은 단계로 원인과 경계를 분석
→ 재현 테스트로 결론 확인

작업을 나눌 수 있다면 모든 단계에서 높은 설정을 유지할 필요는 없다. 먼저 낮은 비용으로 저장소를 살피고, 원인이 좁혀지지 않는 분석 단계에서만 높인다. 구현과 검증은 각각 필요한 수준으로 지정한다.

Codex 설정 예시는 다음과 같다. 지원하는 값은 모델에 따라 다르므로 실제 사용 모델의 목록을 확인한다.

# ~/.codex/config.toml
model_reasoning_effort = "medium"

여러 요청에서 계속 적용할 값은 설정 파일에 두고, 한 작업에만 필요한 심화는 요청에 적는다. 매 요청마다 최고 단계를 지정하면 가벼운 일에도 시간과 비용이 들 수 있다.

작업 지시에 검증 방법을 넣으면 조정 결과를 비교하기 쉽다.

변경 범위는 입력 검증 함수와 테스트 파일이다.
재현 사례를 확인하고 수정안을 제시해라.
관련 테스트를 실행해 실패가 사라졌는지 결과를 보여줘라.

Claude Code에서 한 번만 깊은 검토를 요청할 때는 프롬프트에 심화 표현을 덧붙일 수 있다.

이 변경의 경계 조건과 실패 경로를 확인하고, 발견한 문제와 근거를 정리해라.
ultrathink

Effort를 높이는 것만으로 검증이 끝나지는 않는다. 테스트 결과나 빌드 로그처럼 확인 가능한 근거를 함께 요구하고, 중요한 변경은 별도로 실행해 본다.

강도 조절 전후를 비교할 때는 같은 입력과 완료 조건을 사용한다. 입력이 바뀌면 결과 차이가 effort에서 왔는지 알기 어렵다. 응답 시간이 다소 줄었더라도 누락과 재작업이 늘었다면 실제 작업 시간은 오히려 길어질 수 있다.

설정값 이름을 여러 런타임에 그대로 적용하지 않는다. 값이 없거나 해당 모델에서 지원되지 않으면 런타임이 기본값을 사용할 수 있으므로, 설정이 실제로 반영됐는지 해당 모델 문서와 실행 결과를 함께 확인한다.

간단히 비교하는 방법

effort를 조정할지 망설여지면 대표 작업 하나를 골라 기본값으로 먼저 실행한다. 입력, 수정 범위, 완료 조건을 기록한다. 같은 조건으로 한 단계 올려 다시 실행하고 두 결과를 나란히 확인한다.

입력: 날짜 형식이 다른 레코드 3개
완료 조건: 기존 테스트 통과, 누락 값 처리 설명
비교할 것: 정답 여부, 빠뜨린 사례, 수정 횟수, 소요 시간

한 번의 결과만으로 어느 설정이 항상 낫다고 판단하지 않는다. 다른 작업에서는 난도와 오류 유형이 달라질 수 있다. 짧은 반복 작업은 기본값을 유지하고, 높은 단계가 반복해서 도움을 준 유형을 기록해 다음 선택의 기준으로 삼는다.

높은 단계가 유용했던 이유가 모호한 요구사항 때문이라면 effort보다 지시를 구체화하는 편이 나을 수 있다. 대상 파일, 입력과 출력, 검증 조건을 명시한 뒤에도 복잡한 추론이 필요할 때 설정을 바꾼다.

모델이나 런타임을 바꾼 뒤에는 이전 비교를 그대로 적용하지 않는다. 지원 단계와 기본값이 달라질 수 있으므로 새 기준으로 결과를 살핀다.

설정을 점검할 때는 한 번에 한 값만 바꾼다. 모델, 프롬프트, 도구를 동시에 바꾸면 어떤 변화가 결과에 영향을 줬는지 알기 어렵다.

작업에 필요한 정보가 빠져 있다면 추론 단계를 올리기 전에 자료와 완료 조건을 보충한다. 강도 설정은 부족한 코드나 잘못된 입력을 대신 채워 주지 않는다.

빠른 답이 중요한 탐색과 정확성이 중요한 변경을 같은 기준으로 평가하지 않는다. 먼저 작업에서 중요한 결과가 속도인지, 빠뜨리지 않는 것인지 정하고 비교 항목에 반영한다.

마지막으로 사용한 설정값과 작업 유형을 짧게 기록하면 이후 비슷한 문제에서 출발점을 다시 찾기 쉽다. 기록에는 비밀 정보나 긴 프롬프트 전체를 넣지 않는다.

보충: 런타임별 설정과 공식 권장

Claude Code의 모델 설정과 effort 설명은 기본값에서 시작해 작업 성격에 따라 조절하는 방법을 안내한다. 일상 작업은 medium, 검증과 엣지 케이스는 high, 장시간·최난도 작업은 xhigh 또는 max를 고려하며, 일회성 심화 요청에는 ultrathink를 쓸 수 있다. 모델별 기본값은 다르다.

Codex의 기본 설정, 전체 설정 항목, 모델 목록은 model_reasoning_effort를 통해 강도를 조절하도록 설명한다. 지원 값은 모델마다 다르며, 가장 높은 단계는 장기적이거나 어려운 작업에 필요한 경우만 선택한다. 비용과 시간이 늘 수 있다.

두 런타임 모두 기본 설정에서 시작해 필요한 만큼 조절하는 방향은 같다. 설정 이름, 기본값, 지원 단계와 일회성 요청 방법은 런타임·모델마다 다르다. 기준일: 2026-09-30.