결제·핀테크 엔지니어링 브리핑
← 목록으로

카드번호, 우리 서버에 저장해도 될까 — 토큰화 볼트 선택지 비교

2026-09-09인프라·시스템
#PCI DSS#토큰화#PG#인프라
Ad slot

정기결제(구독) 기능을 만들다 보면 누구나 한 번은 이 질문에 부딪힌다 — "다음 달에도 결제하려면 카드번호를 우리 DB에 저장해둬야 하는 거 아닌가?" 결론부터 말하면, 대부분의 PG(결제 대행 회사)와 가맹점(물건을 파는 사업자)에게 답은 "안 된다"다. 카드번호를 직접 저장하는 대신 무엇으로 대체할지 — 이 선택이 시스템 구조를 크게 좌우한다.

왜 카드번호를 함부로 저장하면 안 되나

여신전문금융업법(신용카드 관련 법) 제19조는 가맹점의 준수사항을 정하는데, 가맹점 표준약관 제19조 2항은 "손님과 거래 과정에서 알게 된 카드 정보를 보관하거나 거래 목적 외로 활용할 수 없다"고 명시한다. 즉 카드번호를 결제 순간에만 스쳐 지나가게 하고, 그 이후에는 남겨두면 안 된다는 뜻이다.

그럼 PG는 저장해도 될까? 여신금융협회와 카드업계는 "적격 PG사" 제도로 답을 정해뒀다. 카드정보를 저장할 수 있으려면 다음을 전부 갖춰야 한다.

요건 기준
재무 건전성 자기자본 400억원 이상, 순부채비율 200% 이하
보안 체계 부정사용방지시스템(FDS), 재해복구센터 구축
보안 인증 PCI DSS(카드업계 국제 데이터 보안 표준) 인증 취득

국내 상위 PG사 대부분은 이 기준을 충족해 카드정보를 저장하지만, 그 아래 2차 PG사나 이제 막 시작한 핀테크 스타트업은 대부분 미달이다. 자기자본 400억원은 스타트업 단계에서 넘기 어려운 벽이고, 그렇다고 정기결제 기능을 포기할 수도 없다. 그래서 실무에서는 카드번호 자체가 아니라 "카드번호를 대신할 무언가"를 저장하는 구조로 우회한다 — 이게 토큰화(tokenization)다.

토큰화가 실제로 어떻게 동작하나

아래 그림처럼, 카드번호는 고객이 처음 입력할 때 딱 한 번만 원본 그대로 흐르고, 그 이후에는 원본을 대신하는 "토큰"만 시스템 사이를 오간다.

카드정보 토큰화 흐름: 고객, 가맹점, PG, 토큰 볼트, 카드사 사이에서 원본 카드번호와 토큰이 나뉘어 흐르는 다이어그램

국내에서 가장 흔한 형태는 PG가 발급하는 "빌링키(BillKey)"다. 발급(Issue) 단계에서 PG가 카드정보를 받아 자기 쪽 안전한 저장소에 넣고, 그 대신 의미 없는 문자열(빌링키)을 가맹점에 돌려준다. 가맹점은 그 빌링키만 자기 DB에 저장(Store)해두고, 다음 달 결제할 때 이 빌링키로 결제를 요청(Use)한다. 빌링키만 유출돼도 카드번호로 되돌릴 방법이 없다는 게 핵심이다.

여기서 PCI DSS(카드업계가 정한 국제 보안 표준, 2026년 기준 버전 4.0.1)의 요구사항 3번(저장된 카드정보 보호)과 4번(전송 중 카드정보 보호)이 요구하는 게 바로 이 구조다 — "아예 안 갖고 있으면" 이 두 요구사항을 지키기 위한 부담 자체가 사라진다는 뜻에서, 이 접근을 "PCI DSS 적용 범위(scope) 축소"라고 부른다.

토큰화, 누구에게 맡길 것인가 — 선택지 비교

