오답 제거하기
안티 패턴은 대개 오답 선택지입니다. 이를 알아보는 법을 익힙니다
오답 제거하기은(는) CoddyKit의 무료 Claude Architect 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Claude Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
The Distractor Is Usually an Anti-Pattern
On the Claude Certified Architect exam, every question gives you 4 options and exactly 1 is correct. The other 3 are distractors — and they are not random. They are engineered to look reasonable to someone who half-knows the material.
Here is the single most useful insight for this lesson: distractors are very often well-known anti-patterns dressed up as solutions. If you can recognize the anti-pattern catalog on sight, you can eliminate 2-3 options before you even finish reading them.
Elimination is leverage. With no penalty for guessing, killing two wrong answers turns a 25% guess into a 50% one — and usually leaves the correct answer obvious.
Build a Mental Anti-Pattern Catalog
Before you can eliminate, you need a list of red flags memorized cold. These are the recurring wrong answers across all 8 exam scenarios:
- Parsing text for completion signals ("stop when the reply contains 'done'")
- Arbitrary iteration caps as the primary stop mechanism
- Minimal/ambiguous tool descriptions or too many tools per agent
- Generic error statuses ("Operation failed")
- Enforcing critical business rules with prompts alone
- Single-pass multi-file review and same-session self-review
- Batch API for blocking/time-sensitive checks
- Sentiment/confidence-based escalation
- Requiring possibly-absent schema fields
- Silent error suppression and aggregate-only accuracy metrics
When an option matches one of these, it is almost certainly the wrong answer. Treat the list as a tripwire.
Red Flag: Parsing Text to Stop the Loop
The agentic loop terminates on stop_reason — never by scanning the model's text for words like "done" or "finished". Any option that loops while a string is in the output is an anti-pattern distractor.
The correct mechanism: send the full history each turn, inspect stop_reason, run tools on tool_use, and stop on end_turn.
# ANTI-PATTERN (a distractor you should eliminate):
while "done" not in response.content[0].text.lower():
response = client.messages.create(...)
# CORRECT: terminate on the structured stop_reason
while response.stop_reason == "tool_use":
tool_results = run_tools(response.content)
messages.append({"role": "user", "content": tool_results})
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=messages,
tools=tools,
)
# loop exits when stop_reason == "end_turn"Red Flag: Iteration Caps as the Primary Stop
A close cousin of the previous trap. An iteration cap ("stop after 10 turns") is a legitimate safety net — but it is never the primary stop mechanism. Decisions are model-driven; you reserve hard-coded limits for guarantees, not for control flow.
So when two options both mention a loop cap, read carefully: the wrong one makes the cap the main exit condition. The right one stops on end_turn and keeps the cap purely as a runaway guard.
MAX_TURNS = 25 # safety net ONLY — not how we normally stop
turns = 0
while response.stop_reason == "tool_use":
if turns >= MAX_TURNS:
raise RuntimeError("runaway loop guard tripped") # rare escape hatch
turns += 1
messages.append({"role": "user", "content": run_tools(response.content)})
response = client.messages.create(model="claude-sonnet-4-5",
max_tokens=1024, messages=messages, tools=tools)
# normal, expected exit: stop_reason == "end_turn"Red Flag: Prompts for Critical Business Rules
When a question involves money, legal, or safety consequences (refund limits, policy violations), an option that says "instruct the model in the system prompt to never refund over $500" is a distractor. Prompts are ~90% probabilistic. Hooks are 100% deterministic.
The correct answer enforces the rule with a PostToolUse / outgoing-call hook or a programmatic precondition — code the model cannot talk its way around.
# Distractor: "Add 'never refund more than $500' to the system prompt."
# Correct: deterministic enforcement outside the model.
def on_pre_tool_use(tool_name, tool_input):
if tool_name == "process_refund" and tool_input["amount"] > 500:
return {"block": True,
"reason": "Refunds over $500 require human approval."}
# precondition: identity must be verified first
if tool_name == "process_refund" and not customer_verified():
return {"block": True, "reason": "Verify customer identity first."}
return {"block": False}Red Flag: Bad Tool Design
Two tool-design distractors show up constantly in Scenario 4 and 8 questions:
- "Improve selection by renaming the tools" — wrong. Tool descriptions, not names, are the primary selection mechanism.
- "Give the agent all 18 tools so it never lacks one" — wrong. 4-5 tools per agent is optimal; 18+ degrades selection reliability.
The correct answers: write rich descriptions (purpose, return values, input formats with examples, edge cases, boundaries) and scope tools tightly to the role with least privilege.
# Correct: a description that actually drives selection.
lookup_order = {
"name": "lookup_order",
"description": (
"Retrieve a customer's order by order_id. "
"Returns status, line items, and total. "
"order_id format: 'ORD-' + 8 digits, e.g. 'ORD-10293847'. "
"Use AFTER get_customer verifies identity. "
"Returns an empty result (not an error) if no order matches."
),
"input_schema": {"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"]},
}Red Flag: Generic Errors & Silent Suppression
In multi-agent and extraction scenarios, watch for two error anti-patterns:
- Returning
"Operation failed"— a generic status that blocks intelligent recovery. - Silently swallowing a failure, or aborting the whole workflow because one subagent failed.
The correct answer returns structured errors: isError, errorCategory (transient/validation/business/permission), isRetryable, the attempted query, and partial results. It also distinguishes an access failure (maybe retry) from a valid empty result (no matches — don't retry).
# Distractor: return {"status": "Operation failed"}
# Correct: structured, routable error
error = {
"isError": True,
"errorCategory": "transient", # vs validation/business/permission
"isRetryable": True,
"message": "Upstream timeout from inventory service",
"attempted_query": "SELECT * FROM stock WHERE sku='A91'",
"partial_results": [{"sku": "A91", "warehouse": "EU"}],
}Red Flag: Same-Session & Single-Pass Review
For code-review and CI/CD scenarios (Scenario 2 and 5), eliminate any option that reviews in the same session that generated the code — the author keeps its own reasoning and won't challenge itself. An independent, fresh-instance review is always stronger.
Also eliminate single-pass multi-file review: it dilutes attention. The correct multi-pass approach does a per-file local pass, then a separate cross-file integration pass.
# Distractor: same chat asks itself "now review what you wrote."
# Correct (CI/CD): isolated, non-interactive review session.
# claude -p "Review this diff for correctness bugs only." \
# --output-format json \
# --append-system-prompt "Flag an issue ONLY when code contradicts intent."
#
# Multi-pass: pass 1 per-file, pass 2 cross-file integration —
# never one single pass across all files at once.Red Flag: Batch API for Blocking Checks
The Message Batches API is 50% cheaper with up to a 24-hour window — but it has no latency SLA and does not support multi-turn tool calling. So any option that uses Batch for a pre-merge gate, a synchronous user-facing check, or an agentic tool loop is a distractor.
Batch is correct only for non-blocking jobs: overnight audits, bulk reports. If the scenario word is "blocking", "pre-merge", "real-time", or "the user is waiting" — eliminate Batch immediately.
# Correct use of Batch: overnight, non-blocking audit.
batch = client.messages.batches.create(requests=[
{"custom_id": "doc-001", # custom_id correlates each result
"params": {"model": "claude-sonnet-4-5", "max_tokens": 1024,
"messages": [{"role": "user", "content": audit_prompt(d)}]}}
for d in nightly_documents
])
# WRONG: using this for a pre-merge CI gate (no latency SLA, no tool loop).Red Flag: Bad Escalation & Bad Schemas
Two more high-frequency distractors:
- Escalation triggered by sentiment analysis or a model self-rated confidence score (1-10). These are bad triggers. Good triggers: explicit human request, policy gaps, no progress after attempts, threshold violations.
- Marking a possibly-absent field as
requiredin a JSON schema. The model will fabricate it. Require a field ONLY if it is always present; use enums with an "other" value plus a free-text detail for extensibility.
If an option escalates on "angry tone" or requires "middle_name" — eliminate it.
# Distractor schema: requires a field that's often missing.
# Correct: only truly-always-present fields are required.
schema = {
"type": "object",
"properties": {
"invoice_id": {"type": "string"},
"category": {"type": "string",
"enum": ["goods", "services", "other"]},
"category_detail": {"type": "string"}, # free-text, NOT required
"po_number": {"type": "string"}, # may be absent -> NOT required
},
"required": ["invoice_id", "category"],
}The Elimination Drill
Put it together into a repeatable process for every question:
- 1. Read the scenario for the real constraint — money/legal (needs a hook), blocking vs overnight (Batch or not), single vs multi-file (passes), present vs absent field (required or not).
- 2. Scan all 4 options for anti-pattern tripwires and strike every match. Usually 2-3 fall away.
- 3. Among survivors, pick the one with a deterministic guarantee where it matters — structured over generic, model-driven stop over text parsing, independent over self-review.
- 4. Always answer. No penalty for guessing — never leave a blank, even when you're down to a coin flip.
Anti-pattern recognition isn't a shortcut around understanding; it's how an experienced architect reads a question fast and clean.
Quick Check
Apply the elimination drill to a real exam-style scenario.
Recap: Read the Constraint, Strike the Anti-Pattern
Key takeaways for eliminating wrong answers:
- Distractors are usually anti-patterns in disguise. Memorize the catalog and treat each one as a tripwire.
- Eliminate on sight: text-parsing to stop, iteration caps as the primary stop, prompts for critical rules, generic/suppressed errors, too many tools, name-based tool selection, single-pass and same-session review, Batch for blocking checks, sentiment/confidence escalation, requiring absent fields.
- The right answer favors deterministic guarantees where stakes are high: hooks and preconditions, structured errors, model-driven termination on
end_turn, independent review, rich tool descriptions. - Always answer — no guessing penalty. Strike two distractors and a coin flip becomes a strong bet.
Recognize the trap, and the correct option practically selects itself.
자주 묻는 질문
“오답 제거하기” 강의는 무료인가요?
네 — “오답 제거하기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Claude Architect 강의 전체를 잠금 해제할 수 있습니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.
“오답 제거하기”에서 뭘 배우나요?
안티 패턴은 대개 오답 선택지입니다. 이를 알아보는 법을 익힙니다 브라우저에서 직접 실행하는 실습 코드로 Claude Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Claude Architect을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Claude Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.
“오답 제거하기” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Claude Architect 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Claude Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.