지식 관리와 회사 위키 만들기

위키는 문서를 모아두는 곳이 아니다

회사 위키를 만들 때 가장 흔한 실수는 모든 문서를 한곳에 넣는 것이다. 처음에는 정리된 것처럼 보이지만, 시간이 지나면 오래된 정책, 임시 회의 메모, 확정된 절차가 뒤섞인다. 결국 사람들은 위키를 믿지 못하고 다시 동료에게 묻는다.

좋은 위키의 목적은 "문서가 있다"가 아니라 "필요한 순간에 믿고 찾을 수 있다"이다. 개인 지식 관리도 같다. 읽은 글, 업무 메모, 아이디어를 아무 페이지에나 쌓으면 나중에 다시 꺼내기 어렵다. 반대로 지식의 종류와 사용 시점을 정해두면 기록은 자료실이 아니라 판단을 돕는 시스템이 된다.

노션에서 위키를 만들 때는 세 가지 질문으로 시작하면 좋다.

• 이 문서는 누가 읽는가?

• 이 문서는 언제 다시 확인되는가?

• 이 문서의 신뢰도는 누가 책임지는가?

이 질문에 답할 수 있어야 위키가 오래 유지된다.

AI 생성 이미지

회사 홈에서 시작해 팀별 공간으로 내려가기

회사 위키의 첫 화면은 모든 정보를 펼쳐놓는 게시판이 아니라 길잡이여야 한다. 새로 합류한 사람도, 오래 일한 사람도 어디로 가야 할지 바로 알 수 있어야 한다.

기본 구조는 다음처럼 잡을 수 있다.

• 회사 홈

  • 회사 소개와 일하는 방식

  • 공통 정책

  • 팀별 페이지

  • 온보딩 안내

  • 자주 찾는 문서

• 팀별 페이지

  • 팀 목표와 역할

  • 주요 업무 프로세스

  • 사용하는 도구와 계정 안내

  • 팀 회의록과 프로젝트 링크

  • 팀 전용 온보딩 자료

• 정책 문서

  • 근무 제도

  • 비용 처리

  • 휴가 신청

  • 보안 규칙

  • 채용과 평가 기준

• 온보딩 자료

  • 첫날 해야 할 일

  • 첫 주에 읽을 문서

  • 자주 묻는 질문

  • 팀별 학습 경로

여기서 중요한 점은 모든 문서를 회사 홈에 직접 넣지 않는 것이다. 회사 홈에는 큰 입구만 둔다. 실제 문서는 팀별 페이지나 위키 데이터베이스에 넣고, 회사 홈에서는 필요한 곳으로 이동하게 만든다.

개인용 지식 관리도 같은 방식으로 구성할 수 있다. 예를 들어 개인 홈에는 업무 노트, 학습 자료, 독서 기록, 아이디어, 참고 링크 정도의 입구만 둔다. 세부 내용은 각 영역 안에서 관리한다. 처음부터 모든 것을 한 페이지에 모으면 검색은 쉬워 보여도 읽기와 유지보수가 어려워진다.

위키 데이터베이스로 문서를 관리하기

문서 수가 적을 때는 페이지 목록만으로도 충분하다. 하지만 회사 정책, 업무 절차, 온보딩 자료, 회고 문서가 늘어나면 단순한 페이지 구조만으로는 한계가 생긴다. 이때 위키 데이터베이스를 사용하면 문서를 목록이 아니라 관리 대상처럼 다룰 수 있다.

위키 데이터베이스의 기본 속성은 다음 정도면 충분하다.

처음부터 속성을 많이 만들 필요는 없다. 특히 태그를 지나치게 많이 만들면 분류가 흐려진다. 위키의 핵심 속성은 문서를 찾는 기준과 신뢰도를 판단하는 기준이어야 한다. 그래서 문서 유형, 담당 팀, 최신 검토일, 상태가 중요하다.

보기는 목적별로 나눈다.

• 전체 문서: 모든 위키 문서를 표로 확인한다.

• 팀별 문서: 담당 팀 기준으로 그룹화한다.

