8.3 주제가 늘어날 때 관리하기

핵심 요약

8.3의 핵심은 LLM위키가 잘 쓰이기 시작한 뒤 생기는 성장 문제를 관리하는 것이다. 처음에는 회의록 몇 개와 업무 규칙 몇 줄로 충분하지만, 시간이 지나면 보고서 자동화, 고객 문의 분류, 회의록 요약, 채용 문서, 팀 온보딩 같은 주제가 한 공간에 섞일 수 있다. 이때 위험은 자료가 많다는 사실보다 질문 맥락과 운영 상태가 흐려지는 데 있다.

첫 판단은 하나의 큰 위키로 유지할지, 여러 주제 위키로 나눌지, 큰 위키 안에 주제 폴더를 둘지다. 같은 핵심 질문, 같은 독자, 같은 업무 흐름이면 기존 위키에 둘 수 있다. 질문, 독자, 보안 등급, 산출물 형식이 달라지면 새 주제 위키나 별도 폴더를 검토해야 한다.

주제 위키가 세 개를 넘으면 기억으로 관리하기 어렵다. 이때 필요한 것은 단순 파일 목록이 아니라 주제 이름, 핵심 질문, 상태, 마지막 갱신일, 다음 행동, 대표 산출물을 담은 운영 인벤토리다. 특히 상태와 다음 행동은 LLM에게 읽힐 범위와 실제 운영 우선순위를 정하는 핵심 열이다.

오래된 주제는 삭제보다 아카이브가 안전하다. 아카이브는 쓸모없다는 판정이 아니라 기본 질문 맥락에서 제외하되 필요하면 다시 찾을 수 있게 보존하는 일이다. 날짜 하나만으로 판단하지 말고 프로젝트 종료, 최신성, 중복 흡수, 보안 분리, 계속 참조 여부를 함께 확인해야 한다.

원문 구조와 실무 의미

원문 절	핵심 내용	실무 의미
도입부	주제가 늘어나면 어디에 넣을지, 아직 쓰는지, 비슷한 위키가 중복인지 문제가 생긴다.	성장한 위키의 문제는 문서 부족이 아니라 상태와 범위의 불명확성이다.
하나의 큰 위키와 여러 주제 위키	큰 위키, 여러 위키, 큰 위키와 주제 폴더 조합을 비교한다.	답변 품질과 관리 비용 사이에서 구조를 고른다.
새 자료 배치 흐름	새 자료가 기존 위키의 핵심 질문, 독자, 업무 흐름과 같은지 묻는다.	파일 형식보다 실제 질문 기준으로 위치를 정한다.
인벤토리로 전체 현황 보기	주제 이름, 핵심 질문, 상태, 마지막 갱신, 다음 행동, 대표 산출물을 관리한다.	문서가 많다는 느낌을 관리 가능한 상태 목록으로 바꾼다.
오래된 주제 아카이브하기	오래된 주제를 기본 질문 맥락에서 빼되 삭제하지 않고 보존한다.	아카이브는 근거 제거가 아니라 맥락 축소다.
도구형 아카이브 주의점	도구 기능을 쓸 때 아카이브 위치, 기본 검색 포함 여부, 복구 방법을 확인한다.	특정 구현체 기능을 공통 내장 기능처럼 오해하지 않는다.

성장한 위키의 핵심 위험

LLM위키는 작게 시작할수록 질문이 선명하다. 그러나 잘 쓰일수록 새 자료와 새 주제가 들어오고, 같은 폴더에 계속 넣으면 LLM은 질문에 필요한 맥락보다 넓은 맥락을 읽게 된다. 답변은 길어지고, 근거는 흐려지며, 오래된 프로젝트가 현재 판단에 섞일 수 있다.

