Supabase 노출 보도, AI 앱의 완성 기준을 묻다

앱은 돌아가는데 데이터 경계는 비어 있었다

9월 25일 TechCrunch 보도에 따르면 보안 업체 UpGuard는 Supabase에 호스팅된 약 1만 6천 개 데이터베이스에서 일정 수준의 개인정보가 외부에 노출된 것을 발견했다고 밝혔다. 보도는 이름, 주소, 전화번호 등을 언급하며 일부 인증 관련 정보도 포함됐다고 전한다.

여기서 숫자의 의미를 정확히 해야 한다. 약 1만 6천은 연구자가 제시한 데이터베이스 수이며 피해자 수나 전체 Supabase 프로젝트 대비 비율이 아니다. 원자료의 표본과 탐지 기준을 모두 독립 검증한 수치도 아니다. 또 모든 노출 앱이 AI로 만들어졌다고 확인된 것은 아니다.

보도는 UpGuard 연구 페이지를 연결하지만, 이번 확인에서는 연구 본문 전체를 안정적으로 확보하지 못했다. 따라서 규모와 노출 유형은 TechCrunch가 연구자를 취재해 전한 내용으로 한정한다. 노출된 서비스나 개인정보를 직접 조회한 분석이 아니다.

플랫폼 전체 침해와 설정 오류를 구분해야 한다

이번 기사는 Supabase의 중앙 시스템이 뚫려 모든 고객 데이터가 유출됐다는 발표가 아니다. 외부에서 접근할 수 있게 설정된 고객 프로젝트가 문제의 중심이다. TechCrunch에 답한 Supabase 보안 책임자는 프로젝트가 기본적으로 안전하며, 회사가 기본값과 도구를 제공하고 고객이 자신의 설정을 통제하는 공유 책임 구조라고 설명했다.

이 반론 역시 함께 읽어야 한다. 안전한 기본값이 있다고 이후의 잘못된 권한 변경이 불가능해지는 것은 아니다. 반대로 고객 설정 문제가 발생했다고 플랫폼의 모든 보안 장치가 무의미한 것도 아니다. 제품의 기본 설정, 코드 생성 도구의 변경, 운영자의 확인 절차를 각각 나누어 보아야 한다.

AI 코딩이 중요한 이유는 취약점의 원리가 새로워서가 아니다. 앱과 데이터 테이블을 만드는 속도가 빨라지면서 권한 설계가 그 속도를 따라가지 못할 수 있기 때문이다. 화면에서 데이터가 보이게 하는 데 성공한 순간을 배포 완료로 간주하면, 누가 그 데이터를 보지 못해야 하는지 놓치기 쉽다.

공개 키와 비밀 키는 서로 다른 문제다

Supabase API 키 문서는 배포되는 브라우저·모바일 앱용 공개 키와 통제된 서버 환경의 비밀 키를 구분한다. 공개 키는 사용자 인증 자체를 대신하지 않는다. 공개 키가 보인다는 사실만으로 곧바로 비밀 유출이라고 부르는 것도 정확하지 않다.

반면 비밀 키는 RLS를 우회할 수 있으므로 클라이언트에 포함하면 안 된다. 공개 키를 숨기려는 노력만으로 접근 제어가 완성되는 것도 아니다. 실제 사용자의 인증 정보와 데이터베이스 권한이 결합해 누가 어떤 행을 읽고 수정할지 결정해야 한다.

Supabase RLS 문서는 노출된 스키마의 테이블에서 권한 부여와 행 정책을 함께 다뤄야 한다고 설명한다. PostgreSQL 행 보안 문서도 RLS와 일반 권한의 관계, 테이블 소유자 등 예외를 구분한다. RLS는 유용한 장치지만 시스템의 모든 경로를 대신 검사하는 마법 스위치는 아니다.

성공 테스트보다 거절 테스트가 중요하다

일반적인 시연은 사용자가 로그인하고 자기 데이터를 읽는 장면을 보여준다. 그러나 데이터 격리는 “하면 안 되는 요청”이 거절되는지 확인해야 증명할 수 있다. 이 차이가 AI 생성 앱의 검증에서 특히 중요하다.

자신이 소유하거나 명시적으로 시험 권한을 가진 개발 환경에서, 테스트용 사용자 두 명과 가짜 데이터를 준비하는 방법이 유용하다. 비로그인 상태에서 개인 행을 읽을 수 없는지, 사용자 A가 사용자 B의 행을 읽거나 수정할 수 없는지, 관리 기능이 일반 계정에 열리지 않는지를 확인한다. 실서비스 개인정보를 수집하거나 다른 프로젝트를 탐색할 이유는 없다.

읽기만 검사해서도 부족하다. 쓰기·수정·삭제 권한은 각각 잘못 설정될 수 있다. 새 테이블이나 뷰, 서버 함수가 추가되면 기존에 통과한 정책 검사 범위를 벗어나는지도 봐야 한다. 사내 코드 벤치마크의 필요성처럼 실제 서비스의 경계 조건이 평가에 들어가야 한다.

한국 팀의 배포 완료 기준을 바꿀 때

국내 스타트업과 사내 도구 팀은 “페이지가 뜬다”와 “개인정보를 안전하게 다룬다”를 별도 완료 조건으로 두는 편이 좋다. 고객 상담, 채용, 결제 보조 같은 앱은 작아 보여도 민감한 업무 맥락을 담는다. 모델이 코드를 작성했는지와 무관하게 운영 책임은 서비스 팀에 남는다.

기업 데이터 거버넌스 분석에서 다룬 권한과 출처의 문제는 이런 작은 앱에도 적용된다. 개발 속도가 빠를수록 스키마 변경 이력, 정책 검토자, 배포 전 거절 테스트를 함께 남기는 것이 유지보수 비용을 줄일 수 있다.

이미 자신의 프로젝트에서 노출이 의심된다면 접근 경로를 제한하고 로그를 보존한 뒤, 실제 노출 정보와 비밀 키 유출 여부를 구분해 대응해야 한다. 단순히 화면을 숨기거나 프런트엔드 버튼을 지우는 것으로 데이터 접근이 차단되는 것은 아니다.

AI 코딩 이후 CI를 재설계한 사례처럼 생성 속도에 맞춰 검증 구조도 바뀌어야 한다. 이번 보도의 핵심은 특정 플랫폼을 포기하라는 구호보다, 자동화된 구현에 자동화된 접근 제어 검증을 짝지어야 한다는 데 있다.

자주 묻는 질문

Supabase 전체가 해킹됐다는 보도인가?

아니다. 보도의 중심은 일부 고객 프로젝트의 공개 접근과 권한 설정 문제다.

1만 6천은 피해자 수인가?

아니다. UpGuard가 발견했다고 밝힌 데이터베이스 수이며 개인 수나 전체 프로젝트 비율과 다르다.

공개 API 키는 반드시 숨겨야 하나?

공개용 키와 서버 비밀 키를 구분해야 한다. 공개 키는 클라이언트 사용을 전제로 하며 실제 데이터 보호는 인증과 권한 정책에 달려 있다.

RLS를 켜면 검증이 끝나나?

아니다. 역할별 권한, 정책 조건, 우회 가능한 서버 경로를 함께 확인하고 거절돼야 할 요청을 시험해야 한다.

가장 작은 배포 전 검사는 무엇인가?

소유한 테스트 환경에서 비로그인·사용자 A·사용자 B의 가짜 데이터를 이용해 교차 계정 읽기와 쓰기가 차단되는지 확인하는 것이다.