RAG 다음은 시멘틱 레이어라는데, 고객한테 뭘 만들어 줘야 하나

요즘 고객 미팅에 들어가면 "시멘틱 레이어", "온톨로지", "컨텍스트 레이어" 같은 단어가 자주 들린다. Microsoft는 Fabric IQ를, Google은 Looker 시멘틱 레이어를, Snowflake와 Databricks는 각자 시멘틱 뷰와 메트릭 뷰를 밀고 있다. 다들 "AI 에이전트가 우리 회사 데이터를 제대로 이해하게 해 준다"고 말한다.

우리 팀은 고객을 만나 컨설팅을 하고 프로토타입까지 만들어 주는 팀이고, 나는 거기서 개발을 맡고 있다. 그러니 결국 내가 궁금한 건 하나다. 이걸 고객 환경에 실제로 어떻게 만들어 주느냐.

그래서 AI한테 한참 물어봤다. 답변 자체는 꽤 괜찮았는데, 순서가 뒤죽박죽이고 "그래서 내일 뭘 하면 되는데?"에 대한 답이 부족했다. 이 글은 그 답변을 뼈대로 삼아 순서를 다시 잡고, 공식 문서와 자료를 확인하면서 구현 관점의 내용을 보탠 학습 노트다.

미리 밝혀 두면, 여기 나오는 모든 플랫폼을 직접 다 써 본 건 아니다. 플랫폼 기능과 출시 상태는 2026년 10월 초 기준으로 찾아본 자료를 바탕으로 정리했고, 이 분야는 몇 달 단위로 바뀐다. 고객 앞에서 쓰기 전에 한 번 더 확인하는 게 좋다.

먼저, RAG는 뭐가 부족했나

대부분의 사내 RAG는 이렇게 돈다.

질문 → 관련 문서 검색 → 문서를 LLM에 전달 → 답변

예를 들어 협회 고객의 상담 Agent 프로젝트에서 누군가 이렇게 묻는다고 해 보자.

이 프로젝트에서 위험한 이슈 알려줘

RAG는 이슈 문서, 주간보고, 회의록을 뒤져서 '지연', '오류', 'SLA', '긴급' 같은 단어가 들어간 문단을 찾고, 그걸 요약해서 답한다. 문서를 찾고 요약하는 일이다. 그리고 이 방식은 몇 가지 질문 앞에서 확실히 무너진다.

첫째, "위험하다"의 뜻을 모른다. 우리 팀에서 고위험 이슈는 "긴급 등급이면서 3일 이상 미조치"인데, 그 정의는 어떤 문서에도 문장으로 적혀 있지 않다. 사람 머릿속에 있다.

둘째, 계산을 못 한다. "가장 문제가 많은 회원사는?"이라는 질문에 답하려면 회원사별로 상담건을 세고, 미해결을 거르고, 긴급을 다시 세야 한다. "회원사 A 문제 많음"이라는 문서는 없다. 검색할 대상이 아예 없는 거다.

셋째, 말이 애매하면 답도 애매하다. 회의록에 "일정이 좀 늦어지고 있습니다"라고 적혀 있으면 RAG는 "A 프로젝트가 늦어지고 있는 것으로 보입니다"라고 답한다. 얼마나? 왜? 진짜로? 아무것도 모른다.

솔직히 나도 처음엔 "프롬프트에 정의 몇 줄 넣고, 청킹 좀 잘 하면 되는 거 아냐?" 싶었다. 정의 몇 개까진 그걸로 버틴다. 그런데 정의가 수십 개가 되고, 그 정의가 숫자 계산과 테이블 조인을 요구하기 시작하면 프롬프트로는 감당이 안 된다. RAG 쪽 오해는 예전 글에서도 다뤘으니 같이 보면 좋다.

시멘틱 레이어, 컨텍스트 레이어, 온톨로지 — 다 같은 말인가

벤더마다 이름이 달라서 처음엔 엄청 헷갈렸다. 내 나름대로 정리하면 이렇다. 이건 좀 의견이 갈릴 수 있다.

• 시멘틱 레이어(Semantic layer): 원래는 BI 쪽 용어다. "매출 = 주문금액 합계 − 반품금액" 같은 지표 정의를 한 곳에 모아 두고, 대시보드든 SQL이든 같은 숫자가 나오게 하는 층. LookML, dbt Semantic Layer, Power BI 시멘틱 모델이 여기 속한다. 요즘은 이걸 LLM이 읽게 해서 Text-to-SQL 정확도를 올리는 용도로 다시 팔리고 있다.
• 온톨로지(Ontology): 지표보다 한 단계 넓다. "회원사", "상담건", "담당자" 같은 업무 개체(엔터티)와 그 사이 관계, 그리고 규칙과 액션까지 정의한다. Palantir가 오래전부터 이 단어를 핵심으로 써 왔고, Microsoft Fabric IQ도 이 단어를 쓴다.
• 컨텍스트 레이어(Context layer): 마케팅 용어에 가깝다고 본다. AI가 답할 때 참고하는 조직의 맥락 전체 — 데이터 의미, 문서 지식, 업무 관계, 권한 — 를 묶어서 부르는 말이다.

