진입장벽이 사라진 세계에서 생기는 진짜 문제
최근 dev.to에 흥미로운 글이 올라왔다. Google AI Studio를 이용해 Kotlin을 단 한 줄도 쓰지 않고 오후 한 나절 만에 네이티브 Android 앱을 완성했다는 사례다. 5분 만에 작동하는 프로토타입이 손에 들어왔다고 한다. 충격적이지 않다. 오히려 이미 예고된 일이 도착했다는 느낌이다.
이 이야기가 흥미로운 건 속도 자체가 아니다. '익숙하지 않은 도메인'에서 AI가 진입장벽을 실질적으로 해체하고 있다는 사실이다. Kotlin을 모르는 프론트엔드 개발자, 앱 개발 경험이 없는 기획자, 아이디어만 있는 1인 창업자—이들이 이제 '일단 만들어볼 수 있는' 시대가 됐다. 빠른 프로토타이핑은 더 이상 숙련된 개발자의 특권이 아니다.
하지만 여기서 멈추면 절반짜리 이야기다. AI가 만들어준 첫 번째 프로토타입이 작동한다는 것과, 그것이 지속 가능한 제품으로 성장할 수 있다는 건 전혀 다른 문제다. 속도로 얻은 것을 구조로 지켜야 한다는 과제가 곧바로 뒤따른다.
구조의 비용을 미루면 생기는 일
같은 날 눈에 띈 또 다른 글이 이 문제를 정확히 보여준다. dev.to에 공개된 TanStack Router 모노레포 사례다. 팀은 화이트라벨 어드민 패널을 여러 고객사에 납품하면서 오랫동안 git clone 방식으로 버텼다. 새 고객이 생길 때마다 전체 코드베이스를 포크했고, 열 개의 포크가 쌓이자 권한 시스템 버그 하나를 고치는 데 열 번의 수작업 포팅이 필요해졌다. 구조를 미룬 대가를 정확히 치른 것이다.
이 팀이 선택한 해법은 pnpm 모노레포로의 전환이었다. 공유 가능한 코어(@bo/core)를 별도 패키지로 분리하고, 각 고객사 앱은 얇은 껍데기(thin shell)만 갖도록 설계했다. 핵심 규칙은 단순하다: 라우트 트리만 빼고 전부 공유한다. 페이지 컴포넌트, 가드, 검색 파라미터 유효성 검사기는 코어에서 가져오지만, routeTree.gen.ts는 각 앱이 직접 소유한다.
왜 라우트 트리는 공유하지 않는가. TanStack Router는 프로젝트당 하나의 라우트 트리를 자동 생성하는 구조인데, 이 생성된 트리는 패키지 경계를 넘지 못한다. 팀은 가상 파일 라우트, 라우트 설정 스텁 등 세 가지 공유 방식을 검토하고 모두 폐기했다. 실제로 구현해보고 나서 되돌린 방식도 있다. 결론은 역설적이다: 공유할 수 없는 단 하나를 인정하고 나머지를 철저히 공유하는 게 가장 현실적인 아키텍처였다.
두 사례가 함께 가리키는 것
표면적으로 두 이야기는 달라 보인다. 하나는 AI로 처음 만드는 이야기, 다른 하나는 팀이 수년간 쌓인 부채를 구조로 해결하는 이야기다. 하지만 이 둘은 동일한 패턴의 서로 다른 단계를 보여주고 있다.
현대 프론트엔드 개발의 리듬은 이렇게 흘러간다: AI로 빠르게 가능성을 검증한다 → 작동하는 것을 확인한다 → 구조를 설계해 지속 가능하게 만든다. 이 세 단계를 분리해서 인식하지 않으면, 첫 번째 단계의 흥분이 세 번째 단계의 비용을 가린다.
AI가 Kotlin 없이 Android 앱을 만들어줄 때, 그 코드는 작동하지만 구조는 없다. 마치 10개의 포크 코드베이스처럼, 당장은 편하지만 시간이 지날수록 유지보수 비용이 기하급수적으로 쌓인다. 반대로 처음부터 완벽한 구조를 설계하려는 시도는 검증되지 않은 가설 위에 아키텍처를 짓는 것과 같다. 빠른 프로토타입이 없으면 무엇을 구조화해야 하는지조차 모른다.
실무에서 이 균형을 잡는 법
두 사례에서 추출할 수 있는 실용적 원칙은 세 가지다.
첫째, AI 프로토타입은 '가능성의 증명'으로만 쓴다. Kotlin 없이 만든 앱이 작동한다는 사실은 아이디어 검증에 충분하다. 그 코드를 그대로 프로덕션으로 끌고 가려는 유혹을 이겨내야 한다. 프로토타입 코드와 프로덕션 코드 사이에는 의도적인 단절이 있어야 한다.
둘째, 구조 설계는 '공유할 수 없는 것'을 먼저 파악하는 데서 시작한다. TanStack Router 사례의 핵심 인사이트는 라우트 트리가 공유 불가능하다는 제약을 인정하고 나머지를 최대한 공유하는 방향으로 설계했다는 점이다. 제약을 싸우는 대상이 아니라 설계의 출발점으로 삼을 때 현실적인 아키텍처가 나온다.
셋째, thin shell 패턴은 AI 코드에도 적용된다. 각 고객사 앱이 얇은 껍데기만 갖듯, AI가 생성한 코드는 최대한 얇게 유지하고 핵심 로직은 팀이 직접 설계한 구조 안에 두는 게 장기적으로 안전하다.
속도와 구조는 트레이드오프가 아니다
많은 팀이 여전히 '빠르게 만들기'와 '제대로 구조화하기'를 양자택일의 문제로 본다. 하지만 지금 보여주는 패턴은 다르다. AI 도구가 첫 번째 단계의 비용을 극적으로 낮춰줬기 때문에, 오히려 구조 설계에 쓸 수 있는 시간과 에너지가 늘어났다.
문제는 그 시간을 쓰지 않는 데 있다. 프로토타입이 너무 빨리 만들어지면, 그게 곧 프로덕션 코드처럼 느껴지는 착시가 생긴다. AI가 속도를 올려줄수록 구조 설계를 의도적으로 스케줄링하는 팀의 규율이 더 중요해지는 이유다.
앞으로 더 많은 팀이 'AI로 오후에 만든 것'을 어떻게 '수년간 유지 가능한 것'으로 전환하느냐의 문제와 마주칠 것이다. 그 전환의 품질이 결국 팀의 실제 역량을 가른다.