보안팀 없이 AI로 만든 앱의 사용자 데이터를 지키는 법

우리가 아는 한 코치는 주말 동안 AI 앱 빌더로 고객 관리 앱을 만들었습니다. 세션 노트, 목표, 진행 점검 — 예전에는 공책에 적어 두던 모든 것이, 이제 검색되고 정리됩니다. 너무 잘 되어서 코치 친구 둘이 자기들도 쓰게 해 달라고 했습니다.

바로 그때 깨달았습니다. 그녀는 더 이상 자기 노트를 보관하는 게 아니었습니다. 다른 사람들의 고객에 관한 노트 — 건강 정보, 개인적인 고민, 이름 — 를 들고 있었던 겁니다. 그 데이터가 새면, 그건 그녀의 망신이 아닙니다. 그들의 망신이 되죠.

이걸 책임감 있게 다루는 데 보안팀은 필요 없습니다. 세 가지 습관, 그리고 AI 빌더에게 몇 가지 직설적인 질문을 던질 의지면 됩니다. 이 가이드는 작은 제품에 실제로 중요한 수준에서, AI로 만든 앱의 사용자 데이터를 지키는 법을 다룹니다.

당신이 실제로 무슨 사용자 데이터를 들고 있는지 알아채는 것부터

대부분의 메이커가 이걸 과소평가합니다. “그냥 가입 양식 하나 있어요”는 보통 이런 걸 가졌다는 뜻입니다.

이메일 주소 — 누군가에게 스팸이나 피싱을 보내기에 충분합니다.
행동과 연결된 이름 — 무엇을 샀는지, 무엇을 썼는지, 언제 로그인하는지.
사용자가 자유 입력 칸에 적는 무엇이든 — 그리고 사람들은 노트 칸에 뭐든 적습니다. 전화번호, 의료 정보, 연봉, 상사에 대한 불만까지요.

10분을 들여, 당신의 앱이 한 사람에 관해 저장하는 모든 정보를 적으세요. 데이터베이스 필드가 아니라 — 사람으로서의 의미를요. “이메일”, “어떤 보충제를 먹는지”, “트레이너가 그들에 관해 쓴 노트.” 그 목록이 당신의 책임 표면입니다. 이 글의 나머지는 전부 그 표면을 더 작고 안전하게 만드는 것에 관한 것입니다.

습관 1: 덜 수집하라

지키기에 가장 싼 데이터는 애초에 수집하지 않은 데이터입니다. 무언가를 지키기 전에, 목록을 줄이세요.

방금 만든 목록을 훑으며 각 항목에 대해 물으세요. 이걸 내가 쓰나? 코치의 앱은 가입 시 생년월일을 물었습니다 — AI 빌더의 가입 템플릿에 그게 들어 있었으니까요. 그녀는 그걸 어디서도 쓰지 않았습니다. AI 빌더에게 한 문장 — “가입에서 생년월일 빼고 그 칸 삭제해 줘” — 이면 민감한 데이터의 한 범주가 통째로 사라졌습니다.

앱이 흔히 수집하지만 절대 쓰지 않는 것들: 생년월일, 전화번호, 실제 주소, 성별, “어떻게 알게 되셨나요.” 이번 달에 쓰지 않는다면, 나중에 언제든 요청할 수 있습니다. 한 번 샌 건 되돌릴 수 없습니다.

습관 2: 누가 무엇을 볼 수 있는지 통제하라

이 질문에는 두 가지 버전이 있고, 둘 다 필요합니다.

앱 안에서: 한 사용자가 다른 사용자의 데이터를 볼 수 있나요? 앱에 고객과 코치가 있다면, 고객 A가 고객 B의 노트를 볼 수 있나요? AI로 만든 앱의 사용자 권한에 관해 통째로 가이드를 써 두었지만, 짧게 말하면 이렇습니다. 규칙을 평범한 말로 AI 빌더에게 설명하고(“코치는 자기 고객만 본다, 고객은 자기 자신만 본다”) 그런 다음 계정 둘로 직접 테스트하세요. 한 사용자로 로그인해, 이리저리 클릭하며 다른 사용자의 데이터에 닿아 보세요. 5분, 테스트 계정 둘이면 됩니다. 이 한 가지 테스트가 작은 앱에서 가장 흔한 누출을 잡아냅니다.

앱 밖에서: 데이터베이스 자체를 누가 볼 수 있나요? 그건 당신, 당신의 AI 빌더 플랫폼, 그리고 당신이 로그인 정보를 공유한 누구든입니다. 그래서 질문으로 이어집니다.

습관 3: 빌더에게 이 다섯 가지를 물어라

답을 깊이 이해할 필요는 없습니다. 묻기만 하면 되고, 답은 자신 있는 “예”여야 합니다. 이것들을 AI 앱 빌더에 한 번에 하나씩 붙여넣으세요.

