본문 바로가기
구축기술

번호 인증까지 다 만들어 놓고, 안 쓰기로 했습니다

무료 진단 리포트를 휴대폰 번호 인증 뒤에 주려다 접었습니다. 번호 한 칸에 딸려 오는 처리방침 개정과 문자 발송 준비, 그리고 대신 고른 사람 확인 방식을 정리했습니다.

휴대폰 번호 인증 화면을 끝까지 만들어 놓고, 켜기 직전에 접었습니다. 번호 한 칸이 생각보다 훨씬 무거웠습니다.

이 글 3줄 요약

  • 무료 진단 뒤에 주는 AI 리포트를 '번호 인증한 분께만' 주려고 기능을 다 만들었다가, 하루 사이에 방향을 뒤집었습니다.
  • 전화번호를 받는 순간 처리방침 개정, 미리 알리는 기간, 문자 발송 준비, 번호 관리 규칙이 줄줄이 따라왔습니다.
  • 번호 대신 '사람 확인 + 접속당 하루 1번'으로 바꾸자 손님은 덜 기다리고, 제 손일은 대부분 사라졌습니다.

무엇을 만들고 있었나

저는 사장님이 가게 링크를 넣으면 공개된 정보를 읽어 점수를 매겨 주는 무료 가게 진단 웹앱을 운영하고 있습니다. 여기에 한 단계를 더 얹으려 했습니다. 결과지 아래에서 'AI 리포트'를 받으면 4주 실행 계획, 항목별 자세한 처방, 바로 복사해 붙일 수 있는 완성 문구를 드리는 기능입니다.

처음 그린 흐름은 이랬습니다.

  1. 결과지 아래 'AI 리포트 받기' 버튼을 누릅니다.
  2. 휴대폰 번호를 넣고 동의 항목 3개에 체크합니다.
  3. 문자로 받은 인증번호(6자리, 5분 안에 입력)를 넣습니다.
  4. '인증됐어요'가 뜨고, 3분쯤 뒤 메시지로 리포트 링크를 받습니다.

구현은 코딩 AI 도구(말로 시키면 코드를 짜 주는 AI)에 맡기고, 다른 AI에게 검수를 시키는 방식으로 진행했습니다. 인증 화면까지 실제로 다 만들었습니다. 문자는 실제로 나가지 않게 꺼 둔 시험 모드였고, 입구도 비밀 링크로 연 제 브라우저에서만 보이게 숨겨 두었습니다. 기능만 놓고 보면 거의 다 된 상태였습니다.

켜려고 보니 번호 한 칸에 짐이 줄줄이 달려 있었습니다

문제는 기능이 아니라 번호였습니다. 계획표를 다시 펼쳐 '이걸 진짜로 켜려면 무엇이 더 필요한가'를 적어 보니 목록이 이렇게 나왔습니다.

  • 처리방침 큰 개정: 개인정보 처리방침(손님 정보를 무엇을, 왜, 얼마나 모으는지 공개하는 문서)에 전화번호라는 새 항목과, 번호를 맡겨 처리하는 바깥 업체 2곳을 넣어야 했습니다.
  • 미리 알리는 기간: 크게 고치는 만큼 시행 7일 전 예고 일정을 잡았습니다. 동의문도 새 판으로 바꿔야 했고요.
  • 문자 발송 준비: 문자 대행 업체 가입, 충전, 알림용 채널 연동, 메시지 템플릿(미리 심사받는 고정 문구) 2개 승인, 발송용 인증키 입력까지 전부 제 손일이었습니다.
  • 지우는 약속: 받은 번호를 언제 지울지 정해서 공개하고, 그대로 지켜야 했습니다.
  • 개발 규칙: 번호 원문은 저장소 딱 한 칸에만 두고, 화면·기록·운영 알림 어디에도 남기지 않고, 인증번호는 원문을 아예 저장하지 않는 식의 규칙이 줄줄이 붙었습니다.

여기에 문자를 보낼 때마다 비용이 붙습니다. 손님 입장에서도 번호를 넣고, 인증번호를 기다리고, 입력하고, 또 링크를 기다려야 합니다. 리포트 한 장 드리자고 이걸 다 짊어진다는 게 그제야 보였습니다.

왜 틀어졌나: 남용 막기를 번호로만 생각했습니다

번호를 받으려 한 이유는 단순했습니다. AI 리포트를 무료로 드리면 누군가 끝없이 눌러 비용을 태울 수 있습니다. 그래서 '한 사람에 번호 하나'로 묶으면 막힌다고 봤습니다. 덤으로 나중에 안내할 연락처 명단도 쌓이고요.

