Claude 사용법: Sonnet 5.5 실전 가이드

Claude 사용법의 첫 단계: Medium으로 한 가지 작업부터

가장 빠르게 쓸 만한 결과를 얻는 방법은 Claude 앱에서 시작하는 것입니다. Sonnet 5.5와 Medium effort를 선택하고, 참고 자료 묶음 하나를 제공한 뒤 한 줄씩 확인할 수 있는 형식으로 답을 요청합니다.

Anthropic 앱과 Claude Code의 기본값은 Medium입니다. 반면 Claude Platform은 High가 기본이므로 API 사용자는 수준을 명시해야 합니다. Medium은 피드백 주기를 빠르게 유지하면서도 최저 수준까지 낮추지는 않기 때문에 지원 요약, 고객 브리프, 일상적인 분석, 요구사항이 분명한 툴 작업을 처음 시험하기에 적합합니다.

테스트에 사용한 합성 티켓은 로그인 도메인을 변경한 뒤 지원 상담원 6명이 잠겼고, 2명은 로그인 상태를 유지했다는 내용이었습니다. “Invalid organization” 오류가 발생했으며, 사용자 레코드에는 이미 새 도메인이 반영돼 있었습니다. Sonnet 5.5는 이 세부사항을 보존하고 4개 불릿 형식을 따랐습니다. 그러나 조직 매핑이 여전히 이전 도메인을 가리키는 것 같다고 추정했고, 한 가지 해결책을 덜 파괴적인 방법이라고 표현했습니다. 두 내용 모두 티켓에는 없었습니다.

모델 호출 자체의 비용 계산은 간단합니다. Anthropic의 공개 요금에 따르면 입력 194토큰은 $0.000388, 출력 291토큰은 $0.00291이므로 합계는 $0.003298입니다. 10,000번의 호출이 모두 정확히 같은 토큰 구성을 가진다면 순수 모델 비용은 $32.98입니다. 이는 티켓 10,000건을 해결하는 데 드는 비용이 아닙니다. 검색, 연동, 재시도, 저장, 모니터링, 사람의 검토 비용은 모델 호출 밖에 남아 있습니다.

Claude Sonnet 5.5는 어떤 모델인가

Sonnet 5.5는 Anthropic 5.5 제품군의 빠른 범용 모델입니다. 범위가 정해진 업무를 처리하는 실무형 모델로 생각하면 됩니다. 반면 Opus 5.5는 문제가 개방적이고 높은 수준의 판단이 필요할 때 투입하는 선임 전문가에 가깝습니다.

이번 릴리스는 Sonnet 5와 별개의 모델입니다. Claude API에서 사용하는 직접 모델 ID는 날짜 접미사가 없는 claude-sonnet-5-5입니다. 텍스트와 이미지를 입력받아 텍스트를 출력하며, 1 million-token 컨텍스트 창과 최대 128,000개의 출력 토큰을 지원합니다. 이전 모델의 가격과 토크나이저 맥락이 필요하다면 Claude Sonnet 5 리뷰에서 해당 릴리스를 별도로 확인할 수 있습니다.

Anthropic에 따르면 Sonnet 5.5는 Sonnet 5보다 출력을 30% 이상 빠르게 생성하며, 자체 테스트에서 완료된 작업당 비용을 최대 30% 절감했습니다. 두 번째 주장은 토큰 단가가 낮아졌다는 뜻이 아니라, 작업을 끝내는 데 더 적은 토큰을 썼다는 의미입니다. 요금은 Sonnet 5와 같습니다.

벤치마크 수치 역시 Anthropic이 제시한 결과입니다. Terminal-Bench 4.0에서 Sonnet 5.5는 70.6%, Sonnet 5는 10.3%였으며, CursorBench 4.0에서는 각각 55.5%와 34.1%였습니다. 새 모델을 시험할 근거는 되지만, 자신의 티켓 정책이나 코드베이스, 문서 템플릿이 기준을 통과하는지는 알려주지 않습니다. Anthropic의 출시 보고서도 벤치마크 점수와 개방형 업무에서 지속적으로 발휘되는 판단력을 구분합니다.

오류 비용을 기준으로 effort 선택하기