• 정책 문서: 문서 유형이 정책인 항목만 보여준다.

• 온보딩 필수 문서: 중요도가 높고 문서 유형이 온보딩인 항목을 보여준다.

• 검토 필요 문서: 최신 검토일이 오래되었거나 상태가 검토 필요인 문서만 보여준다.

이렇게 하면 같은 문서를 여러 곳에 복사하지 않고도, 읽는 사람의 상황에 맞는 화면을 만들 수 있다.

검증된 문서와 오래된 문서를 구분하기

위키가 실패하는 가장 큰 이유는 오래된 문서가 새 문서처럼 보이기 때문이다. 사람이 문서를 열었을 때 "이 내용을 믿어도 되는가?"를 바로 판단할 수 있어야 한다.

이를 위해 문서 상태를 명확히 나눈다.

• 검증됨: 담당자가 최근에 확인했고 현재 기준으로 사용할 수 있는 문서

• 검토 필요: 내용이 오래되었거나 변경 가능성이 있어 확인이 필요한 문서

• 초안: 아직 확정되지 않았지만 작성 중인 문서

• 보관: 현재 업무에는 쓰지 않지만 기록 목적으로 남기는 문서

상태를 나누는 것만으로는 부족하다. 검토 주기도 함께 정해야 한다. 예를 들어 근무 제도나 보안 정책처럼 영향이 큰 문서는 분기마다 확인한다. 팀 내부 절차는 반기마다 확인해도 된다. 제품 기능 설명처럼 자주 바뀌는 문서는 주요 릴리스 후에 검토한다.

노션에서는 최신 검토일 속성을 기준으로 검토 필요 보기를 만들 수 있다. 예를 들어 90일 이상 검토되지 않은 중요 문서를 따로 보여주면, 관리자가 오래된 문서를 놓치지 않는다.

운영 규칙은 단순해야 한다.

1. 모든 중요 문서에는 담당 팀과 담당자를 둔다.

2. 정책과 절차 문서는 최신 검토일을 반드시 기록한다.

3. 검토가 끝난 문서는 상태를 검증됨으로 바꾼다.

4. 더 이상 쓰지 않는 문서는 삭제보다 보관 상태로 바꾼다.

5. 같은 내용의 문서가 여러 개 있으면 하나를 원본으로 정하고 나머지는 링크로 연결한다.

위키는 완벽한 문서 모음이 아니라 계속 갱신되는 지식 기반이다. 따라서 "누가 최신 상태를 책임지는가"가 구조보다 더 중요하다.

회의록과 프로젝트 문서를 위키로 승격하기

팀에서 중요한 지식은 처음부터 위키 문서로 태어나지 않는다. 대개 회의록, 프로젝트 문서, 업무 메모에서 시작된다. 문제는 그 안에 중요한 결정이 숨어버리는 것이다.

예를 들어 프로젝트 회의록에 "앞으로 고객 문의는 A 채널로만 접수한다"는 결정이 적혀 있다고 하자. 그 결정이 회의록 안에만 있으면, 회의에 참석하지 않은 사람은 알기 어렵다. 몇 달 뒤 새 팀원이 들어오면 또 누군가에게 물어봐야 한다.

이때 필요한 흐름이 승격이다. 승격은 임시 기록에서 오래 유지할 지식을 골라 위키 문서로 옮기는 작업이다.

회의록과 프로젝트 문서를 검토할 때 다음 항목은 위키로 승격할 후보가 된다.

• 앞으로 반복해서 따라야 할 업무 절차

• 팀 전체가 알아야 하는 정책 변경

• 고객이나 제품에 대한 확정된 기준

• 신규 입사자가 반드시 알아야 할 배경지식

• 자주 반복되는 질문에 대한 답변

• 프로젝트가 끝난 뒤에도 남겨야 할 의사결정 근거

승격할 때는 회의록을 그대로 복사하지 않는다. 회의록은 논의의 흐름을 남기는 문서이고, 위키는 실행 기준을 알려주는 문서다. 따라서 위키 문서에는 결론, 적용 대상, 구체적인 절차, 담당 팀, 시행일을 중심으로 정리한다.

