야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장 Tech Blog Review 원문: RESTful API validation 자동화 하기 — 야놀자클라우드 Tech Blog, 이병준(키오스크 서버팀), 2022-01-11 야놀자의 현재 기술 블로그는 야놀자클라우드 Medium이고, 옛 주소 techblog.yanolja.com은 NOL 메인으로 리다이렉트된다. 그 Medium에서 백엔드 글을 고르면 이것이다. 2022년 글이... 2026/06/19 Yanolja 빅테크 기술 블로그 리뷰 41편
SLASH 23 리뷰 - Kafka 이중화로 다양한 장애 상황 완벽 대처하기: Active-Standby를 믿지 않고 Active-Active로 간 이유와 IDC 장애 당일의 순서 Conference 발표 SLASH 23, Data 트랙 연사 강병수 (토스증권 데이터 플랫폼팀 Data Engineer) 자료 세션 페이지 · 발표 영상 Toss Tech 3부작으로 정리된 Kafka 데이터... 2026/06/16 Toss 토스증권 엔지니어 발표 리뷰 5편
Security 필터 체인 - 인증과 인가는 실제로 어디에 꽂히는가 Notes Spring Security 설정이 안 먹을 때 디버깅이 어려운 이유는, 무엇이 어떤 순서로 도는지 안 보이기 때문이다. @PreAuthorize를 붙였는데 통과하거나, permitAll()을 줬는데 401이 나거나, CORS 프리플라이트가 막힌다. 셋 다 체인의 어디에서 처리되는가를 알면 설명된다. 구조: 서블릿 필터 하나가 스프링 빈들을 호출... 2026/06/14 Spring
네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정 Tech Blog Review 원문: 스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기 — NAVER D2, 조호영·김지한, 2026-01-22 한 줄 요약 10년 넘은 서비스의 데이터베이스를 Oracle에서 MySQL로 바꾸는데, 서비스를 멈출 수 없고 문제가 나면 바로 되돌릴 수 있어야 했다. 원문이 택한 답은 이중 쓰기다. 쓰기를 두 DB에 동시에 하되 새 ... 2026/06/14 Naver 빅테크 기술 블로그 리뷰 40편
G1과 ZGC가 p99에 남기는 차이 - 300배 짧은 pause가 꼬리의 11%를 가져갔다 실무 사례 Notes GC 알고리즘 비교는 각 수집기가 무엇을 포기하는지 문서를 근거로 정리한 글이다. 거기서 ZGC의 pause는 힙 크기와 무관하게 1ms 미만이라고 썼다. 사실이다. 그런데 그 문장은 “그래서 내 서비스의 p99가 얼마나 좋아지는가”에 답하지 않는다. pause 시간과 요청 지연은 같은 축이 아니다. 6ms pause가 0.7초에 한 번 있는 서버에... 2026/06/11 Java
GC 알고리즘 비교 - G1, ZGC, Shenandoah가 각자 무엇을 포기하는가 Notes GC를 고르는 일은 “가장 좋은 것”을 고르는 일이 아니다. 세 가지 목표(처리량, 지연, 메모리 사용량) 중 무엇을 포기할지 정하는 일이고, 알고리즘마다 포기하는 것이 다르다. 각자가 무엇을 내주는지 적어 두면 선택이 단순해진다. 모든 GC가 푸는 같은 문제 살아 있는 객체를 찾아 표시하고(mark), 죽은 객체의 공간을 회수하고(sweep)... 2026/06/09 Java
EMA 기반 이상 탐지 — 가격 급등과 거래량 서지 실시간 감지 “급등”을 어떻게 정의하는가 가격이 올랐다. 그게 급등인가, 정상 변동인가? 고정 임계값을 쓰면 문제가 생긴다. “3% 이상 오르면 급등”이라고 정의하면, 평소 변동폭이 0.5%인 삼성전자에서는 3%가 확실한 이상이지만, 변동폭이 5%인 중소형주에서는 3%가 노이즈다. 이상 탐지에는 상대적 기준이 필요하다. 최근 추이 대비 얼마나 벗어났는지를 봐... 2026/06/09 Realtime monticker 설계와 구현 기록 7편
SLASH 23 리뷰 - 실시간 시세 데이터 안전하고 빠르게 처리하기: Kafka 15ms 대 Redis Pub/Sub 3ms, 그리고 22,000 TPS에서 1ms를 만든 이벤트 루프 설계 Conference 발표 SLASH 23, Server 트랙 연사 정도원 (토스증권 마켓 플랫폼팀 Server Developer) 자료 세션 페이지 · 발표 영상 거래소 시세를 가장 먼저 받아 가공해 내부 서... 2026/06/04 Toss 토스증권 엔지니어 발표 리뷰 3편
TimescaleDB를 시계열 DB로 고른 이유 — Hypertable과 연속 집계 주식 데이터는 왜 특별한가 주식 시세 데이터에는 일반 OLTP(주문·회원처럼 행 단위로 읽고 고치는 트랜잭션 처리) 데이터와 다른 특성이 있다. 쓰기 패턴이 단조롭다. 항상 현재 시각 기준으로만 INSERT하고, UPDATE·DELETE는 거의 없다. 범위 쿼리가 지배적이다. “최근 1시간 데이터”, “어제 오전 9시~10시 사이 데이터”... 2026/06/04 Architecture monticker 설계와 구현 기록 3편
로그 컴팩션과 보존 - 상태 토픽이 보장하는 것과 하지 않는 것 Notes Kafka 토픽에는 두 가지 정리 정책이 있다. 기본은 시간이나 크기로 지우는 delete이고, 다른 하나가 키별 최신 값만 남기는 compact다(Topic Configs: cleanup.policy). 후자는 토픽을 “변경 로그”가 아니라 “현재 상태의 스냅샷”으로 쓸 수 있게 하는데, 그 보장의 범위가 생각보다 좁다. 두 정책의 차이 ... 2026/06/03 Infrastructure