전자상거래를 위한 Claude Opus 5.5: 카피라이팅과 고객 응대 답변

claude-opus-5-5는 hiapi 자체의 모델 카드에서 입력 및 출력 모달리티가 모두 text로 표시되어 있습니다. 이미지 생성은 없고, 이미지 입력에 대한 언급도 없습니다. 따라서 요구사항에 '상품 이미지'가 등장하면, 순수 텍스트 LLM을 마주할 때와 똑같이 솔직한 답은 '잘못된 도구를 썼다'입니다. 온라인 스토어 시나리오에서 이 모델이 실제로 잘하는 것은 글쓰기입니다. 상품 설명, 상품 페이지 카피, 고객 응대 답변이죠. 또한 대부분의 사람이 한 번도 건드려 본 적 없는 reasoning 파라미터가 있는데, 이 파라미터에는 실제로 요금이 부과되는 부작용이 있어 운영 파이프라인에 연결하기 전에 알아 둘 가치가 있습니다. 아래는 hiapi API를 대상으로 한 네 번의 실제 호출로, 실제 출력, 실제 토큰 카운트, 그리고 실제 비용을 치르고서야 발견한 함정 하나를 담고 있습니다.

reasoning.effort 파라미터, 그리고 그것이 실제로 주는 것

claude-opus-5-5의 모델 카드에는 다섯 가지 reasoning effort 등급이 나열되어 있습니다: low, medium, high, xhigh, max. 요청 구조는 다음과 같습니다:

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "high"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Write a 60-word product description. No superlatives."},
      {"role": "user", "content": "Product: insulated water bottle. 750ml, stainless steel, double-wall vacuum insulation, leak-proof lid, matte finish. Keeps drinks cold 24h, hot 12h."}
    ]
  }'

다른 두 가지 요청 구조도 그럴듯해 보이지만 모두 실패합니다. 최상위 필드 reasoning_effort와 Anthropic 네이티브의 thinking: {"type": "enabled", "budget_tokens": ...} 블록은 모두 invalid_request를 반환합니다. 이 라우트에서 유일하게 유효한 구조는 reasoning: {"effort": "..."}입니다.

처음의 가설은 더 높은 effort 등급이 더 깊이 사고한 답변을 대가로 더 많은 토큰을 소비한다는 것이었습니다. 완전히 동일한 60단어 설명 프롬프트를 max_tokens: 500으로 minimal(문서화되지 않음, 아래 참조), low, medium, high, max로 각각 보내 보았지만 결과는 그렇지 않았습니다:

effort	prompt_tokens	completion_tokens	finish_reason
minimal	130	499	stop
low	130	499	stop
medium	130	499	stop
high	130	499	stop
max	130	499	stop

모든 등급이 동일한 프롬프트에 대해 정확히 499개의 completion 토큰을 청구했습니다. 근접한 것이 아니라 완전히 동일했습니다. 실제로 달라진 것은 작성된 내용이었습니다:

minimal: 어디에 있든 이 750ml 스테인리스 물병으로 수분을 유지하세요. 이중벽 보온으로 음료를 24시간 차갑게, 12시간 뜨겁게 유지해 주므로 등산로에서 헬스장까지 물이 늘 상쾌합니다. 누수 방지 뚜껑은 배낭 안에서도 단단히 밀폐되고, 무광 마감은 긁힘에 강하며 손에 쥐었을 때도 안정적입니다. BPA 프리, 내구성 좋음, 모든 운동과 야외 모험에 적합합니다.

high: 스테인리스 보온 물병, 750ml. 긴 등산로와 더 긴 운동을 위해 만들어졌습니다. 이중벽 스테인리스 보온으로 음료를 24시간 차갑게 또는 12시간 뜨겁게 유지하므로 마지막 한 모금까지 물이 신선합니다. 누수 방지 뚜껑은 배낭이나 헬스백 안에서도 단단히 밀폐됩니다. 무광 마감은 마모에 강하고 땀 묻은 손에도 문제없습니다. 750ml는 라이딩 한 번에 충분하면서도 너무 무겁지 않습니다.

