🖼️ 4컷 인포그래픽

💡 한 줄 결론

이 영상은 LLM을 즉답형 챗봇으로 쓰는 대신, 문서와 논문을 계속 축적하고 다시 질문할 수 있는 개인용 연구 위키의 정리·연결 도구로 활용하자는 실무형 워크플로우를 설명한다.

📌 핵심 요점

1. 영상은 기존 LLM이 얕은 정보 요약에는 쓸 만하지만, 여러 아이디어를 비교하거나 깊이 있는 연구로 들어가면 구조와 일관성이 쉽게 무너진다는 한계를 먼저 제시한다.
2. 이에 대한 대안으로 Andre Karpathy의 게시물에서 출발한 LLM wiki 개념을 소개하며, 핵심은 질문 몇 번으로 끝나는 사용이 아니라 개인이 모은 자료를 지속적으로 축적하는 문서 중심 환경을 만드는 데 있다고 설명한다.
3. 구현 방식은 Obsidian vault를 만들고, 공개된 LLM-wiki 문서를 에이전트형 코딩 환경에 넣어 주제별 위키 골격을 세운 뒤, 기사와 PDF를 수집해 같은 위키 안으로 인덱싱하는 흐름으로 제시된다.
4. 이 워크플로우의 핵심 가치는 연구 판단 자체를 전부 자동화하는 데 있지 않고, 출처 선별과 질문 설계, 해석은 사람이 맡고 기록 정리, 연결, 인덱싱, 유지보수 같은 반복 작업을 LLM에 맡기는 역할 분담에 있다.
5. 영상 후반부는 그래프 뷰와 개인 조건이 들어간 질의를 통해 이 위키를 실제 탐색 도구처럼 쓰는 모습을 보여주며, 시간이 지나도 자료를 계속 추가하고 재인덱싱하면서 답변 기반을 갱신할 수 있다는 점을 강조한다.

🧩 배경과 문제 정의

• 이 영상은 일반적인 LLM이 몇 개 웹페이지를 바탕으로 표면적인 답변을 만드는 데는 유용할 수 있지만, 여러 아이디어를 비교하거나 깊이 있는 조사를 진행하려 하면 구조와 일관성이 쉽게 무너진다는 문제의식에서 출발한다.
• 이에 대한 대안으로, 자료를 일회성으로 소비하는 대신 문서와 논문을 계속 축적하고 연결하는 개인용 LLM wiki 방식이 제시된다.
• 핵심은 연구 판단 자체를 전부 자동화하는 데 있지 않다. 출처 선별, 질문 설계, 해석은 사람이 맡고, 반복적인 정리와 기록 관리, 인덱싱 같은 작업을 LLM에 맡기는 역할 분담이 중요하게 제시된다.
• 무료 도구만으로도 시작할 수 있고, 자료가 누적될수록 더 복잡한 질문에 대응할 수 있는 작업 환경을 만들 수 있다는 점에서 실용적 가치가 강조된다.

🕒 시간순 섹션별 상세정리

1. 깊이 있는 리서치에서 기존 LLM이 무너지는 지점 [00:00]

• 기존 LLM은 몇 개 사이트를 참고한 얕은 답변은 가능하지만, 아이디어를 비교하거나 더 깊게 파고들면 결과가 쉽게 흔들린다고 본다.
• 문제 해결책으로 Karpathy의 방식이 제시되며, 시간이 갈수록 더 쓸모 있어지는 맞춤형 지식 베이스를 만들 수 있다고 강조한다.
• 짧은 시간 안에 무료로 자신만의 LLM wiki를 구축할 수 있다는 기대를 초반부터 강하게 걸어 둔다.

2. Karpathy 게시물에서 출발한 LLM wiki 개념 [00:41]

• 이 아이디어의 출발점은 4월 2일 Karpathy가 올린 게시물이며, 개인 지식 기반을 LLM과 결합하는 방식이 큰 반응을 얻었다고 언급한다.
• 핵심 개념은 개인이 모은 자료를 LLM이 활용할 수 있는 형태로 축적하는 것이고, 이를 LLM wiki라고 부른다.
• 단순히 질문 몇 번 던지는 방식이 아니라, 연구 자산을 지속적으로 쌓는 환경이라는 점이 중심에 놓인다.

