글 | 만리풍취 정연태, 건설산업정보원 원장

최근 은행과 저축은행, 캐피탈사 등 금융권에서 잇따라 침해사고와 정보유출 사고가 확인되면서 금융당국이 전 금융권을 대상으로 긴급 점검에 나섰다. 특히 금융당국은 이번 사고에서 대출모집인이나 임직원이 업무 편의를 위해 사용하는 외부 웹페이지와 서버 등 상대적으로 관리가 덜 된 영역이 공격대상으로 활용된 사례가 확인됐다고 밝혔다. 또 인공지능(AI)을 이용한 공격 가능성까지 제기되면서 금융회사의 보안대응 방식도 달라져야 한다는 지적이 나온다.

그러나 금융회사가 가장 먼저 해야 할 일은 공격자가 AI를 사용했는지를 규명하는 것이 아니다. 사고가 현재 진행되고 있는지 확인하고 추가 피해를 막으며, 사라질 수 있는 증거를 보존하고, 실제로 어떤 정보가 어디까지 이동했는지를 확인하는 것이 우선이다.

금융범죄 예방·탐지·대응 AI GPT의 Cyber·Privacy·Forensics 분석체계를 이번 사고에 적용하면 금융회사 침해사고 대응은 크게 다음 단계로 구성할 수 있다.

1. 가장 먼저 해야 할 일은 ‘원인 규명’이 아니라 추가 피해 차단이다

침해사고 초기에는 공격자가 누구인지, 어떤 공격도구를 사용했는지를 분석하는 데 시간을 보내기 쉽다. 하지만 고객정보가 계속 조회되거나 외부로 이동하고 있거나 관리자 계정이 침해된 상황이라면 원인 분석보다 추가 피해를 막는 것이 먼저다. 금융범죄 대응 AI GPT는 이를 Golden Hour 단계로 구분한다.

CONTAIN → PRESERVE → IDENTIFY → PROTECT → ESCALATE → VERIFY LEGAL DUTIES → INVESTIGATE

첫 번째는 CONTAIN, 즉 확산 차단이다. 침해된 것으로 의심되는 계정과 세션, 관리자 권한, 외부접속 경로 등을 확인하고 추가적인 고객정보 조회·다운로드·외부전송 가능성을 차단해야 한다. 다만 무조건 시스템 전체를 종료하는 방식은 서비스 중단이나 증거 훼손을 가져올 수 있으므로 CISO, 정보보호, IT운영, 법무, 감사 등 권한 있는 조직의 판단 아래 조치해야 한다.

두 번째는 PRESERVE, 증거보존이다. IAM·MFA·PAM 로그, DB Query 및 Export 기록, EDR, 파일·USB 기록, Firewall·Proxy·VPN·DNS 로그, Application 로그, DLP, 이메일, Cloud, 출입기록 등을 가능한 한 신속하게 보존해야 한다. 사고 이후 로그가 순환삭제되거나 시스템 변경으로 증거가 사라지면 이후 정확한 사고범위 판단이 어려워질 수 있다. 금융 포렌식에서는 원본증거, 포렌식 복제본, 분석용 작업본, 파생자료를 구분하고 Hash와 Chain of Custody를 관리하는 것이 중요하다.

2. ‘접근’과 ‘유출’을 구분해야 한다

개인정보 사고에서 가장 흔한 오류 가운데 하나는 대량조회 사실이 확인되면 곧바로 모든 정보가 외부로 유출됐다고 판단하는 것이다. 그러나 고객정보에 접근한 것과 외부로 데이터를 반출한 것은 다른 사실이다. 금융범죄 대응 AI GPT는 개인정보 사고를 다음과 같은 Privacy Kill Chain으로 분석한다.

P0 Exposure → P1 Initial Access → P2 Privilege/Discovery → P3 Data Access → P4 Mass Acquisition → P5 Collection → P6 Staging → P7 Exfiltration → P8 Disclosure/Abuse

