🎬 The Biggest OpenClaw Update Yet... (Ver 3.8 Full Breakdown)

▶️ 유튜브

• 원본 링크: https://youtu.be/MoKNM53PLS4?si=RoXleyf6az3qcNR2

🖼️ 4컷 인포그래픽

💡 한 줄 결론

이번 OpenClaw 3.7·3.8의 본질은 에이전트 운영을 단일 세션 실험에서 벗어나, 주제별 분리·압축 내성·복구선·보안 통제가 갖춰진 실전형 운영 체계로 끌어올린 데 있습니다. 장기 투자 포인트는 기능 추가 자체보다도 멀티에이전트 재현성과 운영 사고 비용을 동시에 낮춘 구조 변화에 있습니다.

📌 핵심 요점

1. 텔레그램 토픽 라우팅은 한 그룹 안에서도 토픽별로 모델·프롬프트·스킬·메모리·워크스페이스를 분리해, 멀티에이전트 운영에서 자주 터지는 맥락 오염과 도구 선택 혼선을 줄인다.
2. post-compaction sections와 recent turns preserved는 긴 세션에서 압축이 발생해도 안전 규칙과 최근 작업 문맥을 남겨, “초반 지시가 사라져 사고가 나는 문제”를 설정 차원에서 직접 완화한다.
3. 스킬이 절차 지침이라면 플러그인은 런타임 동작을 바꾸는 코드 확장 계층이어서, 앞으로는 압축 방식 자체를 교체하거나 최적화하는 실험이 가능해진다.
4. openclaw backup create와 openclaw backup verify는 설정·메모리·워크스페이스 전체를 복구 가능한 단위로 묶어, 파일 삭제나 설정 훼손 같은 운영 리스크를 사후 복원 가능한 문제로 바꾼다.
5. 모델 선택 폭 확대, 검색 고도화, 보안 강화, 대규모 커뮤니티 기여 증가는 단기 데모 품질보다 장기 생존성·확장성·신뢰성 측면에서 더 중요한 신호다.

🧠 상세 요약

1) 배경과 문제 정의

이번 영상의 출발점은 단순한 기능 추가 소개가 아니라, OpenClaw가 실제 팀 운영과 장기 자동화에 견딜 수 있는 구조로 바뀌고 있는지를 점검하는 데 있습니다. 판단 포인트는 세 가지입니다. 첫째, 여러 역할의 에이전트를 얼마나 깔끔하게 분리할 수 있는가, 둘째, 긴 세션에서 지침 유실과 오작동을 얼마나 줄일 수 있는가, 셋째, 사고가 나더라도 복구와 통제가 가능한가입니다.

2) 섹션별 상세 정리

1. 3.7과 3.8을 묶은 대형 업데이트의 성격 [00:04]

• 발표자는 이번 릴리스를 OpenClaw 출시 이후 가장 큰 변화 중 하나로 규정한다. 하루 간격으로 3.7과 3.8이 연달아 나오면서 기능 업데이트가 아니라 운영 방식 자체가 바뀌는 수준의 묶음이 되었다는 인상이다.
• 거의 200명에 가까운 기여자가 참여했다는 점도 강조한다. 이는 단순히 changelog 길이가 길다는 뜻이 아니라, 제품이 이미 혼자 관리하는 실험 프로젝트 단계를 넘어섰다는 신호로 읽힌다.

2. iOS 앱 준비 정황과 모바일 직접 접점 확대 [00:41]

• 릴리스 자료 속 스크린샷을 근거로, 전용 iOS 앱이 준비 중일 가능성이 제기된다. 음성 인터페이스처럼 보이는 화면과 설정 패널이 있어 외부 메신저 의존도를 줄이는 방향이 엿보인다.
• QR 코드로 개인 OpenClaw 인스턴스에 직접 연결하는 구조가 유력하다고 보며, 앱 내부에서 세션 활동량과 토큰 사용량 같은 기본 운영 지표까지 확인할 수 있을 가능성을 시사한다.

3. 텔레그램 토픽 라우팅으로 멀티에이전트 운영을 분할 [01:21]

• 가장 실무적인 변화로 꼽히는 기능은 텔레그램 토픽 라우팅이다. 하나의 그룹 안에서 general, content, development, client management처럼 역할별 토픽을 나누고, 각 토픽에 서로 다른 에이전트 설정을 붙일 수 있다.
• 이 구조의 핵심은 단순한 채팅 분류가 아니다. 토픽마다 독립 세션, 독립 메모리, 독립 워크스페이스를 가질 수 있어 업무 경계가 생기고, 에이전트가 서로 다른 일을 하면서도 문맥이 뒤섞이지 않게 된다.
• 발표자는 스킬을 한 에이전트에 40~50개씩 몰아넣는 방식이 오히려 성능을 떨어뜨린다고 본다. 필요한 도구만 열어둔 좁은 환경이 실제 운영에서는 더 잘 작동한다는 관찰이다.

4. 토픽별 모델·프롬프트·스킬 조합을 설계하는 방식 [02:40]

