범범의 기술블로그

인덱스, 캐시 그래서 언제 어떻게 사용하는 거야? 10만 건 상품 데이터로 EXPLAIN 찍고, 부하테스트 돌려보니까 보이더라 TL;DR 복합 인덱스 하나로 읽은 행이 5,000 → 20으로 줄고, 실행 시간이 76~231배 개선됐다. Redis 캐시만 쓰면 네트워크 왕복이 병목. 로컬 캐시(Caffeine)를 앞에 두니 목록 조회 p95가 10.71ms → 7.08ms로 떨어졌다. "캐시 쓰면 빨라진다"는 감이 아니라, EXPLAIN과 부하테스트로 숫자로 증명하는 게 중요했다. 인덱스가 뭘까? ..

비관적 락 하나로 다 해결한 줄 알았다(도메인 순수성과 성능 사이에서 락전략) 비관적 락 하나로 락을 정복한 줄 알았습니다.. TL;DR동시성 전략은 하나로 통일하는 게 아니라, 도메인 특성에 따라 달라야 한다.좋아요 → Atomic Update / 쿠폰 → 비관적 락 / 재고 → 비관적 락 으로 결정한 이유그런데 도메인 아키텍처에 집착하면, 더 가벼운 도구를 놓칠 수도 있다. 비관적 락이면 되는 거 아니야? 이전까지 비관적락과 낙관적락을 비교하는 포스팅을 할정도로 저는 꽤 자신감이 있었습니다. 재고 차감? SELECT ... FOR UPDATE로 줄 세우면 끝. 쿠폰 이중 사용? 마찬가지로 비관적 ..

이커머스 프로젝트에서 브랜드 도메인을 구현하다가 문득 이런 생각이 들었습니다." DDD 구현중인데 이 @Transactional, 도메인에 있어도 되는 거 맞아?" 발단: 어노테이션 하나에서 시작된 의문 브랜드 CRUD를 구현하고 나서, 코드를 보고 있었습니다. 겉보기에는 아무 문제 없었습니다. 테스트도 다 통과하고, API도 잘 동작했습니다. // Domain Service@Transactionalclass BrandService( private val brandRepository: BrandRepository,) { fun createBrand(name: String, description: String?): Brand { val brand = Brand(name = nam..

"재고가 딱 1개 남았는데 두 명이 동시에 주문하면 어떻게 되지?" 이번에 이커머스 프로젝트의 설계를 진행하면서, 주문 생성 흐름을 생각하고 있었습니다. 상품 조회 → 재고 확인 → 재고 차감 → 주문 생성 글로 적으면 단순한 흐름인데, 막상 "동시에 요청이 들어오면?" 의 제대로 답을 하지 못했습니다.재고는 이커머스에서는 상당히 중요한 존재이면서 동시에 외부몰, 자사몰, SCM 등 많은 도메인에 얽혀 있는 복잡한 문제입니다. 재고가 한번 틀어지면 그 틀어진 구간을 바로 잡기가 정말 어렵습니다. 실제로 회사에서 외부몰과 자사몰의 재고 싱크가 어긋나서, CS 팀이 하루 종일 수동으로 주문 취소 처리를 했던 적도 있습니다. 재고 -1이 만들어낸 나비효과가 고객 불만, 보상 비용, 운영 리소스 낭비로 이어지는..

제목 어떠셨나요? 더는 못참겠어서 Claude Code를 앞에 세워 TDD를 불러내 봤습니다! 😂왜 이 글을 쓰게 되었는가?개발자들에게 TDD는 너무 익숙한 단어이면서, 또 저같은 테스트 코드를 멀리하던 개발자에게는 두려운 단어이기도 한 것 같습니다. TDD를 다들 어디서 들어보셨나요? 저는..."요즘은 TDD가 대세래!""좋은 회사는 TDD로 개발한대!""TDD로 개발한 코드가 좋은 코드래!" 라는 말을 수도 없이 들어왔습니다. 그런데 솔직히 이렇게 생각했어요."TDD... 나도 알아! 그런데 급하게 업무가 쏟아지는데 언제 테스트 먼저 짜고 있냐고!" 지금 생각해보면 사실 도피였던 것 같아요. 잘 모르니까, 또 "할 상황이 안 된다"고 핑계를 대고 있었던 거죠. 이번에 루퍼스에서 회원 API(회원가입..