예를 들어 공격자가 고객 DB에서 30만 건을 조회했다는 로그가 확인됐다고 하더라도 그것만으로 30만 건이 외부로 유출됐다고 확정할 수는 없다. DB Query가 있었는지, Export가 있었는지, 파일이 생성됐는지, 압축됐는지, 서버 내 특정 위치에 Staging 됐는지, 실제 외부 IP·Cloud·메일·USB 등으로 전송됐는지를 단계적으로 확인해야 한다. 따라서 사고보고서에는 적어도 다음 세 가지가 구분돼야 한다.

• 확인된 접근범위
• 확인된 다운로드·Export 범위
• 확인된 외부전송 범위

이 세 항목이 동일하지 않을 수 있다.

3. 핵심계정계만 보면 사고를 놓칠 수 있다

이번 사고가 주는 또 하나의 중요한 시사점은 공격대상이 반드시 은행의 핵심 계정계일 필요가 없다는 점이다. 대출모집인 시스템, CRM, ODS, 직원용 웹서비스, 콜센터, 관리자 Console, 개발·운영지원 시스템, 외부 위탁업체 시스템에도 고객정보가 존재할 수 있다. 금융범죄 대응 AI GPT에서는 이러한 Core와 Non-Core 시스템을 모두 동일한 Attack Surface로 관리한다. 따라서 금융회사는 다음 질문에 답할 수 있어야 한다.

• 우리 회사 고객정보가 존재하는 시스템은 모두 몇 개인가.
• 외부 인터넷에서 접근 가능한 시스템은 무엇인가.
• 누가 관리자 권한을 갖고 있는가.
• 외주업체가 접근할 수 있는 시스템은 무엇인가.
• 대량조회·다운로드가 가능한 계정은 누구인가.
• 계약이 종료된 외주직원의 계정이 남아 있지는 않은가.
• 공용계정이나 MFA가 적용되지 않은 관리자 계정은 없는가.

이번 사고를 계기로 금융회사들은 핵심계정계 중심의 방어에서 벗어나 고객정보가 존재하거나 접근 가능한 모든 시스템을 Attack Surface Inventory로 관리할 필요가 있다.

4. 공격 IP 하나만으로 공격자를 확정해서는 안 된다

침해사고 조사에서는 IP, 계정, Device가 중요한 단서가 된다. 그러나 특정 계정에서 공격행위가 발생했다고 해서 그 계정의 명의자가 실제 공격자라고 단정할 수는 없다. 계정탈취, 공용계정, Credential 공유, VPN, Proxy, 자동화 시스템 등이 존재할 수 있기 때문이다. 따라서 실제 행위자를 확인하려면 다음 정보를 함께 분석해야 한다.

Credential → Session → Device → IP → Privilege → System → Dataset → Query → Export

특히 관리자 계정이 사용됐다면 권한이 언제 부여됐는지, 누가 부여했는지, 어느 Device와 IP에서 사용됐는지, 해당 시간에 실제 사용자가 어디에 있었는지까지 확인해야 한다.

5. ‘AI 해킹’ 여부도 증거 중심으로 판단해야 한다

이번 금융권 침해사고에서는 AI를 활용한 공격 가능성이 제기됐다. 그러나 “AI 공격 가능성을 배제할 수 없다”는 표현과 “AI가 공격했다”는 표현은 다르다. AI 활용 여부를 검증하려면 공격 속도와 반복성, 자동화된 Payload 생성 흔적, 대량 Endpoint 탐색, API 호출 패턴, 공격도구 로그 등 기술적 증거가 필요하다. 금융범죄 대응 AI GPT에서는 이러한 주장을 다음과 같이 구분한다.

• CONFIRMED — 객관적인 자료로 확인
• SUPPORTED — 복수의 자료가 뒷받침
• INDICATIVE — 정황상 가능성 존재
• UNVERIFIED — 추가 확인 필요

AI 공격 여부도 이 같은 증거수준으로 표현해야 한다.

6. 사고가 끝난 뒤에는 ‘2차 금융범죄’가 시작될 수 있다

