AI 에이전트가 뒤집은 Build vs Buy의 공식
Uncle Bob Martin의 통찰 심층 분석
“AI agents have vastly changed the build vs buy calculus. The vast majority of tools can be built at virtually no cost.” — Robert C. Martin (@unclebobmartin), 2026. 3. 10.
들어가며
2026년 3월 10일, 클린 코드(Clean Code)와 SOLID 원칙으로 수십 년간 소프트웨어 엔지니어링 세계에 영향을 미쳐온 Robert C. Martin, 즉 “Uncle Bob”이 X(구 트위터)에 단 두 문장짜리 트윗을 올렸다. 조회 수 1.1만 회를 기록한 이 짧은 글은, 그 간결함에 비해 담고 있는 의미가 상당히 묵직하다. 요지는 이렇다: AI 에이전트의 등장으로 인해 소프트웨어 도구를 “사야 할지(Buy) 아니면 직접 만들어야 할지(Build)” 고민하던 오래된 공식이 근본적으로 바뀌었다는 것이다. 그리고 그 변화의 핵심은, 예전에는 만들기 너무 어렵다거나 비용이 너무 많이 든다는 이유로 상용 솔루션에 의존하거나 아예 포기했던 수많은 도구들을, 이제는 AI 에이전트를 통해 거의 비용 없이 직접 구축할 수 있게 되었다는 것이다.
Build vs Buy란 무엇인가
소프트웨어 산업에서 Build vs Buy 결정은 오랫동안 가장 중요한 전략적 선택 중 하나였다. 간단히 말하면, 팀이 필요로 하는 특정 기능이나 도구를 직접 개발할 것인지(Build), 아니면 시장에 이미 존재하는 솔루션을 구매하거나 구독할 것인지(Buy) 결정하는 문제다.
전통적인 관점에서 이 결정은 여러 요소를 저울질하는 복잡한 계산이었다. 직접 개발하면 요구사항에 딱 맞게 커스터마이징할 수 있고 외부 벤더 의존도가 없다는 장점이 있지만, 개발 시간과 인건비가 상당하고 장기적인 유지보수 부담도 따른다. 반면 구매를 선택하면 빠르게 도입할 수 있고 전문 업체의 지속적인 업데이트와 지원을 받을 수 있지만, 커스터마이징에 한계가 있고 라이선스 비용이 누적된다는 단점이 있다.
이 고전적 방정식에서 Build 쪽을 무겁게 만들었던 가장 큰 요인은 바로 인건비와 시간이었다. 숙련된 개발자가 특정 분석 도구나 내부 DSL 파서 같은 것을 처음부터 구축하려면 수주에서 수개월이 걸리고, 그 사이 발생하는 기회비용은 막대하다. 바로 이 지점에서 Uncle Bob의 주장이 시작된다.
AI 에이전트가 방정식을 어떻게 바꾸었는가
Uncle Bob이 말하는 “build at virtually no cost”는 물론 소프트웨어 개발에 드는 비용이 완전히 사라진다는 의미가 아니다. 그가 지목하는 본질적인 변화는, AI 에이전트를 활용하면 개발 비용의 가장 큰 구성 요소였던 숙련 개발자의 시간이 극적으로 압축된다는 사실이다.
후속 댓글에서 Uncle Bob은 구체적인 예시를 열거했다. Crap Analysis(코드 품질 저하 분석), Mutation Testing(변이 테스트), Dependency Management and Visualization(의존성 관리 및 시각화), DSL Parsing and Execution(도메인 특화 언어 파싱과 실행), Debug Logging and Analysis(디버그 로그 기록 및 분석)가 그것이다. 그는 “목록은 끝이 없다”고 덧붙이며, 이것들이 바로 “갖고 싶었지만 만들기에는 너무 어렵다고 생각했던 모든 도구들”이라고 요약했다.
어떤 팔로워가 “이런 도구들은 어차피 구매하지도 않았고 오픈소스로도 많이 있지 않냐”고 반문하자, Uncle Bob은 핵심을 짚었다: “이제 AI로 반나절 만에 직접 만들 수 있다, 그것도 여러분의 프로젝트에 맞게 튜닝된 형태로. 그것을 다른 누군가가 꼭 써야 할 필요도 없다.” 이 마지막 문장이 특히 중요하다. 기존의 도구 개발 경제학은 어느 정도의 규모를 전제로 했다. 많은 사람이 쓸수록 개발 비용이 분산되므로 ROI가 나왔다. 하지만 AI 에이전트 시대에는 오직 내 팀, 내 프로젝트를 위해 딱 맞는 도구 하나를 만드는 것도 경제적으로 타당해진다.
Uncle Bob이 언급한 도구들의 의미
Crap Analysis (코드 품질 저하 분석)
“CRAP”은 Change Risk Anti-Patterns의 약자로, 코드의 순환 복잡도(cyclomatic complexity)와 테스트 커버리지를 결합하여 리팩토링이 필요한 위험 영역을 수치화하는 지표다. JaCoCo 같은 기존 도구들이 Java 생태계에서 이를 일부 지원하지만, 특정 프로젝트의 아키텍처 맥락이나 팀의 코딩 컨벤션을 반영한 맞춤형 분석은 여전히 갭이 크다. AI 에이전트를 활용하면 코드베이스를 읽고 이해하여 팀 고유의 맥락에서 “지금 가장 위험한 코드는 어디인가”를 진단하는 도구를 빠르게 구축할 수 있다.
Mutation Testing (변이 테스트)
변이 테스트는 소프트웨어 테스트 품질을 측정하는 기법으로, 프로그램의 소스코드를 의도적으로 소규모 변형(mutation)시킨 후 기존 테스트 스위트가 이 변화를 감지(kill)하는지 확인한다. 테스트 케이스를 작성했더라도 실제로 그 테스트가 버그를 잡아낼 수 있는지를 검증하는 메타 테스팅 방법이다. PIT(Pitest) 같은 도구가 Java에서 이를 수행하지만, 대규모 코드베이스에서 변이 테스트를 실행하면 시간이 매우 오래 걸리고 분석 결과를 해석하는 데도 상당한 노력이 필요하다. AI 에이전트는 변이 생성과 분석, 우선순위 선정을 자동화하는 파이프라인 구축을 단시간에 가능하게 한다.
Dependency Management and Visualization (의존성 관리 및 시각화)
현대 소프트웨어 프로젝트는 수백, 수천 개의 외부 라이브러리에 의존한다. 이 의존성 그래프를 시각화하고, 취약점이 있는 패키지를 추적하고, 버전 충돌을 감지하고, 업그레이드 경로를 제안하는 통합 도구는 여러 오픈소스 조각들을 붙여 만들기 까다롭다. AI 에이전트는 프로젝트의 의존성 메타데이터를 읽고 Neo4j 같은 그래프 데이터베이스와 결합하여 인터랙티브한 시각화 도구를 구축하는 작업을 빠르게 처리할 수 있다.
DSL Parsing and Execution (도메인 특화 언어 파싱 및 실행)
DSL(Domain-Specific Language)은 특정 문제 영역에 맞춰 설계된 소형 언어다. Makefile, SQL, 정규표현식, Terraform HCL이 모두 DSL의 일종이다. 내부 설정 언어나 비즈니스 규칙을 표현하기 위한 커스텀 DSL을 설계하고 파서를 작성하는 일은 전통적으로 컴파일러 이론에 익숙한 숙련 개발자가 필요한 작업이었다. AI 에이전트는 문법 명세를 이해하고 ANTLR이나 PEG.js 기반의 파서 코드를 생성하거나, 아예 인터프리터까지 구현하는 수준의 작업을 빠르게 수행할 수 있다.
Debug Logging and Analysis (디버그 로그 기록 및 분석)
애플리케이션이 복잡해질수록 로그 분석은 점점 어려워진다. 수백만 줄의 로그에서 특정 에러 패턴을 추출하고, 분산 시스템에서 요청 추적(distributed tracing)을 연결하고, 성능 이상 징후를 감지하는 도구를 내 시스템에 맞게 튜닝하는 것은 비용이 크다. Elastic Stack이나 Datadog 같은 상용 도구는 강력하지만 일반화된 솔루션이라 팀 고유의 로그 스키마와 패턴에 최적화하기 어렵다. AI 에이전트를 통해 우리 시스템의 로그 포맷을 이해하고 이상 탐지를 수행하는 맞춤형 분석 파이프라인을 구축하는 것이 현실적으로 가능해졌다.
Uncle Bob의 AI 코딩 여정과 이 발언의 맥락
이 트윗을 단순한 과장으로 읽어서는 안 된다. Uncle Bob은 2026년 2월 초에도 AI 코딩 도구 사용 6주차 소감을 올렸다. 그는 “파워는 부정할 수 없지만 리스크와 시간 낭비도 똑같이 부정할 수 없다”며, 마치 수공구에 능숙한 목수가 갑자기 전동공구 가게에 들어간 것 같다고 비유했다. 처음에는 배우는 데 시간이 걸려 오히려 느릴 수도 있다는 솔직한 고백이었다.
그런 신중한 입장을 가진 Uncle Bob이 한 달 만에 “대부분의 도구를 거의 무료로 만들 수 있다”는 발언을 한 것은, 그 자신의 학습 곡선이 임계점을 넘었거나 AI 에이전트의 능력에 대한 관찰과 경험이 쌓였음을 시사한다. 클린 코드의 저자답게 그는 조심스럽게 접근했고, 그만큼 이 단언은 무게가 있다.
기존 Build vs Buy 공식이 무너지는 이유
전통적인 Build vs Buy 프레임워크는 몇 가지 핵심 가정 위에 세워져 있었다. 첫째, 빌드에는 고가의 개발자 시간이 필요하다는 것. 둘째, 도구의 복잡성이 높을수록 전문 지식이 필요하다는 것. 셋째, 한번 만든 도구는 유지보수 비용이 지속적으로 발생한다는 것.
AI 에이전트는 이 세 가지 가정을 모두 흔들었다. 개발자 시간은 의도(intent)를 명확히 표현하는 데 집중되고 구현 작업의 상당 부분은 에이전트가 처리한다. 복잡성이 높은 도메인도 LLM의 방대한 학습 데이터 덕분에 일정 수준의 전문 지식이 내재화되어 있다. 유지보수 측면에서도 내 프로젝트에 특화된 소형 도구는 그 목적이 명확하기 때문에 상용 도구보다 오히려 변화에 유연할 수 있다.
한편, 2026년 현재 AI 에이전트 도입에 관한 기업들의 인식도 변하고 있다. AI 에이전트가 전통 소프트웨어와 다른 점은 한번 만들고 끝나지 않는다는 것, 즉 지속적으로 새로운 절차를 배우고 새로운 유스케이스에 적응해야 한다는 것이다. 이는 Build vs Buy 결정이 일회성이 아니라 지속적인 판단이 됨을 의미한다. 그러나 Uncle Bob이 언급한 내부 개발 도구들—코드 분석기, 의존성 시각화기, 디버그 로그 분석기—은 비교적 안정적인 목적을 가진 도구들이므로 이 지속성 문제가 상대적으로 작다.
개발자에게 실질적으로 의미하는 바
Uncle Bob의 발언에서 가장 실천적인 교훈은 “어차피 아무도 안 쓸 것 같아서 만들지 않았던 그 도구들을 이제는 만들어도 된다” 는 것이다. 팀 내부의 워크플로우를 개선하기 위해 필요하지만 제품 로드맵에 들어가기에는 너무 작고, 그렇다고 외부에서 사와서 쓰기에는 너무 맞지 않는 그 중간 영역의 도구들이 있다.
예를 들어 특정 팀의 PR 리뷰 패턴을 분석해서 코드 품질 추세를 알려주는 도구, 레거시 시스템의 특이한 로그 형식을 파싱해서 의미 있는 알림을 생성하는 도구, 팀의 도메인 언어로 작성된 설정 파일을 검증하고 실행하는 도구 같은 것들이다. 이런 도구들을 AI 에이전트와 함께 반나절 스프린트로 만들어내는 것이 이제 현실적인 선택지가 되었다.
이것은 개발자의 역할 변화와도 맞닿아 있다. AI가 구현의 상당 부분을 맡으면서, 개발자에게 요구되는 핵심 역량은 점점 더 “무엇을 만들 것인가”를 정확히 정의하는 능력과 “제대로 만들어졌는지 검증하는 능력” 으로 이동하고 있다. Uncle Bob이 수십 년간 강조해온 명세의 명확성, 테스트의 중요성, 아키텍처적 사고가 오히려 AI 시대에 더 중요해지는 이유가 여기에 있다.
결론
Uncle Bob Martin의 이 짧은 트윗은 단순한 기술 낙관론이 아니다. 수십 년간 소프트웨어 개발 현장을 관통해온 실용주의자의 관찰이다. Build vs Buy라는 오래된 이분법이 AI 에이전트라는 새로운 변수 앞에서 재편되고 있으며, 그 결과 개발팀이 가질 수 있는 도구의 범위와 품질이 전에 없이 확장되었다.
이제 남은 질문은 “만들 수 있는가”가 아니라 “무엇을 만들 가치가 있는가”다. 도구를 구현하는 능력의 장벽이 낮아진 만큼, 도구의 필요성과 설계를 판단하는 역량이 더욱 중요해진다. Uncle Bob이 평생 가르쳐온 것이 바로 그 판단력이었다는 사실은, 어쩌면 우연이 아닐지도 모른다.
작성 일자: 2026-03-11