오픈클로(OpenClaw)의 2026년 6월 달 변화 브리핑

안녕하세요, Seigniter의 유민수 개발자입니다.

이 글은 OpenClaw 기능 업데이트를 하나씩 소개하는 글이 아닙니다. OpenClaw의 2026년 6월 변화를 렌즈 삼아, B2B AX에서 에이전트가 어디로 가고 있는지 읽어 보려는 글입니다.

요즘 AX 논의에서 에이전트라는 말은 너무 쉽게 쓰입니다. 어떤 조직에서는 챗봇을 에이전트라고 부르고, 어떤 조직에서는 사내 검색 도구를 에이전트라고 부릅니다. 또 어떤 조직에서는 Slack에 붙은 자동 응답기를 에이전트라고 부릅니다. 모두 틀렸다고 말하기는 어렵지만, B2B 전환 관점에서는 더 엄격한 기준이 필요합니다.

기업에서 에이전트가 의미를 가지려면 답변을 잘하는 수준을 넘어야 합니다. 업무 채널에서 호출되고, 필요한 시스템에 접근하고, 외부 도구를 쓰며, 이전 실행 기록을 기억하고, 실패하면 복구하고, 권한과 승인 경계를 지켜야 합니다. 반복 업무를 학습했다면 그것을 재사용 가능한 절차로 남길 수 있어야 하고, 그 절차는 운영자가 검토하고 통제할 수 있어야 합니다.

이 기준으로 보면 OpenClaw의 6월 변화는 단순한 기능 추가가 아닙니다. 에이전트가 개인 생산성 도구에서 업무 운영 계층으로 이동하는 신호에 가깝습니다.

저는 이번 변화를 여섯 가지 흐름으로 봅니다.

에이전트의 접점이 CLI에서 업무 채널로 내려온다.
에이전트 실행은 단발 답변이 아니라 복구 가능한 workflow run이 된다.
모델 선택은 취향이 아니라 provider 실행 계약의 문제가 된다.
Tool, MCP, Plugin은 데모 기능이 아니라 업무 실행의 손발이 된다.
Skill은 프롬프트 조각이 아니라 통제 가능한 업무 자산이 된다.
보안, 권한, UI, 릴리즈 검증은 부가 기능이 아니라 운영 조건이 된다.

가장 크게 봐야 할 대목은 다섯 번째입니다. 특히 Skill Workshop의 변화가 큽니다. B2B AX에서 진짜 어려운 문제는 AI가 한 번 일을 잘하는 게 아닙니다. 잘한 일을 조직의 재사용 가능한 방식으로 남기고, 그 방식을 누가 승인하고, 어떻게 바꾸며, 문제가 생겼을 때 어떻게 되돌릴지 정하는 일입니다.

AX의 질문이 바뀌고 있다

초기 생성형 AI 도입의 질문은 대개 이랬습니다.

"직원들이 어떤 AI 도구를 쓰게 할 것인가."

그다음 질문은 이렇게 바뀌었습니다.

"어떤 업무 use case를 자동화할 것인가."

이제 B2B AX에서 필요한 질문은 한 단계 더 들어갑니다.

"어떤 업무 절차를 에이전트가 실행 가능한 단위로 바꿀 것인가."

이 차이는 큽니다. 도구 도입은 사용률을 만듭니다. use case 발굴은 PoC를 만듭니다. 하지만 업무 절차를 실행 가능한 단위로 바꾸는 일은 운영모델을 바꿉니다.

예를 들어 고객 문의를 요약하는 AI는 개인 생산성 도구에 가깝습니다. 고객 문의를 분류하고, 계약 정보를 확인하고, 과거 이슈를 검색하고, 답변 초안을 만들고, 위험도가 높으면 담당자에게 승인을 요청하고, 처리 이력을 남기는 AI는 업무 실행 시스템에 가깝습니다.

B2B에서 에이전트의 가치는 후자에서 나옵니다. 이때 필요한 것은 좋은 프롬프트 하나가 아닙니다. 채널, 세션, 도구, 권한, 기억, 승인, 로그, 재사용 가능한 절차가 함께 필요합니다.

