위키는 만들었는데, 뭘 하죠? — 쌓기만 하던 기록을 AI가 꺼내 쓰는 지식으로

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

만들어 둔 위키를 AI가 꺼내 쓰는 지식으로 바꾸려면, 원하는 산출물을 먼저 정하고 선별한 기록을 개념·목차·링크로 연결한 뒤 질문과 검수에 활용해야 한다.

📌 핵심 요점

1. 수집보다 활용 목적이 먼저다. 강의·영상·프로젝트 등 만들 결과를 정하고, 그 목적에 필요한 최신 자료와 자신의 경험·생각을 ‘골드 데이터’로 선별한다. 자료를 저장할 때 수집 이유까지 남겨야 AI가 사용자의 관심과 의도를 참고할 수 있다.
2. 원문을 재사용할 수 있는 지식으로 가공한다. 인제스트는 원문을 마크다운으로 정리하고 개념·인물·단체 등을 분리해 기존 문서와 연결한다. 인덱스는 전체 목차 역할을 하며, 린트는 끊어진 링크·고아 페이지·중복을 점검한다.
3. 질문의 답을 다시 다음 작업의 재료로 남긴다. 쿼리는 인덱스에서 관련 문서를 고르고 링크를 따라 근거를 모은다. 답변에서 얻은 발견을 신테시스로 저장하면 수집→가공→연결→질문→재활용의 흐름이 이어진다. 다만 시연 답변에는 방금 넣은 자료가 아직 검색되지 않았다.
4. 공유 위키는 여러 에이전트의 협업 기반이 된다. 공통 자료를 함께 읽되 역할·작업 폴더·개별 메모리를 나누고, 회의 맥락과 발주·작업 과정·산출물을 축적한다. 목차와 링크로 기존 맥락을 찾게 하고, 필요한 규칙은 훅과 코드로 보완한다.
5. 목표 설정과 검수에는 사람의 판단이 필요하다. 사람은 목표·합격 기준·완료 경계를 정하고 자신의 관점을 계속 기록해야 한다. 제작과 검수를 분리해 원자료와 기준으로 확인하되, 다중 에이전트 구성에도 운영 비용·맥락 혼선·산출물 오류가 남는다는 점을 고려해야 한다.

🧩 배경과 문제 정의

• LLM 위키는 AI가 기록을 알아서 기억하고 꺼내 준다는 기대를 모았지만, 어떤 자료로 구성하고 어떻게 활용할지에 대한 고민도 필요하다.
• AI가 개인의 문제를 해결하려면 일반적인 지식뿐 아니라 사용자가 선별한 최신 자료, 경험, 생각 등 자신과 관련된 데이터가 필요하다.
• 기록을 쌓는 데서 활용하는 데로 나아가려면 자료를 재사용하기 좋은 형태로 가공하고 연결해야 한다. 목표 산출물을 정하고 자신의 판단을 더하는 일도 이 과정에 포함된다.
• 옵시디언에 자료를 수집하고 AI로 지식을 정리하는 사례를 통해, 사람의 자료 선별과 AI의 가공·활용이 어떻게 이어지는지 살펴본다.

🕒 시간순 섹션별 상세정리

1. ‘AI가 알아서 기억한다’는 기대만으로는 부족하다

• LLM 위키를 둘러싼 콘텐츠는 AI가 모든 것을 기억해 준다는 효과에 집중하는 경향이 있다. 다만 이는 발표자가 자신의 피드에서 관찰한 경향이며, 다른 콘텐츠를 놓쳤을 가능성도 인정한다 [04:11]
• AI가 생성한 내용을 보기 위해 옵시디언을 사용하는 것도 가능하지만, 그것만으로는 지식 관리의 역할을 충분히 활용하기 어렵다. 위키를 무엇으로 구성하고 에이전트 활용으로 어떻게 이어 갈지가 남은 과제다 [05:43]

2. LLM 위키는 AI도 읽고 편집하는 지식 베이스다

• 위키의 핵심은 여러 사람이 공동으로 참여하고 편집할 수 있다는 점이다. 나무위키의 편집 기능은 이러한 공동 지식 관리 방식을 보여 준다 [07:16]
• LLM 위키는 이 참여 주체에 언어 모델을 포함한다. AI가 사람과 함께 지식 베이스를 읽고, 편집하고, 쓰는 구조다 [07:55]

3. 개인에게 필요한 ‘골드 데이터’를 AI에 제공한다

