스키마 쉽게 설명하기

스키마(schema)는 쉽게 말해 ‘정보를 어떤 틀로 정리할지 정해 놓은 설계도’예요.

대표님 회사의 현장 관리대장 양식을 생각하면 쉬워요.

현장마다 직원들이 제각각 적으면,

• 누구는 현장 이름만 적고
• 누구는 자재와 수량을 적고
• 누구는 금액만 적겠죠.

나중에 모아 보면 비교하거나 빠진 내용을 찾기가 어려워요.

그래서 미리 이렇게 정하는 거예요.

“현장 기록에는 현장명, 사용 자재, 수량, 시공일, 특이사항을 꼭 적자. 수량 단위도 함께 적자.”

이렇게 정해 놓은 항목과 규칙이 스키마예요.
그 틀에 맞춰 적은 ‘A현장, 대리석, 20㎡…’는 실제 데이터고요.

지금 보고 있는 LLM 위키에서는?

노트에서는 스키마를 조금 넓게 써서 ‘AI가 자료를 정리하는 구조와 작업 규칙’이라는 뜻으로 설명하고 있어요.

예를 들어 하자 사례를 정리한다면:

• 어디에 둘까? → 하자사례 폴더
• 무엇을 적을까? → 증상, 원인, 조치, 근거 자료
• 모르는 내용은? → 추측해서 채우지 말고 ‘미확인’ 표시
• 새 사실이 확인되면? → 기존 설명을 고치고 관련 문서도 연결

엄밀하게는 폴더·항목 같은 정리 틀이 스키마, 갱신·검토 방법은 운영 규칙인데, 지금 노트에서는 둘을 묶어서 다루는 거예요.

한 줄로 기억하면: 자료가 내용물이라면, 스키마는 그 내용을 담는 정해진 틀이에요.

여기서 Query는 대표님이 AI에게 질문하는 것이에요. AI가 누구에게 다시 질문한다는 뜻은 아니에요.

예를 들면 이렇게 흘러가요.

① 대표님이 AI에게 질문해요.

“전에 대리석 상판에 얼룩 생겼던 현장, 어떻게 해결했지?”

② AI가 위키에서 관련 기록을 찾아 읽어요.

하자 사례와 조치 기록을 찾아서 확인해요.

③ AI가 그 기록을 근거로 대표님께 답해요.

“해당 현장 기록에는 이렇게 조치했다고 적혀 있어요.”

즉, 이 노트의 Query는 ‘사람이 질문하고, AI가 정리된 지식을 찾아 답하는 과정’을 말해요. 위키는 질문받고 말하는 상대가 아니라, AI가 찾아보는 자료집이고요.

앞의 세 가지를 같은 관점으로 보면 더 쉬워요.

• Ingest: “이 자료 읽고 정리해 둬.”
• Query: “정리해 둔 자료를 보고 이것 좀 알려줘.”
• Lint: “정리된 내용에 모순이나 빠진 게 없는지 점검해 줘.”

자료 넣기 → 꺼내 물어보기 → 잘 정리됐는지 점검하기, 이렇게 생각하면 돼요.

백링크는 ‘지금 보고 있는 문서를 다른 어떤 문서가 연결해 뒀는지’ 보여 주는 기능이에요.

대표님 업무로 예를 들면요.

① 「A현장 시공 기록」에 이렇게 적어요.

사용 자재: [[칼라카타]]

여기서 ‘칼라카타’를 누르면 「칼라카타」 자재 설명 문서로 이동해요. 이게 일반적인 링크예요.

② 반대로 「칼라카타」 문서를 열면?

백링크에 이렇게 표시되는 거예요.

이 문서를 연결한 문서: A현장 시공 기록

나중에 B현장 기록에도 같은 링크를 넣으면, 칼라카타 문서의 백링크에서 A현장과 B현장 기록을 모두 찾을 수 있어요.

핵심은 칼라카타 문서에 현장 목록을 일일이 적지 않아도, Obsidian이 들어오는 연결을 찾아 보여 준다는 거예요.

• 링크: “이 문서에서 어디로 갈 수 있지?”
• 백링크: “어떤 문서에서 이 문서로 연결해 뒀지?”

그래서 자재 설명을 보다가 그 자재를 사용했다고 연결해 둔 현장 기록까지 거꾸로 찾아가기 편해져요.

네, 정확히 그렇게 이해하시면 돼요. 나무위키처럼 글 중간의 단어를 눌러 관련 문서로 이동하는 거예요.

