11월 5일 학습일지

총학습시간 : 3시간 (본업,치과치료,아기 컨디션 난조..)

AI 꼬리질문
https://share.aside.com/s/lZnNHLpaqh9Ubmmy

-LLMWIKI 와 옵시디언 복습 및 꼬리질문-

Q1.스키마에 대해 쉽게 설명해줘

쉽게말해 정보를 어떤 틀(형식) 으로 정리할지 정해 놓은 설계도

예를들어 , 건설현장에 현장관리대장 양식 이라고 생각하면된다.

양식없이 직원들이 마음대로 적으면

누구는 현장이름만 , 누구는 자재와 수량만 , 누구는 금액만 적는 상황이 나온다.

이를 방지하기위해

"이 대장에는 현장명,사용자재,수량,시공일,특이사항을 순서대로 적어주세요 ,단위도함께"

이런식으로 규칙을 정해놓는 것이 스키마 이다.

lllm위키에서는

시공현장 하자사례를 예로들어 설명해보면,

어디에 저장? ->하자사례 폴더

무엇을 적어? -> 증상, 원인, 조치 , 근거자료

모르는 내용은? -> 추측해서 채우지말고 "미확인" 표시해

새 사실이 확인되면? -> 기존 설명을 고치고 관련문서도 연결해

이런식으로 어떤 내용을 담는 정해진 틀을 스키마라고 한다.

Q2. Query는 누가 누구에게 질문을 한다는건지 안와닿아

Query는 사람이 질문하고, AI가 정리된 지식을 찾아 답하는 과정을 뜻한다.

위키는 질문을 받고 말하는 상대가 아니라, Ai가 찾아보는 자료집이다.

ingest : "이 자료를 읽고 정리해 줘"

Query : "정리해 둔 자료를 보고 이것 좀 알려줘"

lint : "정리된 내용에 모순이나 빠진게 없는지 점검해 줘"

자료넣기 -> 꺼내 물어보기 -> 장정리되고있는지 점검하기

Q3. "백링크"에 대해 쉽게 설명해줘

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

<링크>

A현장 시공기록에 이렇게 적는다.

사용자재: 대리석1번

여기서 대리석1번을 누르면 대리석1번 자재설명 문서로 이동한다.

<백링크>

반대로 대리석1번 문서를 열면?

백링크에는 아래와 같이 표시된다.

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

나중에 B현장시공기록에도 같은 링크를 넣으면 대리석1번 문서의 백링크에서

A현장과 B현장 기록을 모두 찾을수 있다.

핵심은 대리석1번 문서에 현장목록을 일일이 적지 않아도 옵시디언이 들어오는 연결을 찾아 보여준다는 것이다.

링크 : 이 문서에서 어디로 갈 수 있지?

백링크: 어떤 문서에서 이 문서로 연결해 뒀지?

그래서 거꾸로도 찾아가기 편해진다.

Q4.옵시디언을 사용했을때 마크다운으로 저장된 파일의 내용들 중간중간 단어에 나무위키처럼 하이퍼택스트로 링크를 건다는거야?

-맞다. 옵시디언의 읽기화면에서는 링크가 대괄호 대힌 클릭할수 있는 링크로 보인다.

다만, 옵시디언을 설치한다고 모든 단어에 자동으로 링크가 생기는건 아니다.

사람이 대괄호안에 문서이름을 적거나, [[문서 이름]]

Ai에게 관련 문서 링크를 넣도록 시켜야 한다.

Q5. 임베딩 쉽게 설명해줘

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

우리 회사 하자기록으로 생각해보면

A기록: “대리석 상판에 커피 자국이 남았다.”

B기록: “주방 천연석에 음료 얼룩이 생겼다.”

C기록: “현관 타일이 깨졌다.”

시람은 A와 B가 비슷한 이야기라는걸 한번에 안다.

사용한 단어는 달라도 둘다 "석재 표면에 생긴 얼륙"에 관한 내용이니까.

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

링크가 문서끼리 직접 연결하는것이라면 ,

임배딩은 "직접 연결하지 않은 문서도 의미가 비슷한지 비교할 수 있게 하는것" 이다.

Q6.그럼 그 숫자묶음이 좌표 개념인가?

맞다. 임베딩은 글의 특징을 담기위해 수백~수천개로 된 좌표를 쓰기도 한다.

이 숫자 묶음을 "벡터" 라고 한다.

