뇌와 손: 프로덕션 AI 에이전트를 안전하게 운영하는 법

원문 제목: Brains vs Hands: How to Run AI Agents Safely in Production — Viren Baraiya URL: https://www.youtube.com/watch?v=NaOkR3VSfR4 날짜: 2026-10-09 채널: aiDotEngineer

📌 핵심 질문 / 프로덕션 에이전트의 안전한 실행을 어떻게 보장할 것인가

==LLM 에이전트는 다음에 무엇을 해야 할지 계획하고, 결정론적 하니스(harness)는 그 계획을 통제된 방식으로 실행해야 한다.==

• LLM의 추론은 비결정론적이므로 계획 수립에 적합하지만, 결제·클러스터 재시작·승인 게이트 같은 실행을 맡기면 환각이 실제 부작용으로 이어질 수 있다.
• 하니스는 에이전트, 데이터베이스, 내부·기업 시스템, API·MCP 도구, 사람의 승인 절차를 하나의 애플리케이션으로 묶고 상태·부작용·복구를 관리한다.
• 장기 실행·이벤트 기반·스케줄 기반 에이전트는 네트워크 장애와 인프라 중단을 견디는 내구성(durability), 가시성, 멱등성 또는 부작용 기록을 기본 조건으로 가져야 한다.

챗봇 하나를 만드는 문제를 넘어, 여러 전문 에이전트와 결정론적 워크플로를 조합해 비즈니스 목표를 달성하는 애플리케이션을 설계해야 한다. 핵심 분리는 ‘뇌(brains)’와 ‘손(hands)’이다. LLM이 계획을 쓰고 하니스가 계획을 실행하면, 에이전트의 유연성과 전통적 워크플로의 통제력을 함께 얻을 수 있다.

1. 에이전트의 범위를 챗봇에서 애플리케이션으로 확장하기

에이전트의 프로덕션 역할은 대화형 인터페이스에 한정되지 않으며, 하니스가 애플리케이션의 실행 경계를 만든다.

1.1. ‘헬로 월드’ 에이전트와 실제 운영 환경의 차이

1. 초기 에이전트 예제의 좁은 시야

   1. 도구 호출 중심 구조: LLM이 어떤 도구를 호출할지 결정하고, 문맥이나 메모리를 활용해 앞선 계획을 세우는 형태가 에이전트의 기본 예제로 널리 사용된다.
   2. 챗봇 편중: 초기 사례는 고객 서비스 챗봇이나 유사한 대화형 봇을 만드는 데 집중했다.
   3. 프로덕션의 더 넓은 문제: 실제 운영에는 대화 응답뿐 아니라 지속적인 감시, 이벤트 반응, 외부 시스템 조정, 사람의 승인, 장기 상태 관리가 필요하다.

2. 프로덕션 에이전트의 다양한 형태

   1. 백그라운드 에이전트와 워커: 사용자와 대화하지 않고 뒤에서 작업을 수행하는 에이전트가 존재한다.
   2. 스케줄 기반 에이전트: 매시간 일정(schedule)을 확인하고 새로 생긴 중요한 항목을 알려주는 에이전트처럼 정해진 주기에 실행되는 형태가 있다.
   3. 이벤트 기반 에이전트: 프로덕션 시스템에서 간헐적으로 발생하는 알림과 로그를 수신해 현재 상황을 파악하고 대응한다.
   4. 장기 실행 코디네이터: 오랫동안 실행되는 에이전트의 진행 상태를 다른 에이전트가 감시하고, 계속 진행하도록 독려하거나 다른 행동을 취하도록 유도한다.
   5. 멀티 에이전트 시스템: 에이전트끼리 서로 대화하고 역할을 나눈다. 한 에이전트에 여러 업무를 맡기면 책임 범위가 넓어져 환각 위험이 커지므로 피해야 한다.

1.2. 에이전트와 마이크로서비스의 구조적 유사성

1. 단일 책임의 원칙

   1. 만능 마이크로서비스의 문제: 모든 일을 하나의 마이크로서비스가 처리하면 더 이상 마이크로서비스라고 부르기 어렵다.
   2. 서비스 조합: 여러 마이크로서비스가 choreography 또는 orchestration으로 서로 대화하고, 각각 단일 책임을 수행하며 비즈니스 목표를 전달한다.
   3. 에이전트 적용: 각 에이전트도 특정 책임을 맡고, 하니스가 여러 에이전트를 결합해 하나의 목표를 달성하게 해야 한다.

