AI 에이전트가 이제 분산 시스템이 된 이유 (Why AI Agents Are Distributed Systems Now)

URL: https://www.youtube.com/watch?v=XV6WcGliCGM
날짜: 2026-09-02
채널: Tech Bridge
원문 제목: [한영자막] AI 에이전트가 이제 분산 시스템이 된 이유 — TikTok Salman Munaf
영상 길이: 19:19
Video ID: XV6WcGliCGM

---

📌 핵심 질문 / AI 에이전트가 분산 시스템이 되는 조건

==외부 시스템을 호출하고 상태를 바꾸는 순간 AI 에이전트는 더 이상 단순한 언어 모델이 아니라, 확률적 조정자가 포함된 분산 시스템이 된다.==

• LLM이 텍스트를 생성하기만 할 때 실패의 결과는 잘못된 출력에 머물렀지만, 에이전트는 API·데이터베이스·도구를 호출하고 외부 세계에 부작용(side effect)을 만든다.
• 에이전트의 판단과 행동은 확률적이므로, 권한 범위·멱등성(idempotency)·재시도·예산·회로 차단기(circuit breaker) 같은 결정론적 통제가 필요하다.
• 메모리와 검색 컨텍스트가 행동에 영향을 미치면 그것은 단순한 컨텍스트가 아니라 오염되거나 오래될 수 있는 상태(state)다.
• 좋은 모델은 실수를 줄이지만 네트워크 장애·오래된 데이터·적대적 입력을 없애지 못하므로, 에이전트의 행동을 제한하고 관찰하고 복구할 수 있는 구조가 핵심이다.

LLM 기반 챗봇은 입력 프롬프트에 텍스트로 응답하는 경계가 분명한 소프트웨어였다. 에이전트는 프롬프트를 받아 계획하고, 도구와 외부 서비스를 호출하고, 결과를 관찰하고, 상태를 저장하고, 다음 행동을 결정한다. 각 단계는 서로 다른 시스템과 경계를 넘으며 실패·중복·부분 성공·권한 남용을 일으킬 수 있다. 따라서 설계자는 “모델이 무엇을 할 수 있는가”뿐 아니라 “모델이 틀렸을 때 시스템이 무엇을 허용하는가”를 물어야 한다.

1. 챗봇에서 외부 세계를 바꾸는 Production System으로

AI 에이전트의 아키텍처 경계는 LLM 모델 바깥으로 확장됐고, 부작용을 관리하는 시스템 설계가 필수 조건이 됐다.

1.1. 텍스트 생성과 행동 수행의 차이

1. 초기 LLM의 제한된 실패 범위

   1. 텍스트 입력과 텍스트 출력: 초기 LLM은 프롬프트를 받아 텍스트를 생성했으며, 다른 시스템과 상호작용하지 않았다.
   2. 잘못된 출력이라는 결과: 모델이 틀리더라도 직접 발생하는 효과는 잘못된 모델 출력이었다. 데이터베이스를 지우거나 고객에게 환불을 실행하는 외부 부작용은 없었다.

2. Agentic Era에서 생긴 외부 영향력

   1. 에이전트 루프: 에이전트는 프롬프트를 입력받아 계획(planning)하고 행동(action)하며 결과를 관찰(observation)한 뒤 다음 행동을 결정한다.
   2. 도구와 서비스 호출: 외부 API, 데이터베이스, 큐(queue), 파일 및 각종 도구를 호출할 수 있다.
   3. 상태 변경: 호출 결과로 데이터를 기록하거나 티켓을 수정하고, 이메일을 보내고, 환불처럼 되돌리기 어려운 작업을 실행할 수 있다.
   4. 이동한 아키텍처 경계: 시스템의 위험 경계가 모델 자체에서 외부 시스템·자격 증명·저장된 상태·허용된 행동 전체로 넓어졌다.

1.2. AI 에이전트 사고가 보여주는 시스템 설계의 필요성

