아직 정원에 없는 층 — 글쓰기 하네스가 제품의 하네스가 되려면

3줄 요약 • 이 하네스에는 도메인 계층이 없다 — 그리고 지금까지는 없어도 됐다. 매 편이 새 주제로 시작하고 글과 함께 완결되기 때문이다. 그러나 하네스가 제품의 최신 정보 제공, 올바른 운영 안내, 다음 기능을 위한 기존 기능 개선을 맡는 순간 성질이 바뀐다 — 글은 끝나도 도메인은 계속 자라고, 단순하게 도메인을 다루는 방법으로는 충분하지 않다. • 씨앗 글이 건넨 지도는 두 층이다. 카파시의 LLM 위키는 불확실한 지식을 축적하는 층, Microsoft의 온톨로지는 조직이 책임질 뜻을 고정하는 층 — 그리고 다음 단계는 위키를 버리는 것이 아니라, 위키에서 반복 검증된 지식을 온톨로지 계약으로 승격하는 것이다. • 이 확신은 독해가 아니라 실습에서 왔다 — 기획정책서를 도메인 주도 설계(DDD)로 재해석해 그래프로 잇고, 작은 놀이터에서 먼저 배우고, 고객의 소리(VOC)를 연결하자 리스크 등급표가 아닌 로드맵의 언어가 생겼으며, 노드 그래프가 아니라 인포그래픽으로 번역했을 때 비로소 이해가 열렸다.

1. 없어도 됐던 층

열일곱 편 동안 이 정원의 토양은 세 층이면 충분했다 — 판단 기준을 심는 지식(knowledge), 역할과 책임을 긋는 에이전트(agents), 일이 흐르는 물길(engine). 눈 밝은 독자라면 눈치챘겠지만, 이 지식 층에 들어 있는 것은 문체와 용어와 규약 — 장인의 지식이다. 글감 자체에 대한 주제의 지식, 이른바 도메인 계층은 없다. 그리고 그것은 결핍이 아니었다. 이 하네스의 업무는 매 편 새로운 주제로 시작하는 글쓰기이고, 조사한 지식은 참고 자료와 함께 글 안에서 완결된다. 글이 끝나면 그 주제와의 계약도 끝난다.

그런데 하네스가 다른 일을 맡는다고 상상해 보자. 제품의 최신 정보를 계속 제공하는 문서, 제품의 올바른 운영을 안내하는 가이드, 다음 기능을 만들기 위해 기존 기능을 정리하고 개선하는 문서 — 새로운 글쓰기가 아니라, 지속 성장하는 대상을 따라가는 글쓰기다. 이때 성질이 바뀐다. 글은 끝나도 도메인은 계속 자란다. 어제의 문서가 오늘의 기능과 어긋나기 시작하고, 같은 기능이 문서마다 다른 이름으로 불리기 시작하며, "이 화면·이 설정·이 정책"이 정확히 무엇을 가리키는지가 흔들리기 시작한다. 복잡한 도메인이 자라나는 곳에서, 단순하게 도메인을 다루는 방법 — 노트 폴더 하나, 잘 쓴 위키 몇 페이지 — 으로는 충분하지 않다.

이번 편은 그 "충분하지 않음"의 지도를 그린다. 씨앗 글 모델이 문서를 읽는 시대를 넘어 — Karpathy Wiki에서 Microsoft Ontology까지를 들여온다. 미리 고백하면, 이 씨앗은 책상에서 고른 것이 아니다 — 우리가 먼저 만져 보고, 중요해질 것을 직감했기에 심은 씨앗이다(그 실습기가 4절과 5절이다).

시리즈 독자를 위한 정직 고지 하나: 17편이 예고한 스킬 내장 Eval(평가, evaluation) 장착 실전기는 이번 편이 아니다. 시리즈의 다음 단계가 두 갈래가 되었기 때문이다 — 정원을 더 단단하게 만드는 심화(Eval 장착)와, 정원이 더 큰 도메인을 맡을 준비를 하는 확장. 이번 사이클의 베팅은 확장의 답사다. 심화의 약속은 유효하다.

