들어가며
그동안 프로젝트를 하며 항상 마음 한구석에 아쉬움이 있었습니다.
"동시 요청이 몰리면 어떻게 하지? 장애가 나서 데이터가 꼬이면?" 같은 질문들을 머리로는 알고 있었지만, 정작 해결할 줄 몰랐기 때문입니다.
그저 기능이 돌아가는 것에 만족하며 '공부해야 할 숙제'로만 남겨두고 있었습니다.
하지만 ccommit 개발자 멘토링을 계기로 이 숙제를 정면으로 마주하기로 했습니다.
이번 프로젝트는 단순한 기능 구현을 넘어 데이터 안전성, 대용량 트래픽 처리, 테스트 코드 기반 검증, 배포 자동화, 그리고 코드 리뷰를 통한 객체지향 리팩토링을 핵심에 두고 진행하려 합니다.
그리고 그 출발점으로 무신사와 같은 패션 커머스 플랫폼을 프로젝트 주제로 선택한 이유를 이번 글에서 정리해보려 합니다.
왜 커머스인가 :대용량 트래픽과 데이터 정합성의 한계를 시험할 가장 완벽한 무대
무신사와 같은 대형 커머스 플랫폼은 단순한 상품 CRUD 시스템이 아닙니다.
겉으로 보기에는 상품 등록과 주문이라는 전형적인 구조를 갖고 있지만, 실제 운영 환경에서는 전혀 다른 차원의 과제가 존재합니다.
한정 수량 발매나 선착순 쿠폰 이벤트가 시작되는 순간, 시스템은 단순히 “사람이 많이 몰린다”는 문제를 넘어 데이터 정합성이 무너질 위험과 마주하게 됩니다.
- 쿠폰이 1만 장인데 1만 1천 장이 나가는 초과 발급
- 재고가 1개인데 2명이 동시에 결제에 성공하는 오버셀링
- 결제는 성공했지만 주문 정보는 유실되는 트랜잭션 불일치
- 네트워크 지연으로 인한 중복 주문 생성
이러한 문제들은 단순 성능 저하가 아니라 금전적 손실과 직결되는 데이터 무결성 붕괴 이슈입니다.
실제 커머스 환경에서는 대용량 트래픽이 발생해도 데이터가 단 한 건이라도 틀어지면 안됩니다.
무신사 주문개발팀은 하루 30만 건, 분당 최대 1.5만 건의 주문을 처리하며대용량 트래픽과 복잡한 도메인 속에서 견고하고 유연한 시스템을 운영하고 있습니다.
저 역시 그런 개발자가 되고 싶었습니다. 기능을 만드는 개발자가 아니라, 문제가 터졌을 때 설계로 해결하고 기술적 의사결정을 주도할 수 있는 개발자.
그 출발점으로 대용량 트래픽 환경에서 데이터 정합성을 어떻게 지켜낼 수 있을지를 직접 고민해보고자 했습니다.
그래서 이번 프로젝트의 주제를 무신사와 같은 패션 커머스 플랫폼으로 정했습니다.
마치며
결국 제가 이커머스라는 거대한 무대를 선택한 이유는 단순히 유명한 무신사 서비스를 흉내 내기 위함이 아닙니다. 백엔드 개발자로서 '정답이 없는 문제'에 부딪혀보고 싶었기 때문입니다.
머리로만 알고 있던 동시성 제어, 트랜잭션 격리 수준, 그리고 분산 환경에서의 데이터 정합성...등등 이제는 이론이을 벗어나 실제 코드에 이론을 녹이고, 그리고 수치로 제 설계를 증명해 보려 합니다.
물론 그 과정에서 수많은 시행착오와 예상치 못한 에러를 마주하겠지만, 그 '삽질'의 시간이야말로 저를 기능을 만드는 개발자에서 시스템을 지탱하는 엔지니어로 성장시켜줄 핵심 동력이라 믿습니다.
그 여정을 이 프로젝트와 함께 기록해보려 합니다.
앞으로 이어질 글에서는 실제 설계 과정과 기술적 선택, 그리고 그 과정에서의 고민들을 차근차근 정리해보겠습니다.