Ben DH Kim – Notes from Building Cyber Security Startup

AI 시대, 보안의 외주화는 끝내야 한다.

보안의 외주화

그동안 국내 수많은 조직에서 보안은 오랫동안 ‘맡기는 일’이었습니다. 1년에 한 번 외부 업체에 모의해킹을 맡기고, 인증 심사는 컨설팅사에, 위협 탐지는 솔루션에, 그리고 남은 일은 보안팀에 맡겨버리곤 했죠. 개발팀, 인프라팀, 그리고 경영진까지도 보안을 “누군가 알아서 처리해 주는 일” 정도로 받아들였습니다. 이것이 제가 말하는 ‘보안의 외주화’입니다.

사실 이 방식이 처음부터 틀렸던 것은 아닙니다. 공격 주체가 사람이었고, 공격 속도가 사람의 호흡을 따르던 시절에는 연 1회 정기 점검과 분기별 보고서만으로도 어느 정도 버틸 수 있었습니다.

하지만 이제 그 전제 자체가 무너졌습니다. AI가 공격자의 손에 들어가면서, 사이버 공격은 사람의 속도가 아닌 ‘기계의 속도’로 몰아치기 시작했습니다. 그리고 기계의 속도로 쏟아지는 공격은 ‘맡겨 두는’ 구조로는 결코 막을 수 없습니다.

최근 실제 AI가 개입된 공격 사례들을 통해 무엇이 바뀌었는지 돌아보고, 왜 새 솔루션을 사 오는 것만으로는 답이 되지 않는지, 그리고 방어하는 우리 조직은 어떻게 달라져야 하는지 이야기해 보려 합니다.

머신의 속도로 벌어지는 해킹사고

2025년 하반기는 AI가 단순한 ‘보조 도구’에서 실질적인 ‘공격 실행 주체’로 진화한 기점이라고 생각합니다. 아래 세가지 사건은 저에게도 큰 충격을 주었던 사례들입니다.

1. Anthropic 공개 AI 주도 사이버 첩보 캠페인 (2025년 11월) 중국 배후로 추정되는 해킹 그룹이 Claude Code를 공격 프레임워크에 결합해 글로벌 조직 30여 곳을 노렸습니다. 정찰, 취약점 탐색, 익스플로잇 작성, 자격증명 수집, 유출 데이터 분류까지 전체 작업의 80~90%를 AI가 직접 수행했고, 사람은 캠페인당 4~6번 정도의 결정적 판단에만 개입했습니다. 피크 시점에는 초당 수십 건의 요청이 몰렸는데, 이는 사람 해커 팀으로는 불가능한 속도입니다. 공격자는 작업을 작은 단위로 쪼갠 뒤 AI에게 “보안 회사의 방어 테스트”라고 속여 안전 가드레일을 우회했습니다.
2. Nx ‘s1ngularity’ 공급망 공격 (2025년 8월) 취약한 GitHub Actions 워크플로를 타고 npm 배포 권한을 탈취한 뒤 악성 Nx 패키지를 유포한 사건입니다. 주목할 점은 감염된 개발자 PC에 설치된 Claude Code, Gemini CLI, Amazon Q 같은 AI CLI 도구를 위험 권한 옵션과 함께 강제 실행시켰다는 것입니다. 개발자의 생산성 도구가 순식간에 파일시스템을 뒤지는 공격자의 정찰 도구로 변했습니다. GitGuardian 분석에 따르면 이로 인해 2,349개의 시크릿이 유출되었고, 상당수는 유출 후에도 한동안 폐기되지 않은 채 방치되었습니다.
3. npm 자가 복제 웜 ‘Shai-Hulud’ (2025년 9월) 탈취한 메인테이너 토큰으로 npm에 인증한 뒤, 다른 패키지에 악성 코드를 주입하고 자동 재배포를 거쳐 500개 이상의 패키지를 연쇄 감염시켰습니다. 수작업으로 이뤄지던 감염 과정이 완전히 자동화된 도미노 현상으로 변한 것입니다.

세 사례의 공통점은, 공격 시간은 ‘분 단위’로 단축되었고, 임팩트는 단일 기업을 넘어 생태계 전체로 확대되었습니다. 공격 진입점 역시 외부 방화벽이 아닌 개발자의 터미널, CI/CD 파이프라인, 그리고 그 안에 흩어진 토큰과 API 키였습니다. 즉, 사람이 아닌 비인가 자격증명(Non-Human Identity)이 핵심 표적이 된 것입니다.

솔루션 만능주의로 해결되지 않는 것

