푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 253편 · 1 / 26 페이지)
-
-
*AI 코드 PR* 머지 전, *7 가지 질문* — *vibe coding 의 *마지막 게이트***
AI 가 만든 코드의 PR 머지 전 던져야 할 7 가지 질문 — 신뢰할 수 없는 입력 / 동시 요청 / 경계값 / 외부 의존 다운 / 100만 건 데이터 / 도메인 규칙 / 로그·알람. Rule of thumb: “이게 운영에서 죽을 수 있는 5 가지 시나리오는?” — 머지 전 항상. -
*ELK + Beats* — *Filebeat / Logstash / Elasticsearch / Kibana* 의 *4 단계* 와 *production 로깅 의 *진짜 그림*
서비스/앱 → Filebeat (경량 수집) → Logstash (파싱·변환) → Elasticsearch (색인·검색) → Kibana (시각화). 이 4 단계 의 *각자 책임 분리 가 production 로깅 의 진짜 그림.* -
*쿠버네티스 의 작동 원리* — *kubectl 한 줄* 이 *컨테이너 가 뜨기 까지* 의 *8 단계* 와 *그 안 의 *분산 합의 의 우아함**
-
*kubectl run* 한 줄 의 *뒷 이야기* — *Scheduler · Kubelet* *두 개의 Watch-Reconcile 루프* 가 *느슨하게 *춤추는 방식*
kubectl run echo –image=… 한 줄. Enter. 몇 초 뒤 Pod 가 Running.
이 사이 에 무슨 일 이 일어나는가. 이 한 줄 이 왜 *Scheduler 와 Kubelet 사이 의 두 개의 *독립적 루프 로 처리* 되는가. 왜 그 둘 은 *서로를 직접 호출 하지 않는가. *왜 *어느 쪽이 죽어도 *다른 쪽 이 계속 * 인가.
-
*컨테이너 오케스트레이션* — *DEIS / Rancher / Mesos / Nomad / Swarm* 의 *전쟁사* 와 *우리 가 실제로 *쓰고 있는 *Kubernetes 의 *기능 들*
컨테이너 오케스트레이션 전쟁 (2014~2018) 의 5 후보 — 그리고 살아남은 K8s. 이 글은 그 *전쟁사 와 우리가 실제로 쓰는 K8s 의 기능 을 다룬다.* -
*쿠버네티스의 *논리적 단위 12종 — *Pod / ReplicaSet / Deployment / StatefulSet / DaemonSet / Job / Node / Namespace / Endpoint / Volume / Service / Ingress* 를 *한 장의 *지도* 로 *연결* 한다
쿠버네티스 의 *논리적 단위 — 좌측 워크로드 계열 (Pod / ReplicaSet / Deployment / StatefulSet / DaemonSet / Job), 우측 컨텍스트 계열 (Node / Namespace / Endpoint / Volume / Service / Ingress). 이 12 개 가 어떻게 *서로 참조 하고 어느 축 에 속하는지 를 분해 한다.* -
*쿠버네티스* 의 *유용성* — *온프레미스* 와 *클라우드* 의 *비대칭 비교*
“쿠버네티스 는 *클라우드 회사 가 *클라우드 회사 를 위해 *만든 *툴 인데, 왜 *내 *온프레미스 5 대 노드 에 *깔고 있을까?” — 이 질문 은 모순 처럼 보이지만 *사실은 *쿠버네티스 의 *진짜 매력 을 드러내는 질문 이다.
쿠버네티스 는 *2014 년 Google 에서 *Borg 의 오픈소스 자녀 로 세상 에 나왔다. 그래서 *클라우드 의 자식 처럼 보이지만, 그 본질 은 *추상화 그 자체 — “내 워크로드 가 *어떤 인프라 에서 돌든 *같은 방식 으로 기술 / 배포 / 운영 가능 하다”* 는 선언. 그 선언 이 *클라우드 에서 *극대화 되고 온프레미스 에서 *다른 종류의 가치 를 만든다*.
이 글은 온프레미스 K8s (k3s, kubeadm, RKE2, OpenShift) 와 클라우드 K8s (EKS, GKE, AKS) 의 유용성 을 *동일 한 7 가지 축 에서 비대칭 비교 한다. 내 6 노드 K3s 클러스터 운영 경험 + 클라우드 production 경험 을 교차해서 정리.
-
*보안* 의 *7 기둥* — *인증 / 인가 / 암호화 / 위변조 검증 / 방화벽 / 감사 로그 / 시큐어 코딩*
“보안 은 *문제 가 생긴 후에 *생각 하는 것” — 이 발상 자체 가 문제 의 시작 이다.
보안은 기능 이 아니라 속성. 한 번 *추가 하고 끝 나는 것이 아니라 모든 계층 에 *얇게 *스며들어야 하는 *횡단 관심사 (cross-cutting concern). 인증 가 *되어 있어도 *인가 가 *허술 하면 뚫리고, 인가 까지 다 잡았어도 *암호화 안 된 통신 으로 세션 토큰 이 새면 의미 없다.
그래서 보안은 7 가지 기둥 으로 각각 따로 *동시에 설 수 있어야 한다 — 어느 하나 가 무너져도 *다른 6 개 가 *받쳐주는 *defense in depth.
이 글은 백엔드 개발자 의 *현실적 관점 에서 7 기둥 각각 의 *왜 → 어떻게 → Spring Boot 코드 → 함정 까지 체계적 으로 *분해 한다.
-
*논블로킹 I/O 서버* — *C10K* 부터 *Reactor 패턴*, *epoll / io_uring*, *Netty / Node.js / Nginx* 까지
“왜 *Node.js 는 *싱글 스레드 인데 동시 접속 10 만 을 처리 하는가?”* — 이 질문 의 답 은 Node.js 가 아니라 그 아래 의 *epoll 에 있다.
블로킹 I/O 서버 는 “1 connection = 1 thread” 라는 직관적 모델 위에서 만들어졌다. 2000 년대 초 까지 그것 으로 충분 했다. 그런데 *C10K (concurrent 10,000 connections) 가 현실 이 되자 그 모델 은 *벽 에 부딪쳤다. 스레드 1 만 개 의 컨텍스트 스위치 와 스택 메모리 가 서버 를 *죽였다.
논블로킹 I/O 서버 는 완전히 다른 철학 으로 답했다. “스레드 가 *I/O 를 기다리지 않게 한다” — event loop 하나 가 수만 connection 을 돌아가며 *상태 확인, 준비 된 것만 처리. Nginx 의 *4 worker 가 *10 만 동시 접속 을 처리하는 물리적 근거.
이 글은 C10K 문제 → select/poll/epoll/kqueue/io_uring 진화 → Reactor 패턴 → Netty/Node.js/Nginx 구현 → 백프레셔 → Virtual Thread 와 의 비교 까지 논블로킹 I/O 서버 의 *모든 층 을 분해 한다.