바이브 코딩 보안 도구 실험: 침해사고 분석 14분, 가짜 등록 페이지, 익스플로잇 등장 시간 변화

핵심 메시지

• SANS 인스티튜트의 로브 리는 침해사고 대응 도구 모음 위에 AI 코딩 도구를 얹어, 사람이 사흘 걸리던 단일 시스템 침해 분석 보고서를 14분 27초 만에 자동 생성했다.
• 그레이노이즈의 글렌 소프는 개인화된 컨퍼런스 일정 앱을 AI로 만들었지만, 발표 설명의 약 75%가 사실과 다르게 생성돼 검증 절차 없이 공유한 뒤에야 오류를 발견했다.
• 또 다른 발표자는 8분 만에 6,800줄 규모의 소셜미디어 코멘트 수집기를 만들었고, 같은 방식으로 컨퍼런스 공식 사이트를 그대로 흉내 낸 가짜 등록 페이지도 시연했다.
• 시스디그의 세르게이 에프는 취약점 공개부터 실제 악용까지 걸리는 시간이 2020년 1년 이상에서 현재 하루 안팎으로 줄었다는 데이터를 제시했다.
• 무기화된 익스플로잇의 절반 이상이 패치 공개 이전이나 당일에 쓰이는 제로데이인 반면, 기업의 패치 절차는 그만큼 빨라지지 않았다.

쉽게 이해하기

미국의 보안 행사 [un]prompted 2026 마지막 순서는 조금 특이했다. 발표자들이 행사가 열리는 동안 AI 코딩 도구로 직접 만든 결과물을 그 자리에서 시연한 것이다. 준비된 강연이 아니라 며칠 사이에 만들어진 도구들이었고, 그래서 오히려 AI 코딩이 실무에서 어디까지 왔고 어디서 무너지는지가 솔직하게 드러났다.

가장 인상적인 사례는 침해사고 분석이었다. 18년 전 포렌식 워크스테이션을 만든 로브 리는 그 도구 모음 위에 AI 코딩 도구를 설치하고 설정 파일과 스킬을 정리하는 데 45분에서 한 시간 정도를 썼다고 밝혔다. 그런 다음 '악성 흔적을 찾아라'는 한 줄 명령만 주자, 침해된 시스템의 디스크 이미지에서 전체 보고서까지 14분 27초 만에 끝났다. 그는 참석자들에게 물어보니 같은 작업을 사람이 하면 보통 사흘이 걸린다고 덧붙였다.

반대편 사례도 나왔다. 글렌 소프는 행사 일정표가 구글 스프레드시트로만 공유되는 것이 아쉬워 개인화된 일정 앱을 AI로 만들었다. 문제는 모델이 발표 내용을 뒤섞어 버린 것이었다. 자기 회사 이름이 엉뚱한 발표 설명에 등장하는 것을 보고서야 확인해 보니, 결국 설명의 4분의 1만 맞고 나머지는 틀렸다. 그는 더 명시적으로 검증 지시를 준 뒤에야 고칠 수 있었다고 말했다.

세 번째 발표자는 속도 자체를 문제로 제기했다. 여러 소셜미디어에 흩어진 행사 반응을 모으는 도구를 8분 만에 만들었는데, 생성된 코드가 6,800줄에 의존성이 17개였다. 그는 같은 방식으로 행사 공식 사이트를 크롤링해 겉모습이 똑같은 가짜 페이지를 만든 뒤, 그 위에 비밀번호와 신용카드 정보를 입력받는 내년도 사전등록 폼을 붙여 보였다. 마음만 먹으면 어떤 사이트에도 같은 일을 할 수 있다는 뜻이다.

마지막 발표는 이 모든 변화를 하나의 지표로 정리했다. 세르게이 에프는 정부 기관과 상용 취약점 데이터베이스를 에이전트로 수집해 '악용까지 걸리는 시간'을 계산했다. 2020년에는 1년이 넘었지만 지금은 하루 안팎이다. 그는 이 한 장의 슬라이드를 경영진과 보안 책임자에게 설명할 때 쓰라고 권했다.

주요 인사이트

• AI가 침해사고 분석을 사흘에서 15분 이내로 줄인다고 해서 분석가가 필요 없어지는 것은 아니다. 발표자 본인이 보고서에 담긴 아티팩트를 판단하려면 기본 지식이 여전히 필요하다고 못 박았다.
• 공격 측이 몇 달 걸리던 작업을 며칠이나 몇 분으로 줄이고 있기 때문에, 방어 측도 같은 속도를 내야 한다는 것이 속도 경쟁의 출발점이다.
• 일정 앱 사례는 AI 결과물의 실패가 조용히 일어난다는 점을 보여준다. 앱은 정상 동작했고 화면도 그럴듯했지만 내용의 4분의 3이 틀렸으며, 만든 사람이 우연히 자기 회사 이름을 발견하기 전까지 아무도 몰랐다.
• 8분에 6,800줄과 17개 의존성이 생성된다는 것은 검토되지 않은 코드와 공급망이 그만큼 빠르게 늘어난다는 뜻이기도 하다.
• 악용까지 걸리는 시간이 하루로 줄었는데 패치 절차는 그대로라면, 격차는 도구가 아니라 조직의 프로세스에서 벌어진다.

자주 묻는 질문

관련 AI 소식