high는 굵은 제목 한 줄을 추가하고 세일즈 포인트 순서를 재구성했으며, minimal은 곧바로 세일즈 포인트로 들어갑니다. 둘 다 60단어에 맞고, 둘 다 '최상급 형용사 금지' 규칙을 지켰으며, 비용도 같습니다. low와 medium은 그 사이에 위치하며 구조가 차례로 줄어듭니다. 참고로 minimal은 실제로 문서에 나열된 다섯 등급 목록에 없습니다. 거부되지는 않았지만 문서화되지 않은 값은 운영에서 의존하지 말고 지원되지 않는 것으로 취급해야 합니다. 나열된 다섯 등급 중 하나(low/medium/high/xhigh/max)를 사용하세요.

진짜 교훈: reasoning.effort는 가격이 아니라 스타일을 바꿉니다. 고정된 max_tokens 아래에서는 비용이 effort 문자열이 아니라 당신이 설정한 상한에 달려 있습니다. low가 저렴한 등급이라고 생각하며 effort 등급별로 카피 파이프라인 예산을 잡고 있다면, 그건 아닙니다. max_tokens만이 청구서를 바꾸는 유일한 레버입니다.

함정: reasoning이 max_tokens 예산을 조용히 잠식한다

'비용은 max_tokens에 달려 있다'는 발견에는 날카로운 부작용이 있습니다. claude-opus-5-5는 눈에 보이는 답변을 쓰기 전에 내부 추론을 수행하는데, 이 내부 추론이 답변 자체와 동일한 max_tokens 상한을 공유합니다. 상한을 올리지 않고 effort를 높이면, 모델이 답변을 쓰다 중간에 예산을 다 써 버리거나, 눈에 보이는 내용을 하나도 쓰기 전에 다 써 버릴 수 있습니다.

첫 번째 사례: 평범한 카피 프롬프트에 effort: xhigh와 max_tokens: 500을 사용:

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "xhigh"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Given a product spec, write a title (max 70 characters), 3 bullet features, and a 2-3 sentence description. No superlatives, no exclamation marks."},
      {"role": "user", "content": "Product: insulated travel mug. Material: 18/8 stainless steel, double-wall vacuum insulation. Capacity: 16oz. Lid: leak-proof slide lock. Keeps drinks hot 6 hours, cold 12 hours."}
    ]
  }'

실제 응답, 편집 없음. 문장 중간에서 끊겼습니다:

제목: 16oz 스테인리스 보온 여행 머그, 누수 방지 슬라이드 락 뚜껑

특징:

• 보온 및 보냉: 이중벽 진공 보온으로 음료를 6시간 뜨겁게, 12시간 차갑게 유지합니다.
• 내구성 있는 구조: 18/8 스테인리스로 제작되어 녹슬지 않고 냄새가 남지 않습니다.
• 누수 방지 뚜껑: 슬라이드 락이 개구부를 밀폐해 가방에 넣어도 쏟을 걱정이 없습니다.

설명: 이 16oz 여행 머그는 이중벽 진공 보온으로 커피를 오전 내내 뜨겁게 유지하거나, 당신의

finish_reason: "length", 500개의 completion 토큰 청구, 그리고 설명 절이 '또는 당신의'에서 뚝 끊겼습니다. 끝 문장부호도 없고, 오류도 없고, 경고 필드도 없습니다. HTTP 200만 확인하는 파이프라인이라면 그 반쪽 문장을 상품 페이지에 그대로 게시할 것입니다.

두 번째 사례는 더 나쁩니다. 고객 응대 답변 프롬프트를 max_tokens: 300으로 기본 reasoning과 함께 보내자 완전히 빈 응답이 반환되었습니다.

