Hermes와 기존 lecture-material-ontology로 3백만 바이트 교재를 130개 노드 그래프로 바꿨다

📝 한줄 요약

GPTers의 강의교재 온톨로지 사례를 참고해, 이미 있던 lecture-material-ontology를 새로 복제하지 않고 실제 『신민사소송법』 제7판 원문을 130개 노드·354개 관계의 탐색 가능한 그래프로 바꿨습니다. 처음부터 성공했다고 꾸미지 않고, 초기 15/17 FAIL을 남긴 뒤 수리하여 최종 17/17 PASS까지 확인했습니다.

바쁘시면 이것만 읽어도 돼요:

• 출발점은 6개 장·450개 지식 객체·361개 관계를 보고한 GPTers 참고 글이었지만, 그 숫자를 우리 결과처럼 가져오지 않았습니다.

• 새 스킬을 하나 더 만드는 대신, 먼저 기존 lecture-material-ontology가 이미 같은 책임을 갖고 있는지 확인했습니다.

• 3,011,327바이트·17,977줄의 『신민사소송법』 제7판 Markdown을 SHA-256으로 고정하고 원문은 수정하지 않았습니다.

• 실제 local build 결과는 8개 편·18개 장·21개 section cluster·10개 progression chain·130개 node·354개 edge였습니다.

• 독립 validator가 처음에는 15/17 FAIL이었고, 실패 원인을 추측하지 않은 채 수정 후 같은 범위를 다시 검사해 17/17 PASS를 확인했습니다.

• 이 작업의 시간 절약은 따로 측정하지 않았습니다. 대신 원문, 그래프, validation report, Wiki index·log·FTS를 다시 열 수 있게 만든 것이 확인 가능한 결과입니다.

• 이 글은 기판력 사건을 각색한 법률 사례가 아니라, 실제 교재를 지식 구조로 바꾼 개발과정 사례입니다.

🎯 이런 분들께 도움돼요

• 강의자료나 법률 교재를 AI에게 읽히고 싶지만, 목차를 연결하는 것만으로는 부족하다고 느끼는 분

• 이미 비슷한 AI 스킬이 있는데도 새 스킬을 계속 만들고 있는 분

• 문서의 모든 문장을 노드로 만들지 않고, 다시 사용할 만한 구조만 지식그래프로 만들고 싶은 분

• AI가 만든 그래프가 그럴듯해 보이는 것과 실제 원문에 근거한 것은 다르다고 생각하는 분

• 교재의 역사적 설명과 현재 적용되는 법령·판례를 섞지 않고 관리해야 하는 분

• 실패한 검증을 숨기지 않고, 수리 후 다시 통과시킨 과정을 사례로 보고 싶은 분

😫 문제 상황 (Before)

처음 사용자가 남긴 요청은 길지 않았습니다.

강의교재 온톨로지

이 말만 놓고 보면 새 스킬을 만들고, 교재의 장·절을 노드로 만든 뒤, 그래프 그림 하나를 보여주면 끝날 것처럼 보입니다. 하지만 실제로 필요한 질문은 훨씬 많았습니다.

• 교재에서 단순한 목차와 다시 사용할 지식은 어떻게 구분할까?

• 어떤 내용이 해결해야 할 Problem이고, 어떤 내용이 그 문제에 대한 Attempt일까?

• 앞선 시도가 부족해지는 FailureBoundary는 어디에 붙여야 할까?

• 장·절의 위치와 “왜 다음 내용이 필요한가”라는 진행 관계를 같은 선으로 연결해도 될까?

• 제7판의 역사적 조문·판례·학설을 현재의 법률 근거처럼 읽지 않으려면 어떻게 해야 할까?

• 그래프가 만들어졌다고 말하기 전에, 원문 해시와 node·edge 구조를 누가 다시 확인할까?

실제 원문은 이미 있었습니다. 문제는 자료가 없는 것이 아니라, 3,011,327바이트·17,977줄의 교재가 검색 가능한 원문에서 이유와 순서까지 다시 따라갈 수 있는 지식 구조로 아직 바뀌지 않았다는 점이었습니다.

기존 상태와 목표를 비교하면 이랬습니다.

그래서 목표를 “큰 그래프를 만들기”가 아니라 원문에서 왜 다음 지식이 필요해지는지 설명 가능한 그래프를 만들기로 바꿨습니다.

🛠️ 사용한 도구와 자료

• Hermes Agent / Libro Vitae: 기존 Wiki와 스킬을 확인하고, 실제 구현·검증·사례글을 연결했습니다.