2. 두 개의 이름 — 읽을 수 있는 지식과 실행할 수 있는 의미

씨앗 글의 첫 번째 이름은 안드레이 카파시(Andrej Karpathy)가 제안한 LLM 위키다. 원문 gist의 설계는 명료하다. 원문 자료(raw sources)는 불변으로 보관하고, LLM(Large Language Model, 대규모 언어 모델)이 그 위에 구조화된 마크다운 위키 — 요약, 개념 페이지, 인물·개체 페이지, 상호 링크 — 를 증분으로 유지한다. 운영은 세 동작이다: 새 자료를 소화해 관련 페이지들에 통합하는 Ingest, 원문이 아니라 이미 종합된 위키를 검색하는 Query, 그리고 모순·고아 페이지·낡은 주장·누락된 링크를 주기적으로 점검하는 Lint. 매번 검색해서 다시 종합하는 대신, 위키는 축적되는 지속 자산이 된다 — 상호 참조가 이미 거기 있다.

두 번째 이름은 Microsoft가 말하는 **온톨로지(Ontology)**다. 여기서 기본 단위는 문서가 아니라 업무 객체다. Customer, Order, Supplier처럼 실제 데이터와 연결될 대상을 정의하고, 각 대상에 식별자와 속성을 부여하며, 관계를 방향 있는 동사로 명시한다 — Customer places Order, Supplier provides Product. 관계에는 카디널리티(cardinality, 관계에 허용되는 개수 규칙)까지 붙는다. 씨앗 글의 대조를 한 표로 줄이면:

질문	LLM 위키	온톨로지
무엇을 저장하는가	문서, 조사, 개념, 출처, 해석	업무 객체, 식별자, 속성, 관계, 규칙
연결은 어떻게 만드는가	링크와 LLM의 의미 요약	타입 있는 관계, 방향, 카디널리티
강점	빠른 축적, 설명, 모순과 불확실성 보존	일관성, 검증, 그래프 탐색, 권한 통제
잘 맞는 대상	기술 조사, 시장 리서치, 회의 기록	고객, 주문, 계약, 자산, 운영 이벤트
에이전트에 주는 것	길고 풍부한 작업 맥락	정확한 객체 참조와 행동 경계

씨앗 글의 핵심 결론이 여기서 나온다. 둘은 경쟁하지 않는다 — 그리고 둘 중 하나만 고르면 대개 실패한다. 모든 문서를 온톨로지로 만들면 모델링 비용이 폭발하고, 반대로 고객·계약·결제·권한까지 위키 링크로만 관리하면 에이전트가 실제 행동에 들어가는 순간 모호성이 사고로 바뀐다. 위키는 새 정보를 소화하는 곳이고, 온톨로지는 충분히 안정되어 조직이 책임질 수 있는 뜻을 고정하는 곳이다.

3. 작은 놀이터 — 온톨로지 설계의 최소 단위

온톨로지라는 말은 무겁게 들리지만, Microsoft가 공개한 오픈소스 학습 도구 Ontology Playground(라이브 데모)는 그 설계의 최소 단위를 만질 수 있는 크기로 보여준다. React 기반 정적 사이트라 백엔드 없이 돌고, 미리 준비된 도메인 예시(소매·의료·제조 등)를 탐색하거나 시각 편집기로 엔터티·속성·관계를 만들어 RDF(Resource Description Framework, 그래프 지식 표현 표준)로 내보낼 수 있다. 이 작은 도구가 가르치는 원칙이 알차다.

• 엔터티(entity)는 사람이나 사물이 아니라 업무상 구분 가능한 대상이다.
• 각 엔터티는 적어도 하나의 식별자를 가져야 한다.
• 관계는 명사가 아니라 방향을 가진 동사로 이름 붙이는 편이 낫다.
• 카디널리티는 데이터 모델의 장식이 아니라 에이전트의 탐색 범위를 정하는 제약이다.
• 좋은 온톨로지는 기업 전체 지도를 한 번에 그리지 않는다 — 핵심 객체 셋에서 여덟 개와 그 관계부터 시작한다.

