앱 개발을 위해 OpenClaw를 설정하는 분들로부터 계속해서 같은 질문을 받고 있습니다:

멀티 에이전트 (multi-agent) 설정으로 시작해야 할까요, 아니면 그냥 에이전트 하나만 사용해야 할까요?

문서를 읽고, 사람들이 어려워하는 모습을 지켜보고, 직접 이러한 워크플로우를 구축해 본 제 의견은 다음과 같습니다:

대부분의 팀은 스웜 (swarm)으로 시작해서는 안 됩니다.

다음과 같이 시작하세요:

1. 1명의 코딩 에이전트 (coding agent)
2. 1명의 리뷰어 에이전트 (reviewer agent)
3. 1개의 배포 게이트 (deploy gate)

그게 전부입니다.

멀티 에이전트 시스템이 가짜이기 때문이 아닙니다. OpenClaw는 이를 완벽하게 지원합니다.

하지만 OpenClaw에서는 추가되는 에이전트 하나하나가 저렴한 조력자가 아닙니다. 그것은 자체적인 설정 (config), 저장소 (storage), 그리고 실패 모드 (failure modes)를 가진 새로운 격리 경계 (isolation boundary)입니다.

그리고 이것은 트레이드오프 (tradeoff)를 빠르게 변화시킵니다.

저를 생각에 잠기게 한 Reddit 스레드

첫날부터 멀티 에이전트 개발 환경을 계획하고 있는 누군가의 r/openclaw 게시물을 읽고 있었습니다:

https://reddit.com/r/openclaw/comments/1v6neop/new_to_openclaw_ai_agents_looking_for_advice_on/

그 본능은 이해할 수 있습니다. 에이전트 하나가 유용하다면, 6개의 전문화된 에이전트가 더 낫게 들릴 것입니다.

Planner. Builder. Tester. Debugger. Reviewer. Release manager.

화이트보드 위에서는 아주 멋져 보입니다.

하지만 실제로 많은 이러한 설정들은 LLM 중간 관리직 (middle management)으로 변질됩니다.

진짜 문제는 대개 다음과 같습니다:

에이전트가 더 필요하다.

가 아니라,

내 에이전트 하나가 너무 많은 컨텍스트 (context)와 너무 많은 권한을 가지고 있으며, 감독 (supervision)이 없다.

이것들은 서로 다른 문제입니다.

만약 다섯 명의 에이전트를 더 추가함으로써 두 번째 문제를 해결하려 한다면, 대개 더 많은 상태 (state), 더 많은 요약 (summaries), 그리고 설정을 잘못할 수 있는 더 많은 지점만을 만들게 될 뿐입니다.

OpenClaw의 기본 설정이 가장 큰 단서입니다

OpenClaw에서 가장 시사하는 바가 큰 점은 기본값이 **단일 에이전트 모드 (single-agent mode)**라는 것입니다.

특별한 작업을 하지 않는다면, 여러분은 하나의 에이전트, 하나의 워크스페이스 (workspace), 하나의 상태 디렉토리 (state directory)를 갖게 됩니다.

이것은 우연이 아닙니다.

OpenClaw는 멀티 에이전트 라우팅 (multi-agent routing), 격리된 워크스페이스 (isolated workspaces), 별도의 인증 프로필 (auth profiles), 바인딩 (bindings), 그리고 에이전트별 SQLite 세션 히스토리 (session history)를 지원합니다. 스웜 방식을 완벽하게 수행할 수 있습니다.

하지만 기본 설정은 정상적인 경로가 무엇이어야 하는지를 알려줍니다:

잘 설정된 단일 에이전트로 시작하세요.

이는 제가 실제로 경험한 것과 일치합니다.

에이전트를 추가할 때 실제로 추가되는 것들

사람들은 마치 브라우저 탭을 하나 더 여는 것처럼 "두 번째 에이전트를 추가하는 것"에 대해 이야기합니다.

OpenClaw에서는 그보다 더 무겁습니다.

각 에이전트는 자신만의 워크스페이스 (workspace), 상태 (state), 인증 경계 (auth boundary), 바인딩 (bindings), 그리고 세션 히스토리 (session history)를 갖게 됩니다. 세션 DB 경로는 다음과 같습니다:

~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

따라서 에이전트를 추가한다는 것은 단순히 동작을 추가하는 것 이상의 의미를 갖습니다. 운영상의 표면적 (operational surface area)을 더 늘리는 것입니다.