예를 들어 A현장.md 파일에 이렇게 적어요.

이번 주방 상판에는 [[칼라카타]]를 사용했다.시공 중 발생한 얼룩은 [[대리석 얼룩 제거법]]을 참고해 처리했다.

Obsidian의 읽기 화면에서는 대괄호 기호 대신 ‘칼라카타’와 ‘대리석 얼룩 제거법’이 클릭할 수 있는 링크로 보여요. 누르면 각각 연결된 노트로 이동하고요.

다만 Obsidian을 설치한다고 모든 단어에 자동으로 링크가 생기는 건 아니에요. 사람이 [[문서 이름]]을 적거나, AI에게 관련 문서 링크를 넣도록 시키는 거예요.

그리고 「칼라카타」 노트에서 “나를 연결한 문서가 뭐지?” 하고 확인하는 것이 앞서 말한 백링크예요.

임베딩은 글이나 사진의 특징을 숫자로 바꿔서, 서로 얼마나 비슷한지 비교할 수 있게 만드는 거예요.

대표님 회사의 하자 기록으로 생각해 볼게요.

• A기록: “대리석 상판에 커피 자국이 남았다.”
• B기록: “주방 천연석에 음료 얼룩이 생겼다.”
• C기록: “현관 타일이 깨졌다.”

사람은 A와 B가 비슷한 이야기라는 걸 알죠. 사용한 단어는 달라도 둘 다 ‘석재 표면에 생긴 음료 얼룩’에 관한 내용이니까요.

컴퓨터도 이런 비슷함을 비교할 수 있도록, 임베딩 모델이 각 글을 여러 숫자로 이루어진 묶음으로 바꿔요.

‘의미 지도에 주소를 붙인다’고 생각하면 쉬워요

비유하자면,

• A와 B는 얼룩 동네의 가까운 곳에
• C는 파손 동네의 다른 곳에 놓는 거예요.

실제로는 평면 지도보다 훨씬 복잡한 숫자 공간이지만, 비슷한 내용끼리 가까워지도록 표현한다는 게 핵심이에요.

그래서 어디에 쓰냐면요

대표님이 AI에게 이렇게 물어요.

“상판에 커피 쏟았을 때 어떻게 했지?”

질문도 임베딩으로 바꿔서 저장된 기록들과 비교하면, ‘커피’라는 단어가 없는 B기록도 관련 자료로 찾아낼 수 있어요. 정확히 같은 단어뿐 아니라 비슷한 의미로 찾는 거죠.

다만, 의미가 비슷하다고 정답인 건 아니에요. 찾은 자료가 실제 상황에 맞는지는 따로 확인해야 해요.

링크가 ‘이 문서와 저 문서를 직접 연결하는 것’이라면, 임베딩은 ‘직접 연결하지 않은 문서도 의미가 비슷한지 비교할 수 있게 하는 것’이에요.

네, 좌표 같은 개념이 맞아요. 제가 앞에서 말한 ‘의미 지도상의 주소’가 바로 그 좌표예요.

일반 지도는 위치를 (가로, 세로)처럼 숫자 2개로 나타내죠. 임베딩은 글의 특징을 담기 위해 숫자 수백~수천 개로 된 좌표를 쓰기도 해요. 이 숫자 묶음을 벡터라고 불러요.

그래서 보통:

• 의미가 비슷한 글 → 좌표가 가깝거나 방향이 비슷함
• 의미가 다른 글 → 좌표가 멀거나 방향이 다름

다만 “첫 번째 숫자는 자재 종류, 두 번째는 얼룩 정도”처럼 각 숫자의 뜻이 사람이 알아보기 쉽게 정해진 건 아니에요. 모델이 학습한 특징들이 여러 숫자에 나뉘어 담겨 있어요.

즉, 임베딩은 ‘글의 의미나 특징을 복잡한 좌표로 표현하는 것’이라고 이해하시면 돼요.

맞아요. 위키에서도 RAG 방식으로 필요한 자료를 찾아 답할 수 있어요. 둘이 서로 반대되는 개념은 아니에요.

제가 임베딩을 설명하면서 헷갈리게 연결한 부분이 있는데, RAG가 꼭 임베딩으로만 검색하는 건 아니에요. 키워드 검색이나 목차·링크를 따라 관련 자료를 찾는 방식도 활용할 수 있어요.

각각 맡는 일이 달라요.