Effort는 품질, 지연 시간, 토큰 사용량을 조절하는 설정이지 글의 길이를 정하는 옵션이 아닙니다. 수준을 높이면 모델이 추론하고 확인할 여지가 커지지만, 대기 시간과 비용도 늘 수 있습니다. 짧은 답이 중요하다면 별도로 간결하게 답하라고 프롬프트에 명시합니다.

Anthropic은 Sonnet 5.5에 맞춰 이 수준들을 다시 보정했습니다. 따라서 이 모델의 Medium은 Sonnet 5의 Medium과 같은 추론량을 뜻하지 않습니다. 자신의 사례로 설정별 테스트를 새로 진행해야 합니다. 이름이 같다는 이유만으로 기존 설정을 그대로 이어 쓰면 안 됩니다.

단기 효과가 큰 7가지 활용법

활용 가치가 높은 업무에는 세 가지 공통점이 있습니다. 입력 자료가 준비돼 있고, 원하는 출력 형식이 분명하며, 사람이나 규칙으로 결과를 검증할 수 있습니다.

1. 지원 티켓 분류

지원 운영 책임자는 고객 메시지, 계정 상태, 최근 티켓 이력, 에스컬레이션 정책을 한데 묶어 제공할 수 있습니다. Sonnet 5.5는 문제, 영향, 근거, 빠진 사실, 허용되는 다음 조치를 정리해 반환할 수 있습니다. 라우팅이나 인계 전에 자료를 다시 읽는 시간이 줄어드는 것이 핵심 효과입니다. 계정을 바꾸는 조언, 환불, 약속, 근본 원인에 대한 주장은 사람이 계속 확인해야 합니다.

첫 워크플로로 가장 적합한 이유는 모든 출력 내용을 특정 출처 필드와 연결할 수 있기 때문입니다. 모델 오류도 빠르게 드러납니다. 요약문이 주장의 출처를 보여주지 못한다면 실제 조치를 실행할 준비가 되지 않은 것입니다.

2. 고객 미팅 사전 브리프

어카운트 디렉터는 최근 통화 녹취, 작업 명세서, 진행 중인 할 일, 갱신 관련 메모를 제공할 수 있습니다. 의사결정, 약속, 위험, 미해결 질문, 다음 회의 안건을 한 페이지에 담도록 요청합니다. 매번 통화 전에 빈 페이지에서 새로 시작하는 대신 반복 가능한 브리핑 형식을 얻는 것이 장점입니다.

“확정”과 “추론”을 별도 섹션으로 나눕니다. 이 한 가지 구분만으로도 모델의 그럴듯한 해석이 고객과의 약속으로 굳어지는 일을 막을 수 있습니다.

3. Pull request 검토

엔지니어링 리드는 모델에 코드 diff, 저장소 규칙, 보안·테스트·하위 호환성 체크리스트를 제공할 수 있습니다. Sonnet 5.5는 위험도 순으로 정리한 1차 검토 결과와 테스트 제안을 만들 수 있습니다. 검토자가 맥락을 더 빨리 파악하도록 돕는 것이 목적이지 자동 승인하기 위한 기능은 아닙니다. 변경 사항의 merge 여부는 시스템을 책임지는 사람이 결정해야 합니다.

4. 범위가 정해진 버그 수정

재현 가능한 버그를 다루는 제품 엔지니어라면 실패 동작, 관련 파일, 인수 조건을 제공할 수 있습니다. 요구사항이 명확한 수정은 Medium effort로 시작하는 것이 합리적입니다. 문제가 여러 서비스에 걸쳐 있거나 첫 실행에서 검증을 건너뛴다면 High로 올립니다. 인수 조건으로 작업의 확산을 막으면서 구현과 테스트 주기를 줄일 수 있습니다.

5. 운영 리뷰와 이사회 자료 초안

재무 또는 운영 팀은 원본 자료와 승인된 슬라이드·문서 템플릿을 함께 제공할 수 있습니다. Sonnet 5.5는 구조화된 리뷰 초안을 만들고, 빠진 부분을 드러내며, 1차 결과물의 형식을 정리할 수 있습니다. Anthropic도 세련된 문서, 슬라이드, 스프레드시트 작업에 이 모델을 명시적으로 포지셔닝합니다. 자료 조립에 드는 시간을 줄일 수 있지만, 모든 재무 관련 주장은 여전히 출처 셀이나 문서 참조가 필요합니다.

