CVV 뜻을 한 줄로 말하면 카드를 손에 쥐고 있는지 확인하는 숫자입니다. 카드 번호는 어딘가에서 유출될 수 있지만, 카드 뒷면에 인쇄된 짧은 코드는 그 카드를 실제로 만져 본 사람만 볼 수 있습니다. 이 차이가 온라인 결제에서 이 코드를 따로 받는 이유이고, 동시에 이 코드를 저장하면 안 되는 이유이기도 합니다. 이 글에서는 자릿수와 위치, 저장 금지의 배경, 그리고 테스트할 때의 주의점을 살펴봅니다.
CVV는 카드 어디에 인쇄되어 있을까?
대부분의 카드에서는 뒷면 서명란 옆에 세 자리가 인쇄되어 있습니다. 번호 전체와 같은 줄에 있지 않고 서명란 오른쪽에 따로 놓이는 경우가 많아서, 처음 보는 사람은 한참 찾기도 합니다.
American Express는 예외입니다. 이 카드의 코드는 앞면 오른쪽 위에 네 자리로 인쇄되어 있습니다. 카드마다 위치와 자릿수가 다르니, 결제 화면의 안내 문구도 카드사를 알아본 뒤 바뀌어야 합니다.
| 구분 | 인쇄 위치 | 자릿수 |
|---|---|---|
| 대부분의 카드 | 뒷면 서명란 옆 | 3자리 |
| American Express | 앞면 오른쪽 위 | 4자리 |
같은 코드를 두고 부르는 이름도 여러 가지라서, 화면 문구를 정할 때는 사이트 안에서 한 가지 표현으로 통일하는 편이 좋습니다.
이 코드는 언제 요구되고 언제 요구되지 않을까?
모든 결제 화면이 이 값을 요구하지는 않습니다. 카드를 직접 긁거나 꽂는 대면 결제에서는 카드 자체가 확인 수단이므로 코드를 따로 입력받지 않습니다. 카드 정보를 미리 등록해 두고 반복 결제하는 구독형 서비스도 첫 등록 이후에는 코드를 다시 묻지 않습니다. 이 경우 카드사와 결제 대행사가 발급한 참조 값을 대신 씁니다.
반대로 카드 번호를 매번 새로 입력받는 온라인 결제에서는 거의 항상 요구됩니다. 화면 설계를 할 때 이 구분을 알고 있으면, 어떤 흐름에 코드 입력 칸이 필요한지 판단하기 쉬워집니다.
이 코드가 증명하는 것
카드 번호만으로 결제가 가능하다면, 번호를 한 번 본 사람은 누구나 남의 카드로 결제할 수 있게 됩니다. 그래서 번호와 함께 카드 자체에만 있는 값을 요구합니다. 번호를 외우고 있는 사람과 카드를 들고 있는 사람을 구분하는 최소한의 장치인 셈입니다.
이 코드는 카드 정보가 유출되어도 피해를 줄이는 역할을 합니다. 번호와 유효기간만 빼낸 공격자는 코드를 모르면 온라인 결제를 끝내지 못합니다. 그래서 코드는 카드 번호보다 더 엄하게 다뤄야 하는 값입니다.
왜 저장하면 안 될까
결제 카드 산업의 보안 기준은 인증이 끝난 뒤 이 코드를 보관하는 것을 금지합니다. 코드는 승인 요청을 보낼 때 한 번 쓰이고, 그 요청이 끝나면 남겨 두어서는 안 되는 값입니다.
이유는 단순합니다. 코드를 저장해 두면 그 저장소가 곧 공격의 표적이 됩니다. 번호와 유효기간, 코드를 함께 갖고 있으면 온라인 결제에 필요한 값이 모두 모이기 때문입니다. 저장하지 않으면 유출될 것도 없습니다.
구현 관점에서 이 금지는 여러 곳에 걸립니다.
- 결제 요청을 보낸 뒤 메모리에서도 곧바로 지우기
- 요청 본문을 통째로 남기는 로그를 만들지 않기
- 오류 추적 도구에 요청 전체가 실려 나가지 않도록 설정하기
- 개발자 도구나 관리자 화면에서 코드를 다시 보여 주지 않기
특히 로그가 가장 흔한 구멍입니다. 오류를 잡으려고 요청을 통째로 남겨 둔 로그 파일에 코드가 함께 들어가는 경우가 많습니다.
결제 화면의 입력 칸은 어떻게 만들어야 할까?
코드 입력 칸은 자릿수가 짧아서 대충 만들어도 될 것 같지만, 실제로는 세심한 처리가 필요합니다.
- 숫자만 입력받고, 붙여넣기로 들어온 공백도 걷어내기
- 자릿수를 넘겨 입력하면 더 받지 않기
- 카드사를 인식한 뒤 안내 문구와 최대 길이를 바꾸기
- 마스킹된 값이나 잘못된 형식의 값을 붙여넣었을 때 이유를 알려 주기
- 자동 완성 기능이 코드 칸에 다른 값을 채우지 않도록 지정하기
American Express 카드를 선택했는데 세 자리까지만 받는 화면은, 사용자에게는 카드가 잘못된 것처럼 보입니다. 카드사 인식과 자릿수 처리를 같은 시점에 갱신하는 것이 좋습니다.
테스트할 때 무엇을 조심해야 할까
테스트 환경에서도 이 코드를 다루는 방식은 같아야 합니다. 개발용 데이터라서 괜찮다고 생각하고 실제와 비슷한 값을 저장하기 시작하면, 그 습관이 그대로 운영 코드로 넘어갑니다.
테스트에서 확인할 항목은 다음과 같습니다.
- 코드 없이 제출했을 때의 오류 문구가 이해하기 쉬운지
- 자릿수가 짧거나 긴 값에 대해 적절히 막는지
- 카드사를 바꿨을 때 안내 문구와 최대 길이가 함께 바뀌는지
- 제출 후 다시 입력 화면으로 돌아왔을 때 이전 값이 남아 있지 않은지
마지막 항목은 눈으로 확인하기 어렵지만 중요합니다. 뒤로 가기를 눌렀을 때 코드가 그대로 채워져 있다면, 그 값은 어딘가에 남아 있다는 뜻입니다.
개발자를 위한 메모: 저장 금지를 코드로 강제하라
규칙을 문서로만 두면 지켜지지 않습니다. 코드 차원에서 막는 편이 확실합니다.
- 결제 요청을 나타내는 값에서 코드 필드를 요청 직후 비우기
- 로그에 남기는 값을 미리 정한 항목으로만 제한하기
- 저장소에 들어가는 값에 대해 마스킹을 기본 동작으로 두기
- 오류 보고 도구에 전송되는 값에서 코드를 제거하는 필터 두기
관리자 화면이나 고객 지원 도구에서 코드를 조회할 수 있게 만들면, 그 순간 저장 여부와 무관하게 규정 위반에 가까워집니다. 지원 담당자가 코드를 물어보는 흐름 자체를 만들지 않는 것이 가장 안전합니다. 저장과 마스킹 규칙 전반은 PCI DSS 테스트 데이터에서 더 넓게 다룹니다.
다음 단계
결제 폼에 코드 입력 칸이 있다면, 카드사를 바꿔 가며 안내 문구와 자릿수가 제대로 따라오는지 먼저 확인해 보세요. 생성기에서 카드사별로 번호와 함께 표시되는 예시 코드를 쓰면 두 경우를 모두 재현할 수 있습니다. 결제 폼 테스트 체크리스트를 함께 보면 오류 응답과 재입력 흐름까지 점검할 수 있습니다. 생성기에서 만들어지는 값은 구조적으로 유효할 뿐 실제로 발급된 적이 없으므로, 실제 결제에 사용할 수 없습니다.