원문 번역 요청

댓글을 제외한 원문 본문 전체 번역입니다. 복사하기 쉽게 하나로 담았습니다.

LLM 위키
LLM을 활용해 개인 지식 기반을 만드는 방식.
이 문서는 아이디어를 담은 파일입니다. 자신이 사용하는 LLM 에이전트, 예를 들어 OpenAI Codex, Claude Code, OpenCode / Pi 등에 그대로 복사해 붙여 넣도록 작성했습니다. 전체적인 아이디어를 전달하는 것이 목적이며, 구체적인 구현 방식은 에이전트가 여러분과 협력해 만들어 나가게 됩니다.

핵심 아이디어
대부분의 사람이 LLM과 문서를 함께 사용하는 방식은 RAG와 비슷합니다. 여러 파일을 업로드하면, 질문할 때 LLM이 관련된 부분을 찾아 답변을 생성합니다. 이 방식도 작동하지만, LLM은 질문을 받을 때마다 처음부터 지식을 다시 찾아내고 있습니다. 축적되는 것이 없습니다. 다섯 개 문서의 내용을 종합해야 하는 섬세한 질문을 하면, LLM은 매번 관련된 조각들을 찾아 다시 조합해야 합니다. 쌓이는 것이 없는 겁니다. NotebookLM, ChatGPT의 파일 업로드 기능, 대부분의 RAG 시스템이 이런 방식으로 작동합니다.
여기서 제안하는 아이디어는 다릅니다. 질문할 때 원본 문서에서 내용을 찾아오는 데 그치지 않고, LLM이 지속적으로 남는 위키를 조금씩 구축하고 관리합니다. 이 위키는 여러분과 원본 자료 사이에 놓이는, 체계적으로 정리되고 서로 연결된 마크다운 파일 모음입니다. 새 자료를 추가하면 LLM은 나중에 검색할 수 있도록 색인만 만드는 것이 아닙니다. 자료를 읽고 핵심 정보를 추출한 뒤 기존 위키에 통합합니다. 인물·조직 등 개별 대상의 페이지를 갱신하고, 주제별 요약을 수정하며, 새로운 데이터가 기존 주장과 충돌하는 지점을 표시하고, 지금까지 형성된 종합적인 이해를 강화하거나 재검토합니다. 지식은 한 번 정리한 뒤 최신 상태로 유지하며, 질문할 때마다 처음부터 다시 도출하지 않습니다.
핵심적인 차이는 이것입니다. 위키는 계속 남아 있으면서 가치가 누적되는 결과물입니다. 관련 내용 사이의 상호 참조가 이미 만들어져 있습니다. 모순도 이미 표시되어 있습니다. 종합된 내용에는 지금까지 읽은 자료가 이미 반영되어 있습니다. 자료를 추가하고 질문을 할 때마다 위키는 점점 더 풍부해집니다.
여러분이 직접 위키를 작성하는 일은 없거나 거의 없습니다. LLM이 위키 전체를 작성하고 관리합니다. 여러분은 자료를 찾고, 탐색하고, 적절한 질문을 하는 일을 맡습니다. LLM은 지식 기반이 시간이 지나도 실제로 쓸모 있게 유지되도록 하는 모든 반복 작업을 맡습니다. 요약, 상호 참조, 분류·저장, 관리 기록 같은 일들입니다.
실제로 저는 한쪽에 LLM 에이전트를 열어 두고, 다른 쪽에는 Obsidian을 열어 둡니다. LLM은 대화 내용을 바탕으로 문서를 수정하고, 저는 링크를 따라가고 그래프 보기를 확인하며 갱신된 페이지를 읽는 식으로 결과를 실시간으로 살펴봅니다. Obsidian이 IDE라면, LLM은 프로그래머이고, 위키는 코드베이스인 셈입니다.
이 방식은 다양한 상황에 적용할 수 있습니다. 몇 가지 예를 들면 다음과 같습니다.
• 개인:자신의 목표, 건강, 심리, 자기계발 등을 추적합니다. 일기, 기사, 팟캐스트 메모 등을 정리해 넣으면서 시간이 지날수록 자신에 대한 체계적인 이해를 쌓아갑니다.
• 연구:몇 주 또는 몇 달 동안 한 주제를 깊이 파고듭니다. 논문, 기사, 보고서를 읽으며, 중심 주장도 발전시켜 나가는 포괄적인 위키를 점진적으로 구축합니다.
• 책 읽기:각 장을 읽을 때마다 내용을 정리하고, 등장인물, 주제, 줄거리의 흐름과 그 연결 관계를 다루는 페이지를 만듭니다. 책을 다 읽고 나면 풍부한 독서 보조 위키가 생깁니다. Tolkien Gateway 같은 팬 위키를 떠올려 보세요. 자원봉사자 공동체가 수년에 걸쳐 만든, 등장인물·장소·사건·언어 등을 다루는 수천 개의 서로 연결된 페이지가 있습니다. LLM에 상호 참조와 유지관리를 모두 맡기면, 여러분도 책을 읽어 가면서 개인적으로 비슷한 것을 만들 수 있습니다.
• 회사·팀:Slack 대화, 회의록, 프로젝트 문서, 고객 통화 내용을 바탕으로 LLM이 관리하는 내부 위키를 만듭니다. 사람이 중간에 참여해 갱신 내용을 검토하도록 할 수도 있습니다. 팀원 누구도 하고 싶어 하지 않는 유지관리 작업을 LLM이 맡기 때문에 위키가 최신 상태로 유지됩니다.
• 경쟁사 분석, 실사, 여행 계획, 강의 노트, 취미 심화 탐구:시간이 지나면서 지식이 쌓이고, 그 지식을 흩어진 채로 두지 않고 정리하고 싶은 모든 상황에 적용할 수 있습니다.

구조
세 가지 계층으로 이루어집니다.
원본 자료:여러분이 선별해 모은 원본 문서 모음입니다. 기사, 논문, 이미지, 데이터 파일 등이 여기에 해당합니다. 이 자료들은 변경하지 않습니다. LLM은 읽기만 하고 절대 수정하지 않습니다. 이것이 사실 확인의 기준이 되는 원천입니다.
위키:LLM이 생성한 마크다운 파일들이 들어 있는 디렉터리입니다. 요약, 개별 대상 페이지, 개념 페이지, 비교 자료, 개요, 종합 정리 등이 포함됩니다. 이 계층은 전적으로 LLM이 맡습니다. 페이지를 만들고, 새 자료가 들어오면 갱신하며, 상호 참조를 관리하고, 전체 내용의 일관성을 유지합니다. 여러분은 읽고, LLM은 씁니다.
스키마:위키의 구조, 따라야 할 규칙, 자료를 받아들이거나 질문에 답하거나 위키를 관리할 때의 작업 절차를 LLM에 알려 주는 문서입니다. 예를 들어 Claude Code에서는 CLAUDE.md, Codex에서는 AGENTS.md를 사용할 수 있습니다. 이것은 핵심 설정 파일입니다. LLM을 일반적인 챗봇이 아니라 규칙을 지키는 위키 관리자로 만들어 주는 것이 바로 이 파일입니다. 여러분의 분야에 어떤 방식이 잘 맞는지 알아가면서, 여러분과 LLM이 함께 이 문서를 점차 발전시켜 나갑니다.

