에이전트가 소프트웨어가 될 때 — Agentic Software

Zhenfeng Cao의 Agentic Software: How AI Agents Are Restructuring the Software Paradigm을 읽었습니다. 제목만 보면 흔한 낙관론 같은데 후반부가 오히려 냉정해서 기록해둡니다. 개인적으로 에이전트 시대 속에서 개발자들이 꼭 한번 읽어볼 만하다고 생각합니다.

AI 에이전트는 소프트웨어를 만드는 새 도구가 아니라, 소프트웨어의 정의를 바꾸는 개념이다.

정적인 D, 실행 시점의 D

논문은 전통적 소프트웨어를 S = (C, D, E)로 놓습니다. 계산 자원, 의사결정 규칙, 실행 환경. 핵심은 D가 실행 전에 이미 다 쓰여 있어야 한다는 점입니다. 기능 하나를 더할 때마다 사람이 D의 어느 지점을 고쳐야 하는지 찾고, 회귀 없이 고치고, 정합성을 확인해야 합니다. 변경 비용은 D의 크기와 내부 의존성 밀도를 따라 커집니다.

에이전트 시스템은 A = (M, 𝒯, ℳ, Π)로 놓습니다. 모델, 도구, 메모리, 계획. 달라지는 지점은 하나뿐입니다. D가 실행 시점에 생성됩니다. 코드는 시스템 그 자체가 아니라 추론 과정에서 만들어졌다 버려지는 일회용 산출물이 됩니다.

카파시의 Software 2.0에서 한 걸음 더 나간 셈입니다. 2017년에 나온 글인데, 사람이 규칙을 한 줄씩 짜던 자리를 학습된 신경망 가중치가 대신 차지한다는 이야기였습니다. 코드를 쓰는 대신 데이터를 모으고 목표를 정하면 최적화가 프로그램을 찾아냅니다.

차이는 이렇습니다. Software 2.0에서는 신경망이 프로그램을 대체하지만, 여기서는 신경망이 필요할 때마다 프로그램을 짜서 씁니다.

복잡도를 누가 떠안는가

전달 방식이 세 번 바뀌었다는 정리는 짚어둘 만합니다. 로컬 설치 시절엔 사용자가 설치와 유지보수를 떠안았고, SaaS로 넘어오면서 벤더가 인프라와 업데이트를 떠안았습니다. 논문이 AaaS라고 부르는 다음 단계에서는 에이전트가 “어떻게”를 떠안습니다. 주문하는 쪽은 무엇을 원하는지만 말합니다.

세 번 다 같은 패턴입니다. 복잡도는 가장 잘 감당할 수 있는 쪽으로 옮겨갑니다.

여기서 논문이 선을 하나 긋습니다. 지금 주류인 “AI 보조 개발”은 이 전환이 아니라는 것. LLM으로 코드 작성을 빠르게 해도 최종 산출물은 여전히 정적인 D이고, 고치려면 여전히 사람이 이해해야 하고, 요구사항에서 배포까지의 사슬도 그대로 남습니다. 빨라진 것은 D를 쓰는 속도뿐입니다.

82%에서 38%로

그래서 어디까지 왔나. 논문이 인용하는 가장 냉정한 숫자는 EvoClaw 벤치마크에서 나옵니다.

기존 벤치마크는 고립된 이슈 하나를 풀게 합니다. EvoClaw는 커밋 히스토리 전반에 걸쳐 시스템을 계속 진화시키라고 요구합니다. 오류가 누적되는 환경입니다. 12개 모델과 4개 에이전트 프레임워크를 붙인 결과, 고립 과제에서 82%였던 성공률이 연속 진화 과제에서는 38%로 떨어졌습니다.

원인으로 네 가지가 꼽힙니다.

• 코드베이스가 컨텍스트 윈도우를 넘어서면 시스템 전반의 불변식과 의존관계를 놓친다
• 초기 커밋의 작은 오류가 뒤에서 누적으로 터지는데, 그 연쇄를 감지하고 되돌리는 메커니즘이 아직 없다
• 설계 결정의 장기 비용을 모델링하지 못한다. 당장의 과제 완료만 최적화한다
• 테스트를 통과시키면서도 새 입력에서만 드러나는 의미적 오류를 만든다

읽으면서 최근 며칠이 떠올랐습니다. 시스템 OS 프로토콜 적용 작업 도중에 문제 증상 하나를 네 번 고쳤는데 네 번 다 다른 가설이었고 네 번 다 틀렸습니다. 세 번째 수정은 증상을 오히려 키웠습니다. 매번 그럴듯한 원인을 찾아냈고 매번 자신 있게 고쳤습니다. 위 목록의 첫 번째와 세 번째가 정확히 그 모습이었습니다.

논문은 이 격차를 근본적 한계가 아니라 컨텍스트 관리와 메모리 아키텍처, 검증 메커니즘의 현재 수준으로 봅니다. 보강 도구로서는 이미 현실적이지만 완전 자율은 아직 수년짜리 연구 과제라는 평가입니다.

그래서 사람은 무엇을 하는가

논문은 코드 생성 능력 자체가 상품화된다고 봅니다. 남는 차별화 요소로 네 가지를 듭니다. 에이전트가 오해하지 않을 만큼 의도를 명확하게 표현하는 능력, 여러 에이전트를 어떻게 조율하고 어디에 사람의 판단을 끼울지 시스템 수준에서 보는 능력, “좋다”의 정의를 세워 평가 체계로 만드는 능력, 그리고 거버넌스.

LangChain이 보고한 파일럿도 같은 방향을 가리킵니다. 20개 이상의 기업 디버깅 워크플로에 에이전트 무리를 투입해 근본 원인 규명 시간을 93% 줄였는데, 개선의 출처가 개별 에이전트의 성능이 아니라 컨텍스트 공유와 병렬 조사, 상호 검증이라는 조율 자체였습니다.

읽고 남은 생각

코딩이 일의 전부인 시기가 지나간다는 말 자체는 이제 새롭지 않습니다. 이 논문을 덮고 정리된 건 그 자리를 대체하는 것이 “코딩을 더 잘하기”도 “에이전트를 더 잘 쓰기”도 아니라는 점입니다.

에이전트에게 무엇을 맡길지 정하는 일, 나온 결과를 분석하는 일, 그 결과가 시스템 전체에 어떤 부채를 남겼는지 관리하는 일. 이 전부가 소프트웨어 개발입니다. 예전에 코드를 쓰는 일이 소프트웨어 개발이었던 것과 정확히 같은 의미로요.

시야를 그 크기로 넓혀두지 않으면 82%와 38% 사이의 격차는 계속 사람이 뒤늦게 메우는 몫으로 남습니다. 그 몫을 줄이는 게 앞으로 세워야 할 목표 중 하나이지 않을까 싶습니다.