이 위키를 만들기로 한 가장 직접적인 원인 제공자가 안드레 카파시였다. 그는 단순히 유명한 AI 연구자가 아니라, AI를 실제로 다루는 방법을 교육과 구현, 그리고 운영의 언어로 풀어내는 사람에 가깝다.고 검색에 나오지만 나랑 완전 세계에 있는 다른 사람이었다. 나는 적어도 메모앱에 대해서는 첨단을 달리는 사람이었다. 2007년 엔씨소프트에서 한국의 난다긴다 하는 개발자들을 모아 야심차게 만든 스프링노트부터 시작해서 원노트는 2009년경부터 쓰며 업무기록을 하며 노트앱의 유용성에 눈을떴고, 노션을 2020년경에  2년쯤 쓰다가 Dynalist라는 아웃라이너 노트앱에 한참동안 정착했다(이 개발자들이 옵시디언을 만들었다!) 네트워크 그래프와 로컬 위키 기능이라는 기능에 매료되어 옵시디언에 정식버전이 나오기도 전부터 쓰기 시작했다가 눌러앉게 된 것이다. 옵시디언의 장점은 무한한 자유도였고 단점도 마찬가지다. 저장공간을 제약받지 않고 사용자가 입맛대로 만들수 있다는 것은 구조를 유지하기 힘드다는 말과 동일한 말이다. 내가 이 위키를 만들 때 중요하게 봤던 것도 비슷했다. 멋진 말보다 실제로 돌아가는 구조, 한 번 쓰고 끝나는 정리보다 다시 읽고 다시 판단할 수 있는 구조였다.

그가 던진 LLM Wiki라는 개념도 같은 방향을 가리킨다. 사람이 문서를 다 모아놓고 끝내는 것이 아니라, LLM이 원문을 읽고 구조화된 위키를 계속 유지하면서 지식을 쌓아가는 방식이다. 원문은 원문대로 두고, 위키는 다시 읽기 좋게 정리하며, 시간이 지날수록 지식이 누적되는 형태다. 내 위키도 정확히 그 흐름을 참고했다.

그의 공식 사이트와 저작물은 그런 감각을 이해하는 데 도움이 된다.

• 공식 사이트: karpathy.ai
• 공식 GitHub: github.com/karpathy
• 대표 작업:
  • nanoGPT
  • micrograd
  • llm.c

특히 nanoGPT와 micrograd는 내가 이 위키를 보면서 느꼈던 감각과 닮아 있다. 복잡한 것을 끝까지 단순화해 보고, 결국 남는 핵심을 구현으로 증명해 보는 태도다. 이 위키도 비슷하게, 자료를 쌓는 데서 끝내지 않고 실제로 다시 읽고 다시 판단할 수 있는 구조를 만들려는 쪽으로 흘러갔다. 적어도 데이터를 저장하는 방법에 있어서는 나도 비슷한 고민을 했지만 WIKI운영자를 인공지능이 한다는 생각은 혁신적인 생각이었다. 나도 사실 개인 데이터 저장소에 대한 고민을 많이 하던 분야였고 내 채널의 이름도 공부방인데 프사는 제텔카스텐의 책 표지를 쓸만큼 이쪽분야에 관심이 있었다.

1. 그런데 왜 투자자용 위키는 달라야 하나?

왜 투자자용 위키가 필요했는가

투자 자료는 생각보다 쉽게 흩어진다. 회의록은 회의록대로, 리포트는 리포트대로, 메모는 메모대로 쌓이는데, 막상 다시 보려고 하면 “그때 왜 이런 판단을 했는지”가 잘 남아 있지 않다. 숫자만 남고 맥락이 사라지면, 자료를 많이 모아도 판단에는 잘 이어지지 않는다.

나는 옵시디언 사용자로서 투자자용 저장공간을 설계에 대해서 고민을 하고 하면서 관계형 DB방법을 도입한 방법론을 만들었지만, 잘 설계를 했어도 운영은 다른 문제였다. 일관성과 정합성 자료 표준화를 모두 지키면서 지속적으로 운영하는건 쉽지 않은 일이었다

그래서 투자자용 위키가 필요했다. 여기서 위키는 단순한 저장소가 아니다. 자료를 쌓아두는 곳이 아니라, 다시 읽었을 때 바로 연결되고 다시 판단할 수 있게 정리된 작업 공간이다. 한 번 보고 끝내는 문서가 아니라, 다음 판단으로 이어지는 문서가 필요했다.

이런 구조가 있어야 자료가 늘어도 덜 흔들린다. 어떤 종목을 왜 봤는지, 어떤 산업을 왜 중요하게 봤는지, 어떤 리스크를 먼저 봐야 하는지가 문서 안에 남는다. 결국 위키는 기록을 쌓는 도구이면서 동시에 생각을 정리하는 도구가 된다.

이 위키로 무엇을 만들려고 했는가

처음 목표는 단순했다. 파일을 넣으면 이름이 정리되고, 내용을 읽고, 종류를 판단한 다음, 알맞은 자리로 들어가게 만드는 것이다. 회의록이면 회의록답게, 리포트면 리포트답게, 개인 메모면 개인 메모답게 정리되도록 하는 것. 겉으로 보면 파일 정리지만, 실제로는 투자 판단의 재료를 다시 쓰기 쉽게 만드는 작업이다.

정리의 핵심은 문서를 예쁘게 만드는 것이 아니었다. 나중에 다시 찾고, 다시 연결하고, 다시 비교할 수 있게 만드는 것이 핵심이었다. 제목을 맞추는 이유는 찾기 위해서고, 출처를 남기는 이유는 검증하기 위해서고, 관련 기업이나 산업을 연결하는 이유는 같은 재료가 다른 판단으로 이어질 수 있게 하기 위해서다.

인공지능 코딩 툴에서 스키마는 어떤 역할을 하는가

