RAG(Retrieval-Augmented Generation) 시스템을 실제로 구축하다 보면, 튜토리얼에서는 절대 알려주지 않는 결정의 순간들이 찾아옵니다. "벡터DB에 다 넣으면 되는 거 아냐?"라고 생각하며 시작했다가, 문서를 어디에 어떻게 저장할지부터 사용자의 질의를 어떻게 해석할지까지, 매 단계가 선택의 연속이었습니다.이 글은 여러 종류의 전문 문서를 다루는 검색 시스템을 설계하면서 실제로 부딪혔던 네 개의 갈림길과, 각 지점에서 내린 판단의 근거를 정리한 기록입니다. 완성된 정답을 나열하기보다, "왜 그렇게 결정했는가"의 사고 과정을 담으려 했습니다.시작점: 왜 저장소를 세 개로 나누는가가장 먼저 정리해야 할 것은 데이터가 어디에 사는가입니다. 처음에는 벡터DB 하나면 충분해 보였지만, 실제로..

들어가며: 우리는 모델을 키우는 시대를 지나왔다몇 년 전까지 AI 성능 이야기는 곧 모델 크기 이야기였다. 파라미터를 더 키우고, 데이터를 더 먹이고, 더 큰 GPU를 붙이는 것. 그런데 지금 실무에서 LLM을 다뤄본 사람이라면 누구나 같은 벽에 부딪힌다. 모델은 충분히 똑똑한데, 우리 회사의 현실 앞에서는 자꾸 헛소리를 한다는 것.이 문제를 푸는 두 가지 흐름이 지금 가장 뜨겁다. 하나는 개발자 커뮤니티에서 유행하는 하네스 엔지니어링(harness engineering), 다른 하나는 팔란티어가 20년에 걸쳐 밀어붙인 **온톨로지(Ontology)**다. 표면적으로는 전혀 다른 세계의 이야기처럼 보이지만, 들여다보면 둘은 놀랍도록 같은 깨달음 위에 서 있다. 이 글은 그 둘을 같은 무대에 올려놓고 비교..

회사에서 대시보드를 본 적 있는 사람이라면 누구나 한 번쯤 이런 경험을 했을 것이다. 화면 한쪽에 빨간불이 켜진다. "매출 하락", "재고 부족", "이상 징후 감지". 그런데 그다음은? 우리는 다른 창을 열고, 담당자에게 메신저를 보내고, ERP에 로그인해서 직접 처리한다. 대시보드는 문제를 알려줬을 뿐, 아무것도 해결하지 않았다.최근 팔란티어(Palantir)라는 회사가 주목받는 이유를 파고들면서, 나는 이 회사가 던지는 질문이 의외로 단순하다는 걸 깨달았다. "데이터를 보기만 할 거냐, 아니면 그 데이터로 일을 끝낼 거냐?" 이 글은 그 질문에 대한 내 나름의 정리다. 전문 용어를 최대한 일상의 비유로 바꿔 풀어보려 한다.1. 온톨로지, 그래프DB와 뭐가 다른가팔란티어를 이해하려면 '온톨로지(Ont..