작업
자료 반영(Ingest)
원본 자료 모음에 새 자료를 넣고 LLM에 처리하라고 요청합니다. 예를 들어 다음과 같이 진행할 수 있습니다.
LLM이 자료를 읽고, 핵심 내용을 여러분과 논의하고, 위키에 요약 페이지를 작성하고, 색인을 갱신하고, 위키 곳곳의 관련 대상·개념 페이지를 갱신한 다음, 작업 기록에 항목을 추가합니다.
자료 하나가 위키 페이지 10~15개에 영향을 줄 수도 있습니다.
개인적으로 저는 자료를 한 번에 하나씩 반영하면서 직접 관여하는 방식을 선호합니다. 요약을 읽고, 갱신 내용을 확인하고, 무엇을 강조해야 하는지 LLM에 방향을 제시합니다. 하지만 감독을 줄이고 여러 자료를 한꺼번에 반영할 수도 있습니다. 자신의 스타일에 맞는 작업 흐름을 만들고, 이후 세션에서도 따를 수 있도록 스키마에 기록하는 것은 여러분의 몫입니다.
질의(Query)
위키를 대상으로 질문합니다. LLM은 관련 페이지를 검색하고 읽은 뒤, 출처를 표시하면서 내용을 종합해 답합니다.
답변의 형태는 질문에 따라 달라질 수 있습니다. 마크다운 페이지, 비교표, 슬라이드 자료(Marp), 차트(matplotlib), 캔버스 등이 될 수 있습니다.
여기서 중요한 점은 좋은 답변을 새로운 페이지로 만들어 위키에 다시 저장할 수 있다는 것입니다. 여러분이 요청한 비교, 분석, 새롭게 발견한 연결 관계는 모두 가치 있는 내용이며, 채팅 기록 속으로 사라져서는 안 됩니다. 이렇게 하면 여러분의 탐색 결과도 새로 반영한 자료처럼 지식 기반 안에 축적됩니다.
점검(Lint)
주기적으로 LLM에 위키의 상태를 점검해 달라고 요청합니다.
확인할 항목은 다음과 같습니다.
• 페이지 사이의 모순• 더 최신 자료로 대체되어 낡아 버린 주장• 다른 페이지에서 연결해 주는 링크가 없는 고립된 페이지• 중요하게 언급되지만 별도의 페이지가 없는 개념• 빠진 상호 참조• 웹 검색으로 보완할 수 있는 정보의 빈틈
LLM은 추가로 탐구할 질문이나 찾아볼 자료를 제안하는 데도 능숙합니다. 이런 점검은 위키가 커져도 건강한 상태를 유지하도록 도와줍니다.

색인과 작업 기록
위키가 커질 때 LLM과 여러분이 내용을 찾아다닐 수 있도록 도와주는 특별한 파일 두 개가 있습니다. 두 파일의 목적은 서로 다릅니다.
index.md는 내용 중심의 파일입니다.
위키에 들어 있는 모든 것을 정리한 목록입니다. 각 페이지의 링크와 한 줄 요약을 적고, 필요하면 날짜나 출처 개수 같은 메타데이터도 넣습니다. 개별 대상, 개념, 출처 등의 범주별로 정리합니다.
LLM은 자료를 반영할 때마다 이 파일을 갱신합니다. 질문에 답할 때는 먼저 색인을 읽어 관련 페이지를 찾은 다음, 해당 페이지의 내용을 자세히 살펴봅니다.
이 방식은 중간 정도 규모, 대략 자료 100개와 수백 개의 페이지에서도 놀라울 만큼 잘 작동하며, 임베딩 기반 RAG 인프라를 따로 마련할 필요가 없게 해 줍니다.
log.md는 시간순 기록 파일입니다.
자료 반영, 질의, 점검 등 어떤 작업이 언제 이루어졌는지를 뒤에 계속 추가하는 방식으로 기록합니다.
유용한 팁이 하나 있습니다. 각 항목을 일정한 형식으로 시작하면 간단한 유닉스 도구로 기록을 분석할 수 있습니다. 예를 들면 다음과 같습니다.
## [2026-04-02] ingest | 기사 제목
다음 명령으로 최근 항목 5개를 확인할 수 있습니다.
grep "^## \[" log.md | tail -5
이 기록은 위키가 발전해 온 시간 흐름을 보여 주고, LLM이 최근 어떤 작업이 이루어졌는지 이해하도록 도와줍니다.

선택 사항: CLI 도구
어느 시점에는 LLM이 위키를 더 효율적으로 다룰 수 있도록 작은 도구를 만들고 싶어질 수 있습니다.
가장 먼저 떠오르는 것은 위키 페이지 검색 엔진입니다. 규모가 작을 때는 색인 파일만으로 충분하지만, 위키가 커지면 제대로 된 검색 기능이 필요해집니다.
qmd는 좋은 선택지입니다. 마크다운 파일을 대상으로 하는 로컬 검색 엔진으로, BM25와 벡터 검색을 결합한 하이브리드 검색 및 LLM을 이용한 검색 결과 재정렬을 지원하며, 모든 처리가 기기 안에서 이루어집니다.
CLI와 MCP 서버를 모두 제공합니다. CLI를 통해서는 LLM이 셸 명령으로 실행할 수 있고, MCP 서버를 통해서는 LLM이 자체 도구처럼 사용할 수 있습니다.
더 단순한 도구를 직접 만들어도 됩니다. 필요할 때 LLM의 도움을 받아 기본적인 검색 스크립트를 바이브 코딩으로 만들 수도 있습니다.

