AI Agent Store의 에이전트 팀 vs Grok Bot, OpenAI dot, Muse: 자신만의 자율 에이전트 스택 선택하기

제품을 구축하는 것은 코드를 작성하는 것 이상의 일을 포함합니다.

누군가는 여전히 출시 버전을 테스트하고, 문서를 업데이트하며, 유용한 콘텐츠를 게시하고, 고객에게 답변하고, 관심 있는 사용자들을 후속 조치하며, 피드백을 다음 개선 사항으로 전환해야 합니다.

솔로 창업가나 소규모 스타트업의 경우, 이는 흥미로운 질문을 던집니다. 하나의 AI 비서(assistant)를 선택해야 할까요, 아니면 사업의 여러 부분을 처리할 수 있는 자율 작업자 팀을 구축해야 할까요?

Grok Bot, OpenAI dot, Muse, 그리고 AI Agent Teams 모두 이 대화에 속합니다. 하지만 단순히 그 기반 모델의 지능만으로 비교하는 것은 중요한 차이점을 놓칩니다.

에이전트가 어떻게 작동할지 결정할 수 있는 자유도가 얼마나 되며—시작하는 데 얼마나 적은 노력이 필요한가?

AI Agent Store의 AI Agent Teams는 관리형 에이전트 호스팅과 공유 작업 공간으로 이 문제를 접근합니다. 그 제안은 간단합니다. 간단하게 시작하고, 필요에 따라 다른 에이전트 소프트웨어, 모델 및 도구를 선택할 수 있는 능력을 유지하는 것입니다.

고지 사항: 저희는 AI Agent Store에서 AI Agent Teams를 구축했습니다. 이 글은 그 뒤에 숨겨진 설계 선택과 그것들이 유용할 수 있는 곳을 설명합니다. 아래의 워크플로우는 벤치마크 결과가 아닌 예시적인 것입니다.

먼저, 운영 모델을 비교해 봅시다

네 가지 제품들은 중복되지만, 시작 지점은 다릅니다.

마찬가지로, OpenAI의 dot 문서는 지속적인 책임에 대해 설명하고 있으며, Meta의 Muse 발표는 앱이 닫힌 후에도 작업을 수행하고 계속 작동하는 에이전트를 설명합니다.

AI 에이전트 팀을 지지하는 근거는 대안들이 단순히 채팅봇이라는 것이 아닙니다.

이는 모든 역할에 대해 제공업체 관리형 에이전트 경험 중 하나를 선택하는 대신, 작업에 맞춰 기반 팀을 구성할 수 있다는 것입니다.

모델은 에이전트의 일부일 뿐입니다

개발자들은 이미 프로그래밍 언어를 선택하는 것이 전체 애플리케이션을 결정하지 않는다는 것을 이해하고 있습니다.

에이전트에도 같은 구분이 적용됩니다.

모델은 추론(reasoning)과 생성(generation)에 기여합니다. 주변 소프트웨어는 모델이 도구를 사용하는 방법, 컨텍스트를 처리하는 방법, 파일과 상호작용하는 방법, 그리고 작업을 통해 지속적으로 작동하는 방법을 결정합니다.

이러한 주변 소프트웨어를 종종 **에이전트 하네스(agent harness)**라고 부릅니다.

LangChain의 에이전트 하네스 설명은 이 구분을 다루고 있습니다: 유용한 에이전트 동작은 모델 자체뿐만 아니라 모델 주변 시스템에 달려 있다는 것입니다.

결과적으로 동일한 모델을 사용하는 두 에이전트는 서로 다른 도구, 메모리, 지침 및 실행 루프를 가지고 있기 때문에 다르게 행동할 수 있습니다.

창업자에게 이것은 “어떤 모델을 사용해야 할까요?”라는 질문이 절반의 문제에 불과하다는 것을 의미합니다.

나머지 절반은 다음과 같습니다: “어떤 환경이 이 작업자가 자신의 임무를 완수하도록 도울 수 있을까요?”

OpenClaw가 적합한 이유

