개념
결제 시스템 QA가 PCI DSS를 알아야 하는 이유
PCI DSS(Payment Card Industry Data Security Standard)는 카드 브랜드들이 만든 PCI 보안표준위원회(PCI SSC)가 관리하는 카드 소지자 데이터 보호 표준 이다. 법률은 아니지만, 카드 결제를 받는 가맹점과 결제를 처리하는 서비스 제공자(PG·결제 대행·처리 업체)는 카드 브랜드·매입사와의 계약으로 준수를 요구받는다. 국내에서도 글로벌 카드 결제를 처리하는 PG사· 해외 가맹점 서비스·글로벌 서비스 기업이 인증을 유지한다.
QA가 이 표준을 알아야 하는 이유는 단순하다. PCI DSS는 보안 조직만의 표준이 아니라 시험 환경, 시험 데이터, 변경 절차, 정기 보안 시험 주기 를 직접 요구한다. 결제 기능을 시험하는 방식 자체가 준수 대상이다. 결제 시험 환경에 실제 카드번호가 들어가 있으면 그 환경 전체가 심사 범위가 되거나 부적합이 된다.
버전과 시행 시점
| 시점 | 내용 |
|---|---|
| 2022년 3월 | PCI DSS v4.0 발행 |
| 2024년 6월 | v4.0.1 발행 (명확화·오류 수정 중심의 제한적 개정) |
| 2024년 12월 31일 | v4.0 은퇴, v4.0.1이 유효 판 |
| 2025년 3월 31일 | v4.0에서 "미래 시행"으로 유예됐던 신규 요건들이 모두 의무화 |
2025년 3월 31일 이후 의무가 된 요건에는 QA와 직접 관련된 것이 여럿 있다. 결제 페이지 스크립트 관리(6.4.3), 결제 페이지 변경·변조 탐지(11.6.1), 공개 웹 애플리케이션 보호를 위한 자동화된 기술 솔루션(6.4.2), 맞춤 소프트웨어와 제3자 구성요소 목록 유지(6.3.2), 내부 취약점 스캔의 인증된 스캔(11.3.1.2), 범위 문서화와 확인(12.5.2) 등이다. 인용할 때는 PCI SSC 문서 라이브러리의 현행 판 을 확인한다.
범위가 곧 시험 계획의 범위다
PCI DSS의 모든 요건은 카드 소지자 데이터 환경(CDE) 에 적용된다. CDE는 카드 소지자 데이터(PAN 등)나 민감 인증 데이터를 저장·처리·전송하는 시스템, 그리고 그것들과 연결되거나 보안에 영향을 주는 시스템이다. 범위를 좁히는 것이 준수 비용을 줄이는 핵심이고, 그래서 범위를 좁히는 설계(토큰화, 결제창 위임, 네트워크 세분화) 가 널리 쓰인다.
QA에게 범위는 두 가지 의미다.
| 의미 | QA 행동 |
|---|---|
| 범위 안 시스템은 PCI 요건 전부를 적용받는다 | 시험 계획에서 범위 안 컴포넌트를 표시하고, 변경 시 12.5.2 범위 재확인 영향 검토 |
| 범위를 좁히는 설계가 실제로 동작해야 범위가 좁아진다 | 토큰화 후 하류 시스템에 PAN이 흐르지 않는지, 세분화가 CDE를 격리하는지 시험으로 증명 |
두 번째가 QA의 핵심 기여다. 예를 들어 결제 대행사의 호스팅 결제창을 써서 가맹점 서버가 PAN을 받지 않는 구조라고 설계서에 적혀 있어도, 실제로는 이런 경로로 PAN이 흘러들 수 있다.
[PAN 유입 경로 탐색 시험 — 범위 축소 설계 검증]
- 결제 실패 시 결제창이 가맹점 콜백 URL 에 오류 상세로 카드번호 일부·전체를 붙여 보내는가
- 고객센터 문의 양식·채팅에 고객이 카드번호를 입력하면 어디에 저장되는가
- 프런트엔드 오류 수집 도구가 결제 화면 입력값을 수집하는가 (세션 리플레이·로그 SDK)
- 애플리케이션 로그·APM 트레이스에 요청 본문이 통째로 기록되는가
- 분석·광고 스크립트가 결제 화면 DOM 을 읽는가 (6.4.3 과 연결)
판정: 테스트 카드번호를 입력한 뒤 로그·DB·트레이스·오류 수집 도구·백업에서 PAN 패턴 검색 → 0건마지막 줄의 PAN 패턴 검색 은 자동화할 수 있다. 시험용 카드번호를 흘린 뒤, 범위 밖이어야 할 저장소 전체를 카드번호 형식과 Luhn 검사로 훑는다. 범위 축소 설계를 회귀 시험으로 지키는 가장 싼 방법이다.
시험 환경과 시험 데이터 — 6.5.x
PCI DSS v4.0에서 변경 관리 요건은 6.5.1~6.5.6으로 묶였다. QA 업무와 직결되는 조항이다.
| 요건 | 요지 | QA 절차 |
|---|---|---|
| 6.5.1 | 운영 환경의 시스템 구성요소 변경은 정해진 절차(사유·보안 영향 문서화·승인·기능 시험으로 보안에 악영향 없음 검증·롤백 절차)를 따른다 | 변경 건별 시험 결과와 승인 기록 연결 (레슨 1 프로그램 통제와 같은 구조) |
| 6.5.2 | 중대한 변경 완료 시 해당 PCI DSS 요건이 새·변경 시스템에 적용되었음을 확인 | 중대 변경 후 요건 적용 확인 체크리스트 |
| 6.5.3 | 운영 전 환경은 운영 환경과 분리, 접근 통제로 분리를 강제 | 시험 환경 네트워크·계정 분리 시험 |
| 6.5.4 | 운영·운영 전 환경의 역할과 기능이 분리되어 책임이 명확 | 개발자의 운영 배포 권한 점검 |
| 6.5.5 | 실제 PAN은 운영 전 환경에서 쓰지 않는다 (그 환경이 CDE에 포함되어 모든 요건으로 보호되는 경우 제외) | 시험 데이터 정책, 운영 전 환경 PAN 검색 |
| 6.5.6 | 시험 데이터와 시험 계정은 시스템이 운영에 들어가기 전에 제거 | 출시 체크리스트, 운영 환경 시험 계정 검색 |
6.5.5가 결제 QA의 일상을 바꾼다. 결제 시험은 카드 브랜드·결제 대행사가 제공하는 시험용 카드번호 와 샌드박스로 한다. "운영 데이터 복사본으로 재현하면 편하다"는 유혹이 결제 영역에서는 준수 위반이 된다. 결함 재현에 실제 카드번호가 필요한 상황이면, 재현 환경을 CDE 수준으로 보호하거나 토큰으로 재현하는 절차를 미리 만든다.
6.5.6은 의외로 자주 걸린다. 시험 편의를 위해 만든 관리자 시험 계정·고정 OTP 계정·결제 우회 플래그 가 운영에 남는 경우다. 출시 전 점검을 사람의 기억에 맡기지 말고 자동화한다.
[출시 전 자동 점검 — 6.5.6]
- 운영 DB·인증 시스템에서 시험 계정 명명 규칙(test_, qa_, dummy) 검색 → 0건
- 설정에서 결제 우회·샌드박스 엔드포인트·고정 인증번호 플래그 → 비활성
- 운영 번들에 시험용 카드번호 목록·시험 픽스처 파일 포함 여부 → 0건
- 결제 대행사 연동 키가 운영 키인지 (샌드박스 키가 운영에 배포되면 결제가 실제로 안 됨)소프트웨어 개발 요건 — 6.2.x·6.3.2·6.4.2
| 요건 | 요지 | QA 접점 |
|---|---|---|
| 6.2.4 | 맞춤 소프트웨어에 흔한 공격 기법(인젝션, 데이터 구조 공격, 암호 오용, 비즈니스 로직 우회, 접근 통제 우회, 알려진 취약점)을 막는 공학 기법 적용 | 모듈 16 보안 시험 기법과 비즈니스 로직 우회 시험 (금액 변조·결제 단계 건너뛰기) |
| 6.3.2 | 맞춤 소프트웨어와 그 안의 제3자 구성요소 목록 유지 | SBOM (모듈 40 레슨 5와 같은 방식) |
| 6.4.2 | 공개 웹 애플리케이션 앞에 웹 기반 공격을 탐지·차단하는 자동화된 기술 솔루션 배치 | 솔루션이 켜진 상태에서 결제 기능 회귀 — 정상 결제가 차단되지 않는가 |
6.2.4의 비즈니스 로직 우회 는 스캐너가 잘 못 찾는 영역이라 QA의 몫이 크다. 결제에서 전형적인 시험은 이렇다.
- 주문 금액을 클라이언트에서 변조해 결제 요청 (서버가 주문 원장 금액과 대조하는가)
- 결제 승인 콜백을 위조해 "결제 완료" 상태 만들기 (서명·상태 조회 검증)
- 결제 단계 건너뛰기: 결제 전 주문 완료 API 직접 호출
- 부분 취소 금액 합계가 원 결제 금액 초과
- 같은 결제 승인 번호로 여러 주문 완료 처리 (레슨 2 멱등성)
- 할인·포인트 적용 후 음수 금액결제 페이지 스크립트 — 6.4.3과 11.6.1
전자상거래 결제 페이지에 악성 스크립트를 심어 카드 입력값을 빼가는 공격(웹 스키밍)이 늘면서 두 요건이 2025년 3월 31일부터 의무가 됐다.
| 요건 | 요지 |
|---|---|
| 6.4.3 | 고객 브라우저에서 로드·실행되는 모든 결제 페이지 스크립트 에 대해 — 인가 확인 방법, 무결성 보장 방법, 스크립트 목록과 각각의 사업상·기술상 필요 사유 유지 |
| 11.6.1 | 소비자 브라우저가 받는 결제 페이지의 보안 영향 HTTP 헤더와 스크립트 내용에 대한 무단 변경을 탐지·경보 하는 메커니즘. 기본 주기는 최소 7일마다 (또는 위험 분석으로 정한 주기) |
"모든 스크립트"는 결제 관련 스크립트만이 아니다. 분석 태그·채팅 위젯·A/B 테스트 도구처럼 결제 페이지에 로드되는 모든 스크립트가 대상이다. 그리고 결제 페이지가 결제 대행사의 iframe을 포함하는 구조라면, 적용 범위와 책임 분담은 결제 대행사 연동 방식과 PCI SSC의 해설(명확화 문서·FAQ)에 따라 달라지므로 연동 구조를 근거로 범위를 확인 한다.
QA가 이 두 요건에 기여하는 방식은 결제 페이지를 시험 대상으로 삼는 것 이다.
[결제 페이지 스크립트 회귀 시험 — Playwright 로 구현 가능]
1. 결제 페이지를 로드하며 네트워크 요청 중 script 리소스를 전부 수집
(동적으로 삽입되는 스크립트 포함 — 페이지 로드 후 N초 대기, 결제 단계별로)
2. 수집 목록을 승인된 스크립트 목록(출처 URL·무결성 해시·사유)과 대조
→ 목록에 없는 스크립트 = 실패
→ 해시 불일치 = 실패
3. 보안 관련 응답 헤더(Content-Security-Policy 등) 스냅샷을 기준과 대조
4. 결과를 판정 레코드로 저장 (모듈 38 레슨 4)
주기: 배포마다 + 운영 환경 대상 주기 실행 (11.6.1 주기 이상)이 시험은 11.6.1의 탐지 메커니즘 그 자체 는 아니지만(운영의 상시 탐지는 전용 솔루션이나 CSP 보고로 구현하는 경우가 많다), 배포 단계에서 승인되지 않은 스크립트가 운영으로 가는 것을 막고, 탐지 메커니즘이 제대로 경보하는지 시험하는 도구 가 된다. 태그 관리자로 마케팅 팀이 배포 없이 스크립트를 추가하는 조직이라면, 배포 게이트 밖에서 스크립트가 바뀌므로 운영 대상 주기 실행이 특히 중요하다.
정기 보안 시험 주기 — 11.3·11.4
PCI DSS는 정기 보안 시험의 주기와 수행자 를 정한다. QA는 이 일정을 릴리스 일정과 맞춰야 한다.
| 요건 | 시험 | 주기·조건 | 수행자 |
|---|---|---|---|
| 11.3.1 | 내부 취약점 스캔 | 최소 3개월마다, 고위험·치명 취약점 해결 후 재스캔 | 자격 있는 인력, 조직적 독립성 |
| 11.3.1.2 | 내부 스캔을 인증된 스캔 으로 | 위 주기 | 〃 |
| 11.3.1.3 | 중대한 변경 후 내부 스캔 | 변경 후 | 〃 |
| 11.3.2 | 외부 취약점 스캔 | 최소 3개월마다, PCI SSC 승인 스캔 업체(ASV) 가 수행, 통과할 때까지 재스캔 | ASV |
| 11.3.2.1 | 중대한 변경 후 외부 스캔 | 변경 후 | 자격 있는 인력 |
| 11.4.1~11.4.3 | 내부·외부 침투 시험 | 문서화된 방법론, 최소 12개월마다 + 중대한 인프라·애플리케이션 변경 후 | 자격 있는 내부 또는 외부, 조직적 독립성 |
| 11.4.4 | 침투 시험 발견 사항 조치 | 조치 후 재시험으로 확인 | — |
| 11.4.5 | 세분화 통제 시험 (세분화로 범위를 줄인 경우) | 가맹점 최소 12개월마다 + 세분화 변경 후 | — |
| 11.4.6 | 서비스 제공자 세분화 시험 | 최소 6개월마다 + 세분화 변경 후 | — |
두 가지를 기억하자. 첫째, 분기 ASV 스캔은 침투 시험을 대신하지 못한다. 스캔은 알려진 취약점을 찾고, 침투 시험은 공격자 관점의 조합 공격을 본다. 둘째, "중대한 변경 후" 조건이 QA의 릴리스 판단과 직결된다. 결제 흐름을 바꾸는 큰 릴리스는 중대한 변경일 수 있고, 그러면 연간 일정과 별개로 스캔·침투 시험이 필요하다. 모듈 38 레슨 5 게이트에 "PCI 중대 변경 여부" 판단을 넣고, 해당하면 시험 일정을 릴리스 계획에 포함한다.
11.4.4의 조치 후 재시험 은 레슨 1의 취약점 분석·평가와 같은 구조다. QA가 재시험과 기능 회귀를 함께 설계한다.
준수 증거를 시험 체계와 잇는다
PCI DSS 평가(QSA의 현장 평가 또는 자체 평가 설문)에서 요건마다 증거를 제시한다. QA 산출물 중 증거가 되는 것을 대응표로 관리한다.
[PCI DSS 요건 ↔ QA 증거 — 발췌]
요건 증거 생성원
6.5.1 변경 건별 기능 시험 결과·승인·롤백 절차 배포 게이트 결정 기록
6.5.3 운영 전 환경 분리 시험 기록 분기 환경 분리 점검
6.5.5 운영 전 환경 PAN 패턴 검색 결과 (0건) 주간 자동 검사
6.5.6 출시 전 시험 계정·데이터 제거 점검 릴리스 체크리스트 자동 점검
6.2.4 비즈니스 로직 우회 시험 결과 릴리스 전 보안 시험 세트
6.4.3 결제 페이지 스크립트 목록 대조 결과 배포마다 + 주기 실행
11.4.4 침투 시험 발견 조치 재시험·회귀 결과 조치 건별
12.5.2 범위 축소 설계 검증 (PAN 유입 경로 탐색 시험) 릴리스마다 + 연 1회 범위 확인모듈 39 레슨 9의 증거 대응표와 같은 구조다. 결제 조직이 CSAP·ISMS-P·ISO 27001을 함께 유지한다면 같은 증거가 여러 인증에 쓰인다.
실무에서 왜 필요한가
결제 영역 QA에서 가장 흔한 준수 위반은 보안 설정이 아니라 시험 관행 에서 나온다. 운영 데이터 복사본으로 만든 시험 DB에 실제 카드번호가 남아 있다, 시험 계정이 운영에 배포됐다, 마케팅 스크립트가 결제 페이지에 조용히 추가됐다, 범위 밖이라던 로그에 카드번호가 찍힌다. 모두 QA가 시험 설계와 자동 점검으로 막을 수 있는 것들이다.
2025년 3월 31일 이후 결제 페이지 스크립트와 변조 탐지 요건이 의무가 되면서, 결제 페이지를 보안 회귀 시험 대상 으로 다룰 줄 아는 QA의 수요가 커졌다. 면접에서 "결제 기능을 시험했다"보다 "시험용 카드번호를 흘려 로그·트레이스·오류 수집 도구에서 PAN을 찾아 범위 축소 설계의 누수를 발견했다", "배포마다 결제 페이지 스크립트를 승인 목록과 대조하는 시험을 만들었다"가 결제 도메인 경험을 보여준다.