• lecture-material-ontology: 원문 고정, typed node, progression·context 관계, 독립 검증의 공통 절차로 사용했습니다.

• GPTers 참고 글: 데이터과학 교재를 Problem → Attempt → FailureBoundary → Decision 흐름으로 다시 읽은 방법론의 참고자료로만 사용했습니다.

• 『신민사소송법』 제7판 Markdown: 실제 graph build의 source of truth입니다.

• 민사소송법 전용 OntologyProfile: 법률 교재의 장절·진행 순서·negative example·권위 경계를 별도로 보관했습니다.

• builder와 independent validator: 사람이 읽는 ontology, machine-readable graph, build report, validation report를 생성·확인했습니다.

• LLM Wiki index·log·private FTS: 결과물을 다음 질문에서 다시 찾을 수 있도록 연결했습니다.

GPTers 원문이 보고한 450개 지식 객체·361개 관계는 source-reported로 구분했습니다. 이번 글의 130개 node·354개 edge·17/17 PASS는 이 저장소에서 실제로 생성하고 검증한 local artifact입니다.

🔧 작업 과정

1. 숫자부터 복사하지 않고, 참고 글의 방법을 분리했다

GPTers 참고 글은 교재를 장·절 목록으로만 보지 않고, “어떤 문제가 있었고, 무엇을 시도했으며, 어디서 한계가 생겨 다음 개념이나 판단이 필요해졌는가”를 따라가는 방법을 보여줬습니다.

그 글의 숫자를 그대로 재현했다고 말하는 대신, 이번 작업에서 실제로 재사용할 수 있는 원칙만 골랐습니다.

• 장 제목을 그대로 연결하는 것과 지식의 진행을 표현하는 것은 다르다.

• 원문과 원문이 참조하는 자료를 provenance의 기준으로 삼아야 한다.

• Problem, Attempt, FailureBoundary, Case, EducationalConcept, FormalConcept, Decision을 역할별로 구분해야 한다.

• 진행 관계와 장·절·출처를 위한 문맥 관계를 분리해야 한다.

• 코드·의미·시각 검증을 나누고 실패 결과를 남겨야 한다.

여기서 첫 번째 교훈을 얻었습니다. 참고 글의 결과 숫자를 가져오는 것과, 참고 글의 사고방식을 내 자료에 적용하는 것은 전혀 다른 작업이었습니다.

2. 새 스킬을 만들기 전에 이미 있는 스킬부터 확인했다

“강의교재 온톨로지”라는 말을 보면 새 스킬부터 만들기 쉽습니다. 하지만 기존 스킬 목록을 확인하자 이미 lecture-material-ontology가 다음 책임을 갖고 있었습니다.

• 원문과 변환본 구분

• source hash와 provenance 기록

• Problem → Attempt → FailureBoundary 진행 계약

• context layer와 progression layer 분리

• 실패 경계와 negative example 관리

• 독립 validator와 regression

• Wiki index·log·검색 갱신

새 스킬을 복제하면 처음에는 빠른 것처럼 보여도, 다음 교재를 처리할 때 어느 스킬이 정본인지 다시 판단해야 합니다. 그래서 공통 절차는 기존 스킬에 맡기고, 『신민사소송법』에서만 필요한 차이는 별도 profile과 validation contract에 넣었습니다.

이 선택은 기능을 덜 만든 것이 아닙니다. 재사용되는 책임과 책마다 달라지는 지식을 서로 다른 곳에 둔 것입니다.

3. 3백만 바이트 교재를 먼저 잠갔다

그래프를 만들기 전에 실제 원문을 고정했습니다.

• Source ID: TEXTBOOK-CIVPRO-SHINMINSA-7E-LEE-20260807

• 크기: 3,011,327 bytes

• 줄 수: 17,977 lines

• SHA-256: 63df7c5774955c785e8fa808c6953bd2bab3712dc3138df0a29b6723ed078070

• source authority: textbook-background

• 사용 범위: background-only

원문은 직접 고치지 않고 domain source layer에 byte-preserving capture로 보존했습니다. 그래프에서 어떤 해석이 이상해져도 원문을 다시 쓰는 것이 아니라, profile·builder·compiled page를 고치고 검증하도록 경계를 만든 것입니다.

이 단계가 없으면 그래프가 틀렸을 때 무엇이 잘못된 것인지 알 수 없습니다. 원문이 바뀐 것인지, 변환이 바뀐 것인지, 모델링 판단이 바뀐 것인지 모두 섞이기 때문입니다.