• 위키: 지식을 정리하고, 연결하고, 새 정보에 맞게 고쳐 두는 방식
• RAG: 질문에 필요한 자료를 찾아서 AI의 답변에 활용하는 방식
• 임베딩: 자료를 찾을 때 의미가 비슷한지 비교하기 위해 쓸 수 있는 기술

예를 들어 대표님이 “대리석 커피 얼룩은 어떻게 처리해?”라고 물으면요.

1. 평소 하자 사례와 처리법을 정리·연결해 둔 곳이 위키예요.
2. AI가 거기서 관련 기록을 찾아 읽고 답하면 RAG 방식이에요.
3. 그때 ‘커피 자국’과 ‘음료 얼룩’처럼 표현이 다른 자료도 찾으려고 임베딩을 활용할 수 있어요. 꼭 써야 하는 건 아니고요.

위키는 ‘잘 정리해 둔 자료집’, RAG는 ‘그 자료집에서 찾아보고 답하는 과정’이라고 구분하면 돼요.

네, 큰 흐름은 잘 잡으셨어요. 다만 비유를 조금만 다듬으면 더 정확해요.

LLM 위키는 ‘기록을 관리하는 비서의 업무 방식’

실제 비서 역할은 클로드 같은 AI가 하고, LLM 위키는 그 비서가 자료를 정리·관리하는 방식이에요.

단순히 그날 일을 날짜별로 적는 데서 끝나지 않고,

“오늘 확인한 하자 원인은 하자 사례에 넣고, 기존 시공 주의사항도 고쳐 두자.”

이렇게 관련된 곳에 정리하고, 연결하고, 오래된 내용도 갱신하는 거예요.

다만 일거수일투족을 저절로 아는 건 아니고, 대표님이 알려주거나 접근을 허용한 자료 안에서 일해요. 모든 일을 무조건 저장하는 것도 아니고요.

옵시디언은 ‘직원’보다는 ‘문서를 펼쳐 보는 작업대’

비서가 정리한 똑같은 MD 파일을 대표님이 읽고, 수정하고, 연결을 따라가며 검토하는 도구예요.

스스로 사실관계를 판단해 검토하는 또 다른 직원은 아니에요. 대표님이 검토하기 편하도록 보여 주는 쪽이죠.

한 문장으로 정리하면:

“AI 비서가 LLM 위키 방식으로 서류를 관리하고, 나는 옵시디언이라는 작업대에서 그 서류를 펼쳐 보고 확인한다.”

구조와 내용이 똑같다면, 차이는 주로 ‘대표님이 그 자료를 직접 보는 편의성’이에요. AI가 갑자기 더 똑똑해지는 건 아니고요.

같은 서류를 파일철에 그대로 두느냐, 찾아보기 편한 작업대에 펼쳐 놓느냐의 차이에 가까워요.

옵시디언 없이 쓰면

AI에게 이렇게 요청하면서 활용할 수 있어요.

“칼라카타 관련 기록 찾아줘.”
“이 자재를 사용한 현장들을 알려줘.”

직접 확인하려면 메모장이나 다른 편집기로 MD 파일을 열면 돼요. 다만 사용하는 프로그램에 따라 [[칼라카타]]가 클릭되는 링크가 아니라 글자 그대로 보일 수 있고, 나를 연결한 문서도 따로 찾아야 해요.

옵시디언을 쓰면

AI에게 물어보지 않고도 대표님이 자료 사이를 직접 돌아다니기 편해져요.

• 글 속 칼라카타 링크를 눌러 자재 설명으로 이동
• 백링크에서 그 자재를 연결한 현장 기록 확인
• 검색으로 필요한 기록 찾기
• 제목·목록 등이 정돈된 화면에서 읽고 바로 수정

다른 편집기도 일부 기능을 제공하지만, 옵시디언은 이런 연결된 노트 탐색 기능을 한곳에 모아 둔 도구예요.

정리하면, AI에게 물어서 꺼내 보는 게 중심이면 옵시디언 없이도 충분하고, 대표님이 직접 읽고 연결을 살피며 검토하려면 옵시디언이 편해지는 거예요. 설치 자체가 기록의 정확성이나 AI의 검색 능력을 높여 주는 건 아니에요.

아니에요. 위키 자체에도 링크가 있어요. 제가 앞에서 옵시디언의 편의성을 설명하다 보니 헷갈리게 말씀드렸네요.

예를 들어 AI가 A현장.md에 이렇게 저장해 둬요.

이번 현장에는 [[칼라카타]]를 사용했다.

