PCI DSS 테스트 데이터 규칙은 많은 팀이 뒤늦게 알게 되는 주제입니다. 테스트 환경이니까 괜찮다는 판단으로 운영 데이터를 복사해 온 순간, 그 환경도 규정이 정한 범위 안으로 들어옵니다. 규정은 데이터가 운영 시스템에 있는지 개발 장비에 있는지를 구분하지 않습니다. 이 글에서는 테스트 환경에서 무엇을 쓰면 안 되는지, 대신 무엇을 쓰면 되는지, 그리고 그것을 코드로 어떻게 강제하는지 정리합니다.
테스트 환경이 규정 대상이 되는 이유
규정의 목적은 카드 정보를 보호하는 것이지, 특정 서버를 보호하는 것이 아닙니다. 그래서 카드 소지자 데이터가 있는 시스템은 어디에 있든 같은 보호 의무를 집니다. 개발자 노트북, 사내 테스트 서버, 자동화 테스트용 데이터베이스가 모두 여기에 해당합니다.
문제는 이런 환경의 보호 수준이 운영보다 낮다는 점입니다. 접근 권한이 느슨하고, 백업이 여기저기 흩어져 있고, 폐기 절차도 없습니다. 실제 데이터를 넣어 두면 가장 약한 고리에서 유출됩니다.
저장하면 안 되는 항목은 무엇일까?
결제 카드 산업의 보안 기준은 인증이 끝난 뒤 보관할 수 없는 항목을 분명히 정해 둡니다. 안전 코드와 카드 전체의 자기띠 정보가 대표적입니다. 이 값들은 승인 요청을 보낼 때 한 번 쓰이고, 그 뒤에는 남겨 두어서는 안 됩니다.
저장을 허용하는 항목도 조건이 붙습니다. 계정 번호는 보관할 수 있지만 보호 조치가 필요하고, 화면에 보여 줄 때는 일부를 가려야 합니다. 일반적으로 앞 여섯 자리와 뒤 네 자리만 남기고 나머지를 가리는 방식이 쓰입니다.
- 저장 금지: 보안 코드, 자기띠 전체 정보
- 조건부 저장: 계정 번호, 유효기간, 이름
- 표시 규칙: 앞 여섯 자리와 뒤 네 자리만 노출
실무에서 자주 생기는 위반은 저장 자체보다 주변에서 나옵니다. 로그, 오류 추적 도구, 백업 파일, 개발자 화면, 테스트 데이터베이스 덤프가 대표적입니다.
적용 범위는 어떻게 정해질까?
범위는 카드 소지자 데이터가 흐르는 경로를 따라 정해집니다. 데이터가 저장되는 곳뿐 아니라 그 데이터를 지나 보내는 시스템과, 그 시스템에 접근할 수 있는 계정까지 함께 포함됩니다. 그래서 실제 카드 정보가 들어 있는 테스트 서버 한 대가 있으면, 그 서버와 연결된 계정 관리와 접근 통제까지 심사 대상이 됩니다.
범위를 줄이는 가장 확실한 방법은 실제 데이터를 아예 들이지 않는 것입니다. 합성 데이터로 채워 두면 그 환경은 카드 소지자 데이터를 다루지 않게 되고, 관리해야 할 항목이 크게 줄어듭니다.
테스트 환경이 규정을 지키는지 어떻게 확인할까?
확인은 문서와 코드, 그리고 도구 세 곳에서 함께 이뤄집니다. 어느 하나만 점검하면 구멍이 남습니다.
- 테스트 데이터를 어떻게 만드는지 절차가 문서로 있는지
- 그 절차를 사람이 손으로 하는지, 자동으로 도는지
- 저장소에 들어가는 값에 가리기 처리가 기본으로 걸려 있는지
- 로그와 오류 보고 도구로 나가는 값을 걸러 내는 규칙이 있는지
- 테스트 환경이 운영 데이터베이스에 닿지 못하는지
- 실제 데이터를 넣은 흔적이 남아 있지 않은지 주기적으로 확인하는지
마지막 항목은 대개 자동 점검으로 만듭니다. 실제 데이터가 들어오면 경보가 울리게 해 두면, 규칙을 몰랐던 사람이 운영 데이터를 복사해 오는 사고를 조기에 잡을 수 있습니다.
실제 카드 정보를 테스트에 쓰면 왜 안 될까?
첫째, 규정 위반입니다. 개발과 테스트 환경에서는 실제 카드 소지자 데이터를 사용하지 않고 합성 데이터나 토큰을 쓰도록 요구합니다.
둘째, 범위가 넓어집니다. 실제 데이터가 있는 시스템은 모두 심사 대상이 됩니다. 테스트용 서버 한 대 때문에 관리해야 할 시스템이 몇 배로 늘어납니다.
셋째, 사고가 났을 때 피해가 큽니다. 테스트 환경에서 유출된 실제 카드 정보도 똑같이 피해입니다. 게다가 테스트 환경은 추적과 차단 장치가 부족한 경우가 많아, 유출 사실을 늦게 알게 됩니다.
그렇다면 합성 데이터와 토큰화는 어떻게 다르고, 어느 쪽을 골라야 할까요? 합성 데이터는 실제 카드와 무관하게 형식만 맞춰 새로 만든 값입니다. 카드 조직별 대역과 자릿수, 검산 규칙을 지키므로 화면과 검증 로직은 정상적으로 동작합니다. 하지만 뒤에 계좌가 없어서 승인은 되지 않습니다.
토큰화는 실제 카드 번호를 결제 대행사가 보관하고, 우리 쪽에는 그 번호를 가리키는 참조 값만 두는 방식입니다. 반복 결제나 환불처럼 같은 카드를 다시 써야 하는 상황에서 실제 번호 없이 처리를 이어 갈 수 있습니다.
| 구분 | 합성 데이터 | 토큰 |
|---|---|---|
| 실제 계좌 연결 | 없음 | 결제 대행사 쪽에 있음 |
| 형식 검증 통과 | 통과 | 통과 |
| 승인 가능성 | 없음 | 조건에 따라 가능 |
| 반복 결제 | 불가 | 가능 |
| 적합한 용도 | 화면과 검증 테스트 | 운영 결제 흐름 |
두 방식을 구분하지 않고 쓰면 문제가 생깁니다. 합성 데이터로 반복 결제를 시험하려 하면 당연히 실패하고, 그 실패를 코드 결함으로 오해하게 됩니다.
개발자를 위한 메모: 테스트와 운영을 갈라 놓아라
규칙은 문서에만 두면 지켜지지 않습니다. 구조로 막아야 합니다.
- 테스트 환경이 운영 데이터베이스에 접근하지 못하게 망을 분리하기
- 운영 데이터를 내려받는 절차 자체를 만들지 않기
- 로그와 오류 보고 도구에 전송되는 값을 미리 정한 항목으로 제한하기
- 화면과 API 응답에서 계정 번호를 가리는 처리를 기본값으로 두기
- 테스트 데이터 생성 절차를 자동화하고, 수작업 복사를 금지하기
테스트 데이터를 자동으로 만들 때는 재현 가능성이 중요합니다. 같은 조건에서 같은 데이터가 나와야 실패를 다시 재현할 수 있습니다. 이 주제는 스테이징 데이터베이스에 가짜 데이터 심기에서 더 자세히 다룹니다.
생성기에서 함께 확인할 것
합성 데이터를 직접 만들 때는 카드 조직별 대역과 자릿수가 실제 규칙과 맞는지, 검산 숫자가 제대로 채워졌는지, 표시용으로 함께 나오는 유효기간과 보안 코드가 입력 칸의 기대 형식과 맞는지를 한 번에 확인하는 편이 좋습니다. 테스트용 신용카드 번호 생성기에서 카드사를 지정하고 필요한 개수만큼 만들면 이 세 가지를 동시에 볼 수 있어, 저장과 표시 규칙을 점검하는 출발점으로 쓰기 좋습니다.
다음 단계
먼저 테스트 환경에 실제 카드 정보가 들어 있는지 확인하고, 있다면 합성 데이터로 교체하는 것부터 시작하세요. 교체용 번호는 테스트용 신용카드 번호의 기준에 맞춰 고르면 됩니다. 저장과 표시 규칙을 코드로 강제하는 방법은 보안 코드와 결제 폼 테스트 체크리스트를 함께 보면 정리됩니다. 이 글에서 말하는 합성 번호는 구조적으로 유효하지만 실제로 발급된 적이 없으므로 결제에 사용할 수 없습니다.