실무적으로는 이렇게 기억하면 충분했다. 시멘틱 레이어는 "숫자의 뜻", 온톨로지는 "업무의 구조", 컨텍스트 레이어는 "그걸 AI한테 먹이는 통로 전체".

동작 방식: 질문이 들어오면 무슨 일이 일어나나

컨텍스트 레이어 방식은 흐름이 이렇게 바뀐다.

질문 → 엔터티 식별 → 관계 탐색 → 규칙 적용 → 답변 생성

단계별로 보자.

엔터티 식별: 질문 속 명사가 무엇을 가리키는가

지난주부터 답변품질 문제가 계속되고 있는데 담당 부서는 어디야?

AI는 이 질문을 이렇게 쪼갠다.

"답변품질 문제"  → 이슈(Issue) 엔터티, 유형 = 답변품질
"지난주부터"     → 생성일 >= 지난주 월요일
"담당 부서"      → 조직(Department) 엔터티

단어 검색이 아니라 "무엇을 찾으라는 질문인가"를 해석하는 단계다. 여기서 용어사전이 결정적인 역할을 한다. "답변품질 문제"가 이슈 유형 코드 QA_QUALITY라는 걸 알려주는 게 용어사전이기 때문이다.

관계 탐색: 연결을 따라가며 답을 찾는다

여기가 제일 중요하다고 생각한다. 이런 관계가 정의되어 있다고 하자.

회원사 ─(요청)→ 상담건 ─(발생)→ 이슈 ─(배정)→ 담당자 ─(소속)→ 부서

"가장 문제가 많은 회원사는?"이라는 질문이 오면, 관계 기반 AI는 이렇게 계산한다.

회원사 A
 └ 상담건 45건
    └ 미해결 12건
       └ 긴급 5건

회원사 → 상담건 → 이슈를 따라가면서 숫자를 모은다. 앞의 "담당 부서" 질문도 이슈 → 담당자 → 부서로 두 번 건너가면 답이 나온다. 이런 걸 멀티홉(multi-hop)이라고 부른다.

규칙 적용: "위험하다"를 계산 가능한 조건으로

팀에서 고위험 이슈를 이렇게 정의했다고 하자.

고위험 이슈 = 긴급 등급 AND (SLA 초과 OR 미해결 7일 초과)

실제 데이터에 이슈 A가 있다.

이슈 A: 등급 = 긴급, SLA 초과 = Y, 미해결 10일

사용자는 "위험한 이슈 알려줘"라고만 묻는다. 그래도 AI는 "위험한 이슈"가 무엇인지 안다. 규칙이 있으니까. 그래서 "이슈 A는 긴급 등급이고 SLA를 초과했으며 10일째 미해결이라 고위험 조건을 만족합니다"라고 근거까지 붙여서 답한다.

비교해 보면

"진행이 늦어지는 프로젝트 알려줘"라는 같은 질문에 대해:

[일반 RAG]
검색 결과: 회의록 "일정이 좀 늦어지고 있습니다"
답변: A 프로젝트가 늦어지고 있는 것으로 보입니다.

[컨텍스트 레이어]
엔터티: 프로젝트 A (예정일 9/20, 오늘 9/29, 완료율 60%)
규칙:   예정일 경과 AND 완료율 < 100% → 지연 프로젝트
답변:   A 프로젝트는 예정일을 9일 초과했고 완료율 60%라 지연 상태입니다.

차이가 보이는가? 앞의 답은 "그런 것 같다"이고, 뒤의 답은 "이래서 그렇다"다.

정리하면서 가장 크게 와닿은 것

규칙 계산을 LLM에게 맡기면 안 된다. "날짜 비교해서 9일 초과면 지연이라고 판단해"라고 프롬프트로 시키면 대부분은 맞겠지만, 날짜 계산이나 집계에서 가끔 틀리는 게 LLM이다. 규칙은 SQL 뷰나 코드로 미리 계산해 두고, LLM은 "어떤 규칙을 호출할지 고르고, 결과를 설명하는" 역할만 하게 하는 게 훨씬 안정적이다. 벤더들이 하나같이 '검증된 지표 정의'를 강조하는 것도 같은 이유라고 본다. 시멘틱 레이어의 진짜 가치는 결정적(deterministic)인 계산을 LLM 바깥으로 빼 주는 데 있다고 본다.