유용한 팁
• Obsidian Web Clipper
웹 기사를 마크다운으로 변환해 주는 브라우저 확장 프로그램입니다. 원본 자료 모음에 자료를 빠르게 추가할 때 매우 유용합니다.
• 이미지를 로컬에 내려받기
Obsidian의 설정 → 파일 및 링크에서 ‘첨부 파일 폴더 경로’를 고정된 디렉터리, 예를 들어 raw/assets/로 지정합니다.
그다음 설정 → 단축키에서 ‘Download’를 검색해 ‘Download attachments for current file’, 즉 현재 파일의 첨부 파일 다운로드 기능을 찾고, Ctrl+Shift+D 같은 단축키를 지정합니다.
기사를 클리핑한 뒤 이 단축키를 누르면 모든 이미지가 로컬 디스크로 내려받아집니다.
선택 사항이지만 유용합니다. 나중에 깨질 수 있는 URL에 의존하는 대신, LLM이 이미지를 직접 보고 참조할 수 있게 해 주기 때문입니다.
다만 LLM은 이미지가 본문에 삽입된 마크다운을 한 번에 그대로 읽어 처리하지는 못한다는 점에 유의해야 합니다. 우회 방법은 먼저 텍스트를 읽게 한 다음, 참조된 이미지의 일부 또는 전체를 따로 보게 해서 추가 맥락을 얻도록 하는 것입니다. 약간 번거롭지만 충분히 잘 작동합니다.
• Obsidian의 그래프 보기
위키의 전체적인 모습을 확인하는 가장 좋은 방법입니다. 무엇이 무엇과 연결되어 있는지, 어떤 페이지가 연결의 중심인지, 어떤 페이지가 고립되어 있는지 볼 수 있습니다.
• Marp
마크다운 기반의 슬라이드 자료 형식입니다. Obsidian용 플러그인도 있습니다. 위키 내용을 바탕으로 발표 자료를 바로 만들 때 유용합니다.
• Dataview
페이지의 프런트매터를 대상으로 질의를 실행하는 Obsidian 플러그인입니다. LLM이 위키 페이지에 태그, 날짜, 출처 개수 등을 담은 YAML 프런트매터를 추가하면, Dataview가 동적으로 갱신되는 표와 목록을 만들 수 있습니다.
• Git
위키는 결국 마크다운 파일로 이루어진 Git 저장소입니다. 따라서 버전 이력, 브랜치, 협업 기능을 별도로 구현하지 않고도 활용할 수 있습니다.

이 방식이 잘 작동하는 이유
지식 기반을 유지할 때 지루한 부분은 읽거나 생각하는 일이 아니라 관리 작업입니다.
상호 참조를 갱신하고, 요약을 최신 상태로 유지하고, 새로운 데이터가 기존 주장과 충돌하면 표시하고, 수십 개 페이지에 걸쳐 일관성을 유지하는 일들입니다.
사람들이 위키를 포기하는 이유는 얻는 가치보다 유지관리 부담이 더 빠르게 커지기 때문입니다. LLM은 지루해하지 않고, 상호 참조 갱신을 잊지 않으며, 한 번의 작업으로 파일 15개를 수정할 수 있습니다. 유지관리 비용이 거의 0에 가깝기 때문에 위키가 계속 관리됩니다.
사람의 역할은 자료를 선별하고, 분석 방향을 정하고, 좋은 질문을 던지고, 이 모든 것이 무엇을 의미하는지 생각하는 것입니다. 그 밖의 모든 일은 LLM의 역할입니다.
이 아이디어는 기본 취지에서 버니바 부시가 1945년에 제안한 메멕스(Memex)와도 관련이 있습니다. 메멕스는 개인이 자료를 선별해 보관하고, 문서 사이를 연상에 따라 연결하는 개인 지식 저장소입니다.
부시가 그린 모습은 실제로 발전한 웹보다는 이 방식에 더 가까웠습니다. 개인적이고, 적극적으로 자료를 선별·정리하며, 문서 사이의 연결이 문서 자체만큼이나 중요한 형태입니다.
그가 해결하지 못했던 부분은 누가 유지관리를 할 것인가였습니다. 이제 그 일을 LLM이 맡습니다.

참고
이 문서는 의도적으로 추상적인 수준에서 작성되었습니다. 특정한 구현 방식이 아니라 아이디어를 설명합니다.
정확한 디렉터리 구조, 스키마 규칙, 페이지 형식, 사용하는 도구 등은 모두 여러분의 분야, 선호, 선택한 LLM에 따라 달라집니다.
앞서 언급한 모든 요소는 선택 사항이며, 각각 따로 조합해 사용할 수 있습니다. 유용한 것은 선택하고, 필요 없는 것은 무시하세요.
예를 들어 자료가 전부 텍스트라면 이미지 처리 기능은 전혀 필요하지 않습니다. 위키가 작다면 색인 파일만으로 충분하고 검색 엔진은 필요하지 않을 수 있습니다. 슬라이드 자료에는 관심이 없고 마크다운 페이지만 원할 수도 있습니다. 완전히 다른 출력 형식을 원할 수도 있습니다.
이 문서를 활용하는 올바른 방법은 자신의 LLM 에이전트와 공유한 뒤, 필요에 맞는 형태를 함께 구체적으로 만들어 보는 것입니다.
이 문서의 유일한 역할은 이 방식을 전달하는 것입니다. 나머지는 여러분의 LLM이 구체화할 수 있습니다.

꼭 RAG 방식이라는 뜻은 아니에요. MD 파일을 읽는다는 사실만으로 RAG라고 하지는 않습니다. 앞의 글을 보면 그렇게 받아들이기 쉬운데, 구분해서 설명할게요.

말씀하신 작업은 우선 “노하우와 작업 규칙을 파일에 저장하고, 클로드가 그걸 참고해 일하는 방식”이에요.

여기서 파일에 무엇을 저장하고, 어떻게 활용하느냐가 중요합니다.

1. 지금 말씀하신 방식: 작업 매뉴얼을 읽고 일하기

예를 들어 병윤님이 이렇게 말합니다.

“견적 낼 때 이 항목은 반드시 별도로 계산해. 이 내용을 MD 파일에 저장해 둬.”

이후 클로드가 그 파일을 읽고 견적을 작성한다면, 직원에게 업무 매뉴얼을 만들어 주고 따르게 하는 것에 가깝습니다. 스킬이나 지침 파일을 활용하는 방식이죠.

이것만으로는 RAG라고 단정할 수 없어요.

2. RAG: 질문에 필요한 자료를 찾아서 답하기

예를 들어 다음처럼 물어봅니다.

“지난번 A현장은 왜 추가 비용이 발생했어?”

그러면 여러 현장 문서에서 관련 내용을 찾아 읽고 답합니다.

자료 보관함에서 질문에 필요한 서류를 꺼내 답하는 방식이에요. 보통 RAG라고 부르는 시스템은 이런 검색과 답변 과정을 연결해 놓은 것입니다.

3. LLM 위키: 찾은 내용을 관리대장에 계속 반영하기

같은 자료를 읽더라도 답변만 하고 끝내지 않습니다.

“A현장은 양중 조건 때문에 추가 비용이 발생했네. A현장 페이지에도 기록하고, 양중비 기준 페이지와 관련 현장 목록도 함께 갱신하자.”

이렇게 여러 자료를 종합한 정리본을 만들고, 서로 연결하고, 새 내용이 생기면 기존 정리까지 고쳐 나가는 것이 이 글에서 말하는 LLM 위키입니다.

그러니까 병윤님은 이미 이 아이디어의 일부를 실천하고 계셨던 거예요. 노하우를 채팅에만 남기지 않고 파일로 저장해 다음 작업에 활용하셨으니까요.

