저는 최근 AI의 발전들이 소프트웨어 산업을 어디로 이끌지 깊이 생각하며 많은 시간을 보냈습니다.

단순히 오늘날 AI 코딩 에이전트가 개발자에게 어떤 의미인지, 혹은 우리가 얼마나 더 빠르게 코드를 작성할 수 있는지에 대한 문제가 아닙니다. 이러한 역량들이 소프트웨어를 구축하는 경제 자체를 근본적으로 변화시킬 때 무슨 일이 벌어질지에 관한 문제입니다.

지난 몇 달 동안 저는 이 변혁의 여러 측면에 대해 글을 써왔습니다:

각 글은 동일한 변혁의 다른 부분을 탐구합니다. 이 모든 것을 종합해 보니 저에게는 더 큰 질문이 생겼습니다.

만약 AI 에이전트가 우리가 소프트웨어를 구축하는 방식을 근본적으로 변화시킨다면, 우리는 그것을 개발하는 방식을 안내하는 원칙들을 재고해야 할까요?

저는 그 답은 '그렇다'라고 생각합니다.

그리고 저는 AI 에이전트가 소프트웨어를 자율적으로 구축하는 능력이 점점 커지는 세상에서, 애자일 매니페스토가 오늘날 어떤 모습일지 대화를 시작해보는 것이 흥미로울 것 같다고 생각했습니다.

이는 그러한 대화를 시작하려는 시도입니다. 제가 모든 것을 알아냈다는 선언은 아니며, 우리가 배운 애자일의 모든 것이 갑자기 틀렸다는 주장도 결코 아닙니다.

오히려 그 반대입니다. 저는 원래의 애자일 가치들 중 많은 부분이 여전히 매우 관련성이 높다고 생각합니다. 하지만 우리가 그것들을 적용하는 맥락이 변화하고 있습니다.

왜 애자일 매니페스토를 재검토해야 하는가?

애자일 매니페스토는 2001년에 작성되었는데, 당시 소프트웨어 개발은 매우 다른 활동이었습니다.

그 저자들은 작동하는 소프트웨어를 제공하는 데 종종 방해가 되었던 무거운 프로세스, 과도한 문서화, 경직된 계획, 그리고 조직 구조에 도전했습니다.

그들은 네 가지 가치를 확립했습니다:

프로세스와 도구보다 개인과 상호작용(Individuals and interactions over processes and tools).
포괄적인 문서화보다 작동하는 소프트웨어(Working software over comprehensive documentation).
계약 협상보다 고객과의 협업(Customer collaboration over contract negotiation).
계획을 따르기보다 변화에 대응하기(Responding to change over following a plan).

이러한 가치들은 한 세대의 엔지니어와 조직들이 소프트웨어 개발에 접근하는 방식을 형성하는 데 도움을 주었습니다.

하지만 AI 에이전트가 인간의 개입이 점점 줄어들면서 기능을 구현하고, 기존 시스템을 수정하며, 테스트를 생성하고, 코드를 리팩토링하며, 전체 코드베이스에 걸쳐 작업할 수 있게 될 때 무슨 일이 일어나는지 생각해 보십시오.

병목 지점이 이동하기 시작합니다.

코드를 작성하는 것이 더 저렴해집니다. 여러 구현체를 생산하는 것이 더 쉬워집니다. 다양한 접근 방식을 실험하는 것이 더 경제적이 됩니다.

하지만 우리는 여전히 소프트웨어가 우리가 의도한 대로 작동하는지, 취약점을 도입하는지, 프로덕션 환경에서 올바르게 동작하는지, 그리고 실제로 고객의 문제를 해결하는지를 알아야 합니다.

많은 경우, 더 어려운 문제는 더 이상 솔루션을 생산하는 것이 아닙니다. 그 솔루션이 신뢰할 만한 가치가 있다는 것을 확립하는 것입니다.

코드가 저렴해질 때, 검증(verification)은 비싸집니다.

이는 단순히 도구의 변화가 아닙니다. 이는 팀 구조, 소프트웨어 아키텍처, 엔지니어링 관행, 제품 발견(product discovery), 그리고 맞춤형 소프트웨어의 경제학에 영향을 미칩니다.

