Claude Architect · 강의

결정적 강제 적용과 프롬프트

훅은 100% 확실하지만 프롬프트의 성공 확률은 약 90%입니다

결정적 강제 적용과 프롬프트은(는) CoddyKit의 무료 Claude Architect 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Claude Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Two Ways to Enforce a Rule

When you need an agent to always follow a rule, you have two fundamentally different tools.

Prompts ask the model to behave a certain way. The model usually complies — but it's still a probabilistic system making a judgment call.
Hooks are deterministic code that runs around tool calls. They don't ask — they enforce.

This lesson teaches the single most important number in workflow enforcement: a well-written prompt gives you roughly ~90% compliance; a hook gives you 100%.

Prompts Are Probabilistic

A system prompt is guidance. Even an excellent one — explicit criteria, few-shot examples — steers the model toward the right behavior but never guarantees it.

Across thousands of requests, that residual ~10% surfaces: an edge case, an unusual phrasing, a long context where the rule sits in the lost-in-the-middle zone. The model generalizes from your instructions, which is exactly why it can also generalize wrong.

For most behaviors that's fine. For rules where a single violation is unacceptable, ~90% is a liability.

system = (
    "You are a refund agent. "
    "NEVER issue a refund above $500 without manager approval."
)
# This is guidance. The model will *usually* obey —
# but 'usually' is not 'always'. There is no code path
# that physically blocks a $501 refund.

Hooks Are Deterministic

A hook is ordinary code wired into the agent lifecycle. It runs every time, evaluates a condition the same way every time, and its decision does not depend on model reasoning.

PostToolUse hooks intercept a tool's result before the model ever sees it.
Outgoing-call hooks block policy-violating actions before they execute.

Because the logic is hard-coded, the guarantee is absolute: 100% deterministic enforcement. A blocked action is blocked — no matter what the model decides.

def block_large_refund(tool_name, tool_input):
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {"allow": False,
                "reason": "Refunds over $500 require manager approval"}
    return {"allow": True}
# Runs on EVERY process_refund call. $501 is blocked, every time.

The Decision Rule

Here is the rule to memorize for the exam and for real architecture:

Use hooks when failure has financial, legal, or safety consequences.

If a single violation costs money, breaks the law, or endangers someone, ~90% is not acceptable — you need 100%. That is a hook's job. Prompts are for guidance, tone, preference, and the countless soft behaviors where an occasional miss is recoverable.

Don't enforce a critical business rule with prompts alone. That is one of the most common wrong answers on scenario questions.

Programmatic Preconditions

The same deterministic principle applies to preconditions — rules about what must happen before an action is allowed.

Example from the Customer Support scenario: never run process_refund until get_customer has returned a verified customer ID. You could write that as a prompt instruction... or you could enforce it in code so it physically cannot be skipped.

A programmatic precondition gives a deterministic guarantee that prompt guidance cannot. The identity check happens 100% of the time, not 90%.

def require_verified_identity(tool_name, tool_input, state):
    if tool_name == "process_refund" and not state.get("verified_customer_id"):
        return {"allow": False,
                "reason": "Block refund until get_customer returns a verified ID"}
    return {"allow": True}

Why Not Just Prompt Harder?

A tempting trap: "I'll write a really strong prompt — all caps, repeated three times, with examples." This improves compliance, but it does not change the category. You are still on the probabilistic side of the line.

Few-shot examples and explicit criteria are powerful — they raise quality, reduce hallucination, and lock in output format. But they raise the ceiling of ~90%; they never reach the deterministic 100% that financial, legal, and safety rules demand.

If the requirement is a guarantee, no amount of prompt engineering substitutes for code.

Hooks Don't Replace Model Decisions

Important balance: hooks are not a license to hard-code everything. The agentic loop is model-driven — the model decides which tools to call and when, based on stop reasons.

You reserve hard code for guarantees, not for routine decision-making. Think of it as a thin, deterministic safety boundary around an intelligent, flexible core.