다만 “클로드가 매뉴얼을 읽고 일한다”와 “클로드가 관련 지식을 계속 종합하고 연결해서 관리한다”는 다른 단계입니다.

지금 클로드가 MD 파일을 단순히 추가·참고하는지, 기존 관련 파일까지 찾아 함께 갱신하는지는 제가 확인하지 않았으니 단정할 수 없습니다. 후자까지 하고 있다면 이미 LLM 위키와 상당히 비슷하게 운영하고 있는 겁니다.

RAG는 쉽게 말하면 “AI가 자기 지식만으로 답하지 않고, 필요한 자료를 찾아 읽은 뒤 답하도록 하는 방식”입니다.

병윤님 회사에 비유하면 “자기 경험으로만 답하는 직원”에게 “회사 서류함을 찾아보고 근거를 확인한 다음 답하게 하는 것”이에요.

익숙한 1~5번 틀로 설명하고, 지금 클로드를 쓰시는 방식과도 연결해 볼게요.

1. RAG라는 이름은 무슨 뜻인가?

Retrieval-Augmented Generation의 약자입니다.

• Retrieval: 필요한 정보를 찾아 가져오기
• Augmented: 가져온 정보로 보강하기
• Generation: 답변 생성하기

합치면 “검색한 정보로 보강해서 답변을 만드는 방식”입니다.

여기서 ‘검색’은 네이버나 구글 검색만 뜻하지 않습니다. 회사 폴더, PDF, MD 파일, 데이터베이스 등에서 필요한 내용을 찾는 것도 포함됩니다.

예를 들어 병윤님이 이렇게 물었다고 해볼게요.

“우리 회사 기준으로 이 현장은 양중비를 별도로 받아야 해?”

일반적인 AI는 건설업의 일반적인 관행은 설명할 수 있어도, 병윤님 회사에서 정한 내부 기준은 원래 알 수 없습니다.

RAG는 이때 회사의 양중비 규정과 해당 현장 자료를 찾아 AI에 전달합니다. AI는 그 내용을 참고해 답합니다.

AI 자체가 갑자기 회사 전문가가 된 것이 아니라, 답할 때 회사 자료를 펼쳐 볼 수 있게 된 것입니다.

2. 누가, 언제, 왜 만들었나?

현재 널리 쓰이는 RAG라는 이름과 대표적인 구조는 Patrick Lewis 등 Facebook AI Research·University College London 등의 연구진이 2020년 발표한 논문에서 제시했습니다.

다만 “자료를 찾아 답한다”는 아이디어 전체를 그때 처음 발명했다는 뜻은 아닙니다. 이전부터 정보 검색과 AI를 결합하는 연구는 있었습니다.

해결하려던 핵심 문제는 이겁니다.

“AI가 학습하면서 익힌 지식만으로는, 필요한 사실을 정확하고 최신 상태로 제공하기 어렵다.”

회사에 아무리 유능한 직원을 채용해도 입사 전부터 우리 회사의 단가표와 현장 이력을 알고 있지는 않죠.

그렇다고 단가가 바뀔 때마다 직원을 처음부터 다시 교육할 필요는 없습니다.

최신 단가표를 찾아보고 일하도록 하면 됩니다. RAG도 비슷한 발상입니다.

3. RAG가 없으면 무엇이 불편한가?

① AI는 비공개 회사 자료를 원래 모릅니다

예를 들어 다음 내용은 일반적인 모델 지식만으로 알 수 없어요.

• 우리 회사의 거래처별 단가
• 대표가 정한 견적 예외 규칙
• 특정 현장에서 추가 비용이 발생한 이유
• 지난주 직원 회의에서 결정한 내용

이런 내용을 근거 없이 물으면 AI가 모른다고 답하거나, 그럴듯하지만 틀린 답을 만들 수 있습니다.

② 매번 사람이 자료를 골라 붙여 넣어야 합니다

병윤님이 직접 이렇게 할 수도 있습니다.

“이게 우리 규정이고, 이게 현장 자료야. 둘을 읽고 답해줘.”

자료가 적으면 충분히 좋은 방법입니다.

하지만 현장이 수백 개이고 문서가 수천 개라면, 질문할 때마다 사람이 필요한 서류를 찾는 것부터 해야 합니다.

RAG는 그 자료 찾기 과정을 시스템에 맡기는 것입니다.

③ 모든 자료를 매번 한꺼번에 읽히기도 어렵습니다

AI가 한 번에 받아들일 수 있는 정보량에는 한계가 있습니다. 이것을 컨텍스트 창이라고 합니다.

한도가 크더라도 회사 자료 전체를 매 질문에 넣으면 비용과 처리 시간이 늘고, 중요한 내용을 놓칠 수도 있습니다.

그래서 이렇게 바꿉니다.

“회사 서류를 전부 책상에 올리지 말고, 이번 질문에 필요한 서류만 찾아 올리자.”

4. RAG를 쓰면 무엇이 편해지나?

회사 내부 자료를 바탕으로 답할 수 있습니다

일반적인 설명이 아니라 우리 회사의 기준과 기록을 근거로 답할 수 있습니다.

자료 변경을 반영하기 쉬워집니다

단가표가 바뀌면 원본과 검색용 자료를 갱신해, 이후 질문에서 새 자료를 찾도록 할 수 있습니다.

보통의 RAG 운영에서는 자료가 바뀔 때마다 AI 모델 자체를 재학습시킬 필요가 없습니다.

단, 파일만 수정했다고 모든 시스템에 즉시 반영되는 것은 아닙니다. 검색 색인도 함께 갱신되어야 하는 경우가 있습니다.

답변의 근거를 확인할 수 있습니다

출처를 함께 표시하도록 구성하면 다음처럼 답하게 할 수 있습니다.

“이 조건은 별도 청구 대상입니다. 근거: 양중비 규정 3항, 해당 현장 작업 메모.”

다만 RAG를 쓴다고 출처가 자동으로 정확해지는 것은 아닙니다. 실제로 그 자료가 답변을 뒷받침하는지도 확인해야 합니다.

5. 실제로 어떤 원리로 해결하나?

이해하기 쉽게 자료를 준비하는 과정과 질문에 답하는 과정으로 나눠볼게요.

A. 먼저 자료를 검색하기 좋게 준비합니다

① 자료를 모읍니다

예를 들어 다음 파일들이 있습니다.

• 양중비_규정.md
• 거래처별_단가표.xlsx
• A현장_작업기록.pdf
• B현장_추가비용.md

② 내용을 읽어낼 수 있게 꺼냅니다

PDF나 엑셀에서 텍스트와 표를 읽고, 스캔한 이미지라면 글자를 인식하는 OCR이 필요할 수 있습니다.

이 과정에서 표나 숫자가 잘못 읽히면 이후 답변도 틀릴 수 있습니다.