만약 우리가 검증하고 유지할 수 있는 능력을 초과하는 속도로 소프트웨어를 생산할 수 있게 된다면, 개발 역량 자체를 늘리는 것만으로는 우리의 문제를 해결할 수 없습니다.

우리는 소프트웨어가 생산되는 시스템 자체에 대해 다시 생각해야 합니다.

애자일(Agile)에서 에이전틱(Agentic)으로

저는 답이 애자일을 폐기하고 AI 코딩 에이전트를 사용하는 방법을 규정하는 방법론으로 대체하는 것이라고 생각하지 않습니다.

그것은 핵심을 놓치는 것입니다.

더 흥미로운 질문은 소프트웨어 개발의 근본적인 가치와 원칙들이 이 새로운 현실을 반영하여 진화해야 하는가입니다.

제가 주목할 만하다고 생각하는 변화들은 다음과 같습니다.

1. 소프트웨어를 생산하는 것에서 결과를 검증하는 것으로

작동하는 소프트웨어는 계획과 문서를 진행 측정 지표로 삼았던 것보다 큰 개선이었습니다.

하지만 에이전틱한 세상에서는 작동하는 코드를 생성하는 것이 점점 쉬워지고 있습니다. 심지어 테스트를 통과한다고 해서 반드시 우리가 올바른 것을 만들었다는 의미는 아닙니다.

우리는 검증된 결과(verified outcomes)에 초점을 맞춰야 합니다. 즉, 요구사항을 명확하게 만족시키고, 의도된 제약 조건 내에서 작동하며, 고객에게 가치를 제공하는 소프트웨어입니다.

2. 암묵적 가정에서 명시적 의도로

AI 에이전트는 상당한 자율성으로 작동할 수 있지만, 무엇을 달성하려고 하는지, 그리고 무엇을 해서는 안 되는지를 이해해야 합니다.

제약 조건(Constraints), 사양(specifications), 아키텍처 경계(architectural boundaries), 승인 기준(acceptance criteria), 실행 가능한 정책(executable policies)은 의도를 해석하고 검증하기 쉽게 만들기 때문에 점점 더 가치가 높아집니다.

명시성 자체가 궁극적인 목표는 아닙니다. 그것은 더 큰 자율성을 가능하게 하면서도 더 신뢰할 수 있는 결과를 달성하기 위한 수단입니다.

3. 구현을 감독하는 것에서 자율 시스템을 설계하는 것으로

인간이 대부분의 구현 작업을 수행할 때, 우리는 코드를 작성하고, 검토하고, 통합하는 사람들을 중심으로 팀을 조직합니다.

에이전트가 그 많은 작업을 수행할 수 있게 되면서, 우리는 개발 시스템 자체에 대해 다르게 생각해야 합니다.

우리가 안전하게 지원할 수 있는 자율성은 어느 정도일까요? 어떤 결정은 인간의 판단을 필요로 할까요? 검증은 어디에서 이루어져야 할까요? 실패가 전파되는 것을 어떻게 막을 수 있을까요?

목표는 소프트웨어 개발에서 인간을 제거하는 것이 아닙니다. 가장 중요할 때 인간의 판단, 창의성, 소유권을 활용하는 것입니다.

결과적으로 훨씬 더 많은 것을 성취할 수 있지만, 자신이 만든 시스템과 운영하는 시스템에 대해 더 큰 책임을 지는 엔지니어가 적어질 수도 있습니다.

4. 구현 최적화에서 전체 시스템 최적화로

도요타 생산 시스템(Toyota Production System)은 여기서 유용한 관점을 제공합니다.

개별 단계의 생산성을 향상시키는 것이 반드시 전체 시스템의 성능을 향상시키는 것은 아닙니다.

만약 에이전트가 코드를 10배 더 빠르게 생성하지만, 검증, 통합 및 유지보수는 변하지 않는다면, 우리는 단지 해당 활동들을 기다리는 더 큰 작업 대기열을 만들 수 있습니다.

우리는 생성된 코드의 양(volume)이 아니라, 검증된 가치(verified value)의 흐름을 최적화해야 합니다.