4. 장·절을 단순한 노드가 아니라 두 층으로 나눴다

다음으로 교재의 구조를 두 종류의 선으로 나눴습니다.

• Context layer: 어느 편·장·절에 있는지 알려주는 위치와 provenance

• Progression layer: 앞선 문제와 시도가 왜 다음 문제·개념·판단으로 이어지는지 보여주는 흐름

민사소송법 전용 profile에는 다음의 학습 진행 순서를 넣었습니다.

1. 현대형 분쟁에 맞는 절차구조

2. 법원·관할 선택

3. 당사자·능력·적격·대리

4. 청구 형성·소송요건·소제기

5. 변론·쟁점정리·집중심리

6. 증거조사·자유심증·증명책임

7. 소송 종료·판결·기판력

8. 청구병합·다수당사자·참가

9. 상소·재심

10. 소액·독촉의 간이절차

그리고 모든 명사를 노드로 만들지 않았습니다. 민사소송, 관할, 기판력이라는 단어가 나온다는 이유만으로 Problem을 만들지 않고, 실제로 학습자가 해결해야 하는 질문인지 원문 위치와 함께 확인했습니다.

5. 법률 교재에 맞는 profile과 경계를 추가했다

공통 스킬만으로는 법률 교재의 차이를 충분히 표현할 수 없었습니다. 그래서 다음 항목만 교재별 profile에 추가했습니다.

이번 그래프에서 교재는 법률 자문 데이터가 아니라 textbook-background입니다. 현재 법령이나 개별 사건의 결론이 필요하면 general-law와 case-law authority overlay를 별도로 통과해야 합니다.

6. 그래프를 크게 만드는 대신, 이유가 이어지는지 확인했다

실제 local build 결과는 다음과 같습니다.

핵심 진행 계약은 다음과 같습니다.

Problem → Attempt → FailureBoundary → Decision 또는 다음 Problem

Problem에서 FailureBoundary로 바로 건너뛰는 shortcut은 허용하지 않았습니다. 어떤 시도가 있었고, 그 시도가 어디서 충분하지 않았으며, 그래서 어떤 다음 판단이 필요해졌는지를 따라갈 수 있어야 하기 때문입니다.

머리말에 언급된 삼성가 상속소송·삼성 대 Apple 특허소송·집단소송·전자소송도 원문이 언급한 범위까지만 Case로 보존했습니다. 원문에 없는 사건 사실이나 판결 결과를 사례의 빈칸을 채우기 위해 만들지 않았습니다.

7. 처음부터 PASS라고 쓰지 않고, 실패한 gate를 다시 통과시켰다

그래프가 만들어졌다고 바로 완료 선언을 하지 않았습니다. 독립 validator를 돌린 결과 초기 상태는 15/17 FAIL이었습니다.

초기 실패의 상세 원인은 보존된 기록에 충분히 남아 있지 않기 때문에 추측하지 않았습니다. 확인할 수 있는 사실만 남겼습니다.

1. 초기 validator가 같은 범위에서 실패했다.

2. 실패 상태를 최종 PASS처럼 덮어쓰지 않았다.

3. 수정 후 동일 범위의 검증을 다시 실행했다.

4. 최종 validation report에서 17/17 PASS, failed: 0을 확인했다.

최종 validator는 source 존재와 hash, graph metrics, node ID, type·predicate, edge endpoint, locator, typed edge, shortcut 금지, progression DAG, regression path, semantic locator, OCR boundary, evidence link를 검사했습니다.

이 과정에서 배운 점은 단순합니다. AI 결과물이 그럴듯해 보이는 것과, 독립 검증을 통과한 것은 다릅니다. 실패 기록이 남아 있어야 다음 사람이 무엇을 다시 확인해야 하는지도 알 수 있습니다.

8. 그래프를 만드는 데서 끝내지 않고, 다시 찾을 수 있게 연결했다

최종 산출물은 JSON 그래프 하나가 아니었습니다.

• 사람이 읽는 ontology page

• machine-readable graph

• 교재별 OntologyProfile

• 별도 validation contract

• build report

• validation report와 validation JSON

• source registry와 byte-preserving capture

• ontology index·log

• subject index와 case index

• private FTS 검색 인덱스

최종 private FTS에는 1,977 legal-lecture docs가 재색인되었고, 기존 스킬 보완 신민사소송법 질의에서 구현 사례 문서가 반환되는 것을 확인했습니다.

