자율 코딩 에이전트 지형(2026)

SWE-bench Verified는 3년도 안 되는 시간 동안 4%에서 80.9%까지 올라갔습니다. 같은 Claude Sonnet 4.5 모델도 SWE-agent v1에서는 43.2%, Cline 자율(autonomous) 모드에서는 59.8%를 기록했습니다. 이제 모델을 둘러싼 스캐폴딩(scaffolding)이 모델 자체만큼 중요합니다. OpenHands(이전 OpenDevin)는 가장 활발한 MIT 라이선스 플랫폼이며, CodeAct 루프는 JSON 도구 호출(JSON tool call) 대신 샌드박스(sandbox) 안에서 파이썬 액션(Python action)을 직접 실행합니다. 그러나 이 표면적 숫자(headline number)는 방법론적 문제를 가립니다. SWE-bench Verified 500개 작업 중 161개는 12줄만 바꾸면 되고, 10줄 이상 수정이 필요한 SWE-bench Pro에서는 같은 프런티어(frontier) 모델도 2359% 범위에 머뭅니다.

유형: Learn 언어: Python(stdlib, CodeAct와 JSON 도구 호출 비교) 선수 조건: Phase 14 · 07(도구 사용), Phase 15 · 01(장기 수행 에이전트) 예상 시간: 약 45분

문제

"어떤 코딩 에이전트가 최고인가"는 잘못된 질문입니다. 올바른 질문은 이것입니다. 내 업무와 맞는 작업 분포에서, 내가 프로덕션에서 실제로 실행할 스캐폴딩을 사용했을 때 처음부터 끝까지의 신뢰성(end-to-end reliability)이 얼마나 나오는가?

2022년부터 2026년 사이에 이 분야는 스캐폴딩이 하중을 지탱한다(load-bearing)는 사실을 배웠습니다. 검색 계층(retrieval layer), 계획기(planner), 샌드박스, 수정-검증 루프(edit-verify loop), 피드백 형식이 모두 중요합니다. Claude Sonnet 4.5는 SWE-agent v1에서 SWE-bench Verified 43.2%를 기록했지만, 같은 모델이 Cline의 자율 스캐폴드 안에서는 59.8%를 기록했습니다. 모델 가중치(weights)는 동일한데 절대 점수 차이가 16.6%포인트(p)에 달합니다. 기본 모델은 하나의 구성요소이며, 루프 전체가 곧 제품인 셈입니다.

이와 함께 따라오는 문제가 벤치마크 포화(benchmark saturation)가 성능 회귀(regression)를 가린다는 점입니다. SWE-bench Verified는 이미 포화에 가깝고, 쉬운 작업 꼬리(easy-task tail), 즉 500개 중 161개 작업이 2줄 이하 수정만 요구한다는 점이 상위 점수를 끌어올립니다. 실제 품질은 SWE-bench Pro처럼 10줄 이상 변경이 필요한 분포에서 더 정확하게 측정됩니다. 이 분포에서는 같은 선두 모델도 여전히 23~59% 수준에 머뭅니다.

개념

SWE-bench를 한 문단으로 설명하기

SWE-bench(Jimenez et al.)는 실제 GitHub 이슈와 그에 대한 정답 패치(ground-truth patch)를 가져와, 에이전트가 테스트 스위트(test suite)를 통과시키는 패치를 직접 만들도록 요구합니다. SWE-bench Verified(OpenAI, 2024)는 모호하거나 깨진 작업을 제거한 뒤 사람이 직접 선별한 500개 작업의 하위 집합입니다. SWE-bench Pro는 더 어려운 후속 벤치마크입니다. 10줄 이상 변경이 필요한 작업으로 구성되며, 현재 프런티어 에이전트도 23~59% 수준에 머뭅니다.

2022 → 2026 곡선이 실제로 보여주는 것