• 사용 중인 모델은 학습한 지식을 활용하며, 최신 정보를 답할 때는 인터넷 검색 같은 외부 자료 접근이 필요하다. 현재 해결하려는 문제에 필요한 지식과 보고서를 별도로 제공해야 하는 이유다 [09:31]
• 자신이 선별한 최신 자료와 개인의 경험·생각을 ‘골드 데이터’라고 부른다. AI가 기본적으로 알지 못하는 이 데이터를 활용 가능한 상태로 제공하는 것이 LLM 위키의 첫 번째 목적이다 [10:43]

4. 사람이 읽는 문서를 AI가 재사용하기 좋은 형태로 가공한다

• PDF 논문, PPT, 웹페이지는 사람이 보기 편하게 편집된 자료다. AI도 읽을 수 있지만, 매번 해석하는 과정에서 토큰을 많이 사용할 수 있다 [11:33]
• 마크다운은 일반 텍스트에 제목과 강조 등의 구조를 표현해 AI가 내용을 가볍게 읽도록 돕는다. 원본 자료를 이런 형태로 손질해 다시 활용하기 쉽게 만드는 것이 두 번째 목적이다 [12:31]

5. 좋은 재료를 선별하고 손질하는 ‘골드 인, 골드 아웃’

• 자신과 관련 있고 최신성이 있는 좋은 데이터를 제공해야 좋은 결과를 얻을 수 있다는 원칙을 ‘골드 인, 골드 아웃’으로 표현한다 [13:33]
• 사람은 좋은 원재료를 선별하고, AI는 이를 소분해 언제든 꺼낼 수 있도록 정리한다. LLM 위키는 손질한 재료를 보관하는 냉장고에, 그 재료로 결과물을 만드는 AI는 요리사에 해당한다 [13:50]

6. 목차와 연결을 따라 지식을 찾는 탐색 방식

• RAG는 데이터를 벡터화해 저장하고 질문마다 계산을 통해 필요한 자료를 검색하는 방식으로 드러난다. 다만 발표자는 기술자가 아니며 자신의 설명이 정확하지 않을 수 있음을 인정한다 [14:26]
• LLM 위키는 정리된 책장과 도서관에 비유된다. AI가 전체 목차를 보고 필요한 항목과 연결을 따라 이동하며 자료를 찾아 활용한다는 점이 핵심적인 차이로 드러난다 [15:33]

7. 수집보다 먼저 목표 산출물을 정한다

• LLM 위키를 잘 활용하려면 어떤 지식으로 어떤 산출물을 만들지 먼저 정해야 한다. 모든 지식을 모으는 것 자체가 목적이 되어서는 안 된다 [16:37]
• 강의, 프로젝트, 스토리텔링, 영상 편집처럼 원하는 결과를 정한 뒤, 그 목표에 맞춰 무엇을 수집하고 무엇을 줄일지 결정한다 [16:49]

8. 사람의 판단을 넣고 AI 생성 기록과 구분한다

• AI가 정리를 맡더라도 사람의 생각·감정·판단을 입력해야 한다. 전적으로 위임하면 목적에 맞는 골드 데이터를 수집하고 선별하는 데 필요한 사람의 관점이 빠진다 [17:10]
• 위키가 만들어진 뒤에도 자신의 기록과 생각을 계속 더해야 한다. AI가 만든 자료와 사람이 만든 자료는 분리해 운영하되, 필요할 때 함께 활용할 수 있는 구조가 필요하다 [17:35]

9. 원본 수집에서 지식 가공과 새 산출물로 이어지는 기본 구조

• 기본형은 크게 세 부분으로 구성되며, 스킬과 워크플로가 이를 연결한다. 원본을 담는 raw에는 PDF처럼 사람이 읽는 자료를 넣는다 [18:19]
• 인제스트는 원본을 읽고 손질해 관련 개념을 연결하는 과정이다. 서로 다른 글에서 개념을 분리해 재사용할 수 있는 위키 지식으로 정리한다 [19:00]

10. 인제스트·쿼리·린트가 지식의 연결과 관리를 담당한다

• 인제스트는 자료를 마크다운으로 분해하고 개념과 내용을 기존 지식에 연결하며, 인덱스라는 목차도 정리한다 [20:11]
• 쿼리는 목차를 먼저 읽고 연결을 따라가며 관련 자료를 모아 답변을 구성한다 [20:40]

