AI가 건설을 저렴하게 만든다. 우리 제품 아키텍처는 여전히 비싸다고 가정한다.
Source: Dev.to
지금 일어나고 있는 이상한 현상 중 하나는 사람들이 AI를 이용해 놀라울 정도로 유용한 소프트웨어를 갑자기 만들 수 있게 되었다는 점이다.
창업자들은 Claude로 내부 도구를 만들고 있다.
PM들은 주말에 워크플로를 프로토타이핑하고 있다.
작은 팀들은 조직이 검토하기도 전에 작동하는 기능을 빠르게 만들어 내고 있다.
그리고 아주 타당한 질문이 떠오른다:
이제 유용한 소프트웨어를 이렇게 빨리 만들 수 있다면, 왜 성숙한 제품 팀은 여전히 느리게 움직이는 걸까?답의 일부는 대형 제품이 고립된 시스템이 아니라는 데 있다.
작은 프로토타입에서는 기능이 스스로 동작하면 충분하지만, 성숙한 제품에서는 기능이 이미 존재하는 모든 것—권한, 워크플로, 통합, 엣지 케이스, 모니터링, 운영 제약—과 안전하게 공존해야 한다.
그리고 가장 중요한 것은, 기능이 개별적으로 동작하는 것만으로는 충분하지 않다는 점이다.
기능들은 서로 함께 동작해야 한다.
그래서 복잡성은 종종 n²에 가깝게 느껴진다.
10개의 기능이 있다면, 10개의 기능만 관리하는 것이 아니라 그들 사이의 상호작용도 관리해야 한다.이것이 성숙한 제품이 느려지는 이유다.
팀이 빌드 방법을 잊어서가 아니라, 새로운 모든 것이 이미 존재하는 모든 것과 안전하게 공존해야 하기 때문이다.
어느 순간, 소프트웨어를 배포하는 일은 기능 자체를 만드는 것보다 살아있는 시스템에 안전하게 통합하는 일이 된다.
나는 AI가 우리를 다른 제품 아키텍처 모델로 이끌고 있는지 궁금했다.
핵심 제품을 대체하는 것이 아니라, 그 주위에 더 안전한 실험 레이어를 추가하는 것이 아니다.
Base44, Lovable 같은 AI 빌더들은 고립된 소프트웨어를 얼마나 빠르게 만들 수 있는지 이미 보여주고 있다.
문제는 성숙한 제품이 고립된 환경이 아니라는 점이다.
그래서 아마도 전체 제품을 바이브 코딩 시스템으로 바꾸는 것이 아니라—
그 속도를 핵심 제품을 불안정하게 만들지 않으면서도 가능하게 하는 더 안전한 모듈 레이어를 만드는 것이 기회일지도 모른다.목표는 AI가 만든 소프트웨어로 전체 시스템을 재구축하는 것이 아니다.
기존 제품 안에서 실험을 위한 더 안전한 경계를 만드는 것이다.
인증, 권한, API, 공유 디자인 프리미티브, 엄격한 운영 경계 등 안정적인 기반을 가진 제품을 상상해 보라.
그 위에 AI를 이용해 독립적으로 개발할 수 있는 가벼운 모듈 “박스”들을 얹는다.
이 박스들은 운영상으로는 격리된 상태를 유지하고, 기존 서비스에 제한된 인터페이스만 사용하며, 대부분 읽기 전용 모드로 동작하고, 자체적인 논리와 저장소를 갖는다.
많은 경우, 각 박스는 작은 엔드‑투‑엔드 제품 표면—자체 UI, 워크플로, 로직, 격리된 데이터 레이어—으로 기능하면서 핵심 제품과는 제어된 인터페이스를 통해 연결된다.
사용자는 반드시 별도의 애플리케이션 사이를 오가는 느낌을 받을 필요는 없다.
실험 레이어가 아래에서 운영상으로 격리돼 있더라도 경험은 여전히 통합된 느낌을 줄 수 있다.
목표는 완벽한 엔지니어링이 아니라 빠른 학습이다.
이 단계에서는 사고방식도 달라질 수 있다.
내부 구현을 완전히 이해하거나 완벽하게 만들 필요는 없고, 입력을 정의하고, 출력을 평가하며, 충분히 현실적인 사례에 대해 테스트해 실제로 가치를 창출하는지 확인하면 된다.
실험이 실제 시나리오에서 일관되게 동작한다면, 그것만으로도 학습을 지속할 충분한 근거가 된다.
실험이 성숙하면, 더 깊은 엔지니어링, 강력한 보증, 핵심 제품과의 tighter integration이 필요한지 결정하면 된다.
PM, 창업자, 작은 팀은 핵심 제품에 큰 위험을 초래하지 않으면서도 워크플로, 내부 도구, AI 경험, 고객 맞춤 기능 등을 빠르게 테스트할 수 있다.실험이 실패하면?
박스를 제거한다.
최소한의 정리.
최소한의 파급 범위.
최소한의 조직적 오버헤드.많은 소프트웨어 조직이 아직도 “구축 비용이 비싸다”는 세계관에 기반한 가정으로 운영되고 있다고 생각한다.
그래서 자연스럽게 장기적인 유지보수성, 확장성, 시스템 품질, 중앙 집중식 제어를 최적화해 왔다.
그리고 이러한 요소들은 여전히 중요하다.
하지만 AI는 실험 비용을 급격히 낮춘다.
이는 병목이 다른 곳—학습 속도, 반복 속도, 조직 유연성, 안전한 실험—으로 이동할 수 있음을 의미한다.
그렇다고 해서 모든 기업이 AI에게 무작위 생산 시스템을 만들게 해서는 안 된다.
여전히 해결해야 할 실제 문제들이 있다: 거버넌스, 보안, 일관성, 유지보수성, 가시성, 아키텍처 스프롤 등.
하지만 나는 많은 팀이 제품 실험 자체가 얼마나 크게 변할지를 과소평가하고 있다고 본다.
모든 아이디어가 즉시 핵심 제품의 일부가 될 필요는 없을지도 모른다.
제품은 아이디어를 핵심 제품에 완전히 통합하기 전에 더 안전하게 탐색할 방법이 필요할 수도 있다.