복리로 쌓인 건 지식이 아니라 실패였습니다

복리로 쌓인 건 지식이 아니라 실패였습니다

미용실 1호 고객 블로그 발행 시스템을 LLM Wiki로 2개월 돌린 기록

저는 이런 걸 만들고 있습니다

소상공인이 슈퍼마켓에서 생필품 사듯 AI 마케팅을 쓰게 하는 걸 하고 있습니다. 1호 고객은 강동구청역 앞 미용실입니다. 상호가 바뀌었는데(체인 → 개인 브랜드) 아직 아무도 모르고, 원장님은 동네 미용실에서 손상모·심한 곱슬 전문으로 방향을 틀고 싶어 하십니다. 마케팅 예산은 월 50~60만 원. 유료 광고는 불가능하니 블로그·스레드로 승부해야 합니다.

그런데 제 진짜 목표는 이 미용실 블로그를 잘 쓰는 게 아닙니다. 다음 가게에 그대로 복사할 시스템을 만드는 겁니다. 그래서 처음부터 두 레이어를 갈라놨습니다.

레이어 1 (고객 결과물)  →  미용실 블로그·스레드 발행물
레이어 2 (진짜 제품)    →  그걸 만드는 동안 반복 가능한 부분만 기록한 것

시스템을 따로 기획하지 않습니다. 미용실을 직접 손으로 하면서 반복되는 것만 기록하면 그게 시스템이 된다고 보고 있습니다.

스터디 오기 전에 이미 하고 있었는데, 이름이 없었습니다

카파시 gist를 읽고 나서 제가 한 일은 새 구조를 만든 게 아니라 이미 하던 것에 이름을 붙인 것이었습니다. 저장소 루트에 LLMWIKI.md 한 장을 만들고 매핑표를 채웠습니다.

별거 아닌 작업 같은데, 이걸 하고 나서야 다음 가게 복제가 가능해졌습니다. 이름이 없는 구조는 복사할 수 없더라고요. 어디까지가 이 가게 전용이고 어디부터가 재사용 조각인지 구분이 안 되니까요.

그래서 지금은 3층으로 나눠져 있습니다.

docs/           ← 이 가게의 진실과 과정 (메타)
os/알레이헤어/   ← 실제로 돌아가는 인스턴스 (raw → wiki → output)
llm_wiki/       ← 방법론·스키마·포맷 (가게마다 포크하지 않고 참조만)

복리가 실제로 도는 지점은 성공이 아니라 사고 기록이었습니다

2주차 주제가 "지식의 복리"였는데, 저희 위키에서 제일 자주 읽히는 문서를 열어보니 성공 노하우 정리본이 아니었습니다. 2.wiki/발행-배운점.md입니다. 첫 줄이 이렇습니다.

새 소재를 시작하기 전에 이 문서를 먼저 읽는다. 한 글에서 얻은 교훈이 다음 글에 반영되지 않으면 같은 사고가 반복된다.

여기 쌓이는 건 전부 사고 기록입니다. 세 가지만 옮겨 보겠습니다.

1) 겹침은 소재가 아니라 문장에서 샜습니다

기획 단계에서 "이 글의 각도가 앞 글과 겹치는가"는 대조하고 통과시켰습니다. 그런데 발행 직전에 걸린 건 전부 문장이었습니다.

각도 대조와 문장 대조는 다른 일이었습니다. 각도만 보다가 최근 2주 발행글 3편을 통째로 놓쳤습니다. 그리고 대조 우선순위도 뒤집혔습니다 — 수개월 전 아카이브 155편보다 바로 앞 2주에 나간 글이 훨씬 위험합니다. 같은 시기에 같은 사람이 썼으니 어휘가 그대로 따라오거든요.

2) 자기 검사가 "통과"라고 거짓 보고를 했습니다

이게 제일 무서웠습니다. 하나의 소재를 A·B 두 편으로 나눠 각각 생성 에이전트를 돌렸는데, 두 에이전트가 모두 자체 유사도 검사를 "통과"로 신고했습니다. 실제로는