1. Replit AI 에이전트의 Production Database 삭제

   1. 위험한 부작용: 에이전트가 운영 데이터베이스를 삭제하는 사고가 발생했다. 모델의 의도나 능력보다 삭제 권한이 실제 운영 환경에 열려 있었다는 시스템 설계 문제가 중요하다.
   2. 예방 통제: 견고한 백업(robust backup)을 마련하고, 권한 범위를 좁히고(scoped authority), AI 에이전트가 운영 데이터베이스를 삭제하지 못하게 해야 한다.

2. Air Canada 챗봇의 잘못된 환불 안내

   1. 권위 있는 사실의 부재: 챗봇이 오래됐거나 잘못된 정책을 근거로 판단하면 고객에게 잘못된 환불을 약속하거나 실행할 수 있다.
   2. Source of Truth 검색: 정책을 결정할 때 권위 있는 최신 원천(authoritative source of truth)을 검색하도록 해야 하며, 모델의 기억이나 임의 생성 결과만으로 결정을 내리게 해서는 안 된다.

3. 사고를 예방하는 관점 전환

   1. 확인해야 할 외부 대상: 에이전트가 어떤 외부 시스템과 대화하는지, 어떤 상태를 읽고 쓰는지, 어떤 자격 증명을 보유하는지, 어떤 행동을 수행할 수 있는지 먼저 목록화해야 한다.
   2. 부작용 중심의 설계: “정답을 생성하는가?”만으로 품질을 평가하지 말고, 잘못된 판단이 외부 세계에 만들 수 있는 결과를 제한하고 복구하는 경로까지 설계해야 한다.

2. 확률적 조정자와 결정론적 통제

AI 에이전트의 독특한 위험은 확률적 모델이 여러 시스템에 걸친 작업의 조정자(coordinator)가 된다는 데 있다.

2.1. Deterministic Coordinator에서 Probabilistic Coordinator로

1. 전통적 분산 시스템의 조정

   1. 미리 정의된 흐름: 전통적인 서비스는 여러 단계의 워크플로를 조정하더라도 가능한 경로를 비교적 결정론적으로 정의할 수 있었다.
   2. 예측 가능한 행동 공간: 설계자가 트리 형태로 단계와 분기를 매핑하고, 허용된 경로를 기준으로 부작용을 분석할 수 있었다.

2. AI 에이전트의 확률적 조정

   1. 행동의 가변성: 에이전트는 같은 목표라도 상황과 모델 출력에 따라 선택하는 도구·순서·호출 횟수가 크게 달라질 수 있다.
   2. 예측 불가능한 영향: 전통적인 흐름도에 모든 행동을 미리 담기 어렵고, 제한되지 않은 선택이 심각한 결과로 이어질 수 있다.
   3. 확률성을 통제로 감싸기: 모델의 유연한 판단을 제거할 필요는 없지만, 모델 바깥에 결정론적 규칙을 배치해 위험한 행동을 막아야 한다.

2.2. 권한이 아니라 통제 경계로 에이전트를 감싸기

1. 행동 전 검증

   1. 도구 호출 전에 요청 스키마, 대상, 권한, 금액, 변경 범위를 결정론적으로 검사해야 한다.
   2. 운영 데이터 삭제·대규모 변경·외부 고객 통신처럼 되돌리기 어렵거나 위험한 작업에는 별도 승인 또는 차단 규칙을 둬야 한다.

2. 행동 후 추적과 복구

   1. 에이전트가 어떤 컨텍스트를 사용했고 어떤 호출을 했는지 매 단계 저장해야 한다.
   2. 실패 지점을 재구성하고, 가능한 작업은 undo 또는 보상 작업(compensation operation)으로 되돌릴 수 있어야 한다.

3. 에이전트 루프는 매 단계 시스템 경계를 넘는다

계획·행동·관찰·저장·결정의 반복은 하나의 함수 호출이 아니라 여러 외부 경계를 횡단하는 분산 트랜잭션이다.

3.1. 계획부터 다음 결정까지의 단계

