개발자 아키텍처 안내 프롬프트

지금 상황에서는 “주문·결제·알림을 어떻게 나눌까?”보다 먼저 “이 시스템의 전체 흐름과 책임 경계가 무엇인가?”를 파악하는 것이 중요합니다.

아키텍처는 부서 배치도라기보다 하나의 물류센터 운영 방식에 가깝습니다. 주문 접수, 결제 승인, 배송 알림이 각각 다른 담당자라면, 담당자를 나누는 것만으로는 충분하지 않습니다. 업무 인계 방식, 실패 시 재처리, 기록의 기준도 함께 정해야 합니다.

1. 먼저 전체 흐름으로 보기

일반적인 주문 시스템은 다음처럼 볼 수 있습니다.

[사용자]
   |
   v
[Next.js Frontend]
   |
   v
[NestJS Backend/API]
   |
   +--> [주문 영역] ---- 결제 요청 ----> [결제 영역]
   |        |                              |
   |        |                              +--> 외부 PG
   |        |
   |        +---- 주문 상태 변경 ----------+
   |
   +---- 알림 요청 -----------------------> [알림 영역]
                                             |
                                             +--> 이메일 / SMS / 푸시

여기서 중요한 것은 세 영역이 서로 같은 수준의 책임을 갖지 않는다는 점입니다.

• 주문: 사용자가 무엇을 샀고 주문이 현재 어떤 상태인지 관리
• 결제: 돈의 승인·취소·환불 상태를 관리
• 알림: 어떤 사건을 사용자에게 어떤 채널로 전달할지 관리
• Next.js: 화면 표시와 사용자 입력 담당
• NestJS: 업무 규칙과 외부 시스템 연동 담당
• 데이터 저장소: 각 데이터의 영속성과 조회 책임 담당

즉, “서비스가 세 개”라는 사실보다 “각 영역이 어떤 진실의 기준을 소유하는가”가 더 중요합니다.

예를 들어 결제 성공 여부의 기준은 주문 서비스가 임의로 판단해서는 안 됩니다. 결제 영역 또는 PG 연동 영역이 관리해야 합니다. 주문은 그 결과를 받아 자신의 상태를 변경합니다.

2. 모놀리식과 마이크로서비스의 차이

모놀리식

하나의 배포 단위 안에 주문·결제·알림이 함께 있는 구조입니다.

하나의 NestJS 애플리케이션
 ├── 주문 모듈
 ├── 결제 모듈
 └── 알림 모듈

다만 모놀리식이라고 해서 모든 코드가 뒤섞여야 하는 것은 아닙니다. 모듈 간 경계를 명확히 둔 “모듈러 모놀리식”으로 설계할 수 있습니다.

장점:

• 개발과 배포가 단순함
• 트랜잭션과 디버깅이 쉬움
• 팀 규모가 작을 때 협업 비용이 낮음
• 로컬 개발과 테스트가 상대적으로 편함

단점:

• 한 영역의 변경이 전체 배포로 이어질 수 있음
• 모듈 경계가 무너지면 거대한 덩어리가 됨
• 특정 영역만 독립적으로 확장하기 어려움

마이크로서비스

주문·결제·알림을 별도의 애플리케이션과 배포 단위로 분리합니다.

[주문 서비스] <--> [결제 서비스]
      |
      +----------> [알림 서비스]

장점:

• 서비스별 독립 배포와 확장이 가능함
• 장애를 일정 범위에 가둘 수 있음
• 팀별 소유권과 기술 선택을 분리하기 쉬움

단점:

• 네트워크 호출, 메시지 전달, 재시도, 중복 처리 문제가 생김
• 데이터 일관성을 유지하기 어려움
• 장애 원인 추적과 운영이 복잡해짐
• 배포·모니터링·보안 체계가 필요함

마이크로서비스는 “코드를 더 잘 나누는 방법”이라기보다 “분산 시스템을 운영하는 방법”에 가깝습니다.

3. 결정 기준

다음 질문에 답하면 판단이 훨씬 쉬워집니다.

① 변경 주기가 서로 다른가?

결제 정책은 자주 바뀌지만 알림 템플릿은 별도 팀이 매일 수정한다면 분리의 이유가 될 수 있습니다.

반대로 세 영역이 항상 같은 릴리스에서 함께 변경된다면 굳이 분리할 이유가 약합니다.

② 확장 요구가 다른가?

• 주문 조회량은 매우 많음
• 결제는 트래픽은 적지만 외부 PG 호출이 중요함
• 알림은 특정 시간대에 대량 발송됨

이처럼 확장 방식이 크게 다르면 분리 가치가 있습니다.

③ 장애 격리가 필요한가?

알림 서버가 잠시 중단되어도 주문과 결제가 계속되어야 한다면 알림을 독립적인 비동기 처리 영역으로 분리하는 것이 적절합니다.

하지만 결제 장애가 주문 처리 전체를 멈추지 않아도 되는지, 결제 실패가 주문 상태에 어떤 영향을 주는지는 먼저 업무적으로 정의해야 합니다.