{
  "finish_reason": "length",
  "usage": {"prompt_tokens": 157, "completion_tokens": 300, "total_tokens": 457},
  "message": {"content": "", "reasoning_details": [{"text": "", "type": "reasoning.text"}]}
}

content는 빈 문자열입니다. reasoning_details 필드가 원인을 확인해 줍니다. 모델이 300 토큰 예산 전부를 내부 추론에 써 버렸고("text": "", 추론 흔적조차 노출되지 않고 불투명한 암호화 signature 블록만 있음), 실제 답변을 쓸 공간이 남지 않았습니다. hiapi는 여전히 그 호출에 300개의 completion 토큰 전부를 청구했습니다. 눈에 보이는 답변이 나왔든 아니든 당신은 사고에 대해 비용을 지불합니다.

두 경우 모두 해결책은 같습니다. max_tokens를 설정할 때 눈에 보이는 답변에 필요한 양 위로 실제 여유분을 남기세요, 특히 high/xhigh/max effort에서 그렇습니다. 또한 finish_reason: "stop"을 좋은 답변의 증거로 믿지 마세요. 데이터베이스에 쓰기 전에 content가 비어 있지 않고 실제로 의미를 완결지었는지 확인하세요.

사용 사례: 고객 응대 답변 초안 작성

당신의 정책과 실제 고객 메시지를 넣어 주세요:

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 400,
    "reasoning": {"effort": "medium"},
    "messages": [
      {
        "role": "system",
        "content": "You are a customer support agent for an online water bottle store. Policy: 30-day return window from delivery. Manufacturing defects reported after the window should be referred to the manufacturer'\''s own warranty. Reply in under 100 words, empathetic but concise, end with a clear next step."
      },
      {
        "role": "user",
        "content": "I bought a water bottle 35 days ago and the seal is already leaking. Can I get a refund or exchange?"
      }
    ]
  }'

실제 응답, 편집 없음:

누수가 발생해 죄송합니다. 이미 35일이 지나 주문이 저희의 30일 반품 기간을 넘었기 때문에 저희 쪽에서 반품이나 교환을 처리해 드릴 수 없습니다. 많은 물병 브랜드가 정상 사용 중 발생한 밀봉 결함에 대해 보증을 제공하므로 제조사에 직접 문의하시기를 권장합니다. 주문 번호를 알려 주시면 브랜드 상세 정보를 드려 청구 절차에 도움이 되도록 하겠습니다.

정책의 정확한 경계 사례를 올바르게 적용했습니다. 35일은 30일 기간을 넘으므로 직접 반품을 거절하고 제조사 보증으로 안내했으며, 사과만 하고 여전히 환불을 제안하지는 않았습니다. 277개의 completion 토큰, finish_reason: "stop", 답변이 완전하고 잘리지 않았습니다. 위 카피 표와 동일한 모델, 동일한 계정, 동일한 medium effort입니다. 여기서 차이는 max_tokens: 400이 추론과 답변을 동시에 할 충분한 공간을 주었다는 점입니다.

모델 카드가 안 된다고 해도 시각 기능은 작동한다

실제로 검증한 또 하나의 의외의 사실이 있습니다. claude-opus-5-5의 모델 카드에는 Input modalities: text가 나열되어 있고 어디에도 이미지 입력에 대한 언급이 없습니다. 하지만 이미지를 보내도 여전히 작동합니다:

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 150,
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "In one sentence, what is in this photo?"},
        {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
      ]
    }]
  }'

실제 응답, 편집 없음(위에서 언급한 동일한 max_tokens 메커니즘으로 잘림. 150은 공간이 부족함):

회색 표면을 배경으로 남성용 데일리 액세서리를 가지런히 배열한 플랫레이 사진으로, 검은색 지퍼 지갑, 파일럿 선글라스, 트위드 보타이, 노트북이 포함되어 있습니다

