[arXiv 2604.20779] SWE-chat: 실제 오픈소스 개발 로그로 본 코딩 에이전트의 사용 패턴과 실패 비용

SWE-chat: Coding Agent Interactions From Real Users in the Wild

https://arxiv.org/abs/2604.20779

Joachim Baumann, Vishakh Padmakumar, Xiang Li, John Yang, Diyi Yang, Sanmi Koyejo | Stanford University | arXiv:2604.20779 | 2026년 4월

---

1. 서론: 패치 벤치마크 밖으로 나가야 할 시점

최근 코딩 에이전트는 더 이상 연구 데모나 소수의 얼리어답터 도구가 아니다. 실제 개발자들은 이미 Claude Code, Cursor, Gemini CLI 같은 도구를 써서 코드를 읽고, 디버깅하고, 테스트를 돌리고, 커밋 직전의 수정까지 위임하고 있다. 그런데 지금까지 공개적으로 널리 쓰인 평가는 대체로 정제된 이슈 해결 벤치마크나 짧은 패치 생성 시나리오에 집중되어 있었다. 즉, 에이전트가 현실 개발 흐름에서 어떤 식으로 쓰이고 어디서 어긋나는지에 대한 실사용 로그 기반 증거는 의외로 많지 않았다.

이 논문이 흥미로운 이유는 바로 그 공백을 정면으로 겨냥하기 때문이다. 저자들은 실제 오픈소스 저장소에서 개발자들이 남긴 실제 프롬프트, 에이전트 응답, 툴 호출 궤적, 커밋 시점 코드 귀속 정보를 한 번에 묶은 데이터셋 SWE-chat을 제안한다. 논문의 관점은 단순한 성능 리더보드가 아니라, “사람은 코딩 에이전트를 무엇에 쓰고, 에이전트가 쓴 코드는 실제로 얼마나 살아남으며, 사용자는 어느 지점에서 자주 개입하는가”라는 운영 질문에 가깝다. 이 점 때문에 SWE-chat은 모델 자체의 절대 점수표보다 개발 워크플로의 실제 마찰면을 읽는 데 더 큰 가치가 있다.

논문이 공개한 규모도 작지 않다. 원문 기준 SWE-chat은 약 6,000개 세션, 63,000개 이상의 사용자 프롬프트, 355,000개 이상의 에이전트 툴 호출, 2.7M 로그 이벤트를 포함한다. 중요한 것은 이 숫자가 단순 대화 로그의 크기를 뜻하는 것이 아니라, 각 세션이 실제 저장소 변경과 연결되어 있다는 사실이다. 저자들은 이 점을 활용해 에이전트가 만든 코드 중 최종 커밋에 남은 부분과 인간이 덮어쓴 부분을 줄 단위(line-level)로 분리해 분석한다.

Figure 1: SWE-chat 데이터셋 수집 구조와 전체 규모 요약

Figure 1은 이 논문의 문제 설정을 한 장으로 압축한다. 공개 저장소에 Entire.io 기반 로그가 남으면, 연구진은 세션 transcript와 commit 결과를 연결해 사람 vs 에이전트 코드 귀속을 복원한다. 단순히 프롬프트 몇 개를 모은 것이 아니라, 실제 개발 작업의 시간 순서와 결과물을 함께 보존했다는 점이 핵심이며, 그래서 이 데이터셋은 패치 생성 성능보다 실전 사용 행태와 실패 비용을 분석하는 데 더 적합하다.

저자들은 이 데이터셋을 통해 두 가지 큰 질문을 던진다. 첫째는 RQ1으로, 개발자들이 실제 현장에서 코딩 에이전트를 어떤 종류의 작업에 어떻게 쓰는지다. 둘째는 RQ2로, 코딩 에이전트가 어디서 실패하고 사용자는 그 실패에 어떤 방식으로 반응하는지다. 다시 말해 이 논문은 “에이전트가 몇 문제를 맞혔는가”보다 “에이전트가 실제 개발 루프 안에서 어떤 역할을 맡고, 인간은 언제 그 결과를 받아들이거나 거부하는가”를 묻는다.

이 질문은 요즘 코딩 도구 담론과도 직접 닿아 있다. 한편에서는 vibe coding처럼 에이전트가 거의 전부를 작성하도록 맡기는 사용 패턴이 급격히 늘어나고 있고, 다른 한편에서는 긴 세션에서의 품질 회귀, 불필요한 수정, 보안 취약점 유입이 계속 문제로 지적된다. SWE-chat은 이 충돌을 정량화할 수 있는 몇 안 되는 공개 데이터셋으로 읽힌다. 그래서 이 논문은 특정 모델 홍보 글이 아니라, 코딩 에이전트를 실제로 쓰는 사람이라면 한 번쯤 꼭 읽어 둘 만한 운영 계측 논문에 가깝다.

Figure 2: 실제 사용 패턴과 실패 모드를 함께 요약한 SWE-chat의 중심 그림

Figure 2는 SWE-chat이 단순히 데이터셋 소개에서 멈추지 않고, 바로 사용 패턴 분석과 실패 분석으로 이어진다는 점을 보여준다. 왼쪽은 사람들이 코딩 에이전트를 무엇에 쓰는지, 오른쪽은 효율과 보안, 사용자 개입이라는 관점에서 어디서 문제가 생기는지를 정리한다. 즉 이 논문의 기여는 데이터 수집 자체에만 있지 않고, 그 데이터를 기반으로 현실 개발 워크플로에 맞는 평가 관점을 제안했다는 데 있다.

1.1 벤치마크가 놓친 것

기존 소프트웨어 에이전트 평가는 대체로 “이 이슈를 풀 수 있는가”, “패치를 성공적으로 제출하는가”에 집중해 왔다. 물론 이런 벤치마크는 여전히 중요하지만, 실제 개발 업무는 훨씬 넓다. 저장소 구조를 이해하는 일, 이미 존재하는 코드를 읽고 왜 그렇게 짜였는지 파악하는 일, 테스트 실패 원인을 찾아 재현하는 일, git으로 브랜치를 정리하고 커밋을 나누는 일은 현실 작업에서 매우 큰 비중을 차지한다. SWE-chat은 바로 이 넓은 범위를 데이터로 드러낸다.

논문이 특히 강조하는 지점은 코드 이해(code understanding)와 운영성 있는 툴 사용이다. 실제 사용 로그에서 가장 흔한 의도는 새로운 코드를 무조건 많이 쓰게 하는 요청이 아니라, 기존 코드를 이해하거나 디버깅하거나 저장소를 조작하는 일이다. 이 결과는 패치 생성 중심 벤치마크만으로는 코딩 에이전트의 실질적 역량을 온전히 측정하기 어렵다는 주장을 뒷받침한다. 에이전트가 얼마나 코드를 쓰는지보다, 언제 읽고 언제 검색하고 언제 사용자의 피드백을 받아 다시 바꾸는지가 더 중요하다는 뜻이다.

1.2 논문이 답하려는 두 질문

RQ1의 초점은 “사람이 코딩 에이전트를 실제로 어떻게 쓰는가”다. 저자들은 프롬프트 의도, 툴 호출 패턴, 저장소 도메인, 사용자 유형, 코딩 모드를 함께 본다. 여기서 코딩 모드는 인간이 전부 쓰는 human-only, 인간과 에이전트가 같이 쓰는 collaborative, 에이전트가 거의 전부를 작성하는 vibe coding으로 나뉜다. 이 구분은 이후 효율성과 보안 분석의 기준축이 된다.

RQ2의 초점은 “에이전트는 어디서 실패하고 사용자는 어떻게 반응하는가”다. 논문은 이 질문을 위해 session success rating, code survival, cost/time efficiency, Semgrep 기반 보안 취약점 도입률, clarification, user interruption, pushback 같은 지표를 만든다. 덕분에 이 논문은 단순히 성공/실패 이진 판정을 넘어서, 코딩 에이전트가 실전에서 만들어 내는 비용 구조와 인간 감독 부담까지 함께 보여준다.

2. 배경 및 관련 연구: SWE-bench 이후의 공백을 메우는 로그 데이터

SWE-chat의 위치를 이해하려면 먼저 기존 소프트웨어 에이전트 데이터셋이 어디에 초점을 맞췄는지 볼 필요가 있다. 대표적인 벤치마크는 실제 GitHub 이슈를 푸는 형태로 에이전트의 패치 능력을 재는데, 대부분은 문제 정의가 이미 정리된 상태에서 출발한다. 즉, 사용자가 처음 어떤 질문을 던졌고 중간에 어떤 식으로 요구를 수정했으며, 에이전트가 어느 순간 잘못된 방향으로 갔는지는 충분히 남지 않는다. 여기에 비해 SWE-chat은 결과물보다 상호작용 자체를 먼저 수집한다.

또 다른 흐름으로는 오픈소스 에이전트가 만들어 낸 trajectory 데이터셋이 있다. 이런 자료는 툴 호출과 코드 diff는 남기지만, 실제 인간이 무엇을 의도했고 어떻게 개입했는지에 대한 정보가 없는 경우가 많다. SWE-chat은 이 점에서 차별적이다. 저자들은 real human prompts, agent trajectories, code diffs, code attribution이 한 묶음으로 있는 첫 데이터셋이라고 주장한다. 이 구조 덕분에 에이전트가 실제로 개발자의 일을 얼마나 덜어주는지, 아니면 중간 결과를 많이 버리게 하는지를 보다 직접적으로 측정할 수 있다.

데이터셋	실제 인간 프롬프트	에이전트 trajectory	코드 diff	코드 귀속 정보
SWE-smith trajectories	아니오	예	예	아니오
CoderForge-Preview	아니오	예	예	아니오
SERA	아니오	예	예	아니오
nex-agi-agent-sft	아니오	예	예	아니오
SWE-rebench-openhands-trajectories	아니오	예	예	아니오
Agent Data Protocol	아니오	예	예	아니오
AIDev	아니오	아니오	예	아니오
AgentPack	아니오	아니오	예	아니오
SWE-chat	예	예	예	예

Table 1이 말하는 포인트는 단순하다. 기존 자료들은 대개 에이전트가 무엇을 했는가는 남기지만, 사용자가 왜 그렇게 시켰고 그 결과를 얼마나 받아들였는가를 끝까지 연결하지 못했다. SWE-chat은 이 빠진 고리를 메우기 위해 프롬프트와 궤적, 결과 코드를 한 자리에서 본다. 그래서 이 데이터셋은 학습용 코퍼스로서의 가치도 있지만, 그보다 먼저 평가와 진단을 위한 계측층으로서의 가치가 크다.

2.1 상호작용을 본다는 것의 의미