보통 이는 다음을 의미합니다:

• 또 다른 워크스페이스 (workspace)
• 또 다른 상태 (state) 디렉토리
• 또 다른 인증 프로필 (auth profile) 경계
• 조사해야 할 또 다른 세션 히스토리 (session history)
• 검증해야 할 또 다른 바인딩 (bindings) 세트
• 권한이 어긋날 수 있는 또 다른 지점
• 이제 고려해야 할 또 다른 설정 표면 (config surface)

품질 향상을 얻기 전에 이러한 오버헤드 (overhead)가 실제로 발생합니다.

대부분의 팀에게 권장하는 설정

실용적인 버전은 다음과 같습니다.

그 중간 옵션이 최적의 지점 (sweet spot)입니다.

그것이 우아하기 때문이 아닙니다.

오케스트레이션 (orchestration) 복잡성이 이득을 갉아먹기 시작하기 전에 대부분의 이점을 얻을 수 있기 때문입니다.

사람들이 건너뛰는 부분: 멀티 에이전트 버그는 종종 설정 버그입니다

많은 "에이전트의 이상 동작"은 모델의 이상 동작이 아닙니다.

그것은 설정의 이상 동작입니다.

OpenClaw에는 매우 중요한 몇 가지 주의 사항 (gotchas)이 있습니다.

스킬 허용 목록 (Skill allowlists)이 예상치 못한 결과를 초래할 수 있습니다

에이전트별로 스킬 허용 목록 (skill allowlists)을 명시적으로 설정한다면, 그것이 기본값과 친화적으로 병합될 것이라고 가정하지 마세요.

그렇게 하면 리뷰어 에이전트 (reviewer agent)에 기대했던 기능이 누락되거나, 코딩 에이전트 (coding agent)가 사용자의 멘탈 모델 (mental model)과 일치하지 않는 도구 표면 (tool surface)을 갖게 될 수 있습니다.

그것은 지능의 문제가 아닙니다. 그것은 오케스트레이션 부채 (orchestration debt)입니다.

플러그인 저장소는 항상 당신이 생각하는 방식으로 격리되어 있지 않습니다

이것이 더 큰 지뢰입니다.

OpenClaw는 플러그인이 소유한 저장소가 에이전트 간에 자동으로 분리되지 않는다고 경고합니다.

이것은 중요한 문제입니다.

별도의 워크스페이스(workspace)가 있다고 해서 모든 플러그인 메모리나 저장 영역이 자동으로 안전하게 격리되는 것은 아닙니다.

진정한 메모리 분리가 필요하다면, OpenClaw의 자체 문서에서는 별도의 Memory Wiki 볼트(vault)와 같은 에이전트별 볼트 패턴(per-agent vault patterns)을 권장합니다.

이는 강력한 힌트입니다.

만약 리뷰어 에이전트(reviewer agent)는 운영 런북(production runbooks)을 알고 있어야 하지만, 실험적인 코딩 에이전트(experimental coding agent)는 몰라야 한다면, 그렇습니다, 별도의 에이전트를 생성하고 메모리를 적절히 격리하십시오.

만약 그 정도 수준의 분리가 필요하지 않다면, 추가적인 에이전트는 격리되지 않았음에도 격리되었다고 스스로를 속이는 추가적인 방법이 될 뿐입니다.

에이전트가 많다고 해서 자동으로 실수가 줄어드는 것은 아닙니다

이것은 환상 단계입니다.

사람들은 OpenClaw 내부에 아주 작은 AI 소프트웨어 회사가 있다고 상상합니다:

• 에이전트 1명은 계획을 세우고
• 에이전트 1명은 코드를 작성하고
• 에이전트 1명은 테스트를 하고
• 에이전트 1명은 디버깅을 하고
• 에이전트 1명은 문서를 작성하고
• 에이전트 1명은 배포(ship)를 합니다

매우 고급 기술처럼 들립니다.

하지만 대신 흔히 발생하는 일은 다음과 같습니다:

1. 코딩 에이전트가 코드를 작성합니다.
2. 다른 에이전트가 발생한 일을 요약합니다.
3. 세 번째 에이전트가 요약본과 차이점(diff)을 다시 읽습니다.
4. 네 번째 에이전트가 요약본에서 세부 사항이 누락되었다며 원래 요구사항을 다시 요청합니다.