증상	실제 모습	8.3 기준 해석	대응
답변이 길고 일반론이 많다	고객 문의 질문에 회의록 요약과 채용 문서까지 섞인다.	위키의 기본 맥락이 너무 넓다.	핵심 질문 기준으로 주제를 나눈다.
최신 문서를 모른다	비슷한 자동화 후보 문서가 여러 폴더에 있다.	대표 문서와 상태 기준이 없다.	인벤토리에 상태, 갱신일, 다음 행동을 기록한다.
끝난 프로젝트가 섞인다	작년 캠페인 회고가 올해 실행 계획의 근거로 쓰인다.	아카이브해야 할 주제가 운영 맥락에 남아 있다.	보존 위치로 분리하고 재확인 조건을 남긴다.
새 자료 위치를 매번 고민한다	회의록이 팀 운영인지 고객 리서치인지 업무 자동화인지 불명확하다.	자료 형식으로만 분류하고 질문 기준이 없다.	새 자료 배치 기준 질문을 만든다.

위키 구조 선택 기준

하나의 큰 위키, 여러 주제 위키, 큰 위키와 주제 폴더 조합은 우열의 문제가 아니다. 질문이 선명해지고 운영 비용을 감당할 수 있는 구조를 고르는 문제다.

구조	적합한 상황	장점	위험	운영 기준
하나의 큰 위키	주제가 작고 서로 강하게 연결된다.	탐색 위치가 단순하다.	주제가 늘면 답변 맥락이 넓어진다.	핵심 질문이 하나인지 주기적으로 확인한다.
여러 주제 위키	업무 흐름, 독자, 자료 출처가 다르다.	질문 범위를 좁히기 쉽다.	중복 문서와 관리 누락이 생긴다.	`inventory.md`로 상태와 다음 행동을 관리한다.
큰 위키와 주제 폴더	공통 규칙은 같고 세부 주제만 다르다.	공통 운영 규칙과 주제별 맥락을 함께 유지한다.	폴더 규칙이 없으면 다시 뒤섞인다.	주제 폴더별 핵심 질문과 링크 규칙을 둔다.

실무 선택 기준은 관리하기 편한가가 아니라 질문이 선명해지는가다. 문서가 한곳에 있어도 질문이 선명하면 유지할 수 있고, 문서가 많지 않아도 독자와 보안 등급이 다르면 분리해야 한다.

주제 분리의 판단 순서

새 자료가 기존 위키의 핵심 질문에 직접 답하는지 확인한다.
같은 독자와 같은 업무 흐름에서 쓰이는지 확인한다.
출처와 보안 등급이 기존 주제와 같은지 확인한다.
산출물 형식이 같은지 확인한다.
3개월 뒤에도 독립적으로 다시 물어볼 가능성이 있는지 확인한다.
기존 index.md에 자연스럽게 연결되는지 확인한다.
같은 검증 기준을 적용할 수 있는지 확인한다.

핵심 질문, 독자, 보안 등급, 산출물 형식이 달라지면 새 주제 위키나 별도 주제 폴더가 적합하다. 반대로 같은 업무 판단에 계속 쓰이고 같은 원천 자료 묶음에서 나오며 기존 색인과 검증 기준에 연결된다면 기존 위키에 넣을 수 있다.

규칙 영역	좋은 규칙	점검 질문
핵심 질문	기존 위키의 핵심 질문과 다르면 새 주제 후보로 둔다.	새 자료가 어떤 질문에 답하는지 문서에 남았는가?
독자	자료를 읽는 사람이 다르면 분리한다.	임원용 보고서와 실무 체크리스트가 같은 맥락에 섞이지 않았는가?
보안 등급	출처나 보안 등급이 다르면 제한 공간 또는 보류로 둔다.	고객명, 계약 정보, 내부 정책 원문이 일반 위키에 섞이지 않았는가?
산출물 형식	보고서, 실행 계획, 외부 요청서가 다르면 위치를 분리한다.	다른 독자용 output이 과도하게 혼합되지 않았는가?
장기 재사용	3개월 뒤 독립 질문 가능성이 높으면 별도 주제로 둔다.	일회성 output을 장기 위키로 승격하지 않았는가?

인벤토리는 운영 장부다

