Select Language

Contact

회사소개

서비스

제품

미디어센터

채용

Contact

회사소개

서비스

제품

미디어센터

채용

Select Language

Contact

회사소개

서비스

제품

미디어센터

채용

오늘 닫기

Go to Top

보안 인사이트

매년 점검받는데, 왜 취약점은 사라지지 않을까? 취약점 점검을 받던 내가 공격자 관점에서 보니 달라진 것들

엔키화이트햇

2026. 6. 30.

Content

매년 취약점 점검을 받고 “양호” 판정을 받은 기업이더라도 레드팀 프로젝트를 수행하면 치명적인 취약점들이 발견됩니다. 취약점 점검과 실제 공격의 차이는 무엇인지 그리고 침해사고가 일어나기 전에 무엇을 점검해야 하는지 정리했습니다.

——————

지난 몇 년 사이, IT 환경은 빠르게 변했습니다. 온프레미스 중심이던 인프라가 클라우드로 옮겨 갔고, CI/CD 파이프라인을 통해 하루에도 여러번 배포가 이뤄지며, 최근에는 Cursor, GitHub Copilot 같은 AI 코딩 도구까지 개발 현장에 뛰어들었습니다. 서비스가 만들어지고 변경되는 속도는 과거와 비교할 수 없을만큼 빨라졌습니다.

문제는 그 시스템의 보안을 검증하는 방식, 즉 정기 취약점 점검의 형태는 거의 그대로라는 점입니다. 그리고 여기서 한 가지 모순이 반복적으로 확인됩니다. 매년 성실하게 점검을 받고 '양호' 판정을 받은 기업들을 대상으로 레드팀 프로젝트를 수행하면 예외없이 치명적인 취약점들이 발견됩니다. 금융, 제조, 유통, 헬스케어, 이커머스, 공공 등 업종을 가리지 않습니다. 특히 가장 엄격하게 규제받고 가장 자주 점검받는 금융권조차 예외가 아니었습니다. 가장 촘촘하게 검증받는 곳에서도 이런 결과가 나온다면 점검 빈도가 낮은 다른 업종들은 더 말할 것도 없습니다.

이 글은 방어자와 공격자의 자리에서 모두 들여다본 저의 경험입니다. 다만 목적은 현상을 설명하는데 있지 않습니다. 정기적으로 받는 취약점 점검이 구조적으로 무엇을 놓치고 있는지, 그리고 무엇보다 같은 자리에 서있는 보안 담당자가 지금 무엇을 바꿔야 하는지 말씀드리려 합니다. 한때 점검을 받던 제가 이제는 공격하는 사람으로서 최대한 솔직하게 작성했습니다.

방어자였던 나는 체크리스트를 채웠고, 공격자가 된 지금은 진짜 취약점을 찾습니다.

이 간극을 누구보다 잘 아는 이유는 제가 한때 점검을 받는쪽에서 일했기 때문입니다. 그리고 솔직히 말씀드리면 그 시절의 저는 “증빙”하기에 바빴습니다. 이 이야기를 꺼내는 이유는 지난 일을 고백하기 위해서가 아닙니다. 지금, 같은 자리에 있는 많은 보안 담당자가 어쩌면 같은 선상에 있을지 모르기 때문입니다.

방어자의 하루는 취약점이 아니라 체크리스트로 채워집니다.

금융권 보안 담당자 시절 제 하루를 채운것은 시스템을 깊이 들여다보며 취약점을 찾아 고치는 일이 아니었습니다. 상위 기관에서 내려보낸 점검용 체크리스트를 한 항목씩 만족시키고, 그 근거가 될 문서를 만들고, 부서마다 흩어진 자료를 취합해 기한 안에 제출하는 일이었습니다. 보안 업무라기보다 보안을 “증빙”하는 업무에 더 가까웠습니다.

그러나 이것은 개인의 게으름이 아니라 평가 기준의 문제입니다. 조직의 윗사람도, 그 위의 상위 기관도, 보안 담당자에게 던지는 첫 질문은 "얼마나 심각한 취약점을 찾아냈는가?"가 아닙니다. "점검용 체크리스트를 모두 만족시켰는가?"가 언제나 먼저입니다. 평가가 그렇게 매겨지면 일하는 방향도 그렇게 연결됩니다. 모든 항목에 “양호”를 받아내는 것이 목표가 되고, 진짜 공격자가 이 시스템을 노린다면 어디로 들어올까?라는 질문은 늘 뒤로 밀립니다. 점검을 통과하기 위한 일과 실제로 안전해지기 위한 일은 같지 않은데 조직이 보상하는 것은 늘 전자입니다.