OpenClaw는 Clawdbot 및 Moltbot으로 알려졌던 프로젝트에서 발전했습니다. 공식 소개에서는 이러한 명명 이력과 오픈 소스 개인 비서로서 프로젝트의 광범위한 방향을 설명합니다.

중요한 아이디어는 단순히 사람이 다음에 무엇을 해야 할지 설명하는 것 이상으로, 도구 및 서비스와 상호 작용할 수 있는 에이전트입니다.

이는 OpenClaw가 반복적인 운영 작업에 유용함을 보여줍니다: 워커는 자신의 환경을 사용하고, 유용한 컨텍스트를 유지하며, 다음 단계를 수행해야 합니다.

Hermes의 적합성

Hermes Agent는 Nous Research에서 나왔습니다. 이 에이전트의 문서는 지속적인 메모리(persistent memory), 재사용 가능한 기술(reusable skills), 예약된 작업(scheduled work), 그리고 경험을 통해 절차를 생성하고 개선할 수 있는 학습 루프(learning loop)를 강조합니다.

이는 반복되지만 매번 동일하지 않은 작업을 수행하는 경우에 특히 흥미롭습니다.

예를 들어, 고객 문제를 조사하는 워커는 매주 같은 진단 과정을 재발견할 필요가 없어야 합니다.

어떤 하네스(harness)도 만능의 승자로 취급되어서는 안 됩니다. 그들의 기능은 중복되며, 최적의 선택은 작업 흐름에 따라 달라집니다.

유용한 자유란 둘 다를 사용할 수 있다는 것입니다.

워커별로 하네스와 모델을 선택하기

AI Agent Teams는 OpenClaw와 Hermes를 같은 팀에서 지원하며, 개별 워커에 대한 지원되는 모델 선택지를 제공합니다.

전체 비즈니스를 하나의 조합으로 표준화할 필요가 없습니다.

가능한 설정으로는 시간이 지남에 따라 절차가 발전하는 연구 역할을 위해 Hermes를 사용하고, 기존의 운영 도구 세트를 사용하는 워커를 위해 OpenClaw를 사용하며, 각각 다른 모델을 사용하는 것이 있습니다.

이것은 테스트하기 위한 시작 가설일 뿐이며, 어느 하네스가 본질적으로 해당 작업에만 제한된다는 주장은 아닙니다.

동일한 논리가 모델 지출에도 적용됩니다. 어려운 디버깅 작업과 일상적인 분류 작업이 반드시 동일한 모델을 정당화하는 것은 아닙니다.

다른 모든 것을 재설계하지 않고 개선이 필요한 워커를 개선하세요.

결정적으로, 이러한 유연성은 시작하기 전에 별도의 서버를 유지해야 한다는 의미는 아닙니다. 관리형 호스팅(Managed hosting)은 주변 인프라를 제공하며, 추가적인 선택지들은 필요할 때 여전히 사용할 수 있습니다.

자율성이란 성장하는 초안 폴더가 아니라 완료된 작업을 의미해야 한다

창업자가 20개의 제안을 생성하고 뒤에 20개의 실행 과제를 남기는 에이전트로부터 많은 역량을 얻지는 못합니다.

위임의 유용한 단위는 완성된 작업입니다.

개발자에게는 변경 사항 구현, 테스트 실행, 승인된 배포 프로세스를 통한 배포, 그리고 실제 결과를 확인하는 것을 의미할 수 있습니다.

출판 담당자에게는 고객 질문 조사, 독창적인 기사 작성, 주장 검토, 게시, 회사 채널을 통한 배포, 결과 기록 등을 의미할 수 있습니다.

고객 지원 담당자에게는 일상적인 요청 해결, 고객 기록 업데이트, 반복되는 제품 문제 개발팀에 전달하는 것을 의미할 수 있습니다.

Agent Teams를 통해 우리가 목표로 하는 것은 최대의 실질적 자율성입니다: 창업자가 방향을 설정하고; 작업자들이 할당된 권한 내에서 실행합니다.

