AI agent 안전 설계, 모델은 판단하고 실행은 등록된 작업만

AI agent를 실서비스에 올릴 때 가장 위험한 순간은 모델이 판단을 틀릴 때보다, 판단한 일을 모델이 직접 실행할 때일 수 있습니다. 운영 중인 클러스터가 불안정하다고 본 agent가 재시작 명령을 즉석에서 만들어 실행한다면, 그 절차가 맞는지 보장할 장치가 없습니다. Netflix에서 오케스트레이션 엔진 Conductor를 처음 만든 엔지니어는 해법으로 역할 분리를 제시합니다. 모델은 다음에 무엇을 할지만 정하고, 실제 실행은 미리 등록해 검증한 작업만 결정적으로 수행하는 실행 틀(harness)이 맡아야 한다는 것입니다. 모델은 두뇌, harness는 손이라는 구도입니다.

챗봇 그림으로는 보이지 않는 agent

흔히 떠올리는 agent의 모습은 사용자가 prompt를 보내면 챗봇이 도구를 한 번 호출하고 답을 돌려주는 구조입니다. 고객 응대 챗봇이 대표적입니다. 하지만 실제 운영 환경의 agent 대부분은 사람이 지켜보거나 지시하지 않는 상태로 돕니다. 이 그림만으로 agent를 이해하면 백그라운드 작업이나 이벤트 기반 자동화처럼 가치가 큰 쓰임을 놓치기 쉽습니다.

사람이 곁에 없는 agent일수록 실행을 무엇이 통제하느냐가 곧 안전의 문제가 된다고 볼 수 있습니다.

agent는 부품이고 harness가 애플리케이션

이 구조는 마이크로서비스 아키텍처와 닮았습니다. 기업은 모든 로직을 서비스 하나에 몰아넣지 않고, 작은 서비스 여러 개를 두고 그 위의 오케스트레이션 계층이 상태, 경로, 정책, 장애 복구를 맡게 합니다. agent도 같은 길을 걷고 있습니다. agent 루프 하나는 애플리케이션이 아니라 부품이고, agent와 사람, 데이터베이스, API, MCP(Model Context Protocol, AI가 외부 도구를 쓰게 하는 연결 규격) 도구 서버를 묶는 harness가 진짜 애플리케이션입니다. agent 하나에 모든 일을 맡길수록 hallucination(모델이 그럴듯하지만 틀린 내용을 만들어 내는 현상) 위험이 크게 늘어난다는 점도 역할을 나눠야 하는 이유입니다.

즉흥에 맡기면 안 되는 일

agent 시스템 안의 일은 두 종류로 나뉩니다.

• 비결정적인 일(agent 몫): 계획, 추론, 분류, 요약, 다음 단계 고르기, 다시 계획하기
• 결정적인 일(harness 몫): 결제, 클라우드 인프라 프로비저닝, 법적 승인, 규정 감사, 롤백, SLA(서비스 수준 약속) 타이머

뒤쪽은 확률로 움직이는 모델이 지어내거나 즉흥으로 처리해서는 안 되는 일입니다. Kubernetes 클러스터 재시작이 좋은 예입니다. 재시작에는 매번 똑같은 검증과 배포 단계를 정해진 순서로 밟아야 합니다. agent가 클러스터 상태가 나쁘니 재시작이 필요하다고 판단하는 것은 괜찮지만, 재시작을 어떻게 수행할지는 harness가 엄격히 통제해야 합니다. 운영 환경이라면 실행 전에 Slack으로 엔지니어에게 승인을 요청하는 단계도 harness에 들어가야 합니다. 모델이 안전 정책을 알아서 지켜 주리라 믿는 것은 위험하고, 실행 제약은 코드로 보장해야 한다는 판단입니다.

역할을 표로 정리하면 다음과 같습니다.

▲ agent를 감싼 harness 구조

오래 도는 agent에 필요한 내구성

실서비스 agent는 HTTP 요청 하나가 끝나는 동안에 일을 마치지 않습니다. 택배사 응답과 창고 담당자 승인을 며칠, 몇 주씩 기다리는 주문 처리처럼 몇 시간에서 몇 달까지 이어집니다. 그 사이 harness는 사람의 검토를 기다리고, 비동기 이벤트에 반응하고, 정해진 일정에 작업을 실행하고, 서버가 죽어도 복구해야 합니다. 분산 클라우드에서는 네트워크 단절, 컨테이너 중단, 하드웨어 고장이 반드시 일어나기 때문입니다.

그래서 실행 내구성은 있으면 좋은 기능이 아니라 실서비스에 들어가기 위한 최소 조건으로 봐야 합니다. 멈춘 곳에서 정확히 이어 가되 작업을 중복하거나 상태를 잃지 않아야 합니다.

