푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 662편 · 1 / 67 페이지)
-
@Async 를 튜닝하다가 @Async 를 떠난 78분 — settlement 의 ThreadPoolTaskExecutor 이력
ThreadPoolTaskExecutor를 설명하는 글은 대개corePoolSize/maxPoolSize/queueCapacity세 숫자를 어떻게 잡느냐로 끝난다. 그런데 내 settlement 리포에 남은 실제 이력은 그 방향이 아니었다. 숫자를 고치고, 풀을 쪼개고, 거부 정책을 바꾸고 — 78분 뒤에 그 작업 자체를@Async밖으로 들어냈다. -
핀이 사라진 뒤에도 ReentrantLock 이 남은 두 자리 — settlement 실측
Java 21 이 가상 스레드를 내놓았을 때 딸려 온 숙제가 하나 있었다.
synchronized안에서 블로킹하면 가상 스레드가 캐리어 플랫폼 스레드에 핀(pinned) 되어 못 내려온다는 것. JEP 444 는 아예 이렇게 적어 뒀다. -
레플리카가 3개인데 ConcurrentHashMap 을 믿었다 — settlement 의 7개 사용처를 전수 조사했다
ConcurrentHashMap(이하 CHM)은 “동시성 걱정 없이 쓰는 Map” 으로 배운다. 그 문장은 절반만 맞다. CHM 이 보장하는 것은 한 프로세스 안에서, 한 번의 메서드 호출이 원자적이라는 것뿐이다. 프로세스가 늘어나면 보장은 프로세스 수만큼 쪼개지고, 호출이 두 번이 되면 그 사이는 아무도 지켜주지 않는다. -
CompletableFuture 를 본문 3개 파일에만 쓴 이유
정산 시스템(
settlement) 전체에서CompletableFuture를import하는 곳은 31군데다. 그중 테스트를 빼면 본문은 3개 파일뿐이고, 그 3개는 전부 같은 이음매에 붙어 있다 — outbox 레코드를 Kafka 로 내보내는 발행 경로. -
양쪽 다 초록인데 가운데가 끊겨 있었다 — 포인트 적립 왕복을 끝단까지 붙여 보고
이벤트 프로모션(출석체크·럭키박스)을 별도 서비스로 떼어내는 중이었다. 보상 포인트는 이 서비스가 직접 지급하지 않는다. 원장은 주문 서비스가 쥐고, 마케팅은 “지급해 달라”는 이벤트만 낸다. 적립이 실제로 성사되면 주문 서비스가 다시 이벤트를 돌려주고, 그걸 받아야 보상이 확정된다.
-
jakubkrehel/skills 뜯어보기: 인터페이스 품질을 11개 스킬로 쪼갠 저장소
jakubkrehel/skills 는 “인터페이스를 잘 만들도록 돕는” 에이전트 스킬 모음이다. 타이포그래피·색·레이아웃·접근성·UX 라이팅 같은 디자인 엔지니어링 지식을 에이전트가 읽을 수 있는 형태로 정리해 두었다.
-
내 인프라를 한 문단으로 소개하고, 그 문단을 전부 재봤다
홈랩 클러스터를 남에게 소개할 때 쓰는 문단이 있다.
-
무기한 예외를 문법적으로 불가능하게 만들기 — 가드 19종을 직접 돌려봤다
정산 서비스에 규칙 엔진 하나(
guard.mjs)를 붙여 두고 쓴 지 좀 됐다. 설명은 여러 번 했는데 실제로 무엇을 통과시키고 무엇을 막는지 재본 적은 없어서, 오늘 직접 돌려봤다. 결과부터 적으면 제일 잘 만든 부분은 규칙이 아니라 예외 처리였고, 설명과 실제가 어긋난 곳도 두 군데 나왔다. -
카프카는 예외도 로그도 없이 조용히 잃는다 — 정산 시스템이 실패를 시끄럽게 만드는 여섯 지점
HTTP 는 실패할 때 시끄럽다. 500 이 뜨고, 스택트레이스가 남고, 호출한 쪽이 즉시 안다.
-
319단어 대 28만 줄 — grill-me 와 우로보로스는 같은 실패를 반대편에서 막는다
grill-me와 우로보로스(Ouroboros)를 비교해 달라는 요청을 받고 둘을 나란히 열어봤다. 둘 다 “에이전트 하네스” 라는 말로 뭉뚱그려 불리는데, 열어보니 크기가 우스울 정도로 다르다.