🎬 My OpenClaw System Is Out of Control

▶️ 유튜브

• 원본 링크: https://youtu.be/oY3y4fpLSEo?si=DhE4Y-6hKNHE20zj

🖼️ 4컷 인포그래픽

💡 한 줄 결론

토큰 비용을 감당하지 못한 채 에이전트와 권한을 계속 늘리면 자동화의 생산성보다 운영비와 복잡도가 먼저 폭발한다. 이 시스템의 진짜 병목은 모델 출력 품질이 아니라 입력 컨텍스트 비용과 프로젝트별 컨텍스트 분리 설계다.

📌 핵심 요점

1. 개발자 에이전트에 서버와 GitHub 푸시 권한까지 넘기자 실제 수정·복구는 가능해졌지만, 시스템 장애와 통제 리스크도 함께 커졌다.
2. 비용의 대부분은 결과물 생성보다 프로젝트 맥락을 모델에 반복 전달하는 입력 토큰에서 발생했고, 한 시간 100달러·누적 20억 토큰 수준까지 치솟았다.
3. 캐시 효율이 이상적인 6:1~8:1이 아니라 약 2:1 수준에 머물러, 같은 맥락을 계속 보내면서도 비용 절감 효과를 거의 못 얻고 있다.
4. 컨텍스트를 줄이면 압축 과정에서 캐시가 깨지고, 컨텍스트를 넓히면 캐시 미스 패널티가 커져 비용 최적화가 단순한 축소 문제로 풀리지 않는다.
5. 단일 Linkbot 운영은 돌아가더라도, 여러 SaaS·클라이언트를 동시에 다루려면 프로젝트별 SOP·태그·하드코딩 값 분리 없이는 확장성이 무너진다.

🧠 상세 요약

1) 배경과 문제 정의

발표자는 OpenClaw 기반 자율 에이전트 운영을 실제 사업에 붙이면서, 성능 향상보다 운영 복잡도와 비용 폭증이 더 빠르게 커졌다는 문제를 마주한다. 핵심 관찰 포인트는 세 가지다: 권한을 어디까지 위임할지, 입력 컨텍스트 비용을 어떻게 줄일지, 그리고 여러 프로젝트를 섞지 않고 확장할 수 있는 구조를 만들 수 있는지다.

2) 섹션별 상세 정리

1. 시작부터 “통제 불능”을 선언한 이유 [00:00]

• 발표자는 최근 며칠 사이 OpenClaw 세팅이 너무 빠르게 복잡해져 현재 상태를 자신도 완전히 추적하기 어려운 수준이라고 말한다.
• 문제는 단순 버그가 아니라, 여러 변경이 누적되며 시스템 전체의 예측 가능성이 떨어졌다는 점이다.

2. Linkbot 운영은 되지만 구조적 문제는 따로 있다 [00:15]

• 자율 SEO 에이전시 실험의 현재 대상은 Linkbot이며, 이 프로젝트 자체는 당장 크게 망가지지 않고 돌아가고 있다.
• 그러나 특정 클라이언트 한 곳이 돌아간다는 사실이 곧 시스템 설계가 건강하다는 뜻은 아니며, 발표자는 그 간극을 분명히 인식한다.

3. 역할 특화 에이전트를 붙이면서 복잡도가 급증했다 [00:28]

• 이번 주부터 각 기능별 전문 에이전트를 추가하면서 구조가 급격히 복잡해졌고, 무엇이 어디에 반영돼 있는지 재점검이 필요해졌다.
• 성능 향상을 위해 역할을 쪼갠 선택이 오히려 조합 비용과 운영 추적 비용을 키운 셈이다.

4. CRO·광고·PM 역할이 자동화 범위를 넓혔다 [00:40]

• 포지(Porgy)는 전환율 최적화, Apex는 구글 광고 분석, Compass는 제품/프로젝트 관리와 UX 점검 같은 역할을 맡는다.
• 이들은 각각 유료 전환, 광고 성과 개선, 기능 제안 등 실무 가치가 있는 업무를 수행하지만, 동시에 더 많은 컨텍스트와 판단 경로를 시스템에 추가한다.

5. 개발자 에이전트 Bolt는 생산성을 주지만 위험도 함께 키운다 [01:37]

• Bolt는 서버와 GitHub 접근 권한을 갖고 실제 푸시와 수정 작업까지 수행하며, 한 번은 문제를 일으켰지만 이후 직접 고치는 사례도 있었다.
• 발표자는 이를 사실상 “시스템 열쇠를 넘긴 것”으로 표현하며, 에이전트의 자율성이 곧 운영 리스크의 확대라는 점을 인정한다.

6. Cursor CLI와 고성능 모델 조합이 개발 자동화의 핵심이다 [02:14]

• Bolt는 고수준 사양서를 만들고, Cursor CLI가 이를 바탕으로 실제 구현을 수행하는 방식으로 돌아간다.
• 발표자는 직접 코드를 쓰는 것보다, 코드베이스 인덱싱과 맥락 파악 능력 덕분에 Cursor가 더 깔끔한 결과를 낼 수 있다고 평가하며 Opus 4.6을 핵심 코딩 에이전트로 본다.

7. 진짜 폭탄은 출력이 아니라 입력 토큰 비용이다 [02:50]

• 한 시간 만에 100달러가 소모되고, 같은 시간대에 1억 1,900만 토큰, 전체 누적 20억 토큰 이상이 처리됐다고 밝힌다.
• 발표자의 해석은 명확하다. 비용의 본질은 결과물 생성량이 아니라, 프로젝트의 전체 맥락을 모델에게 계속 전달하는 입력 컨텍스트에 있다.

