올웨이즈 요가 — 요가 스튜디오 플랫폼 백엔드
2024.12 — 2025.05 · Backend Lead
NestJS, TypeScript, TypeORM, PostgreSQL, Redis, Elasticsearch, AWS S3, Firebase
재직 기업의 저작권·보안 정책에 따라 코드 수준의 서술 없이 아키텍처와 규모 수준에서만 기록.
문제 정의
- 스튜디오·강사·시간표, 예약·결제, 출석·다이어리, 피드형 커뮤니티까지 — 도메인 폭이 넓은 플랫폼을 소수 인원으로 감당해야 하는 상황.
- 기능 속도보다 도메인 경계를 바르게 긋는 것이 우선이라고 판단.
설계와 구현
- DDD 지향 모듈러 아키텍처 — 초기의 평면적 구조를 도메인 계층 구조로 리팩터링. 15개 도메인 모듈(인증·유저·스튜디오·예약·결제·출석·피드·검색·알림 등)을 controllers/services/dtos/entities로 일관되게 계층화.
- 권한 이원화 인증 체계 — 일반 유저와 스튜디오 운영자(비즈니스 유저)를 별도 JWT 전략·가드로 분리. 카카오·네이버 소셜 로그인, Redis 캐시 기반 이메일·휴대폰 2단계 인증 구현.
- 예약·결제 파이프라인 — 예약 검증, 취소 후 재예약, 장바구니 흐름 설계. PG(PortOne) 결제 검증을 서버사이드에서 수행해 클라이언트 신뢰 없이 결제 무결성 보장.
- 인프라 통합 — Elasticsearch 스튜디오 검색, AWS S3 presigned URL 이미지 업로드, Firebase FCM 푸시, 메일 발송 직접 통합. GitHub Actions 기반 자동 배포 파이프라인 구축.
규모
- 5개월 · 139커밋 — 15개 도메인 모듈 · 18개 컨트롤러 · 약 92개 엔드포인트 · 33개 엔티티 · 약 1만 줄.
- 커밋 이력에 남은 확장 순서: 인증 → 커뮤니티 → 검색·캐시 → 스튜디오/강사 → 예약·결제 → 출석·활동.
배움
- 도메인 경계 리팩터링을 미루면 비용이 복리로 누적 — 초반의 구조 개편이 이후 개발 속도의 근거.
- 결제처럼 신뢰가 걸린 흐름은 "동작한다"와 "검증된다"가 다른 문제 — 서버사이드 검증을 기본값으로 삼는 습관 확립.
- 외부 서비스 통합의 본질은 개별 기술이 아니라 실패 시나리오 설계 — 각 연동의 장애가 핵심 흐름(예약)을 막지 않도록 경계를 긋는 감각.