틀린 지점은 목적과 수단을 한 덩어리로 본 데 있었습니다. 제가 진짜 원한 건 '같은 사람이 무한정 받아 가지 못하게'였지, '번호를 갖고 싶다'가 아니었습니다. 번호는 여러 수단 가운데 하나였는데, 가장 무거운 걸 제일 먼저 집었습니다.

AI 탓도 아닙니다. "번호 인증 기능 만들어 줘"라고 하면 AI는 정말 잘 만들어 줍니다. 하지만 그 기능이 켜진 뒤 따라오는 법적 절차와 운영 손일까지 먼저 따져 묻지는 않습니다. 그 질문은 시키는 사람이 했어야 했습니다.

이렇게 잡았습니다: 번호 없이, 그 자리에서

계획을 세운 바로 다음 날 밤에 결정을 뒤집었습니다. 번호 없이 웹 리포트를 그 자리에서 보여 드리기로 했습니다. 문자도, 메신저 알림도, 전화번호 칸도 없앴습니다. 이미 만든 인증 코드는 입구를 닫아 숨겨 두었고, 나중에 정리해 지울 계획입니다.

남용은 번호 대신 네 겹으로 막았습니다.

  • 사람 확인: 버튼을 누르면 자동 프로그램이 아닌 사람인지 한 번 확인합니다('로봇이 아닙니다' 같은 장치).
  • 접속당 하루 1번: 같은 접속(같은 인터넷 연결 지점)에서는 새 리포트를 하루 1번만 시작할 수 있습니다.
  • 전체 하루 20번: 아무리 몰려도 하루에 쓸 수 있는 양에 천장이 생깁니다.
  • 결과지 1개에 리포트 1벌: 같은 결과지에서 다시 누르면 새로 만들지 않고 저장해 둔 리포트를 엽니다.

만들면서 잡은 디테일도 있습니다. 하루 횟수는 '새 리포트를 처음 시작할 때'만 셉니다. 중간에 끊겨서 이어 만들거나 다시 만드는 건 세지 않습니다. 손님 잘못도 아닌데 몫이 깎이면 안 되니까요. 날이 바뀐 직후 첫 신청이 동시에 들어와도 잠금을 걸어 한 줄로 세웠습니다. 둘 다 '오늘 첫 번째'로 통과하는 구멍을 막으려는 겁니다. 막힌 손님에게는 "오늘 이 접속에서 새 리포트를 이미 만들었어요, 내일 다시"라고 안내하고, 이미 만든 리포트는 언제든 열리게 했습니다. 제가 시험할 때는 비밀 링크로 연 제 브라우저만 접속당 제한에서 빼고, 전체 20번에는 똑같이 세게 했습니다.

운영 알림도 줄였습니다. 처음엔 알림에 가게 이름과 가게 번호를 넣으려 했는데, 검수 AI가 가게 번호도 공개 정보와 합치면 개인사업자를 알아볼 수 있다고 짚었습니다. 그래서 알림에는 '새 리포트 1건'과 시각만 남겼습니다. 어느 가게인지는 필요할 때 제가 데이터베이스(정보를 모아 두는 저장소)에서 직접 봅니다.

바꾸기 전과 뒤를 한 표로 놓으면 이렇습니다.

항목번호 인증 방식바꾼 방식
손님이 할 일번호 입력, 인증번호 입력, 메시지로 링크 기다리기버튼, 사람 확인, 그 자리에서 리포트
남용 막기번호당 횟수 제한사람 확인, 접속당 하루 1번, 전체 하루 20번
처리방침큰 개정, 7일 예고작은 개정, 새로 받는 손님 정보 없음
제 손일업체 가입, 충전, 채널 연동, 템플릿 승인, 인증키없음
잃은 것없음나중에 안내할 연락처 명단

잃은 것도 숨기지 않겠습니다. 연락처 명단은 쌓이지 않습니다. 알고 고른 손해입니다. 수요가 분명히 보이면 그때 연락처를 받는 창구를 따로 고민하기로 했습니다.

현장 인사이트

손님 정보 한 칸을 받는 순간, 그 칸을 설명하고 지키고 지우는 일까지 같이 받게 됩니다. 안 받는 게 가장 싸고 튼튼한 보안이었습니다.