11. 사람과 에이전트의 역할 분담을 기준으로 첫 자료를 선별한다

• 첫 수집 사례는 OpenAI의 하네스 엔지니어링 글이다. “사람은 방향을 주고 에이전트는 실행한다”는 역할 분담이 재활용하고 싶은 핵심 내용이다 [21:40]
• 옵시디언 웹 클리퍼로 웹페이지를 가져와 마크다운으로 저장한다. 자료를 모으는 데에는 어떤 내용을 다시 활용하려는지에 대한 이유가 있어야 한다 [22:31]

12. ‘실행자에서 설계자로’라는 관점의 글을 추가한다

• 두 번째 자료는 티아고 포르테의 ‘실행하는 사람에서 설계하는 사람으로’라는 취지의 글이다. 사람과 AI의 역할을 구분하고 사람의 역할을 설계로 옮겨 보는 관점이 수집 이유다 [23:54]
• 웹 클리퍼로 내용이 모두 수집되지 않아 원문을 복사해 옵시디언에 직접 넣는다. 자료 수집은 특정 도구 하나에만 의존할 필요가 없다 [24:33]

13. 수집 이유와 처리 대상을 명확히 지정한다

• 자료를 저장한 뒤에는 왜 캡처했는지도 입력하려 한다. 수집한 두 글은 인제스트를 통해 분해하고 지식으로 가공할 대상이다 [25:21]
• 클로드 코드에서 인제스트를 실행할 때 처리할 두 파일의 경로를 명확히 지정한다. 단순히 최신 자료를 처리하라고 맡기는 대신 원하는 입력을 특정한다 [26:11]

14. 원문에서 개념과 개체를 추출하며 중복 처리 결과는 아직 기다린다

• 인제스트는 원문을 읽고 개념과 용어를 분리한다. 글 전체를 인용하는 것뿐 아니라 특정 개념의 설명이나 표현을 추출해 저장하는 데도 목적이 있다 [28:04]
• 위키 볼트에는 원문과 함께 그 안에 등장하는 개념, 사람, 단체 등을 분리해 저장하는 구조가 적용되어 있다 [28:41]

15. 새 자료를 기존 지식과 비교해 개념으로 연결한다

• 수집한 글을 기존 자료와 비교해 중복 여부와 새로운 연결 가능성을 찾는다. 두 글에서 발견한 하네스 엔지니어링, 퍼널, 콘텍스트 매니지먼트 등의 개념도 이미 저장된 위키 내용과 연결할 수 있다 [30:01]
• 자료를 글 단위로 보관하는 데서 더 나아가 개념을 분리한다. 같은 개념이 다른 글에서 다시 등장하면 기존에 저장된 내용과 연결해 정리한다 [30:38]

16. 수집 이유와 활용 목적을 인제스트에 포함한다

• 브라이언의 인제스트 스킬은 개념을 정리하면서 “왜 캡처했는가”를 묻는다. 자료를 수집한 사람의 관심과 의도를 함께 저장하기 위한 절차다 [31:13]
• 예시에는 사람과 에이전트의 역할 분기에 관심이 있고, 이를 바탕으로 영상을 만들고 싶다는 목적을 입력한다. 이 맥락이 자료 정리에 함께 반영된다 [31:41]

17. AI의 연결 판단을 인덱스에 모아 탐색 기반을 만든다

• 새 개념은 기존의 에이전틱 하네스나 에이전틱 워크스페이스 등과 유사성을 바탕으로 연결된다. 다만 연결은 AI의 판단이므로 자료가 들어온 순서와 사용 모델에 따라 결과가 달라질 수 있다 [32:59]
• 개별 글의 연결보다 중요한 것은 정리된 글이 인덱스에 편입되는 일이다. 인덱스는 위키 전체의 목차로서 개념과 객체에 설명을 붙여 자료의 위치와 관계를 파악하게 한다 [34:17]

18. 쿼리는 인덱스에서 출발해 관련 문서를 따라간다

• 새 세션에서 “사람과 에이전트의 협업 프로세스와 역할은 어떻게 분리되는가”를 질문한다. 쿼리 스킬에는 위키에 모아 둔 자료만을 토대로 답하도록 지시한다 [36:02]
• AI는 먼저 전체 인덱스를 읽고, 개념별 요약과 사용자 질문을 비교해 필요한 문서를 선택한다. 인덱스가 너무 커지면 읽는 부담도 커질 수 있다 [36:42]