혹시 지금 이 글을 읽는 여러분의 하루도 이와 크게 다르지 않습니까? 그렇다면 그것은 보안담당자 개인의 문제가 아니라 여러분이 놓인 평가 구조의 문제이고 바로 그 구조야말로 공격자가 가장 반기는 환경입니다.

레드팀은 짜여진 형식을 걷어내고 오직 치명적인 취약점을 찾아내는 것입니다.

레드팀의 자리에 오니 모든 것이 반대였습니다. 채워야 할 체크리스트도, 제출용으로 보기 좋게 정리해야 할 표도, 형식을 맞추기 위한 문서도 없습니다. 인가된 범위 안에서 제 일은 단 하나로 압축됩니다. 무슨 수를 써서라도 실제 크리티컬한 취약점을 찾아내는 것. 방어자 시절 저를 묶어두던 온갖 제약과 형식이 사라지자 비로소 시스템의 진짜 모습이 보이기 시작했습니다.

목표가 하나로 좁혀지니 보이는 것이 달라졌습니다. 방어자 시절 제가 그토록 공들여 “양호”로 채우던 항목들 사이로 공격자는 너무나 쉽게 빠져나갔습니다. 형식을 맞추느라 쌓아둔 문서들은 실제 침투 경로 앞에 아무것도 막아주지 못했습니다. 제가 방어자 시절 가장 많은 시간을 쏟았던 바로 그 일들이 공격자에게는 가장 먼저 가장 가볍게 비켜가는 대상이었던 것입니다.

두 자리를 모두 겪고 나서야 저는 분명히 알게 됐습니다. 취약점 점검은 “체크리스트를 만족시켰는가?”를 확인하지만, 공격자는 “그래서 정말 안전한가?”를 확인합니다. 그리고 그 두 질문 사이의 거리가 매년 성실히 양호를 받는 기업에서 치명적인 취약점이 발견되는 이유입니다. 이제 그 거리가 구체적으로 어디에서 벌어지는지, 구조적으로 짚어보겠습니다.

왜 매년 점검받는데도 취약점은 사라지지 않을까요?

취약점 점검과 실제 공격은 목적도, 방식도, 시각도 다릅니다. 그 차이가 곧 점검의 빈틈입니다. 실무에서 반복적으로 확인되는 여섯가지를 짚어보겠습니다.

1. 점검 받는 범위와 실제 공격자의 범위는 다릅니다.

취약점 점검은 범위가 정해집니다. 일정이 공지되고, 대상 시스템이 합의되며, 운영에 영향을 줄 만한 민감한 자산은 종종 범위에서 제외됩니다. 점검을 안정적으로 수행하기 위한 합리적인 선택입니다.

그러나 실제 공격자에게는 그런것들이 존재하지 않습니다. 점검 대상에서 빠진 레거시 서버, 외주 개발 후 인수인계가 끊긴 시스템, 임시로 띄워두고 잊어버린 서비스, 잠시 열어 두었던 포트까지 이 모든 것이 실제 침투 경로가 됩니다. 엔키화이트햇의 레드팀 프로젝트에서도 정작 침투의 시작점이 된 자산은 취약점 점검 범위 어디에도 속해있지 않았던 경우가 많습니다. 점검은 우리가 보여주려는 곳을 보고, 공격자는 우리가 잊은 곳을 봅니다.

2. 점검은 ”체크리스트”, 공격은 “시나리오”입니다.

취약점 점검은 본질적으로 한계가 존재합니다. 알려진 취약점 목록과 시스템을 항목별로 맞춰보고 그 결과를 정리합니다.

레드팀은 항목을 채우는 것이 아니라 목표를 달성합니다. 고객 데이터 탈취, 영업기밀 접근, 결제·이체 조작, 서버 장악이라는 목표를 가지고 실제 공격자의 전술·기법·절차(TTP)를 그대로 재현하며 개별적으로는 낮음으로 판정된 취약점들을 하나의 공격으로 엮습니다. 서비스 정보가 조금 노출되는 결함, 권한 검증이 느슨한 지점, 내부망에서 불필요하게 열려있는 포트를 순서대로 연결하면 외부에서 핵심 데이터까지 도달하는 경로가 완성됩니다. 체크리스트는 구조적으로 이 조합을 찾지 못합니다. 항목 하나하나는 모두 “양호” 또는 “낮음” 이였는데 시나리오로 엮으면 “치명”이 되는 것, 이것이 점검과 공격의 가장 큰 차이입니다.

