실제로 쓰이는 팀 위키 만드는 법: 구조, 책임자, 검색

대부분의 팀 위키가 1년 안에 죽는 이유

위키는 예측 가능한 순서로 죽습니다. 누군가 의욕적으로 깊은 폴더 구조를 만듭니다. 첫날부터 빈 가지가 있어서 사람들은 신뢰하지 않게 됩니다. 맞는 자리를 찾지 못해 새 페이지는 최상위에 만들어집니다. 석 달이 지나면 같은 주제의 페이지가 두 개 있고 하나는 틀렸습니다. 누군가 검색해서 틀린 페이지를 열고, 그때부터는 채팅에서 묻습니다.

각 단계에는 설계로 막을 수 있는 원인이 있습니다.

• 빈 구조. 내용보다 폴더를 먼저 만들었습니다. 해결: 들어갈 페이지가 세 개 준비됐을 때만 섹션을 만듭니다.
• 책임자 없음. 아무도 책임지지 않는 페이지는 틀릴 때까지 표류합니다. 해결: 페이지마다 한 사람의 이름을 페이지 위에 보이게 둡니다.
• 중복 페이지. 약한 검색과 이름 규칙 부재가 원인입니다. 해결: 명명 규칙과 매주 5분의 병합 작업.
• 낡은 내용. 1월에는 맞는 페이지였습니다. 해결: 모든 페이지에 검토일을 두고 분기마다 정리합니다.
• 답하지 않고 나열하는 검색. "환불 정책이 뭐지?"라고 묻는 사람은 '환불'이라는 단어가 들어간 문서 아홉 개를 원하지 않습니다. 해결: 검색이 좋은 도구를 고르고, 사람들이 묻는 질문 그대로 제목을 씁니다.

소규모 팀을 위한 위키 구조

최상위 섹션 네 개면 15명 이하 팀에 필요한 거의 모든 것이 담깁니다. 이 중 하나가 넘칠 때까지 다섯 번째를 추가하고 싶은 마음을 참으세요.

핸드북은 가장 느리게 바뀌고 신규 입사자가 가장 먼저 읽는 것입니다. "일하는 방식"은 운영 매뉴얼입니다. 런북은 새벽 2시에 여러분을 구하는 페이지입니다. 의사결정은 회사의 기억이자 대부분의 팀이 건너뛰는 섹션입니다. 네 번째 섹션에 맞는 의사결정 로그 템플릿을 운영하고 있습니다.

각 섹션 안에서는 섹션, 주제, 페이지의 세 단계보다 깊게 중첩하지 마세요. "런북 / 인프라 / 데이터베이스 비밀번호 교체"는 괜찮습니다. 그보다 깊으면 사람들은 맞는 가지를 찾는 대신 최상위에 중복을 만듭니다.

페이지 이름은 질문이나 동사로

런북은 동사로 이름 짓습니다. "API 배포하기", "고객에게 환불하기", "API 키 교체하기". 핸드북과 일하는 방식 페이지는 사람들이 묻는 질문으로 이름 짓습니다. "휴가는 어떻게 신청하나요?", "무엇이 경비 처리되나요?", "스탠드업은 언제인가요?". 제목은 검색이 가장 먼저 대조하는 부분이고, 사람들은 동료에게 물을 때 쓰는 말로 검색합니다.

위키를 살아 있게 하는 책임 규칙

구조는 쉬운 부분입니다. 첫 달이 지난 뒤에도 위키를 정확하게 유지하는 것은 다음 세 규칙입니다.

1. 페이지마다 책임자 한 명, 이름을 페이지에 표시. 팀도 역할도 아닌 한 사람입니다. 퇴사하면 오프보딩 체크리스트에서 페이지를 인계합니다. 책임자 없는 페이지는 표류시키지 않고 보관 처리합니다.
2. 모든 페이지에 검토일. 핸드북은 12개월, 일하는 방식은 6개월, 런북은 3개월입니다. 책임자는 페이지가 여전히 맞는지 확인하거나 고칩니다. 검토일이 지난 페이지에는 눈에 띄는 경고를 띄우고, 월간 보고서에 책임자별 기한 초과 페이지를 나열합니다.
3. 실수를 발견한 사람이 고친다. 런북을 따라가다 4단계가 틀렸다면, 작업을 마치기 전에 4단계를 고칩니다. 위키의 궤적을 가장 크게 바꾸는 규칙이며, 온보딩에서 소리 내어 말해야 하는 규칙입니다. 새로 온 사람은 자기에게 권한이 없다고 생각하기 때문입니다.

