TTESays

주기적인 모의해킹/취약점 점검과 반복되는 사고

Donghwi Shin

Published: 15:56, 05 Nov 2025 (Updated: 02:02, 12 Nov 2025)

💡

Editor Pick
- 2025년 보안 사고의 증가는 ‘사건의 폭증’이 아니라 ‘탐지·보고 역량의 향상’일 가능성
- 반복되는 취약점 문제는 모의해킹을 형식적으로 수행하고 결과를 단순 패치로만 처리하는 관행에서 비롯
- 진정한 해결책은 취약점의 Exploit·파급력·근본 원인까지 가시화
- PTaaS, Git·이슈 트래커로 라이프사이클을 연동해 지속적으로 추적

2025년, ‘사건’이 늘어난 게 아니라 ‘발견’이 늘어난 것이다 — 취약점 관리의 근본을 묻다

2025년 들어 침해·정보유출 사건 소식이 잇따르고 있다. 통신사, 카드사, 플랫폼 등 다양한 영역에서 개인정보 유출, 서비스 가용성 저하, 불법 결제 사고가 보도되며 보안에 대한 관심도 증가했지만 담당자들의 부담도 커졌다. 물론 이와 같은 관심이 꾸준한 투자와 발전으로 이어지면 좋겠지만 사실 꾸준히 이어지지 못하는 것이 우리의 현실이다.

많은 사고 발생과 대응의 관점으로 돌아와서, 현 시점에 중요한 질문은 “왜 사고가 급증했는가”가 아니라 “우리는 무엇을 발견하고 어떻게 대응해왔는가”다. 즉, 2025년에 이전보다 더 많은 공격이 새로 생겼을 가능성도 있지만, 기존에 존재했으나 식별하지 못했던 문제들을 올해 더 많이 찾아냈을 가능성도 크다. 그렇다면 이렇게 많은 위협이 도사리고 있었다는 뜻인데, 이렇게 된 이유가 무엇인지 생각해봐야 한다.

모의해킹과 취약점 점검 — 형식적 수행으로 끝나는 일회성 관행

많은 기관이 보안성 강화를 위해 연례(또는 필요 시) 모의해킹, 취약점 진단을 의무적으로 수행한다. 예컨대 전자금융감독규정 제37조 2항은 인력 300인 이상 금융사·전자금융업자에게 연 1회 이상 취약점 분석·평가를 요구한다. 규정에는 ‘어떻게’보다는 ‘횟수’가 명시되어 있어, 형식적으로 연 1회만 수행하면 요건을 충족할 수 있다는 해석을 내놓을 수 있다. 비용과 효율을 중시하는 경영진 입장에서는 ‘최소 비용으로 규제 요건 충족’이 합리적 선택처럼 보이기도 한다.

문제는 여기서 끝나지 않는다. 모의해킹 결과를 단순히 ‘취약점 목록 → 패치’의 순서로 처리하면 표면적인 문제만 제거할 뿐, 근본 원인과 재발 방지로 이어지지 않는다. 많은 조직이 ‘결과(패치 완료)’만 보고 활동을 마무리한다. 이는 보안 활동을 ‘증명’을 위한 절차로 전락시키고, 동일하거나 유사한 취약점이 반복 발생하는 구조를 고착시킨다.

💡

위 지적을 “보안 담당자의 문제로 전락시켜 누군가가 문제였다.”로 만들지 않아야 한다. 그들은 항상 없는 예산과 자원을 가지고 열심히하려고 노력한다. 문제는 한 사람 한 사람이 아닌 우리 모두의 방향성과 방향이 그렇게 설정될 수 밖에 없는 배경에 있다.

핵심 문제 — 가시성의 부재와 깊이 있는 분석의 결여

현실에서 가장 큰 약점은 ‘가시성’의 부족이다. 단순히 몇 건의 취약점이 발견되었는지, 혹은 쉬운(저등급) 취약점만 나왔다는 정성적 평가만으로는 충분치 않다. 진짜 필요한 가시성은 다음과 같다.

취약점의 구체적 Exploit 방법과 실제 악용 시나리오
해당 취약점이 서비스 전체에서 갖는 파급력(권한 상승, 데이터 노출 범위 등)
취약점 발생의 근본 원인(특정 코드·아키텍처·개발·운영 관행 등)
취약점 간 연계 가능성 — 여러 취약점을 조합 했을 때의 위협

대부분 조직은 취약점 하나하나를 독립적인 ‘수리’ 대상으로 판단한다. 마치 기계가 고장났으면 문제가 어딘지 보고 당장 드러나는 문제점만을 찾아 수리하고 당장 잘 동작하기만 하면 문제가 끝났다고 생각하는 것과 같다. 그러나 SQL 인젝션 하나가 단독으로 끝나는 경우는 드물다. 정보 수집 → 인증 우회 → 권한 획득 → 권한 탈취·금융사기 등으로 이어질 수 있다. 따라서 취약점은 ‘패치’ 이전에, 그리고 패치와 병행하여 심도 있는 영향 분석과 악용 시나리오 설계가 필요하다. 그래야 서비스 상에 동일 취약점이 발생하더라도 취약점 이후의 상황 전개가 일어나지 않도록 차단할 수 있는 방향으로 업무를 진행할 수 있는 것이다.

