세상에 벌써 마지막 회고라니..7월 어느 날 시작한 프로젝트가 벌써 10주가 지나 대단원의 막을 내리게 되었다.한여름에 시작할 땐 언제 10주가 지나지 했는데, 이젠 살짝 춥기도 한 가을의 초입이라니 시간이 참 빠르다.루프팩을 마무리하면서 느낀 것들을 정리해보려고 한다. 사실 루프팩을 시작하기 직전 6월, 회사에서 정리해고를 당했다.SNS에서만 보던 일이 나에게 일어날 줄은 몰랐는데..잘 가다가 갑자기 모르는 길 한복판에 내던져진 기분이었다.한동안 방향도 잃고 방황도 조금 했던 것 같다. 그러던 중 친구에게 루퍼스에서 이 과정을 진행한다는 소식을 듣게 되었다.마침 시간도 뜨고 퇴직금도 생겼겠다.. 같이 해보자는 친구의 권유로 시작하게 되었다. 사실 나는 작년에 비슷한 플랫폼에서 비슷한 코스를 진행한 ..

이번 주는 상품 목록 조회 API의 읽기 성능 개선 작업을 진행했다. 단순히 애플리케이션 로직만 손보는 것만이 아니라 DB 인덱스와 캐시까지 적용하며 병목 지점을 단계별로 확인하고 개선하는 데 집중했다.먼저 불필요하다고 생각한 로직을 제거해봤지만 응답 속도나 TPS 개선 폭은 미미해서 놀랐었다. 구조 개선도 어느정도 영향을 줄 수 있을줄 알았는데 거의 없다니.. 그래도 이 작업을 통해 병목의 주된 원인이 애플리케이션 로직이 아니라 DB 쿼리 처리 과정에 있음을 확인할 수 있었다. 이후 검색 조건과 정렬 조건을 조합한 복합 인덱스를 적용하자 filesort가 제거되고 쿼리 실행 시간이 약 500ms에서 3ms까지 단축되었다. TPS도 약 2배 상승하고 에러율도 70% 이상 줄었지만, 부하 테스트에서 응답 ..

이번 주는 DB 수준에서의 동시성 제어를 주문 로직에 적용하는 작업을 진행했다. 단순히 @Transactional을 거는 것 외에, 락 전략을 어떻게 선택할지와 그 이유를 명확히 하기 위해 DB의 트랜잭션과 격리 수준, MVCC 구조, Undo Log 동작 방식 등을 먼저 학습해 보았다. 이 과정을 거치니 락이 실제로 어떤 상황에서 동작하고 성능에 어떤 영향을 주는지 더 이해가 잘 됐다.주문 로직에서 락이 필요한 지점은 쿠폰 사용, 포인트 사용 그리고 재고 차감 부분이었다. 각 자원의 특성과 경합 가능성을 고려해서 쿠폰과 포인트는 낙관적 락, 재고는 비관적 락을 적용했다. 특히 포인트는 두 방식 다 사용해도 될 것 같아 어떤 락을 선택할지 고민을 많이 했었다. 1000건 정도의 요청이 들어올 것을 가정해..

이번 주는 도메인 간 흐름을 명확히 하고 각 도메인의 책임과 상호작용을 구체화하는데 집중했다.초기에는 ERD를 기반으로 전체 구조를 잡은 후, 도메인 모델로 전환하면서 필요한 Entity와 VO를 정의했다. Entity 내 필드 중 ID나 길이 제한, null 여부 정도만 검증이 필요한 경우는 굳이 VO로 분리하지 않고 Entity 필드로 관리하는 방식으로 정리했다. 상품, 브랜드, 좋아요, 주문, 결제 등 각각의 도메인이 어떤 책임을 갖고 어떻게 협력할지 명확히 하기 위해 레이어드 아키텍처를 적극적으로 활용하며 흐름을 다음과 같이 구성했다.Interface → Application → Domain ← Infrastructure특정 도메인과 관련된 로직은 Domain 레이어 내부의 도메인 서비스에서 처리..

이번 주는 전체 도메인 흐름을 정리하기 위해 시나리오 기반의 요구사항 명세서부터 시퀀스 다이어그램, ERD, 클래스 다이어그램까지 설계 문서를 체계적으로 작성해보았다. 처음엔 막연했지만 요구사항 명세서로 시나리오를 정리하고 시퀀스 다이어그램으로 각 시나리오의 흐름을 시각화하면서 점점 구조가 뚜렷해지는 것을 느꼈다.ERD와 클래스 다이어그램을 작성하면서 테이블로 분리할지, 도메인 클래스만 분리할지에 대한 고민도 많았다. 상품 재고처럼 단순한 컬럼으로 처리할 수도 있는 데이터를 별도 엔티티로 분리할지 기준을 잡는 것이 쉽지 않았다. 결국에는 책임을 명확히 나누고 복잡해질 가능성이 있는 부분은 미리 분리해두는 방향으로 정리했다. 문서를 작성하면서 Mermaid 를 활용해보았는데, 외부 툴로 이미지 형태의 문서..

이번 주는 프로젝트에 TDD를 적용하며 테스트에 용이한 구조가 무엇일지 고민하며 진행했다. 특히 요구사항에 맞게 validation 을 추가하려다보니 어디에서 어떻게 책임을 나눠야하는지 고민이 되었다. 평소에는 그냥 서비스에서 다 처리했는데 막상 테스트를 하려니 테스트 조건을 일일이 수기로 맞춰주어야하는 등 꽤 번거로웠다. 그러다보니 유효성 검증을 테스트하기 좋은 구조가 어떤 것일지 고민하게 되었고 각 계층의 역할과 책임에 대해서도 다시한번 생각해보게 되었다.전에는 도메인 객체를 그냥 DB에 매핑되는 객체로 다뤘었다면, 이번에는 도메인 내부에서 자체적으로 유효성 검증을 하게 함으로써 무결성을 보장할 수 있도록 해보았다. 단위테스트로도 분리할 수 있게되면서 테스트나 전체 코드 흐름이 깔끔해진 것을 느꼈다...