이것은 에이전트가 실수하지 않는 척한다는 의미가 아닙니다. 이는 창업자가 모든 평범한 단계를 승인하는 대신 워크플로우 내에 검사를 넣는다는 것을 의미합니다.

유용한 작업 개요(job brief)는 다음과 같을 수 있습니다:

온보딩 도움말 콘텐츠 개선 담당. 연결된 지원 받은 편지함에서 반복되는 질문을 찾고, 각 답변을 제품과 대조하여 누락된 도움말 페이지를 문서화 시스템에 게시합니다. 게시하기 전에 링크와 예시를 검증합니다. 중복 생성을 하기보다는 기존 페이지를 업데이트합니다. 게시된 URL과 해결되지 않은 문제를 기록합니다. 새로운 비즈니스 정책이나 접근 권한이 필요할 때만 저에게 질문합니다.

이것은 기술적 설정 파일이 아니라 일반 언어의 책임(responsibility)입니다.

이는 결과, 출처, 허용되는 작업 및 예외를 식별합니다. 작업자는 루프를 닫는 책임을 집니다.

반드시 강제되어야 하는 제한 사항의 경우, 프롬프트 내 지침뿐만 아니라 도구에서 사용 가능한 실제 권한과 지출 통제를 사용해야 합니다.

실용적인 세 명의 작업자 스타트업

작동하는 제품은 있지만 주변에 할애할 시간이 제한적인 소규모 소프트웨어 비즈니스를 가정해 봅시다.

즉시 정교한 AI 조직을 만드는 대신, 세 가지 책임부터 시작하세요.

1. 개선 사항을 배포하는 제품 담당자

이 워커에게 애플리케이션의 정의된 부분에 대한 책임을 부여합니다.

예를 들어, 재현 가능한 온보딩 문제를 조사하고, 수정 사항을 구현하며, 회귀 테스트(regression test)를 추가하고, 릴리스 검사(release check)를 실행하며, 허가된 파이프라인을 통해 배포하고, 영향을 받은 흐름을 검증하는 임무가 있을 수 있습니다.

그 완료 보고서에는 증거가 포함되어야 합니다: 변경 사항, 검사 결과, 그리고 실제 작동 결과입니다.

창업자는 열정적인 “완료했습니다(Done).”라는 말만 듣고 무슨 일이 일어났는지 재구성할 필요가 없어야 합니다.

2. 발행 및 배포 워커 (A publishing and distribution worker)

이 워커는 실제 고객 질문과 제품 개선 사항을 유용한 자료로 만듭니다.

연구부터 출판까지의 순서를 소유할 수 있으며, 여기에는 출처 확인, 필요한 경우 스크린샷이나 예시 추가, 관련 오래된 페이지 업데이트, 그리고 승인된 채널을 통해 완성된 자료를 배포하는 것이 포함됩니다.

목표는 가능한 최대량의 생성 콘텐츠가 아닙니다. 읽을 가치가 있는 자료를 생산하는 반복 가능한 프로세스입니다.

3. 고객 및 성장 워커 (A customer and growth worker)

이 워커는 관심 있는 사용자들의 일상적인 질문에 답하고, 적절할 때 후속 조치를 취하며, 기록을 업데이트하고, 반복되는 반대 의견이나 혼란스러워하는 지점을 식별합니다.

반복되는 반대 의견은 제품 워커의 임무가 될 수 있습니다. 반복되는 질문은 발행 워커의 주제가 될 수 있습니다.

이것이 피드백 루프(feedback loop)를 만듭니다:

고객 질문 → 제품 또는 콘텐츠 개선 → 출판된 결과 → 고객 후속 조치.

이들은 제안된 작업 흐름이며, 모든 통합이 접근 권한이나 테스트 없이 작동한다는 약속은 아닙니다. 중요한 설계 선택은 각 워커에게 대화의 단편(fragment)이 아닌 결과(result)에 대한 책임을 부여하는 것입니다.

창업자 주도 비즈니스(creator-led business)는 생산, 배포, 그리고 오디언스 또는 고객 운영과 같은 다양한 역할을 사용하여 동일한 패턴을 활용할 수 있습니다.