1. Planning

   1. 에이전트는 목표를 달성하기 위한 다음 행동을 계획한다.
   2. 계획 과정에서 데이터 소스에 접근해 필요한 정보를 검색할 수 있으며, 검색 결과 자체가 이후 행동을 좌우한다.

2. Action

   1. 외부 API·도구·데이터베이스를 호출하고 실제 작업을 수행한다.
   2. 이메일 발송, 티켓 수정, 환불 실행 등 외부 상태를 바꾸는 부작용이 발생할 수 있다.

3. Observation

   1. 호출 결과가 완전하지 않고 부분적인 결과(partial result)만 도착할 수 있다.
   2. 에이전트는 부분 결과에 근거해 다음 계획을 세우거나 후속 호출을 수행하므로, 부분 결과가 오해되면 오류가 연쇄된다.

4. Persistence와 Decision

   1. 에이전트는 컨텍스트·결과·중간 상태를 데이터 저장소에 기록할 수 있지만, 잘못된 데이터가 저장되면 이후 판단까지 오염된다.
   2. 다음 행동을 결정하는 단계에서 잘못된 명령을 선택하거나, 실패를 감지한 뒤 과도한 재시도 폭풍(retry storm)을 시작할 수 있다.

3.2. 모든 단계를 영속화하고 보상 트랜잭션을 정의하기

1. 단계별 기록

   1. 어떤 컨텍스트를 검색했는지, 어떤 도구를 어떤 인자로 호출했는지, 어떤 응답·오류를 받았는지 모두 저장해야 한다.
   2. 장애가 발생하면 어느 단계에서 실패했는지 파악하고, 이미 실행된 작업 중 되돌릴 수 있는 범위를 식별할 수 있어야 한다.

2. 명시적 트랜잭션과 보상

   1. 각 작업에는 실패했을 때 어떤 트랜잭션으로 보상할지 명시해야 한다.
   2. 되돌릴 수 없는 작업이라도 실수를 완화하는 보상 경로를 정의해야 한다. 예를 들어 잘못된 이메일을 고객에게 보냈다면 사과 이메일이나 오류를 바로잡는 후속 이메일을 발송하는 절차가 필요하다.

3. 분산 트랜잭션의 부분 성공

   1. 에이전트가 내부 티켓을 업데이트하고 고객에게 이메일을 보낸 뒤 CRM 업데이트 직전에 실패할 수 있다.
   2. 이때 티켓과 이메일을 원상복구할지, CRM 업데이트를 재개할지, 고객에게 정정 메시지를 보낼지에 대한 올바른 보상 작업을 사전에 정해야 한다.

4. 원격 호출의 실패는 ‘실패’가 아니라 ‘알 수 없음’일 수 있다

도구는 외부 API·데이터베이스·큐를 감싼 래퍼일 뿐이며, 네트워크의 불확실성이 부작용 중복과 잘못된 재시도로 이어진다.

4.1. Timeout이 성공 여부를 말해주지 않는 이유

1. 원격 호출의 다양한 실패

   1. 네트워크 지연과 타임아웃이 발생할 수 있다.
   2. 요청이 중복 전송될 수 있고, 서버는 작업을 완료했지만 클라이언트는 오류를 보고받는 비대칭 상황도 생긴다.

2. 서버 성공·클라이언트 오류의 사례

   1. 데이터베이스가 실제로 데이터를 기록했지만 다른 통신 오류 때문에 클라이언트에 실패를 반환할 수 있다.
   2. 사람은 실제 데이터베이스나 권위 있는 원천을 확인해 교정할 수 있지만, 에이전트는 오류만 보고 작업이 실패했다고 추론한 뒤 같은 부작용을 다시 실행할 위험이 있다.

3. 환불 호출의 불확실성

   1. refund customer 도구 호출이 타임아웃되면 환불이 실행됐는지 실행되지 않았는지 알 수 없다.
   2. 타임아웃을 곧바로 실패로 취급해 재환불하면 고객에게 중복 환불이 발생할 수 있으므로, 상태 조회를 먼저 수행해야 한다.

4.2. Request ID와 Idempotency Key

