[전문가 인사이트] AI가 바꾼 공격 판도, 금융보안의 대응 전략

최근 국내 주요 은행들이 연달아 해킹 공격을 받으면서 금융권 전체가 큰 충격에 빠졌습니다. 일부 금융사에서는 고객 정보 유출로 이어졌고, 공격 차단에 성공한 곳들 역시 놀란 가슴을 쓸어내려야 했습니다.

금융결제원과 금융보안원 등에서 보안관제와 침해위협 분석 업무를 수행했던 경험에 비추어 볼 때, 이번 사고에서 특히 주목해야 할 지점은 공격의 방향입니다. 공격자들은 견고하게 구축된 인터넷뱅킹이나 핵심 거래 시스템만을 정면으로 노리지 않았습니다. 대신 직원용 모바일 업무지원, 영업지원, 대출모집인용 조회 서비스처럼 방어자의 시야에서 한발 비켜나 있던 주변 시스템을 파고들었습니다.

10년 전이나 지금이나 공격자가 노리는 구간 자체가 완전히 달라진 것은 아닙니다. 달라진 것은 그 구간을 찾아내고, 분석하고, 실제 공격 가능성을 확인하는데 필요한 비용과 난이도입니다. LLM을 비롯한 AI 기술과 다양한 공격·침투 도구가 빠르게 발전하면서 공격자는 더 넓은 공격 표면을 더 짧은 시간에 탐색하고 분석하고 공격 가능성을 시험할 수 있게 됐습니다.

과거에는 숙련된 공격자가 상당한 시간과 노력을 들여야 했던 작업의 일부를 이제는 기계가 빠른 속도로 반복할 수 있습니다. 즉, 바뀐 것은 공격 대상만이 아니라 Attack Economics, 공격의 경제성입니다.

그동안 보안은 비용과 속도 같은 현실적인 제약 때문에 중요한 자산을 선별하고 깊게 점검하는 방식으로 운영되어 왔습니다. 합리적인 선택이었습니다. 문제는 상대적으로 중요도가 낮다고 판단해 적은 노력으로 관리해온 수많은 자산입니다.

“설마 여기가 문제가 되겠어?”
“이 정도면 괜찮겠지?”

이런 자산들은 조직 전체에 넓게 흩어져 있고 가시성도 낮습니다. 하지만 침투가 발생하면 계정과 세션, 내부 API와 신뢰 관계를 따라 내부 시스템 접근이나 데이터 유출로 이어질 수 있습니다.

그동안 방어자에게는 관리 우선순위 밖의 Long Tail이었던 수많은 자산이, 자동화된 공격자에게는 더 이상 Long Tail이 아닐 수 있습니다.

오늘날의 금융 서비스는 고객 접점인 앱·웹에서 출발해 WAF, API 게이트웨이, 인증·세션, 내부 API를 거쳐 핵심 DB에 도달합니다. 그 사이에는 SaaS, 클라우드, AI, 협력사 외주 서비스가 촘촘하게 연결되어 있습니다. 수천 개의 기능과 수천만 줄에 달하는 코드를 제한된 수의 보안 담당자가 24시간 빠짐없이 눈으로 살피는 것은 이미 물리적인 한계를 넘어섰습니다.

이제는 ’중요한 곳을 얼마나 깊게 점검할 것인가’만큼 ’얼마나 넓은 영역을 지속적으로 검증할 수 있는가’가 중요해지고 있습니다.

기계의 속도 vs 사람의 검증: ’캐노피 갭’의 경고

숫자는 이 불균형을 더 선명하게 보여줍니다. CrowdStrike의 분석에 따르면 공격자가 최초 침투 후 내부 횡이동(Lateral Movement)을 시작하기까지 관측된 최단 시간은 단 51초였습니다. Netacea 역시 기업의 93%가 매일 AI 기반 공격에 직면할 것으로 전망했습니다.

공격과 탐지는 이미 기계의 속도로 움직이고 있는데, 방어자는 쏟아지는 알림 속에서 진짜 위협을 선별하고, 재현하고, 개발팀에 전달해 패치한 뒤 재검증하는 과정을 여전히 사람의 속도로 처리하는 경우가 많습니다.

이 기계 속도의 발견과 사람 속도의 검증 사이에서 발생하는 방어 역량의 격차를 ’캐노피 갭(Canopy Gap)’이라고 볼 수 있습니다.

이 간극은 단순히 스캐너를 더 많이 돌리고 취약점을 더 많이 찾는 것만으로는 메워지지 않습니다.