CSP별로 뭘 팔고 있나

이제 벤더 이야기. 같은 문제를 각자 다른 쪽에서 풀고 있다는 게 재밌다.

Microsoft: IQ 패밀리

Microsoft는 아예 "IQ"라는 브랜드로 묶었다. 여기서 IQ는 지능지수가 아니라, AI가 업무 맥락을 이해하게 만드는 컨텍스트 레이어라는 뜻으로 쓴다.

• Fabric IQ: 이번 글의 주인공. Fabric(OneLake) 위의 기업 데이터에 비즈니스 의미를 입힌다. 공식 페이지 기준으로 다섯 가지를 묶는다. 엔터티·관계·규칙·목표를 정의하는 Ontology, 기존 Power BI 시멘틱 모델, 멀티홉 추론용 Graph 엔진, 자연어 질의용 Data Agent, 이벤트를 감지하고 후속 조치까지 하는 Operations Agent.
• Work IQ: Microsoft 365 쪽. 메일, Teams, 캘린더, 파일에서 "누가 누구와 무슨 일을 하는지"를 이해한다. 조직도가 아니라 실제 협업 관계(Work Chart)를 본다는 게 포인트다.
• Foundry IQ: Azure AI Search 기반의 지식 베이스. 정책 문서, 매뉴얼 같은 비정형 지식을 권한을 지키면서 검색해 준다. 복잡한 질문을 하위 질의로 쪼개 병렬로 검색하고 재순위화한다. 사실상 "잘 만든 엔터프라이즈 RAG"라고 이해했다.
• Web IQ: 웹 정보. 자료마다 언급은 되는데 상세 설명은 거의 없어서 나도 잘 모르겠다.

정리하면 Fabric IQ는 정형 데이터의 의미, Foundry IQ는 문서 지식, Work IQ는 사람과 협업의 맥락이다. 세 개를 겹쳐 쓰라는 게 Microsoft의 그림이다.

출시 상태는 좀 복잡하다. Atlan의 정리에 따르면 Fabric IQ는 Build 2026에서 GA가 발표됐지만 Learn 문서에는 온톨로지 등 일부가 아직 프리뷰로 표기되어 있고, Work IQ는 2026년 6월 GA라고 한다. 그리고 온톨로지가 바인딩할 수 있는 데이터는 OneLake 안의 데이터다. 고객 데이터가 Fabric에 안 올라와 있으면 그것부터가 프로젝트가 된다는 뜻이다. 이건 견적 낼 때 꼭 짚어야 한다.

Google Cloud: Looker 시멘틱 레이어 + Gemini

Google은 원래 갖고 있던 무기를 꺼냈다. Looker의 LookML은 10년 넘게 쓰인 시멘틱 레이어다. 지표, 차원, 조인 경로를 코드로 정의한다.

• Conversational Analytics in Looker: Gemini가 LookML 모델을 근거로 자연어 질의에 답한다. LLM이 SQL을 맨땅에서 짜는 게 아니라 LookML에 정의된 지표와 조인만 쓰도록 묶어 두는 방식이다.
• Gemini Enterprise 연동: Looker에서 만든 대화형 에이전트를 A2A(Agent-to-Agent) 프로토콜로 Gemini Enterprise에 게시할 수 있게 됐다. 업무용 AI 비서에서 Looker 지표를 바로 묻는 그림이다.
• Next '26에서 대시보드 에이전트, 에이전트 기반 시멘틱 모델링(LookML을 AI가 같이 짜 주는 것) 등이 추가로 발표됐다.
• 데이터 카탈로그 쪽은 Dataplex의 비즈니스 용어집(glossary)이 용어사전 역할을 한다.

Microsoft처럼 "온톨로지"라는 단어를 전면에 내세우진 않는다. 내 느낌으론 Google은 "검증된 지표 정의"에 더 무게를 둔다. 관계 그래프 쪽은 상대적으로 약하다.

AWS: 조립형

AWS는 늘 그렇듯 단일 제품보다 부품을 준다.

• Amazon Quick Suite(구 QuickSight): 2025년 10월 QuickSight가 에이전트형 워크스페이스로 확장되면서 이름이 바뀌었다. 여기서 시멘틱 레이어 역할을 하는 게 Topics다. 필드에 동의어, 단위, 설명을 달고, 여러 데이터셋 간 관계를 정의해서 자연어 질의가 런타임 조인을 할 수 있게 한다. 최근에는 기존 Topics를 "시멘틱 데이터셋"으로 옮기라는 가이드도 나왔다.
• Bedrock Knowledge Bases 정형 데이터 지원: Redshift 같은 정형 저장소에 대해 관리형 NL2SQL을 제공한다. 데이터를 옮기지 않고 자연어로 조회한다.
• GraphRAG: Bedrock Knowledge Bases가 Neptune Analytics와 엮어서 그래프 기반 검색을 지원한다.
• 파트너 조합: AWS 블로그에 Stardog의 시멘틱 레이어를 Aurora와 Redshift 위에 얹고, Bedrock AgentCore 위의 Strands 에이전트가 그걸 질의하는 예제가 있다. 온톨로지를 제대로 하고 싶으면 파트너를 쓰라는 메시지로 읽혔다.

