바인드 프로젝트 구조 구상 및 설계 방향

이 글은 바인드 프로젝트를 시작하며 전체 구조를 어떻게 구상했는지,
어떤 기술을 어떤 의도로 선택했는지를 기록한 기술 회고다.

프로젝트 개요

서비스 목표 : 합주실 예약 및 밴드원들을 위한 커뮤니티

기술적 목표 :
바인드(Bind)는 모듈화된 백엔드 아키텍처를 기반으로, 서비스 확장성과 유지 보수성을 고려하여 설계된 프로젝트다.
각 기능 단위를 별도의 모듈로 분리함으로써, 다음과 같은 목표를 달성하고자 했다:

책임이 분리된 공용 유틸리티를 재사용 가능한 형태로 정리
Kafka, Redis, Outbox 등 외부 시스템과의 통합을 안정적으로 추상화
실전 운영 환경을 고려한 모니터링 및 트레이싱 체계 내장

전체 모듈 구조(예상)

/backend
├── public/               # 공통 유틸리티 및 인프라 모듈
│   ├── primary-id-provider   # Snowflake 기반 ID 생성기
│   ├── data-serializer       # JSON <-> Object 직렬화 유틸
│   ├── exception             # 전역 예외 처리 및 에러 코드 체계
│   ├── event                 # 도메인 이벤트 정의 및 발행 구조
│   ├── outbox                # Outbox 패턴 관리 (이벤트 저장소)
│   ├── log-manager           # 공통 로깅 정책 (traceId, masking 등)
│   └── monitoring (계획 중) # Prometheus/Micrometer 연동을 통한 메트릭 추적
│
└── service/              # 실제 도메인 서비스들 (회원, 주문, 알림 등)
    ├── user-service
    ├── order-service
    └── ...

모듈 구상(구현 예정) 이유 및 설명

`primary-id-provider`

Twitter의 Snowflake 알고리즘을 직접 구현
시간순 정렬 가능하고, nodeId 기반으로 충돌 방지
TPS 테스트 및 시계 역행 처리까지 포함

회고: UUID의 비정렬성과 ULID의 복잡함 사이에서 직접 ID 전략을 구축하는 것이 명확하고 제어 가능하다고 판단했다.

`data-serializer`

Jackson 기반 JSON <-> Object 변환 유틸
Optional<T> 반환으로 null 처리 안정성 확보
Kafka, Redis 모두에서 사용할 수 있도록 byte[] 지원

회고: Kafka 직렬화 실패나 Redis 캐시 무효화 문제가 자주 발생해서, 공통 직렬화 정책의 중요성을 체감하게 됐다.

`exception`

BusinessException, ErrorCode, GlobalExceptionHandler 구성
서비스 레이어에서 일관된 에러 처리 방식 확보

`event`

도메인 이벤트를 직접 정의하고 발행/구독 구조를 분리
향후 Kafka, 비동기 큐로 확장 가능성을 고려한 인터페이스 설계

`outbox`

DB 트랜잭션과 메시지 발행을 분리하기 위한 핵심 패턴
OutboxMessage, OutboxProcessor, EventSerializer 등으로 구성 예정

`log-manager`

MDC 기반 traceId 주입
request-response logging
log masking 및 structured logging 대응

`monitoring`

Micrometer + Prometheus를 통해 핵심 지표 수집
Outbox 지연, 이벤트 실패율, ID 생성 TPS 등 수집 예정

728x90