OpenClaw의 6월 업데이트는 바로 이 층들을 하나씩 보강하는 방향으로 읽힙니다.

1. 채널: 에이전트는 별도 앱이 아니라 업무 접점으로 들어간다

OpenClaw는 Telegram, WhatsApp, iMessage, Slack, Discord, Matrix, Google Chat, Teams, WebChat, iOS, macOS 같은 채널을 계속 다듬고 있습니다. 이 변화는 겉으로 보면 메신저 지원 확대처럼 보입니다. 하지만 AX 관점에서는 더 중요한 의미가 있습니다.

에이전트는 사용자가 원래 일하는 곳으로 들어가야 합니다.

기업 사용자는 매번 터미널이나 별도 콘솔을 열지 않습니다. 영업팀은 Slack이나 Teams에서 움직이고, 현장 조직은 모바일 메신저에 익숙하며, 개발팀은 GitHub와 Discord, 운영팀은 대시보드와 알림 채널 안에서 일합니다. 에이전트가 실제 업무에 들어가려면 그 접점으로 내려와야 합니다.

그래서 Telegram의 topic routing, streamed text, 긴 답변 chunking, rich text 처리 같은 개선은 단순 UX가 아닙니다. 업무 채널에서는 어느 대화방의 요청인지, 어떤 스레드에 답해야 하는지, 긴 결과를 어떻게 끊어 보낼지, 표와 목록을 어떻게 무너지지 않게 전달할지가 실제 품질을 가릅니다.

WhatsApp의 계정별 설정, 재시작, 비활성 계정 teardown, socket cleanup도 같은 맥락입니다. 모바일 채널은 연결이 끊기고 다시 붙는 일이 자연스럽습니다. B2B 환경에서 이런 불안정성을 전제로 처리하지 못하면 현장 업무에는 들어가기 어렵습니다.

iMessage의 echo marker와 inbound restart, Slack과 Discord의 스레드와 전송 안정성, Teams의 group action 권한도 모두 채널을 단순 입출력 창이 아니라 업무 권한 경계로 본다는 뜻입니다.

AX 관점에서 채널은 사용성 문제가 아닙니다. 에이전트가 조직 안에서 어디에 배치되는가의 문제입니다. 직원이 일하는 채널 안에서 호출되고, 그 채널의 권한과 맥락을 이해하며, 답변과 실행 결과를 같은 자리로 돌려보내는 구조가 되어야 adoption이 생깁니다.

2. 런타임: 에이전트 품질은 긴 일을 끝내는 능력에서 갈린다

두 번째 흐름은 런타임입니다. OpenClaw의 Gateway, session, transcript, memory, state 저장소 관련 변화는 에이전트가 중간에 끊기지 않고 일을 이어가게 만드는 작업입니다.

기업 업무는 한 번의 답변으로 끝나지 않습니다. 보고서 하나를 만들더라도 자료 수집, 문서 검색, 데이터 확인, 초안 작성, 검토, 수정, 전송이 이어집니다. 고객지원 업무라면 더 복잡합니다. 문의를 받고, 고객 정보를 확인하고, 정책을 찾고, 과거 티켓을 보고, 답변을 만들고, 필요하면 승인 요청을 보냅니다.

이런 흐름에서 에이전트는 chat completion이 아니라 workflow run입니다.

workflow run에는 상태가 필요합니다. 어느 단계까지 끝났는지, 어떤 tool call이 실패했는지, 어떤 승인 대기 상태인지, 어떤 문서를 근거로 삼았는지 알아야 합니다. Gateway restart 이후 세션이 꼬이지 않아야 하고, stale session binding이나 session lock timeout 때문에 작업이 멈추지 않아야 합니다. interrupted tool call이 생겨도 복구할 수 있어야 합니다.

