이제 인상적인 AI 에이전트 데모를 만드는 것은 비교적 쉬운 일이 되었습니다.

모델에 몇 가지 지침을 주고, 몇 가지 도구(tools)를 연결하며, 메모리(memory)를 추가하여 다단계 작업(multistep task)을 완료하게 하면 됩니다. 여기에 여러 전문화된 에이전트(agents)를 추가하면 데모는 더욱 매력적으로 변합니다. 한 에이전트는 조사하고, 다른 에이전트는 작성하며, 또 다른 에이전트는 검토하고, 매니저 에이전트(manager agent)가 이들의 작업을 조정하는 식입니다.

하지만 성공적인 데모가 프로덕션 시스템(production system)과 동일한 것은 아닙니다.

어려운 질문들은 보통 에이전트들이 작동하기 시작한 후에 발생합니다:

• 런타임(runtime)에 업데이트가 필요할 때 어떤 일이 발생하나요?
• 에이전트는 재시작 후에도 메모리(memory)를 유지하나요?
• 한 작업자가 차단(blocked)되었을 때 누가 이를 알아차리나요?
• 에이전트가 사람을 개입시키지 않고 책임을 전가할 수 있나요?
• 인간이 모든 대화를 읽지 않고도 여러 에이전트를 어떻게 감독할 수 있나요?
• 사용자가 휴대폰으로 팀에 접속할 수 있나요?
• 타이핑 대신 에이전트와 대화할 수 있나요?
• 각 워크로드(workload)에 대해 어떤 모델이 비용을 지불하나요?
• 개인적인 기록과 자격 증명(credentials)을 복사하지 않고 성공적인 에이전트를 어떻게 복제(clone)하나요?

이것들은 모델의 문제가 아닙니다. 운영(operational)의 문제입니다.

따라서 프로덕션 멀티 에이전트 시스템(multi-agent system)에는 오케스트레이션(orchestration) 로직 이상의 것이 필요합니다. 배포(deployment), 지속성(persistence), 통신(communication), 유지보수(maintenance), 모델 액세스(model access), 복구(recovery), 그리고 인간 에스컬레이션(human escalation)을 위한 관리 계층(management layer)이 필요합니다.

데모는 보통 운영이 시작되는 지점에서 끝납니다

A 전형적인 멀티 에이전트 예시는 해피 패스(happy path, 정상 경로)에 집중합니다.

매니저 에이전트가 목표를 받습니다. 에이전트는 한 작업자에게 조사를, 다른 작업자에게 작성을, 세 번째 작업자에게 검토를 할당합니다. 작업자들이 결과를 반환하면 매니저는 최종 결과물을 조립합니다.

이는 위임(delegation)을 보여주는 데는 유용하지만, 프로덕션 시스템은 해피 패스(happy path) 이외의 상황에서 훨씬 더 많은 시간을 보냅니다.

에이전트가 통합 서비스(integration)에 대한 액세스 권한을 잃을 수도 있습니다. 소프트웨어 업데이트 이후 예약된 프로세스가 실패할 수도 있습니다. 한 작업자(worker)가 다른 에이전트가 소유한 정보를 무한정 기다려야 할 수도 있습니다. 작업이 인간의 승인을 필요로 하는 동작 단계에 도달할 수도 있습니다. 모델 제공업체가 요청을 거부하거나, 사용량 제한(usage limit)을 모두 소모하거나, 일시적으로 서비스가 중단될 수도 있습니다.

실제 배포 환경에서 시스템은 작업이 예상대로 정확히 진행되지 않을 때 어떻게 대응해야 하는지 알고 있어야 합니다.

이것이 바로 프로덕션 준비성(production-readiness)을 평가할 때 최종 답변의 품질뿐만 아니라, 연속성(continuity)과 장애 처리(failure handling)를 중심으로 평가해야 하는 이유입니다.

지속적 상태(Persistent State)는 런타임(Runtime)과 분리되어야 합니다

자율 에이전트는 대화 기록 이상의 것을 축적합니다.

