푸른영혼의 별 | Tech Blog

---

Posts (총 294편 · 1 / 30 페이지)

• 2026-06-30
• 2026-06-30
• 2026-06-30

  Elasticsearch 와 Kibana — Lucene 의 segment 부터 Kibana 의 dashboard 까지

  어제 의 Logstash + Elasticsearch — Fluent Bit 부터 ILM 까지 의 자매 편. 이번 엔 Logstash 빼고 *Elasticsearch 의 *내부 mechanics + Kibana 의 실무 활용 의 2 인 무대. 내 6 노드 K3s + ELK 운영 의 14 개월 경험 중 어제 글 에 안 들어간 *깊은 부분 의 집중.

  #elasticsearch #kibana #lucene #segment #refresh #flush #kql #lens #alerting #runtime-field
• 2026-06-29

  *풀 스캔 이 *인덱스 보다 *빠른 경우* — *옵티마이저 의 *수학* 과 *주니어 가 *흔히 *오해 하는 *7 가지 시나리오**

  PR 리뷰 — 주니어 가 *“이 쿼리 가 *너무 느려서 *인덱스 를 *하나 *추가 했습니다”.

  나는 *EXPLAIN ANALYZE 를 *돌려 본다. 인덱스 추가 후 의 *쿼리 가 추가 전 보다 *느리다. 3 배. 왜?

  주니어 의 *놀란 표정 — “인덱스 가 *빠른 거 아닌가요?”

  9 년 의 *조용한 진실 — 인덱스 가 *항상 빠른 것 이 *아니다. 때로는 *풀 스캔 이 *압도 적으로 빠르다. 그 *때 가 *언제 인지 를 옵티마이저 는 *수학 으로 결정 한다. 그 *수학 을 *모르면 *불필요한 인덱스 가 *쿼리 를 *느리게 만든다. 그리고 *INSERT / UPDATE 를 *영구 적 으로 *5 ~ 30 % *느리게 만든다.

  #full-table-scan #sequential-scan #index-scan #cost-based-optimizer #selectivity #bookmark-lookup #postgres #mysql #oracle #explain-analyze #btree #planner
• 2026-06-29

  Spring AI vs Python — sparta-msa 의 ai-service 운영 으로 본 *현실 의 trade-off*

  내 sparta-msa-project 의 ai-service (chat.lemuel.co.kr) 는 Spring AI 1.0.0 기반 Gemini 챗봇. 14 개월 운영 하면서 Python 의 LangChain + FastAPI 와 직접 비교 한 현실 의 trade-off 를 정리. 어느 한 쪽 의 우월 함 의 주장 이 아니라 — 팀 의 *맥락 과 조직 의 *기존 stack 에 따른 합리적 선택 의 가이드.

  #spring-ai #python #langchain #fastapi #gemini #openai #rag #vector-store #tool-calling #mcp
• 2026-06-29

  *DB 옵티마이저* 와 *JPA 낙관적 락* 의 *실패 방어* — *동시성 의 *두 얼굴* 의 실전***

  내 settlement 의 *오늘 의 두 가지 알람:

  1. EXPLAIN 의 *plan 이 어제 *Index Scan 이었는데 오늘 Seq Scan 으로 바뀜* → p99 가 *20 배 폭증
  2. Settlement.confirm() 의 *OptimisticLockException 폭증 → retry 3 회 다 실패 → 사용자에게 *500 응답

  두 문제 가 *같은 시각 에 *함께 발생. 우연 이 아니다. DB 옵티마이저 와 JPA 낙관적 락 은 같은 *동시성 의 두 얼굴. 옵티마이저 의 *plan 의 *불안정 이 락 retry 의 *deterministic execution 의 기반 을 흔든다.

  #postgres #optimizer #query-planner #jpa #optimistic-lock #version #retry #spring-retry #saga #deadlock
• 2026-06-29

  *성능* 과 *서버 구조 설계 패턴* — *코드 최적화 가 아니라 *구조 의 선택* 이 *80% 를 결정* 한다

  “내 시스템 이 *느려요. *어디 를 최적화 해야 하나요?” 의 질문 의 80% 의 답 은 코드 가 아니라 *구조.

  “DB index 추가 하면 빨라지나요” — 대답 은 *“인덱스 보다 *읽기 모델 의 분리 가 10 배 효과”. “thread pool 늘리면 되나요” — 대답 은 *“thread 보다 *비동기 메시지 의 도입 이 근본”.

  성능 의 *근본 적 향상 은 구조 설계 패턴 의 *선택 에서 결정.

  #performance #monolith #msa #hexagonal #cqrs #outbox #saga #read-projection #service-mesh #sharding #scalability
• 2026-06-29

  Logstash 와 Elasticsearch — Fluent Bit 파이프라인 부터 ILM 까지

  내 6 노드 K3s 클러스터 의 33 개 도메인 의 로그는 모두 ELK 로 모인다. Fluent Bit (각 노드 의 DaemonSet) → Logstash (필터 + 라우팅) → Elasticsearch (hot/warm tier + ILM) → Kibana (시각화) 의 완전 한 파이프라인. 이 글은 14개월 운영 경험 위에서 Logstash 와 Elasticsearch 의 *역할 + 설계 결정 + 운영 함정 의 현실 가이드.

  #elasticsearch #logstash #fluent-bit #ilm #kibana #eck #observability #log-aggregation #inverted-index
• 2026-06-29

  DB 설계와 쿼리 — 14개월 운영 경험 으로 정리한 실전 가이드

  DB 설계 와 쿼리 는 책 으로 학습 하는 영역 이 아니다. 14개월 운영 하면서 V50 사고 같은 생살이 를 겪고 *회복 해야 진짜 의 깊이 가 들어 온다. 이 글 은 settlement / sparta / lemuel-xr 의 수십 만 row 의 PostgreSQL 운영 위에서 체화 한 *현실 적 패턴 의 정리.

  #database #postgresql #schema-design #index #query-optimization #n-plus-one #transaction #isolation-level #migration #flyway
• 2026-06-26

  *기본기 강화* — *SOLID* 와 *디자인 패턴* 을 *실무 코드* 에 *어떻게 적용 했는가* — *Settlement 의 *살아있는 사례***

  

  #solid #srp #ocp #lsp #isp #dip #design-pattern #strategy #observer #command #outbox #hexagonal #archunit #settlement