여기서 transcript는 단순한 대화 기록이 아닙니다. 실행 이력입니다. B2B 시스템으로 보면 감사 로그이자 재현 가능성의 기반입니다. 나중에 사용자가 "왜 이런 답변이 나왔나"라고 물었을 때, 어떤 모델을 썼고, 어떤 도구를 호출했고, 어떤 데이터를 참고했는지 따라갈 수 있어야 합니다.

memory와 SQLite state, embedding batch, memory search, NFS 위의 WAL 문제도 같은 층입니다. 장기 기억과 상태 저장이 불안하면 에이전트는 매번 새로 시작하는 비서가 됩니다. 반대로 상태와 기록이 안정되면, 에이전트는 이어서 일하는 운영 주체가 됩니다.

B2B AX에서 중요한 건 "AI가 대답했다"가 아닙니다. "AI가 업무 흐름을 끝까지 처리했고, 그 실행이 추적 가능하다"입니다. OpenClaw의 런타임 변화는 이 방향을 가리킵니다.

3. Provider: 모델 선택은 실행 계약의 문제가 된다

세 번째 흐름은 모델 provider입니다. OpenAI, Anthropic, Gemini, Google Vertex, OpenRouter, Kimi, Mistral, Fireworks, DeepSeek, GLM 같은 provider 연결은 단순히 선택지를 늘리는 일이 아닙니다.

B2B에서는 모델을 하나만 쓰기 어렵습니다. 비용, 품질, 지연 시간, 데이터 정책, 지역 규제, 고객 요구, 기존 계약에 따라 provider를 바꿔야 할 때가 생깁니다. 어떤 업무는 OpenAI를 쓰고, 어떤 업무는 Anthropic을 쓰며, 어떤 업무는 Vertex나 내부 라우팅을 탈 수 있습니다.

문제는 provider마다 실행 방식이 다르다는 점입니다. 모델 이름 규칙이 다르고, 인증 방식이 다르고, tool schema가 다르고, streaming 이벤트가 다릅니다. reasoning content와 prompt cache, replay 처리도 다르게 움직입니다.

OpenRouter와 Vertex의 provider prefix normalization, Anthropic의 extended thinking과 stale thinking 처리, Kimi와 DeepSeek 계열의 reasoning_content replay 보정, Mistral tool schema 처리 같은 변화는 모두 이 문제를 줄이는 작업입니다.

AX 관점에서 이것은 모델 선택의 자유가 아니라 실행 계약의 안정성입니다.

에이전트가 tool call을 수행하고, 그 결과를 다시 모델에 넣고, 필요하면 replay해야 한다면 provider 차이가 바로 운영 리스크가 됩니다. OpenAI에서는 되던 업무가 Anthropic에서는 깨지고, OpenRouter에서는 모델 ID가 어긋나고, Vertex에서는 인증 경로가 달라지는 식이면 실제 업무에는 쓰기 어렵습니다.

기업은 앞으로 모델을 바꾸는 일이 더 잦아질 겁니다. 그래서 agent platform은 provider를 갈아끼우는 수준을 넘어, provider가 바뀌어도 실행 흐름이 깨지지 않는 계층을 가져야 합니다. OpenClaw의 provider 안정화는 이 흐름을 보여줍니다.

4. Tool, MCP, Plugin: 에이전트의 가치는 외부 시스템과 만나는 곳에서 나온다

네 번째 흐름은 Tool, MCP, Plugin입니다.

LLM은 혼자서는 업무를 끝낼 수 없습니다. 검색하고, 파일을 읽고, 브라우저를 조작하고, 회의록을 만들고, 코드를 실행하고, 외부 API를 호출해야 실제 업무가 됩니다. 그래서 tool 계층은 에이전트의 손발입니다.

OpenClaw가 MCP tool result를 다루는 방식을 계속 보강하는 것도 이 때문입니다. tool이 resource_link, resource, audio, malformed image, non-text block 같은 결과를 반환했을 때, provider가 이해하는 형태로 안전하게 바꿔야 합니다. tool 결과가 잘못 들어가면 해당 호출만 실패하지 않습니다. 대화 기록 전체가 오염되고, 다음 실행도 깨집니다.

