본문 바로가기
카테고리 없음

SWE Agent (소프트웨어 에이전트)

by AteN 2026. 4. 12.

SWE Agent (소프트웨어 엔지니어링 에이전트)

소프트웨어 엔지니어링 에이전트는 코드를 한 번 생성하는 데서 끝나지 않고 이슈나 요구사항을 이해하고, 관련 코드를 탐색하고, 수정한 뒤 테스트 결과를 관찰해 다시 고치는 반복 루프를 실행합니다. 실제 소프트웨어 개발이 탐색, 수정, 실행, 검증을 여러 번 반복하는 과정이라는 점을 모델의 실행 구조에 옮긴 것입니다.

이 분야에서 중요한 변수는 모델 성능만이 아닙니다. 파일과 코드를 어떻게 검색하는지, 어느 범위까지 내용을 읽을 수 있는지, 편집과 셸 실행을 어떤 형태로 제공하는지, 테스트 결과를 어떻게 다시 모델에게 보여주는지에 따라 같은 모델도 다른 행동을 보일 수 있습니다. 특정 시스템인 SWE-agent가 ACI(Agent-Computer Interface)를 강조한 이유도 모델과 개발 환경 사이의 인터페이스 자체가 agent 성능에 영향을 주기 때문입니다.

평가에서는 SWE-bench 계열이 중요한 기준이지만 서로 다른 benchmark와 subset의 점수를 그대로 비교하면 안 됩니다. 원본 SWE-bench, Lite, Verified는 데이터 구성과 검증 수준이 다르고, SWE-bench Pro는 Scale AI가 더 긴 작업과 다양한 repository를 대상으로 별도로 만든 후속 benchmark입니다. 2026년에는 SWE-bench Verified에서 테스트 설계 문제와 데이터 오염이 공개적으로 지적됐고, 이후 대안으로 주목받은 SWE-bench Pro에서도 상당수 task의 평가 품질 문제가 다시 확인됐습니다.

따라서 SWE agent의 점수는 숫자 하나보다 어떤 데이터셋과 split을 사용했는지, 어떤 agent scaffold와 tool interface를 사용했는지, 어떤 evaluation harness와 실행 환경에서 측정했는지, 모델과 inference 조건이 무엇인지를 함께 확인해야 합니다.

1장. 코드 생성 모델과 무엇이 다른가

실제 개발은 한 조각으로 안 끝납니다.

이슈를 읽고
   ▼
관련 파일을 찾고
   ▼
고치고
   ▼
테스트를 돌려 확인하고
   ▼
안 되면 다시 위로

   이 루프가 다 돌아야 진짜 PR 이 된다

코드를 생성하는 모델과 이슈를 해결하는 에이전트의 차이가 바로 이 루프의 유무입니다.

자기 교정이 가능해집니다. 테스트가 실패하면 그 로그를 보고 다시 고치는데, 단발 생성은 틀려도 알 방법이 없습니다.

탐색도 가능해집니다. 어느 파일을 고쳐야 하는지 미리 몰라도 찾아가면서 합니다. 그리고 검증이 내장되어, 됐다는 것을 모델의 주장이 아니라 테스트 통과로 판정합니다.

단발 생성의 문제는 어떻게 더 좋은 코드를 뽑을까였고, 에이전트의 문제는 루프를 어떻게 안정적으로 굴릴까입니다. 모델 품질만의 문제가 아니게 됩니다.

2장. ACI, 이 분야의 중심 통찰

낯선 사무실에 온 신입. 잘 정리된 터미널과 이 파일의 이 문자열을 저것으로 바꾸라는 명확한 편집 명령을 주면 금방 일합니다. 아무 설명 없이 날것의 운영체제만 던져 주면 헤맵니다.

에이전트가 다루기 좋게 설계한 명령과 관찰 인터페이스가 ACI입니다.

논문의 핵심 주장.

LLM 에이전트는 새로운 종류의 사용자이며, 사람이 IDE의 덕을 보듯 전용 인터페이스의 덕을 본다.

사람용으로 만든 인터페이스가 에이전트에게 최적이 아니고, 에이전트용 인터페이스를 따로 설계하면 같은 모델의 성능이 달라진다는 뜻입니다.