“사용자 비밀번호가 해시되어 저장되나요, 아니면 누구나 읽을 수 있나요?” 받아들일 만한 유일한 답에는 “해시”라는 단어가 들어 있습니다. 앱이 누구나 읽을 수 있는 비밀번호를 저장한다면, 오늘 고치세요 — 보통 프롬프트 한 번이면 되는 수정이고, 대부분의 현대 빌더는 기본값으로 이걸 올바르게 합니다.
“앱으로의 연결이 암호화되어 있나요(HTTPS)?” 당신 브라우저에서 자물쇠 모양을 찾으세요. 앱 주소가 https://로 시작하면, 이건 끝입니다.
“누군가 데이터베이스 파일을 손에 넣으면, 민감한 칸을 읽을 수 있나요?” 이건 저장 시 암호화에 관한 겁니다. 대부분의 호스팅 플랫폼이 자동으로 처리합니다 — 그래도 묻고, 답을 적어 두세요.
“어떤 서드파티 서비스가 사용자 데이터를 받나요?” 이메일 도구, 분석, 결제 처리업체. 그것들을 없애라는 게 아니라 — 목록을 완전하게 만들라는 겁니다. 당신 사용자의 데이터를 들고 있는 모든 서비스가 당신의 책임 표면의 일부니까요.
“백업이 있나요, 그리고 누가 접근할 수 있나요?” 백업은 데이터의 사본이고, 사본도 보호가 필요합니다. (백업을 아예 설정하지 않았다면, 여기서 시작하세요.)

답을 문서에 저장하세요. 그 문서가 당신 보안 태세의 출발점이고, 고객이 — 혹은 고객의 변호사가 — 처음 물어오는 순간 그게 있다는 걸 다행스러워할 겁니다.

누군가 “내 데이터를 삭제해 줘”라고 할 때

결국 누군가는 그럴 것이고, 대부분의 지역의 법(유럽의 GDPR, 다른 곳의 비슷한 규정)은 정말로 그렇게 해야 한다고 말합니다. 당신의 답이 무엇일지 지금 정하세요.

한 사용자와 그에게 연결된 모든 것을 삭제할 수 있나요? 마감에 쫓기기 전에 AI 빌더에게 이걸 추가해 달라고 하세요 — “한 사용자와 그의 모든 데이터를 삭제하는 관리자 기능을 만들어 줘.”
앱에서 그들을 삭제하면 이메일 도구와 분석에서도 사라지나요? 4번 질문의 목록을 확인하세요.
백업에는 한동안 여전히 그들이 남아 있을 겁니다. 그건 정상이고 대체로 괜찮습니다 — 다만 그 사실을 알아 두어야, 정직하게 말할 수 있습니다.

준비해 둔 덕에 하루 만에 삭제 요청에 답하면 전문가다워 보입니다. 2주 동안 허둥대면, 딱 그 모습 그대로 보입니다.

평범한 말로 된 개인정보 페이지를 써라

지금은 4천 단어짜리 생성된 법률 용어는 건너뛰세요. 정직한 다섯 문장을 쓰세요. 무엇을 수집하는지, 왜인지, 또 누가 손대는지(당신의 이메일 도구, 결제 처리업체), 얼마나 오래 보관하는지, 그리고 삭제를 요청하는 법. /privacy에 두고 가입 페이지에서 링크하세요.

이건 법률 자문이 아니고, 정말로 민감한 데이터 — 건강, 아이, 금융 — 를 다룬다면 변호사와 한 시간에 돈을 쓰세요. 하지만 아무도 읽을 수 없는 그럴듯한 페이지보다, 분명하고 정직한 페이지가 낫습니다. 그리고 그걸 쓰는 일이 당신이 자기 답을 실제로 알도록 강제합니다.

기준은 당신이 두려워하는 것보다 낮고, 0보다는 높다

당신은 국가 단위 해커를 막는 게 아닙니다. 지루하고 흔한 실패들을 막는 겁니다 — 아무도 필요로 하지 않던 남은 데이터 칸, 아무도 테스트하지 않은 권한 규칙, 누가 해시하는 걸 잊은 비밀번호 테이블. 이 수준에서 사용자 데이터를 지키는 건 전문가의 기술이 아닙니다 — 그 실패 하나하나가 평범한 말로 된 프롬프트와 5분짜리 테스트로 고칠 수 있습니다.

서두에 나온 코치는 이 모두를 오후 한나절에 했습니다. 쓰지 않던 칸 둘을 삭제하고, 두 계정 테스트를 돌리고(그리고 누출 하나를 잡았습니다 — 고객들이 드롭다운에서 서로의 이름을 볼 수 있었죠), 다섯 가지를 묻고, 개인정보 페이지를 썼습니다. 그 후로 그녀의 앱은 겉보기에 전혀 달라지지 않았습니다. 하지만 친구가 “이거 내 고객 노트를 맡겨도 안전해?”라고 물었을 때, 그녀에게는 진짜 답이 있었습니다.

오후 한나절을 들이세요. 당신의 사용자는 믿음으로 데이터를 건넸습니다 — 그걸 지키는 모습이 바로 이것입니다.