✦ guniq 시각
PCI DSS v4.0 요구사항 6.4.3과 11.6.1은 단순한 규정 강화가 아니다. “우리 서버는 안전하다”는 말이 더 이상 면피가 되지 않는 시대의 선언이다. 문제는 브라우저 안, 즉 고객이 카드 번호를 타이핑하는 바로 그 순간에 있다. 중소 전자상거래 사업자라면 구글 애널리틱스 태그 하나, 채팅 위젯 하나도 이제 문서화된 승인 대상이다. 준비가 안 된 곳은 이미 비컴플라이언트 상태다.
▲ 이미지 출처: The Hacker News
결제 페이지의 서드파티 스크립트가 PCI DSS 컴플라이언스 의무 대상이 된 지 이미 1년이 넘었다. PCI Security Standards Council(PCI SSC)이 2022년 3월 발표한 PCI DSS v4.0에는 결제 페이지 스크립트 관리를 명문화한 두 가지 새 요구사항, 즉 6.4.3과 11.6.1이 포함됐다. 2025년 3월 31일 유예 기간이 종료되면서 이 두 요구사항은 전 세계 모든 카드 결제 처리 사업자에게 즉시 강제되는 필수 통제 항목으로 격상됐다. 분석 태그, 마케팅 픽셀, 채팅 위젯, 결제 iframe — 현대적인 결제 페이지를 구성하는 수십 개의 서드파티 요소가 이제 전부 관리 대상이다.
Magecart가 만들어 낸 규제: 왜 지금인가
이 규제가 탄생한 배경에는 Magecart라는 위협 집단의 활동이 있다. PCI SSC 공식 블로그는 Magecart를 “2015년부터 다양한 온라인 스키밍 공격을 수행하는 범죄 해킹 그룹들의 통칭”으로 정의한다. 이들의 방식은 단순하지만 치명적이다. 전자상거래 사이트에 악성 자바스크립트를 심어 고객이 카드 번호를 입력하는 순간 해당 정보를 탈취한다. 취약한 플러그인, 패치되지 않은 소프트웨어, 그리고 광고 스크립트·라이브 채팅·고객 평점 기능 같은 서드파티 서비스가 주요 침투 경로다.
규모는 이미 산업적 수준이다. 2024년 한 해 동안 2억 6,900만 건의 카드 정보가 다크웹과 클리어웹을 통해 노출됐으며, 감염된 전자상거래 도메인만 1만 1,000개 이상에 달했다. 전년 대비 거의 300% 증가한 수치다. 2024~2025년 사이 6개월 만에 공격 건수가 103% 급증했다는 통계도 있다. 가장 유명한 단일 사례에서는 22줄의 코드 삽입으로 한 기업 고객의 38만 건 결제 정보가 한꺼번에 유출됐다.
서버 방어만으로는 이 공격을 막을 수 없다. 악성 자바스크립트는 고객의 브라우저 안에서 카드 데이터를 캡처하기 때문에, 서버 사이드 도구만으로는 e-스키밍 공격을 차단하기에 충분하지 않다. 결제 페이지 위에서 실행되는 코드, 바로 그 코드가 공격 표면이다.
요구사항 6.4.3: 스크립트 승인·무결성·인벤토리 3중 의무
PCI DSS v4.0 요구사항 6.4.3의 공식 텍스트는 명확하다. Foregenix가 인용한 원문은 다음과 같다: “소비자 브라우저에서 로드·실행되는 모든 결제 페이지 스크립트는 다음과 같이 관리되어야 한다. 각 스크립트가 승인됐음을 확인하는 방법이 구현되어야 한다. 각 스크립트의 무결성을 보장하는 방법이 구현되어야 한다. 각 스크립트의 필요성에 대한 서면 정당성을 포함한 모든 스크립트 인벤토리가 유지되어야 한다.”
세 가지 하위 요구사항(a·b·c)은 각각 독립적이다. 첫째, 승인(Authorization): 허용된 스크립트 URL, 해시 값, 목적이 포함된 화이트리스트를 구축하고 Content Security Policy(CSP) 헤더로 미승인 스크립트를 차단한다. 둘째, 무결성(Integrity): SHA-256 같은 암호화 해시로 스크립트를 실행 전에 검증하는 Subresource Integrity(SRI) 또는 파일 무결성 모니터링(FIM) 도구를 적용한다. 셋째, 인벤토리(Inventory): 스크립트 URL, 출처, 목적, 승인 방법, 무결성 검증 방법, 그리고 해당 스크립트가 필요한 이유에 대한 서면 정당성을 모두 문서화해 유지한다.
핵심은 범위다. 구글 태그 매니저(GTM)를 통해 로드되는 모든 태그도 개별적으로 인벤토리에 등록하고 승인해야 한다. “구글 태그 매니저나 동등한 도구를 통해 로드되는 모든 태그는 개별적으로 인벤토리화되고 승인되어야 한다”는 것이다. GTM 컨테이너가 있다고 해서 그 안의 태그들이 자동으로 관리되는 게 아니다.
요구사항 11.6.1: 7일 이내 주기의 변조 탐지 의무
요구사항 11.6.1은 실시간 감시 의무다. 공식 요구사항 원문은 이렇다: “변경·변조 탐지 메커니즘이 다음과 같이 배포되어야 한다. HTTP 헤더 및 소비자 브라우저가 수신하는 결제 페이지의 콘텐츠에 대한 무권한 수정(침해 지표, 변경, 추가, 삭제 포함)을 직원에게 알리기 위해.” 그리고 하위 요구사항 11.6.1.c는 이 점검이 “적어도 7일에 한 번 또는 12.3.1에 정의된 목표 위험 분석에 따라 정기적으로” 수행되어야 한다고 명시한다.
탐지 범위는 스크립트 내용만이 아니다. HTTP 응답 헤더 변경도 포함된다. Content-Security-Policy 헤더가 약화되거나, X-Frame-Options이 제거되거나, 기존에 없던 Set-Cookie 속성이 추가되는 것도 탐지 대상이다. 구현 방법으로는 CSP violation reporting(report-to/report-uri 지시어), 합성 사용자 모니터링(Synthetic Monitoring), 결제 페이지에 내장된 변조 방지 스크립트, 역방향 프록시·CDN을 활용한 비교 검증 등이 인정된다.
SRI와 CSP만으로는 부족한 이유
기술적으로 가장 흔하게 언급되는 구현 방법은 Subresource Integrity(SRI)와 Content Security Policy(CSP)다. RSM US에 따르면 SRI는 “소비자 브라우저가 암호화 해시 태그를 통해 스크립트를 검증할 수 있게 하는” 방법으로, PCI DSS v4.0.1에서 유효한 구현 방법으로 인정된다. CSP는 “소비자 브라우저가 스크립트를 로드하고 계정 데이터를 전송할 수 있는 위치를 제한한다.”
그러나 현실적 한계가 있다. CSIDE는 SRI가 정적 스크립트에는 유효하지만 동적 스크립트에는 한계가 있다고 지적한다. 서드파티 스크립트가 업데이트될 때마다 해시를 재생성하고 재배포해야 하는데, 이는 금방 감당하기 어려운 수준이 된다. 구글 애널리틱스 같은 서드파티 스크립트는 공급업체가 수시로 업데이트하기 때문에 고정된 SRI 해시를 유지하기 어렵다. CSP 역시 강력하지만, 잘못 설정하면 합법적인 기능이 차단되고 배포 파이프라인에 복잡성이 추가된다.
결국 대규모 프로덕션 환경에서는 전용 클라이언트 사이드 모니터링 플랫폼을 도입하는 것이 현실적 선택이 된다. 해당 시장의 솔루션 가격대는 중소기업 기준 월 99달러~999달러 수준으로 형성돼 있으며, 자동화된 인벤토리 관리, AI 기반 정당성 작성 보조, 지속적 모니터링 및 QSA 검증 리포트 등을 제공한다.
SAQ A 간소화의 착각: 호스티드 결제도 예외가 아니다
많은 중소 사업자가 “우리는 스트라이프·페이팔 같은 호스티드 결제 솔루션을 쓰니까 괜찮다”고 여긴다. 이것은 착각이다. Compass MSP는 이렇게 설명한다: “결제 페이지가 서드파티 스크립트, 심지어 애널리틱스 도구, 채팅 위젯, 광고 픽셀이라도 로드하고 있다면, 그 확인은 간단하지 않다.”
PCI DSS v4.0.1 개정 과정에서 SAQ A(가장 간소화된 자기 평가 설문지) 범위가 조정됐다. PCI SSC의 Lauren Holloway는 SAQ A에서 요구사항 6.4.3, 11.6.1, 12.3.1이 제외됐음을 확인하면서도, 새로운 SAQ A 적격 요건으로 “사업자가 자신의 사이트가 전자상거래 시스템에 영향을 줄 수 있는 스크립트 기반 공격에 취약하지 않음을 확인”해야 한다는 조건이 추가됐다고 밝혔다. 이를 보호 기술 적용 또는 서드파티 제공업체 확인을 통해 충족시켜야 한다는 것이다. 사이트에 어떤 형태의 서드파티 스크립트도 없는 완전 정적 결제 페이지가 아니라면, 증명 의무는 여전히 남는다.
구현 방식에 따른 SAQ 적용 범주도 다르다. Foregenix에 따르면 iframe 방식은 SAQ A, Direct Post 방식은 SAQ A-EP, API 직접 연동 방식은 SAQ D(전체 요구사항 적용)가 된다. 통합 방식의 선택이 컴플라이언스 부담 규모를 결정한다.
PCI SSC가 직접 내놓은 공식 보충 지침
PCI SSC는 2025년 3월 10일, 유예 기간 종료를 앞두고 공식 보충 지침서를 발표했다. 제목은 “Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1”이다. 이 문서는 PCI SSC 스태프, 카드 브랜드 대표자, 이사회 자문위원회·기술 자문위원회 위원, 글로벌 평가자 원탁회의(GEAR) 참가자, 소규모 가맹점 태스크포스 대표들이 공동으로 작성했다.
보충 지침은 e-커머스 플랫폼 또는 결제 보안에 영향을 미치는 임베디드 iframe을 통해 카드 결제를 처리하는 모든 사업자와 서드파티 서비스 제공업체를 대상으로 한다. PCI SSC는 이 문서에서 “소비자 브라우저에서 실행되는 스크립트는 이제 결제 카드 데이터를 훔치려는 공격자의 주요 표적이 됐다”고 명시했다. 문서는 PCI SSC 문서 라이브러리에서 무료로 다운로드할 수 있다. 단, PCI SSC는 “카운슬은 컴플라이언스를 집행하거나 특정 구현이 컴플라이언트인지 결정하지 않는다”고 명확히 한다. 실제 판정은 QSA(공인 보안 평가자)가 수행한다.
비컴플라이언스의 실제 비용
규정을 어겼을 때의 비용 구조를 알면 투자 우선순위가 명확해진다. Compass MSP가 제시한 벌금 구조는 다음과 같다. 비컴플라이언스 1~3개월은 월 5,000~1만 달러, 4~6개월은 월 2만 5,000~5만 달러, 6개월 초과는 월 10만 달러다. 침해 사고가 발생하면 유출 건당 50~90달러의 추가 벌금이 부과된다. 고객 1만 명 데이터 유출 시 벌금만으로 50만~90만 달러에 달한다.
실제 판례도 있다. 미국 소매 브랜드 Hanna Andersson은 Salesforce Commerce Cloud 플랫폼을 통한 Magecart 공격으로 고객 20만 명이 피해를 입었고, CCPA(캘리포니아 소비자 프라이버시법) 위반으로 40만 달러 합의금과 함께 강화된 보안 요구사항을 수용해야 했다. 신뢰할 만한 서드파티 플랫폼을 쓴다고 해서 침해 책임에서 자유롭지 않다는 것을 보여주는 사례다. 그리고 사이버 공격 이후 6개월 내에 문을 닫는 중소기업이 60%에 달한다는 통계는, 이 리스크가 단순한 벌금 문제가 아님을 시사한다.
중소 전자상거래 사업자를 위한 컴플라이언스 로드맵
- 스크립트 인벤토리 즉시 작성 — 결제 페이지에서 로드되는 모든 스크립트를 열거하라. 브라우저 개발자 도구 Network 탭과 document.scripts로 확인할 수 있다. GTM 내부 태그도 개별 등재가 필요하다.
- 서면 정당성 문서화 — 각 스크립트에 대해 “(스크립트 이름)은 (목적)을 위해 필요하며 (담당자/날짜)가 승인했다”는 형식의 레코드를 남겨라. QSA가 요구하는 최소 형식이다.
- SRI 또는 CSP 적용 — 정적 스크립트에는 SRI 해시를 붙여라. 전체 결제 도메인에 CSP 헤더를 적용해 허가되지 않은 스크립트 실행을 차단하라. 단, 동적 스크립트에는 SRI의 한계를 인식하고 전용 모니터링 솔루션을 검토하라.
- 7일 주기 변조 탐지 체계 구축 — CSP violation report 수집, 합성 모니터링 툴 또는 전용 클라이언트 사이드 보안 솔루션을 통해 요구사항 11.6.1의 주기적 점검 의무를 충족하라. 알림 수신자와 대응 프로세스를 문서화하라.
- SAQ 유형 재검토 — 현재 사용 중인 결제 통합 방식이 iframe인지, Direct Post인지, API인지 확인하고 그에 맞는 SAQ 유형과 의무 범위를 QSA와 재확인하라.
- 서드파티 공급업체 책임 확인 — Clover, Stripe 등 결제 플랫폼을 사용한다면 해당 플랫폼이 6.4.3·11.6.1을 어떻게 처리하는지 명시한 공식 문서를 확보하라. 구두 확인은 감사 증거로 인정되지 않는다.