인벤토리는 단순한 파일 목록이 아니라 주제별 운영 상태를 보여 주는 문서다. 주제 위키가 세 개 이상이면 기억으로 관리하기 어렵기 때문에, 주제 이름과 핵심 질문뿐 아니라 상태, 마지막 갱신일, 다음 행동, 대표 산출물을 함께 기록해야 한다.

항목	역할	작성 기준
주제 이름	위키를 부르는 안정된 이름	`work-automation`, `customer-inquiry`처럼 짧고 고유하게 쓴다.
핵심 질문	이 위키가 답해야 하는 질문	하나의 업무 질문으로 표현한다.
상태	운영 중, 점검 필요, 아카이브 후보 등	LLM에게 읽힐 범위와 점검 우선순위를 정한다.
마지막 갱신일	최근 자료나 결정이 반영된 날짜	오래된 주제를 찾는 기준이다.
다음 행동	이어서 해야 할 일	자료 보강, 최신성 확인, 링크 점검, 아카이브 결정처럼 실제 행동을 쓴다.
대표 산출물	이 위키가 만든 output	보고서, 실행 계획, 회의 자료로 연결한다.
소유자 또는 검토자	상태 갱신 책임	선택 항목이지만 실무에서 유용하다.
보안·공유 범위	외부 공유 가능 여부와 접근 범위	민감 자료에서는 필수에 가깝다.

상태값 운영표

상태	의미	다음 행동 예
운영 중	기본 질문 맥락에 포함해도 되는 주제	최근 자료 반영, output 생성, 질문 템플릿 갱신
점검 필요	출처, 최신성, 중복, 링크 확인이 필요한 주제	누락 raw 수집, 오래된 주장 점검, 대표 문서 정리
아카이브 후보	기본 맥락에서 뺄지 판단해야 하는 주제	산출물 확정 여부 확인, 다시 볼 조건 작성
아카이브됨	기본 맥락에서 제외했지만 보존하는 주제	명시 요청 시만 확인, 복구 조건 기록
보류	위치나 보안 기준이 정해지지 않은 주제	보안 검토, 독자와 핵심 질문 확정

LLM에게 인벤토리를 읽힐 때

인벤토리는 사람만 보는 장부가 아니라 LLM에게 줄 운영 맥락으로도 쓸 수 있다. 이때 가장 중요한 제한은 인벤토리에 없는 주제를 새로 추측하지 말라는 것이다. 빠진 정보를 그럴듯하게 채우지 말고, 없는 정보는 확인 필요로 남겨야 한다.

inventory.md를 읽고 상태가 `운영 중`인 주제만 골라 주세요.
각 주제마다 다음 행동이 구체적인지 평가해 주세요.
`점검 필요` 주제는 어떤 원천 자료, 최신성 확인, 링크 점검이 부족한지 질문 목록으로 정리해 주세요.
`아카이브 후보` 주제는 아카이브 이유와 다시 볼 조건이 충분한지 평가해 주세요.
단, inventory.md에 없는 주제는 새로 추측하지 마세요.
출처나 보안 등급이 불명확한 자료는 확인 필요로 표시해 주세요.

요청 목적	좋은 요청 조건	위험한 요청
운영 중 주제 선별	상태가 운영 중인 주제만 고르게 한다.	전체 위키를 보고 중요한 주제를 알아서 고르게 한다.
점검 필요 분석	부족한 원천 자료와 질문 목록을 만든다.	점검 필요 주제를 LLM이 새 결론으로 확정한다.
아카이브 후보 검토	갱신일, 다음 행동, 대표 산출물, 사용 여부로 평가한다.	오래됐다는 이유만으로 삭제한다.
주제 중복 확인	핵심 질문과 대표 산출물이 겹치는 주제를 표시한다.	비슷한 이름만 보고 합친다.

아카이브는 삭제가 아니다

오래된 주제를 기본 질문 맥락에서 제외하되 보존하는 것이 아카이브다. 끝난 프로젝트, 낡은 리서치, 다른 위키에 흡수된 중복 주제, 보안상 분리가 필요한 자료는 아카이브 후보가 될 수 있다. 반대로 오래됐지만 계속 쓰는 기준 문서는 운영 중으로 유지하고 확인 날짜와 최신성 주의를 갱신한다.

