Tech Diary Tech Diary

TL;DR: Materialized View는 비싼 쿼리의 결과를 미리 계산해서 저장해두는 조회 전용 구조다. 읽기 성능을 극적으로 개선하지만, 데이터 신선도와 유지 비용이라는 대가를 치른다. 그리고 MV가 어디까지 유용한지는 MV 설계가 아니라 원천 데이터의 구조가 결정한다.매 요청마다 집계할 것인가이커머스 서비스에서 "이번 주 인기 상품 TOP 100"을 보여주는 페이지가 있다고 해보자.이 데이터를 만들려면 수백만 건의 상품 메트릭(좋아요 수, 조회 수, 주문 수)을 읽고, 가중치를 곱해 점수를 계산하고, 정렬해서 상위 100개를 골라야 한다.SELECT product_id, (like_count * 0.2 + view_count * 0.1 + order_count * 0.7) as sco..

TL;DR: 커머스 상품 조회에 Redis 캐시를 적용해도 네트워크 왕복은 남는다.로컬캐시(Java의 고성능 인메모리 캐싱 라이브러리인 Caffeine 같은)을 Redis 앞에 두면, 같은 JVM 안에서 즉시 반환하여 Redis 부하와 응답 시간을 동시에 줄일 수 있다.DB만 → Redis만 → Caffeine+Redis 순서로 K6 부하테스트를 돌려 실제 TPS 차이를 직접 확인해 본다.상황 가정: 캐시를 넣었는데도 "빠르다"는 느낌이 안 든다 커머스 서비스에서 상품 목록과 상세 조회는 전체 API 트래픽의 상당 부분을 차지하는 경우가 많다. 당연히 Redis 캐시를 도입하게 되고, 실제로 DB 쿼리 수는 눈에 띄게 줄어든다.그런데 이상하게도 동시 요청이 올라가면 여전히 latency가 튀는 구간이 보..