이제 결과물은 한 번 읽고 끝나는 보고서가 아니라, 다음 질문에서 원문·그래프·검증 결과를 다시 연결할 수 있는 Wiki artifact가 되었습니다.

9. 기술 기록과 독자용 사례글을 분리했다

처음 작성한 v1은 source lock, ontology profile, graph metrics, validator 항목을 빠짐없이 남기는 기술 중심 문서였습니다. 구현 사실을 보존하는 데는 적합했지만, 게시판에서 처음 읽는 사람에게는 문제 상황과 작업의 감각이 앞부분에서 충분히 보이지 않았습니다.

그래서 이번 v2에서는 기술 사실을 버리지 않고, 독자가 따라갈 수 있는 이야기 순서로 다시 배치했습니다. 이 수정 요청도 실제 기록으로 남깁니다.

그런데 이번 사례게시글 쓴거 보니까 이게 우리가 write-post 스킬로 쓰는 형식하고 많이 달라서 v2를 작성해줘. write-post 스킬에 맞춰서

v2에서 달라진 것은 다음과 같습니다.

• 기술 용어를 먼저 설명하지 않고, Before 문제와 독자 대상을 먼저 제시했습니다.

• 작업 과정은 보고서 목차가 아니라 실제 판단이 일어난 에피소드 순서로 바꿨습니다.

• 15/17 FAIL → 17/17 PASS를 결과 표에만 두지 않고, 실패를 숨기지 않은 작업 장면으로 풀었습니다.

• 실제 사용자 요청을 코드블록으로 보존하고, 독자가 복붙할 수 있는 프롬프트를 마지막에 추가했습니다.

• 이미지 추천과 게시판 업로드 안내를 넣어, Wiki 문서와 게시용 글의 역할을 분리했습니다.

즉, v2는 v1을 삭제한 글이 아니라 같은 구현 사실을 독자용 write-post 서사로 다시 편집한 sibling revision입니다.

✅ 결과 (After)

Before vs After

결과물

실제로 확인할 수 있는 결과물은 다음과 같습니다.

• 신민사소송법 제7판 ontology package

• 교재별 ontology profile

• build report

• validation report

• v2 write-post 사례글

• v1 기술·검증 원장

• GPTers 참고 원문

이 글의 local 결과와 GPTers 원문의 보고 결과는 서로 다른 층입니다. 외부 원문은 방법론과 source-reported 수치의 출처이고, local report는 이번 구현의 실제 검증 결과입니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 새로 만들기 전에 기존 스킬의 책임부터 확인하기
   비슷한 이름의 스킬을 여러 개 만들기보다, 공통 절차와 교재별 차이를 분리하면 다음 작업에서도 무엇을 재사용할지 분명해집니다.

2. 장·절 위치와 지식의 진행을 다른 선으로 연결하기
   “어디에 있는가”와 “왜 다음 내용이 필요한가”를 한 종류의 관계로 만들면 그래프가 커져도 설명력은 커지지 않습니다.

3. 검증 실패를 결과물의 일부로 남기기
   15/17 FAIL을 지우고 17/17 PASS만 남기는 것보다, 실패 후 수리했다는 사실을 보존하는 편이 재현성과 신뢰성이 높습니다.

4. 교재의 법률 설명에 권위 경계를 붙이기
   교재가 법률을 설명한다고 해서 곧바로 현재 사건의 법적 근거가 되는 것은 아닙니다. 교재 background와 현행 authority를 별도 layer로 관리해야 합니다.

이렇게 하면 안 돼요

1. 외부 사례의 450/361을 local 결과처럼 복사하면 안 됩니다.

2. 교재에 등장한 모든 명사와 소제목을 node로 승격하면 안 됩니다.

3. Problem → FailureBoundary shortcut으로 시도와 실패의 책임을 생략하면 안 됩니다.

4. validator가 실패했을 때 원인을 기록에서 찾지 못했다면 추측해서 채우면 안 됩니다.

5. 실제로 측정하지 않은 시간 절약이나 업무 효율을 성과 숫자로 쓰면 안 됩니다.

6. 교재의 역사적 조문·판례·학설을 현행 법률 자문처럼 사용하면 안 됩니다.

🌍 다른 업무에 적용한다면?

이 방식은 민사소송법에만 한정되지 않습니다.

법무팀 계약심사 매뉴얼

• Problem: 계약서에서 반복적으로 놓치는 검토 질문