개인정보가 유출된 사고는 시스템 복구로 끝나지 않는다. 유출된 정보가 보이스피싱이나 스미싱, 계정탈취, 명의도용, 부정대출 등에 사용될 가능성이 있기 때문이다. 금융범죄 대응 AI GPT에서는 사고 이후 위험을 다음과 같은 연쇄로 분석한다.

Data Leak → Identity Theft → Synthetic Identity → Account Takeover → Unauthorized Transfer → Fraudulent Loan·Card Fraud → Mule Account → Money Laundering

따라서 침해사고 이후 FDS와 AML 시스템도 함께 강화해야 한다. 예를 들어 고객에게 다음과 같은 이벤트가 연속적으로 나타난다면 하나의 Case로 묶어 분석할 필요가 있다.

연락처 변경 → 비밀번호 변경 → 신규 Device 등록 → 이체한도 상향 → 신규 수취인 등록 → 고액이체

각 이벤트를 개별 Alert로만 처리할 경우 실제 계정탈취를 놓칠 수 있다.

7. ‘왜 Alert가 있었는데도 사고를 막지 못했는가’를 조사해야 한다

침해사고 조사는 공격자가 무엇을 했는지만 조사해서는 충분하지 않다. 금융회사 내부에서 위험신호가 발생했지만 이를 놓쳤거나 Alert가 반복적으로 해제됐는지도 확인해야 한다. 금융범죄 대응 AI GPT에서는 Alert Closure와 Override 자체도 조사대상으로 관리한다. 예를 들어 다음과 같은 경우다.

• 동일 관리자가 다수 Alert를 반복적으로 해제했다.
• 고위험 Alert가 발생한 직후 별다른 조사 없이 종료됐다.
• 고객 설명만으로 Alert가 종료됐다.
• 동일 계정에서 같은 유형 Alert가 반복됐지만 Case로 묶이지 않았다.
• 사고 발생 후 과거 로그를 확인했더니 이미 여러 차례 이상신호가 존재했다.

이러한 상황은 단순한 보안사고가 아니라 탐지·모니터링 통제 실패일 수 있다.

8. 외주업체와 개발사 계정도 같은 수준으로 조사해야 한다

금융회사의 공격표면에는 외주업체와 개발사도 포함된다. 특히 다음 구조를 추적해야 한다.

Vendor → Contract → Employee → Credential → Privilege → Device → IP → System → Customer Data

계약은 종료됐지만 계정이 남아 있거나, 개발자가 Production DB에 직접 접근하거나, 공용계정을 이용하거나, MFA 없이 관리자 권한을 사용하는 환경은 중요한 통제취약점이 될 수 있다.

9. 사고 원인을 ‘직원 교육 부족’으로 끝내서는 안 된다

사고조사 이후에는 Root Cause를 찾아야 한다. 금융범죄 대응 AI GPT는 원인을 People, Process, Technology, Governance, Control, Data, External 등으로 구분한다. 예를 들어 사고의 직접원인은 외부 공격자의 계정탈취일 수 있다. 하지만 근본원인은 다음과 같은 통제실패의 결합일 수 있다.

• MFA 미적용.
• 관리자 권한 과다.
• 외주계정 미회수.
• 대량 Export 통제 부재.
• 로그 수집 사각지대.
• Alert 반복 해제.
• 취약 시스템 장기간 방치.

이런 사고를 단순히 “보안교육 강화”로 마무리해서는 재발방지가 어렵다. 개선조치는 다음 구조로 관리하는 것이 바람직하다.

Finding → Root Cause → Action → Owner → Due Date → Completion Evidence → Validation → Sustainability

그리고 시스템을 수정했다는 사실과 통제가 실제로 작동한다는 사실도 구분해야 한다.

IMPLEMENTED ≠ VALIDATED

금융회사 침해사고 발생 후 24시간 대응표

사고 인지 직후부터 초기 24시간 동안은 다음 업무를 우선할 수 있다.

0~1시간

• 침해 가능 계정·Session 식별.
• Active Exfiltration 여부 확인.
• 관리자 침해 여부 확인.
• 관련 Incident Team 가동.
• 필요한 범위의 접근 및 외부전송 차단.
• 로그 순환삭제 방지.