번호 인증을 만든 시간이 아깝지 않냐고 물으시면, 아깝습니다. 그래도 켜 둔 뒤 매일 드는 손일보다는 훨씬 작았습니다. 이미 들인 수고가 아니라 앞으로 들 손일을 기준으로 판단하는 게 맞았습니다.

오늘 바로 해 볼 것

가게나 회사에서 지금 손님 정보를 받는 곳을 하나 골라 보세요. 예약 폼, 이벤트 응모, 쿠폰 신청, 상담 신청 어디든 괜찮습니다. 그리고 칸 하나하나에 아래를 물어보세요.

  • 미완료: 이 칸이 없으면 일이 아예 안 돌아가나요, 아니면 '있으면 좋은' 칸인가요?
  • 미완료: 이 칸을 받는 진짜 목적은 무엇인가요? (중복 방지, 연락, 마케팅 등)
  • 미완료: 그 목적을 정보를 덜 받고 이룰 방법은 없나요?
  • 미완료: 이 정보는 어디에 저장되고, 누가 볼 수 있고, 언제 지우나요?
  • 미완료: 바깥 업체(문자 발송, 설문 도구 등)에 맡기는 게 있다면 처리방침에 적혀 있나요?
  • 미완료: 직원 단톡방이나 운영 알림에 손님 정보가 그대로 흘러가고 있지 않나요?

이미 받고 있는데 아무도 안 쓰는 칸을 찾는 법은 손님이 채운 입력칸 이야기에 따로 적어 두었습니다.

AI에게 새 기능을 맡기기 전이라면, 만들어 달라고 하기 전에 이 질문부터 붙여 넣어 보세요.

지금부터 [만들려는 기능]을 만들려고 합니다.
코드를 쓰기 전에 아래 내용을 표로 먼저 정리해 주세요.

1. 이 기능이 손님에게서 새로 받는 정보 목록
2. 각 정보를 받는 진짜 목적
3. 그 목적을 정보를 덜 받거나 아예 안 받고 이룰 대안
4. 이 정보를 받으면 따라오는 일
   - 개인정보 처리방침에 더해야 할 내용
   - 바깥 업체에 맡기게 되는지
   - 저장 위치, 볼 수 있는 사람, 지우는 시점
   - 계속 드는 운영 손일과 비용 항목(금액 말고 항목만)
5. 정보를 안 받으면 잃는 것

법적으로 확실하지 않은 부분은 "전문가 확인 필요"라고 따로 표시해 주세요.

이 표를 받아 보면 제 경우처럼 '번호가 꼭 있어야 하는 이유'가 생각보다 약하게 나올 수 있습니다. 법적인 판단은 AI 답을 그대로 믿지 마시고 전문가에게 한 번 더 확인하세요. 제 사례도 기준이 아니라 참고로만 봐 주세요.

손님 정보를 어디까지 받아야 할지, 자동화를 어디서부터 붙일지 같이 따져 보고 싶으시면 편하게 신청해 주세요.

AI 자동화 상담 신청 →

자주 묻는 질문

손님 전화번호를 받으면 꼭 처리방침을 고쳐야 하나요?

새로 받는 정보가 생기면 개인정보 처리방침에 그 내용을 적는 것이 기본입니다. 다만 고치는 범위와 미리 알리는 기간은 상황마다 다를 수 있습니다. 제 사례를 기준으로 삼지 마시고, 실제로 적용하기 전에 전문가나 공공 안내 자료로 꼭 확인하세요.

번호를 안 받으면 같은 사람이 계속 받아 가지 않나요?

완벽히 막지는 못합니다. 저는 사람 확인 한 번, 같은 접속은 하루 1번, 서비스 전체는 하루 20번, 결과지 하나에 리포트 한 벌이라는 네 겹으로 막았습니다. 남용을 없애기보다 감당할 수 있는 크기로 묶어 두는 쪽을 골랐습니다.

이미 만든 기능을 안 쓰면 아깝지 않나요?

아깝습니다. 그래도 켜 두는 순간부터 관리할 일이 계속 생깁니다. 저는 입구를 닫아 숨겨 두고 나중에 정리해 지우기로 했습니다. 이미 들인 수고보다 앞으로 들 손일을 기준으로 판단했습니다.

연락처를 안 받으면 나중에 안내는 어떻게 하나요?

그것이 이 결정에서 잃은 부분입니다. 안내를 보낼 연락처 명단이 쌓이지 않습니다. 알고 고른 손해이고, 수요가 분명히 보이면 그때 연락처를 받는 창구를 따로 고민하기로 했습니다.

관련 글