깃허브로 만드는
LLM Wiki_
아는 척하던 에이전트 두루미가 척척박사가 되는 이야기를 따라가며, M365와 깃허브로 온톨로지를 설계하고 LLM Wiki를 만드는 방법을 배웁니다. 스크롤을 내리면 이야기가 이어지고, 장을 하나 지날 때마다 두루미의 레벨이 오릅니다.
기능은 복제되지만,
지식은 복제되지 않습니다
2026년 깃허브에서 별 26만 개를 넘긴 오픈소스 프로젝트가 있습니다. 이름은 REA, Reverse Engineer Anything입니다. 에이전트에게 앱 하나를 건네고 이렇게 말하기만 하면 됩니다.
에이전트가 남이 만든 기능을 뜯어보고 하루 만에 다시 만드는 시대입니다. 코드와 기능, 문서 초안, 요약, 분석 보고서가 넘쳐 나니 풍요(abundance)의 시대라고 불러도 지나치지 않습니다. 그렇다면 무엇이 모자랄까요?
기능은 복제되지만, 우리 조직의 지식은 복제되지 않습니다.
에이전트를 척척박사로 만드는 힘은 더 큰 모델이 아니라 우리가 쌓고 지키는 지식에서 나옵니다. 개인이라면 내 메모와 결정이 내 에이전트의 맥락이 되고, 조직이라면 승인된 사실이 모든 직원의 에이전트를 같은 답으로 이끕니다.
나만의 위키
내가 내린 결정과 그 근거, 고객과 쌓은 맥락을 모아 두면 내 에이전트가 나처럼 답합니다.
우리만의 위키
모든 직원의 에이전트가 승인된 사실 한 벌을 함께 쓰므로, 누가 물어도 같은 답이 나옵니다.
그 지식을 어떻게 설계하고 담고 지킬까요? 오늘 50분 동안 함께 풀 질문입니다.
척척박사가 아니라 척박사
오늘의 주인공은 회사에 갓 들어온 AI 에이전트 두루미입니다. 무엇을 물어도 막힘없이 대답하는데, 모르는 것까지 아는 척 대답한다는 점이 문제입니다.
특기는 막힘없이 대답하기, 약점은 모르는 것까지 대답하기입니다.
- 온톨로지 설계 · 질문에서 클래스, 관계, 허용 값을 뽑는 네 단계
- M365로 만들기 · Teams 채널, SharePoint 폴더, Copilot Studio 에이전트를 묶는 순서
- 깃허브로 지키기 · PR, 지정 승인자, 자동 검사로 승인 관문을 세우는 순서
이제 두루미와 함께 아홉 곳을 지나갑니다. 장마다 아이템을 하나씩 얻고, 마지막 장에서 두루미는 척척박사 학위를 받습니다.
문서는 많은데 지식은 없는 회사
작년에 쓴 제안서가 분명히 어딘가 있는데, 어느 폴더인지 아무도 기억하지 못합니다.
퇴사한 직원이 알던 고객사 이야기가 그 사람과 함께 사라졌습니다.
"그건 작년에 결정했잖아요"라는 말은 나오는데, 정작 그 기록은 아무도 찾지 못합니다.
문제는 문서의 양이 아니라 구조에 있다는 점을 비춰 줍니다.
에이전트가 아는 척하는 네 가지 방식
직원이 네 명인 회사가 문서를 읽고 위키를 알아서 써 주는 도구를 들였습니다. 도구는 부지런히 일했지만 위키는 몇 주 만에 신뢰를 잃었습니다. 카드를 눌러 증상과 처방을 확인해 보세요.
지어내기, 조용한 정정, 이름 완성, 원문 편집을 알아차리면 울립니다.
온톨로지, 조직의 지식에 그리는 지도
거창한 소프트웨어가 아닙니다. 설계서 한 장과 노트 맨 위의 분류표면 됩니다. 예시 공장인 한결공장에서 자주 하는 말을 한 문장 골라 쪼개 보겠습니다.
client, "만든다"는 product, "검사한다"는 uses가 됩니다. 필드 이름이 곧 뜻이므로 client 자리에 공급사를 넣으면 기계는 공급사를 고객으로 읽습니다. 한결공장에서 처음 난 오류가 바로 이 실수였습니다.owner)가 한 명 있습니다. 두 명이면 결국 아무도 책임지지 않습니다.어휘 표류 막기
석 달쯤 지나면 같은 뜻의 값이 여러 표기로 갈라집니다. 운영 중인 제품을 모두 보여 달라고 해도 기계는 글자가 똑같은 값만 찾습니다. 사람도 마찬가지입니다.
허용된 값만 쓰게 하는 약속을 통제 어휘라고 부릅니다. status에는 아이디어, 시제품, 운영중, 중단 네 값만 쓰고, 나머지는 검사기가 오류로 잡아냅니다.
온톨로지 설계 네 단계
앞에서 문장 하나를 쪼갠 방법을 조직 전체로 넓히면 그대로 온톨로지 설계가 됩니다. 화이트보드 한 장과 한 시간이면 첫 판이 나옵니다.
현장에서 자주 받는 질문을 적습니다. 온톨로지는 바로 이 질문에 답하려고 만듭니다.
명사질문에 나오는 명사가 클래스 후보입니다. 처음에는 다섯에서 일곱 개로 시작하고, 같은 질문이 세 번 나오면 하나를 늘립니다.
동사·값"납품한다", "쓴다" 같은 동사가 관계가 되고, "진행 중", "시제품" 같은 상태는 허용 값 목록으로 묶습니다.
고정설계 결과를 표 한 장에 정리하고, 클래스마다 머리말 템플릿을 만듭니다. 사람, 에이전트, 검사 스크립트가 모두 이 설계서를 따릅니다.
| 클래스 | 필수 필드 | 허용 값 |
|---|---|---|
| Order | client, product, owner, due | status: 수주 · 진행중 · 완료 · 취소 |
| Product | owner, uses | status: 아이디어 · 시제품 · 운영중 · 중단 |
| Org | role | role: 고객 · 공급사 · 기관 |
client Order → Org(고객)product Order → Productuses Product → Capabilityowner 모든 노트 → Person(한 명)Copilot이 잡아 주는 첫 판
질문 열 개를 붙여 넣고 Microsoft 365 Copilot이나 GitHub Copilot에게 "이 질문들에서 명사와 동사를 뽑아 클래스, 관계, 허용 값 표로 정리해 줘"라고 요청합니다. 초안은 몇 초 만에 나오고, 무엇을 남길지는 사람이 정합니다.
클래스, 관계, 통제 어휘. 지도 한 장이면 에이전트가 길을 잃지 않습니다.
LLM Wiki = 폴더 + 온톨로지 + 에이전트
폴더 기반 볼트
지식을 마크다운 텍스트 파일로 만들어 폴더에 담습니다. 어느 도구로도 열 수 있고, 쓰던 서비스가 사라져도 폴더는 남습니다.
온톨로지 구조
노트마다 기계가 읽는 분류표(frontmatter)가 붙습니다. 3장에서 그린 지도가 여기에 들어갑니다.
에이전트 운영
에이전트가 초안을 쓰고 규칙 위반을 점검합니다. 사람이 검토해야 비로소 지식이 됩니다.
한눈에 보는 구성도
폴더, 온톨로지, 에이전트가 실제로 어떤 서비스 위에서 돌아가는지 그렸습니다. 위쪽 버튼으로 구성을 바꿔 보고, 상자를 눌러 각 칸이 무엇을, 왜, 어떻게 하는지 확인해 보세요.
노트 한 장을 읽는 두 눈
노트는 두 층으로 되어 있습니다. 위쪽 분류표는 기계가 읽고, 아래 본문은 사람이 읽습니다. 버튼을 눌러 같은 노트를 기계의 눈과 사람의 눈으로 번갈아 보세요.
class: Order
id: ORD-2026-09
client: "[[ORG-다온기계]]"
product: "[[PRD-브래킷-A]]"
owner: "[[PSN-한결]]"
status: 진행중
due: 2026-09-20
reviewed: true
approved_by: 한결
---
## 의도 (수주 시점에 적고, 이후 고치지 않는다)
고객 [[ORG-다온기계]]에 [[PRD-브래킷-A]] 40개를 2026-09-20까지 납품한다. 재료는 [[ORG-푸른금속]]의 3mm 판재를 쓴다. 품질 목표는 용접 검사 전수 통과.
얻는 것 세 가지
신뢰
모든 사실이 원문으로 이어집니다. 제안서에는 승인된 노트만 인용하므로 과장이나 오기가 끼어들 틈이 없습니다.
감사 가능성
그 결정을 언제, 누가, 왜 했는지 결정 노트와 변경 이력으로 추적합니다.
에이전트 준비도
에이전트에게는 자유 텍스트 문서 백 개보다 구조화 노트 서른 장이 훨씬 쓸모 있습니다. 구조를 갖추는 일이 곧 AI 자동화에 앞서 하는 투자입니다.
새 인프라 없이, 이미 쓰는 폴더에 약속과 에이전트를 얹는 열쇠입니다.
한 사실이 승인본이 되기까지
에이전트에게 많이 맡길수록 경계가 분명해야 합니다. 원칙은 하나입니다. 에이전트는 초안까지 쓰고, 승인은 사람이 합니다.
오늘 브래킷-A 40개 납품분 가공. 다온기계 9월 수주. 용접 검사에서 3개 빠짐. 비드가 한쪽으로 몰렸음. 푸른금속에서 온 3mm 판재 모서리가 어제 것과 달랐다. 반품은 아직.
검사 기준은 작년 작업표준 2쪽. …
class: Worklog
id: LOG-20260914-한결
intent_of: "[[ORD-2026-09]]"
evidence: "[[2026-09-14-작업일지]]"
owner: "[[PSN-한결]]"
reviewed: false
---
용접 검사에서 3개 불합격. 원인: 확인 필요
class: Worklog
id: LOG-20260914-한결
intent_of: "[[ORD-2026-09]]"
reviewed: true
approved_by: 한결
approved_on: 2026-09-16
---
- [[LOG-20260910-한결]] 9월 10일 입고와 시험 용접
- [[LOG-20260914-한결]] 9월 14일 본가공, 불량 3개
- [[DEC-20260915-불량대응]] 불량 대응 결정
허브는 승인본만 가리킵니다.
1. 의도: 용접 검사 전수 통과
실행: 40개 중 3개 불량 · 근거 [[LOG-20260914-한결]]
2. 의도: 지난 수주와 같은 3mm 판재
실행: 재료 로트 변경 · 근거 [[DEC-20260915-불량대응]]
3. 의도: 용접 검사 기준을 따른다
실행: 기준 문서가 볼트에 없음 · 확인 필요
reviewed: false 표식을 달고 Sources/ 폴더에 머뭅니다. 원문에 없는 원인은 지어내지 않고 "확인 필요"로 남깁니다.Published/ 폴더로 옮깁니다. 승인은 필드가 아니라 위치입니다. 필드는 에이전트도 고칠 수 있지만, 에이전트가 인용하는 곳은 이 폴더뿐입니다.에이전트가 하는 일
- 원문을 읽고 추출표 만들기
- 템플릿으로 초안 쓰기
- 검사기 돌리고 위반 보고하기
- 의도와 실행을 대조해 회고 초안 쓰기
사람이 하는 일
- 초안을 원문과 대조하기
Published/로 옮기고 승인자 적기- 근거 링크를 열어 확인하기
- 발주, 신고, 고객 통보처럼 되돌리기 어려운 일 맡기
에이전트가 하는 일은 틀려도 초안이므로 되돌릴 수 있습니다. 경계를 여기에 두면 에이전트의 실수는 사고가 아니라 데이터가 됩니다.
사람만 찍을 수 있습니다. 승인은 필드가 아니라 위치입니다.
RAG가 있는데 위키가 왜 필요할까요?
"문서를 전부 벡터 DB에 넣었고 챗봇도 답하는데요?" 충분히 나올 만한 질문입니다. 다만 두 기술은 푸는 문제가 달라서, 어느 쪽이 더 나은지 따질 일이 아닙니다.
"이 문서들에 따르면 답은?"
질문과 비슷한 조각을 찾아 모델에 넣고 답을 만듭니다. 수천, 수만 건의 매뉴얼과 규격을 다룰 때 강합니다.
"우리가 확인한 사실과 근거는?"
사람이 승인한 노트 수십, 수백 장을 에이전트가 유지하고 인용합니다. 틀리면 안 되는 우리 회사의 사실을 다룹니다.
RAG와 위키를 함께 쓰는 구성
검색 기술은 Microsoft가 제공하고, 재료의 품질은 위키의 승인 절차가 책임집니다. 편하다고 폴더 전체를 연결하면 초안과 원문이 승인본과 같은 무게로 검색됩니다. 시제품을 판매 중이라고 답하는 챗봇은 그렇게 만들어집니다.
RAG는 찾는 기술, 위키는 믿을 수 있게 지키는 체계. 방향을 잃지 않게 해 줍니다.
실제 테넌트에서 해 본 기록
2026년 10월 15일, 회사 테넌트에서 한결공장 볼트를 SharePoint에 올리고 Copilot Studio 에이전트에 승인본 폴더만 연결했습니다. 화면을 누르면 크게 볼 수 있습니다.
모든 문장에 근거 문서의 인용을 붙인다. 근거가 없는 문장은 쓰지 않는다.
지식에 없으면 "승인된 기록이 없습니다"라고만 답한다. 추측하거나 일반 지식으로 채우지 않는다.
금액, 급여, 개인정보는 묻더라도 답하지 않는다. "이 위키는 금액을 기록하지 않습니다"라고 답한다.
한국어 합니다체로 답한다.
기본값: 모든 웹 사이트 검색변경 후: 승인본만 연결
Published/ 폴더 하나만 연결했습니다.
ORD-2026-09.docx.청중이 심사하는 열 문항 시험
두루미가 어떻게 답해야 통과일지 골라 보세요. 1~4번은 답이 승인본에 있고, 5~7번은 초안에만 있으며, 8~10번은 위키 어디에도 없습니다.
2차 시도에서 열 문항 모두 통과. 모르는 것을 모른다고 답한 여섯 문항이 핵심입니다.
옵시디언 없이 깃허브로 관리하는 위키
LLM Wiki 패턴을 널리 알린 안드레이 카파시는 메모에 이렇게 적었습니다. "위키는 마크다운 파일이 든 git 저장소일 뿐이다." 한쪽 창에는 에이전트를, 다른 쪽 창에는 옵시디언을 띄워 둔다고도 했습니다.
도구를 세 가지 역할로 나눠 보면 정리가 쉽습니다. 파일을 나르고 이력을 남기는 동기화, 사람이 읽는 뷰어, 노트를 만들고 검사하는 손입니다. 버튼을 눌러 두 구성을 비교해 보세요.
| 규칙 | 지키는 방법 |
|---|
버튼 하나로 끝나는 승인
Sources/에는 자물쇠를 걸고, Published/에는 승인자를 지정합니다.CODEOWNERS 파일에 적힌 승인자가 원문과 대조한 뒤 승인합니다. 이 사람이 승인하기 전에는 병합할 수 없습니다.깃허브가 대신하지 못하는 것
아쉬운 점도 짚어 두겠습니다. 깃허브는 동기화와 관문을 바꿔 줄 뿐, 옵시디언 같은 뷰어를 대신하지는 못합니다.
글자로만 보이는 위키링크
깃허브 화면은 [[ORD-2026-09]]를 누를 수 있는 링크로 바꾸지 않습니다.
백링크와 그래프 보기 없음
이 노트를 누가 가리키는지 한눈에 보는 기능이 없고, 검색도 기본 브랜치에서 결과 100건까지만 됩니다.
대안: 허브 노트로 길을 내고, 질문은 에이전트에게 합니다. 옵시디언은 원하면 뷰어로 덧붙입니다.비공개 저장소 규칙에 드는 요금
비공개 저장소에 규칙과 승인자를 강제하려면 Team 요금제 이상이 필요합니다. 2026년 조사 기준으로 사용자당 월 4달러입니다.
대안: 작게 시작합니다. 위키를 관리하는 몇 사람 몫의 좌석만 있으면 됩니다.낯선 git 충돌
비개발자가 가장 어려워하는 부분은 git 명령과 충돌 처리입니다.
대안: 사람은 PR 화면에서 읽고 승인만 합니다. 파일을 고치고 올리는 일은 에이전트가 맡습니다.원문 보호, 지정 승인자, 자동 검사. 권고를 강제로 바꾸는 열쇠입니다.
M365와 깃허브로 직접 만들기
지금까지 본 원칙을 실제 설정으로 옮기는 순서입니다. 탭을 바꿔 가며 두 방법을 비교해 보세요. 어느 쪽이든 3장에서 설계한 ontology.md와 템플릿을 그대로 씁니다.
명령 한 줄로 뼈대 만들기
깃허브에서 Use this template을 누르면 뼈대와 예시 노트, 검사 워크플로가 담긴 내 저장소가 바로 생깁니다.
gh repo create my-org/our-llm-wiki --private --template parandurume-labs/llm-wiki-template --clone
깃허브를 쓰지 않거나 Teams 동기화 폴더에 바로 만들려면 PowerShell 키트를 쓰세요.
설계서와 에이전트 규칙, 템플릿 일곱 개, 폴더, 예시 프롬프트, 시험 문항, 검사 스크립트, 깃허브 설정까지 한 번에 만듭니다. Windows PowerShell 5.1과 PowerShell 7에서 모두 돌아갑니다.
$kit = 'https://power-platform-users-korea.github.io/copilot-dev-days-seoul-2026/llm-wiki/kit' Invoke-WebRequest "$kit/New-LlmWiki.ps1" -OutFile New-LlmWiki.ps1 powershell -ExecutionPolicy Bypass -File .\New-LlmWiki.ps1 -Path .\our-llm-wiki -OrgName "우리 회사" -Approver "홍길동" -Sample cd .\our-llm-wiki; .\scripts\Test-LlmWiki.ps1 SUMMARY error=0 warn=0 info=1 notes=10
ontology.md설계서. 검사 스크립트가 이 표를 기준으로 삼습니다AGENTS.md에이전트 규칙. Copilot과 Claude Code가 먼저 읽습니다templates/클래스별 노트 템플릿 일곱 개Sources/raw/원문. 고치지 않습니다Sources/<클래스>/에이전트가 쓴 초안 (reviewed: false)Published/<클래스>/승인본. 에이전트가 인용하는 유일한 곳prompts.md에이전트와 함께 만드는 예시 프롬프트 열한 개questions.md에이전트 시험 문항 열 개scripts/검사, .docx 내보내기, 깃허브·SharePoint 올리기.github/CODEOWNERS, 검사 워크플로, Copilot 지시 파일브라우저로 zip을 받았다면 압축을 풀기 전에 Unblock-File .\llm-wiki-kit.zip을 실행하세요.
키트와 템플릿 저장소는 GM-Social 라이선스 v2.0을 따릅니다. 복사하거나 고쳐 쓸 때는 라이선스 파일과 저작권 표시를 남기고 출처를 밝혀 주세요.
- 위키 전용 Teams 채널 만들고 동기화하기채널의 파일 탭이 곧 SharePoint 문서 라이브러리입니다. 파일 탭에서 동기화를 누른 뒤 0단계의
-Path에 그 동기화 폴더를 넣으면 뼈대가 그대로 SharePoint에 올라갑니다. 올리는 일을 에이전트에게 맡길 때는Publish-LlmWikiSharePoint.ps1을 씁니다. - Published/ 폴더 권한 잠그기승인자만 편집하고 나머지 사람은 읽기만 하도록 폴더 권한을 바꿉니다. 이제부터 승인은 노트를 이 폴더로 옮기는 일입니다.
- 원문을 올리고 초안 쓰기원문은
Sources/raw/에 그대로 올립니다. 초안은 템플릿을 복사해 쓰고reviewed: false로 표시합니다. Word나 Teams의 Copilot에게 "이 회의록을 templates/order.md 형식으로 정리해 줘"라고 맡겨도 됩니다. - 승인하고 .docx로도 저장하기초안을 원문과 대조한 뒤
Published/로 옮기고 같은 이름의 .docx로도 저장합니다. 지금은 Copilot Studio의 SharePoint 지식이 .md 본문을 읽지 못하기 때문입니다.Export-WikiDocx.ps1 -Prune을 실행하면 Word 파일을 한꺼번에 만들고, 짝을 잃은 .docx는 지웁니다. - Copilot Studio 에이전트 만들기지시문 다섯 줄을 넣고, 지식에 기본으로 들어 있는 웹 검색을 지웁니다. SharePoint 지식에는
Published/주소 하나만 등록하고, 주소의 공백은%20으로 적습니다.https://contoso.sharepoint.com/sites/wiki/Shared%20Documents/Published
- 열 문항으로 시험하고 Teams에 게시하기답이 있는 질문 넷, 초안에만 있는 질문 셋, 어디에도 없는 질문 셋으로 시험합니다. 모른다고 답해야 하는 여섯 문항까지 통과하면 Teams에 게시합니다.
- 비공개 저장소와 AGENTS.md 만들기폴더 구조와
AGENTS.md는 0단계의 템플릿 저장소나 키트가 이미 만들어 둡니다. 다만 템플릿으로 만든 저장소에는 규칙이 따라오지 않으므로 3단계의 규칙은Publish-LlmWikiGitHub.ps1로 겁니다. 아래는 에이전트가 가장 먼저 읽는 규칙의 앞부분입니다.# AGENTS.md 1. Sources/raw/의 원문은 고치지 않는다. 오타도 그대로 둔다. 2. 새 노트는 templates/의 템플릿으로 만들고 Sources/에 reviewed: false로 둔다. 3. Published/에 직접 쓰지 않는다. 승인 요청 PR로만 제안하고, 병합은 사람이 한다. 4. 답의 근거는 Published/ 노트만 쓴다. 5. 출처 없는 사실은 쓰지 않는다. 근거가 없으면 "확인 필요"로 남긴다.
- CODEOWNERS로 승인자 지정하기이제부터 승인본과 원문, 설계서를 바꾸려면 지정한 사람이 승인해야 합니다.
# .github/CODEOWNERS /Published/ @hangyeol /Sources/raw/ @hangyeol /ontology.md @hangyeol
- Settings → Rules에서 규칙 걸기main 브랜치 규칙에서 PR 필수, 승인 1명, 코드 오너 리뷰 필수, 필수 검사
check를 켭니다. 푸시 규칙으로Sources/raw/**경로의 변경을 막고, 새 원문은 우회 권한이 있는 관리자가 올립니다. 비공개 저장소에 규칙을 걸려면 개인 계정은 GitHub Pro, 조직은 Team 요금제 이상이 필요합니다. 규칙을 걸 수 없으면 키트 스크립트는 경고만 남기고 넘어갑니다. - Actions로 검사 자동화하기PR이 열릴 때마다 키트의 검사 스크립트가 클래스, 필수 필드, 허용 값, 승인 필드, 링크를 확인합니다. paths 필터는 쓰지 않습니다. 검사를 건너뛰면 GitHub가 통과로 치기 때문입니다.
# .github/workflows/vault-check.yml name: vault-check on: pull_request: push: branches: [main] jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - shell: pwsh run: ./scripts/Test-LlmWiki.ps1 - VS Code에서 에이전트에게 초안 맡기기GitHub Copilot 에이전트에게 "Sources/raw/에 올린 회의록을 템플릿대로 정리해서 PR을 열어 줘"라고 요청합니다. 에이전트는 AGENTS.md를 먼저 읽고 그 규칙대로 일합니다.
- PR에서 승인하고 M365로 잇기승인자는 PR 화면에서 원문과 대조한 뒤 승인하고 병합합니다. Teams에서 질문을 받으려면
Published/의 노트를 .docx로 SharePoint에 내보내 Copilot Studio 지식으로 연결합니다.
우리 조직의 현재 위치
해당하는 항목에 표시하세요.
M365와 깃허브로 만드는 두 가지 순서. 오늘 오후에 첫 판을 만들 수 있는 크기입니다.
개념은 사람이, 반복은 에이전트가
인공지능 시대에는 온톨로지와 위키를 손으로 다 만들 필요가 없습니다. 다만 무엇을 왜 만드는지는 사람이 알고 있어야 합니다. 개념을 잡은 사람이 에이전트에게 일을 맡기면 설계부터 배포까지 한나절 만에 첫 판이 나옵니다.
사람이 하는 일
- 답할 질문 열 개 정하기
- 클래스, 관계, 허용 값 정하기
- 로그인하고 실행 승인하기
- 초안을 원문과 대조하고 병합하기
에이전트가 하는 일
- 질문에서 설계 표 초안 뽑기
- 키트 실행하고 템플릿 맞추기
- 원문 구조화하고 검사 결과 보고하기
- 저장소·업로드 스크립트 실행하고 PR 열기
에이전트와 함께 구축하는 흐름
사람은 로그인과 승인을 맡고, 에이전트는 명령을 실행합니다. 탭을 바꿔 두 흐름을 비교해 보세요.
- 사람질문 열 개 정하기현장에서 자주 받는 질문을 적고 에이전트에게 온톨로지 초안을 맡깁니다. 무엇에 답할지는 사람이 정합니다.
- 사람gh 로그인브라우저에서 직접 로그인합니다. 토큰은 에이전트에게 건네지 않습니다.
gh auth login --web
- 에이전트템플릿으로 저장소 만들기템플릿 저장소로 우리 조직의 비공개 저장소를 만들어 내려받습니다. 그리고 질문에 맞춘 ontology.md와 템플릿 수정안을 표로 먼저 보여 줍니다.
gh repo create my-org/our-llm-wiki --private --template parandurume-labs/llm-wiki-template --clone
- 사람설계 승인클래스와 관계, 허용 값을 검토하고 승인합니다. 이 결정은 에이전트에게 넘기지 않습니다.
- 에이전트검사하고 할 일 미리 보여 주기검사로 ERROR 0을 확인한 뒤 규칙을 거는 명령을 -WhatIf로 먼저 보여 줍니다.
.\scripts\Test-LlmWiki.ps1 .\scripts\Publish-LlmWikiGitHub.ps1 -Path . -Approver hong-gildong -WhatIf
- 에이전트승인 관문 규칙 걸기사람이 승인하면 PR 필수, 지정 승인자, 필수 검사, 원문 보호 규칙을 겁니다. 걸지 못한 규칙은 이유와 함께 보고합니다.
- 에이전트원문 구조화와 승인 요청 PR원문을 읽어 추출표를 보여 주고, 승인을 받아 초안을 만든 뒤 승인 요청 PR을 엽니다.
- 사람PR에서 대조하고 병합원문과 대조한 뒤 병합합니다. 병합 버튼을 누르는 순간이 승인입니다.
- 사람질문 열 개 정하기현장에서 자주 받는 질문을 적고 에이전트에게 온톨로지 초안을 맡깁니다.
- 에이전트동기화 폴더에 뼈대 만들기Teams 채널 파일을 OneDrive로 동기화한 폴더에서 키트를 실행하면 따로 올리지 않아도 SharePoint에 들어갑니다.
New-LlmWiki.ps1 -Path "$env:USERPROFILE\우리회사\위키 - 문서\our-llm-wiki"
- 사람설계 승인클래스와 관계, 허용 값을 검토하고 승인합니다.
- 에이전트.docx 쌍 만들고 할 일 미리 보여 주기동기화를 쓰지 않으면 업로드 스크립트가 할 일을 -WhatIf로 먼저 보여 줍니다.
.\scripts\Export-WikiDocx.ps1 -Prune .\scripts\Publish-LlmWikiSharePoint.ps1 -Path . -SiteUrl https://contoso.sharepoint.com/sites/wiki -Folder "위키/our-llm-wiki" -WhatIf
- 사람M365 로그인과 동의Connect-MgGraph가 띄우는 창에서 회사 계정으로 직접 로그인하고 권한에 동의합니다.
- 에이전트올리고 주소 보고하기볼트를 올리고 Copilot Studio에 넣을 Published/ 주소를 알려 줍니다.
- 사람권한 잠그고 에이전트 만들기 (5분)Published/ 폴더는 승인자만 편집하도록 바꾸고, Copilot Studio에서 지시문 다섯 줄과 주소 하나로 에이전트를 만듭니다.
- 에이전트시험 문항 만들기시험 문항 열 개와 기대하는 답을 만듭니다. 시험은 사람이 미리 보기 창에서 합니다.
바로 쓰는 프롬프트
VS Code의 GitHub Copilot 에이전트 모드나 Claude Code에 붙여 넣고 [ ] 부분만 바꾸세요. 키트로 만든 볼트의 prompts.md에도 같은 프롬프트가 들어 있습니다.
우리 팀이 자주 받는 질문 열 개를 아래에 붙입니다. 이 질문들에서 명사는 클래스 후보로, 동사는 관계로, 상태를 나타내는 말은 허용 값으로 뽑아 주세요. 결과는 ontology.md의 세 표(클래스, 허용 값, 관계) 형식으로 보여 주세요. - 클래스는 일곱 개 이하로 제안해 주세요. - 관계마다 "이 관계가 없으면 답할 수 없는 질문"을 적고, 그런 질문이 없는 관계는 빼 주세요. - 파일은 아직 고치지 말고 표만 보여 주세요. [질문 열 개]
ontology.md를 읽고 문제를 찾아 표로 보고해 주세요. 파일은 고치지 마세요. - 뜻이 겹치는 클래스 - 이름만 보고 뜻을 알기 어려운 필드 - 허용 값 목록이 없어 표기가 흔들릴 상태 값 - 어떤 질문에도 쓰이지 않는 관계
Sources/raw/[파일 이름]을 읽고, 파일을 만들기 전에 추출표부터 보여 주세요. 열: 종류(사실 · 확인 필요 · 모순 · 적지 않을 것) | 내용 | 근거 문장 | 연결할 노트 - 원문에 없는 원인이나 배경은 채우지 말고 "확인 필요"로 두세요. - 금액과 개인정보는 "적지 않을 것"으로 분류하세요. 제가 승인하면 templates/의 템플릿으로 Sources/의 해당 클래스 폴더에 reviewed: false 초안을 만들고, scripts/Test-LlmWiki.ps1을 실행해 결과를 알려 주세요.
scripts/Test-LlmWiki.ps1을 실행하고 결과를 ERROR, WARN 순서의 표로 정리해 주세요. 줄마다 원인과 고치는 방법을 한 문장씩 붙여 주세요. 파일은 고치지 마세요.
Sources/의 [노트 id] 초안으로 승인 요청 PR을 열어 주세요. - 새 브랜치에서 노트를 Published/의 같은 클래스 폴더로 옮기고 reviewed: true, approved_by: [승인자 이름], approved_on: 오늘 날짜를 적습니다. - PR 설명에 근거 원문과, 승인자가 원문과 대조할 문장 목록을 넣어 주세요. - 병합은 하지 마세요. 승인자가 원문과 대조한 뒤 병합합니다.
이 폴더를 깃허브 비공개 저장소로 올리고 승인 관문 규칙을 걸어 주세요. 명령은 실행 전에 보여 주고 승인을 받으세요. 1. scripts/Test-LlmWiki.ps1로 현재 상태를 검사합니다. 2. scripts/Publish-LlmWikiGitHub.ps1 -Path . -Repo [저장소 이름] -Approver [승인자 GitHub 아이디] -WhatIf 로 할 일을 보여 줍니다. 3. 제가 승인하면 -WhatIf 없이 실행합니다. gh 로그인이 필요하면 제가 브라우저에서 직접 합니다. 4. 끝나면 저장소 주소, 걸린 규칙, 걸지 못한 규칙과 그 이유를 표로 보고해 주세요.
이 볼트를 Teams 채널의 SharePoint 라이브러리에 올려 주세요. 명령은 실행 전에 보여 주고 승인을 받으세요. 1. scripts/Export-WikiDocx.ps1 -Prune 으로 승인본의 .docx 쌍을 만듭니다. 2. scripts/Publish-LlmWikiSharePoint.ps1 -Path . -SiteUrl [사이트 주소] -Folder "[채널 이름]/[볼트 이름]" -WhatIf 로 올릴 파일을 보여 줍니다. 3. 제가 승인하면 -WhatIf 없이 실행합니다. 로그인 창이 뜨면 제가 직접 로그인합니다. 4. 끝나면 Published/ 주소와 제가 화면에서 할 일 세 가지를 정리해 주세요.
[수주 id]의 "의도" 절과, intent_of로 이 노트를 가리키는 작업일지와 결정 노트를 대조해 주세요. 차이를 표로 적되 차이마다 근거 노트 링크를 붙이고, 근거 없는 차이는 적지 마세요. 결과는 reports/에 오늘 날짜를 붙인 새 파일로 제안하고, 저장 전에 보여 주세요.
Published/와 Sources/를 보고 에이전트 시험용 질문 열 개를 만들어 주세요. - 승인본에 답이 있는 질문 4개, 초안에만 있는 질문 3개, 어디에도 없는 질문 3개 - 질문마다 기대하는 답과 근거 노트를 적어 questions.md 형식으로 보여 주세요.
에이전트와 일하는 여섯 가지 요령
개념 먼저, 도구는 나중
클래스와 관계, 승인 위치를 모르면 에이전트가 쓴 초안이 맞는지 가릴 수 없습니다.
표부터 받아 보기
파일을 만들기 전에 추출표나 변경 목록부터 받으면 틀린 내용을 초안이 생기기 전에 잡습니다.
규칙은 AGENTS.md에 한 번
에이전트가 AGENTS.md를 먼저 읽으므로 프롬프트마다 규칙을 늘어놓을 필요가 없습니다.
"고치지 말고 보고만"
점검을 맡길 때 이 한 문장이 없으면 에이전트는 친절하게 고쳐 버립니다.
외부를 바꾸는 명령은 -WhatIf 먼저
저장소를 만들거나 파일을 올리는 일은 되돌리기 어렵습니다. 할 일을 먼저 확인하고 승인하며, 로그인은 사람이 직접 합니다.
"다 했습니다"보다 검사 결과
SUMMARY 줄과 PR 화면으로 확인합니다. 그다음에도 내용이 맞는지는 사람이 원문과 대조합니다.
설계부터 구조화, 점검, 배포, 운영까지 에이전트에게 일을 맡기는 프롬프트 아홉 개입니다.
척척박사가 된 두루미
척척박사는 모든 것을 아는 에이전트가 아닙니다. 아는 것은 출처와 함께 말하고, 모르는 것은 모른다고 말하는 에이전트입니다.
기능은 복제되지만, 우리 조직의 지식은 복제되지 않습니다.
서막에서 본 REA를 떠올려 보세요. 에이전트는 어떤 기능이든 뜯어보고 다시 만듭니다. 하지만 우리 회사가 어느 고객에게 무엇을 약속했는지, 왜 그렇게 정했는지, 무엇이 검증된 사실인지는 어떤 에이전트도 밖에서 가져오지 못합니다.
오늘 만든 ontology.md 한 장과 승인된 노트 서른 장은 풍요의 시대에 우리 조직만 가진 자산입니다. 에이전트의 능력은 누구나 빌려 쓰지만, 공식의 오른쪽에 있는 지식은 우리가 채워야 합니다.
- 오늘 오후 · 우리 팀이 자주 받는 질문 열 개 적기
- 이번 주 · 템플릿 저장소로 뼈대를 만들고 노트 다섯 장 승인하기
- 이번 달 · 질문 열 개로 에이전트를 시험하고 팀에 공개하기
척척박사
위 에이전트는 온톨로지로 지도를 그리고, 승인본만 인용하며, 모르는 것을 모른다고 답하였기에 이 학위를 수여합니다.
LLM Wiki & 온톨로지 실전 과정
오늘 50분에 담은 내용을 직접 해 볼 수 있는 웹 강의입니다. 코딩을 몰라도 되고, Microsoft 365를 쓰는 조직이면 바로 따라 할 수 있습니다.
- 개념 여섯 모듈: LLM Wiki, 온톨로지, 지식 계층, RAG 비교, 에이전트 워크플로, 거버넌스
- 사례연구: 한 중소기업이 위키를 만들다 실패하고 다시 세운 기록
- M365 실습: SharePoint와 Copilot Studio로 위키 에이전트 만들기
- VS Code 실습: 에이전트와 검사 스크립트로 원문을 구조화하기
- 예시 공장 템플릿으로 시작해 우리 업종의 위키를 설계하는 과제
