ktx, 데이터 에이전트에 컨텍스트 계층을 붙이다

데이터 에이전트는 스키마만으로 부족하다

Kaelio의 ktx는 데이터 에이전트를 위한 컨텍스트 계층을 표방하는 오픈소스 프로젝트다. README는 ktx가 승인된 지표 정의, 조인 가능한 컬럼, 비즈니스 지식을 바탕으로 에이전트가 데이터 웨어하우스를 정확히 질의하도록 돕는다고 설명한다. PostgreSQL, Snowflake, BigQuery, ClickHouse, MySQL, SQL Server, SQLite를 지원하고 dbt, MetricFlow, LookML, Looker, Metabase, Notion과 통합한다고 안내한다.

이 문제는 단순하다. 에이전트에게 DB 연결만 주면 SQL은 만들 수 있다. 그러나 어떤 테이블이 매출의 정본인지, 어떤 조인이 팬아웃을 만드는지, 환불을 매출에서 빼야 하는지, active customer가 조직에서 무엇을 뜻하는지는 스키마만으로 알 수 없다. ktx 문서는 컨텍스트 계층을 데이터 스택과 에이전트 사이의 신뢰 가능한 지식 표면으로 정의한다.

로컬 파일로 만드는 의미 계약

ktx의 흥미로운 선택은 컨텍스트를 SaaS 블랙박스가 아니라 로컬 파일로 만든다는 점이다. 문서에 따르면 컨텍스트 계층은 YAML, Markdown, JSON 파일로 구성되며 사람이 리뷰할 수 있다. 시맨틱 소스 YAML은 테이블 grain, 조인, measure, dimension, filter를 담고, 위키 Markdown은 정책, 예외, 지표 해석, 업무 정의를 담는다. 이는 Models.dev, 모델 선택을 데이터 문제로 바꾸다가 모델 메타데이터를 공개 데이터로 다루려 한 흐름과 비슷하다. 에이전트 시대에는 숨은 설정보다 검토 가능한 파일이 더 강한 운영 자산이 된다.

Building Context 문서는 ktx setup 이후 ktx ingest <connectionId> 또는 ktx ingest --all로 컨텍스트를 빌드하고, 생성된 semantic-layer/와 wiki/ 파일을 검색, 수정, 검증한 뒤 에이전트에 넘기는 흐름을 제시한다. deep ingest는 설명, 임베딩, 관계 증거, 선택적 쿼리 히스토리까지 포함할 수 있고, dbt, MetricFlow, Looker, Metabase, Notion 같은 소스에서 메타데이터를 끌어온다.

MCP보다 중요한 것은 정본성이다

ktx는 CLI와 MCP 도구를 제공해 Claude Code, Codex, Cursor, OpenCode 같은 에이전트가 컨텍스트를 검색하게 한다. 하지만 핵심은 MCP 연결 자체가 아니다. 핵심은 에이전트가 매번 "그럴듯한 SQL"을 새로 쓰지 않고, 승인된 metric과 wiki 정의를 먼저 찾도록 만드는 것이다. Semble, 에이전트 코드 검색의 토큰세를 줄이다가 코드베이스 검색 비용을 줄이려 했다면, ktx는 데이터 조직의 의미 검색 비용을 줄이려 한다.

README는 ktx가 자체 호스팅 서비스를 필요로 하지 않고 로컬에서 실행되며, 창고 연결은 read-only라고 설명한다. 동시에 LLM 백엔드는 사용자가 설정한 Anthropic API, Google Vertex AI, AI Gateway, 로컬 Claude Code 세션 등을 쓴다. 즉 ktx 자체가 모델 비용을 대신 내는 제품이 아니라, 에이전트가 쓸 컨텍스트를 정리하는 계층이다. 이 구분은 중요하다. 데이터 유출과 비용 책임은 여전히 도입 조직의 설정에 달려 있다.

한국 데이터팀에 주는 의미

한국 기업의 데이터 문제는 종종 모델 성능보다 지표 정의 불일치에서 온다. 같은 매출, 활성 사용자, 이탈률이 부서마다 다르게 계산된다. 분석가는 Slack, Notion, dbt, Looker, 스프레드시트에 흩어진 맥락을 머릿속으로 합친다. 이 상태에서 데이터 에이전트를 붙이면 빠른 답변은 나오지만, 틀린 답변도 더 빠르게 확산된다. 공공변호 현장이 법률 AI에 던지는 질문이 전문 업무에서 맥락과 책임의 중요성을 보여준 것처럼, 데이터 업무도 정본성 없이는 자동화가 위험하다.

ktx가 시사하는 운영 원칙은 세 가지다. 첫째, 지표 정의는 코드처럼 리뷰하고 버전 관리한다. 둘째, 에이전트가 읽는 업무 지식은 출처와 연결 관계를 가져야 한다. 셋째, read-only와 네트워크 경계를 기본값으로 둔다. 데이터 에이전트의 경쟁력은 더 좋은 문장으로 SQL을 설명하는 데 있지 않다. 조직이 합의한 의미를 얼마나 안정적으로 재사용하는지에 있다.

자주 묻는 질문

Q1: ktx는 BI 도구인가요?

A: 전통적 대시보드 도구라기보다 에이전트가 사용할 컨텍스트와 시맨틱 계층을 만드는 도구에 가깝다.

Q2: 데이터베이스 쓰기 권한이 필요한가요?

A: README는 연결이 read-only이며 ktx가 데이터베이스에 쓰지 않는다고 설명한다.

Q3: 기존 dbt나 Looker가 있으면 필요 없나요?

A: 반드시 그런 것은 아니다. ktx는 그런 소스의 정의를 에이전트가 검색할 수 있는 파일과 위키로 결합하려 한다.

Q4: LLM API 비용은 누가 부담하나요?

A: 사용자가 설정한 LLM 백엔드를 사용한다. ktx 자체가 별도 사용량 과금을 대신 부담하는 구조는 아니다.

Q5: 한국 조직이 먼저 준비할 것은 무엇인가요?

A: 핵심 지표의 정본 정의, 조인 금지 규칙, 예외 정책을 파일로 옮기고 리뷰 절차를 만드는 일이다.