푸른영혼의 별 | Tech Blog

Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.

주요 프로젝트: Settlement MSA · ASAT · GitHub


Posts (총 78편 · 1 / 8 페이지)

  • Lemuel 정산 플랫폼 아키텍처 분석 — 모노-MSA 하이브리드, Outbox, 헥사고날, Triple Idempotency

    5월 17일 새벽, 내 정산 프로젝트(코드명 Lemuel) 의 구조를 다시 들여다봤다. 헥사고날·이벤트 드리븐·MSA 같은 키워드를 말로만 쓰는 게 아니라 실제로 어떻게 구현됐는지 코드 단위로 검증하는 게 목적이었다.

  • AI agent를 잘 쓰는 법 — 6개월 동안 Claude Code와 함께 일하면서 배운 7가지

    ASAT(청각 재활 훈련 시스템)와 K3s 홈랩을 운영하는 동안 Claude Code 와 매일 함께 일했다. 처음에는 “코드 자동완성 좀 똑똑한 거” 정도로 썼는데, 6개월 지나니 작업 방식 자체가 바뀌었다 — 코드 직접 치는 시간은 줄고, agent 가 일을 잘 할 수 있는 환경을 만드는 시간이 늘었다.

  • K3s 홈랩 하루치 운영기 — Logstash 파이프라인, etcd leader 안정화, ECK 크래시 디버깅

    ELK 학습 목표 5가지 — 구축 / 자동 수집 / Logstash 변환 / ES 고급 집계 / Kibana 대시보드 — 를 한 번에 끝내려고 시작한 하루였는데, 중간에 클러스터 부하 spike·etcd leader 변동·ECK operator 크래시 루프까지 줄줄이 만나서 결국 종합적인 운영 회고가 됐다.

  • 정산 관리자 페이지가 빈 화면이 된 이유 — MSA 전환 중간 단계가 만든 4층 도미노

    저녁 10시 반, 텔레그램에 한 줄짜리 신고가 들어왔다.

  • ELK 'monitoring 45건' 알람의 정체 — 모니터링이 자기를 알람하는 메타-함정

    오후 2시, 텔레그램에 알람이 떴다:

  • Load 12인데 CPU 60% Idle? — Linux loadavg가 거짓말하는 순간

    K3s 마스터 노드 르무엘에서 부하 스파이크를 추적하던 중, 새벽 2시 51분에 Load Average 12.28 / 4 cores 알람이 떴다. 4코어 머신에서 Load 12면 300% — 본능적으로 “이건 죽기 직전이다”라고 생각하게 된다. 그런데 같은 시각에 잡은 vmstat 출력은 정반대였다:

  • Load 5.09 → 0.92, sed 한 줄로 — K3s coredns Addon 재적용 무한루프 잡기

    5/15 밤, 텔레그램 서버모니터 봇이 르무엘(K3s 마스터 노드, 4코어/31GB) CPU 부하를 4번 연속 ⚠️로 표시했다. 첫 알람은 가볍게 봤는데 두 번, 세 번 계속 떴고, 간격이 점점 짧아지고 강도가 점점 세지는 패턴이었다. 결국 마지막 알람은 Load 5.09 / 4 cores (127%). 라이브로 잡고 들어가 보니 원인은 docker 런타임도, etcd compaction도 아닌 — K3s Addon controller가 매니페스트 한 줄 때문에 15초마다 재적용을 시도하고 매번 실패하는 무한루프였다.

  • 쿠버네티스 운영 함정 4가지 — 하룻밤 디버깅 노트

    5/15 저녁 텔레그램 알림으로 시작된 한 통의 메시지 — “⚠️ Pod 132개 중 4개 CrashLoopBackOff”. 이 한 줄에서 출발해 자정 넘어까지 4가지 서로 다른 종류의 함정에 빠졌다 빠져나왔다. 각각의 함정이 K3s/K8s 운영하는 사람이라면 한 번쯤은 만나는 패턴이라 정리해둔다.

  • 쿠버네티스 × ELK — 둘이 같이 굴러야 하는 이유, 실제 운영 시나리오, 기대 효과

    쿠버네티스에 ELK 를 붙이는 건 단순히 “로그 좀 보기 좋게” 가 아닙니다. 컨테이너 워크로드의 운영 구조 자체 가 로그 집계 시스템을 필수 부품으로 요구합니다. 어제 5-노드 K3s 홈랩에 ECK 기반 ELK 스택을 깐 후 일주일도 안 됐는데, 이미 운영 패턴이 달라진 게 체감됩니다. 둘의 상관관계, 실 운영 시나리오, 그리고 기대 효과를 정리합니다.

  • Jenkins vs GitHub Actions — Docker 빌드부터 Kubernetes 배포까지 자동화 실전 비교

    CI/CD 도구를 처음 고르는 분, 또는 Jenkins 만 알다가 GitHub Actions 로 넘어가려는 분, 반대로 Actions 만 써본 분이 사내 Jenkins 와 마주쳤을 때 — 결국 같은 질문에 부딪힙니다. “내 코드 push 가 어떻게 컨테이너가 되고, 어떻게 Pod 으로 돌아가나?”