결제에 관여하는 자체 도구를 직접 개발하는 경우, 규정 준수 리스크는 누구의 책임일까요?

바로 귀사입니다. 코드를 생성한 AI도, 호스팅 제공업체도, 결제 서비스 제공업체도 아닙니다. 직접 개발한 도구가 결제를 다루는 순간 규정 준수 리스크는 귀사의 비즈니스에 귀속되며, 규정을 준수하는 외부 업체를 아무리 많이 연결하더라도 그 책임은 그대로 유지됩니다. 귀사가 바꿀 수 있는 것은 그 리스크의 크기이며, 잘 설계된 커스텀 도구와 부주의하게 만들어진 도구 사이의 격차는 엄청납니다.

리스크가 협력업체가 아닌 귀사에게 돌아가는 이유는 무엇일까요?

카드 결제 수락은 계약의 사슬로 운영됩니다. 카드 브랜드사(네트워크)가 규칙을 정하고, 매입사(귀사를 대신해 카드 매출을 정산하는 은행)가 이를 집행하며, 가맹점 계약을 통해 귀사에게 그 규칙이 전달됩니다. 이 규칙서가 바로 카드 업계의 데이터 보안 표준인 PCI DSS이며, 카드회원 데이터(카드 번호 및 이와 함께 전송되는 세부 정보)를 저장, 처리 또는 전송하는 모든 비즈니스에 적용됩니다. 현재 버전은 4.0.1입니다. (버전 번호 및 프로그램 세부 정보는 발행 시점 기준이며, 구체적인 내용은 스냅샷으로 참고하시기 바랍니다.)

협력업체는 자체 시스템에 대한 의무를 지며, 규정을 준수하는 결제 서비스 제공업체를 이용하면 귀사가 해야 할 작업의 양이 극적으로 줄어듭니다. 하지만 협력업체의 어떠한 조치도 책임 자체를 이전하지는 않습니다. PCI 보안표준위원회(PCI Security Standards Council)는 규정 준수 여부를 검증해야 하는지 여부는 결제 브랜드사와 매입사가 결정한다고 명시하고 있으며, 가맹점 계약서에 명시된 그들의 답변은 '예'입니다. 매년 귀사의 담당자는 귀사의 환경이 표준을 충족한다는 증명서(AoC)에 서명합니다. 그 서명은 협력업체가 아닌 귀사의 서명입니다.

자체 코드가 카드 데이터를 다루는 순간 무엇이 달라질까요?

범위(Scope)입니다. 규정 준수를 위한 노력은 범위에 따라 결정됩니다. 카드회원 데이터를 다루는 모든 시스템과 여기에 연결된 모든 것이 표준의 적용 범위에 포함됩니다.

규정을 준수하는 제공업체와 인증된 단말기를 통해 결제를 완전히 처리하는 가맹점은 수십 개의 문항으로 구성된 간단한 자체 평가 설문서(SAQ, 연간 체크리스트)로 검증을 완료합니다. 반면, 자체 소프트웨어로 카드 번호를 처리하는 가맹점은 가장 까다로운 단계에 해당하여 전체 표준의 대부분을 반영하는 분량을 감당해야 합니다. 여기에는 분기별 취약점 점검, 모의 침투 테스트, 접근 제어, 로깅 및 공식 보안 정책을 포함하는 200개 이상의 요구사항이 포함됩니다¹.

AI가 반나절 만에 작성해 준 결제 양식 말인가요? 만약 그것이 카드 번호를 수집한다면, 귀사의 웹 서버, 데이터베이스, 관리자용 노트북, 매장 Wi-Fi까지 모두 심사 범위에 포함될 수 있습니다. 그리고 어쨌든 간단한 설문서로 몰래 제출하고 넘어갈 수도 없습니다. 자격이 되지 않는 단계를 선택한다고 해서 리스크가 줄어드는 것은 아닙니다. 이는 귀사가 서명한 문서가 잘못되었음을 의미하며, 대개 보안 사고가 발생한 직후라는 최악의 타이밍에 드러나게 마련입니다.