스키마라는 말은 어려워 보이지만, 쉽게 말하면 “문서를 어떤 모양으로 저장할지에 대한 약속”이다. 제목은 어디에 넣고, 날짜는 어디에 넣고, 출처는 어떻게 남기고, 태그는 어떤 식으로 붙일지 정해두는 것이다. 이렇게 약속을 정해두면 나중에 사람이 읽어도 편하고, 기계가 읽어도 덜 헷갈린다. 인공지능 코딩툴(클로드 Code, chatGPT Codex)는 명령어를 읽고 코딩을 한다. 매번 똑같은 명령을 일일이 칠 수 없으니 헌법이나 법전같은 상위 명세서가 있어야 한다. 코드를 짤때 늘 염두에둬야하는 상위개념, 페르소나들, 에이전트들을 저장해놓고 다시시작할때도 잊지 않도록 다시 불러오게 되는 것이다. 이 구조를 알고 나아 이후의 내용을 이해할 수 있다.

나는 스키마를 만들 때 네 가지를 특히 중요하게 봤다.

1. 원문과 해석을 섞지 않을 것
   • 원문은 원문대로 남기고, 내 해석은 따로 둔다.
   • 그래야 나중에 내 판단이 틀렸는지 다시 검토할 수 있다.
2. 서로 다른 종류의 문서는 서로 다른 칸에 둘 것
   • 회의록, 리포트, 개인 메모, 산업 설명, 회사 기록은 같은 방식으로 다루지 않는다.
   • 문서 성격이 다르면 저장 방식도 달라야 한다.
3. 상태와 연결이 눈에 보여야 할 것
   • 이 문서가 아직 살아 있는지, 끝난 것인지, 보강이 필요한지 보여야 한다.
   • 관련 기업이나 산업도 한 번에 연결돼야 한다.
4. 같은 내용을 두 번 관리하지 않을 것
   • 산업 설명과 큰 지도 문서가 같은 범위를 겹쳐서 관리하면 나중에 틀어진다.
   • 그래서 역할을 분리했다.

이 원칙을 바탕으로 문서 구조를 짰다. 처음에는 복잡해 보여도, 실제 기준은 단순하다. 다시 찾기 쉬운가, 다시 연결하기 쉬운가, 다시 검토하기 쉬운가. 결국 이 셋만 붙잡고 설계했다.

실제 폴더 구조도 이 생각을 그대로 따랐다. 원본은 01_inbox와 02_raw에 두고, 다시 읽기 좋은 정리는 04_wiki에 두고, 내 생각과 복기는 05_personal에 두었다. 01_inbox는 아직 정리되지 않은 입구이고, 02_raw는 원문을 보관하는 창고에 가깝다. 반대로 04_wiki는 다시 꺼내 보기 좋게 정리한 지식 공간이고, 05_personal은 그걸 보고 내가 남긴 생각을 적는 공간이다. 폴더 이름만 보면 숫자가 앞에 붙어 있지만, 실제로는 문서가 지나가는 순서와 역할이 다 들어 있다.

운영 문서가 필요한 이유

위키를 실제로 굴리다 보면, 자료 문서만으로는 부족하다는 걸 곧 알게 된다. 문서를 어떻게 저장할지, 어디까지 표준으로 볼지, 무엇을 자동화할지, 세션이 끝나면 무엇을 먼저 다시 읽을지 같은 운영 기준이 따로 필요했다. 그래서 이 볼트에는 자료를 담는 문서들 말고도, 운영을 설명하는 md들이 따로 생겼다.

여기서 LLM CLI는 사람 손을 대신하는 작업자처럼 움직인다. 먼저 SCHEMA.md와 AGENTS.md를 읽고, 지금 무엇을 해야 하는지 파악한다. 그다음 관련 문서를 열어 내용을 확인하고, 필요한 곳을 고치고, 다시 저장한다. 작업이 끝나면 lint나 검사를 돌려서 구조가 깨지지 않았는지 다시 본다. 결국 CLI는 문서를 읽고, 문서를 쓰고, 다시 검증하는 흐름으로 이 위키를 운영한다.

이 운영 md들은 자료를 담는 문서와 역할이 다르다. 자료 문서가 “무엇을 봤는가”를 남긴다면, 운영 문서는 “이 볼트를 어떤 규칙으로 굴릴 것인가”를 남긴다. 내가 처음에는 이 둘을 조금 헷갈렸는데, 실제로 운영을 해 보니 둘은 반드시 분리돼야 했다. 자료는 계속 쌓이지만, 운영 규칙은 자주 바뀌지 않아야 하기 때문이다. 그래서 이 md들은 볼트의 법전처럼 두는 것이 맞았다.

쉽게 말하면, 일반 프로그램을 만들 때도 기능명세서가 있고 입출력 규격이 있다. 입력이 들어오면 어떤 모양으로 처리하고, 어떤 형태로 결과를 내보낼지 미리 정해 두는 것이다. 이 위키도 비슷하다. LLM이 문서를 읽고, 읽은 내용을 정리하고, 다시 문서로 써 내려가는 과정이 반복되는데, 그 결과물이 어떤 구조로 나와야 하는지 미리 정해 둬야 한다. 그래서 이 위키는 단순한 메모장이 아니라, LLM이 작업한 산출물을 어떤 형태로 출력할지 정해 두는 구조 명세서에 가깝다.

• SCHEMA.md는 볼트 전체의 설계도다. 문서가 어떤 모양이어야 하는지, 어떤 폴더에 무엇을 두는지, 엔티티와 태그와 MOC를 어떻게 나누는지를 정한다.
• AGENTS.md는 현재의 운영 원칙이다. 작업하기 전에 무엇을 먼저 읽고, 어떤 순서를 지키고, 무엇을 바꾸면 안 되는지 적어 둔 실행 규칙이다.
• OPERATOR.md는 이 볼트를 실제로 쓰는 사람의 성향을 적은 문서다. 무엇을 좋아하고 무엇을 싫어하는지, 어떤 결정을 빠르게 내리는지, 어떤 스타일의 결과물을 선호하는지 남긴다.
• SESSION_NOTE.md는 세션 세이브 파일이다. 지금 어떤 작업을 하고 있었는지, 무엇을 끝냈고 무엇이 남았는지, 다음에 어디서 이어가야 하는지 적는다.
• STARTUP_CONTEXT.md는 다시 열 때 읽는 시작 패키지다. 다음 세션이 들어오면 가장 먼저 봐야 할 것들을 한 파일에 묶어 둔 것이다.
• CLAUDE_HANDOFF.md는 다른 AI나 후속 운영자에게 넘길 때 보는 인수인계 문서다. 이 볼트가 왜 이렇게 생겼는지, 어떤 순서로 읽어야 하는지, 어디를 건드리면 안 되는지 적는다.