이때 이미 파일 안에 다른 문서로 연결하는 표시가 들어 있는 거예요. 옵시디언이 있어야만 이 표시를 적을 수 있는 건 아니에요.

같은 파일을 어디에서 여느냐에 따라 달라지는 거죠.

• 메모장: [[칼라카타]]라는 글자가 그대로 보임
• 옵시디언: ‘칼라카타’를 클릭해서 해당 노트로 이동할 수 있음
• AI: 파일을 읽고 이 표시가 가리키는 관련 문서를 찾아볼 수 있음

물론 AI가 실제로 링크를 따라 읽도록 하는 설정이나 지침은 필요해요.

위키에 연결을 기록해 두고, 옵시디언은 그 연결을 사람이 클릭하고 살펴보기 편하게 보여 준다, 이렇게 이해하시면 정확해요.

옵시디언은 ‘파일을 찾아서 열고, 관련 문서를 다시 찾는 수고’를 줄여 줘요. 제가 계속 작업대라고만 해서 구체적으로 와닿지 않았을 거예요.

같은 파일이 100개 있다고 생각해 볼게요.

1. 기호로 적힌 글을 읽기 편하게 보여 줘요

MD 파일에는 이렇게 저장돼 있어요.

# A현장사용 자재: [[칼라카타]]- 주방 상판 시공- 얼룩 주의

옵시디언은 읽기 화면에서 이걸 큰 제목, 클릭할 수 있는 링크, 정돈된 목록으로 보여 줘요. 파일 내용이 바뀌는 게 아니라, 읽기 좋게 표현하는 거예요.

2. 관련 파일을 폴더에서 다시 찾지 않아도 돼요

A현장 기록을 보다가 자재가 궁금하면 ‘칼라카타’를 클릭하면 돼요.

탐색기 열기 → 자재 폴더 찾기 → 칼라카타 파일 찾기 → 열기

이 과정을 클릭 한 번으로 줄여 주는 거예요.

3. 반대쪽 연결은 직접 목록을 만들지 않아도 보여 줘요

칼라카타 설명을 보다가,

“이 자재와 연결된 현장 기록이 뭐가 있지?”

싶으면 백링크를 확인해요. 옵시디언이 파일들을 살펴서 이 노트를 연결한 문서 목록을 보여 줘요.

단, 실제로 사용한 모든 현장을 알아내는 건 아니고, 링크를 걸어 둔 기록을 보여 주는 거예요.

4. 여러 문서를 한곳에서 검색하고 비교해요

전체 노트에서 ‘얼룩’이 들어간 내용을 검색하거나, 현장 기록과 시공 기준을 나란히 열어서 읽고 수정할 수 있어요.

즉, AI가 정리해 놓은 글을 ‘그냥 파일 더미’가 아니라 ‘클릭하며 돌아다닐 수 있는 내 업무 위키’처럼 이용하게 해 주는 거예요.

대표님이 항상 AI에게 물어서 답만 받는다면 필요성이 작고, 직접 기록을 펼쳐 보고 근거와 연결을 확인하려면 편리함이 커져요.

맞아요. 옵시디언 없이 LLM 위키만으로도 됩니다.
그 의문이 남는 건 이해를 못 하셔서가 아니라, 대표님이 생각하는 업무에는 실제로 옵시디언이 필수가 아니기 때문이에요. 제가 자꾸 장점을 설명하느라 큰 변화가 있는 것처럼 느끼게 했네요.

대표님이 이렇게 일한다면 차이가 거의 없어요

“이 자료 정리해 둬.”
“지난번 하자 어떻게 해결했지?”
“새 기준으로 기존 문서도 수정해 줘.”

AI에게 말하고, AI가 파일을 관리하고, 답을 받는 방식이죠.

이 흐름은 옵시디언 없이도 가능해요. 옵시디언을 설치해도 답변이 저절로 더 정확해지거나, 기록이 더 잘 쌓이는 건 아니에요.

차이는 ‘대표님이 직접 문서를 다루는 순간’에 생겨요

예를 들어 AI가 이렇게 답했다고 해볼게요.

“칼라카타 관련 하자 기록은 A·B·C현장에 있습니다.”

여기서 두 갈래로 나뉘어요.

① 계속 AI에게 맡기기

“세 현장 기록 보여줘. 차이도 비교해 줘.”

이렇게 하면 되니 옵시디언이 없어도 불편하지 않을 수 있어요.

② 내가 직접 펼쳐 보기

