SWE-agent: 인터페이스 디자인이 자동화된 소프트웨어 엔지니어링을 구현하는 방법
지난주에 SWE-bench 논문을 읽고 간단한 결론을 내렸습니다. 순수 GPT-4는 실제 GitHub 이슈의 1.96%만 해결한다는 것입니다. 이번 주에는 그 숫자를 실제로 움직이는 요인이 무엇인지 후속 질문을 이해하고 싶었습니다. Yang 등이 발표한 SWE-agent(NeurIPS 2024)가 이에 답을 제시하며, 그 답은 의외로 단순합니다. 바로 더 나은 인터페이스입니다.
논문 요약
SWE-agent(John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, Ofir Press; 프린스턴 / 스탠퍼드)는 **에이전트-컴퓨터 인터페이스(Agent-Computer Interface, ACI)**라는 개념을 도입합니다. 이는 LLM과 리눅스 환경 사이에 놓인 특수 목적의 소프트웨어 레이어로, 인간 사용 자가 아닌 언어 모델이 실제로 정보를 처리하는 방식에 맞춰 설계되었습니다. 이 논문의 주장은 자율 소프트웨어 엔지니어링 에이전트의 주요 병목 현상이 기본 모델이 아니라 이 인터페이스의 설계라는 점입니다.
시스템은 SWE-bench의 GitHub 이슈를 바탕으로 작동합니다. 이슈를 읽고, 저장소를 탐색하며, 관련 코드를 찾고, 수정하고, 수정을 확인하기 위해 테스트를 실행합니다. 이 논문의 독창적인 기여는 새로운 모델이나 학습 절차가 아니라, 기본 리눅스 셸을 대체하기 위해 세심하게 설계된 일련의 명령 프리미티브(command primitives)와 피드백 형식입니다.
핵심 아이디어
- 인터페이스가 원시 셸보다 10.7%포인트 더 우수한 성능을 보입니다. 300개의 SWE-bench Lite 인스턴스에 대한 절제 연구(ablation study)에서, SWE-agent는 단순 리눅스 셸에 배치된 동일한 에이전트보다 10.7%p 더 많은 이슈를 해결했습니다. 이것이 이 논문에서 가장 큰 레버리지 역할을 합니다.
- 100행 창을 사용하는 파일 뷰어. 전체 파일을
cat으로 출력하는 대신, ACI는 스크롤 명령을 통해 한 번에 약 100행씩 보여줍니다. 컨텍스트가 너무 적으면(30행) 3.7%p의 손실이 발생하고, 너무 많으면(전체 파일) 모델이 집중력을 잃습니다. 최적의 지점(sweet spot)은 좁습니다. - 편집 루프 내의 린터(Linter). 모든 편집 명령은 변경 사항을 커밋하기 전에 구문 검사기(syntax checker)를 실행합니다. 이를 통해 모델이 자연어만으로는 탈출하기 어려운 망가진 코드 상태에 갇히는 것을 방지합니다.
- 미니멀리즘 디렉토리 검색. 주변 컨텍스트를 포함하는
grep -r(모델을 압도함) 대신, ACI는 일치하는 파일 이름 목록만 반환합니다. 모델이 다음에 어디를 살펴볼지 결정해야 할 때는 '적은 것이 더 많은 것(Less is more)'이 됩니다. - 전체 벤치마크 결과: GPT-4 Turbo를 사용한 SWE-bench에서 12.47% 기록. 이는 3.8%의 비대화형 RAG 시스템과 원래 SWE-bench 논문의 단순 검색 베이스라인인 1.96%와 대조됩니다. HumanEvalFix는 87.7%에 도달했습니다.
- ACI 설계의 일반화. 사이버 보안 변형 모델(SWE-agent EnIGMA)은 동일한 ACI 철학을 CTF 챌린지에 적용하여, 동시 셸 세션을 유지하는 대화형 에이전트 도구를 사용해 이전 시스템보다 3배 강력한 13.5%의 성과를 거두었습니다.
유효한 점과 그렇지 않은 점
핵심 통찰력 — 에이전트를 위한 인터페이스 설계가 프롬프트 엔지니어링만큼 중요하다는 점 — 은 충분히 뒷받침되며 매우 유용하다고 생각합니다. 절제 연구는 정직합니다. 저자들은 구성 요소를 분리하고 각 구성 요소가 기여하는 바를 보여줍니다. 원시 셸 베이스라인 대비 10.7%p의 이득은 모델 차이로 설명할 수 없는 명확한 결과입니다.
덜 확신이 가는 부분은 벤치마크 자체입니다. SWE-bench 테스트 세트에는 복잡성, 모호성, 그리고 정답 패치(ground-truth patch)가 얼마나 잘 지정되어 있는지에 따라 매우 다양한 이슈가 포함되어 있습니다. 이슈 품질의 높은 편차는 12.47%라는 수치가 평가 세트에 어떤 이슈가 포함되었느냐에 따른 결과일 수도 있음을 의미합니다. 저자들은 절제 연구를 위해 SWE-bench Lite(300개 이슈)의 결과를 보고하며 이를 암시적으로 언급했지만, 해당 하위 세트 내에서도 편차는 여전히 높습니다.
더 큰 한계는 범위입니다. SWE-bench는 단일 이슈 해결을 고립된 상태에서 측정합니다. 이슈 간의 세션 메모리도 없고, 코드베이스 이력에 대한 이해도 없으며, 다중 이슈 종속성 추적도 없습니다. 이후 SWE-Bench Pro(arXiv:2509.16941, 2025)는 이슈가 여러 파일에 걸친 조정된 변경을 요구할 때 프런티어 모델조차 25% 미만으로 떨어진다는 것을 보여주었습니다. 파일 수가 증가함에 따라 성능은 급격히 저하됩니다. ACI는 단일 이슈 내에서는 도움이 되지만, 어려운 문제는 SWE-agent가 해결하도록 설계되지 않은 장기적인(long-horizon) 다중 파일 케이스입니다.
또한 반복적으로 떠오르는 재현성 질문이 있습니다. 인터페이스 설계 선택(100행 창, 미니멀리스트 검색 출력)은 훈련/개발 세트에서의 반복적인 실험을 통해 발견되었습니다. 이러한 선택들이 유사한 튜닝 노력 없이 새로운 도메인으로 명확하게 전이될지는 미지수입니다. 이는 실질적인 비용입니다.
금융 AI(Finance AI)에 중요한 이유
ACI 프레임워 크는 Beancount 에이전트 설계 문제에 직접적으로 연결됩니다. Beancount 원장(ledger)은 명령줄은 아니지만, 모델이 읽고 탐색하고 작성해야 하는 구조화된 결과물입니다. 여기서 얻을 수 있는 교훈은 다음과 같습니다:
- 스크롤 및 필터 명령을 갖추고 한 번에 20~50개의 트랜잭션을 보여주는 원장 뷰어는 10년 치 데이터를 한꺼번에 쏟아내는 방식보다 성능이 뛰어날 것입니다. 컨텍스트 창 오버플로는 동일한 실패 모드입니다.
- 항목을 커밋하기 전에 복식 부기 잔액(double-entry balance)과 계정 존재 여부를 확인하는 **작성 유효성 검사기(write validator)**는 SWE-agent 린터의 원장 버전입니다. 이것이 없다면 구문적으로 틀린 항목을 생성한 에이전트는 복구할 방법이 없습니다.
- 미니멀리즘 검색이 중요합니다. "날짜 Y와 Z 사이의 계정 X에 있는 모든 트랜잭션 표시"라는 쿼리는 주변 컨텍스트가 포함된 장황한 데이터가 아니라 압축되고 훑어보기 쉬운 목록을 반환해야 합니다.
이 논문은 또한 Beancount 자동 기록(write-back) 에이전트의 초기 버전에서 기대할 수 있는 수준에 대한 실질적인 벤치마크를 설정합니다. 잘 정의된 GitHub 이슈에 대한 12.47%의 해결률은 세심하게 설계된 단일 이슈 에이전트의 현재 상한선입니다. 원장 자동 기록은 사용자 의도, 구조화된 파일, 필수 출력, 검증기라는 유사한 작업 구조를 가지고 있습니다. 잘 정의된 작업에서는 비슷한 수준의 성공률을 기대할 수 있지만, 다중 항목(multi-entry), 다중 계정(multi-account) 워크플로에서는 급격한 성능 저하가 예상됩니다.
더 읽어볼 자료
- MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — SWE-agent의 컨텍스트 관리는 반응형(오버플로 시 절단)입니다. MemGPT는 선제적인 계층형 메모리를 제안하며, 이는 수년간의 Beancount 원장을 추론해야 하는 에이전트에게 필수적으로 보입니다.
- SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — SWE-agent가 부족한 부분을 직접적으로 추적합니다. 다중 파일 성능 저하 데이터는 복잡한 원장에서 자동 기록의 안전성을 설계할 때 필수적으로 읽어야 할 자료입니다.
- Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — ACI가 인터페이스 디자인에 관한 것이라면, Gorilla는 API 검색에 관한 것입니다. 이 두 가지가 결합되어 에이전트가 도구를 안정적으로 선택하고 호출하는 방법에 대한 더 완전한 그림을 완성합니다.
