The End of Software Engineering: 코드가 사라진다는 주장과 그 근거의 무게¶
- 논문: The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm
- HTML: arXiv:2606.05608v1
- 저자: Zhenfeng Cao (단독)
- 소속: Lingxi Intelligent Investment (Shenzhen) Development Co., Ltd.
- arXiv: 2606.05608v1 [cs.SE], 2026-06-04 제출
- 라이선스: CC BY 4.0
- 읽은 날짜: 2026-09-02
- 태그: #AgenticEngineering #AIAgent #SoftwareEngineering #PositionPaper #SWEbench #비판적읽기
한 줄 요약¶
"코드는 시스템이 아니라 LLM이 필요할 때 만들고 버리는 소모품이 된다"는 주장을 first principles로 세우고 SaaS 다음 세대를 AaaS(Agent-as-a-Service)로 규정한 선언문 성격의 포지션 페이퍼. 새 실험도 새 데이터도 없다.
이 논문의 성격부터 짚고 간다¶
읽기 전에 알아두면 기대치가 맞는다. 단독 저자이고 소속은 선전 소재 투자회사다. 새로운 실험, 벤치마크, 시스템 구현이 없다. 기존 벤치마크 결과와 블로그·오픈소스 레포를 인용해 논지를 세운 주장문이다.
그렇다고 읽을 가치가 없지는 않다. 흩어져 있던 논의를 한 축으로 꿰어 정리한 부분과 자기 주장에 불리한 반대 증거를 숨기지 않고 5장에 배치한 태도는 볼 만하다. 다만 "논문이 증명했다"가 아니라 "저자가 이렇게 주장한다"로 읽어야 한다.
세 가지 중심 주장¶
- First-Principles Necessity. 에이전트 패러다임은 시장의 취향이 아니라 복잡도 스케일링의 필연적 귀결이다.
- Paradigm Shift, Not Optimization.
AI -> 소프트웨어 -> 결과에서에이전트 -> 결과로 넘어가면서 소프트웨어 산출물 자체가 중간 매개에서 빠진다. - Emergent Discipline. Agentic Engineering은 별개 분과로 떠오른다. 그 실무자는 "더 나은 프로그래머"가 아니라 의도 설계자, 에이전트 조율자, 결과 감사자라는 다른 직군이다.
논증 구조¶
1. 전통 소프트웨어의 정의¶
전통 시스템을 (R, L, E) 튜플로 정의한다. R은 계산 자원, L은 소스코드에 인코딩된 결정론적 결정 규칙, E는 실행 환경이다. L은 실행에 대해 정적이다. 이 점이 핵심이다. 모든 결정 논리는 시스템이 입력을 만나기 전에 사람이 미리 써둬야 한다.
2. 복잡도 장벽¶
Brooks의 essential complexity 논의를 가져와 Proposition 2.1을 세운다. 컴포넌트가 n개일 때 각 쌍이 상호작용할 수도 안 할 수도 있으므로 가능한 의존 그래프는 2^(n(n-1)/2)개다. 반면 사람의 인지 용량은 사실상 상수다. 계층 분해와 모듈 인터페이스는 상수항을 줄일 뿐 점근 거동을 바꾸지 못한다. 이 절의 결론이다.
3. 에이전트 시스템의 정의¶
에이전트를 (M, T, Mem, P) 튜플로 정의한다. M은 추론 엔진인 LLM, T는 실행 도구, Mem은 단기 컨텍스트와 장기 벡터 저장소, P는 의도를 행동 시퀀스로 쪼개는 계획 기제다. 결정 논리가 런타임에 생성된다는 점이 결정적으로 다르다. 생성된 코드는 시스템이 아니라 필요할 때 만들어졌다 버려지는 일시적 산출물이다.
저자는 이것을 Karpathy의 Software 2.0에서 한 걸음 더 나간 자리에 놓는다. Software 2.0에서 신경망이 손으로 짠 로직을 대체했다면, 에이전트에서는 신경망이 프로그램을 대체하는 게 아니라 필요할 때마다 프로그램을 쓴다.
4. 왜 에이전트가 더 잘 확장되는가¶
해답 탐색 공간의 크기를 S라 할 때, 전통 방식에서는 사람의 인지 용량 C_human이 고정이라 S가 그보다 크면 어떤 비용을 치러도 불가능하다. 에이전트 방식에서는 LLM의 유효 용량 C_LLM이 모델 크기와 학습 연산량에 따라 늘고 계획 기제가 문제를 쪼개며 코드는 실제로 밟는 경로에만 생성된다. 여기서 해결 용량이 인간 인지 한계와 분리된다는 결론이 나온다.
SaaS에서 AaaS로¶
상용 소프트웨어의 역사를 "복잡도를 최종 사용자에게서 계속 떼어내는 과정"으로 읽는다.
| 세대 | 작동 방식 | 복잡도 소유자 | 수익 모델 | 사례 |
|---|---|---|---|---|
| Software 1.0 (Local) | 코드와 데이터가 온프레미스에서 실행 | 최종 사용자 (설치·유지보수) | 라이선스 판매 | Microsoft, Oracle |
| Software 2.0 (SaaS) | 코드와 데이터가 클라우드에서 실행 | 벤더 (인프라·업데이트) | 구독 | Salesforce, AWS |
| Software 3.0 (AaaS) | 에이전트가 클라우드에서 자율 작동 | 에이전트 (이해·구축·실행) | 결과 기반 | OpenAI, Anthropic |
SaaS가 기업을 서버실에서 해방했다면, AaaS는 결과를 어떻게 만들지 명세할 필요에서 해방한다. 저자가 그린 구도다. 무엇을 원하는지만 말하면 된다.
이어서 지금 주류인 AI -> 소프트웨어 -> 결과 방식의 구조적 약점 세 가지를 든다. 사람이 설계·통합·배포의 임계 경로에 그대로 남고(병목 존속), 최종 산출물이 여전히 전통 소프트웨어라 복잡도 천장이 그대로다. 기능 변경마다 요구사항부터 배포까지 전 체인을 도는 반복 지연은 사람의 소통 속도 밑으로 내려가지 못한다.
Agentic Engineering이라는 분과¶
LangChain이 2026년 4월에 제시한 정의를 가져온다. "AI 에이전트가 각자 역할과 공유 메모리, 통합 관측 계층을 갖춘 디지털 팀원으로 기능하며, 코드를 더 빨리 생성하는 데 그치지 않고 전달 파이프라인 전체를 끌고 가는 다중 에이전트 조율 모델."
| 차원 | 전통 SE | Agentic Engineering |
|---|---|---|
| 핵심 산출물 | 소스코드 (정적) | 에이전트 시스템 (동적) |
| 통제 중심 | 사람 엔지니어 | LLM 추론 엔진 |
| 결정 기제 | 사전 설계된 로직 | 런타임 생성 추론 |
| 개발 주기 | 선형 (설계 -> 코드 -> 테스트) | 자율 반복 루프 |
| 사람의 역할 | 코드 작성자 | 의도 설계자, 조율자, 감사자 |
| 복잡도 천장 | 사람의 인지 | 모델 용량 (연산량에 따라 증가) |
| 산출 단위 | 동작하는 소프트웨어 | 전달된 결과 |
| 오류 처리 | 프로그래머가 정의 | 모델이 적응 |
| 진화 | 수동 리팩터링 | 자기 수정 |
사람에게 남는 차별화 요소로는 의도 표현, 아키텍처 감독, 품질 기준 정의, 윤리적 거버넌스 네 가지를 든다.
근거로 든 실증 자료¶
| 항목 | 내용 | 출처 성격 |
|---|---|---|
| SWE-bench Verified | Lingma SWE-GPT 72B가 GitHub 이슈 30.20% 해결, GPT-4o 31.80%에 근접. 7B도 18.20% | 피어리뷰 논문 (2024-11) |
| 다중 에이전트 조율 | 기업 디버깅 워크플로 20여 건에서 근본원인 규명 시간 93% 단축, 한 달 200시간 절감 | 벤더 블로그 파일럿 |
| 자기 진화 | Hermes Agent가 작업 후 재사용 가능한 Skill을 스스로 만들고, 부족하면 자동으로 기워 넣는 폐루프 | 오픈소스 레포 |
| 일반화 | Wang et al. 서베이가 요구사항 분석부터 유지보수까지 전 주기 적용 사례를 집대성 | 서베이 논문 |
반대 증거: 연속 진화에서 무너진다¶
저자가 스스로 "가장 냉정한 데이터"라 부른 부분이다. 고립된 이슈 수정이 아니라 커밋 히스토리를 따라 계속 개발하면서 시스템 무결성을 유지해야 하는 벤치마크에서 성공률이 고립 과제 80% 이상에서 연속 설정 최대 38%로 떨어진다. 프런티어 모델 12개를 에이전트 프레임워크 4종에서 평가한 결과다.
원인으로 네 가지를 든다.
- 컨텍스트 표류. 코드베이스가 유효 컨텍스트 창을 넘어서면 시스템 전역 불변식과 의존관계 이해가 깨진다.
- 오류 전파. 초기 커밋의 작은 오류가 이후 작업에서 복리로 커지는데, 이 연쇄를 탐지하고 회복하는 기제가 없다.
- 기술 부채 무감각. 설계 결정의 장기 비용을 모델링하지 않고 당장의 과제 완료만 최적화한다.
- 검증 충실도. 테스트를 통과하면서도 새로운 입력에서만 드러나는 미묘한 의미 오류를 넣을 수 있다.
저자는 이 격차를 "근본적인 것이 아니라 컨텍스트 관리, 메모리 구조, 검증 기제의 한계"로 규정하고 오늘의 Agentic Engineering은 증강 패러다임으로서는 실재하고 변혁적이지만 완전 자율 개발은 몇 년의 집중 연구가 더 필요하다고 정리한다. 선언문치고는 절제된 결론이다.
4단계 로드맵¶
| 단계 | 에이전트 능력 | 사람의 역할 | 대표 시스템 |
|---|---|---|---|
| I. Tool-Augmented (2023~2025) | 코드 완성, 단일 이슈 수정 | 작성자 + 리뷰어 | GitHub Copilot, Claude Code |
| II. Single-Task Autonomous (2025~2027) | 기능 단위 종단 구축, 디버깅 | 의도 설계자 + 감사자 | Devin, OpenHands |
| III. Multi-Agent Teams (2026~2029) | 대형 시스템 조율, 전 주기 관리 | PM + 아키텍트 + 감사자 | LangChain 조율, MetaGPT |
| IV. Self-Evolving Ecosystems (2028~) | 자율 발견·학습·번식·적응 | 목표 설정자 + 윤리 감독 | (전망) |
비판적 검토¶
읽으면서 걸린 지점들이다. 인용은 직접 확인했다.
- 형식화가 장식에 가깝다. Proposition 2.1이 세는 2^(n(n-1)/2)는 "가능한 의존 그래프의 개수"지 저자가 말한 "상호작용 경로 수"가 아니다. 게다가 이 값을 사람의 인지 용량과 나란히 놓고 비교하는 것은 단위가 다른 양을 견주는 셈이다. Definition 2.1, 2.2도 튜플 표기만 있을 뿐 이후 논증에서 실제로 쓰이지 않는다. 수식을 걷어내도 주장은 그대로 남는다.
- 핵심 전제가 인용 없이 단언된다. 논증 전체가 "C_LLM이 학습 연산량에 따라 계속 증가한다"에 기대는데, 괄호 안에 "which they have been, exponentially"라고 적혔을 뿐 근거가 없다. 이 전제가 흔들리면 4절 전체가 무너진다.
- 돌파 근거의 시점이 낡았다. 핵심 근거로 든 SWE-bench 수치는 2024년 11월 논문의 30.20%다. 2026년 6월 시점에 패러다임 전환을 논하면서 1년 반 전 수치를 "돌파"로 제시하는 것은 설득력이 약하다. 그사이 이 벤치마크 점수는 크게 올라갔다.
- 근거 넷 중 둘이 피어리뷰 밖이다. 93% 단축은 벤더 블로그의 파일럿이고 표본은 워크플로 20여 건이다. 자기 진화 근거는 오픈소스 레포 소개다. 인상적이긴 해도 논문이 기대는 무게를 견디긴 어렵다.
- 인용 오류가 있다. 참고문헌 [10]의 SWE-bench 저자를 X. Wang 외 9인으로 적었는데, 실제 SWE-bench(arXiv:2310.06770, ICLR 2024)의 저자는 Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan이다.
- 벤치마크 이름이 현재 원문과 다르다. 논문은 arXiv:2603.13428을 EvoClaw로 인용하지만 확인 시점의 해당 문헌 제목은
SWE-Milestone: Evaluating AI Agents on Continuous Software Evolution이다. 저자 목록은 일치하므로 개명으로 보이나, 이름으로 검색하면 못 찾는다. - 날짜가 어긋난다. arXiv 제출 스탬프는 2026-06-04인데 본문 표지 날짜는 2026-08-24다.
- 반증 가능성이 없는 문장으로 끝난다. "The old software engineering is ending; the new one has already begun." 어떤 관측이 나와야 이 주장이 틀리는지 논문 어디에도 없다.
그럼에도 건질 것¶
비판과 별개로 실무에 옮길 만한 대목이 있다.
- 고립 과제와 연속 진화의 성능 격차는 지금 에이전트를 어디까지 맡길지 정하는 실질 기준이다. 명확한 성공 조건과 테스트 인프라가 있는 범위로 한정하라는 권고가 이 데이터에서 나온다.
- 관측 인프라에 먼저 투자하라는 권고는 동의할 만하다. 에이전트 추론 사슬 추적, 환각 탐지, 결과 품질 측정은 기존 모니터링 도구로 안 된다.
- 평가 프레임워크가 산출물 품질을 결정한다는 지적도 맞다. 에이전트에 자기 교정을 시키려면 교정의 기준이 되는 평가 신호가 먼저 있어야 한다.
AI -> 소프트웨어 -> 결과와에이전트 -> 결과의 구분은 프레이밍으로서 쓸모가 있다. 지금 만드는 것이 사람의 개발을 빠르게 하는 도구인지, 결과를 직접 내놓는 시스템인지 갈라 보게 만든다.
가져갈 지점¶
- 연속성이 실제 병목이라는 확인
RAG든 에이전트든 한 번의 질의응답에서는 잘 되다가 세션이 이어지면 무너지는 현상은 같은 뿌리다. 컨텍스트 표류와 오류 전파는 검색 파이프라인에서도 그대로 나타난다. LogicRAG의 rolling memory나 ROGRAG의 다단계 격하 같은 장치가 결국 이 문제를 다룬다.
- 검증을 어디에 둘 것인가
이 논문이 연구 과제로 꼽은 "개방된 환경에서의 검증"은 ROGRAG의 argument checking 실험과 같은 자리를 가리킨다. 답을 만든 뒤 판정하는 것보다 근거가 충분한지를 먼저 보는 쪽이 낫다는 결과는 에이전트 루프에도 그대로 적용해볼 만하다.
- 인용은 직접 확인한다
이 논문을 읽으면서 확인한 인용 넷 중 둘에서 문제가 나왔다. 저자명이 틀렸고 벤치마크 이름이 현재 문헌과 달랐다. 포지션 페이퍼를 인용할 때는 그 논문이 인용한 원문까지 열어보는 편이 안전하다.
결론¶
주장은 크고 근거는 그에 못 미친다. 형식 정의와 명제로 감싼 논증은 걷어내면 "LLM 용량이 계속 는다면 사람이 못 풀던 문제를 풀게 된다"는 한 문장으로 줄어든다. 그 전제 자체는 증명되지 않았다.
읽을 값어치는 다른 데 있다. 5장의 반대 증거가 이 논문에서 가장 단단한 부분이다. 고립 과제 80% 이상에서 연속 진화 최대 38%로 떨어진다는 수치는 에이전트를 어디까지 맡길지 정할 때 실제로 쓸 수 있는 숫자다. 선언에 해당하는 1~4장보다 스스로의 주장에 제동을 거는 5장을 먼저 읽는 편을 권한다.