AI가 앱을 생성할 수 있다면, 앱 빌더(app builder)가 도대체 왜 필요할까요? 여기 한 업계 내부자의 솔직한 답변이 있습니다. AI는 백지 상태(blank page)에서는 매우 뛰어나지만, 2년 차 단계에서는 쓸모가 없습니다. 데모에서 생략되는 모든 것을 담고 있는 프레임워크 (framework) 내부에 자리 잡지 않는 한 말이죠.

이 질문에는 정직한 답변이 필요합니다

이 질문은 어리석은 것이 아닙니다. 외부에서 보기에는 논리가 완벽해 보입니다. 프레임워크와 앱 빌더가 존재했던 이유는 소프트웨어를 작성하는 것이 느리고 희귀한 기술을 필요로 했기 때문입니다. 이제 AI는 문장 하나로 몇 초 만에 소프트웨어를 작성합니다. 따라서 중간 계층은 불필요한 짐이 됩니다. 저처럼 앱 빌더 소프트웨어를 만드는 일을 직업으로 삼고 있다면, 지난 2년 동안 매주 이런 이야기를 들어왔을 것입니다. 때로는 질문으로, 때로는 조사(eulogy)의 형태로 말이죠.

질문하는 사람들이 목격한 바가 틀린 것은 아닙니다. 모델은 과거에 한 스프린트(sprint)가 걸렸던 작업을 30초 만에 만들어냅니다. 그 사실을 과소평가하며 시작하는 그 어떤 답변도 무시될 것이며, 마땅히 그래야 합니다. 그러니 반대편 끝에서부터 시작해 봅시다.

AI가 탁월하게 해내는 것

AI는 백지 상태의 문제를 해결했습니다. 아이디어 구상(Ideation), 초안 작성, 스캐폴딩 (scaffolding), 보일러플레이트 (boilerplate): 아무것도 없는 상태에서 무언가를 만들어내는 빌딩의 전체 단계가 며칠에서 몇 분으로 단축되었으며, 그 결과물은 종종 훌륭합니다. 하나의 흐름(flow)에 대해 다섯 가지 변형을 탐색하는 것은 과거에는 예산의 문제였습니다. 이제는 커피 한 잔 마시는 시간 정도의 일입니다. 모든 프로젝트의 중간을 채웠던 지루한 전사(transcription) 작업, 즉 어렵지도 않고 흥미롭지도 않은 코드는 바로 이러한 모델들이 가장 잘 만들어내는 결과물입니다.

저는 이 양보를 전략적인 차원이 아니라 온전한 진심으로 하고 있습니다. 이것은 실제적이고 영구적인 이득이며, 우리 산업의 비용이 가장 비효율적이었던 지점에 정확히 도달했습니다. 누구의 직업적 자부심도 보일러플레이트를 직접 타이핑하는 데 투자되어서는 안 됩니다.

하지만 이 이득이 어디에 도달하는지 보십시오. 바로 시작 단계입니다. 제가 방금 나열한 모든 것은 프로젝트 생애 주기의 첫 주에 일어나는 일들입니다.

여전히 프레임워크가 필요한 이유

이제 시간을 앞으로 돌려봅시다. 생성된 앱이 작동하고, 출시되고, 시간이 흐릅니다. 그리고 바로 그 '시간'이야말로 데모의 가설들이 무너지는 지점입니다.

지속되는 소프트웨어는 성장함에 따라 일관성을 유지하는 아키텍처 (Architecture)가 필요합니다. 30번째 화면은 3번째 화면과 동일한 컨벤션 (Conventions)을 따라야 하며, 그렇지 않으면 모든 변경 사항이 고고학적 발굴 작업이 되어버립니다. 실제 기기에서, 실제 데이터 볼륨을 가지고, 실제 OS 업데이트 환경 하에서, 앱 스토어와 사용자가 실제로 요구하는 수준의 출력 품질을 유지해야 합니다. 또한 유지보수 (Maintenance)가 하나의 프로세스로 작동해야 합니다. 즉, 누군가가 요청받지 않더라도 수년간 Deprecations (지원 중단), API 변경, 보안 패치 등을 모니터링해야 합니다. 그리고 시각적·기능적 일관성이 필요하며, 이는 특정 세대의 속성이 아니라 제품 전체의 속성이어야 합니다.

