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

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

앞에서 지식그래프에 기본 이론과 온톨로지 설계 과정을 살려보았다면, 마지막으로 온톨로지 기반으로 지식그래프를 어떻게 생성하고 관리하는지 알아보도록 하게습니다. 참고한 도서는 유원북스의 지식그래프(2025)입니다. 1. 지식 그래프 성명주기 개요1) 구축(Construction / Creation):다양한 데이터로 부터 정보를 추출하고 구조화함온톨로지 설계하고 원본 데이터를 RDF와 같은 그래프 형태로 변환데이터 소스와 온톨로지 간의 매핑 규칙 정의 2) 저장 및 호스팅(Storage/ Hosting)지식 그래프의 특성(데이터 모델, 규모, 쿼리 패턴)에 맞는 적절한 데이터베이스 기술을 선택RDF 트리플 저장소나 속성 그래프 데이터베이스가 사용됨데이터베이스에 구축된 지식그래프 데이터를 로드하고 인데싱하는 ..

이번에는 지난번 지식그래프에 대한 전반적인 이해를 했다면, 이번에는 8단계 온톨로지 구축단계 중 핵심이라고 할 수 있는 단계4, 클래스/속성 정의, 단계5. 관계 정의, 단계6. 표현 및 구현 단계를 공연/전시 사례를 바탕으로 진행할 예정입니다.참고한 도서는 유원북스의 지식그래프(2025)입니다.공연/전시 서비스 온톨로지 구축 예시(단계4,5,6)단계4: 클래스 및 속성 정의 1. 클래스(Class) 및 계층 구조 정의클래스는 온톨로지의 '주체'가 되는 틀입니다. 공연 서비스라면 우리가 다룰 데이터의 가장 큰 범주를 먼저 설정합니다.1) 클래스 정의 (Class Definition)단순한 카테고리가 아니라, "이 세상에 존재하는 것들의 유형"을 정의하는 것입니다.:Performance: 모든 공연의 공통..

최신 LLM과 기법을 통해 AI 에이전트를 구축해봐도 어딘지 조금 멍청하게 동작을 했던 경험이 있을 것입니다. 2026년 5월 현 시점에서 내 부족한 AI에이전트에게 무엇을 추가하면 성능이 급격히 상승할까요? 이미 만들어진 전문영역 AI Agent에게 더 성능좋은 LLM, AI Agent 설계 변화, 다양한 테스트를 통한 오작동 감소 등으로 큰 변화를 이룰 수 있을까요? 저는 현시점에서 지식그래프를 활용한 '온톨로지' 구축이 가장 자신있게 내놓을 수 있는 답 같습니다. 현 시점에서 AI 기술은 '도구'에 가깝고, 중요한 것은 이 도구들을 기존 전문화된 데이터와 어떻게 연결학고 활용하여, 내 비지니스 문제를 해결하는 것이라고 생각합니다. 개인이 AI시대에 생존할 수 있는 꽤 괜찮은 방법 중 하나가 자신이..

AI 개발 도구, 단순한 코드 생산을 넘어 '기획-생산-학습'의 선순환으로최근 개발 생태계에서 Claude, Cursor와 같은 AI 도구들은 강력한 코드 생산 도구로 확고히 자리 잡았습니다. 간단한 프롬프트 몇 줄만으로도 상당한 수준의 코드가 즉각적으로 생성되며, 과거와는 비교할 수 없을 정도로 개발 속도가 비약적으로 향상되었습니다.하지만 이러한 AI 도구를 단순히 '코드를 빠르게 찍어내는 자동화 도구'로만 소비한다면, 장기적인 관점에서는 오히려 치명적인 독이 될 수 있습니다. AI가 생성한 코드의 동작 원리를 온전히 이해하지 못한 채 실무 서비스에 그대로 적용하게 되면, 시스템의 복잡도만 통제 불능 상태로 높아지고 결국 막대한 기술 부채(Technical Debt)로 돌아오기 때문입니다. 진정한 전문..