앱 개발자를 위한 PCI 준수: 짧고도 아픈 가이드

PCI 준수(카드 데이터를 다루는 모든 대상을 위한 결제 카드 산업 규제 보안 규칙)는 "신용카드 결제 지원"이라는 단어를 쓰기 위해 지불해야 하는 대가입니다. 간단히 말해, 카드 데이터가 작성한 코드나 운영하는 서버에 단 한 번이라도 접촉하면 수백 가지 통제 항목이 포함된 보안 표준, 연례 증명(표준 준수를 증명하는 서명된 공식 선언서), 결제대행사를 통해 전달되는 불이익을 받아들여야 합니다. 앱 개발자에게 결제 규제가 까다로운 이유는, 대부분 체크아웃 기능을 이미 다 구축한 후에야 이 사실을 깨닫기 때문입니다.

구체적인 내용을 다루기 전 한 가지 알려드립니다. 아래에 기술된 버전 번호, 날짜, 설문지 규칙은 게시일 기준 최신 내용입니다. 규정은 변경될 수 있으므로 세부 사항은 특정 시점의 정보로 참고해 주세요.

PCI 준수란 정확히 무엇인가요?

PCI DSS(결제 카드 산업 데이터 보안 표준)는 법률이 아니라 계약상의 의무 사항입니다. 카드 네트워크 회사는 은행과 결제 대행사에 이를 부과하며, 이들은 다시 가맹점과 가맹점이 운영하는 소프트웨어에 부과합니다. 현재 버전은 4.0.1이며, 새로운 요건의 마지막 적용 단계가 2025년 3월 31일부로 의무화되었습니다¹. 이 표준은 네트워크 보안 및 암호화부터 액세스 제어 및 로깅에 이르기까지 12가지 요구 사항 범주를 포함하며, 이는 수백 개의 개별 통제 항목으로 구체화됩니다².

규제 기관이 직접 찾아오는 것은 아닙니다. 대신 상업적 불이익이 발생합니다. 매입 은행(가맹점의 카드 결제를 정산하는 은행)을 통한 과태료 부과, 수수료율 인상, 최악의 경우 카드 결제 자격 상실까지 이어집니다. 데이터 유출 사고가 발생할 경우 디지털 포렌식 조사 및 카드 재발급 비용도 모두 부담해야 합니다.

왜 "결제 기능 추가"만으로 앱 전체가 적용 대상이 될까요?

적용 범위(Scope) 규정이 전부라 해도 과언이 아닙니다. PCI DSS는 카드보유자 데이터를 저장, 처리, 전송하는 모든 시스템과 그 시스템에 연결된 모든 환경에 적용됩니다. 규제 검증은 사다리처럼 단계별로 구성되며, 각 단계가 올라갈수록 부담이 기하급수적으로 늘어납니다²:

• SAQ A(자체 평가 설문지 A): 결제가 규준을 준수하는 외부 업체에 완전히 위탁되어 카드 데이터가 자체 시스템에 전혀 닿지 않는 경우입니다. 가장 짧은 설문 양식입니다.

• SAQ A-EP: 사이트에서 카드 데이터를 직접 처리하지 않지만 고객이 결제 폼에 도달하는 방식을 제어하는 경우입니다. 웹 서버에 전체 표준의 상당 부분이 적용됩니다.

• SAQ D: 구축한 시스템을 통해 카드 데이터가 아주 잠시라도, 저장되지 않고 통과하는 경우입니다. 사실상 표준 전체가 적용되며 매년 문서화 및 증명을 거쳐야 합니다.

가장 낮은 단계라 해서 부담이 전혀 없는 것은 아닙니다. 2025년 1월 PCI 보안 표준 협의회는 SAQ A에서 결제 페이지 스크립트 요건을 제거했으나 자격 조건을 추가했습니다. 즉, 사이트가 이커머스 시스템에 영향을 미칠 수 있는 스크립트 공격에 취약하지 않음을 확인해야 합니다¹. 결제를 전적으로 외부에 위탁한 단계라 하더라도 다른 업체의 결제 폼을 호스팅하는 페이지는 직접 보호해야 합니다.

연간 카드 거래 건수가 600만 건을 초과하면 자체 평가는 완전히 종료되고 QSA(공인 보안 평가사)의 현장 감사가 시작됩니다².

코딩만으로 대면 결제 규제를 우회할 수 있을까요?