읽는 순서도 정해 두는 편이 낫다.

• 먼저 SCHEMA.md를 읽어서 문서 구조와 역할을 잡는다.
• 그다음 AGENTS.md로 지금 해야 할 일과 하지 말아야 할 일을 본다.
• 그 다음에는 필요에 따라 OPERATOR.md, SESSION_NOTE.md, STARTUP_CONTEXT.md, CLAUDE_HANDOFF.md를 펼친다.

이렇게 해 두면 운영 문서들은 서로 겹치지 않는다. SCHEMA.md는 설계, AGENTS.md는 실행 규칙, OPERATOR.md는 사람의 성향, SESSION_NOTE.md는 세션의 현재 상태, STARTUP_CONTEXT.md는 재개용 압축본, CLAUDE_HANDOFF.md는 인수인계서다. 역할이 다르니 한 문서가 다른 문서의 일을 대신하지 않는다. 이 분리가 없으면 문서가 늘어날수록 오히려 기준이 흐려진다.

이 문서들이 따로 있는 이유는 단순하다. 자료를 저장하는 규칙과, 그 자료를 운영하는 규칙은 다르기 때문이다. 나는 처음에 이 차이를 얕봤고, 그래서 문서가 많아질수록 오히려 기준이 흐려질 뻔했다. 그런데 운영 md를 따로 빼 두니, 자료는 자료대로 쌓이고 운영은 운영대로 유지되는 구조가 생겼다. 덕분에 세션이 끊겨도 다시 이어받기 쉬워졌고, 다른 LLM이 들어와도 어디부터 읽어야 하는지 분명해졌다.

아예 그림으로 보면 더 쉽다. 스키마 문서에 넣어 둔 구조도도 이런 식이다.

LLM WIki/
├── 01_inbox/        # 아직 정리하지 않은 입구
├── 02_raw/          # 원문 보관 창고
├── 03_my_work/      # 내가 직접 다루는 작업 공간
├── 04_wiki/         # 다시 읽기 좋게 정리한 지식 공간
│   ├── index/       # 안내판과 목차
│   ├── invest/      # 투자 관련 지식
│   └── knowledge/   # 일반 지식
└── 05_personal/     # 생각과 복기 공간

이 그림을 본 뒤부터는 폴더 이름을 외우는 것보다 역할을 이해하는 쪽이 더 중요하다고 느꼈다. 어디에 두느냐가 곧 그 문서의 운명이 되기 때문이다.

이 구조 안에서 각 개념의 자리도 자연스럽게 나뉜다. raw는 01_inbox와 02_raw에서 원문을 받아들이고, wiki는 04_wiki에서 다시 읽기 좋은 형태로 정리된다. 엔티티는 04_wiki/invest/companies나 04_wiki/invest/industries처럼 실제 대상을 두는 자리로 가고, MOC는 04_wiki/index에서 그 대상들을 찾아가게 만드는 안내판이 된다. 태그는 이 모든 폴더에 걸쳐 상태와 성격을 표시하는 공통 표식이고, 05_personal은 그걸 읽고 남긴 내 생각을 적는 공간이다. 이렇게 나눠 두니 문서가 어디서 왔고 어디로 가는지가 훨씬 분명해졌다.

여기에 MOC와 엔티티도 각각 자리를 잡았다. 엔티티는 기업, 산업, 인물처럼 실제로 반복해서 불러야 하는 대상이 들어가는 곳이고, MOC는 그 대상들을 한눈에 훑게 해 주는 큰 지도 역할을 한다. 그래서 엔티티는 04_wiki/invest/companies나 04_wiki/invest/industries처럼 실제 대상을 두는 쪽에 가깝고, MOC는 04_wiki/index처럼 그 대상을 찾아가는 안내판 쪽에 가깝다. 이 배치를 해 두니 “무엇이 대상이고, 무엇이 안내판인지”가 폴더만 봐도 한 번에 보였다.

raw와 wiki를 분리

처음에는 문서를 그냥 한곳에 모아두면 되는지 알았고 열심이 폴더 분류하고, 태그도 열심이 달고 링크도 열심이 달았다. 그런데 실젤 운영하다보면 미묘한 분류의 차이가 분기가 되어 데이터가 거스를수 없을정도로 일관성이 깨저버린다. 실제로 해보면 원문 그대로 두어야 하는 자료와, 다시 읽기 좋게 정리해야 하는 자료는 성격이 달랐다. 그래서 raw와 wiki를 나눴다. raw는 말 그대로 원본 창고에 가깝다. 회의록 원문, 리포트 원문, 기사 원문처럼 손대기 전에 그대로 남겨둬야 하는 자료를 두는 곳이다. wiki는 그 원문을 다시 읽기 쉽도록 정리한 곳이다. 한 번 보고 끝낼 자료가 아니라, 다시 참고하고 다시 연결할 가치가 있는 것들을 모아두는 쪽이다.

이 둘을 나누는 이유는 실용적이다. 원문은 나중에 검증할 때 필요하고, 정리본은 나중에 판단할 때 필요하다. 원문과 정리본이 한곳에 섞여 있으면, 어디까지가 사실이고 어디부터가 해석인지 흐려진다. 반대로 나눠 두면 한쪽은 증거로 남고, 다른 한쪽은 생각을 쌓는 자리가 된다. 이 분리가 있어야 LLM도 더 적은 비용으로 자료를 읽고, 내 판단을 덜 헷갈리게 도와줄 수 있다.

개인 생각과 복기 공간은 왜 따로 두었는가

05_personal은 원문도 아니고, 정리본도 아니다. 여기는 내가 그 자료를 보고 어떻게 느꼈는지, 왜 그렇게 판단했는지, 다음에는 무엇을 다르게 볼지 적는 자리다. 같은 문서를 보고도 어떤 날은 낙관적으로 읽히고 어떤 날은 보수적으로 읽히는데, 그 차이를 남겨두지 않으면 나중에 내가 어떤 논리로 움직였는지 다시 따라가기 어렵다.

