어떤 모델보다 '얼마나 깊게 생각하게 할까' — model × effort 2축으로 LLM 제어하기

LLM을 붙여 무언가를 만들 때 가장 먼저 부딪히는 질문은 보통 이거다. "어떤 모델을 쓰지?" 자연스럽게 우리는 모델 이름들을 줄 세운다. 작고 빠른 모델, 중간 모델, 가장 똑똑한 모델. 그리고 작업이 어려워 보이면 큰 모델로, 단순해 보이면 작은 모델로 손이 간다. 마치 모델을 고르는 일이 곧 "얼마나 똑똑하게 풀까"를 정하는 일인 것처럼.

그런데 최근 모델들은 이 한 줄 직관을 깨뜨린다. 같은 모델 안에서도 "얼마나 깊게 생각할지"를 따로 조절할 수 있게 됐기 때문이다. 이걸 흔히 추론 깊이(reasoning effort)라고 부른다 — 모델이 답을 내기 전에 속으로 얼마나 많은 단계를 거쳐 생각하느냐를 정하는 값이다. 같은 모델, 같은 질문이라도 추론 깊이를 낮게 주면 빠르고 싸게, 높게 주면 느리고 비싸지만 더 꼼꼼하게 답한다.

다시 말해 LLM을 제어하는 손잡이가 하나가 아니라 둘이 됐다. 하나는 모델 능력(어떤 모델을 쓸까), 다른 하나는 추론 깊이(그 모델을 얼마나 깊게 굴릴까). 이 글은 이 둘을 한 축으로 뭉뚱그릴 때 생기는 낭비를 짚고, 둘을 따로 떼어 격자(grid)처럼 다루는 방법, 그리고 빠지기 쉬운 함정을 정리한다.

통념: "GPT-X냐 Claude-Y냐"라는 한 축

"모델을 고른다"는 말에는 은근한 전제가 깔려 있다. 모델 능력과 사고 깊이가 한 덩어리라는 전제다. 큰 모델은 똑똑하니까 깊게 생각하고, 작은 모델은 가벼우니까 얕게 생각한다 — 이렇게 한 줄에 묶어 버리면 선택지는 "능력의 사다리" 한 줄로 좁아진다.

다이어그램 설명. 위 그림은 흔히 머릿속에서 돌아가는 모델 선택 흐름을 그린 것이다. 작업이 들어오면 "어렵냐 / 보통이냐 / 쉽냐"만 보고 능력 사다리에서 한 칸을 고른 뒤, 그 모델이 알아서 적당히 생각해 주기를 기대한다. 핵심은 분기가 단 하나라는 점이다 — "얼마나 깊게 생각할지"라는 두 번째 결정이 아예 보이지 않고, 모델 능력을 고르는 순간 깊이도 따라 정해진다고 가정한다. 이 가정 때문에 "쉬운 작업인데 깊게 검증하고 싶다" 같은 조합을 표현할 길이 없어진다. 함정은, 이 그림에서 빠진 두 번째 손잡이가 실제로는 비용과 품질을 가장 크게 흔드는 손잡이라는 데 있다.

이 한 축 사고가 옛날에는 맞았다. 추론 깊이를 따로 조절할 수단이 없었으니까. 모델을 고르면 그 모델의 "생각하는 양"은 사실상 고정이었다. 그래서 더 깊은 사고가 필요하면 더 큰 모델로 갈아타는 것 말고는 방법이 없었다. 모델 능력과 사고 깊이가 실제로 한 손잡이에 묶여 있었던 시대다.

문제: 능력과 깊이를 뭉뚱그리면 세밀한 제어가 안 된다

최근 모델 API에는 추론 깊이를 직접 지정하는 파라미터가 생겼다. 예를 들어 한 모델은 사고 깊이를 low · medium · high · max 같은 단계로 받는다(여기에 high와 max 사이의 한 단계가 더 끼어 있기도 하다). 같은 모델에 같은 입력을 줘도 이 값에 따라 결과의 꼼꼼함과 토큰 비용이 크게 달라진다. 낮은 단계는 군더더기 없이 빠르게 답하고, 높은 단계는 여러 갈래를 검토하고 스스로 검산까지 하며 답한다.

여기서 통념의 한계가 드러난다. 능력과 깊이를 한 축으로 뭉뚱그려 버리면, 이 둘이 만드는 조합 중 절반을 표현할 수가 없다. 구체적으로 두 가지 낭비가 생긴다.