논문은 한 세션을 단순한 질문-답변 쌍으로 보지 않는다. 사용자 프롬프트가 들어오고, 에이전트가 응답을 내며, 그 사이에 파일 읽기, 검색, 수정, 셸 명령, 빌드, git 작업이 촘촘하게 끼어든다. 즉 실제 코딩 에이전트는 채팅 모델이 아니라 도구를 순차적으로 오케스트레이션하는 시스템이고, SWE-chat은 그 오케스트레이션 과정을 그대로 보존하려 한다.

Figure 3: SWE-chat이 포착하는 한 세션의 기본 구조

Figure 3은 SWE-chat이 왜 단순 대화 데이터셋이 아닌지를 보여준다. 한 세션 안에는 사용자 발화, 에이전트 서술, 툴 호출, 툴 결과가 교차하며, 실제로는 이 네 층이 함께 움직여야 하나의 작업이 끝난다. 이런 구조를 기록해 두어야만 “에이전트가 자주 읽기만 하다 끝나는지”, “계획 모드에서 오래 머무는지”, “수정 직전에 사용자가 자주 끊는지” 같은 운영 질문에 답할 수 있다.

이 관점은 최근 실서비스 웹 평가나 컴퓨터 사용 에이전트 신뢰성 논문과도 결이 맞는다. 즉, 에이전트 성능은 결과 한 장으로 끝나지 않고 반복 실행의 안정성, 중간 과정의 감독 가능성, 현실 환경에서의 마찰로 읽어야 한다는 것이다. SWE-chat은 코딩 영역에서 그 생각을 한 단계 더 밀어붙여, 아예 실제 커밋과 연결된 로그를 데이터셋의 기본 단위로 삼는다.

2.2 코드 귀속 정보가 왜 중요한가

코딩 에이전트를 평가할 때 가장 자주 빠지는 질문이 있다. 에이전트가 코드를 써 준 것은 알겠는데, 그 코드가 실제로 최종 산출물에 남았는가는 별개의 문제라는 점이다. 많은 로그 데이터셋은 에이전트가 어떤 패치를 제안했는지까지는 남기지만, 사용자가 그 패치를 받아들였는지, 일부만 남겼는지, 전부 지웠는지까지는 추적하기 어렵다. SWE-chat은 이 문제를 줄 단위 귀속으로 풀면서 code survival이라는 강력한 렌즈를 얻게 된다.

이 접근 덕분에 논문은 “세션은 성공으로 보이지만 실제 커밋에는 절반도 안 남는다”는 식의 역설을 관찰할 수 있다. 결국 코딩 에이전트의 가치는 멋진 중간 출력보다 사용자가 유지하기로 선택한 코드에 더 가깝다. 이 논문이 단순 벤치마크 리더보드보다 더 설득력 있게 읽히는 이유가 여기에 있다. 사람의 승인과 삭제라는 마지막 선택까지 지표 안에 넣었기 때문이다.

3. 방법론: SWE-chat 데이터 수집과 계측 설계

SWE-chat의 방법론은 크게 세 층으로 나뉜다. 첫째는 데이터 수집이다. 공개 GitHub 저장소에서 Entire.io CLI를 통해 기록된 코딩 에이전트 세션을 수집한다. 둘째는 코드 귀속과 효율 지표 계산이다. 에이전트가 만든 코드가 최종 커밋에 얼마나 남았는지, 자가 수정과 인간 수정이 각각 얼마나 발생했는지 계산한다. 셋째는 LLM judge 기반 annotation이다. 세션 성공도, 프롬프트 의도, 사용자 pushback, 사용자 persona 같은 정성 정보를 대규모로 라벨링해 정량 분석이 가능하도록 만든다.

3.1 Entire 기반 세션 수집 파이프라인

저자들에 따르면 데이터의 출발점은 공개 저장소와 opt-in checkpoint logging이다. 개발자가 Entire CLI를 사용하고 공개 로그 저장에 동의하면, 세션 transcript와 관련 메타데이터가 저장소의 별도 브랜치에 남는다. 연구진은 GitHub Code Search API로 이런 저장소를 찾아 checkpoint 디렉터리를 수집하고, 그 안의 이벤트를 구조화된 표 형식으로 정리한다. 즉 수집 파이프라인은 처음부터 장기적으로 계속 확장되는 living dataset을 목표로 설계되어 있다.

이때 기록되는 정보는 꽤 세밀하다. 사용자 프롬프트, 에이전트 응답, 일부 세션의 reasoning trace, 툴 호출, 툴 결과, 토큰 사용량, 파일 경로, 셸 명령이 함께 남는다. 따라서 SWE-chat은 “어떤 질문이 들어왔고 어떤 답이 나갔다” 수준이 아니라, “어떤 질문 뒤에 에이전트가 무엇을 읽고 어떻게 수정했으며, 그 과정에서 얼마나 많은 비용과 시간이 들었는가”를 복원할 수 있다.

• 지원 도구로 언급된 에이전트: Claude Code, OpenCode, Gemini CLI, Cursor, Factory AI Droid
• 핵심 로그 단위: user prompt, assistant response, thinking trace, tool call, tool result
• 부가 메타데이터: 토큰 사용량, 파일 경로, 셸 명령, 커밋 연결 정보
• 관찰 시점 기준 규모: 200개 이상 저장소, 13,000개 이상 checkpoint, 약 6,000개 세션

이 수집 방식의 장점은 연구용 synthetic task를 따로 만들지 않아도 된다는 점이다. 대신 단점도 분명하다. Entire CLI를 직접 설치하고 공개 로그 저장에 동의한 사용자만 들어오므로, 표본은 자연히 오픈소스 친화적이며 도구 수용성이 높은 개발자 쪽으로 쏠린다. 논문도 이 제약을 숨기지 않고 제한사항으로 명시한다.

3.2 줄 단위 귀속과 효율 지표

SWE-chat의 핵심은 단순히 로그를 모으는 데서 끝나지 않는다. 저자들은 파일을 실제로 바꾸는 tool call을 시간순으로 재생해 가며 각 줄의 provenance를 추적한다. 이렇게 하면 특정 줄이 원래부터 있던 코드인지, 에이전트가 새로 쓴 코드인지, 이후 인간이 덮어쓴 코드인지, 에이전트가 스스로 다시 갈아엎은 코드인지 구분할 수 있다. 이 정보가 있어야만 “에이전트가 많이 썼다”와 “에이전트가 쓴 것이 실제로 남았다”를 분리해서 볼 수 있다.

논문은 특히 Coding Efficiency와 Code Survival Rate를 구분한다. 앞의 지표는 총 에이전트 생산량 중 최종 커밋에 살아남은 비율이라서 self-overwrite까지 벌점으로 준다. 반면 뒤의 지표는 최종 상태에 남아 있던 에이전트 순산출물 중 인간이 유지한 비율이므로, 에이전트가 중간에 스스로 고쳐 쓰는 행동은 직접 벌점으로 삼지 않는다. 이 구분이 중요한 이유는 코딩 에이전트가 실제로는 여러 번 초안을 쓰고 지우면서 최종안을 만들기 때문이다.

논문이 제시한 정의를 그대로 쓰면 다음과 같다.

$$\text{Coding Efficiency} = \frac{\text{agent lines survived}}{\text{agent cumulative lines produced}}$$

$$\text{Code Survival Rate} = \frac{\text{agent lines survived}}{\text{agent lines in final state}}$$

여기에 더해 논문은 Token efficiency, Cost efficiency, Cognitive efficiency, Time efficiency, Agent runtime efficiency를 모두 100 committed LOC당 자원 소모량으로 정의한다. 즉, 에이전트가 길고 화려한 세션을 수행했더라도 실제 커밋 줄 수가 적다면 효율은 나빠진다. 개발자 관점에서 이 정의는 꽤 현실적이다. 사용자는 총 토큰이나 총 분이 아니라, 실제로 남는 코드 한 줄당 얼마를 쓰고 있는가를 체감하기 때문이다.

• Token efficiency: 입력, 출력, 캐시 토큰을 모두 합쳐 100 committed LOC당 환산
• Cost efficiency: 모델 가격표를 곱한 총 비용을 100 committed LOC당 환산
• Cognitive efficiency: 사용자가 타이핑한 prompt 문자 수를 100 committed LOC당 환산
• Time efficiency: 세션 runtime을 100 committed LOC당 환산, 단 2분 이상 idle 구간은 제외
• Security analysis: Semgrep를 커밋 전후 스냅샷에 실행해 1,000 added lines당 도입/수정된 취약점 수 계산

보안 분석 역시 흥미롭다. 저자들은 Semgrep를 pre-commit과 post-commit 스냅샷에 각각 실행하고, 커밋이 실제로 건드린 파일에서 새롭게 등장한 finding을 introduced, 사라진 finding을 fixed로 센다. 이 방식을 쓰면 “에이전트가 코드를 더 빨리 썼다”는 주장과 별개로, 그 코드가 얼마나 취약점을 밀어 넣는지를 동일한 단위에서 비교할 수 있다.

3.3 LLM judge 기반 annotation 설계

로그 데이터만으로는 모든 해석이 가능하지 않다. 예를 들어 사용자가 어떤 의도로 프롬프트를 썼는지, 중간에 나온 반응이 단순 질문인지 pushback인지, 세션 전체가 어느 정도 성공적이었는지는 사람 또는 모델이 해석해야 한다. 그래서 저자들은 세션 수준과 프롬프트 수준의 annotation schema를 설계하고, 인간 gold set과 LLM judge를 함께 사용한다.

수준	태스크	출력 형태	입력	목적
Session	Session success	0–100 연속 점수	전체 대화와 tool summary	실패 패턴 식별, reward signal 후보
Session	User persona	Expert nitpicker / Vague requester / Mind changer / Other	세션 요약	실사용자 상호작용 스타일 파악
Prompt	Prompt intent	create / refactor / debug / understand / connect / git / test / other	raw prompt	실제 업무 유형 분해
Prompt	User pushback	correction / rejection / failure report / non-pushback	해당 지점까지의 transcript	마찰과 감독 지점 측정

이 설계의 좋은 점은 정량 로그와 정성 해석이 한 프레임 안에서 결합된다는 것이다. 세션 성공도는 단순 이진 분류가 아니라 0에서 100까지의 연속 점수로 두고, 사용자 persona는 상호작용 스타일을 분해한다. 특히 prompt pushback은 사용자가 에이전트 결과를 어떻게 교정하는지를 직접 드러내므로, 코딩 에이전트의 실제 감독 비용을 읽는 핵심 신호가 된다.