B2B 업무에서는 이 문제가 더 커집니다. 외부 시스템에서 온 데이터는 형식이 일정하지 않습니다. 어떤 API는 파일 링크를 주고, 어떤 시스템은 이미지나 오디오를 주고, 어떤 도구는 비정형 블록을 반환합니다. 에이전트가 이런 결과를 안정적으로 소화하지 못하면 업무 실행자가 될 수 없습니다.

Plugin과 ClawHub 쪽 변화도 같은 선 위에 있습니다. 외부 기능을 붙일수록 에이전트가 할 수 있는 일은 늘어납니다. 하지만 그만큼 공급망 리스크도 커집니다. GitHub commit pinning, trusted pin, plugin install policy, symlink write gate 같은 장치는 외부 코드를 어디까지 신뢰하고 어떤 범위에서 실행할지 정하는 문제입니다.

AX 프로젝트에서 흔히 놓치는 지점이 여기입니다. "API를 붙였다"는 말은 실행 능력이 생겼다는 뜻이지만, 동시에 위험도 생겼다는 뜻입니다. 파일을 읽는 도구, 브라우저를 여는 도구, 외부 API를 호출하는 도구는 모두 권한과 감사의 대상입니다.

그래서 tool 계층은 확장성만의 문제가 아닙니다. 통제 가능한 실행 능력의 문제입니다.

5. Skill Workshop: Skill은 이제 통제 가능한 업무 자산이 된다

이번 변화에서 가장 중요하게 봐야 할 지점은 Skill Workshop입니다.

많은 조직이 AI Skill을 프롬프트 묶음으로 이해합니다. "회의록 작성 skill", "제안서 검토 skill", "고객 문의 답변 skill" 같은 식입니다. 이 접근은 시작점으로는 좋지만 B2B 운영에는 부족합니다.

기업에서 Skill은 반복 업무 절차입니다. 더 정확히 말하면 에이전트가 특정 업무를 다시 수행할 때 따라야 하는 실행 명세입니다. 어떤 입력을 읽고, 어떤 도구를 쓰고, 어떤 기준으로 판단하고, 어떤 산출물을 만들고, 어떤 경우에 사람 승인을 받아야 하는지가 들어갑니다.

그렇다면 Skill은 개인이 적어 둔 프롬프트 파일이 아니라 관리 대상 자산이어야 합니다.

OpenClaw의 Skill Workshop은 이 관점을 잘 보여줍니다. Skill을 곧바로 active SKILL.md로 쓰지 않고 proposal로 먼저 만듭니다. proposal은 PROPOSAL.md로 저장되고, 내용뿐 아니라 target binding, scanner state, hash, support-file metadata, rollback metadata를 함께 가집니다. live skill이 되는 것은 apply가 일어날 때뿐입니다.

이 구조가 없으면 기업 업무에는 바로 문제가 생깁니다. 업무 절차는 마음대로 바뀌면 안 됩니다.

예를 들어 "월간 경영 리포트 작성 Skill"이 있다고 해보겠습니다. 이 Skill이 어떤 데이터 소스를 보고, 어떤 지표 정의를 쓰고, 어떤 예외를 표시하고, 어떤 문체로 요약할지는 조직의 업무 기준입니다. 에이전트가 한 번 좋은 결과를 냈다고 해서 그 절차를 곧바로 활성화하면 안 됩니다. 운영자가 검토하고, 보안 스캐너를 통과하고, 기존 버전과 충돌하지 않는지 확인한 뒤 반영해야 합니다.

Skill Workshop의 proposal first, apply-only live write, hash-bound update, scanner-gated apply, rollback metadata는 이 문제를 정면으로 다룹니다. create, update, revise 단계에서는 active skill을 바꾸지 않고, pending proposal만 다룹니다. apply 직전에는 다시 스캔하고, live 파일을 바꾸기 전에 rollback metadata를 남깁니다. live skill이 중간에 바뀌면 proposal은 stale 상태가 됩니다.