이것은 지능이 아닙니다. 그것은 요약 오버헤드(recap overhead)입니다.

모든 인수인계(handoff)는 더 많은 프롬프트(prompt), 더 많은 요약, 그리고 더 많은 반복적인 컨텍스트(context)를 생성합니다.

따라서 아니요, 스웜(swarm)이 마법처럼 실수를 줄여주지는 않습니다.

GPT-5에서의 잘못된 워크플로(workflow)는 여전히 잘못된 워크플로입니다.

저는 차라리 다음과 같이 실행하겠습니다:

• 강력한 코딩 에이전트 1명
• 권한이 더 제한된 리뷰어 1명
• 자유롭게 행동할 수 없는 배포 게이트(deploy gate) 1개

이러한 설정이 추론하기 더 쉽고 신뢰하기 더 쉽습니다.

리뷰어가 제가 보통 원하는 유일한 추가 에이전트인 이유

이것은 조기에 효과를 볼 수 있다고 생각하는 유일한 추가 역할입니다.

저는 누군가가 다운로드된 스킬(skills)을 검사하고, 그것을 신뢰하기 전에 실제 코드를 살펴보는 데 에이전트를 사용한다고 설명한 다른 r/openclaw 스레드를 발견했습니다:

https://reddit.com/r/openclaw/comments/1v6cf0c/openclaw_skills/

그것이 정확히 올바른 직관입니다.

두 번째 에이전트를 또 다른 과신하는 빌더 (builder)가 아니라, **감사자 (auditor)**로 사용하십시오.

만약 스킬 (skill) 생태계가 소란스럽다면, 해결책은 "더 많은 에이전트에게 더 많은 도구를 주는 것"이 아닙니다.

해결책은 다음과 같습니다:

• 더 엄격한 리뷰 (review)
• 더 좁은 권한 (permissions)
• 명시적인 검사 (explicit checks)

따라서 저의 리뷰어 (reviewer) 에이전트는 보통 다음과 같은 일들을 수행합니다:

• diff 읽기
• 설치 전 스킬 (skills) 감사
• 안전하지 않은 코드 패턴 플래그 (flag) 표시
• 마이그레이션 (migrations) 및 설정 (config) 변경 사항 확인
• 수정 사항이 요청과 일치하는지 검증
• 광범위한 쓰기 권한 (write access) 지양

이것은 즉시 유용합니다.

다섯 번째 자율 빌더 (autonomous builder) 에이전트는 보통 유용하지 않습니다.

단계별로 진행하는 합리적인 OpenClaw 설정

만약 제가 이것을 처음부터 설정한다면, 단계별로 진행할 것입니다.

1단계: 하나의 코딩 에이전트로 시작하기

기본적인 단일 에이전트 (single-agent) 모드를 사용하십시오.

워크스페이스 (workspace)를 깨끗하게 유지하십시오.

스킬 세트 (skill set)를 타이트하게 유지하십시오.

에이전트에게 단 하나의 작업만 부여하십시오: 코드를 작성하고 편집하는 것.

2단계: 실제 분리가 필요한 경우 리뷰어 하나 추가하기

별도의 권한 (permissions), 메모리 (memory), 인증 (auth), 또는 워크스페이스 (workspace) 경계가 필요한 경우에만 두 번째 에이전트를 추가하십시오.

예를 들어:

openclaw agents add reviewer
openclaw agents list --bindings

두 번째 명령어가 중요합니다.

바인딩 (bindings)을 실제로 검사하십시오. 당신이 의도한 대로 되어 있을 것이라고 가정하지 마십시오.

3단계: 배포 (deploy)를 게이트 (gate) 뒤에 유지하기

이 부분은 제가 가장 의견이 확고한 부분입니다.

배포 (Deployment)는 인격 (personality)이 아니라 게이트 (gate)여야 합니다.

그 게이트는 다음과 같을 수 있습니다:

• 인간의 승인 단계
• CI 워크플로우 (workflow)
• 승인은 할 수 있지만 배포는 할 수 없는 읽기 전용 (read-only) 리뷰 단계
• 고정된 검사와 고정된 출력을 가진 스크립트

제가 원하지 않는 것은 창의적인 에이전트가 즉흥적으로 프로덕션 (production) 환경에 진입하는 것입니다.