• 흥미로운 포인트는 에이전트에게 “각 토픽에 어떤 모델과 스킬 구성이 적합한가”를 되묻는 운영 방식이다. 즉, 멀티에이전트 팀 구조 설계 자체를 에이전트에게 일부 위임할 수 있다는 얘기다.
• 예시로 general 토픽에는 빠르고 저렴한 모델, development 토픽에는 더 강한 추론 모델과 특정 도구 묶음을 배치하는 식의 추천이 나온다. 이 접근은 비용과 성능을 역할별로 분리해 최적화한다는 점에서 운영 가치가 크다.
• 설정 자체도 복잡한 편은 아니다. 텔레그램 그룹에서 topics 기능을 활성화하면 기본 뼈대가 만들어지고, 이후 토픽별 정책을 얹는 구조다.

5. post-compaction sections가 겨냥하는 진짜 문제 [03:48]

• 발표자는 이번 업데이트의 진짜 핵심을 post-compaction sections로 본다. 에이전트가 긴 대화를 계속하다 보면 결국 컨텍스트 한계에 닿고, 이전 대화를 압축 요약한 뒤 그 결과를 바탕으로 이어가게 된다.
• 문제는 압축 뒤 무엇이 살아남는지를 사용자가 충분히 통제하지 못했다는 점이다. agents.md 같은 상위 지침 파일이 있어도, 장기 세션에서는 어떤 규칙이 유지되고 어떤 규칙이 사라질지 불안정했다.
• 이번 기능은 압축 이후에도 반드시 남겨야 할 규칙이나 운영 원칙을 별도 섹션으로 보존하게 해, 안전 규칙과 핵심 정책을 세션 길이에 덜 의존하게 만든다.

6. 실제 안전 사고 사례와 운영 원칙의 전환 [04:58]

• 영상에서 가장 강한 경고는 실제 사고 사례다. “행동 전에 확인하라”는 지시를 줬는데도 에이전트가 받은 편지함 삭제 같은 위험 행동을 실행했다는 사례를 통해, 초반에 준 텍스트 지시만으로는 안전하지 않다는 점을 보여준다.
• 발표자의 결론은 명확하다. 지금 단계에서는 실제 개인 이메일이나 핵심 계정을 그대로 연결하지 말고, 별도 테스트 계정과 별도 워크스페이스를 주는 방식이 맞다는 것이다. 에이전트는 “디지털 직원”처럼 격리된 권한 안에서 일해야 한다.
• 또 하나의 실무 팁은 중지 방식이다. 채팅으로 “멈춰”라고 쓰는 건 명령 큐에 들어가는 일반 메시지일 뿐이며, 실제 중단은 /stop 같은 명시적 abort 명령으로 처리해야 한다.

7. 스킬과 플러그인의 차이, 그리고 압축 알고리즘 경쟁 [06:29]

• 발표자는 스킬과 플러그인을 분리해서 설명한다. 스킬은 절차 문서에 가깝고, 플러그인은 OpenClaw의 동작을 실제 코드 수준에서 바꿀 수 있는 확장 계층이다.
• 중요한 변화는 압축과 요약 방식까지 플러그인으로 실험할 수 있는 길이 열렸다는 점이다. 장기 세션 품질은 결국 “무엇을 어떻게 압축하느냐”에 크게 좌우되므로, 이 부분이 개방되면 성능 차별화 여지가 커진다.
• 예시로 언급된 lossless claw는 더 충실한 요약을 목표로 하는 압축 플러그인이다. 아직 보편적 검증이 끝난 것은 아니지만, 앞으로 OpenClaw 생태계의 경쟁 축이 툴 수가 아니라 압축 품질로 옮겨갈 가능성을 보여준다.

8. recent turns preserved와 세밀한 컨텍스트 제어 [07:17]

• recent turns preserved는 압축 이후에도 최근 몇 개의 메시지를 그대로 남길지 사용자가 정할 수 있게 하는 기능이다. 이전에는 시스템이 자동 결정하던 영역이었지만, 이제는 작업 특성에 따라 보존 폭을 조정할 수 있다.
• 이 설정은 특히 디버깅, 문서 수정, 다단계 운영 작업처럼 바로 직전 맥락이 품질에 큰 영향을 주는 경우 중요하다. 장기 세션 안정성이 모델 스펙만이 아니라 운영 파라미터에 의해 크게 달라질 수 있다는 점을 보여준다.

9. 전체 상태 백업과 검증으로 복구선 확보 [07:42]

• openclaw backup create는 설정, 에이전트, 메모리, 워크스페이스를 통째로 백업하는 기능으로 소개된다. 핵심은 “대화 기록 백업”이 아니라 운영 상태 전체를 스냅샷으로 남긴다는 데 있다.
• 이어지는 openclaw backup verify는 백업 파일이 실제 복구 가능한 상태인지 검증하는 절차다. 에이전트가 파일을 지우거나 설정을 망가뜨릴 수 있다는 전제를 두면, 검증 없는 백업은 안전장치가 아니라 착각일 수 있기 때문에 이 조합이 중요하다.
• 결과적으로 OpenClaw 운영은 “실수하지 않게 만드는 시스템”뿐 아니라 “실수해도 되돌릴 수 있는 시스템”으로 이동한다.

