암묵지를 위키에 쌓는 법
노트 한 장이 아니라 계속 쌓이는 틀
조직 위키와 AI 기억의 첫째 갈래입니다. 사람 머릿속에 있는 일의 요령을 조직이 함께 쓰는 지식으로 옮기다가 우리가 잘못 잡았던 자리를 모았습니다.
요지
암묵지를 옮기는 일의 산출물은 설계 노트 한 장이 아니라 규칙과 사례가 위키에 계속 쌓이는 상태입니다. 쌓는 길은 쉬워야 하므로 입구에서 판단을 요구하지 않고, 안전은 절차의 단계 수가 아니라 닫힌 기본값으로 챙깁니다. 그리고 조직마다 자기가 누구인지 적은 팩트시트가 있어야 AI가 추측을 퍼뜨리지 않습니다.
1. 노트 한 장으로 끝내지 말고 계속 쌓이는 틀을
현장 기록에 따르면 한 의료사협 원장이 가진 진료비 청구와 이의신청 요령을 기록하는 일이 있었습니다. 우리는 흐름도와 설계 노트 한 장을 위키에 올리고 끝내려 했는데, 돌아온 지적은 이 암묵지를 계속 위키로 쌓아 가야 한다는 것이었습니다. 설계 노트는 방법일 뿐이고, 쓸모는 그 방법이 낳는 사례 카드와 규칙 한 줄 한 줄에 있습니다. 그것이 위키에 쌓이지 않으면 요령은 원장의 머릿속에서 녹음과 전사를 거쳐 AI 작업 폴더 안에서 멈추고, 처음 목표였던 「다른 사람도 할 수 있게」에 닿지 못합니다.
그 뒤로 우리는 아래처럼 틀부터 세우고 채우는 손을 정해 둡니다.
- 산출물 틀을 위키 노드 셋으로 먼저 세웁니다. 상황마다 할 행동을 적는 규칙 노드, 식별 정보를 뗀 건별 카드를 모으는 사례집, 무엇이 언제 바뀌었는지 적는 변경일지입니다.
- 빈 틀을 채우는 손은 그 조직의 AI이고, 위키에 올리는 권한도 그 AI가 갖습니다. 바깥에서 돕는 쪽은 설계 노트와 그림만 올립니다.
- 엑셀이나 데이터 파일은 노드에서 뽑아내는 산출본으로 두고, 고칠 일이 생기면 노드만 고칩니다.
- 사람이 AI의 초안에 「그대로」나 「고침」 한 줄을 주면 같은 날 규칙 노드와 변경일지를 고칩니다. 우리 경우엔 같은 규칙에 「그대로」가 10건 연이어 나오면 그 규칙을 확정으로 봅니다.
녹음을 어떻게 받을지도 같은 현장에서 배웠습니다. 작업 내내 혼잣말을 녹음해 달라는 설계는 실패했고, 그 일이 이미 가진 분류 단위마다 한 번씩 짧게 받는 쪽으로 바꿨습니다. 그 경위는 무엇을 지을지의 7절에 있습니다.
2. 입구에서 판단하지 말고 임시 수신함으로
우리 기록에 따르면 메신저 봇으로 위키에 파일을 올리는 기능을 설계하면서, 대화방마다 열람 등급을 대응시키고 계획을 보고한 뒤 「배포 확정」 답장을 받는 두 단계 절차를 짰던 적이 있습니다. 승인까지 받았는데 구현 직전에 뒤집었습니다. 안전에 문제가 있어서가 아니라 아무도 쓰지 않을 절차였기 때문입니다. 파일 하나 올리는 데 등급을 고르고 확정 답장까지 해야 하는 봇을 쓸 사람은 없습니다.
판단을 입구에 두면 올릴 때마다 판단하는 비용이 들지만, 임시 수신함으로 미뤄 두면 나중에 한 번 검토하면서 여러 건을 묶어 처리할 수 있습니다.
- 입구에는 고정값 하나만 두어서, 들어온 것은 전부 임시 폴더에 비공개 노드로 쌓이고, 방이나 보낸 사람에 따라 바뀌지 않습니다.
- 안전은 단계 수로 확보하지 않고, 임시 노드를 처음부터 비공개로 두는 닫힌 기본값으로 확보합니다.
- 「아직 검토 안 함」 표시는 노드 본문 맨 앞의 배너로 붙입니다. 폴더 이름에만 적어 두면 검토하는 사람이 노드를 열었을 때 보이지 않습니다.
- 쓰는 쪽의 등급 판단은 없애지만 읽는 쪽의 등급 필터는 유출을 막는 장치라서 그대로 둡니다.
보안이 걱정된다는 이유로 입구를 막지도 않습니다. 한 협동조합의 조합원 명부를 데이터베이스에 올리려 할 때, 무료 요금제에서는 권한을 나눌 수 없으니 올리면 안 된다고 막았던 일이 있습니다. 권한을 못 나눈다는 말은 사실이었지만 실무자는 명부를 보지 않고는 일을 못 하고, 데이터베이스에 없으면 자동화도 없습니다. 적재는 진행하고, 위험은 행 단위 보안과 화면 분리와 권한 등급 같은 설계 과제로 따로 올립니다. 그 설계는 DB 권한과 격리의 실체에 있습니다.
3. 모은 자료는 위키 노드로
우리가 정해 둔 기준에 따르면 한 주제로 자료를 다섯 개 넘게 찾아 읽고 번역했을 때는 사업계획서 본문에만 넣고 끝내지 않고 위키 노드를 만듭니다. 사업이 끝나면 계획서는 서랍에 들어가지만 위키 노드는 다음 사업과 다른 조직이 다시 씁니다. 사업계획서는 위키를 한 번 인용한 문서이고, 본체는 위키입니다.
노드는 주제별로 나누는데, 사람 이름이나 사업 이름으로 폴더를 만들면 주제가 흩어지므로, 누가 자료를 줬는지는 문서 머리의 기여자 칸에 적습니다. 바깥 사람에게 자료를 받을 때는 처음부터 검토 화면을 만들지 않았습니다. 검증된 사람이 공유 폴더에 올리면 그것을 승인으로 보고 시작했고, 사람과 자료가 늘면 그때 검토 화면을 붙이기로 했습니다.
4. 조직 정체성 팩트시트부터
우리 기록에 따르면 본부 AI가 우리 조직의 설립 연도와 소재지를 조각난 기억에 기대어 쓰다가 여러 번 틀렸습니다. 같은 무렵 바깥의 AI 채팅 서비스는 우리 사이트를 수상한 사이트로 분류했습니다. 조직이 자기 정체성을 한 장에 적어 두지 않으면 우리 AI와 사람과 바깥 AI가 모두 추측을 돌려 씁니다.
팩트시트는 출처에 따라 쓰는 방법이 다릅니다.
| 대상 | 출처 | 쓰는 방법 |
|---|---|---|
| 서류가 없는 연합체나 허브 | 대표자의 기억 | 구술을 끌어낸다. AI는 질문만 설계하고 정의 문장을 직접 쓰지 않는다 |
| 법인 | 등기와 사업자 서류, 연차보고서 | 서류 원문을 인용한다. 열어 보기 전에 추측하지 않는다 |
| 이미 노드가 많은 사업 | 기존 위키 노드 | 모아서 요약한다 |
팩트시트가 서기 전에는 바깥으로 나가는 소개문이나 AI용 사이트 안내 파일 같은 작업을 미뤄 둡니다. 기준이 없는 상태에서 쓴 소개문은 고칠 곳만 늘립니다.