③ 필요하면 문서를 작은 단위로 나눕니다

이렇게 나눈 조각을 청크(chunk)라고 부릅니다.

100쪽짜리 매뉴얼 전체 대신, ‘양중비 부과 조건’에 해당하는 부분만 찾아 가져올 수 있도록 하는 거예요.

너무 작게 나누면 예외 조건이 떨어져 나가고, 너무 크게 나누면 불필요한 내용까지 따라옵니다. 그래서 조각의 크기와 문맥 보존이 중요합니다.

④ 검색용 색인을 만듭니다

검색 방식에는 여러 가지가 있습니다.

• 키워드 검색: ‘양중비’라는 단어가 들어 있는 부분 찾기
• 의미 검색: 표현이 달라도 뜻이 비슷한 부분 찾기
• 혼합 검색: 두 방식을 함께 사용하기

의미 검색에는 흔히 임베딩(embedding)을 사용합니다.

글의 의미적 특징을 숫자 목록으로 표현해, 질문과 자료가 얼마나 비슷한지 비교하는 방식입니다.

예를 들어 질문에 ‘양중비’라는 단어가 없어도,

“엘리베이터를 못 쓰고 계단으로 자재를 올리면 비용을 더 받아?”

라는 질문과 ‘계단 운반 추가 요금’ 규정이 관련 있다는 것을 찾도록 돕습니다.

임베딩은 AI에게 문서를 영구적으로 외우게 하는 과정이 아니라, 관련 자료를 찾기 위한 검색용 표현을 만드는 과정입니다.

또한 모든 RAG에 임베딩이나 벡터 데이터베이스가 꼭 필요한 것은 아닙니다. 키워드 검색 등으로도 구성할 수 있습니다.

B. 질문이 들어오면 자료를 찾아 답합니다

병윤님이 질문합니다.

“A현장은 양중비를 별도로 받아야 해?”

그러면 대략 다음 순서로 작동합니다.

1. 질문과 관련된 자료를 찾습니다.
2. A현장 조건과 양중비 규정 등을 가져옵니다.
3. 필요하면 검색 결과 중 더 관련 있는 것을 다시 추립니다.
4. 질문과 찾은 자료를 AI에 함께 전달합니다.
5. AI가 자료를 읽고 답변을 작성합니다.

아래는 설명용 가상 사례입니다.

찾은 자료가 다음과 같다고 해볼게요.

회사 규정: 계단 운반 시 양중비 별도 협의.
A현장 기록: 엘리베이터 사용 불가, 계단 운반 예정.
A현장 계약서: 양중비 포함 여부 기재 없음.

좋은 답변은 이렇게 나와야 합니다.

“회사 규정상 별도 협의 대상입니다. 다만 계약서에 포함 여부가 명시되어 있지 않으므로, 확정 청구 전에 기존 합의 내용을 확인해야 합니다.”

검색은 근거를 가져오는 역할이고, AI는 그 근거를 해석해 답하는 역할입니다.

그럼 RAG는 AI가 기억하는 것인가?

자료가 남아 있는 것과, AI 모델 자체가 그 내용을 학습하는 것은 다릅니다.

직원에 비유하면 다음과 같습니다.

• 모델 학습: 교육을 받아 직원 자체의 지식이나 행동 방식이 달라지는 것
• RAG: 일할 때 관련 서류를 찾아 책상 위에 펼쳐 주는 것
• MD 파일 저장: 다음에도 꺼내 볼 수 있도록 서류함에 문서를 보관하는 것

병윤님이 클로드에 이렇게 말했을 때,

“이 노하우를 MD 파일에 저장해 둬.”

파일에 저장되었다고 해서 클로드 모델 자체가 그 내용을 영구적으로 학습한 것은 아닙니다.

다음 작업에서도 그 파일이 자동으로 제공되거나, 클로드가 찾아 읽어야 활용할 수 있습니다.

그래서 중요한 질문은 “저장했어?”뿐 아니라 “다음 작업에서 그 파일을 어떻게 다시 찾아 읽게 되어 있어?”입니다.

지금 병윤님이 쓰는 방식과 연결하면

앞서 제가 설명한 구분을 조금 더 정확하게 다듬으면 이렇습니다.

“MD 파일을 읽는다”만으로는 RAG 여부를 판단할 수 없습니다.

• 정해진 지침 파일을 매번 제공한다면, 주로 작업 지침을 컨텍스트에 넣는 방식입니다.
• 질문에 따라 관련 파일을 검색하고 읽은 뒤 답한다면, 넓게는 검색으로 답변을 보강하는 RAG 성격이 있습니다.
• 에이전트가 직접 파일 검색 도구를 쓰고, 읽은 내용에 따라 추가 검색까지 한다면 에이전트형 RAG라고 부르기도 합니다.

즉, 별도 벡터 데이터베이스가 없다고 RAG가 아닌 것도 아니고, MD 파일을 쓴다고 무조건 RAG인 것도 아닙니다.

RAG와 LLM 위키는 반대되는 방식인가?

아닙니다. 함께 사용할 수 있습니다.

• RAG: 필요한 지식을 어떻게 찾아서 답변에 사용할 것인가?
• LLM 위키: 지식을 어떻게 정리하고 연결하고 최신 상태로 유지할 것인가?

병윤님 회사에 비유하면,

• 원본 자료: 계약서, 현장 메모, 단가표
• LLM 위키: 원본을 바탕으로 정리한 현장별 관리대장과 업무 기준서
• RAG: 질문에 맞는 계약서나 관리대장을 찾아 담당자에게 가져다주는 과정

입니다.

잘 정리된 위키를 RAG로 검색할 수도 있고, 필요하면 원본까지 함께 검색할 수도 있습니다.

마지막으로, RAG도 틀릴 수 있습니다

대표적인 이유는 다음과 같습니다.

• 필요한 자료를 검색하지 못함
• 이름이 비슷한 다른 현장 자료를 가져옴
• 최신 규정 대신 예전 규정을 가져옴
• 본문만 가져오고 예외 조건은 빠뜨림
• 자료는 맞게 찾았지만 AI가 잘못 해석함

그래서 실제 회사 업무에서는 현장·거래처 구분, 적용 날짜, 최신본 관리, 출처 확인, 접근 권한이 중요합니다. 금액 계산은 별도의 계산 로직으로 검증하는 편이 안전하고요.

정리하면, RAG는 “AI에게 모든 것을 외우게 하는 기술”이 아니라 “필요한 순간에 맞는 자료를 찾아 읽고 답하게 하는 방식”입니다.

그건 주로 ‘컨텍스트(context, 문맥)’를 이용하는 원리예요.

이전 대화를 기억하는 것처럼 보이지만, 실제로는 답변할 때 앞선 대화 내용을 함께 참고하는 것에 가깝습니다.

