🎬 This Openclaw Trick Makes Single Agents Obsolete

▶️ 유튜브

• 원본 링크: https://youtu.be/esuPIJeRotI?si=8Fk4-48Xx9CisD3b

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw를 오래 안정적으로 쓰려면 하나의 만능 에이전트에 업무를 몰아주지 말고, 공유 맥락이 필요한 일은 라우팅형으로, 권한·도구·작업공간이 달라야 하는 일은 분리형 에이전트로 나눠 운영하는 편이 성능·병렬성·장애 격리에서 유리하다.

📌 핵심 요점

1. 하나의 에이전트에 코딩, 이메일, 문서, 배포까지 몰아주면 제한된 컨텍스트 창 안에서 정보 과부하가 생겨 지시 누락과 환각 가능성이 커진다.
2. 이메일에는 간결함, 코드 리뷰에는 엄밀함이 필요한데 단일 시스템 프롬프트가 여러 업무 규칙을 동시에 품으면 지침 충돌로 일관성이 깨지기 쉽다.
3. 다중 에이전트 구조는 코드 리뷰·문서 작성·받은편지함 확인 같은 작업을 병렬로 돌릴 수 있어 단일 에이전트의 순차 처리 한계를 줄인다.
4. 프로젝트 내부 라우팅 방식은 같은 저장소와 파일을 공유하는 팀형 운영에 적합하고, 역할별 폴더·프롬프트·route 연결만으로 빠르게 특수 모드를 만들 수 있다.
5. 완전 분리형 터미널 방식은 서로 다른 코드베이스, 권한, 도구 세트를 가진 독립 에이전트를 운영할 수 있어 보안 격리와 운영 통제가 중요한 환경에 더 맞다.

🧠 상세 요약

1) 배경과 문제 정의

출발점은 “왜 에이전트가 자꾸 맥락을 놓치고 기대와 다르게 움직이는가”라는 문제다. 발표자는 원인을 모델 자체의 부족함보다도, 너무 많은 업무를 하나의 에이전트에 몰아넣는 운영 방식에서 찾는다. 따라서 판단 포인트는 기능 추가가 아니라 업무 분리, 맥락 범위 축소, 그리고 격리 수준 설계다.

2) 섹션별 상세 정리

1. 단일 만능 운영이 깨지는 이유를 다시 정의한다 [00:00]

• 많은 사용자가 코딩, 이메일 확인, 파일 관리, 설문 검토 같은 서로 다른 일을 하나의 OpenClaw 세션에 모두 맡긴다.
• 발표자는 이를 “유능한 한 명을 더 혹사시키는 문제”가 아니라, 애초에 전문가 팀으로 분업해야 할 문제라고 프레임을 바꾼다.

2. 핵심 병목은 컨텍스트 창의 한계다 [00:31]

• 에이전트는 한 번에 유지할 수 있는 정보량이 제한되어 있어, 코드베이스와 문서와 운영 맥락을 한꺼번에 들고 가면 초점이 흐려진다.
• 그 결과 원래 기억해야 할 지시를 잊거나, 좁은 범위였다면 피할 수 있었던 오류와 환각이 발생한다.

3. 업무별 요구 성격이 달라 단일 프롬프트가 충돌한다 [01:11]

• 이메일 작성은 짧고 신속해야 하지만 코드 검토는 꼼꼼하고 보수적이어야 하는 식으로 업무별 최적 성격이 다르다.
• 하나의 에이전트가 이 상반된 규칙을 동시에 품으면 어떤 순간에 어떤 원칙을 우선할지 흔들리기 쉽고, 결국 품질이 들쭉날쭉해진다.

4. 다중 에이전트는 병렬성과 장애 격리를 함께 가져간다 [01:41]

• 단일 에이전트는 구조적으로 한 번에 한 가지 일만 처리하므로 처리량이 제한된다.
• 반면 역할을 나누면 한 에이전트가 실패해도 다른 에이전트는 계속 돌아갈 수 있어 전체 시스템의 폭발 반경이 줄어든다.

5. 구축 방식은 크게 라우팅형과 분리형 두 갈래다 [01:53]

• 첫 번째는 같은 프로젝트 안에서 역할별 하위 에이전트를 만들어 필요할 때 라우팅하는 방식이다.
• 두 번째는 아예 새로운 작업공간을 가진 독립 에이전트를 생성하는 방식으로, 목적은 더 강한 격리와 독립 운영이다.

6. 라우팅형은 같은 프로젝트 안에서 빠르게 역할 분업을 만든다 [02:26]

• 시작은 프로젝트 디렉터리 안에 역할별 폴더를 만드는 것이다.
• 폴더 이름 자체가 업무를 설명해야 하며, 이메일 확인·코드 리뷰·문서 작성처럼 역할 단위로 쪼개는 것이 핵심이다.

7. 역할별 프롬프트를 좁고 선명하게 설계한다 [02:50]

