소프트웨어 공학의 종말인가, 추상화 경계의 이동인가
이 글은 Zhenfeng Cao의 논문 “The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm”를 한국어로 정리하고, 23년간 소프트웨어 개발과 아키텍처 현장을 경험한 관점에서 비판적으로 해석한 글입니다. 논문의 주장과 필자의 해석을 구분해 기술했습니다.
원문: arXiv:2606.05608v1 · cs.SE · CC BY 4.0
들어가며: 제목보다 중요한 질문
“소프트웨어 공학의 종말”이라는 제목은 도발적입니다. 그러나 이 논문이 실제로 묻는 질문은 조금 다릅니다.
소프트웨어의 의사결정 로직은 반드시 사람이 미리 작성한 정적 코드 안에 있어야 하는가?
전통적인 소프트웨어는 개발자가 가능한 상황을 분석하고 그 판단을 조건문·상태 머신·규칙·워크플로로 코드에 고정합니다. 에이전틱 소프트웨어에서는 LLM이 목표와 맥락을 해석하고, 도구를 선택하며, 중간 결과에 따라 다음 행동을 런타임에 결정합니다. 필요하면 코드를 만들고 실행한 뒤 버릴 수도 있습니다.
논문은 이것을 개발 도구의 개선이 아니라 소프트웨어의 본질이 바뀌는 패러다임 전환이라고 주장합니다. 결론부터 말하면, 저는 변화의 방향에는 동의하지만 “종말”이라는 표현에는 동의하지 않습니다. 사라지는 것은 소프트웨어 공학이 아니라, 모든 의사결정을 코드에 선기록해야 한다는 전제입니다.
1. 논문의 핵심 주장 세 가지
- 복잡도 관점의 필연성 — 시스템 상호작용 복잡도는 인간의 인지 능력보다 빠르게 증가하며, 모델 추론과 도구 사용으로 이를 보완해야 한다.
- 최적화가 아닌 전환 —
AI → Software → Result에서Agent → Result로 이동하며, 정적 소프트웨어가 결과를 얻기 위한 필수 중간재가 아니게 된다. - 새로운 공학 규율 — 중심 대상이 소스 코드에서 에이전트 시스템으로, 인간은 코드 작성자에서 의도 설계자·조정자·감사자로 이동한다.
핵심은 AI가 코드를 얼마나 빨리 생성하느냐가 아닙니다. 판단의 위치, 변경의 단위, 책임의 경계가 어디로 이동하는가가 이 논문의 주제입니다.
2. 정적 소프트웨어와 에이전틱 소프트웨어
논문은 전통적 소프트웨어를 다음 튜플로 표현합니다.
\[S=(C,D,E)\]- $C$: CPU·메모리·I/O 같은 계산 자원
- $D$: 소스 코드에 인코딩된 결정 규칙
- $E$: 입력에 규칙을 적용하는 실행 환경
$D$는 실행 중에는 정적입니다. 요구사항이 바뀌면 사람이 변경을 이해하고, 코드의 위치를 찾고, 수정하고, 회귀 여부를 검증합니다.
에이전트 시스템은 다음과 같이 정의합니다.
\[A=(M,\mathcal{T},\mathcal{M},\Pi)\]- $M$: 추론 엔진인 LLM
- $\mathcal{T}$: API·DB·파일 시스템·코드 실행기 등의 도구
- $\mathcal{M}$: 단기 컨텍스트와 장기 기억
- $\Pi$: 목표를 행동 순서로 분해하는 계획 메커니즘
에이전트는 현재 상태를 읽고 행동을 선택한 뒤, 실행 결과로 다음 상태를 만듭니다.
\[a_t \leftarrow M(s_t,\mathcal{M}), \qquad s_{t+1} \leftarrow \operatorname{exec}(a_t)\]| 구분 | 전통적 소프트웨어 | 에이전틱 소프트웨어 |
|---|---|---|
| 중심 산출물 | 정적 소스 코드 | 목표를 수행하는 에이전트 시스템 |
| 판단 시점 | 설계·구현 시점 | 런타임 |
| 제어 중심 | 사람이 정의한 규칙 | 모델·계획·도구 실행 루프 |
| 변경 방식 | 코드 수정과 재배포 | 컨텍스트·도구·정책·모델·메모리 조정 |
| 인간의 역할 | 구현자·리뷰어 | 의도 설계자·조정자·감사자 |
| 결과 단위 | 동작하는 소프트웨어 | 검증된 업무 결과 |
여기서 코드는 시스템 그 자체가 아니라 목적 달성을 위해 생성되는 도구가 될 수 있습니다.
3. License에서 SaaS, 다시 AaaS로
논문은 소프트웨어 전달 모델의 역사를 복잡도의 이전으로 읽습니다.
| 세대 | 사용자가 넘긴 복잡도 | 사용자가 여전히 맡는 일 | 과금 방식 |
|---|---|---|---|
| Software 1.0: 설치형 | 거의 없음 | 설치·인프라·업데이트·사용법 | 라이선스 |
| Software 2.0: SaaS | 운영 복잡도 | 기능을 조합해 결과 만들기 | 구독 |
| Software 3.0: AaaS | 운영 + 의사결정 복잡도 | 목표·제약·완료 기준 제시 | 사용량·성과 기반 |
SaaS는 서버실과 설치 작업을 공급자에게 넘겼지만, 사용자는 여전히 어떤 메뉴를 어떤 순서로 사용해야 하는지 알아야 했습니다. Agent-as-a-Service(AaaS) 는 그 의사결정 복잡도까지 흡수합니다.
예를 들어 사용자는 “지난달 클라우드 비용이 급증한 원인을 찾아 절감안을 제시해 줘”라고 말합니다. 에이전트는 비용 데이터를 조회하고, 배포 이력을 대조하고, 이상 리소스를 찾고, 절감안을 시뮬레이션합니다. 사용자는 기능을 조작하는 대신 원하는 결과와 허용 범위를 정의합니다.
이 변화의 본질은 UI가 대화형으로 바뀌는 것이 아닙니다. 제품의 추상화 경계가 기능(feature) 에서 성과(outcome) 로 올라가는 것입니다.
4. Agentic Engineering과 인간의 역할
Agentic Engineering은 단일 코딩 에이전트를 잘 쓰는 기법이 아닙니다. 역할이 분리된 에이전트, 공유 기억, 관찰 가능성, 전 생애주기 추적성을 묶는 제어 평면(control plane) 에 가깝습니다.
Intent Architect는 목표뿐 아니라 정책, 금지 조건, 품질 기준, 비용·시간 상한, 실패 시 중단 조건을 명세합니다. Agent Coordinator는 탐색·설계·구현·검증 역할을 나누고 공유할 상태와 격리할 권한을 정합니다. Outcome Auditor는 결과가 비즈니스 의도, 보안, 규제, 운영 가능성에 맞는지 판단합니다.
23년 동안 현장에서 아키텍처를 다뤄보면, 기술 변화 때마다 구현의 추상화 수준은 올라갔지만 책임이 사라진 적은 없습니다. 어셈블리에서 고급 언어로, 온프레미스에서 클라우드로, 서버에서 관리형 서비스로 이동할 때도 아키텍트의 일은 없어지지 않았습니다. 오히려 보이지 않는 실패 모드와 공급자 의존성을 판단하는 일이 중요해졌습니다. 에이전트 전환도 같은 패턴을 따를 것입니다.
5. 논문이 제시하는 증거와 한계
- SWE-bench Verified: 논문이 인용한 Lingma SWE-GPT 72B는 실제 GitHub 이슈의 30.20%를 해결했고, GPT-4o의 31.80%에 근접했습니다. 7B 모델도 18.20%를 기록했습니다.
- 멀티에이전트 조정: 논문이 인용한 20개 이상의 기업 디버깅 워크플로 파일럿에서는 근본 원인 식별 시간이 93% 감소하고 한 달에 200시간 이상이 절감됐다고 보고합니다.
- 장기 작업의 성능 절벽: EvoClaw에서는 고립된 단일 작업의 80% 이상 성능이 연속적인 소프트웨어 진화 환경에서 최대 38%로 하락합니다.
마지막 수치가 가장 중요합니다. 실제 엔터프라이즈 시스템은 독립된 GitHub 이슈의 모음이 아닙니다. 과거 결정, 암묵적 계약, 데이터 마이그레이션, 운영 예외와 조직 간 합의가 시간축 위에 누적된 시스템입니다.
논문은 장기 작업의 실패 원인을 네 가지로 정리합니다.
- Context drift — 시간이 길어지면 시스템 불변조건과 초기 의도를 잃는다.
- Error propagation — 초기의 작은 오류가 후속 변경에 누적된다.
- Technical debt blindness — 당장의 테스트 통과를 최적화하고 장기 비용을 보지 못한다.
- Verification gap — 테스트를 통과해도 새로운 운영 조건에서 의미론적 오류가 드러난다.
현재 에이전트의 약점은 코드를 작성하지 못하는 것이 아니라 시간을 가로질러 시스템의 일관성을 보존하는 능력입니다.
6. 논문의 4단계 진화 로드맵
| 단계 | 시기(전망) | 에이전트 역량 | 인간 역할 |
|---|---|---|---|
| I. 도구 보강 | 2023~2025 | 코드 완성, 단일 이슈 수정 | 작성자 + 리뷰어 |
| II. 단일 작업 자율화 | 2025~2027 | 기능 구현·디버깅 E2E | 의도 설계자 + 감사자 |
| III. 멀티에이전트 팀 | 2026~2029 | 역할별 에이전트 협업 | PM + 아키텍트 + 감사자 |
| IV. 자가 진화 생태계 | 2028년 이후 | 자기 수정·학습·전문화 | 목표 설정자 + 윤리 거버너 |
이 일정은 예측이지 약속이 아닙니다. III단계 이후에는 공유 메모리 정합성, 권한 격리, 비용 통제, 관찰 가능성, 책임 소재 같은 분산 시스템 및 거버넌스 문제를 함께 풀어야 합니다.
7. 아키텍트의 비판적 독해
“코드가 사라진다”는 표현은 지나치다
탐색용 코드와 일회성 스크립트는 휘발될 수 있습니다. 그러나 금융 계산, 개인정보 처리, 접근 통제, 데이터 스키마처럼 재현성과 감사가 필요한 영역에서 코드·정책·테스트는 여전히 실행 가능한 계약입니다.
코드는 사라지는 것이 아니라, 제품의 유일한 의사결정 저장소라는 지위를 잃는다.
앞으로 시스템 동작은 코드뿐 아니라 모델, 시스템 프롬프트, 도구 명세, 메모리, 정책, 평가셋의 조합으로 결정됩니다. 버전 관리의 대상은 줄어드는 것이 아니라 넓어집니다.
복잡도 논증은 직관이지 엄밀한 증명이 아니다
논문은 $n$개 컴포넌트의 가능한 의존 그래프 수 $2^{\binom{n}{2}}$를 언급하면서도 본문에는 $P(n)\in\Theta(2^n)$로 표기합니다. 두 표현은 일치하지 않으며 가능한 모든 그래프가 실제 실행 경로를 뜻하지도 않습니다.
LLM 용량이 커진다고 시스템 복잡도를 안정적으로 탐색한다는 보장도 없습니다. 에이전트는 인간의 인지 한계를 확장하지만 비결정성·환각·확률적 실패라는 새 복잡도를 추가합니다. 이 논증은 방향을 설명하는 직관적 모델로 읽어야 합니다.
벤치마크 성능과 운영 신뢰성은 다르다
이슈 해결률은 보안 사고 영향도, 장애 복구 가능성, 데이터 무결성, 3년 뒤 변경 비용을 설명하지 못합니다. 기업 도입에서는 평균 성공률보다 다음이 중요합니다.
- 실패를 사전에 탐지하는 비율
- 잘못된 실행의 영향 반경(blast radius)
- 중단·롤백·보상 가능성
- 의사결정과 도구 호출의 재현성
- 장기 변경에서 불변조건을 지키는 비율
“사람이 병목”이라는 말의 함정
안전·윤리·사업 책임이 걸린 지점에서 사람은 제거해야 할 병목이 아니라 책임을 명시하는 제어 장치입니다. 목표는 human-out-of-the-loop가 아니라, 위험도에 따라 사람이 개입할 위치를 정확히 설계하는 것입니다.
8. 프로덕션 에이전트 시스템의 참조 구조
1
2
3
4
5
6
7
8
9
10
11
┌──────────────────────────────────────────────────────┐
│ 1. Intent & Policy: 목표·제약·완료 기준·승인 정책 │
├──────────────────────────────────────────────────────┤
│ 2. Orchestration: 계획·작업 분해·상태/예산 관리 │
├──────────────────────────────────────────────────────┤
│ 3. Context & Memory: 코드·ADR·도메인 지식·기억 │
├──────────────────────────────────────────────────────┤
│ 4. Tool & Execution: API·DB·샌드박스·최소 권한 │
├──────────────────────────────────────────────────────┤
│ 5. Verification & Observability: 평가·승인·롤백 │
└──────────────────────────────────────────────────────┘
가장 중요한 것은 5번 계층입니다. LLM의 판단이 런타임으로 이동하면 사전 설계만으로 모든 경로를 검증할 수 없습니다. 품질 보증도 코드 리뷰 중심에서 실행 추적과 결과 검증 중심으로 이동해야 합니다.
좋은 하네스는 에이전트에게 자유를 많이 주는 환경이 아니라 다음 질문에 기계적으로 답할 수 있는 환경입니다.
- 지금 무엇을 하려는가?
- 어떤 근거로 이 행동을 선택했는가?
- 어떤 권한과 예산을 사용했는가?
- 성공을 무엇으로 증명하는가?
- 실패하면 어디까지 되돌릴 수 있는가?
- 누가 최종 책임을 승인했는가?
9. 조직이 지금 실행할 일
- 에이전트에 적합한 업무부터 고른다. 명확한 완료 조건, 자동 테스트, 제한된 권한, 쉬운 롤백을 가진 업무가 첫 대상이다.
- 저장소를 에이전트가 이해할 수 있게 만든다. ADR, API 계약, 도메인 용어, 테스트 기준과 금지 규칙을 구조화한다.
- 프롬프트보다 평가 체계를 자산화한다. 골든 태스크, 회귀 테스트, 정책 검사, 실패 사례 데이터셋은 모델이 바뀌어도 남는다.
- 자율성의 등급을 운영한다.
제안 → 샌드박스 실행 → PR → 제한적 배포 → 자율 실행처럼 위험에 맞춰 승급한다. - 생산성을 결과로 측정한다. 생성 코드 줄 수가 아니라 리드타임, 변경 실패율, 복구 시간, 재작업률, 운영 비용으로 평가한다.
맺으며: 끝나는 것은 공학이 아니라 공학의 익숙한 형태다
이 논문은 엄밀한 실증 연구라기보다 방향을 선언하는 포지션 페이퍼에 가깝습니다. 일부 수학적 설명과 미래 일정은 과감하고, 벤치마크에서 산업 전반의 필연성을 끌어내는 과정에는 비약도 있습니다. 그럼에도 중요한 문제를 정확히 짚습니다.
소프트웨어의 중심이 정적 코드에서 목표를 해석하고 행동하는 에이전트로 이동하면, 소스 코드만 잘 구조화해서는 부족합니다. 의도, 컨텍스트, 권한, 기억, 도구, 평가, 감사 가능성을 하나의 실행 시스템으로 설계해야 합니다.
23년차 엔지니어의 시선에서 보면 이것은 소프트웨어 공학의 종말이 아닙니다. 소프트웨어 공학이 코드 바깥으로 확장되는 순간입니다.
앞으로 좋은 아키텍처는 정답 경로를 모두 코딩한 구조가 아니라, 불확실한 판단이 일어나더라도 시스템이 안전하게 관찰하고 검증하고 복구할 수 있는 구조다.
코드를 만드는 능력의 희소성은 낮아질 수 있습니다. 하지만 무엇을 만들지 결정하고, 경계를 세우고, 결과를 신뢰할 수 있게 만드는 능력의 가치는 더 커질 것입니다.
참고 자료
- Zhenfeng Cao, The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm, arXiv:2606.05608v1, 2026.
- Y. Wang et al., Agents in Software Engineering: Survey, Landscape, and Vision, 2024.
- Y. Ma et al., Lingma SWE-GPT, 2024.
- Fred Brooks, The Mythical Man-Month, 1975/1995.
- Andrej Karpathy, Software 2.0, 2017.
이 블로그의 관련 글
- AI-Native Developer: 코드 작성자에서 Creative Director of Code로
- Harness Engineering: AI Agent 시대의 새로운 소프트웨어 공학 패러다임
- 대규모 멀티에이전트 시스템을 위한 패턴