범위도 제한됩니다. Skill Workshop은 workspace skill을 대상으로 하고, bundled skill이나 plugin skill, ClawHub skill, system skill을 임의로 바꾸지 않습니다. agent가 대화에서 재사용 가능한 절차를 발견하더라도, 그것은 곧바로 조직 표준이 아니라 검토 대기 중인 제안으로 남습니다. 승인 정책도 운영자가 정합니다.

이것은 AI 업무 절차의 change management입니다.

B2B AX에서 Skill은 앞으로 세 가지 성격을 동시에 갖게 될 가능성이 큽니다.

SOP: 반복 업무를 어떻게 수행할지 정의한 절차서
Policy object: 어떤 권한과 도구를 쓸 수 있는지 정한 통제 단위
Product asset: 팀과 조직이 재사용하고 개선하는 운영 자산

여기서 Skill의 성격이 바뀝니다. 에이전트가 일을 잘하면 그 경험을 개인 프롬프트로 끝내지 않고, 조직의 Skill 후보로 승격합니다. 하지만 승격은 자동 반영이 아니라 proposal, review, approval, apply를 거쳐야 합니다. 그래야 현업의 암묵지가 조직의 재사용 자산이 되면서도 통제 범위 안에 남습니다.

B2B AX에서 이 지점은 꽤 결정적입니다. AI 도입 초기에는 prompt library를 만들었습니다. 앞으로는 skill registry와 skill governance가 필요해질 겁니다. 어떤 Skill이 표준인지, 누가 owner인지, 마지막으로 언제 바뀌었는지, 어떤 scanner를 통과했는지, 문제가 생기면 어디로 rollback할지 관리해야 합니다.

OpenClaw의 Skill Workshop 변화는 이 방향을 보여주는 작은 사례입니다. Skill이 "AI에게 주는 좋은 지시문"에서 "조직이 승인하고 관리하는 업무 실행 자산"으로 이동하고 있습니다.

6. 보안과 운영: 에이전트가 실행자에 가까워질수록 통제는 더 앞단으로 온다

여섯 번째 흐름은 보안, 권한, UI, 릴리즈 검증입니다.

에이전트가 답변만 한다면 보안 리스크는 상대적으로 작습니다. 잘못된 답변을 할 수는 있지만, 직접 파일을 지우거나 외부 API를 호출하지는 않습니다. 하지만 tool-using agent는 다릅니다. 파일을 읽고 쓰고, 명령어를 실행하고, 브라우저를 열고, 내부 시스템과 외부 시스템을 오갑니다.

그래서 exec approval timeout이 fail closed로 바뀌는 변화는 작아 보여도 무게가 있습니다. 승인이 필요한 실행에서 사용자가 응답하지 않으면 허용하지 않고 막는다는 뜻입니다. 자동화 시스템에서 침묵은 허가가 아니어야 합니다.

sandbox bind, host environment variable inheritance, MCP stdio, Codex HTTP access, Browser SSRF, malformed Host header, loopback tool 같은 이슈도 모두 같은 층입니다. 에이전트가 어디까지 볼 수 있고, 어디까지 실행할 수 있으며, 외부 입력이 내부 도구 실행으로 바뀌는 경로를 어떻게 막을지가 핵심입니다.

채널 보안도 빠질 수 없습니다. Slack, Discord, Teams, Telegram 같은 채널에서는 누가 에이전트를 호출할 수 있는지, 그룹 액션은 누가 승인해야 하는지, DM은 어떤 정책으로 열리는지 정해야 합니다. 업무 채널로 들어간 에이전트는 채널 권한과 분리될 수 없습니다.

UI와 릴리즈 검증도 운영 통제의 일부입니다. Control UI startup, WebChat backscroll, sidebar session picker, iOS stale gateway reconnect, Mac app Settings, usage footer, credential-aware limits, slow-reply diagnostics, first-event tracing 같은 변화는 운영자가 상태를 보고 원인을 찾게 해줍니다.

릴리즈 검증도 마찬가지입니다. npm package, registry tarball, integrity hash, GitHub release target, Docker, macOS app validation, E2E, smoke test, plugin publish 검증은 모두 신뢰의 문제입니다. 에이전트 플랫폼은 설치와 업데이트가 흔들리면 바로 운영 리스크가 됩니다.