2. 하니스가 애플리케이션이 되는 순간

   1. 목표 중심 하니스: SRE 작업을 수행하는 하니스처럼 특정 목표를 책임지는 실행 틀을 만든다.
   2. 정보 수집과 조정: 로깅 시스템에서 이벤트를 받고, 에이전트를 통해 Kubernetes 클러스터와 통신하며, 메트릭 시스템과 고객 서비스 대시보드를 함께 조회한다.
   3. 전체 전제의 완성: 에이전트 하나만으로는 애플리케이션의 목적을 충족하지 못한다. 여러 구성 요소를 모으고 에이전트 실행을 제어하는 하니스를 만들 때 애플리케이션이 완성된다.
   4. 통합 경계: 데이터베이스, 내부 시스템, 기업용 시스템, 사람의 개입(human in the loop), API·MCP를 통한 도구가 한 애플리케이션 안에서 함께 작동한다.

2. 하니스가 제공해야 할 운영 특성

하니스는 단순한 에이전트 루프가 아니라 결정론적 코드와 비결정론적 추론을 결합한 장기 실행 시스템이다.

2.1. 결정론과 비결정론의 경계

1. 두 종류의 실행 요소

   1. 비결정론적 영역: LLM이 추론하고 사고하며 현재 상태에서 다음에 무엇을 할지 제안한다.
   2. 결정론적 영역: 실제 작업을 수행하는 순서, 권한, 승인, 재시도, 부작용 처리를 코드로 고정한다.
   3. 경계의 필요성: 결제 시스템처럼 결과가 매번 달라져서는 안 되는 영역에는 LLM의 비결정론이 스며들지 않아야 한다.

2. Kubernetes 재시작 사례

   1. LLM의 판단: SRE 에이전트가 클러스터가 비정상이라고 판단하고 재시작을 제안할 수 있다.
   2. 하니스의 실행: 클러스터 재시작에 필요한 절차와 순서를 하니스가 정하고, 실행할 때마다 동일한 과정을 보장한다.
   3. 사람의 승인: 프로덕션 클러스터라면 Slack으로 담당자에게 재시작 여부를 묻는 human gate를 반드시 거친다.
   4. 환각 차단: 승인 단계가 필요한지 여부를 LLM의 환각에 맡기지 않는다. 실행 경로에 승인 게이트를 결정론적으로 넣어야 한다.
   5. 멱등성과 부작용: 이상적으로 재시작 절차는 멱등적이어야 한다. 멱등적이지 않다면 그 사실과 실제 발생한 일을 기록해 부작용을 별도로 관리한다.

2.2. 장기 실행과 내구성

1. 실행 시간의 범위

   1. 짧은 실행: 현재 상황을 확인하는 몇 초짜리 작업도 하니스가 맡을 수 있다.
   2. 긴 실행: 며칠, 몇 달 또는 그 이상 실행되는 프로세스도 같은 하니스 모델로 다룬다.
   3. 주문 관리 사례: 외부 서비스가 배송을 완료하기를 기다리거나, 사람이 조치를 취하고 승인하기를 기다리는 동안 하니스가 상태를 유지한다.
   4. 이벤트 대기: 하니스가 아무 작업도 하지 않고 이벤트를 기다리다가 이벤트가 발생하면 그에 맞는 작업을 실행할 수 있다.

2. 내구성은 선택 기능이 아니다

   1. 복구 가능성: 클라우드나 샌드박스에서 실행되는 하니스는 인프라가 올라갔다 내려갈 수 있으므로 장애 후 복구할 수 있어야 한다.
   2. 장애 유형: 네트워크 장애, 네트워크 파티셔닝, 실행 환경 중단 등 다양한 실패를 전제로 삼는다.
   3. 기본 입장 조건: 내구성(durability)은 차별화 기능이 아니라 비용을 지불하고 입장하기 위한 기본 조건(table stakes, cost of admission)이다.
   4. 범위: 하니스가 실행하는 루프는 LLM 에이전트뿐 아니라 에이전트 외부의 모든 시스템과 작업까지 포괄한다.

2.3. 상태와 부작용을 기반으로 다음 행동 결정하기

1. 하니스가 유지하는 세계의 상태

   1. 완료된 작업: 현재까지 어떤 작업이 완료됐는지 기록한다.
   2. 부작용 기록: 클러스터 재시작을 실행했는지, 이메일을 전송했는지처럼 외부에 남은 side effect를 기록한다.
   3. 성공과 실패: 각 단계가 성공했는지 실패했는지 알고 있어야 한다.

