AI agent 아키텍처에는 model과 tool loop보다 더 많은 것이 필요합니다. production 설계는 identity, 도구, task state, 장기 memory, durable execution, 백엔드 서비스, telemetry를 분리해야 합니다. 각 계층이 담당하는 실패가 다르기 때문입니다.
가장 명확한 테스트는 두 번의 외부 쓰기 사이에 crash를 일으키는 것입니다. 시스템은 conversation text에서 현실을 다시 구성하도록 모델에 요구하지 않고도 누가 작업했고, 무엇이 완료되었고, 무엇이 완료되었을 수 있으며, 어디에서 재개해야 하는지 알아야 합니다.
실행 경로부터 살펴보세요
flowchart TB
Trigger[User or event] --> Loop[Model and agent loop]
Loop --> Policy[Identity and policy]
Policy --> Tools[Tool registry]
Tools --> Durable[Durable execution]
Durable --> Backend[Backend services]
Loop <--> State[(Task state)]
Loop <--> Memory[(Long-term memory)]
Loop --> Telemetry[Traces, logs, metrics, evals]
Tools --> Telemetry
Durable --> Telemetry
Backend --> Telemetry
모델은 다음 작업을 제안합니다. policy는 그 identity가 작업을 수행해도 되는지 결정합니다. tool layer는 판단을 범위가 제한된 contract로 바꿉니다. durable execution은 외부 영향 전후의 진행 상황을 기록합니다. 백엔드 서비스는 기준이 되는 비즈니스 데이터를 보관합니다. telemetry는 사람이 실행 과정을 재구성할 수 있게 합니다.
이 순서는 더 넓은 production agent stack에 속하지만, 회사의 모든 서비스를 그리는 것보다 실제 workflow 하나를 그리는 편이 더 유용합니다.
각 계층에 한 종류의 기준 정보만 맡기세요
model loop는 선택하지만 권한을 부여하지 않습니다
loop는 prompt, 최근 message, tool result, stopping rule을 보관합니다. 도구를 선택할 수는 있지만 권한은 다운스트림 시스템에서 적용해야 합니다. “invoice를 읽기만 하라”는 prompt는 지침이지 접근 제어 경계가 아닙니다.
도구는 범위가 제한된 작업을 제공합니다
tool contract는 작업 이름을 정하고, 인수를 제한하고, 다음 판단에 필요한 필드를 반환합니다. 모델이 원하는 것을 설명할 수 있다는 이유만으로 광범위한 administrative API를 노출해서는 안 됩니다. MCP 도구 설계 가이드는 선택, schema, 안정적인 오류, 안전한 쓰기를 다룹니다.
identity와 policy는 실행 가능 여부를 결정합니다
tenant, user, agent, 위임된 scope를 작업을 수행하는 시스템까지 전달하세요. 결과가 큰 호출 전에 policy를 검사하고 판단을 audit record에 보존해야 합니다. 서버가 자격 증명에서 알아낼 수 있는 tenant ID를 모델에 요구하지 마세요.
task state는 현재 실행 위치를 기록합니다
task state에는 현재 step, 완료된 operation, 대기 중인 approval, retry count, 다음 예정 attempt가 포함됩니다. 이를 생성한 process가 종료되어도 유지되어야 합니다. conversation history는 실행에 대한 입력이지만 transaction state를 안정적으로 표현하지 못하므로 명시적 state를 대신하기에는 부족합니다.
memory는 실행 사이에 선택된 사실을 전달합니다
memory에는 user preference, 이전 summary, 검색된 document가 포함될 수 있습니다. 오류 가능성이 있는 context이므로 provenance, retention, deletion rule을 유지하세요. “invoice sent” 같은 memory 문장만으로 되돌릴 수 없는 부작용을 기록하지 마세요. 그 사실은 기준이 되는 backend state에 속합니다.
durable execution은 중단을 견딥니다
durable execution은 retry, checkpoint, wait, resume을 조율합니다. Temporal은 crash나 outage가 발생해도 기록된 event history를 재생해 계속 진행하는 방식을 durable execution이라고 정의합니다. Temporal을 도입하지 않고 더 작은 operation ledger를 구현하더라도 이 모델은 유용합니다. Temporal의 durable execution 설명과 자세한 agent durability 가이드를 참고하세요.
백엔드 서비스는 비즈니스 사실을 소유합니다
order, payment, file, permission, customer record는 invariant를 적용하도록 설계된 시스템에 둡니다. agent는 범위가 제한된 API나 도구로 접근해야 합니다. model response가 주문을 설명할 수는 있지만 주문의 기준 record가 되어서는 안 됩니다.
telemetry는 경로 전체를 다시 연결합니다
model call, tool selection, policy check, tool execution, downstream request 전체에 하나의 trace를 사용하세요. operation ID와 redaction된 argument를 포함합니다. event에는 log, 집계 상태에는 metric, 예상 동작에는 evaluation을 사용하세요. 어느 하나가 다른 것을 대신할 수는 없습니다.
제품을 선택하기 전에 실패를 구분하세요
agent가 timeout 후 email을 다시 보냈다면 durable execution과 idempotency를 조사하세요. 다음 주에 preference를 잘못 기억한다면 memory와 provenance를 조사하세요. 다른 tenant의 record를 읽었다면 identity와 authorization을 조사하세요. delete_project를 선택하고 archive_project를 선택하지 않았다면 모델에 보이는 도구 집합과 selection test를 조사하세요.
“agent platform” 하나를 구매한다고 해서 이 경계가 사라지지는 않습니다. 어떤 component가 경계를 소유하는지가 바뀔 뿐입니다. 제품 이름 뒤에 있는 평범한 database나 queue까지 포함해 소유권을 명시적으로 기록하세요.
가장 까다로운 workflow부터 그리세요
읽기 전용 chat부터 시작하지 마세요. 두 번 쓰고, 승인을 기다리고, 불안정한 API를 호출하거나, 비용을 지출할 수 있는 workflow를 고르세요. 모든 부작용 전후에 기준 record를 표시하세요. 아래 프롬프트는 이 경로를 아키텍처 지도로 바꾸고 현재 모델의 context window 안에만 존재하는 계층을 찾아냅니다.