1. 중복 요청 식별

   1. 모든 원격 호출에 요청 ID(request ID)를 부여해 동일 작업을 추적해야 한다.
   2. 멱등성 키(idempotency key)를 사용하면 동일 요청이 다시 들어왔을 때 외부 시스템이 중복 요청임을 알아차릴 수 있다.

2. 중복 부작용 차단

   1. 같은 멱등성 키를 가진 요청은 한 번만 부작용을 만들고 이후 중복 호출에는 기존 결과를 돌려줘야 한다.
   2. 이전 요청의 상태를 조회할 수 있는 API를 제공하면 에이전트가 재실행 전에 이미 처리됐는지 확인할 수 있다.

3. 에이전트의 기본 반응인 재시도 제어

   1. 에이전트는 장애를 만나면 첫 번째 반응으로 재시도를 선택하기 쉽다.
   2. 따라서 멱등성은 선택적 최적화가 아니라 에이전트 도구 계약(tool contract)에 내장해야 하는 안전장치다.

5. Retry Storm과 Cascading Failure를 막는 운영 한계

에이전트의 자율적 재시도와 병렬 호출은 하위 시스템을 포화시키고 장애를 연쇄 확산시킬 수 있다.

5.1. 재시도 폭풍의 전파 경로

1. 과도한 Fan-out

   1. 에이전트가 여러 도구를 병렬로 호출하거나 실패한 호출을 계속 반복하면 외부 API에 짧은 시간 동안 큰 부하가 집중된다.
   2. 하위 서비스가 이미 포화된 상태라면 재시도가 부하를 더 키워 상위 에이전트와 다른 의존성까지 함께 실패시킨다.

2. 결정론적 예산 설정

   1. 최대 턴 수(max turns)와 최대 병렬 호출 수(max parallel calls)를 설정해 한 실행이 만들 수 있는 행동의 양을 제한해야 한다.
   2. 비용 상한(max spend)을 두어 에이전트가 문제를 해결하려고 무한히 토큰·API 호출 비용을 쓰지 않게 해야 한다.

5.2. Backoff, Circuit Breaker, Compensation

1. Exponential Backoff

   1. 재시도 사이의 대기 시간을 점진적으로 늘려 하위 의존성이 회복할 시간을 줘야 한다.
   2. 무작정 즉시 재호출하는 정책은 장애가 난 시스템을 더 압박하므로 금지해야 한다.

2. Circuit Breaker

   1. 하위 시스템이 비정상적이거나 포화되면 회로 차단기(circuit breaker)가 추가 호출을 막아야 한다.
   2. 호출을 차단하면 에이전트가 장애 의존성을 계속 태우는 것을 막고, cascading failure가 다른 시스템으로 확산되는 것을 줄일 수 있다.

3. 보상 작업과 복구 경로

   1. 부작용을 만든 호출이 부분적으로 성공했을 때 취소·정정·후속 처리를 실행할 보상 작업을 준비해야 한다.
   2. 재시도 정책은 단순히 “다시 해보기”가 아니라, 기존 요청 상태 조회·멱등성 확인·보상 여부 판단을 포함해야 한다.

6. 에이전트 컨텍스트는 행동에 영향을 주는 상태다

에이전트의 메모리가 행동의 입력으로 사용되는 순간 컨텍스트(context)는 캐시처럼 관리해야 하는 상태가 된다.

6.1. Short-term Memory와 Long-term Memory

1. 단기 메모리(Short-term Memory)

   1. 현재 채팅 스레드(chat thread)에 묶인 실행 맥락이다.
   2. 단일 실행에 종속되므로 해당 실행의 계획과 다음 행동을 결정하는 직접적인 입력이 된다.

2. 장기 메모리(Long-term Memory)

   1. 프로젝트 파일, 시스템 프롬프트, 에이전트가 연결된 데이터베이스, 캐시 레이어 등이 포함된다.
   2. 여러 실행에서 재사용될 수 있어 오래된 정보가 미래 행동에 지속적으로 영향을 줄 위험이 있다.

6.2. 메모리를 Cache로 취급하기