저자들은 코드북을 반복 수정한 뒤 인간 annotator 두 명이 90개 IAA 샘플을 독립적으로 라벨링했고, 이견을 정리해 총 100개 gold label을 만들었다. 그 다음 여러 오픈/클로즈드 모델과 프롬프트 변형을 비교해 full-dataset annotation에 쓸 모델을 골랐다. 흥미로운 점은 pushback 태스크에서 최고 정확도 모델 대신 더 싼 qwen-3.5-9b를 선택했다는 사실이다. 전체 transcript를 넣어야 해서 비용이 커지는 작업이라는 현실을 반영한 결정이다.

이 과정을 조금 더 뜯어보면, 저자들은 annotation을 한 번에 밀어붙이지 않고 코드북 정제 → IAA 측정 → gold label 확정 → 모델 선택의 순서로 진행한다. 특히 zero-shot 성능을 비교할 때도 모델 하나만 본 것이 아니라, 과제별로 9~11개 모델과 2~4개 프롬프트 변형을 함께 실험했다. 즉 SWE-chat의 annotation은 값싼 자동 라벨 생성이라기보다, 제한된 인간 라벨을 발판으로 삼아 대규모 로그를 읽을 수 있게 만드는 확장형 판독 파이프라인에 가깝다.

repo 수준 annotation도 따로 존재한다는 점이 중요하다. 저자들은 저장소의 domain과 audience를 분리해 분류했고, 이 덕분에 단순히 “코딩 에이전트가 많이 쓰인다”는 말이 아니라 “어떤 종류의 프로젝트에서 누구를 위한 소프트웨어를 만들 때 많이 쓰이는가”까지 함께 읽을 수 있게 된다. 실제로 application과 devtools가 큰 비중을 차지하고, audience는 developer가 가장 크다. 이 메타데이터는 이후 결과를 해석할 때 매우 유용한 맥락이 된다.

• Prompt intent 최종 선택 모델: qwen-3.5-27b
• Prompt pushback 최종 선택 모델: 비용 대비 성능을 고려한 qwen-3.5-9b
• User persona 최종 선택 모델: gpt-5.4-2026-03-05
• Repository domain / audience 최종 선택 모델: claude-opus-4-6
• Session success 최종 선택 모델: claude-sonnet-4-6

이 선정 결과는 SWE-chat의 또 다른 실용적 면모를 보여 준다. 데이터셋 자체가 실사용 로그에서 왔듯이, annotation 파이프라인도 정확도만 보는 연구용 선택이 아니라 비용과 문맥 길이까지 고려한 운영형 선택을 한다. 예를 들어 pushback 태스크는 전체 transcript를 같이 읽어야 해서 컨텍스트가 길고, 이런 과제에서는 최고 성능 모델보다 지속적으로 돌릴 수 있는 모델이 더 현실적인 선택이 된다. living dataset이라는 구조를 유지하려면 이런 판단이 필수적이다.

정리하면 3절의 방법론은 세 가지 층위를 동시에 품고 있다. 수집 파이프라인은 세션을 확보하고, 귀속 파이프라인은 커밋 결과와 연결하며, annotation 파이프라인은 그 의미를 읽을 수 있게 만든다. 이 세 층이 모두 있어야만 “에이전트가 실제로 무엇을 했는가”, “사용자는 어떻게 받아들였는가”, “그 과정이 얼마나 비쌌고 위험했는가”를 하나의 논문 안에서 일관되게 다룰 수 있다.

4. 실험 설정: 실사용 로그를 비교 가능한 분석 단위로 바꾸는 과정

이 논문은 전통적인 학습 실험처럼 train/validation/test를 나누고 모델을 반복 학습시키는 구조가 아니다. 대신 이미 수집된 대규모 로그를 어떤 분석 축으로 쪼개고, 어떤 세션만 commit-level 평가에 넣을지 정교하게 정한다. 그래서 “실험 설정”은 모델 하이퍼파라미터보다 데이터 포함 조건, 필터링 전략, 비교 기준의 의미가 더 크다.

4.1 데이터셋 및 분석 대상

논문 본문과 부록을 종합하면 SWE-chat은 약 6,000세션, 63,000개 이상 프롬프트, 355,000개 이상 tool calls, 2.7M 로그 이벤트를 가진다. 다만 저자들은 전체 raw 로그를 그대로 쓰지 않고, 봇으로 보이는 데이터는 제외했다고 밝힌다. 또 분석용 데이터의 약 85%가 Claude Code에서 왔다고 적기 때문에, 논문의 결론은 “모든 코딩 에이전트의 평균”이라기보다 현재 가장 많이 쓰이는 CLI형 에이전트 중심의 관찰로 읽는 편이 안전하다.

Figure 4: 세션당 turn 수, turn당 tool call 수, 자주 다뤄지는 파일 유형

Figure 4는 실사용 로그가 결코 짧고 단순하지 않다는 점을 보여준다. 세션은 여러 turn에 걸쳐 이어지고, turn 하나 안에서도 도구 호출이 연속적으로 일어난다. 또 에이전트가 만지는 파일 유형이 다양하다는 사실은 코딩 에이전트의 역할이 단지 새 파일을 생성하는 데 그치지 않고, 기존 저장소 내부의 다양한 자산을 탐색하고 수정하는 일까지 포함한다는 점을 드러낸다.

언어 다양성도 흥미롭다. 부록 기준 상위 6개 프롬프트 언어는 영어, 일본어, 중국어, 러시아어, 포르투갈어, 한국어다. 즉, 이 데이터셋은 완전히 영어권에만 갇혀 있지 않다. 물론 대부분의 분석은 여전히 영어 중심으로 읽는 것이 맞지만, 적어도 코딩 에이전트 사용이 이미 다국어 개발 문화에 퍼져 있다는 신호는 분명하다.

프롬프트 의도	비중	해석
other	26.6%	정형 카테고리 밖의 잡다한 실제 요청이 적지 않음을 의미
understand	19.0%	새 코드 작성보다 기존 코드 이해가 더 자주 등장
git	13.6%	브랜치/커밋/PR 관리 같은 운영 작업 비중이 큼
create new code	13.4%	패치 생성은 중요하지만 전부는 아님
debug	13.0%	재현과 원인 탐색이 현실 업무에서 큰 축임을 시사
refactor	9.2%	기존 코드 구조 재정리가 꽤 자주 요청됨
test	4.0%	테스트 생성과 수정은 빈도는 낮지만 명확한 축
connect	1.0%	시스템 연결이나 배선 작업은 상대적으로 소수

Table 3의 수치는 이 논문의 핵심 메시지 중 하나를 뒷받침한다. 코드 이해가 19.0%로 가장 두드러진 상위 의도 중 하나이고, git과 debug도 각각 13%대라는 점은, 현실 개발자 업무가 “명세가 주어지면 새 코드를 생성”하는 단선 구조가 아니라는 사실을 보여 준다. 코딩 에이전트를 평가할 때 저장소 탐색과 운영 작업을 빼면 실제 유용성의 상당 부분을 놓치게 된다.

4.2 구현 세부사항

부록을 보면 저자들은 추가 분석을 위해 여러 구현 선택을 분명히 적는다. 예를 들어 topic clustering은 영어 프롬프트를 대상으로 Sentence-BERT(all-mpnet-base-v2) 임베딩을 만든 뒤, UMAP으로 축소하고 HDBSCAN*으로 군집화한다. 보안 분석은 Semgrep를 쓰고, 시간 효율 계산에서는 2분 이상 idle 구간을 제외한다. 이런 세부 선택은 숫자 자체보다도, 논문이 실사용 로그를 가능한 한 비교 가능한 분석 단위로 만들기 위해 얼마나 많은 정제 과정을 거쳤는지를 보여 준다.

또 한 가지 중요한 조건은 commit-level 지표를 계산할 수 있는 세션 비율이 전체의 48.6%라는 점이다. 저자들은 세션과 커밋의 line attribution이 애매하지 않게 연결되는 경우에만 Table 3과 효율 그림을 계산한다. 이 기준은 분석 신뢰도를 올리지만, 동시에 “절반 조금 안 되는 세션만 commit-linked 평가에 들어간다”는 한계를 함께 남긴다. 즉, 논문의 효율 수치는 전체 모집단의 절대 진실이라기보다 충분히 정렬 가능한 세션의 보수적 분석으로 읽는 것이 맞다.

4.3 베이스라인: human-only, collaborative, vibe coding

이 논문은 특정 모델끼리 승부를 가르는 전통적 baseline을 두지 않는다. 대신 실제 사용 모드를 human-only, collaborative, vibe coding 세 그룹으로 나누고, 이 축에서 효율과 안전성을 비교한다. 이렇게 하면 “에이전트를 조금 쓰는 개발자”와 “거의 전부를 맡기는 개발자” 사이의 구조적 차이를 읽을 수 있다. 사용자 선택 자체를 실험 변수처럼 취급한 셈이다.

코딩 모드	정의	세션 비중	해석
Human-only	커밋된 코드의 0%를 에이전트가 작성	22.7%	에이전트는 이해와 보조 역할에 머묾
Collaborative	에이전트가 0% 초과 99% 미만의 커밋 코드를 작성	36.5%	사람과 에이전트가 공동 저자처럼 작동
Vibe coding	커밋 코드의 99% 이상을 에이전트가 작성	40.8%	거의 전면 위임에 가까운 사용 방식

Figure 5: human-only, collaborative, vibe coding으로 갈라지는 agent-authored code 분포

Figure 5는 코딩 에이전트 사용이 “조금씩 보조받는 형태”로만 늘어나는 것이 아니라, 상당수가 거의 전면 위임 쪽으로 이동하고 있음을 보여 준다. 분포가 연속적으로 퍼지지 않고 양극단에 몰리는 모습은 실제 개발자들이 에이전트를 사용할 때 점진적으로 섞기보다, 세션 성격에 따라 “거의 안 쓰거나 거의 다 맡기거나”의 형태를 자주 택한다는 해석을 가능하게 한다.

이 baseline 구성이 좋은 이유는 모델 브랜드보다 사용 방식 자체가 결과에 미치는 영향을 먼저 보여 주기 때문이다. 같은 모델이어도 human-only처럼 쓰면 안전성과 효율이 달라지고, vibe coding처럼 거의 전부를 맡기면 비용과 취약점 양상이 달라진다. SWE-chat은 모델 비교보다 사용 모드 비교가 더 직접적인 통찰을 준다는 점을 잘 보여 준다.

부록의 저장소 메타데이터를 함께 보면, 이 비교가 단지 개인 취향의 문제가 아니라는 점도 드러난다. 프로젝트 유형은 application 52.8%, devtools 32.0%, other 15.1%로 나뉘고, audience는 developer 58.8%, end-user 35.2%, researchers 3.5%, education 2.5%다. 즉 SWE-chat은 개발자용 도구와 실제 앱이 섞인 현실 프로젝트를 다루며, 이 안에서 human-only와 collaborative, vibe coding이 어떻게 갈라지는지 보는 것이 논문의 핵심 실험 설정이 된다.