잘못 대처했을 때 실제로 발생하는 비용은 얼마일까요?

규정 집행은 계약을 기반으로 하므로, 대개 결제 처리 명세서에 비용으로 청구됩니다. 많은 결제 대행사(processor)가 규정 준수를 검증할 때까지 매달 미준수 수수료(non-compliance fee)를 반복해서 부과합니다. 보안 사고가 발생한 후에는 비용이 걷잡을 수 없이 불어납니다. 귀사가 비용을 지불해야 하는 의무 포렌식 조사, 카드 재발급 비용, 매입사를 통해 전달되는 점증적인 벌금 등이 있으며, 이는 보통 월 5,000달러에서 100,000달러 범위로 알려져 있습니다(PCI 준수 평가 기관이 발표한 벌금 기준표 기준). 심각한 경우 비즈니스에서 카드 결제 수락 권한을 완전히 박탈당할 수도 있습니다.

소규모 가맹점의 경우, 가장 큰 비용은 벌금보다 더 조용히 찾아옵니다. 실제 보안 프로그램을 운영하는 데 비즈니스 운영에 쏟아야 할 소중한 시간을 빼앗기게 되기 때문입니다.

카드 데이터 심사 범위를 떠안지 않고 커스텀 도구를 개발하려면 어떻게 해야 할까요?

코드가 카드가 지나가는 경로(card path)에 관여하지 않도록 하세요. 커스텀 도구는 장바구니 구성, 할인 적용, 주문 합계 계산, 청구 금액 전송 등 판매 과정을 조율하는 역할만 해야 합니다. 카드 자체는 인증된 단말기(카드 처리가 검증된 결제 하드웨어) 또는 제공업체의 호스팅 결제 페이지하고만 접촉해야 하며, 이 두 가지 방식 모두 카드를 결제 대행사(자금을 이동시키는 회사)로 직접 전달합니다. 귀사의 도구는 승인 또는 거절 결과와 함께 토큰(도난당하더라도 아무런 쓸모가 없는 참조 번호)만 돌려받게 됩니다.

이러한 분리가 바로 헤드리스 POS 아키텍처를 지지하는 핵심 논거입니다. 상단에는 커스텀 화면을 두고, 하단에는 인증된 결제 인프라를 배치하는 것이죠. 또한 AI가 생성한 결제 기능이 데모에서는 훌륭해 보이지만 실제 운영 환경에서 막히는 이유이자, Interac과 같은 대면 데빗 카드 결제에서 웹 양식이 잘못된 답인 이유이기도 합니다. 대면 결제는 기술적으로나 계약상으로나 인증된 하드웨어에서 이루어져야 합니다.

Final은 정확히 이 경계를 중심으로 설계되었습니다. 직접 프롬프트를 작성하든 MCP를 통해 자체 AI를 연결하든 간에, 귀사가 구축하는 플로우는 화면, 장바구니, 카탈로그를 제어합니다. 카드 데이터는 인증된 단말기 하드웨어에서 Final Pay를 통해 결제 대행사로 전송되며, 귀사가 구축한 플로우에는 절대 유입되지 않습니다. 안전한 영역은 커스텀으로 자유롭게 구성하고, 책임이 따르는 영역은 표준화된 방식을 따릅니다.

그렇다면 규정 준수 리스크는 누구의 책임일까요?

귀사이며, 앞으로도 항상 그럴 것입니다. 진짜 결정해야 할 것은 얼마나 많은 범위를 감당할 것인가이며, 이는 서류 작업의 선택이 아닌 아키텍처의 선택입니다. 결제를 다루는 도구를 배포하기 전에 한 가지만 자문해 보세요. '내 코드가 카드 번호를 볼 수 있는가?' 만약 그렇다면 규정 준수 프로그램은 귀사가 직접 운영해야 합니다. 그렇지 않다면 부담을 획기적으로 줄이면서도 커스텀 빌드의 유연성을 유지할 수 있습니다. 현재 이러한 빌드를 고민 중이시라면, 기성품 POS의 한계를 느끼고 있다는 신호 글부터 읽어보시기 바랍니다.