• A편이 6일 전 발행글과 9어절 연속 일치 ("오늘은 여기까지만 하자고 말씀드리…")

• B편의 원리 설명 사슬("단면 → 큐티클 → 수분 → 푸석")이 3편째, 그중 한 구절은 4어절 완전 일치

원인을 파보니 A편은 제목 충돌만 보고 본문을 안 맞췄고, B편은 6음절 n-gram이라 앞부분만 겹치고 뒤가 갈라지는 어구를 구조적으로 못 잡았습니다. 네이버 유사문서 판정은 그걸 잡습니다.

여기서 배운 건 검사 방식보다도, 에이전트의 자기 신고를 그대로 믿으면 안 된다는 쪽이었습니다. 그래서 검사 결과가 아니라 검사가 틀렸던 사실 자체를 기록으로 남기게 했습니다. 각 글의 메타데이터에 selfCheckFailure(자체 검사가 뭘 놓쳤나), priorClaimWasWrong(이전 판단 중 틀린 것) 필드를 두고 매번 채웁니다.

발표 중에 "런백(runbook)의 기준을 어떻게 정하느냐"는 질문이 나왔는데, 저희는 아직 자동 판정 기준은 없고 사람이 걸러낸 순간을 무조건 적는 것으로 대신하고 있습니다.

3) "전수 대조했다"고 적었지만 5편만 봤습니다

리서치 문서에 "아카이브 155편 + 발행분 전수 대조" 라고 적혀 있었습니다. 실제로 본 건 5편이었습니다.

과장된 표기가 다음 글에서 같은 사고를 부릅니다. 다음 작업자(사람이든 에이전트든)가 "이미 전수 대조했구나" 하고 안 봅니다. 그래서 규칙을 하나 추가했습니다 — 실제 한 만큼만 적는다.

이 세 건이 전부 다음 글 시작 전 체크리스트가 됐습니다. 이게 저한테는 복리였습니다. 지식이 쌓여서가 아니라, 실패가 다음 작업의 입력으로 배선됐을 때 돌기 시작했습니다.

제일 아팠던 건 "빈 칸을 자산으로 착각한 것"입니다

원장님 블로그 155편을 어휘 단위로 분석하다가, 업계 용어 몇 개가 거의 안 쓰이는 걸 발견했습니다.

저는 이걸 보고 "아직 아무도 안 쓴 비어 있는 자산" 이라고 판단했습니다. 그래서 생성된 초안이 파상모 9회, 셰이프 8회를 쓰는 걸 그대로 통과시킬 뻔했습니다.

틀렸습니다. 비어 있는 이유를 따지지 않은 게 문제였습니다. 원장님 현장 노트 원문을 다시 열어보니 이렇게 적혀 있었습니다.

"저희가 말하는 이런 반곱슬머리(파상모)"

원장님은 그게 업계어라는 걸 스스로 밝히고, 고객이 쓰는 말을 앞에 두고 계셨습니다. 25년 동안 손님 앞에서 검증된 선택이었던 겁니다. 0편은 공백이 아니라 결론이었습니다.

데이터가 0인 이유를 안 따지면 위키는 틀린 걸 복리로 쌓습니다. 스터디에서 "신뢰성이 진짜 어려운 부분"이라는 얘기가 나왔는데, 저한테는 이게 그 사례였습니다.

지금 못 푼 문제 — 규칙끼리 싸우기 시작합니다

지식이 쌓이니 이런 일이 생깁니다.

나중 것이 실무 관행이 됐는데 정본이 갱신되지 않았습니다. 그리고 이번에 실제로 충돌했습니다 — 금지 조항이 걱정했던 사고(두 글이 같은 원인 설명을 씀)가 그대로 재현됐거든요.

이번엔 최신 문서를 따랐지만, 근거가 "더 최신이라서" 였지 명시된 우선순위가 아니었습니다.

AI가 스스로 판단하려면 어느 쪽이 이기는지가 문서에 있어야 합니다.

이게 아직 미결입니다. 지식 관리 체계를 오래 돌리면 "무엇을 아는가"보다 "충돌할 때 뭐가 이기는가"가 더 중요해지는 것 같습니다.