19. 질문의 답을 저장해 콘텐츠 제작에 재사용한다

• 협업 역할에 대한 답변은 구도, 루프, 검증의 사다리 등을 설명하는 기존 글을 인용한다. 다만 방금 수집한 자료는 당시 답변에서 아직 검색되지 않은 상태다 [38:08]
• 답변을 얻는 데서 끝내지 않고 내용을 신테시스에 정리하도록 요청한다. 질문으로 발견한 내용을 저장하면 이후 글이나 콘텐츠를 만드는 데 다시 사용할 수 있다 [38:41]

20. 논문·파일·활동 기록으로 지식의 재료를 확장한다

• 브라이언은 논문을 읽고 메모하는 Zotero를 연결해 논문 내용도 인제스트한다. DEVONthink에는 다양한 소스를 저장하고 AI가 내용을 꺼내 활용하도록 구성한다 [39:43]
• Screenpipe로 화면과 음성을 기록하고, Omi 앱으로 일상 기록도 모은다. 수집한 외부 자료에 개인의 활동과 기억을 연결하면 활용 범위를 더 넓힐 수 있다는 구상이다 [40:30]

21. 정리를 맡기더라도 질문과 생각은 사람이 보탠다

• 무엇을 질문하고 어떻게 활용할지, 무엇을 만들고 어떤 문제를 해결할지는 사람의 생각으로 채워야 한다. 자료 정리를 AI에 맡긴다고 해서 사람의 입력까지 빠져서는 안 된다 [41:19]
• AI에게만 맡기면 생각을 외주화하게 될 수 있다. 직접 읽고 느낀 점도 기록해 AI가 정리한 내용과 함께 활용해야 한다 [42:10]

22. 개인화의 이점에는 최신성 유지와 관리 비용이 따른다

• 카카오톡, 업무 메신저, 이메일까지 정리하면 AI가 자신을 잘 안다는 느낌을 얻을 수 있다. 반면 연결하는 데이터가 늘수록 관리에 드는 시간도 커진다 [42:30]
• 에이전트가 고장 나거나 최신 데이터를 계속 공급하지 않으면 현재 상황과 맞지 않는 과거 자료로 답할 수 있다 [42:49]

23. 여러 에이전트로 맥락·관점·축적의 문제를 나눈다

• 김재경이 자료 관리에 관심을 가진 출발점은 연구소 업무와 AI 공부 과정에서 접한 방대한 자료였다. 이를 AI가 빠르게 정리할 수 있는지가 핵심 문제였다 [46:17]
• 하나의 세션에서 모든 일을 처리하면 맥락이 섞이고 관점도 하나로 좁아진다. 같은 모델이라도 에이전트 설정을 다르게 구성하면 여러 관점에서 작업하게 할 수 있다 [48:17]

24. 공유 위키와 개별 폴더로 공동 자료와 역할을 관리한다

• 위키를 여러 에이전트가 함께 일하는 공간으로 구성한다. 팀 프로젝트의 공유 문서함처럼 동일한 자료를 보며 협업하게 하는 것이 목적이다 [49:26]
• 하나의 위키 안에서도 에이전트별 작업 폴더와 메모리, 역할·성격·행동 설정 문서를 나눈다. 화면에 공개한 일부 문서는 원래 숨김 설정 폴더에 있는 내용을 읽기 쉽도록 복사한 것이다 [50:13]

25. 독립 에이전트는 메모리를 축적하고 서브에이전트도 활용한다

• 서브에이전트도 생성 방식을 문서화해 다르게 구성할 수 있다. 다만 위키를 기반으로 개별 봇을 운영하면 각자의 메모리를 따로 관리하며 지속적으로 발전시키기 편하다는 설명이다 [52:47]
• 개별 봇이 다시 서브에이전트를 사용할 수도 있다. 여러 봇을 운영하지 않더라도 프로젝트 폴더를 나누고 에이전트 설정을 별도로 두는 방식으로 역할을 분리할 수 있다 [53:07]

26. 모델과 역할을 조합하되 운영 비용은 별도로 고려한다

• 같은 모델 안에서 역할을 나누거나 서로 다른 AI를 섞어 쓴다. 예시에서는 Codex 기반 봇이 이미지 생성·편집과 팩트 체크·자료 조사 등을 나누어 맡는다 [53:34]
• Claude 기반 봇에는 총괄 역할 등을 부여하고, 다른 봇에는 X 검색을 맡긴다. Gemini도 함께 사용하며 여러 모델을 하나의 협업 구성 안에 배치한다 [54:10]

