문서 91개를 올리려다 16개만 남긴 이유

조직이 프로젝트 하나를 굴리는 동안 문서는 끝없이 쌓입니다. 회의록, 결정 기록, 트러블슈팅 노트가 폴더를 채웁니다. 그런데 프로젝트가 끝나는 순간 그 문서 대부분은 그 폴더 안에서 조용히 묻힙니다. 다음 프로젝트에서 똑같은 문제를 다시 만나도 누구도 옛 문서를 열지 않습니다.

이건 흔한 지식 자산화 실패입니다. 조직이 값을 치르고 얻은 지식이 프로젝트마다 매장되고, 재사용이 되지 않습니다. 최근 어떤 내부 프로젝트 관리 도구에서 한 프로젝트의 문서를 회사 공용 지식으로 끌어올리는 파이프라인을 처음 끝까지 돌려봤습니다. 이 글은 그 첫 완주에 대한 회고입니다.

문서 91개에서 시작했습니다

대상 프로젝트의 문서는 161개였습니다. 그중 자동 생성 로그나 빈 껍데기 같은 노이즈를 걷어내니 91개가 남았습니다. 증분 처리는 매번 전체를 다시 훑지 않고 변경분 diff만 집어 올리도록 설계했습니다.

여기서 첫 갈림길이 나옵니다. 91개를 전부 공용 지식으로 올릴 수도 있었습니다. 그게 손이 가장 덜 가는 선택입니다. 하지만 다 올리면 공용 지식 창고가 프로젝트 부스러기로 가득 찹니다. 나중에 검색해도 진짜 쓸 문서가 잡동사니에 묻힙니다.

두 문항으로 좁힌 승격 게이트

그래서 승격 기준을 딱 두 문항으로 좁혔습니다. 첫째, 이 문서가 프로젝트가 끝나도 유효한 지식인가. 이건 수명에 대한 질문입니다. 특정 회의 일정이나 그날의 임시 결정은 프로젝트와 함께 수명이 끝납니다. 둘째, 나중에 누군가 지식을 소비할 때 이 문서를 다시 열어볼 만한가. 이건 재소비 가치에 대한 질문입니다.

두 문항 모두 예인 문서만 승격 후보가 됩니다. 하나라도 아니오면 제자리에 둡니다. 기준을 두 개로 묶은 이유는, 관문이 많아질수록 판정이 흐려지고 심사자마다 결과가 달라지기 때문입니다. 수명과 재소비 가치, 이 두 축이 재사용 지식의 본질을 거의 다 설명합니다.

심사는 병렬 에이전트, 판정은 사람

91개를 사람이 한 장씩 읽어 두 문항을 매기는 건 비쌉니다. 그래서 심사는 병렬 에이전트 세 개에 맡겼습니다. 각 에이전트가 문서를 나눠 받아 두 문항으로 예와 아니오를 판정하고, 둘 다 예인 것만 후보로 올립니다.

결과는 후보 16건이었습니다. 특정 프로젝트에 매인 지식 6건과 어디서나 쓰이는 범용 노하우 10건입니다. 나머지 75건은 제자리에 남았습니다. 91개 중 16개, 수확률 18%입니다.

여기서 선을 하나 그었습니다. 심사 비용은 기계가 치르되, 최종 판정은 사람이 합니다. 후보 16건은 전건을 사람이 눈으로 보고 승인한 뒤에만 등록했습니다. AI 심사에는 오탐과 미탐이 있습니다. 사람 게이트 없이 전자동으로 밀면 지식 창고가 그대로 오염됩니다.

싼 분류는 자동으로, 비싼 판정은 사람으로 나누는 이 2단계 게이트는 이번에 처음 짜낸 구조가 아닙니다. 예전에도 AI 자동 분류 위에 사람 검토 게이트를 얹어 산출물 품질을 지킨 적이 있습니다.

인박스가 아니라 제안함에 담았습니다