3. 문서 인덱싱과 Obsidian 프런트엔드 구조 [01:20]

• 텍스트 파일, PDF 등 원문 자료를 넣으면 LLM이 이를 분류하고 정리하는 데이터 수집 구조가 소개된다.
• 원자료를 보는 인터페이스로는 Obsidian을 사용하며, 사용자는 그 안에서 자료를 직접 탐색한다.
• 각 데이터 포인트와 문서가 서로 연결된 형태로 보이기 때문에, 어떤 아이디어끼리 맞물리는지 파악하기 쉬운 구조를 지향한다.

4. 대규모 자료 축적과 출력 방식의 변화 [02:20]

• 충분히 많은 기사와 논문을 넣어 두면 더 복잡한 질문을 던질 수 있고, 예시로는 100개 이상의 문서와 방대한 분량이 언급된다.
• 다만 그 수치가 반드시 필요하다는 뜻은 아니고, 지나치게 많은 문서를 밀어 넣으면 오히려 방법이 적합하지 않을 수 있다는 주의도 함께 나온다.
• 출력은 일반 챗봇처럼 터미널 답변으로 끝내기보다, 마크다운 파일이나 슬라이드처럼 구조화된 결과물을 선호하는 방향으로 제시된다.
• 위키가 커질수록 오류 수정과 낡은 내용 정리 같은 유지보수 문제도 생기는데, 이 부분 역시 AI가 맡을 수 있는 작업으로 본다.

5. 공개 프롬프트 문서와 커스터마이즈 여지 [03:17]

• 반응이 커진 뒤 Karpathy가 LLM-wiki.md 문서를 공개했고, 이를 LLM에 넣으면 기본 위키 골격을 만들 수 있도록 했다고 설명한다.
• 이 문서는 의도적으로 다소 추상적으로 작성되었고, 개인 프로젝트를 공유한 성격이 강하다고 덧붙인다.
• 따라서 그대로 고정 규칙처럼 따르기보다는, 시작점으로 활용한 뒤 각자 목적에 맞게 수정해도 된다는 태도가 강조된다.

6. 리소스 안내와 Obsidian 새 vault 준비 [04:15]

• 관련 링크와 자료는 별도 커뮤니티 게시물에서 무료로 확인할 수 있다고 안내한다.
• 실습의 첫 단계는 Obsidian을 내려받아 연구 자료를 볼 수 있는 작업 공간을 만드는 일이다.
• 사용자는 새 vault를 만들고 저장 위치를 정한 뒤, 비어 있는 새 환경에서 출발한다.

7. 코딩 에이전트에 위키 초기 세팅 맡기기 [05:24]

• 새 vault를 만든 뒤에는 에이전트형 코딩 환경을 열고, 방금 만든 폴더를 작업 대상으로 불러온다.
• 이어 공개된 LLM-wiki 문서를 통째로 붙여 넣고, 특정 주제에 맞는 위키를 세팅해 달라고 요청한다.
• 예시에서는 영양 연구를 주제로 지정하고, 구조를 먼저 만든 뒤 이후에 추가 자료를 넣겠다는 식으로 작업을 나눈다.
• 사람이 주제와 방향을 정해 주고, 에이전트가 초기 구조화 작업을 대신 수행하는 흐름이 만들어진다.

8. Web Clipper로 기사 수집해 위키에 넣기 [06:39]

• Obsidian의 웹 클리퍼를 활용하면 웹페이지 기사를 손쉽게 위키 쪽으로 가져올 수 있다고 설명한다.
• 예시 검색 주제는 인지 기능과 뇌 건강에 좋은 식단이며, 검색 결과 중 신뢰할 만해 보이는 기관 자료를 고른다.
• 각 페이지에서 클리퍼를 열면 Obsidian으로 바로 보내거나, 클립보드 복사나 파일 저장 방식으로 수집할 수 있다.
• 이렇게 모은 자료는 나중에 AI가 서로 연결하고 종합하는 재료가 된다.

9. 기사와 PDF를 함께 인덱싱하는 실제 입력 단계 [08:08]