“AI가 요약한 것 말고, 기록을 직접 읽고 여기저기 살펴보면서 고치고 싶어.”

이때 옵시디언이 편해져요. 문서를 나란히 열고, 자재 링크를 누르고, 연결된 현장을 살펴보고, 그 자리에서 수정할 수 있으니까요.

하지만 이것도 옵시디언만 가능한 일은 아니에요. 다른 편집기나 잘 만든 열람 화면으로도 할 수 있어요.

그래서 대표님에게는

지금처럼 AI에게 지시하고 답받는 것이 중심이라면, 일단 LLM 위키만으로 운영하셔도 돼요.

그러다가 “내가 직접 문서를 찾아 읽고 고치기에는 불편하네”라는 문제가 생기면 옵시디언을 붙이면 돼요. 같은 MD 폴더를 열면 되므로 처음부터 꼭 함께 시작할 필요도 없고요.

옵시디언은 LLM 위키를 완성시키는 필수 부품이 아니라, 사람이 그 위키를 직접 다루기 위한 선택 도구예요.

제가 옵시디언을 파는 사람이라면, 대표님께 이렇게 말씀드릴 거예요.

“대표님, AI 비서를 한 명 더 드리는 게 아닙니다.
AI 비서가 관리하는 업무 자료를 대표님이 직접 펼쳐 보고 통제할 수 있는 화면을 드리는 겁니다.”

왜 이게 이득인지, 대표님 업무로 설명해 볼게요.

1. 지금 방식은 ‘비서에게 물어서 확인하는 구조’예요

대표님이 AI에게 말해요.

“이번 A현장은 양중비를 견적에 포함해.”

AI가 이 내용을 파일에 저장해요. 설명을 위한 가상 사례예요.

나중에 제대로 저장했는지 확인하려면 다시 물어보죠.

“A현장 조건 어떻게 기록했어?”
“회사 전체 기준으로 넣은 건 아니지?”
“관련 견적 기준도 보여줘.”

기록한 직원에게, 그 직원이 제대로 기록했는지 설명까지 듣는 구조예요.

이 방식도 충분히 쓸 수 있어요. 다만 대표님은 주로 AI가 골라 보여 주는 답변을 보게 돼요.

2. 옵시디언을 쓰면 ‘실제 관리대장을 직접 보는 구조’가 추가돼요

AI가 작업하는 방식은 그대로예요. 달라지는 건 대표님 쪽이에요.

대표님이 실제 문서를 열어서 확인해요.

• A현장 기록: 양중비 포함
• 적용 범위: A현장만 해당
• 회사 견적 기준: 기존 기준 유지
• 근거: 해당 지시나 자료로 연결

그리고 잘못 적힌 부분이 있으면 그 자리에서 수정해요.

AI의 보고를 듣는 것과, AI가 작성한 실제 관리대장을 펼쳐 보는 것은 다르죠.

옵시디언은 그 관리대장을 읽고, 관련 장부로 이동하고, 수정하기 편하게 해 주는 도구예요. 내용의 정확성은 여전히 사람이 확인해야 하고요.

3. 대표님이 얻는 이득은 세 가지예요

① “어떻게 저장했어?”를 반복해서 물을 일이 줄어요

AI에게 매번 문서를 출력해 달라고 하지 않고, 자주 확인하는 기준서를 직접 열어 둬요.

대화로 확인하는 절차 일부를 문서 열람으로 바꾸는 이득이에요.

단, 가끔 한두 번 확인하는 정도라면 차이가 작아요. 같은 기준서를 자주 확인할수록 도움이 되는 거죠.

② 대표님의 노하우가 ‘채팅 답변’이 아니라 ‘꺼내 읽는 업무책’이 돼요

대표님은 AI에게 단순한 질문만 하는 게 아니잖아요.

• 시공·견적 기준
• 하자 사례와 조치
• 제품 설명과 근거
• SNS 문체와 사진 사용 기준

이런 지식을 계속 알려 주고 계세요.

LLM 위키가 이것들을 정리해 둔다면, 옵시디언은 대표님이 ‘견적 기준’ 문서를 열고 관련 사례까지 직접 따라 읽는 업무책의 열람 화면이 되는 거예요.

AI에게 잘 물어봐야 꺼낼 수 있는 지식을, 내가 직접 훑어볼 수도 있게 만드는 이득이에요.

③ AI를 바꿔도 ‘내가 자료를 보는 방식’은 유지할 수 있어요