승격 후보를 어디에 담느냐도 그냥 지나칠 문제가 아니었습니다. 처음엔 임시 메모함인 인박스에 넣을까 했습니다. 하지만 인박스는 며칠 안에 비워야 하는 휘발성 임시함입니다. 승격 후보는 사람 승인을 기다리는 대기 큐라 성격이 다릅니다.

그래서 별도의 제안함을 뒀습니다. 인박스가 흘려보내는 곳이라면 제안함은 쌓아두고 심사하는 곳입니다. 둘은 처리 속도도, 존재 이유도 다른 차원의 함입니다. 같은 상자에 섞으면 승격 후보가 임시 메모에 밀려 사라집니다.

승격 후보를 별도 큐에 두고 사람 승인을 거치게 한 건, AI가 발견한 것을 즉시 반영하지 않고 그 사이에 게이트를 두려는 같은 생각의 연장입니다.

어느 위키에 올릴지가 절반입니다

승격이 끝이 아닙니다. 후보 16건을 어디에 등록하느냐가 남습니다. 특정 프로젝트에 매인 지식은 그 프로젝트의 회사 위키로, 범용 노하우는 글로벌 노하우로 나눴습니다. 운영을 맡은 회사와 실제 고객사가 다를 때는 소속도 그에 맞게 갈랐습니다.

이 경계를 잘못 그으면 엉뚱한 위키에 지식이 박힙니다. 그래서 클라이언트 경계를 먼저 정의하고 등록을 시작했습니다. 등록 후에는 실제로 그 프로젝트 채팅의 컨텍스트 앞부분에 회사 위키 6건이 실려 들어가는지까지 확인했습니다. 올리기만 하고 주입이 안 되면 승격은 장부상 숫자로만 남습니다.

이 방식이 흔들리는 지점

이 파이프라인이 만능은 아닙니다. 두 문항의 표현이 느슨하면 수확률이 크게 튑니다. 기준 문장 자체가 곧 품질이라, 문항을 어떻게 쓰느냐에 결과가 좌우됩니다. 사람 승인이 그 흔들림을 잡아주는 보정 장치입니다.

AI 심사에는 오탐과 미탐이 남습니다. 좋은 문서를 떨어뜨리기도, 부스러기를 올리기도 합니다. 그래서 사람 게이트가 전제 조건입니다. 프로젝트 소속 판정이 틀리면 지식이 엉뚱한 위키로 갑니다. 클라이언트 경계를 먼저 못 박은 이유입니다.

정리하면

운영하며 쌓은 문서 대부분은 그 프로젝트에서 죽습니다. 다시 쓸 만한 건 소수였고, 이번엔 18%였습니다. 다 올리면 지식 창고가 노이즈로 찹니다. 승격 기준을 수명과 재소비 가치 두 문항으로 좁히고, 심사는 병렬 에이전트에, 판정은 사람에 맡기는 구조가 이번 첫 완주의 뼈대였습니다.

이 작업은 아직 수동 단계입니다. 로드맵은 수동 완주에서 명세와 스킬로 굳히고, 그다음 월간 스케줄로 도는 자동 러너와 제안함 화면까지 가는 순서로 잡았습니다.

승격 파이프라인을 검토하는 체크리스트

📋 우리 조직의 문서는 프로젝트가 끝난 뒤 재사용되고 있는가, 아니면 폴더에 매장되는가

📋 공용 지식으로 올릴 기준이 두세 문항으로 명확한가 (수명 + 재소비 가치)

📋 심사(싼 일)와 승인(비싼 판정)이 기계와 사람으로 분리돼 있는가

📋 승격 후보가 휘발성 임시함이 아니라 별도 큐에 쌓이는가

📋 등록 위치(프로젝트 위키 vs 범용)와 클라이언트 경계가 등록 전에 정의돼 있는가

첫 완주의 숫자는 91개 중 16개, 수확률 18%였습니다. 나머지 82%를 올리지 않기로 한 판단이 이 파이프라인의 핵심이었습니다.