27. 교차 검증에서는 모델뿐 아니라 역할 설정도 판단을 바꾼다

• 원고의 팩트 체크 과정에서 Opus 기반 코난이 Astra 기반 봇의 오류를 지적했고, 그 사례에서는 코난의 판단이 맞았다. 서로 다른 에이전트의 검토가 오류 발견에 도움이 된 사례다 [55:04]
• 이미지 검수 봇을 평가할 때도 평가를 맡은 봇의 역할에 따라 점수가 달라졌다. 같은 모델을 사용하더라도 설정에 따라 동일한 작업에 대한 판단이 갈릴 수 있다 [55:40]

28. 협업 규칙을 코드로 보완하고 자료 선택에는 사람이 개입한다

• 에이전트 간 작업 조율은 Markdown 파일에 적힌 규칙과 훅·파이썬 코드로 강제하는 규칙을 나누어 운영한다 [56:20]
• 좋은 결과를 얻으려면 입력부터 좋은 자료로 구성해야 한다. 자료를 넣는 과정에서도 사람의 개입이 중요하며, 위키를 공유한다고 자료의 품질 문제가 저절로 해결되는 것은 아니다 [56:56]

29. 회의록을 개념·기존 문서와 연결해 공동 작업의 재료로 만든다

• 세미나 진행 중 코난에게 자료를 정리하도록 요청해 옵시디언에 회의록을 저장한다. 회의록 외에 관련 개념 문서도 자동으로 생성된 상태를 확인한다 [57:38]
• 회의 종료 시간이 매번 달라 수집 과정은 반자동 스킬로 구성한다. 저장된 내용에는 골드 데이터, 인제스트와 쿼리, 확장 연동과 관리 비용 등이 포함되며 기존 문서와도 링크가 연결된다 [58:38]

30. 회의 맥락과 산출물을 함께 남기는 협업 위키

• 미리 축적한 자료는 에이전트 협업을 빠르게 하고, 위키는 작업 중 방향을 유지하며 토론하는 공간으로도 쓰인다. 디스코드에서는 슬라이드와 PDF 제작을 위한 회의실을 따로 운영한다 [1:00:23]
• 옵시디언에는 회의별 맥락 문서, 발주 문서, 회의 문서, 아웃컴 문서를 남긴다. 다만 시연 당시 일부 아웃컴은 완료 통보를 하지 않아 미완료 상태였다 [1:01:15]

31. 목차와 링크로 기존 지식을 찾아가는 구조

• 봇은 작업을 받으면 위키를 검색한다. 코드 형태의 폴더 구조와 별도 목차 문서를 제공해 전체 구조를 파악하고 관련 문서로 들어가게 한다 [1:02:42]
• 목차는 강의, 세미나, 함께 일한 담당자 등의 맥락을 연결한다. 작업 시 기존 맥락을 읽도록 하고, 산출물은 위키에 동기화한다 [1:03:18]

32. 공통 운영 원칙과 봇별 정체성의 분리

• 최상위 AGENTS.md에는 봇 정체성의 가드, 완료 게이트, 핵심 경로 포인터를 헌법처럼 둔다. 각 에이전트의 설정 문서에는 개별 정체성과 역할을 담는다 [1:04:44]
• 이미지와 말투를 다르게 설정하면 여러 봇의 역할과 작업을 구분하기 쉽고 실제 팀원과 일하는 느낌을 준다. 이는 운영자의 경험에 근거한 효과이며, 뇌과학과의 연관성은 공부 중이다 [1:05:12]

33. 상황별 규칙 선택과 메모리 자동 주입

• 규칙 전체를 매번 읽히지 않고 디스코드 회의, 도구 사용, 한국어 응답, 글쓰기 등 상황에 맞는 문서로 연결해 읽기 부담을 나눈다 [1:06:11]
• 일부 훅은 관련 규칙을 강제로 읽게 한다. 디스코드 규칙에는 사용자가 터미널을 보지 않으므로 반드시 디스코드로 답하고, 파일이 세 개 이상이면 압축해서 보내라는 조건이 있다 [1:07:01]

34. 컨텍스트 압축 대응과 훅 축소의 균형