이러한 아이디어들을 염두에 두고, 저는 어떤 새로운 매니페스토가 생겨날지 궁금해지기 시작했습니다.

에이전트 매니페스토 (The Agentic Manifesto)

우리는 지능형 에이전트를 사용하여 구축하고 그들이 작동하는 시스템으로부터 학습함으로써 소프트웨어를 개발하는 더 나은 방법을 발견하고 있습니다.

이 작업을 통해 우리는 다음 가치들을 중요하게 여기게 되었습니다:

생성된 출력(generated output)보다 검증된 결과(verified outcomes)

암묵적 가정(implicit assumptions)보다 명시적 의도(explicit intent)

인간의 감독(human supervision)보다 인간의 판단과 소유권(human judgment and ownership)

통제되고 순차적인 인계(controlled, sequential handoffs)보다 안전하고 지속적인 흐름(safe, continuous flow)

즉, 오른쪽 항목들에도 가치가 있지만, 우리는 왼쪽 항목들을 더 중요하게 여깁니다.

에이전트 매니페스토의 원칙 (Principles behind the Agentic Manifesto)

우리는 다음 원칙들을 따릅니다:

1. 우리의 최우선 순위는 조기에 지속적으로 가치 있는 검증된 결과물을 고객에게 전달하는 것입니다.

목표는 더 많은 코드를 생산하거나, 더 많은 작업을 완료하거나, 더 많은 에이전트를 배포하는 것이 아닙니다. 의미 있는 문제를 해결하고, 우리가 그 문제들을 해결했음을 입증하는 것입니다.

2. 변화하는 요구사항과 새로운 정보를 환영하라. 변경을 저렴하고, 검증 가능하며, 되돌릴 수 있게 만드는 시스템을 설계하라.

AI는 실험과 구현 비용을 낮춥니다. 우리는 이러한 유연성을 활용해야 하지만, 불필요한 위험을 초래하지 않으면서도 변화가 평가되고 수정될 수 있도록 보장해야 합니다.

3. 개발 전반에 자동화된 검증을 통합하여 작동하는 소프트웨어를 자주 제공하라.

짧은 피드백 루프는 여전히 필수적입니다. 에이전트는 나중에 검토되어야 하는 대량의 코드를 생성하기보다는, 변경 사항을 지속적으로 구현하고, 테스트하고, 평가하고, 개선할 수 있어야 합니다.

4. 의도를 인간과 에이전트 모두가 무엇을 달성해야 하고 무엇을 절대 위반해서는 안 되는지 이해할 만큼 명시적으로 하라.

요구사항(Requirements), 제약조건(Constraints), 불변 조건(Invariants), 수용 기준(Acceptance Criteria), 아키텍처 경계(Architectural Boundaries) 등은 명확하게 표현되어야 하며, 가능한 모든 곳에서 실행 가능하도록 만들어져야 합니다. 명시성은 자율성(Autonomy)을 가능하게 하지만, 판단의 필요성을 없애지는 않습니다.

5. 개발 프로세스에 검증을 내장하고, 실패의 결과에 비례하는 증거를 요구하라.

품질은 생성된 코드가 정확할 것이라고 기대하거나 인간의 검토에만 의존해서는 안 됩니다. 적절한 경우 자동화된 테스트(Automated tests), 정적 분석(Static analysis), 보안 점검(Security checks), 형식적 방법(Formal methods), 런타임 모니터링(Runtime monitoring), 독립적인 평가를 사용해야 합니다. 위험도가 높은 변경 사항일수록 더 강력한 증거가 필요합니다.

6. 검사(Inspection)에 의존하기보다 프로덕션 시스템 자체에 품질을 내장하라.

이상 징후를 가능한 한 빨리 감지하고, 결함이 전파되는 것을 방지하며, 중요한 검증에 실패하면 작업을 중단해야 합니다. 코드를 더 빠르게 생산하지만 결함이 축적되도록 허용하는 시스템은 더 나은 시스템이 아닙니다.