시간이 흐름에 따라 에이전트는 다음과 같은 것들을 발전시킬 수 있습니다:

• 역할 지침 (Role instructions)
• 사용자 선호도 (User preferences)
• 작업 파일 (Working files)
• 장기 기억 (Long-term memory)
• 예약된 작업 (Scheduled jobs)
• 도구 설정 (Tool configurations)
• 자격 증명 (Credentials)
• 대화 기록 (Conversation history)
• 반복되는 프로세스에 대한 지식 (Knowledge about recurring processes)
• 완료 및 대기 중인 작업 기록 (Records of completed and pending tasks)

만약 해당 상태가 단 하나의 런타임 내부에만 존재한다면, 에이전트는 취약해집니다. 런타임을 재시작하거나 교체하면 작업자의 경험이 사실상 삭제될 수 있습니다.

더 나은 아키텍처는 지속적인 작업 공간(persistent workspace)을 일회성 실행 환경(disposable execution environment)과 분리합니다.

이렇게 하면 에이전트가 처음부터 다시 시작할 필요 없이 런타임을 재시작, 업데이트, 교체 또는 이동할 수 있습니다. 에이전트의 지침, 파일, 메모리 및 작업 컨텍스트(working context)는 현재 이를 실행 중인 프로세스와 독립적으로 계속 사용할 수 있는 상태로 유지됩니다.

이는 호스팅된 AI 에이전트 팀(hosted AI agent teams)의 이면에 있는 운영 개념 중 하나입니다. OpenClaw 및 Hermes 에이전트는 중요한 작업 상태를 중단 및 재시작 간에도 유지하면서 관리형 환경에서 실행될 수 있습니다.

이러한 구분은 애플리케이션 데이터와 애플리케이션 컨테이너를 분리하는 것과 유사합니다. 프로세스는 일시적일 수 있지만, 프로세스를 유용하게 만드는 상태는 반드시 살아남아야 합니다.

백업과 클론은 서로 다른 문제를 해결합니다

프로덕션 시스템(Production systems)은 기존 에이전트를 복구하는 것과 동일한 역할을 기반으로 다른 에이전트를 생성하는 것을 구분할 필요가 있습니다.

체크포인트(Checkpoint)나 백업(Backup)은 현재 작업자(Worker)를 보존해야 합니다:

• 메모리 (Memory)
• 대화 내용 (Conversations)
• 현재 파일 (Current files)
• 스케줄 (Schedules)
• 축적된 운영 상태 (Accumulated operating state)

반면 클론(Clone)은 종종 이와 반대되는 동작이 필요합니다.

어떤 기관이 효과적인 고객 지원 에이전트를 생성했고, 다른 고객을 위해 동일한 역할을 배포하고자 한다고 가정해 봅시다. 원본 에이전트의 대화 내용, 자격 증명(Credentials), 개인 메모리, 그리고 과거 작업 내역을 그대로 복사하는 것은 안전하지 않을 것입니다.

대신 깨끗한 클론(Clean clone)은 재사용 가능한 설정만을 재현해야 합니다:

• 역할 지침 (Role instructions)
• 선택된 설정 파일 (Selected configuration files)
• 표준 워크플로 (Standard workflows)
• 승인된 도구 (Approved tools)
• 재사용 가능한 템플릿 (Reusable templates)

새로운 에이전트는 새로운 자격 증명, 메모리, 스케줄, 그리고 대화 내용과 함께 시작해야 합니다.

백업과 클로닝을 별개의 작업으로 취급하면 에이전트 배포를 더욱 재사용 가능하게 만들면서 동시에 더욱 안전하게 만들 수 있습니다.

에이전트 통신은 인간 라우터(Human Router)에 의존할 수 없습니다

에이전트 그룹이 모인다고 해서 자동으로 팀이 되는 것은 아닙니다.

