결제정보 유출이 의심될 때 PG사와 카드사 대응 순서

이 글이 필요한 사람과 다른 안내가 필요한 사람

온라인 결제를 직접 운영하는 사업자라면 도움이 됩니다

자사몰, 예약사이트, 교육·구독 서비스처럼 PG사와 계약해 카드결제를 받는 사업자라면 이 글의 대응 순서를 그대로 체크리스트로 사용할 수 있습니다. 대표자뿐 아니라 개발자, 개인정보 보호책임자, 고객센터 책임자도 함께 보는 편이 좋습니다.

• 결제 페이지에 알 수 없는 코드가 삽입된 경우
• 관리자 계정 탈취 후 결제 설정이 변경된 경우
• PG 연동키 또는 비밀키 노출이 의심되는 경우
• 고객이 결제 직후 모르는 카드승인을 제보한 경우
• 서버 로그에서 비정상적인 주문·결제 관련 접근이 발견된 경우
• 개발자 PC나 배포 계정 침해와 결제 시스템이 연결된 경우

개인 카드 이용자라면 순서가 다릅니다

사업자가 아니라 자신의 카드정보 유출을 걱정하는 이용자라면 PG사보다 카드 발급사에 먼저 연락해 이용정지·재발급·의심 거래 확인을 문의하는 편이 직접적입니다. 여러 장의 카드를 분실한 경우에는 여신금융협회의 카드 분실 일괄신고 제도도 확인할 수 있습니다.

이미 거액의 부정결제가 확인됐다면 이 글만으로 충분하지 않습니다

다수 고객의 부정사용, 수사기관 연락, 개인정보위 조사, 카드사 사고조사 요청, 대규모 데이터 반출 정황이 확인됐다면 단순 고객센터 업무가 아닙니다. 보안 사고 대응, 개인정보 법률 검토, PG·카드사 대응을 하나의 사고팀으로 묶어야 합니다.

읽기 전에 확인하세요: PG 문의만으로 법적 대응이 끝나지는 않습니다

2026년 8월 현재 개인정보가 유출됐음을 알게 된 경우 정보주체에 대한 통지는 원칙적으로 72시간 이내가 기준입니다. 개인정보위 신고도 모든 사고가 동일한 것은 아니며, 1천명 이상 정보주체의 개인정보 유출, 민감정보·고유식별정보 유출, 외부 불법 접근에 의한 개인정보 유출 등 법령상 기준에 해당하는 경우 72시간 이내 신고가 요구될 수 있습니다.

또한 2026년 3월 공포된 개인정보 보호법 개정 내용 가운데 유출 가능성 단계에서의 통지제도 등은 2026년 9월 11일 시행 예정입니다. 이 글을 9월 11일 이후 읽고 있다면 개정 시행령과 개인정보위 최신 안내를 다시 확인하는 것이 안전합니다.

처음 30분, 서버를 지우기 전에 해야 할 순서

사고 초기에는 “복구”보다 “통제와 보존”이 먼저입니다. 정상 영업을 빨리 되돌리려는 마음 때문에 공격 흔적이 있는 서버를 초기화하면 나중에 PG사, 카드사, 조사기관이 사고 범위를 확인하기 어려워질 수 있습니다.

1단계: 의심 경로부터 차단합니다

1. 침해가 의심되는 관리자·개발·배포 계정의 추가 접근을 제한합니다.
2. 노출 가능성이 있는 API 키와 PG 연동 비밀정보의 사용 중지·교체 절차를 PG사와 협의합니다.
3. 악성 결제 페이지나 변조된 코드가 확인되면 신규 노출을 막되 원본 증거는 별도로 보존합니다.
4. 가능하면 사고 시스템과 정상 시스템의 네트워크 경계를 분리합니다.

2단계: 시각과 로그를 고정합니다

최초 발견 시각, 최초 이상 징후, 관리자 로그인 기록, 웹서버·애플리케이션 로그, 주문번호, PG 거래번호, 배포 기록, 보안장비 로그를 복사해 보존합니다. 사고 원본을 무턱대고 삭제하거나 포맷하지 않는 것이 중요하다는 점은 개인정보 포털의 유출 대응 안내에서도 강조됩니다.