2. 상태에서 계획으로 이어지는 루프

   1. 다음 작업 계산: 현재 세계의 상태와 최종 목표를 비교해 다음에 무엇을 해야 할지 정한다.
   2. LLM의 역할: 상태와 목표 사이의 간극을 바탕으로 다음 계획을 세우는 지점에서 추론과 LLM이 사용된다.
   3. 실행의 역할 분담: LLM은 계획을 만들고, 하니스는 계획에 포함된 작업을 실제로 수행한다.

3. ‘뇌와 손’ 분리로 안전한 실행 만들기

비결정론적 에이전트의 책임은 행동 자체가 아니라 다음 행동의 계획이며, 결정론적 하니스가 실행을 책임져야 한다.

3.1. 핵심 분리: LLM은 뇌, 하니스는 손

1. 계획과 실행의 구분

   1. 뇌(brains): LLM은 무엇을 해야 하는지, 다음 단계가 무엇인지 계획한다.
   2. 손(hands): 하니스는 계획을 받아 실제 도구와 시스템을 호출하고 정해진 절차를 실행한다.
   3. 안전 효과: LLM의 창의적·비결정론적 추론은 유지하면서도 실행의 순서와 승인, 권한, 결과 기록은 통제할 수 있다.

2. 하니스가 실행을 소유해야 하는 이유

   1. 실행 지식: 하니스는 작업을 수행하는 데 필요한 구체적 절차를 이해하는 결정론적 코드다.
   2. 동일한 결과: 같은 종류의 클러스터 재시작은 매번 정확히 같은 프로세스로 수행되어야 한다.
   3. 보장된 게이트: 프로덕션 재시작에 필요한 사람의 승인을 LLM이 생략하지 못하도록 실행 코드가 보장한다.
   4. 감사 가능성: 멱등성이 없더라도 무슨 일이 일어났는지 기록하면 외부 효과를 추적하고 별도의 보정 처리를 할 수 있다.

3.2. 새로운 발명이 아닌 ‘후기 바인딩 사가’

1. 전통적 사가(saga)와의 연속성

   1. 기존 워크플로: 전통적인 사가는 개발자가 발생할 일을 미리 작성하고 정의한 결정론적 프로세스 집합이다.
   2. 공통 이점: 실행 가시성, 현재 진행 상황 파악, 실행 제어, 실패와 부작용 관리가 가능하다.

2. 에이전트 하니스의 후기 바인딩

   1. 유한한 도구와 작업: 하니스가 사용할 수 있는 도구와 수행 가능한 작업의 범위는 미리 제한하고 결정론적으로 정의한다.
   2. 런타임 구성: 사가의 모든 단계를 처음부터 조합해 두는 대신, 에이전트가 런타임에 필요한 순서를 제안하고 하니스가 그 구성을 만든다.
   3. 계획 범위 조절: 한 번에 한 단계만 계획할 수도 있고, 여러 단계의 앞선 계획을 한꺼번에 세울 수도 있다.
   4. 분기 워크플로: 가능한 모든 분기 조합을 미리 워크플로로 작성하는 대신, 에이전트가 현재 상황에 맞는 분기를 선택해 구성한다.
   5. 조합 수의 증가: 사용 가능한 도구가 n개라면 실행 조합도 n가지 이상으로 늘어날 수 있어 모든 경우를 사전에 예측하기 어렵지만, 에이전트는 이 구성을 런타임에 단순화한다.

4. SRE 에이전트 데모: 계획을 결정론적 워크플로로 컴파일하기

SRE 에이전트가 장애를 조사하고 복구하는 과정을 계획·컴파일·실행·검증 루프로 분리한다.

4.1. 두 번의 remediation loop

1. 첫 번째 반복

   1. 현재 시스템 파악: 에이전트가 현재 시스템에 무슨 일이 일어나는지 이해한다.
   2. 근본 원인 조사: 문제의 root cause를 파악하려고 로그와 시스템 상태를 조사한다.
   3. 대응 실행: 원인에 맞는 조치를 취한다.
   4. 결과 관찰: 조치 후 시스템의 출력을 관찰하고 어떤 단계가 완료됐는지 확인한다.

2. 두 번째 반복

   1. 새 상태 확인: 첫 번째 대응 이후의 세계 상태를 다시 읽는다.
   2. 다음 단계 계획: 남은 문제와 목표를 기준으로 다음 실행 단계 묶음을 계획한다.
   3. 다운스트림 점검: downstream 시스템을 확인하고 필요하면 복구를 검증한다.
   4. 중복 실행 방지: 첫 번째 반복에서 이미 롤백을 수행했다면 두 번째 반복에서는 롤백하지 않는다.