이런 사례를 접하면 가장 먼저 나오는 반응은 “그럼 AI 보안 솔루션을 도입하자”입니다. 솔루션 기업을 운영하는 입장에서 이런 말씀을 드리는 게 아이러니하지만, 솔루션 구매만으로는 이 문제를 풀 수 없습니다.

• 솔루션은 ‘알려진 패턴’을 막습니다. ‘s1ngularity’ 사태에서 공격자가 쓴 것은 악성 바이너리가 아니라 개발자가 정상적으로 설치해 둔 AI CLI였습니다. Anthropic 사례도 개별 요청만 보면 무해한 보안 테스트처럼 보였을 것 입니다. 정상 도구와 정상 권한으로 움직이는 공격은 시그니처 분석으로 잡히지 않습니다. 이것이 정상인지 아닌지는 그 환경을 운영하고 있는 사람, 즉 개발팀과 운영팀의 맥락이 있어야만 판단할 수 있습니다.
• 솔루션은 알람을 만들 뿐 고치지 않습니다. Nx 사건 당시 시크릿 유출 탐지 자체는 비교적 빨랐습니다. 그러나 정작 키를 폐기하고 교체하는 작업이 이뤄지지 않아 키가 한참 동안 유효했습니다. 키를 교체하려면 ‘누가 만들었고, 어느 서비스가 쓰고 있으며, 바꿨을 때 무엇이 영향받는지’ 알아야 합니다. 이건 탐지 솔루션이 아니라 시스템을 운영하고 이해하는 사람이 해야 하는 일입니다.
• 공격 속도와 대응 속도 사이의 간극입니다. 공격자는 패치가 나오면 몇 분 만에 익스플로잇을 개발하고, 웜은 사람이 몇 시간 사이에 수백 개 패키지로 번집니다. 반면 많은 조직의 사고 대응 체계는 솔루션 알람, 외주 관제, 내부 보안팀 전달, 개발팀 이메일 요청...으로 이어집니다. 이 구조처럼 특정한 팀, 특정한 회사, 특정한 솔루션에 ‘맡기는’ 구조에 머무는 한, 전체 속도는 저하될 수 밖에 없습니다.
• 체크리스트형 컴플라이언스의 한계입니다. ISMS-P 같은 인증은 통제 항목의 ‘존재 여부’를 봅니다. 하지만 개발자 노트북에 설치된 AI 에이전트가 어떤 토큰에 접근할 수 있는지, CI 파이프라인 배포 토큰이 언제 교체되었는지는 체크리스트에 잘 드러나지 않습니다. “인증을 받았다”는 사실과 “실제로 안전하다”는 사실 사이의 거리는 AI 시대에 더 멀어지고 있습니다.

결국 솔루션은 도구일 뿐입니다. 쓰는 사람과 조직의 운영 방식이 함께할 때만 제 역할을 합니다. 솔루션을 사는 것이 보안의 외주화를 한 단계 더 진행하는 편법이 되어서는 안 됩니다.

DevSecOps 관점

그렇다면 내부 보안팀은 무엇이 달라져야 할까요? 한 문장으로 요약하면, 보안팀은 ‘사후 검사’ 관점에서 ‘만드는 과정의 보안 내제화’로 관점을 바꿔야 합니다.

전통적인 보안팀의 위치는 개발 프로세스의 밖에, 그것도 맨 단계에 있었습니다. 다 만들어진 서비스를 출시 직전에 점검하고 문제가 있으면 반려하죠. 이 구조에서 보안팀은 자연스럽게 ‘속도를 늦추는 걸림돌’이 되고, 개발팀은 보안팀을 돌아서 가는 편법을 찾게 됩니다. 외주 모의해킹 결과서가 아무도 읽지 않는 보고서로 남고, 취약점이 몇년이 지나도 해결되지 않는 것도 같은 이유입니다.

DevSecOps 관점이란, 보안을 개발과 운영의 흐름 안에 코드와 자동화의 형태로 녹여내는 것입니다.

• 시크릿은 사람이 관리하는 문서가 아니라 파이프라인이 관리하는 자산이 됩니다. 장기 토큰 대신 OIDC 기반 단기 자격증명을 쓰고, 유출되면 자동화 시스템이 즉시 폐기하고 교체합니다.
• 공급망 의존성은 ‘설치하는 것’이 아니라 ‘검증하고 들여오는 것’이 됩니다. 락파일 고정, 패키지 출처 검증, postinstall 스크립트 통제가 CI의 기본값이 됩니다.
• 개발자 PC와 AI 에이전트도 보안 경계 안에 들어옵니다. 어떤 AI 도구가 어떤 권한으로 어떤 자격증명에 접근하는지 알고 있어야 합니다. AI 에이전트는 이제 또 하나의 Non-Human Identity입니다.
• 보안 정책은 문서가 아니라 코드로 존재합니다. 리뷰 가능하고, 버전 관리되며, 개발자가 PR(Pull Request)로 수정을 제안할 수 있어야 합니다.