8. 캐시 전략이 기대만큼 작동하지 않는다 [03:10]

• 캐시된 입력과 비캐시 입력 비율이 약 2:1 수준인데, 이상적으로는 6:1 또는 8:1 정도가 나와야 한다고 본다.
• 캐시가 잘 먹으면 비용을 최대 90% 가까이 줄일 수 있으므로, 현재 구조는 성능 문제가 아니라 캐시 활용 실패에서 오는 경제성 문제를 드러낸다.

9. 컨텍스트 압축과 캐시 활용이 서로 충돌한다 [03:53]

• 컨텍스트를 작게 보내면 당장 토큰은 줄일 수 있지만, 압축을 자주 할수록 캐시가 깨져 장기적으로는 오히려 비효율이 생긴다.
• 반대로 큰 컨텍스트와 넓은 캐시를 허용하면 캐시 미스 시 비용 충격이 커져, 단순히 “줄이자” 혹은 “늘리자”로 해결되지 않는 최적화 문제가 된다.

10. 권한 위임과 확장 목표가 동시에 시스템 부담을 키운다 [04:28]

• 발표자는 애플리케이션 수준을 넘어 시스템 관리 권한까지 OpenClaw에 넘긴 상태라고 밝히며, 지금은 그 구조 자체를 재평가하는 단계라고 말한다.
• 이는 기능 자동화 범위를 넓히는 대신, 실패했을 때의 영향 반경도 크게 만든다.

11. 단일 프로젝트가 아니라 멀티프로젝트 운영이 최종 목표다 [04:50]

• 발표자의 관심은 Linkbot 하나를 잘 돌리는 데 그치지 않고, 더 큰 가치가 있는 여러 SaaS 프로젝트에 같은 운영 체계를 확장하는 데 있다.
• 그래서 지금 문제는 단순 비용 절감이 아니라, 다수 프로젝트를 동시에 다룰 수 있는 운영 모델을 만드는 데 연결된다.

12. 프로젝트별 컨텍스트 분리와 범용화가 필수 과제로 떠올랐다 [05:17]

• 여러 클라이언트에 서로 다른 지침과 레이블을 붙이는 상황에서는, cron·태그·컨텍스트가 프로젝트 단위로 분리되어야 혼선이 줄어든다.
• Google Analytics 속성 ID 같은 하드코딩 값, Notion 문서, SOP도 프로젝트별 변수화·범용화가 필요하다고 본다.

13. 우선순위는 명확하지만 실행은 역행하고 있다 [05:59]

• 발표자는 현재 최우선 과제를 토큰 소각 축소와 멀티프로젝트 지원 두 가지로 정리하되, 당장은 전자가 더 급하다고 말한다.
• 동시에 그 문제를 해결하기도 전에 기존 10명 에이전트에 3~4명을 더 붙였다고 인정하며, 스스로도 “거꾸로 가는 것”이라고 평가한다.

14. 혼란 자체를 공개 실험 콘텐츠로 전환한다 [06:24]

• 영상 말미에서 발표자는 자신의 당황과 문제 해결 과정을 지켜보는 것 자체가 재미 포인트가 될 수 있다고 농담 섞어 정리한다.
• 이는 단순 실패 고백이 아니라, 실제 운영 중 드러나는 비용·권한·확장성 문제를 공개적으로 검증하는 기록이기도 하다.

✅ 액션 아이템

• 현재 에이전트별 입력 토큰, 캐시 적중률, 평균 세션 길이를 분리 집계해 어떤 역할이 비용을 가장 많이 태우는지 순위화한다.
• 개발자 에이전트의 서버·GitHub 권한을 작업 유형별로 재분리하고, 자동 푸시 가능한 범위와 사람 승인 필수 범위를 명시한다.
• 프로젝트별 태그, SOP, 환경변수, 분석 ID를 하드코딩 대신 템플릿화해 Linkbot 외 신규 SaaS 하나를 같은 구조로 붙여보는 확장 테스트를 한다.
• 컨텍스트 압축 빈도와 캐시 유지 시간을 바꾼 2~3개 실험군을 만들어, 비용 절감률과 작업 정확도를 함께 비교한다.
• 전문 에이전트 추가 전후의 성과 차이를 측정해, CRO·광고·PM 역할 중 실제 ROI가 낮은 에이전트는 비활성화하거나 호출 조건을 더 엄격하게 건다.

❓ 열린 질문

• 캐시 비율을 2:1에서 6:1 이상으로 끌어올렸을 때도 에이전트별 판단 품질이 유지되는지, 아니면 특정 역할에서만 품질 저하가 발생하는가?
• Bolt처럼 고권한 개발자 에이전트가 실제 장애를 낸 뒤 스스로 복구한 사례는 생산성 우위의 증거인가, 아니면 사람 검토 없는 배포 구조의 위험 신호인가?
• 멀티프로젝트 확장 시 프로젝트별 컨텍스트를 태그로만 분리하는 방식이 충분한지, 아니면 메모리·권한·도구 접근까지 완전히 분리된 실행 단위가 필요한가?
• Linkbot처럼 상대적으로 작은 프로젝트에서 검증되지 않은 비용 구조를 더 큰 SaaS에 그대로 확장하면, 수익 증가보다 토큰 원가와 운영 복잡도가 먼저 누적될 가능성은 얼마나 큰가?