파일을 소유하는 장점은 원래 MD 기반 위키에 있어요. 옵시디언만의 장점은 아니에요.

여기에 옵시디언을 붙이면 어떤 AI를 쓰든, 대표님이 같은 자료를 읽고 편집하는 창을 유지할 수 있어요.

비서가 바뀌어도 대표님 책상 위 관리대장은 그대로인 셈이죠.

4. 그래서 제가 대표님께 파는 건 이것입니다

“AI에게 일을 맡기면서도, 회사 지식이 어떻게 정리돼 있는지는 대표님 눈으로 직접 확인할 수 있는 편리함.”

메모장이나 다른 편집기로도 가능해요. 옵시디언은 문서 보기·검색·링크 이동·백링크 확인을 한곳에 모아서 그 수고를 줄이는 상품인 거죠.

대신 시작할 때는 사용법을 조금 익혀야 하고, 직접 열어보는 습관도 필요해요. 설치만 하고 계속 AI 답변만 읽는다면 대표님이 얻는 이득은 거의 없습니다.

제가 판매자라면 “AI가 더 똑똑해집니다”가 아니라, “대표님이 AI에게 맡긴 지식을 더 쉽게 들여다보고 관리할 수 있습니다”라고 팔겠어요.

맞아요. 옵시디언이라는 도구만 놓고 보면, 대표님 말씀처럼 조회·편집·연결의 편리함이 핵심이에요.

사람들이 ‘세컨드 브레인’이라고 부르는 건, 앱 자체가 뇌처럼 생각해서가 아니라 그 안에 지식을 쌓고 활용하는 방식까지 묶어서 말하기 때문이에요. 옵시디언만의 명칭도 아니고요.

뇌가 하는 일 중 일부를 바깥으로 옮긴다는 비유예요.

1. 기억을 대신 보관해요

“예전에 그 하자를 어떻게 처리했더라?”

머리로 전부 기억하지 않아도 기록에서 꺼낼 수 있어요. 여기까지는 일반 메모장도 해요.

2. 서로 다른 경험을 연결해요

A현장 하자 기록을 보다가 관련 자재, 시공법, B현장의 비슷한 사례로 이동해요.

“따로 겪은 문제인 줄 알았는데, 같은 조건에서 반복됐네?”

기록 하나를 찾는 데서 끝나지 않고, 기록 사이의 관계를 보면서 생각을 이어 가는 거예요. 옵시디언이 원인을 알아내는 건 아니고, 사람이 알아보기 쉽게 연결을 보여 주는 거죠.

3. 경험을 다음 판단의 기준으로 바꿔요

여러 사례를 비교한 뒤 이렇게 정리할 수 있어요.

“다음부터 이런 조건의 현장은 견적 전에 이 항목부터 확인하자.”

지난 경험이 단순한 보관 자료가 아니라 앞으로 판단할 때 쓰는 지식이 되는 거예요.

그래서 구분하면 정확해요.

• 기록을 저장하고 찾아보기만 하면: 편리한 자료함
• 기록을 연결하고 비교해 내 판단에 계속 활용하면: 사람들이 말하는 ‘세컨드 브레인’

그리고 대표님이 짚으신 대로, 그 역할은 옵시디언 없이 LLM 위키로도 할 수 있어요. 오히려 잘 운영된 LLM 위키가 이미 세컨드 브레인 역할을 하고, 옵시디언은 사람이 그 지식을 직접 살펴보고 생각을 이어 가기 편한 창인 거예요.

제가 앞에서 ‘옵시디언을 써야 얻는 이득’과 ‘지식을 잘 관리하면 얻는 이득’을 섞어서 설명한 부분이 있었어요. 둘은 구분하는 게 맞습니다.

네! 역할 관계로 보면 그 비유가 훨씬 잘 맞아요. 제가 말한 ‘작업대’보다 더 명확하네요.

조금만 정확하게 맞추면:

• 위키를 이루는 MD 파일들 ↔ 링크로 연결된 HTML 문서들
• 옵시디언 ↔ 그 문서들을 읽고 돌아다니는 브라우저
• AI ↔ 문서를 작성하고 연결하고 갱신하는 담당자

HTML 파일 안에 이미 내용과 링크가 있고, 브라우저는 그것을 읽기 좋게 보여 주고 클릭해서 이동하게 하죠.

마찬가지로 MD 파일 안에 이미 내용과 연결 표시가 있고, 옵시디언은 그것을 읽기 좋게 보여 주고 문서 사이를 이동하게 해 줘요. 추가로 직접 편집하거나 백링크를 확인하는 기능도 있고요.