4.2. 계획 및 컴파일(Plan and Compile)

1. LLM 출력

   1. 단계 묶음 제안: LLM은 한 단계만 제안하지 않고 증거 수집, 로그 분석, 필요 시 배포 롤백, 복구 검증으로 이어지는 실행 순서를 제시한다.
   2. 데모의 조건: 시연을 위해 입력과 실행이 미리 계획된 상태였지만, 계획을 하니스로 넘기는 구조와 루프의 상태 갱신을 확인할 수 있다.

2. 결정론적 컴파일

   1. 전용 도구: 에이전트가 만든 계획을 ‘plan and compile’이라는 특수 도구에 전달한다.
   2. 워크플로 생성: 계획이 결정론적 워크플로로 컴파일된다.
   3. 실행 엔진: Conductor를 워크플로 실행 엔진으로 사용해 완전히 실행 가능한 워크플로를 만든다.

4.3. 실행·검증·반복

1. 첫 실행 단계

   1. 증거 수집과 분석: 로그를 분석하고 메트릭 쿼리를 확인한다.
   2. 복구 조치: 증거에 따라 배포 롤백을 결정하고 롤백을 수행한다.
   3. 복구 검증: 복구가 실제로 완료됐는지 검증한다.

2. 다음 상태에서의 실행

   1. 완료 상태 반영: 다음 반복은 로그 분석, 메트릭 확인, 롤백과 검증이 완료됐다는 상태를 확인한다.
   2. 남은 확인 수행: 다운스트림 시스템을 점검하고 필요한 경우 복구를 다시 검증한다.
   3. 루프 종료: 필요한 작업이 끝나면 다음 실행 단계가 작업을 완료하고 전체 루프가 종료된다.

3. 프로덕션 트리거

   1. 반복 실행: 같은 루프를 프로덕션에서 필요한 횟수만큼 실행할 수 있다.
   2. 이벤트 트리거: 알림이나 로그 같은 이벤트가 발생했을 때 루프를 시작할 수 있다.
   3. 스케줄 트리거: 정해진 일정에 따라 루프를 시작할 수 있다.
   4. 장기 지속: 전체 과정은 짧은 실행으로 끝날 수도 있고 훨씬 긴 기간 동안 계속 실행될 수도 있다.

5. Conductor와 운영 적용

Conductor는 에이전트 루프의 유연한 계획과 프로덕션 워크플로의 결정론적 실행을 연결하는 오픈소스 오케스트레이션 플랫폼이다.

5.1. 플랫폼의 역할

1. 워크플로 오케스트레이션

   1. 오픈소스 엔진: Conductor는 에이전트 루프와 에이전트 시스템 구축을 지원하는 완전한 오픈소스 워크플로 오케스트레이션 플랫폼이다.
   2. 실행 가능한 결과: LLM이 만든 계획을 결정론적이고 실행 가능한 워크플로로 바꿔 상태, 실행 순서, 반복을 관리한다.
   3. 에이전트 호환성: LangChain 에이전트, OpenAI 에이전트 등 종류와 무관하게 다양한 에이전트를 실행할 수 있다.

2. Orkes의 제공 범위

   1. 엔터프라이즈 에디션: Orkes가 Conductor의 엔터프라이즈 에디션을 제공한다.
   2. 후속 지원: Slack 커뮤니티 참여, 부스 방문, 라이브 데모 확인, 질문 상담이 제공된다.

주요 발언 모음

“비결정론적 에이전트의 책임은 무엇을 해야 할지 계획하는 것이지, 직접 실행하는 것이 아니다.”

“하니스는 손이고, 뇌는 LLM이다.”

“하니스는 애플리케이션이고, 그 반대도 마찬가지다.”

“내구성은 하니스에서 찾는 특별한 기능이 아니라 비용을 지불하고 입장하기 위한 기본 조건이다.”

“에이전트 기반 하니스는 본질적으로 후기 바인딩된 사가다.”

핵심 데이터 & 수치