• 큰 모델에 얕은 일을 시키는 낭비. 형식 변환, 라벨 붙이기, 간단한 추출처럼 기계적인 작업에 가장 똑똑한 모델을 높은 깊이로 굴리면, 답은 맞지만 토큰과 지연을 몇 배로 태운다. "어려운 도메인이니 큰 모델"이라는 직관이 "그러니 깊게도"로 새어 나간 결과다.
• 작은 모델에 깊은 검증을 맡기는 낭비. 반대로 비용을 아끼겠다고 작은 모델을 골라 놓고 어려운 설계·검증을 시키면, 깊이를 아무리 높여도 능력의 천장에 막혀 결과가 부실해진다.

두 낭비의 뿌리는 같다. "어떤 모델"이라는 결정과 "얼마나 깊게"라는 결정이 사실은 서로 다른 질문인데, 하나로 합쳐 버렸다는 것이다. 도메인 난이도(모델 능력으로 풀 문제)와 사고량(추론 깊이로 풀 문제)은 같이 움직이지 않을 때가 많다. 쉬운 도메인이라도 실수 비용이 크면 깊게 생각하게 해야 하고, 어려운 도메인이라도 한 번 훑기만 하면 되는 단계가 있다.

방법: model × effort, 2축 격자로 제어하기

해법은 단순하다. 한 축을 둘로 쪼갠다. 가로축에 모델 능력(어떤 모델), 세로축에 추론 깊이를 놓으면, 작업마다 격자의 한 칸을 고르는 문제가 된다. 사다리 위 한 점이 아니라, 평면 위 한 점을 고르는 것이다.

다이어그램 설명. 위 그림은 가로축에 모델 능력(왼쪽 작은 모델 → 오른쪽 큰 모델), 세로축에 추론 깊이(아래 낮음 → 위 높음)를 놓은 사분면이다. 왼쪽 아래 칸은 "작은 모델을 얕게 굴리는" 가장 싼 칸(대량 분류·형식 변환)이고, 대각선 반대편 오른쪽 위 칸은 "큰 모델을 깊게 굴리는" 가장 비싼 칸(설계·검증 같은 난제)이다. 이 대각선이 곧 통념의 "능력 사다리" 한 줄에 해당한다. 핵심은 대각선을 벗어난 두 칸이다 — 오른쪽 아래는 "어려운 도메인이지만 단순 추출"이라 큰 모델을 얕게, 왼쪽 위는 "쉽지만 꼼꼼함이 필요한 추론"이라 작은 모델을 깊게 굴리는, 한 축으로는 그릴 수 없던 조합이다. 함정은 이 사분면을 보고 "오른쪽 위로 갈수록 항상 좋다"고 읽는 것이다 — 칸의 가치는 작업이 무엇을 요구하느냐에 달려 있지, 오른쪽 위 구석이 정답인 게 아니다.

실제 코드에서 두 손잡이는 정말로 분리돼 있다. 모델은 모델 식별자로, 추론 깊이는 별도 설정값으로 지정한다. 아래는 한 LLM API(Anthropic의 Claude API)에서 두 축을 따로 주는 모습이다.

# 1단: 모델 능력 축 — "어떤 모델" (가로축)
#       작업의 도메인 난이도에 맞춰 고른다
# 2단: 추론 깊이 축 — output_config의 effort (세로축)
#       같은 모델이라도 얼마나 깊게 생각할지를 따로 지정
response = client.messages.create(
    model="claude-opus-4-8",                 # 능력 tier (별개의 손잡이)
    max_tokens=16000,
    thinking={"type": "adaptive"},           # 깊이를 모델이 적응적으로 조절
    output_config={"effort": "low"},         # 추론 깊이: low | medium | high | max
    messages=[{"role": "user", "content": "..."}],
)

