👀 들어가기 전에 이 프로젝트에서 처음 맡았던 R&R은 주문과 결제 도메인이었다.다만 MVP 이후 재고 테이블을 별도의 도메인으로 분리하는 리팩토링이 진행되면서, 자연스럽게 재고 도메인까지 함께 맡아 개발을 이어가게 되었다. 사실 재고는 개인적으로도 꼭 한 번 제대로 다뤄보고 싶었던 영역이었다. 주문 / 결제 / 재고는 결국 하나의 트랜잭션 흐름으로 엮이고, 특히 재고는 동시성 문제를 정면으로 마주하게 되는 도메인이기 때문이었다. 그래서 재고 관리 로직을 어떤 기준으로 설계하는 것이 맞는지부터 다시 고민하게 되었다.MVP 단계에서는 낙관락 기반으로 재고 차감으로 구현되어 있었는데, 아무리 봐도 재고 도메인에서는 실제 케이스가 지나치게 많아질 수밖에 없는 구조라는 생각이 들었다. 이 시점부터 "재고를 ..

👀 들어가기 전에 ERD를 설계한 뒤, 애자일하게 시작하기 위해 API 명세를 Swagger로 먼저 빠르게 작성하고 MVP 개발에 바로 들어갔던 기억이 난다.일정이 빠듯했기 때문에 "일단 MVP를 시간 내에 완성하는 것"이 최우선 목표였고, 구조적인 개선이나 리팩토링은 MVP 이후 단계에서 진행하기로 결정했다. 그래서 이전 글과 이 글까지의 중간 과정이 다소 많이 생략되어있다. (그 시점에서는 정말 숨 돌릴 틈이 없었다... 🙏)👀 본론 : 재고 ERD 분리 과정 MVP 단계에서는 재고 정보는 product_detail 테이블에 포함된 형태로 관리되고 있었다.기능적으로는 문제가 없었지만, 개발을 진행하면서 점점 한 가지 의문이 들었다.재고 데이터와 상품 데이터가 정말 같은 라이프사이클을 가져도 되는..

👀 들어가기 전에프로젝트를 시작할 때마다 공통적으로 해야 하는 작업들이 있다. ERD 작성, 요구사항 정의서, API 명세서 (Swagger), 역할 분배 (R&R) 그리고 Figma를 통한 화면 흐름 파악. 이번 프로젝트에서는 팀장을 맡아 일정과 역할을 분배했고, 프론트 담당자에게는 Figma 기반 화면 설계를 요청했다. 나는 백엔드 관점에서 프로젝트의 "골격"이 되는 작업(ERD / 요구사항 / API 명세 / R&R)을 먼저 단단히 잡는 데에 집중했다.👀 본론이번 포스팅은 그중에서도 ERD 설계에 집중해 정리하려 한다.ERD는 이후 개발 속도/ 확장성 /운영 난이도를 좌우하는 아주 중요한 요소이기 때문에 그만큼 더 집중했고 지속해서 질문을 던졌다.내가 ERD를 작성하며 계속 던졌던 질문은 아래..

👀 들어가기 전에 개발을 좋아해 매주 주말마다 사이드 프로젝트를 진행해왔다. 다만 그동안은 아이디어나 고민들을 노션에 단편적으로 정리해두는 데 그쳤고, 하나의 프로젝트를 처음부터 끝까지 체계적으로 정리할 기회가 부족했다. 노션은 현재 개인적인 메모 공간에 가깝게 사용하다보니 하나의 프로젝트를 처음 기획부터 구현, 고도화까지 흐름 있게 정리하기에는 뭔가 아쉬웠다. 그래서 이번 기회를 통해 이 블로그에 이미 완료한 사이드 프로젝트와 더불어 앞으로 진행하는 사이드 프로젝트들을 하나의 기록으로 정리해보려 한다. 정리할 부분들은 다음과 같다.왜 이런 선택을 했는지어떤 문제를 만났고어떻게 해결했는지소개 | DAU 100,000명, Peak VUs 1,000명을 목표로하는 고급 명품을 판매하는 이커머스 서비스👀 ..