속도는 스타트업 세계의 건국 신화와 같습니다. 빠르게 출시하고, 더 빨리 반복하며, 사용자가 나타날 때 인프라에 대해 걱정하는 식입니다. 오랫동안 그 논리가 통했고, 적어도 그 실패는 근본적인 실수가 아닌 성장통처럼 보일 만큼 느렸습니다.

무언가 변화하고 있습니다. 초기 단계 팀들이 아키텍처적 적응성(architectural adaptability)을 2단계 프로젝트가 아니라 일급 관심사(first-class concern)로 다루기 시작하는 경우가 늘고 있습니다. 심리도 변하고 있고, 이를 가능하게 하는 도구들도 변하고 있습니다.

이유를 이해하려면 속도를 우선시하는 접근 방식이 실제로 어떤 비용을 초래하는지, 그리고 그 비용들이 더 이상 미룰 수 없게 되는 이유를 솔직하게 살펴봐야 합니다.

왜 많은 초기 단계 시스템은 변경 불가능해지는가?

그 메커니즘은 간단하지만, 그 결과는 값비쌉니다. 초기 아키텍처 결정들은 장기적 사고에 매우 좋지 않은 조건들 하에서 이루어집니다: 압축된 시간표, 제품이 무엇이 될지에 대한 불완전한 정보, 그리고 가능한 한 빨리 작동하는 소프트웨어를 보여줘야 한다는 강한 압박감입니다.

그런 조건들에서 내려진 결정들은 당장 시점에서는 결코 틀리지 않습니다. MVP(Minimum Viable Product)를 위한 모놀리식 아키텍처는 합리적입니다. 현재 사용 사례에 맞는 관계형 스키마(relational schema)를 사용하는 것은 합리적입니다. 어떤 방식으로든 서로 통신하는 서비스를 구축하는 것이 구현하기 가장 빠르기 때문에 합리하다가, 그렇지 않게 됩니다.

문제는

그 시점이 되면 모든 선택지가 비용이 많이 듭니다. 제품을 계속 운영하면서 핵심(Core)을 리팩터링(Refactor)하거나, 처음부터 다시 구축하며 전환 과정을 관리하거나, 아니면 계속해서 기술 부채(Debt)를 쌓으면서 점점 더 느려지는 기능 개발 속도(Feature velocity)를 받아들여야 합니다. 이 중 어느 것도 좋은 선택이 아니며, 이들은 모두 변화를 고려하지 않았던 이전 결정들의 결과물입니다.

엔지니어링 원칙으로서의 적응력(Adaptability)은 실제로 무엇을 의미하는가?

구체적으로 명시할 가치가 있습니다. 왜냐하면 "적응력을 위한 설계(Design for adaptability)"라는 말은 시간 압박을 받는 팀에게 유용한 프레임워크가 되지 못하는, 단순히 더 주의를 기울이라는 모호한 지침으로 흐려질 수 있기 때문입니다.

구체적으로, 이는 제품 전달(Delivery) 속도를 크게 늦추지 않으면서도 초기 단계에 적용할 수 있는 몇 가지를 의미합니다:

서비스와 컴포넌트 간의 명시적인 계약(Explicit contracts)을 설계하십시오. 입력과 출력을 명시적으로 만드는 인터페이스(Interface)는 요구사항이 변경됨에 따라 다르게 구현될 수 있습니다. 반면, 우연히 이를 사용하는 코드에 의해 암시적으로 정의된 인터페이스는 오직 그 특정 구현체에 의해서만 준수될 수 있습니다. 구현을 변경한다는 것은 모든 소비자(Consumer)를 변경해야 함을 의미합니다.

서로 다른 속도로 변화하는 관심사(Concerns)를 분리하십시오. 비즈니스 로직(Business logic)은 빈번하게 변경됩니다. 인프라(Infrastructure) 결정은 드물게 변경됩니다. 데이터 모델(Data models)은 마이그레이션(Migration)과 함께 신중하게 변경됩니다. 이러한 레이어(Layer)들을 별도로 유지하는 것은 일차적으로 코드 품질에 관한 것이 아니라, 한 레이어의 무언가를 변경해야 할 때 그 영향 범위(Blast radius)를 제한하기 위함입니다.

맥락(Context)이 생생할 때 결정을 문서화하십시오. 가장 비용이 많이 드는 종류의 기술 부채(Technical debt)는 지식 부채(Knowledge debt)입니다. 즉, 왜 무언가가 그런 방식으로 구축되었는지 아무도 기억하지 못하는 시스템을 말합니다. 이해하고 있는 시스템을 변경하는 것은 다룰 수 있는 수준(Tractable)이지만, 추론을 통해 재구성해야 하는 시스템을 변경하는 것은 불가능합니다.

이러한 원칙 중 그 어느 것도 MVP 단계에서 팀의 속도를 늦출 것을 요구하지 않습니다. 대신 결정에 대해 약간 다른 방향성을 요구합니다. 즉, 선택지를 조기에 소멸시키기보다는 선택지를 보존하는 것을 기본값으로 하는 방향성입니다.

왜 적응력 우선(Adaptability-first) 사고로의 전환이 지금 가속화되고 있는가?

두 가지 힘이 결합하면서 이러한 전환은 더욱 시급해지는 동시에 더욱 실현 가능해지고 있습니다.