이렇게 하려면 보안팀 스스로 코드를 읽고 쓸 수 있어야 하며, CI/CD와 클라우드 인프라, 현대적 보안 방안을 깊이 이해해야 합니다. 컴플라이언스 문서나 관리하던 역량으로는 부족합니다. 동시에 방어자 역시 AI를 적극적으로 써야 합니다. 공격자가 AI로 공격 표면을 찾고 익스플로잇을 자동화하며 머신의 스피드로 공격하고 있는데, 방어자는 수작업 리뷰와 엑셀 자산 관리에 머문다면 속도 싸움에서 이미 이길 수 없는 구조가 됩니다.

내부 내재화의 필요성

그런데 여기에는 한 가지 불편한 현실이 있습니다. 가장 강력한 보안 특화 AI는 일반 기업에게 열려 있지 않다는 점입니다.

Anthropic은 2026년 4월 Project Glasswing을 발표하며, 주요 운영체제와 브라우저 전반에서 수천 건의 고위험 취약점을 찾아낸 Claude Mythos Preview를 일반에 공개하지 않겠다고 밝혔습니다. 접근권은 AWS, Apple, Google, Microsoft, CrowdStrike, Palo Alto Networks 같은 출범 파트너와 핵심 소프트웨어를 유지하는 40여 개 조직에만 우선 부여되었습니다.

Google도 같은 길을 가고 있습니다. 지난 9월 보안 특화 모델 Gemini 3.8 Flash Cyber를 일반 출시 대신 Fairwind Program이라는 제한 접근 프로그램으로만 풀었습니다. 대상은 정부, 핵심 기반시설 운영사, 주요 기술 플랫폼으로 제한되며, 사용 인력도 내부 보안 팀, 침해대응 팀, 모의해킹 팀으로 엄격히 한정됩니다.

그리고 바로 오늘, Google은 차세대 프런티어 모델 Gemini 4 Argon을 발표하면서 이 모델 역시 Fairwind의 신뢰된 방어자들에게 먼저 배포한다고 밝혔습니다. 더 눈에 띄는 대목은, 신뢰된 방어자와 Google 내부 팀에게는 Argon을 사이버 가드레일 없이 제공해 최고 수준의 방어 역량을 그대로 쓰게 하지만, 일반 개발자와 기업에게는 안전장치를 강화한 뒤 순차 공개하겠다는 점입니다. 같은 모델이라도 사용자에 따라 쓸 수 있는 능력이 근본적으로 다르게 됩니다.

이 결정 자체는 이해할 수 있습니다. 취약점을 탐지하는 능력은 곧 공격 무기가 될 수 있으므로, 제약 없이 풀었다간 공격자에게 무기를 쥐여주는 꼴이 되기 때문입니다. 하지만 그 결과 방어 환경에는 ‘기울어진 운동장’이 형성됩니다. 빅테크와 글로벌 보안 기업은 최고 수준의 AI로 자사 코드를 먼저 점검하지만, 대부분의 국내 기업과 스타트업은 그 울타리 밖에 남겨집니다. 공격자는 일반 모델을 탈옥하거나 오픈 웨이트 모델을 쓸 수 있지만, 일반 방어자는 제한된 도구로 싸워야 합니다.

이 격차는 단순한 솔루션 구매로 해결할 수 없습니다. 결국 우리에게 남는 가장 확실한 무기는 우리 시스템을 가장 잘 아는 내부 구성원과, 내재화된 자동화 체계뿐입니다.

책임은 나누고, 속도는 올려야 한다

보안팀이 DevSecOps의 시선을 갖는 것만으로는 충분하지 않습니다. 수십 명의 보안팀이 수백, 수천 명의 개발자와 수만 개의 토큰, 매일 늘어나는 AI 에이전트를 혼자 감당할 수는 없습니다. 그래서 책임을 분산하고 나누어야합니다.

사실 보안은 원래 특정한 한 팀만의 일이 아닙니다. 자기 집 보안을 제 3자에게 전부 맡기는 사람은 없습니다. 물리적 열쇠를 쓰든, 도어락이나 지문 인식을 쓰든, 사후 확인용 CCTV를 달든 각자의 환경과 지켜야 할 자산, 감당할 수 있는 불편함에 따라 집 보안을 직접 선택합니다. 경비업체를 고용하더라도, 모든 권한을 넘기지 않고 문단속은 결국 집주인이, 집의 구성원이 하는 것입니다.

