TL;DR: Controller에는 비즈니스 로직 외에도 파라미터 파싱·뷰 결정·렌더링 책임이 섞여있다. 이 셋을 단계별로 떼어내면 Controller는 진짜 컨트롤러 역할만 남고, 결과적으로 Spring MVC와 거의 같은 구조가 만들어진다.지난 글(한 메서드 안에

TL;DR: 서블릿 N개에 흩어진 공통 로직은 새로운 보일러플레이트다. 모든 요청을 받는 단일 진입점 + 비즈니스 로직만 담는 핸들러로 분리하면, 중복이 N에 비례하던 코드가 상수로 압축된다.지난 글(URL이 100개면, Servlet 클래스도 100개가 되어야 하는가

TL;DR: "서블릿 컨테이너"라는 한 단어를 부품 다섯 개로 쪼개서 보면, 톰캣이 무엇을 책임지는지가 명확해진다.지난 글(| 계층 | 누가 처리하는가 |\| --- \| --- \|| 비즈니스 로직 | 개발자가 작성한 코드 || HTTP 메시지 처리 | 서블릿 컨테이

TL;DR: "스프링 없이 CRUD 4개쯤이야"로 시작했는데, Socket 추상화 너머에 OS 커널이 통째로 떠받치고 있다는 것과, 그 위에 짜는 코드의 95%는 HTTP 스펙 처리라는 것을 연달아 깨달았다.강의 서비스 백엔드를 처음부터 짜보는 과제를 받았다. 회원 가

"이 시장에서 나는 경쟁력이 있는 사람일까?"그 질문 하나로 시작된 10주의 기록.2025-12-31은 나에게 의미있는 날이였다.25년도 한 해를 마무리하며 회고하고 있었는데 문득 이런 생각이 들었다.어느새 3년이나 회사를 다녔는데, 나는 과연 이 시장에 경쟁력이 있는

상품 랭킹 시스템을 일간 / 주간 / 월간 세 가지 주기로 나눠 구현했다.핵심은 "조회 주기에 따라 적절한 저장소를 고르는 것" 이었다.랭킹은 결국 "점수 기반 정렬 + 순위 조회" 문제다.ZSET은 내부적으로 skip list + hash를 써서 score 정렬 삽입

이 글은 L0~L7 8가지 배치 기법을 동일 데이터셋으로 측정하고, 각 기법이 어떤 상황에서 옳은 선택인지 역으로 추적한 기록입니다. 코드와 측정값은 batch-benchmark-java 저장소에서 모두 재현할 수 있습니다.작년에 팀에서 배치 작업을 새로 설계하면서,

TL;DR10주 동안 TDD, 도메인 설계, 락, 인덱스, 캐시, Circuit Breaker, 이벤트, Kafka, 대기열, Redis ZSET, Spring Batch를 공부했다. 처음엔 각자 다른 도구라고 생각했는데, 돌아보니 대체로 트레이드오프의 다른 이름들이

이번 주 과제는 "상품 인기 랭킹을 실시간으로 보여줘라"였다. 처음에는 간단할 줄 알았다. product_metrics 테이블에 조회수, 좋아요, 주문수가 이미 쌓이고 있으니까 ORDER BY 한 방이면 되지 않나? 하지만 "인기"를 정의하려는 순간부터 생각보다 복잡한

TL;DR: "대략 맞으면 되는" 줄 알았던 랭킹 데이터에서 가장 많은 설계 판단이 필요했다.29CM BEST 페이지. 이 순위는 어떻게 정해지는 걸까?이 글에서 사용한 실험 환경은 Spring Boot + Redis ZSET 기반 학습용 프로젝트입니다. Score 방

이번 주 과제는 "블랙 프라이데이에 주문이 폭주하면 어떻게 할 것인가?"였다. 처음에는 단순히 Rate Limiting으로 요청을 거부하면 되지 않나 싶었는데, 과제를 읽으면서 생각이 바뀌었다.Rate Limiting은 초과 트래픽에 429를 던지고 끝이다. "나중에

TL;DR: 에러 없이 정합성이 깨지는 게 가장 무섭다. 그걸 수치로 증명하고, 한 겹씩 고쳐간 기록.멜론티켓을 열면 항상 같은 화면을 본다. "현재 대기 인원 23,482명". 그리고 숫자가 줄어들길 기다리다가 결국 "선택 가능한 좌석이 없습니다"를 마주한다.그런데

루퍼스라는 부트캠프를 시작한 지 어느덧 7주차가 완료되었다.기술적인 회고를 작성할 수도 있지만, 7주라는 시간이 지났으니 나 스스로에 대해 되돌아보는 시간을 가지고 싶었다. 매주 코드를 돌아봤으니, 이번엔 코드를 치는 '나'라는 사람을 돌아보려 한다. 그래서 이번 WI

TL;DR올리브영 세일 전날, 선착순 쿠폰 발급과 좋아요 폭증이 동시에 터지는 상황을 가정했다. 좋아요 집계가 느려지면서 좋아요 자체가 실패하고, 서버 배포 한 번에 이벤트가 통째로 유실되는 문제까지. 이걸 해결하기 위해 Outbox 패턴으로 이벤트를 DB에 저장하고,

지금부터 하는 이야기는 PG 시뮬레이터(요청 성공률 60%, 비동기 처리 성공률 70%, 종합 성공률 42%)를 상대로 커머스 결제 시스템의 장애 대응을 설계한 과정입니다. 실제 PG사의 실패율은 이보다 훨씬 낮지만, 극단적인 환경이 더 좋은 질문을 만들어줬습니다.PG

TL;DR 결국 "어디에 인덱스를 거는가"보다 "쿼리가 실제로 어떻게 실행되는가"를 먼저 이해해야 했고, EXPLAIN을 읽는 법을 배운 뒤에야 진짜 병목을 찾을 수 있었다.사내 ERP 시스템에 계약대장관리 화면이 있다. 계약 건별 마스터 정보를 조회하는 화면인데, 검

TL;DR "데이터가 사는 곳에서 잠가야(Lock) 한다."카페에서 아이스 아메리카노 한 잔이 남았다.두 명이 동시에 주문 버튼을 누르면 어떻게 될까?일상에서는 별일 아니다. 점원이 "죄송합니다, 한 잔 남았는데요"라고 말하면 된다.그런데 서버에서는 점원이 없다. 코드

이전 글에서 33개의 Q&A로 설계를 먼저 한 이야기를 했다. 이번에는 그 설계 과정에서 가장 머리를 싸맸던 부분에 대해 써보려 한다."이 코드를 어디에 둬야 하는가?"DDD를 공부하면 "바운디드 컨텍스트", "어그리게이트", "도메인 서비스" 같은 용어가 쏟아진다.

들어가며 — 바로 코딩하면 어떻게 되는지 알고 있다 이커머스 과제를 받았다. Brand, Product, Stock, Like, Order — 5개 도메인, 21개 API. 요구사항 문서를 읽으면서 떠오른 첫 번째 생각은 "일단 엔티티부터 만들자"였다. 하지만 경

검증 로직을 어디에 둘 것인가 — 회원가입 구현에서 배운 것 > TL;DR > 비밀번호 규칙, 이메일 형식 같은 검증 로직을 Controller, Service, Entity 순서로 시도하다가, 최종적으로 Value Object에 넣었다. 결정적 계기는 테스트였다.