벤더의 '이것만 합니다'를 실제로 확인하고 있는가

CEO가 "총성만"이라고 했을 때

AI 감시 카메라·마이크 업체 Flock Safety의 CEO, Garrett Langley는 공개 석상에서 단호하게 말했다. "우리 마이크는 총성만 감지합니다." 미국 경찰 수백 곳에 장비를 납품한 회사 대표의 발언이니 무게가 있었다.

그런데 같은 회사 웹사이트를 열면 내용이 다르다. 엔진 소리, 유리 깨지는 소리, 그 외 여러 음향 패턴. ACLU와 프라이버시 단체들이 이 간극을 집중적으로 파고들었고, 지금 Flock은 심각한 신뢰 위기에 놓였다.

이 사태의 핵심은 기술 자체가 아니다. "우리 시스템은 X만 합니다"라는 공개 주장과 시스템이 실제로 하는 일 사이의 간극 — 그게 문제다. 결제·정산 파이프라인을 직접 굴리는 팀이라면, 이 간극이 얼마나 가까운 곳에 있는지 생각해봐야 한다.

단, 이 글에서 말하는 위험은 벤더가 의도적으로 속인다는 게 아니다. 문제는 우리가 실제로 확인하지 않는다는 것이다.

우리도 같은 말을 하고 있지 않나

PG사를 선택할 때, 정산 SaaS를 붙일 때, 우리는 벤더 문서를 읽는다. "결제금액과 주문번호만 처리합니다." "개인정보는 당사 서버에 저장하지 않습니다." 이 말을 믿고 계약하고, 서비스 약관에 비슷한 내용을 적어 사용자에게 고지한다.

문제는 이걸 직접 확인한 팀이 얼마나 될까 하는 점이다.

실제로 웹훅 페이로드를 처음 제대로 뜯어봤을 때 — 계약서엔 언급도 없는 필드들이 딸려오고 있었다. device fingerprint, 브라우저 user-agent, 결제 시도 횟수, 정확한 IP 주소. 벤더가 의도적으로 숨긴 게 아닐 수 있다. 기술적으로 필요해서 포함된 건데 문서화가 덜 된 것일 수도 있고, 원래 있던 게 언젠가 추가된 것일 수도 있다.

그런데 우리가 사용자에게 "우리는 이것만 수집합니다"라고 공개 고지를 한 상태라면 — 그 간극은 벤더 문제가 아니라 우리 문제가 된다. Flock CEO가 자기 회사 웹사이트와 다른 말을 한 것처럼.

범위 확장이 부르는 값

숫자로 보면 얼마나 심각한지 보인다.

PCI DSS SAQ A는 카드 데이터를 직접 다루지 않는 가장 단순한 환경에 적용되는 자가 평가지로, 항목이 14개다. 반면 SAQ D는 329개. 같은 PCI DSS 기준 아래에서도 어떤 데이터가 어디까지 흐르느냐에 따라 감사 부담이 약 23배 차이가 난다.

PG 벤더가 "민감 카드 데이터를 건드리지 않는다"고 했지만, 실제로 트랜잭션 메타데이터가 우리 서버를 경유한다면 — 우리의 PCI 범위(scope)가 조용히 확장된 셈이다. 감사자가 이걸 잡으면 SAQ A에서 SAQ D로 재분류될 수 있다. 비용 문제만이 아니다. 갑자기 329개 항목을 모두 충족해야 하는 상황이 된다.

국내 개인정보보호법 관점에서도 마찬가지다. 개인정보보호위원회는 2023년 이후 위반 과징금 상한을 위반 관련 매출액의 3%로 올렸다. 월 5,000만 원 결제를 처리하는 팀이 연간 6억 매출이면 이론적으로 1,800만 원 과징금이 가능하다. 벤더가 "이것만 수집한다"고 했는데 실제로 더 수집하고, 그걸 사용자에게 제대로 고지하지 못했을 때 — 이 리스크는 벤더가 아닌 우리에게 온다.

AI 개발 속도가 만드는 새 불일치