7. 에이전트에게 명시적 경계(explicit boundaries), 신뢰할 수 있는 피드백, 그리고 효과적인 제어 장치로 안전하게 지원될 수 있는 최대의 자율성(autonomy)을 부여하라.

자율성은 증거를 통해 얻어져야 하며 위험에 의해 제한되어야 한다. 에이전트는 권한(permissions), 아키텍처 규칙(architectural rules), 운영 한계(operational limits), 그리고 에스컬레이션 요건(escalation requirements)을 존중하면서도 일상적인 결정을 독립적으로 내릴 수 있어야 한다.

8. 자율 시스템의 역량이 증가함에 따라 인간의 판단력, 창의성, 소유권을 보존하라.

구현(implementation)을 위임하고 책임(responsibility)은 위임하지 마라. 인간은 문제를 정의하고, 모호성을 해결하며, 중대한 결정을 내리고, 결과에 대한 책임을 지는 데 집중해야 한다. 더 큰 레버리지(leverage)는 더 큰 책임을 요구한다.

9. 고객과 실제 운영 환경에서의 소프트웨어 행동으로부터 지속적으로 학습하라.

명세서와 테스트만으로는 모든 것을 예측할 수 없다. 실제 사용, 운영 신호(operational signals), 사고(incidents), 그리고 고객 피드백이 소프트웨어 자체와 그것을 생성하는 시스템 모두에 정보를 제공해야 한다.

10. 구현 비용이 저렴하더라도 불필요한 복잡성보다 단순성과 유지보수성을 선호하라.

에이전트가 기능을 빠르게 생성할 수 있다는 사실이 우리가 그것을 구축해야 한다는 의미는 아니다. 추가적인 기능, 추상화(abstraction), 의존성(dependency), 그리고 아키텍처 결정은 구현 비용을 넘어 확장되는 잠재적 비용을 초래한다.

11. 사람의 활용률, 생성된 코드의 양, 또는 배포된 에이전트의 수를 최적화하는 것이 아니라 검증된 가치(verified value)의 흐름을 최적화하라.

생산적인 시스템은 아이디어와 검증된 결과 사이에서 불필요한 대기열, 인계(handoffs), 재작업(rework), 지연을 최소화한다. 전체 시스템 개선 없이 출력을 늘리는 것은 단지 병목 현상(bottleneck)을 이동시킬 뿐이다.

12. 소프트웨어를 생성하는 시스템 자체를 지속적으로 개선하라.

모든 결함(defect), 실패한 검증(verification) 사례, 프로덕션 인시던트(production incident), 그리고 예상치 못한 에이전트 행동은 우리의 사양(specifications), 제약 조건(constraints), 테스트, 아키텍처, 그리고 피드백 루프를 개선할 기회입니다. 프로덕션 시스템 자체도 우리의 역량이 변화함에 따라 진화해야 합니다.

이것은 소프트웨어 개발의 미래에 어떤 의미가 있는가?

저는 AI가 개별 개발자의 생산성 이상을 변화시키고 있다고 믿습니다.

그것은 소프트웨어 자체의 경제학을 변화시키고 있습니다.

코드가 공공재(common good)가 된다면, 구현 능력이 약한 경쟁 우위가 됩니다. 가치는 문제 이해, 차별화된 결과 제공, 가치 있는 데이터와 배포를 소유하는 것, 신뢰할 수 있는 서비스 운영, 그리고 신뢰 구축 쪽으로 이동합니다.

이는 엔터프라이즈 소프트웨어를 근본적으로 바꿀 수 있습니다.

조직들은 일반적인 제품의 한계, 복잡성, 비용을 받아들이기보다는 자신들의 필요에 맞춰 소프트웨어를 점점 더 구축하고 적응시킬 것입니다. 이전에 너무 비싸서 정당화하기 어려웠던 맞춤형 소프트웨어(custom software)가 경제적으로 실현 가능해질 수 있습니다.

하지만 이러한 미래는 단순히 모두에게 코딩 에이전트 접근 권한을 부여한다고 해서 실현되는 것은 아닙니다.

에이전트 매니페스토: AI 시대의 애자일 매니페스토는 어떠해야 하는가?

요약

핵심 포인트