비교 한눈에 보기

구분	Microsoft	Google Cloud	AWS
핵심 제품	Fabric IQ (+ Work IQ, Foundry IQ)	Looker (LookML) + Gemini	Quick Suite Topics, Bedrock KB
강점	온톨로지·그래프·액션까지 한 묶음, M365 맥락	검증된 지표 정의, 성숙한 시멘틱 모델	부품 선택 자유, 기존 AWS 데이터 그대로
약점	데이터가 OneLake에 있어야 함, 일부 기능 프리뷰	관계/그래프 추론은 상대적으로 약함	직접 조립해야 할 게 많음
이럴 때	고객이 이미 M365 + Power BI 중심	고객이 이미 Looker/BigQuery 사용	고객 데이터가 Redshift/Aurora에 있음

CSP가 아닌 쪽: 데이터 플랫폼과 SaaS

사실 이 판에서 더 빠르게 움직이는 건 데이터 플랫폼 회사들이다.

Snowflake — Semantic Views + Cortex Analyst. 시멘틱 뷰는 Snowflake의 네이티브 객체다. 논리 테이블, 관계, 팩트, 차원, 지표, 동의어, 그리고 검증된 예시 쿼리(verified queries)를 담는다. Cortex Analyst가 이걸 읽고 자연어 질의를 처리하고, Snowflake Intelligence가 그 위에서 에이전트 UI를 제공한다. YAML 스펙이 공개되어 있어서 구조를 공부하기에 좋다. 나는 시멘틱 레이어에 뭐가 들어가야 하는지 감 잡을 때 이 스펙을 제일 많이 참고했다.

Databricks — Unity Catalog Metric Views + Genie. YAML로 차원과 측정값을 정의하는 메트릭 뷰를 Unity Catalog에 등록하면, SQL·대시보드·AI/BI Genie가 같은 정의를 쓴다. 스타·스노우플레이크 스키마의 멀티홉 조인도 지원한다.

Palantir — Ontology. 이 분야의 원조 격이다. 객체, 링크, 액션을 정의하고 AIP의 에이전트가 그 위에서 동작한다. 비싸고 무겁지만, 고객이 "온톨로지"라는 말을 꺼낼 때 머릿속에 있는 그림은 대개 이거다.

독립 시멘틱 레이어.

• dbt Semantic Layer(MetricFlow): dbt를 이미 쓰는 고객이면 가장 자연스럽다. 지표를 코드로 버전 관리한다.
• Cube: 오픈소스 기반이라 프로토타입에 가볍게 쓰기 좋다. API로 지표를 노출한다.
• AtScale: 대기업 BI 쪽에서 오래 쓰인 시멘틱 레이어.
• Stardog 등 지식 그래프 계열: 관계와 추론이 중요할 때.

표준화 움직임. Snowflake가 주도해 dbt Labs, Salesforce 등과 함께 시작한 OSI(Open Semantic Interchange)가 있다. 시멘틱 정의를 벤더 간에 주고받을 수 있게 하자는 취지다. 아직 초기라 실무 영향은 지켜봐야 할 것 같다. 다만 고객에게 "한 벤더에 정의를 다 박아 두면 나중에 못 옮긴다"는 리스크를 설명할 때 꺼낼 만한 근거는 된다.

그래서 고객한테 뭘 추천하나

내 기준은 단순하다. 고객 데이터가 이미 있는 곳을 따라간다.

• M365 + Power BI를 쓰는 고객 → Fabric IQ부터 검토
• BigQuery/Looker 고객 → LookML + Conversational Analytics
• Snowflake 고객 → Semantic Views + Cortex Analyst
• Databricks 고객 → Metric Views + Genie
• 데이터가 흩어져 있고 어디에도 정착 안 한 고객 → 플랫폼을 고르기 전에 아래의 "플랫폼 없는 프로토타입"으로 가치부터 증명

마지막 케이스가 생각보다 많다. 그리고 그런 고객한테 처음부터 Fabric 전환을 제안하면 POC가 데이터 이관 프로젝트로 변해 버린다. 이건 꽤 확신한다.

우리가 직접 구현할 때의 순서