의미가 비슷한 글 → 좌표가 가깝거나 방향이 비슷함

의미가 다른 글 → 좌표가 멀거나 방향이 다름

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

Q6. 그럼 위키는 rag 방식으로 필요한 자료를 찾는게 아니야?

위키에서도 RAG방식으로 필요한 자료를 찾을수 있긴하다. 둘이 서로 반대되는 개념은 아니다.

RAG가 꼭 임배딩으로만 검색하는건 아니다.

키워드 검색이나 목차,링크를 따라 관련 자료를 찾는 방식도 활용한다.

위키: 지식을 정리하고, 연결하고, 새 정보에 맞게 고쳐 두는 방식

RAG: 질문에 필요한 자료를 찾아서 AI의 답변에 활용하는 방식

임베딩: 자료를 찾을 때 의미가 비슷한지 비교하기 위해 쓸 수 있는 기술

예를들어 "대리석 김치 얼룩은 어떻게 처리해?" 라고 물으면

평소 하자 사례와 처리법을 정리·연결해 둔 곳이 위키.

AI가 거기서 관련 기록을 찾아 읽고 답하면 RAG 방식.

그때 ‘커피 자국’과 ‘음료 얼룩’처럼 표현이 다른 자료도 찾으려고 임베딩을 활용.

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

Q7.쉽게 표현하자면

llm위키는 내옆에 따라다니면서 내 일거수일투족, 그날의 일을

일목요연하게 필요한 위치에 나중에 찾기 쉽도록 저장을해주는

비서직원인거고,

옵시디언은 기록을 읽고, 검토하기 쉽게 해주는

또다른 직원인건가?

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

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

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

비서가 정리한 똑같은 MD 파일을 내가 읽고, 수정하고, 연결을 따라가며 검토하는 도구

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

Q8.그럼 옵시디언 없이 llm위키만으로 구조를 옵시디언 썼을때랑 똑같이 가져갔을떄랑

옵시디언 이라는 작업대를 썼을때의 차이가 뭐야?

한마디로, 내가 자료를 직접 보는 편의성의 차이이다. Ai가 더 똑똑해 지는건 아니다.

같은 서류를 파일철에 그대로 두느냐. 찾아보기 편한 작업대에 정리해두느냐 차이.

옵시디언 없이 쓰면

무언가를 찾기위해 메모장이나 다른 편집기로 MD파일을 열면 된다.

다만 사용하는 프로그램에 따라 [[문서A]]가 클릭되는 링크가 아니라 글자 그대로 보일수도 있다.

옵시디언을 쓰면

Ai에게 물어보지 않고도 내 자료 사이를 직접 돌아다니기 편해진다.

정리하면, AI에게 물어서 꺼내 보는 게 중심이면 옵시디언 없이도 충분하고,

내가 직접 읽고 연결을 살피며 검토하려면 옵시디언이 편해지는 것이다.

설치 자체가 기록의 정확성이나 AI의 검색 능력을 높여 주는 건 아니다.

Q9. 옵시디언 부터 링크가 쓰이는거지? 위키자체로는 링크가 없고?

아니다. 위키 자체에도 링크가 있다.

[[문서A]] <- 이게 파일안에 다른 문서로 연결한믄 표시가 들어있는 것이다.

꼭 옵시디언이 있어야만 표시를 적을수 있는건 아니다.

같은 파일을 어디서 여느냐에 따라 달라지는것이다.

메모장: [[문서A]]라는 글자가 그대로 보임

옵시디언: ‘칼라카타’를 클릭해서 해당 노트로 이동할 수 있음

AI: 파일을 읽고 이 표시가 가리키는 관련 문서를 찾아볼 수 있음

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

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

Q10. llm 위키 방식으로 업무를 하던사람이

옵시디언이라는 도구를 쓰면

어느부분에서 어떤차이가 발생하냐가 계속크게 안와닿아

계속 그럼 llm위키 만으로도 되는거 아니야?

라는 의문이 지워지질않아

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

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

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

Q11. 그럼 나같은 사람이 옵시디언을 써야하는 이유를

너가 옵시디언 파는 사람이라고 가정하고

나한테 옵시디언을 팔아봐 .

대체 어느부분에서 내가 이득을 보는건지

구조적으로 쉽게 이해가 가도록 (이 컨셉은 AI 질문과 답변 그대로 필사)

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