④ 데이터 소유권이 명확한가?

다음과 같은 구조가 바람직합니다.

데이터	소유 영역
주문 상태, 주문 상품	주문
승인·취소·환불 상태	결제
발송 이력, 재시도 상태	알림

여러 서비스가 같은 테이블을 직접 수정한다면 서비스 분리보다 먼저 책임 경계를 정리해야 합니다.

⑤ 팀과 운영 역량이 준비되어 있는가?

마이크로서비스에는 다음 운영 능력이 필요합니다.

• 중앙 로그와 분산 추적
• 서비스별 배포 파이프라인
• 메시지 재처리와 중복 방지
• 장애 알림과 대응 절차
• 서비스 간 계약 관리
• 데이터 백업과 복구 전략

팀이 아직 이 체계를 갖추지 못했다면 마이크로서비스가 구조적으로 더 세련되어 보여도 실제 생산성은 떨어질 수 있습니다.

4. 현재 상황에서의 현실적인 방향

현재 정보만으로는 다음 순서를 추천합니다.

1. Next.js는 화면과 사용자 흐름에 집중시킵니다.
2. NestJS 안에서 주문·결제·알림의 모듈 경계를 명확히 합니다.
3. 각 모듈이 소유하는 데이터와 상태를 정의합니다.
4. 알림은 처음부터 비동기 처리 가능한 구조로 설계합니다.
5. 결제는 외부 PG와의 상태 동기화, 콜백, 재시도를 별도 책임으로 봅니다.
6. 실제 병목이나 독립 배포 요구가 확인된 영역부터 분리합니다.

즉, 현재 세 서비스를 바로 합치거나 더 쪼개기보다 “모듈러 모놀리식으로 경계를 정리한 뒤, 필요한 부분만 서비스로 추출”하는 접근이 안전합니다.

특히 알림은 주문 완료와 강하게 연결되어 보이지만, 주문 자체가 알림 서버의 응답을 기다릴 필요는 없습니다.

주문 완료
   |
   +--> 주문 상태 저장
   |
   +--> 알림 발송 요청 기록
             |
             v
        알림 처리 및 재시도

알림 발송이 실패했다고 주문이 실패해서는 안 되는 경우가 많기 때문입니다. 반면 결제는 주문 상태에 직접 영향을 주므로 상태 전이와 책임을 더 엄격하게 정의해야 합니다.

5. 설계할 때 특히 조심할 점

서비스 간 직접적인 데이터 수정

주문 영역이 결제 테이블을 직접 수정하거나, 알림 영역이 주문 테이블을 직접 조회해 상태를 판단하면 경계가 빠르게 무너집니다.

가능하면 “결제 승인 완료”, “주문 생성 완료” 같은 명확한 사건이나 API 계약을 통해 협력해야 합니다.

분산 트랜잭션에 대한 막연한 기대

주문 저장, 결제 승인, 알림 발송을 하나의 데이터베이스 트랜잭션처럼 묶기는 어렵습니다. 대신 다음을 정의해야 합니다.

• 중간 단계에서 실패하면 현재 상태는 무엇인가?
• 같은 요청이 두 번 들어오면 어떻게 되는가?
• 일정 시간이 지나도 응답이 없으면 어떻게 재처리하는가?
• 사용자가 확인할 최종 상태는 무엇인가?

“서비스 개수”를 성공 지표로 보는 것

서비스가 많다고 좋은 아키텍처는 아닙니다. 좋은 구조는 각 책임이 명확하고, 변경과 장애의 영향 범위를 예측할 수 있는 구조입니다.

6. 실무 판단용 간단한 기준

다음처럼 생각해 볼 수 있습니다.

모듈 경계가 불명확하다
        |
        v
먼저 모듈러 모놀리식으로 정리

변경 주기·확장·장애 영향이 크게 다르다
        |
        v
해당 영역만 독립 서비스로 분리

분리했지만 운영·관측·재처리 체계가 없다
        |
        v
분리보다 운영 기반을 먼저 마련

실무에서는 “마이크로서비스로 갈 것인가?”를 한 번에 결정하기보다, 각 영역에 대해 다음 점수를 매겨보면 좋습니다.

• 독립 배포 필요성
• 독립 확장 필요성
• 장애 격리 필요성
• 데이터 소유권의 명확성
• 팀의 독립적 소유 가능성
• 운영 복잡성을 감당할 준비

앞의 항목들이 높고 마지막 항목도 충분히 준비되어 있을 때 분리를 고려합니다.

정리하면, 지금 필요한 첫 단계는 서비스 개수를 결정하는 것이 아니라 주문·결제·알림의 책임, 데이터 소유권, 상태 변화, 실패 처리 흐름을 하나의 그림으로 그리는 것입니다. 그 그림에서 경계가 명확하고 독립 운영의 이득이 큰 영역만 마이크로서비스로 분리하면 됩니다.