왜 필요한가

이웃이 요리책을 찾아 저장하고 부가 기능을 구매하는 요리법 앱을 만든다고 가정해 봅시다. 작은 팀 하나가 저장한 책에 가족 태그를 넣으려 합니다. 별도 배포를 조율하면 일이 늘어나므로 기능별 독립 일정보다 함께 배포하는 편을 우선합니다.

어떻게 해결하는가

  1. 한 팀이 카탈로그·보관함·결제를 함께 배포합니다. 저장한 동네 요리책에는 태그가 없습니다.
  2. 보관함에 태그 기능을 추가하고 앱 v2를 배포합니다. 결제 동작은 그대로지만 같은 배포물에 포함됩니다. 공유 데이터베이스는 앱이 소유합니다.
  3. 보관함이 프로세스 내부에서 카탈로그를 조회한 뒤 가족을 기록합니다. 쓰기 전 조회 실패 시 태그 없음 유지, 복구 후 재시도.
여러 기능을 담은 하나의 배포 단위

설명을 위한 가상 예시

하나의 배포물이 함께 이동

요리법 앱 · 한 팀 · 동네 요리책에 가족 태그 없음

변경: 보관함 태그 추가. 결제 동작은 그대로.

배포 단위 · 1

앱 v1 → 앱 v2

서버 애플리케이션 전체 빌드·배포

  1. 카탈로그

    동작 유지

  2. 보관함

    태그 기능 추가

  3. 결제

    동작 유지

보관함 → 카탈로그 · 프로세스 내부 호출

기능 상자는 내부 모듈 구성 여부를 정하지 않습니다.

공유 데이터베이스 · 소유자: 앱

카탈로그 / 보관함 / 결제

카탈로그 조회 성공 후 보관함이 태그 기록.

  1. 조회 성공 → 가족 기록 → 동네 요리책 태그는 가족.
  2. 쓰기 전 조회 실패 → 태그 없음. 실패 안내, 복구 후 재시도.

복제본은 같은 배포물의 사본이며 별도 서비스가 아닙니다. 프로세스가 죽으면 해당 복제본의 모든 기능이 영향을 받습니다.

소유권 상자는 접근 규칙을 뜻하며 데이터베이스 서버 수를 뜻하지 않습니다.

한 배포에 여러 복제본을 둘 수 있습니다. 프로세스 장애는 해당 인스턴스 기능에 영향을 주며 코드 복귀가 DB 쓰기를 되돌리지는 않습니다.

무엇이라 부르는가

모놀리스는 서버 애플리케이션을 하나의 단위로 배포합니다. 같은 배포물의 복제본을 늘려도 모놀리스이며, 내부에 모듈을 둘 수 있습니다. Lewis·Fowler

배포와 프로세스 장애는 공유합니다. 경계가 중요해지면 명시적인 모듈을 추가합니다.