5.3모델 선택과 트레이드오프

Claude 모델은 대체로 세 갈래로 나뉩니다. 이름은 바뀔 수 있지만 성격의 구분은 유지됩니다.

• 가장 가벼운 등급 — 빠르고 저렴합니다. 분류, 추출, 형식 변환처럼 판단이 단순한 작업에 맞습니다.
• 중간 등급 — 대부분의 실무 작업에서 균형이 좋습니다. 기본 선택지로 삼기 좋습니다.
• 가장 강한 등급 — 복잡한 추론과 긴 맥락 통합에서 앞섭니다. 대신 느리고 비쌉니다.

선택 기준은 작업의 성격입니다. 정답이 하나로 정해져 있고 형식만 맞추면 되는 일에 강한 등급을 쓰면 비용만 오릅니다. 반대로 여러 조건을 함께 따져야 하는 판단에 가벼운 등급을 쓰면 품질이 떨어집니다.

시험에서는 "항상 가장 강한 모델을 쓰는 것이 안전하다"는 선택지가 오답으로 나옵니다. 지연이 사용자 경험을 좌우하는 기능에서는 강한 모델이 오히려 나쁜 선택입니다.

품질·지연·비용은 따로 재면 판단이 안 됩니다. 같은 평가 세트로 세 축을 동시에 재야 비교가 됩니다.

for name in CANDIDATES:
    t0 = time.time()
    results = [run(name, case) for case in eval_set]
    elapsed = time.time() - t0
    print(name,
          pass_rate(results),                     # 품질
          elapsed / len(eval_set),                # 건당 지연
          sum(r.usage.input_tokens + r.usage.output_tokens for r in results))

수치가 나오면 대화가 달라집니다. "정확도가 3%p 오르는 대신 지연이 2배가 되고 비용이 4배가 된다"는 문장이 나와야 결정할 수 있습니다. 어느 쪽이 맞는지는 기능에 따라 다릅니다. 실시간 채팅이면 지연이 결정적이고, 야간 배치면 품질을 사도 됩니다.

혼합 전략도 자주 씁니다. 쉬운 입력은 가벼운 모델로 처리하고, 확신이 낮거나 복잡한 것만 강한 모델로 넘기는 방식입니다. 다만 분기 자체에 비용이 들고 구조가 복잡해지므로, 단일 모델로 충분한지 먼저 확인하는 편이 낫습니다.

모델을 바꾸면 정확도만 달라지는 것이 아닙니다. 출력의 습관이 달라집니다.

• 길이가 달라집니다. 같은 지시에 더 길거나 짧게 답합니다.
• 형식 준수 경향이 달라집니다. 어떤 모델은 JSON만 요청해도 설명을 붙이는 경향이 더 강합니다.
• 거절 경계가 달라집니다. 한쪽에서 답하던 요청을 다른 쪽이 거절할 수 있습니다.
• 도구 사용 성향이 달라집니다. 더 자주 부르거나 덜 부릅니다.

그래서 교체는 설정 한 줄 바꾸는 일이 아니라 배포 절차입니다. 평가 세트를 새 모델로 돌려 점수를 비교하고, 차이가 나는 사례를 눈으로 확인하고, 프롬프트를 조정해야 할 수도 있습니다.

특히 위험한 것이 버전을 고정하지 않고 쓰다가 자동으로 갱신되는 경우입니다. 우리가 의도하지 않은 시점에 이 변화들이 한꺼번에 옵니다. 운영에서 버전을 고정하는 이유가 여기에 있습니다.

모델 등급을 바꾸는 것 말고도 조절할 수 있는 축이 있습니다. 더 오래 생각하게 하는 설정입니다.

같은 등급이라도 사고를 늘리면 어려운 추론에서 정확도가 오릅니다. 대신 출력 토큰과 지연이 늘어납니다. 그래서 선택지가 둘로 갈립니다. 강한 등급으로 올릴 것인가, 지금 등급에서 더 생각하게 할 것인가.

판단 기준은 실패의 성격입니다.

• 답이 짧고 성급해서 틀린다면 → 사고를 늘리는 쪽이 효과가 있습니다.
• 개념 자체를 잘못 이해한다면 → 등급을 올리는 쪽이 맞습니다.

둘 다 안 되면 프롬프트나 입력 자료를 의심해야 합니다. 모델만 바꾸며 시간을 쓰는 것이 흔한 낭비입니다. 어느 축을 건드릴지 정하기 전에 실패 사례를 먼저 분류하는 편이 빠릅니다.