“대표님, 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에게 맡긴 지식을 더 쉽게 들여다보고 관리할 수 있습니다”라고 팔겠어요.

Q12. 결국 조회의 편리함인대,

왜 사람들은 세컨드브레인이라고 부르지?

맞다. 내말대로 그 역할은 옵시디언 없이 LLM위키로도 할수있다.

오히려 잘 운영된 LLM위키가 이미 세컨드 브레인 역할을 하고 , 옵시디언은 사람이 그 지식을 직접

살펴보고 생각을 이어가기 위한 창이다.

Q13.그럼 처음 html문서를 웹으로 주고받던 방식에서

브라우저가 나타난것처럼 위키가 html이면

옵시디언이 브라우저 이런느낌인가?

맞다.

키를 이루는 MD 파일들 ↔ 링크로 연결된 HTML 문서들

옵시디언 ↔ 그 문서들을 읽고 돌아다니는 브라우저

AI ↔ 문서를 작성하고 연결하고 갱신하는 담당자

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

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

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

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

Q14. 앱이나 서비스를 개발하는과정에서 일어나는 시행착오들은

위키에 어떤부분이 저장되지?

git과 git허브와 역할을 나눠서

코드가 아닌 부분만 저장하나?

대체로 코드는 Git으로 관리하고, 시행착오에서 얻은 지식은 위키에 남기면 된다.

다만 정확한 기준은 ‘코드냐 아니냐’보다 ‘무엇을 남기려는가’이다.

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

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

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

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

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

Q15. qmd가 뭐야?

qmd는 ‘내 컴퓨터에 저장된 MD 문서들을 찾아주는 검색 도구’

이름은 Query Markup Documents이고, 키워드 검색과 의미 검색 등을 지원한다.

LLM 위키: 자료를 정리·연결해서 관리하는 방식

옵시디언: 사람이 그 자료를 펼쳐 보는 도구

qmd: 자료가 많을 때 필요한 문서를 찾아주는 검색 담당

AI: 찾은 자료를 읽고 판단해서 답하는 담당

앞에서 배운 임베딩도 qmd가 의미가 비슷한 자료를 찾을 때 사용하는 기술이다.

qmd는 정확한 단어를 찾는 검색과 임베딩 기반 의미 검색을 함께 활용하고,

결과의 관련도를 다시 평가할 수 있다.

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

Q16. md는 기본적으로 어디에 깔려있는거야?

옵시디언은 다운받으면 거기에 깔려있는거야? 아니면 따로 플러그인처럼 받아야되는거야?

qmd는 옵시디언에 기본으로 들어 있지 않다.

별도로 설치하는 독립 프로그램이다.

각각 어디에 설치되는가?

옵시디언: 내 컴퓨터에 설치하는 노트 앱

qmd: 내 컴퓨터에 따로 설치하는 문서 검색 프로그램

MD 파일들: 두 프로그램이 읽을 수 있는 내 문서 폴더

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

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

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

qmd 설치

“이 폴더의 문서들을 검색해”라고 등록

AI가 qmd를 사용할 수 있도록 연결

AI는 명령어로 qmd를 실행하거나 MCP라는 연결 방식을 통해 검색을 요청할 수 있다.

설치만 한다고 모든 AI가 자동으로 쓰는 건 아니다.

옵시디언에는 자체 검색 기능이 있다. 그 기본 검색과 qmd는 별개다.

따라서 지금은 옵시디언만 쓰고, 나중에 AI가 많은 문서에서 필요한 내용을 찾는 데 더 나은 검색이 필요할 때 qmd를 추가해도 된다.


잘한점 :
어제 공부하면서 머리에 잘 들어오지 않은거같아서 꼼꼼히 다시 읽어보면서
계속 꼬리질문을 하며 깊게 파보니 이제 진짜 핵심이 이해가 되었다.


못한점:
이론공부에 치중하다보니 실제로 해보는건 아직 계획대로 시도해보진 못했다.

총평: 어떻게든 시간내서 더 집중해서 해보자.
Ai가 답변을 준내용을 이해됐다고 판단 되더라도
내 식대로 다시 받아적어보는게 확실히 머리에 잘 들어온다는 경험이 좋았다.
꼭 5가지 질문이 아니어도
Ai와 나눈 대화에서 얻은 답도 직접 내식대로 다시 옮겨 적어보는게
집중도 잘되고 머리에도 잘들어온다는걸 느꼈다.