예를 들어 회의록의 한 줄 결정은 위키에서 이렇게 바뀐다.

고객 문의 접수 채널은 2026년 7월 1일부터 A 채널로 통일한다. 기존 이메일 접수는 예외 상황에만 사용한다. 운영 담당은 고객지원팀이며, 채널 변경 안내 문구는 아래 템플릿을 사용한다.

이렇게 정리하면 결정이 실행 가능한 지식이 된다. 원래 회의록은 관련 페이지로 연결해두면 된다. 나중에 "왜 이렇게 정했는가?"가 필요할 때 회의록으로 돌아가 맥락을 확인할 수 있다.

새 팀원을 위한 온보딩 경로 만들기

좋은 위키는 검색만 잘 되는 것이 아니다. 처음 들어온 사람이 무엇부터 읽어야 하는지 알려준다. 새 팀원은 회사의 모든 문서를 한 번에 이해할 수 없다. 그래서 온보딩 경로는 순서가 있어야 한다.

온보딩 페이지는 다음 순서로 구성하면 읽는 부담이 줄어든다.

1. 회사 전체 이해: 회사 소개, 조직 구조, 일하는 원칙

2. 기본 정책 확인: 근무 제도, 휴가, 비용 처리, 보안 규칙

3. 도구 세팅: 노션, 메신저, 이메일, 프로젝트 관리 도구 접근 방법

4. 팀 이해: 팀 목표, 역할, 주요 업무 흐름

5. 반복 업무 학습: 업무 절차, 체크리스트, 예시 문서

6. 자주 묻는 질문: 처음 한 달 동안 자주 막히는 문제

7. 첫 번째 실행 과제: 실제로 해볼 작은 업무와 확인 담당자

노션에서는 이 온보딩 페이지 안에 링크드 데이터베이스를 넣어 문서 유형 = 온보딩, 중요도 = 높음, 담당 팀 = 해당 팀인 문서만 보여줄 수 있다. 이렇게 하면 팀별 온보딩 페이지를 따로 복사하지 않아도 된다. 원본 위키 데이터베이스는 하나이고, 각 팀 페이지에서는 필요한 문서만 필터로 보여준다.

검색을 고려한 문서 제목도 중요하다. 사내에서 사람들이 실제로 쓰는 단어를 제목과 본문에 넣어야 한다. 예를 들어 공식 명칭이 지출 승인 프로세스라 해도 구성원들이 보통 비용 처리라고 검색한다면, 문서 제목이나 첫 문단에 두 표현을 함께 넣는 것이 좋다.

문서 안에는 관련 문서 링크를 적절히 넣는다. 보안 정책 문서에는 계정 발급 가이드를 연결하고, 비용 처리 문서에는 영수증 제출 템플릿을 연결한다. 링크는 독자가 다음에 해야 할 행동으로 이동하게 만드는 길이다.

오래 쓰는 위키의 기준

회사 위키는 한 번 정리하고 끝나는 프로젝트가 아니다. 업무가 바뀌면 위키도 바뀌어야 한다. 그래서 처음부터 거창한 구조보다 운영 가능한 구조가 좋다.

다음 기준을 기억하자.

• 회사 홈은 입구이고, 세부 문서는 위키 데이터베이스에서 관리한다.

• 문서는 유형, 담당 팀, 최신 검토일, 중요도, 상태로 분류한다.

• 오래된 문서가 새 문서처럼 보이지 않게 검토 필요 상태를 만든다.

• 회의록과 프로젝트 문서의 핵심 결정은 위키로 승격한다.

• 새 팀원이 따라갈 수 있는 온보딩 경로를 만든다.

위키의 품질은 문서 수로 결정되지 않는다. 필요한 사람이 필요한 순간에 신뢰할 수 있는 답을 찾을 수 있는지가 더 중요하다. 노션의 페이지, 데이터베이스, 링크, 필터를 이 기준에 맞게 사용하면 위키는 단순한 자료실을 넘어 팀의 기억이 된다.