Anthropic은 왜 OpenClaw를 막았을까? 플랫폼 리스크 이야기

최근에 "Anthropic just blocked OpenClaw"라는 이야기를 보면서, 저는 이 사건을 단순히 한 회사가 한 툴을 막은 뉴스로만 보지 않았습니다. 오히려 훨씬 익숙한 문제로 읽혔습니다. 우리가 편하다고 느끼는 워크플로우 하나가 사실은 남의 플랫폼 위에 위태롭게 서 있을 수 있다는 점입니다.

AI를 자주 쓰지 않는 분도 이 얘기는 어렵지 않게 이해하실 수 있습니다. 넷플릭스에서 보던 콘텐츠가 어느 날 사라지는 일, 인스타그램 알고리즘이 바뀌는 순간 도달률이 반 토막 나는 일, 잘 쓰던 외부 앱 연동이 정책 변경 한 번으로 멈추는 일과 비슷합니다. 이번 일도 본질은 같습니다. 내가 익숙하게 쓰던 방식이 "공식적으로 허용된 길"이 아니었다면, 어느 날 바로 끊길 수 있다는 겁니다.

🔍 이번에 실제로 무슨 일이 있었을까

외신 보도를 보면, Anthropic은 자사 소비자용 Claude 구독 계정으로 서드파티 하네스(harness)를 통해 자동화하는 방식에 대해 더 강하게 차단하기 시작했습니다. The Register 보도에 따르면 Anthropic은 기존 소비자 약관과 법적 안내를 다시 분명히 하면서, Claude Free·Pro·Max 계정에서 받은 OAuth 토큰을 다른 제품이나 서비스에서 사용하는 것은 허용되지 않는다고 명시했습니다. 또 Anthropic의 소비자용 약관에는 원래부터 API 키나 별도 허용 없이 봇, 스크립트 같은 자동화 수단으로 서비스에 접근하면 안 된다는 문구가 들어 있었습니다.

쉽게 말하면 이렇습니다. 사람 한 명이 공식 앱에서 대화하라고 만든 구독제를, 다른 툴이 대신 붙어서 자동화 엔진처럼 돌리기 시작하면 플랫폼 입장에서는 비용 구조도 흐트러지고, 문제 발생 시 책임 소재도 복잡해집니다. 사용자는 "Claude가 이상하다"고 느끼지만, 실제로는 그 중간에 붙은 래퍼나 자동화 루프가 원인일 수 있기 때문입니다.

VentureBeat 보도도 비슷한 맥락을 전했습니다. Anthropic은 서드파티 툴이 자사 공식 클라이언트인 것처럼 보이게 만드는 스푸핑을 더 강하게 막았고, 이유로는 디버깅 불가능한 트래픽 패턴과 비용 문제를 함께 언급했습니다. 이건 결국 기술 이슈이면서 동시에 수익 모델 이슈이기도 합니다.

💸 왜 막았을까, 정말 이유는 하나일까

제 생각에 이건 한 가지 이유로 설명하면 오히려 놓치는 게 많습니다. Anthropic이 OpenClaw 같은 흐름을 막은 배경에는 최소 세 가지가 겹쳐 있다고 봅니다.

첫째는 비용입니다. 월 구독형 상품은 보통 "사람이 적당히 쓴다"는 가정 위에서 설계됩니다. 그런데 자동화 에이전트는 밤새 코드를 돌리고, 다시 테스트하고, 또 수정하는 식으로 훨씬 빠르고 많이 사용합니다. 같은 20만 원대 구독이라도 어떤 사용자는 하루 몇 번 질문하고 끝나지만, 어떤 사용자는 사실상 API처럼 갈아 넣을 수 있습니다. 플랫폼이 이런 사용까지 모두 감당하면 손익이 무너지기 쉽습니다.

둘째는 통제입니다. 플랫폼 회사는 자기 서비스가 어떤 환경에서 어떻게 쓰이는지 알아야 장애 대응도 하고 정책도 세웁니다. 그런데 중간 래퍼가 끼면 데이터 흐름이 가려집니다. 에러가 나도 원인을 바로 파악하기 어렵고, 사용자는 공식 서비스의 문제로 인식합니다.

