푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 915편 · 34 / 92 페이지)
-
[Briefing] 2026-08-14 AI·Kubernetes·보안·금융 기술 동향
매일 아침 최신 기술 동향을 요약하여 전달해 드립니다. 오늘은 특히 머신러닝·딥러닝의 최신 논문과 릴리스, 그리고 Kubernetes v1.37 소식을 중점적으로 다룹니다.
-
사고는 층과 층 사이에서 난다 — 홈랩 K3s 장애를 '어느 문서를 안 읽었나'로 분류했다
0. 질문을 정확히 세운다
-
쿠버네티스라는 이름은 어디서 왔나 — 마지막 날 차 안에서 정한 이름이 하필 제어이론의 어원이었던 사건
쿠버네티스라는 이름은 출시 마감 전날, 출근길 차 안에서 정해졌다. 앞선 13개 후보가 전부 법무팀에서 반려된 뒤였다. 그런데 그렇게 급하게 고른 그리스어 단어가, 하필이면 제어이론(control theory)의 어원이었다. 이름이 나중에 아키텍처를 따라잡은 게 아니라, 아키텍처가 이미 그 이름이었다.
-
AI 에이전트에서 얻을 수 있는 것은 모델 바깥에 있다 — 세션 7개에 모델 이야기가 한 줄도 없는 세미나 프로그램
-
다음 모델이 나오면 무엇이 만료되고 무엇이 남는가 — 에이전트 자산을 감가상각으로 분류한다
-
말 그리기 5단계와 소프트웨어 방법론 — MVP 부터 완성까지, 폭포수와 애자일을 다시 비교한다
-
컨슈머는 코드에 있는데 브로커엔 그룹이 없다 — settlement 카프카를 '강제 장치의 경계선'에서 읽었다
같은 시스템의 카프카를 오늘 두 번 읽었다. 한 번은 브로커가 무엇을 갖고 있나를 보려고(카프카 구조는 설계도가 아니라 브로커에 남는다), 이 글은 무엇이 그 상태를 강제하고 있나를 보려고 읽었다.
결론부터. settlement 는 정합성을 문서로 부탁하지 않고 기계로 강제한다 — 계약 테스트, 커밋 훅 린트, DB UNIQUE 3단. 그런데 오늘 실측으로 남아 있는 카프카 결함은 하나도 빠짐없이 그 강제 장치가 닿지 않는 바깥쪽에 있었다. Helm 환경변수 한 줄, 브로커 기본값, 3일 전까지 Git 에 없던 CR.
-
Java/Spring & AI 데일리 브리핑: 2026-08-13
오늘의 Kubernetes·클라우드 네이티브 동향
-
카프카 구조는 설계도가 아니라 브로커에 남는다 — settlement 토픽 38개를 실측해 다시 그렸다
설계 문서에는 “이벤트 기반 아키텍처”라고 적혀 있다. 그런데 브로커에 붙어서
kafka-topics.sh --describe를 때려보면, 문서에 없는 토픽이 나오고, 문서에 있는 토픽에는 컨슈머가 없다. 이 글은 settlement 의 카프카를 코드가 아니라 실행 중인 브로커에서 읽어 구조를 다시 그린 기록이다. -
한국 기업의 쿠버네티스 사용 사례를 1차 출처로만 읽어봤다 — 공통점은 '클라우드로 갔다'가 아니었다
“국내 쿠버네티스 도입 사례”를 검색하면 상당수가 컨설팅사·솔루션 벤더의 요약 글이다. 그래서 이번에는 규칙을 하나 정하고 읽었다. 회사가 자기 이름으로 쓴 기술 글, CNCF 공식 케이스 스터디, KubeCon 공식 세션 프로그램만 본다. 제3자 요약 블로그는 인용하지 않는다.