개인정보 동의를 붙였더니, 화면 세 개와 계정 116건이 따라 움직였습니다

프랜차이즈 ERP 에서 가맹점의 배달 매출·리뷰·정산을 모으려면 그 배달 플랫폼의 점주 계정으로 로그인해야 합니다. 처음에는 본사가 점주에게 계정 정보를 받아 직접 등록하고 수집 워커를 돌렸습니다. 데이터를 빠르게 채우기에는 이 방식이 가장 편합니다.

그러다 점주 개인정보 동의를 받는 구조를 만들었습니다. 계정 등록 API 는 동의 기록이 없으면 428 로 막히도록 했습니다. 흔히 말하는 '동의 붙였다'는 보통 여기까지입니다. 다음 날 화면을 열어보고 나서 이게 절반도 안 된다는 것을 확인했습니다.

동의 절차는 있는데 아무도 동의할 필요가 없었습니다

점주 웹의 매출·리뷰·정산 세 화면이 본사가 관리하는 매장과 플랫폼의 매핑 테이블을 기준으로 열려 있었습니다. 점주가 자기 계정을 등록하지 않아도 본사가 수집한 데이터가 그대로 보이는 구조였습니다.

실측해보니 등록 계정이 0건인 한 점주에게 배달 플랫폼 4곳의 매출 4,742만원이 표시되고 있었습니다. 동의를 하면 얻는 것이 이미 그 자리에 다 있었습니다. 동의율이 오르지 않는 이유를 문구에서 찾을 일이 아니었습니다.

같은 시점의 실태는 이랬습니다.

개점 매장 219곳 중 배달앱 미연동이 185곳으로 84%입니다

크롤이 돌고 있는 수집 계정 99개 중 소유주가 연결된 것은 2개입니다

그중 개인정보 동의 기록이 있는 점주는 1명입니다

공개 기준을 매핑에서 내 계정 등록으로 바꿨습니다

세 화면의 판정을 계정 서비스의 등록 계정 보유 여부 하나로 통일했습니다. 화면마다 따로 판정하면 계정 목록은 비어 있는데 매출은 보이는 어긋남이 생깁니다. 계정 목록 조회를 그대로 재사용해 규칙이 갈리지 않게 했습니다.

미등록 점주에게는 매출 화면에서 배달앱 카드가 미연동으로 표시되고 POS 매출은 계속 보입니다. 리뷰와 정산은 빈 목록입니다. 대신 그 자리를 비워두지 않고 유도 블록을 세웠습니다.

문구는 '연동 안 됨'이 아니라 '배달앱 매출도 함께 보세요'로 잡았습니다. 앞은 결핍 통보이고 뒤는 얻는 것입니다. 버튼을 누르면 계정 등록 화면으로 가고 동의서부터 뜹니다. 이 블록이 동의를 받는 실제 입구입니다.

화면에서 감추는 것과 서버에서 막는 것은 다릅니다

세 화면의 응답을 서버에서 같이 막았습니다. 클라이언트에서 숨기고 API 는 그대로 내주면 그것은 정책이 아니라 배려입니다. 엔드포인트를 직접 부르면 본사 수집분이 그대로 나갑니다.

정산은 특히 그렇습니다. 화면에 안 그리는 것과 응답에 담지 않는 것 사이에 입금액이 놓여 있습니다. 미등록이면 의미가 없는 컨트롤인 리뷰 플랫폼 필터와 정산 기간 선택도 같이 감췄습니다.

본사가 켜고 끌 수 있으면 동의의 의미가 남지 않습니다

처음에는 관리자 웹의 계정관리 팝업에 계정 활성 토글과 비밀번호 변경 UI 를 그대로 뒀습니다. 기술적으로는 자연스러운 기능입니다. 작업 도중에 방향을 뒤집었습니다.

점주가 자기 아이디로 동의하고 등록한 계정을 본사가 켜고 끄고 비밀번호까지 바꾼다면, 앞에서 받은 동의가 무엇을 보장하는지 설명하기 어렵습니다. 본사가 봐야 하는 것은 잘 돌고 있는가 하나입니다.

두 UI 를 프론트에서 제거하고 백엔드 API 는 남겼습니다. 운영 복구 경로는 두되 일상 조작은 못 하게 하는 선택입니다

대신 점주 단위 팝업을 만들었습니다. 왼쪽에 매장별 등록 계정, 오른쪽에 개인정보 동의 이력 전체를 붙였습니다

목록 필터를 문제 계정, 소유주 미연결, 동의 기록 없음 세 축으로 바꿨습니다

소유주 미연결 표시를 회색에서 빨강으로 올렸습니다. 보조 정보가 아니라 채워야 할 일감입니다

이미 모아둔 것을 어떻게 할지가 진짜 시험대입니다

