어떤 Claude를 얼마에 쓸 것인가 — 상황에 맞춰 고르고 비용까지 설계하기

5.1 토큰·컨텍스트 윈도우와 비결정성

Claude는 문장을 통째로 이해하지 않고, 텍스트를 토큰(token, 모델이 다루는 최소 단위 — 한국어는 한두 글자, 영어는 단어 일부 규모)으로 나눠 다음 토큰을 하나씩 예측하며 답을 이어 갑니다. 컨텍스트 윈도우(context window, 한 요청에서 참고 가능한 토큰 총량)는 입력과 출력을 합쳐 세므로, 긴 문서를 넣을수록 답변에 쓸 여유가 줄어듭니다. 같은 프롬프트라도 매번 답이 미세하게 달라지는데(비결정성, non-determinism), 이는 다음 토큰을 확률로 뽑는 샘플링(sampling)과 temperature 설정 탓입니다. 재현이 중요하면 temperature를 낮춰 답을 안정시킵니다.

5.2 Opus·Sonnet·Haiku: 세 티어의 분업

Claude 모델군은 크게 세 등급으로 나뉩니다. Opus는 가장 깊은 추론을 맡는 상위 모델로 복잡한 코드 분석이나 다단계 판단에 강하지만 응답이 느리고 비용이 높습니다. Sonnet은 품질과 속도·비용의 균형점으로, 실서비스 대부분의 기본값으로 삼기 좋습니다. Haiku는 가장 빠르고 저렴한 경량 모델로 분류·추출·간단한 응답처럼 부담이 낮은 작업에 맞습니다. 세 축(품질·지연 시간·비용)은 함께 좋아지지 않으므로, 작업의 난이도와 허용 지연, 호출량을 저울질해 티어를 정합니다. 하나로 통일하기보다 경로별로 다른 모델을 쓰는 편이 합리적입니다.

5.3 빠른 응답부터 확장 사고까지: 노력 수준 조절

같은 모델이라도 얼마나 깊이 생각하게 할지 조절할 수 있습니다. 기본은 즉답에 가까운 빠른 모드지만, 확장 사고(extended thinking, 모델이 최종 답 이전에 내부적으로 단계를 밟아 추론하는 방식)를 켜면 어려운 문제의 정확도가 올라가는 대신 토큰과 시간이 더 듭니다. 최신 모델은 적응형 사고(adaptive thinking)를 지원해, 질문의 난이도에 따라 생각의 깊이를 스스로 늘리고 줄입니다. 노력 수준(effort level)을 낮음·중간·높음처럼 지정하면, 쉬운 요청은 값싸게 넘기고 어려운 요청에만 계산을 더 쓰도록 예산을 배분할 수 있습니다. 모델마다 지원 여부가 다르니 선택 전에 확인합니다.

5.4 제로샷·싱글샷·멀티샷: 예시의 개수

프롬프트에 정답 예시를 몇 개 넣느냐로 기법을 나눕니다. 제로샷(zero-shot)은 예시 없이 지시만 주는 방식으로, 일반적인 작업이면 이것만으로 충분할 때가 많습니다. 싱글샷(single-shot)은 원하는 입력과 출력 형태를 한 쌍 보여 주는 방식이고, 멀티샷(multi-shot)은 예시를 여러 개 제시해 형식과 판단 기준을 더 촘촘히 잡아 줍니다. 출력 형식이 까다롭거나 분류 기준이 미묘할수록 예시를 늘리면 일관성이 올라가지만, 예시도 전부 입력 토큰이라 비용과 컨텍스트를 함께 잡아먹습니다. 먼저 제로샷으로 시도하고, 품질이 흔들리는 지점에만 예시를 더하는 순서가 경제적입니다.

5.5 SDK와 실시간 스트림: 어떻게 호출할 것인가

Claude 호출의 바탕은 REST 방식의 HTTP 요청이며, 파이썬·타입스크립트용 공식 SDK는 그 요청과 응답을 감싸 인증·재시도·타입 처리를 대신해 줍니다. SDK를 쓰면 원시 HTTP를 직접 다룰 때보다 코드가 짧고 실수가 줄지만, 내부에서 오가는 것은 결국 같은 REST 요청이라는 점을 알면 문제를 추적하기 쉽습니다. 응답을 한꺼번에 받지 않고 생성되는 대로 흘려받는 스트리밍(streaming)을 쓰면, 긴 답변도 첫 글자가 빨리 도착해 체감 지연이 줄어듭니다. 실시간 음성처럼 양방향 연결이 필요할 때는 웹소켓(websocket) 경로를 씁니다.

5.6 토큰 예산·프롬프트 캐싱과 모델 교체 리스크

비용은 대체로 입력·출력 토큰 양에 비례하므로, 기능을 붙이기 전에 요청당 평균 토큰과 하루 호출량을 곱해 월 비용을 미리 가늠해 두면 예산이 어긋나지 않습니다. 매 요청에 똑같이 들어가는 긴 지시문이나 참고 문서가 있다면 프롬프트 캐싱(prompt caching, 반복되는 앞부분을 저장해 재사용하는 기능)으로 그 부분의 비용과 지연을 크게 줄이고, 캐시 구간을 나눠 지정하면 바뀌는 뒷부분만 새로 처리하게 됩니다. 한편 모델을 새 버전으로 올릴 때는 같은 프롬프트라도 응답 형식이나 판단이 달라질 수 있으니, 버전을 고정해 두고 교체 전에 회귀 점검을 거치는 편이 안전합니다.

! 흔한 함정

• 가장 똑똑한 모델을 기본값으로 두면 안전하다는 생각 — 대부분의 요청은 Opus까지 필요하지 않아, 무거운 모델을 전 구간에 쓰면 비용과 지연만 불어납니다.
• temperature를 0으로 두면 완전히 똑같은 답이 늘 보장된다는 오해 — 비결정성은 크게 줄지만 완전한 재현이 항상 보장되지는 않으므로, 응답의 정확 일치에 의존하는 검증은 피합니다.
• 예시를 많이 넣을수록 언제나 좋다는 생각 — 멀티샷은 정확도를 올리지만 예시도 전부 토큰이라 비용과 컨텍스트를 함께 소모하므로, 필요한 만큼만 더합니다.
• 확장 사고를 켜 두면 항상 낫다는 생각 — 쉬운 작업에는 시간과 토큰만 늘고 이득이 적으므로, 난이도에 맞춰 켜고 끕니다.