메타 항목	세부 분포	왜 중요한가
Repository domain	application 52.8%, devtools 32.0%, other 15.1%	실제 배포형 앱과 도구 제작이 함께 들어 있어 특정 한쪽으로 치우친 벤치마크가 아님
Repository audience	developer 58.8%, end-user 35.2%, researchers 3.5%, education 2.5%	개발자용 내부 도구뿐 아니라 실제 사용자-facing 코드도 상당수 포함
Agent concentration	분석 데이터의 약 85%가 Claude Code	현실 로그 기반이지만 특정 도구군에 대한 관찰이라는 점을 함께 기억해야 함
Commit-linked subset	전체 세션의 48.6%	효율과 survival 지표는 정렬 가능한 세션에 대해 계산된 값임

Table 4를 보면 SWE-chat의 수치는 매우 현실적이지만 동시에 해석상 주의가 필요하다는 점이 분명해진다. 예를 들어 결과의 대부분이 Claude Code 중심이라는 점은 오늘 시점의 CLI형 코딩 에이전트 사용을 잘 보여 주지만, 브라우저 중심 제품이나 기업 내부 도구에 그대로 일반화하기는 어렵다. 반대로 commit-linked subset을 따로 두는 보수적 설정은 숫자를 덜 화려하게 만들더라도 분석 신뢰도를 높여 준다.

또 하나 주목할 부분은 vibe coding 비중의 시간 추세다. 부록에 따르면 3개월 관찰 구간 동안 vibe coding 세션 비중은 대략 20% 수준에서 40%를 넘는 수준으로 두 배 가까이 늘었다. 즉 이 모드는 변두리 사용법이 아니라, 이미 상당수 개발자가 실제로 시도하는 방식이다. 그래서 논문이 human-only와 collaborative를 단순 대조군이 아니라 동일한 시기에 병행 관찰되는 동시대 사용 모드로 놓는 것이 설득력 있다.

실험 설정 관점에서 보면, 이 논문은 결국 “어떤 모델이 가장 좋으냐”보다 “어떤 사용 모드가 어떤 비용 구조를 갖느냐”를 묻는다. 그리고 이런 질문은 앞으로 코딩 에이전트 평가가 모델 중심에서 workflow 중심으로 이동할수록 더 중요해질 가능성이 크다. SWE-chat은 바로 그 이동을 뒷받침하는 기초 실험판을 제공한다.

5. 주요 실험 결과: 코딩 에이전트는 널리 쓰이지만 아직 비싸고 자주 교정된다

5.1 실제 사용 패턴과 사용자 유형

저자들은 먼저 에이전트가 어떤 종류의 저장소와 작업에서 쓰이는지 본다. 저장소 도메인은 application이 52.8%로 가장 크고, 그 다음이 devtools 32.0%다. 대상 사용자도 developer가 58.8%로 가장 많고, end-user 대상 저장소가 35.2%로 뒤를 잇는다. 즉, SWE-chat은 장난감 프로젝트보다 실제 배포와 도구 제작이 섞인 오픈소스 현장을 꽤 많이 반영한다.

Figure 6: 프롬프트 의도, 툴 호출, 저장소 유형, 코딩 모드를 한 번에 요약한 부록 그림

Figure 6은 SWE-chat의 실제 사용 분포를 읽는 핵심 그림이다. 프롬프트 의도, 툴 호출 분포, 저장소 도메인과 audience, 코딩 모드를 한 장에 묶어 보여 주기 때문에 “코딩 에이전트는 주로 어떤 작업을 하고 어떤 환경에서 쓰이는가”라는 질문에 가장 직접적으로 답한다. 특히 code understanding과 git 작업 비중이 크다는 점, 그리고 vibe coding이 이미 상당한 세션 비중을 차지한다는 점이 눈에 띈다.

순위	툴 카테고리	호출 수	비중
1	read	60,855	19.8%
2	edit	60,205	19.6%
3	git/gh	36,537	11.9%
4	grep	31,238	10.1%
5	bash:build	24,699	8.0%
6	bash:file	21,130	6.9%
7	agent	20,495	6.7%
8	bash	16,527	5.4%
9	write	9,025	2.9%
10	mcp	6,001	1.9%

Table 5를 보면 read와 edit가 각각 약 20%로 최상위에 있고, git/gh, grep, bash:build가 그 뒤를 받친다. 논문이 “bash와 git 계열 호출이 전체의 약 3분의 1”이라고 해석하는 이유가 여기에 있다. 즉, 코딩 에이전트는 단순 생성기라기보다 저장소 탐색기 + 셸 오퍼레이터 + 코드 편집기의 결합체로 쓰이고 있으며, 현실 사용 패턴을 이해하려면 세 역할을 함께 보아야 한다.

사용자 성향도 뚜렷하다. Expert Nitpicker가 39.7%로 가장 많고, Vague Requester가 33.5%, Mind Changer가 7.0%다. 이 결과는 실제 사용자들이 벤치마크처럼 처음부터 완결된 명세를 주지 않는다는 사실을 뒷받침한다. 특히 nitpicker가 많다는 것은, 에이전트가 한 번에 완벽한 결과를 내기보다 사용자 교정 루프 속에서 점진적으로 다듬어지는 경우가 더 많다는 뜻이다.

5.2 세션 성공도와 코드 생존율은 왜 다른가

논문은 먼저 전체 세션의 90%가 session success rating 50 이상을 받는다고 보고한다. 겉으로 보면 꽤 높은 성공률처럼 보인다. 실제로 많은 세션에서 에이전트는 어느 정도 요청을 처리하고, 사용자는 세션을 완전히 중단하지 않는다. 하지만 저자들은 여기서 한 발 더 나아가, “성공처럼 보인 세션에서 에이전트가 쓴 코드가 실제로 얼마나 남는가”를 묻는다. 이 추가 질문이 논문의 가치다.

Figure 7: LLM-annotated session success rating의 전체 분포

Figure 7은 success rating 분포가 왼쪽으로 치우쳐 있어, 대다수 세션이 완전한 실패라기보다 어느 정도 목적을 달성한 것으로 평가된다는 점을 보여 준다. 다만 이것은 세션 전체의 인상에 가까운 지표다. 실제 개발자 입장에서는 세션의 분위기보다 최종 커밋에 남은 코드가 더 중요할 수 있다. 바로 이 지점에서 session success와 code survival의 차이가 생긴다.

코딩 모드	Coding efficiency	Code survival rate	Survived	Agent self-overwrite	Human overwrite	Human deletion
All modes	44.3%	50.3%	44.3%	9.3%	1.5%	42.2%
Collaborative	38.2%	44.1%	38.2%	10.1%	1.5%	46.9%
Vibe coding	59.0%	64.6%	59.0%	7.1%	1.4%	30.9%

Table 6은 이 논문의 가장 많이 인용될 결과 중 하나다. 전체적으로 보면 에이전트가 만들어 낸 코드 중 최종 커밋에 살아남는 비율은 44.3%에 불과하다. 다시 말해 에이전트가 쓴 코드의 절반 이상은 최종 결과에 그대로 남지 않는다. 특히 human deletion이 42.2%라는 수치는 많은 세션에서 사용자가 에이전트 산출물을 과감히 버리고 있다는 뜻이다.

흥미롭게도 vibe coding에서는 survival이 59.0%, survival rate가 64.6%로 올라간다. 이를 곧바로 “vibe coding이 더 좋다”로 읽기는 어렵다. 논문도 지적하듯, 이는 에이전트 출력이 더 정확해서일 수도 있고, 반대로 사용자가 덜 엄격하게 검수했기 때문일 수도 있다. 즉, 높은 생존율은 품질 신호일 수도 있고 낮은 감독 강도의 부산물일 수도 있다. 이 모호함 자체가 실사용 로그 분석의 중요한 포인트다.

Figure 8: 100 committed LOC당 토큰, 인지, 시간 효율을 비교한 boxplot

Figure 8은 코딩 에이전트의 “편함”이 실제로는 꽤 비싼 편일 수 있음을 보여 준다. 논문 본문과 부록을 합치면 vibe coding은 204K tokens / 100 committed LOC를 쓰고, $0.13 / 100 LOC, 12.6분 / 100 LOC 정도가 든다. 반면 collaborative coding은 시간 효율이 4.8분 / 100 LOC로 가장 좋고, 비용도 $0.05 / 100 LOC 수준이다. 즉, 현 시점에서는 전면 위임보다 공동 저자 모드가 더 경제적이라는 결론이 자연스럽다.

이 숫자는 최근 코딩 에이전트 담론을 현실 쪽으로 끌어당긴다. 많은 사용자는 “에이전트가 다 해 주는 것이 더 빠를 것”이라 기대하지만, SWE-chat이 보여 주는 그림은 반대다. 에이전트가 코드를 많이 쓰는 세션일수록 토큰과 비용, 시간, 감독이 함께 커진다. 결국 현재의 코딩 에이전트는 인간을 완전히 대체하기보다, 인간이 적절한 순간에 개입할 때 가장 높은 생산성을 내는 보조형 협업 도구에 더 가깝다.

5.3 보안 취약점과 사용자 감독 패턴

효율성보다 더 강하게 읽히는 결과는 보안 취약점이다. 저자들은 Semgrep로 commit 전후를 비교해 새롭게 들어온 취약점을 세고, 이를 1,000 added lines당 비율로 환산했다. 이 방식 덕분에 “더 빨리 많이 썼다”는 주장이 아니라, “그 과정에서 얼마나 위험한 코드를 밀어 넣었는가”라는 더 직접적인 질문을 던질 수 있다.

코딩 모드	Fixed / 1K lines	Introduced / 1K lines
Human-only	0.04	0.08
Collaborative	0.08	0.14
Vibe coding	0.52	0.76
Overall	0.06	0.11

Table 7의 숫자는 직관적으로도 꽤 강하다. vibe coding은 1,000 added lines당 0.76개의 취약점을 새로 도입해, human-only의 0.08보다 약 9배, collaborative의 0.14보다 약 5배 높다. 동시에 fixed 비율도 높지만, 모든 모드에서 introduced가 fixed보다 크고 그 차이가 vibe coding에서 가장 벌어진다. 즉, 전면 위임은 단순히 더 많은 코드를 쓰는 모드가 아니라, 더 많은 보안 리스크를 동반하는 모드로 보인다.

Figure 9: 코딩 모드별 clarification, interruption, pushback 비율