1. 질문 한 줄만 AI에게 전달되는 게 아닙니다

병윤님과 AI가 이렇게 대화했다고 해볼게요.

병윤님: “나는 석재 회사를 운영해.”
AI: “어떤 업무를 도와드릴까요?”
병윤님: “견적서 작성이 필요해.”
AI: “어느 현장인가요?”
병윤님: “아까 말한 회사 기준으로 만들어줘.”

마지막 문장만 보면 ‘아까 말한 회사’가 어디인지 알 수 없죠.

그런데 채팅 앱은 보통 마지막 질문만 보내는 것이 아니라, 이전 대화와 필요한 지침 등을 묶어서 모델에 전달합니다.

개념적으로는 이렇게 됩니다.

[앞선 대화]사용자는 석재 회사를 운영한다고 말했다.견적서 작성을 요청했다.어느 현장인지 질문했다.
[이번 질문]아까 말한 회사 기준으로 만들어줘.
→ 이 내용을 참고해서 다음 답변을 작성해라.

실제로는 대화 원문이 들어갈 수도 있고, 일부가 요약되어 들어갈 수도 있습니다.

그래서 AI는 지금 전달받은 내용 안에서 앞뒤 관계를 파악해 답할 수 있는 거예요.

2. 현장 회의에 비유하면 이렇습니다

매번 답변하기 전에, 지금까지의 회의록을 펼쳐 보는 담당자라고 생각하시면 됩니다.

병윤님이 이렇게 말씀하십니다.

“아까 정한 방식대로 하되, 양중비만 별도로 빼줘.”

담당자는 회의록에서 다음 내용을 확인합니다.

• ‘아까 정한 방식’이 무엇인지
• 어느 현장 이야기인지
• 어떤 항목까지 포함하기로 했는지

그다음 변경 사항을 반영하죠.

AI도 비슷하게 앞선 대화에서 대상·조건·결정 사항을 읽어 이번 질문의 뜻을 해석합니다.

이것을 문맥 안에서 정보를 활용하는 것, 조금 전문적으로는 인컨텍스트 러닝(in-context learning)이라고 합니다.

이름에 ‘러닝’이 들어가지만, 그 대화로 모델 자체를 재학습한다는 뜻은 아닙니다.

3. 그럼 대화가 길어지면 왜 잊어버리나요?

회의록을 한 번에 펼쳐 볼 수 있는 책상 크기에 한계가 있기 때문입니다.

AI가 한 번에 참고할 수 있는 정보량을 컨텍스트 창이라고 해요. 여기에는 대화뿐 아니라 파일 내용, 도구로 읽은 결과 등도 들어갈 수 있습니다.

대화가 길어지면 앱은 제품과 설정에 따라 다음 같은 처리를 합니다.

• 오래된 대화 일부를 제외하기
• 이전 내용을 요약해서 넣기
• 필요할 때 과거 기록을 다시 검색하기

여기서 문제가 생길 수 있어요.

원래 대화가 이랬는데,

“A현장만 양중비를 빼줘. 다른 현장은 기존대로야.”

요약 과정에서 이렇게 줄어들면,

“양중비를 제외하기로 함.”

‘A현장만’이라는 중요한 조건이 사라집니다.

그러면 AI가 다른 현장에도 잘못 적용할 수 있죠. 기억을 못 하는 것처럼 보이는 이유 중 하나입니다. 물론 내용을 보고도 잘못 해석하는 경우도 있고요.

다만 병윤님이 쓰시는 클로드 앱이 실제로 어떤 내용을 언제 요약하거나 제외했는지는, 제가 확인하지 않았으므로 단정할 수 없습니다.

4. 그러면 컨텍스트, RAG, MD 파일은 어떻게 다른가요?

이 셋은 경쟁하는 방식이 아니라 서로 연결되는 요소예요.

컨텍스트는 지금 AI가 펼쳐 보고 있는 작업 자료입니다.

그 자료를 가져오는 경로가 다른 거예요.

• 대화 기록: 방금까지 나눈 이야기를 컨텍스트에 넣음
• MD 파일 읽기: 저장해 둔 규칙이나 노하우를 읽어 컨텍스트에 넣음
• RAG: 질문에 맞는 자료를 검색해서 컨텍스트에 넣음

결국 모델은 그렇게 전달받은 내용을 바탕으로 답변을 만듭니다.

그래서 같은 세션에서,

“아까 그 방식으로 해줘.”

라고 했을 때는 대화 기록만으로 이해할 수 있지만, 새 세션에서는 앞선 기록이 제공되지 않으면 무엇을 뜻하는지 모를 수 있습니다.

반면 중요한 결정을 MD 파일에 저장해 두고 새 세션에서도 그 파일을 읽도록 해놓으면, 이전 대화 전체가 없어도 기준을 이어갈 수 있죠.

병윤님이 그동안 경험하신 것은 주로 “이전 대화를 작업 자료로 함께 읽으면서 흐름을 이어가는 것”입니다.

그리고 노하우를 MD에 저장하신 것은 “그 대화가 더 이상 전달되지 않더라도, 나중에 다시 꺼내 쓸 수 있게 별도로 기록해 둔 것”이에요.

단, 파일이 존재하는 것과 매번 실제로 읽는 것은 별개라는 점이 중요합니다.

둘 다 “대화에서 얻은 내용을 파일에 남겨, 나중에 다시 활용한다”는 점에서는 같습니다.

차이는 MD라는 파일 형식이 아니라, 무엇을 어떻게 정리하고 관리하느냐예요. 앞에서 제가 둘을 너무 다른 것처럼 설명했다면, 이 부분은 바로잡을게요.

1. memory.md는 보통 ‘기억해 둘 핵심 메모’입니다

예를 들어 이런 내용입니다.

- 사용자는 석재 회사를 운영한다.- 설명은 쉬운 한국어로 한다.- 견적에서 양중비는 현장 조건을 확인한다.- A현장은 양중비 포함 여부를 추가 확인해야 한다.

다음 대화나 작업에서 AI가 이 파일을 읽으면, 처음부터 설명하지 않아도 기준을 이어갈 수 있죠.

담당자가 인수인계 수첩에 중요한 내용을 적어 두는 것과 비슷합니다.

다만 memory.md라는 이름에 정해진 기능이 있는 것은 아닙니다. 실제 내용과 읽는 방식은 사용하는 프로그램의 설정에 따라 달라요.

2. LLM 위키는 ‘연결된 업무 지식 체계’에 가깝습니다

같은 내용을 위키로 관리하면, 예를 들어 이렇게 나눌 수 있습니다.

회사_견적기준.md→ 양중비 기준 페이지 연결
양중비_기준.md→ 기본 원칙→ 예외 조건→ 근거 자료→ 관련 현장 사례 연결
현장_A.md→ 현장 조건→ 양중비 협의 내용→ 현재 미확정 사항→ 원본 계약서 연결

