푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 574편 · 1 / 58 페이지)
-
설계에서 구현으로 — 정산 시스템에 RAG를 붙이며 만난 세 개의 조용한 함정, 그리고 시끄러운 하나
지난 글에서 RAG 파이프라인을 실패 지점으로 분해해 봤다. 이번엔 그 설계를 실제 코드로 옮겼다. 정산 플랫폼의 AI 챗봇에 pgvector 기반 지식베이스를 붙이고, Flyway 마이그레이션과 헥사고날 어댑터까지 얹는 작업이다.
-
신규 AI 검색 솔루션 구축 — 요구사항 분석부터 아키텍처 설계까지
“AI 검색 붙여주세요”라는 요구가 들어오면 대개 벡터 DB부터 고른다. 그런데 검색 품질을 결정하는 건 벡터 DB 선택이 아니라 무엇을 정답으로 볼 것인지 정의했는가다. 정답 정의가 없으면 어떤 엔진을 골라도 개선 여부를 알 수 없다.
-
LLM/RAG 기반 AI 서비스 분석·설계 — 어디서 조용히 깨지고, 무엇부터 고도화할 것인가
RAG를 붙이는 일 자체는 어렵지 않다. 문서를 자르고, 임베딩하고, top-k를 프롬프트에 넣으면 데모는 그날 돈다. 어려운 건 그게 틀렸을 때 알아채는 것이다.
-
Oracle · MySQL · MariaDB · Tibero — 벤치마크 표 없이 쓰는 4대 RDBMS 비교
이 글에는 “A가 B보다 몇 배 빠르다” 같은 표가 없다. 그걸 쓸 수 있는 근거가 없기 때문이다.
-
카파시는 그 말을 한 적이 없다 — 내 30일치 토큰 로그로 채점한 'AI 코딩 비용 절약 10계명'
카카오톡으로 이 이미지를 받았습니다. 51만 명이 봤다는 리스트입니다.
-
Self-Improving Loop에 대한 고찰 — 토비의 글을 1차 자료와 대조하며
토비(이일민)의 AI Agentic Coding의 Self-Improving Loop란 무엇인가(2026-08-08)를 읽었다. 최근 읽은 에이전트 관련 글 중 가장 정리가 잘 된 축에 든다. 그래서 요약만 하고 넘기는 대신, 그 글이 세운 주장을 논문과 벤더 1차 자료에 하나씩 대조해봤다.
-
AI OCR 솔루션 분석·설계 — 제품 비교표 대신 제약에서 시작한다
AI OCR을 도입한다고 하면 대개 제일 먼저 나오는 게 제품 비교표다. 정확도 몇 %, 페이지당 얼마, 한국어 지원 O/X. 그런데 그 표는 대부분 쓸모가 없다.
-
AI 기반 엔터프라이즈 문서 검색·관리·유지보수·기술지원 설계
기업의 문서 검색 시스템은 단순한 파일 검색기가 아니다. 파일을 찾는 것보다 더 중요한 것은 다음 질문에 답하는 것이다.
-
쿠버네티스 관리자가 알아야 할 A to Z — 조용히 실패하는 것들
앞 글에서는 쿠버네티스 아래 층을 봤다. 네트워크, 방화벽, 디스크, 쿼럼처럼
kubectl로는 안 보이는 것들이었다. 이번엔 같은 6노드 클러스터를 안쪽에서 본다. -
DB 관리자가 알아야 할 A to Z — 공식 문서로 검증한 12가지
DBA의 일을 한 문장으로 줄이면 이렇다.