2026년 6월에 Anthropic의 새로운 플래그십 모델 Claude Fable 5가 일반 제공되었으며, Claude Code에서도 사용할 수 있게 되었습니다. 저도 약 1개월 동안 Fable 5를 메인으로 사용해 왔기에, 이 기사에서는 Fable 5를 중심으로,

• Fable 5란 어떤 모델인가
• 다른 모델(Opus 5 / Sonnet 5 / Haiku 4.5)과의 스펙 및 가격 비교
• 사용해 본 느낌을 바탕으로 한 장단점과 용도별 추천도

를 정리해 보겠습니다. 추천도나 활용법은 어디까지나 저 개인의 주관적·체감 기반입니다. 용도나 사용 방식이 다르면 느끼는 점도 크게 달라질 수 있으므로, "그런 관점도 있구나" 정도의 온도감으로 하나의 참고 자료 정도로 읽어주시면 감사하겠습니다.

먼저, 2026년 8월 시점의 현행 모델을 스펙으로 비교합니다(공식 문서 1에 의거). Opus는 7월 24일에 출시된 차세대 Claude Opus 5가 주력입니다2(이전 세대인 Opus 4.8도 동일한 가격으로 계속 제공되고 있습니다).

※ Sonnet 5는 2026년 8월 31일까지 $2 / $10의 도입 가격이 적용됩니다1.

대략적으로 말하면, 가격은 Haiku → Sonnet → Opus → Fable 순으로 단계적으로 올라가는 이미지입니다. Opus 5는 지식 컷오프(Knowledge Cutoff)가 2026년 5월로, 라인업 중 가장 최신이라는 점도 포인트입니다.

참고로, 저 자신은 Claude Code를 정액제 플랜(팀 플랜인 Team Premium)으로 사용하고 있으며, API 종량제 과금이 아닙니다. 위의 가격은 API 이용 시의 것이지만, 정액제 플랜에서도 상위 모델일수록 이용 한도를 더 빨리 소비하므로, "상위 모델일수록 비용이 더 많이 든다"는 감각 자체는 공통적일 것이라고 생각합니다. 이후의 비용에 관한 기술은 그 전제하에 읽어주시기 바랍니다.

스펙과 가격만으로는 차이를 알기 어려우므로, 기능 측면도 정리합니다13.

사고의 깊이는 effort 파라미터로 조정할 수 있습니다. low / medium / high / xhigh / max의 5단계로, Opus 5와 Sonnet 5의 기본값은 high입니다. 어려운 코딩 태스크는 xhigh로 올리고, 속도 우선의 정형화된 태스크는 low/medium으로 낮추는 등의 조정이 가능합니다. Claude Code를 사용하고 있는 경우에도 내부적으로 이 메커니즘으로 작동하고 있습니다.

fast mode는 이 중에서 Opus 5만의 기능입니다. 동일한 모델을 최대 2.5배의 출력 속도로 구동할 수 있는 모드로 (API 이용 시에는 요금 할증 및 연구 프리뷰(Research Preview)로 취급됩니다. Opus 5의 fast mode는 $10/$50), Claude Code에서는 /fast 명령어로 전환할 수 있습니다. "Fable 정도의 깊이는 필요 없지만, 어쨌든 템포 있게 진행하고 싶다"라고 느낄 때 유용합니다.

이미지 입력의 해상도에도 차이가 있습니다. Fable 5 / Opus 5 / Sonnet 5는 긴 변이 2576px까지의 고해상도 이미지에 대응하여, 스크린샷이나 도표의 판독 정밀도가 높아졌습니다. Haiku 4.5는 기존 해상도(긴 변 1568px)까지입니다.

2026년 6월에 일반 제공이 시작된, Claude 5 세대의 최상위 모델입니다. 지금까지 최상위였던 Opus의 그 상위 티어(Tier)로 위치하고 있습니다4. 주요 포인트는 다음과 같습니다.

• 장시간·고난도의 자율 에이전트(Autonomous Agent) 작업을 주안점으로 둔 모델로, 사고(Thinking) 기능이 상시 켜져 있습니다.
• 듀얼 유즈(Dual-use) 영역(사이버 보안·생물학 등)에는 추가적인 안전 대책이 적용되어 있으며, 해당 요청은 안전 분류기(Safety Classifier)에 의해 거부되거나 Opus 4.8로 폴백(Fallback)되어 처리되도록 설계되었습니다.
• Claude API 외에도 AWS, Google Cloud, Microsoft Foundry의 각 클라우드에서도 제공되며, Claude Code에서도 모델로 선택할 수 있습니다.