여기서 중요한 것은 파일을 여러 개로 나누는 것 자체가 아닙니다.

새로운 사실이 들어오면 이미 정리한 관련 내용까지 함께 고친다는 점이에요.

예를 들어 병윤님이 이렇게 말씀하셨다고 해볼게요.

“A현장은 확인해 보니 양중비가 계약에 포함돼 있었어.”

단순한 메모 추가라면 다음 한 줄만 남길 수 있습니다.

“A현장 양중비 포함.”

위키식으로 관리한다면 다음까지 처리하는 겁니다.

• A현장의 ‘추가 확인 필요’를 ‘포함 확인 완료’로 수정
• 확인 근거인 계약서 연결
• 기존에 ‘별도 청구 예정’이라고 적힌 관련 문서도 수정
• 이 결정이 A현장에만 해당하며 회사 전체 기준 변경은 아니라는 점 유지

메모를 쌓는 데서 끝내지 않고, 기존 지식과 맞춰 정리하는 것이 핵심입니다.

3. 건설 업무로 비유하면

memory.md는 대표님 옆에 있는 업무 인수인계 수첩에 가깝고,

LLM 위키는 현장별 관리대장·업무 기준서·근거 서류가 서로 연결된 문서 체계에 가깝습니다.

수첩도 충분히 유용합니다. 기억할 것이 적다면 오히려 간단하고 좋죠.

하지만 현장과 예외 조건이 많아지면 한 수첩에 계속 추가하는 것만으로는 이런 문제가 생길 수 있습니다.

• 이 기준이 어느 현장에 적용되는지 헷갈림
• 예전 결정과 새 결정이 같이 남음
• 왜 그렇게 결정했는지 근거가 사라짐
• 관련 내용이 여러 곳에서 서로 달라짐

LLM 위키는 이런 문제를 줄이도록 관리하는 방식입니다.

4. 그럼 지금 쓰던 memory.md는 위키가 아닌가요?

이미 위키처럼 관리되고 있을 수도 있습니다.

예를 들어 memory.md에는 핵심 요약과 다른 문서의 위치만 적혀 있고, 세부 내용은 주제별 파일에 나뉘어 있으며, 새 결정이 생길 때 관련 파일까지 갱신한다면 이미 LLM 위키와 상당히 비슷한 구조예요.

반대로 파일 이름을 ‘위키’로 바꿔도 대화 요약만 계속 덧붙인다면, 관리 방식은 크게 달라지지 않습니다.

병윤님이 쓰시는 클로드의 실제 파일 구조와 갱신 과정을 제가 보지는 않았으니, 현재 어느 쪽인지는 단정할 수 없습니다.

정리하면, memory.md는 기억을 담는 파일이고, LLM 위키는 그런 기억과 자료들을 연결하고 갱신하는 운영 방식입니다. 따라서 memory.md가 LLM 위키의 일부가 될 수도 있습니다.

병윤님은 요청하는 방식을 크게 바꿀 필요가 없습니다.
잘 연결해 놓으면 지금처럼 대화하면서 일하되, 작업 뒤에 남는 지식을 병윤님도 직접 보고 확인하기 쉬워지는 것이 가장 큰 변화예요.

다만 먼저 구분해야 합니다.

Obsidian은 문서를 보고 연결하는 도구이고, LLM 위키는 그 문서를 AI가 정리·관리하는 방식입니다.

Obsidian을 설치하는 것만으로 클로드가 더 똑똑해지거나, 기억이 자동으로 정확해지지는 않습니다.

1. 아웃풋은 무엇이 체감적으로 달라질까?

① 결과물 자체보다 ‘결과물 뒤에 남는 것’이 달라집니다

지금도 클로드에게 견적 검토나 글 작성을 요청하면 결과물이 나오죠.

위키 방식으로 운영하면 결과물 외에도 다음이 남게 할 수 있습니다.

• 이번 작업에서 사용한 기준
• 새로 확인된 예외 조건
• 결정한 이유와 근거
• 아직 확인되지 않은 사항
• 관련된 과거 작업과의 연결

예를 들어 설명용으로 이런 상황을 생각해볼게요.

“이 현장은 양중비가 계약에 포함돼 있으니까 별도로 넣지 마.”

지금은 견적을 수정하고, 기억 파일에 한 줄 남기는 것으로 끝날 수 있습니다.

위키 방식이라면 견적 수정과 함께 다음까지 정리합니다.

• 해당 현장 페이지에 ‘계약에 포함’ 기록
• 근거 계약서 연결
• 기존의 ‘별도 청구 예정’ 기록 정정
• 회사 전체 규칙이 아닌 해당 현장의 예외로 구분

당장 받는 견적서가 극적으로 달라지는 것보다는, 다음 견적 작업에서 같은 설명을 반복할 필요가 줄어드는 쪽입니다. 물론 다음 작업에서 그 기록을 실제로 읽도록 연결되어 있어야 합니다.

② “AI가 뭘 기억하고 있지?”를 직접 확인할 수 있습니다

지금은 클로드가 “저장했습니다”라고 하면, 실제로 무엇을 어떻게 적었는지 파일을 찾아 열어봐야 할 수 있죠.

Obsidian에서는 관련 문서를 열어 다음을 살펴보기 편해집니다.

• 내 말을 정확히 기록했는지
• 예외를 전체 규칙으로 잘못 적지는 않았는지
• 오래된 내용이 아직 남아 있는지
• 어떤 자료를 근거로 정리했는지

AI의 기억을 믿기만 하는 것이 아니라, 눈으로 검토할 수 있는 업무 문서로 다루게 되는 것이에요.

③ 여러 작업을 가로지르는 질문에 유리해질 수 있습니다

예를 들어 이렇게 물을 수 있습니다.

“최근 견적에서 자주 헷갈렸던 조건들을 모아서 직원용 확인 목록으로 만들어줘.”

현장별 기록과 기준이 잘 정리되어 있다면, 긴 채팅들을 다시 뒤지는 대신 관련 문서를 바탕으로 만들 수 있습니다.

다만 없는 기록까지 알아내거나, 자료가 부실한데도 정확한 답을 보장하는 것은 아닙니다.

④ 지금도 이미 잘 관리되고 있다면 차이는 작을 수 있습니다

현재 클로드가 주제별 MD 파일을 만들고, 관련 내용을 찾아 함께 갱신하고 있다면 이미 상당 부분 하고 있는 겁니다.

그 경우 Obsidian을 추가했을 때 가장 큰 차이는 AI의 능력 향상보다 병윤님이 문서를 읽고, 찾고, 연결을 살펴보기 쉬워지는 것입니다.

2. 인풋, 즉 요청하는 방식도 바꿔야 할까?

기본적으로 지금처럼 말씀하시면 됩니다.