만약 각 에이전트가 격리된 대화 속에서 작동한다면, 인간 사용자가 통신 버스(Communication bus) 역할을 하게 됩니다. 사람은 한 에이전트가 유용한 것을 발견했다는 사실을 알아차리고, 그 정보를 다른 채팅창으로 복사하고, 다음 단계를 할당하며, 작업이 완료되었는지 모니터링해야 합니다.

에이전트가 두 명일 때는 이것이 작동할 수도 있습니다. 하지만 열 명이 되면 비실용적이 됩니다.

진정한 에이전트 팀은 작업자들이 다음과 같은 일을 할 수 있는 내부 통신 계층(Internal communication layer)을 필요로 합니다:

• 작업 위임 (Delegate tasks)
• 소유권 이전 (Transfer ownership)
• 진행 상황 보고 (Report progress)
• 발견 사항 공유 (Share discoveries)
• 정보 요청 (Request information)
• 실패 공지 (Announce failures)
• 차단 요소 에스컬레이션 (Escalate blockers)
• 승인 요청 (Ask for approval)

이 구조는 계층적(Hierarchical)일 수 있습니다. 한 에이전트가 AI CEO 또는 관리자(Manager) 역할을 수행하는 동안, 전문화된 에이전트들이 그 아래에서 작업할 수 있습니다. 관리자는 더 넓은 목표를 유지하고, 작업을 위임하며, 일상적인 의존성을 해결하고, 결과를 수집합니다.

구조는 더 분산화(decentralized)될 수도 있습니다. 에이전트들은 작업을 계속 수행하기에 가장 적합한 전문가에게 직접 업무를 넘길 수 있습니다.

OpenAI의 AI 에이전트 구축을 위한 실무 가이드 (practical guide to building AI agents)는 관리자 주도형 오케스트레이션 (orchestration)과 분산형 핸드오프 (decentralized handoffs)를 모두 설명합니다. 적절한 패턴은 시스템에 하나의 중앙 통제원 (central source of control)이 필요한지, 아니면 전문가 간의 더 직접적인 협업이 필요한지에 따라 달라집니다.

실제로 많은 팀은 이 두 가지를 혼합하여 사용할 것입니다.

가장 중요한 에이전트는 더 적은 일을 하는 에이전트일 수 있습니다

멀티 에이전트 시스템에서 간과되기 쉬운 역할은 커뮤니케이터 에이전트 (communicator agent)입니다.

이 에이전트의 역할은 반드시 조사를 수행하거나, 코드를 작성하거나, 비즈니스 프로세스를 실행하는 것이 아닙니다. 이 에이전트의 역할은 팀을 모니터링하고 인간이 무엇을 알아야 하는지 결정하는 것입니다.

에이전트의 수가 증가함에 따라 이 역할은 필수적이 됩니다.

사람이 지속적으로 작동하는 AI 인력 사이에서 교환되는 모든 메시지를 현실적으로 다 읽을 수는 없습니다. 대부분의 메시지는 일상적일 것입니다:

• 작업이 수락되었습니다.
• 파일이 생성되었습니다.
• 조사가 전달되었습니다.
• 예정된 점검이 성공적으로 완료되었습니다.
• 다른 에이전트가 소유권을 가져갔습니다.
• 결과가 검증되었습니다.

사용자는 일반적으로 각 이벤트를 모두 볼 필요가 없습니다.

커뮤니케이터 에이전트는 이러한 활동을 필터링하여 의미 있는 예외 사항(exceptions)만을 표면화할 수 있습니다:

• 에이전트에게 자격 증명 (credentials)이 필요합니다.
• 작업이 예산을 초과했습니다.
• 두 작업자가 상충하는 결론을 도출했습니다.
• 외부 서비스를 사용할 수 없습니다.
• 고객 대면 작업에 승인이 필요합니다.
• 비즈니스 결정 없이는 팀이 진행할 수 없습니다.

이는 확장 가능한 인간 참여형 (human-in-the-loop) 아키텍처를 생성합니다.

인간은 팀의 디스패처 (dispatcher) 역할을 하는 대신, 예외 사항에 대한 최종 권한자가 됩니다.