참고로, 이러한 유지보수 부담은 추상적인 개념이 아닙니다. 여기에는 정해진 일정이 있습니다. Apple: 2026년 4월 28일부터 모든 제출 또는 업데이트는 최래 SDK로 빌드되어야 하며, 이 기준은 매년 높아집니다. Google Play: 앱은 출시된 지 1년 미만인 Android API 레벨을 타겟팅 (Target)해야 하며, 그렇지 않으면 업데이트가 차단되고, 2년이 지나면 앱이 새로운 사용자에게 노출되지 않습니다. Meta는 대략 분기마다 새로운 Graph API 버전을 출시하고 2년 후에 각 버전을 은퇴 (Retire)시키며, 그 시점이 되면 호출은 단순히 에러를 반환합니다. 자체적인 사이클을 가진 결제, 광고, 분석 SDK들을 더해보면, 업계의 표준 추정치에 도달하게 됩니다: 앱을 유지보수하는 데는 매년 초기 개발 예산의 15~20%가 소요됩니다. 이 중 어떤 작업도 데모에는 나타나지 않습니다. 하지만 이 모든 것은 필수적입니다.

생성(Generation)은 하나의 이벤트입니다. 앞서 언급한 네 가지는 프로세스(processes)입니다. 모델이 아무리 유능하더라도, 시간 T에 실행되고 다음으로 넘어갑니다. 이것이 프레임워크에 관한 질문이 놓치고 있는 비대칭성입니다. AI는 백지 상태에서는 매우 뛰어나지만, 2년 차에는 쓸모가 없습니다. 이는 AI가 코드를 잘못 작성하기 때문이 아닙니다. 2년 차의 문제는 코드 작성의 문제가 아니라, 소유권(ownership)의 문제이기 때문입니다. 그리고 프레임워크는 구조적으로 계속 남아 있는 것입니다. 인코딩된 의견(Opinions encoded), 강제된 불변성(invariants enforced), 그리고 모든 앱에 걸쳐 분할 상환되는 엔지니어링 팀이 그 안에 있습니다.

참고로, 저만 이런 결론에 도달한 것은 아닙니다. 코드-프레임워크 측면에서, Ayobami Ogundiran은 AI가 프레임워크를 덜 중요하게 만든 것이 아니라 오히려 더 중요하게 만들었다고 주장했습니다. 에이전트 상태(agent state), 비동기 UI(asynchronous UIs), 브라우저 네이티브 에이전트(browser-native agents)는 정확히 새로운 추상화(abstractions)를 요구하는 새로운 문제들이기 때문입니다. 그의 주장은 AI가 추가하는 새로운 문제들에 관한 것입니다. 저의 주장은 시간이 모든 앱에 미치는 영향에 관한 것입니다. 이 두 가지는 같은 방향을 가리킵니다. 생성 비용이 저렴해진다고 해서 구조를 담고 있는 계층의 가치가 떨어지지는 않습니다.

따라서 이 파도 한가운데에서 앱 플랫폼을 구축하며 우리가 내린 결론은 거의 기하급수적이었습니다. AI를 프레임워크 대신 사용하지 마세요. 프레임워크 안에 넣으세요.

프레임워크에 내장된 AI

"안에 넣는다"는 것은 각 AI 기능이 플랫폼의 보장(guarantees)을 우회하는 대신, 플랫폼의 보장 체계에 연결됨을 의미합니다. 가장 명확한 예시는 우리가 가장 멀리 밀어붙인 결과물인 AI 확장 빌더(AI Extension Builder)입니다. 고객이 자연어(natural language)로 커스텀 섹션을 설명하면, 어시스턴트가 코드를 생성하고 이를 실시간으로 렌더링하며, 결과물은 플랫폼 자체의 API인 지리 위치(geolocation), 콘텐츠, 푸시(push), 커머스 데이터 등에 연결됩니다. 계속해서 프롬프트를 입력하거나, 코드를 열어 직접 편집할 수도 있습니다.

이제 그 경제적 측면을 살펴보겠습니다. 이는 제가 다른 곳에서도 주장하는 자유의 실제 비용에 대한 산술적 논리와 동일하기 때문입니다. 당신이 어떤 앱을 만들든, 그 대부분은 이미 정형화된 형태(formalized form)로 존재합니다: 리스트, 계정, 검색, 푸시(push), 결제 등입니다. 이러한 기능들은 수년간의 프로덕션(production) 환경을 통해 연구되고, 최적화되었으며, 디버깅(debugged)되었습니다. 모델에게 이를 다시 생성하라고 요구하는 것은, 이미 느리게 해결되었던 문제들을 빠르게 재창조하라고 요구하는 것과 같습니다. 따라서 역할 분담은 자연스럽게 이루어집니다. 플랫폼은 당신에게 특화되지 않은 90%를 담당합니다. AI는 전용 섹션에서 그 누구의 로드맵도 예측할 수 없었던, 진정으로 당신만의 부분인 나머지 10%를 구축합니다.

