에이전트 해부학: Brain, Tools, Memory, Policy

모형은 장기 하나일 뿐

강한 모형은 천장을 높여줘. 하지만 실제 일을 버티는지는 몸 전체가 결정해. 도구가 무엇을 할 수 있는지 정하고, memory가 무엇을 이어갈지 정하고, policy가 절대 하면 안 되는 일을 막고, observability가 나중에 삽질을 추적하게 해준다. 어차피 한 번쯤 실망시킬 거야. 그러니까 볼 수 있게 만들어야지.

다섯 부분짜리 스택

Brain: model selection, prompt, reasoning budget, output format.
Hands: tools, hosted tools, MCP servers, APIs, local shell, browser, code execution.
Memory: short-term context, scratchpad, vector recall, structured facts, durable notes.
Nerves: traces, logs, metrics, replayable runs, eval records.
Immune system: permissions, guardrails, sandboxing, human approval, kill switch.

한 부분을 갈아도 전체를 다시 만들 필요는 없어. 그래서 좋은 agent design은 model-agnostic이지만 model-indifferent는 아니야. 아무 모델이나 꽂아도 된다는 뜻이 아니라고, 이 미묘한 차이 중요해.

Blast radius로 설계하기

도구가 바꿀 수 있는 게 클수록 policy는 더 빡세야 해. 공개 웹페이지 읽기는 blast radius가 작아. 카드 결제, DB row 삭제, production push는 blast radius가 커. 이 차이는 프롬프트의 희망사항이 아니라 코드의 권한층에 박혀 있어야 한다.

Code

Capability map·yaml

agent:
  brain:
    model: "provider-selected"
    output_contract: "final_answer | tool_calls | handoff"
  hands:
    read_tools: ["web_search", "read_file"]
    write_tools: ["write_file"]
    destructive_tools: ["delete_file", "deploy"]
  memory:
    short_term: "conversation"
    long_term: "sqlite + markdown notes"
  policy:
    require_approval: ["delete_file", "deploy"]
    max_steps: 20
    max_cost_usd: 1.00

Exercise

학습자가 만든 에이전트 설계에 capability map을 그려봐. 모든 도구를 read-only, write, destructive, external, privileged 중 하나 이상으로 표시해.

Hint

도구 하나가 여러 라벨을 가질 수 있어. Slack send는 external + write, deploy는 privileged + destructive야.