구체적으로 무엇인가.

편집 도구가 정확한 문자열 매칭을 요구한다
   ──► 엉뚱한 위치를 고치는 실수가 줄어든다

절대 경로를 강제한다
   ──► 상대 경로 혼동으로 인한 실패가 사라진다

도구 설명과 명세에 공을 들인다
   ──► 도구 선택 오류가 줄어든다

편집 후 결과를 바로 보여준다
   ──► 잘못 고쳤을 때 즉시 알아챈다

undo 를 제공한다
   ──► 되돌릴 수 있으면 과감히 시도한다

LLM의 실패 중에는 모델 능력의 한계뿐 아니라 경로·편집 위치·도구 인자처럼 인터페이스가 유발하는 실수도 큰 비중을 차지할 수 있습니다. 줄 번호를 착각하고 경로를 헷갈리고 비슷한 문자열을 잘못 고릅니다. 이것은 인터페이스로 구조적으로 막을 수 있습니다.

즉 ACI 설계는 모델을 똑똑하게 만드는 것이 아니라 똑똑한 모델이 바보 같은 실수를 못 하게 막는 일입니다.

Anthropic도 별개의 실험에서 도구 설명에 공을 들이고 실수 방지 장치를 넣는 것이 성능에 크게 영향을 준다고 보고했습니다. 서로 다른 팀이 다른 경로로 같은 결론에 왔다는 것이 이 통찰의 신뢰도를 높입니다.

3장. 두 갈래

구분 코딩 에이전트 컴퓨터 사용 에이전트
다루는 대상 코드베이스. 파일, 터미널, 테스트 화면 픽셀. 임의의 GUI 앱과 OS
조작 방식 ACI 명령. 파일 편집, bash 실행, 검색 커서 이동, 클릭, 키보드 입력
관찰 형식 텍스트 스크린샷 이미지
강점 신뢰성과 속도 일반성. 코드가 없는 레거시 앱도 조작
약점 코드 밖 작업은 못 함 느리고 실수가 잦음
성공 신호 테스트 명확한 것이 없음
대표 SWE-agent, OpenHands, Aider, Claude Code Anthropic Computer Use

코딩 에이전트가 유리한 이유는 환경 자체에 있습니다. 관찰도 행동도 텍스트라 다루기 쉽고 빠르며 좌표를 계산할 필요가 없습니다. 무엇보다 테스트라는 명확한 성공 신호가 있습니다.

컴퓨터 사용 에이전트에는 이에 상응하는 신호가 없습니다. 잘 됐는지를 판정하기부터 어렵고, 화면이 바뀌었다고 목표를 이룬 것이 아닙니다.

API나 안정적인 자동화 인터페이스가 없는 레거시·GUI 중심 시스템도 여전히 많습니다. 레거시 사내 시스템과 데스크톱 전용 소프트웨어, 자동화를 막아 둔 웹사이트가 그렇습니다. 코드가 없으면 코딩 에이전트는 아무것도 못 합니다.

실무에서는 코드 작업은 코딩 에이전트에, GUI 전용이나 레거시 앱은 컴퓨터 사용 에이전트에 맡기고 섞어 쓰는 것도 흔합니다.

4장. 이슈 하나가 PR이 되기까지

시나리오는 이렇습니다.

이슈. parse_date() 가 끝에 Z 가 붙은 ISO 8601 문자열 "2026-01-01T09:00:00Z" 에서 ValueError 를 던진다.

GitHub 이슈 본문
   │
   ▼
관찰   이슈에 첨부된 재현 코드를 읽는다
       실패해야 정상인 테스트 (Fail-to-Pass) 가 딸려 있다
   │
   ▼
탐색   grep -rn "def parse_date" src/
       src/utils/dates.py 에서 찾았다
   │
   ▼
편집   파싱 전에 끝의 Z 를 +00:00 으로 바꾸는 한 줄을 넣는다
       정확 매칭을 요구하므로 엉뚱한 줄을 고칠 위험이 낮다
   │
   ▼