여기에 지켜야 할 원칙이 하나 더 있습니다. 다시 계획하기는 앞으로의 단계만 바꿀 수 있고 과거는 바꾸지 못합니다. 끝난 작업, 이미 일어난 부수 효과, 받은 승인, 드러난 실패는 저장소에 그대로 고정합니다. 예상하지 못한 상황이 생기면 harness가 현재 상태를 agent에게 돌려주고, agent는 그 상태에서 출발하는 새 단계를 계획합니다. 쓸모 있는 제어 루프는 agent 내부의 prompt 사슬이 아니라, 실제 결과가 agent의 피드백이 되는 바깥 경계에 있다는 설명입니다.

계획은 자유롭게, 실행 어휘는 미리 정해 둔다

agent가 실행 중에 계획을 새로 만든다면 harness가 처음 보는 계획의 동작을 어떻게 보장할 수 있을까요. 답은 실행할 수 있는 작업의 어휘를 배포 시점에 미리 등록해 두는 것입니다. 계획은 자유롭지만, 계획에 쓸 수 있는 낱말은 정해져 있습니다. 이를 late-bound saga라고 부릅니다. 전통적인 saga는 사람이 손으로 짠 결정적 작업 흐름이었는데, 여기서는 agent가 등록된 작업 목록에서 실행 시점에 작업을 골라 엮습니다.

등록할 때는 상태를 바꾸는 작업마다 되돌리는 작업을 짝지어 둡니다.

분기형 작업 흐름과의 차이도 분명합니다. 닫힌 세계의 분기형 흐름은 배포할 때 모든 경로를 미리 그려야 하고 계획기는 그중 하나를 고를 뿐입니다. late-bound saga는 여러 도구를 새로운 조합으로 엮을 수 있어, 엔지니어가 앞으로 나올 모든 조합을 하드코딩하지 않아도 됩니다. 실행 시점의 모든 경우를 미리 정해 두는 일은 사실상 불가능하다는 점에서, 이 방식은 유연성과 보장 사이의 현실적인 절충으로 보입니다.

장애 대응 agent는 이렇게 움직인다

이 구조를 장애 대응 agent에 적용한 시연은 흐름을 잘 보여 줍니다. 시연용으로 미리 준비한 시나리오이지만, 절차는 다음과 같습니다.

1. 기존 agent를 harness에 연결합니다. agent의 행동을 등록된 작업에 잇는 데 약 12줄의 코드가 들었습니다.
2. 첫 회차에서 agent가 로그 증거를 살피고 지표를 조회합니다.
3. 모은 맥락을 받은 모델이 실행할 작업 순서를 구조화된 JSON 계획으로 냅니다.
4. 계획을 컴파일하는 도구가 이 계획을 검사할 수 있는 DAG(방향성 비순환 그래프, 단계와 순서를 화살표로 이은 실행 흐름)로 바꾸고 Conductor가 실행합니다.
5. 실패한 서비스 배포를 롤백하고, 지표를 계속 조회해 복구를 확인합니다. 각 단계는 진행 중에서 완료로 바뀌며 실행 기록이 남습니다.
6. 다음 회차에서 agent는 복구된 상태를 보고 롤백이 성공했다고 판단해, 같은 롤백을 반복하지 않고 끝냅니다.

▲ 롤백과 복구 확인 흐름

Conductor는 Netflix에서 처음 만든 오케스트레이션 엔진으로 Apache 2.0 라이선스의 오픈소스이며, 장기 실행 루프와 agent 작업 흐름을 상태를 저장하며 실행합니다. LangChain, OpenAI Agents SDK, 직접 만든 SDK 기반 agent와도 연결됩니다.

지금 점검할 안전장치

판단은 모델에게, 실행은 결정적인 코드에게 맡기는 것이 핵심입니다. 예약·이벤트·장기 실행 agent를 운영하거나 준비하고 있다면 다음을 점검해 볼 만합니다.

• 업무 로직을 모델의 추론 단계와 결정적 작업으로 나누고, 한 prompt 루프에 섞지 않았는지
• 결제, 클러스터 재시작, 규정 집행처럼 되돌리기 어려운 작업을 모델이 직접 실행하지 못하게 막았는지
• agent가 임의 명령을 만들지 못하게 미리 등록한 작업 목록 안에서만 고르게 했는지
• 상태를 바꾸는 작업마다 되돌리는 작업을 정의했는지
• 운영 환경의 위험한 작업 앞에 Slack 승인 같은 사람의 확인 단계를 두었는지
• 끝난 작업과 부수 효과를 바꿀 수 없는 기록으로 남겨, 다시 계획해도 앞으로의 단계만 바뀌게 했는지
• 모델이 낸 계획을 실행 전에 검사할 수 있는 DAG로 바꿔 추적하고 다시 실행할 수 있게 했는지
• 네트워크 단절과 서버 재시작, 긴 대기를 견디는 실행 계층을 갖췄는지