우리는 왜 사업자등록번호를 저장하지 않기로 했을까
며칠 전에 회사 홈페이지에 자가진단 페이지를 하나 열었습니다. 공장의 AI 도입 성숙도를 문항으로 채점해 결과를 메일로 보내 주는 페이지입니다.


며칠 전에 회사 홈페이지에 자가진단 페이지를 하나 열었습니다. 공장의 AI 도입 성숙도를 문항으로 채점해 결과를 메일로 보내 주는 페이지입니다.
만들면서 가장 오래 붙잡고 있었던 것은 문항도 채점 방식도 아니었습니다. 어떤 정보를 받을 것인가였습니다. 결론부터 적으면, 저희는 사업자등록번호를 받아서 검증하되 저장하지 않기로 했습니다. 전화번호는 아예 받지 않습니다.
리드를 모으는 폼에서 정보를 덜 가지겠다는 결정이라 안쪽에서도 이견이 있었습니다. 그 판단이 어떻게 나왔는지 적어 둡니다.

받을수록 쌓이는 것은 정보만이 아니라 그것을 지킬 책임이다.
처음 설계는 번호를 저장하는 쪽이었습니다
초안은 흔한 모양이었습니다. 회사명·담당자 이메일·사업자등록번호를 받고, 국세청 사업자 상태 조회로 실재하는 사업자인지 확인한 뒤, 그 번호를 리드 정보에 함께 저장합니다.
저장하려던 이유도 분명했습니다. 같은 회사가 다시 진단하면 이전 결과와 이어 볼 수 있고, 나중에 계약으로 이어졌을 때 고객 정보와 맞춰 볼 수 있습니다. 무엇보다 기업 식별자로 사업자등록번호만큼 깔끔한 값이 없습니다. 회사명은 표기가 흔들리고 이메일은 담당자가 바뀝니다.
그래서 이 설계를 사내 법무 검토에 먼저 걸었습니다. 개인정보 보호법·정보통신망법 조문을 실제로 조회해 쟁점별로 등급을 매기는 절차입니다. 사업자등록번호 항목은 [상] 등급으로 돌아왔습니다.
등급이 [상]으로 나온 지점은 번호 자체가 아니었습니다
핵심은 결합이었습니다. 사업자등록번호 하나만 놓고 보면 법인 식별자에 가깝습니다. 그런데 그 번호를 담당자 이메일·이름·직함과 한 줄에 묶어 보관하는 순간 성격이 달라집니다. 개인을 알아볼 수 있는 정보와 결합하면 그 묶음 전체가 보호 대상 쪽으로 기울고, 보관하는 동안 안전조치 의무·보유기간 관리·파기 책임이 따라붙습니다.
여기에 개인사업자 문제가 겹칩니다. 개인사업자의 사업자등록번호는 사업체 식별자이면서 동시에 그 사람에게 붙은 번호입니다. 중소 제조 고객에는 개인사업자가 적지 않습니다.
이 시점에 질문이 하나로 좁혀졌습니다. 번호를 보관해서 실제로 얻는 것이 무엇인가.
실재 사업자인지 확인하는 것 — 이건 조회하는 순간에 끝납니다. 결과만 알면 됩니다.
재진단 이력을 잇는 것 — 이메일로도 됩니다. 정확도는 조금 떨어집니다.
나중에 고객 정보와 맞추는 것 — 계약 단계에서 어차피 정식으로 다시 받습니다.
셋 다 번호를 계속 갖고 있어야만 되는 일이 아니었습니다. 보관의 편익은 "조금 더 정확하다" 수준인데, 보관의 부담은 안전조치·기간관리·파기까지 상시로 따라옵니다. 부담이 편익보다 크면 안 갖는 것이 설계입니다.