3. 점검은 한 시점이고, 공격은 지속입니다.

분기·반기 점검은 본질적으로 순간의 사진 한 장과 같습니다. 그러나 오늘날의 시스템은 하루에도 여러번 배포되고 설정이 운영중에도 조금씩 변합니다.

지난 점검과 다음 점검 사이의 긴 공백동안 생긴 업데이트와 새 자산은 사실상 무방비 상태입니다. 변화의 주기는 분 단위가 되었는데 검증의 주기는 여전히 분기 또는 반기 단위입니다. 점검 직후 추가된 API 하나, 급하게 연 방화벽 정책 하나가 다음 점검까지 수개월간 검증없이 노출되는 구조이지요. 이 간극이 치명적인 취약점이 발생하는 시작점입니다.

4. 취약점 점검은 시스템만 보고, 사람과 프로세스는 보지 않습니다.

취약점 점검은 시스템을 봅니다. 그러나 실제 침해사고의 시작점은 피싱 메일 한 통, 권한 관리가 허술한 협력업체 계정, 신뢰를 악용하는 사회공학인 경우가 많습니다.

이는 데이터로도 확인됩니다. 매년 발표되는 글로벌 침해 분석 보고서들은 침해사고의 상당수가 피싱, 도용된 자격증명, 내부자 권한 관리 미흡처럼 “사람”을 경유한다는 사실을 반복적으로 보여주고 있습니다. 그러나 이런 경로는 어떤 시큐어코딩 가이드에서도 “취약”으로 잡히지 않습니다. 레드팀은 사람, 프로세스, 시스템 모든 것을 하나의 공격 표면으로 통합해 검증합니다.

5. '막을 수 있는가'는 보지만 '알아챌 수 있는가'는 보지 않습니다

취약점 점검은 "구멍이 있는가"를 묻습니다. 그러나 더 중요한 점은 "누군가 침입했을 때 우리가 그것을 알아챌 수 있는가"입니다.

많은 기업이 취약점 점검을 통해 초기 침투는 차단합니다. 그런데 일단 한 발이 들어온 뒤에는 내부에서 옆으로 이동하고, 권한을 상승하고, 데이터를 모아 외부로 유출하는 과정에서 탐지에 실패하는 경우가 대부분입니다. 한 건의 침해를 식별하고 대응하기까지 여전히 평균 수십, 수백 일이 걸린다는 것은 많은 조직이 '막기'에 투자한 만큼 '알아채기'에는 투자하지 못했음을 드러냅니다. 실제로 공격자가 며칠에 걸쳐 내부를 휘젓는 동안 보안관제에 단 한 건의 알람도 발생하지 않는 일이 대다수 입니다. 침투 가능성과 탐지·대응 역량을 동시에 검증하는 것 이것이 레드팀의 핵심 가치입니다.

6. “양호 리포트”가 만드는 안심의 함정

마지막은 기술이 아니라 조직의 문제입니다. 매년 “양호” 리포트가 쌓이면 "우리는 점검을 받는 회사"라는 안전의 서사가 생깁니다. 더 근본적인 원인은 평가의 방향에 있습니다. 윗선과 상위 기관이 “얼마나 심각한 취약점을 찾았는가”보다 “체크리스트를 모두 만족했는가”를 먼저 묻는 한, 조직 전체는 위험을 찾아내는 쪽이 아니라 “양호”를 받아내는 쪽으로 최적화됩니다. 점검 벤더 역시 관계를 이어가야 하는 입장에서 불편한 결론을 강하게 제시할 동기가 크지 않습니다.

레드팀이 독립적이고 적대적인 시각으로 존재하는 이유가 여기에 있습니다. 관계가 아니라 결과로 평가받는 검증만이 보고서에 가려진 진짜 위험을 드러냅니다.

그래서 무엇을 점검해야 할까요? - 단계별 검증 체계

위에서 말씀드린 여섯가지 빈틈은 결국 한 방향을 가르킵니다. 보안 담당자의 일이 “체크리스트를 채우는 것”에서 “공격자의 시선으로 검증하는 것”으로 옮겨가야 한다는 것입니다. 거창한 조직 개편이 필요하다는 이야기가 아닙니다. 업종과 무관하게 지금 일하는 방식부터 바꿀 수 있는 실무를 세 단계로 정리했습니다.

1단계. 점검을 설계하는 단계 - 범위와 자산