엔트로픽의 Claude Mythos Preview가 오픈소스 프로젝트 281개에서 1,596건의 취약점을 찾아냈을 때, 외부 보안 리서치 펌 6곳이 검증에 참여했지만 실제 패치까지 이어진 것은 약 6%였습니다. 발견이 기계의 속도로 빨라질수록 병목은 ’검증’과 ’조치’로 이동합니다. 검증되지 못한 수많은 탐지 결과는 그대로 보안 부채로 쌓이게 됩니다.

보안팀에게 이미 부족하지 않은 것이 하나 있다면 Alert입니다.

AI를 이용해 취약점 후보를 몇 배 더 많이 찾아낸다고 해서 그 자체로 조직이 몇 배 더 안전해지는 것은 아닙니다. 앞으로 필요한 것은 더 많은 Finding이 아니라, 실제 공격 가능한 위험을 더 빠르게 구분하고 제거하는 능력입니다.

공격자가 더 넓은 영역을 더 낮은 비용으로 탐색할 수 있게 됐다면, 방어자 역시 더 넓은 영역을 더 낮은 비용으로 지속적으로 검증할 수 있어야 합니다.

규제와 감사 의무, 고객 신뢰를 동시에 지켜야 하는 금융권이 이 격차를 줄이기 위해 필요한 세 가지 실전 전략을 살펴보겠습니다.

1. 경계 허물기: 계정·데이터·실행 경로 중심의 ‘공격 표면’ 재정의

IP나 URL 목록만으로 방어선을 구축하던 방식만으로는 충분하지 않습니다. 주변부 시스템까지 공격의 시작점이 될 수 있는 환경에서는 방어자가 먼저 서비스의 연결 상태를 입체적으로 파악해야 합니다.

• 세션 탈취 시 도달 범위: 특정 토큰이나 세션이 탈취되었을 때 내부 어디까지 도달 가능한가?

• 권한 오남용 위험: 인증된 사용자가 타인의 데이터나 관리자 권한에 무단 접근할 수 있는가?

• 서드파티 권한 이행: 협력사 계정이나 연동 SDK의 권한이 내부 핵심 서비스까지 연결되어 있지는 않은가?

공격 표면은 단순한 네트워크 경계가 아닙니다. 계정(Identity), 데이터(Data), 신뢰 관계(Trust), 실행 경로(Execution Path)가 복합적으로 연결된 생태계입니다.

방어자는 노출 자산과 연결 경로를 지속적으로 파악하고, 공격자의 관점에서 실제 침투 가능성을 먼저 검증해야 합니다.

공격자가 할 법한 행위를 방어자가 먼저, 더 자주 실행하는 것.

이것이 넓어진 공격 표면에 대응하는 중요한 방어 방식입니다.

2. 비결정적 AI를 단단하게 매듭짓는 ‘하네스(Harness)’ 구축

ChatGPT나 Claude 같은 고성능 LLM을 사내에 들여오는 것만으로 보안 문제가 해결되지는 않습니다. AI는 본질적으로 비결정적이며, 동일한 입력에도 다른 결과를 만들 수 있고 때로는 잘못된 조치 코드를 제시할 수도 있습니다.

따라서 AI가 금융사의 보안 정책, 실행 환경, 감사 기준 안에서 일관되게 검증을 수행하도록 통제하는 운영 체계, 즉 하네스(Harnessing)가 필요합니다.

하네스는 관념적인 개념이 아니라 매우 실무적인 작업입니다.

• 규칙 파일의 계층화: 에이전트 행동 지침(AGENTS.md)을 전사 공통-도메인-모듈 단위로 세분화하여 상속

• AI 리더블(Machine-Readable) 문서화: 사내 보안 표준과 정책을 AI가 정확히 이해할 수 있는 구조화된 문서로 변환

• 역할 분담 및 격리 환경: 분석, 공격 재현, 패치 제안 등 역할별 에이전트를 분리하고, 코드를 빌드·실행하는 환경은 격리된 샌드박스로 운영

실제로 티오리가 참가했던 미국 DARPA 주최 AI 사이버 챌린지(AIxCC)에서도 핵심은 단일 모델의 성능만이 아니라 모델이 실제 보안 업무를 수행할 수 있도록 만든 하네싱 시스템이었습니다.

5,400만 줄 규모의 코드베이스를 대상으로 티오리의 AI 검증 시스템 Xint는 주최 측 출제 취약점의 86%를 탐지했고, 주최 측도 몰랐던 제로데이 취약점 18개를 추가로 발견했습니다. 탐지에서 재현, 패치, 재검증까지 이어지는 과정은 평균 45분이었습니다.

