AI로 만든 Moltbook, Supabase RLS 미적용이 부른 유출 사고

AI가 “한 줄도 안 짰다”고 말하며 만든 서비스, 믿고 써도 괜찮을까요? 최근 바이럴된 AI 소셜 네트워크 Moltbook 사례는 ‘빠르게 만든 제품’이 어떻게 ‘빠르게 뚫릴 수 있는지’를 아주 적나라하게 보여줍니다.

Moltbook 해킹 사건 요약: “AI 소셜” 뒤에 숨은 현실

Moltbook은 AI 에이전트(Agent, 자동으로 글을 쓰고 상호작용하는 프로그램)가 글을 올리고 댓글을 달며 카르마(평판)를 쌓는, 일종의 “AI용 Reddit”을 표방했어요. 실제로 Andrej Karpathy가 X에서 극찬하면서 며칠 새 AI 커뮤니티에서 크게 주목받았고, 창업자는 스스로 “vibe-coded(AI로 감각적으로 빠르게 구현)”했다고 밝혔습니다.

그런데 Wiz 연구팀이 일반 사용자처럼 사이트를 둘러보는 수준의 비침투(non-intrusive) 리뷰만으로도, 운영(프로덕션) DB 전체에 읽기/쓰기 권한이 열려 있는 상태를 발견했어요. 결과적으로 35,000개 이메일, 150만 개에 달하는 API 토큰, 그리고 에이전트 간 **DM(개인 메시지)**까지 외부에서 접근 가능한 상태였습니다. 다행히 Wiz는 즉시 제보했고, Moltbook 팀은 수 시간 내에 조치를 진행했으며 연구 과정에서 접근한 데이터는 삭제했다고 밝혔습니다.

Supabase 설정 한 방이 만든 대형 사고: RLS 미적용의 파장

문제의 핵심은 Supabase(오픈소스 Firebase 대안, PostgreSQL 기반 BaaS)가 아니라 설정이었어요. 웹앱은 프론트엔드 JS 번들(정적 자바스크립트 파일)에 설정값이 포함되기 쉬운데, Moltbook은 여기에서 Supabase 프로젝트 정보와 API Key가 그대로 노출돼 있었습니다. Supabase는 원래 공개 키가 프론트에 있어도 괜찮을 수 있지만, 그 전제가 있습니다.

바로 RLS(Row Level Security)가 제대로 걸려 있어야 한다는 점이에요. RLS는 “이 사용자는 이 행(row)을 볼 수 있다/없다”를 강제하는 최후의 방어선인데, Moltbook은 이게 빠져 있었고, 공개 키만으로도 관리자처럼 DB를 조회할 수 있었어요. curl로 테이블을 조회했더니 에이전트의 인증 토큰까지 반환됐고, PostgREST 에러 힌트와 GraphQL 인트로스펙션(스키마 탐색)까지 결합해 약 475만 레코드 규모의 스키마가 사실상 열람 가능한 상태였다고 합니다.

유출/악용 가능했던 것들: “데이터 유출”을 넘어 “플랫폼 조작”까지

이번 사건이 더 위험했던 이유는 단순히 정보가 새나간 정도가 아니라, 계정 탈취와 콘텐츠 무결성(Integrity) 훼손까지 가능했다는 점이에요. 공개된 agents 테이블에는 api_key, claim_token, verification_code 같은 값이 들어 있었고, 이는 곧 에이전트 계정 완전 탈취로 이어질 수 있습니다. 유명한 고카르마 에이전트도 예외가 아니었고요.

게다가 owners 테이블에는 1.7만 명 이상 사용자 이메일이 있었고, 별도 observers 테이블에서 2.9만 건 추가 이메일(신규 제품 얼리액세스 신청자)도 확인됐습니다. 사용자는 DM이 비공개라고 믿고 OpenAI API 키 같은 서드파티 자격증명을 공유했는데, agent_messages 테이블이 노출되면서 이런 키가 평문으로 드러난 사례도 있었다고 해요. 더 충격적인 건, 초기 조치 이후에도 한동안 게시글 수정(PATCH) 같은 쓰기 권한이 열려 있어 기존 글을 바꾸거나 악성 프롬프트(프롬프트 인젝션)를 주입하는 것도 가능했다는 점입니다.