정액제 플랜에서의 제공 상황은 7월에 여러 차례 변동을 겪은 끝에 결정되었습니다. 당초에는 7월 12일까지 각 플랜에 추가 요금 없이 포함되었으나(주간 이용 한도의 50%까지), 7월 13일~19일에는 선불 이용 크레딧을 통해서만 이용 가능한 상태로 잠시 후퇴했습니다. 그 후 7월 20일부터 Max 플랜과 Team Premium 플랜에는 영구적으로 포함되기로 했습니다(마찬가지로 주간 이용 한도의 50%까지). Pro 플랜과 Team Standard 플랜은 계속해서 이용 크레딧을 통해 사용하며, 전환 시 일괄적으로 $100 상당의 크레딧이 배포되었습니다56. Anthropic 측은 "Fable의 수요 예측이 어려워, 용량(Capacity)을 확보하면서 단계적으로 전개했다"라고 설명하고 있으며, 제공 형태는 다시 바뀔 가능성도 있으므로 최신 상황은 공식 도움말을 확인하시기 바랍니다.

저는 코딩 외에도 버그 조사·디버깅 용도로 사용하고 있지만, 안전 대책에 걸린 적은 현재까지 없습니다. 일반적인 개발 용도라면 "Fable 5 = 현시점의 최상위 모델"이라고 생각해도 무방할 것 같습니다.

여기서부터는 각 모델의 장단점과 저의 주관적인 추천도입니다. 주로 Claude Code를 이용한 코딩과 버그 조사·디버깅 같은 태스크에서의 체감을 바탕으로 하고 있으므로, 프론트엔드 중심의 개발이나 문장 생성이 메인인 분들이라면 또 다른 평가가 될 수도 있습니다.

추천도: ★★★★☆ (지능만 따지면 나무랄 데 없는 ★5. 대기 시간과 이용 한도 소모를 허용할 수 있는지에 따라 평가가 달라집니다)

장점

• 장시간의 자율 태스크에 매우 강합니다. 규모가 큰 리팩터링(Refactoring)이나 조사를 맡겼을 때, 중간에 길을 잃지 않고 끝까지 완수해 내는 느낌이 있습니다.
• 계획과 자기 검증(Self-verification)이 철저합니다. 손을 움직이기 전에 상황을 파악하고, 마친 뒤에 스스로 확인하는 동작이 자연스럽게 들어가기 때문에, "다 했다고 생각했는데 사실은 망가져 있는" 패턴이 줄어든 느낌입니다.
• 버그 조사에 강합니다. 로그나 코드, 커밋 히스토리(Commit History)를 폭넓게 추적하여, 표면적인 증상에서 근본 원인까지 파고드는 느낌이 있습니다. "고쳤다"라고 끝내지 않고, 재현 조건까지 확인해 주는 경우가 많습니다.
• 모호한 지시에 대한 대응이 능숙합니다. 세세한 절차를 적지 않아도 목적과 목표만 전달하면 의도를 파악해 주는 경우가 많습니다.
• 진행 보고나 최종 요약 문장이 읽기 쉬워졌다고 느낍니다.

단점

• 응답이 느립니다. 공식 문서에서도 타 모델보다 "Slower"라고 명시되어 있으며, 어려운 태스크의 경우 한 턴(Turn)에 몇 분에서 십수 분이 걸리는 일도 흔합니다. effort를 낮추거나 지시를工夫(고안)하면 가벼운 질문에도 충분히 사용할 수 있지만, 사고(Thinking)를 완전히 끌 수는 없기 때문에 템포를 최우선으로 하는 상황에서는 하위 모델이 더 쾌적하다고 느껴집니다.
• 가격이 Opus의 2배($10 / $50)입니다. API 이용 시 상시 사용하기에는 비용 부담이 크고, 정액제 플랜에서도 이용 한도 소모가 빠릅니다.
• API 사양에 특징이 있습니다 (후술).

적합하다고 생각하는 용도: 던져두고 다른 작업을 하는 동안 진행하게 하는 긴 자율 작업, 대규모 리팩터링, 난이도 높은 디버깅, 사양이 모호한 상태에서의 설계

