[박준성의 SW] 에이전트 코딩, SW공학에 기반해야
클라우드-네이티브 개발 출현 2007년경부터 선진 기업들이 애플리케이션을 IaaS 기반 퍼블릭 클라우드로 이전하기 시작했다. 2010년경부터 넷플릭스, 아마존 등 선진 기업들이 마이크로서비스 아키텍처(MSA)를 개척하기 시작했다. 2013년 마이크로서비스를 담을 도커 컨테이너 출현과 2015년 구글의 쿠버네티스, 아마존의 ECS 등 컨테이너 오케스트레이션 플랫폼의 출현에 힘입어, 2015년부터 마이크로서비스가 서비스 지향 아키텍처(SOA)의 주요 구현 패턴으로 확산되기 시작했다. 같은 해 리눅스 재단은 클라우드 네이티브 컴퓨팅 재단(CNCF)을 설립해 클라우드-네이티브 생태계의 표준화와 오픈소스 프로젝트 육성을 본격화했다. 2015년에 아마존은 이미 수천 개의 데브옵스 팀들이 표준화된 사내 CI/CD(Continuous Integration/Continuous Deliver) 파이프라인을 이용해 마이크로서비스를 독립적으로 연간 약 5천만 회(평균 0.6초마다 한 번) 배포하고 있었다. (Chris Munns, I Love APIs 2015: Microservices at Amazon, 2015.) 이와 같이 클라우드-네이티브 앱 개발의 주축 요소는 MSA, CI/CD 파이프라인 자동화, 컨테이너 및 컨테이너 오케스트레이션, 그리고 IaC(Infrastructure as Code) 기반의 데브옵스다. 2022년 생성형 AI 등장 이후 AI 지원 코딩, 바이브 코딩, AI 에이전트 코딩이 빠르게 확산하면서 SW 개발 방식은 새로운 전환기를 맞았다. 그러나 이러한 변화 역시 클라우드-네이티브 개발 패러다임을 대체한 것이 아니라, 그 위에서 진화하고 있다. 클라우드-네이티브 개발의 허와 실 2020년 들어 MSA 한계가 알려지면서, 모듈리스(Modulith, Modular Monolith)와 서비스 기반 아키텍처(SBA, Service-Based Architecture: M. Richards and N. Ford, Fundamentals of Software Architecture, 2020)가 현실적인 대안으로 주목받기 시작했다. SBA는 가트너에서 제시한 미니서비스 아키텍처(A. Thomas and A. Gupta, Miniservices: A Pragmatic Alternative to Microservices, Gartner, 2017)와 유사한 SOA 구현 패턴으로, 서비스를 마이크로서비스보다 큰 규모로 패키징해 배포하고, DB per Service, Event Sourcing, 데브옵스 등 일반 기업에서 운영하기 어려운 와해적 기법은 배제한다. 모듈리스는 전체 앱을 하나로 배포하는 점이 SBA와 다르다. 가트너(Gartner)는 위에 인용한 보고서에서 2019년까지 MSA를 검토하는 기업의 90% 이상이 마이크로서비스 대신 미니서비스를 선택하게 될 것으로 전망했다. 아래 표 1의 DORA(DevOps Research and Assessment) 척도는 클라우드-네이티브 개발이 추구하는 SW 전달 성과를 측정하는 대표적인 지표다. (dora.dev/guides/dora-metrics/) 클라우드-네이티브 개발 목표의 가장 큰 특징은 매우 짧은 배포(운영 환경에 설치) 및 릴리스(사용자에게 출시) 사이클이다. 아마존처럼 0.6초는 아니더라도 하루에 한 번 이상 배포를 목표로 한다. 선도적인 SaaS 기업들은 하루에 수십 번 업그레이드를 배포·출시한다. 마이크로서비스 아키텍처의 핵심 기법인 서비스별 독립 배포, 서비스별 물리적 DB 소유, 이벤트 소싱 등은 높은 릴리스 민첩성을 가능하게 하지만, 그 대가로 일반 기업이 감당하기 어려울 정도의 분산 시스템 복잡성과 운영 난도를 수반한다. 국내에는 SW를 한 달 이내의 주기로 정기적으로 출시하는 기업이 매우 드물다. 따라서 가트너의 조사 결과와 같이, 국내에서도 대부분의 기업은 MSA보다는 모듈리스나 SBA가 적합하다. 이 경우 DORA 지표 중 배포 빈도, 변경 리드 타임, 실패 배포의 회복 시간은 비교적 중요도가 낮다. 그러나 변경 실패 비율과 배포 재작업 비율은 SW의 품질과 관련된 지표로서 매우 중요하다. MSA, 컨테이너, 쿠버네티스, CI/CD, IaC 자체는 SW 품질을 직접 보증하지 않는다. 이들은 빠른 배포를 가능하게 하는 기반 기술일 뿐이며, 품질은 그 위에서 실행되는 SW 공학적 검증 활동을 통해 확보된다. 클라우드 네이티브 개발에서 품질은 아래 그림 1의 검정색 박스로 표시된 SW 엔지니어링 활동을 통해 확보된다. 요구 분석에서의 프로세스 모델링, 시맨틱 모델링, 사용사례 분석과 테스트 케이스 도출, 객체 설계 기법 기반의 도메인 모델 설계, 서비스 식별과 SOA 아키텍처 설계, 그리고 프로덕션 시스템의 구현을 위한 TDD, 테스트 자동화 및 CI/CD 자동화 등이다. 그림 1에 빨간색 박스로 표시된 활동은 SOA 설계를 MSA로 구현할 때 실행하는 활동이다. 1950년대 초 SW 발명 이후, IT의 모든 발전은 기존에 확립된 기술과 새롭게 발전하는 기술의 융합이 반복하면서 점증적, 누적적으로 이뤄져 왔다. 그림 1에서 보듯이, 2010년대 초에 확산되기 시작한 MSA는 약 10년 전인 1990년대 초부터 확산되기 시작했던 SOA에 기반을 두고 있다. 따라서 SOA 기반의 분석·설계 역량을 갖춘 기업일수록 MSA를 성공적으로 도입할 가능성이 높았다. SOA의 설계는 1990년 중반에 확산되기 시작한 사용사례 위주의 요구 분석과 객체 설계에 기반하고 있다. 따라서 비즈니스 프로세스 모델, 시맨틱 모델 기반의 사용사례 분석과 객체 설계 원칙, 설계 패턴, 리팩토링 등의 역량이 축적되지 않은 기업은 SOA 도입에 많은 어려움을 겪었다. 더욱이 사용사례 분석과 객체 설계 관행도 정착되지 않은 기업이 SOA를 건너뛰고 MSA를 시도한 경우 대부분 실패했다. 2010년대 초에 확산되기 시작한 CI/CD의 자동화는 그로부터 약 10년 전에 확산되기 시작했던 테스트 주도 개발(Test-Driven Development, TDD)과 TDD 기반의 테스트 자동화에 기반하고 있다. TDD 및 테스트 자동화 역량을 갖추지 못한 기업은 자동화된 CI/CD 파이프라인에서 SW 품질을 유지할 수 없고, 따라서 변경 실패 비율과 배포 재작업 비율이 높게 나타난다. 한편 TDD가 효과적으로 작동하려면, 사용사례 중심의 요구 스펙의 상세도와 완성도가 높아, 사용사례별로 테스트 커버리지가 높은 테스트 케이스 세트를 도출할 수 있어야 한다. 결국 클라우드-네이티브 개발의 성패는 MSA나 쿠버네티스 자체가 아니라, 요구 분석, 객체 설계, SOA 아키텍처 설계, TDD, 테스트 자동화 등 기존 SW 엔지니어링 원칙을 얼마나 충실히 적용하느냐에 달려 있다. 이러한 SW 엔지니어링 역량 위에서 비로소 CI/CD는 높은 품질과 빠른 릴리스를 동시에 가능하게 한다. 결국 CI/CD는 스스로 품질을 보증하는 기술이 아니라, 요구 분석부터 테스트까지 SW 엔지니어링 원칙을 자동으로 검증하고 실행하는 플랫폼이다. AI 에이전트 코딩 시대에는 이러한 검증 규칙이 AI 에이전트를 통제하는 실행 가능한 거버넌스로 진화하게 된다. AI 에이전트 코딩 시대, 클라우드-네이티브 개발 공법의 진화 아래 표 2에서 보듯이, AI 에이전트 코딩에서는 표 1에서 보았던 5개 DORA 지표를 보완해야 한다. 표 2의 에이전트 코딩 성과 지표를 개선하려면, 에이전트가 생성하는 결과의 비결정성(Nondeterminism)과 그에 따른 환각(Hallucination) 및 오류를 최소화해야 한다. 이를 위해서는 명확하고 검증 가능한 스펙, 실행 가능한 제약조건, 그리고 결정적(deterministic) 검증 기반의 폐쇄 루프 피드백이 필요하다. 구체적으로는 사전 요구공학(Upfront Requirements Engineering, URE), 스펙 기반 개발(Spec-Driven Development, SDD), 제약조건 기반 개발(Constraint-Driven Development, CDD), 검증 기반 개발(evaluation-Driven Development, EDD)을 통해 에이전트 코딩에서도 신뢰성과 장기 유지보수성이 높은 프로덕션 시스템을 구축할 수 있다. URE는 무엇을 만들 것인지를 정의하고, SDD는 이를 명세하며, CDD는 구현 과정에서 지켜야 할 제약조건을 정의하고, EDD는 구현 결과를 결정적으로 검증한다. 그림 2와 같이 URE, SDD, CDD, EDD는 이미 확립된 SW 공학 기법을 통해 실현된다. 이러한 SW 공학 기법들은 AI 코딩 에이전트 환경에서는 컨텍스트 파일, 훅(Hook), 스킬(Skill), 툴(Tool), 서브에이전트(Subagent) 등의 형태로 구현돼 에이전트의 행동을 통제하는 실행 가능한 거버넌스로 작동한다. (박준성, AI 코딩 에이전트는 주니어 개발자...SW공학 필요, '박준성의 SW' 지디넷코리아, 2026.6.6) 에이전트 코딩을 시작하기 전에 애플리케이션이 지원하거나 혁신할 비즈니스 프로세스 모델의 설계, 비즈니스 데이터의 시맨틱 모델 설계와 이들 모델 기반의 사용사례 분석을 선행하는 것이 비즈니스 가치를 창출하기 위해 중요하다. (박준성, AI 에이전트 성공의 핵심 조건, [박준성의 SW] ZDNET Korea, 2026.5.1; McKinsey, One Year of Agentic AI: Six Lessons from the People Doing the Work, 2025) 에이전트 코딩은 개발할 앱의 스펙 정의에서 출발해야 한다. 스펙에는 행위 기반 개발(behavior-Driven Development: Dan North, Introducing BDD, dannorth.net/, 2006)을 위한 인수 테스트 기준과 앱 도메인의 온톨로지를 정의하는 것이 AI 에이전트 코딩에서 특히 효과적인 접근법이다. 에이전트 코딩의 핵심 원칙은 비결정적으로 생성된 코드를 결정적인 테스트로 검증하는 것이다. 이를 위해 BDD의 인수 테스트 기준을 기반으로 TDD를 적용해 테스트를 먼저 정의하고, 에이전트가 이를 만족하는 코드를 생성하도록 유도해야 한다. 온톨로지는 에이전트가 도메인 지식을 일관되게 이해하기 위한 컨텍스트 엔지니어링의 핵심 기반이 된다. 도메인 기반 설계(Domain-Driven Design, DDD: Eric Evans, Domain-Driven Design, 2003), SOA(박준성, The Complete Guide to SOA, MSA and Modulith, kosta-online.com/, 2005), 아키텍처 의사결정 기록(Architectural Decision Records, ADR) 등 아키텍처의 핵심 원칙은 아키텍처 적합성 검증 함수(Architectural Fitness Function, AFF: Neal Ford et al., Building Evolutionary Architectures, 2017)로 구현해 CI/CD 파이프라인에서 자동 검증하는 것이 바람직하다. 또한 보안, 규제 준수, 비용 통제, 관측 가능성(Observability)도 CI/CD 파이프라인에서 자동으로 검증되도록 할 수 있다. 결정적인 테스트 코드(TDD)는 기능 요구사항을 검증하고, AFF는 아키텍처 제약조건을 검증하며, 보안·컴플라이언스·관측가능성 규칙은 비기능 요구사항을 검증한다. 이처럼 SW 공학의 원칙과 제약조건은 AI 코딩 에이전트를 통제하는 실행 가능한 거버넌스로 구현되고, CI/CD 파이프라인은 이를 지속적으로 검증함으로써 에이전트가 생성하는 비결정적 결과물의 품질을 결정적으로 검증하고 보증하는 역할을 수행한다. 에이전트 코딩의 핵심 원칙은 비결정적으로 생성된 결과물을 결정적인 검증 규칙으로 평가하는 것이다. 클라우드-네이티브 에이전트 코딩 프로세스 아래 그림 3은 기존 애자일 개발 프로세스를 AI 에이전트 코딩에 맞게 재해석한 클라우드-네이티브 에이전트 코딩 프로세스를 보여준다. 디자인 씽킹, 린 스타트업, 스크럼, 극한 프로그래밍(Extreme Programming, XP )등 기존 방법론의 기본 구조는 유지하되, 개발자가 직접 구현하던 활동을 AI 에이전트가 수행하고 개발자는 이를 검증·조정하는 방식으로 역할이 전환된다. (Tim Brown, Change by Design, 2019; Eric Ries, The Lean Startup, 2011; Ken Schwaber, Agile Project Management with Scrum, 2004; Kent Beck, Extreme Programming Explained, 2004 참조) 먼저 디자인 씽킹 루프를 통해 사전 요구 분석을 수행해 사용자가 원하고(desirable), 기술적으로 구현 가능하며(feasible), 사업적으로 수익 동반 성장이 가능한(viable) 애플리케이션의 스펙을 도출한다. 다음으로, 스펙을 만족하는 최소 기능 제품(MVP)을 구축하고 Build-Measure-Learn 루프를 반복한다. Build에서는 스크럼, 칸반, DevOps 또는 SAFe 등의 애자일 개발 루프를 적용한다. 스펙을 구성하는 사용사례 리스트를 포함한 프로덕트 백로그에서 각 스프린트(즉, 한 달 이하의 릴리즈 사이클)에 구현할 사용사례를 선택해 (즉, 스프린트 플래닝을 통해) 스프린트 백로그를 구성한다. 개발자는 스프린트 백로그의 사용사례를 AI 에이전트에게 할당하고, 에이전트는 TDD와 실행 가능한 거버넌스를 준수하며 구현을 수행한다. 개발자는 AI 에이전트가 생성한 결과를 검토·승인하며, 실행 가능한 거버넌스와 EDD 검증을 통과한 변경만 CI/CD 파이프라인을 통해 지속적으로 통합·배포한다. Build에서 가장 내부의 사이클(innermost cycle)은 에이전트가 소스 코딩을 위해 자율적으로 수행하는 Red-Green-Refactor TDD 사이클이다. 에이전트가 생성한 PR마다 개발자의 코드 리뷰를 수행하는 것이 바람직하다. 다음의 외부 사이클(outer cycle)은 에이전트가 빈번하게 빌드하는 CI 사이클이다. 그 바깥의 외부 사이클은 에이전트가 하루에 여러 차례 배포하는 CD 사이클이다. CI와 CD 실행 시 EDD를 통한 검증을 반드시 수행해야 한다. AI 에이전트 코딩에서는 XP의 핵심 실천인 TDD, 리팩토링, 지속적 통합(CI)이 에이전트에 의해 자동화되며, 여기에 현대적인 CD와 실행 가능한 거버넌스가 결합된다. XP를 포함하는 가장 외부의 사이클(outermost cycle)은 스크럼 사이클(즉, 릴리스 사이클)이다. 매 스프린트 종료 시 Product Owner(PO), 이해관계자, 개발팀이 참여하는 스프린트 리뷰에서 제품 증분을 검토하고, PO가 릴리스 여부를 결정한다. 승인되면 출시한 제품 증분에 대한 사용자의 반응을 린 스타트업의 혁신회계(Innovation Accounting) 방식으로 데이터 기반으로 측정한다. 측정 결과가 목표 KPI를 충족하면 현재 전략을 유지(persevere)하고 다음 스프린트로 진행한다. 반대로 KPI를 충족하지 못하면 디자인 씽킹 단계로 돌아가서 문제 정의와 해결 방안을 다시 탐색(pivot)한다. 스프린트 리뷰에서 릴리스가 기각된 경우에는 프로젝트 계획·조직을 수정하거나 디자인 씽킹으로 회귀한다. 클라우드 네이티브 개발에서는 SW 공학이 CI/CD를 통해 SW를 검증했다. AI 에이전트 코딩에서는 동일한 SW 공학이 실행 가능한 거버넌스로 구현되어 AI 에이전트를 통제하고, CI/CD는 이를 지속적으로 검증한다. 결국 AI 에이전트 코딩은 새로운 SW 공학이 아니라, 기존 SW 공학을 실행 가능한 거버넌스로 구현해 AI 에이전트에 적용하는 새로운 개발 방식이다. 따라서 AI 에이전트 시대에는 SW 공학의 중요성이 줄어드는 것이 아니라, 오히려 SW 공학이 AI 에이전트를 통제하는 실행 가능한 거버넌스로 구현되면서 그 중요성이 더욱 커진다. 결론 클라우드 네이티브의 성공은 MSA보다 SW 공학에 기반했다. 에이전트 코딩도 동일하게 SW 공학에 기반해야 한다. 차이점은 SW 공학이 사람을 위한 가이드라인에서 AI 에이전트를 통제하는 실행 가능한 거버넌스로 진화했다는 것이다. CI/CD는 그 거버넌스를 지속적으로 검증하는 실행 플랫폼이다.