1~4시간

• IAM·MFA·PAM 로그 확보.
• DB Query·Export 로그 확보.
• EDR·Network·DLP·Cloud·Email 로그 보존.
• 고객정보 접근범위 잠정 산정.
• 공격계정·Device·IP·System 관계분석.
• 사건 Master Timeline 생성 시작.

4~8시간

• Access·Query·Export·Staging·Exfiltration 여부 구분.
• 영향 Dataset과 정보주체 범위 분석.
• 동일 IOC·Credential·Device가 다른 시스템에도 존재하는지 확인.
• Vendor·외주계정 확대 조사.
• 유사 시스템에 대한 긴급 Hunt 실시.

8~12시간

• 고객피해 가능성 평가.
• ATO·명의도용·보이스피싱·부정대출 관련 FDS Rule 강화 검토.
• 경영진 초기보고.
• 법무·준법·개인정보보호 조직을 통한 신고·통지 의무 검토.
• 필요한 경우 외부 포렌식 지원 검토.

12~24시간

• 잠정 침해범위 작성.
• Master Timeline 업데이트.
• Evidence Matrix 작성.
• 공격경로 가설 및 반대가설 정리.
• 추가 피해고객 탐색.
• Control Failure 초기분석.
• 감독기관 대응자료 준비.
• 24시간 이후 조사계획 수립.

금융범죄 대응 AI GPT를 어디에 활용할 수 있나

이 과정에서 AI GPT가 금융회사의 판단이나 시스템 운영자를 대신하는 것은 아니다. 대신 방대한 사고자료를 구조화하는 역할을 할 수 있다. 예를 들어 로그와 거래자료가 제공되면 사건 Timeline을 재구성하고, 여러 Alert를 하나의 Case로 묶으며, 계정·Device·IP·Dataset 사이의 관계를 분석할 수 있다. 사고보고서와 Evidence Matrix, 증거목록, 조사질문서, 경영진 보고자료, 감독기관 대응자료, Root Cause 보고서, 재발방지계획도 동일한 사실기반에서 작성할 수 있다.

핵심은 AI가 범죄자를 판정하는 것이 아니다. 사실과 추정을 나누고, 흩어진 증거를 연결하고, 확인되지 않은 내용을 확인된 사실처럼 표현하지 않도록 통제하면서 사람이 더 빠르고 정확하게 사고를 조사하도록 지원하는 것이다. 이번 금융권 침해사고는 금융회사의 사이버보안에서 한 가지 중요한 질문을 던지고 있다. “우리의 핵심시스템은 안전한가”만 물어서는 충분하지 않다. 앞으로는 다음 질문까지 답할 수 있어야 한다.

• 우리 고객정보는 어디에 존재하는가.
• 누가 접근할 수 있는가.
• 누가 대량으로 가져갈 수 있는가.
• 실제로 누가 접근했는가.
• 파일로 만들어졌는가.
• 어디로 이동했는가.
• 왜 탐지하지 못했는가.
• 그리고 유출된 정보가 다음 금융범죄에 사용되고 있지는 않은가.

이 질문에 얼마나 빨리 답할 수 있느냐가 AI 시대 금융회사의 새로운 사고대응 능력을 결정할 가능성이 크다.

필자 소개

만리풍취 정연태는 전문지식 AI 기획·설계자이자 GPT 개발 전문가이다. 미국 스티븐스공과대학교 대학원에서 수학한 뒤 정보통신기업과 공공기관, 기업경영 및 산업정책 현장에서 활동해 왔다. 현재 재단법인 건설산업정보원 원장으로 재직하며, 건설·법률·세무·금융·경영·의료·과학·역사·철학 등 54개의 전문지식 GPT를 개발했다. 온톨로지와 XAI, OXMV Loop 및 Evidence Ledger를 결합해 AI의 오류를 줄이고 인간의 책임 있는 판단을 지원하는 검증형 전문지식 AI 체계를 연구하고 있다.

영문판 보기