실제로 여러분이 운영자라면 이런 시나리오가 바로 떠오를 거예요. 예를 들어 “AI 에이전트들이 읽고 학습하는 피드”에 악성 콘텐츠를 심으면, 단순 훼손을 넘어 다른 에이전트의 행동을 유도하는 연쇄 효과까지 만들 수 있습니다. AI 서비스에선 ‘읽기 유출’도 치명적이지만, 쓰기 권한 오픈은 게임의 룰 자체를 바꾸는 수준이에요.

“에이전트 150만”의 함정: 지표는 검증과 가드레일이 필요해요

DB가 보여준 또 다른 현실은, Moltbook이 말한 “150만 에이전트”와 달리 실제 인간 소유자는 약 17,000명이었다는 점이에요. 즉 **인간 1명당 평균 88개 에이전트(88:1)**를 가진 구조였고, 루프 한 번으로 에이전트를 대량 생성할 수 있을 정도로 레이트 리밋(rate limiting, 요청 빈도 제한) 같은 기본 가드레일도 약했습니다.

이게 곧 “사기”라는 뜻은 아니에요. 오히려 ‘에이전트 인터넷’이라는 카테고리 자체가 초창기라, 창작자들이 실험적으로 지표를 만들고 커뮤니티를 키우는 단계일 수 있죠. 다만 제품/투자/운영 관점에서 보면 **참여 지표는 반드시 검증(verification)과 제어장치(guardrails)**가 있어야 신뢰를 얻습니다. 특히 “AI가 자율적으로 활동한다”는 세계관을 내세울수록, 그 정체성을 확인하는 메커니즘은 더 중요해져요.

이번 사건이 주는 5가지 보안 교훈(바로 적용 가능한 포인트)

Wiz가 정리한 교훈은 ‘AI로 빠르게 만들기’ 자체를 부정하지 않습니다. 대신 빠르게 만들수록 기본값과 체크리스트가 더 중요하다고 말해요.

• Speed vs Secure Defaults: Supabase 같은 BaaS는 설정 한 줄이 사고를 만들 수 있어요. 특히 RLS는 켜는 순간부터 시작이어야 합니다.
• 지표 검증 + 레이트 리밋: “에이전트 수/활동량”은 쉽게 부풀려질 수 있어요. Rate limiting, 생성 제한, 신원/자동성 검증이 필요합니다.
• 프라이버시 붕괴는 연쇄로 번져요: DM에서 새나간 키가 곧 OpenAI 같은 외부 서비스 침해로 이어질 수 있어요. 한 서비스의 설정 실수가 생태계 전체로 전파됩니다.
• 쓰기 권한은 읽기보다 훨씬 위험: 데이터 유출도 문제지만, 콘텐츠 조작/프롬프트 인젝션은 플랫폼 신뢰를 붕괴시킵니다.
• 보안은 반복(Iterative) 성숙: 한 번 막고 끝이 아니라, 막을수록 다른 구멍이 보여요. Moltbook도 여러 차례 수정 끝에 전체 테이블을 닫았습니다.

마무리: “vibe coding” 시대, 보안도 기본값이 되어야 해요

이번 Moltbook 사례의 메시지는 단순합니다. AI가 개발 속도를 낮춰준 만큼, ‘안전하게 만드는 장벽’은 상대적으로 더 높아졌다는 거예요. 특히 Supabase처럼 빠르게 붙는 도구를 쓸수록, “키가 노출돼도 괜찮다”는 전제를 만족시키는 RLS/권한/레이트리밋을 제품 출발점에 박아야 합니다.

지금 AI로 MVP를 만들고 있다면, 오늘 할 수 있는 질문은 하나예요. “내 앱에서 공개 키가 노출돼도, RLS와 권한 정책이 진짜로 나를 지켜주고 있나?” 이 질문을 체크리스트로 만들어 팀에 공유해보면, 다음 바이럴은 ‘사고’가 아니라 ‘성장’ 쪽으로 갈 확률이 훨씬 높아질 거예요.