소프트웨어 엔지니어링의 종말
2026년 6월 4일, Zhenfeng Cao가 arXiv에 논문 한 편을 공개했습니다. 제목은 「The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm」. 소프트웨어 엔지니어링의 종말입니다. 논문을 끝까지 읽지는 않았지만, 요즘 이 제목이 여기저기서 떠들썩하게 오르내립니다. 개발자로 일하는 입장에서 그냥 지나치기 어려운 제목입니다.
그런데 6월 10일에 올라온 개정판의 제목은 「Agentic Software: How AI Agents Are Restructuring the Software Paradigm」입니다. 종말이라는 단어가 사라졌습니다. 본문도 소프트웨어 엔지니어링이 끝난다고 말하지 않습니다. AI 에이전트의 등장으로 그 정의와 범위가 확장되고 있다고 설명합니다.
제목에서 빠진 단어 하나가 이 글을 읽는 방향을 바꿉니다. 제가 하는 일이 사라지는지 묻기 전에, 지금까지 그 일을 무엇이라고 생각해 왔는지부터 돌아보게 됩니다.
코드를 만드는 AI에서 일을 수행하는 에이전트로
논문은 사람이 판단 규칙을 미리 코드에 담는 소프트웨어와, 실행 중에 모델이 다음 행동을 선택하는 에이전트를 대비합니다. AI가 코드를 더 빨리 써 주는 데서 멈추지 않고, 필요한 코드를 만들어 실행한 뒤 버리면서 목표를 달성하는 구조입니다. 저자는 이때 에이전트 자체가 소프트웨어가 된다고 봅니다.
이 구조를 이해하는 데에는 논문이 참고한 ReAct 연구가 도움이 됩니다. 모델은 계획을 세운 뒤 도구를 사용하고, 그 결과를 관찰해 다음 행동을 정합니다. 처음에 만든 계획을 끝까지 그대로 실행하는 대신 외부에서 얻은 정보를 바탕으로 계획을 수정할 수 있습니다.
가령 여러 파일에 흩어진 데이터를 모아 월별 보고서를 만드는 일을 생각해 볼 수 있습니다. AI에게 보고서 생성 프로그램을 만들어 달라고 요청하면, 만들어진 프로그램을 실행하고 관리하는 과정이 뒤에 남습니다. 반면 에이전트에게 보고서 자체를 맡기는 방식에서는 파일의 구조를 확인하고 데이터를 집계하는 작업까지 한 흐름 안에 들어갑니다. 집계에 필요한 짧은 코드는 그때 만들어 쓰면 됩니다. 이 예제에서 사용자가 필요로 하는 것은 계속 보관할 프로그램보다 정확한 보고서에 가깝습니다.
그 배경에는 복잡성에 대한 주장이 있습니다. 저자는 기능과 의존 관계가 늘어날수록 사람이 작성하고 이해해야 할 판단 규칙이 많아지지만, 사람의 인지 능력에는 한계가 있다고 봅니다. 반면 에이전트는 모델과 연산 자원의 발전을 활용해 필요한 실행 경로를 그때 구성하므로 다른 방식으로 확장할 수 있다는 논리입니다.
저자는 소프트웨어의 전달 방식도 이 관점에서 설명합니다. 설치형 소프트웨어에서 SaaS로 옮겨가며 공급자가 운영의 복잡성을 더 많이 맡았다면, 에이전트 서비스인 AaaS(Agent-as-a-Service)는 결과를 만드는 절차와 판단까지 맡는다는 것입니다.
이 흐름의 다음 단계로는 코딩 보조 도구, 단일 작업을 자율적으로 수행하는 에이전트, 여러 에이전트의 협업, 스스로 개선하는 생태계를 제시합니다. 이는 저자가 제안한 발전 경로이지, 실현 시점까지 검증된 일정표는 아닙니다.
그럼 엔지니어는 무엇을 만드나
논문에서 사람의 역할은 목표와 제약을 명확히 하고, 에이전트의 협업 구조를 설계하며, 결과의 품질과 허용 범위를 판단하는 쪽으로 이동합니다. 저자는 이 실천을 에이전틱 엔지니어링(Agentic Engineering)이라고 부릅니다.
앞의 보고서 예제로 돌아가 보면 이 일이 조금 더 구체적으로 보입니다. 어느 파일을 원본으로 삼을지, 누락된 데이터가 있으면 작업을 멈출지, 어디까지 외부로 전달해도 되는지를 정해야 합니다. 보고서가 보기 좋게 나왔더라도 집계 기준을 잘못 적용했다면 사용할 수 없습니다. 그럴듯한 설명과 실제 계산 결과를 어떻게 대조할지도 필요합니다.
이런 조건을 프롬프트에 적어 두는 것만으로 충분할까요? 원본을 바꾸면 안 되는 작업이라면 읽기 권한만 주는 편이 낫습니다. 외부 전달에 승인이 필요하다면 전송 직전에 승인 절차를 둘 수 있습니다. 실패 후 재시도할 때 같은 보고서가 여러 번 전송되지 않도록 처리하는 일도 생각해야 합니다. 에이전트의 능력과 별개로, 그 능력을 어떤 환경에서 사용하게 할지 설계하는 문제입니다.
Anthropic의 에이전트 구축 안내도 도구의 인터페이스와 실행 결과를 확인하는 과정을 다룹니다. 중간에 사람의 판단을 구할 지점, 반복 횟수 같은 중단 조건, 오류가 누적되지 않도록 시험할 환경이 필요하다고 설명합니다. 에이전트에게 실행을 맡긴다고 해서 시스템 설계가 없어지는 것은 아닙니다.
다만 이 논문은 직업의 소멸을 실험으로 확인한 연구로 읽기 어렵습니다. 기존 연구와 사례를 모아 변화의 방향을 주장하는 글에 가깝습니다. 복잡성이 커질수록 에이전트 방식이 필연적이라는 주장과, 유지보수의 한계가 해결될 것이라는 전망은 근거와 구분해서 읽어야 합니다.
논문이 참고한 SWE-Milestone 벤치마크도 그 간격을 보여줍니다. 이 연구는 하나의 문제만 해결하는 대신, 앞선 변경의 영향을 이어받으며 여러 개발 목표를 차례로 수행하게 합니다. 개별 문제에서 80%를 넘던 성능은 이렇게 이어지는 조건에서 38.03%로 떨어졌습니다. 연구진은 에이전트가 기존 동작을 유지하고 오류의 누적을 억제하는 데 어려움을 겪는다고 보고했습니다. 한 번 동작하는 결과물을 만드는 능력과 여러 차례 바뀌는 시스템을 계속 유지하는 능력은 구분해서 평가해야 합니다.
종말이 되지 않았던 자동화
사람이 직접 하던 구현 작업을 도구에 맡기는 변화는 처음이 아닙니다.
1957년 공개된 FORTRAN은 수식에 가까운 표현을 컴퓨터가 실행할 코드로 옮겨 주었습니다. IBM의 역사 자료에 따르면 과학자와 엔지니어는 자신의 문제를 기계어로 번역해 줄 전문 프로그래머에게 전적으로 의존하지 않고도 프로그램을 작성할 수 있게 됐습니다. 컴파일러가 사람이 손으로 작성한 코드만큼 효율적일 수 없다는 의심도 있었지만, 최적화 컴파일러는 그 격차를 크게 줄였습니다.
이 변화에서 제가 읽는 것은 프로그래밍의 소멸보다 작업의 분담이 달라졌다는 점입니다. 기계가 실행할 명령을 하나씩 다루는 수고를 덜고, 풀려는 문제를 더 높은 수준의 표현으로 기술하게 됐습니다. 어떤 일을 직접 하지 않게 되는 것과 그 일을 포함한 직업 전체가 사라지는 것은 다른 주장입니다.
1986년 프레드 브룩스가 쓴 「No Silver Bullet」도 함께 떠오릅니다. 브룩스는 소프트웨어를 언어나 기계에 맞춰 표현하면서 생기는 어려움과, 만들려는 시스템의 개념과 관계 자체가 복잡해서 생기는 어려움을 구분했습니다. 도구가 표현의 수고를 줄이더라도 설계 대상의 복잡성까지 같은 비율로 줄어드는 것은 아니라는 지적입니다.
예를 들어 두 부서가 같은 상태 값을 서로 다른 뜻으로 사용한다면, 코드를 빠르게 생성하는 것만으로 어느 뜻을 제품의 기준으로 삼을지 정해지지 않습니다. 먼저 차이를 발견하고 실제 업무에서 무엇을 가리키는지 확인해야 합니다. 그 차이를 없앨지, 별개의 개념으로 남길지도 선택해야 합니다.
그렇다고 브룩스의 글을 근거로 AI는 이런 문제에 손댈 수 없다고 말하고 싶지는 않습니다. AI가 모순을 찾아내거나 설계 대안을 비교하는 데 도움을 줄 가능성까지 닫을 이유는 없습니다. 제가 가져오고 싶은 것은 인간만 할 수 있는 일의 목록이 아니라, 어떤 어려움을 줄였고 어떤 어려움을 아직 다루지 못했는지 구분하는 시선입니다.
이번에도 같을 거라는 보장은 없지만
FORTRAN의 역사가 이번 변화의 결말까지 증명하지는 않습니다. 정해진 언어 규칙을 번역하는 컴파일러와, 자연어로 주어진 목표에서 작업 절차를 선택하는 에이전트는 위임받는 범위가 다릅니다. 과거의 자동화가 직업 전체를 없애지 않았다는 사실만으로 지금의 역할과 인원도 그대로 유지될 것이라고 결론 내릴 수는 없습니다.
반대로 AI가 코드를 생성할 수 있다는 사실을 곧바로 전체 개발 생산성의 향상으로 바꾸어 읽는 것도 조심스럽습니다. METR이 2025년에 발표한 무작위 대조 실험에서는 숙련된 오픈소스 개발자 16명이 익숙한 프로젝트에서 246개 작업을 수행했습니다. 당시 AI 도구를 사용할 수 있었던 조건에서는 작업 완료 시간이 오히려 19% 길어졌습니다.
이 숫자만 가져오면 이야기가 또 한쪽으로 기웁니다. METR은 2026년 2월 후속 보고에서 개발자들이 AI로 더 빨라졌을 가능성을 언급했습니다. 다만 AI 없이 일하고 싶지 않아 연구에 참여하지 않거나 특정 작업을 실험에 제출하지 않는 선택 편향 때문에, 효과의 크기를 신뢰성 있게 추정하기 어렵다고 밝혔습니다. 초기의 결과를 모든 도구와 시점에 적용할 수는 없습니다.
제가 이 연구들에서 가져오는 질문은 단순합니다. 코드를 쓰는 시간이 줄었다면 검토와 수정에 쓰는 시간은 어떻게 달라졌을까요. 더 많은 기능을 만들었다면 사용자가 겪던 문제도 그만큼 줄었을까요. 빨라진 구간이 있다는 사실과 일 전체가 나아졌다는 판단 사이에는 확인할 것이 남아 있습니다.
모든 기능을 에이전트로 바꾸는 것이 답이라고 생각하지도 않습니다. Anthropic도 작업이 명확할 때는 미리 정해진 워크플로가 예측 가능성과 일관성에 유리하며, 에이전트의 유연성에는 비용과 지연이 따를 수 있다고 설명합니다.
저라면 자료의 의미를 해석하고 예외를 찾아내는 일에는 에이전트의 도움을 받아 보겠습니다. 이미 합의된 계산 규칙을 적용하는 부분은 검증 가능한 코드로 유지할 수 있습니다. 두 방식을 어디에서 연결할지 고르는 것 역시 엔지니어링의 일부라고 생각합니다.
제가 계속 만들고 싶은 것
저는 산업디자인을 하다가 개발자가 됐습니다. 최근에는 AI를 활용해 오래된 디자인 작업들을 웹으로 옮겼습니다. 구현에 필요한 수고가 줄자 예전 같으면 시간 때문에 접었을 시도를 해볼 수 있었습니다. 동시에 무엇을 원본대로 유지할지, 어떤 조작이 제품을 이해하는 데 도움이 될지는 계속 판단해야 했습니다.
그 경험을 떠올리면 제가 좋아하는 일의 범위를 특정 도구로만 설명하기 어렵습니다. 디자인을 할 때는 형태와 사용 장면을 다뤘고, 지금은 화면과 동작을 만듭니다. 제가 표현하고 싶은 생각을 실제로 다룰 수 있는 것으로 옮기고, 그것이 누군가에게 쓸모가 있는지 살피는 과정에 더 오래 마음이 갑니다.
업무에서도 비슷한 생각을 해왔습니다. 화면에서 시작한 문제가 데이터 모델과 제품 정책으로 이어졌을 때, 전문 영역 밖이라는 이유만으로 놓고 싶지는 않았습니다. 그렇다고 혼자 모든 일을 하겠다는 뜻은 아니었습니다. 필요한 사람과 함께 문제를 끝까지 다루고, 제가 넘어간 영역의 기준으로 검증받는 일까지 포함했습니다.
제가 지키고 싶은 업의 가치는 그쪽에 가깝습니다. 누군가의 문제를 이해하고, 그 사람이 믿고 쓸 수 있는 해결책을 만드는 일입니다. 코드를 작성하는 능력은 그 일을 해내는 데 쌓아 온 전문성입니다. 앞으로도 직접 코드를 읽고 고쳐야 할 이유가 생기면 그렇게 할 것입니다. 더 나은 도구에 맡길 수 있다면 맡기는 법을 배우겠습니다.
다만 이 문장을 안심하기 위한 구호로 두고 싶지는 않습니다. 문제를 이해한다는 말도 실제 사용자와 이야기하지 않으면 빈말이 될 수 있습니다. 믿고 쓸 수 있다는 말에는 어떤 실패를 확인했고, 무엇은 아직 확인하지 못했는지 설명할 수 있어야 한다는 뜻이 들어 있습니다. 제가 만들었다는 이유만으로 그 결과를 신뢰해 달라고 할 수는 없습니다.
AI가 발전할수록 기획이나 판단은 영원히 인간의 몫이라고 선을 긋는 일도 조심하고 싶습니다. 그런 일을 돕는 도구까지 좋아진다면 제 역할은 다시 달라질 수 있습니다. 업의 본질을 찾는 일은 자동화되지 않을 안전한 자리를 골라 두는 일이 아닙니다. 도구와 역할이 바뀌었을 때도 무엇을 위해 배우고 판단할지 정하는 일에 가깝습니다.
그래서 다음 작업에서는 제가 얼마나 직접 구현했는지와 함께, 누구의 어떤 어려움을 줄였는지 적어 보려 합니다. AI에게 맡긴 부분을 제가 어떤 근거로 받아들였는지도 남기고 싶습니다. 익숙한 수고가 줄어든 자리에 제가 실제로 기여한 것이 무엇인지 확인하는 기록이 될 것입니다.
소프트웨어 엔지니어링의 종말이라는 제목에서 출발했지만, 제게 남은 것은 일을 다시 정의해야 한다는 생각입니다. 앞으로 어떤 도구를 쓰고 어떤 이름으로 불릴지는 달라질 수 있습니다. 그럴수록 제가 왜 이 일을 하고, 무엇을 더 낫게 만들고 싶은지는 지금보다 분명하게 알고 싶습니다.