로그를 어디서부터 모아야 할지 막힌다면 고객정보 유출 시 확인할 로그 정리 가이드처럼 웹·관리자·데이터베이스 기록을 시간순으로 모으는 방식이 도움이 됩니다.

잠깐, 비밀번호부터 전부 바꾸면 끝일까요?

비밀번호와 키 교체는 필요할 수 있지만, 교체하기 전에 누가 언제 어떤 계정으로 접근했는지 남겨두어야 합니다. 공격자를 쫓아내는 조치와 사고 흔적을 보존하는 조치를 동시에 진행해야 합니다.

PG사에 먼저 보낼 정보 7가지: 대응 속도는 여기서 갈립니다

온라인 가맹점이 결제정보 유출을 의심한다면 PG사는 결제 경로를 확인하는 핵심 연락처입니다. “해킹당한 것 같습니다”라고만 문의하기보다 PG 담당자가 거래를 바로 추적할 수 있는 정보를 함께 보내는 편이 낫습니다.

PG사 사고 문의 메모

준비 항목	적어둘 내용
가맹점 식별정보	상호, 가맹점 ID, 서비스 도메인
발견 시각	최초 이상 징후를 확인한 날짜와 시간
의심 기간	최초 침입 가능 시점부터 차단 시점까지
결제 방식	PG 결제창, 앱 연동, 정기결제, 토큰 결제 등
의심 정보	카드번호, 유효기간, 주문정보, 결제 토큰, 거래번호 등 확인 중인 항목
대표 거래	의심 주문번호·승인번호·PG 거래번호 몇 건
이미 한 조치	계정 차단, 키 교체 요청, 페이지 차단, 서버 격리 여부

PG사에 반드시 물어볼 질문

• 고객 카드정보 입력이 실제로 어느 시스템에서 처리됐는가?
• 당사 서버를 통과하는 카드 관련 데이터가 있었는가?
• 노출된 연동키로 가능한 행위의 범위는 어디까지인가?
• 해당 기간의 승인·취소·환불·인증 이상 패턴이 있는가?
• 가맹점 계정 또는 연동키 긴급 교체가 필요한가?
• 카드사나 매입 관련 기관에 PG사가 별도 사고 전파를 진행하는가?
• PG 측에서 보존해야 할 로그와 당사가 제출해야 할 자료는 무엇인가?

카드사는 언제 끼워야 하나: 바로 연락할 때와 PG를 거칠 때가 다릅니다

PG사와 카드사의 역할은 겹쳐 보이지만 다릅니다. 사업자의 결제 연동과 거래 흐름을 먼저 좁히는 창구는 보통 PG사이고, 개별 카드의 이용정지·재발급·부정사용 조사와 같은 카드회원 조치는 카드 발급사가 담당합니다.

사업자라면 무조건 모든 카드사에 전화할 필요는 없습니다

PG를 통해 카드승인을 받고 있다면 먼저 PG사의 사고 대응팀이나 가맹점 담당자에게 사고를 알리고 카드사 전파 절차를 확인하는 것이 실무적으로 정돈된 방법입니다. 다만 카드사와 직접 계약한 구조, 별도 매입 계약, VAN 연동 등 계약 구조가 다르면 해당 계약의 사고 연락 절차를 따라야 합니다.

고객에게 실제 부정사용이 나타났다면 카드사 대응을 늦추면 안 됩니다

고객이 본인이 승인하지 않은 거래를 발견했다면 사업자가 대신 보상 가능 여부를 단정해서는 안 됩니다. 해당 고객에게 카드 발급사의 공식 신고 채널을 통해 카드 정지, 재발급, 거래 이의제기 절차를 확인하도록 안내하는 편이 안전합니다.

여신금융협회는 카드 분실·도난 신고와 부정사용 관련 소비자 안내를 운영하고 있습니다. 실제 보상 여부는 사고 유형과 카드회원의 고의·과실 여부 등 구체적 사정에 따라 달라질 수 있습니다.