그래서 “옵시디언이 지식을 만들어 주는 게 아니라, 이미 정리된 지식을 사람이 이용하기 편하게 해 주는구나”라고 이해하시면 돼요.

다만 역사 부분은 하나만 바로잡으면, 웹은 처음부터 HTML·HTTP·브라우저가 함께 만들어졌어요. ‘HTML만 주고받다가 나중에 브라우저가 등장했다’는 순서는 아니지만, 지금 말씀하신 역할 비유는 잘 맞습니다.

반영해뒀어요. 질문을 끝에만 붙이지 않고, 헷갈렸던 개념이 나오는 본문에 쉬운 예시와 비교를 넣었습니다.

• 앞부분: 위키 문서 ↔ HTML, 옵시디언 ↔ 브라우저 비유
• 각 설명 위치: 스키마·Query·링크·백링크·임베딩·RAG 보강
• 업무 적용 부분: 옵시디언 없이도 되는 일과, 쓸 때 편해지는 일 구분
• 세컨드 브레인의 의미와 한계 설명

손필기 HTML과 MD를 함께 수정했고, 오늘 개념 질문 15개도 기록했습니다. 기존 5문항 구성과 직접 작성하는 칸은 유지했어요. PC·모바일 표시도 확인했습니다.

[Image blocked: 보강한 손필기 노트]

대체로 코드는 Git으로 관리하고, 시행착오에서 얻은 지식은 위키에 남기면 돼요.
다만 정확한 기준은 ‘코드냐 아니냐’보다 ‘무엇을 남기려는가’예요.

1. Git은 “무엇을 어떻게 바꿨나”를 남겨요

• 어떤 파일의 어느 부분을 수정했는지
• 수정 전후 코드가 무엇인지
• 어느 시점의 상태로 되돌릴 수 있는지

쉽게 말하면 설계도와 시공 결과의 변경 이력이에요.

코드뿐 아니라 설명서·설정 파일·위키의 MD 파일도 Git으로 관리할 수 있어요.

2. GitHub는 “그 변경을 함께 관리하는 공간”이에요

Git 저장소를 올려 두고, 문제와 수정 작업을 연결해 관리해요.

• Issue: 어떤 문제나 할 일이 있는지
• PR: 어떤 변경을 제안했고, 무엇을 검토했는지
• 저장소: 코드·문서와 변경 이력 공유

즉, Git이 변경 이력을 관리하는 기술이라면, GitHub는 그 이력을 공유하며 협업하는 서비스예요.

3. 위키는 “왜 그랬고, 다음에는 어떻게 할까”를 남겨요

시행착오 중에서도 다음 작업에 다시 쓸 만한 내용을 정리해요.

• 어떤 조건에서 문제가 발생했나?
• 원인은 무엇으로 확인됐나?
• 무엇을 시도했고, 왜 실패했나?
• 최종적으로 어떤 방법이 해결했나?
• 다른 방법 대신 그것을 선택한 이유는?
• 다음부터 무엇을 확인하면 같은 실수를 막을까?
• 아직 해결하지 못했거나 검증하지 못한 것은?

Git의 변경 이력만 보고는 바로 알기 어려운 ‘판단과 배운 점’을 꺼내 보기 쉽게 만드는 거예요.

같은 시행착오를 나눠 저장하면

설명을 위한 가상 사례예요.

“PC에서는 저장 버튼이 보이는데, 모바일에서는 안 보였다.”

Git에 남는 것

버튼이 잘리던 화면의 CSS를 어떻게 수정했는지.

GitHub에 남는 것

문제 제보, 재현 화면, 수정 PR, 검토·테스트 결과.

위키에 남는 것

좁은 화면에서 부모 영역의 설정 때문에 버튼이 잘렸다.
버튼 크기만 줄여서는 해결되지 않았다.
부모 영역을 수정한 뒤 확인한 화면 크기에서는 해결됐다.
다음부터 모바일 화면은 버튼이 실제로 보이고 눌리는지 확인한다.
근거: 해당 Issue·PR·수정 커밋 링크.

여기서 위키는 모든 코드와 대화·오류 로그를 통째로 복제하는 곳이 아니에요. 필요한 설명을 정리하고, 상세 근거는 원래 기록으로 연결하면 돼요. 필요하다면 짧은 코드 예제도 넣을 수 있고요.

대표님 업무에 비유하면:

