푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 280편 · 1 / 28 페이지)
-
-
-
*데이터베이스 관리 시스템* 의 *3 층 구조* — *클라이언트 / 인스턴스 / 데이터베이스* 가 *왜 *그렇게 분리* 되는가
-
*알고리즘 을 *표현 하는 *기법* — *순서도 (Flowchart)* 가 *처음 이고 *마지막 이 *아닌 *이유*, 그리고 *거스름돈 (그리디)* 이 *왜 *순서도 예제 의 *고전* 인가
위쪽 — *거스름돈 860 원 (500/100/50/10) 의 *그리디 알고리즘 을 순서도 로 표현. 아래쪽 — 순서도 의 *10 개 *표준 기호 (터미널 / 판단 / 처리 / 입출력 / 흐름선 / 연결점 / 준비 / 서류 / 수동입력 / 천공카드). 이 한 장 이 알고리즘 학습 의 *첫 페이지 에 왜 *놓이는지, 그리고 왜 *현대 *코드 베이스 에서는 *덜 보이는지 를 함께 *분해 한다.* -
K3s vs K8s — 현실적인 비교, 6노드 14개월 운영 경험
K3s 클러스터 운영 14개월 째 다. 6 노드, 65+ ArgoCD apps, 33 도메인. 그 사이 cluster-dns outage 복구 (6시간), etcd orphan member 제거, Velero OOM fix, frp self-host 구축, SOPS+age 도입 등 작은 사고들 의 *반복. 그 운영 의 14개월 위에서 자주 받는 질문 — “K3s 와 K8s 차이가 뭐냐” + 그 자매 질문 — “그럼 K8s 로 옮겨야 하나?”.
-
서버 구조 설계 패턴 — 모놀리스 부터 헥사고날, CQRS, Saga, Service Mesh 까지
서버 코드 를 짜는 사람 이라면 한 번 쯤 마주치 는 질문 들이 있다. “왜 Service 클래스 가 1000 줄 이 되면 안 되나?”, “Repository 는 왜 인터페이스 로 두나?”, “왜 도메인 객체 가 JPA Entity 와 분리 되어야 하나?”, “외부 결제 API 호출 을 어디 에 두나?” — 이 모든 질문 의 밑 에 구조 설계 패턴 이 있다.
-
*서버 의 *기본기* — *한 개의 요청* 이 *내 손가락 부터 *DB 와 *돌아오기까지* — *내 새벽 운영 사고 의 *교재 적 정리*
오늘 새벽 02:00 ~ 03:00. 내 홈랩 클러스터 에서 연달아 사고 :
- KubeNodeNotReady — louise 노드 24 시간 다운
- KubeContainerWaiting — jabis / logistic 의 GHCR 401
- KubeAPIErrorBudgetBurn — 컨트롤 플레인 503
- xr.lemuel.co.kr — 502 Bad Gateway
- oms.lemuel.co.kr — Hikari Connection is not available
이 5 가지 가 *우연히 같은 새벽 에 모인 것이 아니다. *서로 *서버 의 다른 layer 의 같은 기본기 를 건드린 것. DNS · TLS · Ingress · Pod · Connection Pool · Storage · 노드 — 어느 한 곳 이 무너지면 *상위 가 다 따라간다.
-
*네트워크 기초* — *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 엔지니어 의 *깊이 로 정리한다.