코딩 에이전트가 풀 리퀘스트(PR)를 만들어주면 사람은 마지막 diff만 보면 될까? A H M 나즈무스 사키브와 공동 연구자들의 논문은 이 질문에 불편한 숫자를 내놨어. AIDev 데이터셋의 에이전트 생성 PR 4,022개와 파일 변경 16,112건을 살펴본 결과, 38.9%의 PR에서 적어도 하나의 보안 냄새가 나타났다는 거야.1
무엇을 찾았나
연구진은 검증된 LLM-as-a-judge 방식과 수동 질적 분석을 함께 사용해 에이전트가 만든 PR의 보안 코드 냄새를 분류했어. 논문이 말하는 보안 냄새는 곧바로 침해가 일어났다는 뜻이 아니라, 보안상 잘못된 설정이나 코드 패턴이 발견됐다는 뜻이야.
발견된 냄새의 82.3%는 공급망 무결성 문제에 해당했어. 심각도가 높은 냄새만 놓고 보면 99.6%가 하드코딩된 자격증명이었고. 에이전트가 코드를 만들 때 생기는 문제를 이야기하지만, 실제로는 의존성과 비밀정보 관리가 가장 큰 비중을 차지한 셈이야.1
여기서 중요한 건 발견량과 실제 유출의 주체가 같지 않다는 점이야. 연구진의 분석에서는 사람 협업자가 진짜로 유출된 비밀정보의 67.6%를 도입했어. 에이전트가 만든 변경만 따로 떼어 “AI가 보안 문제를 만들었다”고 읽을 수 없는 이유야.
그런데 검토가 놓친 것도 있다
문제는 기존 검토 절차가 이 비밀정보를 충분히 잡지 못했다는 데 있어. 논문은 자동화된 검토와 사람 검토를 거쳤는데도 통합 전에 자격증명의 81.1%가 발견되지 않았다고 보고해.1 에이전트가 만든 코드의 양이 늘어나는 것만 문제가 아니라, 사람이 만든 변경까지 포함한 긴 작업 흐름을 사람이 끝까지 읽기 어려워진다는 뜻으로 읽혀.
이 지점은 agentic workflow의 핵심과 맞닿아 있어. 에이전트가 도구를 쓰고 여러 단계를 이어갈수록 검토 대상은 한 번의 코드 제안이 아니라 목표 설정, 파일 변경, 의존성 선택, 검증 결과가 연결된 흐름이 되거든. 연구가 직접 측정한 것은 PR의 보안 냄새와 자격증명 누락이지, 에이전트의 장기 실행이 왜 검토를 어렵게 만드는지에 대한 모든 원인은 아니야.
다음에 확인할 것
논문이 제안하는 방향은 협업 지점에 맥락을 아는 보안 가드레일을 두는 거야. 다만 이번 결과만으로 어떤 도구가 실제 누락을 줄이는지, LLM 심사 방식의 오탐과 누락이 어느 정도인지까지 알 수는 없어.
다음에는 에이전트가 만든 PR과 사람이 만든 PR을 같은 기준으로 비교한 연구, 그리고 자격증명이 통합 전에 실제로 얼마나 차단되는지를 봐야 해. 숫자가 줄었다는 보고보다, 어떤 변경 지점에서 무엇을 찾아냈는지가 더 중요해질 거야.
댓글