불가능합니다. 대면 결제는 규제의 사다리가 거대한 장벽으로 바뀌는 구간입니다. 카드 실물 결제에는 인증된 하드웨어가 필요합니다. 협의회의 PTS 연구소 프로그램을 통과하고 승인된 펌위웨어를 실행하며 PG사를 통해 공급된 실물 리더기가 필요합니다. 소프트웨어만으로 스마트폰을 리더기로 변환하는 것은 별도의 표준인 Mobile Payments on COTS (MPoC)의 적용을 받으며, 이는 작성한 코드가 아닌 솔루션 제공업체를 인증하는 규정입니다.

이것은 AI 코드 생성 기술로도 넘을 수 없는 경계입니다. AI 모델은 반나절 만에 그럴듯한 체크아웃 화면을 만들 수 있지만, Lovable이나 Replit으로 POS를 구축할 수 있을까요? 및 바이브 코딩으로 POS 제작하기 문서에서는 이러한 빌드가 한계에 부딪히는 지점을 추적합니다. 모델이 감독 없이 얼마나 오래 코딩하든 생성된 코드가 인증된 리더기, 가맹점 계약, 규준 준수 증명서까지 만들어내지는 못합니다. 보안 규정 준수는 바이브 코딩된 결제 앱이 앱 스토어에서 거절당하는 이유의 주요 원인이기도 합니다.

개발자는 실제 어떻게 PCI 적용 범위를 줄일 수 있을까요?

규정에 억지로 맞추려 하지 말고, 준수해야 할 대상 자체를 줄이도록 아키텍처를 설계해야 합니다:

• PAN(기본 계좌 번호, 즉 카드 번호 자체)이 작성한 코드에 절대 접촉하지 않도록 하세요. PG사의 호스팅 결제 필드를 사용하여 카드 데이터가 고객 브라우저에서 PG사로 직접 전달되게 만드세요.

• 카드가 아닌 토큰을 저장하세요. 토큰화(카드 번호를 도난당해도 무용지물인 참조 문자열로 대체)를 사용하면 저장된 카드 정보나 환불 처리로 인해 데이터베이스가 규제 대상에 포함되는 것을 막을 수 있습니다.

• 대면 판매의 경우 PG사에서 제공하는 인증된 리더기를 사용하여 카드 데이터가 앱을 거치지 않고 리더기에서 PG사로 바로 이동하도록 하세요.

• 결제 페이지는 최대한 단순하게 유지하세요. 페이지에 포함되는 제3자 스크립트 하나하나가 모두 관리 대상이 됩니다.

제대로 구축하면 앱은 카드 데이터를 전혀 다루지 않고도 결제를 조율할 수 있으며 설문지도 매우 간소화됩니다. 반면 잘못 설계하면 편의 기능 하나("전체 요청 본문 로깅") 때문에 조용히 SAQ D 대상자로 전환될 수 있습니다.

그렇다면 앱 개발자에게 PCI 준수는 얼마나 까다로울까요?

작성한 코드가 카드 데이터에 접촉하는 정도에 비례하여 까다로워지므로, 가장 좋은 방법은 데이터 접촉을 완전히 차단하는 것입니다. 규정은 앱을 개발자 팀이 작성했든 AI가 반나절 만에 만들었든 상관하지 않습니다. 적용 범위는 동일하게 적용됩니다. 카드 결제 기능을 출시하기 전에 한 가지만 자문해 보세요. 내가 작성한 코드를 통해 카드 번호가 단 한 번이라도 통과하는가? 그렇다면 감사 예산을 세우세요. 아니라면, 앞으로도 카드 데이터가 코드에 닿지 않도록 유지하세요.

Final이 사용하는 아키텍처 방식도 이와 동일합니다. Final 기반으로 구축된 체크아웃 시스템은 Build에서 생성되었든 MCP를 통해 자체 AI로 구축되었든 Final Pay를 통해 결제를 처리합니다. 카드 데이터는 PG사 및 인증된 단말기 하드웨어에서 처리하므로 워크플로우 자체는 카드 번호를 소유하지 않습니다. 실무적 내용은 Final Pay 이용 가능 지역을 확인하시고, 규제 레이어가 사전에 갖춰졌을 때의 결제 승인 모습은 Tap to Pay를 AI POS 플로우에 연결하기에서 확인해 보세요.