Architecture: MSA 전환 검토 — 방향 기록·트리거·단계적 경로

[chanwoo7]

배경 — 현재는 모놀리스 유지 (의도적 결정)

알림센터 실시간 subscription 도입(PR #270) 시점에 아키텍처 토폴로지를 논의한 결과, 단일 NestJS 모놀리스를 유지하기로 함. 근거:

• 단독 개발 단계 + prod 인프라 비가동(요금 절약) — 서비스 분리의 운영 비용(배포 파이프라인 N개, 분산 디버깅)을 감당할 이득이 없음
• 현재 정합성 설계가 같은 DB 위의 트랜잭션·row 잠금에 의존 (예: 대화 전송/읽음의 FOR UPDATE 직렬화로 커밋 순서 보장, 주문 알림을 상태 변경과 같은 트랜잭션으로 생성). 분리 시 사가/outbox/멱등성으로 재설계 필요
• 모듈 경계는 이미 도구로 강제 중(arch:check, ESLint boundaries, feature 배럴) — "수정 부담" 문제의 처방은 물리 분리가 아니라 경계 관리

다만 장기적으로는 MSA 운영 의향이 있음(복잡성 관리 + 향후 개발자 합류 대비). 이 이슈는 그 방향 기록이며 약속이 아님.

검토 트리거 — 아래 중 하나가 발생하면 재검토

• 시안 화면 대응 API 개발이 전반적으로 완료됨
• 개발자 합류로 배포 주기/코드 소유권 분리 필요성 발생
• 특정 워크로드(ws 커넥션, 검색 등)의 독립 스케일 필요성 발생

단계적 경로 (전면 전환이 아니라 진화)

1. 런타임 분리 — 같은 코드베이스/이미지를 역할별 플래그로 분리 기동: API 서버 / ws 게이트웨이 / 크론 워커. 코드 분리 비용 거의 0으로 배포·스케일 이득 확보. Redis PubSub(PR feat(conversation): 실시간 subscription — graphql-ws + Redis PubSub #270)이 이 단계의 발판
2. ws 게이트웨이 파일럿 — 첫 물리 분리. 상태가 Redis 토픽 뒤에 격리돼 있고(PUB_SUB 토큰 + ConversationEventsService 단일 발행 경계), connectionParams JWT로 독립 인증 가능 → 분리 비용 최소
3. 도메인 분리 — 파일럿 경험 기반으로 판단. GraphQL schema-first이므로 Apollo Federation(도메인별 subgraph → supergraph)이 자연 경로

선행 과제 (전환과 무관하게 그 자체로 이득)

• 도메인 이벤트 목록화 + outbox 패턴 도입 — 알림 생성의 트랜잭션 인라인을 이벤트 소비로 전환. PR feat(conversation): 알림센터 대화 탭 — 대화 목록·채팅 상세 조회·읽음 처리 #269/#270에서 미반영으로 남긴 이벤트 순서/유실 엣지(ms 동률)도 정석으로 해소됨
• cross-도메인 read 정리 — 예: 알림 조회의 order/store/product join → 이름 스냅샷 저장 방향 검토
• 정리 백로그(Cleanup: 데드 코드·과도기 잔재 일괄 정리 (2026-08 위생 점검) #225~Tech Debt: 미사용 스키마 잔재 정리 (SearchEvent·미사용 컬럼·enum 값) #229)와 묶어 경계 감사 1회

분리 후보 우선순위

순위	후보	근거
1	ws 게이트웨이(subscription)	스케일 프로파일 상이(커넥션 多), Redis 뒤로 상태 격리 완료, 분리 비용 최소
2	알림 발송 워커	FCM 푸시·재시도·배치는 본질적으로 비동기 워커. outbox 첫 소비자로 적합
3	검색/랭킹	크론 스냅샷 기존재. ES류 도입 시 자연 분리
4	채팅(conversation) 도메인	테이블 결합도는 낮으나 잠금 기반 정합성 재설계 필요 — 게이트웨이 분리로 부하 문제 대부분 해소되므로 후순위
5	auth	영향 반경 최대 — 다른 분리 안정화 후

참고

• 관련 PR: feat(user): 알림센터 알림 탭 대응 — event·연관 정보 노출, 3개월 필터, 커서 전환 #267~feat(conversation): 실시간 subscription — graphql-ws + Redis PubSub #270 (알림센터·실시간 subscription)
• 단일 머신(홈서버) 운영 시나리오에서는 docker-compose 컨테이너 수준이 현실적 상한 — k8s 등은 과설계