앞으로 동의 없이 모으지 않겠다는 결정은 쌉니다. 이미 들고 있는 것을 지우는 결정이 비쌉니다. 후자를 하지 않으면 앞의 결정은 선언에 그칩니다.

배달 7개 플랫폼의 수집 계정 중 동의한 점주의 것을 뺀 116건을 삭제했습니다. 삭제 전에 전체 125행을 백업 테이블로 떠두고 FK 참조가 없는 것을 확인한 뒤 실행했습니다. 남은 9건은 동의한 점주 1명의 배달 계정 4건과 상용 POS·외부 회계 SaaS·외부 공급사 시스템 계정 5건입니다.

삭제의 영향은 좁았고, 그건 조건이 맞아떨어진 결과입니다

지우는 것이 항상 옳지는 않습니다. 잔존 데이터가 핵심 지표를 떠받치고 있었다면 116건 삭제를 이렇게 가볍게 결정하지 못합니다. 삭제 전에 세어야 하는 것은 건수가 아니라 그 데이터에 무엇이 매달려 있는가입니다.

알고 남긴 구멍과 따라온 청구서

계정은 점주에게 걸리고 매장에는 걸리지 않습니다. 한 점주가 매장을 여러 곳 운영하면 한 곳만 등록해도 전 매장이 열립니다. 매장별로 막으려면 계정과 매장을 잇는 연결이 필요한데 스키마에 없습니다. 지금 목적이 동의 확보라서 승인을 받고 이대로 뒀습니다.

모르고 남긴 것과 알고 남긴 것은 다릅니다. 알고 남긴 것은 문서에 적어야 다음 사람이 버그로 오해하지 않습니다.

하루 작업의 청구서는 이렇게 왔습니다.

116건은 대부분 소유주 컬럼이 비어 있어 누구 것인지 모르는 채로 지웠습니다. 되돌리려면 그 사람들에게 다시 받아야 합니다

소유주 연결이 있는 1명 기준으로만 남겼으니, 동의했는데 연결이 없어 지워진 계정이 있을 수 있습니다

계정이 0개가 된 플랫폼에서 크롤 배치가 에러를 내는지 대상 0으로 조용히 넘어가는지 확인된 적이 없습니다

다음 날 아침 점검 기준이 같이 무너졌습니다. 배치 디스패치 건수와 한 플랫폼의 정산 첫 실행은 둘 다 계정이 있어야 성립하는 기준이었습니다

백업 테이블을 언제 지울지 정해야 합니다. 삭제의 안전망이 정책의 예외가 되는 자리입니다

정책 전환은 한 화면에서 끝나지 않습니다

이 하루를 정리하면 순서가 분명합니다. 공개 기준이 바뀌자 조작 권한의 정당성이 무너졌고, 조작 권한을 걷어내자 잔존 데이터를 들고 있을 근거가 사라졌고, 데이터가 사라지자 배치 전제와 다음 날 점검 기준이 같이 흔들렸습니다.

착수 전에 세어야 하는 것은 작업량이 아니라 무엇을 근거로 삼고 있던 것들이 같이 무너지는가입니다.

동의는 화면이 아니라 인센티브 구조입니다. 동의율이 낮을 때 문구를 고치기 전에 동의 없이도 열려 있는 문을 먼저 찾는 편이 빠릅니다

권한은 할 수 있는가가 아니라 해도 되는가로 다시 물어야 합니다. 기능이 그대로여도 전제가 바뀌면 정당성이 사라집니다

이번 판단은 동의를 받는 구조를 이미 만들었다는 전제에서 나옵니다. 계약으로 대리 등록 권한을 명확히 받았다면 대리 방식 자체가 문제는 아닙니다. 어긋나는 것은 두 방식을 동시에 두는 쪽입니다

전환 전에 확인할 것

동의 없이도 결과물이 보이는 화면이나 API 가 남아 있는지 확인합니다

화면에서 감춘 범위와 서버에서 막은 범위가 같은지 확인합니다

관리자가 가진 조작 기능 중 전환 뒤에도 정당성이 남는 것을 골라냅니다

이미 모아둔 데이터에 무엇이 매달려 있는지 세고 지울 범위를 정합니다

데이터가 사라졌을 때 같이 무너지는 배치·지표·점검 기준을 미리 적어둡니다

마무리

동의를 받기로 한 결정의 실제 비용은 동의서 화면이 아니라 그 뒤에 붙어 있던 것들에서 나왔습니다. 동의 없이도 열려 있는 문, 동의를 무력화하는 조작 권한, 동의 없이 모아둔 잔존 데이터입니다. 세 곳이 같이 움직이지 않으면 정책은 성립하지 않습니다.

이 정책의 진짜 병목은 코드가 아니었습니다. 크롤이 돌던 계정 99개 중 소유주 연결이 2개였다는 숫자와 미연동 매장이 84%라는 숫자는 같은 이야기를 합니다. 남은 일은 점주 웹 온보딩입니다.