Figure 9는 보안 문제의 배경을 설명해 주는 그림이기도 하다. 에이전트는 clarification을 거의 하지 않는데, 사용자는 매우 자주 pushback과 interruption으로 개입한다. 즉, 에이전트가 스스로 불확실성을 표면화하기보다 그냥 계속 진행하고, 사용자가 나중에 결과를 보고 교정하는 구조가 반복된다. 이 패턴은 보안 취약점이 왜 더 쉽게 커밋 직전까지 흘러갈 수 있는지를 잘 보여 준다.

코딩 모드	Uninterrupted	AskUserQuestion	Pushback total	Interruption
Human-only	50.7%	1.4%	41.9%	6.0%
Collaborative	55.0%	1.6%	38.4%	5.0%
Vibe coding	56.0%	1.1%	39.6%	3.3%

Table 8에서 가장 눈에 띄는 값은 AskUserQuestion이 1.1%–1.6% 수준에 머문다는 점이다. 사용자에게 먼저 물어보는 비율은 매우 낮은데, Pushback total은 38%에서 42% 사이로 높다. 즉, 사용자는 거의 두 턴에 한 번꼴로 교정, 거부, 실패 보고를 한다. 논문이 discussion에서 전체적으로 pushback이 약 39%, interruption까지 합치면 discussion 문맥에서 대략 44%의 turn에 인간 개입이 있다고 요약하는 이유가 여기에 있다.

Figure 10: Claude Code 세션에서 turn duration의 시계열 변화

Figure 10은 코딩 에이전트가 점점 더 긴 자율 구간을 시도하고 있음을 보여 준다. 중앙값은 1분 미만, p90도 7분 미만이지만, p99.9는 관찰 후반부에 100분을 넘는 수준까지 올라간다. 즉, 긴 autonomous run은 이미 현실 사용 로그에서 관찰된다. 그런데 앞선 Figure 9와 Table 8을 보면, 이런 긴 자율 구간이 늘어나도 사용자의 교정과 개입은 사라지지 않는다. 이 긴장 관계가 바로 현재 코딩 에이전트의 현실이다.

정리하면, SWE-chat의 주요 결과는 세 문장으로 압축된다. 첫째, 코딩 에이전트는 이미 널리 위임되고 있다. 둘째, 그러나 그 결과물의 상당수는 최종 커밋에 남지 않으며, 전면 위임은 비용과 보안 측면에서 특히 비싸다. 셋째, 에이전트는 점점 더 오래 혼자 일하지만, 사용자는 여전히 매우 자주 수정하고 끊어 세운다. 즉, 자율성은 늘고 있지만 감독 부담은 아직 줄지 않았다.

사용자 persona를 별도로 보면 이 결론이 더 선명해진다. 논문은 전체 세션의 39.7%를 Expert Nitpicker로, 33.5%를 Vague Requester로 분류한다. 즉, 현실 사용자는 처음부터 완성된 명세를 내리는 사람이기보다, 결과를 본 뒤 세밀하게 수정하거나 적당히 방향만 던지는 경우가 많다. 지금의 코딩 에이전트가 “요청을 받으면 스스로 완결형 해결책을 낸다”는 이미지와 달리, 실제 현장에서는 지속적인 조율과 수정 속에서 작동한다는 뜻이다.

사용자 persona	비중	의미
Expert Nitpicker	39.7%	결과를 세밀하게 검토하고 수정 지시를 반복하는 사용자
Vague Requester	33.5%	초기 요구가 느슨하고 에이전트에 결정을 많이 위임하는 사용자
Other	19.9%	명확한 범주로 모이지 않는 다양한 상호작용 스타일
Mind Changer	7.0%	중간에 목표를 바꾸거나 방향을 다시 설정하는 사용자

이 표에서 특히 중요하게 읽히는 것은 vibe coding에서도 nitpicker가 많다는 점이다. 논문은 vibe coding 세션에서도 약 47%가 expert nitpicker이며, mind changer는 오히려 더 적다고 적는다. 이는 전면 위임이 “사용자가 아무것도 안 본다”는 뜻이 아니라, 에이전트가 초안을 크게 만들고 인간이 그 위를 미세하게 깎는 구조일 수 있음을 시사한다. 즉 vibe coding의 본질은 무감독 자동화라기보다, 대규모 초안 위에 얹힌 고빈도 인간 교정일 가능성이 크다.

효율 수치를 조금 더 묶어서 보면 왜 collaborative coding이 현재 가장 현실적인 모드인지 이해하기 쉽다. collaborative는 비용과 시간에서 가장 좋은 균형을 보이고, human-only는 비용은 중간이지만 에이전트 활용도가 낮으며, vibe coding은 커밋 대비 자원 소모가 가장 크다. 에이전트가 더 많은 줄을 쓰는 것이 곧 더 빠른 개발을 뜻하지 않는다는 사실이 이 비교에서 분명해진다.

코딩 모드	Cost efficiency	Time efficiency	보조 해석
Human-only	$0.07 / 100 LOC$	8.6분 / 100 LOC	에이전트 의존은 낮지만 인간 작업 비중이 커서 시간은 아주 짧지 않다.
Collaborative	$0.05 / 100 LOC$	4.8분 / 100 LOC	현재 기준 가장 좋은 비용-시간 균형을 보이는 모드다.
Vibe coding	$0.13 / 100 LOC$	12.6분 / 100 LOC	자원 소모가 가장 크며, token efficiency도 약 204K tokens / 100 LOC로 매우 높다.

Table 9를 보면 비용과 시간 모두에서 collaborative가 가장 낫다. 이는 코딩 에이전트가 인간을 완전히 대체할 때보다, 인간이 방향과 검수를 맡고 에이전트가 초안과 반복 작업을 맡을 때 더 효율적이라는 점을 보여 준다. 지금 시점의 코딩 에이전트는 독립적인 개발자보다 빠른 주니어 초안 작성기에 더 가까우며, 강한 인간 개입이 있을 때 가장 좋은 산출물을 낸다는 해석이 가능하다.

보안 결과도 같은 방향을 가리킨다. vibe coding이 취약점을 더 많이 고치기도 하지만, 동시에 더 많이 도입한다는 사실은 에이전트가 위험한 코드를 더 많이 건드리고 있다는 뜻이기도 하다. 즉 “fix도 많다”는 사실은 품질의 증거라기보다, 보안적으로 민감한 편집을 더 공격적으로 수행한다는 신호에 가깝다. 따라서 현재 단계에서는 전면 위임을 늘리기보다, 어느 지점에서 사람 확인을 강제할지를 더 정교하게 설계하는 편이 현실적이다.

나는 이 결과를 코딩 에이전트의 미래를 비관하는 근거로 읽지 않는다. 오히려 사용 패턴이 이미 충분히 넓게 퍼져 있고, collaborative 모드에서 뚜렷한 효율 이점이 보인다는 점은 향후 제품 개선 여지가 크다는 뜻이다. 다만 개선의 방향은 “더 길게 혼자 돌게 만들기” 하나만이 아니라, 더 자주 물어보고, 더 일찍 멈추고, 더 싸게 재시도하게 하는 상호작용 설계 쪽으로 가야 한다는 메시지가 함께 따라온다.

5.4 왜 collaborative coding이 현재의 sweet spot인가

이 논문을 제품 관점에서 읽으면 가장 중요한 결론 중 하나는 collaborative coding이 현재 코딩 에이전트의 가장 현실적인 사용 모드라는 점이다. human-only는 에이전트의 잠재력을 충분히 쓰지 못하고, vibe coding은 비용과 취약점이 너무 크다. 반면 collaborative는 에이전트의 빠른 초안 작성 능력과 인간의 검수 능력을 서로 보완적으로 묶는다. 논문이 보여 주는 시간, 비용, survival, oversight 수치를 한 번에 놓고 보면 이 모드가 현 시점의 실전 최적점에 가장 가깝다.

흥미로운 것은 collaborative가 단순히 “중간 정도의 절충안”이 아니라는 점이다. 오히려 이 모드는 실제 개발 루프에 필요한 역할 분담을 잘 반영한다. 에이전트는 저장소 탐색, 반복적인 수정, 빌드와 테스트 실행을 빠르게 처리하고, 인간은 요구사항 확정, 위험 구간 검수, 최종 채택 여부 결정을 맡는다. 즉 collaborative coding은 기술적으로 덜 성숙해서 생긴 임시 상태가 아니라, 현재 에이전트 능력과 인간 요구가 맞물려 만들어진 구조적 균형점에 가깝다.

코딩 모드	Correction	Rejection	Failure report
Human-only	31.6%	1.3%	8.9%
Collaborative	30.2%	1.0%	7.3%
Vibe coding	32.0%	0.9%	6.7%

이 표를 보면 세 모드 모두에서 correction이 가장 큰 pushback 유형이라는 점이 보인다. 즉, 사용자는 대개 에이전트를 완전히 거절하기보다 “방향은 비슷하지만 이 부분을 다시 해 보라”고 수정하는 방식으로 개입한다. 특히 vibe coding에서도 correction 비율이 높다는 것은, 전면 위임이 사실상 무감독 자동화가 아니라 큰 덩어리의 초안에 대한 반복 수정 루프라는 점을 다시 확인시켜 준다.

여기서 중요한 실무 해석은 두 가지다. 첫째, 현재 코딩 에이전트는 사용자의 요구를 한 번에 끝내 주기보다 빠르게 시도하고 빨리 고쳐 나가는 사이클에 최적화되어 있다. 둘째, 그러려면 제품도 그 리듬에 맞춰 설계되어야 한다. 예를 들어 작은 단위의 checkpoint, 저렴한 재실행, 명확한 diff 제시, 불확실할 때 먼저 묻는 인터페이스가 중요해진다. SWE-chat의 수치는 모델 성능보다 상호작용 설계의 중요성을 더 강하게 말해 준다.

나는 그래서 이 논문이 “코딩 에이전트는 아직 멀었다”는 결론보다 “지금은 협업형 인터페이스를 최적화해야 할 때”라는 결론으로 읽힌다. 이미 실제 사용량은 충분히 많고, human-only보다 collaborative가 낫고, vibe coding도 빠르게 늘고 있다. 문제는 에이전트를 더 오래 혼자 돌게 하는 것만이 아니라, 인간의 수정 의도를 더 빠르게 반영하는 구조를 만드는 데 있다. 그런 의미에서 SWE-chat은 성능표보다 제품 설계 방향에 더 직접적인 시사점을 준다.

6. 추가 분석 및 Ablation Study: 부록이 보여주는 long-tail 구조

이 논문은 전통적 의미의 모델 ablation보다 부록 기반 추가 분석이 훨씬 풍부하다. 오히려 이 부록이 SWE-chat의 가치를 더 명확히 드러낸다. 저자들은 툴 궤적, 토픽 군집, 사용자 언어, 시간에 따른 모드 변화, 개발 활동별 차이, annotation 검증까지 꼼꼼하게 보여 준다. 실제 운영에 가까운 연구일수록 이런 부록이 중요해지는데, SWE-chat은 그 점에서 매우 잘 구성된 편이다.

