푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 505편 · 24 / 51 페이지)
-
*네트워크 기초* — *OSI 7 계층* / *IP* / *TCP vs UDP* / *DNS* / *HTTP* 까지, *입문* 부터 *실전 도구* 까지
“브라우저 주소창 에 google.com 입력 하고 엔터 치면 *무슨 일 이 일어 나는가?”* — 주니어 면접 의 *고전 질문. *시니어 가 보기엔 그 한 줄 에 *수십 개 의 *네트워크 의 층 이 함께 도는 것 이 보인다.
DNS lookup 으로 *도메인 → IP 변환, TCP 3-way handshake 로 _연결 수립_, *TLS handshake 로 *암호화, HTTP 요청 송신, Cloudflare edge 가 _처리_, *origin 서버 로 *forward, *response 가 역경로 로 돌아옴. *각 단계 가 *서로 다른 OSI 계층 에서 각자 책임 을 수행.
이 글은 기본기 시리즈 의 *네트워크 입문 편 — OSI 7 계층 의 _각자 의무_, *IP / MAC / ARP / NAT 의 *물리적 의미, TCP vs UDP 의 _철학_, *DNS 의 *분산 lookup, HTTP / HTTPS 의 _진실_, *ping / traceroute / dig 의 *진짜 동작 — 까지 *입문자 부터 백엔드 엔지니어 까지 *공통 으로 *알아야 하는 깊이* 로 정리한다.
-
*네트워크 의 *본질* — *TCP 상태 기계*, *BBR vs CUBIC*, *QUIC*, *mTLS handshake*
“왜 *이 API 요청 이 200 ms 걸리지?” — 백엔드 의 *흔한 질문. 답 의 대부분 의 비용 은 애플리케이션 코드 가 아니라 *TCP 의 *3-way handshake, TLS 의 *4 round-trip, Slow Start 의 *cwnd 성장, Nagle 의 *지연 같은 네트워크 의 *물리적 본질.
Service Mesh 의 *mTLS, gRPC 의 *HTTP/2 multiplexing, Cloudflare 의 *BBR, HTTP/3 의 *QUIC — 모두 *지난 10 년 의 *네트워크 진화. 그 진화 의 밑 에 TCP 가 *여전히 도는 것 도 사실, 그 위 에서 *새 layer 가 *재발명 되는 것 도 사실.
이 글은 기본기 시리즈 의 *네트워크 편 — TCP 의 상태 기계 와 함정, Congestion Control (CUBIC vs BBR), QUIC / HTTP/3, TLS / mTLS handshake, Service Mesh 의 implementation — 을 백엔드 엔지니어 가 알아야 할 깊이 로 정리한다.
-
*Linux Kernel 의 *본질* — *Process*, *Scheduler*, *Namespaces*, *Cgroups*, *BPF*
“컨테이너 는 *가상 머신 의 *경량 버전 이 *아니다” — Docker / K8s 시대 의 가장 흔한 오해. 컨테이너 는 *Linux 의 *기본 기능 인 Namespaces + Cgroups 의 조합 이다. 별도 OS 없음, hypervisor 없음, 격리 도 *kernel level.
그런데 그 *Namespaces 는 *어떻게 격리 하고, Cgroups 는 *어떻게 자원 제한 하고, Scheduler 는 *수천 process 사이 *CPU 시간 을 어떻게 분배 할까? 그 모든 것 의 *밑 에 Linux Kernel 의 *내부 가 작동 한다.
이 글은 기본기 시리즈 의 *Linux 편 — Process / Thread 의 진실, CFS → EEVDF Scheduler, Namespaces 7 종, Cgroups v1 / v2, eBPF 의 *현대 적 위력 — 을 infrastructure 엔지니어 의 *깊이 로 정리한다.
-
*서평 — *『다시, 소프트웨어 엔지니어』* (네서니얼 슈타·댄 베가 지음 / 박성철 옮김, 책만, 2026)
원서: “Fundamentals of Software Engineering: From Coder to Engineer” (Nathaniel Schutta & Dan Vega, O’Reilly, 2026) 역자: 박성철 — 국내 기술서 번역 의 *오랜 *신뢰 의 이름. 『소프트웨어 엔지니어 가이드북』 (Gergely Orosz, 한빛, 2025) 도 그 가 옮긴 책. 국문 출판: 책만 (2026). 국문 부제는 *“AI 시대 에도 *결코 대체 되지 않을 *개발자 의 기본 역량 과 생존 법”.
-
*분산 시스템 의 *본질* — *CAP*, *BASE*, *Saga*, *2PC vs CDC*, *일관성 spectrum*
“단일 DB 가 *터졌다” — 전통 적 시스템 의 최대 fear. 해결책 은 2 가지 뿐 : vertical scale (한 대를 더 크게) 또는 horizontal scale (여러 대 로 나눔). 전자 는 *물리적 상한. 후자 는 *복잡성 의 지옥.
그 복잡성 의 지옥 의 어휘 가 분산 시스템. CAP 정리, BASE 의 결정, Saga 의 보상, 2PC 의 차단, CDC 의 우회, Raft / Paxos 의 합의. 이 어휘 를 *알아야 마이크로서비스 의 *경계 결정, eventual consistency 의 *trade-off, outbox 패턴 의 *왜 가 근거 있는 선택 이 된다.
이 글은 기본기 시리즈 의 *분산 편 — CAP 의 진짜 의미, 3 가지 trade-off 의 결정 매트릭스, 7 가지 일관성 모델, 분산 트랜잭션 의 *4 가지 패턴 (2PC / Saga / Outbox / Sourcing), 합의 알고리즘 (Raft, Paxos) — 을 시스템 설계자 의 *깊이 로 정리한다.
-
*JVM 의 *본질* — *JIT 컴파일*, *GC 알고리즘*, *메모리 모델*, *Escape Analysis* 까지
“java 명령어 가 *내 코드 를 *실행 한다” — 이 문장 의 9 단어 안 에 수십 가지 의 *내부 동작 이 숨어 있다. JVM 의 *bytecode 인터프리터, JIT 컴파일러 의 *C1 → C2 단계 적 최적화, GC 의 *generational hypothesis, Escape Analysis 의 *스택 할당, Memory Model 의 *happens-before. 이 모든 것 이 Spring Boot 앱 한 줄 의 뒤 에서 작동 한다.
ORM 위에서 일하는 백엔드 가 DB 본질 을 알아야 하듯, Java 위에서 일하는 백엔드 는 *JVM 본질 을 알아야 한다. GC pause 가 *p99 latency 의 *큰 부분 일 때, JIT 가 *warm-up 안 끝났을 때, memory leak 이 *조용히 누적 될 때 — 그 모든 순간 의 *원인 추론 이 JVM 내부 의 물리 에 뿌리 박혀 있다.
이 글은 기본기 시리즈 의 JVM 편 — Class Loading, Bytecode 실행, JIT, GC (Serial → G1 → ZGC), Memory Model, Escape Analysis, Modern features (Virtual Thread, AOT, GraalVM) — 을 백엔드 엔지니어 의 *깊이 로 정리한다.
-
*다시 소프트웨어 엔지니어*
9 년차. 기술 적 으로는 *수많은 것 을 *익혔다. Spring Boot, Kafka, Kubernetes, Hexagonal, Outbox, JIT, GC, CRI, etcd. AI 시대 가 와서 *Claude Code 가 *내 동료 가 되었다. *블로그 글 이 *수십 편. 깃허브 의 *수십 개 리포.
그런데 *문득 *멈춰 서서 본다. 이 모든 것 의 *중심 에 내가 *소프트웨어 엔지니어 임 * 의 그 한 정체성 이 흐려졌나. 나는 *언제 부터 *Tool 의 운영자 로 살았나. 내 *손 으로 무엇 을 *마지막 으로 *만들었나.
그래서 *오늘 *이 글 을 쓴다. “다시 소프트웨어 엔지니어” — 되돌아 가지 말고, *되찾아 오자.
-
*서평* — *조영호* 의 *오브젝트* : *코드로 이해 하는 *객체지향 설계*
“객체 가 *데이터 가 아니라 *역할 이라는 것 을 진심으로 *받아들이기 까지 *7년 이 걸렸다” — 이게 오브젝트 를 처음 읽은 *2020 년 의 *내 *마음 의 균열 이었다.
조영호 (Cho Young-ho) 의 오브젝트: 코드로 이해 하는 객체지향 설계 (위키북스, 2019) 는 한국 어로 쓰여진 *객체지향 설계 의 *가장 깊은 책 중 하나 다. 교보문고 2019 올해 의 책, Java 진영 의 *진짜 명저. 656 쪽 의 밀도 가 높은 코드 + 일관 된 *영화 예매 시스템 예제 가 부실 한 코드 를 *점진 적으로 개선 하는 리팩토링 의 여정 으로 독자 를 끌고 간다.
이 글은 내가 *직접 *2 회 정독 한 경험 + 국내 의 *여러 리뷰 — Velog, Jinwoo’s Blog, 위키북스 공식, Trevari 모임 등 — 의 공통 인상 과 상이 한 시각 을 교차 정리 한 서평 이다.
-
*데이터베이스 의 *본질* — *B+Tree* 부터 *MVCC*, *Isolation*, *Replication*, *Sharding* 까지
“ORM 이 *알아서 해주는데 *왜 *DB 본질을 알아야 할까?” — 2026 년 의 흔한 질문. 답은 “ORM 이 알아서 못 하는 순간” 이 바로 그 본질 이 깨질 때 라는 것.
Spring Data JPA 가 *쿼리 1 줄 을 N+1 회 호출 로 변환 하는 순간, index 가 *full scan 으로 바뀌는 순간, 낙관적 락 이 *deadlock 으로 터지는 순간, replica 의 *replication lag 으로 방금 쓴 데이터 가 *못 읽히는 순간. 그 모든 순간 의 진실 은 DB 안 의 *B+Tree, MVCC, WAL, Replication 의 물리 다.
이 글은 PostgreSQL 을 *기본 reference 로 두고, DB 의 *7 가지 본질 — Storage engine (B+Tree vs LSM), Index 구조, MVCC, Isolation Level, Locking, WAL, Replication / Sharding — 을 백엔드 엔지니어 가 *알아야 하는 깊이 로 정리한다.
-
*GitHub PAT 만료* 로 *13 pod* 가 *동시에 죽었다* — *GHCR 인증 사고* 와 *재발 방지 3 패턴*
“2 일 전 부터 *13 pod 가 ImagePullBackOff 였습니다”* — 우리 클러스터 의 모니터링 알림 이 조용히 누적 되다가 오늘 눈에 띄게 보였다.
원인 은 Kubernetes 도, Docker 도, ArgoCD 도 아니었다. GitHub Personal Access Token (PAT) 이 만료 된 것. 클러스터 의 *모든 namespace 에 동일한 ghcr-pull secret 이 수동 kubectl create 로 분산 되어 있어서, 그 토큰 만료 가 *체감 적으로 *13 pod 동시 죽음 으로 드러났다.
더 고통스러운 발견 : 다른 정상 동작 처럼 보이는 pod 들 도 같은 만료된 토큰 을 가지고 있었다. 그들은 *image 가 노드 에 *이미 cached 되어 있어 imagePullPolicy: IfNotPresent 덕분에 조용히 살아 있는 것. 다음 *rolling update / 노드 재시작 의 시점 에 전부 동시 죽을 시한 폭탄.
이 글은 그 사고 의 *진단 과정, 해결 의 즉시 조치, 그리고 *재발 방지 의 3 패턴 — SOPS+ArgoCD 분배, default ServiceAccount 자동 패치, Kyverno 자동화 (미래) — 를 현장 의 깊이 로 정리한다.