최근 3주간 가장 많이 써본 에이전트 스킬은 LLM-WIKI.
결론부터 말하면, LLM-WIKI는 생각보다 똑똑한데 동시에 생각보다 정직하다.
정확하고 구조화된 매뉴얼을 넣으면 꽤 좋은 지식 베이스가 만들어진다.
특히 업무상 자주 보는 비행 관련 매뉴얼처럼 입력 정보의 품질이 높은 경우 결과물도 안정적이다.
반대로 X, 웹 크롤링, YouTube에서 긁어온 정보들은 양은 많지만 노이즈가 많다.
그만큼 Wiki 결과물도 얕아지거나, 직관적으로 바라보던 핵심이 비켜가는 경우가 많았다.
결국 LLM-WIKI의 핵심은 많은 정보가 아니라
더 좋은 인풋을 어떻게 선별해서 넣느냐인 듯.
LLM Knowledge Bases
Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:
Data ingest:
I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.
IDE:
I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).
Q&A:
Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.
Output:
Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base.
Linting:
I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.
Extra tools:
I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.
Further explorations:
As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows.
TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.
6개월간 클로드 코드를 매일 사용한 시니어 개발자의 조언
수많은 시행착오 끝에 진짜 생산성을 올려준 Claude Code 워크플로우
■ 복잡한 건 무조건 'Plan' 모드부터
코드 쓰기 전에 접근 방식/단계부터 먼저 뽑기
■ '전체 기능 구현' 금지, 항상 첫 스텝부터
처음부터 "이 기능 전체 구현해줘" = 망하는 지름길
한 단계 만들고, 리뷰하고, 다음 단계로 넘어가는 식으로 쪼개기
■ 'Preview' 적극 활용
데스크톱 앱의 Preview 기능으로
프런트엔드 코드를 렌더링하고
눈으로 보면서 디버깅하기
■ 버그는 직접 고치지 말고 Claude에게 시켜라
에러 로그·스크린샷·테스트 결과 던져주고
"여기서 이렇게 깨진다, 네가 고쳐라"
Claude가 스스로 맥락을 업데이트하게 만들기
■ 리뷰 전에 /simplify 한 번 돌려라
과설계, 쓸데없는 추상화, 중복 코드를
먼저 다듬고 나서 리뷰하면 훨씬 덜 피곤하다.
■ 세션 끝날 때 '레트로'를 남겨라
"오늘 세션에서 배운 점/결정/실수/다음 할 일
정리해서 retro 노트 만들어줘"라고 시키기
노하우를 쌓는데 도움이 된다.
2주동안 엎어왔던 프로젝트
드디어 실자금 투입해서 테스트 돌리는데 갑자기 상승해버리면 테스트 의미가 없는거 아닌가 싶네..
현재 진행중인 프로젝트
가칭 Five show
에이전트 다섯.
프롬프트는 정체성만 주입
(Do or Not 없음)
로그라이크 게임처럼
매 라운드별 시장상황을 보고
각자 거래를 진행중
📊 구조만 보는 놈 — Level Map으로 저항선 찍고 들어감
🤏 틈새만 노리는 놈 — 호가창 X-Ray로 갭 찾아서 먹고 튐
🎰 확률만 계산하는 놈 — 청산 히트맵에서 폭발 지점 노림
😀 군중 따라가는 놈 — 대중 심리 체크하고 흐름 탐
🔍 남들 패턴 읽는 놈 — 다른 4명 전적 분석해서 역으로 침
17개 도구 중 매 라운드 4개씩
자기가 골라서 씀.
같은 시장 보고 전부 다른 결론ㅋㅋㅋㅋ
심지어 지금은 대중들만 따라가는 놈이 제일 많이 버는중
.
.
.
이렇게 더 기계랑 노는시간이 늘어간다😂