조직도 마찬가지입니다. 우리 조직이 무엇을 지켜야 하는지, 어떤 속도로 움직이는지, 어디까지의 불편함을 감수할 수 있는지는 외부 업체나 솔루션이 대신 정해주지 못합니다. 남이 정해준 표준 체크리스트가 아니라, 우리 조직에 맞는 보안을 우리가 고르고 직접 운영해야 합니다.

이것이 현대적 보안의 핵심입니다. 모든 조직에 똑같이 적용되는 정답 대신, 내가 지켜야 할 자산과 감수할 위험을 스스로 정의하고, 그에 맞는 통제를 고르고, 그 통제를 직접 운영하는 것. 제로 트러스트(Zero Trust)도, 클라우드의 공동 책임 모델(Shared Responsibility Model)도 결국 같은 비전을 이야기합니다. 경계 밖에 맡겨두면 안전하다는 가정을 버리고, 각 아이덴티티와 각 시스템의 주인이 자기 몫의 보안을 책임지라는 것입니다.

책임을 나눈다는 것은 “보안은 모두의 책임입니다”라는 구호를 외치는 게 아닙니다. 구호는 역설적으로 아무의 책임도 아니게 만듭니다. 필요한 것은 구체적인 소유권(Ownership)입니다.

“이 서비스 계정은 누가 만들었고 누가 교체하는가?”

“이 파이프라인의 배포 토큰은 어느 팀 소관인가?”

“이 AI 에이전트에 붙은 권한은 누가 승인했는가?”

시스템을 만든 팀이 그 시스템의 보안도 소유하고, 보안팀은 그 소유권 행사가 가능하도록 기준과 도구, 가드레일을 제공하는 것. 이것이 건강한 역할 분담입니다.

그리고 이 구조의 궁극적인 목적은 속도입니다. AI 시대의 보안에서 가장 중요한 지표는 “몇 개의 통제 항목을 갖췄느냐”가 아니라 “문제를 발견한 뒤 실제로 고치기까지 얼마나 걸리느냐”입니다. 유출된 키를 몇 분 안에 폐기할 수 있는가? 감염된 패키지 버전을 몇 시간 안에 전사 코드베이스에서 걷어낼 수 있는가? 이 대응 시간은 보안팀이 다른 팀에 요청하고 답변을 기다리는 구조에서는 절대로 줄어들지 않습니다. 시스템의 주인이 직접 고칠 수 있고, 그렇게 처리하는 것이 자연스러운 조직에서만 줄어듭니다.

경영진의 역할도 바로 여기에 있습니다. 보안 사고가 터졌을 때 보안팀만 문책하는 조직에서는 아무도 책임을 나누어 가지려 하지 않습니다. 반대로 각 팀의 목표와 평가에 보안 지표가 반영되고, 빠른 조치를 취한 팀이 인정받는 조직에서는 보안이 자연스러운 업무의 일부가 됩니다. 보안을 외부 업체나 특정 팀에 ‘맡기는’ 문화에서 벗어나는 것은 결국 조직 설계의 문제인 것입니다.

물론 외부 전문가의 역할이 완전히 사라지는 것은 아닙니다. 깊이 있는 정밀 진단과 제3자 관점의 독립적 검증은 여전히 필요합니다. 다만 외부 점검은 내부 역량을 대신하는 것이 아니라, 내부 역량이 제대로 작동하고 있는지 확인하는 수단이 되어야 합니다.

맺으며

AI는 공격자에게 지치지 않는 최정예 팀원을 무한정 만들 수 있는 능력을 만들어주었습니다. 공격 표면 탐색도, 익스플로잇 작성도, 유출 데이터 분류도 이제는 기계의 속도로 일어납니다. 이러한 상대 앞에서 연 1회 외부 점검과 솔루션 알람, 그리고 ‘보안팀이 알아서 하겠지’라는 안일한 기대에 의존하는 것은 더 이상 전략이 될 수 없습니다.

보안을 다시 우리 손으로 가져와야 합니다. 보안팀은 개발과 운영의 흐름 안으로 들어가고, 각 팀은 자기가 만든 시스템과 아이덴티티의 보안 소유권을 가지며, 조직은 문제 발견부터 수정까지의 시간을 줄이는 데 모든 역량을 집중해야 합니다.

외주화된 보안은 과거의 사치였습니다. AI 시대의 보안은 다시 내부 팀의 일입니다.