TIMBR.AI · DATA AGENT
왜 우리 회사 AI는
아직도 부정확한가
LLM과 RAG가 등장한 지 수년, 사내 데이터를 연결한 온프레미스 AI조차
여전히 신통치 않은 답을 내놓는 이유와 해법 — Timbr.ai Data Agent
코세나(KOSENA) · Timbr.ai 공식 한국 총판
문제 제기
사내 데이터를 가져와도, AI 답변은 왜 여전히 부정확한가
2 / 10
테이블은 있어도 '의미'가 없다
RAG와 온프레미스 LLM은 문서·테이블을 검색해 오지만, 컬럼과 테이블이 실제로 무엇을 의미하는지, 서로 어떻게 연결되는지는 알지 못합니다.
매번 처음부터 추론한다
지난주 분석가가 이미 검증한 로직을 AI는 기억하지 못하고, 같은 질문에도 매번 다르게, 종종 틀리게 SQL과 JOIN을 새로 추론합니다.
지표의 정의가 부서마다 다르다
'매출', '정산금액' 같은 핵심 지표조차 부서별 정의가 다른데, AI는 어떤 정의가 맞는지 판단할 근거(거버넌스)가 없습니다.
LLM은 SQL을 잘하지만, 스키마를 모른다
LLM 자체의 추론 능력은 충분히 성숙했지만, 수천 개 테이블·여러 스키마에 흩어진 이기종 데이터의 구조를 스스로 파악하지 못합니다.
Timbr.ai × KOSENA
근본 원인
모든 질문이 '0'에서 다시 시작된다
3 / 10
재발명 (Reinvents)
분석가가 지난주에 이미 해결한 로직을, AI는 매 질문마다 미묘하게 — 때로는 명백히 틀리게 — 다시 유도합니다.
망각 (Forgets)
검증되고 승인된 정답 쿼리도 세션이 끝나면 사라집니다. 아무것도 조직의 자산으로 축적되지 않습니다.
흩어짐 (Scatters)
업무 지식은 슬랙 대화, 위키 페이지, 담당자의 머릿속에만 존재하며 AI 에이전트는 이를 볼 수도, 접근할 수도 없습니다.
Timbr.ai × KOSENA
핵심 개념
온톨로지는 '데이터'를 알고, Knowledge Base는 '조직'을 안다
4 / 10
온톨로지 (Semantic Layer)
"데이터가 무엇을 의미하는가?"
Knowledge Base (Data Agent 메모리)
"우리는 실제로 이걸 어떻게 쓰는가?"
역할
개념·관계·측정값·거버넌스 규칙을 한 번 인코딩한 구조적 진실
분석가의 질문 표현 방식, 선호하는 JOIN, 과거 결정을 축적한 해석 계층
담는 것
테이블/컬럼 매핑, 계층·분류, 비즈니스 로직(측정값)
승인된 질문→SQL 예시, 큐레이션된 지침, 검증 규칙
진화 방식
모델링 단계에서 정의되고 검증되며 점진적으로 정교화
승인된 질문마다, 교정마다 자동으로 학습·축적(플라이휠)
AI에게 주는 것
'무엇을 물어야 하는지'에 대한 정확한 스키마와 의미
'어떻게 신뢰성 있게 재사용할지'에 대한 검증된 선례
두 계층이 합쳐질 때 비로소 신뢰할 수 있는 Data Agent를 위한 '컨텍스트 기반(context substrate)'이 완성됩니다. (출처: docs.timbr.ai / Knowledge Base for Data Agents)
Timbr.ai × KOSENA
아키텍처
질문에서 신뢰된 SQL까지, 4개 레이어의 역할 분담
5 / 10
ASKS
Data Agent Reasoning — 자연어로 질문을 추론
질문 + 컨텍스트 → 근거 있는 답변
REMEMBERS
Knowledge Base Memory — 과거 지식을 검색·검증
검증되고 통제된 재사용
MEANS
Ontology Meaning — 개념·측정값·관계·거버넌스
의미론적 모델과 규칙
STORES
사내 데이터 플랫폼 — 원본 데이터
쿼리는 데이터가 있는 곳으로 푸시다운되어 실행
Timbr는 데이터를 이동·복제하지 않습니다. 질의는 최적화되어 원본 소스에 그대로 푸시다운(pushdown)되어 실행됩니다.
Timbr.ai × KOSENA
Knowledge Base for Data Agents
쓸수록 똑똑해지는, 신뢰 가능한 Data Agent의 기억 장치
6 / 10
검증된 질문→SQL 예시 축적
분석가가 승인한 실제 질문·SQL 쌍을 저장해, 유사한 질문이 오면 이미 검증된 로직을 그대로 재사용합니다.
큐레이션된 지침과 규칙
"매출은 완료된 주문만 포함" 같은 업무 규칙과 KPI 정의를 사람이 주석으로 남기면 AI가 그대로 따릅니다.
단계적 신뢰도 하락 (Graceful Degradation)
완전 일치 시 직접 재사용 → 유사 사례는 예시 기반 안내 → 선례가 없으면 온톨로지만으로 생성. 막히는 지점이 없습니다.
실행 전 거버넌스 검증
재사용되는 모든 경로는 온톨로지 그래프상에서 연결성·파라미터·권한(RBAC)을 검증받은 뒤에만 실행됩니다.
Timbr.ai × KOSENA
GenAI NL2SQL Engine
Timbr가 LLM의 SQL 정확도를 근본적으로 높이는 방법
7 / 10
명시적 관계로 JOIN 추론 제거
테이블 간 관계를 온톨로지에 미리 선언해 두어, LLM이 복잡한 JOIN 로직을 추측할 필요가 없어지고 다중 테이블 질의 정확도가 크게 향상됩니다.
LLM이 이해하는 형태의 메타데이터
의미 모델·계보(lineage)·메타데이터를 사람이 읽을 수 있는 형태로 LLM에 노출해, 질의를 정확히 구성할 충분한 맥락을 제공합니다.
설명 가능성과 추적성
생성된 모든 SQL은 원래의 개념·로직·메타데이터까지 역추적이 가능해 검증, 디버깅, 감사 대응이 가능합니다.
환각(Hallucination) 감소
구조화된 비즈니스 로직과 거버넌스된 의미 체계로 LLM을 안내함으로써 오해석의 여지를 근본적으로 제거하고자 합니다.
Timbr.ai × KOSENA
Before / After
기존 RAG·온프레미스 LLM Agent vs Timbr Data Agent
8 / 10
지금까지의 사내 AI Agent
문서·테이블을 검색은 하지만, 의미와 기억이 없다
Timbr.ai Data Agent
온톨로지 + Knowledge Base로 '의미'와 '기억'을 동시에 확보
Timbr.ai × KOSENA
온프레미스 구축 이점
데이터가 있는 곳에, 통제된 방식으로 — 온프레미스 Data Agent
9 / 10
1
데이터는 이동하지 않는다
Timbr는 데이터를 저장·복제하지 않고 원본 위치에 그대로 매핑만 합니다. 온프레미스·프라이빗 클라우드 환경에서도 데이터 반출 없이 구축 가능합니다.
2
SaaS·클라우드·온프레미스 어디든 동일 배포
Azure/GCP/AWS와 쿠버네티스 컨테이너 기반으로 동일한 아키텍처를 사내 인프라에 그대로 이식할 수 있습니다.
3
권한(RBAC)과 승인 워크플로우 내장
역할 기반 접근 제어가 검색·재사용 시점에 적용되어, 분석가는 자신이 허가된 데이터만 보게 됩니다.
4
Timbr가 유일한 실행 경계(Execution Boundary)
Knowledge Base는 제안만 하고, 최종 판단과 실행은 항상 온톨로지의 거버넌스를 통과한 뒤 Timbr를 통해서만 이뤄집니다.
Timbr.ai × KOSENA
이제, AI에게 정확한 답을 요구할 시간입니다
Timbr.ai의 SQL 온톨로지와 Knowledge Base로, 사내 어떤 데이터에도
정확하고 설명 가능한 답을 내놓는 Data Agent를 경험해 보세요.
코세나(KOSENA) | 이승훈 실장 | admin@kosena.kr | 010-9338-6400