정직 고지를 씨앗 글에서 그대로 계승한다. Playground는 운영 플랫폼이 아니다. 저장소의 자체 Gap Analysis가 실제 Fabric IQ(6절에서 다룰 Microsoft의 운영 의미 계층)와의 거리를 명시한다 — 데이터 바인딩(data binding, 온톨로지 객체를 실제 테이블·이벤트 원천에 연결하는 일)과 인스턴스 그래프(instance graph, 온톨로지 정의를 실제 데이터에 연결해 만든 조회 가능한 그래프) 생성, 품질 제약은 부분 구현이거나 계획 단계이고, 자연어 질의 기능도 규칙 기반 매칭의 학습용 데모이지 운영형 엔진이 아니다. 온톨로지의 가치는 멋진 노드 그래프가 아니라 실제 데이터와 연결된 식별자·관계·규칙·권한에서 나온다 — 이 한계를 아는 것 자체가 학습의 일부다.

4. 우리는 먼저 만져 봤다 — 기획정책서를 DDD로 잇다

여기서부터는 답사기다. 우리는 이 개념들을 글로 배우기 전에 손으로 먼저 배웠다.

재료는 우리 곁에 이미 쌓여 있던 것 — 기획정책서였다. 제품이 자라는 동안 기획과 정책 문서는 계속 늘어나는데, 그 안의 개념들은 서로를 부르는 이름이 조금씩 다르고, 어떤 정책이 어떤 기능에 닿아 있는지는 문서를 다 읽은 사람의 머릿속에만 있다. 우리는 이 문서 더미를 13편에서 들여온 DDD(Domain-Driven Design, 도메인 주도 설계)의 눈으로 재해석했다 — 문서 속 명사들에서 업무 객체 후보를 고르고, 동사들에서 관계를 고르고, 그것을 그래프로 이었다. 이를테면 환불 정책 문서라면 '환불'이라는 명사가 객체 후보가 되고, "고객이 주문을 취소한다"라는 문장에서 Customer cancels Order 같은 방향 있는 관계 후보가 나온다 — 실제 실습은 우리 제품의 정책·기능·화면 이름 위에서 이뤄졌지만, 여기서는 구조만 옮긴다. 유비쿼터스 언어(팀 전체가 같은 뜻으로 쓰는 공용 언어)를 사람의 합의로 끝내지 않고, 선으로 연결된 구조로 옮겨 본 것이다.

그다음 선택이 이 실습의 요점이다. 우리는 거대한 그래프 데이터베이스를 구축하지 않았다. 대신 에이전트와 함께, 앞 절의 그 작은 놀이터에서 연습했다 — 객체 몇 개, 관계 몇 개를 만들고 부수고 다시 만들면서. 원칙은 하나였다. 이해하지 못한 채 프로덕션에 채택하지 않는다 — 학습을 먼저 한다. 15편의 언어로 말하면, 이것은 기술 도입이 아니라 학습 사이클에 건 작은 베팅이었다. 시간의 상한이 있는 놀이터 실습은 실패해도 배움이 남고, 이해가 쌓인 뒤의 채택 판단은 벤더의 데모가 아니라 우리 손의 감각 위에서 내릴 수 있다.

5. VOC를 넣자 로드맵이 보였다 — 그리고 그래프보다 인포그래픽

놀이터에서 손이 익은 뒤, 우리는 범위를 기획정책서 더미 전체로 넓혔다 — 객체 몇 개짜리 연습이 노드와 관계 수십 개 규모의 그래프로 자랐다. 그리고 실습이 흥미로워진 것은 그 그래프 뒤에 VOC(Voice of Customer, 고객의 소리)를 함께 넣었을 때다.

