8개의 앱을 동시에 개발하는 방법: 정신적 한계를 극복하는 아키텍처

저는 8개의 앱을 동시에 구축하고 있습니다. 단순한 주말 사이드 프로젝트가 아니라, 실제 포트폴리오에 포함될 프로덕션 제품들입니다. 이것이 악몽이 되지 않도록 유지해 주는 아키텍처를 소개합니다.

아무도 말하지 않는 문제

인디 개발자와 소규모 팀은 대기업과는 다른 확장성 (Scaling) 문제를 겪습니다. 대기업은 인력을 추가함으로써 확장하지만, 1인 개발자는 제품을 추가함으로써 확장합니다. 하지만 새로운 앱이 추가될 때마다 다음과 같은 것들이 따라옵니다:

• 새로운 인증 (Auth) 흐름
• 새로운 결제 (Billing) 연동
• 새로운 배포 파이프라인 (Deployment pipeline)
• 새로운 분석 (Analytics) 설정
• 새로운 모니터링 (Monitoring) 구성
• 새로운 도메인 + SSL
• 새벽 3시에 발생하는 새로운 버그 리포트

5번째 앱쯤 되면, 당신은 제품을 만드는 것이 아니라 인프라를 유지보수하고 있게 됩니다.

해결책: 공유 인프라 계층 (Shared Infrastructure Layer)

8개의 별도 모놀리스 (Monolith)를 만드는 대신, 모든 앱이 상속받는 공유 기반을 구축했습니다.

1. 통합 인증 (Unified Auth - NextAuth.js)

모든 앱은 동일한 인증 제공자, 동일한 세션 관리, 동일한 사용자 테이블 구조를 사용합니다.

// apps/app-a/auth/[...nextauth]/route.ts
import { baseAuthConfig } from "@shared/auth";

export const authOptions = {
  ...baseAuthConfig,
  providers: [
    /* app-specific providers */
  ],
};

세션 로직을 한 번만 변경하면 모든 곳에 전파됩니다. "앱 3에서는 수정했는데 앱 7에서는 잊어버렸다"는 상황은 더 이상 발생하지 않습니다.

2. 공유 결제 계층 (Shared Billing Layer)

Stripe나 Lemon Squeezy를 8번 연동하는 대신:

• 하나의 @shared/billing 패키지가 체크아웃, 웹훅 (Webhook), 구독 관리를 처리합니다.
• 각 앱은 자신의 플랜 등급과 가격만 지정하면 됩니다.
• 웹훅 라우팅이 중앙 집중화되어 하나의 엔드포인트가 모든 앱을 처리합니다.
• 결과: 결제 로직을 업데이트해야 할 때, 8개가 아닌 단 하나의 코드베이스만 수정하면 됩니다.

3. Turborepo를 이용한 모노레포 (Monorepo with Turborepo)

poria/
├── packages/
│   ├── @shared/ui       # 컴포넌트 라이브러리 (Component library)
│   ├── @shared/auth    # 인증 설정 (Auth configuration)
│   ├── @shared/billing # 결제 처리 (Payment handling)
│   ├── @shared/analytics # 트래킹 및 이벤트 (Tracking & events)
│   └── @shared/db      # 데이터베이스 스키마 및 Prisma 클라이언트 (Database schemas & Prisma client)
├── apps/
│   ├── app-a/          # 제품 A (Next.js)
│   ├── app-b/          # 제품 B (Next.js)
│   └── ...             # 나머지 6개
└── turbo.json

Turborepo는 앱 전반에 걸쳐 빌드를 캐싱합니다. @shared/ui를 변경하면 영향을 받는 앱만 다시 빌드됩니다.

4.

통합 배포 파이프라인 (Unified Deployment Pipeline)
모든 앱은 동일한 설정 패턴으로 Vercel에 배포됩니다: { "buildCommand" : "turbo run build --filter=app-a..." , "env" : { "SHARED_*" : "from monorepo root" } }. 단 하나의 CI/CD 워크플로우가 8개의 앱 전체를 처리합니다. 하나가 실패하더라도 나머지 앱들은 여전히 배포됩니다.

5.

중앙 집중식 관측성 (Centralized Observability)
8개의 Sentry 프로젝트와 8개의 분석 (Analytics) 대시보드 대신:

• 하나의 Sentry 조직(org), 앱당 하나의 프로젝트 (앱 간 쿼리를 위한 태그 활용)
• 앱 수준의 세분화 (segmentation)가 가능한 하나의 분석 워크스페이스
• 모든 이벤트에 앱 식별자 (app identifier)가 포함된 하나의 로깅 파이프라인
  무언가 고장 나면, 어떤 앱인지, 어떤 버전인지, 그리고 앱 간에 연관성이 있는지 즉시 확인할 수 있습니다.

이 방식의 실제 비용

• 설정 시간: 공유 레이어 구축에 약 40시간 소요
• 앱당 한계 비용 (marginal cost): 2030시간 대신 약 48시간 소요
  이것이 계산법입니다. 첫 번째 앱을 만드는 데 가장 오래 걸립니다. 이후 각 앱은 인증 (auth), 결제 (billing), 또는 배포를 다시 발명할 필요가 없기 때문에 점점 더 빨라집니다.

뼈아픈 교훈들

• 초기에 과도하게 추상화하지 마세요. 공유 레이어로 추출하기 전에 패턴이 2~3번 반복될 때까지 기다리세요.
• 공유 패키지의 버전을 관리하세요. 공유 코드의 파괴적 변경 (breaking changes)은 8개의 앱을 한꺼번에 무너뜨릴 수 있습니다.
• 앱별 로직은 앱에만 머물게 하세요. 공유 패키지는 인프라를 위한 것이지, 비즈니스 로직을 위한 것이 아닙니다.
• 모든 것을 문서화하세요. 미래의 당신 (새벽 2시에 6번째 앱을 디버깅하고 있는 당신)이 현재의 당신에게 감사할 것입니다.

결과
이 시스템을 구축한 후:

• 새로운 앱 프로토타입: 2주 대신 2일 소요
• 공유 코드의 버그 수정: 한 번 수정하면 모든 곳에 배포됨
• 온보딩: 어떤 새로운 앱이든 첫날부터 인증, 결제, 분석 기능을 상속받음
• 정신적 부하 (Mental load): 8개의 별개 시스템 대신, 1개의 시스템 + 8개의 프론트엔드

핵심 요약 (Takeaway)
1인 개발자나 소규모 팀으로서 여러 제품을 만들고 있다면, 각 앱을 완전히 새로운 프로젝트 (greenfield project)로 취급하는 것을 멈추세요. 공유 인프라 레이어는 당신의 생산성을 배가시키는 힘 (force multiplier)입니다. 초기에 투자하되, 과도하게 설계 (over-engineer)하지는 마세요. 실제 반복을 통해 패턴이 나타나게 한 다음, 그때 추출하세요. 8개의 제품을 관리하게 될 미래의 당신이 당신에게 감사할 것입니다.

Codcompass에서 공개적으로 빌드 중 — 개발자 지식 베이스.

규모 있는 제품을 구축하는 방법에 대한 더 심도 있는 기술적 분석을 계속 확인해 보세요.