셋째는 제품 전략입니다. 솔직히 말해, 모델 회사는 좋은 모델만 만드는 데서 끝나지 않습니다. 결국 사용자가 어디에서 일하는지도 가져오고 싶어 합니다. 즉 모델만 빌려주는 공급자가 아니라, 작업 환경 전체를 자기 플랫폼 안으로 끌어오려는 겁니다. 공식 앱, 공식 코드 툴, 공식 API를 밀고 싶은 이유가 여기에 있습니다.

🧩 이 사건이 일반 사용자에게 왜 중요할까

"나는 OpenClaw나 Claude API를 안 쓰는데요"라고 느끼실 수도 있습니다. 그런데 제가 보기엔 이 사건의 교훈은 개발자보다 일반 사용자에게 더 중요합니다. 요즘 많은 분들이 업무를 특정 AI 서비스 하나에 깊게 얹고 있기 때문입니다.

예를 들어 어떤 분은 콘텐츠 기획을 전부 한 챗봇에만 맡깁니다. 어떤 분은 회의 요약, 문서 정리, 번역, 이메일 초안을 한 서비스 안에서만 처리합니다. 어떤 팀은 특정 AI 툴의 프로젝트 보드, 메모리, 프롬프트 구조에 아예 업무 방식을 맞춰버립니다. 그 상태에서 가격 정책이 바뀌거나, 기능이 유료 플랜으로 밀리거나, 한국어 품질이 흔들리거나, 계정 제한이 걸리면 어떨까요. 툴 하나를 잃는 게 아니라, 일하는 리듬 자체가 무너집니다.

저는 이걸 늘 "도구 리스크"보다 "업무 구조 리스크"라고 봅니다. 진짜 위험한 건 서비스 하나가 사라지는 게 아닙니다. 그 서비스가 사라졌을 때 내 일이 다른 데로 옮겨가지 못하는 상태가 위험합니다.

한때 많은 브랜드가 페이스북 페이지만 열심히 키웠다가, 도달률이 급감하자 고객 접점 자체를 잃어버렸습니다. 쇼핑몰들이 특정 마켓플레이스 한 곳에만 기대다가 수수료와 노출 정책이 바뀌면서 수익성이 흔들린 적도 많았고요. AI도 똑같습니다. 지금은 편해서 몰리지만, 어느 순간 규칙은 플랫폼이 정합니다.

📦 그래서 필요한 건 "백업 툴"이 아니라 "백업 워크플로우"

이 지점에서 자주 생기는 오해가 있습니다. 많은 분이 "그럼 ChatGPT 하나 더, Claude 하나 더 써두면 되는 거네요"라고 생각합니다. 반은 맞고 반은 틀립니다. 모델을 여러 개 아는 건 중요하지만, 더 중요한 건 내가 하던 일을 다른 툴로 옮길 수 있는 구조를 만들어두는 것입니다.

예를 들어 프롬프트가 특정 서비스 내부 프로젝트에만 저장돼 있으면 옮기기 어렵습니다. 회의 요약 결과가 그 플랫폼 내부 메모리에만 쌓이면 검색과 재활용이 막힙니다. 문서 초안이 특정 AI 워크스페이스에만 남아 있으면 팀원과 공유하는 순간부터 의존도가 더 커집니다.

그래서 저는 요즘 AI를 쓸 때 세 가지를 더 중요하게 봅니다. 첫째, 프롬프트와 템플릿은 복사 가능한 문서로 따로 관리할 것. 둘째, 결과물은 노션·구글독스·로컬 폴더처럼 내가 통제 가능한 저장소로 빼둘 것. 셋째, 핵심 업무는 최소 두 개 이상의 모델로 대체 가능하게 설계할 것. 결국 중요한 건 "어떤 AI가 제일 똑똑한가"보다 "내 업무가 얼마나 이동 가능한가"입니다.

🧠 데이터 이식성은 생각보다 더 중요하다

