초기 단계의 아키텍처는 자신의 성공에 거는 도박입니다. 과도하게 설계(Over-engineer)하면 아직 존재하지도 않는 문제를 해결하기 위해 없는 돈을 쓰게 됩니다. 반대로 설계가 부족하면(Under-engineer), 트랙션(Traction)이 발생하는 바로 그 시점에, 즉 멈춰서 재구축할 여력이 가장 없을 때 벽에 부딪히게 됩니다.

비결은 "백만 명의 사용자를 위해 구축하라"가 아닙니다. 되돌리기 치명적인 특정 결정들 — 즉, 일방통행 문(one-way doors) — 을 식별하고, 다른 모든 곳에서는 기민함(scrappy)을 유지하면서 그 부분에만 주의를 기울이는 것입니다. 이 포스트는 언어 모델(Language Model)이 요청 경로(request path)에 위치하는 AI 네이티브 MVP의 맥락에서, 이 두 가지를 구분하는 방법에 대해 다룹니다.

mvp architecture

멘탈 모델: 양방향 문(two-way doors) vs 일방통행 문(one-way doors)

대부분의 결정은 양방향 문(two-way doors)입니다. UI 프레임워크, 호스팅 제공업체, 백그라운드 작업 시스템(background-job system), CSS 접근 방식 등은 적절한 것을 선택하고 넘어가십시오. 나중에 교체하는 것이 번거롭기는 하겠지만, 그 범위가 제한적이기 때문입니다. 이러한 것들에 대해 괴로워하는 것은 일종의 미루기(procrastination)입니다.

일방통행 문(One-way doors)은 다릅니다. 지금 결정하기에는 비용이 적게 들지만, 일단 프로덕션 데이터와 사용자가 생기고 나면 변경하기가 매우 고통스럽습니다. 다행히도 이런 결정은 몇 가지 되지 않습니다. 즉, 짧은 목록에 대해 깊이 고민할 여유가 있다는 뜻입니다.

일방통행 문 #1: 데이터 모델(data model)

실제 데이터가 흐르기 시작하면 이를 변경하는 것이 가장 어려운 작업입니다. 고객이 있는 라이브 시스템에서의 마이그레이션(Migrations)은 느리고 위험하며, 때로는 감당할 수 없는 다운타임(downtime) 없이 수행하는 것이 불가능할 수도 있습니다. AI 네이티브 제품의 경우, 데이터 모델은 어떤 컨텍스트(context)를 검색할 수 있는지, 그리고 모델에 얼마나 깔끔하게 데이터를 공급할 수 있는지를 결정하기 때문에 더 큰 비중을 차지합니다. 여기서 추가적인 시간을 투자하십시오. 매달 보상으로 돌아올 것입니다.

일방통행 문 #2: 인증(auth) 및 멀티 테넌시(multi-tenancy)

인증 (Authentication), 인가 (authorization), 그리고 테넌트 격리 (tenant isolation)는 하위의 모든 것을 결정짓습니다. 특히 B2B의 경우 더욱 그렇습니다. 단일한 평면적 사용자 공간 (single flat user space)을 가정하고 만든 앱에 실제 권한 모델을 사후에 적용하는 것은 패치가 아니라 재작성 (rewrite)에 가깝습니다. 그리고 바로 이 지점이 AI 보조 코딩 (AI-assisted coding)이 당신을 위험에 빠뜨리는 영역입니다. 모델은 몇 초 만에 그럴싸해 보이는 권한 계층을 생성해 내겠지만, "그럴싸해 보이는 것"과 "테넌트 간 데이터 유출이 없는 것"은 매우 다른 보증입니다. 생성하고 싶다면 생성하되, 검증은 인간의 몫입니다.

일방통행 문 #3: 코어와 AI 사이의 경계 (the seam between core and AI)

사람들이 놓치는 부분이 바로 여기입니다. 당신의 결정론적 코어 (deterministic core) (계정, 데이터, 워크플로우, 결제 — 매번 반드시 정확해야 함)와 지능형 계층 (intelligent layer) (요약, 추출, 추천, 에이전트) 사이에 깨끗한 경계를 유지하십시오. 만약 그 경계가 깨끗하다면, 앱의 나머지 부분을 건드리지 않고도 모델을 교체하거나, 캐싱 계층 (caching layer)을 추가하거나, 제공업체를 변경하거나, 추론 (inference)을 핫 패스 (hot path)에서 분리할 수 있습니다. 만약 이 경계가 코드베이스 전체에 뒤섞여 있다면, 이 모든 작업은 수술과 같은 고통스러운 작업이 될 것입니다.

구체적으로 말하면, 이는 AI 계층이 잘 정의된 인터페이스 (interfaces)를 통해 코어와 통신하고, 그 출력값이 중요한 요소에 닿기 전에 검증되어야 하며, 앱이 무너지지 않고도 특정 기능을 끌 수 있어야 함을 의미합니다. 모델 호출을 신뢰할 수 없고, 지연 시간 (latency)이 가변적이며, 때때로 틀릴 수 있는 다른 외부 의존성 (external dependency)과 동일하게 취급하십시오. 왜냐하면 실제로 그러하기 때문입니다.

AI 계층이 초기에 규율을 강제하는 이유

LLM 기반 기능의 몇 가지 특성 때문에, 느슨한 아키텍처는 비용이 많이 들게 됩니다:

• 지연 시간(Latency)은 가변적이며 종종 높습니다. 동기식 경로(synchronous path)에 있는 모델은 전체 UX 예산을 변화시킵니다. 무엇이 동기식(sync)이고 무엇이 비동기식(async)인지 초기에 결정하십시오.
• 추론(Inference)은 호출당 발생하는 가변 비용입니다. 한 번 프로비저닝하면 끝나는 서버와 달리, 이는 사용량에 따라 확장됩니다. 만약 사용자 동작 하나당 수십 번의 호출을 발생시키는 디자인을 택한다면, 마진(margin) 문제를 야기하게 됩니다.
• 출력값은 확률적(probabilistic)입니다. 평가(evaluation)와 가드레일(guardrails)을 사후 고려 사항이 아닌 시스템의 일급 시민(first-class parts)으로 포함해야 합니다. 그렇지 않으면 데모에서는 한 시간 만에 작동하던 기능이 프로덕션 환경에서 안전하게 작동하기까지 몇 주가 걸릴 수 있습니다.

이것이 MVP를 지나치게 화려하게(gold-plate) 만들라는 뜻은 아닙니다. AI 통합의 '형태(shape)'는 일방통행 문(one-way-ish door)에 가깝다는 의미이므로, UI를 구축하기 전에 의도적으로 설계도를 그려보라는 뜻입니다.

어려운 부분부터 리스크를 제거하십시오

가장 저렴한 코드는 첫 주에 계획이 잘못되었음을 증명함으로써 아예 작성하지 않아도 되는 코드입니다. AI 네이티브 제품의 경우, 제품을 구축하기 전에 다음의 두려운 질문에 답할 수 있는 짧은 스파이크(spike)를 실행하십시오: 검색(retrieval)이 실제 데이터에서 좋은 답변을 반환하는가? 에이전트(agent)가 핵심 작업을 안정적으로 완료할 수 있는가? 첫 주에 어려운 부분을 발견하는 것은 축복입니다. 4개월 차에 발견하는 것은 위기입니다.

전체 글

이것은 아키텍처에 관한 내용입니다. 비용, 타임라인, 플랫폼 선택, 직접 구축 vs 구매 vs 미세 조정(fine-tune), 인력 구성, 그리고 성공 지표를 포함한 창업자를 위한 완전한 가이드는 여기에 있습니다:

→ 2026년 스타트업 앱 개발: 창업자를 위한 AI 네이티브 플레이북

저희는 또한 창업자들을 위해 이러한 시스템을 구축합니다. 귀하의 아키텍처에 대해 제2의 시각이 필요하다면 문의해 주세요.

자주 묻는 질문 (FAQ)

소프트웨어 아키텍처에서 "일방통행 문(one-way door)" 결정이란 무엇인가요?
나중에 큰 고통 없이 변경할 수 있는 '양방향 문(two-way doors)'과 대조적으로, 지금 결정하기에는 저렴하지만 프로덕션 데이터와 사용자가 확보된 이후에는 되돌리기에 비용이 많이 들거나 불가능한 결정을 의미합니다.

왜 데이터 모델은 나중에 변경하기가 그토록 어려운가요?
실제 고객 데이터가 있는 라이브 시스템에서의 마이그레이션 (Migration)은 느리고 위험하며, 때로는 감당할 수 없는 다운타임 (Downtime)을 요구합니다. AI 제품의 경우, 데이터 모델은 검색할 수 있는 컨텍스트 (Context)를 결정하기도 하므로 실수가 누적되어 큰 영향을 미칩니다.

내 앱과 AI 레이어 사이의 경계를 어떻게 구조화해야 하나요?
지능형 레이어 (Intelligent layer)가 잘 정의된 인터페이스 (Interface)를 통해 결정론적 코어 (Deterministic core)와 통신하도록 하고, 모델 출력값이 중요한 요소에 영향을 미치기 전에 검증하며, 모든 AI 기능을 독립적으로 토글 (Toggle)할 수 있게 만드세요. 모델 호출은 신뢰할 수 없고 지연 시간 (Latency)이 가변적인 외부 의존성 (External dependency)으로 취급해야 합니다.

AI 기능은 동기적 (Synchronously)으로 실행해야 하나요, 아니면 비동기적 (Asynchronously)으로 실행해야 하나요?
UX 예산에 따라 조기에 결정하세요. 모델의 지연 시간은 가변적이고 종종 높기 때문에, 많은 AI 기능은 핵심 상호작용을 차단하기보다는 로딩 상태나 점진적 공개 (Progressive-reveal) 상태를 활용하여 비동기적으로 실행하는 것이 더 좋습니다.

AI가 내 권한 시스템 (Permissions system)을 생성하게 그냥 두어도 될까요?
초안을 생성할 수는 있지만, 반드시 직접 검증해야 합니다. "그럴듯해 보인다"와 "테넌트 (Tenant) 간에 데이터를 유출하지 않는다"는 서로 다른 보증이며, 오직 인간의 검토만이 그 간극을 메울 수 있습니다.

MVP에서 과도하게 설계 (Over-engineer)하지 말아야 할 것은 무엇인가요?
양방향 문 (Two-way doors): UI 프레임워크 (UI framework), 호스팅 (Hosting), 작업 큐 (Job queue), 스타일링 방식 (Styling approach). 합리적인 것을 선택하고 다음 단계로 넘어가세요. 이것들은 나중에 변경하는 비용이 저렴합니다.