• 발표 시간: 프로덕션 에이전트 운영을 다루는 15~20분 세션으로 구성됐다.
• 청중 반응: 현재 프로덕션에서 에이전트를 운영하는 사람이 많이 손을 들었고, 몇 주 전 다른 컨퍼런스에서 같은 질문을 했을 때는 한 명 정도만 손을 들었다.
• 실행 시간: 하니스는 몇 초짜리 확인 작업부터 며칠·몇 달·그 이상의 장기 프로세스까지 실행한다.
• 도구 조합: 사용 가능한 도구가 n개이면 런타임에 다양한 실행 조합을 구성할 수 있어 모든 조합을 사전에 작성하기 어렵다.
• 데모 반복 횟수: SRE remediation loop는 첫 번째 반복에서 원인을 조사하고 대응·관찰한 뒤, 두 번째 반복에서 다운스트림과 복구 상태를 확인하는 두 번의 루프로 진행됐다.

결론 및 시사점

1. LLM을 시스템의 손으로 사용하지 말고, 다음에 무엇을 할지 제안하는 뇌로 제한한다.
2. 하니스에 실제 실행, 승인 게이트, 권한, 순서, 재시도, 멱등성, 부작용 기록을 맡긴다.
3. 에이전트를 챗봇이나 단일 구성 요소가 아니라 여러 시스템과 사람을 연결하는 애플리케이션으로 설계한다.
4. 하니스의 상태에 완료 작업, 성공·실패, 이메일 발송·클러스터 재시작 같은 부작용을 기록한다.
5. 내구성을 기본 조건으로 삼고, 클라우드·샌드박스 중단과 네트워크 장애 후에도 장기 실행을 복구할 수 있게 한다.
6. 전통적 사가의 가시성과 통제력을 유지하면서, 에이전트가 런타임에 분기와 실행 순서를 선택하도록 후기 바인딩 구조를 사용한다.
7. SRE 사례처럼 계획을 실행 가능한 결정론적 워크플로로 컴파일하고, 실행 결과를 검증한 뒤 다음 상태에서 다시 계획한다.
8. 이벤트 기반·스케줄 기반·장기 실행 트리거를 모두 고려해 실제 운영 환경의 반복 루프를 설계한다.

핵심 요약 (20줄)

1. 프로덕션 AI 에이전트의 안전한 운영은 LLM의 계획과 하니스의 실행을 분리하는 데서 시작된다.
2. 도구 호출과 메모리를 다루는 챗봇형 예제만으로는 실제 운영 에이전트의 범위를 설명할 수 없다.
3. 백그라운드 워커와 스케줄 기반 에이전트는 사용자 대화 없이도 지속적인 업무를 수행한다.
4. 이벤트 기반 에이전트는 알림과 로그를 감지하고 시스템 상태에 맞는 대응을 계획한다.
5. 장기 실행 코디네이터는 다른 에이전트의 진행을 감시하고 필요한 시점에 행동을 독려한다.
6. 여러 업무를 한 에이전트에 몰아주면 책임 범위와 환각 위험이 함께 커진다.
7. 특정 책임을 가진 여러 에이전트를 하니스로 조합하면 하나의 애플리케이션이 된다.
8. 하니스는 데이터베이스와 기업 시스템, 사람의 승인, API와 MCP 도구를 함께 연결한다.
9. LLM은 추론과 계획에서 비결정론을 제공하고 하니스는 실행에서 결정론을 제공한다.
10. 결제나 Kubernetes 클러스터 재시작 같은 작업은 매번 같은 절차로 실행되어야 한다.
11. 프로덕션 재시작에 필요한 Slack 승인 게이트를 LLM의 판단에 맡겨서는 안 된다.
12. 실행 절차는 이상적으로 멱등적이어야 하며 불가능하면 부작용과 발생 결과를 기록해야 한다.
13. 하니스는 몇 초짜리 확인부터 며칠과 몇 달 이상 지속되는 프로세스까지 관리한다.
14. 장기 실행 하니스는 네트워크 장애와 인프라 중단 뒤 복구할 수 있는 내구성을 기본으로 가져야 한다.
15. 현재 완료 작업과 외부 부작용, 성공과 실패를 기록하면 다음 계획의 근거가 생긴다.
16. 에이전트 하니스는 전통적 사가의 통제력을 유지하면서 실행 조합을 런타임에 정하는 후기 바인딩 사가다.
17. 사용 가능한 도구가 n개이면 미리 예측하기 어려운 실행 조합을 에이전트가 런타임에 구성할 수 있다.
18. SRE 에이전트는 증거 수집과 로그 분석 뒤 필요하면 롤백하고 복구를 검증한다.
19. Plan and Compile 도구는 LLM의 계획을 Conductor에서 실행 가능한 결정론적 워크플로로 변환한다.
20. 이벤트·스케줄·장기 실행 트리거와 상태 기반 검증을 결합하면 유연하면서 통제 가능한 운영 루프가 완성된다.