기업 AX에서 보안과 운영은 마지막 체크리스트가 아닙니다. 실행 가능한 에이전트를 만들려면 처음부터 들어가야 하는 조건입니다.

OpenClaw 업데이트가 보여주는 B2B 에이전트 운영모델

OpenClaw의 6월 변화를 한 문장으로 줄이면 이렇게 볼 수 있습니다.

"에이전트가 여러 업무 채널에서 호출되고, 여러 모델 provider를 바꿔 쓰며, 외부 도구로 실제 일을 수행하고, 그 실행 절차를 Skill로 축적하되, 세션 복구와 권한 통제, 릴리즈 검증 안에서 운영되도록 정리되고 있다."

이 문장에서 중요한 단어는 "운영"입니다.

B2B AX에서 에이전트는 기능이 아니라 운영모델입니다. 업무 채널, 런타임, provider, tool, Skill, 보안, UI, 릴리즈가 맞물려야 합니다. 어느 하나만 좋아도 충분하지 않습니다. 채널이 좋아도 실행 기록이 없으면 위험하고, tool이 많아도 권한 통제가 없으면 못 씁니다. Skill이 많아도 승인과 버전 관리가 없으면 조직 자산이 되기 어렵습니다.

이제 AX 리더가 봐야 할 질문도 달라집니다.

우리 조직의 어떤 workflow가 agent-executable하게 바뀔 수 있는가
그 workflow는 어떤 채널에서 호출되어야 하는가
어떤 tool과 API를 허용하고, 어떤 실행은 금지할 것인가
반복 업무 절차는 Skill로 남길 수 있는가
Skill의 owner, 승인자, 변경 이력, rollback 기준은 무엇인가
모델 provider가 바뀌어도 실행 계약은 유지되는가
실패와 승인, 감사 로그를 어디에서 볼 수 있는가

이 질문에 답하지 못하면 AI 도입은 use case 목록에 머뭅니다. 반대로 이 질문에 답하기 시작하면 AX는 업무 운영체계의 변화로 넘어갑니다.

마무리

OpenClaw는 아직 모든 기업이 그대로 도입할 완성형 엔터프라이즈 플랫폼이라고 단정하기는 어렵습니다. 하지만 2026년 6월의 변화는 방향을 보여줍니다.

에이전트는 점점 더 많은 채널에 들어가고 있습니다. 더 긴 작업을 맡고, 더 많은 provider를 넘나들며, 더 많은 tool을 쓰고, 더 많은 권한 경계를 만납니다. 그 과정에서 Skill은 단순한 프롬프트가 아니라 조직이 관리해야 할 실행 절차가 됩니다.

저는 이 변화가 B2B AX의 다음 단계를 잘 보여준다고 봅니다.

초기 AX는 직원에게 AI 도구를 배포하는 일이었습니다. 다음 단계는 use case를 만드는 일이었습니다. 이제는 agent-executable workflow를 설계하고, 그 workflow를 안전하게 실행하며, 반복되는 절차를 Skill로 관리하는 일이 됩니다.

그래서 OpenClaw의 6월 업데이트를 단순히 "무엇이 추가됐나"로 읽으면 아쉽습니다. 더 중요한 질문은 이것입니다.

"에이전트가 조직 안에서 통제 가능한 업무 실행 단위로 성숙하고 있는가."

이 질문에 대한 대답은 점점 더 선명해지고 있습니다. 에이전트의 경쟁력은 모델 하나에서 나오지 않습니다. 채널, 런타임, provider, tool, Skill governance, 보안, 운영이 하나의 체계로 묶일 때 B2B AX의 실제 성과가 나옵니다.

이 글은 OpenClaw 공식 저장소와 공개 문서에서 확인할 수 있는 2026년 5월 중순부터 6월 14일까지의 변화 흐름을 바탕으로, Seigniter 관점에서 재구성한 분석입니다.