푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1371편 · 127 / 138 페이지)
-
Chunking → Embedding → Search → LLM — *앞 단계의 결정이 뒷 단계를 묶는다*: RAG 효율화 4 축과 벡터 DB·LLM 의 진짜 관계
'’Garbage in, garbage out’’ — RAG 시스템에서 이 격언은 층층이 작동한다. Chunking 에서 잘못 자르면 Embedding 이 의미를 못 잡고, Embedding 이 흐릿하면 Vector DB 가 검색을 못 하고, 검색이 부정확하면 LLM 이 환각 (hallucination) 한다. 네 단계는 독립 이 아니라 체인 이다. 한 단계의 결정 이 다음 세 단계를 묶는다.
-
Kafka, RabbitMQ, Celery — *메시지가 가는 길* 의 세 가지 철학: 탄생, 기업 사용사례, 그리고 2026 년의 유효성
'’메시지를 어떻게 전달할 것인가’’ — 이 단순한 질문에 세 가지 완전히 다른 답 이 나왔다. RabbitMQ 는 '’똑똑한 우체국’‘, Kafka 는 '’끝없이 쓰여지는 책’‘, Celery 는 '’Python 의 분산 작업 위임자’‘. 표면적으로 비슷해 보이지만, 근본 모델 은 서로 다른 우주에 있다. 그리고 이 차이가 '’어느 회사가 어느 걸 쓰는가’’ 의 진짜 이유 다.
-
이벤트 아키텍처 — *''호출하는 시스템''* 에서 *''반응하는 시스템''* 으로, 그리고 그 안의 *함정 7 개*
'’서비스 A 가 *서비스 B 를 호출 한다’’* 라는 한 문장은 분산 시스템의 가장 흔한 결합 이다. 호출하는 순간 A 는 B 의 *주소·가용성·응답 시간 을 모두 떠안는다. *'’서비스 A 가 *이벤트를 발행 하고, 누구든 들으면 반응한다’’* 로 한 번 뒤집으면, 결합이 *시간·공간 양쪽에서 떨어진다**.
-
DDD 와 MSA 의 상관관계 — Bounded Context 가 곧 서비스 경계인 이유, 그리고 DDD 없이 MSA 가면 만나는 Distributed Monolith
“MSA 갈 거면 DDD 부터 배워라” 라는 말, 매우 자주 듣는데 왜 가 잘 안 드러난다. DDD 는 2003 년 (Eric Evans), MSA 는 2014 년 (Lewis & Fowler). 서로를 위해 태어난 게 아닌 두 개념이 결과적으로 떨어질 수 없는 한 쌍 이 된 데에는 분명한 구조적 이유가 있다.
-
MSA 12 년 — *Netflix·Amazon 의 성공*, *Segment·Prime Video 의 회귀*, 그리고 *2026 년의 답*
2014 년 3 월 25 일, Martin Fowler 와 James Lewis 가 '’Microservices’’ 라는 한 단어를 글의 제목으로 올렸다. 그 뒤 12 년 동안 '’MSA 로 가자’’ 라는 결정은 전 세계 백엔드 진영의 디폴트 가 되었다. 하지만 같은 12 년 동안, '’MSA 로 갔다가 돌아왔다’’ 는 사례들도 놀랄 만큼 많이 쌓였다.
-
Kubernetes 와 웹의 미래 — *서버는 어디에 사는가*: Edge, WASM, AI 추론이 다시 그리는 *런타임의 지도*
'’서버는 어디에 사는가?’’ — 이 질문은 25 년간 단 한 번도 같은 답을 가진 적이 없다. '’내 컴퓨터 밑에 있는 본체’’ 에서 시작해서 '’랙 끝의 1U 서버’‘, '’AWS 의 한 리전’‘, '’엣지의 PoP’‘, '’사용자 브라우저’’ 까지 — 서버의 거주지 는 계속 사용자 쪽으로 움직여 왔다. 그리고 그 이동의 매 단계마다 Kubernetes 는 옆에 있었다.
-
Spring Boot 안티패턴 *2종* — @Service 비대화 + @Transactional 경계 흐림 (실전 리팩토링)
새 Spring Boot 프로젝트 시작할 때 누구나 깔끔하게 짠다.
OrderService가 200줄,PaymentService가 150줄. 한 달 뒤OrderService는 1500줄,@Transactional이 메서드마다 붙어있고, 어떤 메서드가 진짜 비즈니스 경계인지 모르겠다. -
홈랩 K3s 5노드의 CPU 가 모자랄 때 — 데이터센터의 Capacity Planning 흉내내기
홈랩 K3s 5노드 클러스터를 프로덕션처럼 굴리다 보면, 어느 날 “왜 자꾸 CPU 가 모자라지?” 가 시작된다. 빌드는 늦어지고, 배치 잡은 밀리고, 가끔 응답이 느려진다. 노드 한 대 더 살까? 어떤 사양으로? 얼마짜리까지 사야 하나?
-
CI/CD 의 역사 — *cron 스크립트* 부터 *쿠버네티스 GitOps* 까지: 빌드 파이프라인이 *클러스터의 일부* 가 되기까지
'’아침에 출근해서 보니 빌드가 깨져 있었다’’ — 1999 년 Martin Fowler 가 Continuous Integration 논문에 적은 이 한 줄은, 20 년 뒤에는 '’누가 kubectl 을 만졌어요?’’ 로 바뀌게 된다. CI/CD 의 25 년 역사는 곧 '’빌드와 배포를 어떻게 사람 손에서 뺏을까’’ 의 역사다. 그리고 그 끝에 쿠버네티스 가 서 있다.
-
TDD 와 Mockito — Kent Beck 의 *빨강·초록·리팩토링* 부터 Spring 단위 테스트의 현재까지
'’테스트를 먼저 쓴다’’ 는 한 문장은, 2002 년 Kent Beck 이 출판한 Test-Driven Development by Example 의 표지 한 줄로 요약된다. 하지만 그 한 문장이 자바 진영에서 진짜 살아남은 이유는, Mockito 라는 작은 라이브러리가 '’의존성을 어떻게 끊을 것인가’’ 라는 막막한 문제를 대화체 로 풀어냈기 때문이다.