이 공간을 따로 둔 이유는 아주 단순하다. raw는 사실을 남기고, wiki는 정리를 남기고, personal은 판단의 흔적을 남긴다. 이 셋이 섞이면 나중에 복기하기 어렵다. 반대로 분리해 두면, “자료 자체가 어땠는가”, “정리하면 무엇이 보였는가”, “나는 그때 왜 그렇게 봤는가”를 각각 따로 볼 수 있다. 투자에서는 이 세 가지가 모두 중요하다. 자료만 있어도 안 되고, 정리만 있어도 안 되고, 내 판단 기록이 없으면 결국 같은 실수를 반복하기 쉽다.

2. 어떻게 구조를 세웠는가

왜 표준화가 필요했는가

처음에는 단순히 옵시디언 안에 투자 위키를 저장할 공간을 설계하는 일부터 시작했다. 그런데 일을 하다 보니 저장공간만 정해서는 부족했다. 그 공간 안에서 쓰일 용어들, 예를 들면 기업명, 산업명, 태그명명규칙, 연결지도를 만드는 규격까지 몽땅 정의해야 했다. 어디에 무엇을 넣는지만 정하면 되는 줄 알았는데, 실제로는 그 안에서 같은 말을 같은 방식으로 쓰게 만드는 일이 더 중요했다.

표준화가 필요한 이유는 단순하다. 같은 기업이 문서마다 조금씩 다른 이름으로 적히면 나중에 다시 찾기 어렵다. 같은 산업이 어떤 곳에서는 회사처럼, 어떤 곳에서는 개념처럼 적히면 연결이 꼬인다. 그래서 기업명 같은 것은 하나의 이름을 기준으로 두고, 그 아래에 여러 별칭을 붙이는 방식이 필요했다. 마치 관계형 데이터베이스처럼 보이지만, 실제로는 훨씬 쉬운 이야기다. “한 가지 대상에는 하나의 표준 이름을 두고, 나머지는 그 이름으로 모이게 한다”는 것이다.

YAML도 같은 이유로 필요했다. YAML은 문서 앞에 붙는 표식이고, 이 표식이 있어야 나중에 LLM이 문서의 성격을 빠르게 알아볼 수 있다. 무엇이 제목인지, 언제 만들어졌는지, 어디서 왔는지, 어떤 상태인지 먼저 알려주는 작은 안내판이라고 보면 된다.

태그와 링크를 구분한 것도 같은 이유다. 태그는 문서가 어떤 분류에 속하는지 보여주는 표시이고, 링크는 실제 대상과 연결하는 줄이다. 예를 들어 #status/active 같은 태그는 이 문서가 지금 살아 있는지, 검토 중인지, 끝난 것인지를 보여준다. 반면 [[삼성전자]] 같은 링크는 이 문서가 실제로 어떤 기업과 연결되는지를 보여준다. 이 둘을 섞어 쓰면 분류와 연결이 헷갈리지만, 나눠 두면 상태와 관계를 따로 볼 수 있다.

태그도 계층 구조가 있어서 설계가 쉽지 않았다. #status/active처럼 상위와 하위 의미를 같이 담는 방식은 편하지만, 계층을 어떻게 자를지, 어디까지 세분화할지, 비슷한 말은 같은 태그로 모을지 아니면 따로 둘지 정해야 한다. 동의어와 계층화가 함께 들어오면 사실상 볼트 설계는 기업의 데이터베이스를 설계하는 일과 크게 다르지 않다. 다만 이걸 데이터베이스 전공자가 아니라 일반인이 직접 고민해야 한다는 점이 생각보다 쉽지 않을것으로 보인다.

명사는 엔티티로, 형용사나 상태는 태그로 두는 원칙도 도움이 됐다. 기업, 산업, 인물처럼 실체가 있는 것은 따로 이름을 가진 대상으로 두고, active, monitoring, upgraded처럼 상태를 나타내는 말은 태그로 둬야 나중에 뒤섞이지 않는다. 이런 감각은 데이터베이스 모델링 책에서 보던 정규화의 기본 원칙과 닿아 있었다. 무엇이 주체이고 어떤것이 대상이고 무엇이 대상의 상태인지 나누는 일이다. 이 원칙을 위키에 가져오니, 문서와 표식의 역할이 훨씬 또렷해졌다.

실제로 이렇게 나눈 사례도 많았다.

• 엔티티로 둔 것들
  • [[삼성전자]], [[SK하이닉스]], [[알지노믹스]]처럼 기업 자체는 엔티티로 두었다.
  • [[정유]], [[반도체_메모리]], [[AI_에이전트_결제]]처럼 산업이나 개념도 반복해서 참고할 가치가 있으면 별도 문서로 분리했다.
  • [[워렌버핏]], [[홍길동]]처럼 자주 등장하는 인물도 별도 표준명으로 관리했다.
• 태그로 둔 것들
  • #status/active, #status/monitoring, #status/upgraded, #status/closed처럼 문서의 상태를 나타내는 것은 태그로 뒀다.
  • #holding/hold, #holding/watch처럼 포트폴리오 상태도 태그로 뒀다.
  • #topic/llm_wiki, #writing/blog처럼 문서의 성격을 알리는 값도 태그로 둬서 검색 기준으로 쓸 수 있게 했다.
• MOC로 보낸 것들
  • MOC_특수상황은 여러 특수 이벤트를 한눈에 보는 큰 지도 역할로 뒀다.
  • MOC_에너지섹터는 에너지 관련 기업과 산업 노드를 묶는 안내판 역할로 뒀다.
  • MOC_반도체섹터, MOC_바이오섹터, MOC_포트폴리오처럼 여러 문서를 한 번에 훑는 허브는 MOC로 두었다.

엔티티나 YAML을 고치지 않고 버전관리도 느슨하게 두면, 금방 문제가 드러난다는 것도 경험했다. 처음에는 파일 하나만 고치면 끝날 것 같았는데, 실제로는 회사명 하나를 바꾸면 연결된 문서가 줄줄이 흔들리고, YAML 키 하나가 다르면 Dataview 결과가 비거나 엉뚱한 문서가 잡혔다. 어떤 날은 summary를 조금 바꾸는 정도로 끝났지만, 다른 날은 표준명과 별칭, 연결된 MOC와 raw 문서까지 같이 다시 맞춰야 했다. 버전관리가 없었다면 이 수정이 어디서 시작됐고 어디까지 반영됐는지 추적하기 어려웠을 것이다.

