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