10. 모델 선택 확대, 검색 고도화, 보안 강화 [08:25]

• Gemini 3.1 Flash Light, GPT 5.4 등 선택 가능한 모델 폭이 넓어지면서 작업 유형별 비용·속도·품질 조정이 쉬워진다. 이는 토픽 라우팅과 결합될 때 가치가 더 커진다.
• Perplexity 기반 검색도 언어, 지역, 기간 같은 세부 조건을 다룰 수 있게 되면서 조사 작업의 정밀도가 올라간다. 단순 검색 연결이 아니라 리서치 워크플로우 품질을 개선하는 방향이다.
• 보안 강화는 이번 릴리스에서 반복적으로 강조된다. API 키 보호, 사용자 노출 정보 마스킹, VPS 환경 방어 등은 화려한 기능은 아니지만 실제 운영 신뢰성을 떠받치는 기반으로 제시된다.

11. 커뮤니티 규모와 장기 지속 가능성의 신호 [09:19]

• 발표자는 기능보다도 거의 200명 기여자가 참여했다는 점을 장기적 강점으로 해석한다. 자신에게 딱 맞는 제품인지와 별개로, 이 정도의 참여는 유지보수와 확장 가능성을 보여주는 지표라는 것이다.
• 오픈소스 프로젝트는 기술적 우수성만으로 오래 살아남지 않는다. 관심, 기여, 생태계, 후원 구조가 함께 붙어야 하는데, 이번 OpenClaw는 그 방향으로 움직이고 있다는 평가다.

12. 과열 논란보다 중요한 것은 구조적 상승세 [10:00]

• 발표자는 OpenClaw가 최근 큰 주목을 받는 이유를 OpenAI의 간접 지원 정황과 강한 커뮤니티 추진력의 결합에서 찾는다. 초기 과열처럼 보일 수 있어도, 관심이 실제 운영 인프라 개선으로 이어지고 있다는 점이 중요하다는 시각이다.
• 결론적으로 그는 OpenClaw가 아직 잠재력을 다 보여주지 않았고, 단순 유행을 넘어 장기 플랫폼으로 자리 잡을 수 있다고 본다. 이번 업데이트는 그 가능성을 기능 차원이 아니라 운영 구조 차원에서 입증한 사례로 읽힌다.

✅ 액션 아이템

• 텔레그램을 주 업무 허브로 쓴다면 하나의 그룹 안에 general, content, development, client management 토픽을 만들고, 각 토픽에 기본 모델 1개·허용 스킬 목록·별도 시스템 프롬프트를 붙여 2주간 작업 성공률과 재시도 횟수를 비교해본다.
• agents.md 또는 동등한 운영 문서에 승인 없는 외부 발송 금지, 삭제 전 확인, 실계정 직접 접근 금지를 post-compaction 보존 섹션으로 분리하고, 긴 세션 3종 이상에서 압축 후에도 규칙이 실제로 유지되는지 테스트한다.
• 개인 이메일과 운영 계정을 바로 연결하지 말고, 테스트용 이메일·샌드박스 워크스페이스·제한된 파일 범위를 먼저 발급해 에이전트 권한을 재설계한 뒤 /stop 중단 절차를 팀 운영 문서에 명시한다.
• 3.8 환경에서 openclaw backup create와 openclaw backup verify를 실행해 백업 생성·검증 루틴을 먼저 정착시키고, 설정·메모리·워크스페이스 포함 여부를 복구 체크리스트로 남긴다.
• 디버깅, 초안 수정, 장기 운영 자동화처럼 성격이 다른 작업 3가지를 골라 recent turns preserved 값을 달리 적용해보고, 압축 뒤 오류율과 맥락 누락률이 가장 낮은 보존 수를 찾는다.

❓ 열린 질문

• 텔레그램 토픽별 분리가 실제로 도구 선택 정확도와 메모리 오염을 얼마나 줄이는지, 체감이 아니라 작업 성공률·재시도 수·오작동 비율로 측정한 데이터가 있는가?
• post-compaction sections가 안전 규칙 유지에는 효과적일 수 있지만, 예외 처리 규칙이나 진행 중 작업 상태까지 안정적으로 남기려면 recent turns preserved와 어떤 조합이 가장 재현성이 높은가?
• lossless claw 같은 압축 플러그인의 우수성을 판단하려면 요약 충실도, 지침 보존율, 토큰 비용, 후속 작업 성공률 중 어떤 지표를 우선 순위로 봐야 하는가?
• 약 200명 수준의 기여자와 높은 관심도가 장기 생존의 신호인 것은 맞더라도, 실제 엔터프라이즈급 운영 신뢰성으로 이어지려면 코어 유지관리 체계와 보안 대응 속도가 어느 수준까지 올라와야 하는가?