VOC를 다루는 흔한 방식은 목록화다 — 접수하고, 리스크 등급을 매기고, 등급 높은 순으로 처리한다. 그런데 정책·기능의 그래프에 VOC를 연결하자 다른 질문이 가능해졌다. 이 VOC는 어느 기능에 닿아 있는가. 그 기능은 어떤 정책·다른 기능과 얽혀 있는가. 고치는 난이도는 어느 정도이고, 짧은 사이클 안에 진행 가능한가. 등급순 정렬이 "무엇이 급한가"만 답한다면, 연결 위의 VOC는 "무엇을 고치면 어디까지 함께 좋아지는가, 지금 사이클에 걸 수 있는 것은 무엇인가"를 답한다 — 단순한 우선순위표가 아니라 인사이트가 있는 로드맵의 언어였다.

그리고 뜻밖의 발견이 하나 있었다. 노드와 선이 이 규모를 넘어가면, 그래프 시각화는 솔직히 말해 읽기 어려운 분포 그림이 된다 — 연결이 있다는 것은 보이는데, 그래서 무엇인지가 보이지 않는다. 연결 구조가 눈에 들어오지 않을 때 우리는 접근을 바꿔, 이미지 생성 모델(gpt-image 계열)에게 그 관계를 인포그래픽으로 그려 달라고 했다. 그러자 우리가 알지 못했던 부분이 이해되기 시작했다 — 어느 정책 덩어리에 VOC가 몰려 있는지, 어느 기능이 여러 정책의 교차점에 서 있는지가 그림의 언어로 보였다. 놀이터가 그래프 기능을 제공하는데도, 우리가 원하던 인사이트를 실제로 건네준 것은 그것을 인포그래픽으로 번역한 쪽이었다.

정직하게 한정해 둔다. 이 실습이 "온톨로지가 완전하게 작동한다"를 검증한 것은 아니다 — 데이터 바인딩도, 운영 규모의 검증도 하지 않았다. 우리가 확인한 것은 두 가지다. 연결된 지식은 목록보다 좋은 질문을 만들게 해 준다는 것, 그리고 연결의 가치는 이해 가능한 시각화를 통과할 때 비로소 사람에게 닿는다는 것. 이 두 확인이, 이 씨앗 글을 정원에 심게 한 직감의 정체다.

6. Fabric IQ와 의미 라우팅 — 씨앗이 그리는 원경

이 작은 실습의 원경에 있는 것이 Microsoft의 Fabric IQ다. 문서에 따르면 Fabric IQ의 온톨로지는 데이터 원천 전반의 의미를 통합하는 기업 어휘 계층으로, 바인딩된 데이터와 관계 정의로 조회 가능한 인스턴스 그래프를 만들고 그 맥락을 에이전트 계열 제품에 제공하는 방향이다(아직 Preview 단계로 빠르게 진화 중임을 명시해 둔다). 기존 BI(Business Intelligence, 비즈니스 인텔리전스)의 시맨틱 모델(Semantic Model)이 "이 지표를 어떻게 계산하는가"를 다뤘다면, 온톨로지는 한 발 더 나간다.

씨앗 글의 예시가 좋다. "VIP 고객의 연체 계약을 조정해 달라"는 요청 앞에서, 문서 검색만 있는 에이전트는 관련 정책 문서를 찾아 모델에 넣는 것까지가 전부다. 온톨로지가 있으면 에이전트는 행동 전에 확인할 수 있다 — 누가 VIP Customer인가, 어떤 Contract가 연결되는가, 연체는 어떤 관계와 속성으로 정의되는가, 변경 권한은 누구에게 있고 어느 금액부터 사람의 승인이 필요한가. 온톨로지는 정답 생성기가 아니라, 무엇을 조회하고 어느 관계를 따라가며 어디서 멈춰 사람에게 넘길지를 정하는 업무 언어이자 경계선이다.

17편을 기억하는 독자라면 이 층의 자리가 보일 것이다. 모델 라우팅이 "이 요청에 어떤 모델이 적절한가"를 묻는다면, 온톨로지는 그보다 한 층 아래에서 "이 요청이 말하는 고객·계약·자산은 정확히 무엇이며, 어떤 관계와 정책을 따라야 하는가"를 정한다 — 모델 라우팅 아래의 의미 라우팅이다.