추천도: ★★★★★ (일상적인 코딩의 주력으로)

7월 24일에 출시된 Opus의 차세대 모델입니다27. 이전 세대인 Opus 4.8과 동일한 가격($5 / $25)의 드롭인 (drop-in) 후속 모델로, 포지셔닝은 "많은 태스크에서 Fable에 가까운 성능을 절반 가격으로"입니다. 한 가지 덧붙이자면, 제가 Opus 라인업을 주력으로 사용해 온 기간의 대부분은 이전 세대인 Opus 4.8이었으며, Opus 5는 이제 막 사용하기 시작했습니다. 다만 동일한 가격의 후속 모델이기에 갈아타지 않을 이유가 없으므로, 아래의 체감 내용은 Opus 라인업(주로 4.8, 일부 5)을 기준으로 작성했음을 참고해 주세요.

장점

• 지능·속도·가격의 밸런스가 좋아, 일상적인 코딩 태스크의 대부분은 이것으로 충분하다고 느낍니다. 저 자신도 Fable과 이 두 모델을 양대 축으로 활용하고 있습니다.
• 장시간의 에이전트 (agent) 작업이나 코드 리뷰·디버깅에 강합니다.
• 지식 컷오프 (knowledge cutoff)가 2026년 5월로, Fable을 포함한 현행 라인업 중 가장 최신입니다.
• Fable과 달리 fast mode (응답 속도를 높이는 모드)도 지원합니다.

단점

• 최난도 태스크에서는 Fable 5와의 차이를 느끼는 경우가 있습니다 (애초에 그런 태스크가 일상에 얼마나 있느냐의 문제이기도 합니다).
• Sonnet 5의 성능이 올라오면서, "Opus가 아니면 곤란한" 상황은 이전보다 줄어들었다는 인상입니다.
• Opus 5 세대부터 Fable과 마찬가지로 사이버 보안 안전 대책 (refusal)이 적용되었기 때문에, 보안 관련 작업에서는 드물게 거부(refusal)가 발생할 가능성이 있습니다.

적합한 용도: 일상적인 코딩 전반, 에이전트 방식의 다단계 작업, 고민될 때의 기본값

추천도: ★★★★☆ (비용 의식이 있다면 ★5도 괜찮을 정도)

장점

• 코딩·에이전트 용도로 "이전 세대의 Opus 클래스"에 가까운 품질을 Opus 가격의 60% 정도로 사용할 수 있습니다.
• 응답이 빠르기 때문에 대화하며 진행하는 작업에서 스트레스가 적습니다.
• API 이용 시, 2026년 8월 말까지는 도입 가격($2 / $10)으로 더욱 저렴하게 사용할 수 있습니다.
• 컨텍스트 (context) 1M · 최대 출력 128K로 스펙은 Opus/Fable과 동등합니다.

단점

• 최난도 추론·설계 태스크에서는 상위 모델과의 차이가 나타날 수 있습니다.
• 지시 사항을 상당히 문자 그대로 해석하는 경향이 있어, 프롬프트 (prompt) 작성이 허술하면 의도와 어긋날 수 있습니다.

적합한 용도: 일상적인 코딩, 비용 중시형 API 임베딩, 응답 속도가 중요한 대화형 작업

추천도: ★★★☆☆ (용도에 맞으면 ★5)

장점

• 압도적으로 빠르고 저렴합니다 ($1 / $5). 분류·추출·요약과 같은 정형 태스크를 대량으로 돌린다면 제1순위 후보가 됩니다.
• 서브 에이전트 (sub-agent)로 사용하면 상위 모델의 비용을 억제하면서 병렬 작업을 수행할 수 있습니다.

단점

• 컨텍스트가 200K로 타 모델보다 좁고, 지식 컷오프도 2025년 2월로 다소 오래되었습니다.
• 복잡한 추론이나 거대한 코드베이스의 이해에는 취약합니다. 메인 코딩 모델로 쓰기에는 부족함을 느낄 것입니다.

적합한 용도: 대량 배치 처리 (batch processing), 분류·추출, 서브 에이전트, 레이턴시 (latency) 최우선 채팅

