왜 필요한가

가족이 행사 안내를 저장하고 참가비를 내는 학교 앱을 만든다고 가정해 봅시다. 자원봉사 태그는 급하지만 결제는 기존 배포 일정을 지켜야 합니다. 한 팀이 태그를 독립 배포하려고 네트워크 조율을 감수합니다. 내부 모듈만 나누면 배포는 여전히 함께입니다.

어떻게 해결하는가

  1. 한 팀이 카탈로그·보관함·결제를 각각 v1으로 운영합니다. 저장한 학교 행사 안내에는 태그가 없습니다.
  2. 호환되는 태그 기능을 보관함 v2로만 배포합니다. 카탈로그·결제는 v1 유지.
  3. 보관함이 네트워크로 카탈로그를 조회한 뒤 자체 저장소에 자원봉사를 기록합니다. 쓰기 전 조회 시간 초과 시 태그 없음 유지. 실패를 알리고 복구 후 재시도합니다.
독립 배포와 함께 다뤄야 할 원격 장애

설명을 위한 가상 예시

기능 하나만 독립 배포

학교 행사 앱 · 한 팀 · 학교 행사에 자원봉사 태그 없음

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

호환 계약 유지: 보관함만 새 배포 필요.

  1. 배포 단위 · 1

    카탈로그

    v1 → v1

    동작 유지

    자체 저장소카탈로그

  2. 배포 단위 · 2

    보관함

    v1 → v2

    태그 기능 추가

    자체 저장소보관함

  3. 배포 단위 · 3

    결제

    v1 → v1

    동작 유지

    자체 저장소결제

네트워크 조회 · 태그 쓰기 이전

보관함 → 카탈로그 API

원격 응답은 보장되지 않습니다. 결제는 이 조회 경로에 참여하지 않습니다.

  1. 1 · 성공

    조회 성공 → 자원봉사 기록 → 학교 행사 태그는 자원봉사.

  2. 2 · 카탈로그 조회 시간 초과

    쓰기 전 조회 실패 → 태그 없음. 실패 안내, 복구 후 재시도.

각 서비스가 데이터를 소유하며 다른 서비스 테이블을 직접 읽지 않습니다. 독립 배포에도 관측·장애 처리가 필요하며 의존 서비스의 장애가 전파될 수 있습니다.

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

독립 배포가 자동 장애 격리는 아닙니다. 동기 카탈로그 의존성은 보관함을 막을 수 있습니다. 시간 제한·재시도를 정하세요.

무엇이라 부르는가

마이크로서비스는 명시적 계약과 데이터 소유권을 갖고 독립 배포하는 업무 기능별 서비스입니다. 프로세스를 나누기만 해서는 독립성이 생기지 않습니다. Lewis·Fowler

네트워크 장애와 서비스 간 데이터는 조율해야 합니다. 나머지 기능은 모듈러 모놀리스로 유지할 수 있습니다.