1. 상태가 가진 세 가지 위험

   1. 메모리는 최신 원천 데이터와 불일치할 수 있다.
   2. 서로 다른 데이터 소스가 충돌하거나, 잘못된 정보가 저장돼 이후 행동을 오염시킬 수 있다.
   3. 컨텍스트가 단순한 참고자료가 아니라 행동에 영향을 주면, 이를 업데이트·무효화하지 않는 것이 상태 관리 결함이 된다.

2. Source of Truth와 Provenance

   1. 여러 메모리가 충돌할 때 어떤 시스템을 권위 있는 원천으로 볼지 먼저 결정해야 한다.
   2. 메모리에 출처(provenance)를 붙여 언제 어디서 얻었는지 추적하고, 최신 원천과 연결된 상태인지 확인해야 한다.

3. 무효화(Invalidation)

   1. 데이터베이스나 원천 데이터가 업데이트되면 그 데이터를 바탕으로 만든 에이전트 컨텍스트와 메모리를 무효화해야 한다.
   2. 오래된 메모리를 그대로 사용하지 않게 해야 에이전트가 낡은 정책이나 과거 상태에 근거해 외부 부작용을 만드는 일을 줄일 수 있다.

7. 권한과 인간 승인은 행동 단위로 좁혀야 한다

모델이 무해해 보여도 안전하지 않은 작업 권한이 붙는 순간 위험한 시스템이 되므로, 자격 증명과 승인 범위를 최소화해야 한다.

7.1. Scoped Credentials와 도구 Allowlist

1. 과도한 기본 권한의 문제

   1. 에이전트가 작업을 완수하도록 데이터베이스 전체에 읽기·쓰기 권한을 주는 방식은 편하지만, 한 번의 잘못된 판단이 전체 테이블을 훼손하게 만든다.
   2. 모델의 의도가 선하더라도 삭제·대량 수정·민감 데이터 접근이 가능하면 결과적으로 위험한 에이전트가 된다.

2. 최소 권한 설계

   1. 읽기와 쓰기 권한을 분리하고, 필요한 데이터 범위에만 접근하도록 자격 증명을 좁혀야 한다.
   2. 호출할 수 있는 도구를 allowlist로 제한하고, 각 도구에 허용된 입력·대상·작업 유형을 명시해야 한다.

7.2. Human Approval은 Blanket Approval이 아니다

1. 승인에 묶어야 할 속성

   1. 인간 승인은 포괄적 허가가 아니라 특정 action, timestamp, actor, expiration에 연결해야 한다.
   2. 승인된 매개변수와 실제 실행 매개변수가 일치하는지 결정론적으로 검증해야 한다.

2. 30달러 환불과 300달러 환불의 차이

   1. 사용자가 30달러 환불을 승인했다고 해서 그 승인이 이후 300달러 환불까지 승인하는 것으로 해석돼서는 안 된다.
   2. 승인 범위·금액·대상·시간이 바뀌면 새 승인을 요구해야 하며, 만료된 승인이나 다른 행위자(actor)의 승인을 재사용해서는 안 된다.

8. 로그를 넘어선 관측 가능성(Observability)

에이전트 장애를 고치려면 오류 한 줄이 아니라 판단을 재구성할 수 있는 분산 추적이 필요하다.

8.1. 왜 일반 로그만으로 부족한가

1. 재구성해야 할 질문

   1. 에이전트가 언제 실패했는가?
   2. 어떤 정보에 반응했는가?
   3. 왜 해당 행동을 선택했는가?
   4. 외부 시스템에 어떤 변경을 남겼고, 어떤 승인을 받았는가?

2. 단편 로그의 한계

   1. 일반 로그만으로는 모델의 입력 컨텍스트, 검색 결과, 도구 응답, 재시도 순서를 하나의 실행 흐름으로 연결하기 어렵다.
   2. 실패 시점만 기록하면 잘못된 판단의 원인과 복구에 필요한 실제 상태를 확인할 수 없다.

8.2. 반드시 추적할 실행 증거