사용자 요청
  → 온톨로지: 업무 객체와 허용 관계를 해석
  → 하네스: 컨텍스트 구성, 도구 호출, 평가
  → 모델 라우터: 추론 엔진 선택
  → 에이전트: 행동을 제안하거나 실행
  → 흔적: 위키와 평가 체계로 환류

17편이 정리한 자체 판단권 다섯 계층(도메인 평가기·컨텍스트 계약·권한 경계·관찰성과 비용 원장·교체 가능한 연결부) 중 컨텍스트 계약의 심화가 정확히 이 자리다. 그리고 해자(垓字, 성 둘레의 방어용 도랑 — 경쟁 방어 자산의 비유)의 정의도 같은 방향으로 깊어진다 — 모델을 바꿔도 남는 것은 이제 로그와 평가 기준만이 아니라, 업무 객체의 정의, 데이터 바인딩, 정책, 감사 기록이다.

7. 승격의 기술 — 위키에서 온톨로지로

그렇다면 실무의 경로는 무엇인가. 씨앗 글의 답은 "처음부터 전사 온톨로지를 설계하지 말라"다 — 그 길은 대개 끝나지 않는다. 현실적인 방식은 승격이다: 위키에서 반복적으로 등장하고, 여러 팀이 같은 뜻으로 써야 하며, 에이전트가 실제로 행동할 대상만 온톨로지로 올린다.

단계	하는 일	산출물
1. 탐색	문서·회의·시장 자료를 LLM 위키에 축적	개념, 출처, 모순, 후보 용어
2. 선별	자주 쓰이는 핵심 명사와 동사를 고름	후보 엔터티와 관계
3. 합의	식별자, 소유 부서, 정의, 관계 방향을 리뷰	온톨로지 계약
4. 바인딩	테이블·컬럼·이벤트 원천에 연결	데이터 바인딩과 인스턴스 그래프
5. 통제	권한, 품질 규칙, 승인 조건을 붙임	에이전트 행동 경계
6. 학습	실행 로그와 실패 사례를 위키·평가기로 환류	개선된 위키와 온톨로지 백로그

이 무늬가 낯익지 않은가. 이 정원은 방법론의 층위에서 정확히 같은 무늬를 반복해 왔다. 원고는 draft에서 검증을 거쳐야 published로 승급되고, 용어는 여러 편에서 반복 검증된 뒤에야 용어집에 등재되어 다음 실행의 계약이 된다 — 16편이 "파일에 써야 래칫이 걸린다"고 불렀던 그것이, 씨앗 글의 언어로는 위키에서 온톨로지로의 승격이다. 그러니 우리의 용어집은 사실 이 정원의 미니 온톨로지였고, 13편의 유비쿼터스 언어는 온톨로지 계약의 사람 쪽 절반이었다 — 온톨로지는 그 합의를 에이전트가 따라갈 수 있는 구조로 고정한, 유비쿼터스 언어의 기계 실행판이다.

8. 우리 정원의 사전 답사 목록

서두의 가정으로 돌아가자. 이 하네스가 언젠가 제품의 문서를 맡는다면 — 지속 성장하는 도메인을 따라가는 글쓰기를 맡는다면 — 지금의 3층에 무엇이 더 필요한가. 답사에서 돌아온 우리는 빈 터에 네 개의 말뚝을 박아 둔다. 짓는 것이 아니다 — 표시해 두는 것이다.

1. 도메인 위키 층 — 제품의 개념·릴리스·정책 변화·모순을 축적하는 곳. Ingest·Query·Lint가 도는, 글이 끝나도 남는 지속 자산. 사실 이 정원의 계보에는 원형이 있다 — 8편에서 다룬 그래프 지식 시스템이 정확히 이 층의 실전이었다.
2. 승격 계약 층 — 여러 글이 같은 뜻으로 써야 하는 개념의 온톨로지. 용어집의 진화형이며, 시작은 전사 지도가 아니라 핵심 객체 셋에서 여덟 개.
3. 문서↔제품 바인딩 — 문서가 가리키는 기능·화면·버전의 식별자. "이 문서는 무엇에 대한 문서인가"를 기계가 알아야, 제품이 바뀌었을 때 어긋난 문서를 기계가 찾아낸다.
4. 이해의 다리 — 시각화 번역 층 — 5절의 실습이 직접 확인한 요건. 연결된 지식은 분포 그래프가 아니라 이해 가능한 인포그래픽으로 번역될 때 사람의 결정에 닿는다.

