AI 에이전트 실전 설계 시리즈 (10) - 작은 업무 자동화 에이전트 설계 예제

업무 자동화 에이전트를 보면 AI 에이전트가 챗봇과 어떻게 다른지 더 분명해집니다. 이번 10편은 앞에서 다룬 tool calling, MCP, RAG, memory, workflow, tracing, eval, security를 작은 업무 자동화 에이전트 하나로 묶어봅니다.

핵심은 처음부터 거대한 자율 에이전트를 만들지 말고, 작고 검증 가능한 업무 흐름부터 설계하는 것입니다. 작은 에이전트도 도구 권한, 승인, 로그, 평가 기준이 없으면 운영 단계에서 쉽게 흔들립니다.

업무 자동화 에이전트 요약 카드 — 작은 업무 자동화 에이전트는 workflow, tool permission, memory policy, eval을 함께 가져야 한다.

업무 자동화 에이전트의 업무 범위

예제는 블로그 운영 보조 에이전트로 잡겠습니다. 이 에이전트는 큐에서 글 후보를 고르고, 자료를 확인하고, 초안을 만들고, 검토 결과를 보고합니다. 단, 공개 발행은 사람 승인 없이는 하지 않습니다.

할 수 있는 일: 큐 읽기, 자료 조사, 초안 생성, 검증, draft 생성, 결과 보고
하면 안 되는 일: 승인 없는 publish, 승인 없는 queue 수정, 출처 없는 최신 정보 단정
반드시 멈출 일: 발행, 삭제, 비용이 큰 외부 작업, 개인정보가 섞인 작업

전체 구조를 먼저 그린다

작은 업무 자동화 에이전트도 한 덩어리로 만들면 디버깅하기 어렵습니다. 최소 구조는 입력, workflow, tools, resources, memory, eval, tracing, approval로 나눌 수 있습니다.

업무 자동화 에이전트 아키텍처 도식 — 작은 업무 자동화 에이전트는 workflow, tools, resources, memory, tracing, eval, approval을 분리해서 설계한다.

User request
  -> Intent router
  -> Workflow
     1. select topic
     2. build fact pack
     3. draft article
     4. validate package
     5. create WordPress draft
     6. wait for publish approval

Shared layers
  - tools: WordPress, search, queue, renderer
  - resources: queue, series catalog, format rules
  - memory: user preferences and editorial decisions
  - tracing: every tool call and decision
  - eval: task success and safety checks

User request
  -> Intent router
  -> Workflow
     1. select topic
     2. build fact pack
     3. draft article
     4. validate package
     5. create WordPress draft
     6. wait for publish approval

Shared layers
  - tools: WordPress, search, queue, renderer
  - resources: queue, series catalog, format rules
  - memory: user preferences and editorial decisions
  - tracing: every tool call and decision
  - eval: task success and safety checks

Intent router는 첫 번째 안전장치다

사용자 요청을 받자마자 바로 도구를 호출하면 위험합니다. 먼저 요청이 주제 선택인지, draft 생성인지, publish 승인인지, 시리즈 글인지 분류해야 합니다. 이 단계가 틀리면 뒤 workflow 전체가 잘못 흘러갑니다.

def route_request(message: str) -> str:
    if contains_publish_approval(message):
        return "publish_existing_draft"
    if mentions_specific_series(message):
        return "series_article_draft"
    if asks_queue_delegation(message):
        return "queue_selection_needs_approval"
    if asks_specific_topic(message):
        return "single_article_draft"
    return "clarify"

def route_request(message: str) -> str:
    if contains_publish_approval(message):
        return "publish_existing_draft"
    if mentions_specific_series(message):
        return "series_article_draft"
    if asks_queue_delegation(message):
        return "queue_selection_needs_approval"
    if asks_specific_topic(message):
        return "single_article_draft"
    return "clarify"

router의 목표는 똑똑한 추론이 아니라 위험한 착각을 줄이는 것입니다. 특히 publish, queue 수정, series 수정처럼 되돌리기 어려운 작업은 별도 경로로 분리합니다.

Tools는 권한 기준으로 나눈다

도구 목록을 기능별로만 나누면 부족합니다. 에이전트 설계에서는 읽기 도구, 쓰기 도구, 위험 도구를 권한 기준으로 나눠야 합니다. OpenAI Agents SDK와 MCP 명세 모두 도구를 외부 시스템과 연결되는 실행 단위로 다루므로, 도구 설명과 권한이 중요합니다.

업무 자동화 에이전트 도구 권한 매트릭스 — 도구는 read, write, dangerous, costly, memory 작업으로 나누고 승인 기준을 다르게 둔다.

