[박준성의 SW] 한국 SW개발, 미국 1990년대...AI강국 걸림돌
AI 경쟁력은 단순히 우수한 AI 모델이나 반도체, 데이터와 같은 개별 자산만으로 결정되지 않는다. 인재와 교육, R&D, 컴퓨팅과 반도체, 에너지와 디지털 인프라, 데이터 생태계, 민간의 기술과 투자, 정책과 거버넌스가 함께 작동해야 한다. 제조·의료·금융 등 산업 현장에서 AI를 실제 경쟁력으로 전환하는 것도 이러한 기반 위에서 가능하다. 그러나 이 모든 자산을 실제 서비스와 산업 시스템으로 연결하는 마지막 연결고리가 있다. 바로 소프트웨어 공학(SW Engineering)이다. 아무리 뛰어난 AI 모델과 풍부한 데이터, 막대한 컴퓨팅 자원을 확보하더라도 요구사항을 정의하고, 아키텍처를 설계하고, 고품질 소프트웨어를 개발·테스트·배포·운영하는 역량이 부족하면 이를 지속 가능한 산업 경쟁력으로 전환하기 어렵다. 여기서 말하는 SW공학 역량은 단순히 숙련된 개발자의 수를 의미하지 않는다. 대규모 소프트웨어 시스템을 예측 가능하고 반복 가능하게 개발·운영할 수 있는 기술과 조직, 프로세스, 그리고 이를 뒷받침하는 제도적 역량을 모두 포함한다. 문제는 한국이 AI 기술을 충분히 확보했느냐가 아니다. 그 기술을 빠르게, 안정적으로, 지속적으로 소프트웨어와 산업 경쟁력으로 전환할 수 있는 SW 공학 체계를 갖추고 있느냐다. 미국 SW공학 변화: 1990년대 이후 아래 그림 1은 소프트웨어가 본격적으로 산업화되기 시작한 1950년대부터 최근의 AI 도구 기반 에이전트 개발 시대에 이르기까지 미국 SW 공학의 주요 변화를 보여준다. 특히 1990년대 이후 미국의 SW 개발은 사전 계획과 단계별 개발을 중시하는 프로젝트 중심 방식에서 반복적인 개발과 자동화, 서비스 중심 아키텍처를 거쳐 클라우드 네이티브와 AI 에이전트 중심의 개발 방식으로 진화해 왔다. 아래 표 1은 이 가운데 1990년대의 주류적인 SW 개발 관행과 2000년대에 확산된 주요 관행을 비교한 것이다. 한국의 SW 산업, 특히 공공 SW와 전통적인 SI 프로젝트에서는 이러한 변화가 충분히 정착되지 않아 1990년대의 개발·관리 관행이 여전히 상당 부분 남아 있다. 그렇다면 왜 한국은 아직도 이러한 1990년대의 SW 개발 관행에서 벗어나지 못하고 있는가? 그리고 AI 시대에는 왜 이 관행의 현대화가 더욱 시급한가? 그 이유와 전환 방향을 살펴봤다. ISP에서 EA로... 정보전략계획(Information Strategy Planning, ISP)은 제임스 마틴(James Martin)이 제창한 정보공학(Information Engineering, IE) 방법론이 1980년대 중반 IEW, IEF 등의 CASE 도구에 반영되면서 미국 대기업으로 확산되기 시작했다. ISP는 정보시스템 구축 프로젝트를 시작하기 전에 기업의 정보화 전략과 시스템 구축 방향을 수립하는 일회성 활동이었다. 문제는 ISP의 완성도를 높이려면 상당한 시간과 비용이 필요하고, 반대로 짧은 기간에 수행하면 이후 시스템 개발에 실질적인 도움이 되지 않는다는 점이었다. 1990년대 중반 이후 이러한 ISP의 한계를 보완하면서 기업 아키텍처(Enterprise Architecture, EA)가 확산되기 시작했다. ISP가 특정 시점의 정보화 전략을 수립하는 일회성 활동이었다면, EA는 기업의 변화에 따라 비즈니스, 데이터, 애플리케이션, 기술 아키텍처를 지속적으로 관리하고 정렬하는 상시적인 경영·IT 활동이다. 특히 1990년대 비즈니스 프로세스 리엔지니어링(BPR)이 미국 산업 전반으로 확산되면서 EA의 비즈니스 아키텍처에서도 업무 프로세스의 모델링과 혁신이 중요한 요소로 자리 잡았다. 애플리케이션 측면에서는 서비스 지향 아키텍처(SOA)를 통해 변경 용이성, 상호운용성 및 재사용성을 높이고, 데이터 측면에서는 전사적으로 활용할 정보와 메타데이터를 표준화하며, 기술 측면에서는 빠르게 진화하는 IT 인프라 기술을 기업 차원에서 표준화하는 것이 EA의 주요 과제가 되었다. 미국 연방정부에서는 1996년 Clinger-Cohen Act를 계기로 연방 차원의 EA가 제도화되었으며, 이후 FEAF(Federal Enterprise Architecture FRAMEwork) 등이 발전했다. 민간 부문에서도 TOGAF(The Open Group Architecture FRAMEwork) 등의 확산과 함께 EA가 기업의 경영전략과 IT 전략을 연계하는 주요 방법론으로 자리 잡았다. 2006년 하버드 대학에서 출간한 J. Ross 등의 'Enterprise Architecture as Strategy'는 이러한 EA의 발전과 기업 전략과의 관계를 잘 보여준다. 한국에서도 2000년대 중반 정부와 일부 대기업을 중심으로 EA 도입이 추진됐다. 2005년 ITA법 제정, 관련 정부 부처의 추진체계 마련, 한국지능정보사회진흥원(NIA)의 EA 지원 및 확산 활동 등이 이어졌다. 그러나 EA를 도입했다는 것과 EA가 실제로 기업과 정부의 의사결정에 활용된다는 것은 별개의 문제였다. 2005년 ITA법 제정 당시에는 한번 구축한 EA를 기반으로 개별 정보화 사업을 신속하게 추진한다는 목표가 제시됐지만, 실제 현장에서는 여전히 수억 원 규모의 일회성 ISP 보고서를 작성하는 방식이 반복됐다. EA 역시 실제 의사결정에 활용하는 살아 있는 아키텍처라기보다 사업 완료 후 산출물로 관리되는 문서가 되기 쉬웠다. 일부 공공기관에서는 신규 시스템을 먼저 기획·개발한 뒤, 연말의 공공부문 EA 실태조사에 대응하기 위해 완성된 시스템의 구조를 역으로 추적해 EA 관리시스템에 입력하는 관행까지 나타났다. 왜 한국에서는 EA가 실질적인 경영·IT 혁신 수단으로 정착하지 못했을까? 필자는 2000년대 중반 한국지능정보사회진흥원(NIA)에서 운영한 EA 포럼 의장을 맡으면서 이 문제를 가까이서 지켜볼 기회가 있었다. 당시를 돌이켜보면 가장 근본적인 문제는 정부 각 부처가 자체적으로 아키텍처를 설계하고 검토할 EA 전문가를 충분히 양성하지 않았다는 점이었다. 그 결과 EA 데이터 입력과 관리, 아키텍처 산출물 작성과 유지가 해당 기관의 공무원이나 내부 전문가가 아니라 정보시스템 유지보수를 담당하는 SI 업체 개발자 또는 외부 컨설턴트에게 의존하는 경우가 많았다. EA가 조직 내부의 의사결정 역량으로 자리 잡지 못하고 외부 사업자가 만들어 주는 산출물이 된 것이다. 미국에서는 연방정부의 EA 제도화를 뒷받침하기 위해 EA 전문인력을 육성하고, 아키텍처 역량과 성숙도를 체계적으로 관리하기 위한 교육·평가 체계를 발전시켜 왔다. 즉, EA를 단순한 문서 작성이나 시스템 등록 업무가 아니라 정부의 IT 의사결정을 수행하기 위한 전문 역량으로 접근한 것이다. 이러한 EA 중요성은 AI 기반 경영혁신(AX) 시대에 오히려 더욱 커지고 있다. 비즈니스 프로세스 재설계, 전사적인 메타데이터와 온톨로지 구축, SOA 기반의 애플리케이션 구조 설계 등은 AI 에이전트를 기업 업무에 도입하기 위한 핵심 기반이기 때문이다. (박준성, AI Agent의 실패 원인과 성공 방안, kosta-online.com/post/ai-agent-success-factors, 2026.3; 박준성, AI 에이전트 성공의 핵심 조건, 지디넷 코리아, 2026.4 참조) EA에 기반한 전사적 비즈니스·데이터·애플리케이션·기술 아키텍처 분석과 설계 없이 개별적으로 추진하는 AX 프로젝트는 국지적인 파일럿과 중복 개발 반복에 그칠 가능성이 높다. AI 에이전트가 전사 업무를 넘나들며 데이터를 활용하고 여러 시스템의 서비스를 호출해야 하는 시대에는 더욱 그렇다. 이제라도 기업과 정부는 EA 전문가를 체계적으로 양성하고, 이를 전담하는 조직과 책임체계를 마련해야 한다. EA를 사업 종료 후 작성하는 문서가 아니라 지속적으로 변화하는 기업의 비즈니스와 IT를 설계하고 관리하는 공학적 활동으로 정착시켜야 한다. 그것이 끊임없이 진화하는 IT 기술을 경영혁신과 국제경쟁력으로 전환하기 위한 중요한 기반이다. Waterfall에서 Iterative 프로세스로 SW 개발의 폭포수(Waterfall) 프로세스는 사업기획 → 요구사항 정의 → 분석 → 설계 → 개발 → 테스트 → 인수/검수 → 운영의 단계를 순차적으로 진행한다. 사용자 요구사항과 경영혁신에 필요한 SW 기능을 개발 초기에 비교적 명확하게 정의할 수 있는 경우에는 효과적인 프로세스다. 그러나 요구사항이나 필요한 기능이 불확실한 경우, 특히 새롭고 혁신적인 애플리케이션을 개발하는 경우에는 개발 후반에 요구사항이 변경되면서 과도한 재작업(Rework)이 발생하거나, 최종 시스템의 품질과 경제성이 떨어질 수 있다. 불확실성이 큰 경우에는 전체 범위 중 비즈니스 중요도가 높은 부분부터 점증적으로 반복적으로 개발, 배포하면서 사용자의 반응이나 경영 성과를 모니터링하여 그 피드백을 다음 차 개발에 반영하는 반복·점증적 개발 프로세스를 적용하는 것이 프로젝트의 성공 가능성을 높이는 방안이다. 미국에서는 폭포수 프로세스가 1970년대에 널리 활용되었지만, 1980~90년대에는 그 한계를 극복하기 위한 Barry Boehm의 Spiral Model, Tom Gilb의 Evolutionary Delivery 등 반복·점증적 개발 방법이 등장해 확산됐다. 2000년대에는 이러한 접근법이 애자일(Agile)과 Unified Process 등의 형태로 빠르게 확산하면서 주요 SW 개발 방식으로 자리 잡았다. 대규모 조직에서는 Unified Process와 이후의 SAFe와 같은 확장형 프레임워크가 활용됐고, SW 제품 개발에서는 XP와 Scrum을 중심으로 한 Agile 방법론이 확산됐다. 대표적인 저서로 I. Jacobson 등의 The Unified Software Development Process(1998), K. Beck의 Extreme Programming Explained(1999), K. Schwaber와 M. Beedle의 Agile Software Development with Scrum(2001), D. Leffingwell의 SAFe 2.0 Reference Guide(2013) 등을 들 수 있다. 2010년대 이후에는 애자일 개발이 데브옵스(DevOps) 및 클라우드 네이티브(Cloud-Native) 개발과 결합하면서 CI/CD, 테스트 자동화, Infrastructure as Code, 컨테이너 및 쿠버네틱스(Kubernetes) 등을 활용하는 지속적 소프트웨어 전달 방식으로 발전했다. 최근에는 여기에 AI 코딩 도구와 AI 에이전트가 결합하면서 개발 프로세스 자체가 다시 변화하고 있다. 한국의 공공 SW 부문에서는 아직도 폭포수에 가까운 프로젝트 및 계약 구조가 강하게 유지되고 있다. 현행 공공 SW 관련 규제 체계에서도, 예를 들어 소프트웨어사업 계약 및 관리감독에 관한 지침은 공공기관이 사업을 발주하기 전에 사업 범위와 예상 일정 등을 포함한 사업계획을 수립하도록 하고 있다. 이러한 계약 및 검수 구조에서는 발주 단계에서 사업 범위와 일정이 상당 부분 확정되기 때문에, SI 업체가 내부적으로 Agile을 활용하더라도 프로젝트의 공식적인 사업관리 방식은 폭포수에 가까워지기 쉽다. 민간 부문은 어떠한가? 한국에서도 2000년대 중반부터 Agile 개발에 대한 관심이 높아졌다. 그러나 관심과 실제 실행 사이에는 큰 차이가 있었다. 필자가 2023년 Scrum을 주제로 한 컨퍼런스에서 기조강연을 할 당시 약 200명이 참석했는데, “회사에서 SW 제품 업그레이드를 한 달 이내의 주기로 정기적으로 출시하는 분은 손을 들어 보십시오”라고 질문했을 때 손을 든 사람은 단 한 명이었다. 이는 Scrum이나 Agile이라는 용어가 확산된 것과 실제로 짧은 주기의 반복적 개발과 배포를 실행하는 것은 별개의 문제임을 보여준다. (박준성, 한국 기업들의 Scrum 활용 역사, 현황과 향후 개선방향, kosta-online.com/post/scrum-in-korea, 2025) 그렇다면 왜 한국에서는 Agile이 현장에서 충분히 정착하지 못했을까? 여러 원인이 있겠지만, 필자는 그중에서도 XP의 핵심 엔지니어링 실천법이 제대로 도입되지 않은 것이 중요한 기술적 원인이라고 본다. Scrum은 주로 제품 백로그, 스프린트, 역할과 협업 방식 등 팀의 작업을 조직하는 프레임워크인 반면, XP는 Test-First Programming(TFP), TDD, Refactoring, Continuous Integration(CI), Pair Programming 등 개발자가 실제로 코드를 어떻게 개발하고 검증할 것인가에 초점을 둔다. 특히 TDD와 CI를 제대로 실행하지 않으면 코드의 변경 용이성과 빌드의 안정성을 지속적으로 유지하기 어렵다. 그 결과 짧은 주기로 기능을 개발하고 검증해 정기적으로 배포하는 것이 점점 어려워진다. 즉, Scrum의 스프린트라는 시간 상자를 도입하는 것만으로는 Agile의 핵심인 짧은 피드백 주기와 지속적인 소프트웨어 전달을 실현하기 어렵다. TFP/TDD를 제대로 실행하려면 요구사항을 검증 가능한 형태의 스펙으로 정의하고, 사용 사례별로 구체적인 테스트 케이스를 도출할 수 있어야 한다. 그러나 이러한 요구사항·테스트 설계 역량 역시 한국 기업에서 충분히 정착되지 않은 경우가 많다. 또한 Refactoring을 지속적으로 수행하려면 개발자가 객체지향 설계 원칙과 디자인 패턴, Clean Code, Refactoring 패턴 등에 대한 충분한 훈련을 받아야 한다. 이 점에서 XP는 AI 에이전트 코딩 시대에 다시 중요해진다. AI 에이전트가 매우 빠르게 코드를 생성할수록 인간이 모든 코드를 직접 검토하는 방식으로는 품질을 보장하기 어렵다. 따라서 명확한 요구사항 스펙, 자동화된 테스트, 지속적 통합, 결정적(Deterministic) 검증을 통해 AI 에이전트가 생성한 코드가 지속적으로 검증되도록 해야 한다. XP가 발전시킨 이러한 엔지니어링 실천법은 AI 에이전트가 신뢰할 수 있고 장기적으로 유지보수 가능한 프로덕션 시스템을 구축하기 위한 중요한 기반이 될 수 있다. 정보공학(IE)에서 객체지향 분석/설계로 미국에서 1990년대까지 널리 활용되었던 정보공학(IE)은 기능 계층도(Function Hierarchy Diagram, FHD)와 개체-관계 다이어그램(Entity-Relationship Diagram, ERD) 등을 이용해 기능적 요구사항과 관계형 DB 모델을 정의했다. 1990년대 후반부터 2000년대 중반까지는 Unified Modeling Language(UML) 기반의 객체 분석·설계(Object-Oriented Analysis & Design, OOAD)가 주요 분석·설계 접근법으로 자리 잡았다. OOAD에서는 분석 단계에서 기능적 요구사항을 사용 사례(Use Case)로 표현하고, 주요 도메인 개념과 그 관계를 개념 수준의 클래스 다이어그램(Conceptual-Level Class Diagram)으로 모델링한다.설계 단계에서는 사용 사례 시나리오에서 도출된 오퍼레이션을 구현 수준 클래스 다이어그램(Implementation-Level Class Diagram)의 클래스 메소드로 매핑한다. 이 설계 방법을 클래스-책임 할당(Class-Responsibility Assignment, CRA)이라 부르고, CRC(Class-Responsibility-Collaborator) 카드와 GRASP 패턴을 적용해 수행할 수 있다(C. Larman, Applying UML and Patterns, 1997 참조). 관계형 DB 스키마도 개념 수준의 클래스 다이어그램에서 자동으로 생성할 수 있어, 객체-관계형 매핑(Object-Relational Mapping, ORM)도 자연스럽게 구현할 수 있다. (박준성, The Complete Guide to Business Analysis, kosta-online.com/post/the-complete-guide-to-business-analysis, 2025 참조) 2000년대 후반 이후 Agile 개발이 확산되면서 전통적인 정식 사용 사례 모델링 대신 사용자 스토리(User Story)와 행위 주도 개발(behavior-Driven Development, BDD)을 이용해 요구사항과 인수 기준을 정의하는 방식이 널리 활용되기 시작했다. 객체 설계에서도 개발자가 CRC 카드 및 GRASP 패턴의 적용을 통해 모든 설계를 사전에 모델링하는 방식보다는, 객체지향 설계 원칙과 패턴에 대한 지식을 바탕으로 도메인 주도 설계(DDD), 리팩토링, 코드 리뷰 등을 지속적으로 수행하는 방식이 중요해졌다. E. Evans의 Domain-Driven Design(2003)은 이러한 접근을 체계화한 대표적인 저서다. SOLID와 같은 객체지향 설계 원칙과 E. Gamma 등의 Design Patterns(1994)에 소개된 GoF 패턴 역시 오늘날에도 객체지향 설계를 위한 중요한 지식 기반으로 활용되고 있다. 다만 현대의 SW 개발에서는 이러한 원칙과 패턴을 형식적인 설계 산출물로 작성하기보다는 코드와 아키텍처에 지속적으로 적용하고, 리팩토링과 코드 리뷰를 통해 유지하는 방식이 일반적이다. 그렇다면 한국의 현실은 어떠한가? 필자가 국내 SW 기업을 대상으로 조사한 결과, 사용 사례, 사용자 스토리, BDD 등을 이용해 요구사항을 체계적으로 분석하거나, 클래스 모델링, DDD, 리팩토링, 코드 리뷰 등을 체계적으로 수행하는 기업은 많지 않았다. 즉, 분석·설계 방법론의 명칭은 알려져 있지만 이를 실제 개발 프로세스에 내재화한 조직은 상대적으로 드문 것이다. 이 문제는 AI 에이전트 코딩 시대에 더욱 중요해진다. AI 에이전트에게 코드를 생성하도록 할 때도 개발자가 명확한 요구사항 스펙과 인수 기준을 제공하고, 에이전트가 생성한 코드를 자동화된 테스트와 함께 검증하는 체계가 필요하다. 이러한 접근을 에이전트 코딩에서 Spec-Driven Development(SDD) 및 eval-Driven Development(EDD)라고 부른다. 또한 개발자는 생성된 코드가 객체지향 설계 원칙, 도메인 모델, 아키텍처 원칙 등을 적절하게 구현하고 있는지 코드 리뷰를 통해 확인해야 한다. 구글에서는 AI 활용이 확대되고 있지만, 코드 생성 결과를 무검증으로 프로덕션에 반영하지 않는다. T. Winters 등의 Software Engineering at Google(2020)에 따르면 Google에서는 사실상 모든 코드 변경에 대해 코드 리뷰가 의무화되어 있으며, 각 변경에는 해당 프로그래밍 언어의 전문성을 인증받은 엔지니어의 'Readability Approval'도 요구된다. Readability는 단순한 문법 검사가 아니라 해당 언어의 관용적 사용법, 코드 구조, API 설계, 공통 라이브러리 활용, 문서화와 테스트 커버리지 등을 포함하는 Google의 표준화된 전문 검토·멘토링 체계다.Google은 이러한 기존의 코드 리뷰 체계를 AI 시대에도 유지하면서, 동시에 AI를 코드 리뷰와 Readability 개선 자체에도 활용하고 있다. 실제로 Google은 AI를 이용해 코드 리뷰 Comment를 해결하고, 코드 Readability 개선을 지원하며, Build Failure 수정 등을 수행하는 도구를 내부 개발 환경에 적용하고 있다. (research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/ 참조) AI 에이전트는 요구사항이 모호하거나 설계 원칙이 명확하지 않을수록 그 빈틈을 임의의 코드로 채울 가능성이 높다. 따라서 AI 에이전트 코딩에서 개발자의 역할은 코드를 직접 작성하는 것에서 벗어나, 명확한 스펙을 정의하고, 아키텍처와 설계 원칙을 제시하며, 에이전트가 생성한 결과를 검증하고 승인하는 역할로 변화해야 한다. 환각과 오류 가능성을 완전히 제거할 수 없는 AI 에이전트 코딩에서 프로덕션 시스템의 품질과 유지보수성을 확보하려면, 객체지향 분석·설계 역량을 갖춘 개발자가 에이전트가 이해할 수 있는 명확한 스펙을 제공하고, 생성된 코드가 설계 원칙과 아키텍처를 준수하는지 검증하며 최종적으로 그 결과에 책임지는 개발 체계가 필요하다. 3-Tier 모놀리식 아키텍처+EAI에서 서비스 지향 아키텍처(SOA)로 미국에서도 1990년대까지는 UI–application Logic–Database로 구성되는 3-Tier 기반의 모놀리식 애플리케이션이 널리 사용되었다. 이러한 애플리케이션을 기업 전체 차원에서 통합하기 위해서는 Enterprise application Integration(EAI) 기술을 이용해 시스템 간 인터페이스를 연결하는 방식이 일반적이었다. 특히 Point-to-Point 방식에서는 애플리케이션의 수가 증가할수록 시스템 간 연결과 인터페이스가 조합적으로 증가하여 통합 복잡도가 빠르게 커지는 문제가 있었다. 2000년대 초부터 선도 기업들은 이러한 문제를 해결하기 위해 서비스 지향 아키텍처(SOA)를 도입하기 시작했다. SOA에서는 애플리케이션의 기능을 독립적인 비즈니스 서비스로 분리하고, 각 서비스를 명확한 서비스 계약(Service Contract)과 인터페이스를 통해 외부에 공개한다. 서비스 간에는 정의된 인터페이스를 통해서만 상호작용하도록 함으로써 서비스의 내부 구현과 변경을 다른 서비스의 구현과 상대적으로 독립시킬 수 있다. Point-to-Point 통합에서는 애플리케이션 수가 증가할수록 시스템 간 연결이 기하급수적으로 복잡해질 수 있지만, SOA에서는 공통의 서비스 인터페이스와 서비스 계약을 중심으로 통합 구조를 구성함으로써 이러한 복잡도를 크게 줄일 수 있다. 그 결과 애플리케이션 통합과 상호운용성을 높이고, 서비스의 변경과 재사용을 용이하게 하며, 장기적으로 개발 및 유지보수 비용과 품질을 개선할 수 있다. 아래 표에서 보듯이, 가트너(Gartner) 조사에 따르면 2008년 북미, 유럽, 아시아에서 SOA를 도입한 기업의 비율은 각각 55%, 70%, 25%로 SOA 도입이 이미 상당히 진행되고 있었음을 보여준다. 그렇다면 한국에서는 어떠했을까? 한국에서도 2000년대 중반 SOA에 대한 관심과 투자가 상당히 높아졌지만, 많은 프로젝트가 기대했던 수준의 성과를 내지 못했다. 필자는 그 주요 원인 가운데 하나가 서비스를 구현하기 전에 필요한 비즈니스·데이터·애플리케이션 분석과 아키텍처 설계가 충분하지 않았다는 점이라고 본다. 비즈니스 프로세스 모델링, 데이터 모델링, 사용 사례 분석, 객체 설계를 통한 도메인 모델링 등을 선행하여 비즈니스 역량을 식별하고 이를 적절한 서비스로 설계해야 하는데, 이러한 분석·설계 역량과 SOA 설계 경험이 충분히 축적되지 않은 상태에서 기술 도입 자체에 초점을 맞춘 프로젝트가 추진되었기 때문이다. 2010년대에 마이크로서비스 아키텍처(Microservice Architecture, MSA)가 부상하면서 SOA가 다시 주목받았다. MSA는 SOA가 강조했던 서비스 기반과 느슨한 결합이라는 원칙을 클라우드 네이티브 환경에서 독립적인 배포와 확장을 중심으로 구체화한 아키텍처 스타일로 볼 수 있다. 아마존, 넷플릭스 등 웹 스케일 기업들은 서비스별 독립 배포를 통해 전체 애플리케이션의 배포 주기를 단축하고, 서비스별로 서로 다른 확장성을 제공할 수 있는 구조를 발전시켰다. 그러나 모든 애플리케이션을 처음부터 마이크로서비스로 분해하는 것이 항상 좋은 선택은 아니다. 서비스별 독립 배포와 독립적인 확장이 실제로 필요하지 않은 경우에는 마이크로서비스가 오히려 분산 시스템의 복잡성, 운영 부담, 네트워크 장애, 데이터 일관성 문제 등을 추가한다. 예컨대 아마존은 2015년에 평균 0.6초의 배포 주기를 보였다. (W. Vogel, I Love APIs 2015: Microservices at Amazon, 2015.) 미국의 선도적인 SaaS 기업에서는 하루에도 여러 차례 SW를 배포할 수 있는 지속적 전달 체계가 일반화되어 있다. 반면 앞에서 언급했듯이 1개월 이내의 배포 주기를 실현하는 기업이 많지 않은 한국의 일반적인 기업 환경에서는, 모든 애플리케이션을 MSA로 전환하는 것이 반드시 경제적인 선택이라고 보기 어렵다. 최근에는 무조건 MSA로 분해하기보다 먼저 애플리케이션 내부를 비즈니스 도메인별로 명확하게 모듈화하고, 독립적인 배포나 확장이 실제로 필요한 부분만 마이크로서비스로 분리하는 Modulith 접근이 주목받고 있다. 애플리케이션 전체를 일단 Modulith로 구축한 다음, 필요한 부분을 점진적으로 마이크로서비스화하는 이른바 Strangler 패턴을 적용할 수도 있다. (박준성, The Complete Guide to SOA, MSA and Modulith, kosta-online.com/post/the-complete-guide-to-business-analysis, 2025 참조) 이러한 서비스 중심 아키텍처는 AI 에이전트 시대에도 중요한 의미를 갖는다. 기업의 AI 에이전트를 신뢰할 수 있는 프로덕션 시스템으로 운영하려면 에이전트의 추론·의사결정과 비즈니스 기능의 실제 실행을 분리하는 것이 바람직하다. 예를 들어 전자상거래 시스템에서는 고객, 주문, 결제, 재고, 배송 등의 비즈니스 역량을 각각 서비스로 구현하고, AI 에이전트가 이들 서비스를 필요한 순서와 조합으로 호출하도록 구성할 수 있다. 이 구조의 가장 중요한 장점은 비결정적인(Nondeterministic) AI 에이전트에게 추론과 의사결정을 맡기되, 실제 비즈니스 트랜잭션의 실행은 결정적인(Deterministic) 서비스에 맡길 수 있다는 것이다. 에이전트가 환각이나 잘못된 추론을 완전히 피할 수 없더라도, 서비스 계층에서는 인증·인가, 데이터 검증, 비즈니스 규칙, 트랜잭션, 감사 로그 등의 제약을 결정적으로 적용할 수 있다. 따라서 AI 에이전트 시대 핵심은 전통적인 애플리케이션과 서비스를 없애는 것이 아니라, 에이전트 동적 추론과 서비스의 결정적 실행을 결합하는 것이다. 전통적인 애플리케이션에서는 복잡한 비즈니스 프로세스의 실행 순서를 개발자가 정태적으로 미리 정의한 반면, 에이전트 기반 시스템에서는 주어진 목표와 현재 상황에 따라 어떤 비즈니스 역량을 어떤 순서로 호출할 것인지 에이전트가 동태적으로 결정할 수 있다. 서비스는 실행의 신뢰성을 담당하고, 에이전트는 상황에 따른 조정과 의사결정을 담당하는 것이다. V-모델에서 테스트 주도 개발(TDD)로 아래 그림 3의 V-모델에서 보듯이 전통적인 Waterfall 프로세스에서는 개발이 완료된 이후 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트 등을 순차적으로 수행한다. 이러한 방식은 요구사항과 설계가 개발 초기에 안정적으로 확정되어 있고 변경이 많지 않은 시스템에서는 효과적이다. 그러나 요구사항의 불확실성이 높고 빈번한 변경이 예상되는 시스템에서는 테스트가 개발 후반에 집중되면서 결함을 늦게 발견하고 수정 비용이 증가할 수 있다. 미국에서는 2000년대 중반부터 Agile 개발이 확산되고 JUnit, NUnit 등 테스트 자동화 도구가 보급되면서 테스트 방식도 크게 변화했다. XP에서는 개발이 완료된 후 테스트하는 대신 테스트를 개발 과정에 내재화하고, 코드를 변경할 때마다 자동화된 테스트를 반복적으로 실행하는 방식을 강조했다. 즉, V-모델과 같은 순차적인 테스트 방식에서 벗어나 개발과 테스트를 짧은 주기로 반복하는 것이다. XP의 핵심 실천법에는 Test-Driven Development(TDD), Test-First Programming(TFP), Refactoring, Continuous Integration(CI) 등이 포함된다. TDD에서는 그림 4처럼 코딩에 앞서 먼저 실패하는 테스트를 작성하고(Red), 그 테스트를 통과할 최소한의 코드를 구현한 후(Green), 기능을 변경하지 않으면서 객체지향 설계 원칙과 패턴을 적용해 코드의 구조와 가독성을 개선한다(Refactoring). 그리고 다시 다음 테스트를 작성하는 짧은 사이클을 반복한다. CI에서는 코드 변경을 자주 통합하고 자동화된 빌드와 테스트를 실행하여 오류가 누적되지 않도록 한다. 이러한 짧은 개발·검증 사이클을 통해 코드의 품질과 변경 용이성을 지속적으로 유지할 수 있다. (Kent Beck, Extreme Programming Explained, 2003 참조) 그렇다면 왜 한국에서는 이러한 XP의 엔지니어링 실천법이 충분히 확산되지 못했을까? 여러 원인이 있겠지만, 필자는 무엇보다 교육과 훈련의 부족을 중요한 원인으로 본다. TDD와 CI가 단순한 테스트 기법이 아니라 SW 품질을 지속적으로 통제하면서 동시에 짧은 개발·배포 주기를 가능하게 하는 핵심 엔지니어링 Practice라는 점을 개발자들이 충분히 이해하고 훈련받아야 한다. 또한 이를 개인의 개발 습관에 맡기지 않고 조직의 표준 개발 프로세스와 CI/CD 파이프라인에 내재화해야 한다. XP의 이러한 엔지니어링 실천법은 Waterfall에서 Iterative/Agile 개발로 전환하기 위한 중요한 기술적 기반이기도 하다. (박준성, 애자일 개발의 성공 비결인 테스트 주도 개발 (TDD), kosta-online.com/challenge-page/tdd) 이러한 역량의 중요성은 AI 에이전트 코딩 시대에 더욱 커지고 있다. AI 에이전트가 생성하는 코드는 확률적 생성 과정의 특성상 요구사항을 잘못 해석하거나 존재하지 않는 API를 사용하거나, 기존 코드의 설계 원칙을 위반하는 등의 오류를 포함할 수 있다. TDD와 CI/CD를 자동화된 결정적(deterministic) 검증 장치로 활용하면 이러한 오류를 테스트 단계에서 탐지하고, 검증에 실패한 코드를 프로덕션에 배포하지 않도록 통제할 수 있다. 즉, TDD와 CI/CD가 AI의 비결정성을 제거하는 것은 아니지만, 비결정적인 코드 생성 과정을 결정적인 검증 과정으로 감싸는 역할을 한다. 따라서 AI 시대의 SW 개발에서는 TDD와 CI/CD의 중요성이 오히려 커진다. AI 에이전트가 코드를 빠르게 생성할수록 사람이 모든 코드를 직접 읽고 검증하는 방식은 병목이 되기 때문이다. 대신 요구사항과 비즈니스 행위를 충분히 커버하는 자동화된 테스트를 먼저 정의하고, AI 에이전트가 생성한 코드가 이를 통과하는지를 자동으로 검증하는 방식으로 개발 프로세스를 전환해야 한다. 이를 위해서는 TDD와 CI 자체에 대한 교육만으로 충분하지 않다. 먼저 사용 사례와 사용자 스토리 등을 기반으로 요구사항을 명확하게 정의하고, 각 비즈니스 행위에 대한 검증 가능한 인수 기준과 테스트 케이스를 도출하는 역량이 필요하다. 또한 객체지향 설계와 리팩토링 역량을 통해 코드의 변경 용이성과 지속 가능성을 확보해야 한다. 결국 높은 품질의 테스트를 자동화하려면 높은 품질의 요구사항·분석·설계가 선행돼야 한다. 공공 SW 계약·발주·검수 제도 지속 배포 가능하게 개선해야 지금까지 살펴본 것처럼 미국의 SW 공학은 지난 30여 년 동안 ISP에서 EA로, Waterfall에서 Iterative/Agile로, IE에서 객체지향 분석·설계로, 3-Tier 모놀리식과 EAI에서 SOA로, V-모델에서 TDD와 CI/CD로 지속적으로 진화해 왔다. 이러한 변화의 공통점은 단순히 새로운 방법론이나 기술을 도입한 것이 아니다. 변화와 불확실성이 증가하는 환경에서도 SW를 빠르게 개발하면서 품질과 유지보수성을 확보하기 위해 SW 개발을 점점 더 공학적으로 체계화해 온 과정이었다. 한국은 그동안 하드웨어, 제조업, 통신 인프라 등에서는 세계적인 경쟁력을 확보했지만, SW 공학에서는 이러한 변화가 충분히 내재화되지 못했다. 특히 공공 부문에서는 사업 범위와 일정을 사전에 확정하는 Waterfall식 계약·관리 체계가 여전히 강하고, 많은 기업에서도 EA, 객체지향 분석·설계, TDD, CI/CD와 같은 SW 공학 실천법이 개발 현장에 충분히 정착되지 못했다. 문제는 이것이 과거의 개발 방식에 머무르는 데 그치지 않고, AI 에이전트를 활용한 차세대 SW 개발로 전환하는 데에도 장애가 될 수 있다는 점이다. AI는 SW 개발의 생산성을 획기적으로 높일 수 있다. 그러나 AI 에이전트가 코드를 자동으로 생성한다고 해서 SW 공학이 필요 없어지는 것은 아니다. 오히려 반대다. AI 에이전트가 코드를 빠르게 생성할수록 요구사항을 명확하게 정의하고, 아키텍처와 설계 원칙을 설정하며, 자동화된 테스트와 CI/CD를 통해 결과를 검증하고, 최종적으로 사람이 품질과 책임을 보장하는 체계가 더욱 중요해진다. AI 에이전트에게 필요한 것은 더 많은 코딩 능력이 아니라, 더 명확한 스펙과 더 엄격한 검증 체계다. 따라서 한국이 AI 강국으로 도약하려면 GPU와 데이터센터, AI 모델과 인재에 대한 투자만으로는 충분하지 않다. AI가 실제 산업의 생산성과 경쟁력으로 전환되도록 하는 SW 공학 역량을 국가 차원에서 현대화해야 한다. 이를 위해서는 공공 SW의 계약·발주·검수 제도를 Iterative/Agile과 지속적 배포가 가능하도록 개선하고, 기업과 정부에 EA와 SW 아키텍처 전문가를 체계적으로 양성하며, 대학과 기업 교육에서 요구 공학, 객체지향 분석·설계, TDD, CI/CD, Cloud-Native 및 AI Agent Engineering을 핵심 역량으로 강화해야 한다. 궁극적으로 AI 시대의 SW 개발은 “사람이 코드를 작성하고 AI가 보조하는 방식”에서 “AI 에이전트가 코드를 생성하고 SW 공학이 이를 통제하는 방식”으로 진화할 것이다. 이때 SW 공학의 역할은 사라지는 것이 아니라 실행 가능한 거버넌스(executable Governance)로 진화한다. 요구사항은 테스트 가능한 스펙이 되고, 아키텍처 원칙은 코드로 검증되며, 품질 기준은 자동화된 테스트와 CI/CD 파이프라인으로 실행된다. AI 에이전트의 자율성이 커질수록 이를 안전하게 통제할 수 있는 공학적 제약과 검증 체계의 중요성도 커지는 것이다. 한국이 AI 강국이 되기 위해 지금 필요한 것은 과거의 SW 개발 방식을 AI로 자동화하는 것이 아니다. 과거의 SW 공학을 과감히 현대화해 AI 에이전트가 활용하고 준수할 수 있는 실행 가능한 SW 공학 체계로 전환하는 것이다. AI 경쟁력의 궁극적인 기반은 AI 기술 자체가 아니라, AI를 신뢰할 수 있는 산업 시스템으로 전환하는 SW 공학 역량이다.