• 클로드 코드의 훅 종류가 코덱스보다 많다는 사용 경험이 있다. 약 1.5배 이상이었다는 기억을 덧붙이지만, 구체적인 개수를 직접 비교한 수치는 아니다 [1:08:43]
• 컨텍스트 압축 전에 특정 상황을 저장하고 압축 후에는 필요한 내용을 반드시 다시 읽도록 훅을 설정한다. 반면 훅이 많아지면 AI가 무거워져, 최근에는 구성을 비우고 하나씩 추가하는 방식도 시도한다 [1:09:01]

35. 역할에 맞춘 메모리와 작업 대장

• 총괄 봇과 실무 봇은 맡은 일에 따라 다른 메모리를 받는다. 실수와 틀린 방식을 기록하고, 검증 봇의 과도한 정정·번복을 줄이기 위해 메모리로 행동 수정을 시도하기도 한다 [1:10:11]
• 사용자가 결정할 사안이 없으면 디스코드로 추가 보고하기보다 봇끼리 먼저 토론하라는 운영 지침도 저장한다. 현재 진행 중인 작업은 SQLite 기반 작업 대장으로 함께 확인한다 [1:11:09]

36. 실제 작업 기록을 근거로 답하는 위키

• 사람과 에이전트의 작업 범위에 관한 자료와 질문을 바탕으로 에이전트끼리 토론한다. 저장된 외부 문서뿐 아니라 실제 지시와 작업 과정도 답변의 근거가 된다 [1:12:19]
• 작업 기록을 활용하면 사람이 먼저 목표와 합격 기준, 완료의 경계를 정해야 한다는 답변을 구체화할 수 있다. 검수 역시 제작자와 구분된 검수자가 원자료와 기준에 비추어 독립적으로 확인해야 한다는 논지로 계속된다 [1:13:32]

37. 총괄 봇의 작업 분배와 발주문 구체화

• 슬라이드 제작은 총괄 봇에 핸드오프한 뒤 제작과 검수 루프를 거쳐 최종 결과를 받는 방식이다. 총괄 봇은 일을 나누어 서브에이전트와 다른 봇에 배정하고, 보고를 받으며 회의록을 갱신하고 위키를 검색한다 [1:15:11]
• 우로보로스 플러그인은 소크라테스식 문답으로 모호한 질문과 부족한 발주문을 구체화하는 데 쓰인다. 이 과정도 위키에 저장해 이후 AI 작업에서 다시 참고하게 한다 [1:16:06]

38. 슬라이드 자동화의 한계와 사람이 정할 내용

• 슬라이드 제작의 자동화 범위는 개인적인 판단으로 최대 약 60%다. 기존 자료가 많아도 상황과 전달하려는 내용이 달라져, 장별로 들어갈 핵심 내용을 사람이 넣어야 결과가 깔끔해진다 [1:16:58]
• 화면 캡처를 골라 넣는 작업은 AI가 선호와 맥락을 알고 있어 시간을 줄여 준다. 시연에 쓰인 슬라이드의 캡처 화면도 자동으로 삽입했다 [1:17:45]

39. 표기·시각 요소·논지를 나누는 검수

• 슬라이드 제작에서는 이미지 생성과 검수를 분담한다. 표기·문체·은어를 확인하는 봇과 이미지의 깨짐, 잘못된 삽입, 크기 등을 확인하는 봇을 따로 둔다 [1:18:24]
• 적대적 리뷰에서는 해당 장이 꼭 필요한지, 논지가 원문과 맞는지를 추가로 점검한다. 한 제작 도구의 결과만 믿지 않고 내용 구성까지 별도로 검토하는 방식이다 [1:18:54]

40. 산출물 시연의 오류와 제작 시간 정정

• 브라이언의 자료와 세미나 기획 자료를 바탕으로 PDF 책 형태의 결과물을 만들었다. 다만 급히 제작하면서 저자 표기가 공동 세미나로 들어간 상태였다 [1:19:57]
• 이후 슬라이드 시연에서는 HTML이 열리지 않았고, 확인한 결과물도 의도한 자료가 아니라 자신의 3부 내용을 담은 PDF로 보였다. 해당 시연은 잘못 만들어진 것으로 판단해 넘어갔다 [1:21:38]

41. 위키·훅·규칙을 실제 제작 과정으로 연결하기

• 위키는 봇의 검색과 산출물 축적에, 훅은 컨텍스트 압축과 규칙 적용에, 규칙은 작업 위임과 검수 분배 등에 활용된다 [1:22:38]
• 디스코드에 입력한 요청은 터미널로 전달된다. 세미나 참여자에게 인사하라는 요청으로 이 연결을 시연한다 [1:23:06]

