푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1371편 · 122 / 138 페이지)
-
Datadog vs 무료 Observability Stack — 비용·시간 효율의 *손익분기점* 분석 (Prometheus·Grafana·Loki·Tempo·Alertmanager)
Datadog 한 달 청구서 5,000 만원. 스타트업 CTO 들이 2026 년에도 자주 듣는 충격. 그 5,000 만원의 실제 가치 는 얼마인가? Prometheus + Grafana + Loki + Tempo 무료 stack 으로 같은 가시성 을 얻는 데 진짜 비용 (셋업 시간 + 운영 시간 + 클러스터 자원) 은 얼마인가?
-
MySQL DB 안정성 *7대 기둥* — 백업·HA·성능·스키마·모니터링·변경관리·보안
“우리 DB 는 *안정적 이에요”* 라는 문장은 기준이 모호 하다. 어느 누군가에겐 “99.9% uptime” 이고, 또 다른 사람에겐 “매일 슬로우 쿼리 알람 안 옴”. 진짜 DB 안정성 은 7 가지 차원의 합 인데, 한두 개만 잘하고 다른 데 구멍 이 있으면 그 구멍으로 다 무너진다.
-
Java 21 Virtual Threads 실전 사례 5 가지와 Kotlin Coroutines 비교 — 같은 *Continuation* 이 만든 *두 결말*
Java 21 의 Virtual Threads (Project Loom, 2023) 와 Kotlin Coroutines (2018) 는 같은 문제 를 같은 메커니즘 (continuation) 으로 풀지만, 언어 철학 의 차이 때문에 전혀 다른 사용자 경험 을 준다. 둘이 경쟁 인지 상호보완 인지가 2026 년 백엔드 개발자의 핵심 질문.
-
서비스 안정성과 고도화 — *측정 → 자동화 → 회복 → 학습* 루프, 그리고 오늘 logistic-prod / fashion-prod / pg-backup 실전 사고 4 건의 진단 과정
서비스 안정성 (reliability) 과 고도화 (evolution) 는 두 별개의 일처럼 보이지만 본질은 같다 — 반복 가능한 측정·자동화·회복·학습 루프 이다. 안정성 없는 고도화는 사상누각, 고도화 없는 안정성은 정체. 오늘 내 K3s 클러스터에서 4 개 사고 가 동시 발생했고, 그 진단 흐름 자체가 안정성·고도화 루프의 살아있는 교과서 였다.
-
모니터링 5대 도구 비교 — Datadog · Grafana · Prometheus · 제니퍼 · Netdata *언제 어느 것*
“모니터링 뭐 써요?” 의 답이 “우리는 X 써요” 한 단어로 끝나면 위험 신호. 실은 5~10 개 도구가 *서로 다른 층 에서 굴러가야* 한다. 그리고 어느 도구가 어느 층에 맞는지 결정이 비용·운영 부담·SLA 의 80% 를 좌우한다.
-
낙관적 락 vs 분산 락 — *언제 어느 것* 을 써야 하나 (Spring + JPA + Redis 실전)
“동시성 문제 어떻게 막아요?” 의 첫 답은 거의 항상 “락 걸어요”. 그런데 어떤 락 이냐가 그 시스템의 성능 / 안정성 / 비용 을 좌우 한다.
-
*홈랩 K3s · AWS · Cloudflare* — *로드밸런서와 *오토스케일링의 *가능성을 *3 인프라에서 *비교 *고찰*
사설망 주소는
<lan>·<mgmt>로 가렸다. 호스트 옥텟과 각 줄의 의미는 원본 실측 그대로다. -
쿠버네티스 시대의 @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, 몇 개는 관측성, 몇 개는 실제 비즈니스 서비스. 한 클러스터에 너무 많은 종류 가 섞여있어서 전체 그림이 안 보일 때 가 많다.