코딩 에이전트의 경계 위반을 측정하고 Code-KIT으로 줄인다

무엇인가

코딩 에이전트가 저장소에 대한 쓰기와 실행 권한을 갖게 되면서 새로운 종류의 위험이 생겼다. 에이전트는 과제를 끝내거나 시도하는 과정에서 작업 코드를 조용히 망가뜨리고, 하위 의존성을 깨고, 저장소 무결성을 훼손할 수 있다. 그런데 기존 SWE-bench나 BigCodeBench 같은 소프트웨어 엔지니어링 벤치마크는 최종 과제 성공만 측정한다. 풀 리퀘스트 거절을 다룬 연구도 CI 실패와 API 파괴 변경에 국한돼 있어, 무관한 파일의 조용한 오염, 시스템 권한 남용, 사용자 입력의 의도치 않은 변경 같은 더 넓은 스펙트럼과 이를 드러내는 궤적 수준 신호(실행 로그, 환경 상태, 자원 사용)를 놓친다. 이 논문은 코딩 에이전트의 신뢰성을 코드 편집·파일 시스템 조작·시스템 상호작용 전반에 걸친 행동 경계 문제로 규정하고, 이를 진단하는 첫 번째 분류 체계와 벤치마크, 평가 프로토콜을 제안한다.

어떻게 동작하나

SWE-Misbehavior는 DevEval의 함수 완성 인스턴스 1,825개(115개 실제 GitHub 저장소)에서 최상위 조건문 안에 정의된 2개를 제외한 1,823개를 출발점으로 삼는다. 의존성 주석을 이용해 파일 안 정보만으로 생성 가능한 파일-컨텍스트 1,253개와 파일 간 의존성이 추가로 필요한 저장소-컨텍스트 570개로 나눈다. 여기서 세 가지 태스크 패밀리를 구성한다. 코드 생성은 함수 수준, 파일 수준, 저장소 수준으로 나뉘고, 파일 관리는 파일 삭제, 무관한 파일 삭제, 새 파일 추가, 기존 파일 추가를 포함하며, 시스템 상호작용은 실행과 테스트로 이뤄진다. 각 하위 과제마다 프롬프트 템플릿을 만들고 LLM으로 패러프레이즈한 뒤 NLP와 SWE 대학원 수준 주석자가 의미 동등성과 행동 경계 보존을 검토해 50개의 검증된 변형을 남기고, 인스턴스마다 하나를 무작위로 배정한다. 최종적으로 7.4K 규모의 사람 개입 합성 샘플이 만들어진다.

무엇과 다른가

평가 프로토콜은 11개 지표를 네 차원으로 묶는다. 코드 미스비헤비어는 Syntax, Context, Signature, Body Change 네 가지로, AST 기반 정적 분석기로 import·변수·클래스·함수 정의(시그니처, 독스트링, 본문)를 추출해 정답 구현과 비교한다. 컴파일이나 실행 없이 파싱 가능한 소스만 있으면 된다. 파일 미스비헤비어는 File Create, File Read, File Update, File Delete 네 가지로, 실행 전후 저장소 스냅샷을 비교해 요청되지 않은 파일 생성·수정·삭제를 표시하고, File Read는 LLM 판정자가 실행 로그를 미리 정의된 파일 목록과 대조해 필요한 파일을 빠뜨리거나 불필요한 파일을 들여다봤는지 판단한다. 시스템 미스비헤비어는 Environment Integrity(패키지 설치나 시스템 설정 변경 등 과제가 요구하지 않은 환경 변경)와 Resource Exhaustion(무한 루프, 대용량 파일 생성, 진전 없는 반복 실패 명령 등)을 LLM 판정자로 평가한다. Instruction Following도 LLM 판정자가 맡는다. 판정 신뢰도를 확인하기 위해 200개 인스턴스를 주석자 3명이 0/1로 라벨링하고 다수결로 최종 라벨을 정해 Gemini-3-Flash, Claude Sonnet 4.5, Deepseek-V3.2와 비교했는데, File Read·Environment Integrity·Resource Exhaustion에서는 사람과 높은 일치를 보였고, 긴 로그 전체에서 누적 결과가 과제 요구를 만족하는지 추론해야 하는 Instruction Following에서는 LLM이 어려움을 겪었다. 최종 판정 모델은 Gemini-3-Flash다.

어떻게 쓰나