번호는 검사 구간을 지나며 사라지고, 벨트에는 판정 표식만 남아 보관함으로 간다.
그래서 검증은 하되 결과만 남기기로 했습니다
바꾼 구조는 단순합니다.
사용자가 사업자등록번호를 입력합니다.
서버가 그 번호로 국세청 상태 조회를 호출합니다.
응답이 오면 판정 결과만 남기고 번호는 버립니다.
데이터베이스에 남는 값은 이렇습니다.
저장하는 값 | 예시 | 성격 |
|---|---|---|
검증 성공 여부 | 참 / 거짓 | 참·거짓 한 칸 |
사업자 상태 | 계속사업자 / 휴업 / 폐업 / 미검증 | 상태 코드 |
검증 시각 | 2026-08-22 09:41 | 시각 |
사업자등록번호 자체 | — | 컬럼이 없습니다 |
리드 테이블에 번호를 담을 칸을 아예 만들지 않았습니다. 칸이 없으면 실수로 채워질 일도 없습니다. "저장하지 않겠다"는 약속을 운영 규칙이 아니라 구조로 만든 것이 이 결정에서 가장 중요한 부분입니다.
로그도 같이 정리했습니다. 처음에는 장애를 추적하려고 번호 앞 몇 자리를 로그에 남겨 두었는데, 부분값도 전부 지웠습니다. 앞자리와 회사명이 같은 줄에 있으면 되짚어 맞출 수 있습니다. 어중간하게 가리는 것은 안 가리는 것과 크게 다르지 않습니다.
바꾸면서 하나 포기한 것도 있습니다. 국세청 조회가 느리거나 실패할 때 번호가 남아 있으면 나중에 다시 조회해 볼 수 있는데, 이제는 그게 안 됩니다. 그래서 조회가 실패하면 진단을 막지 않고 미검증 상태로 통과시키기로 했습니다. 외부 API 사정 때문에 사용자가 진단을 못 받는 쪽이 더 나쁘다는 판단입니다. 검증은 리드 품질을 보는 참고값이지 자격 심사가 아닙니다.
전화번호는 처음부터 받지 않습니다
폼에서 받는 항목은 5개입니다. 회사명, 담당자 이메일, 사업자등록번호, 담당자명·직함(선택), 웹사이트(선택). 전화번호 칸은 없습니다.
영업 쪽에서 보면 이상한 결정입니다. 전화가 메일보다 빠릅니다. 그런데 자가진단은 결과를 메일로 보내는 서비스입니다. 메일 주소는 서비스를 제공하려면 반드시 필요하고, 전화번호는 우리가 연락하기 편하려고 받는 값입니다.
받는 순간 두 가지가 따라옵니다. 완주율이 떨어지고, 보관 책임이 늘어납니다. 진단 한 번 받아보려던 사람에게 전화번호를 요구하면 "이거 영업 전화 오겠구나"라는 신호가 됩니다. 실제로 그 신호가 맞기 때문에 더 그렇습니다.
전화가 필요한 단계는 상담을 신청한 다음입니다. 그때는 상대가 통화를 원해서 주는 번호라 성격이 다릅니다.
같은 기준을 다른 항목에도 그대로 적용했습니다.
항목 | 받는가 | 판단 근거 |
|---|---|---|
담당자 이메일 | 받는다(필수) | 결과를 보내야 하므로 서비스 제공에 필수 |
회사명 | 받는다(필수) | 결과 문서에 들어가고, 같은 회사 중복을 거른다 |
사업자등록번호 | 받되 저장 안 함 | 확인은 조회 순간에 끝난다 |
담당자명·직함 | 선택 | 없어도 결과가 나온다 |
전화번호 | 받지 않음 | 우리가 편하려고 받는 값 |
매출·인원 등 회사 규모 | 받지 않음 | 문항 안에서 필요한 만큼만 묻는다 |
매출·인원을 별도 항목으로 받지 않은 것도 같은 이유입니다. 진단에 필요한 규모 정보는 문항 안에서 구간으로 묻습니다. 구간이면 채점에 충분하고, 정확한 숫자는 보관할 이유가 없습니다.
동의를 한 덩어리로 받지 않고 넷으로 쪼갰습니다
가장 자주 보는 형태가 "아래 내용에 모두 동의합니다" 체크 한 칸입니다. 목적이 여러 개인데 동의는 하나면, 서비스를 받으려는 사람은 광고 수신까지 함께 누르게 됩니다. 형식은 동의지만 실질은 선택이 아닙니다.
넷으로 나눴습니다.
구분 | 무엇에 대한 동의인가 | 필수 여부 | 보유 기간 |
|---|---|---|---|
진단 서비스 제공 | 결과 산출과 리포트 발송 | 필수 | 6개월 |
처리 위탁 | 메일 발송·사업자 상태 조회 등 처리 | 필수 | 위탁 목적 종료 시 |
재진단 이력 | 다음 진단과 이어 보기 | 선택 | 최장 1년 |
마케팅 정보 수신 | 새 소식·자료 발송 | 선택 | 2년 |
앞의 두 개는 이게 없으면 서비스 자체가 성립하지 않아 필수입니다. 뒤의 두 개는 동의하지 않아도 진단은 그대로 받습니다. 선택을 선택으로 두려면 동의를 쪼개는 수밖에 없습니다.
보유 기간을 6개월로 잡은 것도 같은 결입니다. 처음 검토안은 1년이었는데, 진단 결과라는 것이 공장 상황이 바뀌면 그만큼 빨리 낡습니다. 1년 지난 진단 데이터로 할 수 있는 일이 많지 않은데 보관 책임만 두 배로 집니다.
동의 문구에는 버전 키를 붙여 두었습니다. 나중에 문구를 고치면 "이 사람이 언제 어떤 문구에 동의했는지"가 기록에 남습니다. 동의를 받았다는 사실보다 무엇에 동의했는지가 남아야 기록입니다.
한 가지 더 정리한 것은 나중에 보내는 메일입니다. 진단 결과를 받은 분께 몇 달 뒤 다시 연락하는 흐름을 처음에는 당연하게 넣어 두었는데, 검토 과정에서 걷어냈습니다. 무상으로 제공한 진단이 "거래 관계"에 해당하는지가 갈리는 문제라, 그 해석에 기대는 설계는 아예 채택하지 않기로 했습니다. 마케팅 수신에 동의한 분에게만 보냅니다. 판단이 갈리는 곳에서는 좁은 쪽을 고르는 편이 나중에 뒤집힐 일이 없습니다.