그런데 실제로는 다릅니다: PG 확인과 고객 보호는 병렬입니다

PG 조사 결과가 나올 때까지 고객에게 아무 조치도 안내하지 않는 것은 피해야 합니다. 구체적인 카드 노출 가능성이 있는 고객이 확인되면 카드사 확인 방법을 안내하면서, 사업자는 PG와 사고 범위를 계속 좁히는 두 갈래 대응이 필요합니다.

결제정보가 정말 유출됐는지 가르는 세 가지 경계선

“결제 시스템이 해킹됐다”는 말만으로는 카드번호가 빠져나갔는지 알 수 없습니다. 반대로 카드번호를 DB에 저장하지 않았다는 사실만으로 결제정보 사고 가능성이 사라지는 것도 아닙니다.

경계선 1: 고객이 카드정보를 어디에 입력했는가

PG사가 제공하는 별도 결제 화면에서 카드정보가 처리됐다면 사업자 서버가 카드 원문을 직접 보유하지 않았을 가능성이 있습니다. 하지만 결제 직전 페이지가 변조돼 다른 곳으로 입력값을 복제하는 악성 코드가 삽입됐다면 상황이 달라집니다.

경계선 2: 카드번호가 아니라 토큰만 노출됐는가

결제 토큰은 원래 카드번호 자체와 동일하지 않습니다. 그러나 그 토큰이 어떤 기능을 허용하고, 가맹점 키와 결합했을 때 재결제가 가능한지는 PG 설계와 계약에 따라 달라집니다. “토큰이니 안전하다”가 아니라 노출된 값으로 무엇을 할 수 있었는지를 확인해야 합니다.

경계선 3: 주문정보만 빠져나갔는가

카드 원문이 없더라도 이름, 전화번호, 주소, 이메일, 주문내역, 결제금액 등이 외부로 반출됐다면 개인정보 유출 문제가 별도로 남을 수 있습니다. 결제정보 사고와 개인정보 사고의 범위를 따로 그린 뒤 겹치는 부분을 찾는 방식이 좋습니다.

조금 더 깊이 알고 싶다면

결제 연동에서는 카드 원문, 일부 마스킹 값, 결제 토큰, 가맹점 키, 승인번호, 주문번호가 서로 다른 역할을 합니다. 사고 분석에서는 “어떤 문자열이 노출됐는가”보다 그 값 하나 또는 다른 자격증명과 조합했을 때 가능한 행위를 확인해야 합니다.

따라서 개발팀은 노출 데이터 목록을 만들고, PG사에는 각 항목의 재사용 가능성·유효기간·권한 범위를 문의하는 것이 좋습니다. 이 작업은 불필요한 카드 재발급 공지를 줄이면서도 실제 위험을 놓치지 않게 해줍니다.

72시간과 24시간, 서로 다른 사고 시계를 구분하세요

사고 대응에서 가장 위험한 착각 중 하나가 “PG사에 접수했으니 신고도 끝났다”는 생각입니다. PG 문의, 개인정보 유출 통지·신고, 정보통신망 침해사고 신고는 목적과 근거가 서로 다를 수 있습니다.

개인정보 유출을 알게 됐다면 72시간 기준을 먼저 표시합니다

현행 개인정보 보호법 시행령은 개인정보가 분실·도난·유출됐음을 알게 된 때 원칙적으로 72시간 이내에 정보주체에게 필요한 사항을 알리도록 규정하고 있습니다. 일정 규모·유형의 유출은 개인정보위 또는 KISA에 대한 신고 대상이 됩니다. 정확한 범위를 아직 다 확인하지 못한 경우에는 확인된 내용으로 우선 신고하고 추가 사항을 보완하는 제도도 마련돼 있습니다.

해킹 침해사고라면 별도 신고 대상인지 확인합니다

KISA 보호나라는 정보통신서비스 제공자의 침해사고 신고와 관련해 침해사고 발생을 알게 된 때부터 24시간 이내 신고 기준을 안내하고 있습니다. 자신의 사업이 해당 신고의무 대상인지 모호하다면 사고 초기에 118 또는 KISA 공식 창구에서 확인하는 편이 안전합니다.