6.1 토픽 군집과 agent trajectory 분석

부록의 토픽 분석은 영어 프롬프트를 대상으로 Sentence-BERT 임베딩과 HDBSCAN* 군집화를 적용해 얻는다. 결과적으로 20개 cluster가 전체 프롬프트의 57.4%를 설명하고, 나머지 42.6%는 noise로 남는다. 이 수치는 실제 코딩 에이전트 사용이 얼마나 롱테일(long-tail)인지 보여 준다. 즉, 몇 개 대표 태스크로는 도저히 다 담기지 않는 다양한 사용 맥락이 존재한다는 뜻이다.

저자들이 직접 짚는 사례도 흥미롭다. 예를 들어 frontend coding 관련 cluster는 pushback 비율이 75%로 특히 높다. 이는 프론트엔드 작업이 단순 정답 여부보다 취향과 세부 레이아웃, 상호작용 품질에 더 민감하기 때문으로 해석할 수 있다. 정답 패치 하나로 끝나는 백엔드 버그 수정과 달리, 프론트엔드는 사용자의 기대가 자주 바뀌고 “이건 아닌데”가 더 빨리 튀어나오는 영역이다.

trajectory 분석도 실전적이다. 저자들에 따르면 에이전트는 한 turn의 초반에 read, grep, glob, git 같은 탐색 도구를 많이 쓰고, 뒤로 갈수록 edit, write, bash:build 비중이 올라간다. 즉, 실제 코딩 에이전트 turn은 “탐색 → 실행”의 구조를 띤다. 그런데 interruption된 turn에서는 마지막 툴로 ExitPlanMode가 등장하는 비중이 32%로 높다고 보고한다. 사용자는 에이전트가 계획 단계에서 실행 단계로 넘어가려는 순간을 민감하게 바라본다는 의미다.

• 20개 cluster가 전체의 57.4%만 설명하고, 42.6%는 noise로 남는다.
• frontend coding cluster는 pushback이 75%로 특히 높다.
• turn 초반은 read/search, 후반은 edit/build로 무게중심이 이동한다.
• interrupt된 turn의 마지막 툴에서 ExitPlanMode 비중이 높아, 사용자가 계획-실행 전환에 자주 개입함을 시사한다.

6.2 언어, annotation 검증, 개발 활동별 차이

언어 분포는 SWE-chat이 특정 국가나 커뮤니티에만 갇힌 자료가 아님을 보여 준다. 영어가 가장 크지만, 일본어, 중국어, 러시아어, 포르투갈어, 한국어가 상위권에 함께 등장한다. 논문은 low-confidence 언어 판정 2,000건을 수동 검토해 교정했다고 밝혀, 최소한 이 분포를 대충 찍은 값으로 두지 않았다는 점도 확인할 수 있다.

Figure 11: code writing과 code reviewing에서 달라지는 agent behavior

Figure 11은 개발 활동별 차이를 꽤 생생하게 보여 준다. code writing 프롬프트는 code reviewing보다 평균 agent turn이 더 길고, 더 많은 툴 호출과 더 높은 마찰을 동반한다. 논문 본문과 부록 수치를 합치면 writing은 평균 4.1분, reviewing은 2.4분 수준의 turn duration을 보이고, AskUserQuestion 비율도 6.0% 대 2.6%로 더 높다. 즉, 새 코드를 실제로 쓰는 작업은 리뷰보다 훨씬 더 협상적이고 불확실한 활동이다.

같은 그림과 부록 통계를 보면 writing은 reviewing보다 pushback total과 hard interruption도 더 높다. 대략적으로 pushback은 37.3% 대 31.7%, interruption은 5.1% 대 4.2%로 읽힌다. 이 차이는 의미가 크다. 리뷰 작업은 이미 존재하는 코드 위에서 평가와 제안을 하는 일이지만, 작성 작업은 구체적 구현 선택을 실제로 결정해야 하므로 사용자의 수정과 개입이 더 자주 발생한다.

과제	핵심 검증 수치	해석
Prompt intent	Agreement 75.6%, Cohen’s kappa 0.709	업무 유형 분류가 비교적 안정적임
Prompt pushback	Agreement 88.9%, kappa 0.832	사용자 반발 감지는 비교적 신뢰도 높음
Prompt pushback(binary)	Agreement 94.4%, kappa 0.888	pushback 여부 자체는 더 견고하게 검출 가능
User persona	Agreement 78.9%, kappa 0.662	사람 유형 분류는 다소 애매하지만 usable
Session success	Spearman rho 0.757, ICC(2,1) 0.503	연속 점수는 완전 견고하지는 않지만 비교 신호로는 유효

Table 9는 LLM judge 기반 연구에서 중요한 방어 장치 역할을 한다. 이 논문은 annotation을 대규모로 자동화하지만, 동시에 사람 간 합의가 어느 정도인지도 공개한다. 특히 pushback 탐지는 kappa가 높아 꽤 믿을 만한 반면, session success는 ICC가 0.503이라 해석에 어느 정도 주의가 필요하다. 즉, 저자들도 이 라벨을 절대적 진실로 다루지 않고, 대규모 로그를 필터링하고 탐색하기 위한 보조 계층으로 사용하는 태도를 취한다.

개인적으로 이 부록 분석이 중요한 이유는, SWE-chat이 단순 데이터셋 발표를 넘어 코딩 에이전트 관찰학(observational science)에 가까운 문법을 보여 주기 때문이다. 어떤 일은 long-tail이라 표준 벤치마크로 묶기 어렵고, 어떤 실패는 pushback과 interruption으로만 드러난다. SWE-chat은 그런 미묘한 차이를 로그와 annotation으로 잡아내려 한다.

데이터 다양성이 시간이 지나며 어떻게 바뀌는지도 중요하다. 부록에 따르면 entireio/cli 저장소에서 나온 세션의 누적 비중은 관찰 시점 기준 20% 미만이며, 시간이 갈수록 감소하는 추세다. 이는 초기에 도구 제작자 주변에서 많이 발생하던 로그가 점차 외부 저장소로 퍼지고 있음을 뜻한다. 실사용 데이터셋이 처음에는 제품 내부 사용자에 크게 의존하더라도, living dataset 구조를 유지하면 다양성이 점차 개선될 수 있다는 사례로 읽을 만하다.

oversight 비율의 시계열도 흥미롭다. 에이전트의 최상위 자율 구간은 길어지고 있지만, clarification, interruption, pushback 비율 자체는 기간 전체에서 크게 사라지지 않는다. 즉 모델이 더 오래 혼자 실행되는 방향으로 발전해도, 인간의 감독 필요성이 자연스럽게 사라지는 것은 아니라는 뜻이다. 긴 autonomy와 높은 oversight가 동시에 존재한다는 점이, 오늘의 코딩 에이전트가 가진 가장 중요한 긴장이다.

annotation 과제	선택 모델	보고 수치	의미
Prompt intent	qwen-3.5-27b	accuracy 0.76	업무 유형 분해는 비교적 자동화가 잘 되는 편이다.
Prompt pushback	qwen-3.5-9b	accuracy 0.67	더 비싼 최고 성능 모델 대신 비용 효율을 택했다.
User persona	gpt-5.4-2026-03-05	accuracy 0.69	사람 유형 분류는 완전하지 않지만 분석용 필터로는 충분하다.
Repository domain / audience	claude-opus-4-6	accuracy 0.81 / 0.84	저장소 메타데이터 분류는 비교적 안정적이다.
Session success	claude-sonnet-4-6	ICC 0.60	연속 점수는 noisy하지만 대규모 triage에는 유용하다.

이 표는 SWE-chat이 왜 단순 데이터 dump가 아닌지를 잘 보여 준다. 데이터셋은 living dataset이지만, 그 위에 얹힌 annotation은 과제별로 다른 모델과 비용 구조를 고려해 설계된다. 연구 관점에서는 다소 번거로운 절차지만, 실제로 계속 업데이트되는 로그를 장기적으로 관리하려면 이런 운영 친화적 라벨링 설계가 필요하다.

특히 pushback 태스크에 대한 선택은 시사점이 크다. 이 과제는 특정 프롬프트만 보면 안 되고, 그 시점까지의 전체 transcript를 읽어야 하므로 문맥 길이가 길다. 따라서 가장 정확한 모델보다 충분히 괜찮은 성능을 내면서 계속 돌릴 수 있는 모델을 택하는 편이 현실적이다. 코딩 에이전트 연구가 점점 실사용 로그로 이동할수록, 모델 선택도 이런 장기 운영 비용을 고려하는 방향으로 갈 가능성이 크다.

결국 6절의 추가 분석은 한 가지 결론으로 모인다. 실제 코딩 에이전트 사용은 생각보다 훨씬 다양하고, 그 다양성은 모델 하나의 절대 성능표로 요약되지 않는다. 언어도 다양하고, 프로젝트도 다양하고, 토픽과 도구 흐름도 다양하며, 감독 방식도 다양하다. SWE-chat은 바로 그 다양성을 숨기지 않고 드러내는 데이터셋이라는 점에서 가치가 있다.

6.3 이 데이터셋이 바꿔 놓을 수 있는 평가와 학습의 방향

SWE-chat의 진짜 잠재력은 단순 통계 요약을 넘어서, 앞으로 코딩 에이전트를 어떻게 평가하고 학습시킬지의 방향을 바꿀 수 있다는 데 있다. 지금까지 많은 벤치마크는 이슈 설명과 정답 패치를 고정해 두고, 에이전트가 얼마나 잘 맞히는지 보는 방식이었다. 하지만 SWE-chat은 프롬프트가 길게 이어지고, 사용자가 중간에 방향을 바꾸고, 에이전트가 여러 도구를 호출하며, 최종적으로는 일부 코드만 살아남는 현실을 보여 준다. 이런 데이터가 있으면 평가도 더 이상 한 번의 patch solve로 끝나기 어렵다.

첫 번째 변화는 trajectory-aware benchmark 쪽이다. 즉, 특정 시점의 전체 대화와 도구 상태를 주고 “다음에 무엇을 해야 하는가”를 묻는 평가를 만들 수 있다. 이 방식은 단순 패치 생성보다 더 현실적이다. 실제 개발자는 처음부터 정답 패치를 기대하기보다, 에이전트가 지금 어떤 파일을 읽고 어떤 명령을 돌리고 어떤 질문을 먼저 해야 하는지를 더 자주 본다. SWE-chat은 이런 next-action evaluation의 재료를 충분히 제공한다.