중요한 것은 AI가 단순히 더 많은 취약점을 찾았다는 사실만이 아닙니다. 발견한 문제를 실제로 검증하고, 조치하고, 다시 확인하는 전체 루프를 얼마나 빠르고 반복 가능하게 만들 수 있는가입니다.

3. 실증적 PoV(Proof of Vulnerability)와 감사 가능한 증적 확보

기존 보안 도구가 만들어낸 수많은 탐지 결과를 실제 조치로 연결하는 과정에서는 여전히 많은 시간이 필요합니다. 실행 맥락이 부족한 탐지 결과는 오탐 여부와 실제 위험도를 다시 사람이 판단해야 하기 때문입니다.

AI 기반 검증 체계는 취약점 후보가 탐지되었을 때 단순히 또 하나의 Finding을 만드는 데서 끝나지 않고 다음 단계까지 연결되어야 합니다.

1. 도달 가능성(Reachability) 검증: 외부 입력값이 해당 취약 코드까지 실제로 도달할 수 있는지 실행 경로 추적

2. 공격 재현(PoV): 격리된 샌드박스에서 실제 공격 재현 코드(PoV)를 실행해 악용 가능성 입증

3. 패치 및 회귀 테스트: 최소한의 패치 코드를 생성해 공격이 차단되는지, 기존 정상 기능에 영향이 없는지 확인

4. 증적 보존 및 인계: 판단 근거, 호출 로그, 재현 결과를 증적 패키지로 보존하고 중요한 변경과 패치 승인은 사람이 결정

기존의 탐지를 AI로 대체하는 것이 핵심은 아닙니다. 기존 탐지가 찾아낸 결과에 Context, Execution, Evidence를 더해 실제 악용 가능성을 확인하는 방향으로 검증 체계를 확장해야 합니다.

개발팀에게 “이 코드가 위험할 수 있다”는 추상적인 리포트를 전달하는 대신, “실제 도달 가능한 경로와 샌드박스에서 재현된 공격 로그, 검증된 조치 결과”를 함께 전달할 수 있어야 합니다.

결국 보안 검증은 단순한 Finding 생성에서 끝나는 것이 아니라,

Discover → Validate → Triage → Remediate → Retest → Evidence

라는 지속적인 루프로 이어져야 합니다.

4. 데이터 분류와 Foundation, 그리고 리스크 번다운(Risk Burn-down)

이러한 검증 체계를 실제 금융 환경에 안착시키려면 데이터 처리 통제와 실행 기반이 함께 준비되어야 합니다.

많은 조직이 “어떤 AI를 사용할 것인가”부터 고민하지만, 실제 보안 업무에 AI를 연결하기 전에 먼저 답해야 할 질문들이 있습니다.

어떤 데이터를 AI에게 보여줄 수 있는가?
어떤 모델과 서비스가 승인되어 있는가?
데이터는 어디로 나가는가?
AI가 생성한 코드와 공격은 어디에서 실행할 것인가?
그 과정과 결과를 어떻게 기록하고 감사할 것인가?

이를 위해 승인된 AI 접근 경로와 Gateway, 데이터 분류 체계, Egress 통제, Identity와 Secret 관리, 요청·응답에 대한 Observability, 그리고 AI가 생성한 코드나 공격을 안전하게 실행할 Sandbox와 격리 환경 같은
Foundation이 필요합니다.

특히 모든 데이터를 하나의 정책으로 처리해서는 안 됩니다. 공개 소스와 일반적인 코드 패턴, 내부 비즈니스 로직과 아키텍처 정보, 개인정보와 개인신용정보, 인증정보와 Secret은 민감도와 목적에 따라 서로 다른 통제 수준을 적용해야 합니다.

기존의 질문이 “우리 데이터가 외부로 나가는가?”였다면, 앞으로는 “어떤 데이터가, 어떤 목적으로, 어떤 모델에서, 어떤 통제 아래 처리되는가?”까지 확인해야 합니다.

격리는 여전히 중요한 통제입니다. 동시에 필요한 보호 수준을 유지하면서 외부의 강력한 AI 역량을 통제된 방식으로 활용할 수 있는 능력 역시 하나의 보안 역량이 됩니다.

성과 지표 역시 함께 바뀌어야 합니다.