• Git: 도면 변경 이력
• GitHub: 변경 요청·검토·승인 기록을 함께 관리하는 공간
• 위키: “왜 이렇게 시공했고, 다음 현장에서는 무엇을 조심할지” 정리한 기술 노하우집

그리고 그 노하우집 자체도 Git으로 변경 이력을 관리하고 GitHub에 보관할 수 있어요. 서로 나눠 쓰되, 완전히 분리된 창고일 필요는 없는 거죠.

실제로 어떤 시행착오를 위키에 남길지는 AI의 정리 규칙을 정해야 해요. 위키 방식이라고 모든 실패가 자동으로 기록되는 건 아니에요.

반영했어요. ‘내 업무에 적용’ 부분에 다음을 추가했습니다.

• Git·GitHub·위키 역할 비교표
• 개발 시행착오에서 남길 내용과 가상 사례
• 코드와 문서를 엄격히 나누는 것은 아니라는 설명

HTML·MD를 함께 수정했고, 기존 질문기록에 16번 질문으로 추가했어요.

[Image blocked: 노트에 추가한 역할 비교표]

여기서 qmd는 ‘내 컴퓨터에 저장된 MD 문서들을 찾아주는 검색 도구’예요.
이름은 Query Markup Documents이고, 키워드 검색과 의미 검색 등을 지원해요.

대표님 회사로 비유하면 역할이 이렇게 나뉘어요.

• LLM 위키: 자료를 정리·연결해서 관리하는 방식
• 옵시디언: 사람이 그 자료를 펼쳐 보는 도구
• qmd: 자료가 많을 때 필요한 문서를 찾아주는 검색 담당
• AI: 찾은 자료를 읽고 판단해서 답하는 담당

예를 들어

대표님이 AI에게 물어요.

“예전에 모바일에서 저장 버튼 안 보이던 문제, 어떻게 해결했지?”

qmd를 연결해 뒀다면:

1. AI가 qmd에 관련 자료 검색을 요청해요.
2. qmd가 개발 기록에서 관련 문서나 구절을 찾아줘요.
3. AI가 그 기록을 읽고 해결 방법을 설명해요.

앞에서 배운 임베딩도 qmd가 의미가 비슷한 자료를 찾을 때 사용하는 기술이에요. qmd는 정확한 단어를 찾는 검색과 임베딩 기반 의미 검색을 함께 활용하고, 결과의 관련도를 다시 평가할 수 있어요.

다만 필수는 아니에요. 원문에서도 자료가 적을 때는 목차와 기본 검색으로 시작하고, 위키가 커지면 qmd 같은 검색 도구를 선택적으로 붙이도록 설명해요.

한 줄로 말하면: 옵시디언이 ‘문서를 보는 창’이라면, qmd는 ‘문서 더미에서 필요한 것을 찾아주는 검색기’예요.

qmd는 옵시디언에 기본으로 들어 있지 않아요. 별도로 설치하는 독립 프로그램이에요. 제가 그 부분을 먼저 구분했어야 했네요.

각각 어디에 설치되냐면요

• 옵시디언: 내 컴퓨터에 설치하는 노트 앱
• qmd: 내 컴퓨터에 따로 설치하는 문서 검색 프로그램
• MD 파일들: 두 프로그램이 읽을 수 있는 내 문서 폴더

즉, 옵시디언 안에 qmd가 들어가는 구조가 아니라, 두 프로그램이 같은 문서 폴더를 활용하는 구조예요.

옵시디언 플러그인으로 받는 건가?

qmd 자체는 옵시디언 플러그인이 아니에요. 공식 안내에서는 npm 같은 프로그램 설치 도구로 별도 설치하고, 검색할 폴더를 등록하도록 되어 있어요.

AI가 활용하게 하려면 연결도 따로 해요.

1. qmd 설치
2. “이 폴더의 문서들을 검색해”라고 등록
3. AI가 qmd를 사용할 수 있도록 연결

AI는 명령어로 qmd를 실행하거나 MCP라는 연결 방식을 통해 검색을 요청할 수 있어요. 설치만 한다고 모든 AI가 자동으로 쓰는 건 아니고요.

옵시디언에는 자체 검색 기능이 있어요. 그 기본 검색과 qmd는 별개예요. 따라서 지금은 옵시디언만 쓰고, 나중에 AI가 많은 문서에서 필요한 내용을 찾는 데 더 나은 검색이 필요할 때 qmd를 추가해도 됩니다.