최근 개발자 커뮤니티를 중심으로 OpenClaw의 Moltbot(구 Clawdbot)이 빠르게 확산되며 논란이 됐습니다. 초기에는 ‘Clawdbot’이라는 이름으로 공개됐지만, 기존 GenAI와의 상표권 혼선 이슈가 제기되며 명칭을 ‘Moltbot’으로 변경한 바 있습니다. Moltbot은 단순한 질의응답형 챗봇이 아니라, 외부 서비스와 연동돼 실제 작업을 수행하도록 설계된 AI 에이전트입니다.
개인 환경에서 실험적으로 사용되던 이 도구는 설정 과정에서 접근 범위와 권한 관리가 충분히 이뤄지지 않으며, 의도하지 않은 데이터 접근 가능성이 드러났는데요. 그 결과 Moltbot의 구조적 취약점이 그대로 노출됐고, 이는 빠르게 논란으로 확산됐습니다.
이 사건이 주목받은 이유는 사고의 규모나 피해 때문보다는, AI의 선을 넘은 권한이 유출로 이어진다는 것이 명확히 드러났기 때문입니다. Moltbot은 사용자의 지시에 따라 여러 서비스와 데이터를 연속적으로 다루며 작업을 수행했고, 이 과정에서 한 번의 판단이 곧바로 데이터 접근과 실행으로 이어졌습니다. 기존 챗봇처럼 “답변을 잘못했다”는 수준이 아니라, AI의 행동 자체가 리스크가 될 수 있다는 점이 이번 이슈의 핵심이었습니다.
IT 업계의 뜨거운 감자 Moltbot (출처 : OpenClaw 웹사이트)
비슷한 시기 등장한 Moltbook도 Moltbot 논란과 맞물려 크게 주목받았습니다. Moltbook은 AI 에이전트만이 글을 쓰고 댓글을 달며 상호작용하는 ‘봇 전용 소셜 네트워크’로 출시 직후 150만 개 이상의 계정이 등록되는 등 빠르게 규모가 커졌지만, 여러 보안 문제가 연이어 드러났습니다.
보안 업체 분석 결과, Moltbook의 데이터베이스에서 인증 없이도 API 키, 이메일 주소, 프라이빗 메시지 등 민감 정보가 노출될 수 있는 취약점이 발견됐습니다. 이로 인해 150만 개 이상의 API 토큰과 수만 건의 개인 데이터가 외부에서 접근 가능한 상태였습니다. 또한 일부 계정에는 악성 행위를 유도할 수 있는 잘못된 쓰기 권한까지 부여돼 있었습니다.
이처럼 Moltbot과 Moltbook 사례 모두에서 공통적으로 부각된 것은 AI 에이전트의 상호작용이 인간의 설계, 구성 조건에 크게 의존하며, 그 과정에서 예상하지 못한 보안 취약점과 데이터 노출 가능성이 현실화했다는 사실입니다.
AI 에이전트가 오히려 사용자에게 위협으로 변할 수 있습니다
Moltbot과 Moltbook 같은 여러 이슈에도 불구하고 AI 기술에 대한 관심이 줄어들지 않는 이유는, 조직과 개인 모두가 범용적인 AI가 보다 ‘특화된 AI’를 더욱 원하고 있기 때문입니다. 일반적인 답변을 생성하는 모델만으로는 실제 업무나 목적을 충분히 반영하기 어렵고, 결국 사용자는 자신의 데이터, 업무 방식, 도메인 맥락을 이해하는 AI를 요구하게 됩니다.
문제는 이러한 특화 과정에서 AI가 다루는 데이터의 성격이 달라진다는 점입니다. 도메인에 맞춘 AI를 만들기 위해서는 내부 문서, 로그, 대화 기록, 운영 데이터 등 외부에 노출돼서는 안 되는 정보들이 학습 및 추론 과정에 자연스럽게 포함됩니다. Moltbot과 Moltbook 사례가 보여준 것처럼, 이 단계에서 데이터 접근 범위와 사용 조건이 명확히 통제되지 않으면 의도하지 않은 노출과 확산이 발생할 수 있습니다. AI가 똑똑해질수록, 어떤 데이터를 어떻게 다루고 있는지에 대한 기준은 더 중요해지고 있습니다.
AI가 조직에게 밀접해질수록 더욱 중요해지는 보안
이제 AI는 개인의 실험이나 생산성 도구를 넘어, 기업과 조직의 업무 환경에 밀접하게 들어오고 있습니다. 특히 범용 모델을 그대로 사용하는 방식보다, 자사 업무와 도메인에 맞게 조정된 AI를 구축하려는 움직임이 증가하고 있죠. 내부 문서, 기술 자료, 고객 데이터, 운영 기록 등을 기반으로 AI를 활용해야 실제로 의미 있는 결과를 얻을 수 있기 때문입니다.
하지만 기업 환경에서 AI가 다루는 데이터는 더욱 민감할 수밖에 없습니다. 학습과 추론 과정에 포함되는 정보에는 지식재산, 내부 전략, 고객 정보, 규제 대상 데이터가 함께 섞여 있습니다. AI가 어떤 데이터를 참고하고, 어디까지 접근하며, 그 결과가 어떻게 사용 및 보존되는지에 대한 기준이 없다면 문제가 발생할 수 있습니다. Moltbot과 Moltbook에서 드러난 이슈는, 이러한 관리가 전제되지 않은 상태에서 AI를 확장할 경우 어떤 위험이 현실화될 수 있는지를 미리 보여준 사례에 가깝습니다.
결국 기업과 조직이 마주한 질문은 명확합니다.
‘AI를 도입할 것인가’의 문제가 아니라, AI가 어떤 데이터에 접근하고 그 사용 범위를 어떻게 관리할 것인가에 집중해야 합니다. 즉, AI 데이터 인프라와 거버넌스를 어떻게 설계할 것인지가 핵심 과제인 셈입니다. 도메인 특화 LLM과 AI 에이전트가 현실적인 선택지가 된 지금, 보안과 데이터 보호는 더 이상 부가적인 고려사항이 아니라 AI 활용의 전제가 되고 있습니다.
AI를 활용하는 조직에게 중요한 것은 ‘기준’
AI 데이터 인프라를 구축한다는 것은 단순히 데이터를 축적하는 일이 아닙니다. AI에 제공되는 데이터의 범위와 성격을 정의하고, 학습과 추론 과정에서의 활용 방식, 결과물의 재사용 및 확산 가능성까지 구조적으로 설계하는 일입니다. 데이터 분류 기준, 접근 정책, 사용 기록 추적, 외부 전송 통제와 같은 요소가 체계적으로 연결되지 않으면, AI가 효과적으로 관리되지 못하는 거죠. 결국 중요한 것은 모델의 성능보다, 데이터가 예측 가능한 방식으로 흐르도록 만드는 AI 인프라입니다.
또한, 이 관점에서 기업에게 필요한 것은 거버넌스 안에서 작동하는 보안 중심 LLM 환경입니다. 내부 데이터가 의도와 다르게 학습에 포함되거나 외부로 확산되지 않도록 제어하고, 도메인 특화 모델이라 하더라도 정책과 감사 체계 안에서 운영돼야 합니다.
AI가 조직의 핵심 데이터를 다루는 순간, LLM은 선택적 도구가 아니라 인프라의 일부가 됩니다. 따라서 안전한 AI 활용은 모델 도입 이후의 보완이 아니라, 설계 단계에서부터 데이터 보호를 포함하는 전략으로 시작돼야 합니다.
Moltbot과 Moltbook 사례는 AI 에이전트의 가능성과 함께, 데이터 제어가 전제되지 않은 환경이 얼마나 쉽게 위험으로 이어질 수 있는지를 보여줬습니다. 이는 AI 도입을 멈춰야 한다는 신호가 아니라, 어떤 기준 위에서 AI를 설계하고 운영할 것인지에 대한 질문을 보여준 사건에 가깝습니다. 앞으로 AI는 더 특화되고 더 깊이 조직의 데이터와 연결될 것입니다. 그 흐름 속에서 경쟁력을 좌우하는 것은 데이터를 보호하면서도 활용할 수 있는 구조를 갖추고 있는가입니다. 결국 지속 가능한 AI 전략은 신뢰를 설계하는 일에서 시작됩니다.
안전한 AI 전환, 그리고 조직에게 특화된 LLM 도입을 고민하고 계시다면 파수에게 언제든 연락해 주시기 바랍니다.