실행   pytest tests/test_dates.py
   │
   ├─ 실패 ──► 로그를 관찰하고 다시 편집 단계로
   │
   └─ 통과 ──► Fail-to-Pass 가 초록불로 바뀌고 기존 테스트도 통과
                │
                ▼
             변경분(diff)을 패치로 제출. 사람 리뷰로 넘어간다

grep이 얼마나 유용한 형태로 결과를 주는가라는 탐색, 정확 치환이 실수를 얼마나 막아 주는가라는 편집, 테스트 로그를 얼마나 읽기 좋게 주는가라는 실행입니다. 인터페이스가 이 셋을 얼마나 매끄럽게 해 주느냐가 곧 성능입니다.

Fail-to-Pass만 보면 증상을 가리는 패치가 통과할 수 있습니다. Pass-to-Pass도 함께 봐야 고치면서 다른 것을 깨뜨리지 않았다는 것이 확인됩니다.

5장. SWE-bench

원 SWE-bench는 12개 인기 Python 저장소의 실제 GitHub 이슈 2,294개를 모아, 이슈에서 패치로 가는 능력을 repository test로 자동 평가합니다. 자동 채점은 반복 가능하다는 장점이 있지만 테스트 자체가 요구사항을 완전히 포착하지 못하면 의미상 잘못된 patch도 통과할 수 있으므로 객관적 정답과 동일시하면 안 됩니다.

제안 당시 최고 모델조차 1.96%밖에 못 풀었습니다. 실제 이슈 해결은 여러 함수, 클래스, 파일에 걸친 변경을 조율해야 하고 어느 파일을 고칠지부터 찾아야 해서, 단발 코드 생성 능력과 다른 종류의 일입니다.

변형들.

변형 특징
Full 원본 2,294개
Lite 빠른 반복용 300개 부분집합
Verified 사람이 풀 수 있음을 검토한 500개 subset. 2024~2025에 널리 인용됐으나 2026년에는 오염·포화 문제가 크게 지적됨
Multimodal / Multilingual 시각 자산과 다국어로 확장
Pro 다파일 장기 작업의 오염 내성 확장. Verified보다 훨씬 어렵다

분화한 이유는 셋입니다. Verified 점수가 계속 오르면서 변별력이 준 포화, 원본 이슈가 학습 데이터에 섞였을 가능성인 오염, 그리고 실제 작업은 파일 하나 고치는 것으로 안 끝난다는 실무 대표성입니다.

같은 SWE-bench 몇 퍼센트라도 어느 부분집합인지, 어느 스캐폴드인지, 어느 하니스인지가 다르면 숫자를 나란히 놓는 것 자체가 무의미합니다.

그리고 출처를 구분합니다. 공식 리더보드와 원 논문은 검증된 수치이고 회사 발표는 주장입니다. 후자를 전자와 같은 표에 넣으면 안 됩니다.

6장. 대표 사례

SWE-agent. Princeton과 Stanford, MIT 라이선스입니다. ACI 개념의 원조이고 논문에서 SWE-bench pass@1 12.5%를 보고했으며 직전 최고 기록은 상호작용 없이 LM만 쓴 3.8%였습니다.

mini-SWE-agent. 같은 팀이 만든 것으로 bash 하나만 도구로 쓰는 약 100줄짜리 파이썬입니다. 복잡한 ACI 없이도 강한 모델에 단순 루프면 충분할 수 있음을 보여주고, SWE-bench Verified 74% 이상을 프로젝트 자체 보고로 주장합니다.

같은 연구 계열에서 더 얇은 scaffold도 강한 결과를 낸 것은, ACI의 적정 복잡도가 모델 능력과 평가 환경에 따라 달라진다는 신호로 읽는 편이 안전합니다. 풍부한 ACI가 불필요해졌다는 보편 결론은 아닙니다.

OpenHands. 구 OpenDevin으로 코딩과 명령 실행과 웹 브라우징을 하는 오픈 플랫폼입니다. 샌드박스 실행과 멀티 에이전트 조율, 벤치마크를 내장합니다.