6. 인시던트 요약

인시던트 책임자는 이벤트 타임라인, 알림, 조치, 담당자 메모를 모델에 입력할 수 있습니다. 확정된 사건, 가설, 고객 영향, 미해결 질문, 후속 조치를 각각 별도 블록으로 요청합니다. 더 깔끔한 인계 자료와 사후 보고서 초안을 얻을 수 있습니다. 모델이 상관관계를 근본 원인으로 승격하게 두어서는 안 됩니다.

7. 시각적 QA와 인터페이스 다듬기

제품 디자이너나 프런트엔드 엔지니어는 스크린샷을 브랜드 규칙, 인수 체크리스트와 함께 제공할 수 있습니다. Sonnet 5.5는 불일치를 찾아내고 수정 우선순위를 정하며, 범위가 제한된 개선 작업의 구현을 도울 수 있습니다. 눈에 보이는 결함을 더 빠르게 반복 수정하는 것이 장점입니다. 미적 판단, 접근성 테스트, 최종 제품 판단은 여전히 사람이 맡아야 합니다.

만들어볼 만한 3가지 제품

모델에 접속할 수 있다는 사실만으로는 사업이 되지 않습니다. 판매 가능한 제품에는 독점적인 맥락, 통제된 워크플로, 근거, 사람이 최종 결정을 내릴 수 있는 지점이 더해져야 합니다.

1. 근거가 연결된 지원 분류: 가장 강한 기회

티켓과 계정 레코드를 구조화된 요약으로 바꾸고, 모든 주장에 출처 링크를 붙이며, 제안된 조치를 정책과 대조한 뒤 승인 대기열에 초안을 넣는 지원 코파일럿을 만듭니다. 지원 조직 책임자와 외주 서비스 팀은 더 빠르고 일관된 라우팅을 위해 비용을 지불할 가능성이 있습니다.

수요는 수치로 드러납니다. 이번 키워드 데이터에서 ai customer service agent는 미국 월간 검색량 1,300회, 상업적 의도, 전년 대비 815% 성장률을 보였습니다. Intercom의 Fin 가격은 결과 1건당 $0.99입니다. 해결된 결과는 단순 요약 호출보다 훨씬 큰 작업이므로 직접 비교할 수는 없지만, 구매자가 이미 사용량 기반 지원 자동화에 비용을 지불한다는 점은 보여줍니다.

판매 가능한 최소 버전에는 인박스 커넥터 1개, 계정 데이터 커넥터 1개, 4개 필드 요약, 출처 인용, 정책 확인, 승인 또는 거부 컨트롤이 필요합니다. 문제는 연동과 신뢰입니다. 권장 사항의 근거를 입증하지 못하면 고객은 기존 워크플로를 유지할 것입니다.

2. 정책을 이해하는 코드 리뷰 레이어

코드 diff와 팀별 규칙을 읽고, 위험도 순으로 정리한 리뷰, 빠진 테스트, 짧은 merge 브리프를 반환하는 GitHub 앱을 만듭니다. 구매자는 엔지니어링 매니저와 플랫폼 팀입니다.

ai powered code review platform의 미국 월간 검색량은 1,900회이며 전년 대비 19% 성장했습니다. CodeRabbit의 공개 요금은 연간 결제 기준 개발자 1명당 월 $24부터 시작하고, 상위 플랜은 $48과 $72입니다. MVP에는 저장소 제공업체 1곳, pull request webhook, 맞춤 검사, 댓글 화면, 각 발견 사항을 유발한 규칙을 보여주는 감사 추적 기록이 필요합니다.

다만 경쟁이 치열합니다. 일반적인 리뷰어로는 방어 가능한 차별점을 만들 수 없습니다. 규제 대상 릴리스 검사, 데이터 마이그레이션 안전성, 특정 프레임워크처럼 고통이 큰 틈새를 선택하고, 놓친 결함만큼 오탐도 세심하게 측정해야 합니다.

3. 업종 특화 brief-to-PRD 툴: 범용 제품은 제외