코드 설명. 이 코드가 보여주는 핵심은 모델과 추론 깊이가 같은 요청 안에서 서로 다른 자리에 들어간다는 점이다. model은 능력 tier를 고르는 가로축이고, output_config 안의 effort 값이 그 모델을 얼마나 깊게 굴릴지 정하는 세로축이다. 둘은 독립적이라, 큰 모델에 낮은 깊이를 줄 수도, 작은 모델에 높은 깊이를 줄 수도 있다 — 같은 줄에서 한쪽만 바꿔도 된다. 이 분리가 바로 한 축 사고가 표현하지 못하던 대각선 바깥 조합을 가능하게 한다. 함정 하나: 깊이를 낮게 주면 빠르고 싸지지만 모델이 검토 단계를 줄이므로, 꼼꼼함이 중요한 작업에 무심코 낮은 값을 두면 품질이 조용히 떨어진다.

같은 작업을 추론 깊이만 바꿔 돌려 보면 두 손잡이가 따로 논다는 게 분명해진다. 모델은 그대로 둔 채 깊이만 올리면, 토큰과 지연이 늘어나는 대신 결과의 꼼꼼함이 올라간다.

추론 깊이	토큰·지연	결과 성향	어울리는 작업
낮음(low)	가장 적음	군더더기 없이 바로 답, 도구 호출도 최소	분류·요약·형식 변환 같은 기계적 작업
중간(medium)	보통	균형 — 적당히 검토하고 답	대부분의 일상적 작업
높음(high)	많음	여러 갈래 검토, 더 꼼꼼	코딩·에이전트처럼 정확도가 중요한 작업
최대(max)	가장 많음	스스로 검산까지, 가장 신중	비용보다 정확성이 압도적으로 중요할 때

표 설명. 이 표는 모델을 고정한 채 추론 깊이만 한 단씩 올렸을 때 무엇이 달라지는지를 나란히 둔 것이다. 아래로 내려갈수록 토큰과 지연이 커지는 대가로 결과가 더 신중해진다. 같은 축에서 비교하니 "깊이를 한 단 올릴 때 무엇을 더 내고 무엇을 얻는가"가 한눈에 잡힌다. 표가 던지는 메시지는 단순하다 — 깊이는 공짜가 아니므로, 필요한 만큼만 올린다. 함정은 맨 아래 칸을 기본값처럼 쓰는 것이다. 가장 깊은 단계는 쉬운 작업에서는 오히려 과하게 생각해 토큰만 태우고 품질 이득은 미미할 수 있다.

멀티 에이전트에서 단계별로 둘을 따로 지정하기

2축 분리가 가장 빛나는 곳은 여러 단계를 거치는 에이전트 파이프라인이다. 한 작업이 "탐색 → 작성 → 검증" 같은 단계로 나뉠 때, 각 단계는 요구하는 능력과 깊이가 제각각이다. 통념대로라면 파이프라인 전체에 한 모델·한 깊이를 박아 두지만, 2축으로 보면 단계마다 격자의 다른 칸을 고를 수 있다.

두 흐름을 나란히 비교해 보자. 하나는 모든 단계를 똑같이 깊게 굴리는 흐름, 다른 하나는 단계마다 깊이를 달리 주는 흐름이다.

▲ 흐름 A — 한 깊이로 통일

다이어그램 설명. 위 흐름은 탐색·작성·검증 세 단계 모두에 같은 모델과 같은 높은 추론 깊이를 박아 둔 경우다. 위에서 아래로 단계가 이어지지만 세 칸의 설정이 똑같다는 게 핵심이다. 장점은 단순함 — 한 번 정해 두면 신경 쓸 게 없다. 대가는 분명하다. 파일을 그러모으는 가벼운 탐색 단계까지 가장 깊은 사고로 굴려, 쉬운 구간에서 토큰과 지연을 불필요하게 태운다. 함정은 "어차피 어려운 작업이니 전부 깊게"라는 판단인데, 같은 작업 안에서도 단계별 난이도는 크게 다르다는 사실을 놓친 것이다.

▲ 흐름 B — 단계마다 깊이 분배

다이어그램 설명. 두 번째 흐름은 같은 세 단계인데 칸마다 모델 능력과 추론 깊이를 다르게 줬다. 파일을 빠르게 그러모으기만 하면 되는 탐색 단계는 작은 모델을 얕게, 정확성이 결과를 좌우하는 검증 단계는 큰 모델을 가장 깊게 굴린다. 첫 흐름과의 차이는 "예산을 어디에 몰아주느냐"다 — 똑같이 통일하는 대신, 중요한 단계에 사고 비용을 집중하고 가벼운 단계에서 아낀다. 이렇게 하면 전체 비용은 내려가면서도 결과 품질을 좌우하는 단계의 꼼꼼함은 오히려 지켜진다. 함정은 검증 단계의 깊이까지 아끼려는 유혹인데, 거기서 줄인 비용은 대개 틀린 결과를 되돌리는 비용으로 더 크게 돌아온다.