“양호”를 “안전”으로 읽지 마세요. 점검 리포트의 “양호”는 알려진 위험이 발견되지 않았다는 의미일 뿐 안전하다는 증명이 아닙니다.
모르는 자산은 지킬 수 없습니다. 공격 표면 전체를 파악하세요. 외부 공격 표면 관리와 자산 관리 대장을 잘 작성하는 것은 컴플라이언스가 아니라 생존의 문제입니다.
취약점 점검을 편하게 수행하게끔 만들어주지 마세요. 방화벽을 열어주고 보안장비를 예외처리한 채 받는 점검은 실제 공격자가 마주하는 환경이 아닙니다. 공격자에게 주어지지 않는 편의는 점검시에도 주지 마세요.

2단계. 검증하는 단계 - 체크리스트를 넘어 시나리오로

취약점이 아니라 공격 경로를 생각하세요. 위험도 “낮음”의 취약점들이 모여 치명적인 취약점이 됩니다. 위협 모델링으로 이것들을 엮으면 무엇이 가능한가를 먼저 생각해야 합니다.
실제 공격자의 TTP를 재현하세요. MITRE ATT&CK 기반의 시나리오로 알려진 항목을 채우는 점검이 아니라 목표를 달성하는 공격을 시뮬레이션해야 드러나는 결함이 있습니다.
막는 것을 넘어 탐지·대응 절차를 검증하세요. 방어선이 뚫렸다는 전제에서 시작해 내부 확산, 권한 상승, 데이터 유출을 시도하고, EDR·SIEM·SOC가 실제로 탐지하는지, 탐지까지 얼마나 걸리는지, 차단하는데 얼마나 걸리는지를 측정하세요.

3단계. 상시 운영 단계 - 한 번이 아니라 지속

지속 검증으로 전환하세요. 침해/공격 시뮬레이션이나 상시형 모의해킹으로 검증 주기를 변화 주기에 맞추세요. 분기 단위 검증으로는 분 단위로 바뀌는 시스템을 따라갈 수 없습니다.
사람과 협력업체를 대상 안에 포함하세요. 공급망, 위탁 운영, 임직원까지 사회공학 기법을 검증 범위에 넣어야 합니다. 기술만 점검하는 한, 가장 자주 쓰이는 침투 경로는 영원히 존재합니다.
발견된 취약점을 프로세스로 관리하세요. 레드팀이 찾은 크리티컬한 취약점을 패치로 끝내지 말고, 보안 정책, 개발 가이드, 탐지 룰에 반영해 같은 결함이 다시 생기지 않도록 해야합니다.
불편한 결과를 환영하는 문화를 만드세요. 치명적인 취약점을 찾아내 당신을 불편하게 만드는 파트너가 사실은 당신을 가장 잘 지켜 주는 파트너입니다.

마치며

정기적인 취약점 점검은 보안의 출발점이지 종착점이 아닙니다. 점검은 알려진 문제가 지금 이 범위 안에 존재하는가를 확인하지만, 공격자는 알려지지 않은 경로로, 범위 밖에서, 점검과 점검 사이의 공백을 노립니다.

이 글을 마치며 보안 담당자가 스스로에게 던져야 할 질문은 하나입니다. 우리는 지금 “체크리스트를 채우기 위해” 일하고 있는가, 아니면 “실제로 안전해지기 위해” 일하고 있는가. 방어자와 공격자의 자리를 모두 겪어 보니 이 둘을 구분하는 순간이, 진짜 보안이 시작되는 순간이었습니다. “양호”를 받아 내는데 쓰던 시간과 자원의 일부를 공격자의 시선으로 우리 자신을 먼저 공격해보는 것, 바뀌어야 할 것은 그곳 부터입니다.

엔키화이트햇이 업종을 막론하고 치명적인 취약점을 찾아낼 수 있는 이유는 특별한 비밀 무기 때문이 아닙니다. 체크리스트 대신 시나리오로, 한 시점 대신 지속적으로, 시스템 뿐만이 아니라 사람과 프로세스까지, 뚫리는가를 넘어 들키는가까지 검증하기 때문입니다.

그동안 성실하게 해온 일들이 회사를 안전하게 만드는 일이 아니라 안전하다고 “믿게” 만드는 일이었을지도 모릅니다. 그리고 그 사실을 깨닫는 순간이 비로소 진짜 보안이 시작되는 지점입니다.

엔키화이트햇

ENKI Whitehat

오펜시브 시큐리티 전문 기업, 공격자 관점으로 깊이가 다른 보안을 제시합니다.