코드 에이전트 평가는 “작동했는가”와 “안전했는가”를 분리하면 부족하다

저장소 규모 코드 에이전트를 도입하려는 팀의 결정 기준은 단순해야 한다. 기능 테스트만 통과한 에이전트를 보안 민감 워크플로에 넣어서는 안 된다. 반대로 취약점 탐지만 잘하는 모델 점수도 실제 수정 작업의 신뢰성을 보장하지 않는다. 같은 과제 안에서 기능 성공, 기존 취약점 검증, 새 취약점 유입 여부를 함께 봐야 한다.

이 판단은 코드 LLM의 역할 변화와 관련이 있다. 논문 초록은 LLM이 코드 완성에서 저장소 맥락 검색, 파일 수정, 도구 실행, 보안 민감 워크플로 참여로 이동하고 있다고 정리한다. 그러나 평가 근거는 여전히 나뉘어 있다. 소프트웨어 엔지니어링 평가는 과제 완료 여부를 중심으로 본다. 소프트웨어 보안 평가는 취약점 탐지, 안전한 코드 생성, exploit 지향 검증을 중심으로 본다.

이 분리는 코드 완성기 시절에는 어느 정도 감당할 수 있었다. 모델이 한 함수나 짧은 스니펫을 제안한다면 리뷰어가 좁은 맥락에서 확인할 수 있다. 그러나 저장소 에이전트는 다르다. 검색한 맥락을 바탕으로 여러 파일을 고치고, 테스트나 빌드 같은 도구를 실행한다. 때로는 보안에 직접 영향을 주는 흐름에도 참여한다. 이때 “테스트가 통과했다”는 말은 “취약점이 없다”는 말과 같지 않다.

왜 기능 점수만으로는 위험한가

기능 평가는 대개 사용자가 요구한 동작이 구현됐는지를 확인한다. 테스트가 충분하다면 회귀를 줄이는 데 도움이 된다. 하지만 보안 결함은 기능 성공과 동시에 존재할 수 있다. 인증 우회, 입력 검증 누락, 경로 조작, 민감정보 노출 같은 문제는 정상 시나리오 테스트를 통과하면서 남을 수 있다.

반대로 보안 평가만으로 제품 의사결정을 내리기도 어렵다. 취약점 탐지 능력이 높아도 실제 저장소에서 요구사항을 구현하지 못하면 개발 생산성 도구로 채택하기 어렵다. 안전한 코드 생성 벤치마크에서 좋은 결과를 내더라도, 기존 저장소의 의존성, 테스트, 빌드 스크립트, 파일 간 계약을 지키는지는 별도 문제다.

따라서 코드 에이전트 평가는 “기능 또는 보안”이 아니라 “기능을 만족하면서 보안 상태를 악화시키지 않는가”를 물어야 한다.

통합 평가는 이미 구현 가능한 방향이다

확인된 연구 사례를 보면 통합 평가는 추상적 구호에 그치지 않는다. SecureAgentBench는 기능 테스트, PoC exploit을 통한 취약점 검증, 정적 분석을 통한 새 취약점 탐지를 결합한 평가를 제시한다. SecRepoBench도 저장소 맥락에서 기능 정확성과 PoC 기반 보안성을 함께 평가하는 방향으로 보고됐다.

여기서 필요한 설계 원칙은 점수를 하나로 뭉개지 않는 것이다. 기능 테스트 통과율, PoC exploit 성공 여부, 정적 분석으로 탐지된 신규 취약점은 서로 다른 실패 모드다. 평균 점수 하나로 만들면 치명적인 보안 실패가 기능 성공에 가려질 수 있다.

실무 평가는 다음처럼 구성하는 편이 낫다.

기능 테스트: 요구된 수정이 실제로 동작하는지 확인한다.
exploit 기반 검증: 알려진 취약 시나리오가 여전히 재현되는지, 또는 차단됐는지 확인한다.
신규 취약점 탐지: 수정 과정에서 새 보안 결함이 생겼는지 정적 분석 등으로 확인한다.
통과 조건: 보안 실패가 있으면 기능 점수와 무관하게 배포 후보에서 제외한다.

이 방식은 의사결정을 더 분명하게 만든다. 에이전트가 기능을 맞혔지만 PoC exploit이 성공한다면 “부분 성공”이 아니라 “보안 워크플로 투입 불가”다. 반대로 보안상 안전하지만 기능 테스트를 깨뜨렸다면 자동 수정 도구로는 아직 부족하다.

저장소 에이전트에는 평가 외의 운영 통제도 필요하다

벤치마크는 모델 선택에 필요하지만, 운영 위험을 모두 없애지는 않는다. 저장소 에이전트는 도구를 실행하고 파일을 바꾸기 때문이다. 확인된 자료에 따르면 이런 에이전트에는 파일시스템과 네트워크를 격리하는 샌드박스가 필요하다. 도구별 최소 권한, 관리형 자격증명, 명령 실행이나 파일 변경 같은 영향 큰 작업에 대한 사람 승인도 가드레일로 제시된다.

감사 체계도 단순 로그보다 넓어야 한다. 에이전트의 계획, 검증 결과, 도구 호출의 매개변수와 결과, 사람의 승인 결정, 오류, 상태 변경을 추적 ID와 함께 구조화해 남겨야 한다. 여기에 로그 무결성, 접근 통제, 운영 중 보안 평가, 사고 대응과 변경관리까지 포함돼야 한다는 근거도 있다.

다만 구체적인 승인 대상 명령, 권한 범위, 로그 보존 기간, 경보 임계값은 제공된 근거만으로 확정할 수 없다. 따라서 조직은 이를 표준처럼 받아쓰기보다 자사 저장소의 민감도, 배포 권한, 비밀정보 접근 가능성에 맞춰 정책으로 정해야 한다.

도입 판단 규칙

저장소 규모 코드 에이전트를 평가하는 팀이라면 다음 기준을 적용할 수 있다.

보안 민감 코드베이스에 투입할 에이전트는 기능 테스트만으로 통과시키지 않는다. 최소한 같은 과제에서 기능 성공, PoC 기반 취약점 검증, 신규 취약점 탐지를 함께 본다. 세 축 중 보안 검증에서 실패한 후보는 기능 성과와 별개로 자동 병합이나 자율 실행 범위를 허용하지 않는다.

또한 파일 수정과 도구 실행 권한을 주려면 샌드박스, 도구별 권한, 관리형 자격증명, 사람 승인, 감사 로그가 먼저 있어야 한다. 이 조건을 갖추지 못했다면 에이전트는 코드 제안이나 제한된 로컬 실험 수준에 두는 것이 더 낫다.

현재 근거가 말하는 것은 “단일 표준 평가 프레임워크가 이미 공통 표준으로 굳었다”는 주장이 아니다. 더 정확한 결론은 이렇다. 기능 평가와 보안 평가를 한 과제 안에 묶는 방법은 가능하고, 저장소 에이전트의 위험 모델상 필요하다. 그러므로 실무자는 평가 관문을 먼저 바꿔야 한다.

Aionda

코드 에이전트 평가의 기능과 보안

코드 에이전트 평가는 “작동했는가”와 “안전했는가”를 분리하면 부족하다

왜 기능 점수만으로는 위험한가

통합 평가는 이미 구현 가능한 방향이다

저장소 에이전트에는 평가 외의 운영 통제도 필요하다

도입 판단 규칙

다음으로 읽기

참고 자료

업데이트 받기