본문 바로가기

Study for.11

루퍼스 3기 수료 후기 — 개발은 취향이다 기조: 개발은 취향이다. 10주가 지났다. 10주 전의 나에게 "넌 왜 개발을 그렇게 하니"라고 물었다면, 나는 한참을 머뭇거리다 회사 사정이나 일정, 비용 같은 단어로 얼버무렸을 것 같다. 10주 뒤의 나는, 그 질문을 반긴다. 답이 명쾌해서가 아니라, 답을 만들어 낼 언어가 생겼기 때문이다. 이 글은 그 10주에 대한 기록이다. 목차루퍼스를 신청하게 된 계기루퍼스를 시작하며 마음 먹은 사항루퍼스를 겪으며루퍼스를 수료하고 난 나의 마음가짐이런 분들께 루퍼스를 추천한다마무리 1. 루퍼스를 신청하게 된 계기 루퍼스를 신청하게 된 계기는, 사실 정말 단순했다.더 이상 개발 실력에 대해 핑계를 대고 싶지 않았다. 이런 마음을 품게 된 건 올해 초 성과 평가의 피드백에서 시작되었다. 2025년의 내 .. 2026. 4. 26.
매주 한 편씩 쓰다 보니 10주가 지나 있었습니다 TL;DR — 10주 동안 매주 한 편씩 블로그를 썼습니다. 토요일 저녁마다 "정상이 어디에요?" 라고 스스로에게 물었고, 돌아오는 답은 언제나 "아 5분만 더 가면 돼" 였습니다. 그 5분이 열 번 쌓여 10주가 되었고, 저는 끝내 포기하지 않았습니다. 이 글은 그 열두 편의 흔적이 만든 열한 번째 저를 돌아보는 총괄 회고이자, 마지막 라운드(Spring Batch + Materialized View + 기간별 Ranking API) 에서 내린 결정을 기록한 인덱스입니다.프롤로그 — 글을 쓰기 시작한 2주차의 저처음부터 매주 블로그를 쓸 생각은 아니었습니다. 1주차에는 Ktlint·EditorConfig·Git Hook 같은 도구를 세팅하고, 팀 동료의 질문 ("Kotlin 에 ESLint 같은 거 있.. 2026. 4. 17.
주문 대기열 시스템 설계: Redis Sorted Set의 내부 구조가 실시간 순번 조회를 가능하게 하는 원리 TL;DR — 트래픽 폭증 시 하류 시스템을 보호하면서 유저에게 공정한 순서를 보장하기 위해 Redis Sorted Set 기반의 주문 대기열을 구현했다. 처음에는 "Redis가 빠르니까"라는 이유만으로 충분하다고 생각했지만, 순번 조회(ZRANK)가 왜 O(log N)인지를 제대로 설명하지 못하는 자신을 발견했다. 그래서 Sorted Set의 내부 구현체인 스킵 리스트(Skip List)와 스팬(Span) 메커니즘까지 파고들었고, 그 과정에서 얻은 이해를 이 글에 정리한다. 1. 트래픽 제어의 필요성: Back-pressure 평소 초당 100건이던 주문 요청이 블랙 프라이데이 시작 직후 초당 10,000건으로 폭증하는 상황을 가정해 보았다. 이 트래픽이 주문 API로 직접 유입되면 어떤 일이 벌어질.. 2026. 4. 3.
뽀빠이 식당으로 보는 트래픽 몰림, Retry, 그리고 Idempotency 한 줄 요약같은 순간에 요청이 몰리면 시스템은 생각보다 쉽게 흔들릴 수 있습니다. 그래서 Exponential Backoff + Jitter, Token Bucket 같은 장치로 몰림을 나누어 보고, 결제처럼 상태를 바꾸는 요청에서는 Retry만 붙이기보다 Idempotency와 State를 함께 설계해야 한다고 생각합니다. 먼저 뽀빠이 식당 장면으로 Thundering Herd, Exponential Backoff + Jitter, Token Bucket을 가볍게 풀어 보고요. 그다음 결제 처리 예시를 보면서 Retry, Idempotency, Timeout, State가 왜 같이 묶여야 하는지 천천히 이어서 보려고 합니다. 사실 뽀빠이를 본적이 없습니다, 그저 그림이 귀여워서 예시로 삼아봤습니다왜 .. 2026. 3. 20.
읽기 최적화 관점을 중복 처리 이슈에 적용해 보면 무엇이 보이는가 TL;DR: 하나의 요청만 보냈다고 믿었던 결제 시스템이 왜 같은 거래를 두 번 처리하게 되었는지, 로그와 구조를 따라가며 끝까지 이해해 본 기록 이번 이슈를 다시 돌아보면서 가장 오래 남은 감정은, 나는 처음에 이 문제를 전혀 다른 방향으로 붙잡고 있었다는 약간의 당혹감이었다.처음의 나는 네트워크를 먼저 의심했다. 앞단 장비가 요청을 다시 보낸 것은 아닐까, 중간 프록시가 재전송한 것은 아닐까, 상대 시스템이 같은 요청을 잘못 두 번 처리한 것은 아닐까 같은 생각을 한동안 반복했다. 그렇게 생각한 이유는 분명했다. 내가 보고 있던 결제 시스템 로그에는 외부 적립 요청이 한 번만 찍혀 있었기 때문이다.그래서 처음에는 오히려 확신에 가까운 감정도 있었다. 적어도 내가 보고 있는 장면 안에서는 결제 시스템.. 2026. 3. 13.
인덱스와 캐시, 구조 개선을 통해 읽기 성능을 향상시키며 정리한 판단들 TL;DR: 이번 주차에서는 인덱스, likesCount 비정규화, 캐시, 쓰기 경로의 명시적 무효화를 통해 상품 조회 경로를 더 단순하게 만들고 읽기 성능을 개선하는 방향으로 구조를 정리했다. 이번 주차를 돌아보면서 내 머릿속에 가장 오래 남은 생각은, 읽기 성능 문제는 쿼리 하나만 고친다고 끝나지 않는다는 점이었다.상품 목록을 브랜드로 필터링하고, 좋아요 순으로 정렬하고, 같은 요청이 반복해서 들어오는 흐름을 보고 있으면, 문제는 단순히 더 빨라야 한다에 머무르지 않았다. 오히려 읽기 경로 자체를 더 단순하게 만들 필요가 있는 것 아닌가 하는 생각이 계속 남았다.이번 구현 과제는 바로 그 관점에서 인덱스와 캐시를 추가하고, likesCount를 비정규화하고, 쓰기 경로에 무효화 책임을 두면서 조회.. 2026. 3. 13.

티스토리툴바