이것은 제약이 있는 이메일 에이전트 설정에 관한 또 다른 r/openclaw 토론을 떠올리게 합니다:

https://reddit.com/r/openclaw/comments/1v636xd/email_intelligence_platform_for_openclaw/

한 사용자는 이메일 에이전트를 먼저 읽기 전용 (read-only)으로 실행하고, 명시적으로 요청했을 때만 초안을 작성하도록 운영하는 방식을 설명했습니다.

이는 배포 (deploy) 시에도 가져야 할 올바른 사고방식입니다.

먼저 읽기 전용으로.

행동은 나중에.

자율성 (autonomy) 이전에 가드레일 (guardrails)을.

구체적인 예시: 코더 (coder) + 리뷰어 (reviewer) + 게이트 (gate)

제가 사용할 대략적인 패턴은 다음과 같습니다.

코더 (Coder) 에이전트

책임:

• 기능 구현 (implement features)
• 파일 편집 (edit files)
• 로컬 체크 실행 (run local checks)
• 마이그레이션 제안 (propose migrations)

권한:

• 앱 워크스페이스 (app workspace)에 대한 쓰기 권한 (write access)
• 제한된 도구 세트 (limited tool set)
• 프로덕션 배포 (production deploy)에 대한 직접적인 접근 권한 없음

리뷰어 (Reviewer) 에이전트

책임:

• 차이점 검사 (inspect diffs)
• 생성된 코드 검토 (review generated code)
• 스킬/플러그인 설치 감사 (audit skill/plugin installs)
• 설정 변경 사항 검증 (validate config changes)

권한:

• 읽기 전용 (read-only) 또는 좁게 범위가 지정된 쓰기 권한 (narrowly scoped write access)
• 필요 시 별도의 워크스페이스 (separate workspace)
• 민감한 컨텍스트 (sensitive context)가 포함된 경우 별도의 메모리 (separate memory)

배포 게이트 (Deploy gate)

책임:

• 결정론적 체크 실행 (run deterministic checks)
• 명시적 승인 요구 (require explicit approval)
• 안전하지 않은 릴리스 차단 (block unsafe releases)

권한:

• 개방형 자율성 없음 (no open-ended autonomy)
• 고정된 CI/CD 경로 (fixed CI/CD path)
• 명시적인 환경 제어 (explicit environment controls)

단순한 쉘 (shell) 기반의 게이트는 다음과 같은 모습일 수 있습니다:

#!/usr/bin/env bash
set -euo pipefail

...

이런 경우에는 지루한 것이 좋습니다.

비용 측면은 사람들이 인정하는 것보다 더 중요합니다

제가 이 설정을 좋아하는 또 다른 이유가 있습니다.

에이전트 오케스트레이션 (Agent orchestration)은 본질적으로 실험적입니다.

여러분은 다음과 같은 것들을 시도하고 싶을 것입니다:

• 코더 (coder) 단독
• 코더 (coder) + 리뷰어 (reviewer)
• 서로 다른 리뷰 프롬프트 (review prompts)
• 구현을 위한 GPT-5
• 리뷰를 위한 Claude Opus 4.6
• 더 좁은 검증 작업을 위한 Grok

모든 추가적인 핸드오프 (handoff)가 당신이 돌봐야 하는 또 다른 과금 대상 (billable event)처럼 느껴진다면, 이러한 실험은 금방 짜증스러운 일이 됩니다.

이것이 바로 에이전트 워크플로우 (agent workflows)에는 전통적인 토큰당 과금 (per-token pricing) 방식보다 정액제 추론 (flat-rate inference) 방식이 더 적합한 이유입니다.

오케스트레이션 패턴을 테스트하고 있다면, 틀릴 수 있는 여유가 필요합니다.

루프(loops)를 실행하고, 설정을 비교하며, 실제 낭비가 어디에서 발생하는지 찾아낼 여유가 필요합니다.

보통 낭비는 "이 프롬프트에 토큰이 200개 더 들어갔다"와 같은 것이 아닙니다.

보통 낭비는 구조적인 문제입니다:

• 너무 많은 에이전트 핸드오프 (agent handoffs)
• 너무 많은 반복적인 요약 (repeated summaries)
• 너무 많은 중복된 컨텍스트 (duplicated context)
• 너무 많은 모호하게 정의된 역할 (loosely defined roles)