AI 시대의 데이터 이식성은 단순히 파일 다운로드 기능이 있다는 뜻이 아닙니다. 내가 쌓은 문맥, 템플릿, 자주 쓰는 명령, 팀의 작업 방식까지 다른 환경으로 옮길 수 있어야 한다는 뜻에 가깝습니다.

이게 왜 중요하냐면, 요즘 AI 툴의 진짜 잠금 효과는 모델 성능보다 사용 습관에서 나오기 때문입니다. 처음에는 그냥 질문 몇 개 던지는 정도였는데, 점점 내 어투를 기억시키고, 자주 쓰는 프롬프트를 저장하고, 특정 프로젝트 맥락을 축적하게 됩니다. 그러면 어느 순간 툴을 바꾸는 비용이 너무 커집니다. 그래서 계속 남게 됩니다. 좋게 말하면 편의성이고, 냉정하게 말하면 락인(lock-in)입니다.

이번 Anthropic과 OpenClaw 이야기도 그 연장선에 있습니다. 사용자는 더 편하고 더 싸게 쓰고 싶었고, 플랫폼은 그 우회 경로를 오래 두고 싶지 않았습니다. 둘 다 이해는 됩니다. 다만 사용자 입장에서 중요한 건 누가 더 나쁘냐를 따지는 게 아니라, 이런 긴장이 앞으로도 반복된다는 사실을 받아들이는 겁니다.

🚦현실적으로 어떻게 운영해야 할까

제가 권하고 싶은 방식은 과장된 위기감이 아니라, 현실적인 운영 기준을 세우는 것입니다. 중요한 업무일수록 한 서비스에 100% 의존하지 않는 게 좋습니다. 메인 모델 하나를 정하되, 대체 모델 하나는 항상 테스트해두는 편이 안전합니다. 자동화가 들어가는 작업이라면 더 그렇습니다. 오늘 잘 되던 연결이 내일 정책 변경으로 막힐 수 있기 때문입니다.

그리고 가능하면 "생성"과 "보관"을 분리하는 게 좋습니다. AI는 생성 엔진으로 쓰고, 보관은 노션이나 문서 시스템, 혹은 사내 저장소로 분리하는 식입니다. 그래야 모델을 바꿔도 기록은 남습니다. 여기에 더해, 중요한 반복 작업은 간단한 SOP처럼 문서화해두면 좋습니다. 예를 들어 블로그 초안 작성, 뉴스레터 요약, 회의 정리 같은 작업이 어느 서비스 버튼 몇 개에만 묶여 있으면 위험하지만, 입력값과 원하는 결과 형식이 문서로 정리돼 있으면 다른 도구로 옮기기 훨씬 쉽습니다.

결국 플랫폼 리스크를 줄이는 가장 좋은 방법은 기술 예측이 아니라 구조 설계입니다. 어떤 회사가 누구를 막을지 맞히는 건 어렵지만, 막혀도 돌아가게 만드는 건 지금 할 수 있습니다.

🎯 마무리하며

이번 사건을 보면서 저는 다시 확인했습니다. AI 시대에 필요한 건 "최신 툴을 제일 빨리 쓰는 사람"이 아니라, "툴이 바뀌어도 일의 흐름을 유지하는 사람"이라는 점입니다.

Anthropic이 OpenClaw를 왜 막았는지에 대한 답은 의외로 단순합니다. 비용을 통제하고, 사용자 경험을 통제하고, 자사 플랫폼 경로를 통제하기 위해서입니다. 이건 앞으로 다른 회사들도 비슷하게 할 가능성이 높습니다. 그래서 우리 쪽 대응도 분명해야 합니다. 하나의 서비스에 몰입하더라도, 기록은 바깥에 남기고, 대체 경로를 준비하고, 핵심 업무는 이식 가능하게 설계해야 합니다.

AI 도구는 앞으로 더 좋아질 겁니다. 하지만 플랫폼도 동시에 더 닫힐 수 있습니다. 그 사이에서 살아남는 방법은 하나입니다. 편한 도구를 쓰되, 내 일의 주도권은 넘기지 않는 것. 저는 그게 이번 이슈가 남긴 가장 현실적인 교훈이라고 봅니다.