구분	의미	운영 처리
삭제	자료와 근거를 없앤다.	원문은 권장하지 않는다.
아카이브	기본 질문 맥락에서 제외하되 보존한다.	`.archive/` 또는 별도 보존 위치로 옮기고 기록한다.
보류	위치나 상태를 결정하지 못했다.	`review-needed`나 인벤토리의 점검 필요 상태로 둔다.
운영 중 유지	오래됐지만 계속 쓰는 기준이다.	확인 날짜를 갱신하고 최신성 주의를 붙인다.

아카이브 판단 기준

아카이브 후보	판단 기준	처리
끝난 프로젝트	산출물이 확정됐고 새 질문이 거의 없다.	아카이브하고 다시 볼 조건을 남긴다.
예전 리서치	최신성이 중요하고 자료가 낡았다.	아카이브 후 최신 조사 필요를 표시한다.
중복 주제	다른 위키에 흡수됐다.	대표 문서만 남기고 아카이브한다.
보안상 분리할 자료	접근 범위가 달라졌다.	별도 저장소 또는 제한 공간으로 이동한다.
자주 쓰는 기준 문서	오래됐지만 계속 참조한다.	운영 중 유지하고 확인 날짜를 갱신한다.

도구형 인벤토리와 아카이브 주의점

수동 Markdown 인벤토리는 투명하고 시작 비용이 낮다. 사람이 직접 읽고 고칠 수 있으며 도구 설치나 출력 형식 해석이 필요 없다. 도구형 인벤토리와 아카이브는 주제가 많아지고 기록 방식이 안정된 뒤 붙여도 늦지 않다.

원문은 특정 구현체의 inventory와 Topic Archive Lifecycle을 예로 들지만, /wiki 명령은 OpenAI나 Anthropic의 공통 내장 명령이 아니라 특정 도구 문서 기준이다. 실제 도구를 쓸 때는 현재 README, 릴리스, 설치된 도움말을 확인해야 한다.

확인 항목	이유	검증 질문
아카이브 위치	실제 파일 위치를 알아야 백업과 복구가 가능하다.	`.archive/` 아래인지, 내부 DB인지, 별도 저장소인지 확인했는가?
기본 검색 포함 여부	오래된 주제가 답변에 섞이는지 알아야 한다.	기본 query와 maintenance에서 제외되는가?
복구 방법	잘못 아카이브한 주제를 운영 상태로 돌릴 수 있어야 한다.	restore 명령, 수동 이동, inventory 상태 갱신 절차가 있는가?
문서와 설치 버전 차이	릴리스 문서와 실제 명령이 다를 수 있다.	현재 설치된 도움말을 확인했는가?

실무 적용 절차

현재 위키의 주제 목록을 적고 각 주제가 답해야 할 핵심 질문을 한 문장으로 쓴다.
각 주제의 독자, 업무 흐름, 자료 출처, 보안 등급, 대표 output을 적는다.
새 자료가 들어오면 기존 위키의 핵심 질문과 같은지 먼저 묻는다.
핵심 질문이 같으면 기존 주제 위키에 추가하되 같은 검증 기준과 색인 흐름에 연결되는지 확인한다.
핵심 질문은 다르지만 독자와 업무 흐름이 같으면 기존 위키 안의 주제 폴더 후보로 둔다.
핵심 질문, 독자, 보안 등급, 산출물 형식이 다르면 새 주제 위키 후보로 둔다.
애매한 자료는 즉시 섞지 않고 inbox, review-needed, 또는 인벤토리의 점검 필요 상태로 보류한다.
주제 위키가 세 개 이상이면 inventory.md를 만든다.
인벤토리에는 주제 이름, 핵심 질문, 상태, 마지막 갱신일, 다음 행동, 대표 산출물을 넣는다.
LLM에게 작업을 맡길 때는 인벤토리를 먼저 읽히고 운영 중 주제만 사용하게 한다.
인벤토리에 없는 주제는 추측하지 말라고 명시한다.
오래된 주제는 날짜만으로 판단하지 않고 새 질문 여부, 산출물 확정 여부, 최신성, 중복 흡수, 보안 분리 필요를 함께 본다.
아카이브할 때는 삭제하지 말고 기본 맥락에서 분리한다.
아카이브 기록에는 날짜, 이유, 다시 볼 조건, 관련 대표 문서, 복구 또는 재검토 방법을 남긴다.
아카이브 후 인벤토리, 관련 색인, 운영 로그를 갱신한다.
8.4의 daily-inbox와 주간 점검 루틴에 인벤토리 확인과 아카이브 후보 검토를 넣는다.