AI가 처음 준 답변은 "엔터티 정의 → 관계 → 데이터 매핑 → 용어사전 → 규칙 → Agent 연결 → 그래프" 순서였다. 틀린 건 아닌데, 나는 맨 앞에 하나를 추가하고 맨 뒤에 하나를 더 붙였다. 질문 수집과 평가다.

0. 질문 수집        ← 추가
1. 엔터티 정의
2. 관계 정의
3. 데이터 매핑
4. 용어사전
5. 규칙/KPI
6. Agent 연결
7. 그래프 (필요할 때만)
8. 평가            ← 추가

그리고 목표는 작게 잡는다. 많은 조직이 "우리 회사 온톨로지를 만들자"로 시작한다. 그러면 6개월 동안 엔터티 정의 회의만 하다 끝난다. 대신 "우리 팀 업무를 AI가 이해하게 만들자"로 시작하는 게 맞다.

0단계. 질문부터 모은다

엔터티부터 정의하면 끝이 없다. "고객"을 정의하다 보면 "고객 등급", "고객 유형", "잠재 고객"이 줄줄이 나온다. 범위를 자르는 기준이 없기 때문이다.

그래서 질문을 먼저 모은다. 고객 현업 담당자에게 "이 AI한테 실제로 묻고 싶은 질문 20~30개"를 받는다. 이게 이후 모든 단계의 범위 기준이자, 마지막 평가 세트(골든 셋)가 된다.

- 이번 주 가장 위험한 이슈는?
- 담당자별 미해결 이슈는 몇 건이야?
- 회원사 A의 최근 상담 이력과 관련 프로젝트 현황 알려줘
- 지난주 대비 증가한 상담 유형은?
- 이 이슈는 누가 처리해야 해?

질문을 받을 때 "정답은 지금 어떻게 구하세요?"도 같이 물어본다. "엑셀 두 개 열어서 VLOOKUP 합니다" 같은 답이 나오면 그게 바로 관계와 규칙의 힌트다.

1단계. 엔터티 정의 — 질문 속 명사를 뽑는다

모은 질문에서 명사를 뽑으면 엔터티 후보가 나온다. 위 질문들이면 이슈, 담당자, 회원사, 상담건, 프로젝트, 상담 유형 정도다.

엔터티마다 최소한 이것만 적는다.

• 이름과 한 줄 정의
• 식별자(무엇으로 하나를 구분하는가)
• 핵심 속성 3~7개 — 질문에 실제로 쓰이는 것만

처음엔 4~6개면 충분하다. 우리 팀 업무 기준이면 프로젝트, 이슈, 담당자, 작업(Task). 상담 Agent 고객이라면 회원사, 상담건, 담당자, 사업 정도. FAQ, 매뉴얼, 정책 문서 같은 건 엔터티로 모델링하기보다 Foundry IQ 같은 문서 검색 쪽으로 넘기는 게 낫다고 본다. 모든 걸 온톨로지에 넣으려 하지 말자.

2단계. 관계 정의 — 질문 속 동사를 뽑는다

"회원사가 요청한 상담건", "이슈를 담당하는 사람" 처럼 질문 속 연결어가 관계가 된다.

From	관계	To	카디널리티
회원사	요청한다	상담건	1 : N
상담건	발생시킨다	이슈	1 : N
이슈	배정된다	담당자	N : 1
담당자	소속된다	부서	N : 1
프로젝트	포함한다	이슈	1 : N

AI가 처음 준 표에는 카디널리티와 방향이 없었는데, 구현할 땐 이게 꼭 필요하다. 1:N인지 N:M인지에 따라 조인 방식과 집계 결과가 달라진다. N:M을 1:N으로 착각하면 조인하면서 행이 불어나 숫자가 뻥튀기된다. 집계 버그 중 제일 찾기 어려운 유형이다.

3단계. 데이터 매핑 — 각 엔터티가 어느 시스템에 있나

회원사      → CRM (회원사 마스터)
상담건      → 상담 DB
프로젝트 이슈 → Jira
담당자      → 인사 DB / Azure AD
주간보고    → SharePoint 문서
회의 내용   → Teams 회의록

Microsoft 스택이라면 대략 이렇게 나뉜다. 메일·Teams·회의록은 Work IQ, 상담 DB·요구사항·이슈 같은 정형 데이터는 Fabric IQ, 운영 매뉴얼·정책 문서는 Foundry IQ.

이 단계에서 시간이 제일 많이 깨진다. 기술 문제가 아니라 키 문제다. Jira의 담당자는 이메일로, 상담 DB의 담당자는 사번으로, CRM의 담당자는 이름 문자열로 들어 있다. 이 셋을 같은 사람으로 묶는 매핑 테이블이 없으면 관계 탐색이 전부 끊긴다. 고객 미팅 초반에 "시스템 간에 같은 사람/같은 회원사를 어떻게 식별하세요?"를 꼭 물어봐야 한다. 답이 "음..."이면 일정을 늘려 잡는다.