요구사항 분석 → 시퀀스 다이어그램 → 클래스 다이어그램 → ERD4개의 설계 문서를 작성하고, 셀프 리뷰를 반복하면서 깨달은 것들을 정리합니다.들어가며브랜드, 상품, 좋아요, 주문.어디서든 볼 수 있는 평범한 이커머스 도메인이다. 처음엔 "이 정도면 금방 끝나겠지"라고 생각했다. 요구사항 정리하고, 다이어그램 그리고, ERD 짜면 끝 아닌가?그런데 막상 요구사항 분석서를 작성하고 나서 스스로 리뷰를 해보니, 처음 버전에서는 유스케이스 몇개가 빠져 있었다. 어드민 브랜드 등록/수정? 상품 상세 조회? 어드민 주문 목록? API 테이블에는 떡하니 있는데, 유스케이스 흐름이 없었다."아 이건 당연한 거니까..."라고 넘긴 부분이 결국 전부 구멍이었다.이 글에서는 설계 문서 4종(요구사항 분석 · 시퀀스 다이..

회원가입, 내 정보 조회, 비밀번호 변경의 어디서든 볼 수 있는 평범한 CRUD API를 만들어 보았습니다.하지만 이 세 개의 API를 TDD로 구현하고, 이후 여러번의 리팩토링을 거치면서 생각보다 많은 설계 결정을 내려야 했습니다.이 글에서는 기능을 "일단 돌아가게" 만든 뒤, 어떤 문제를 발견하고 왜 그렇게 고쳤는지를 중심으로 이야기하려 합니다. 리팩토링 자체보다는 그 과정에서 마주한 질문들이 더 재미있었기 때문입니다.먼저, TDD로 뼈대를 세우기Clean Architecture 기반의 레이어 구조(Controller → Facade → Service → Repository)를 따랐고, Red → Green → Refactor 사이클로 진행했습니다. 처음에는 MemberModelTest로 엔티티 생성..

왜 이 글을 쓰게 되었을까? 최근 부서에서 특정 유저의 요청을 1만번 카운트하고 자정마다 리셋하는 기능을 개발하면서, Mock을 사용한 테스트 코드를 작성하게 되었다. 처음에는 "Mock을 왜 만드는 거지? Mock으로 어떤 것들을 테스트하는 거지?"라는 의문이 들었다. 특히 "Mock을 쓰면 테스트를 위한 테스트를 하는 게 아닌가?"라는 생각이 들어서 Mock 사용을 꺼려했었다. 하지만 실제 테스트 코드를 작성하고 실행해보니, Redis를 직접 호출하지 않고도 Redis가 호출된 기록만으로 테스트를 돌리는 것이 신기했다. 이 경험을 바탕으로, Mock을 통한 테스트가 왜 유용한지, 그리고 실제로 어떤 가치를 제공하는지를 정리해보려 한다. 특히 두 가지 측면에서 Mock 테스트가 유용했다.외부 의존성(R..

왜 이 글을 쓰게 되었을까?개발을 처음 배울 땐 컨트롤러, 서비스, 리포지토리. 딱 세 개의 레이어로 프로젝트를 나눴다. 그리고 대부분의 로직은 서비스에 몰아넣었다. 그때는 그것만으로도 어느 정도는 역할이 분리 된다고 생각했다. 그런데 시간이 지나고 개발을 조금씩 더 하다 보니, ‘서비스에 로직을 넣는다’는 말 자체가 점점 모호하게 느껴졌다. ‘서비스’라는게 무엇인지, ‘비즈니스 로직’은 어디까지고, ‘도메인 로직’은 어디까지인지 고민이 되었다. 이런 고민이 깊어질 즈음, 회사에서 프론트엔드 업무도 같이 하게 됐다. 프론트엔드는 백엔드보다 훨씬 얕게 알고 있지만, 프론트 역시설계에서 ‘의존성’은 굉장히 중요한 문제라는 것을 느꼈다. 의존성이 한 번 꼬이기 시작하면 유지보수와 기능 변경이 굉장히 힘들어진다..

왜 이 글을 쓰게 되었을까?부서에서 사용하는 Java 프로젝트를 Kotlin으로 전환하는 작업을 맡게 되었다.문제는, 이 프로젝트의 도메인도 제대로 알지 못했고, 기존 개발자가 부서에 남아 있지도 않았다. 게다가 전환 작업만 할 수 있는 것도 아니고, 기존의 다른 업무들도 병행해야 하는 상황이었다.이런 조건이라면 당연히 실수가 나올 수밖에 없다. 코드 한 줄 수정할 때마다 ‘이게 정말 원래 기능대로 동작할까?’라는 의문이 들었다. 다행히도, 이 프로젝트에는 테스트 코드가 잘 작성되어 있었다. 덕분에 테스트 코드가 없었다면 훨씬 더 많은 시행착오를 겪었을 것이라는 생각이 들었다.이 경험을 바탕으로, 이번 글에서는 Java에서 Kotlin으로 전환하는 과정에서 테스트 코드가 어떤 도움이 되었는지를 정리하려 ..

배포 환경 변수, 어떻게 관리하는 게 좋을까?작년에 진행한 프로젝트에서 쿠버네티스 기반의 사내 배포 툴을 활용해 개발, 스테이징, 운영 환경을 구축하게 되었다. 그런데 배포 환경별로 환경 변수를 어떻게 효율적으로 관리할지 고민이 생겼다.왜 이 문제를 고민했을까?기존 방식에서는 사내 배포 툴에서 직접 Docker에 환경 변수를 입력해야 했다. 이렇게 하면 운영 환경과 개발 환경을 분리할 수는 있지만, 문제는 코드상에서 어떤 환경이 적용되는지 확인할 수 없다는 점이었다. 배포 설정이 사내 툴 내부에서만 관리되다 보니, 코드만 봐서는 어떤 환경에서 실행되는지 알기 어려웠다.그래서 환경 변수를 코드에서도 명확히 확인할 수 있으면서도, 관리가 더 편리한 방법을 찾기로 했다. 처음에는 Dockerfile에서 환경을..