• 각 폴더 안에는 해당 에이전트의 성격, 목표, 금지사항, 출력 규칙이 담긴 마크다운 지침 파일을 둔다.
• 예시의 이메일 에이전트는 받은편지함 요약, 긴급 메일 표시, 무단 발송 금지, VIP 우선순위 같은 구체 규칙까지 포함해 범위를 좁힌다.

8. 라우팅 연결을 넣으면 프로젝트 안에서 특수 모드처럼 쓸 수 있다 [03:40]

• agents.mmd에 route 명령을 연결하면 특정 문구 입력만으로 해당 역할의 프롬프트를 불러오게 만들 수 있다.
• 이 구조는 같은 저장소와 같은 파일 집합을 공유하는 여러 작업을 빠르게 전환해야 할 때 특히 효율적이다.

9. 분리형은 완전히 다른 세계를 운영할 때 쓴다 [04:44]

• 어떤 에이전트는 메인 프로젝트와 다른 코드베이스를 봐야 하고, 어떤 에이전트는 웹 접근이나 데이터베이스 권한처럼 다른 도구 체인이 필요하다.
• 이런 경우에는 프로젝트 내부 하위 폴더 수준이 아니라, 별도 작업공간과 별도 맥락을 가진 독립 에이전트가 더 적합하다.

10. openclaw agents add로 독립 에이전트를 생성하고 자산처럼 관리한다 [05:05]

• 발표자는 openclaw agents add로 새 에이전트를 만들고 온보딩을 거쳐 전용 작업공간을 확보하는 흐름을 보여준다.
• 이렇게 만든 에이전트는 별도 프롬프트, 디렉터리, 도구, 권한을 가질 수 있고 목록 조회·전환·삭제 같은 운영 관리도 가능해 기업형 구성에 잘 맞는다.

11. 선택 기준은 공유 맥락이냐, 진짜 격리냐이다 [06:16]

• 같은 프로젝트 안에서 파일과 맥락을 공유하며 여러 역할을 오가는 경우라면 라우팅형이 더 가볍고 빠르다.
• 반대로 보안 수준, 파일 접근, 코드베이스, 도구 구성이 다르면 분리형이 맞고, 발표자는 이를 같은 사무실 안의 부서와 다른 건물의 사무실에 비유한다.

12. 실전 권장 순서는 라우팅형으로 시작해 필요 시 분리형을 더하는 것이다 [06:38]

• 처음부터 무겁게 설계하기보다 프로젝트 안에 2~3개의 역할형 에이전트를 먼저 두고 운영 감각을 익히는 편이 낫다.
• 이후 실제로 격리 필요성이 생기면 독립 에이전트를 추가하고, 성숙한 환경에서는 두 방식을 혼합해 쓴다.

✅ 액션 아이템

• 현재 OpenClaw에 맡기는 작업을 공유 저장소 필요와 독립 권한/도구 필요로 나눠 보고, 전자는 라우팅형 후보, 후자는 분리형 후보로 1차 분류한다.
• 메인 프로젝트 안에 최소 2개 역할 폴더를 만들고, 예를 들어 email-check와 code-review처럼 업무 범위가 겹치지 않는 프롬프트 파일을 각각 작성한다.
• 이메일 에이전트 프롬프트에는 읽지 않은 메일 요약, 긴급 메일 표시, 명시적 승인 없는 발송 금지, VIP 우선처럼 판단 규칙이 드러나는 제약을 넣어 테스트한다.
• agents.mmd에 자주 쓰는 업무 2~3개만 우선 route로 연결해, 동일 프로젝트 안에서 전문가 모드 전환 속도와 결과 일관성이 실제로 좋아지는지 비교한다.
• 웹 리서치나 데이터 조회처럼 메인 프로젝트와 다른 권한이 필요한 작업 하나를 골라, 분리형 에이전트로 독립 생성했을 때 교차 오염과 보안 관리가 얼마나 줄어드는지 검증한다.

❓ 열린 질문

• 같은 저장소를 공유하는 라우팅형만으로도 충분한 업무를, 관성적으로 분리형 에이전트까지 늘려 운영 복잡도만 키우고 있지는 않은가?
• 반대로 현재 하나의 세션에서 처리 중인 업무 중 어떤 작업은 이미 파일 접근 권한·도구 세트·실패 영향 범위가 달라서 독립 에이전트로 격리해야 하는 단계에 와 있는가?
• 역할별 프롬프트를 나눴을 때 실제 개선이 생기는 핵심 원인은 컨텍스트 절감인지, 지침 충돌 해소인지, 아니면 단순 병렬 처리 효과인지 어떻게 구분해 측정할 것인가?
• 에이전트 수가 늘어날수록 생산성보다 운영 비용이 커질 수 있는데, 어떤 시점부터는 “전문화의 이득”보다 “관리 오버헤드”가 더 커지는지 어떤 기준으로 판단할 것인가?