푸른영혼의 별 | Tech Blog

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

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


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

  • [보고] 2026-09-13 르무엘 클러스터 아침 브리핑

    1. 개요

    2026년 9월 13일 오전 9시 기준 르무엘 클러스터 상태 브리핑입니다. louise 노드의 NotReady 상태와 이와 연동된 주요 엔드포인트 및 Job 실패가 관측되었습니다.

  • 르무엘 클러스터 일일 RCA 리포트 (2026-09-13)

    1. 개요

    본 리포트는 k8s-rca-daily.sh가 수집한 2026-09-12~13 기간의 Trace를 바탕으로 르무엘 클러스터의 상태를 분석한 결과입니다.

  • [데일리 브리핑] 2026-09-13 AI, Kubernetes 및 기술 동향

    🚀 AI & Machine Learning

  • 리눅스는 공짜인데 RHEL 은 무엇을 파는가 — 무료판·유료판 비교와 구독이 필요한 순간

    앞 글에서 오라클·웹로직·JBoss 의 유료 필요성을 따졌다. 그 연장선에서 자연스러운 다음 질문 — OS 층은 어떤가. 리눅스 커널은 GPL v2 자유 소프트웨어이고 우분투는 공짜로 설치하는데, Red Hat Enterprise Linux(RHEL) 구독은 공식 스토어 기준 서버 한 대에 연 $383.90 부터 시작한다. 코드가 무료인 세계에서 이 돈은 무엇에 대한 값이고, 언제 낼 가치가 있는가. 미들웨어 편과 같은 두 관점 — 개발·운영자 관점과 비용 관점 — 으로 정리한다.

  • 오라클·웹로직·JBoss 는 아직 필요한가 — 개발자의 관점과 비용의 관점

    한국 SI·금융권에서 “엔터프라이즈 자바”는 오랫동안 하나의 정형이었다. DB 는 오라클, WAS 는 웹로직 아니면 JBoss, 그 위에 자바 애플리케이션. 셋 다 돈을 내는 제품이고, 그 비용은 시스템 규모에 따라 수억 원 단위로 커진다. 그런데 지금 새 시스템을 설계한다면 이 셋에 돈을 낼 이유가 얼마나 남아 있을까. 자바 백엔드 개발자의 관점과 비용의 관점, 두 축으로 따져 본다.

  • systemctl --failed 가 못 보는 failed 유닛 — snap 유저 데몬 정리기

    홈랩 K3s 노드들의 저널을 훑다가 이상한 것을 봤다. 저널에는 snap.firmware-updater.firmware-notifier.service 가 매일 새벽 3시에 5번 죽고 포기하는 기록이 또렷한데, 정작 systemctl --failed0 loaded units 로 깨끗했고 journalctl -u snap.firmware-updater.firmware-notifier.service 도 빈 결과를 돌려줬다. 유닛이 실패하고 있는데 표준 점검 명령 두 개가 모두 “그런 유닛 없다”고 답하는 상황 — 이 글은 그 사각지대의 정체와, 두 노드에서 각각 다른 원인으로 죽고 있던 이 서비스를 정리한 기록이다.

  • 신호는 -56 dBm 로 멀쩡한데 비콘을 90번 놓쳤다 — dBm 만 보면 안 되는 이유

    집에서 K3s 6노드를 전부 무선으로 굴리고 있다. 한 노드가 자꾸 NotReady 로 떨어져서 무선 링크 통계를 떠봤는데, 숫자가 직관과 정반대였다.

  • sealed 와 record 는 실무에서 무엇이 되는가 — 자바 17의 ADT, 코틀린과 나란히 놓고 보기

    자바 17의 sealed class(JEP 409)와 자바 16의 record(JEP 395)는 따로 보면 각각 “상속 제한 문법”과 “보일러플레이트 절감 문법”처럼 보인다. 하지만 실무에서 이 둘은 거의 항상 한 세트로 쓰인다. 둘을 합치면 함수형 언어들이 대수적 데이터 타입(ADT)이라 부르던 것 — “이 타입의 값은 정확히 이 몇 가지 모양 중 하나다”라는 선언 — 이 자바에 들어오기 때문이다. 코틀린은 같은 자리를 sealed class + data class 로 먼저 채웠다. 이 글은 실제 운영 코드에서 두 기능이 어떤 모습으로 쓰이는지 정리하고, 코틀린과 어디가 같고 어디가 다른지 비교한다.

  • 스왑은 비상 메모리가 아니다 — 서버는 왜 스왑을 끄고, 리눅스는 왜 스왑을 옹호하는가

    새벽에 홈랩 K3s 노드를 점검하다가 익숙한 장면을 만났다. RAM 30GiB 중 21GiB 사용, 스왑 0B. Elasticsearch JVM 두 개와 Logstash, Prometheus가 메모리의 절반을 먹고 있는 노드다. “스왑이 없네, 위험한 거 아닌가?”라는 질문이 자연스럽게 나오지만, 답은 생각보다 재미있다. 이 상태는 쿠버네티스 세계의 표준이면서, 동시에 리눅스 메모리 관리 관점에서는 오랜 논쟁거리다. 이 글은 그 양쪽 논리를 1차 출처 기준으로 정리한다.

  • Java 8·11·17의 발전과 Java 21·25 대비 차이

    Java 8·11·17의 발전과 Java 21·25 대비 차이