왜 사내 위키는 만들었는데 아무도 찾지 않을까? 사내 위키 작성법의 핵심은 문장을 예쁘게 쓰는 데 있지 않습니다. 팀원이 같은 질문을 덜 하고, 신규 입사자가 업무 흐름을 빨리 따라오며, 담당자가 바뀌어도 판단 기준이 끊기지 않도록 지식을 재사용 가능한 형태로 남기는 데 있습니다.
사내 위키는 조직 안의 업무 흔적을 모으는 장소입니다. 하지만 흔적이 많다고 길이 되는 것은 아닙니다. 제목이 모호하고, 담당자가 없고, 언제 고친 문서인지 알 수 없으면 위키는 곧 오래된 파일 창고가 됩니다. 좋은 내부 위키는 “누가, 언제, 무엇을, 어떤 기준으로, 어떻게 해야 하는지”를 빠르게 보여주는 지식 인프라입니다.
사내 위키의 목적은 저장이 아니라 재사용이다
문서가 많아도 재사용되지 않으면 위키로서 실패합니다. 회의록, 절차서, 정책, FAQ가 흩어져 있고 검색해도 원하는 답을 찾지 못한다면 사람들은 다시 메신저에 묻습니다. 결국 문서화는 늘어나지만 반복 질문은 줄지 않습니다.
좋은 사내 위키 문서는 작성자의 기억을 독자의 실행으로 바꿉니다. “지난번에 이렇게 했던 것 같다”가 아니라 “이 경우에는 이 기준에 따라 이렇게 처리한다”로 바뀌어야 합니다. 그래서 문서의 첫 목표는 기록량이 아니라 다음 사용자가 같은 일을 덜 헤매게 만드는 것입니다.
문서를 만들 때는 항상 세 가지 질문을 먼저 던지세요. 이 문서는 누가 찾는가, 읽은 뒤 무엇을 할 수 있어야 하는가, 6개월 뒤에도 같은 기준으로 쓸 수 있는가. 이 질문에 답하지 못하면 문서 제목과 구조부터 다시 잡아야 합니다.
사내 위키 문서에 반드시 들어가야 할 기본 항목
대부분의 사내 문서는 아래 항목만 갖춰도 품질이 크게 올라갑니다. 모든 문서를 길게 만들 필요는 없지만, 검색과 유지보수에 필요한 정보는 빠지면 안 됩니다.
- 문서 제목
- 목적 또는 한 줄 요약
- 이 문서를 읽어야 하는 사람
- 적용 범위
- 상세 절차 또는 기준
- 예외 상황
- 담당자 또는 문서 소유자
- 최종 수정일과 다음 검토일
- 관련 문서 링크
- 변경 이력
문서 제목은 검색어처럼 쓴다
제목은 작성자가 붙이고 싶은 이름이 아니라 읽는 사람이 검색할 단어여야 합니다. “회의록_최종_진짜최종”보다 “신규 거래처 등록 절차”, “월간 리포트 제출 방법”, “법인카드 영수증 제출 기준”이 훨씬 좋습니다. 팀원이 실제로 메신저에 던지는 질문을 제목으로 바꾸면 검색성이 높아집니다.
첫 문단에는 결론과 사용 대상을 적는다
문서를 열자마자 “이 문서가 나에게 필요한가”를 판단할 수 있어야 합니다. 첫 문단에는 문서의 결론, 적용 대상, 사용 상황을 짧게 적으세요. 예를 들어 “이 문서는 신규 거래처를 ERP에 등록해야 하는 영업·운영 담당자를 위한 절차서입니다. 계약서 확인 후 재무팀 승인까지 완료해야 등록이 끝납니다”처럼 쓰면 됩니다.
담당자, 최종 수정일, 검토 주기를 표시한다
사내 문서의 신뢰도는 내용뿐 아니라 관리 정보에서 나옵니다. 담당자가 없는 문서는 질문할 곳이 없고, 수정일이 없는 문서는 지금도 맞는지 알 수 없습니다. 문서 상단 또는 하단에 소유자, 최종 수정일, 다음 검토일을 고정 항목으로 두세요.
관련 문서와 다음 행동을 연결한다
위키의 장점은 문서끼리 이어질 때 살아납니다. 비용 처리 절차서에는 법인카드 정책, 영수증 제출 FAQ, 월마감 일정 문서를 연결하세요. 관련 문서 링크는 단순 참고가 아니라 독자가 다음에 해야 할 행동으로 이어지는 길입니다.
문서 유형별로 쓰는 방식이 달라야 한다
절차서와 정책 문서, FAQ, 의사결정 기록을 한 형식으로 쓰면 독자는 헷갈립니다. Divio Documentation System은 문서를 목적에 따라 나누는 관점을 제시합니다. 사내 위키도 “따라 하는 문서”, “기준을 확인하는 문서”, “질문에 답하는 문서”, “맥락을 설명하는 문서”를 구분하면 찾기 쉽고 유지하기도 편합니다.
업무 절차서는 순서와 예외를 분리한다
업무 절차서는 준비물, 단계, 확인 방법, 자주 나는 오류, 담당자 순서로 쓰면 좋습니다. 절차 중간에 예외를 길게 섞으면 실행 흐름이 끊깁니다. 기본 절차를 먼저 번호 목록으로 제시하고, 예외 상황은 별도 섹션으로 분리하세요.
정책 문서는 기준과 책임 범위를 명확히 한다
정책 문서는 “권장합니다”보다 “적용됩니다”, “승인이 필요합니다”처럼 기준을 분명히 써야 합니다. 적용 범위, 원칙, 예외, 승인권자, 위반 시 처리 방식, 변경 이력을 포함하세요. 정책은 개인 해석을 줄이기 위해 존재합니다.
FAQ 문서는 질문 문장 그대로 시작한다
FAQ는 내부 용어보다 실제 질문을 제목으로 삼는 편이 좋습니다. “계정 권한 요청”보다 “외부 협력사에게 임시 계정을 발급하려면 어떻게 하나요?”가 검색에 유리합니다. 답변은 짧게 쓰고, 상세 절차는 별도 문서로 연결하세요.
의사결정 기록은 결론보다 맥락을 남긴다
의사결정 기록에는 결정일, 참여자, 논의한 선택지, 결정 이유, 포기한 대안, 후속 작업을 남깁니다. 시간이 지나면 “무엇을 결정했는가”보다 “왜 그렇게 결정했는가”가 더 중요해집니다. 맥락이 있어야 같은 논쟁을 반복하지 않습니다.
읽히는 사내 위키 문장을 쓰는 원칙
사내 위키 문장은 보고서처럼 무겁거나 개인 메모처럼 생략되어서는 안 됩니다. 명확하고 일관된 기술 문서를 지향하는 Google, Microsoft 스타일 가이드의 방향처럼, 내부 문서도 친절하되 군더더기 없이 써야 합니다.
- 한 문단에는 하나의 정보만 담습니다.
- 지시문은 “업로드합니다”, “확인합니다”, “공유합니다”처럼 동사로 끝냅니다.
- 조건은 문장 앞에 둡니다. 예: “계약 금액이 1천만 원을 넘으면 팀장 승인을 받습니다.”
- “적절히”, “필요 시”, “관련자” 같은 표현은 가능한 한 구체화합니다.
- 같은 개념은 같은 용어로 씁니다. 고객사, 거래처, 클라이언트를 섞지 않습니다.
- 내부 약어와 은어는 처음 한 번 풀어 씁니다.
중요한 정보와 불필요한 잡음을 구분하는 감각도 필요합니다. 모든 배경을 다 쓰면 독자는 핵심을 놓칩니다. 관련 읽을거리로는 Riviera Dogs의 신호 대 잡음비, 작은 신호를 가려내는 법을 참고할 수 있습니다.
바로 쓸 수 있는 사내 위키 템플릿
템플릿은 완벽해야 하는 것이 아니라 반복해서 쓰기 쉬워야 합니다. 항목이 너무 많으면 작성자가 포기합니다. 기본 템플릿은 8~10개 항목 안에서 시작하고, 문서 유형별로 필요한 항목만 추가하세요.
기본 문서 템플릿
- 문서 제목:
- 이 문서를 읽어야 하는 사람:
- 한 줄 요약:
- 적용 범위:
- 본문 내용:
- 주의할 점:
- 관련 문서:
- 담당자:
- 최종 수정일:
- 다음 검토일:
업무 절차서 템플릿
- 목적:
- 준비물 또는 사전 조건:
- 절차:
- 완료 확인 방법:
- 자주 발생하는 오류:
- 예외 상황:
- 문의 담당자:
- 관련 정책:
의사결정 기록 템플릿
- 결정한 내용:
- 결정일:
- 참여자:
- 검토한 선택지:
- 결정 이유:
- 선택하지 않은 대안:
- 후속 작업:
- 관련 문서:
문서가 낡지 않게 만드는 운영 규칙
사내 위키는 작성보다 유지가 어렵습니다. Nielsen Norman Group의 인트라넷 콘텐츠 전략에서도 콘텐츠 소유자, 최종 수정일, 메타데이터, 아카이브 기준, 중복 제거의 중요성을 강조합니다. 내부 문서도 누가 관리하고 언제 검토할지 정하지 않으면 빠르게 신뢰를 잃습니다.
모든 문서에는 소유자가 있어야 한다
문서 소유자는 내용을 모두 직접 작성하는 사람이 아닙니다. 최신성을 책임지고, 질문을 받아 정리하며, 변경이 생기면 문서를 갱신하는 사람입니다. 소유자가 퇴사하거나 역할이 바뀌면 문서 소유권도 함께 이관해야 합니다.
검토 주기는 문서 성격에 따라 다르게 둔다
- 정책·규정: 분기 또는 반기 검토
- 업무 절차: 변경 발생 시 즉시 수정하고 반기 검토
- FAQ: 월간 검토 또는 질문 누적 시 업데이트
- 의사결정 기록: 원칙적으로 수정하지 않고 후속 문서 연결
중복 문서는 합치고 오래된 문서는 보관한다
중복 문서는 정보 충돌의 원인입니다. 같은 주제의 문서가 여러 개라면 “정답 문서 하나”를 만들고 다른 위치에서는 그 문서로 링크하세요. 더 이상 쓰지 않는 문서는 삭제보다 보관 상태를 표시하는 편이 안전합니다. 단, 개인정보, 계정 정보, 영업기밀처럼 보안상 민감한 내용은 위키에 그대로 남기지 말고 별도 권한과 보안 정책을 적용해야 합니다.
카테고리와 검색성을 설계하는 법
카테고리를 부서명만으로 만들면 협업 업무를 찾기 어려워집니다. 조직도는 자주 바뀌고, 하나의 업무는 여러 부서를 지나갑니다. 따라서 큰 분류는 업무 흐름을 기준으로 잡는 것이 좋습니다.
- 온보딩
- 비용 처리
- 고객 대응
- 보안과 계정
- 운영 정책
- 회의와 보고
- 장애 대응
- 프로젝트 기록
태그는 적게, 일관되게 운영하세요. 태그가 수십 개로 늘어나면 아무도 고르지 않고 검색에도 도움이 되지 않습니다. 예를 들어 “정책”, “절차”, “FAQ”, “온보딩”, “보안”, “재무”처럼 제한된 목록을 정하고 새 태그는 관리자 또는 문서 담당자가 승인하게 할 수 있습니다.
사내 위키 작성 전 체크리스트
- 이 문서는 누가 읽는가?
- 독자는 이 문서를 읽고 무엇을 할 수 있어야 하는가?
- 제목에 독자가 검색할 단어가 들어 있는가?
- 첫 문단에 결론과 적용 대상이 있는가?
- 담당자, 최종 수정일, 다음 검토일이 표시되어 있는가?
- 절차와 예외가 분리되어 있는가?
- 중복 문서가 있는가?
- 관련 문서 링크가 있는가?
- 6개월 뒤에도 이해할 수 있는가?
- 보안상 공개하면 안 되는 정보가 포함되어 있지 않은가?
사내 위키 작성법에서 자주 하는 실수
모든 내용을 한 문서에 몰아넣는다
긴 문서가 항상 좋은 문서는 아닙니다. 절차, 정책, 배경 설명, FAQ가 한 페이지에 섞이면 독자는 원하는 답을 찾기 어렵습니다. 목적별로 나누고 서로 링크하세요.
담당자와 수정일을 남기지 않는다
내용이 맞더라도 최신성 표시가 없으면 신뢰하기 어렵습니다. 위키 문서의 신뢰는 검토 흔적에서 나옵니다. 문서의 역할과 책임 구조를 분명히 하는 일은 정보의 위계를 정리하는 일이기도 합니다.
회의 결론만 남기고 이유를 남기지 않는다
결론만 남기면 다음 회의에서 같은 질문이 반복됩니다. 결정 이유와 포기한 대안을 적어야 조직의 기억이 쌓입니다.
도구를 바꾸면 문제가 해결된다고 믿는다
Notion, Confluence, Google Docs, Wiki.js 중 무엇을 쓰느냐보다 중요한 것은 문서 구조, 소유권, 검색성, 업데이트 규칙입니다. 도구는 문서화 습관을 담는 그릇일 뿐입니다.
사내 위키는 팀의 기억을 관리하는 시스템이다
사내 위키의 목적은 모든 것을 기록하는 것이 아닙니다. 다시 설명해야 할 일을 줄이고, 같은 실수를 반복하지 않으며, 팀이 같은 기준으로 판단하게 만드는 것입니다. 신규 입사자에게는 지도이고, 기존 구성원에게는 기준이며, 관리자에게는 조직 기억의 상태를 보여주는 계기판입니다.
처음부터 거대한 지식 관리 체계를 만들 필요는 없습니다. 반복 질문이 많은 업무, 담당자 변경 시 끊기는 업무, 승인 기준이 자주 흔들리는 업무부터 시작하세요. 다만 작게 시작하더라도 제목, 소유자, 수정일, 관련 문서 링크 네 가지는 처음부터 지켜야 합니다. 이 네 가지가 있어야 사내 위키는 쌓이기만 하는 저장소가 아니라 실제로 검색되고 유지되고 재사용되는 내부 지식 인프라가 됩니다.