• Attempt: 기존 체크리스트나 담당자 검토 방식

• FailureBoundary: 체크리스트로는 발견하지 못하는 예외 조건

• Decision: 추가 법령 검색, 상급자 검토, 계약 조항 수정 여부

다만 매뉴얼의 과거 사례와 현재 법령을 같은 그래프로 단정하지 않고, 현재 법령·판례 검증 layer를 별도로 둬야 합니다.

IT 운영 매뉴얼

장애 대응 문서를 단순한 순서 목록으로 두지 않고, “어떤 증상이 있었고, 어떤 조치를 했으며, 어느 조건에서 그 조치가 더 이상 충분하지 않아 다른 대응으로 넘어가는가”로 바꿀 수 있습니다.

사내 교육 교재

신입 교육자료에서 모든 문장을 검색하는 대신, 학습자가 먼저 해결해야 하는 질문과 다음 개념으로 넘어가는 이유를 연결하면 복습 질문·퀴즈·요약자료를 다시 만들기 쉬워집니다.

🚀 앞으로의 계획

다음 확장은 전체 그래프를 한꺼번에 다시 쓰는 방식이 아닙니다.

1. 소송 종료·판결·기판력 하나의 progression을 골라 교재 원문·강의 recap·용어사전·현행 authority를 함께 대조합니다.

2. ontology와 recap이 어떤 질문에서 서로 보완되는지 usage guide에 계속 기록합니다.

3. 필요하면 사람 눈으로 progression·evidence·authority layer를 확인할 수 있는 graph explorer를 추가합니다.

4. 다른 법률 교재를 편입할 때도 공통 스킬은 재사용하고, 책마다 다른 부분은 OntologyProfile과 validation contract로 분리합니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 기존 스킬부터 확인하기

내 프로젝트의 스킬 목록과 관련 문서를 먼저 읽고, [만들고 싶은 작업]을 담당하는 기존 스킬이 이미 있는지 확인해줘.
새 스킬을 만들기 전에 기존 스킬로 재사용할 책임과, 별도 profile·설정·검증 계약으로 분리해야 할 차이를 표로 보여줘.
중복 스킬을 만들지 않는 쪽을 기본값으로 판단해줘.

프롬프트 2: 교재를 온톨로지로 바꾸기

[원문 파일 또는 교재 경로]를 source of truth로 고정하고, 원문은 수정하지 말아줘.
모든 문장을 노드로 만들지 말고 Problem, Attempt, FailureBoundary, Case, EducationalConcept, FormalConcept, Decision을 구분해 재사용 가치가 있는 후보만 골라줘.
장·절 위치 관계와 Problem → Attempt → FailureBoundary → Decision 진행 관계를 분리하고, 모든 승격 노드와 edge에 원문 locator를 붙여줘.
교재의 역사적 설명과 현행 법령·판례 권위를 섞지 말고, 실패한 검증 결과도 별도 report로 남겨줘.

프롬프트 3: 실패를 숨기지 않는 사례글 만들기

이 작업 기록을 바탕으로 비개발자도 읽을 수 있는 AI 활용 사례게시글을 써줘.
📝 한줄 요약 → 바쁘시면 이것만 → 이런 분들께 도움돼요 → 문제 상황(Before) → 사용한 도구 → 에피소드형 작업 과정 → 결과(After) → 배운 팁 → 다른 업무 적용 → 앞으로의 계획 → 재사용 가능한 프롬프트 순서로 구성해줘.
실제 사용자 요청은 코드블록으로 보여주고, 확인되지 않은 시간 절약·실패 원인·성과 숫자는 지어내지 말아줘.
초기 FAIL과 수리 후 PASS가 있다면 둘 다 기록하고, 기술 용어는 비개발자에게 먼저 풀어서 설명해줘.

📚 도움받은 글

이 사례는 요거트프라푸치노님의 사례글을 직접 읽고 핵심 구조를 확인한 뒤, 기존 lecture-material-ontology와 Libro Vitae의 source lock·provenance·독립 검증 운영 기준에 대조해 정리했습니다.

• 강의 교재 온톨로지로 다시 구성하기 - 6개 장, 450개 지식 객체로 다시 만든 과정 — 작성자는 요거트프라푸치노님입니다.

이 글의 450개 지식 객체·361개 관계는 도움받은 원문에 기록된 source-reported 수치이고, 이번 사례의 130개 node·354개 edge·17/17 PASS는 별도로 수행한 local implementation·validation 결과입니다.