KISA 신고 절차를 더 간단히 정리한 내부 가이드는 KISA 118 사이버사고 신고 방법에서 함께 확인할 수 있습니다.

대부분 여기서 잘못 판단합니다: 신고와 고객 공지는 같은 문서가 아닙니다

기관 신고서에는 사고 경위와 대응 현황 등 조사에 필요한 내용이 중요하고, 고객 통지에는 고객이 어떤 정보의 영향을 받았으며 무엇을 하면 되는지가 선명해야 합니다. 확인되지 않은 공격 규모를 추측해 쓰지도 말고, 불리해 보이는 사실을 모호하게 숨기지도 않는 것이 좋습니다.

고객 안내가 필요한 단계에 들어갔다면 개인정보 유출 고객 안내문 작성법처럼 확인된 사실, 피해 최소화 방법, 문의 창구를 분리해 작성하는 것이 실무적으로 편합니다.

연락·신고 대상	주요 목적	먼저 준비할 것
PG사	결제 경로·거래·연동키 영향 확인	가맹점 ID, 사고 시각, 대표 거래번호
카드사	카드회원 보호, 부정사용 확인·처리	영향 거래·고객 범위, PG 협의 내용
KISA	침해사고 상담·신고 및 개인정보 관련 신고 지원	사고현황, 대응현황, 로그 보존 상황
개인정보위·KISA 유출신고	법령상 개인정보 유출 신고	유출 항목·규모·시점·경위·피해 최소화 조치
경찰	범죄 수사 필요 시 신고	로그, 계정기록, 피해내역, 침입 흔적

흔히 하는 실수: 빨리 움직였는데 오히려 조사만 어려워지는 경우

실수 1: 서버를 곧바로 포맷합니다

서비스 복구만 생각하면 가장 쉬운 선택처럼 보입니다. 하지만 침입 경로, 악성코드, 접속 시각, 반출 데이터 범위를 밝힐 단서까지 사라질 수 있습니다. 개인정보 포털도 해킹 유출사고에서 시스템 초기화나 관련 악성코드·로그를 보존하지 않고 삭제하는 대응을 피하도록 안내합니다.

실수 2: PG사가 알아서 카드사와 고객까지 처리한다고 생각합니다

PG사가 결제 경로 조사와 금융기관 협조에서 중요한 역할을 하더라도 자사 개인정보처리자로서의 고객 통지나 신고 의무까지 자동으로 대신한다고 볼 수는 없습니다. 계약서의 사고 대응 조항과 실제 역할을 각각 확인해야 합니다.

실수 3: 확인 전부터 “카드번호가 전부 유출됐다”고 공지합니다

속도는 필요하지만 추정치를 사실처럼 발표하는 것은 다른 문제입니다. 현재 확인된 정보, 아직 확인 중인 정보, 고객이 즉시 취할 조치를 구분하면 공지는 훨씬 정확해집니다.

실수 4: 고객 문의 내용만 받고 카드 거래번호를 남기지 않습니다

“해외결제가 됐어요”라는 상담 메모만으로는 패턴 분석이 어렵습니다. 문의 시각, 결제일, 금액, 카드사, 당사 주문 여부, 관련 주문번호를 구조화해 기록하면 PG 조사와 사고 범위 비교에 훨씬 유용합니다.

전문가 도움이 필요한 경우: 내부 대응만으로 버티지 말아야 할 신호

작은 쇼핑몰이라도 모든 사고를 외부 업체에 맡겨야 하는 것은 아닙니다. 반대로 몇 가지 신호가 겹치면 내부 개발자 한 명이 복구와 분석을 동시에 맡는 구조는 위험할 수 있습니다.

다음 신호가 있다면 외부 사고대응을 검토하세요

• 침입 시작 시점이 며칠 또는 몇 달 전으로 보이는 경우
• 관리자·서버·데이터베이스 여러 계정이 동시에 침해된 경우
• 웹셸이나 악성 스크립트가 발견된 경우
• 대량 다운로드 또는 외부 전송 흔적이 있는 경우
• 로그가 삭제되거나 일부 기간이 비어 있는 경우
• PG 연동키나 결제 관련 자격증명 노출 가능성이 있는 경우
• 다수 고객에게 부정사용 제보가 들어오는 경우
• 기관·카드사에서 상세 사고자료 제출을 요구한 경우

