데이터 사전은 왜 6개월을 못 버티는가

차세대 정보계 프로젝트에서 여러 벤더와 1년 넘게 작업한 적이 있다. 초반에 데이터 사전을 야심차게 구축했다. “매출”, “원가”, “순매출"의 정의를 벤더별로 맞추고, 테이블 매핑까지 꼼꼼하게 채웠다. 반년쯤 지나니까 신규 테이블은 등록이 안 되고, 기존 정의는 스키마 변경을 반영하지 못하고, 부서 간 해석 차이는 그대로 방치됐다. “어차피 안 맞으니까"가 팀의 공식 입장이 됐다.

카탈로그든 위키든 데이터 사전이든 이름만 다를 뿐 결과는 같다. 만들 때는 열심히 채우는데 유지보수를 못 해서 방치된다.

Karpathy가 며칠 전 X에 LLM 지식 베이스 아이디어를 올렸고, 후속으로 전체 아키텍처를 GitHub Gist에 공개했다 (Karpathy LLM Wiki). 개인 지식 베이스 구축 얘기인데, DataNexus 카탈로그 만들면서 부딪힌 문제와 비슷했다.

RAG는 매번 처음부터 시작한다

대부분의 LLM 문서 활용 방식은 RAG다. NotebookLM, ChatGPT 파일 업로드, 사내 문서 검색 시스템 전부 원본을 청크로 쪼개서 벡터 검색하는 방식이다. 잘 되는 것 같은데, 한 가지 불만이 있다. 어제 다섯 개 문서를 종합해서 답변한 내용을 오늘 다시 물어도 LLM은 같은 검색부터 시작한다. 아무것도 기억하지 않는다.

DataNexus에서도 이게 걸렸다. 1편 에서 온톨로지를 RAG Store에 넣어서 맥락을 주입하는 구조를 설계했는데, 온톨로지가 실제 스키마와 달라지면 NL2SQL이 틀린 SQL을 만든다. RAG Store 자체를 최신으로 유지하는 문제는 아직 풀지 못했다.

위키를 LLM한테 맡긴다

Karpathy의 접근은 간단하게 말하면 이렇다. RAG처럼 매번 원본을 뒤지는 대신, LLM이 마크다운 위키를 직접 관리하게 한다. 원본 자료(Raw Sources)는 사람이 넣고, LLM이 읽어서 위키(Wiki)에 정리한다. 위키의 구조와 규칙을 정의하는 설정 문서(Schema)가 있어야 LLM이 아무렇게나 쓰지 않고 일관된 방식으로 정리한다.

새 소스가 들어오면(Ingest) LLM이 요약하고 관련 페이지 10~15개를 갱신한다. 위키에 질문하면(Query) 답변 과정에서 나온 발견이 다시 위키에 기록된다. 주기적으로 모순이나 오래된 정보를 잡아내는 점검(Lint)도 돌린다.

Karpathy 본인은 Obsidian을 열어두고 LLM 에이전트와 나란히 작업한다고 한다. Obsidian이 IDE, LLM이 프로그래머, 위키가 코드베이스라는 비유를 썼는데, 개발자한테는 바로 와닿는 비유다.

여기서 내가 눈여겨본 건 Schema다. 3편 에서 DataHub의 Business Glossary를 온톨로지 저장소로 쓰면서 관계 유형이 4가지밖에 안 돼서 고생했다는 얘기를 썼다. Karpathy의 Schema도 비슷한 역할이다. LLM한테 “이 용어는 이런 관계 유형으로만 연결해"라고 알려주는 규칙서. 이게 없으면 LLM이 제멋대로 정리해서 오히려 엉망이 될 수 있다.

진짜 병목은 유지보수다

데이터 사전이든 위키든 작성은 어렵지 않다. 프로젝트 초반에 사람 몇 명 붙이면 된다. 문제는 그 다음이다. 페이지가 100개를 넘어가면 교차참조 갱신, 요약 업데이트, 모순 탐지에 드는 시간이 눈에 띄게 불어난다. 사람은 이 시점에서 슬슬 손을 놓는다.

DataNexus도 여기가 걱정이다. 용어 등록, 관계 설정, DozerDB 동기화까지는 만들었다. 근데 DW 스키마는 오픈 이후에도 계속 바뀐다. 단계별 릴리즈가 이어지면 테이블이 추가되고, “순매출” 계산식에 새로운 차감 항목이 생기기도 한다. 이걸 카탈로그에 반영하는 걸 누가 할 것이냐가 문제다.

LLM이라면 파일 15개를 동시에 업데이트할 수 있다. DataHub에서 이미 MCL(Metadata Change Log) 이벤트를 발행하고 있으니, LLM이 이 이벤트를 받아서 영향받는 용어 페이지를 갱신하고 교차참조를 업데이트하는 구조가 가능하다. 4편 에서 설계한 SKOS 호환 레이어의 규칙이 Schema 역할을 하면 된다.

1편에서 “변경을 감지해서 자동으로 RAG Store를 갱신하는 파이프라인이 필요하다"고 썼는데, 그때는 막연했다. Karpathy의 Ingest/Query/Lint 패턴을 보고 나서야 그 파이프라인의 밑그림이 잡혔다.

물론 이게 바로 될 거라고 생각하지는 않는다. LLM이 온톨로지를 자동 갱신할 때 틀린 관계를 만들 수도 있고, 도메인 전문가의 검수가 어디까지 필요한지도 아직 모른다. 이건 메타데이터 변경 감지 파이프라인을 만들면서 부딪혀 볼 문제다.

사람이 못 하는 일

Karpathy가 1945년 Memex까지 끌어온 건, 이 문제가 새로운 게 아니라는 얘기일 거다. 80년 전 구상인데 사람이 관리 비용을 감당 못 해서 매번 실패했다.

Karpathy도 코드 짜는 데 쓰던 LLM 토큰을 요즘은 지식 정리에 더 많이 쓴다고 했는데, DataNexus 만들면서 나도 그쪽으로 가고 있다. 용어 정리, 매핑, 해석 차이 맞추기. 사람이 하면 6개월이면 포기한다. LLM한테 맡기면 어떻게 될지 실험해 볼 생각이다.

DataNexus를 설계하고 구축하는 과정을 기록합니다. GitHub | LinkedIn