푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 138편 · 1 / 14 페이지)
-
쿠버네티스 시대의 @Scheduled 함정 — replicas: 1 에서도 ShedLock 이 필요한 *세 가지* 이유, 그리고 settlement·lemuel-xr 의 7 scheduler 실전 도입기
K3s 클러스터에 60+ prod 서비스 를 운영하면서 어느 날 stat 을 봤다:
-
Jira 의 *5 핵심 키워드* — *Sprint · Story Point · Velocity · Burndown · Release Tracking* 을 *PM · PL · 팀원 · 비개발자* 가 *각자 다르게 *보는 법, 그리고 *4 명 팀의 *실전 *구성*
’‘Story Point 가 시간이 *아니라고요? 그럼 *시간을 *어떻게 *추정해요?”“. 주니어 *백엔드가 *처음 *Jira 를 *마주칠 때 *가장 *자주 *던지는 *질문이다. *답하기는 *어렵지 *않다 — *’‘Story Point 는 상대적 *복잡도 일 뿐, *시간은 *Velocity 가 *알려준다”“. 하지만 그 *답의 *진짜 *깊이는 *’‘같은 Jira 화면을 *PM 과 *PL 과 *팀원과 *비개발자가 *서로 *완전히 *다르게 *본다”” 는 *사실에 있다.
이 글은 Jira 의 *5 가지 *핵심 *키워드 — Sprint · Story Point · Velocity · Burndown · Release Tracking — 를 *원리 부터 *풀고, 그것을 *4 개의 *역할 (PM · PL · 팀원 · 비개발자) 이 *각자 *어떤 *질문에 *답하기 위해 보는지 대조한 뒤, *마지막에 *’‘PM 1 + PL 1 + 팀원 2””* 의 작은 팀이 *Jira 를 *처음부터 *세팅 하는 *실전 *순서 까지 *연결한다.
-
5노드 K3s 홈랩 *146 pod 분해* — 9개 카테고리·배포 방식·운영 흐름 분석
5노드 K3s 클러스터 안에서 146 개 pod 가 동시에 굴러간다. 몇 개는 인프라, 몇 개는 GitOps, 몇 개는 관측성, 몇 개는 실제 비즈니스 서비스. 한 클러스터에 너무 많은 종류 가 섞여있어서 전체 그림이 안 보일 때 가 많다.
-
정산 시스템 *어떻게 동작하나* — 헥사고날 MSA + Outbox + Triple Idempotency + 분산 트레이싱
결제 정산 시스템 은 돈을 다루는 흐름 이라 “한 번 더 결제 / 한 번 덜 정산” 같은 작은 실수가 큰 사고 가 된다. 분산 시스템 의 고전적 어려움 들 — 트랜잭션 경계, 멱등성, 재시도, DLQ, 추적성 — 이 전부 한 자리 에 등장한다.
-
K3s 5 노드 홈랩 — *트래픽이 *몰릴 때 *어디부터 *터지나*, 그리고 *예방 *대책*
’‘홈랩이니까 부담 없겠지”“. 맞는 말 같지만 *완전히 *틀리기도 한다. 내 K3s 위에 *Cloudflare Tunnel 을 *달면 *그 순간부터 *’‘인터넷 전체’’* 가 내 5 노드 클러스터를 *때릴 수 있는 *외부 표면이 *된다. AWS 처럼 *알아서 *오토스케일링 하지 않는 *환경에서 *트래픽 *피크가 *오면 *어디부터 *터지고, *어떻게 *살아남게 *설계할 것인가 가 ’‘홈랩 운영자의 진짜 *공부”“.
이 글은 5 노드 K3s 홈랩 (lemuel / louise / david / ilwon / solomon, WiFi 운영) 위에 Cloudflare Tunnel + Traefik + 다수의 서비스 가 얹혀있는 *실제 상황 에서 트래픽이 *몰릴 때 *어디부터 깨지는가 를 층층이 *해부 하고, *각 층의 *예방 대책 *을 *’‘돈 안 들이고 할 수 있는 것 → 돈 드는 것”” 순서로 본다.
-
SOLID 원칙 × 디자인 패턴 — *결제 처리 시스템* 으로 보는 *왜 그 패턴이 그 자리* 인지
“SOLID 5원칙 외웠고 GoF 23개 패턴도 안다. 근데 실전에서 어디에 써야 할지 모르겠다.” — 이게 교과서로만 배운 사람의 가장 흔한 막힘.
-
개발 프로세스 60년 — *변하는 것* 과 *변하지 않는 것*, 그리고 *좋은 문화* 를 넘어 *훌륭한 문화* 란 무엇인가
“우리 팀은 애자일 합니다” 라는 문장은 어떤 회사도 부정하지 않는다. 그런데 같은 팀에서 3개월에 한 번 배포하는 데가 있고 하루 50번 배포하는 데가 있다. 같은 Scrum 을 하는데 어떤 팀은 spec 한 줄에 일주일 토론하고 어떤 팀은 PRD 없이 직접 만든다.
-
Grafana 의 *3종 데이터소스* — Prometheus (메트릭) · Elasticsearch (로그) · Tempo (트레이스) 의 *제대로 된* 사용법
홈랩 K3s 의 Grafana 에 3종 데이터소스 가 붙어있다. Prometheus (메트릭), Elasticsearch (로그), Tempo (트레이스). 셋 다 3대 옵저버빌리티 기둥 으로 유명한데, Grafana 안에서 함께 쓸 때의 진짜 가치 는 각자가 답하는 질문 이 다르고, 셋이 연결될 때 1+1+1 > 5 가 된다는 거다.
-
ArgoCD · Grafana · Kibana — *실제로 봐야 하는* 화면은 어디인가 (운영자 관점 고찰)
K3s 홈랩에 세 대시보드 가 들어가 있다. ArgoCD 는 배포 상태, Grafana 는 메트릭, Kibana 는 로그. 셋 다 설치하면 멋있어 보이지만, 실제로는 3개월 뒤 에 한 번도 안 켜본 탭이 두 개 정도 생긴다. 왜 그렇게 되는지, 진짜 봐야 할 것 은 무엇인지 — 운영하면서 만들어진 판별 기준 을 적는다.
-
Java vs Kotlin — 코드량·기업 ROI·손익분기점 관점의 비교, 그리고 Claude Code 시대에 *어느 언어가 AI 와 더 시너지* 인가
Kotlin 이 Java 대비 코드 40% 짧다 는 말, 매우 자주 듣는다. 진짜인가? 그게 기업 ROI 로 환산하면 얼마인가? 그리고 *Claude Code 시대 에 AI 가 어느 언어를 더 잘 만들고, 우리는 어디에 시간 투자해야 하나?