요약

entity/lovable 플랫폼에서 비코더 사용자들이 만든 React 앱 170 개 의 인증 (로그인) 로직이 한꺼번에 반대로 뒤집혀 작동하는 충격적인 사고가 발생했다. 사용자들은 인증 사양을 자연어로 "관리자만 admin 페이지에 접근 가능" 처럼 모호하게 명시했는데, AI 에이전트가 이 모호함을 자기 나름대로 해석 한 결과 로그인하지 않은 익명 사용자에게 관리자 권한이 부여되고, 실제 로그인한 정당한 사용자는 오히려 접근이 차단되는 정반대의 코드를 생성했다. 더 무서운 것은 이 사고가 한 앱의 사고 가 아니라 Lovable 의 170 개 앱이 같은 패턴으로 동시에 망가졌다 는 점이다. AI 가 같은 모호한 사양을 같은 잘못된 방식으로 일관되게 해석한 결과다. 핵심 교훈: 요구사항이 모호하면 AI 는 공백 부분에 대해 자율적으로 판단권을 행사 하고, 그 판단이 틀릴 가능성은 결코 작지 않다 — 인증·권한·결제 같은 반대로 작동하면 치명적인 영역일수록 사양은 명시적·검증 가능한 형태여야 한다.

상세

무슨 일이 있었나

• 서비스: Lovable
• 영향 범위: 170개 앱
• 인증 로직 역전:
  • 비로그인 사용자 → 관리자 권한 부여
  • 정상 사용자 → 접근 차단

원인 분석

• term/spec 에 인증 의미가 모호 하게 기술됨
• AI 가 모호한 부분을 임의로 채움
• 채워진 방향이 반대 였음

핵심 교훈

"모호한 요구사항 = AI 에게 위험한 판단권을 위임하는 것."

→ 즉 명세 누락의 비용 이 아니라 모호한 명세의 비용 이라는 점이 본 사례의 차별점.

강의 활용

02 VBC lesson/vbc-failures-and-causes 모호함의 비용 핵심 사례:

• 메시지:
  1. "170개 앱이 한꺼번에 망가졌습니다."
  2. "명세가 없어서 가 아닙니다 — 모호해서 입니다."
  3. "AI 는 빈칸을 채웁니다. 반대 방향 으로요."
  4. "Spec 의 모호함 = 위험한 판단권 위임."
• 04 DSL 연결: 명세를 어떻게 모호하지 않게 쓸 것인가 — Constraints 와 Acceptance criteria 명시.

주의사항

• 170개의 무게: 단일 앱 사고가 아닌 170개 동시 영향 — 플랫폼 단위 사고 의 무게 강조.
• 명세 누락 vs 모호함 구분: case/moltbook-token-leak (누락) 과 본 사례 (모호함) 가 다른 패턴 임을 명시.
• AI 비판 균형: AI 가 반대로 해석 한 게 AI 의 잘못 으로 들리지 않게 — Spec 모호함이 원인 이라는 책임 재분배 일관 유지.
• 출처 정직성: getautonoma.com 1차. 학술 엄밀성은 약함.