1. 모델과 프롬프트

   1. 호출한 모델과 전달한 프롬프트를 기록해야 한다.
   2. 시스템 프롬프트, 단기·장기 메모리, 검색된 컨텍스트 등 모델이 반응한 입력의 출처를 함께 남겨야 한다.

2. 도구 호출과 응답

   1. 호출한 도구, 요청 ID, 요청 내용, 도구의 응답, 발생한 오류를 추적해야 한다.
   2. 서버가 실제로 성공했는지 클라이언트가 어떤 상태를 받았는지 비교할 수 있어야 한다.

3. 상태 변경과 승인

   1. 에이전트가 작성한 데이터와 권한 변경, 외부 시스템에 남긴 부작용을 기록해야 한다.
   2. 어떤 승인(action·timestamp·actor·expiration)을 근거로 실행했는지 남겨야 사후 감사와 복구가 가능하다.

9. 모델 품질을 넘어서는 AI 에이전트 아키텍처

더 똑똑한 모델은 정확도를 높이지만, 분산 시스템의 실패 원인을 제거하지 못하므로 모델 능력과 운영 통제를 분리해 평가해야 한다.

9.1. 좋은 모델의 역할과 한계

1. 모델 능력의 긍정적 효과

   1. 더 좋은 모델은 올바른 작업을 수행할 가능성을 높이고 실수를 줄인다.
   2. 복잡한 목표를 이해하고 적절한 도구를 선택하는 능력을 개선할 수 있다.

2. 모델로 해결할 수 없는 문제

   1. 네트워크 장애와 타임아웃은 아무리 똑똑한 모델도 제거하지 못한다.
   2. 오래된 데이터와 충돌하는 메모리, 적대적 입력(adversarial input), 서버의 부분 성공도 모델 지능만으로 해결되지 않는다.

9.2. Tool Contract와 설계자 체크리스트

1. 도구 계약(tool contract)

   1. 각 도구는 요청·응답 타입과 스키마를 명확하게 정의해야 한다.
   2. 계약은 허용된 작업의 범위를 규정하고 멱등성을 내장해 반복 요청이 위험한 부작용을 재실행하지 않게 해야 한다.

2. 상태와 재시도

   1. 메모리 충돌 시 사용할 Source of Truth를 정하고, 출처와 무효화 규칙을 관리해야 한다.
   2. rate limit, exponential backoff, 최대 턴 수, 최대 병렬성, 최대 지출액을 설정해 공격적 재시도를 막아야 한다.

3. 권한·추적·복구

   1. 최소 권한, 읽기·쓰기 분리, 도구 allowlist, 매개변수 단위 인간 승인을 적용해야 한다.
   2. 모델·프롬프트·검색 컨텍스트·도구 호출·응답·오류·변경·승인을 연결해 추적하고, 각 부작용의 복구 경로를 마련해야 한다.

4. 최종 설계 질문

   1. 에이전트가 실패했을 때 어떤 외부 행동까지 허용되는가?
   2. 이미 실행된 작업을 어떻게 발견하고, 중복 부작용 없이 보상하며, 시스템을 안전한 상태로 되돌릴 것인가?

주요 발언 모음

“AI 에이전트를 기본적으로 확률적 조정자(probabilistic coordinator)라고 생각할 수 있다.”

“타임아웃은 실제로 실패가 발생했다는 뜻이 아니다. 상태가 알려지지 않았다는 뜻이다.”

“행동에 영향을 주는 컨텍스트는 단순한 컨텍스트가 아니라 상태다.”

“더 똑똑한 모델은 실수를 줄일 수 있지만 네트워크 장애, 오래된 데이터, 적대적 입력을 제거할 수는 없다.”

“AI 에이전트를 만들 때는 에이전트가 틀렸을 때 시스템이 무엇을 하도록 허용하는지 물어야 한다.”

핵심 데이터 & 수치