7단계로 위키 구축하기

1. 도구를 고르고 평가를 멈춥니다. 도구는 책임 규칙보다 덜 중요합니다. 페이지를 중첩할 수 있고, 본문을 검색할 수 있고, 누가 언제 무엇을 편집했는지 보이고, 떠날 수 있도록 Markdown으로 내보낼 수 있는 것을 고르세요. 아래 표에서 네 가지를 비교합니다.
2. 누군가를 초대하기 전에 처음 스무 페이지를 직접 씁니다. 빈 위키는 무시해도 되는 것처럼 보입니다. 처음 스무 페이지는 보통 핸드북 열 개, 일하는 방식 다섯 개, 가장 무서운 절차의 런북 세 개, 이번 분기에 내린 결정 두 개입니다.
3. 다시 쓰지 말고 옮깁니다. 이 페이지들 대부분은 이미 채팅 스레드, Google 문서, 누군가의 머릿속에 있습니다. 날짜와 책임자를 붙여 붙여넣고, 다듬는 건 나중에 합니다.
4. 모든 페이지의 책임자와 검토일을 한자리에서 설정합니다.
5. 위키가 아니라 규칙을 공지합니다. 공지는 세 줄입니다. 위키의 위치, "발견하면 고친다" 규칙, 반복되는 질문에 대한 채팅 답변은 페이지 링크로 대체된다는 것.
6. 한 달 동안 채팅 질문에 링크로 답합니다. "항공권 경비 처리는 어떻게 하죠?"라고 물으면 링크로 답하고, 페이지가 없으면 5분 안에 써서 링크를 보냅니다. 한 달 뒤에는 사람들이 먼저 검색합니다.
7. 분기마다 정리합니다. 팀 전체가 30분. 죽은 것은 보관 처리하고, 중복은 병합하고, 기한이 지난 검토를 확인합니다. 페이지 수를 적게 유지하세요. 좋은 소규모 팀 위키는 2,000페이지가 아니라 80~200페이지입니다.

검색 문제, 그리고 Confluence 사용자가 불평하는 이유

위키 검색에 대한 불만은 거의 항상 같습니다. 구절을 검색하면 그 단어가 들어간 페이지의 긴 목록이 아무도 이해 못 하는 순서로 나오고, 맞는 페이지는 두 번째 화면에 있습니다. Confluence가 이 불만에서 가장 자주 거론되는 이유는 가장 널리 쓰이기 때문이기도 하고, 큰 Confluence 사이트에는 수년치 첨부파일, 개인 스페이스, 보관된 페이지가 쌓여 현재의 답과 나란히 순위에 오르기 때문이기도 합니다.

Atlassian을 위해 공정하게 말하면, 지원 문서는 Confluence Cloud의 어떤 요금제에도 검색 제한을 명시하지 않습니다. 2026년 10월 기준으로 문서가 말하는 것은 Free 요금제가 최대 10명의 사용자와 2 GB 파일 저장 공간을 제공하고, Rovo를 포함한 AI 기능은 Standard 이상에 명시되며 Premium에서는 사용 한도가 더 높다는 것입니다. 즉 Free Confluence 사이트에서 검색은 전통적인 키워드 검색이고, AI 답변 계층은 유료 기능입니다.

도구와 무관하게 문제를 줄이는 세 가지가 있습니다.

• 페이지를 줄입니다. 2,850페이지가 낡은 3,000페이지보다 현행 150페이지에서 검색이 더 잘 됩니다. 분기 정리는 곧 검색 개선입니다.
• 사람들이 검색하는 단어로 제목을 씁니다. "PTO 정책 v3 최종"이라는 페이지는 "휴가 신청 방법"이라고 치는 사람에게 보이지 않습니다.
• 질문형 검색. 새로운 접근은 페이지를 나열하는 대신 페이지를 바탕으로 출처를 달아 질문에 답하는 것입니다. Slite, Nuclino, Atrix 모두 그 한 형태를 제공하고, Confluence는 유료 요금제의 Rovo로 제공합니다.

소규모 팀 위키 도구 (2026년 10월 기준)

수치에 대한 참고. Slite 페이지에는 연간 결제 시 Basic이 멤버당 월 10달러, Pro가 20달러이며, 무료 요금제는 없고 카드 없이 14일 체험이 가능하다고 나와 있습니다. Nuclino는 Free, Starter, Business를 연간 결제 시 최대 25% 할인으로 안내하지만 페이지에서 사용자당 가격을 확인할 수 없어 싣지 않았습니다. Starter는 무제한 항목과 30일 버전 기록을 포함하고, Business는 Sidekick AI와 무제한 기록을 더합니다. Confluence Cloud 가격은 결제 주기와 지역에 따라 다르고 확인 시점에 Atlassian 페이지에서 읽을 수 없었으니 직접 확인하세요.