Flock 사태가 더 불편한 이유가 있다. CEO의 발언이 단순 거짓말이 아닐 수 있다는 점이다.

Flock 마이크가 처음 출시됐을 때는 정말 총성만 감지했을 수 있다. 그런데 AI 모델을 업데이트하면서 기능이 늘어났고, CEO의 발언은 예전 버전을 기준으로 한 것일 가능성이 있다. AI 개발 속도가 CEO의 공식 발언 업데이트 속도를 앞서버린 것.

이게 결제·정산 영역에서도 그대로 벌어지고 있다. PG사들은 요즘 AI 기반 사기 감지 레이어를 경쟁적으로 붙이고 있다. "AI로 이상 거래를 차단한다"는 마케팅은 화려한데, 그 AI가 정확히 어떤 데이터를 입력으로 쓰는지는 대부분 불투명하다. 반기마다 모델이 업데이트되면서 처리 범위가 조용히 달라지는데, 그 변화가 우리 API 계약서나 개인정보처리방침에는 반영이 안 된다.

영업 담당자가 2년 전에 설명한 "이것만 합니다"는 지금 사실이 아닐 가능성이 꽤 높다. 시스템은 계속 진화하는데 공식 문서는 멈춰 있다. AI 개발 속도가 문서화 속도를 이미 한참 앞서갔다.

우리 팀이라면 어떻게 할까

작은 팀이라 감사 인력도 없고 벤더와 1:1 협상력도 약하다는 건 안다. 그렇다고 눈 감고 있으면 Flock CEO 처지가 된다 — 내가 모른다고 사용자에게 한 말이 거짓이 되는 상황.

현실적으로 접근하면 이렇다.

정산 자동화 스크립트가 DB에 실제로 뭘 쓰는지, 컬럼 단위로 한 번 훑어보는 것부터 시작할 수 있다. 처음에 "금액이랑 거래번호만"이라고 설계했는데, 어느 시점에 "편의상" 이메일이나 전화번호가 들어간 경우가 생각보다 많다. 코드베이스가 커지면서 슬금슬금 범위가 넓어진 건데, 그 시점에 개인정보처리방침 업데이트를 했을 가능성은 낮다.

웹훅 감사는 더 직접적이다. 결제 완료 후 벤더에서 날아오는 웹훅을 실제로 로깅해서 어떤 필드가 있는지 목록을 만들어라. 계약서에 없는 필드가 보이면 벤더에 서면으로 용도를 물어보면 된다. 그 답변이 기록으로 남는다. 나중에 책임 소재가 불분명해질 때 그 기록이 우리를 지킨다.

지금 바로 할 수 있는 것

추상적인 감사 체계를 새로 만들 여유가 없다면, 이번 주 안에 세 가지만 해봐라.

첫째, 현재 연동된 PG사나 정산 SaaS의 웹훅 응답을 실제로 출력해서 계약서·개인정보처리방침에 명시된 항목과 비교해라. 다른 필드가 보이면 그게 감사 시작점이다.

둘째, 현재 개인정보처리방침의 "제3자 처리위탁" 항목을 벤더가 실제로 받는 데이터와 대조해라. 불일치가 있으면 둘 중 하나를 바꿔야 한다. 방침을 현실에 맞추거나, 현실을 방침에 맞추거나.

셋째, PG사에 공식으로 두 가지만 서면 문의해라. "AI 사기 감지가 어떤 입력 데이터를 씁니까?" 그리고 "그 데이터가 당사 서버 외부로 전송됩니까?" 답이 모호하거나 느리게 오면, 그 자체가 신호다. 계약 재검토의 근거가 된다.

Flock CEO는 자기 회사 웹사이트를 확인하지 않고 "총성만"이라고 말했다. 우리도 벤더 계약서를 마지막으로 연 게 언제인지 기억 안 나는 경우가 많다. "우리는 이것만 수집합니다"라고 사용자에게 말하는 그 문장이 실제로 사실인지 — 확인하고 말하는 팀이 되는 게 목표다.

원문: AI News & Artificial Intelligence | TechCrunch