푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 276편 · 4 / 28 페이지)
-
*Prometheus* 가 *수집* 하고 *Grafana* 가 *대답* 한다 — *서버 죽었나?* 5 가지 질문 의 *PromQL + 대시보드*
“지금 서버가 죽었나?” — 새벽 3 시 에 이 질문 에 5 초 안 에 답할 수 있어야 운영 이다.
Prometheus 와 Grafana 의 짝 은 그 질문 의 표준 답 이 되었다. 그런데 둘이 어떻게 협업 하는지 — Prometheus 가 *무엇 을 *어떻게 수집 하고, Grafana 가 *그것 을 *어떻게 *질문 으로 변환 하는지* — 를 *모르면 대시보드 는 *예쁜 그래프 의 *모음 일 뿐, 진짜 질문 에 *답하지 못한다.
이 글은 8 가지 핵심 메트릭 (CPU / Memory / Disk / HTTP 요청 수 / 에러율 / 응답 시간 / DB 커넥션 / 컨테이너 상태) 이 Prometheus 로 *어떻게 수집 되는지, 그리고 Grafana 가 *5 가지 운영 질문 — 지금 서버가 죽었나? CPU 가 너무 높나? 응답이 느려졌나? 에러율이 올라갔나? 트래픽이 늘었나? — 에 어떻게 답하는지 를 PromQL 한 줄 한 줄 까지 분해 한다.
-
*Virtual Thread* 와 *Carrier Thread* 의 *관계* — *mount / unmount* 메커니즘 과 *pinning* 의 *물리*
“Virtual Thread 는 경량 스레드 다” — 맞는 말 이지만 반쪽 짜리 설명 이다. Virtual Thread 가 *경량 인 이유 는 그 자체로 *가벼워서 가 아니라 실제로 *CPU 를 *돌리는 스레드 가 *따로 있기 때문 이다.
그 따로 있는 스레드 가 Carrier Thread — 플랫폼 스레드 (전통적인 OS 스레드) 의 작은 풀. 수십만 개 의 Virtual Thread 가 수십 개 의 Carrier Thread 위에서 돌아 가며 *마운트 / 언마운트 된다.
이 마운트 / 언마운트 가 *어떻게 작동 하는지 모르면 —
synchronized하나 가 전체 carrier pool 을 잠궈서 Virtual Thread 의 *모든 이점이 *사라지는 *pinning 의 물리적 이유 를 이해 할 수 없다.이 글은 JDK 21 (JEP 444 finalized) ~ JDK 24 (JEP 491) 기준 으로 Virtual Thread 와 *Carrier Thread 의 관계 — Continuation primitive, mount/unmount 시점, pinning 의 *원인 과 *처방, carrier pool 크기, 실전 안티 패턴 — 까지 런타임 관점 에서 분해 한다.
-
*I/O 병목* 어떻게 *해결* 하지? — *디스크 / 네트워크 / DB* 의 *공통 패턴* 과 *층별 처방*
“코드 는 *맞는데 느리다”* — 백엔드 가 *느린 *원인 의 *90% 는 연산 이 *아니라 *I/O 다.
디스크 읽기 80 μs. DB 쿼리 한 번 5 ms. HTTP 외부 호출 한 번 50 ms. CPU 가 *0.25 ns 안에 한 사이클을 도는 4 GHz 시대 에 I/O 한 번 은 수십만 ~ 수억 사이클 을 기다리는 일 이다.
그런데 I/O 병목 은 CPU 처럼 *한 가지 자원 이 아니다. 디스크 / 네트워크 / 데이터베이스 / 파일시스템 / 메모리 매핑 — 서로 다른 *물리적 자원 이 서로 다른 *방식으로 *터지고, 해결책 도 각자 *다르다.
이 글은 I/O 병목 의 *6 가지 패턴 을 진단 → 원인 → 처방 으로 정리하고, Spring Boot / JVM 워크로드 에서 실제로 손이 가는 *해결책 을 층별 로 분해한다.
-
*프로세스* 라는 *추상화* — *CPU · 메모리 · 스레드 · 코어* 가 *어떻게 한 점* 에서 만나는가
CPU 에서 시작 해 보자. 성능 코어 8 + 효율 코어 4. 메인보드 의 *커패시터 는 수명 을 결정한다. *메모리 는 휘발성 이지만 수십 년 가는 반도체. 프로그램 은 디스크 위의 파일. 그런데 — 파일 이 어떻게 동작 하는가. 디스크 의 *바이트 더미 가 어떻게 *키 입력 에 반응 하고 네트워크 패킷 을 받아 *DB 에 쓰는 동적 존재* 가 되는가.
그 변환점 이 프로세스. 정적 파일 → 동적 실행 의 경계. 그리고 *프로세스 안 에서 스레드 가 진짜 일 을 코어 에 던진다.
-
*IntelliJ IDEA 가 켜질 때 도대체 *무엇이 *실행되는가* — *SSD · 메모리 · CPU* 관점 의 *기동 해부*
Dock 아이콘 을 클릭한다. 스플래시 가 뜬다. Welcome 창 이 나타나기까지 3~10 초. 그동안 내 맥 의 CPU 팬 이 잠깐 돌고, SSD 활성 LED 가 깜빡인다.
그 안에서 *무슨 일이 일어나는가. 왜 그렇게 *오래 걸리는가. 왜 *프로젝트 열고 30 초간 CPU 4 코어가 100% 인가. 왜 *idea.vmoptions 의 -Xmx 를 키우면 체감 속도 가 빨라지는가.
-
*CPU 의 *L1 / L2 / L3 캐시* — *메모리 벽* 과 *병목 구간* 에 대한 *고찰*
“CPU 가 빠르다” 는 말 은 반쪽 짜리 진실 이다. CPU 는 *빠르지만, 그 CPU 가 *기다리는 시간 의 대부분은 메모리 다. 현대 CPU 의 *코어 클럭 은 4~5 GHz — 즉 0.25 ns 안에 한 사이클 을 돌린다. 그런데 DRAM 접근 은 80~120 ns — 그 사이 CPU 는 *400 ~ 500 사이클 을 놀고 있다.
이 격차를 메모리 벽 (Memory Wall) 이라고 부른다. 캐시 (L1 / L2 / L3) 는 그 벽 을 *조각조각 *허무는 *3 단계 *완충재 다. 각각 *얼마나 *빠르고, 얼마나 *크고, 어떻게 *공유 되고, 어디서 *병목 이 터지는지 — 그 구조 를 모르면 성능 튜닝 은 추측 게임 이 된다.
이 글은 L1 / L2 / L3 의 *물리적 / 논리적 차이, 현대 워크로드 의 *6 가지 캐시 병목 패턴, 측정 도구, 완화 패턴 을 런타임 관점 에서 정리한다.
-
*쿠버네티스를 *바라보는 *방법* — *Pod 는 *Deployment / ReplicaSet / Service / ConfigMap / Secret / Volume* 위에서 *돈다*
“Pod 가 *그냥 *컨테이너 다” 라고 생각하는 사람과 *“Pod 가 *그 모든 것 위에서 *돈다” 라고 생각하는 사람은 *클러스터 를 *완전히 다르게 *본다.
쿠버네티스는 Pod 하나 만 *보면 *YAML 한 장 이지만, Pod 가 *살아 있게 하는 *모든 것 을 보면 *6 개 의 *서로 다른 *층 이 있다. 그 6 개 가 각자 *책임 을 나눠지고 *맞물려야 Pod 가 *production 에서 돈다.
이 글은 Deployment / ReplicaSet / Service / ConfigMap / Secret / Volume 이 Pod 위 / 옆 / 아래 에서 각자 *무엇을 책임지는지 를 런타임 관점 에서 분해 한다.
-
*바이브 코딩* 과 *AI 시대 시니어 개발자* 의 *7 가지 기준* — *위임 못하는 영역* 의 명세
친구가 메시지를 보냈다 :
7 가지를 적었다. 도메인 경계 / AI 지시 / 코드 리뷰 / 장애·보안·성능 / 테스트 전략 / 운영 구조 / 비즈니스 번역. “이게 AI 시대 의 *남는 역할 이지 않나“*.
이 7 가지를 보다가 놀랐다. 모두 *바이브 코딩 의 *정확한 반대편 에 있었다*.
-
*8 가지 체크리스트* 로 *내 정산 시스템* 을 *자가 검수* 했다 — *동시성 / 트랜잭션 / 보안 / N+1 / 재처리 / 로그 / 예외 / 도메인 규칙*
“운영해 본 적 없는 코드 는 *서비스 가 *아니다.”*
주문·결제·정산 처럼 돈 이 흐르는 시스템 은 코드를 *짠 사람조차 *모르는 사이 조용히 *깨진다. 동시성 / 트랜잭션 / 보안 / N+1 / 재처리 / 로그 / 예외 / 도메인 규칙 — 8 가지 영역 을 체크리스트화 하지 않으면 모르는 사이 가다가 *터진다.
이 글은 내 settlement (이커머스 정산 MSA, Spring Boot 4 hexagonal) 를 그 8 가지 체크리스트 로 자가 감사 한 실제 결과 다. ✅ 안전한 것 도, ❌ 진짜 깨진 것 도, ⚠️ 마지막 5% 도 솔직하게 *기록.
-
*9년차의 Kafka 운영 회고* — Outbox + Triple Idempotency + DLT 로 *메시징을 길들이는 법*
Kafka 는 *기본 설치만 *하면 동작 한다. 그 다음 부터가 *진짜 시작. 유실 / 중복 / 순서 / 독성 메시지 — 기본값 만 *믿으면 *전부 *터진다. 9년차 의 *settlement 운영 회고. 메시징을 *길들이는 *네 개 의 *기둥.