- Published on
Apache Ossie: AI 에이전트가 믿을 수 있는 데이터 답변을 하려면 semantic metadata가 먼저 필요하다
- Authors
- Name
- Kyunghyun Park
- @devkhpark
Apache Ossie · Semantic Metadata · AI Agent Data Layer
Apache Ossie가 흥미로운 이유는 “새로운 오픈소스 스펙이 하나 더 나왔다”가 아니다. 더 큰 변화는 데이터 스택에서 오래된 문제였던 지표 정의의 불일치가 이제 AI 에이전트 품질 문제로 직결되고 있다는 점이다.
GitHub 저장소 설명과 공식 README 기준으로 Apache Ossie는 analytics, AI, BI 플랫폼 사이에서 semantic metadata를 교환하기 위한 Apache incubating 프로젝트다. 목표는 vendor-agnostic semantic model specification, 즉 특정 BI·웨어하우스·에이전트 프레임워크에 묶이지 않는 공통 의미 계층이다.
이 글의 관점은 분명하다. AI 데이터 에이전트의 다음 병목은 더 큰 모델이 아니라, 모델이 참조할 수 있는 일관된 비즈니스 의미 계층이다. Ossie는 아직 draft 상태의 스펙이지만, 지금 봐야 하는 이유가 있다. 데이터 제품이 “질문에 답하는 챗봇”에서 “업무 지표를 해석하고 행동을 제안하는 에이전트”로 넘어가면, 같은 KPI가 도구마다 다르게 정의되는 순간 신뢰가 무너진다.
기준 시점: 이 글은 2026-07-17에 확인한 Apache Ossie 공식 사이트, GitHub 저장소, README, roadmap, core specification, converters 디렉터리 정보를 바탕으로 썼다. Ossie core spec은
0.2.0.dev0draft로 표시되어 있으므로 실제 도입 전 최신 스펙을 다시 확인해야 한다.
문제는 “AI가 SQL을 잘 짜느냐”가 아니라 “무엇을 매출이라고 부르느냐”다
많은 팀이 AI 데이터 분석을 붙일 때 먼저 모델과 쿼리 생성 능력을 본다. 자연어 질문을 SQL로 바꿔주는가, 차트를 그려주는가, 대시보드를 설명해주는가. 물론 중요하다. 하지만 실무에서 더 위험한 실패는 보통 SQL 문법 오류가 아니다.
더 자주 터지는 문제는 이런 것이다.
- 영업팀 대시보드의 “활성 고객”과 재무팀 리포트의 “활성 고객”이 다르다.
- BI 도구에서는 환불 차감 후 매출을 쓰는데, 노트북에서는 총 거래액을 쓴다.
- LLM 에이전트는 어느 테이블을 기준으로 metric grain을 잡아야 하는지 모른다.
- 데이터 카탈로그, dbt 모델, BI semantic layer, 사내 챗봇이 각각 다른 설명을 갖고 있다.
이 상태에서 AI 에이전트만 붙이면 결과는 그럴듯하지만 위험해진다. 모델은 자신감 있게 답하지만, 그 답이 회사 안에서 합의된 비즈니스 정의와 맞는지는 보장하지 못한다.
Apache Ossie README가 말하는 “semantic fragmentation”은 바로 이 문제다. 같은 KPI가 도구마다 다르게 정의되고, 팀이 수작업으로 정의를 맞추며, AI 에이전트가 inconsistent business logic 위에서 불안정한 출력을 만든다는 것이다.
여기서 포인트는 AI가 데이터 스택의 문제를 해결하는 게 아니라, 오히려 기존 의미 불일치를 더 크게 드러낸다는 점이다. 사람이 대시보드를 읽을 때는 “이 팀의 매출 정의는 조금 다르다”는 암묵지가 작동한다. 하지만 에이전트는 그 암묵지를 모르면 잘못된 정의를 빠르게 확산시킨다.
Ossie가 제안하는 것은 semantic model의 교환 포맷이다
Apache Ossie의 README는 프로젝트를 “semantic model exchange and utilization”을 표준화하는 노력이라고 설명한다. 단순히 메타데이터를 모아두자는 말이 아니다. 여러 도구가 읽고 쓸 수 있는 JSON/YAML 기반 specification을 만들자는 것이다.
공식 저장소 구조도 이 방향을 꽤 선명하게 보여준다.
core-spec/— core specification, machine-readable schema, 문서converters/— dbt, GoodData, Polaris, Salesforce, Snowflake 등과의 변환기examples/— TPC-DS와 flights 예제 semantic modelvalidation/— Ossie schema에 맞는지 검증하는 도구ROADMAP.md— metric semantics, catalog integration, ontology, logical modeling 같은 작업 그룹
즉 Ossie는 “대시보드 하나 더”가 아니라 도구 사이를 오가는 의미의 계약서에 가깝다. BI 도구, 데이터 카탈로그, AI 에이전트, 분석 파이프라인이 모두 같은 계약서를 읽을 수 있다면, 최소한 “어떤 지표를 어떤 grain과 relationship으로 해석할 것인가”를 일관되게 다룰 수 있다.
이 관점에서 Ossie의 경쟁자는 특정 LLM 프레임워크가 아니다. 오히려 사내 곳곳에 흩어진 metric 문서, BI semantic layer, dbt 모델, 데이터 카탈로그, 에이전트 prompt 조각이다. Ossie가 성공하려면 이 조각들을 하나의 이식 가능한 의미 계층으로 묶어야 한다.
Core spec에서 가장 중요한 단어는 ai_context다
Ossie core specification은 draft 0.2.0.dev0로 표시되어 있다. 아직 확정된 표준으로 보기는 이르다. 그래도 현재 spec이 무엇을 중요하게 보는지는 읽을 수 있다.
상위 semantic model은 datasets, relationships, metrics, custom_extensions를 담는다. dataset은 source, primary_key, unique_keys, fields를 가진다. relationship은 logical dataset 사이의 foreign key 관계를 표현한다. metric은 aggregation, filter, expression 같은 해석 규칙을 담는다.
여기까지는 전통적인 semantic layer 문맥과 크게 다르지 않다. 그런데 AI 관점에서 눈에 띄는 필드가 있다. ai_context다.
Spec 예시는 semantic model과 dataset, relationship 레벨에 ai_context를 둔다. 예컨대 dataset에는 synonyms나 common terms를 넣어 LLM이 비즈니스 의미를 더 잘 이해하게 할 수 있다. semantic model에는 “이 모델을 sales analysis와 customer insights에 사용하라” 같은 instruction을 넣을 수 있다.
이건 작지만 중요한 설계 신호다. 지금까지 많은 팀은 LLM을 데이터베이스에 붙일 때 prompt 안에 업무 설명을 넣었다. 하지만 prompt는 쉽게 흩어진다. 어느 서비스에는 최신 설명이 있고, 어느 노트북에는 예전 설명이 남아 있다. ai_context가 semantic metadata의 일부가 되면, AI에게 줄 비즈니스 문맥도 버전 관리·검증·교환의 대상이 된다.
물론 위험도 있다. ai_context가 아무 텍스트나 들어가는 “프롬프트 쓰레기통”이 되면 표준의 의미가 약해진다. 그래서 실무에서는 이 필드를 문서가 아니라 운영 인터페이스로 봐야 한다. 누가 업데이트하는가, 어떤 리뷰를 거치는가, 어떤 에이전트가 읽을 수 있는가, 오래된 context를 어떻게 폐기하는가까지 정해야 한다.
Roadmap은 “메트릭 정의”에서 “거버넌스 가능한 semantic service”로 간다
Ossie roadmap에서 현재 작업 그룹으로 잡힌 축은 세 가지다.
첫째, Metric Semantics & Core Semantic Model이다. metrics, aggregation, relationship, grain, semantic filters, derived/cumulative metrics 같은 항목이 나온다. 이건 AI 분석의 품질을 좌우한다. “지난 30일 활성 사용자” 같은 질문은 metric grain, filter, relationship 정의가 모호하면 모델이 아무리 좋아도 틀린다.
둘째, Catalog Integration & Semantic Services다. roadmap은 semantic model이 discoverable, governable, shareable해야 한다고 말한다. 여기서 중요한 단어는 service와 registry다. semantic metadata가 파일 하나로 끝나는 게 아니라, 접근 제어·버전·발견 가능한 중앙 계층이 되어야 한다는 뜻이다.
셋째, Ontology & Semantic Interoperability다. README가 말하는 구조적 interoperability를 넘어, 서로 다른 모델이 같은 business concept을 다른 이름과 구조로 표현할 때 이를 맞추는 conceptual interoperability까지 보겠다는 방향이다.
이 방향은 AI 에이전트 관점에서 꽤 현실적이다. 에이전트가 사내 데이터를 다룰수록 필요한 것은 단순한 schema dump가 아니다. 고객, 주문, 제품, 활성 사용자, 순매출 같은 비즈니스 개념이 물리 테이블과 어떻게 연결되는지, 누가 그 정의를 승인했는지, 언제 바뀌었는지를 알아야 한다.
Converters는 표준의 야심과 현실 사이를 보여준다
좋은 표준은 선언만으로 채택되지 않는다. 기존 시스템과 연결되어야 한다. Ossie 저장소의 converters/ 디렉터리가 중요한 이유가 여기에 있다. 2026-07-17 기준으로 converters에는 dbt, GoodData, Honeydew, Omni, Orionbelt, Polaris, Salesforce, Snowflake 관련 디렉터리가 보인다.
이 목록은 Ossie가 겨냥하는 위치를 보여준다. 데이터 모델링, BI, CRM/analytics, warehouse semantic metadata가 이미 각자의 형식으로 존재한다. Ossie가 모든 도구를 대체하겠다는 것이 아니라, 그 사이를 변환 가능한 공통 형식으로 묶겠다는 쪽에 가깝다.
실무적으로는 이 지점이 가장 중요하다. 팀이 새 표준을 도입할 때 “우리 BI를 갈아엎자”로 시작하면 실패한다. 대신 “기존 dbt/BI/catalog 정의를 Ossie로 export/import하고, AI 에이전트가 같은 semantic model을 읽게 하자”로 접근해야 가능성이 생긴다.
한국 개발팀이 지금 봐야 할 실무 포인트
Apache Ossie가 아직 draft라는 점 때문에 “나중에 보자”고 넘길 수도 있다. 하지만 AI 데이터 제품을 만들고 있다면 지금 봐야 할 질문들이 있다.
1) 사내 KPI 정의는 코드처럼 버전 관리되고 있는가
매출, 활성 고객, 전환율, retention 같은 핵심 metric이 문서·슬랙·BI 설정·SQL 조각에 흩어져 있다면, AI 에이전트는 그 혼란을 그대로 학습한다. 최소한 핵심 지표부터 semantic model로 옮길 준비가 필요하다.
2) 에이전트가 읽는 schema 설명과 BI가 쓰는 정의가 같은가
많은 팀이 LLM용 schema summary를 따로 만든다. 문제는 이 요약이 BI semantic layer와 따로 늙는다는 점이다. Ossie식 접근은 이 둘을 분리하지 말자는 주장에 가깝다.
3) 검증 도구가 있는가
Ossie에는 validation tooling이 포함되어 있다. 이 방향이 중요한 이유는 semantic metadata도 CI 대상이 되어야 하기 때문이다. metric definition이 바뀌었는데 relationship이 깨졌거나, AI context가 오래된 테이블명을 가리키면 배포 전에 잡아야 한다.
4) 표준 채택보다 먼저 “semantic inventory”를 해야 한다
도구부터 도입하면 실패한다. 먼저 사내 핵심 지표, 도메인 개념, 데이터 소스, BI 정의, 에이전트 prompt를 inventory해야 한다. 그다음 어떤 정의를 canonical로 둘지 정해야 한다.
실무 해석: AI 데이터 에이전트는 semantic layer 없이는 프로덕션 제품이 되기 어렵다
Apache Ossie를 단순히 “데이터 엔지니어용 표준”으로만 보면 절반만 보는 것이다. 이 프로젝트의 진짜 의미는 AI 에이전트가 데이터 조직 안으로 들어올 때 필요한 운영 계층을 드러낸다는 데 있다.
LLM은 자연어와 SQL 사이의 간극을 줄인다. 하지만 비즈니스 의미의 간극은 자동으로 사라지지 않는다. 오히려 LLM이 더 많이 배포될수록 그 간극은 더 비싼 장애가 된다. 고객에게 잘못된 매출 분석을 보여주거나, 경영진에게 다른 대시보드와 충돌하는 답변을 내거나, 자동화된 액션이 잘못된 cohort를 대상으로 실행될 수 있기 때문이다.
그래서 AI 데이터 에이전트의 production readiness는 다음 순서로 봐야 한다.
- 모델이 질문을 이해하는가
- 올바른 데이터 소스를 찾는가
- 회사가 합의한 semantic model을 참조하는가
- metric grain과 relationship을 검증하는가
- 답변에 사용한 정의와 버전을 설명할 수 있는가
- 정의 변경이 CI와 리뷰를 거치는가
많은 제품 데모는 1번과 2번에서 멋져 보인다. 하지만 운영 신뢰성은 3번 이후에서 갈린다. Ossie는 바로 그 후반부를 겨냥한다.
도입한다면 작은 기준선부터 잡아라
지금 당장 모든 semantic metadata를 Ossie로 옮길 필요는 없다. 오히려 작은 범위에서 시작하는 편이 좋다.
- 가장 자주 묻는 10개 KPI를 고른다.
- 각 KPI의 owner, 정의, grain, filter, source table, BI 대시보드 링크를 정리한다.
- dbt/BI/catalog에 흩어진 정의와 불일치를 찾는다.
- Ossie core spec의 구조에 맞춰 dataset, relationship, metric 초안을 만든다.
- validation을 CI에 붙일 수 있는지 본다.
- AI 에이전트가 해당 semantic model과
ai_context만 참조하도록 제한한다.
이 정도만 해도 효과가 있다. 목표는 표준을 “완벽히 도입”하는 게 아니라, AI가 참조하는 의미 계층을 제품 운영의 통제면 안으로 끌어들이는 것이다.
결론: Ossie는 AI 시대의 데이터 계약을 다시 쓰려는 시도다
Apache Ossie는 아직 초기다. core spec은 draft이고, roadmap은 열려 있으며, 실제 생태계 채택은 앞으로 봐야 한다. 그럼에도 지금 주목할 가치가 있다.
AI 에이전트가 데이터를 읽고, 지표를 설명하고, 의사결정 흐름에 들어오는 순간 semantic metadata는 문서가 아니라 런타임 의존성이 된다. 이 의존성을 표준화·검증·교환 가능하게 만들지 않으면, AI 데이터 제품은 “말은 잘하지만 믿기 어려운 분석가”에 머무를 가능성이 크다.
Apache Ossie의 핵심 메시지는 간단하다. AI에게 더 많은 데이터를 주기 전에, 그 데이터가 무엇을 의미하는지부터 공통 언어로 묶어야 한다.