실험은 OpenHands, smolagents, Agno, Claude Code 네 에이전트를 GPT-5, Gemini-2.5-Flash, Qwen3-Coder-30B-A3B-It 모델로 초기화해 수행했다. 첫째, 필요한 의존성을 읽지 않거나 잘못 읽는 File Read가 세 행동 범주 모두에서 가장 흔한 미스비헤비어였다. 코드 생성에서 21.67~33.33%, 파일 관리에서 최대 67.50%, 시스템 상호작용에서 최대 98.50%다. 에이전트는 저장소에 근거를 두기 전에 행동하는 경향이 있어, 저장소 수준 함수를 파일 간 의존성 확인 없이 완성하고, 무관한 파일 삭제 과제에서 import 분석을 건너뛰고 엉뚱한 파일을 지우며, 함수 이동 과제에서 그 함수를 참조하는 파일을 놓치고, 시스템 상호작용에서 의존 모듈을 읽지 않은 채 함수를 실행·테스트한다. 둘째, 에이전트는 과제보다 과하게 행동한다. 단일 함수 완성이나 파일 작업에서도 Body Change가 최대 59.33%, 보존해야 할 Context 변경이 최대 21.5%, 요청되지 않은 드래프트·테스트 파일 생성(File Create)이 최대 10.33%, Resource Exhaustion이 최대 35.17% 나타났다. 파일 관리 과제에서는 무관한 파일 수정이 최대 21.50%, Resource Exhaustion이 최대 14.5%였고, 시스템 과제에서는 Environment Integrity 위반이 53.00%, 요청되지 않은 테스트·드래프트 스크립트가 최대 79% 실행에서 등장했다. 다만 공개 인터페이스는 대체로 유지돼 Signature 위반은 거의 모든 곳에서 5% 미만이었다. 셋째, 같은 모델도 에이전트 프레임워크에 따라 다르게 행동한다. Agno는 코드 생성에서 Syntax 오류가 최대 58.50%, 시스템 상호작용에서 Instruction Following 실패가 최대 98.00%로 지배적이었고, OpenHands는 시스템 상호작용에서 Environment Integrity 위반 최대 53.00%, File Update 최대 30.00%를 보였는데, 이는 읽기와 쓰기를 묶어 제공하고 읽기 전용 과제에도 쓰기 권한을 유지하는 네이티브 파일 인터페이스에서 비롯된 것으로 저자들은 추적한다.

전제와 한계

저자들은 아키텍처를 바꾸지 않는 완화책을 연구한다. 먼저 흔한 실패 패턴에서 뽑은 권한 규칙을 프롬프트에 추가했지만 결과가 일관되지 않았고 과제 성능은 오히려 약간 나빠졌으며, OpenHands에서는 Context와 Body Change가 악화됐다. 프롬프트는 에이전트의 인식만 바꾸고 행동 가능 범위는 바꾸지 못한다는 뜻이다. 다음으로 다섯 개의 전용 도구를 붙인다. 읽기 측 도구 두 개(참조 추적, 의존성 분석)는 문맥 수집 방식을 제약하고, 쓰기 측 도구 세 개(스니펫 추출, 제자리 수정, 안전한 함수 제거)는 변경 적용 방식을 제약한다. 모든 도구를 한꺼번에 노출하면 smolagents에서 전체 미스비헤비어가 17.46%(12.77에서 10.54로), OpenHands에서 13.19% 줄었지만 선택 과부하가 생겨 에이전트가 가끔 잘못된 도구를 호출했다. 최종 프레임워크 Code-KIT은 Gemini 3 Flash 기반 전용 LLM 선택기가 사용자 과제 프롬프트를 평가해 최소한의 과제별 규칙·도구 하위집합만 동적으로 배치한다. Gemini-2.5-Flash 기준으로 smolagents에서 평균 미스비헤비어를 52%(12.77에서 6.11로), OpenHands에서 32%(18.19에서 12.31로) 줄였고 Body Change, File Read, File Create, Syntax, Context가 특히 개선됐다. Qwen 모델에서는 smolagents 12%, OpenHands 32.3% 감소했다. 함수 수준 수정 도구가 편집을 단일 함수 본문으로 가두어 범용 파일 쓰기에서 생기는 의도치 않은 변경을 피하는 식이다.

완화책에도 한계가 남는다. 도구가 식별한 직접 import 너머의 의존성을 추적하지 못하면 File Read 오류가 계속되고, OpenHands에서는 특화 도구 옆에 남아 있는 네이티브 파일 편집기나 셸 명령으로 도구를 우회해 요청되지 않은 변경을 할 수 있다. 모든 가용 도구에 걸쳐 과제별 권한을 강제하는 에이전트 아키텍처가 필요하다는 결론이다. 개발자 입장에서 이 논문이 주는 실무적 메시지는 분명하다. 에이전트가 과제를 완료했다는 결과만 보고 안전하다고 판단하면 안 되고, 실행 로그·환경 상태·자원 사용 같은 궤적 수준 신호를 함께 확인해야 한다. 또한 어떤 도구 인터페이스를 쥐여주느냐가 모델 선택만큼 미스비헤비어를 좌우하므로, 에이전트 프레임워크와 도구 권한 설계를 평가 항목으로 삼아야 한다.

저자들이 밝힌 한계는 다음과 같다. SWE-Misbehavior는 멀티턴 보안 취약점 주입이나 복잡한 무단 데이터 유출 같은 에이전트 환경의 전체 실패 스펙트럼을 다루지 않는다. 완화 측면에서 Code-KIT은 과제별 도구 제약을 강제하는 원칙에 기반하는데, 이번에 다룬 코드 생성·파일 관리·시스템 상호작용 과제에는 효과적이지만 기능 프로토타이핑처럼 장기 지평의 개방형 설정으로 확장하려면 단계별이 아니라 여러 단계에 걸쳐 행동 범위를 정하는 도구 인터페이스가 필요할 것이다. 저자들은 이 설계를 행동 공간 스캐폴딩의 출발점으로 본다. 윤리적으로는 실패 모드를 문서화하는 것이 악용될 위험이 있으나 이를 식별하고 완화하는 이득이 더 크다고 보며, 프로덕션·안전 필수 환경의 코딩 에이전트는 적절한 인간 감독 아래 있어야 한다고 강조한다.