이 목록은 실행 안건이 아니라 다음 베팅 테이블에 올릴 후보다. 15편의 규약대로, 확장은 직감이 아니라 베팅으로 결정한다 — 그리고 그 베팅의 근거는 이 답사와, 답사를 부른 실습이다.

9. 마치며 — 아는 것과 책임질 뜻

씨앗 글은 다음 시대의 지식 스택을 한 줄로 정리한다 — "Wiki는 조직이 아는 것을 축적하고, Ontology는 조직이 책임질 뜻을 정의하며, Harness는 그 뜻 안에서 에이전트를 움직인다." 에이전트가 문서를 읽고 요약하는 동안은 위키로 충분하다. 그러나 에이전트가 고객에게 답하고 계약을 바꾸고 비용을 집행하는 순간, 문맥은 길어질수록 느슨해져서는 안 되고 — 식별자와 관계와 권한은 오히려 더 엄격해져야 한다.

이 정원은 아직 그 순간 앞에 있다. 그래서 이번 편은 건축이 아니라 답사였다 — 없어도 됐던 층이 언제 필요해지는지를 알았고, 작은 놀이터에서 손으로 배웠고, VOC와 인포그래픽에서 그 가치의 실마리를 봤으며, 빈 터에 말뚝 네 개를 박았다. 1절의 두 갈래 — 더 단단하게(심화), 더 크게(확장) — 중 어느 쪽에 먼저 걸 것인가는 다음 베팅 테이블의 몫이다.

정원 은유로 맺는다. 좋은 정원지기는 밭을 넓히기 전에 흙을 만져 본다. 우리가 이번에 만진 것은 남의 성의 설계도가 아니라, 우리 손에 이미 쌓여 있던 문서 더미와 그 안에 잠들어 있던 연결이었다 — 도메인은 이미 자라고 있었다. 정원이 그것을 맡을 준비가 되었는지를 묻는 일만 남았을 뿐이다.

Qui bene distinguit, bene docet — 잘 구분하는 자가 잘 가르친다. 온톨로지란 결국, 잘 구분하기의 다른 이름이다.

하네스의 이야기는 계속됩니다. 감사합니다 💙

참고 자료

씨앗 글

• 모델이 문서를 읽는 시대를 넘어 — Karpathy Wiki에서 Microsoft Ontology까지 (웹노리 기고)

원전 및 제품 자료

• Andrej Karpathy — LLM Wiki (gist) — 원문 3층 구조(raw sources/wiki/schema)와 Ingest·Query·Lint
• Microsoft — Ontology Playground (GitHub) / 라이브 데모
• Ontology Playground — Fabric IQ format gap analysis — 학습 도구와 운영 기능의 거리(3절 한계 고지의 근거)
• Microsoft Fabric IQ — What is Ontology? / Fabric IQ 개요
• ※ Fabric IQ와 Ontology Playground는 Preview 또는 빠르게 진화하는 단계다 — Playground의 자연어 질의·데이터 바인딩을 운영 기능과 같은 수준으로 해석해서는 안 된다 (씨앗 글의 주의를 계승)

시리즈 내부 연결

• 8편: 해피톡 그래프 지식 시스템 — Karpathy LLM 위키가 이 시리즈에 처음 등장한 자리
• 13편: LLM 시대에 다시 발견하는 DDD — 유비쿼터스 언어, 이 편 실습의 렌즈
• 15편: 원탁은 아무 때나 열리지 않는다 — 작게 베팅하는 학습 사이클
• 16편: 아흔여덟 장의 기억 — "파일에 써야 래칫이 걸린다", 승격 무늬의 내부 선례
• 17편: 담장 너머의 하네스 워 — 모델 라우팅과 자체 판단권, 이 편이 한 층 내려간 자리