이 일을 겪고 나서야 엔티티와 YAML은 단순한 부가 정보가 아니라, 위키 전체를 붙잡는 뼈대라는 걸 분명히 느꼈다. 뼈대가 흔들리면 문서가 많아질수록 오히려 더 불안해진다. 그래서 결국 작은 수정이라도 기록을 남기고, 바뀐 기준을 다시 확인하고, 연결된 문서까지 함께 보는 습관이 필요했다.
그다음 자연스럽게 떠오른 것이 버전관리였다. 구조를 잡는 것만으로는 부족하고, 그 구조가 바뀌었을 때 이전 상태와 비교할 수 있어야 했다.

표준화가 여기서 멈추지 않았던 이유도 비슷하다. 이름을 하나로 맞추는 것으로 끝나지 않고, 같은 대상이 여러 파일로 갈라지지 않게 막아야 했기 때문이다. 회사 엔티티는 하나의 canonical file로 수렴시키고, 산업도 같은 원칙을 적용하고, 사람만 동명이인 예외를 소속과 직함으로 풀어내는 식으로 중복을 줄였다. 그 과정에서 새 리포트가 들어와도 기존 엔티티를 갱신하고 compiled_from만 더하는 방식이 자리를 잡았다. 결국 표준화는 이름 정리보다 중복을 막는 장치였고, 중복을 막아야 다음에 다시 찾을 때 비용이 덜 들었다.

중복을 줄이고 나서는 운영 최적화가 따라왔다. 린터가 vault 전체를 매번 훑는 방식은 파일이 늘수록 비효율이 컸고, 같은 frontmatter를 반복 파싱하는 것도 낭비였다. 그래서 변경분만 보는 흐름으로 옮기고, frontmatter는 캐시를 두고, 공통 정규화는 라이브러리로 묶었다. lint_all.py가 company_sync -> moc_lint -> lint_entity_duplicates 순서를 고정하고, 변경된 경로에 따라 필요한 검사만 선택하는 식으로 바뀐 것도 같은 맥락이다. 속도를 빠르게 하려는 목적도 있었지만, 더 큰 목적은 같은 실수를 반복하지 않게 만드는 데 있었다.

git이 왜 반드시 필요했는가

위키를 운영하다 보면 문서는 계속 바뀐다. 누군가는 문서를 고치고, 누군가는 이름을 바꾸고, 누군가는 연결을 추가한다. 문제는 이런 변화가 쌓이면 “어느 시점에 무엇이 어떻게 바뀌었는지”가 금세 흐려진다는 점이다. 그때 필요한 것이 git이다. git은 문서의 변경 이력을 남기고, 무엇이 언제 바뀌었는지 다시 볼 수 있게 해 주는 기록 장치다.

git은 쉽게 말하면 문서의 타임머신이다. 지금 상태만 보는 것이 아니라, 이전 상태와 비교할 수 있게 해 준다. 누가 무엇을 바꿨는지, 어떤 줄이 추가됐는지, 어디서부터 틀어졌는지를 되돌아볼 수 있다. 처음에는 이게 조금 번거롭게 느껴질 수 있지만, 문서가 많아질수록 오히려 필수에 가까워진다.

위키에 버전관리가 필요한 이유도 여기서 나온다. 위키는 단순한 메모장이 아니라 계속 커지는 운영 시스템이기 때문이다. 엔티티, YAML, MOC, 프롬프트, 스크립트가 서로 연결돼 있으니, 하나를 고치면 다른 곳도 영향받을 수 있다. 버전관리 없이 이걸 다루면, 잘못된 수정이 들어왔을 때 어디서부터 다시 봐야 하는지 알기 어렵다. 반대로 버전관리가 있으면, 문제를 발견했을 때 바로 이전 상태와 비교하고, 안전하게 되돌리고, 수정 이유를 남길 수 있다.

내가 이 시스템을 운영하면서 가장 많이 느낀 것도 결국 이것이었다. 위키는 점점 쌓이고, 연결은 점점 많아지는데, 기록이 없으면 그 복잡도를 감당하기 어렵다. 그래서 git은 선택이 아니라 운영의 바닥에 가까웠다. 문서가 많아질수록 git이 필요한 이유는 더 분명해졌다. 내가 생각한 위키는 결국 “다시 읽히는 문서”여야 했고, git은 그 다시 읽힘을 가능하게 해 주는 안전장치였다.

왜 그렇게 구조와 표준화에 집착했는가

처음에는 나도 구조를 처음부터 너무 세게 잡는 것 아니냐는 말을 들었다. 일단 빨리 시작하고 나중에 다듬어도 되지 않느냐는 조언도 많았다. 하지만 실제로 여러 시스템이 커지는 과정을 보면서, 초반에 대충 시작한 구조가 나중에 얼마나 큰 기술부채가 되는지 여러 번 봤다. 프로젝트가 중반쯤 가면 회의가 늘고, 책임 소재가 흐려지고, 작은 정의 하나를 두고도 고함과 싸움과 암투가 생긴다. 그때는 이미 손대기 어려울 만큼 구조가 얽혀 있다.

나는 내 위키를 그렇게 만들고 싶지 않았다. 이건 남의 프로젝트가 아니라 내 작업 공간이고, 결국 내가 끝까지 써야 하는 시스템이다. 내 껀데, 나는 나와 싸울 수는 없다. 그래서 가능한 모든 경우의 수를 설계 단계에서 최대한 넣으려고 했다. 어떤 이름을 쓸지, 어떤 태그를 쓸지, 어떤 연결은 허용하고 어떤 연결은 막을지, 어떤 문서는 raw에 남기고 어떤 문서는 wiki로 올릴지. 이런 것들을 미리 많이 생각해 두면 나중에 덜 흔들린다.

이 과정에서 Claude와 ChatGPT 5.5의 검수도 받았다. 혼자만의 감으로 밀어붙이면 보이지 않는 빈틈이 남을 수 있기 때문이다. 서로 다른 모델의 관점을 빌려서 구조를 다시 보면, 내가 놓친 부분이나 과하게 복잡한 부분이 더 잘 보였다. 결국 내가 집착한 것은 형식 그 자체가 아니라, 나중에 내가 나를 괴롭히지 않게 만드는 안전한 구조였다. 초반에 시간을 쓰더라도 그 시간이 뒤에 오는 혼란과 충돌을 줄여준다면, 그건 낭비가 아니라 투자라고 봤다.