두 번째 변화는 user simulator다. 현재 코딩 에이전트 사용자 연구는 비용이 비싸고 규모를 키우기 어렵다. 그런데 SWE-chat에는 실제 사용자가 어떤 식으로 correction을 주고, 언제 interruption을 하고, 어떤 상황에서 failure report를 남기는지가 들어 있다. 이 데이터를 바탕으로 사용자를 흉내 내는 모델을 만들면, 에이전트를 대규모로 offline evaluation할 수 있다. 논문이 discussion에서 이 방향을 별도 future work로 밀어 주는 이유도 여기에 있다.

세 번째 변화는 후학습과 reward 설계다. 지금까지 코딩 에이전트 후학습은 최종 정답 패치 여부를 보상으로 쓰는 경우가 많았다. 하지만 SWE-chat을 보면 유용한 신호가 훨씬 많다. 예를 들어 survival rate, human deletion, pushback subtype, interruption 직전의 tool, 시간당 commit 효율은 모두 행동 수준의 세밀한 보상 후보가 된다. 즉, 이 데이터셋은 단지 평가 세트가 아니라, 코딩 에이전트를 더 현실적인 목표로 미세조정할 수 있는 감독 신호 저장소이기도 하다.

마지막으로 SWE-chat은 제품 운영 지표를 더 정교하게 만드는 데도 쓸 수 있다. 예를 들어 에이전트가 ExitPlanMode 뒤에 자주 끊긴다면, 그 전환 지점에 추가 설명이나 확인 절차를 넣는 식의 제품 개선이 가능하다. correction이 rejection보다 월등히 많다면, 사용자가 완전한 재생성보다 부분 수정 인터페이스를 원한다는 뜻일 수도 있다. 즉, 이 데이터셋은 연구용 논문 데이터가 아니라 실제 코딩 에이전트 제품의 telemetry 설계 원본으로도 읽을 수 있다.

7. 한계점 및 향후 연구 방향: 로그가 포착하지 못한 실패까지 보기 위해

논문이 스스로 인정하는 첫 번째 한계는 표본 편향이다. Entire CLI를 공개 저장소에 설치하고, 공개 checkpoint logging에 동의한 개발자만 데이터에 들어온다. 따라서 이 표본은 오픈소스 지향적이며, 새로운 도구를 빠르게 받아들이는 사용자 쪽으로 치우쳐 있다. 기업 내부 저장소, 레거시 코드베이스, 엄격한 보안 정책 아래의 개발 문화는 거의 반영되지 않는다. 실제로 에이전트가 가장 고전할 수 있는 환경이 빠져 있다는 뜻이기도 하다.

두 번째 한계는 abandonment bias다. 사용자가 에이전트 결과를 완전히 버리고 커밋하지 않으면, 그 세션 로그는 데이터셋에 남지 않는다. 저자들도 그래서 session success와 efficiency가 과대평가될 수 있다고 적는다. 이는 이 논문의 거의 모든 핵심 수치와 연결된다. 예컨대 90%의 세션이 50점 이상이라는 성공도, 44.3%의 code survival, 39%의 pushback 비율은 모두 “그래도 어느 정도 기록으로 남은 세션”을 중심으로 관찰한 값일 가능성이 있다.

세 번째 한계는 line-level attribution의 구조적 제약이다. 인간이 에이전트의 제안을 보고 다른 파일로 재작성하거나, 형태는 바꾸지만 의미는 유지한 경우, 현재 방식은 그것을 살아남은 코드로 잡아내지 못할 수 있다. 반대로 에이전트가 쓴 코드가 최종 파일에 남아 있더라도, 그것이 얼마나 좋은 설계였는지는 별도 문제다. 결국 line attribution은 매우 유용한 시작점이지만, 코드 품질과 사용자 만족을 완전히 대체하지는 못한다.

네 번째 한계는 LLM judge와 proxy metric의 불완전성이다. 프롬프트 문자 수로 cognitive burden를 재거나, committed LOC로 생산성을 재는 방식은 어디까지나 대리 지표다. 마찬가지로 session success는 사람 gold set과 어느 정도 맞아도 완전한 객관 점수는 아니다. 논문이 이 한계를 숨기지 않는다는 점은 오히려 장점이다. SWE-chat은 “모든 답을 준다”기보다, “지금까지 없던 관찰창을 열어 준다”는 쪽이 더 정확하다.

향후 연구 방향으로 저자들은 세 가지를 제시한다. 첫째, real workflow grounded benchmark를 만드는 일이다. 둘째, correction-response cycle을 더 잘 흡수하는 상호작용 설계를 연구하는 일이다. 셋째, 실제 로그를 바탕으로 user simulator를 학습해 offline evaluation을 강화하는 일이다. 모두 타당한 방향인데, 그 공통된 전제는 동일하다. 이제 코딩 에이전트 연구도 curated issue만 볼 것이 아니라, 실제 사용 데이터가 만든 마찰과 편향을 함께 봐야 한다는 점이다.

여기에 더해 나는 사내 코드베이스 일반화 문제가 앞으로 매우 중요해질 것이라고 본다. 공개 오픈소스 저장소는 문서화 정도, 협업 문화, 리뷰 루프, 배포 구조가 기업 내부 환경과 다를 수 있다. 사내 저장소는 종종 더 많은 레거시 코드와 비공개 도메인 지식을 포함하고, 반대로 내부 라이브러리와 테스트 인프라가 잘 갖춰져 있을 수도 있다. 따라서 SWE-chat에서 관찰된 수치가 기업 현장에서 어떻게 달라질지, 특히 code understanding과 git 작업 비중이 어떻게 바뀔지는 별도 연구가 필요하다.

또 하나는 관측되지 않는 인간 시간이다. 논문은 prompt 문자 수와 세션 시간을 바탕으로 cognitive efficiency를 근사하지만, 실제 사용자는 에이전트 출력을 오래 읽고 비교하고 고민할 수 있다. 특히 보안에 민감한 저장소일수록 인간 리뷰 시간이 훨씬 커질 수 있다. 현재 지표는 세션 바깥의 인지 비용을 충분히 잡지 못하므로, 앞으로는 commit 전후의 리뷰 시간이나 revert 결정 시간을 함께 재는 계측이 필요하다.

윤리와 개인정보 측면도 가볍게 넘길 수 없다. 논문은 공개 저장소, 라이선스 허용 범위, PII 제거, TruffleHog 기반 credential 제거, IRB exempt review를 명시한다. 이런 절차는 단지 형식적 문구가 아니라, 실제 상호작용 로그를 공개 데이터셋으로 바꿀 때 반드시 필요한 안전장치다. 코딩 에이전트 로그에는 코드뿐 아니라 사람의 업무 맥락과 계정 정보, 내부 서비스 흔적이 섞일 수 있기 때문에, 앞으로 이 분야가 커질수록 데이터 거버넌스가 연구 품질만큼 중요해질 가능성이 크다.

그럼에도 나는 이런 한계들이 SWE-chat의 가치를 깎는다고 보지는 않는다. 오히려 이 논문은 “무엇을 아직 보지 못하고 있는가”를 비교적 정직하게 드러낸다. 실패 세션 누락, semantic survival 미포착, 기업 환경 부재 같은 약점이 명시되어 있기 때문에, 후속 연구는 이 빈칸을 채우는 방향으로 더 구체적인 질문을 만들 수 있다. 좋은 데이터셋은 모든 답을 담는 것이 아니라, 다음에 어떤 계측을 더 붙여야 하는지를 명확히 보여 주는 경우가 많다.

결국 7절의 메시지는 비관이 아니라 정밀화다. 코딩 에이전트의 사용은 이미 충분히 현실이 되었고, 이제 남은 일은 그 현실을 더 정확히 측정하는 것이다. abandonment, review overhead, enterprise setting, semantic code reuse, long-horizon supervision 같은 빈칸이 채워질수록, 코딩 에이전트 평가는 단순한 과제 해결률에서 실제 개발 생산성의 계측 과학으로 더 가까워질 것이다.

8. 내 해석: commit survival 중심 지표의 힘과 blind spot

나는 이 논문을 읽으면서, 이전에 코딩 에이전트를 다룰 때 자주 이야기되던 read:edit 비율이나 사용자 교정 빈도 같은 운영 감각이 결국 맞는 방향이었다고 느꼈다. SWE-chat은 그 감각을 실사용 로그와 커밋 결과로 구체화한다. 특히 세션 성공도는 높지만 code survival은 44.3%에 머물고, pushback은 약 39% 수준이라는 결과는 “그럴듯하게 잘 돌아가는 것처럼 보여도, 실제 산출물 관점에서는 인간이 많이 쳐내고 있다”는 사실을 분명하게 말해 준다. 내 기준에서 이 논문의 가장 큰 강점은 여기다. 코딩 에이전트를 멋진 데모가 아니라 남는 코드와 감독 비용의 관점으로 다시 보게 만든다.

다만 약점도 명확하다. 내가 가장 걸리는 부분은 역시 커밋에 남은 세션 중심의 선택 편향이다. 저자들도 인정하듯, 사용자가 결과를 완전히 버리고 세션을 접어 버리면 그 실패는 데이터에 거의 남지 않는다. 그렇다면 지금 논문이 보여 주는 90%의 session success나 44.3%의 survival도 사실은 관측 가능한 실패만 남은 하한선일 수 있다. 더구나 현재 표본은 공개 오픈소스 저장소와 Entire opt-in 사용자에 편중되어 있어, 사내 코드베이스나 문서화가 빈약한 레거시 환경에서는 훨씬 더 낮은 수치가 나올 가능성이 있다.

내가 이 연구를 다음 단계로 확장한다면, 가장 먼저 abandonment-aware SWE-chat을 만들고 싶다. 최종 커밋이 없더라도 세션 시작부터 마지막 turn까지는 남기고, 거기에 abandonment rate, revert within N commits, plan mode 이탈 지점, review overhead 같은 지표를 붙이면 좋겠다. 그러면 코딩 에이전트 평가는 “얼마나 많이 썼는가”에서 “얼마나 적절한 순간에 멈추고, 얼마나 적은 검수 비용으로 채택되는가” 쪽으로 한 단계 더 진화할 수 있다. SWE-chat은 그 출발점으로는 충분히 강하고, 동시에 그 다음 연구 질문도 분명하게 남긴다.

또 하나 내가 붙여 보고 싶은 축은 read:edit ratio 같은 운영 신호다. SWE-chat은 이미 read, grep, git, edit, build 같은 도구 분포를 제공하므로, 세션 success나 code survival과 이 비율을 연결해 보면 “얼마나 읽고 나서 수정해야 결과가 더 잘 남는가”를 더 직접적으로 볼 수 있다. 지금 논문은 그 직관을 부분적으로 보여 주지만, 후속 연구에서는 이 신호를 시간축 위에서 더 세밀하게 모델링할 수 있을 것이다.

