상주 에이전트는 역할부터 정해야 했습니다

작업 기록이 쌓이기 시작하니, 다음에는 그 기록을 읽고 일을 이어갈 상주 에이전트를 붙여보고 싶었습니다.

OpenClaw 기반의 오거를 운영하며 메일, 내부 데이터, 자동화 작업을 한 곳에서 정리하려 했습니다. 처음에는 새 도구를 설치하고 설정하면 끝날 줄 알았습니다.

실제 어려움은 이미 돌아가던 것들과의 공존이었습니다.

Hermes를 병렬로 테스트했을 때 Telegram bot이 응답하지 않았습니다. 로그를 보니 같은 token을 이전 gateway와 새 gateway가 동시에 polling하고 있었습니다. 한쪽이 고장 난 것이 아니라, 하나의 bot을 두 프로세스가 잡으려는 충돌이었습니다.

기존 작업 공간과 상태 파일을 그대로 두면 새 에이전트가 오래된 정보를 읽어 혼선을 만들 수도 있었습니다. 그래서 도구 전환은 설치가 아니라 정리의 문제라는 것을 배웠습니다. 이전 프로세스를 확인하고, token과 역할을 분리하고, 무엇을 남기고 무엇을 격리할지를 먼저 정해야 했습니다.

에이전트를 업무별로 나누기 시작하면서 또 다른 문제가 생겼습니다.

메일을 보는 에이전트, 내부 데이터를 보는 에이전트, 자동화를 실행하는 에이전트, 공용 요청을 정리하는 에이전트가 공용 채널에서 동시에 반응하는 일이 생겼습니다. 사용자 입장에서는 누가 최종 답변을 하는지 알기 어려웠습니다.

그래서 전면 창구와 내부 워커를 나눴습니다. 공용 채널에서 최종 답변을 하는 주체는 하나로 두고, 메일·LISA·n8n 같은 전문 작업은 뒤에서만 처리하도록 했습니다. 데이터 조회를 하는 역할, 외부 메시지를 보내는 역할, 전체 운영 규칙을 바꾸는 역할도 가능한 한 분리했습니다.

사람 조직에서도 담당자가 많다고 고객 앞에 모두 나와 말하지는 않습니다.

AI 조직도 비슷했습니다. 역할을 나누는 것만으로는 부족하고, 누가 말하고 누가 실행하고 누가 예외를 판단하는지까지 정해야 덜 복잡해졌습니다.

다음 글에서는 이 과정에서 실패를 어떻게 기록하고, 지금 어떤 기준으로 자동화를 운영하고 있는지 정리해보겠습니다.

역할을 나누는 과정에서 보안과 권한도 같이 보게 됐습니다. 메일 내용을 읽을 수 있는 역할과 내부 데이터를 조회하는 역할, 외부로 메시지를 보낼 수 있는 역할을 한 에이전트에 모두 주는 것은 편해 보이지만, 문제가 생겼을 때 경계를 설명하기 어렵습니다.

그래서 민감한 정보는 가능한 한 내부 처리 단계에 남기고, 외부로 나가는 결과는 필요한 수준으로 줄이거나 사람이 확인하도록 했습니다. 이 방식은 자동화 속도를 조금 늦출 수 있지만, 나중에 더 큰 문제를 막는 쪽이라고 생각합니다.

에이전트가 많아질수록 사람도 새로운 사용법을 배워야 합니다. 어떤 채널에 요청해야 하는지, 어떤 요청은 바로 실행되지 않는지, 결과가 나오기까지 어떤 단계가 있는지를 이해해야 합니다.

그래서 좋은 멀티 에이전트 구조는 내부적으로 복잡해도 사용자 앞에서는 단순해야 한다고 생각합니다. 사용자는 한 곳에 요청하고, 필요한 일이 뒤에서 분리되어 처리되고, 최종 결과만 이해하기 쉬운 형태로 받는 것이 가장 낫습니다.