Aider. 터미널 기반 페어 프로그래머입니다. git 저장소를 직접 편집하고 변경마다 자동 커밋합니다. 자동 커밋이 좋은 설계인데, 매 변경이 커밋이면 언제든 되돌릴 수 있어 에이전트가 과감히 시도할 수 있습니다.

Anthropic Computer Use. Claude가 화면을 보고 커서를 움직이고 클릭하고 입력합니다. 프런티어 모델 최초의 공개 베타 컴퓨터 사용 기능이었고, 스크롤, 드래그, 확대 같은 동작은 아직 서툴다고 공개적으로 인정했습니다.

Devin. Cognition이 최초의 AI 소프트웨어 엔지니어로 마케팅한 상용 제품입니다. 초기 기술 보고서는 SWE-bench 무작위 25% 부분집합에서 45분 제한으로 13.86% 해결을 회사 주장으로 제시했고 독립 검증 언급은 없습니다.

7장. 설계 논쟁

풍부한 ACI는 파일 탐색, 편집, 테스트를 위한 잘 다듬어진 명령 집합을 주는 것으로 약한 모델을 끌어올리는 데 효과적입니다. 얇은 스캐폴드는 범용 프롬프트에 bash 정도만 주고 단순한 루프를 도는 것으로, 강한 모델에서는 단순함의 이점이 큽니다.

Anthropic의 실험에서 상태가 유지되는 Bash 도구와 view, create, str_replace, insert, undo_edit를 지원하는 Edit 도구 단 둘로 개선판 Claude 3.5 Sonnet이 SWE-bench Verified 49%를 냈습니다. 직전 최고 45%를 넘긴 결과입니다.

도구를 몇 개 주느냐가 아니라 각 도구의 인터페이스를 얼마나 신중히 설계했느냐가 문제입니다. Edit 도구에 undo가 있고 str_replace가 정확 매칭을 요구한다는 것이 바로 그 설계입니다. 도구 개수는 둘인데 그 안의 연산 설계는 정교합니다.

어느 쪽이 이기는지는 상당 부분 모델의 강함에 달려 보입니다. 다만 mini-SWE-agent의 74%대나 Devin의 13.86% 같은 수치는 대개 자체 보고라 동일 조건에서의 독립 비교가 없다는 점은 그대로 남습니다.

읽는 법이 있습니다. 얇은 스캐폴드가 이겼다가 아니라 강한 모델에서는 얇아도 된다는 정황이 있다는 것, 이 정도가 지금 말할 수 있는 최대입니다.

8장. 비용과 실패 모드

관찰, 추론, 행동의 루프라 관찰마다 LLM을 다시 호출합니다. 토큰과 지연이 단계 수에 대략 비례해서 한 작업에 수십에서 수백 번의 호출과 수십 분의 런타임이 듭니다. 한 번에 코드를 뽑는 것과는 비용 구조가 다릅니다.

대화 이력을 매 턴 통째로 다시 보내는 구현에서는 누적 처리 토큰량이 step 수에 따라 빠르게 증가할 수 있습니다. 컨텍스트 길이 자체는 새 관찰이 붙는 만큼 늘지만, 매 호출마다 이전 이력을 다시 처리하기 때문에 총 입력 토큰 비용은 단순 선형보다 커질 수 있습니다. prefix caching이나 compaction을 쓰면 이 비용 구조도 달라집니다.

종료 가드가 없으면 같은 시도를 반복합니다. 파일을 고치고 테스트하고 되돌리기를 반복하거나 같은 grep을 계속 실행합니다. 스텝 상한과 타임아웃이 필수입니다.

긴 테스트 로그가 창을 잡아먹습니다. 스택 트레이스 하나가 수천 토큰일 수 있어 몇 번만 돌려도 컨텍스트가 찹니다.

실무에서는 테스트 로그는 실패한 부분만 남기고, 성공한 테스트는 개수만 보고하며, 같은 오류가 반복되면 한 번만 보여줍니다.

가장 다루기 까다로운 문제입니다. 테스트는 통과했지만 의미상 틀린 변경으로, 테스트를 우회하거나 증상만 가리거나 특정 케이스에만 맞는 하드코딩을 넣거나 테스트가 없는 다른 케이스를 깨뜨립니다.