Atrix가 맞는 자리

Atrix는 선택지 중 하나이며, 솔직한 추천 이유는 위키가 작업, 채팅, 캘린더, 고객, 채용까지 담긴 워크스페이스의 한 탭이라는 점입니다. 런북은 자신이 비롯된 이슈에 링크할 수 있고, 의사결정 페이지는 계기가 된 거래에 링크할 수 있습니다. 페이지는 트리로 중첩되고, 페이지를 데이터베이스로 만들 수 있으며(의사결정 섹션에 유용합니다. 결정마다 한 행, 상태와 날짜 열), 여러 사람이 커서를 보며 동시에 편집할 수 있고, 모든 페이지에 버전 기록과 댓글이 있으며, 워크스페이스 전체를 Markdown ZIP으로 내보낼 수 있습니다. 검색창은 페이지, 작업, 메시지를 가로질러 질문에 답하고 답의 출처를 보여줍니다. 같은 워크스페이스에 묻는 기능은 MCP 서버를 통해 Claude, ChatGPT, Cursor에도 열려 있어, 지금 쓰는 도구에서 위키에 물을 수 있습니다.

한계도 있습니다. 무료 요금제가 없고, Builder는 5시트 규모이며, Notion이나 Confluence 내보내기를 가져오는 도구는 Markdown, Word, Excel 파일 외에는 없고, 위키만 원한다면 Slite나 Nuclino가 더 단순합니다. 문서와 화이트보드 페이지에 페이지로 할 수 있는 것과 없는 것을 정리했습니다. Notion과 비교 중이라면 Notion 비교와 Notion 대안 목록이 차이를 자세히 다룹니다.

자주 묻는 질문

회사 위키에는 무엇이 들어가야 하나요?

네 가지입니다. 핸드북(급여, 휴가, 경비, 장비, 가치), 팀이 일하고 배포하는 방식을 담은 운영 매뉴얼, 누군가 압박 속에서 따라야 할 수 있는 모든 절차의 런북, 그리고 의사결정 로그. 제품 문서와 고객용 도움말은 다른 곳에 둡니다.

소규모 팀의 내부 위키는 어떻게 구조화하나요?

최상위 섹션 네 개, 각각에 주제, 주제마다 페이지. 세 단계이며 더 깊게 가지 않습니다. 들어갈 페이지가 세 개 이상 준비됐을 때만 섹션을 만듭니다. 적극적으로 보관 처리해 총 200페이지 아래로 유지합니다.

팀 위키의 책임자는 누가 되어야 하나요?

모든 페이지에 이름이 명시된 책임자 한 명이 있고, 위키 전체에는 분기 정리와 월간 기한 초과 보고서를 운영하는 한 사람이 있습니다. 15명 미만 팀에서는 보통 창업자나 운영 책임자입니다. 페이지 책임은 오프보딩 체크리스트에서 다른 사람에게 넘어갑니다.

위키 페이지는 얼마나 자주 검토해야 하나요?

핸드북은 매년, 일하는 방식은 6개월마다, 런북은 3개월마다 또는 절차가 바뀔 때마다. 의사결정은 사후에 편집하지 않고, 뒤집힌 결정에는 옛 페이지로 링크하는 새 페이지를 만듭니다.

Confluence는 소규모 팀 위키에 적합한가요?

쓸 수 있습니다. 2026년 10월 기준 Free 요금제는 최대 10명의 사용자와 2 GB 저장 공간을 제공합니다. 흔한 불만은 큰 사이트에서의 검색 품질이고, AI 검색 계층(Rovo)은 유료 요금제에 있습니다. 아직 Jira를 쓰지 않는 15명 미만 팀이라면 보통 더 가벼운 도구가 더 빨리 자리 잡습니다.

다음 단계

위의 구조와 처음 스무 페이지로 시작하세요. 위키를 팀의 다른 일 옆에 두고 싶다면 문서와 화이트보드 기능 페이지에서 중첩 페이지, 데이터베이스, 실시간 편집을 볼 수 있고, Notion 비교에서 위키 이전에 무엇이 따르는지 알 수 있습니다.

출처

2026년 10월 확인: Slite 요금, Nuclino 요금, Atlassian: Confluence Cloud 요금제.