• 기본 형식이 갖춰진 뒤에는 방금 수집한 기사들과 추가 PDF 논문을 같은 위키 안으로 인덱싱하도록 지시한다.
• 예시에서는 clippings 폴더 안의 기사들과 PDF 경로를 함께 넘기고, 앞서 준 지침을 그대로 따르라고 요청한다.
• 이 단계의 핵심은 자료를 단순 보관하는 데서 끝내지 않고, 위키 내부의 검색 가능하고 연결 가능한 연구 자산으로 편입시키는 데 있다.

10. 사람이 맡아야 할 연구 역할과 자동화의 한계 [08:47]

• 이 방식의 핵심은 읽기와 사고 자체를 대신하는 것이 아니라, 번거로운 기록 관리와 정리 업무를 LLM이 맡는 데 있다고 정리한다.
• 따라서 이 도구를 쓴다고 해서 곧바로 고급 연구자가 되는 것은 아니며, 출처를 고르고 분석하고 적절한 질문을 던지는 일은 여전히 사람의 책임이라고 못 박는다.
• LLM은 인간이 더 중요한 판단과 해석에 집중하도록 돕는 보조 도구로 위치 지어진다.
• 예시 작업에서는 Claude가 약 11분 만에 다섯 개 자료를 모두 인제스트하고 인덱싱했다고 말하며, 시각화 단계로 넘어가려는 지점에서 범위가 끝난다.

11. 연결망으로 중요 주제 가늠 [10:00]

• Obsidian의 그래프 뷰를 열자 지금까지 학습한 내용이 하나의 연결망처럼 펼쳐진다.
• 오메가3 지방산과 잎채소가 여러 항목과 맞닿아 있어, 상대적으로 더 중요한 축일 수 있다고 판단한다.
• 필요한 경우 각 항목을 읽어 내려가거나, 소스를 눌러 다음 페이지나 마크다운 파일로 바로 이동할 수 있다.
• 시각화와 편집 방식은 원하는 형태로 조정할 수 있다는 점을 강조한다.

12. 개인 조건을 넣어 질의 전환 [10:43]

• 질의를 시작하기 전에 /clear를 입력한 뒤, 개인 조건이 반영된 질문을 새로 던진다.
• 예시 질문은 활동량이 있는 21세 남성이 제지방을 더 늘리고 싶을 때 어떤 식단이 적절한지 묻는 형태다.
• 답변의 근거는 일반 상식이 아니라, 현재 접근 가능한 연구 자료에 기반해야 한다는 전제가 깔려 있다.

13. 반복 질문이 생기는 장기 주제에 적용 [11:08]

• 이 방식은 영양에만 한정되지 않고, 일이나 개인 관심사처럼 다른 분야에도 그대로 확장할 수 있다고 본다.
• 특히 시간이 지나며 비슷한 질문이 계속 생기고, AI로 추가 조사나 보충 답변을 자주 찾는 상황에 잘 맞는 선택지로 제시된다.
• 실제로 질의 결과로 식단 또는 핵심 식품 제안이 생성된 상태를 보여준다.

14. 자료 누적과 재인덱싱으로 발견 갱신 [11:41]

• 여기서 멈추지 않고 기사, 논문, 트윗 등 흥미롭거나 신뢰할 만한 자료를 폴더에 계속 추가할 수 있다.
• 새로 넣은 자료를 AI가 다시 인덱싱하게 하면, 이전과 다른 발견이 나오는지 확인할 수 있다.
• 핵심은 일회성 검색보다, 자료 축적과 재질문을 반복하면서 답변 기반을 계속 넓히는 데 있다.

15. 내부 구조 확인과 불필요 파일 정리 [12:10]

• Obsidian이라는 무료 도구를 통해 정보가 내부에서 어떻게 연결되고 있는지 더 깊게 들여다볼 수 있다고 말한다.
• 일부 항목은 클립하거나 링크로 만들 수 있고, 필요 없는 파일은 직접 삭제하는 식으로 정리할 수 있다.
• 마무리에서는 이 방법이 실제로 어땠는지, 추가 활용 사례나 도움이 된 작은 수정점이 있는지 의견을 요청한다.

🧾 결론