이것이 바로 제가 모델 쇼핑 (model shopping)보다 워크플로의 형태 (workflow shape)에 더 신경을 쓰는 정확한 이유입니다.

그리고 이것이 에이전트와 자동화(automations)를 구축하는 팀들에게 Standard Compute가 흥미로운 이유 중 하나입니다. 만약 OpenAI 호환 SDK나 HTTP 클라이언트를 사용하고 있다면, 이는 토큰당 과금 방식 대신 고정된 월간 요금제를 제공하는 즉시 교체 가능한 (drop-in) API 대체제입니다. 이를 통해 GPT-5.4, Claude Opus 4.6, Grok 4.20과 같은 모델들을 가로지르며 에이전트 루프, 리뷰어 패턴, 라우팅 (routing)을 테스트할 때, 내내 사용량 카운터를 주시할 필요 없이 훨씬 쉽게 테스트할 수 있습니다.

여러분의 업무가 한 번의 추가 반복이 청구서를 급증시킬지 여부를 판단하는 것이 아니라, 워크플로가 좋은지 여부를 파악하는 것이라면 이 점은 매우 중요합니다.

실제로 여러 에이전트를 사용해야 하는 경우

저는 멀티 에이전트 (multi-agent)에 반대하는 것이 아닙니다.

명확한 격리 이유 (isolation reason) 없이 에이전트를 추가하는 것에 반대하는 것입니다.

다음과 같이 구체적인 사항이 필요할 때는 여러 에이전트를 사용하십시오:

• 별도의 인증 프로필 (auth profiles)
• 별도의 워크스페이스 (workspaces)
• 별도의 메모리 저장소 (memory stores)
• 별도의 채널 아이덴티티 (channel identities)
• 별도의 운영 환경 자격 증명 (production credentials)
• 중복되어서는 안 되는 별도의 기술 세트 (skill sets)

만약 그 이유를 한 문장으로 설명할 수 있다면, 그것은 아마도 타당할 것입니다.

예시:

• "리뷰어는 배포 런북 (deployment runbooks)이 필요하지만, 코딩 에이전트는 이를 봐서는 안 됩니다."
• "Slack 대응 에이전트는 다른 아이덴티티와 다른 바인딩 (bindings)이 필요합니다."
• "운영 지원 (production support) 에이전트는 앱 빌더와 별도의 메모리 및 자격 증명이 필요합니다."

이것들은 실제적인 이유들입니다.

"더 많은 협업"은 이유가 될 수 없습니다.

저의 실제 권장 사항

만약 OpenClaw에서 AI 코딩 에이전트 설정을 구축하고 있다면, 저는 여기서부터 시작할 것입니다:

1. 깨끗한 워크스페이스(workspace)를 가진 하나의 코딩 에이전트 (One coding agent)
2. 분리 또는 감사(audit) 동작이 필요한 경우에만 하나의 리뷰어 에이전트 (One reviewer agent)
3. 제약이 있고 단순하게 유지되는 하나의 배포 게이트 (One deploy gate)

그 후 복잡성을 추가하기 전에 워크플로우(workflow)로부터 배우십시오.

여러분은 다음과 같은 사항들을 매우 빠르게 알게 될 것입니다:

• 실제로 별도의 인증(auth)이 필요한지
• 플러그인 저장소(plugin storage)에 더 강력한 격리(isolation)가 필요한지
• 메모리(memory)를 에이전트별로 분리해야 하는지
• 바인딩(bindings)이 깔끔한지
• 핸드오프(handoffs)가 도움이 되는지, 아니면 단순히 더 많은 요약(summaries)을 생성할 뿐인지

나중에 더 많은 에이전트를 추가한다면, 명확하게 이름을 붙일 수 있는 이유가 있을 때만 그렇게 하십시오.

아키텍처 다이어그램(architecture diagram)이 더 멋져 보인다는 이유 때문이 아닙니다.

보통 해결책은 6개의 에이전트를 사용하는 것이 아닙니다.

보통 해결책은 권한이 덜 허용적인(less-permissive) 리뷰어 하나, 더 엄격한 게이트 하나, 그리고 더 깔끔한 업무를 수행하는 코딩 에이전트 하나입니다.

이 설정은 제가 초기에 시도했던 그 어떤 스웜(swarm)보다 저에게 더 잘 작동했습니다.