자동 채점의 맹점인 이유가 있습니다. 테스트가 성공 신호인 구조라 테스트가 놓치는 것은 에이전트도 놓칩니다. 그리고 점수는 테스트 통과율이라 벤치마크 점수에도 안 잡힙니다.

완화책은 기존 테스트를 수정하지 못하게 하고, 패치 크기에 상한을 두고, 변경 이유를 설명하게 하고 그 설명을 리뷰하며, 사람 리뷰를 유지하는 것입니다. 사람 리뷰가 여전히 필요한 이유가 이것이고 점수가 높아도 이 문제는 남습니다.

9장. 발전사

시기 발전
2023-10 SWE-bench 제안. 실제 이슈 2,294개, 당시 최고 모델 1.96%
2024-03 Devin. 제품 마케팅의 시작, 회사 주장 13.86%
2024-05 SWE-agent. ACI 개념 도입, pass@1 12.5%
2024-07 OpenHands. 오픈 플랫폼화
2024-10 Anthropic Computer Use. GUI 조작 공개 베타
2024 후반 최소 스캐폴드로 SWE-bench Verified 49%
2025 이후 단순화와 오염 내성. mini-SWE-agent, SWE-bench Pro

흐름이 읽힙니다. 벤치마크가 먼저 생겨 잴 수 있게 되니 경쟁이 시작됐고, 인터페이스 설계가 성능을 올렸는데 모델이 약할 때 효과가 컸습니다. 모델이 강해지자 스캐폴드가 얇아져 기법이 모델 안으로 흡수되는 패턴이 여기서도 반복됐고, 포화와 오염에 대응해 벤치마크가 다시 어려워졌습니다.

10장. 정리

소프트웨어 에이전트의 본질은 루프입니다. 보고, 고치고, 테스트로 확인하는 반복이 단발 코드 생성과의 차이입니다.

모델만큼 인터페이스가 중요합니다. ACI 설계는 똑똑한 모델이 바보 같은 실수를 못 하게 막는 일입니다.

테스트가 성공 신호라는 것이 강점이자 한계입니다. 테스트가 놓치는 것은 에이전트도 놓치고 벤치마크 점수에도 안 잡힙니다.

어느 부분집합인지, 어느 스캐폴드인지, 자체 보고인지 리더보드인지를 확인하지 않은 비교는 숫자가 커 보일 뿐 의미가 없습니다.

오탐 패치를 자동으로 잡는 법이 가장 실무적인 미해결 문제입니다. 컴퓨터 사용에는 테스트에 상응하는 성공 신호가 없고, 수백 턴짜리 장기 작업에서 무엇을 남기고 버릴지의 컨텍스트 관리도 남아 있습니다. 이 이슈를 고치는 데 얼마 들지를 미리 아는 비용 예측도 아직입니다.

용어 정리

용어 한 줄 뜻
SWE 에이전트 코드베이스를 자율 조작해 이슈를 해결하고 PR을 만드는 에이전트
컴퓨터 사용 에이전트 화면을 보고 클릭과 입력으로 OS를 조작하는 에이전트
ACI (Agent-Computer Interface) LLM 에이전트가 다루기 쉽게 설계한 명령과 관찰 인터페이스
스캐폴드 모델 주위를 감싸는 도구와 프롬프트와 루프 등 외부 골격
SWE-bench 실제 GitHub 이슈를 단위 테스트로 채점하는 벤치마크
Verified / Lite / Pro SWE-bench의 부분집합과 확장 변형. 점수 스케일이 서로 다름
pass@1 한 번의 시도로 작업을 해결한 비율
Fail-to-Pass 패치 후 통과해야 하는, 채점 신호가 되는 테스트
Pass-to-Pass 패치 후에도 계속 통과해야 하는 기존 테스트
데이터 오염 벤치마크가 학습 데이터에 섞여 점수가 부풀려지는 현상
오탐 패치 테스트는 통과하지만 의미상 틀린 변경
실수 방지 설계 절대 경로 강제나 정확 매칭처럼 오류를 구조적으로 막는 장치

참고자료

댓글

티스토리툴바