통화 내용, 제약 조건, 이전 의사결정을 인수 기준과 미해결 질문이 포함된 제품 브리프로 바꾸는 좁은 워크플로를 만듭니다. 템플릿이 실제 업무와 맞는다면 제품 컨설팅 회사나 특정 업종의 소프트웨어 팀이 구매할 수 있습니다.

정확히 일치하는 검색어 ai product requirements document generator의 미국 월간 검색량은 70회에 불과하며, 전년 대비 50% 감소했습니다. 이는 영업 근거가 아니라 경고 신호입니다. 범용 독립형 PRD 생성기는 여기서 가장 약한 기회입니다. 살아남을 수 있는 형태는 에이전시 디스커버리, 의료 분야 도입, 엔터프라이즈 변경 관리처럼 가치가 더 큰 워크플로 안에 들어가는 부가 기능입니다.

MVP에는 고정된 원본 자료 묶음, 관점이 뚜렷한 템플릿 1개, 의사결정 추적 기능, 구매자가 이미 사용하는 시스템으로 내보내는 기능이 필요합니다. 문제는 얕은 수요와 쉬운 복제입니다. 이미 고객 관계나 업종 데이터 채널을 확보한 경우가 아니라면 만들지 않는 편이 낫습니다.

요금은 그대로지만 워크플로 비용은 낮아질 수 있다

Sonnet 5.5의 요금은 입력 1 million토큰당 $2, 출력 1 million토큰당 $10, 캐시 읽기 1 million토큰당 $0.20입니다. Sonnet 5와 동일한 공개 요금입니다. Anthropic이 비용 절감을 주장하는 근거는 더 적은 토큰으로 작업을 완료한다는 데 있습니다.

예측할 때는 이 차이를 구분해야 합니다. 모델의 추론 과정이 짧아지면 단가표가 바뀌지 않아도 지연 시간과 토큰 비용을 모두 줄일 수 있습니다. 반대로 검색, 서드파티 툴, 재시도, 사람의 검토가 비용의 대부분을 차지한다면 제품 전체 비용은 거의 그대로일 수 있습니다. 호출당 비용이 아니라 승인된 출력물당 비용을 측정해야 합니다.

Claude 앱 구독과 API 사용은 별개의 상품입니다. Pro, Max, Team, Enterprise 요금을 내더라도 Claude Console이나 API 사용량은 포함되지 않습니다. Claude 요금제 가이드에서 일반적인 플랜 경계를 확인할 수 있으며, API 워크플로에는 별도의 Console 접근 권한과 사용량 기반 결제가 필요합니다.

작업 검증을 통과한 뒤 Claude API 워크플로 이전하기

가장 안전한 이전 순서는 단순합니다. 대표 사례로 프롬프트를 검증하고, 새 모델 ID를 고정하고, effort를 명시한 다음, thinking과 tool-call 규약을 수정한 뒤 프로덕션 트래픽을 보냅니다.

Adaptive thinking을 사용하는 일반 요청이라면 thinking 필드를 생략하고, 유형별로 텍스트 블록을 읽습니다.

from anthropic import Anthropic

client = Anthropic()
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[{
        "role": "user",
        "content": "Summarize this ticket as Issue, Impact, Evidence, and Next action.",
    }],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

이전 과정에서는 다음 4가지 변경 사항을 반드시 점검해야 합니다.

1. Anthropic의 Claude 직접 API는 더 이상 thinking: {"type": "disabled"}를 허용하지 않습니다. 사전 thinking 없이 시작하려면 thinking: {"type": "between_tools"}를 사용합니다. Low, Medium, High에서는 작동하지만 Xhigh나 Max에서는 사용할 수 없습니다.
2. 직접 API는 강제 tool_choice 값인 any와 이름을 지정한 tool도 더 이상 허용하지 않습니다. auto를 사용하고, 지원되는 경우 schema를 strict로 설정하며, 툴을 실행해야 하는 시점을 프롬프트에 명시합니다.
3. 응답이 thinking 블록으로 시작할 수 있습니다. 모든 content block을 type별로 파싱하고, content[0].text가 항상 존재한다고 가정해서는 안 됩니다.
4. 툴 루프에서는 thinking block을 변경하지 말고 그대로 다시 전달합니다. 이전 대화에 연결된 signature가 들어 있으므로 message history를 append-only로 유지합니다.