첫 번째는 급변하는 시장에서 유연하지 못함(inflexibility)으로 인해 발생하는 비용의 상승입니다. 제품 요구사항이 변하는 속도, 스타트업이 새로운 AI 역량을 통합해야 하는 빈도, 그리고 경쟁 역학이 변화하는 속도가 모두 증가했습니다. 1년 차에 비즈니스 모델에 잘 맞았던 시스템이라도 2년 차 말에는 상당한 수정이 필요할 수 있습니다. 적응력(adaptability)을 고려하여 설계한 팀은 이러한 수정을 수행할 수 있습니다. 그렇지 않은 팀은 유의미할 만큼 빠르게 대응하지 못하는 경우가 많습니다.

두 번째 힘은 도구(tooling)입니다. 8080.ai, CrewAI, Replit을 포함한 에이전트 기반 AI (Agentic AI) 개발 플랫폼은 잘 구조화된 소프트웨어를 구축하는 데 드는 시간 비용을 근본적으로 변화시키고 있습니다. 속도 우선(speed-first) 아키텍처를 옹호하던 전통적인 논거는 부분적으로 적절한 아키텍처를 구축하는 데 초기 팀이 감당할 수 없는 시간이 소요된다는 점이었습니다. 하지만 에이전트 기반 플랫폼이 일반적인 영어 명세(plain-English specification)를 서비스 경계(service boundaries), API 계약(API contracts), 데이터베이스 스키마(database schemas), 인프라 구성(infrastructure configuration)을 포함한 완전한 아키텍처 계획으로 분해하고, 전문화된 에이전트들이 병렬로 해당 계획에 맞춰 구축할 수 있게 되면서, 시간적 제약에 대한 논거는 실질적으로 약화되었습니다.

Microsoft의 스타트업 프로그램 분석은 이러한 기저의 역학을 잘 포착하고 있습니다. AI가 실행 계층(execution layer)의 더 많은 부분을 담당함에 따라, 스타트업의 경쟁 우위는 아키텍처의 명확성(architectural clarity)과 지속 가능한 제품 결정(durable product decisions)을 향해 상류(upstream)로 이동하고 있습니다. 단순한 코딩 속도는 범용화(commoditized)되고 있으며, 구조적 품질(structural quality)이 차별화 요소가 되고 있습니다.

아키텍처 우선 개발 도구는 어떻게 방정식을 바꾸는가?

아키텍처를 사후 고려 사항이 아닌 첫 번째 단계로 다루는 플랫폼에서 가장 흥미로운 점은, 이들이 더 나은 문서(documentation)를 만들어낸다는 것이 아닙니다. 바로 아키텍처에 대한 질문을 회피할 수 없도록 표면 위로 끌어올린다는 점입니다.

예를 들어, 8080.ai는 모든 프로젝트를 계획 단계부터 시작합니다. 이 단계에서 에이전트(agents)는 구현 코드(implementation code)가 생성되기 전에 서비스 경계(service boundaries), 데이터 모델(data models), API 계약(API contracts)을 포함한 전체 아키텍처 명세(architectural specification)를 생성합니다. 그 의도는 구축되는 것이 암묵적인 가설(implicit set of assumptions) 세트가 아니라, 항상 명시적이고 검토 가능한 기반(explicit, reviewable foundation)을 바탕으로 구축되도록 하는 것입니다. 요구사항이 변경될 때, 수정할 수 있는 명확한 시작점이 존재하게 됩니다.

이것은 시니어 엔지니어들이 항상 알고 있었던 새로운 원칙은 아닙니다. 아키텍처를 우선시하는 것이 더 적응력 있는 시스템(adaptable systems)으로 이어진다는 사실은 이미 알려져 있었습니다. 새로운 점은, 제품 출시(ship)에 대한 압박으로 인해 그러한 규율을 강제하기 어려운 환경에서, 이것이 수동으로 부과해야 하는 규율이 아니라 개발 도구(development tooling)의 기본 동작(default behavior)이 되고 있다는 사실입니다.

초기 시스템을 어떻게 구축할지 평가하는 팀들에게 이러한 변화는 매우 중요합니다. 질문은 더 이상 순수하게 "작동하는 무언가를 얼마나 빨리 출시할 수 있는가?"가 아닙니다. "작동하면서도 1년 뒤에 의미 있게 변경할 수 있는 무언가를 얼마나 빨리 출시할 수 있는가?"가 되었습니다.

초기 스타트업은 속도보다 아키텍처를 선택해야 하는가?

"아키텍처 대 속도(architecture versus speed)"라는 프레임워크는 오랫동안 이 논의를 어렵게 만든 요소 중 하나입니다. 역사적으로 이 둘은 트레이드오프(trade-off) 관계로 제시되어 왔으며, 많은 초기 팀들에게 실제로 그러했습니다.

2025년과 그 이후를 위한 더 정확한 프레임워크는 다음과 같습니다: 초기에 내려진 아키텍처 결정이 그 이후에 내려지는 모든 결정의 속도를 결정한다는 것입니다. 잘 구조화된 시스템은 시간이 지남에 따라 속도(velocity)를 축적합니다. 취약한(brittle) 시스템은 속도를 잃습니다. 문제는 아키텍처에 투자할 것인가가 아니라, 그 투자가 언제 결실을 맺는지, 그리고 그 대안(alternative)이 얼마나 많은 비용을 치르게 하는가입니다.

에이전트형 AI (agentic AI) 도구를 사용하여 구축하는 팀들에게 초기 비용은 낮아지고 있습니다. 반면, 이를 수행하지 않았을 때 발생하는 복리적 비용 (compounding cost)은 높아지고 있습니다. 이것이 바로 한 팀씩 심리적 변화를 일으키고 있는 수학적 계산의 변화입니다.