헬스장 앱을 예로 들어보겠습니다. 수업 일정, 멤버십, 푸시 알림, 코치의 콘텐츠, 결제: 이 모든 것은 수년 전에 연구되고 디버깅된 상태로 플랫폼과 함께 제공됩니다. 플랫폼이 제공하지 않는 것은 이 특정 헬스장의 핵심이 되는 기능, 예를 들어 안내 데스크 직원이 업데이트하고 공간이 비면 푸시를 보내주는 실시간 혼잡도 측정기 같은 것입니다. 그 어떤 백로그(backlog)에도 그런 내용은 포함되어 있지 않습니다. 소유자가 이를 설명하면, AI가 이를 구축하고, 해당 섹션은 앱의 다른 모든 기능과 동일한 푸시 및 멤버 API를 호출합니다. 생성(Generation)은 오직 다른 누구도 출시할 수 없었던 무언가를 만들어낼 수 있는 곳에만 정확히 사용되며, 그 외의 곳에는 사용되지 않습니다.

그리고 생성된 섹션은 프레임워크(frame) 내부에 존재하기 때문에, 프레임워크가 보장하는 모든 것을 상속받습니다. 호스팅(hosting), 디자인 시스템(design system), 배포 경로(deployment path), API 표면(API surface) 등이 그것입니다. 이것이 바로 독립형 생성기(standalone generator)가 당신에게 남겨주지 않는 소유권 계층(ownership layer)입니다. 또한 이는 리스크를 제한합니다. 만약 당신의 커스텀 섹션이 잘못된 아이디어로 판명되더라도, 그 영향 범위(blast radius)는 앱 전체가 아닌 단 하나의 섹션에 국한됩니다. 프레임워크는 단순히 AI 출력물을 더 안전하게 만드는 것에 그치지 않습니다. 틀렸을 때의 비용을 저렴하게 만들어주며, 저렴하게 틀릴 수 있다는 점이야말로 실험을 가능하게 하는 전제 조건입니다.

고객이 플랫폼에 없는 기능이 필요할 때, 과거의 답변은 "로드맵을 기다려 주세요"였습니다. 하지만 이제는 그렇지 않습니다. 그렇다고 해서 "여기 생(raw) 코드 생성기가 있으니 행운을 빕니다"라고 말하는 것도 아닙니다. 해당 기능의 탄생 과정은 그 자체로 하나의 이야기이며, 제 동료 Dumè가 그 이야기를 들려줍니다. (동일한 배선 구조가 저희 백오피스의 더 작은 어시스턴트들에도 흐르고 있습니다. 출력값이 디자인 시스템의 시맨틱 컬러 역할(semantic color roles)에 반영되는 팔레트 생성기나, 출력값이 콘텐츠 모델(content model)에 반영되는 초안 작성 도구 등이 그 예입니다. Extension Builder는 이 패턴을 가장 쉽게 확인할 수 있는 곳일 뿐입니다.)

제 동료 Muriel은 사용자 측면에서 "AI가 앱 빌더를 죽일 것인가"[//murielsantoni.substack.com/p/will-ai-kill-no-code-app-builders]라는 공개적인 질문을 다룹니다. "AI가 프레임워크를 죽였다"는 시대가 시작된 지 2년이 지난 지금, 우리의 결론은 추도사와는 정반대입니다. 생성(Generation) 비용은 저렴해졌습니다. 따라서 생성 기술이 수행하지 못하는 모든 것들, 즉 아키텍처(architecture), 보장(guarantees), 유지보수(maintenance), 일관성(coherence)은 상대적으로 더 가치 있어졌습니다. 프레임워크는 우리가 참아내야 했던 느린 부분이 아니었습니다. 그것은 끝까지 남아있는 부분입니다.

Mathieu Poli — GoodBarber의 프론트엔드 엔지니어링 책임자(Head of Frontend Engineering). 저는 프론트엔드 엔지니어링, 제품 디자인, 그리고 AI, 그리고 이 세 가지가 만날 때 발생하는 모든 것에 대해 가르치고 글을 씁니다. · X: @hellomathieup