• 이 영상의 중심 메시지는 “AI가 연구를 대신한다”보다 “연구 자료를 축적하고 갱신할 수 있는 개인 지식 기반을 AI와 함께 운영한다”에 더 가깝습니다.
• Obsidian, 웹 클리퍼, PDF·기사 수집, 에이전트 기반 구조화 작업을 결합하면 특정 관심 주제에 대해 반복적으로 업데이트되는 조사 환경을 만들 수 있다는 점이 실용적으로 제시된다.
• 특히 자료를 단순 저장하는 것이 아니라, 검색 가능하고 서로 연결된 연구 자산으로 편입시키는 과정이 이 방식의 핵심으로 설명된다.
• 영상은 사람이 해야 할 역할을 분명히 남겨 둡니다. 출처를 고르고, 질문을 설계하고, 결과를 해석하는 일은 여전히 인간의 몫이라는 점을 반복해서 강조한다.
• 따라서 이 방식의 가치는 자동 생성된 답변 한 번의 품질보다, 장기적으로 누적되는 연구 워크플로우와 재질문 가능성을 확보하는 데 있다고 볼 수 있다.

📈 투자·시사 포인트

• 생산성 도구 관점에서는 범용 챗봇 자체보다, 개인 문서 저장소와 인덱싱, 시각화, 재질문을 연결하는 연구형 워크플로우 레이어의 중요성이 커질 수 있음을 시사한다.
• 지식노동 시장에서는 단발성 답변보다, 사용자가 직접 모은 자료를 기반으로 검토 가능한 근거망을 유지하게 해 주는 제품이 더 높은 체류성과 차별화를 가질 가능성이 있다.
• 특히 리서치, 교육, 컨설팅, 투자 조사, 콘텐츠 기획처럼 같은 주제를 오래 추적하는 분야에서는 “정답 생성”보다 “지식 축적과 업데이트”가 더 중요한 가치 제안이 될 수 있다.
• 다만 영상에서 언급된 효율, 정확도, 장기 운영 편의성은 시연 흐름에 기반한 설명이므로, 실제 업무 환경에서의 재현성은 별도 검증이 필요한다.
• 또한 Karpathy 게시물의 영향력, 특정 도구 조합의 우월성, 예시 결과의 일반화 가능성은 영상 설명만으로 단정하기 어렵기 때문에, 도입 전에는 실제 자료 규모와 사용 목적에 맞춘 테스트가 필요한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Karpathy가 4월 2일 올렸다고 언급된 게시물의 정확한 원문 내용과, 영상에서 전달된 요지가 얼마나 충실히 반영되었는지는 원문 대조가 필요하다.
• 100개 이상의 문서, 방대한 분량 같은 규모 언급은 예시인지 권장 기준인지 transcript만으로는 확정하기 어렵다.
• 영상에서 사용한 에이전트형 코딩 환경이 정확히 어떤 도구였는지, 어떤 모델과 설정을 썼는지는 section-detail만으로 특정되지 않는다.

✅ 액션 아이템

• Karpathy 관련 원문 게시물과 LLM-wiki.md를 직접 확인해 영상 설명과 실제 문서의 차이를 비교한다.
• Obsidian에 새 vault를 만들고, 관심 주제 기준으로 기사와 PDF를 함께 넣는 최소 실험 환경을 구성한다.
• 웹 클리퍼로 수집한 기사와 PDF를 같은 폴더 체계 안에 정리해, 인덱싱 전후 검색성과 연결성 변화를 확인한다.
• 에이전트에게 초기 위키 구조 생성만 맡기고, 출처 선별 기준과 질문 설계는 사람이 직접 분리해 운영해 본다.

❓ 열린 질문

• 이 방식은 자료가 더 많이 쌓였을 때도 계속 효율적일까, 아니면 어느 시점부터는 정리 비용이 검색 이점을 넘어설까?
• 사람에게 남겨야 할 판단과 AI에 맡겨도 되는 정리 작업의 경계는 실제 운영에서 어떻게 정의하는 게 좋을까?
• 그래프 기반 연결 구조가 연구 질문을 더 잘 만들게 돕는지, 아니면 단지 보기 좋은 시각화에 머무는지 어떻게 평가할 수 있을까?