4단계. 용어사전 — 말의 뜻을 고정한다

실제 컨텍스트 레이어는 여기서 시작된다고 봐도 된다. RAG가 실패하는 원인의 상당수가 단어 의미를 모르는 것이기 때문이다.

- term: 회원사
  definition: 협회 상담 서비스의 대상 기업. 가입 상태가 '정상'인 기업만 해당
  synonyms: [회원기업, 회원 업체, 가입사]
  not_to_confuse: [거래처, 파트너사]   # 비슷하지만 다른 개념
  source: CRM.member.status = 'ACTIVE'

- term: 긴급
  definition: SLA 1일 이하인 상담건/이슈
  synonyms: [급건, P1, 최우선]
  source: issue.priority = 'P1'

- term: 완료
  definition: 요청자가 종료를 승인한 상태. 담당자가 '처리'만 한 것은 완료가 아님
  source: issue.status = 'CLOSED_APPROVED'

여기서 노하우 두 가지.

동의어(synonyms)를 최대한 많이 넣는다. 사용자는 "P1"이라고도 하고 "급건"이라고도 한다. Snowflake 시멘틱 뷰나 Quick Suite Topics가 동의어 필드를 따로 두는 데는 이유가 있다.

헷갈리기 쉬운 것(not_to_confuse)을 적는다. "완료"처럼 팀마다 뜻이 다른 단어가 꼭 있다. 이걸 정리하다 보면 고객 내부에서도 정의가 합의 안 되어 있다는 걸 발견하게 되는데, 사실 이게 컨설팅 관점에선 꽤 큰 산출물이다.

5단계. 규칙과 KPI — 계산 가능한 형태로

규칙은 반드시 쿼리로 바꿀 수 있어야 한다. SQL로 못 쓰는 규칙은 아직 규칙이 아니라 의견이다.

-- 고위험 이슈: 긴급 등급 AND 3일 이상 미조치
CREATE VIEW v_high_risk_issue AS
SELECT
  i.issue_id,
  i.title,
  i.project_id,
  i.assignee_id,
  i.priority,
  CURRENT_DATE - i.last_action_date AS days_without_action,
  '긴급 등급이며 ' || (CURRENT_DATE - i.last_action_date) || '일째 미조치' AS reason
FROM issue i
WHERE i.priority = 'P1'
  AND i.status NOT IN ('CLOSED_APPROVED')
  AND CURRENT_DATE - i.last_action_date >= 3;

-- 지연 프로젝트: 예정일 경과 AND 완료율 < 100%
CREATE VIEW v_delayed_project AS
SELECT
  p.project_id,
  p.name,
  p.due_date,
  p.progress_rate,
  CURRENT_DATE - p.due_date AS days_overdue
FROM project p
WHERE p.due_date < CURRENT_DATE
  AND p.progress_rate < 100;

reason 컬럼을 같이 만들어 두는 게 작은 팁이다. LLM이 "왜 고위험인지"를 설명할 때 이 문자열을 근거로 쓰면 지어내는 일이 줄어든다.

규칙마다 오너(누가 이 정의를 책임지는가)도 적어 두자. 나중에 "3일이 아니라 2일이어야 하는데요?"라는 요청이 반드시 온다.

6단계. Agent에 연결 — LLM에게 도구를 준다

여기서부터 RAG와 확실히 달라진다. LLM에게 "문서 검색" 도구 하나만 주는 게 아니라, 시멘틱 레이어를 다루는 도구들을 준다.

[
  {
    "name": "find_entity",
    "description": "이름/별칭으로 엔터티를 찾는다. 예: '협회 프로젝트' → project_id",
    "parameters": { "entity_type": "project|issue|member|person", "keyword": "string" }
  },
  {
    "name": "traverse",
    "description": "엔터티에서 관계를 따라 연결된 엔터티를 조회한다",
    "parameters": { "from_type": "string", "from_id": "string", "relation": "string", "filters": "object" }
  },
  {
    "name": "evaluate_rule",
    "description": "정의된 비즈니스 규칙을 실행한다. 가능한 규칙: high_risk_issue, delayed_project",
    "parameters": { "rule": "string", "scope": "object" }
  },
  {
    "name": "search_documents",
    "description": "정책 문서, 매뉴얼, 회의록에서 근거 문단을 찾는다",
    "parameters": { "query": "string" }
  }
]

그러면 "이 프로젝트에서 위험한 이슈 알려줘"는 이렇게 처리된다.