협업 자체가 병목 현상이 될 때, 리드 에이전트(lead agent)가 우선순위와 인계(handoffs)를 추적하고, 커뮤니케이터 에이전트(communicator agent)는 창립자에게 간결한 브리핑을 제공할 수 있습니다. 거대한 계층 구조부터 시작할 필요는 없습니다.

간단한 설정이 고정된 상한선을 의미하지 않다

기본적인 시작점은 작업을 설명하거나 준비된 설정을 선택하고, 작업에 필요한 계정을 연결하며, 워커(worker)를 실행하는 것입니다.

유용한 작업을 할당하기 전에 모든 네이티브(native) 설정을 이해할 필요는 없습니다.

추가 제어 기능들은 실제 필요가 생길 때 나중에 중요해집니다.

어쩌면 워커가 다른 모델을 필요로 할 수도 있습니다. 어쩌면 프로세스가 재사용 가능한 스킬(skill)로부터 이점을 얻을 수도 있습니다. 어쩌면 에이전트에게 설명하도록 요청하는 대신 파일을 검사해야 할 수도 있습니다.

초보자는 처음에 그러한 세부 사항들을 무시할 수 있어야 합니다. 개발자는 필요할 때 그것들에 도달할 수 있어야 합니다.

그것이 사용하기 쉬운(simple to use) 것과 설계상 제한적인(limited by design) 것의 차이입니다.

대화뿐만 아니라 작업 자체를 검사하라

자율 워커는 단순히 메시지 기록이 아닌, 작업 공간(workspace)을 필요로 합니다.

Agent Teams의 관리형 호스팅(managed hosting)을 사용하면 노트북을 닫은 후에도 워커를 실행할 수 있으며, 지속적인 파일과 작업 환경에 접근할 수 있습니다.

공유 파일은 제품 정보, 연구 자료, 운영 지침 등을 팀이 이용할 수 있도록 유지하는 실용적인 방법을 제공합니다.

고객 응대 워커가 계속해서 오래된 기능을 설명한다고 상상해 보세요. 유용한 응답은 참조 자료를 검사하고, 이를 수정하며, 업데이트된 소스를 이용 가능하게 만드는 것입니다. 단순히 같은 수정을 여러 채팅에 반복적으로 붙여넣는 것이 아닙니다.

개발자에게 있어 검사 가능성(inspectability)은 완료 주장(completion claim)을 평가하기 더 쉽게 만듭니다.

출력물은 어디에 있나요? 무엇이 바뀌었나요? 워커가 어떤 입력을 사용했나요?

그러한 질문들은 실제 파일과 기록으로 이어져야 합니다.

기존 에이전트는 이동 없이 대시보드에 참여할 수 있다

팀이 항상 처음부터 시작하는 것은 아닙니다.

이미 다른 곳에 유용한 코딩 에이전트나 교체하고 싶지 않은 기존의 연구 워커를 가지고 있을 수 있습니다.

Agent Teams는 호스팅된 워커와 동일한 대시보드에 호환되는 외부 에이전트 보고서를 가져올 수 있게 합니다.

소유자에게 보여지는 연결 흐름은 간단합니다:

1. 외부 에이전트에 이름을 부여합니다.
2. 연결 메시지를 복사합니다.
3. 이 메시지를 에이전트에 붙여넣습니다.

이 메시지가 보고 지침을 제공합니다. 호환되는 에이전트의 경우 직접 통합 코드를 작성할 필요가 없습니다.

외부 워커는 기존에 실행되던 곳에 그대로 머무릅니다. 연결은 그 활동 보고를 화면에 가져올 뿐, 외부 컴퓨터를 장악하거나 전체 대화를 노출하지 않습니다.

이러한 구분이 혼합된 환경을 실용적으로 만듭니다. 이미 작동하는 도구는 유지하면서, 그 보고된 진행 상황들을 한데 모을 수 있습니다.

대시보드는 여전히 모든 활동에 대한 자동 감시가 아니라, 보고된 활동 기록으로 읽혀야 합니다.