방식 예시 장점 트레이드오프
PG 발급 빌링키 토스페이먼츠·나이스페이먼츠·헥토파이낸셜 등 국내 PG의 정기결제 API 별도 계약·비용 없이 PG 이용료에 포함, 국내 규제·관행에 최적화 PG 종속 — PG를 바꾸면 빌링키를 그대로 못 옮기고 전 고객에게 카드 재등록을 요청해야 함
상용 토큰화 벤더 Basis Theory, VGS(Very Good Security) PG와 독립적으로 카드정보를 관리해 PG 교체가 쉬움, PCI Level 1 인증 보유 별도 API 비용 발생, 국내 리전 지원 여부와 데이터 국외 이전 이슈를 반드시 확인해야 함
HashiCorp Vault Transform Vault의 토큰화(Transform) 엔진 Vault를 이미 비밀관리용으로 쓰고 있다면 통합이 쉬워 보임 오해하기 쉬운 지점 — Transform 엔진은 무료 오픈소스가 아니라 Vault Enterprise의 ADP(Advanced Data Protection) 라이선스가 있어야 쓸 수 있다. "오픈소스니까 무료"라고 예산을 잡으면 나중에 틀어진다
직접 구축(셀프호스트 오픈소스) PCI Vault, TokenShield 같은 GitHub 프로젝트 라이선스 비용 없음 대부분 개념 증명(PoC) 수준이라 프로덕션 안전성이 검증되지 않았고, PCI DSS 감사도 직접 통과해야 함 — 카드정보처럼 사고 나면 되돌릴 수 없는 데이터에 검증 안 된 코드를 쓰는 리스크가 절감되는 비용보다 크다

정리하면, 대부분의 PG·가맹점에게는 "PG 발급 빌링키"가 기본값이고, 여러 PG를 동시에 쓰거나 PG 교체 가능성을 열어두고 싶은 규모 있는 사업자만 상용 벤더를 검토할 가치가 있다. 셀프호스트 오픈소스는 카드정보 도메인에서는 비용 절감보다 사고 시 책임 리스크가 더 크다고 보는 게 안전하다.

개발팀이 지금 점검해야 할 것

카드번호가 로그에 남는지부터 확인한다 결제 요청·응답을 그대로 로그로 남기는 코드가 있다면, 카드번호가 뜻하지 않게 로그 저장소에 평문으로 쌓인다. 결제 시스템 모니터링 글에서 다룬 마스킹 원칙이 여기서도 그대로 적용된다 — 카드번호·CVC는 로그·트레이스·에러 리포트 어디에도 원본으로 남으면 안 된다.

빌링키를 "그냥 문자열"로 취급하지 않는다 빌링키 자체는 암호화된 값이지만, 가맹점 DB에 저장할 때는 한 번 더 암호화해서 저장하는 게 안전하다. 빌링키와 실제 고객을 매핑하는 테이블에 대한 접근 권한도 최소한으로 제한해야 한다.

PG 교체 시나리오를 미리 설계해둔다 PG 발급 빌링키를 쓰기로 했다면, PG를 바꿔야 하는 상황이 왔을 때 "전체 고객에게 카드 재등록을 요청"하는 것 외에 다른 선택지가 없다는 걸 미리 인지하고 있어야 한다. 규모가 커질수록 이 전환 비용이 커지므로, 특정 시점부터는 상용 벤더형 토큰화로 옮기는 것도 검토 대상이 된다.

PCI DSS 인증 자체보다 "카드정보를 안 갖고 있는" 것을 목표로 삼는다 적격 PG사가 될 계획이 없다면, PCI DSS 인증을 직접 따는 것보다 카드정보가 우리 시스템에 아예 닿지 않게 만드는 게 훨씬 싸고 안전하다. 결제창을 PG가 제공하는 방식(iframe·리다이렉트)으로 띄워서 카드번호 입력 자체가 PG 도메인에서 이뤄지게 하면, 카드번호가 우리 서버를 한 번도 거치지 않는다.

체크리스트

  • 우리 회사가 여신금융협회 "적격 PG사" 기준(자기자본 400억원 등)을 충족하는지, 아니면 토큰화로 우회해야 하는지 확인했는지
  • 결제 관련 로그·트레이스·에러 리포트 어디에도 카드번호·CVC가 평문으로 남지 않는지 점검했는지
  • 빌링키·토큰을 저장하는 테이블의 암호화와 접근 권한이 최소화돼 있는지
  • HashiCorp Vault를 검토 중이라면 Transform(토큰화) 기능이 Enterprise ADP 라이선스 대상이라는 걸 예산에 반영했는지
  • 결제창을 PG 도메인에서 띄워 카드번호가 우리 서버를 거치지 않는 구조(iframe/리다이렉트)를 쓰고 있는지
  • PG를 교체해야 하는 상황이 왔을 때 빌링키 재발급 절차와 고객 안내 방안을 미리 설계해뒀는지

카드정보는 유출되면 되돌릴 방법이 없는 데이터다. "저장 안 하는 것"이 가장 확실한 보안이고, 토큰화는 그걸 가능하게 해주는 도구일 뿐이라는 걸 설계 초반부터 팀 전체가 공유해두는 게 가장 저렴한 대책이다.

참고자료

관련 글

Ad slot