Fable 5를 사용하면서 "이것은 이전 모델과 질이 다르다"라고 느끼는 포인트를 조금 더 깊이 파고들어 보겠습니다. 공식 소개43에서도 Fable 5의 발전은 "지금까지의 모델로도 가능했던 태스크"보다는 "지금까지는 할 수 없었던 업무"에 치중되어 있다고 설명하고 있는데, 이는 실제 체감과도 잘 일치합니다. 기존 모델과 똑같은 방식으로만 평가한다면, 지능에 비해 차이를 느끼기 어려운 모델일 수 있습니다.

1. 원인 불명의 버그를 끝까지 파헤치기

공식에서도 코드 리뷰·디버깅 및 리포지토리 (repository) 이력 탐색이 강화된 점으로 꼽고 있습니다. 체감상 큰 부분은 증상만 전달해도 로그(log) → 코드 → 커밋 이력 순으로 증거를 쌓아가며 가설을 좁혀 나간다는 점입니다. "아마 여기가 원인일 것입니다"에서 멈추지 않고, 근본 원인과 발생 조건까지 특정하여 설명해 주는 경우가 많아 조사 결과의 신뢰도가 높아졌습니다.

2. 긴 여정을 사람의 수정 없이 완주하기

공식에서 가장 큰 강화점으로 꼽는 것이 "장거리 에이전트 실행"입니다. 규모가 큰 리팩터링이나 구현, 범위가 넓어지기 쉬운 조사 작업에서도 도중에 당초의 목적을 잃어버리거나 어중간한 결론으로 마무리하는 경우가 줄어들었다는 느낌을 받습니다. "처음에 사양과 완료 조건을 전달하고 나머지는 맡긴다"라는 방식이 현실적으로 가능해졌습니다.

3. 서브 에이전트를 병렬로 능숙하게 다루기

여러 서브 에이전트 (Sub-agent)에게 업무를 배분하고, 실행되는 동안에도 자신의 작업을 진행하며 결과를 통합하는 움직임이 안정적입니다. 공식적으로도 장시간 작동하는 서브 에이전트와의 지속적인 상호작용을 유지할 수 있다는 점이 강점으로 언급됩니다. 구현 시 여러 파일의 수정을 병행시키거나, 버그 조사 시 로그·코드·변경 이력을 각기 다른 관점에서 병렬로 조사하게 하는 등의 사용법에서 차이를 느끼기 쉽습니다.

4. 학습 내용을 메모로 남기며 작업하기

파일에 메모 (Memory)를 남겨두고 이후 작업에서 이를 참조하는 능력이 뛰어납니다. 공식적으로도 "학습 내용을 기록할 수 있는 장소를 제공하면 성능이 현저히 향상된다"라고 명시되어 있습니다. 날짜를 넘기는 작업이나 긴 세션에서도 이전까지 파악한 내용을 바탕으로 움직여주기 때문에, 같은 내용을 두 번 설명하거나 다시 조사하는 낭비가 발생하기 어렵습니다.

5. '절차'가 아닌 '목표'를 전달하기

Fable 5로 바꾸면서 가장 변한 점은 요청 방식일지도 모릅니다. 이전에는 절차를 상세하게 적을수록 정밀도가 올라가는 느낌이었지만, Fable 5에서는 반대로 목표(Goal)·제약 사항·완료 조건만 전달하고 진행 방식은 맡기는 편이 더 좋은 결과를 가져오는 경우가 많습니다. 사실 이는 공식 마이그레이션 가이드에도 "이전 세대 모델을 위해 상세하게 작성된 지시는 오히려 출력 품질을 떨어뜨리는 경우가 많다"라고 명시되어 있습니다3.

이미지로 표현하자면 다음과 같은 차이입니다 (소재는 가상의 예시입니다).

【이전의 요청 방식: 절차를 지정】
UserList.tsx의 fetchUsers에서 null 체크를 추가하고,
그다음 API 호출을 try-catch로 감싸고,
...

전자의 요청 방식은 지시한 범위 내의 일만 수행하지만, 후자라면 원인 조사부터 수정 방침 선택, 검증까지 스스로 구성해 나갑니다. 요구사항이 완전히 확정되지 않은 상담 단계부터 시작하더라도 문제를 정리한 뒤 움직여주기 때문에, "요청하기 전에 사양을 확정해야 한다"라는 사전 준비의 부담이 줄어들었습니다.

좋은 이야기만 하면 공정하지 않으므로, 전환하며 당혹스러웠던 점도 적어두겠습니다.