실제로 역할도 나눠 썼다. Claude는 스키마와 템플릿을 설계하고, 문서 구조를 다듬고, 볼트 안의 엔티티와 MOC 관계를 정리하는 쪽에 강했다. Codex는 파이썬 운영 스크립트와 CLI 자동화, 세션 세이브, 시작 파일 같은 운영 도구를 붙이는 쪽을 맡았다. ChatGPT 5.5는 중간중간 설계 검수와 대안 제시에 도움을 줬다. 같은 문제를 서로 다른 렌즈로 보면, 내가 보지 못한 과잉 복잡성과 빠진 예외가 더 잘 드러났다.

실패 사례도 분명했다. 한번은 한양이엔지 리포트에서 한글이 깨져 보였는데, 처음에는 파일이 망가진 줄 알았다. 실제로는 콘솔 인코딩 문제였지만, 당시에는 파일 자체와 표시 문제가 섞여 보여서 한참 돌아가야 했다. 또 status와 #status/*를 혼용하던 시기에는 MOC 특수상황 쿼리가 비어 보이거나 일부만 잡히는 일이 있었다. 이런 문제를 겪고 나서야 “한 파일만 맞추는 것”이 아니라 “연결된 구조 전체를 맞추는 것”이 훨씬 중요하다는 걸 체감했다.

운영 수치도 남겨두면 감이 더 분명해진다. 첫 1주일 동안 원본 raw 파일은 40개가 넘게 들어왔고, 엔티티는 열 개 이상 새로 만들었다. SCHEMA는 버전 기준으로 여러 차례 손을 봤고, lint도 반복해서 돌렸다. 단순히 파일을 정리한 게 아니라, 정리한 방식이 다시 돌아가는지 확인하는 데 시간을 썼다. 숫자로 보면 번거로워 보일 수 있지만, 이런 숫자가 있어야 운영이 취미가 아니라 시스템이 된다.

그렇게 구조와 기록을 같이 보게 되니, 왜 처음부터 설계를 세게 잡아야 했는지도 더 분명해졌다.

MOC가 뭔가요?

MOC는 처음부터 딱 떨어지게 이해한 개념은 아니었다. 산업 문서는 하나의 주제나 업종을 설명하는 본문에 가깝고, MOC는 그보다 위에서 여러 문서와 엔티티를 한 번에 훑게 해 주는 큰 지도에 가깝다. 산업이 “이건 이런 업종이다”라는 설명이라면, MOC는 “이 업종과 관련된 회사와 사건과 문서를 여기서부터 보자”라고 안내하는 쪽이다.

이걸 데이터베이스로 비유하면 MOC는 view와 비슷하다. 원본 데이터는 따로 있고, 그 위에 자주 보는 관점만 다시 묶어 보여주는 것이다. 실제 문서는 회사별로 흩어져 있어도, MOC에서는 관련된 문서만 한 번에 보이게 할 수 있다. 그래서 MOC는 내용을 새로 만드는 문서라기보다, 이미 있는 문서를 보는 방식이다. 이 비유를 붙이고 나니 산업과 MOC의 차이가 훨씬 선명해졌다. 산업은 정의에 가깝고, MOC는 그 정의를 따라 재구성한 화면에 가깝다.

이 차이를 실제 옵시디언 Dataview와 연결하는 과정도 꽤 오래 걸렸다. 처음에는 산업과 MOC를 비슷한 문서로 보고 함께 묶으려 했는데, 그렇게 하면 같은 대상을 두 곳에서 관리하게 되어 금방 어긋났다. 나중에는 산업 문서는 산업 문서대로 개념을 설명하고, MOC는 Dataview로 여러 파일을 모아 보여주는 안내판 역할만 하게 바꾸었다. 예를 들어 특수상황은 별도 이벤트 문서들을 Dataview로 모으고, 에너지 섹터는 관련 회사와 산업 노드를 함께 보이게 했다. 이 과정을 거치면서 MOC는 내용 자체를 많이 쓰는 문서가 아니라, 이미 쌓인 문서들을 한눈에 꺼내 보게 하는 장치라는 걸 깨달았다.

구현도 한 번에 되지는 않았다. 처음에는 type, status, holding_status 같은 구형 필드를 쿼리에서 직접 읽으면서 시작했는데, 문서가 늘어나자 여기저기서 안 맞기 시작했다. 그래서 최신 SCHEMA 기준으로 content_type과 태그 중심으로 다시 맞추고, _template 같은 제어 문서는 제외하고, 산업과 MOC가 겹치지 않게 역할을 나눴다. 겉으로는 쿼리 몇 줄 바꾸는 일 같아 보여도, 실제로는 문서 구조와 조회 구조를 동시에 다시 짜는 일이었다. 이때 느낀 건, MOC는 단순 목차가 아니라 볼트 전체의 탐색 규칙이라는 점이었다. 규칙이 흔들리면 지도도 흔들리고, 지도가 흔들리면 아무리 좋은 문서가 있어도 다시 찾기 어렵다.

왜 파이썬 운영모드가 필요한가

LLM(AI)로 옵시디언 위키 볼트를 운영하려면, 단순히 글을 쓰는 것만으로는 부족하다. 파일을 읽고, 이름을 바꾸고, 원문을 분류하고, 엔티티를 갱신하고, MOC를 다시 묶는 일은 결국 반복 작업이다. 이 반복 작업을 손으로만 하면 오래가기 어렵고, 같은 실수를 다시 하게 된다. 그래서 파이썬 운영모드가 필요했다. 파이썬은 이런 반복 작업을 한 곳에 모아서 다룰 수 있고, 경로 처리나 인코딩 같은 자잘하지만 자주 깨지는 문제를 공통 규칙으로 묶을 수 있다.

