전체 AI 마이크로서비스를 삭제하고 Postgres만 사용했어요 (그 이유는) 🐘⚡
Source: Dev.to
Introduction
몇 달 전, 지금 모두가 요구하는 기능을 만들어야 했습니다: “우리 사용자가 엉망인 데이터를 가지고 대화하도록”. 제 경우는 방대한 양의 혼란스러운 고객 지원 티켓이었습니다.
The Problem with the Typical Stack
이걸 어떻게 만들지 구글에 검색하면, 인터넷은 즉시 5계층 아키텍처를 제안합니다:
- 임베딩을 위한 벡터 DB
- 관계를 위한 그래프 데이터베이스
- 모든 것을 연결해 주는 LangChain
- 모든 것을 실행할 별도 Python 마이크로서비스
저는 그 함정에 빠져서 구축했습니다. 그 결과, 사용자가 메인 데이터베이스에서 티켓을 삭제했을 때, 해당 티켓의 벡터 표현은 벡터 DB에 남아 있어 AI가 삭제된 데이터를 기반으로 답변을 환각하게 되었습니다.
The “Aha” Moment 💡
AI를 맞춤형 생태계가 필요한 마법 같은 존재로 대하는 것을 멈추고 가장 신뢰할 수 있는 백엔드 도구인 Postgres 로 돌아갔습니다.
Postgres + pgvector = Peace of Mind 🧘♂️
pgvector확장을 활성화합니다.- 원시 데이터와 임베딩을 같은 테이블에 저장합니다.
CREATE EXTENSION vector;
CREATE TABLE support_tickets (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
user_id uuid REFERENCES users(id) ON DELETE CASCADE,
issue_text text,
embedding vector(1536) -- OpenAI's embedding size
);ON DELETE CASCADE 를 주목하세요 – 티켓이 삭제되면 해당 임베딩도 자동으로 사라집니다.
Dumping the Heavy Frameworks 🗑️
대부분의 AI 프레임워크는 실제 API 호출을 추상화 레이어 뒤에 숨겨 디버깅을 어렵게 만듭니다. Postgres를 사용하면 전체 Retrieval‑Augmented Generation (RAG) 파이프라인이 순수 SQL 쿼리와 표준 API 호출 하나로 축소됩니다:
- 사용자가 질문을 합니다.
- 질문을 임베딩으로 변환합니다.
- SQL에서 직접 코사인 유사도 검색을 수행합니다:
SELECT issue_text
FROM support_tickets
ORDER BY embedding $1
LIMIT 5;- 그 다섯 개 결과를 엄격한 JSON 스키마를 사용해 OpenAI/Anthropic API에 전달합니다.
그게 전부—마이크로서비스도 없고, $80/월 벡터‑DB 비용도 없으며, 일반적인 모놀리식 백엔드가 효율적으로 작업을 수행합니다.
Why I’m Sharing This ☕
저는 아키텍처를 테스트하고, 실수를 겪으며, 마케팅 과장을 제거하는 데 많은 시간을 투자합니다. 여러분이 실제 프로덕션에서 작동하는 것을 만들 수 있도록 말이죠. 이 글이 불필요한 아키텍처 재작성, 거대한 SaaS 비용, 혹은 주말 디버깅을 피하게 도와줬다면, GitHub에서 제 작업을 후원해 주세요:
후원은 제가 실험을 계속하고, 깨뜨리고, 프로덕션‑레디 보일러플레이트를 오픈‑소스화하여 여러분의 시간을 절약할 수 있게 해줍니다.
TL;DR
궁금합니다—현재 여러분은 임베딩을 어떻게 관리하고 있나요? 별도 DB를 사용하고 있나요, 아니면 모놀리식으로 유지하고 있나요? 아래에 알려 주세요! 👇