실무 템플릿

주제 분리 기준 카드

판단 질문	기존 위키에 넣는 신호	새 주제 또는 분리 신호
핵심 질문이 같은가?	같은 업무 판단에 계속 쓰인다.	다른 질문을 연다.
독자가 같은가?	같은 팀 또는 같은 의사결정자가 읽는다.	임원, 실무자, 외부 협력사처럼 독자가 다르다.
자료 출처와 보안 등급이 같은가?	접근 권한과 공유 범위가 같다.	개인정보, 계약 정보, 내부 정책, 고객 자료가 섞인다.
산출물 형식이 같은가?	같은 보고서, 실행 계획, 체크리스트로 이어진다.	외부 요청서, 보안 검토, 리서치 보고서 등 목적이 다르다.
3개월 뒤 독립 질문 가능성이 있는가?	기존 질문의 보조 근거다.	독립적으로 다시 물어볼 주제다.
기존 색인과 자연스럽게 연결되는가?	관련 문서와 검증 기준이 이미 있다.	색인에 억지로 넣어야 한다.

아카이브 결정 카드

항목	작성 내용
주제 이름	아카이브 후보 주제의 안정된 이름
현재 상태	운영 중 / 점검 필요 / 아카이브 후보
핵심 질문	이 주제가 원래 답하던 질문
대표 산출물	남겨야 할 output 또는 결정 문서
아카이브 이유	프로젝트 종료, 리서치 낡음, 중복 흡수, 보안 분리 등
유지해야 할 근거	`raw/...`, `wiki/...`, `output/...`
다시 볼 조건	새 프로젝트 비교, 회고 재사용, 감사 요청, 복구 필요 등
이동 위치	`.archive/...` 또는 별도 보존 위치
복구 방법	인벤토리 상태 변경, 폴더 이동, 도구 restore 명령 확인

검증 체크리스트

주제 분리

새 자료를 넣기 전 기존 위키의 핵심 질문과 비교했다.
자료 형식이 아니라 실제 업무 질문으로 위치를 정했다.
독자, 업무 흐름, 출처, 보안 등급, 산출물 형식을 확인했다.
애매한 자료를 조용히 섞지 않고 보류 상태로 표시했다.
분리 기준을 규칙 파일에 둘 경우 결과를 사람이 다시 확인했다.

인벤토리

주제 위키가 세 개 이상이면 운영 목록이 있다.
주제 이름, 핵심 질문, 상태, 마지막 갱신일, 다음 행동이 있다.
마지막 갱신일과 다음 행동이 빈칸으로 남아 있지 않다.
LLM에게 인벤토리에 없는 주제를 추측하지 말라고 제한했다.
운영 중 주제만 기본 질문 맥락에 포함할 수 있다.

도구형 기능

도구 명령을 특정 구현체 기준으로만 설명했다.
사용 중인 도구의 README, 릴리스, 설치된 도움말을 확인했다.
아카이브 위치와 기본 검색 포함 여부를 확인했다.
잘못 아카이브한 주제를 복구하는 방법을 확인했다.
도구 기능이 있어도 원천 자료 보존과 사람 검토를 생략하지 않았다.

좋은 질문과 사람의 검증 질문

LLM에게 던질 질문