무료 대응과 유료 도움은 이렇게 나눌 수 있습니다

대응 수준	적합한 상황	포함할 일
기본 대응	영향 범위가 좁고 로그가 온전한 초기 의심	내부 로그 보존, PG 문의, KISA 상담, 키 교체 검토
실속 대응	침입 흔적이나 데이터 접근 정황이 확인됨	외부 사고대응·포렌식, 영향 범위 분석, 재발 방지
확장 대응	대규모 고객 영향, 카드 부정사용, 규제기관 조사 가능성	포렌식 + 개인정보 법률 검토 + 고객 통지·기관 대응 체계

외부 사고대응 업체를 검토한다면 “복구가 가능한가”보다 원본 증거 보존 방식, 분석 범위, 보고서 형태, PG·카드사 제출자료 지원 여부를 먼저 물어보는 편이 낫습니다.

수사기관 신고를 함께 검토해야 하는 경우

명백한 계정 탈취, 서버 침입, 협박, 금전 피해 등 범죄 정황이 있다면 경찰 신고를 검토할 수 있습니다. 이때는 사건 시간표와 원본 로그, 관리자 접속기록, 피해 거래를 정리해 두는 것이 도움이 됩니다. 관련 준비 항목은 해킹 피해 경찰 신고 시 준비할 증거자료에서도 확인할 수 있습니다.

실제 적용 사례: 외부 결제창을 썼는데도 확인이 필요한 이유

실제 적용 사례

작은 온라인 쇼핑몰에서 새벽에 관리자 계정의 비정상 로그인이 발견됐다고 가정해 보겠습니다. 운영자는 카드번호를 저장하지 않고 PG 결제창을 사용했기 때문에 처음에는 “결제정보 사고는 아닐 것”이라고 판단했습니다.

하지만 확인해 보니 공격자가 상품 페이지 파일을 수정할 수 있는 권한까지 확보했고, 결제 버튼이 있는 화면에 낯선 외부 스크립트가 추가돼 있었습니다. 이 시점에서는 카드번호 DB가 없다는 사실보다 고객이 결제 단계에 들어가기 전 어떤 코드가 실행됐는지가 더 중요한 질문이 됩니다.

운영팀은 서버를 바로 초기화하지 않고 파일 변경 시각과 웹로그를 보존했습니다. PG사에는 가맹점 ID와 의심 기간, 대표 거래번호를 전달해 실제 카드정보 입력 구간과 PG 측 이상 거래를 확인해 달라고 요청했습니다. 동시에 관리자 계정과 배포 자격증명을 교체하고 추가 침입을 차단했습니다.

결국 중요한 교훈은 “PG 결제창을 썼으니 안전하다”도, “관리자가 해킹됐으니 모든 카드가 유출됐다”도 아닙니다. 결제 경로와 공격자가 확보한 권한을 연결해 실제로 가능한 행위를 확인하는 것이 사고 범위를 결정합니다.

자주 묻는 질문

PG 결제창을 사용했다면 카드번호 유출 가능성은 없나요?

그렇게 단정하기 어렵습니다. 카드번호를 사업자 DB에 저장하지 않았다는 점은 중요한 판단 요소지만, 결제 전 페이지 변조나 악성 스크립트, 관리자 계정 침해가 있었다면 고객 입력 과정 자체를 확인해야 합니다. PG사에 카드정보가 실제로 입력되는 위치와 자사 서버를 통과하는 데이터 범위를 확인하세요.

의심만 있고 실제 유출 여부를 아직 모르면 고객에게 바로 알려야 하나요?

현재 적용되는 통지 의무는 실제 유출을 알게 된 시점과 구체적인 상황이 중요합니다. 다만 2026년 9월 11일부터는 유출 가능성 단계 통지와 관련한 개정 제도가 시행될 예정이므로 사고 발생 시점의 최신 법령을 확인해야 합니다. 확인을 핑계로 조사를 미루기보다 최초 인지 시각부터 기록해 두는 것이 좋습니다.