• 2022: 연구 모델은 원본 SWE-bench(raw SWE-bench)에서 약 4% 수준이었습니다.
• 2024: GPT-4와 Devin 스타일 스캐폴딩은 약 14%, SWE-agent는 약 12%였습니다.
• 2025: Claude 3.5/3.7 Sonnet을 Aider와 SWE-agent 안에서 실행한 시스템들이 40~55% 범위로 올라섰습니다.
• 2026: Claude Sonnet 4.5와 경쟁 프런티어 모델들이 SWE-bench Verified에서 70~80% 이상에 도달했습니다. Epoch AI의 리더보드(leaderboard)는 이를 실시간으로 추적합니다.

이 가파른 상승 기울기는 세 가지 원천이 복리로 작용한 결과입니다. 더 나은 기본 모델, 더 나은 스캐폴딩(CodeAct, 반영 루프(reflection), 검증기 루프(verifier loop)), 그리고 더 나은 벤치마크(Verified가 잡음(noise)을 제거한 점)가 그것입니다.

CodeAct 대 JSON 도구 호출

OpenHands(All-Hands-AI, arXiv:2407.16741, 이전 OpenDevin)는 매우 뚜렷한 아키텍처 결정을 내렸습니다. 모델이 호스트(host)가 디코딩(decoding)해 실행하는 JSON 도구 호출을 내보내는 대신, 파이썬 코드를 직접 내보내고 주피터(Jupyter) 스타일의 커널(kernel)이 그 코드를 샌드박스에서 실행합니다. 에이전트는 하나의 액션(action) 안에서 파일을 반복해 읽고, 여러 도구를 연결하며, 자신의 예외(exception)까지 잡아낼 수 있습니다.

이때의 트레이드오프(trade-off)는 다음과 같습니다.

• JSON 도구 호출(JSON tool calls): 모든 액션이 한 번의 턴(turn) 안에서 일어납니다. 감사가 쉽고 조합성(compositionality)은 제한적이지만, 각 호출이 명시적 검증기(validator)를 통과하기 때문에 기본적으로 더 안전합니다.
• CodeAct: 하나의 액션이 프로그램 한 편 전체가 될 수 있습니다. 조합성은 높지만 강하게 격리된 샌드박스가 반드시 필요합니다(OpenHands는 Docker 격리(isolation)를 사용합니다). 실패 모드(failure mode)는 샌드박스 런타임(runtime)이 허용하는 모든 동작을 포함합니다.

두 아키텍처 모두 프로덕션에서 사용됩니다. CodeAct는 OpenHands와 smolagents 같은 오픈 플랫폼에서 우세합니다. JSON 도구 호출은 실행기(executor)를 제공자가 통제하는 관리형 서비스, 예컨대 Anthropic Managed Agents나 OpenAI Assistants에서 여전히 우세합니다.

2026년 지형의 스캐폴드들

스캐폴딩이 지배적인 이유

코딩 실행은 장기 수행 궤적(long-horizon trajectory)입니다(Lesson 1). 신뢰성은 단계마다 복리로 누적됩니다. 스캐폴딩이 점수를 끌어올리는 지점은 다음 세 곳입니다.

1. 검색(Retrieval): 읽어야 할 올바른 파일을 찾아내는 일은 눈에 잘 띄지 않는 병목입니다. SWE-agent의 ACI, OpenHands의 파일 인덱스(file-index), Aider의 저장소 지도(repo-map)는 모두 이 지점을 겨냥합니다.
2. 검증기 루프(Verifier loop): 테스트를 실행하고, 스택 추적(stack trace)을 읽고, 다시 시도하는 일은 SWE-bench에서 절대 점수 10%포인트 이상의 차이를 만듭니다.
3. 실패 격리(Failure containment): 오류 발생 시 롤백(rollback)하는 샌드박스는 손상이 복리로 커지는 것을 막아 줍니다. 같은 모델이라도 검증기 루프 유무에 따라 전혀 다른 제품처럼 보입니다.

벤치마크 포화와 실제 분포