에스컬레이션 (Escalation)은 명시적인 규칙을 따라야 합니다

인간에 대한 에스컬레이션은 전적으로 모델의 직관에 맡겨져서는 안 됩니다.

각 에이전트는 다음을 포함하는 정의된 경계를 가져야 합니다:

• 독립적으로 수행할 수 있는 작업 (Actions).
• 절대로 수행해서는 안 되는 작업.
• 승인이 필요한 작업.
• 에스컬레이션 (Escalation)을 트리거하는 조건.
• 각 유형의 의사결정을 어떤 에이전트가 소유하는지.
• 어떤 통신 채널을 사용해야 하는지.

예를 들어, 마케팅 에이전트는 캠페인 카피를 작성할 수는 있지만 이를 게시할 수는 없을 것입니다. 재무 에이전트는 송장을 분석할 수는 있지만 결제를 시작하기 전에는 승인이 필요할 수 있습니다. 지원 에이전트는 일반적인 질문에 답변할 수는 있지만 법적 위협, 환불 분쟁 또는 계정 보안 사고는 에스컬레이션해야 합니다.

작업자(Worker)가 이러한 경계 중 하나에 도달하면, 자신의 AI 매니저에게 알릴 수 있습니다. 매니저는 작업을 재지정하거나, 다른 에이전트에게 도움을 요청하거나, 커뮤니케이터 에이전트에게 사용자에게 연락하도록 지시할 수 있습니다.

이는 인간에게 위험한 동작이 있는지 모든 대화를 지속적으로 모니터링하도록 요청하는 것보다 더 신뢰할 수 있는 방식입니다.

커맨드 센터는 지속적인 감시 없이도 팀을 보여주어야 합니다

내부 통신과 에스컬레이션이 있더라도 사용자는 여전히 가시성 (Visibility)이 필요합니다.

멀티 에이전트 커맨드 센터는 다음 사항들을 이해할 수 있어야 합니다:

• 어떤 에이전트가 실행 중인지.
• 어떤 에이전트가 유휴 (Idle) 상태인지.
• 각 에이전트의 책임 범위가 무엇인지.
• 어떤 에이전트들이 동일한 팀에 속해 있는지.
• 작업이 차단 (Blocked)되었는지 여부.
• 어떤 대화에 주의가 필요한지.
• 각 에이전트가 어떤 모델이나 액세스 방법 (Access method)을 사용하는지.
• 사용량이 얼마나 소비되고 있는지.

Agent Teams Chat Wall은 여러 개의 네이티브 (Native) OpenClaw 또는 Hermes 세션을 한 화면에 로드할 수 있는 공유 인터페이스를 제공합니다.

여기서 중요한 단어는 "네이티브 (Native)"입니다.

관리 계층 (Management layer)이 각 에이전트의 기본 환경을 일반적인 챗봇으로 교체할 필요는 없습니다. OpenClaw 및 Hermes 에이전트는 자신만의 도구, 스케줄, 메모리, 컨텍스트 (Context) 및 서브 에이전트 (Subagents)를 유지할 수 있으며, Chat Wall은 상호작용과 감독을 위한 공통 인터페이스를 제공합니다.

이를 통해 여러 에이전트를 운영하는 데 필요한 노력을 줄이면서도, 기본 하네스 (Harnesses)의 강점을 보존할 수 있습니다.

음성(Voice)은 인간이 에이전트 팀을 감독하는 방식을 변화시킵니다

커맨드 센터(Command center)는 단순히 텍스트 메시지만 지원할 때보다 더 많은 기능을 지원할 때 더욱 유용해집니다.

사용자는 동일한 채팅 월(Chat Wall)에서 서로 다른 에이전트와 대화하고, 음성 응답을 받으며, 그 응답을 텍스트로 읽을 수 있습니다. 상호작용의 기록(written history)을 희생하지 않으면서도 완전한 음성 대화가 가능합니다.

이러한 결합은 매우 중요합니다.

음성은 신속한 감독(supervision)에 있어 편리합니다:

