요약

Moltbook 이라는 서비스에서 데이터베이스 보안의 기본 장치인 Row Level Security (RLS — 행 수준 보안) 가 설계 단계에서 정의되지 않은 채로 운영에 들어간 결과 발생한 대규모 유출 사고. 개발자가 AI 에 "사용자별로 데이터를 저장하고 가져오는 기능" 을 짜달라고 요청하자 AI 는 기능 자체는 정상 작동하는 코드를 만들어냈다. 그러나 RLS 를 박아 사용자별로 자신의 데이터만 접근할 수 있게 제한하라 는 명시적 지시가 없었기 때문에, AI 는 모든 사용자의 데이터를 누구나 조회 가능한 형태 로 코드를 작성했다. 결과적으로 공용 API 키 하나만 알면 150 만 개의 인증 토큰과 사용자들의 개인 메시지 전체에 접근할 수 있는 상태가 운영에 그대로 배포되었다. 본 사례의 핵심 교훈은 — AI 는 눈에 보이는 기능적 코드 는 능숙하게 짜지만, 눈에 보이지 않는 보안 장치 (RLS·권한·암호화 등) 는 명시적으로 지시하지 않으면 구현하지 않는다 는 점이다. 보안은 침묵의 영역 이라 사용자가 명시하지 않으면 AI 도 박지 않는다.

상세

무슨 일이 있었나

• 서비스: Moltbook
• 결과: 150만 개 인증 토큰 + 개인 메시지 유출
• 트리거: 공용 API 키 1개 노출

원인 분석

• 설계 단계에서 RLS (Row Level Security) 미정의
• 즉 term/spec 에 보안 제약 조건 이 빠져 있음
• AI는 기능적 코드는 작성했지만 보이지 않는 보안 장치 는 자발적으로 구현하지 않음

핵심 교훈

"AI는 기능적 코드는 잘 짜지만, 보이지 않는 보안 장치는 지시 없이 구현하지 않는다."

강의 활용

02 VBC lesson/vbc-failures-and-causes 보안 측면 핵심 사례:

• 메시지:
  1. "기능 잘 작동하면 OK 인가요?"
  2. "150만 토큰이 새는 데 30초 걸렸습니다."
  3. "AI는 지시받지 않은 보안 장치를 알아서 만들지 않습니다."
  4. "Spec에 보안 제약을 명시 하는 것 — 이게 term/persistent-instructions 의 출발점."
• 이어지는 04 DSL 단원에서 Spec 작성 방법 으로 환원.

주의사항

• 숫자의 무게: 150만 토큰 — 슬라이드에 큰 폰트.
• RLS 용어 부연: 청중에게 Row Level Security = 행 단위 권한 제어 짧은 부연 필요.
• AI 책임 재분배: AI 잘못이 아닌 우리(Spec 작성자) 잘못 이라는 메시지 — 청중의 AI 비판 회피 욕구를 자극하지 않도록 균형.
• 출처 정확성: getautonoma.com 보고가 1차. 학술적 엄밀성은 약함 — 강의에서 현장 보고 위주로 인용.
• 다른 보안 사례와의 묶음: case/lovable-auth-inversion / case/security-flaw-53-percent 와 한 슬라이드에 묶으면 수렴 패턴.