“취약점 수천 개 탐지”만으로는 실제 보안 수준의 개선을 설명하기 어렵습니다. 앞으로 중요한 KPI는 자동화된 검증을 통해 악용 가능성이 입증된 잔여 리스크를 얼마나 빠르게 줄여나가는가, 즉 Risk Burn-down입니다.

발견 건수보다 실제 공격 가능한 위험이 얼마나 줄어들고 있는지를 측정해야 합니다.

5. 첫 출발: 단 하나의 핵심 서비스에서부터 증명하라

모든 시스템을 한 번에 바꾸는 빅뱅 방식의 전환은 현실적이지 않습니다.

가장 효과적인 접근법은 결제나 인증처럼 비즈니스 파급력이 큰 단 하나의 핵심 서비스를 선정해 90일 단계별 로드맵을 적용해 보는 것입니다.

• 1~30일 (Define): 대상 서비스와 핵심 경로 3~5개를 정합니다. 데이터 분류, 승인된 AI 활용 경로, 증적 기준선, 사람이 승인할 경계를 정의합니다.

• 31~60일 (Validate): 기존 탐지 결과를 보강해 도달 가능성과 악용 가능성을 실증합니다. 오탐과 백로그 규모를 측정하고, 재현 근거를 담은 증적 패키지를 만듭니다.

• 61~90일 (Operate): 패치 제안, 회귀 테스트, 재검증을 실제로 운영합니다. 조치 시간과 Risk Burn-down을 측정하고 확대할지, 조정할지 결정합니다.

이렇게 한 서비스에서 효과가 확인된 운영 모델을 기준으로 삼으면 다른 서비스로 넓혀갈 때도 동일한 통제와 검증 기준을 적용할 수 있습니다.

자동화 역시 처음부터 모든 것을 맡기는 방식보다는 단계적으로 범위를 넓혀가는 것이 현실적입니다.

Foundation → Finding Enrichment → Reachability → PoV Validation →
Patch Proposal & Approval → Controlled Automation

AI가 어디까지 할 수 있는가보다 조직이 어디까지 통제하고 책임질 수 있는가를 기준으로 자동화의 범위를 결정해야 합니다.

마치며

사람의 눈과 수작업만으로 24시간 모든 공격 표면을 지켜낼 수 있다는 전제는 이제 현실적으로 유지하기 어렵습니다.

공격자가 노리는 구간 자체가 완전히 달라진 것은 아닙니다. 달라진 것은 그 구간을 찾아내고 공격 가능성을 확인하는 데 필요한 비용과 속도입니다.

AI와 자동화는 공격자가 더 넓은 공격 표면을 더 낮은 비용으로 탐색할 수 있게 만들고 있습니다. 그렇다면 방어자 역시 같은 방향으로 비용 구조를 바꿔야 합니다.

중요한 자산을 깊게 보호하는 것은 여전히 필요합니다. 하지만 그것만으로는 충분하지 않습니다.

사람이 모두 살펴보기 어려웠던 넓은 공격 표면을 지속적으로 검증하고, 실제 공격 가능한 위험을 증명하고, 수정하고, 다시 확인할 수 있어야 합니다.

AI 시대의 금융보안 경쟁력은 단순히 더 많은 취약점을 찾아내는 데 있지 않습니다.

더 넓은 영역을, 더 자주, 실제 공격자의 관점에서 검증하고 그 위험을 지속적으로 줄여나갈 수 있는 운영 능력이 중요해지고 있습니다.

공격의 경제성은 이미 변하고 있습니다.

이제 방어의 경제성도 바뀌어야 합니다.

공격이 자동화된 만큼 점검도 자동화해야 합니다.

공격의 자동화 수준이 높아지는 만큼, 방어 측에서도 점검 속도와 범위를 함께 넓히는 것이 중요합니다.

티오리의 AI 모의해킹 플랫폼 Xint는 점검 대상을 등록하면 자동으로 보안 검증을 수행하고, 잠재적인 취약점 탐지에 그치지 않고 실제 악용 가능성까지 확인해 결과를 제공합니다. 이를 통해 제한된 보안 인력으로도 그동안 관리가 어려웠던 비주력 서비스나 외부 노출 자산까지 동일한 기준으로 지속적으로 점검하실 수 있습니다.

[Xint가 더 궁금하다면]

📩 최신 보안 인사이트 받아보기

Xint 팀이 분석한 취약점 연구와 최신 보안 인사이트를 이메일로 가장 먼저 받아보세요.

[이메일 뉴스레터 구독하기]

문의: contact@xint.io

웹사이트: xint.io