사진을 정확히 읽었습니다. 모델 카드의 'text' 모달리티 표시는 이 라우트에 대해 틀렸거나 최소한 불완전합니다. 이는 claude-opus-4-8 문서가 시각 기능 주장에서 겪은 '카드와 현실이 불일치하는' 패턴과 같습니다. 게시된 모달리티 목록을 근거로 제한을 두는 파이프라인을 만들지 마세요. 위의 reasoning 파라미터처럼 실제 요청을 보내고 실제 응답을 읽으세요.

비용 설명

아홉 번의 실제 호출, 모두 단일 claude-opus-5-5 라우트로 청구됨(이 모델에는 -aws나 다른 가격 변형이 없으며, claude-opus-4-8과 다름). hiapi 가격 페이지의 백만 입력 토큰당 $2.02, 백만 출력 토큰당 $10.08 기준으로 계산:

호출	prompt_tokens	completion_tokens	비용
effort 표 × 5(minimal/low/medium/high/max)	650	2,495	$0.0264
xhigh 잘림 함정	185	500	$0.0054
빈 응답 함정	157	300	$0.0033
고객 응대 답변	3,590	277	$0.0100
시각 테스트	690	150	$0.0029
총계	5,272	3,722	$0.0482

여기에는 이미지 생성이 전혀 없습니다. claude-opus-5-5는 이미지를 생성하지 않으므로 위의 모든 달러는 토큰 비용이며, 두 개의 '함정' 행은 추가 예산을 배정할 가치가 있습니다. 잘리거나 완전히 빈 출력에 실제 비용을 지불했기 때문입니다.

자주 묻는 질문

claude-opus-5-5가 상품 이미지를 생성할 수 있나요? 아니요. 모델 카드에는 텍스트 전용 입력 및 출력 모달리티가 나열되어 있고, 위의 모든 응답은 텍스트입니다. 작업이 실제로 새로운 상품 사진을 생성하는 것이라면 이 모델이 아니라 이미지 생성 모델이 필요합니다.

더 높은 reasoning.effort가 더 비싼가요? 그 자체로는 아닙니다. 고정 max_tokens 아래에서 위 테스트의 다섯 가지 문서화된 등급은 완전히 동일한 수의 completion 토큰을 청구했습니다. effort는 글쓰기를 바꾸지, 토큰 수를 바꾸지 않습니다. 실제로 더 비싼 것은 max_tokens를 높여 더 높은 effort 등급이 추론과 답변을 동시에 할 공간을 주는 것입니다.

왜 오류 없이 빈 응답을 받았나요? max_tokens가 모델이 쓰기 전에 수행하는 내부 추론에 비해 너무 낮았습니다. 버그가 아닙니다. finish_reason에 "length"가 표시되고, 전체 토큰 수에 대해 여전히 비용을 지불하지만 content는 빈 값이나 잘린 값으로 반환될 수 있습니다. 호출이 200을 반환했는지만 확인하지 말고 항상 content가 비어 있지 않고 완전한지 확인하세요.

실제로 이미지 입력을 지원하나요? 지원합니다. 위의 요청에서 실제 이미지를 보내 정확한 설명을 얻어 확인했습니다. 모델 자체의 카드가 text를 유일한 입력 모달리티로 나열하고 있음에도 그렇습니다.

시작하기

직접 시도하려면 hiapi API 키, claude-opus-5-5 모델 페이지(현재 가격 및 전체 reasoning-effort 목록 확인), 그리고 동일한 전자상거래 카피 및 고객 응대 워크로드에 대해 순수 텍스트 모델을 비교하고 있다면 claude-opus-4-8 문서가 이전 세대 Opus에서 동일한 내용을 다루고 있습니다. 운영 파이프라인을 전환하기 전에 위의 max_tokens/reasoning 트레이드오프가 업그레이드할 가치가 있는지 확인해 볼 만합니다.