실제로는 ops/_shared.py 같은 공통 라이브러리를 두고, moc_lint, inbox_ingest, company_sync 같은 스크립트가 그 공통 규칙을 같이 쓰게 만들었다. 그 전에는 같은 경로를 각 스크립트가 조금씩 다르게 다뤄서, 어떤 날은 한글이 깨지고 어떤 날은 상대경로가 틀어졌다. 공통 라이브러리를 두고 나서야 경로와 인코딩, 로그 형식을 한 번에 고정할 수 있었다. 작은 스크립트 하나가 아니라, 반복 실수 전체를 줄이는 구조를 만든 셈이다.

왜 CLI가 더 적합한가

위키 운영은 눈으로 예쁘게 보는 일보다, 규칙대로 자동으로 돌리는 일이 더 많다. GUI는 편하지만, 운영 흐름을 자꾸 끊고 수동 확인을 늘린다. 반대로 CLI는 명령 하나로 같은 절차를 다시 돌릴 수 있고, 시작 파일과 세션 세이브와도 잘 맞는다. 내가 만든 START_LLM_WIKI.bat 같은 시작 파일도 결국 CLI 흐름 위에서 가장 잘 작동한다. 다시 말해, 위키를 꾸미는 데는 GUI가 편하지만, 위키를 운영하고 유지하는 데는 CLI가 훨씬 안정적이다.

그래서 START_LLM_WIKI.bat와 ops 루틴이 필요했다. 시작 파일은 다시 들어왔을 때 어디부터 읽고 어디서부터 이어갈지를 정해 주는 입구이고, ops 루틴은 반복 작업을 정리하는 작업대다. 둘이 함께 있어야 위키가 단순한 폴더가 아니라, 다시 시작할 수 있는 운영 환경이 된다. 나는 이 구조가 있어야 LLM이 매번 새로 시작하지 않고, 이전 세션의 맥락을 받아서 같은 방식으로 움직일 수 있다고 봤다.

세션 세이브와 시작 파일은 왜 만들었는가

LLM은 세션을 내리면 그동안의 작업 기억이 모두 날아가기 때문에, 맥락을 유지하는 방식에 대한 고려가 처음부터 필수였다. 이 문제를 풀지 않으면, 아무리 많은 문서를 쌓아도 다음에 다시 들어왔을 때는 결국 처음부터 다시 설명해야 한다. 그래서 단순한 저장이 아니라, 다음 세션이 바로 이어받을 수 있는 구조를 만드는 일이 작업의 핵심 중 하나가 되었다.

여기에 더해서, 다시 열었을 때 전의 작업을 바로 이어갈 수 있도록 게임 세이브 같은 장치도 만들었다. SESSION_NOTE.md에는 그때까지의 운영 맥락과 남은 작업을 적어두고, STARTUP_CONTEXT.md에는 시작할 때 읽어야 할 핵심 정보를 모아두었다. 그리고 START_LLM_WIKI.bat 같은 시작 파일을 통해 아예 실행하자마자 그 맥락을 다시 불러오도록 했다. 단순히 파일을 여는 것이 아니라, 이전 세션에서 멈춘 자리까지 다시 데려오는 장치에 가깝다.

이 구조를 만든 이유도 결국 같았다. LLM은 화면을 닫는 순간 기억이 사라지기 때문에, 사람이 “아까까지 여기 했지”라고 말해 줘야만 이어갈 수 있다. 그런데 그 말을 사람이 매번 길게 다시 하면 비효율적이니, 그 역할을 파일이 대신 하게 한 것이다. SESSION_NOTE는 진행 중인 저장 슬롯이고, STARTUP_CONTEXT는 다시 시작할 때 읽는 안내문이다. 이렇게 나누면 현재 상태와 재개 지점이 분리돼서 훨씬 안정적으로 이어받을 수 있다.

왜 문서 유형별 프롬프트를 나눴는가

처음에는 LLM에게 그냥 “잘 정리해 줘”라고만 시키면 되는 줄 알았다. 그런데 실제로 돌려보니 회의록, IR, 콥데이, 브로커 리포트, 신약 발굴 자료는 각각 필요한 정보의 결이 달랐다. 어떤 문서는 발표자와 질의응답이 중요하고, 어떤 문서는 숫자와 목표주가가 중요하고, 어떤 문서는 파이프라인과 임상 단계가 중요하다. 하나의 프롬프트로 다 처리하려고 하면 결국 너무 밋밋해지거나, 반대로 너무 장황해져서 쓸모가 떨어졌다.

그래서 문서 유형별로 프롬프트를 따로 만들었다. 바이오/제약 IR은 파이프라인과 사업화 전략을 중심으로, 신약 발굴 자료는 타깃과 소싱, 임상 단계와 라이선스 구조를 중심으로, 증권사 리포트는 숫자와 투자 논리, 리스크와 시나리오를 중심으로 따로 다루게 했다. 같은 “요약”이라도 무엇을 살리고 무엇을 뒤로 보낼지가 달라야 했다.

이 작업을 하면서 느낀 건, 프롬프트는 단순한 명령문이 아니라 문서를 읽는 습관을 만든다는 점이었다. 어떤 항목을 먼저 보게 할지, 어떤 표현을 오래 유지할지, 무엇을 절대 생략하지 말아야 할지가 결국 프롬프트 안에 들어간다. 그래서 프롬프트를 잘 만든다는 건 LLM에게 일을 시키는 게 아니라, 내가 원하는 읽는 방식과 쓰는 방식을 미리 합의해 두는 일에 가까웠다.

또 하나 중요한 건, 프롬프트도 한 번에 완성되는 게 아니었다는 점이다. 처음 만든 문장은 자주 너무 축약됐고, 때로는 해상도가 낮았고, 때로는 사용자 의도를 너무 뭉개버렸다. 그래서 프롬프트를 고친다는 것은 단순히 문장을 바꾸는 일이 아니라, 어떤 정보가 중요하고 어떤 정보는 덜 중요하게 다룰지를 계속 조정하는 일이었다. 이 과정이 쌓이면서 문서 유형별로 다른 기준을 두는 이유가 더 분명해졌다.

3. 무엇을 다듬고 배웠는가

결국 무엇을 배웠는가

가장 크게 배운 건, 위키는 문서 저장소가 아니라 운영 체계라는 점이다. 자료를 많이 쌓는 것보다 중요한 건, 자료가 쌓였을 때 다시 읽히는 구조를 만드는 것이다. 그 구조가 없으면 아무리 많은 파일이 있어도 결국 다시 처음부터 찾게 된다.