42. 세미나 이후 질문과 에이전트 응답의 연결

• 남은 질문은 질의응답 시간에 다루고, 시간이 부족하면 댓글로도 답할 예정이다. 에이전트 코리아의 카카오톡방과 디스코드 질문 공간에서도 세미나 관련 질문을 받을 수 있다 [1:24:39]
• 디스코드에서는 세미나와 강의에 관해 봇에 질문할 수 있다. 당시 설정상 카파시를 부르면 대부분 페이블로 연결되며, 응답 가능 범위는 운영자의 토큰이 남아 있는 동안이라는 조건이 붙는다 [1:25:50]

🧾 결론

• 위키의 가치는 저장한 문서 수보다 필요한 근거를 찾아 실제 산출물에 재사용하는 과정에서 드러난다.
• 사람은 자료의 가치와 활용 방향을 판단하고, AI는 가공·연결·탐색·제작을 맡는 역할 분담이 핵심이다. 사람이 쓴 기록과 AI 생성 자료는 구분하면서 함께 활용할 수 있어야 한다.
• 협업 위키에는 외부 지식뿐 아니라 실제 지시, 판단, 작업 과정과 결과도 남겨야 한다. 이 기록은 다음 작업의 맥락이자 오류를 수정하는 근거가 된다.
• 시연은 활용 가능한 구조를 보여 주지만 완전 자동화를 입증하지는 않는다. 최신성 유지와 연결 관리, 독립 검수를 지속하는 운영이 필요하다.

📈 투자·시사 포인트

• 도입 판단의 기준은 재사용 성과다. 위키 구축 여부보다 필요한 자료가 답변에 반영되는지, 결과물이 목적과 기준을 충족하는지를 살펴볼 필요가 있다.
• 개인화에는 관리 비용이 따른다. 자료와 메신저·활동 기록의 연동을 늘릴수록 최신 데이터 공급과 장애 대응에 시간이 든다. 활용 범위 확대와 유지 부담을 함께 판단해야 한다.
• 모델 선택만으로 품질이 결정되지는 않는다. 시연에서는 역할 설정에 따라 판단이 달라졌고, 제작자와 분리된 검수자가 오류를 발견했다. 입력 자료의 품질과 역할·검수 설계도 중요한 운영 요소다.
• 금융 투자 판단에 필요한 수치는 제시되지 않았다. 구체적인 유지비나 정량적인 생산성 비교가 없으므로, 이 사례는 도구와 업무 방식의 도입을 검토하는 근거로 활용하는 편이 적절하다.

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

• RAG와 LLM 위키의 차이에 관한 설명은 발표자도 정확성의 한계를 인정했다. 이를 두 방식의 기술적 우열이나 상호 배타성을 입증하는 설명으로 받아들이기는 어렵다.
• 중복 자료의 인제스트 결과는 해당 처리 구간에서 확인되지 않았고, 이후 쿼리에서도 새로 수집한 글이 아직 검색되지 않았다. 저장·연결·검색 반영이 실제로 완료됐는지 별도 확인이 필요하다.
• AI가 만드는 개념 연결은 입력 순서와 모델에 따라 달라질 수 있다. 인덱스가 커질 때의 읽기 부담과 자료의 최신성 유지도 해결해야 할 운영 문제다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 만들 산출물 하나를 고르고, 사용할 자료의 범위와 합격 기준·완료 조건을 적는다.
• 목적에 맞는 자료를 소수 선별하고, 각 자료에 수집 이유와 자신의 생각을 덧붙인다.
• 인제스트할 파일을 명확히 지정한 뒤, 개념 분리·기존 문서 연결·인덱스 편입 여부를 확인한다.
• 위키 자료만으로 답하도록 질문하고, 새 자료가 실제 답변의 근거에 포함됐는지 점검한다. 유용한 발견은 다시 저장한다.

❓ 열린 질문

• 새 자료가 인제스트된 뒤 실제 질문의 답변에 반영됐다는 것을 어떤 기준으로 확인할 것인가?
• 인덱스와 자료가 계속 커질 때 탐색 부담과 최신성 관리 비용을 어떻게 조절할 것인가?
• 여러 에이전트의 검수가 추가 토큰·관리 시간에 비해 충분한 품질 개선을 만드는 작업은 무엇인가?