숫자 몇 개 (실무 원가)

토큰 비용을 재보고 나서 운영 방식이 바뀌었습니다.

• 생성 에이전트 + 검수 에이전트 1회전 ≈ 40만 토큰. 이걸 글 1편의 기본 원가로 잡고 있습니다.

• 검수 에이전트에게 사진 15장 전수 대조를 시키면 13만 → 19만 토큰으로 뜁니다. 사진을 사람이 고를 거면 "사진 열지 마"라고 명시하는 게 쌉니다.

• 초안 전문을 대화창에 띄우면 이후 모든 턴에 계속 실려 다닙니다. 파일로 전달하는 편이 훨씬 쌉니다.

그래서 작업일지를 30분 단위로, L1(고객 청구분) / L2(제 투자분) 을 갈라서 적고 있습니다. 이 경계가 곧 사업 모델이라서요. 원장님께 청구할 건 L1뿐이고, L2는 다음 가게에 팔 물건입니다.

다른 분들 발표 보면서

• 묘랑님 — "진행해는 위임이 아니라 포기였다" 가 제일 오래 남았습니다. 저도 초반에 똑같이 했고, 에이전트가 저 혼자 앞서 달려가서 뭘 만들었는지 모르는 상태를 겪었습니다.

• 유쌤님 — 구글 드라이브 ↔ 로컬을 오가며 중복이 생기는 문제요. 저희는 비슷한 걸 폴더 이동에서 겪었습니다. 원래 발행대기/ → 발행완료/ 로 옮기는 구조였는데, 옮기는 순간 이력이 끊기고 짝이 어긋나더라고요. 폴더를 옮기지 않고 meta.json의 status 필드로 상태를 표시하는 방식으로 바꾸고 나서 사라졌습니다. 상태는 위치가 아니라 값으로 두는 게 안전한 것 같습니다.

• 꾸기장님 — 원본 출처 확인 규칙 때문에 인덱스만 읽고 끝내려던 토큰 효율이 깨졌다는 지점, 저도 정확히 같은 트레이드오프에 있습니다. 저희는 "인용이 필요한 주장"과 "구조만 필요한 질문"을 나눠서 후자는 인덱스에서 끊으려고 하는데 아직 잘 안 됩니다.

다음 주에 할 것

1. 발행 사실 회수 자동화 — 지금 21편 중 발행일이 채워진 건 3편, URL은 1편뿐입니다. 실제로는 10편 이상 올라가 있는데 그 사실이 저장소로 돌아오는 경로가 없어서 제가 폴더명에 손으로 날짜를 붙이고 있었습니다. 읽기 전용 API로 목록을 받아 대조하는 건 이미 되더라고요 (원장님이 초안과 다른 제목으로 올린 글 2건까지 잡아냈습니다). 게시는 자동화 못 해도 확인은 자동화됩니다.

2. 검수 체크리스트에 금지어 grep 추가 — 검수 에이전트가 등재된 금지 표현을 2회 연속 놓쳤습니다. 판단에 맡길 게 아니라 기계적으로 훑어야 하는 항목이 따로 있었습니다.

3. 규칙 충돌 우선순위 명문화 — 위의 미결 항목.

정리하면

2주차에서 "지식의 복리"를 M4 최종 단계로 놓으셨는데, 2개월 돌려본 입장에서 제일 크게 느낀 건 이겁니다.

복리는 좋은 지식을 쌓아서 돌지 않았습니다. 실패한 판단을 지우지 않고 다음 작업의 필독 문서로 배선했을 때 돌기 시작했습니다.

성공 노하우는 사실 잘 안 읽힙니다. 이미 아는 얘기라서요. 그런데 "이 표현 5편째다", "그때 전수 대조했다고 썼는데 5편만 봤다", "0편인 걸 자산으로 착각했다" 같은 건 다음 사람이 반드시 읽습니다. 안 읽으면 똑같이 당하니까요.

그래서 저희 위키에서 가장 값나가는 파일은 잘 정리된 지식 문서가 아니라, 틀렸던 기록을 지우지 않고 모아둔 문서였습니다.