여기서 한 가지 덧붙일 게 있다. 비싼 모델을 깊게 굴리는 작은 보조 작업(서브 에이전트)을 따로 떼어 낮은 능력·낮은 깊이로 돌리면, 메인 흐름은 그대로 두면서 곁가지 비용만 깎을 수 있다. 메인 작업의 캐시나 맥락을 건드리지 않고 곁가지만 싸게 처리하는 셈이다.

효과와 트레이드오프

2축으로 보면 비용과 품질을 격자 위에서 세밀하게 조율할 수 있다. "이 단계는 싸게, 저 단계는 신중하게"를 한 점이 아니라 평면으로 표현하니, 통념의 사다리로는 불가능하던 조합이 전부 손에 들어온다. 비용은 필요한 칸에만 집중되고, 품질이 중요한 칸은 깊이로 지켜진다.

다만 분명한 트레이드오프가 따른다. 추론 깊이를 올리면 토큰과 지연이 가파르게 늘어난다. 깊은 사고는 그 자체로 많은 토큰을 쓰고, 응답이 길어지면서 한 요청이 몇 분씩 걸리기도 한다. 그래서 깊이는 "필요한 칸에만" 올려야지, 안전하게 보이려고 기본값을 높이면 비용이 조용히 새어 나간다.

가장 흔한 함정은 따로 있다. 추론 깊이를 모델 능력으로 착각하는 것이다. 약한 모델에 깊이를 아무리 높여 줘도, 모델 자체의 능력 천장은 그대로다. 깊이는 "주어진 능력 안에서 얼마나 꼼꼼히 굴릴지"를 정할 뿐, 능력 자체를 끌어올리지 못한다. 어려운 도메인 문제가 잘 안 풀린다면 먼저 의심할 것은 깊이가 아니라 모델 능력 축이다 — 깊이를 올리기 전에 한 칸 위 능력의 모델로 올라가야 할 수도 있다. 반대로 큰 모델이 쉬운 작업에서 과하게 생각하며 토큰을 태운다면, 능력은 그대로 두고 깊이만 한 단 내리는 게 답이다.

정리하면, 어떤 작업을 받았을 때 던질 질문은 둘이다. 첫째, "이 작업의 도메인이 얼마나 어려운가"(능력 축). 둘째, "이 단계가 얼마나 꼼꼼한 사고를 요구하는가"(깊이 축). 두 질문에 따로 답하고 격자의 한 칸을 고르면 된다. 아래 결정 흐름이 그 두 질문을 차례로 묻는다.

다이어그램 설명. 위 결정 흐름은 작업 하나를 받았을 때 두 손잡이를 차례로 묻는 길을 그린 것이다. 먼저 도메인이 어려운지를 물어 모델 능력 축을 정하고, 그다음 이 단계가 꼼꼼한 사고를 요구하는지를 물어 추론 깊이 축을 정한다. 두 분기를 거치면 격자의 한 칸이 자연스럽게 떨어진다. 통념의 한 축 흐름(맨 앞 그림)과의 차이는 분기가 둘이라는 점이다 — 능력과 깊이를 한 번에 묶지 않고 따로 결정한다. 함정은 두 질문의 답이 항상 같은 방향이라고 가정하는 것이다. "도메인이 어렵다"가 곧 "깊게 생각해야 한다"는 아니며, 어려운 도메인의 단순 추출 단계나 쉬운 도메인의 신중한 검증 단계처럼, 두 축이 엇갈리는 칸이 실전에서 자주 나온다.

모델 능력과 추론 깊이는 별개의 손잡이다. 하나는 "무엇으로 풀까", 다른 하나는 "얼마나 깊게 풀까". 둘을 한 축으로 뭉뚱그리면 절반의 조합을 잃고, 따로 떼어 격자로 다루면 비용과 품질을 작업마다 정밀하게 맞출 수 있다. 다음에 "어떤 모델 쓰지?"라는 질문이 떠오르면, 곧바로 두 번째 질문을 이어 붙이자 — "그리고 얼마나 깊게 굴리지?"

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.