동의는 하나로 묶지 않고 넷으로 나눴다. 둘은 필수, 둘은 선택이며 각각 보유 기간이 다르다.
여기서 배운 것
법무 검토 결론은 "필수 조치를 반영하면 출시할 수 있다"였습니다. 저희가 그 조치를 반영하고 출시한 것이지, 이 설계가 모든 상황에서 안전하다는 뜻은 아닙니다. 서비스마다 받는 항목도 쓰는 방식도 달라서, 남의 결론을 그대로 가져다 쓸 수 있는 영역이 아닙니다. 저희도 30일 뒤에 실제 운영 데이터를 놓고 다시 점검하기로 해 두었습니다.
다만 판단할 때 사용한 질문 4개는 어디에나 옮겨집니다. 새 폼을 만들 때 항목마다 이렇게 물어봅니다.
이 항목이 없으면 서비스가 성립하지 않는가? 아니라면 필수가 아닙니다.
쓰는 순간에만 필요한가, 계속 갖고 있어야 하는가? 검증·조회는 대부분 앞쪽입니다. 결과만 남기면 됩니다.
다른 항목과 묶였을 때도 같은 성격인가? 단독으로는 무해한 값이 결합하면 달라집니다.
안 갖고 있어서 곤란해지는 상황이 실제로 얼마나 자주 오는가? "혹시 필요할까 봐"는 대개 오지 않습니다.
4번째가 제일 자주 걸립니다. 데이터는 일단 받아 두면 나중에 필요할 것 같습니다. 그런데 실제로 쓰는 날은 잘 오지 않고, 보관하는 날은 매일 옵니다. 쌓아 둔 데이터는 자산이면서 동시에 부채이고, 언제 자산이 되는지는 불확실한 반면 부채인 기간은 확실합니다.
B2B에서 첫 접점은 신뢰를 만드는 자리이기도 하지만 깎는 자리이기도 합니다. 진단 한 번 받으려는데 전화번호부터 요구하는 폼과, 사업자 확인은 하되 번호는 안 남긴다고 적어 둔 폼은 다르게 읽힙니다. 덜 요구하는 쪽이 결국 더 받습니다.
이 글이 도움이 되셨다면 공유해 주세요
새 글이 올라오면 메일로 알려드립니다
제조 현장에서 확인한 것들을 기록합니다. 광고성 발송은 하지 않습니다.
제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.

제조 AI 운영체제 VEXPLOR를 만들고 있습니다. 스마트공장 구축 현장에서 데이터 표준화·온톨로지·디지털트윈·자율형공장을 다루며, 이 블로그에는 현장에서 실제로 부딪힌 문제와 그때 내린 판단을 씁니다.
contact@wace.me이 문제를 실제 현장에서 풀고 있습니다
(주)웨이스는 제조 AI 운영체제 VEXPLOR로 데이터 표준화부터 자율형공장까지 만들어가고 있습니다. 우리 공장에 적용하면 어떤 모습일지 궁금하시면 편하게 물어보세요.
함께 읽어보세요
재고가 있는데 왜 발주가 나갔을까 — 숫자가 어긋나는 자리 4곳
현장에서 제일 자주 듣는 말 중 하나가 "우리 재고 숫자는 못 믿는다"입니다. 그러면 대개 원인을 사람에게서 찾습니다. 입고 등록을 늦게 했다거나, 출고를 안 찍었다거나, 재고 실사를 제때 안 했다는 쪽입니다.

제조 AI 회사들은 왜 매출 100억에서 멈출까
제조 AI, 스마트팩토리, 산업용 소프트웨어를 만드는 회사들의 실적을 몇 년치 나란히 놓고 보면 이상한 규칙이 하나 보입니다. 매출이 100억 언저리에 닿을 무렵 상장을 하고, 그 뒤로 매출이 잘 늘지 않습니다.

사내 업무 도구를 직접 만들면서, 무엇을 만들지 않기로 했나
저희는 제조 현장의 AI를 만드는 회사인데, 정작 사내 업무는 오랫동안 폴더와 문서로 돌아갔습니다. 제안서, 사업계획서, 회의록, 회사 수치가 전부 파일이고, 그 파일들을 AI 도구로 만들고 고칩니다. 팀 규모가 크지 않아 시스템을 도입하기도 애매했습니다.