find_entity(project, "협회 Agent")        → project_id = P-102
evaluate_rule(high_risk_issue, {project_id: P-102})
                                         → 이슈 2건 + reason
traverse(issue, I-881, "assigned_to")    → 담당자 김OO
search_documents("I-881 관련 회의")       → 9/25 회의록 문단
→ 답변: 고위험 이슈 2건, 근거, 담당자, 관련 회의 내용

포인트는 RAG를 버리는 게 아니라는 점이다. 숫자와 판단은 시멘틱 레이어에서, 맥락과 서술은 문서 검색에서 가져와서 섞는다. 내가 보기엔 이 조합이 가장 현실적이다.

시스템 프롬프트에는 용어사전 전체를 넣지 말고, 엔터티 목록과 규칙 목록만 짧게 넣는다. 용어 상세는 find_entity가 필요할 때 조회하게 하자. 용어가 100개를 넘어가면 프롬프트에 다 넣는 방식은 금방 한계가 온다. 이 부분은 컨텍스트 엔지니어링 글과도 이어진다.

7단계. 그래프 — 정말 필요할 때만

Fabric IQ의 핵심 기능 중 하나가 Graph다. 엔터티 연결을 따라 다단계 추론을 한다.

회원사 A → 상담건 #125 → 담당자 김OO → 프로젝트 "Agent 고도화" → 이슈 "SLA 지연"

이런 연결이 있으면 "회원사 A의 최근 이슈와 관련 프로젝트 현황 알려줘" 같은 질문에 답할 수 있다.

그런데 내 생각엔 POC 단계에서 그래프 DB까지 갈 일은 드물다. 홉이 2~3단계면 관계형 DB의 조인으로 충분하다. 그래프가 빛나는 건 홉 수가 가변적이거나("이 협력사 장애가 영향을 주는 모든 프로젝트"), 경로 자체가 궁금할 때다. 그 전까진 조인으로 버티고, 질문 목록에 그런 유형이 늘어나면 그때 그래프를 꺼내자. 그래프 RAG와의 차이는 RAG vs Graph RAG에 따로 정리해 뒀다.

8단계. 평가 — 0단계 질문으로 채점한다

0단계에서 모은 질문 20~30개에 정답을 붙여 골든 셋을 만든다. 그리고 같은 질문을 두 번 돌린다.

• 기존 RAG만으로
• 시멘틱 레이어 + RAG로

비교 항목은 단순하게 잡는다.

• 정답 여부 (숫자가 맞는가)
• 근거 제시 여부 (어떤 규칙, 어떤 데이터로 판단했는가)
• 같은 질문을 다시 했을 때 같은 답이 나오는가

고객 보고에선 이 비교표 한 장이 아키텍처 그림 열 장보다 설득력이 있을 거다. "그래서 뭐가 좋아진 건데요?"라는 질문은 반드시 나오고, 그때 말로만 설명하면 약하다.

플랫폼 없이 먼저 만들어 보는 프로토타입

고객이 아직 플랫폼을 정하지 않았거나, 우리가 빨리 가치를 보여 줘야 할 때 쓰는 구성이다. 우리 팀이 POC에서 쓰기 가장 현실적인 형태라고 생각한다.

[온톨로지 YAML]  엔터티·관계·용어·규칙 정의 (Git으로 관리)
      │
      ▼
[PostgreSQL]     원천 데이터 적재 + 규칙은 VIEW로
      │
      ▼
[도구 API]       find_entity / traverse / evaluate_rule
      │                                      ╲
      ▼                                       ▼
[LLM Agent] ◀──────────────────────── [문서 검색 (기존 RAG)]

온톨로지 YAML은 이 정도 모양이면 시작하기 충분하다.

entities:
  project:
    description: 고객사와 계약된 수행 프로젝트
    table: project
    key: project_id
    display: name
    aliases_column: aliases          # "협회 Agent", "상담봇 고도화" 등
  issue:
    description: 프로젝트 수행 중 발생한 문제 또는 요청
    table: issue
    key: issue_id
  person:
    description: 내부 담당자
    table: person
    key: person_id

relations:
  - name: has_issue
    from: project
    to: issue
    join: project.project_id = issue.project_id
    cardinality: one_to_many
  - name: assigned_to
    from: issue
    to: person
    join: issue.assignee_id = person.person_id
    cardinality: many_to_one

rules:
  high_risk_issue:
    description: 긴급 등급 AND 3일 이상 미조치
    view: v_high_risk_issue
    owner: PMO
  delayed_project:
    description: 예정일 경과 AND 완료율 < 100%
    view: v_delayed_project
    owner: PMO