아래 최소 패턴은 between_tools를 사용하고 tool choice를 auto로 유지하며, assistant turn 전체를 보존합니다.

tools = [{
    "name": "lookup_ticket",
    "description": "Look up a support ticket",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {"ticket_id": {"type": "string"}},
        "required": ["ticket_id"],
        "additionalProperties": False,
    },
}]

messages = [{"role": "user", "content": "Use lookup_ticket for T-42."}]
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    thinking={"type": "between_tools"},
    output_config={"effort": "medium"},
    tools=tools,
    tool_choice={"type": "auto"},
    messages=messages,
)

# Keep every block, including signed thinking blocks, exactly as returned.
messages.append({
    "role": "assistant",
    "content": [block.model_dump() for block in response.content],
})

tool_call = next(block for block in response.content if block.type == "tool_use")
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": tool_call.id,
        "content": "Ticket T-42 is open and assigned to Support Ops.",
    }],
})

follow_up = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    thinking={"type": "between_tools"},
    output_config={"effort": "medium"},
    tools=tools,
    tool_choice={"type": "auto"},
    messages=messages,
)

Anthropic의 Sonnet 5.5 마이그레이션 가이드는 직접 API에서 발생하는 400 오류와 대체 필드를 설명합니다. 제가 로컬에서 실행한 Medium between_tools 요청은 1.35초 만에 HTTP 200을 반환했습니다. 별도의 adaptive tool loop에서는 signed thinking block이 생성됐고, 완전한 블록을 변경 없이 다시 전달하자 다음 turn도 성공했습니다.

주의할 점이 하나 있습니다. 제 호출은 AI 게이트웨이를 통과했습니다. 이 호환성 계층에서는 Anthropic 문서상 직접 API 오류를 일으키는 기존 disabled thinking 값과 강제 tool_choice: any를 의도적으로 보냈는데도 HTTP 200이 반환됐습니다. 미들웨어가 요청을 받아들였다고 해서 직접 연동도 호환된다고 판단하면 안 됩니다. 전환 전에 Anthropic Playground에서 원시 요청을 확인하거나 직접 엔드포인트를 테스트해야 합니다.

Claude Sonnet 5.5가 해결하지 못하는 것

근거 없는 추론을 사실로 바꿔주지는 않습니다. 로컬 지원 테스트가 이를 명확히 보여줬습니다. 영향이 큰 주장에는 출처 참조를 요구하고, 환불, 계정 변경, 법적 약속, 의료적 결정, 보안 조치에는 승인 절차를 유지해야 합니다.

모든 작업을 Medium으로 처리할 수 있게 해주지도 않습니다. 자체 사례에서 추론 누락이나 불완전한 작업이 나타날 때 effort를 높입니다. 지속적인 판단이 필요한 개방형 업무에는 Opus를 사용하는 것이 좋습니다. Opus 5.5 비교에서 상위 모델이 적합한 지점을 설명합니다.

모델 호출 자체를 완성된 제품으로 만들어주지도 않습니다. 커넥터, 권한, 정책 검사, 평가, 관측성, 폴백 동작, 실용적인 검토 인터페이스에 프로덕션 작업의 대부분이 들어갑니다.

최신 출처가 필요 없게 되는 것도 아닙니다. 지원이나 리서치 답변이 현재 허용되는 것, 요구되는 것, 청구되는 비용에 따라 달라진다면 모델에 검색 툴이나 지식 툴을 제공하고 확인하도록 지시해야 합니다.

월요일에 바로 할 일

신뢰할 수 있는 원본이 분명한 대기열 하나를 선택합니다. 월요일에 최근 사례 20개를 가져와 불필요한 개인정보를 제거하고, 하나의 고정된 출력 schema로 Sonnet 5.5를 Medium에서 실행합니다. 사실 정확도, 근거 없는 추론, 완전성, 소요 시간, 토큰 사용량을 평가합니다. 이 프롬프트가 기준을 통과한 뒤에만 기존 API model ID를 변경하고 위의 마이그레이션 검사를 실행합니다.

비즈니스에 맞춘 출처 기반 Claude 워크플로가 필요하다면 AI 프로덕션 시스템에서 자세한 내용을 확인할 수 있습니다.