72시간 안에 유출된 고객 수를 다 파악하지 못하면 어떻게 하나요?

개인정보 보호법 시행령은 신고 대상 사고에서 유출 항목이나 시점의 구체적 내용을 아직 확인하지 못한 경우 확인된 사항으로 우선 신고하고 추가로 확인되는 내용을 보완할 수 있도록 규정하고 있습니다. 사고가 끝날 때까지 기다렸다가 한 번에 완벽한 신고서를 만들겠다는 접근은 주의해야 합니다.

PG사가 이상이 없다고 하면 개인정보 유출 신고도 하지 않아도 되나요?

PG 결제 시스템 이상 여부와 자사 개인정보 유출 여부는 별개로 판단해야 합니다. 주문 DB나 회원정보, 관리자 시스템에서 유출이 있었다면 PG사 결과만으로 신고 여부가 결정되지 않습니다.

카드번호 일부만 보이면 카드사에 신고해야 하나요?

마스킹된 카드번호 일부만으로 실제 결제가 가능한지는 결제 구조와 다른 정보의 노출 여부에 따라 다릅니다. PG사에 해당 데이터의 성격과 재사용 가능성을 확인하고, 개인정보 영향도 별도로 평가하는 것이 좋습니다.

결제 연동키가 깃 저장소에 공개됐다면 카드정보 유출인가요?

키 노출 자체와 카드정보 유출은 같은 사실이 아닙니다. 먼저 키가 허용하는 기능, 외부에서 실제 사용된 흔적, 노출 기간을 확인해야 합니다. 즉시 폐기·교체가 필요한지는 PG사와 협의하면서 기존 키의 사용 로그도 보존하세요.

고객에게 카드 재발급을 무조건 권해야 하나요?

사업자가 모든 고객에게 일률적으로 재발급을 지시하기보다 실제 영향 범위와 카드사 안내를 바탕으로 고객이 자신의 카드 발급사에서 정지·재발급 필요성을 확인하도록 안내하는 편이 신중합니다. 명백한 카드정보 노출이나 부정사용이 확인된 경우에는 카드사와 협의해 보다 구체적인 보호 조치를 안내할 수 있습니다.

사고 대응업체 비용은 언제부터 쓰는 것이 좋나요?

로그가 충분하고 영향 범위가 좁다면 내부 보존과 PG·KISA 확인으로 1차 범위를 잡을 수 있습니다. 반대로 웹셸, 다수 서버 침해, 장기간 잠복, 대량 반출, 로그 훼손, 카드 부정사용이 확인되면 전문 포렌식 비용을 검토할 이유가 커집니다. 가격만 비교하기보다 증거 보존 방식과 보고서 범위를 먼저 비교하세요.

개인정보위 신고와 KISA 침해사고 신고를 둘 다 해야 할 수도 있나요?

가능합니다. 두 제도는 목적과 적용 요건이 다르므로 개인정보 유출과 정보통신망 침해가 동시에 발생한 사고라면 각각의 신고 대상 여부를 확인해야 합니다. 모호한 경우에는 KISA 118과 개인정보 유출 신고 창구에 사고 유형을 설명하고 적용 여부를 확인하는 편이 안전합니다.

지금 15분 안에 사고 메모 한 장부터 만드세요

지금 한 가지만 한다면 새 문서를 열고 아래 여덟 줄을 채우세요. 이 한 장이 PG사 문의, 내부 회의, KISA 상담, 고객 안내의 공통 출발점이 됩니다.

1. 사고를 처음 발견한 정확한 시각
2. 최초 이상 징후가 무엇이었는지
3. 영향이 의심되는 도메인·서버·계정
4. 결제 방식과 PG사·가맹점 ID
5. 노출 가능성이 있는 데이터 항목
6. 의심 기간에 발생한 대표 거래번호 3~5건
7. 현재까지 시행한 차단·키 교체·격리 조치
8. 보존한 로그와 아직 확보하지 못한 로그

최종 검토: 2026-08