사용자 데이터, '안전하다'고 말하기 전에 확인할 것들

4월 25일, PocketOS라는 렌터카 업체용 SaaS의 프로덕션 데이터베이스가 9초 만에 사라졌습니다. 백업 볼륨까지요. Cursor와 Claude Opus 4.6으로 작동하던 코딩 에이전트가 GraphQL API 호출 하나로 처리한 결과였습니다.

에이전트가 남긴 로그에는 이런 기록이 있었습니다. "내가 받은 모든 원칙을 어겼다."

Hacker News에 올라온 글에 댓글이 1,000개를 넘겼고, Guardian이 나흘 후에 기사를 냈습니다. 저도 며칠 동안 이 사건 관련 글들을 찾아 읽었는데, 솔직히 그냥 넘기기가 어려웠습니다. 저도 AI로 코드를 짜서 제품을 만들고, 그 제품에는 지금 사용자의 일정과 이메일 계정 정보가 들어오거든요.

에이전트한테 "조심해"라고 적어두는 건 보안이 아닙니다

여러 보안 분석이 공통으로 짚은 지점이 있었습니다. Zenity의 분석 제목이 "System Prompts Are Not Security Controls"였는데, 그게 핵심이었습니다. 이 사건에서 에이전트는 프로덕션 DB를 삭제할 수 있는 권한을 처음부터 갖고 있었습니다. 권한이 열려 있으면, 경고문은 경고문으로 끝납니다.

Google OAuth 검수하다가 잠깐 손이 멈췄습니다

최근에 vibebuilder.kr Google OAuth 검수를 준비하면서 권한 설정을 처음부터 다시 확인했습니다. "내가 요청하는 스코프가 진짜 필요한 것만인가"를 체크하다 보니, DB 접근 설정도 같이 보게 됐고요. PocketOS 사건을 머릿속에 두고 보니, 몇 군데에서 손이 멈췄습니다.

지금 어떻게 되어 있는지 정리해봤습니다.

지금 걸어둔 것들

RLS를 적용했습니다. 비개발자분들께 설명하면, 데이터베이스에 "각 사용자에게는 자기 데이터만 열리는 개별 자물쇠"를 다는 방식입니다. A가 로그인하면 A의 데이터만 보이고, B의 데이터는 DB 레벨에서 막힙니다. 코드에 실수가 생겨도 한 번 더 차단됩니다.

소유자 검사도 추가해뒀습니다. 요청이 들어오면 그 데이터의 진짜 주인인지를 DB가 직접 확인합니다.

OAuth 스코프는 서비스에 꼭 필요한 것만 요청합니다. 나머지는 요청하지 않습니다.

토큰은 서버에서만 씁니다. 민감한 자격증명이 브라우저 쪽으로 내려가지 않게요.

개발 환경과 서비스 환경 데이터는 분리해뒀습니다. 테스트하다가 실수로 뭘 건드려도 사용자 데이터로 이어지지 않게.

아직 안 한 것도 있습니다

저장 시 암호화는 솔직히 아직입니다. 전송 구간은 HTTPS라 암호화되지만, DB에 저장된 데이터 자체를 한 번 더 암호화하는 건 계속 뒤로 넘겼습니다. "지금 당장 꼭 필요한가"를 스스로 묻다가 미뤄온 게 맞고요.

이번에 다시 들여다보면서, 이게 다음 차례겠다 싶었습니다. '안전하다'고 말할 수 없는 항목이 아직 있습니다.

AI 덕분에 혼자서도 제품을 만들 수 있게 됐고, 그 속도는 빨라지고 있습니다. 근데 빠르게 만든다고 해서 사용자 데이터의 잠금이 자동으로 따라오지는 않습니다. 그건 여전히 제가 직접 확인해야 하는 부분이고, 9초짜리 사건을 보면서 그걸 다시 확인하게 됐습니다.

---

vibebuilder.kr 은 현재 무료 베타로 운영 중입니다. 정부지원사업 공고를 매일 추려드리는 서비스인데, 여기에 입력된 정보는 AI 학습에 쓰거나 외부에 넘기지 않습니다.

한 가지 여쭤보고 싶습니다. 서비스를 처음 써볼 때, 데이터가 어떻게 처리되는지 설명을 어디서 보고 싶으신지요. 가입 화면인지, 서비스 안 설정 페이지인지. 저는 어디에 두는 게 낫겠다 싶은지 아직 확신이 없어서, 써보신 분 의견이 궁금합니다.

 

https://vibebuilder.kr/