대기 시간의 감각이 달라집니다. 몇 분 단위로 고민하는 것이 보통이라 화면 앞에서 기다리고 있으면 상당히 길게 느껴집니다. "던져두고 다른 작업을 하다가, 끝날 때쯤 결과를 확인한다"라는 스타일로 바꾼 뒤 쾌적해졌습니다. 화면에 붙어서 대화하는 모델이 아니라고 단정 짓는 것이 요령이라고 생각합니다 -
정액제 플랜의 이용 한도를 소비하기 쉽습니다. 팀 플랜에서도 Fable 5로 긴 태스크를 돌리면 한도가 줄어드는 것이 체감상 빠릅니다. 한도 잔량을 확인하며 Fable과 Opus를 오가는 운용 방식을 택하게 되었습니다 -
이전 모델용 프롬프트 자산이 역효과를 낼 수 있습니다. 절차를 상세하게 적은 지시 템플릿을 그대로 사용하면, 지시에 너무 충실한 나머지 오히려 유연성이 상실되는 장면이 있었습니다. 위의 "~ならでは(특징)"에서 쓴 것처럼, 목표 기반(Goal-based)으로 다시 작성하는 것이 결과가 더 좋았습니다 -
가끔 묻지 않아도 될 것을 확인하러 옵니다. 맡기고 싶은데 사소한 확인 때문에 작업이 멈출 때가 있습니다. 처음에 "자율적으로 진행하되, 파괴적인 작업만 확인해줘"라고 전달해두면 줄어들었습니다

Fable 5를 API로 사용할 경우, Opus 계열과 같은 감각으로 호출하면 빠지기 쉬운 함정이 있습니다3. Claude Code를 경유한다면 의식할 필요가 없는 내용이므로, API 임베딩을 고려하는 분들을 위해 요점만 정리합니다.

thinking은 상시 On. thinking: {type: "disabled"}나 budget_tokens는 400 에러를 발생시킵니다. 깊이는 output_config.effort (low~max)로 조정합니다 -
사고 내용은 기본적으로 보이지 않습니다. 응답에 사고 블록(Thinking block)은 포함되지만, 텍스트는 기본적으로 비어 있습니다. display: "summarized"를 지정하면 요약본이 들어갑니다. 참고로 가공되지 않은 생(raw) 사고 과정은 어떻게 설정해도 반환되지 않습니다 -
출력의 랜덤성을 조정하는 요청을 포함하면 400 에러가 됩니다 (Opus 4.7 이후 모델 공통). 출력에 변주를 주고 싶다면 프롬프트로 지시해야 하며, temperature / top_p / top_k는 보낼 수 없습니다. -
거절(Refusal)은 에러가 아니라 정상 응답으로 반환됩니다. 안전 분류기(Safety classifier)가 요청을 거절하더라도 HTTP 200이며, stop_reason이 "refusal"이고 content가 비어 있는 응답이 반환됩니다. "200이면 성공"이라고 가정하고 content를 읽는 코드는 여기서 망가지므로, 먼저 stop_reason을 체크해야 합니다. fallbacks

파라미터(Beta)를 붙이면, 거부(refusal) 시 동일한 요청을 Opus 4.8로 자동 재실행해 줍니다 -
30일간의 데이터 보존이 필수입니다. 제로 데이터 리텐션(Zero Data Retention) 설정이 된 조직에서는 모든 요청이 400 -
1턴이 길다는 전제로 설계되었습니다. 타임아웃은 길게 설정하고, 스트리밍(Streaming)을 권장합니다.

또한, Opus 4.7에서 도입된 새로운 토크나이저(Tokenizer) (Fable 5 / Opus 5 / Sonnet 5도 동일한 것)에서는 동일한 텍스트라도 구세대보다 약 30% 더 많은 토큰을 소비합니다¹. 토큰 수 추정이나 max_tokens 설정은 구모델 기준으로 유용하지 않으므로, 이관 시점에 다시 측정하는 것이 안전합니다.

나름의使い分け(용도별 구분)를 플로우차트로 나타내면 다음과 같은 느낌으로 정리됩니다.

표로 정리하면 다음과 같습니다.