규제 충족(Compliance) vs 안전한 운영(Operational Safety) — 목적의 혼동

오늘 우리 보안 관행의 많은 부분은 ‘보여주기 위한 보안’(compliance-first)에 치우쳐 있다. 규제를 충족하면 안전이 확보되는 것이 아니라, 규제는 최소한의 기준을 보장하는 도구일 뿐이다. 규제를 만족시키는 것은 출발점이지 목표가 되어선 안 된다. 특히 다음과 같은 의사결정은 위험을 키운다.

연 1회 진단을 ‘체크리스트’로 처리하고 결과에 깊이 개입하지 않음
비용 절감을 이유로 검사의 범위·깊이를 축소함
취약점 보고서를 단순 문서로 보관하고, 후속 추적·재검증을 하지 않음

💡

우리는 발생한 상황에 마법의 솔루션을 적용하면 이후 동일한 일이 발생하지 않는다고 믿는것 같다. 100원을 벌기 위해 1,000원이 필요했다면 1,000원을 벌기 위해 10,000원이 필요하다는 단편적인 논리로 접근해서는 절대 해결할 수 없는 분야가 보안이다. 효과가 큰 방향은 있지만 수학 문제의 답을 구하듯 해결책을 찾고 실행하는 것으로 문제는 해결되지 않는다. 이는 서비스가 복잡할 수록, 이것 저것 좋다니 이전에 많은 비용을 투자하여 많은 것들을 해두었다면 더욱 심할 것이다. 누구도 규제에서 언급하는 것만으로 해결되는 것이 아니라고 믿지 않을꺼라 생각하지만 직접적인 언급이 필요하다 생각한다.

해결 방향 — 가시성 확보와 ‘지속 가능한’ 취약점 관리

문제를 반복하지 않기 위한 실천적 제언은 다음과 같다.

A. 탐지 결과의 전방위 가시성 확보

취약점 탐지 후 결과 문서에 ‘취약점의 Exploit 절차, 영향 범위, 연계 가능성, 근본 원인’ 등 필수 정보를 구조화하여 기록해야 한다.
단지 ‘취약점 수’나 ‘패치 완료’가 아니라 ‘진행 상태(분석→우선순위 지정→패치→재검증→추적)’를 실시간으로 볼 수 있게 만들어 가시성을 확보해야 한다.

B. 심층 분석(Deep-dive)을 표준 프로세스로 수립

단건 취약점이 발견되면 개발·아키텍처·운영팀을 포함한 크로스펑셔널 팀이 원인분석(RCA), 파급력 분석, 시나리오 기반 위협 모델링을 수행해야 한다.
이 과정을 통해 동일한 패턴의 취약점 재발을 예방하는 설계·개발 지침을 도출.

C. 지속적 추적관리와 자동화 연계

PTaaS(Penentration as a Service) 형태의 모의해킹·취약점 관리 플랫폼과 소스코드 리포지터리(Git), 이슈 추적(예: Atlassian Jira) 등을 연동하여 취약점 발견 → 이슈 생성 → 코드 수정 → CI/CD 재검증 → 재스캔까지의 라이프사이클을 자동화하는 노력을 추진해야 한다.
단발성 리포트가 아니라 ‘이력과 메타데이터’가 남아야 동일 유형 취약점의 재발을 빠르게 탐지하고 우선순위를 정할 수 있다.

D. 조직적 관점 전환 — ‘패치’에서 ‘위협 관리’로

취약점 관리는 PMS(Patch Management System)로만 한정해서는 안 된다. 패치는 수단일 뿐이며, 목표는 ‘서비스의 안전한 운영’이다.
위협 모델링, 로그·탐지 체계, 대응 시나리오와 연계된 취약점 관리가 필요하다.

E. 경영진과 현업의 공감대 형성

보안은 비용 항목이 아니라 비즈니스 연속성을 지키는 투자임을 명확히 전달해야 한다. 이 바탕 위에 규정 준수는 기본이며, 추가적인 분석·추적·재검증을 위한 자원 배분이 필요함을 수치와 사례로 설명하고 공감대를 형성해야 한다.

결론 — “더 많이 찾은 것”을 우리의 자원으로 바꿔야 한다

2025년의 보안 소식이 유독 눈에 띄는 이유는 ‘사건 자체의 급증’일 수도, ‘탐지·보고 역량의 향상’일 수도 있다. 중요한 것은 어느 쪽이든 우리가 발견한 정보를 활용해 재발을 막고 서비스의 근본적 안전성을 높이는 체계를 만드는 것이다. 모의해킹은 끝이 아니라 시작이어야 한다. 취약점을 ‘패치 완료’로 처리하는 관행을 넘어서, 취약점의 발생 원인과 파급효과를 깊이 이해하고 조직 전반에 걸쳐 지속적으로 추적·개선하는 문화와 시스템을 구축할 때 비로소 같은 사건이 반복되지 않는 방향으로 나아갈 수 있다.