푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 584편 · 1 / 59 페이지)
-
사고는 층과 층 사이에서 난다 — 홈랩 K3s 장애를 '어느 문서를 안 읽었나'로 분류했다
0. 질문을 정확히 세운다
-
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자 요약 블로그는 인용하지 않는다.
-
쿠버네티스 구조는 배치도가 아니라 계약이다 — 6노드 클러스터를 해부해 다시 그렸다
쿠버네티스 구조를 물으면 대부분 같은 그림을 그립니다. 왼쪽 박스에 API Server·Scheduler·Controller Manager·etcd, 오른쪽 박스에 kubelet·kube-proxy·컨테이너 런타임. 저도 그렇게 배웠고 1일차 노트에 그렇게 적었습니다.
-
GPU 0장짜리 홈 클러스터를 쿠버네티스 AI 컨포먼스로 채점했다 — 9개 MUST 중 절반은 GPU와 무관하게 떨어진다
“쿠버네티스와 AI”를 검색하면 대부분 GPU 이야기가 나온다. GPU 노드풀, MIG 파티셔닝, 타임슬라이싱. 그래서 GPU가 한 장도 없는 내 홈 클러스터는 이 주제와 무관하다고 생각했다.