프로젝트 한눈에 보기
이 프로젝트의 목표는 단순한 기능 추가가 아니었다.
3개 지점 규모에서는 버티던 운영 방식이 더 이상 확장에 적합하지 않았고, 본사와 각 지점이 같은 데이터를 다루더라도 서로 다른 권한과 책임을 가져야 했다.
그래서 이번 재구축에서는 다음 세 가지를 우선순위로 두었다.
- 가맹점 수가 늘어나도 버틸 수 있는 도메인 구조
- 본사, 지점, 고객 화면이 충돌하지 않는 권한/흐름 설계
- 배포 후 실제 운영 이슈를 빠르게 추적할 수 있는 시스템 가시성
왜 부분 개선이 아니라 재구축이었는가
기존 시스템은 작은 규모에서는 빠르게 움직일 수 있었지만, 지점 수가 늘어날수록 운영 규칙과 코드 구조가 서로 발목을 잡기 시작했다.
- 화면별 책임이 뒤섞여 기능 변경 영향 범위를 예측하기 어려웠다
- 데이터 정합성보다 빠른 수정이 우선되면서 예외 케이스가 누적됐다
- 운영 이슈가 발생했을 때 원인을 좁히는 데 시간이 오래 걸렸다
재구축은 항상 비싼 선택이기 때문에, 감정이 아니라 기준으로 판단해야 했다. 이번에는 아래 질문들에 답하면서 결정을 내렸다.
- 핵심 도메인 경계를 다시 정의하지 않으면 앞으로의 기능 추가가 계속 꼬이는가
- 운영 중 장애와 데이터 이슈를 지금 구조로는 충분히 추적할 수 없는가
- 부분 수정이 이미 여러 번 누적되었고, 앞으로의 변경 속도를 더 늦출 가능성이 큰가
세 질문의 답이 모두 "그렇다"에 가까웠기 때문에, 이번 작업은 기능 개선 프로젝트가 아니라 구조 재정의 프로젝트로 보는 것이 맞았다.
내가 맡은 범위
이번 프로젝트에서는 특정 화면이나 특정 API만 담당한 것이 아니라, 전체 구조를 먼저 정의하고 구현 우선순위를 조정하는 역할을 맡았다.
- 도메인 경계 정의와 Bounded Context 모델링
- 백엔드 계층 구조와 데이터 접근 전략 수립
- 프론트엔드 화면 그룹과 멀티 테넌시 흐름 정리
- 배포 구조와 운영 대응을 위한 관측성 기준 정리