OpenHands 저자들과 Epoch AI는 모두 SWE-bench Verified에 쉬운 꼬리가 존재한다고 지적합니다. 500개 작업 중 161개는 12줄만 바꾸면 끝납니다. 높은 점수는 일부분 이 꼬리에서 만들어집니다. SWE-bench Pro는 10줄 이상 변경으로 제한하며, 프런티어 시스템조차 2359% 범위의 점수에 머뭅니다. 여러분의 프로덕션 분포는 거의 틀림없이 Verified보다 Pro에 더 가깝습니다.

에이전트를 고를 때의 함의는 명확합니다. 여러분의 버그 백로그(backlog)에서 Pro와 비슷한 하위 집합을 직접 실행해 보세요. 중요한 점수는 여러분이 실제로 배포하는 작업을 대표하는 작업에서 얻은 점수입니다.

사용해보기

code/main.py는 고정된 미니 작업 분포 위에서 두 가지 장난감(toy) 에이전트 스캐폴드를 비교합니다.

1. 턴(turn)마다 하나의 액션(action)을 수행하는 JSON 도구 호출(JSON tool-call) 스캐폴드.
2. 액션마다 작은 파이썬 스니펫(Python snippet)을 내보낼 수 있는 CodeAct 스캐폴드.

두 스캐폴드 모두 결정적 규칙으로 동작하는 스텁(stub) "모델"을 사용하므로, 비교는 모델 품질이 아니라 스캐폴드 차이만 분리해 보여줍니다. 출력은 CodeAct 스캐폴드가 더 적은 턴으로 더 많은 작업을 해결하지만, 액션 하나당 영향 반경(blast radius)이 더 크다는 사실을 드러냅니다.

산출물 만들기

outputs/skill-scaffold-audit.md는 코딩 에이전트 스캐폴드를 도입하기 전에 감사(audit)할 수 있도록 돕습니다. 검색 품질, 검증기 유무, 샌드박스 격리, 벤치마크와 실제 분포의 적합성을 점검합니다.

연습문제

1. (쉬움) code/main.py를 실행하세요. 같은 작업 집합에서 각 스캐폴드는 몇 턴(turn)을 사용하나요? 각 액션의 영향 반경(blast radius)은 얼마인가요?

2. (중간) OpenHands 논문(arXiv:2407.16741)을 읽으세요. 이 논문은 복잡한 작업에서 CodeAct가 JSON 도구 호출보다 우수하다고 주장합니다. 논문이 인정하는 실패 모드 하나를 찾고, 그 모드가 프로덕션에서 언제 지배적이 될지 한 문장으로 정리하세요.

3. (중간) 여러분의 버그 백로그에서 두 파일에 걸쳐 10줄 이상 수정이 필요한 작업 하나를 고르세요. 프런티어 모델이 (a) JSON 도구 호출, (b) CodeAct 환경에서 처음부터 끝까지 성공할 확률을 추정하고, 두 확률 사이의 차이를 근거와 함께 설명하세요.

4. (어려움) SWE-bench Verified에는 단일 파일, 1~2줄 작업이 161개 있습니다. 이를 제외하고 점수를 다시 구성해 보세요. 리더보드의 순위는 어떻게 뒤바뀌나요?

5. (어려움) OpenAI의 "Introducing SWE-bench Verified"를 읽으세요. 모호한 작업을 제거하기 위해 사용된 구체적 방법론을 설명하고, 그 선별 과정이 놓칠 만한 범주 하나를 제시하세요.

핵심 용어

더 읽을거리

• Jimenez et al. — SWE-bench — 원본 벤치마크와 방법론입니다.
• OpenAI — Introducing SWE-bench Verified — 선별된 하위 집합이 어떻게 만들어졌는지 설명합니다.
• Wang et al. — OpenHands: An Open Platform for AI Software Developers — CodeAct 아키텍처와 이벤트 스트림 설계입니다.
• Epoch AI — SWE-bench leaderboard — 실시간 추적 점수입니다.
• Anthropic — Measuring agent autonomy — 장기 수행 코딩 에이전트 신뢰성 프레이밍입니다.