새 자료 후보 목록을 기존 위키의 핵심 질문과 비교해 기존 위키 추가, 기존 위키 안 주제 폴더, 새 주제 위키, 보류로 나누고 이유를 표로 작성해 주세요.
현재 인벤토리를 점검해 상태가 빠진 주제, 마지막 갱신일이 오래된 주제, 다음 행동이 모호한 주제, 아카이브 후보를 찾아 주세요.
두 주제 위키가 중복인지 핵심 질문, 독자, 자료 출처, 대표 산출물, 검증 기준으로 비교하고 대표 문서 후보를 제안해 주세요.
아카이브 후보 주제를 평가하되 삭제하지 말고 아카이브 이유, 다시 볼 조건, 보존 위치, 복구 방법 확인 필요를 나누어 주세요.
인벤토리에 없는 주제를 추측하지 말고 현재 운영 중 주제만 기준으로 다음 주 점검 계획을 만들어 주세요.

사람이 확인할 질문

새 자료는 기존 위키의 핵심 질문에 답하는가, 다른 질문을 여는가?
같은 회의록이라는 이유만으로 다른 업무 질문의 자료를 한곳에 넣고 있지 않은가?
주제 분리를 하면 관리할 사람이 있고 인벤토리에서 상태를 볼 수 있는가?
인벤토리의 다음 행동이 실제로 실행 가능한 문장인가?
아카이브한 주제를 언제 다시 볼지 조건이 남아 있는가?
아카이브한 주제가 기본 LLM 질문 맥락에서 제외되는지 확인했는가?
오래됐지만 자주 쓰는 기준 문서를 아카이브해 다음 질문에서 근거를 잃고 있지 않은가?

한계와 확인 필요

이 문서는 2026-06-06 KST에 확인된 Markdown 분석을 HTML로 변환한 것이다. 원문 세부 표현, 실습 명령, 마지막 편집 여부는 WikiDocs 원문에서 다시 확인해야 한다.
원문이 언급한 외부 도구와 문서는 확인일 기준의 참고 근거다. 실제 사용 전 현재 공식 문서, 릴리스, 설치된 도움말을 다시 확인해야 한다.
학습용 inventory.md, topics/, .archive/ 구조를 실제 저장소에서 실행하면 기존 자료를 덮어쓰거나 이동할 수 있으므로 경로와 백업을 먼저 확인해야 한다.
보안상 분리해야 할 자료는 단순 아카이브 이동으로 충분하지 않을 수 있다. 고객 정보, 계약 조건, 개인정보, 비공개 코드, 내부 정책 원문은 접근 제한과 감사 기준을 별도로 확인해야 한다.
인벤토리는 운영 문서이므로 갱신되지 않으면 오히려 위험하다. 마지막 갱신일과 다음 행동이 오래 비어 있으면 주간 점검에서 먼저 다뤄야 한다.

완료 기준

새 자료를 기존 위키에 넣을지, 기존 위키 안 주제 폴더로 둘지, 새 주제 위키로 나눌지 판단하는 기준이 있다.
분리 기준이 자료 형식이 아니라 핵심 질문, 독자, 업무 흐름, 보안 등급, 산출물 형식에 근거한다.
주제 위키가 세 개 이상이면 운영 인벤토리가 있다.
인벤토리에 주제 이름, 핵심 질문, 상태, 마지막 갱신일, 다음 행동, 대표 산출물이 있다.
LLM에게 인벤토리를 읽힐 때 운영 중 주제만 사용하게 하고, 인벤토리에 없는 주제를 추측하지 말라고 제한할 수 있다.
오래된 주제를 삭제하지 않고 아카이브 후보로 평가한다.
아카이브 판단이 날짜 하나가 아니라 프로젝트 종료, 최신성, 중복 흡수, 보안 분리, 계속 참조 여부를 함께 본다.
아카이브 기록에는 날짜, 이유, 다시 볼 조건, 보존 위치, 복구 또는 재검토 방법이 남아 있다.
도구형 아카이브를 사용할 경우 현재 문서와 설치된 도움말에서 아카이브 위치, 기본 검색 포함 여부, 복구 방법을 확인했다.
8.4의 daily-inbox와 주간 점검에서 인벤토리 상태, 다음 행동, 아카이브 후보를 계속 갱신할 준비가 되어 있다.