비개발자가 만드는 '칼날' LLM Wiki
— 선정된 글 이후 4-5일간, 또 한 번 바뀐 생각
들어가며
얼마 전에 GPTers에 글 하나 올렸다. 제목은 '비개발자가 LLM Wiki로 기획 위키를 만들어본 기록'. 사레글 발표 준비를 하다가 한 가지 깨달았다.
그 글을 쓴 이후로 한 4-5일 동안 내 생각이 또 크게 바뀌었다는 것.
그래서 이번 글은 그 글의 '그 다음 이야기'다. 짧은 기간이지만, 그 며칠 동안 내가 LLM Wiki를 보는 시각 자체가 다시 한 번 깎였다.
1. 그 글에서 짚었던 두 가지
지금 그 글을 다시 보니, 내가 짚었던 게 두 가지였다.
하나, LLM Wiki를 단순한 지식 창고가 아니라 내 업무에 쓸 수 있는 전문 도구로 봤다는 점. 카파시가 처음 제안한 LLM Wiki는 개인의 지식을 LLM이 읽기 좋게 정리하는 시스템이지만, 나는 그걸 '드라마 기획'이라는 구체적 도메인에 끌어와서 쓰려고 했다.
둘, 비개발자라서 무에서 창조가 안 되니까 더 잘하는 사람을 벤치마킹해서 부족함을 채우는 방식으로 갔다는 점. 솔직히 나는 코딩 못한다. 근데 시도는 했다. 못해도 시도해본 기록을 솔직하게 적었다.
2. 비개발자가 여기까지 오는 길
나는 코딩에 대해 1도 모르는 상태에서 올해 3월에 오픈클로와 클로드코드를 시작했다. 두 달 좀 넘었다. 지금은 오픈클로 에이전트 2명(루이, 로건), 헤르메스 에이전트 3명(레오, 로이, 류), 그리고 클로드 코드까지 같이 쓰고 있다.
오픈클로_루이(개인일정) 로건(운동/식단) 헤르메스_레오(기획) 로이(업무) 류(개인글))
여기까지 독학으로 오면서 시행착오가 진짜 많았다. 그 와중에 시행착오를 줄이는 나만의 꿀팁이 하나 생겼는데, 이거 하나 공유하고 싶다.
꿀팁: 벤치마킹 케이스를 찾는다
내가 비개발자다. 무에서 유는 진짜 힘들다. 근데 '뭘 만들고 싶다'는 명확하다. 그래서 늘 에이전트한테 이렇게 부탁한다.
"나 운동 트래커 만들고 싶어. 헬스 기록·식단 기 록하고 조언해주는 에이전트. 근데 솔직히 전세계에 1명은 쓰고 있지 않을까? 깃허브든 어디든 찾아줘. 찾으면 내 케이스에 맞게 벤치마킹할 수 있는 요소를 알려줘."
이미 똑똑한 개발자·비개발자 선배들이 만들어둔 게 깃허브에 널려있다. 그분들 케이스 보고 내 상황에 맞게 응용한다. 잘 먹힌다.
3. LLM Wiki를 보는 두 가지 시각
글을 쓰고 나서 카파시 원본을 다시 읽었다. Medium, MindStudio, 데이터사이언스도조 — LLM Wiki 사례라는 사례는 다 찾아봤다.
자료를 넣으면 LLM이 정리해서 백과사전을 만드는 방식. 나는 LLM Wiki를 두 가지로 나눠봤다.
1번 — 백과사전. 내가 가진 자료를 지식화해서 에이전트를 똑똑하게 만드는 거. 도서관 사서가 있는 압축된 도서관이다.
2번 — 칼날. 내 전문성을 행동으로 옮길 수 있게 지식을 깎는 거. 예리한 칼날을 만들 듯이.
이 둘이 완전히 분리된 건 아니다. 1번이 큰 원이라면 2번은 그 안의 작은 원. 1번 위에 2번이 얹히는 부분집합 구조다.
4. 내가 칼날을 원하는 이유
나는 드라마 PD다. LLM Wiki로 만들고 싶은 건 드라마 대본 피드백 에이전트. 기존 드라마 대본들에 대한 이해가 높은 에이전트가, 새로 기획 중인 대본을 분석하고 평가하고 피드백을 주는 거.
근데 대본이 진짜 복잡하다.
• 플롯도 중요하고
• 캐릭터성도 중요하고
• 사건도 대사도 다 중요하고
• 작품 자체를 넘어서 — 편성이 될지, 캐스팅이 될지, 후킹 요소가 뭔지까지 등등
요소도 많고, 그 사이의 균형도 까다롭다. 이걸 다뤄야 하는 나 한테 필요한 건 똑똑한 도서관이 아니었다. 같이 일할 파트너가 필요했다.
그래서 칼날형 LLM Wiki를 만드는 길로 갔다.
5. v0 — 헐렁한 Ingest
폴더 구조: Ginger-Wiki 안의 기획-Wiki
먼저 폴더 구조부터. 내 옵시디언 vault에는 여러 작업 폴더들이 있다. Health Tracker, Magazine, Scripts, Study 같은 것들. 그 중에 '1.Ginger-Wiki'라는 큰 위키가 있다. 내 전체 지식을 다 담는 그릇. 그 안에 '기획-Wiki'를 따로 만들었다. 이게 대본 도메인만 전문적으로 다루는 칼날 위키다.
앞에서 말한 1번(백과사전) 큰 원 안에 2번(칼날) 작은 원 — 그 구조를 폴더로 그대로 구현한 거다.
Ingest 단계에서 미리 답을 적어두는 것
카파시 LLM Wiki의 핵심을 다시 한 번 짚어보자.
Ingest 단계에서 미리 답을 적어두는 것. 자료를 wiki에 넣을 때 LLM이 단순히 텍스트만 저장하는 게 아니라, 읽고 분석하고 의미를 미리 적어둔다. 사용자가 질문을 던지기 전에. 그러면 Query 시점에는 미리 적힌 답을 꺼내기만 하면 된다. 답이 빠르고 정확해진다.
이게 카파시 wiki를 'compounding knowledge base'라고 부르는 이유다. 시간이 지날수록 wiki 안에 통합된 답이 누적된다.
v0의 시도와 실패
내 첫 시도, v0는 단순했다. 가지고 있는 대본을 wiki에 다 넣었다. 새 기획안을 줘서 '분석하고 피드백 줘'라고 했다.
결과는 두루뭉술했다. 깊이가 없고, 내가 못 본 지점을 봐주지도 못했다.
왜? wiki에 대본 텍스트만 넣어두고 — '이 대본을 어떻게 봐야 하나'를 미리 적지 않았다. 그러니까 새 질문이 들어왔을 때 wiki에 미 리 적힌 답이 허술하니, LLM이 매번 새로 추론해야 했다.
Ingest가 헐렁했던 거다. 자료는 넣었지만 그걸 어떻게 봐야 할지에 대한 도구가 없었다.
Ingest 안에 박을 도구가 필요했다.
6. v1 — 함께 공부하기, 그리고 렌즈의 등장
권위자 교수님 모드
v1은 그래서 '함께 공부하기'였다. 대본 작법 관련 논문 5편을 들고와서 클로드 코드에게 이렇게 말했다.
"너는 이제 대본 작성 권위자 교수님이야. 내가 학생이라고 생각하고 강의해주고, 내가 이해했는지 확인하려고 질문도 던져줘. 그리고 이 모든 과정은 궁극적으로 LLM-wiki를 정교하게 만들기 위한 기준을 세우기 위함이야."
그렇게 논문 5편을 같이 공부했다. 그 다음 클로드가 추가로 검색해서 20여 편을 더 가져왔다(이건 솔직히 같이 못 읽었다. 피곤해서…). 다 합쳐서 나만의 평가 기준을 만들었다.
렌즈의 등장
여기서 등장한 게 바로 렌즈다. 나와 클로드 코드는 논문을 통해 배운 기준(도구)를 렌즈라고 부르기로 했다.
기본은 4개. 주인공 능동성, 장면별 시청자 효과, 구조의 명료성, 제작 실현성. 그리고 각 렌즈 아래로 더 세밀한 하위 렌즈들이 붙어서, 다 합치면 20개가 좀 넘는다.
이 렌즈를 v1의 Ingest 단계에 박아 넣었다. 그러면 wiki에 들어가는 모든 대본이 이 렌즈들로 미리 분석된 채로 저장된다. '주인공 능동성 8.1점, 구조 명료성 7.3점, 이런 이유로…' 이런 분석이 wiki 페이지에 미리 적힌다.
v0보다 훨씬 깊어졌다. 꽤 날카로웠다. 내가 못 본 지점도 봐주더라.
그래도 보조도구 수준이었다
근데 여전히 한계가 있었다. 공통적으로 봐야 할 부분도 많이 놓치고, 할루시네이션도 좀 있고. 결국 보조도구 수준이었다. 내가 원한 진짜 파트너는 아니었다.
왜 그랬을까. 한참 고민하다가 답을 찾았다.
렌즈로 분석한 결과는 결국 '읽는 사람의 시점'이다.
작가는 그 대본을 어떻게 만들었는지 알고, 나는 그걸 어떻게 읽을지만 안다. 그 사이의 간격을 분석만으로는 못 메운다.
그러려면 쓰는 사람의 시점이 필요했다.
7. v2 — 쓰는 시점, 거꾸로 쓰기
엔지니어 H님의 한 마디
지난 오프라인 모임에서 스터디장 엔지니어H님이 힌트를 줬다.
"대본 평가에 포인트를 두지 말고, 대본을 에이전트한테 직접 써보라고 하는 건 어때요? 그럼 평가의 기준도 달라지지 않을까요?"
이 한 마디가 나한테는 결정적이었다. v2의 시작.
4단계 루프
새 방법을 짰다.
• 1. 잘 쓴 대본 1편을 고른다. (추후엔 더 늘릴 예정)
• 2. 우리 렌즈로 그 대본을 분석한다.
• 3. 그 분석만 가지고 — 에이전트가 처음부터 다시 쓴다. (원본 없이)
• 4. 원본과 유사도 평가. 합격 기준은 97%. 못 넘으면 다시, 또 다시.
이건 단순한 글쓰기가 아니다
이게 단순히 글쓰기를 시키는 게 아니다.
좋은 대본을 에이전트가 직접 써봄으로써 그 방식을 이해하는 것. 그리고 그 모든 과정을 지식 삼아 렌즈를 더 정교하게 깎는 것 — 이게 진짜 목적이다.
분석은 '읽는 시점'이지만 직접 쓰기는 '만드는 시점'이다. 직접 써봐야 작가의 작법이 어디서 작동하고 어디서 안 작동하는지 보인다.
평가는 점수 X, Y/N 체크리스트
평가도 바꿨다. 점수가 아니라 체크리스트 Y/N으로.
점수로 평가하면 '85점'이라는 답만 나온다. 어디가 강해서 85점인지, 어디가 빠져서 15점이 깎였는지 안 보인다. Y/N로 보면 '이 항목은 통과, 이건 못 따라잡았다'가 한눈에 보인다. 그리고 못 따라잡은 항목이 곧 다음 렌즈를 깎는 재료가 된다.
작가별 미시 항목은 이런 것들이 나왔다:
• 자기-진단형 한 문장 대사가 복수 씬에 반복 등장
• 두 인물 사이 같은 행동 모티프가 평행 구조로 깔림
• 회상 씬을 감정 전환의 키로 사용
• 음절 단위로 끊어 강조하는 대사 톤
작가 한 명당 이런 미시 렌즈가 25개. 일반 드라마 작법 21개. 합쳐서 46개 체크리스트.
8. 3일간 돌려본 결과
v2를 실제로 3일 전부터 돌리고 있다. 어떤 거장 작가의 EP1로. (작가·작품은 비공개 판권 자료라 익명으로.)
결과:
• 1차: 54% (46개 중 25개 통과)
• 2차: 76% (35개 통과, +22%p)
• 3차: 97% (45개 통과, +21%p) — 합격 기준 도달
2차에서 재미있는 일이 있었다. 표면 작법은 좋아졌는데 회상 씬이 4개에서 0개로, 내레이션이 60줄에서 0줄로 깎였다. 회귀.
그때 나 는 가설을 세웠다. '아, 이게 작가법 안에 길항이 있어서 한쪽 살리면 다른 쪽이 죽는 거구나.' 가설 1호.
3차에서 처방을 하나 넣었다. '회상 복원하라.' 그랬더니 세 항목이 동시에 회복되면서 97%가 나왔다. 가설 1호는 어떻게 됐냐. 반증됐다. 작가법 코어의 길항이 아니라 내 피드백 설계가 부실했던 거였다. 가설이 반증되는 것 자체가 wiki 자산이 됐다.
진짜 발견: 안 통과한 1개
근데 진짜 흥미로운 건 안 통과한 1개다.
3번을 돌려도 끝까지 안 따라잡힌 항목이 하나 있다. 그 작가만의 특유한 작법. 처방을 명시해도 에이전트가 그것까지는 못 흉내낸다. 인간다움이랄까.
덧붙이는 솔직 후기
오늘까지 3차 마무리. 내일은 Codex로 외부 검증할 예정이고, 최대 5차까지 돌려볼 생각이다. 자체 critic이 같은 모델이라 편향이 있을 수 있어서 외부 검증을 한 번 거치는 거.
참고로 이 방법의 가장 큰 문제는 — 토큰이 녹는다는 거다. MAX 100달러 쓰는데 200달러로 바꾸고 싶은 욕구가 활활 타오르는 중이다. 이어서 하는 진행 상황도 사례글로 올릴테니 읽으시는 분들은 팝콘 드시면서 구경하시다 괜찮아 보이면 들어오시면 될 것 같다.
9. 이건 대본만의 이야기가 아니다
쓰면서 깨달은 게 있다. 이게 대본만의 이야기가 아니라는 것.
보고서든, 기획서든, 에세이든, 소설이든 — 잘 쓴 완성본만 있으면 똑같이 작동할 것 같다.
분석 → 직접 만들어보기 → 평가 → 렌즈 깎기.
이 공식이 곧 칼날 LLM Wiki다. 도메인 무관.
내가 만들고 있는 건 그 도메인이 '드라마 대본'일 뿐이다. 누군가는 '컨설팅 보고서'로, 누군가는 '연구 논문'으로 만들 수 있다.
10. 마치며
발표를 준비하면서, 그리고 이 글을 쓰면서 한 가지가 더 명확해졌다.
칼날 LLM Wiki는 결국 — 특정 전문 분야에서 자기 시각을 정교하게 다듬는 도구다.
렌즈는 그 분야를 보는 안경이고, 렌즈를 깎는다는 건 그 분야에서 내가 무엇을 어떻게 보는지를 더 날카롭게 만든다는 뜻이다.
카파시 LLM Wiki가 wiki 안의 콘텐츠를 정교하게 만드는 시스템이라면, 칼날 wiki는 거기에 한 분야의 전문성을 같이 다듬는 사이클을 얹는 방식이다.
내 경우엔 그 분야가 '드라마 대본'이다. 누군가는 컨설팅 보고서일 수도, 연구 논문일 수도, 마케팅 카피일 수도 있다. 분야가 무엇이든 — 잘 쓴 완성본 하나만 있으면 같은 공식이 작동한다.
분석 → 직접 만들어보기 → 평가 → 렌즈 깎기.
한 번 깎고 끝이 아니라는 게 핵심이다. 깎을수록 다음에 깎아야 할 게 또 보인다.