사용 구분표만으로는 추상적이므로, 저의 실제 운용 방식을 적어두겠습니다. 솔직히 말하면 "어려운 문제일 때만 Fable"이라기보다, 이용 한도에 여유가 있을 때는 처음부터 Fable 5에게 해결까지 맡기는 경우가 많습니다. 전환 판단은 태스크의 난이도보다 남은 한도에 의해 결정되는 느낌입니다. 참고로, 정액제 플랜의 이용 한도는 "5시간마다 리셋되는 할당량"과 "주간 할당량"의 이중 구조로 되어 있으며, 매일 전환을 판단할 때 주로 보는 것은 5시간 할당량 쪽입니다.

• 한도에 여유가 있다 → 처음부터 Fable 5. 버그 조사도 구현도, 도중에 모델을 바꾸지 않고 끝까지 맡깁니다.
• 남은 한도가 불안하다 → Opus 5로. 일상적인 태스크라면 이것으로 곤란할 일은 거의 없습니다.
• 템포 있게 대화하며 진행하고 싶은 가벼운 작업 → Opus 5 (/fast로 가속화도 가능합니다).

처음에는 "결정적인 순간에만 Fable"을 쓸 생각이었지만, 맡겼을 때의 완주율이 높아서 결국 "여유가 있을 때는 Fable First"로 정착했습니다. 대기 시간과 한도 소비만 허용된다면, 맡길 수 있는 업무의 상한선이 한 단계 올라간 기분이 듭니다.

"Fable First"라고 썼지만, 실제로 어느 정도 Fable에 치우쳐 있는지 수중에 있는 Claude Code 사용 로그(2026년 7월분)를 집계해 보았습니다.

• 7월 출력 토큰(사고 토큰 포함)의 모델별 비율: Fable 5가 약 65%, 나머지는 주로 Opus 계열(당시 주력은 전 세대인 Opus 4.8)
• Fable 5의 세션 수: 48 세션 (가동 16일)
• Fable 5의 1세션당 출력 토큰: 중앙값 약 19만, 최대 약 117만

감각뿐만 아니라 수치로도, 여유가 있을 때는 Fable을 사용하는 운용 방식이 그대로 정착되어 있었습니다. 특히 "1세션에서 출력 100만 토큰 초과"는 Fable 이전의 사용법으로는 거의 나오지 않던 수치로, 긴 호흡의 작업을 통째로 맡기는 스타일로 변했다는 것이 로그에도 나타나 있습니다. 다만, 이는 저의 사용 방식(조사와 수정을 한꺼번에 맡기는 경우가 많음)에서의 수치이므로, 대화 중심의 사용법이라면 비율이 상당히 달라질 것입니다.

• Fable 5는 Opus보다 상위 티어에 위치한 현시점의 최상위 모델입니다.
• Fable 5는 "느리지만 깊게 생각하며 끝까지 완수하는" 모델로, 장시간·고난도 태스크에 적합합니다.
• 정액제 플랜에서의 Fable 5 제공은 7월에 여러 차례 변동이 있었으나, 7월 20일부터 Max / Team Premium 플랜에 대한 영구 제공으로 결정되었습니다.
• 일상적인 사용은 Opus 5, 가성비 중시는 Sonnet 5, 정형화된 대량 처리는 Haiku 4.5와 같이 역할 분담이 확실해진 인상입니다.
• 운용은 "이용 한도에 여유가 있을 때는 Fable First, 남은 한도가 빠듯할 때는 Opus"로 정착되었습니다. 실제로 7월 저의 출력 토큰 중 약 65%는 Fable 5였습니다. 성능에 불만이 있어서 Opus로 돌아가는 것이 아니라, 순수하게 한도의 사정 때문입니다. 역으로 말하면, 한도가 허락한다면 항상 Fable을 선택하고 싶을 정도로, 맡겼을 때의 똑똑함은 한 차원 앞서 있다고 느낍니다.
• Fable 5를 API로 사용할 경우, thinking 상시 On, 샘플링 파라미터 폐지, refusal 핸들링 등 사양의 차이에 주의해야 합니다.

반복해서 말씀드리지만, 여기에 적은 평가는 어디까지나 저의 용도와 사용 방식에서의 체감입니다. 모델 선택은 용도, 예산, 취향에 따라 최적해가 달라지므로, 이 글은 하나의 참고 정도로만 보시고 꼭 본인의 사용법으로 직접 만져보고 비교해 보시기 바랍니다.