• "출시를 가로막고 있는 것이 무엇인가요?"
• "리서치 에이전트에게 해당 소스를 확인하도록 요청하세요."
• "팀이 밤새 완료한 내용을 요약해 주세요."
• "마케팅 에이전트에게 제가 초안을 승인할 때까지 게시하지 말라고 전달하세요."

텍스트는 정밀한 지시, 링크, 코드, 기록 및 사후 검토를 위해 여전히 가치가 있습니다.

두 가지 방식을 모두 지원하면, 사용자가 음성 비서와 텍스트 기반 운영 대시보드 중 하나를 강제로 선택해야 하는 상황을 방지하고, 다양한 상황에서 커맨드 센터를 사용할 수 있게 만듭니다.

또한 이는 멀티 에이전트 상호작용의 느낌을 변화시킵니다. 사용자는 동일한 화면에서 리서치 에이전트, 개발 에이전트, AI 매니저 사이를 이동할 수 있으며, 이는 서로 관련 없는 채팅 애플리케이션들을 조작하는 것이 아니라 여러 팀원과 대화하는 것에 더 가깝게 느껴집니다.

모바일 접속이 반드시 별도의 앱을 의미할 필요는 없습니다

네이티브 모바일 애플리케이션(native mobile application)은 집중된 경험을 제공할 수 있지만, 모바일 관리로 가는 유일한 경로가 되어서는 안 됩니다.

브라우저 기반의 채팅 월(Chat Wall)은 휴대폰에서 로드될 수 있으며, 사용자가 데스크톱에서 사용하는 것과 동일한 인터페이스를 통해 에이전트에게 글을 쓰거나 말할 수 있도록 합니다.

에이전트 프레임워크(Agent frameworks)는 기존의 게이트웨이(gateways)를 노출할 수도 있습니다. OpenClaw 및 Hermes 에이전트는 Telegram, WhatsApp 및 기타 지원되는 서비스와 같은 채널을 통해 통신할 수 있습니다.

이러한 인터페이스들은 각기 다른 목적을 수행합니다:

• 채팅 월(Chat Wall)은 에이전트, 팀, 대화 및 상태에 대한 전체적인 뷰(view)를 제공합니다.
• 모바일 브라우저는 책상을 벗어난 곳에서도 동일한 커맨드 센터에 접속할 수 있게 합니다.
• 메시징 게이트웨이는 알림을 전달하고 사용자가 이미 확인하고 있는 도구들을 통해 빠른 응답을 가능하게 합니다.

따라서 커뮤니케이터 에이전트 (communicator agent)는 WhatsApp이나 Telegram을 통해 중요한 차단 요소 (blocker)를 표면화할 수 있으며, 사용자는 더 많은 문맥 (context)이 필요할 때 전체 채팅 월 (Chat Wall)을 열 수 있습니다.

소프트웨어 업데이트는 에이전트 신뢰성 (Reliability)의 일부입니다

오픈 소스 (Open-source) 에이전트 시스템은 빠르게 진화합니다.

이를 수동으로 업데이트하려면 다음과 같은 과정이 필요할 수 있습니다:

1. 서버에 접속하기.
2. 최신 버전 가져오기.
3. 의존성 (dependencies) 업데이트하기.
4. 설정 변경 사항 해결하기.
5. 프로세스 재시작하기.
6. 도구 (tools)와 게이트웨이 (gateways)가 여전히 작동하는지 확인하기.
7. 무언가 실패할 경우 이전 배포 (deployment) 상태로 복구하기.

숙련된 개발자에게는 이 과정이 관리 가능할 수 있습니다. 하지만 여러 에이전트를 운영하는 기업에게는 반복적인 운영 오버헤드 (operational overhead)가 됩니다.

또한 이는 위험합니다. 하나의 라이브러리 (library), 인증 흐름 (authentication flow), 또는 환경 변수 (environment variable)를 망가뜨리는 업데이트 하나가 에이전트에게 할당된 모든 작업을 중단시킬 수 있습니다.