회원가입 '5분 완성'이 왜 함정인가
먼저 남 얘기 같은 뉴스 하나. 지난달 개인정보보호위원회가 쿠팡에 6,246억 원의 과징금을 매겼습니다. 개인정보 제재로는 역대 최대 규모입니다. 회원 3,370만 명의 성명과 이메일이 유출됐는데, 유출 경로가 다름 아닌 '내 정보 수정' 페이지였습니다. 그런데 조사 결론은 대단한 해킹이 아니라 '기본적인 안전 관리 부족'이었습니다.
왜 이 얘기로 시작하냐면, 요즘은 AI에게 '이메일과 비밀번호로 회원가입하고 로그인되게 만들어줘'라고 한 줄만 넣으면 5분 만에 화면이 나오기 때문입니다. 서비스를 만들어 본 분이라면 대부분 이렇게 시작하셨을 겁니다. 문제는 화면이 떴다고 회원가입이 완성된 게 아니라는 점입니다.
잠깐 기초를 짚고 갑니다. 로그인은 기술적으로 두 가지 일입니다. 하나는 '너 누구야'를 확인하는 인증(authentication), 또 하나는 '확인했으니 당분간 다시 안 물어볼게'라고 기억해 주는 세션(session)입니다. 그리고 비밀번호는 서비스가 원본 그대로 저장하면 안 됩니다. 복원이 불가능한 형태로 바꿔서 저장하는데, 이 변환을 해시(hash)라고 부릅니다. 제대로 만든 서비스는 운영자조차 사용자의 비밀번호를 모릅니다. 해커가 데이터베이스를 통째로 털어가도 원래 비밀번호는 알아낼 수 없죠.
다행히 루비 온 레일즈 같은 웹 프레임워크는 이 해시를 알아서 처리합니다. 우리가 '해시 써'라고 말하지 않아도 AI가 프레임워크의 기본 장치를 써서 암호화해 저장합니다. 즉 여기까지는 도구가 챙겨 주는 기본기입니다. 진짜 문제는 그 다음, '무엇을 만들어 달라고 할지'를 사람이 정해야 하는 영역에서 시작됩니다.
빠진 것 (1)(2) — 비밀번호 찾기와 회원정보 수정
첫 번째로 빠지는 건 비밀번호 찾기입니다. 사용자는 비밀번호를 잊어버릴까요, 안 잊어버릴까요? 확률이 아니라 반드시 잊어버립니다. 그런데 한 줄 프롬프트로 만든 화면에는 '비밀번호를 잊으셨나요?'가 없습니다. 잊어버린 사용자는 다시 못 들어오고, 결국 문의 메일을 보냅니다. 서비스를 열고 처음 받는 문의의 상당수가 비밀번호 문제인데, 이걸 한 명 한 명 손으로 바꿔 주기 시작하면 서비스가 아니라 콜센터가 됩니다.
여기서 정해야 할 게 있습니다. 재설정 링크를 이메일로 보낼 텐데, 그 링크는 몇 분 동안 유효해야 할까요? 한 번 쓰면 무효로 만들어야 할까요? 링크가 계속 살아 있으면 메일함이 뚫리는 순간 계정도 함께 뚫립니다. 이런 걸 정하는 게 정책이지 코드가 아닙니다.
두 번째는 회원정보 수정입니다. 이메일을 바꾸고 싶다, 비밀번호를 바꾸고 싶다 — 당연한 요구인데 한 줄 프롬프트 결과물에는 방법이 없습니다. 여기서도 결정할 게 있습니다. 비밀번호를 바꿀 때 지금 비밀번호를 한 번 더 물어볼 것인가? 안 물어보면 카페에서 잠깐 자리를 비운 사이 계정을 통째로 뺏길 수 있습니다. 쿠팡 유출이 바로 이 '내 정보 수정' 페이지에서 났다는 걸 떠올리면, 이 결정이 얼마나 무거운지 보입니다.
빠진 것 (3) — 회원 탈퇴, 법이 걸린 결정
세 번째가 가장 중요합니다. 회원 탈퇴입니다. 탈퇴 기능 없이 서비스를 여는 경우가 생각보다 많습니다. 그런데 탈퇴를 원하는 사용자는 반드시 생기고, 방법이 없으면 그분은 화가 난 상태로 메일을 보냅니다. 그리고 이건 감정 문제로 끝나지 않습니다. 개인정보보호법상 사용자는 자기 정보를 삭제할 권리가 있습니다. 탈퇴 요청을 처리하지 않고 버티면 법의 문제가 됩니다.
탈퇴에서 정해야 할 결정은 이겁니다. 데이터를 진짜로 지울 것인가, 아니면 지운 것처럼 표시만 할 것인가. 표시만 해 두는 방식을 소프트 딜리트(soft delete)라고 부릅니다. 어느 쪽이 맞는지는 서비스 성격에 따라 다릅니다. 결제 이력이 있는 서비스라면 세법상 거래 기록을 일정 기간 보존해야 할 의무가 있어서, 전부 지우면 오히려 문제가 됩니다.
그래서 보통은 절충합니다. 이메일 같은 개인식별 정보는 익명화(누구인지 알 수 없게 지우거나 대체)하고, 거래 기록 자체는 남기는 식입니다. '탈퇴한 계정으로는 로그인이 안 되게 한다'까지 정해야 합니다. 이 판단은 코드가 아니라 정책의 영역이고, 만들기 전에 정해야 AI에게 정확히 시킬 수 있습니다.
빠진 것 (4)(5) — 처리방침과 이용약관, 그리고 복붙의 함정
네 번째와 다섯 번째는 기능이 아니라 문서입니다. 그런데 이 두 장이 법과 계약의 문제입니다. 먼저 개인정보 처리방침입니다. 여러분이 이메일 하나를 받는 순간부터 법이 말하는 '개인정보 처리자'가 됩니다. 무슨 정보를 왜 모으고, 언제까지 보관하고, 어떻게 파기하는지 정해서 공개할 의무가 생깁니다. 이걸 만들지 않거나 공개하지 않는 것만으로도 개인정보보호법상 1천만 원 이하의 과태료 조항이 걸립니다.
이용약관은 성격이 다릅니다. 이건 정부가 아니라 사용자와의 문제입니다. 약관은 사용자가 가입하는 순간 서비스와 맺는 계약입니다. 이 계약서가 없으면, 어떤 사용자가 다른 사용자에게 욕설을 하거나 사기를 쳐도 '계정을 정지합니다'라고 했을 때 '무슨 근거로요?'라는 물음에 답할 말이 없습니다. 사람이 모이는 서비스에서 약관은 운영자를 지켜 주는 문서입니다.
여기서 흔한 생각. '그 문서, 다른 데서 복사해 오면 안 되나요?' 실제로 다들 그렇게 합니다. 그런데 함정이 있습니다. 처리방침이 실제 서비스와 다르면 그 자체가 위반입니다. 수집하지도 않는 정보를 수집한다고 써 놓거나, 실제로 수집하면서 안 썼으면 맞지 않는 옷을 입은 겁니다. 그래서 이 문서는 복사가 아니라 '내 서비스가 무슨 데이터를 다루는지'에서 출발해야 합니다. 그 데이터 구조를 누가 제일 잘 알까요? 방금 코드를 짠 AI입니다.
관리자 페이지와 '소셜 로그인이면 끝'이라는 착시
회원 데이터가 생기는 순간 하나가 더 필요해집니다. 이걸 들여다보고 관리할 사람, 즉 운영자용 관리자 페이지입니다. 회원 목록을 검색하고, 가입·탈퇴 여부를 보고, 문제를 일으킨 회원을 정지시키는 화면입니다. 여기에도 결정이 숨어 있습니다. 관리자는 회원 정보를 어디까지 볼 수 있어야 할까요? 비밀번호는 해시라서 운영자도 못 봅니다. 이메일은 문의 응대를 위해 봐야 할 수도 있고요. 이렇게 관리자가 볼 수 있는 범위를 정하는 것도 '개인정보 최소 접근'이라는 원칙이 걸린 정책 결정입니다.
그리고 정지 버튼. 관리자가 회원을 정지시킬 수 있는 근거가 바로 이용약관에 있습니다. 약관 없이 정지 버튼을 만들면 운영자 마음대로 내쫓는 기능이 되고, 약관이 있으면 계약에 따른 정당한 조치가 됩니다. 문서와 기능이 이렇게 연결됩니다.
마지막으로 흔한 오해 하나. '카카오나 구글 소셜 로그인을 붙이면 이 숙제가 없어지는 것 아닌가?' 비밀번호 입력을 안 받으니 비밀번호 찾기 하나는 줄어드는 게 맞습니다. 하지만 회원 탈퇴, 처리방침, 이용약관은 그대로 다 필요합니다. 오히려 처리방침에는 '카카오로부터 어떤 정보를 받는다'는 항목이 추가로 들어가야 합니다. 소셜 로그인은 다섯 가지 중 하나를 줄여 줄 뿐, 숙제 전체를 없애 주지 않습니다.
실전 프롬프트 — AI가 먼저 되묻게 하라
그럼 실제로 어떻게 시켜야 할까요? 왼쪽이 다들 넣는 한 줄이고, 오른쪽이 실제 서비스가 가능한 수준의 프롬프트입니다. 길이 차이가 꽤 나지만, 자세히 보면 어려운 기술 용어가 없습니다. 전부 우리가 위에서 이야기한 정책 결정들입니다. 재설정 링크는 30분, 탈퇴는 표시만 하고 익명화, 처리방침은 실제 수집 항목 기준. 코딩 지식이 아니라 서비스를 어떻게 운영할지에 대한 결정들이죠.
핵심은 프롬프트 맨 끝의 한 줄입니다. '구현하기 전에, 내가 정하지 않은 정책 중 결정이 필요한 게 있으면 먼저 질문해줘.' 이 한 줄을 넣으면 AI는 바로 코드를 짜지 않고 되묻습니다. '이메일 인증을 요구할까요, 인증 없이 바로 가입할까요?' '이메일을 바꿀 때 새 이메일 인증이 필요할까요?' 이렇게 물어보는 것 자체가 공부가 됩니다. 내가 미처 생각 못 한 결정을 AI가 목록으로 꺼내 주니까요.
이 한 줄이 AI를 단순한 코더에서 기획 파트너로 바꿉니다. 답하는 과정에서 정책이 쌓이고, AI가 무엇을 묻는지를 보며 내가 모르던 걸 알게 됩니다. 실전 프롬프트에는 이 문장을 항상 넣으시길 권합니다.
이메일과 비밀번호로 회원가입하고 로그인할 수 있게 만들어 줘.
로그인하면 환영 메시지가 보이는 첫 화면도 만들어 줘.회원가입과 로그인을 구현해줘.
- 이메일과 비밀번호(8자 이상)로 가입.
- 비밀번호 재설정 링크는 가입한 이메일로 보내되, 30분 동안만 유효하고 한 번 쓰면 무효로.
- 회원정보 수정: 로그인한 사용자가 이메일/비밀번호를 바꿀 수 있게. 바꿀 때 현재 비밀번호를 한 번 더 입력받아.
- 회원 탈퇴: 내 정보 페이지에서 가능하게. 실수 방지를 위해 비밀번호를 입력받고 진행. 데이터는 진짜 삭제하지 말고 탈퇴 표시만 한 뒤 이메일 같은 개인식별 정보는 익명화. 탈퇴한 계정으로는 로그인 불가.
- 개인정보 처리방침과 이용약관 페이지를 만들고, 내용은 이 서비스가 실제로 수집하는 정보를 기준으로 작성. 모든 페이지 하단에 링크.
- 가입 시 약관/처리방침 동의 체크박스를 넣고, 동의해야 가입되게.
구현하기 전에, 내가 정하지 않은 정책 중 결정이 필요한 게 있으면 먼저 질문해줘.결론 — 실력은 결정 목록에서 나온다
정리하면 이렇습니다. AI로 회원가입을 만드는 건 5분이면 됩니다. 하지만 그게 '서비스'가 되려면 비밀번호 찾기, 회원정보 수정, 회원 탈퇴, 개인정보 처리방침, 이용약관, 그리고 관리자 페이지까지 결정 목록이 먼저 서 있어야 합니다. 코드는 AI가 짜지만, 결정은 사람이 해야 합니다.
회원가입 하나에 이만큼인데, 서비스 하나를 만드는 데는 이런 결정 목록이 수십 개씩 쌓입니다. 기능이 바뀔 때마다 데이터베이스 구조도 바뀌는데, 그 변경 이력을 안전하게 관리하는 장치를 마이그레이션(migration)이라고 부릅니다. 순서대로 기록되고 문제가 생기면 되돌릴 수 있어서, 서비스를 연 뒤에도 데이터베이스를 안전하게 고칠 수 있습니다. 그리고 그렇게 기능이 바뀔 때마다 처리방침과 약관도 계속 업데이트해야 하는데, 여기서도 코드를 아는 AI의 도움을 받을 수 있습니다.
그래서 AI 시대에 만드는 사람의 실력은 코드가 아니라 이 결정 목록에서 나옵니다. 코드는 AI가 다 짭니다. 하지만 무엇을 결정해야 하는지는, 서비스를 만들어 보고 운영하며 겪어 본 사람만 압니다. 당신의 서비스에는 이 결정 목록이 준비돼 있습니까?