마찬가지로 컴퓨터 사용 에이전트의 reliability 논의와 SWE-chat을 연결하면, 코딩 에이전트에서도 one-shot solve보다 반복 가능한 협업 품질이 더 중요하다는 점을 더 분명히 말할 수 있다. 내가 보기에는 앞으로의 핵심 질문은 “혼자 오래 돌 수 있는가”보다 “여러 번 반복해도 비슷한 비용과 비슷한 채택률로 안정적으로 협업할 수 있는가”가 될 가능성이 크다. SWE-chat은 그 질문을 세우기 위한 첫 번째 실사용 데이터셋으로 충분히 설득력이 있다.

9. 결론: 패치 벤치마크에서 실제 워크플로 데이터셋으로

SWE-chat은 코딩 에이전트 연구의 초점을 결과 패치에서 실제 워크플로로 옮겨 놓는다. 이 데이터셋은 사람들이 에이전트를 무엇에 쓰는지, 에이전트가 어느 정도 자율적으로 움직이는지, 그 코드가 실제로 얼마나 남는지, 사용자 교정과 보안 리스크가 어떤 형태로 나타나는지를 한 번에 읽게 해 준다. 덕분에 코딩 에이전트를 둘러싼 많은 논쟁이 “느낌”에서 “측정 가능한 현상”으로 조금 더 이동한다.

논문의 메시지는 의외로 단순하다. 코딩 에이전트는 이미 널리 쓰인다. 하지만 전면 위임은 아직 효율적이지도, 충분히 안전하지도 않다. 그리고 인간의 교정은 여전히 핵심적이다. 이 세 문장이 함께 성립한다는 점이 중요하다. 에이전트가 쓸모없다는 뜻도 아니고, 곧바로 인간을 대체한다는 뜻도 아니다. 오히려 지금의 코딩 에이전트는 강한 초안 작성기이자 끊임없이 감독해야 하는 협업자에 가깝다.

그래서 SWE-chat의 가장 큰 기여는 단일 숫자보다 평가 문법의 변경에 있다. 앞으로 코딩 에이전트를 이야기할 때는 benchmark score뿐 아니라 code survival, cost per committed LOC, pushback rate, interruption point, security findings 같은 실전 지표를 함께 봐야 한다. SWE-chat은 그 전환을 위한 첫 번째 공개 토대를 마련한 논문으로 기억될 가능성이 크다.

이 변화는 연구자뿐 아니라 실제 도구를 도입하는 팀에도 중요하다. 팀이 코딩 에이전트의 가치를 평가할 때 단순히 “얼마나 많은 코드를 생성했는가”만 보면 착시가 생긴다. SWE-chat이 보여 주듯, 많이 쓴 코드가 실제로는 커밋 전에 상당 부분 버려질 수 있고, 남은 코드조차 더 많은 취약점을 품을 수 있다. 따라서 조직 관점의 KPI도 총 토큰이나 총 생성 줄 수보다 채택률, 재작업률, 리뷰 비용, 보안 회귀 쪽으로 이동해야 한다.

개발자 경험 측면에서도 이 논문은 중요한 균형점을 제시한다. 에이전트는 이미 충분히 유용해서 사람들은 계속 쓰고 있고, vibe coding도 빠르게 늘고 있다. 하지만 사용자는 여전히 correction과 interruption으로 개입하며, collaborative 모드가 비용-시간-안전성 측면에서 더 낫다. 즉 지금의 코딩 에이전트는 “자율성을 최대화할수록 좋다”는 단순한 방향보다, 어떤 단계에서 인간 판단을 섞는 것이 전체 시스템 성능을 높이는가를 찾는 방향으로 최적화되어야 한다.

나는 SWE-chat이 앞으로 코딩 에이전트 연구에서 신뢰성 논의의 기준점이 될 가능성이 크다고 본다. 컴퓨터 사용 에이전트에서 repeated-run reliability가 중요했듯, 코딩 에이전트에서도 이제는 patch solve rate 대신 실제 채택된 코드, 사람이 개입한 지점, 보안 비용, 장기 세션의 마찰을 함께 봐야 한다. SWE-chat은 그 네 축을 같은 데이터셋 안에서 동시에 볼 수 있게 만든 첫 사례라는 점에서 오래 남을 논문이다.

결국 이 논문이 남기는 마지막 메시지는 낙관과 경계가 동시에 필요하다는 것이다. 코딩 에이전트는 이미 실전 도구가 되었고, 실제 개발자들은 이를 통해 상당한 양의 코드를 생성하고 있다. 그러나 그 힘을 제대로 쓰려면 더 긴 autonomy만 추구할 것이 아니라, 잘못된 방향으로 오래 가기 전에 멈추게 하는 장치, 수정 의도를 빠르게 반영하는 인터페이스, 커밋 이후 품질을 계속 추적하는 계측이 함께 필요하다. SWE-chat은 바로 그 다음 단계를 준비하게 만드는 논문이다.

만약 이 논문을 팀 도입 관점에서 한 줄로 요약한다면, “코딩 에이전트는 이미 유용하지만, 지금 필요한 것은 더 많은 자율성보다 더 좋은 감독 설계”라고 말할 수 있다. 이 문장은 SWE-chat의 거의 모든 결과를 관통한다. survival, 비용, 취약점, pushback, interruption 모두가 같은 방향을 가리킨다. 인간이 빠져야 한다는 것이 아니라, 인간이 어떤 순간에 개입해야 가장 큰 효과를 내는지를 더 똑똑하게 설계해야 한다는 뜻이다.

그 점에서 SWE-chat은 단순한 2026년 snapshot이 아니라, 앞으로 나올 코딩 에이전트 연구를 읽는 기준선으로 남을 가능성이 크다. 이후 논문이 더 높은 solve rate를 주장하더라도, 이제는 동시에 “채택된 코드가 얼마나 늘었는가”, “보안 회귀는 줄었는가”, “pushback과 interruption은 줄었는가”를 묻게 될 것이다. SWE-chat이 중요한 이유는 새 숫자를 하나 더 만든 데 있지 않고, 무엇을 함께 물어야 하는지를 바꿔 놓았다는 데 있다.

나는 이런 종류의 실사용 데이터셋이 늘어날수록 코딩 에이전트 담론도 더 건강해질 것이라고 본다. 막연한 생산성 낙관론이나 데모 기반 비관론 대신, 어떤 작업에서 누구에게 어떤 비용으로 도움이 되는지 더 정확히 말할 수 있기 때문이다. SWE-chat은 아직 완전하지 않지만, 바로 그 불완전성까지 공개한 덕분에 후속 연구가 무엇을 더 채워야 하는지도 분명하다. 그래서 이 논문은 결과표 하나보다 연구와 제품 모두의 질문 방식을 갱신한 작업으로 읽는 편이 맞다.

같은 맥락에서 SWE-chat은 코딩 에이전트 논의를 “모델이 똑똑한가”라는 추상 질문에서 “실제 개발 흐름에 들어갔을 때 무엇이 남고 무엇이 버려지는가”라는 구체 질문으로 전환한다. 이 차이는 작지 않다. 전자는 데모로도 이야기할 수 있지만, 후자는 로그와 커밋, 인간 개입 기록이 있어야만 말할 수 있다. SWE-chat이 바로 그 기록을 제공한다는 점에서, 이 논문은 단순한 데이터셋 소개를 넘어 코딩 에이전트 평가의 좌표계 자체를 업데이트한 작업으로 볼 만하다.

그래서 이 논문을 읽고 나면 앞으로 코딩 에이전트 관련 주장에 대해 자연스럽게 질문이 더 늘어난다. solve rate가 얼마인지뿐 아니라, 그 결과가 실제로 채택되었는지, 얼마나 많은 수정과 재실행이 필요했는지, 보안 비용은 어땠는지, 사용자가 언제 개입했는지를 함께 묻게 된다. SWE-chat의 가장 큰 성과는 바로 이 질문 목록을 연구자와 실무자 모두의 기본 체크리스트로 밀어 올렸다는 점이다.

이런 의미에서 SWE-chat은 단지 “코딩 에이전트가 인기다”를 보여 주는 자료가 아니라, 인기 이후에 반드시 따라붙어야 할 품질 관리 문법을 같이 제시하는 논문이다. 채택된 코드와 버려진 코드 사이의 차이를 끝까지 추적하는 연구가 왜 중요한지, 이 글 전체가 그 점을 반복해서 증명한다.

실무자가 이 논문에서 바로 가져갈 수 있는 교훈은 분명하다. 코딩 에이전트를 잘 쓰는 일은 더 강한 모델 하나를 고르는 문제가 아니라, 남는 코드의 비율을 높이고 버려지는 코드의 비용을 줄이는 운영 설계를 만드는 문제다.

10. 요약 정리: SWE-chat이 남긴 핵심 포인트

• SWE-chat은 실제 오픈소스 개발자의 코딩 에이전트 세션을 모은 대규모 실사용 데이터셋으로, 약 6,000세션과 63,000개 이상의 프롬프트, 355,000개 이상의 tool call을 포함한다.
• 이 데이터셋의 차별점은 real human prompts, agent trajectories, code diffs, line-level code attribution을 한 번에 제공한다는 점이다.
• 실제 사용자 의도 분포를 보면 code understanding, git 작업, debugging 비중이 높아, 패치 생성 중심 벤치마크만으로는 현실 사용을 충분히 설명하기 어렵다.
• 코딩 모드는 human-only 22.7%, collaborative 36.5%, vibe coding 40.8%로 나뉘며, vibe coding 비중은 관찰 기간 동안 빠르게 늘어난다.
• 전체 committed LOC 중 에이전트가 작성한 비율은 크지만, 실제로 최종 커밋에 살아남는 에이전트 코드 비율은 44.3%에 그친다.
• Collaborative coding은 현재 기준 가장 효율적인 사용 모드로 보이며, vibe coding은 토큰, 비용, 시간 측면에서 더 비싸다.
• 보안 측면에서 vibe coding은 1,000 added lines당 0.76개의 취약점을 도입해 human-only보다 약 9배, collaborative보다 약 5배 높은 위험도를 보인다.
• 에이전트의 clarification 비율은 매우 낮지만, 사용자의 pushback과 interruption은 높아 현재 코딩 에이전트가 여전히 강한 인간 감독에 의존함을 보여 준다.
• 이 논문의 약점은 commit에 남은 세션 중심의 표본 편향이다. 완전히 버려진 실패 세션은 포착되지 않아 실제 실패율은 더 높을 수 있다.
• 그럼에도 SWE-chat은 코딩 에이전트 평가를 benchmark score에서 실제 워크플로 기반 계측으로 옮겨 놓은 중요한 출발점이다.