이렇게 해 두면 좋은 점이 하나 더 있다. 나중에 고객이 Fabric IQ든 Snowflake든 플랫폼을 정하면, 이 YAML이 그대로 이관 설계서가 된다. 엔터티·관계·규칙이라는 개념 자체는 어느 벤더나 같으니까. 실제로 Snowflake 시멘틱 뷰와 Databricks 메트릭 뷰도 YAML 기반이라 구조가 꽤 비슷하다.

4주 POC를 한다면

첫 POC 목표로 가장 현실적인 건 "주간보고 자동 생성 Agent"라고 본다. 데이터가 이미 있고(Jira, 회의록, 메일), 매주 사람이 손으로 하는 일이라 효과가 바로 보이고, 엔터티가 4개(프로젝트, 이슈, 담당자, 액션아이템)면 끝난다.

1주차 — 질문과 엔터티. 현업 인터뷰로 질문 20~30개를 수집하고 정답을 구하는 현재 방식을 기록한다. 엔터티 4개와 관계를 정의하고, 시스템 간 식별 키 매핑 현황을 조사한다. 이 주의 산출물은 질문 목록과 엔터티/관계 정의서.

2주차 — 데이터 연결. Jira, 회의록, 주간보고 원천을 PostgreSQL(또는 고객 플랫폼)에 적재한다. 담당자 키 매핑 테이블을 만든다. 2주차가 밀린다면 대부분 여기서 밀린다.

3주차 — 용어사전과 규칙. 고위험 이슈, 긴급도, 미해결, 배포완료 같은 용어를 정의하고, 규칙을 뷰로 구현한다. 현업과 한 번 리뷰 미팅을 꼭 잡는다. 정의가 틀리면 4주차 결과가 전부 틀린다.

4주차 — Agent와 평가. 도구 API를 만들고 Agent를 연결한다. 골든 셋으로 기존 RAG와 비교 평가하고, 주간보고 초안 자동 생성 데모를 준비한다.

이후 회원사, 상담건, 사업정보까지 확장하면 고객의 상담 Agent 고도화 방향과 자연스럽게 연결된다.

고객 앞에서 써먹을 만한 이야기들

자료를 보고 POC를 구상하면서 정리한 생각들이다. 일부는 아직 가설에 가깝다.

• 고객이 "온톨로지"라는 말을 먼저 꺼내면, 범위를 줄이는 대화부터 한다. "전사 온톨로지"는 POC 범위가 아니다.
• 정의 합의가 기술보다 어렵다. "완료" 하나의 정의를 두고도 부서 간 회의가 열릴 수 있다. 일정에 반영해야 한다.
• 권한을 잊지 말자. 시멘틱 레이어를 거치면 사용자가 원래 못 보던 데이터를 집계로 우회해서 보게 될 수 있다. 행 단위 권한(RLS)을 도구 API 레벨에서 걸어야 한다.
• 데이터 신선도를 답변에 같이 보여 준다. "9/29 06:00 기준"이 붙어 있으면 숫자가 어제와 달라도 고객이 덜 놀란다.
• 규칙의 오너가 정해지지 않으면 운영 단계에서 아무도 고치지 않는다.

아직 고민 중인 부분

몇 가지는 정리가 안 됐다.

용어사전과 규칙을 누가, 어떤 도구로 유지보수하느냐. POC에선 우리가 YAML을 고치면 되지만, 고객에게 넘긴 뒤엔? 현업이 YAML을 고칠 리는 없다. 각 플랫폼의 UI 편집기가 결국 답일 수도 있는데, 그러면 처음 얘기한 벤더 종속 문제로 돌아온다.

LLM이 엔터티 식별을 얼마나 믿을 만하게 하느냐도 아직 모르겠다. "그 프로젝트", "저번에 말한 회원사" 같은 지시어가 나오면 꽤 자주 틀린다. 대화 이력에서 엔터티를 추적하는 별도 장치가 필요할 것 같은데, 아직 깔끔한 방법을 못 찾았다.

그리고 솔직히, 이게 정말 "RAG 다음"인지는 반반이다. 문서가 중심인 업무에선 여전히 RAG가 주인공이고, 시멘틱 레이어는 숫자와 판단이 필요한 질문에서만 빛난다. 둘 다 필요하다는, 좀 재미없는 결론이 맞을지도 모르겠다.

참고자료

• What is Fabric IQ? — Microsoft Learn
• Fabric IQ vs Work IQ vs Foundry IQ — Atlan — 출시 상태와 라이선스 정리가 잘 되어 있다
• Snowflake Semantic View YAML 스펙 — 시멘틱 레이어에 뭘 넣어야 하는지 감 잡기에 좋다
• Conversational Analytics in Looker — Google Cloud
• Build a semantic layer for agentic AI on AWS with Stardog and Amazon Bedrock AgentCore — AWS Blog