The same wisdom appears with iteration caps: a cap is a safety net, never the primary stop mechanism. Terminate on stop_reason, and use deterministic code only where a hard guarantee is genuinely required.

PostToolUse: Guarding Inputs to the Model

A PostToolUse hook intercepts a tool result before the model sees it. This is more than blocking — it's a deterministic checkpoint on data flowing back into the conversation.

Use it to enforce things like: redact secrets from output, validate that a required field is present, or refuse to surface a result that violates policy. Because it runs deterministically on every result, the model never even gets a chance to mishandle data you've decided it must not see raw.

def post_tool_use(tool_name, result):
    if tool_name == "lookup_order":
        # Deterministically strip PII before the model sees it
        result.pop("raw_credit_card", None)
    return result

Outgoing-Call Hooks: Guarding Actions

The mirror image of PostToolUse is the outgoing-call hook: it sits between the model's decision to act and the action actually firing.

This is where you block policy-violating actions — the refund over $500, the email to an unapproved domain, the deletion of a protected resource. The model may request the action; the hook decides whether it executes.

This separation is the architecture: the model proposes, deterministic code disposes — but only for the small set of rules that truly require a guarantee.

def on_outgoing_call(action):
    if action.type == "refund" and action.amount > 500:
        raise PolicyViolation("Refund exceeds $500 ceiling")
    if action.type == "refund" and not action.customer_verified:
        raise PolicyViolation("Customer identity not verified")

Reading the Signal in a Scenario

Exam scenarios telegraph the answer with their wording. Train yourself to spot it:

Words like "must never," "financial," "compliance," "safety," "regulatory," or a hard dollar threshold → the answer involves a hook / deterministic enforcement.
Words like "prefer," "tone," "style," "usually," "when appropriate" → a prompt is fine.

If an option proposes enforcing a hard, costly rule with "a stronger system prompt," it is almost certainly a distractor.

Combine Both Layers

The strongest designs use both. The prompt makes the model want to do the right thing 90% of the time — fewer blocked attempts, smoother conversations, better UX. The hook catches the remaining 10% with a hard guarantee.

Prompt for good default behavior; hook for the non-negotiable boundary. You get a system that is both intelligent and provably safe — guidance for the common case, deterministic enforcement for the catastrophic one.

# Layer 1 (prompt, ~90%): set the right default behavior
system = "Confirm customer identity before any refund, and keep refunds under $500."

# Layer 2 (hook, 100%): the guarantee the prompt can't make
hooks = [require_verified_identity, block_large_refund]

Quick Check: Refund Policy Enforcement

Apply the decision rule to a real scenario.

Recap: 100% vs ~90%

Key takeaways:

Prompts are ~90% probabilistic guidance; hooks are 100% deterministic enforcement.
Use hooks when failure has financial, legal, or safety consequences; use prompts for tone, preference, and soft behavior.
PostToolUse hooks guard results before the model sees them; outgoing-call hooks block policy-violating actions before they fire.
Programmatic preconditions (block a refund until identity is verified) give guarantees prompts cannot.
Reserve hard code for guarantees — keep the loop model-driven, and combine a good prompt (default behavior) with a hook (hard boundary).
Distrust any answer that enforces a critical, costly rule with "a stronger prompt" alone.

자주 묻는 질문

“결정적 강제 적용과 프롬프트” 강의는 무료인가요?

네 — “결정적 강제 적용과 프롬프트” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Claude Architect 강의 전체를 잠금 해제할 수 있습니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“결정적 강제 적용과 프롬프트”에서 뭘 배우나요?

훅은 100% 확실하지만 프롬프트의 성공 확률은 약 90%입니다 브라우저에서 직접 실행하는 실습 코드로 Claude Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Claude Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Claude Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“결정적 강제 적용과 프롬프트” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Claude Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Claude Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Claude Architect(으)로 돌아가기