주문·결제·재고 테이블을 각각 서비스로 나누자는 제안이 나왔습니다. 어떤 변경은 함께 확정해야 하는지와 데이터 소유권을 기준으로 경계를 어떻게 검토하나요?

서비스 경계는 기능이나 테이블을 같은 개수로 쪼개는 문제가 아니라, 어떤 업무 규칙과 데이터를 한 팀이 책임지고 어떤 변경을 독립적으로 배포할지 정하는 문제입니다. 함께 지켜야 하는 불변식이 자주 같은 트랜잭션으로 바뀐다면 같은 경계에 두는 편이 단순합니다. 반대로 별도 보안 권한, 운영 책임, 확장 패턴이 명확하면 분리의 이점이 생깁니다.

예를 들어 계정의 신원 정보와 인증 자격은 책임이 다를 수 있지만, 로그인마다 계정 서비스의 여러 작은 API를 순서대로 호출해야 한다면 지연과 장애 의존성이 커집니다. 다른 서비스가 상대 DB를 직접 읽지 않도록 API나 이벤트로 공개 계약을 만들되, 그 계약 때문에 한 요청의 처리가 여러 저장소를 동시에 바꿔야 한다면 saga·비동기 일관성·보상 비용까지 포함해 판단합니다.

초기에는 모듈 경계를 먼저 강하게 만들고, 실제 변경 빈도·부하·팀 소유권·장애 전파를 관찰한 뒤 프로세스 분리를 늦출 수 있습니다. 반대로 결제 자격처럼 격리된 권한이나 별도 규제 책임이 필요한 영역은 운영 요구 때문에 일찍 분리할 수 있습니다. 서비스 수와 독립 배포 가능성만으로 좋은 경계를 판정하지 않겠습니다.

검증 지표는 호출 왕복 수, 공동 변경 비율, 분산 트랜잭션·보상 수, 장애 전파 범위, 배포 때 함께 건드리는 코드입니다. 분리 뒤 이 지표가 악화되고 소유권이 불명확해지면 서비스를 다시 합치는 것도 합리적인 선택입니다.

원자적 불변식과 소유권을 먼저 씁니다

주문 생성과 재고 차감이 반드시 하나의 트랜잭션이어야 하는지, 예약·결제 승인·확정이라는 중간 상태로 최종 일관성을 허용할지부터 모델링합니다. 각 서비스는 자기 데이터의 원본과 쓰기 권한을 소유하고, 다른 서비스는 API·이벤트로 읽습니다. 상대 DB를 직접 조회하면 경계가 없는 것이며, 분리 뒤 한 요청이 여러 저장소를 바꾸면 saga·보상·대사와 사용자에게 보일 중간 상태가 비용으로 생깁니다.

분리의 효과를 계량합니다

처음에는 한 프로세스 안에서 모듈·포트·권한을 분리해 공동 변경 비율과 규칙을 관찰할 수 있습니다. 보안·규제·확장 패턴이 다른 결제 영역은 일찍 분리할 이유가 있지만, 서비스 수나 팀 이름만으로 경계를 정하지 않습니다. 분리 후 호출 왕복·p99·공동 배포·보상 건수·장애 전파 범위를 비교하고, 이 지표가 악화되면 모듈로 다시 합치는 선택도 열어 두겠습니다.

구체적인 경계 사례

불변식 하나가 서비스 경계를 가로지른다고 무조건 분리가 불가능한 것은 아닙니다. 재고를 예약하고 제한 시간 안에 결제를 확정하는 중간 상태를 도입하면 하나의 큰 트랜잭션을 피할 수 있지만, 예약 만료·결제 응답 유실·늦은 확정의 정책이 새로 필요합니다. 이 추가 상태와 사용자 경험이 분리의 이득보다 큰지 판단하겠습니다.

서비스별 DB를 가졌어도 매 배포마다 공통 라이브러리를 동시에 올리거나 로그인 한 번에 연쇄 호출 열 번이 필요하면 독립성이 낮습니다. 공개 계약의 버전을 관리하고 상대의 내부 스키마를 알지 않는 읽기 모델을 둘 수 있습니다. 모듈 경계를 먼저 만들면 이런 결합을 네트워크 비용 없이 드러낼 수 있으므로 처음부터 프로세스 수를 늘리는 것을 목표로 삼지 않겠습니다.