
AI가 해커처럼 일하기 시작했어요
보안 분야에서 "취약점을 찾는다"는 건 정말 어려운 일이에요. 코드 수십만 줄, 수백만 줄을 사람이 일일이 읽으면서 "여기서 메모리가 잘못 쓰일 수 있겠는데?" 같은 판단을 내려야 하거든요. 그래서 보안 연구자들은 수십 년 동안 이걸 자동화하려고 노력해왔어요. 퍼저(fuzzer)라고 해서 무작위 입력을 마구 집어넣어서 프로그램이 죽는지 보는 도구도 있고, 정적 분석 도구로 코드를 훑어서 의심스러운 패턴을 찾기도 했죠.
그런데 이 방식들에는 한계가 명확해요. 퍼저는 너무 무작위라서 진짜 깊숙한 버그까지 도달하지 못하는 경우가 많고, 정적 분석은 "의심스럽다"는 경고를 너무 많이 내서 실제 취약점을 가려내기 어려워요. 그래서 최근 LLM(거대 언어 모델), 그러니까 ChatGPT 같은 AI를 보안 연구에 활용하려는 시도가 활발해지고 있어요.
이번에 arXiv에 올라온 논문은 그중에서도 한 단계 더 나아간 접근법을 제안해요. 여러 AI 에이전트가 서로 다른 역할을 맡아서 협력하는 시스템으로 취약점을 찾고, 심지어 실제로 재현(reproduce)까지 자동으로 해낸다는 거예요.
멀티 에이전트가 뭐냐면
요즘 AI 업계에서 "에이전트(agent)"라는 단어를 자주 듣게 되실 거예요. 이게 뭐냐면, AI가 단순히 질문에 답만 하는 게 아니라 도구를 쓰고 결정을 내리면서 일을 수행하는 형태를 말해요. 예를 들어 "이 코드의 버그를 찾아줘"라고 하면, 에이전트는 코드를 읽고, 테스트를 돌려보고, 결과를 분석하고, 다시 다른 부분을 살펴보는 식으로 능동적으로 움직여요.
멀티 에이전트는 이런 에이전트를 여러 개 두고 각자 다른 역할을 맡기는 거예요. 회사로 비유하면 한 명의 슈퍼맨이 모든 걸 하는 게 아니라, 분석가, 개발자, QA, 매니저가 따로 있어서 협업하는 거죠. AI 한 개의 컨텍스트(한 번에 기억할 수 있는 정보량)에는 한계가 있는데, 역할을 나누면 각자 자기 일에 집중할 수 있어서 전체 성능이 올라가요.
이 논문에서 제안하는 시스템도 비슷한 구조예요. 한 에이전트는 코드를 정독하면서 의심스러운 부분을 표시하고, 다른 에이전트는 그 부분이 정말 취약한지 검증해요. 또 다른 에이전트는 실제로 그 취약점을 발동시키는 입력값, 그러니까 PoC(Proof of Concept, 개념 증명) 코드를 작성해서 진짜 재현되는지 확인하고요.
자동 재현이 왜 그렇게 중요한가
취약점을 "발견했다"는 것과 "증명했다"는 건 완전히 다른 일이에요. 코드를 보고 "여기 위험해 보여"라고 말하는 건 누구나 할 수 있지만, 실제로 그 버그를 발동시키는 입력을 만들어내는 건 훨씬 어려워요. 보안 업계에서는 PoC가 있어야 비로소 "진짜 취약점"으로 인정받거든요.
기존 자동화 도구들이 가진 가장 큰 문제가 바로 거짓 양성(false positive)이에요. "여기 SQL 인젝션 가능성이 있어요" 같은 경고를 백 개 띄워놨는데 막상 확인해보면 진짜 위험한 건 한두 개뿐이고 나머지는 다 잘못된 경보인 경우가 많아요. 보안 엔지니어가 이 백 개를 일일이 검증하느라 시간을 다 써버리니까 자동화의 의미가 없어지죠.
이 논문이 강조하는 "재현까지 자동화"라는 점이 그래서 의미가 커요. AI가 "여기 버그 있어요"라고만 하는 게 아니라, "이 입력값을 넣으면 진짜로 크래시(crash)가 나요"라는 실증까지 같이 가져다주는 거예요. 그러면 사람은 의심스러운 경보를 일일이 확인할 필요 없이, 이미 증명된 취약점을 받아서 패치만 하면 돼요.
업계에서는 이미 비슷한 움직임이 활발해요
구글의 OSS-Fuzz 프로젝트는 이미 LLM을 활용해서 오픈소스 프로젝트의 버그를 찾는 실험을 하고 있어요. 작년에는 Google의 AI인 Big Sleep이 실제 운영 중인 데이터베이스 엔진에서 0-day 취약점, 그러니까 아직 알려지지 않은 새 취약점을 발견해서 화제가 되기도 했고요. Microsoft도 GitHub Copilot 보안 기능에 비슷한 기술을 녹이고 있어요.
DARPA(미국 국방고등연구계획국)도 AI Cyber Challenge라는 대회를 열어서 AI가 자동으로 취약점을 찾고 패치까지 만드는 시스템을 겨루게 하고 있어요. 이런 흐름을 보면, "AI가 해커처럼 일한다"는 건 더 이상 먼 미래 이야기가 아니라 이미 현실로 다가오고 있는 거예요.
다만 양면성이 있어요. 같은 기술을 공격자가 쓰면 어떻게 될까요? 누군가가 이 시스템을 악용해서 오픈소스 프로젝트의 취약점을 대량으로 찾아낸 다음 패치되기 전에 공격하면, 보안 업계는 정말 곤란해져요. 그래서 "방어자가 먼저 이 기술을 활용해야 한다"는 의식이 강해지고 있어요.
한국 개발자가 알아둘 것
실무에서 당장 이런 멀티 에이전트 시스템을 도입하기는 아직 어려워요. 비용도 많이 들고, 결과 검증도 필요하니까요. 하지만 몇 가지 흐름은 알아두면 좋아요.
첫째, 코드 리뷰에 AI를 통합하는 트렌드가 빨라지고 있어요. GitHub Advanced Security나 Snyk 같은 도구들이 점점 LLM 기반으로 진화하고 있고, 한국에서도 토스나 네이버 같은 회사들이 사내 AI 보안 도구를 만들고 있다고 알려져 있어요. 보안 엔지니어를 꿈꾼다면 이쪽 기술 스택을 익혀두면 큰 도움이 될 거예요.
둘째, 오픈소스 의존성 관리가 더 중요해져요. AI가 취약점을 자동으로 찾아내면, 우리가 쓰는 라이브러리들에서도 새 CVE(공통 취약점 식별자)가 쏟아져 나올 거예요. Dependabot이나 Renovate 같은 도구로 의존성 업데이트를 자동화해두지 않으면 계속 뒤처지게 돼요.
셋째, AI 에이전트 시스템 자체를 공부해두는 것도 좋아요. 보안 도메인이 아니더라도 멀티 에이전트 구조는 앞으로 다양한 자동화 시스템의 기본 패턴이 될 가능성이 커요. LangGraph나 CrewAI 같은 프레임워크를 한번 만져보면 감이 올 거예요.
마무리
AI가 코드를 읽고 취약점을 찾는 시대가 본격적으로 열리고 있어요. 이건 보안 엔지니어를 대체한다기보다, 보안 엔지니어가 진짜 중요한 판단에 집중할 수 있게 하는 도구로 발전할 거예요.
여러분의 팀에서는 코드 리뷰나 보안 점검에 AI를 어떻게 활용하고 계신가요? 혹시 이런 자동화 도구를 도입했을 때 가장 우려되는 부분이 있다면 무엇인지 궁금해요.
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공