푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 239편 · 1 / 24 페이지)
-
-
*프로세스* 라는 *추상화* — *CPU · 메모리 · 스레드 · 코어* 가 *어떻게 한 점* 에서 만나는가
CPU 에서 시작 해 보자. 성능 코어 8 + 효율 코어 4. 메인보드 의 *커패시터 는 수명 을 결정한다. *메모리 는 휘발성 이지만 수십 년 가는 반도체. 프로그램 은 디스크 위의 파일. 그런데 — 파일 이 어떻게 동작 하는가. 디스크 의 *바이트 더미 가 어떻게 *키 입력 에 반응 하고 네트워크 패킷 을 받아 *DB 에 쓰는 동적 존재* 가 되는가.
그 변환점 이 프로세스. 정적 파일 → 동적 실행 의 경계. 그리고 *프로세스 안 에서 스레드 가 진짜 일 을 코어 에 던진다.
-
*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 위 / 옆 / 아래 에서 각자 *무엇을 책임지는지 를 런타임 관점 에서 분해 한다.
-
*8 가지 체크리스트* 로 *내 정산 시스템* 을 *자가 검수* 했다 — *동시성 / 트랜잭션 / 보안 / N+1 / 재처리 / 로그 / 예외 / 도메인 규칙*
“운영해 본 적 없는 코드 는 *서비스 가 *아니다.”*
주문·결제·정산 처럼 돈 이 흐르는 시스템 은 코드를 *짠 사람조차 *모르는 사이 조용히 *깨진다. 동시성 / 트랜잭션 / 보안 / N+1 / 재처리 / 로그 / 예외 / 도메인 규칙 — 8 가지 영역 을 체크리스트화 하지 않으면 모르는 사이 가다가 *터진다.
이 글은 내 settlement (이커머스 정산 MSA, Spring Boot 4 hexagonal) 를 그 8 가지 체크리스트 로 자가 감사 한 실제 결과 다. ✅ 안전한 것 도, ❌ 진짜 깨진 것 도, ⚠️ 마지막 5% 도 솔직하게 *기록.
-
*9년차의 Kafka 운영 회고* — Outbox + Triple Idempotency + DLT 로 *메시징을 길들이는 법*
Kafka 는 *기본 설치만 *하면 동작 한다. 그 다음 부터가 *진짜 시작. 유실 / 중복 / 순서 / 독성 메시지 — 기본값 만 *믿으면 *전부 *터진다. 9년차 의 *settlement 운영 회고. 메시징을 *길들이는 *네 개 의 *기둥.
-
*GitOps(ArgoCD) 기반* *멀티 환경 배포 자동화* 와 *통합 관측 체계 구축* — *K3s 6 노드 HA* (이사갈 합류) *65+ ArgoCD App* *무중단 운영* 실전 정리
“인프라가 무너지면 *비즈니스가 *무너진다.”*
그러나 *무너지는 순간 은 코드가 *고장난 순간 이 아니다. 대부분은 *배포 직후 다. 그래서 *배포 파이프라인 과 관측 체계 가 같은 무게 로 설계 되어야 한다.
이 글은 온프레미스 K3s 6 노드 HA 클러스터 (control-plane × 3 + worker × 3, 74 vCPU / 126 GB / 9 TB+) 위에서 65+ 개 ArgoCD Application 을 GitOps 단일 소스 로 무중단 배포 / 관측 / 백업 / 게이트 하는 5 개 축 의 실제 운영 설계 를 정리한다. 2026-06-07 이사갈 (40 vCPU CPU 깡패) 합류 + HA 3 replica + podAntiAffinity 로 각 핵심 서비스가 *3 노드에 *spread 되어 노드 1 개 fail 에도 *downtime 0.
-
*비동기 연동과 인프라* — *어떤 인프라가* *어떤 비동기를* *가능하게 하나*
비동기 연동 의 코드 는 교과서에 있다.
kafkaTemplate.send(),@Scheduled,@Async,CompletableFuture.supplyAsync(). 어느 자료든 읽으면 된다.그러나 *그 코드 가 *실제로 돌게 하는 *인프라 는 교과서에 별로 안 나온다. Kafka broker 의 *replication factor, K8s scheduler 의 *pod-anti-affinity, cgroup 의 *cpu.weight, DB 의 *connection pool, Redis 의 *persistence 모드.
비동기 연동 코드 가 *제대로 도는 건 *그 인프라 가 *비동기 의 *5 가지 보장 을 해주기 때문.
-
*백엔드 개발자 의 *기본기* — *7 년 후에도 *덜 변하는 *10 개*
프레임 워크 는 *바뀐다. Spring Boot 4 가 5 가 되고, AI 가 코딩 의 *반 을 대신 한다. 그래도 덜 *바뀌는 *기본기 가 있다. 7 년 전 의 *내가 *알았더라면 *좋았을 *10 개 의 영역. 이 글은 3 년차 부터 *7 년차 까지 *공통 으로 *되돌아 *오는 *질문 — 백엔드 의 *기본 기 의 *지도.
-
*Multi-Agent 의 *깊이* — *마스터 ↔ 워커 / 조정 패턴 / 충돌 처리*
Single Agent 가 *모든 걸 *처리 하려 하면 — 답 의 *깊이 ↓ + 비용 ↑ + 컨텍스트 부족. 2026 년 의 *AI 시스템 의 *주류 = *Multi-Agent. 여러 *전문 *Agent 가 *협업 해서 복잡 한 *작업 을 분담. 그러나 Agent 도 *분산 시스템 — 조정, *통신, *충돌, *비용 의 4 차원 *고민 이 필수. 이 글은 Multi-Agent 의 *진짜 *깊이.