또 하나 배운 건, 자동화는 사람을 대체하는 게 아니라 사람의 반복 실수를 줄이는 장치라는 점이다. 내가 자주 틀리는 부분은 생각보다 뻔했다. 경로, 인코딩, 이름 규칙, 상태 표기, 쿼리 조건 같은 것들이다. 이건 재능보다 습관의 문제에 가깝다. 그래서 반복 실수를 로그로 남기고, 그 로그를 바탕으로 스크립트와 규칙을 다듬는 방식이 맞았다.

마지막으로, 설명의 난이도가 중요하다는 것도 배웠다. 이 문서는 나만 읽는 메모가 아니라 나중에 다시 읽어도 이해가 돼야 하는 운영 기록이다. 그래서 비전공자도 흐름을 따라갈 수 있도록 쉬운 말과 전문 용어를 섞는 비율을 계속 조정하고 있다.

결국 내가 만들고 싶은 것은 단순한 아카이브가 아니다. 시장에서 보고 들은 것들을 쌓아두는 창고가 아니라, 그 자료들이 다시 판단으로 돌아오는 통로가 필요했다. 위키는 그 통로를 만들기 위한 장치이고, 스키마와 태그와 엔티티와 MOC는 그 통로를 막히지 않게 하는 부품이다. 처음에는 다소 복잡해 보였지만, 지금은 이 구조가 있어야 투자 판단이 더 적은 비용으로, 더 일관되게 돌아갈 수 있다는 생각이 분명해졌다.

그래서 이 작업은 단순히 문서를 정리하는 일이 아니었다. 나중에 다시 들어와도 같은 기준으로 읽히고, 같은 기준으로 연결되고, 같은 기준으로 다시 판단할 수 있게 만드는 일이었다. 그게 바로 LLM 위키를 만들며 내가 얻은 가장 큰 수확이다.

이 블로그용 기록문서는 어떻게 남길 것인가

이 문서는 단순한 일지로 끝내고 싶지 않았다. 처음에는 운영 기록을 남기기 위한 메모에 가까웠지만, 지금은 그 과정을 블로그 글로도 읽을 수 있어야 한다고 생각한다. 그래서 업데이트를 적더라도 시스템 로그처럼 건조하게 나열하지 않고, 어떤 문제를 만났는지와 왜 그런 선택을 했는지까지 함께 적고 있다.

앞으로도 이 문서는 계속 쌓일 것이다. 다만 쌓는 방식은 무작정 항목을 늘리는 것이 아니라, 하나의 변화가 왜 필요했는지, 그 변화가 어떤 문제를 풀었는지, 그리고 그 과정에서 내가 무엇을 배웠는지를 남기는 방식이 될 것이다. 이렇게 남겨야 나중에 다시 읽었을 때 단순한 작업 목록이 아니라, 실제 운영 경험이 살아 있는 글이 된다.

업데이트 기록

2026-04-30

공통 라이브러리를 두고 반복 작업을 한 곳에서 돌리기 시작했다. 처음에는 파일마다 조금씩 다르게 적혀 있던 경로 처리와 UTF-8 설정이 계속 문제를 만들었는데, 이제는 시작점에서 아예 고정해 두는 방식으로 바꿨다. 덕분에 같은 오류를 계속 다시 보던 일이 줄어들었다.

같은 날 SCHEMA_v2.9 기준도 따로 고정했다. 이 작업은 겉으로 보면 버전 숫자 하나를 올린 것 같지만, 실제로는 앞으로 어떤 규칙을 기준으로 위키를 운영할지 다시 박아두는 일이었다. 문서가 많아질수록 기준이 흔들리는 순간부터 정리가 아니라 혼선이 되기 때문에, 이런 기준 고정은 운영의 바닥 작업에 가깝다.

또 연구과제.md에는 짧은 단기 과제를 넣었다. 3일 안에 해야 할 일과 상반기 동안 계속 다듬어야 할 프롬프트 작업을 나눠 적으면서, 지금 당장 손댈 것과 시간을 두고 볼 것을 구분했다. 이 구분을 해두니 위키 운영이 덜 즉흥적이 되었다.

가장 체감이 컸던 건, 반복 오류를 그때그때 고치는 방식에서 벗어나 공통 규칙과 공통 스크립트를 두는 방식으로 넘어간 점이다. 이건 단순히 코드를 정리한 것이 아니라, 내가 자꾸 틀리는 지점을 시스템이 대신 잡아주게 만든 것이다. 그 뒤로는 같은 종류의 실수를 줄이는 방향이 훨씬 선명해졌다.

같은 흐름에서 회사, 산업, 사람 엔티티를 중복 없이 관리하는 규칙도 더 분명해졌다. 회사와 산업은 하나의 canonical file로 수렴시키고, 사람은 동명이인 예외를 소속과 직함으로 풀어내는 방식으로 정리했다. 그 결과 lint_all.py가 변경분 중심으로 필요한 검사만 고르도록 바뀌었고, frontmatter 캐시와 공통 정규화도 함께 들어갔다. 이 작업은 눈에 잘 띄는 기능 추가는 아니었지만, 운영 비용을 줄이는 데는 꽤 큰 차이를 만들었다.

2026-04-29

투자 문서를 다시 읽고 다시 연결할 수 있게 하는 구조가 실제로 필요하다는 걸 확인했다. 특히 회의록, 브로커 리포트, 특수상황, 회사 엔티티, 산업 설명이 따로 놀면 나중에 판단이 약해진다. 그래서 문서를 저장하는 방식보다 연결하는 방식에 더 신경을 쓰기 시작했다.

이후에는 MOC와 산업 노드를 분리하는 기준을 계속 다듬었다. 처음에는 둘이 비슷해 보였지만, 실제로는 역할이 달랐다. 이 차이를 분명히 해두지 않으면 같은 내용을 여러 곳에서 관리하게 되고, 그러면 유지보수가 급격히 어려워진다.

마지막으로, 블로그용 기록 문서도 시스템 로그가 아니라 회고문처럼 읽히도록 방향을 바꿨다. 이 문서는 나중에 내가 다시 읽어도, 그때 왜 이런 구조를 만들었는지가 보이도록 남겨야 한다고 판단했다.