• 영상 길이: 19분 19초다.
• 환불 승인 예시: 30달러 환불 승인은 300달러 환불 승인으로 확대 해석될 수 없다.
• 핵심 수치의 성격: 성능 벤치마크나 비용 실측 수치는 제시되지 않았으며, 최대 턴 수·최대 병렬 호출 수·최대 지출액·rate limit을 설계자가 명시해야 한다는 운영 원칙이 제시됐다.
• 사례: Replit AI 에이전트의 Production Database 삭제와 Air Canada 챗봇의 잘못된 환불 안내가 외부 부작용 및 권위 있는 원천 데이터의 필요성을 보여준다.

결론 및 시사점

1. AI 에이전트의 경계는 LLM 호출부가 아니라 외부 API·데이터베이스·큐·메모리·권한·승인·부작용 전체를 포함하는 분산 시스템 경계로 정의해야 한다.
2. 확률적 판단은 모델 내부에 맡기되, 도구 계약·스키마 검증·최소 권한·allowlist·예산·병렬성·rate limit은 결정론적으로 강제해야 한다.
3. 원격 호출의 타임아웃은 실패가 아니라 미확정 상태로 처리하고, request ID·idempotency key·상태 조회를 통해 재시도 전에 실제 결과를 확인해야 한다.
4. 에이전트 루프의 모든 단계와 컨텍스트를 영속화해 실패 지점을 재구성하고, 각 부작용에 대한 undo 또는 compensation operation을 준비해야 한다.
5. 메모리는 캐시로 취급하고 provenance와 invalidation을 적용해 오래된 데이터가 미래 행동을 오염시키지 않게 해야 한다.
6. 관측 가능성은 모델 호출과 프롬프트뿐 아니라 검색 컨텍스트·도구 요청/응답·오류·변경·승인까지 하나의 trace로 묶을 때 비로소 복구에 쓸 수 있다.
7. 최종 검토의 기준은 “모델이 얼마나 똑똑한가”가 아니라 “틀렸을 때 어디까지 행동할 수 있고, 그 행동을 어떻게 관찰·제한·복구하는가”다.

핵심 요약 (20줄)

1. LLM이 텍스트만 생성할 때 실패는 잘못된 출력에 머물렀다.

2. AI 에이전트는 외부 API와 도구를 호출해 실제 상태를 변경한다.

3. 외부 부작용이 생기는 순간 에이전트는 분산 시스템으로 다뤄야 한다.

4. Replit AI 에이전트의 운영 데이터베이스 삭제는 권한 설계의 위험을 보여준다.

5. Air Canada 챗봇 사례는 최신 정책을 보장하는 Source of Truth 검색의 필요성을 보여준다.

6. 전통적 서비스 조정자는 결정론적이지만 에이전트는 확률적 조정자다.

7. 확률적 판단을 감싸는 결정론적 통제가 위험한 행동을 차단한다.

8. 에이전트 루프는 계획·행동·관찰·저장·결정을 반복한다.

9. 각 루프 단계는 데이터·도구·상태·권한의 경계를 넘는다.

10. 모든 컨텍스트와 도구 호출을 저장해야 실패 지점을 재구성할 수 있다.

11. 부분 성공에 대비해 명시적인 보상 트랜잭션을 정의해야 한다.

12. 타임아웃은 호출 실패가 아니라 결과가 알려지지 않은 상태일 수 있다.

13. Request ID와 idempotency key는 중복 요청의 부작용을 막는다.

14. 상태 조회는 재시도 전에 서버의 실제 처리 결과를 확인하게 한다.

15. 최대 턴·병렬 호출·지출액과 exponential backoff가 retry storm을 제한한다.

16. Circuit breaker는 포화된 하위 시스템으로의 호출과 cascading failure를 차단한다.

17. 행동에 영향을 주는 단기·장기 메모리는 캐시처럼 무효화해야 한다.

18. 최소 권한·읽기/쓰기 분리·도구 allowlist가 잘못된 행동의 범위를 줄인다.

19. 인간 승인은 action·timestamp·actor·expiration과 구체적 매개변수에 묶어야 한다.

20. 좋은 모델보다 중요한 최종 질문은 틀렸을 때 무엇을 허용하고 어떻게 복구할지다.