이건 다음부터도 이렇게 해줘.
아까 말한 건 A현장에만 해당해.
이 기준은 이제 안 써. 앞으로는 이걸로 바꿔줘.
이건 아직 확정 아니고 검토 중이야.

병윤님이 직접 파일명을 정하거나, 링크를 걸거나, 문서를 분류할 필요는 없습니다. 그런 정리 작업을 AI가 맡도록 만드는 것이 이 방식의 취지니까요.

다만 다음 세 가지를 분명히 말해주시면 효과가 큽니다.

• 적용 범위: 이번 작업만인지, 앞으로 모든 작업인지
• 확정 여부: 결정인지, 아이디어인지, 확인 중인지
• 변경 관계: 기존 기준을 대체하는지, 예외를 추가하는지

이건 Obsidian 사용법을 배우는 문제라기보다, 직원에게 업무를 지시할 때 오해를 줄이는 것과 같습니다.

3. 대신 처음에 ‘AI가 정리하는 규칙’은 정해야 합니다

병윤님이 매번 길게 요청하는 대신, 처음에 클로드 쪽에 이런 운영 기준을 마련하는 거예요.

• 원본 자료는 보존한다.
• 확정된 결정과 검토 중인 생각을 구분한다.
• 새 내용이 기존 기록과 충돌하면 확인하거나 정정한다.
• 중요한 결정에는 근거와 적용 범위를 남긴다.
• 관련 문서를 연결하고, 다음 작업에서 필요한 문서를 읽는다.

병윤님의 인풋을 복잡하게 바꾸는 것이 아니라, AI가 인풋을 처리하는 방식을 바꾸는 것입니다.

그리고 모든 대화를 무조건 저장하는 것은 추천하지 않습니다. 임시 질문까지 쌓이면 오히려 찾기 어려워져요. 공부 꼬리질문처럼 모았다가 요청할 때 한 번에 정리하는 방식도 그대로 유지할 수 있습니다.

4. 오히려 불편해질 수 있는 부분은?

초기 설정과 관리 부담은 조금 생깁니다.

• 어느 폴더를 클로드와 Obsidian이 함께 사용할지 정해야 함
• 클로드가 필요한 파일을 읽고 수정할 수 있어야 함
• 기존 문서를 중복해서 만들지 않도록 해야 함
• 잘못 정리된 내용은 사람이 확인해야 함

Obsidian이 클로드 대화를 알아서 가져오거나, 모든 MD를 자동으로 읽히게 해주는 것은 아닙니다. 그 연결과 작업 규칙은 별도로 마련해야 합니다.

또한 거래·재고·입금 같은 실제 업무 데이터는 Crux에서 관리하고, 위키에는 업무 노하우·판단 기준·결정 이유를 정리하는 식으로 역할을 나누는 편이 좋습니다. 같은 거래 장부를 두 군데 만들면 서로 달라질 수 있으니까요.

병윤님께는 이렇게 시작하는 게 맞습니다

기존 작업을 전부 옮기기보다, 기존 MD를 보존한 상태에서 한 분야만 연결해 보는 것을 추천합니다.

예를 들어 ‘견적 노하우’ 하나로 시작해서 다음을 보는 거예요.

1. 병윤님은 기존처럼 자연스럽게 요청한다.
2. 클로드는 작업하면서 관련 기준과 예외를 정리한다.
3. 병윤님은 Obsidian에서 기록이 맞는지 확인한다.
4. 다음 작업에서 그 기록을 제대로 활용하는지 확인한다.

핵심은 “새로운 앱에서 더 열심히 메모하기”가 아닙니다.
“지금 하던 대화와 작업이, 다음에도 쓸 수 있는 회사 지식으로 남게 만들기”입니다.

맞아요. 같은 내용을 두 군데 복사해서 관리하면 중복으로 읽거나, 서로 다른 내용을 읽는 문제가 생길 수 있습니다. 제가 앞에서 “Obsidian에도 기록한다”고 표현해서 별도 저장소처럼 들리게 했네요.

실제로는 기존 MD 파일을 Obsidian에서 그대로 열면 됩니다.

Obsidian은 별도의 저장 공간이 아닙니다

Obsidian에서 말하는 ‘보관함(Vault)’은 기본적으로 내 컴퓨터의 폴더입니다. 그 폴더 안에 있는 MD 파일을 읽고 편집하는 거예요.

예를 들어 기존에 이런 파일이 있다면,

업무지식/  memory.md  견적기준.md  시공노하우.md

이 업무지식 폴더를 Obsidian의 보관함으로 열 수 있습니다.

그러면:

• 클로드: 그 폴더의 MD 파일을 읽고 수정
• 병윤님: Obsidian으로 똑같은 파일을 열어 확인하고 수정

하는 구조입니다.

파일은 하나이고, 그 파일을 보는 프로그램이 다른 것입니다. 같은 엑셀 파일을 서로 다른 프로그램으로 여는 것과 비슷해요.

따라서 이렇게 할 필요는 없습니다

기존 폴더/견적기준.md옵시디언 폴더/견적기준_복사본.md

이렇게 복사하면 병윤님 말씀대로 문제가 생깁니다.

• 같은 내용을 중복으로 읽을 수 있음
• 한쪽만 수정돼 내용이 달라질 수 있음
• 어느 쪽이 최신 기준인지 헷갈릴 수 있음

추천하는 구조는 기존 문서 한 벌을 클로드와 Obsidian이 함께 사용하는 것입니다. Obsidian을 쓴다는 이유만으로 모델이 파일을 두 번 읽어야 하는 것은 아닙니다.

그럼 기존 memory.md도 그대로 두나요?

네. 다만 내용이 많아지면 역할을 나눌 수는 있습니다.

memory.md→ 꼭 알아야 할 핵심 요약→ 자세한 내용이 있는 파일의 위치
견적기준.md→ 상세 견적 규칙
시공노하우.md→ 상세 시공 지식

이때도 같은 규칙 전문을 모든 파일에 반복해서 적기보다, 핵심 요약과 상세 문서를 연결하는 방식이 좋습니다. 실제로 무엇을 읽게 할지는 클로드의 작업 규칙으로 정해야 하고요.

정리하면, 기존 MD를 버리거나 Obsidian용으로 한 벌 더 만들 필요가 없습니다. 기존 파일을 Obsidian으로 보기 시작하고, 필요하면 그 안의 정리 방식을 개선하는 겁니다.

요청하신 폴더에 기존 손필기 스타일로 만들어 저장했습니다.

• 필기노트 열기 · HTML [blocked]
• 같은 내용의 MD [blocked]

총 12개 장에 두 주제의 기본 5문항, 이번 대화의 추가 질문 6개, 도식과 복습 문제를 담았습니다.

추가 질문은 질문기록에도 모았고, 기존 파일은 보존했습니다. PC·휴대폰 화면과 복습 버튼도 확인했습니다.

[Image blocked: 완성된 필기노트]