read tool: queue 조회, series 조회, 최근 글 조회
write tool: draft 생성, daily log 업데이트
dangerous tool: publish, 삭제, 대량 수정, 비용 발생 작업
approval-gated tool: publish와 queue/series 구조 변경

Resources는 에이전트가 참고하는 기준이다

MCP에서 resources는 모델이 읽을 수 있는 맥락을 제공하는 계층으로 볼 수 있습니다. 블로그 운영 예제에서는 queue.yml, series_catalog.yml, format_rules.md, wp_markup_lock.md 같은 파일이 resource 역할을 합니다.

중요한 점은 resource를 memory와 섞지 않는 것입니다. resource는 현재 작업의 공식 기준이고, memory는 사용자 선호나 과거 결정처럼 장기적으로 참고할 정보입니다.

Memory는 저장보다 쓰기 정책이 먼저다

에이전트가 모든 것을 기억하면 좋아질 것처럼 보이지만, 실제로는 무엇을 저장하지 않을지가 더 중요합니다. 블로그 운영 에이전트라면 사용자의 문체 선호, 발행 승인 방식, 싫어하는 제목 패턴은 기억할 수 있지만, 임시 토큰이나 민감 정보는 기억하면 안 됩니다.

memory_policy:
  write:
    - stable editorial preference
    - repeated feedback
    - approved operating rule
  do_not_write:
    - temporary credential
    - private token
    - unverified fact
    - one-time draft wording

memory_policy:
  write:
    - stable editorial preference
    - repeated feedback
    - approved operating rule
  do_not_write:
    - temporary credential
    - private token
    - unverified fact
    - one-time draft wording

Workflow는 되돌릴 수 있는 단계부터 실행한다

좋은 workflow는 초반에는 되돌리기 쉬운 작업을 하고, 뒤로 갈수록 승인과 검증을 강하게 겁니다. draft 생성은 되돌리기 쉽지만 publish는 공개 작업이므로 별도 승인으로 분리해야 합니다.

큐나 시리즈 정의를 읽는다
선정 이유와 글 방향을 보고한다
사용자 승인 후 fact pack을 만든다
article package를 생성하고 검증한다
WordPress draft를 만든다
preview, link, edit_url을 보고한다
publish 승인 전에는 멈춘다

Tracing은 나중에 실패를 설명하기 위해 남긴다

에이전트가 실패했을 때 최종 답변만 남아 있으면 원인을 알 수 없습니다. 어떤 resource를 읽었고, 어떤 tool을 호출했고, 어떤 검증을 통과했는지 trace로 남겨야 합니다.

선택한 route
읽은 resource와 버전
tool call 이름과 인자
검증 결과
사용자 승인 메시지
최종 결과 링크

trace는 관찰용 로그이기도 하지만, 다음 eval을 만들기 위한 재료이기도 합니다. 실패한 실행을 그대로 버리면 다음 버전에서 같은 실패를 반복합니다. 그래서 실행 로그에는 성공한 경로뿐 아니라 멈춘 이유, 재시도 이유, 사용자에게 넘긴 이유까지 남기는 편이 좋습니다.

{
  "route": "series_article_draft",
  "resources_read": ["chapters.yml", "blueprint.yml", "format_rules.md"],
  "tool_calls": ["render_thumbnail", "validate_package", "wp_create_draft"],
  "approval_gate": "publish_required",
  "result": {
    "status": "drafted",
    "post_id": 3671
  }
}

{
  "route": "series_article_draft",
  "resources_read": ["chapters.yml", "blueprint.yml", "format_rules.md"],
  "tool_calls": ["render_thumbnail", "validate_package", "wp_create_draft"],
  "approval_gate": "publish_required",
  "result": {
    "status": "drafted",
    "post_id": 3671
  }
}

Eval은 작업 완료율과 안전 실패를 나눠 본다

작은 에이전트라도 eval이 있어야 개선할 수 있습니다. 최종 문장이 자연스러운지보다 먼저 봐야 할 것은 작업이 실제로 완료됐는지, 승인 조건을 지켰는지, 잘못된 도구 호출이 없었는지입니다.

{
  "task_success": true,
  "required_outputs_present": true,
  "approval_respected": true,
  "unsafe_action": false,
  "tool_call_errors": 0,
  "public_url_http_200": true
}

{
  "task_success": true,
  "required_outputs_present": true,
  "approval_respected": true,
  "unsafe_action": false,
  "tool_call_errors": 0,
  "public_url_http_200": true
}