사내 위키: 도구, 구조, 그리고 채널 기록에서 자라나는 위키 (2026)

사내 위키는 조직이 자기 자신을 위해, 그 외 누구도 읽지 않을 것을 전제로 쓰는 페이지의 모음입니다. 새 총판을 어떻게 등록하는지, 현행 가격표가 어디 있는지, 6월에 할인에 대해 무엇을 결정했는지, 운송사가 늦을 때 누구에게 전화해야 하는지 같은 내용입니다. 독자가 동료이기 때문에 "사내"이고, 어느 멤버든 페이지를 쓸 수 있고 어느 페이지든 다른 페이지로 연결할 수 있기 때문에 "위키"입니다. 10~200명 규모의 조직은 두 번째 사람이 같은 질문을 던지는 날부터 이미 위키를 갖게 됩니다. 선택지는 페이지가 존재하느냐, 아니면 답이 한 동료의 머릿속과 수십 개의 채팅 스레드에 흩어져 있느냐뿐입니다.

사내 위키를 다루는 대부분의 가이드는 소프트웨어 목록입니다. 이 글은 더 앞에서 시작합니다. 도구는 결정 가운데 가장 작은 부분이기 때문입니다. 잘 돌아가는 위키는 사람들이 길을 찾을 수 있는 구조, 오래도록 정확하게 유지되는 페이지 형식, 팀이 이미 매일 여는 장소로 이루어집니다. 먼저 구조, 복사해 쓸 수 있는 페이지 템플릿, 한 클리닉의 실제 사례 같은 기본기를 다룹니다. 그다음에 실무로 넘어가 팀이 이미 쓰는 도구 안에서 위키가 어디에 자리하는지를 각 도구의 공식 문서에 따라 살펴보고, 규칙이 실제로 정해진 회의를 각 도구가 어떻게 처리하는지 봅니다. 위키의 시험대는 출시한 날이 아니기 때문입니다. 새 동료가 월요일에 위키를 열었을 때 자신이 읽는 언어로 된 페이지를 찾을 수 있느냐가 시험대입니다.

사내 위키란 무엇이고, 무엇이 아닌가

네 가지가 위키라고 불립니다. 이 넷의 혼동 때문에 많이 만들어지고도 열어 보는 일은 드뭅니다.

위키는 첫 번째 행이며, 나머지 셋이 의존하는 것도 위키입니다. 지식 베이스는 구조를 강제한 위키입니다. 질문마다 항목 하나, 항목마다 담당자 한 명을 둡니다. 30일 안에 지식 베이스를 만드는 방법은 해당 가이드에 있고, 이 글은 위키 자체의 형식을 다룹니다. 인트라넷은 쓸 수 있는 사람을 세 명으로 제한했을 때 위키가 변하는 모습입니다. 공유 드라이브는 위키의 파일이 놓이는 곳이며, 위키의 역할은 현행 파일을 가리키는 것입니다. 위키는 프로세스 문서나 SOP도 아닙니다. 그런 문서는 하나의 업무를 처음부터 끝까지 설명하고, 위키 페이지는 그 문서를 어디서 찾는지와 그 뒤에 무엇이 바뀌었는지를 알려 줍니다.

위키를 "사내" 것으로 만드는 것은 비밀번호가 아닙니다. 페이지가 팀이 쓰는 말로 쓰인다는 점입니다. "카사블랑카 규칙", "화요일 배송" 같은 표현이 그렇습니다. 그리고 외부용 페이지라면 결코 말할 수 없는 것, 곧 누가 결정했는지, 왜 그랬는지, 무엇을 대체했는지를 적을 수 있다는 점입니다.

구조: 섹션 일곱 개, 질문 하나에 페이지 하나

사람들이 여는 위키와 더 이상 열지 않게 된 위키의 차이는 도구에서 비롯되는 일이 드뭅니다. 첫 페이지를 쓰기 전에 내렸거나 내리지 않은 세 가지 결정에서 갈립니다.

부서가 아니라 질문으로 섹션을 나눕니다. "스위스 총판에는 청구서를 어떻게 발행하지?"라고 묻는 동료는 그 답이 재무, 영업, 물류 중 어디에 속하는지 모릅니다. 아는 것은 질문입니다. 부서별로 정리된 위키는 페이지 하나를 찾으려는 사람을 섹션 세 곳으로 보냅니다. 사람들이 묻는 질문을 그들의 말로 기준 삼아 정리하고, 최상위는 일곱 개 이하로 유지하세요. 일곱 개를 넘으면 구조 자체를 찾으려고 검색이 필요해지는데, 아직 채워지지 않은 위키를 검색하면 아무것도 나오지 않습니다. 소규모 조직의 일반적인 최상위 구성은 이렇습니다. 고객과 주문, 돈과 청구, 사람과 채용, 도구와 접근 권한, 규칙과 결정, 누구에게 전화할 것인가.

질문 하나에 페이지 하나, 한 화면 이내로. 질문 하나에 답하는 페이지는 발견되고 읽힙니다. 한 기능 전체를 설명하는 페이지는 북마크만 되고 대충 훑어보게 됩니다. "스위스에는 청구서를 어떻게 발행하나?"는 페이지입니다. "재무"는 섹션입니다. 페이지에 목차가 필요하다면 그것은 페이지 두 개입니다.

모든 페이지에 담당자와 날짜를. 담당자와 마지막 확인 날짜가 적힌 페이지는 신뢰받습니다. 같은 내용이라도 그것이 없으면 "아마 낡았을 것"이 됩니다. 담당자의 일은 작습니다. 분기마다 한 번 "이게 아직 맞는가?"에 답하고 날짜를 바꾸는 것이며, 위키를 첫 해 이후에도 살아 있게 하는 유일한 요소입니다. 담당자를 지목할 수 없는 페이지는 지식이 아니라 추측이므로 빼야 합니다.

구조가 만들어진 뒤에는 두 가지 습관이 그것을 지켜 줍니다. 팀 채널에서 두 번 이상 물어본 답은 페이지가 되고, 그 답을 한 사람이 써서 해당 섹션에서 연결합니다. 그리고 규칙을 바꾸는 모든 결정은 먼저 결정 로그에 한 줄을 남기고, 그 규칙을 서술하는 페이지가 그 줄을 링크합니다. 그러면 여섯 달 뒤에도 페이지가 규칙이 무엇인지뿐 아니라 왜 그런지도 말해 줄 수 있습니다.

일주일 만에 사내 위키 만들기

이 계획은 한 사람이 주도하고, 나머지 팀원은 몇 분씩만 쓴다고 가정합니다. 주도하는 사람은 팀 리더이거나 질문을 가장 많이 받는 사람입니다.

1일 차 — 팀이 이미 읽는 곳을 기준으로 장소를 고릅니다. 소프트웨어 비교로 고르지 않습니다. 위키는 질문이 오가는 곳, 곧 팀 채널이나 파일이 이미 들어 있는 제품군 안에 둡니다. 자체 로그인이 있는 다섯 번째 도구에 만든 위키는 월요일 아침에 아무도 열지 않는 위키입니다. 아래 표는 각 장소가 무엇을 담고 어디서 한계에 부딪히는지 보여 줍니다.

1~3일 차 — 답이 아니라 질문을 모읍니다. 채널에 메시지를 하나 올립니다. "이번 주에 동료에게 물어본 질문을 쓴 표현 그대로 전부 답글로 남겨 주세요." 사흘째가 되면 마흔에서 예순 개가 모이고, 그 3분의 1은 중복입니다. 반복 횟수를 세어 보세요. 다섯 번 나온 질문이 첫 번째 페이지입니다.

4일 차 — 섹션 일곱 개로 분류하고 담당자를 정합니다. 질문이 묶이는 그룹이 곧 섹션입니다. 섹션마다 담당자를 정하되, 그 섹션의 질문에 가장 많이 답한 사람이 맡습니다. 처음 열다섯 페이지도 각각 담당자를 정합니다. 아직은 목록 외에는 아무것도 쓰지 않습니다. 섹션, 질문, 담당자만 적습니다. 그 목록을 "빠진 것이 무엇인가요?"라는 질문 하나와 함께 팀에 돌려보냅니다.

5~7일 차 — 이미 있는 자료로 첫 열다섯 페이지를 씁니다. 각 담당자가 아래 템플릿으로 자기 페이지를 씁니다. 출발점은 채팅 답변, 규칙이 정해진 회의의 요약, 3월에 첨부한 파일입니다. 첫 주의 원칙은 "짧고 정확한 것이 길고 완전한 것보다 낫다"입니다. 파일 링크가 달리고 날짜와 서명이 있는 두 문장짜리 답이 곧 페이지입니다. 그런 다음 섹션 목차를 팀이 읽는 곳에 고정하면 위키가 존재하게 됩니다.

그 한 주 동안 일어나지 않는 일은 공유 드라이브 이전, 모든 프로세스에 대한 페이지 작성, 새 도구 선정입니다. 위키는 파일이 있는 곳의 파일을, 절차가 있는 곳의 절차를 가리킵니다.

사내 위키 페이지 템플릿

페이지 하나, 질문 하나, 한 화면 이내입니다. 메모로 복사해 채워 넣으세요. 가장 자주 빠지는 줄은 마지막 세 줄이며, 페이지를 정확하게 유지하는 것도 바로 그 줄입니다.

[질문, 사람들이 묻는 표현 그대로]
담당자: [이름] · 섹션: [일곱 개 중 하나] · 마지막 검토: [날짜] · 다음 검토: [날짜]
짧은 답: [두 문장 — 무엇을 해야 하는가]
적용 대상: [팀, 사무소, 고객 유형] · 적용되지 않는 경우: [사람들이 혼동하는 사례]
방법: [번호를 붙인 단계, 각 단계에 관련된 시스템, 사람 또는 파일을 명시]
그 뒤에 있는 규칙: [규칙을 정한 결정, 날짜와 이유 포함 — 결정 로그 링크]
예외: [일반 경로를 벗어나는 사례와 각각을 누가 결정하는지]
파일 위치: [현행 템플릿, 가격표, 계약서 링크]
관련 페이지: [SOP, 프로세스, 이 페이지의 이전 버전]

이 템플릿은 굵은 라벨이 붙은 일반 텍스트이므로 Word 파일, Google Doc, 위키 페이지, Slack canvas, 채팅 메모에 서식 변환 없이 붙여 넣을 수 있습니다.

실제 사례: 일주일 뒤 한 클리닉의 위키

바르셀로나의 물리치료 클리닉, 24명입니다. 접수 데스크 4명, 치료사 14명, 청구 담당 2명, 나머지는 행정입니다. 치료사 절반은 최근 2년 사이에 아르헨티나, 콜롬비아, 우크라이나에서 왔고, 환자의 3분의 1은 영어로 예약하는 영국인과 독일인 거주자입니다. 사흘간 모은 질문은 52개였고, 중복을 제거하니 37개가 되었습니다. 이렇게 나온 구조와 7일 차 시점의 섹션별 페이지 수는 다음과 같습니다.

1. 환자와 예약 (5) — 첫 진료 예약 방법, 노쇼 처리 방법, 환자가 치료사를 바꾸는 방법
2. 청구와 보험 (4) — 직접 청구하는 보험사, 해외 보험사용 영수증 발급 방법, 세션을 환불하는 시점
3. 치료 프로토콜 (3) — 프로토콜 시트의 위치, 치료 계획을 승인하는 사람, 매 세션 뒤에 기록하는 내용
4. 도구와 접근 권한 (2) — 예약 시스템 접근 권한을 주는 사람, 환자 안내문 템플릿의 위치
5. 규칙과 결정 (2) — 24시간 취소 규칙, 결정 로그
6. 누구에게 전화할 것인가 (1) — 보험사 연락처, 장비 서비스 전화

페이지는 열일곱 개였습니다. 가장 많이 나온 질문인 "독일 보험사가 받아 주는 영수증은 어떻게 발급하지?"는 1년 동안 접수 데스크에서 같은 청구 담당 리더가 아홉 번 답했습니다. 아홉 번째 답이 이미 채널에 적혀 있었고 담당자 줄과 날짜만 더하면 되었기 때문에, 페이지를 만드는 데는 15분이 걸렸습니다.

2번 섹션에서 채워 넣은 페이지는 다음과 같습니다.

해외 보험사가 받아 주는 영수증은 어떻게 발급하나요?
담당자: 청구 담당 리더 · 섹션: 청구와 보험 · 마지막 검토: 2026년 11월 6일 · 다음 검토: 2027년 2월 6일
짧은 답: "보험사 영수증" 템플릿을 환자의 언어로 사용하고, 모든 줄에 진단 코드와 치료사의 면허번호를 넣습니다.
적용 대상: 직접 지불하고 해외 보험사에 청구하는 환자 · 적용되지 않는 경우: 우리가 직접 청구하는 보험사. 이 보험사에는 월별 명세서를 보냅니다.
방법: 1. 예약 시스템에서 환자를 엽니다. 2. 보험사 영수증 템플릿을 선택합니다. 3. 치료 계획에서 진단 코드를 가져와 추가합니다. 4. 모든 줄에 면허번호가 있는지 확인합니다. 5. PDF로 보내고 사본을 환자 폴더에 보관합니다.
그 뒤에 있는 규칙: 2026년 4월 독일 보험사의 거부 사례 이후 면허번호가 추가되었습니다(결정 로그 항목 2026-04-22).
예외: 세션별 상세 영수증이 필요한 환자는 청구 담당 리더에게 요청합니다. 다른 사람은 발급하지 않습니다.
파일 위치: 보험사 영수증 템플릿, 진단 코드 목록, 환자 폴더.
관련 페이지: 직접 청구하는 보험사, 세션을 환불하는 시점.

이미 쓰고 있는 도구 안에서 위키가 놓이는 곳

10~200명 규모의 조직은 이미 비용을 내고 있는 제품군 안에 위키를 만듭니다. 각 제품군에는 페이지를 놓을 곳, 파일을 놓을 곳, 회의가 남기는 것을 옮길 경로가 있습니다. 각각 멈추는 지점이 다르고, 어느 쪽이든 페이지는 입력한 언어로 남습니다. 아래는 각 벤더의 공식 페이지에 문서화된 동작만 정리한 것이며, 각 페이지를 확인한 달을 함께 적었습니다.

네 가지에 공통된 점이 세 가지 있습니다. 첫째, 페이지는 입력한 단일 언어로 된 문서이거나 메시지이며, 다른 언어를 읽는 멤버는 그것을 그대로 읽거나 누군가 만든 사본을 읽습니다. 둘째, 파일은 다른 곳에 있고 두 번째 검색으로 찾아야 합니다. 셋째, 규칙이 논의되고 정해진 회의는 누군가 나중에 직접 입력해야만 위키에 도달합니다. Teams와 Meet가 전사본과 요약을 어디까지 보관하는지, 통화 뒤에 그것을 어떻게 보존하는지는 Microsoft Teams와 Google Meet가 전사본, 녹화, 요약을 저장하는 곳에 있습니다. 같은 이유로 많은 팀이 추가하는 AI 노트테이커는 Otter.ai 대안에서 비교하는데, 그 도구들도 각자 요약을 하나의 언어로 씁니다.

이 제품군들이 문서화한 번역은 페이지가 아니라 통화나 독자의 화면에 속합니다. Microsoft는 주최자가 Teams Premium 또는 Microsoft 365 Copilot 라이선스를 가진 경우 Teams 회의에서 번역된 실시간 자막을 지원한다고 문서화했고, Google은 해당 Workspace 플랜의 Meet에서 번역된 자막을 지원한다고 문서화했으며(둘 다 2026년 8월 확인), WhatsApp은 받은 메시지를 독자의 휴대전화에서 번역하는 기능을 문서화했습니다(2026년 8월 확인). 각 기능이 다루는 범위와 멈추는 지점은 Microsoft Teams 실시간 번역, Google Meet 실시간 번역, WhatsApp 번역에 있습니다. 우크라이나어를 쓰는 치료사가 월요일에 여는 영수증 페이지는 그 자막과는 별개의 대상이며, 입력된 언어로 읽힙니다.

채널 기록에서 자라나는 위키

InterMIND는 팀의 업무가 채널 안에서 이루어지는 커뮤니케이션 공간이므로, 위키의 자연스러운 자리는 그것을 쓰는 팀의 채널입니다. 클리닉의 접수 데스크, 수출팀, 에이전시의 어카운트 그룹이 그 예입니다. 그 채널은 질문이 오가는 곳이자 회의가 시작되는 곳이기도 합니다. 앞서 말한 세 가지 결정은 이 채널에 그대로 대응됩니다.

페이지와 담당자는 채널의 노트입니다. 노트는 제목과 번호 목록을 쓸 수 있는 리치 텍스트 메시지로, 나중에 노트 자체의 메뉴에서 편집할 수 있습니다. 각 멤버가 자기 언어로 읽고 원문은 토글 한 번이면 볼 수 있으며, 섹션 목차를 고정해 두면 새 동료가 가장 먼저 찾게 됩니다. 편집 기록을 켜 두면 바뀐 규칙의 이전 표현이 현재 텍스트 위에 타임스탬프와 함께 단어 단위 diff로 나타납니다. 담당자의 "마지막 검토" 줄이 가리키는 검토 이력이 바로 이것입니다. 페이지가 가리키는 파일(영수증 템플릿, 진단 코드 목록, 보험사 계약서)은 같은 채널에 업로드되며, 모든 플랜에서 독자의 언어로 된 AI 요약이 붙고 각 요점은 출처가 된 단락에 연결됩니다. 유료 플랜에서는 파일 자체가 독자의 언어로 번역되어 열립니다(문서는 30개 언어). 원본 문서를 문서 도구에 두는 경우, 그 업데이트는 이메일로 채널에 도착합니다. 채널의 호스트가 채널 전용 주소를 만들어 주면, 그 주소로 보낸 메시지가 보낸 사람 이름과 첨부 파일이 유지된 일반 메시지로 나타납니다. Slack에서 옮겨 오는 팀은 채널을 그대로 가져옵니다. 표준 Slack 워크스페이스 내보내기 파일은 Slack 채널 하나당 채널 하나로 복원되고, 메시지는 원래 타임스탬프 순서대로 들어가며 고정과 리액션도 유지되고, 각 메시지는 모든 멤버가 자기 언어로 읽습니다.

모든 페이지 뒤의 기록은 위의 표에서 사람에게 맡겨진 일을 채널이 맡는 곳입니다. 규칙이 정해지는 회의는 채널에서 시작됩니다. 통화 중에는 Share to conference로 초안 페이지를 화면 속 영상 타일 옆에 모두에게 띄웁니다. 노트일 수도 있고 채팅에 링크한 Google Docs나 OneDrive 문서일 수도 있습니다. 참가자는 각자 독립적으로 스크롤하며 자기 언어로 읽고, 공유한 사람은 그 자리에서 실시간으로 편집합니다. 통화가 끝나면 요약이 회의 자체를 바탕으로 작성됩니다. 요약문, 합의·미결·쟁점으로 표시된 사항, 담당자가 지정된 action items가 들어가고 각 줄에 타임스탬프가 유지됩니다. 세션 중에 공유된 문서는 그 요약을 발언 내용과 함께 보탭니다. 요약은 이메일, 채널 메시지, 캘린더 일정의 링크로 도착하며, 로그인한 모든 멤버가 자기 언어로 읽습니다. 기록은 회의실에서 우연히 쓰인 언어로 한 번 작성되는 것이 아니라 독자별로 번역됩니다. 어느 멤버든 편집할 수 있고, 모든 편집은 작성자와 수정 이력을 남기며, 채널은 과거 모든 세션의 요약을 보관합니다. 그래서 면허번호 규칙을 정한 회의는 그 규칙을 서술한 페이지에서 한 번 클릭하면 닿습니다. 이것이 채널 기록에서 자라나는 위키입니다. 접수 데스크의 아홉 번째 답, 규칙이 논의된 통화의 요약, 4월에 첨부한 템플릿이 모두 한곳에 있고 그 위에 페이지가 놓입니다. 위의 표와 나란히 놓으면 차이는 사실을 그대로 적은 것입니다. 그 제품군들이 문서화한 자막은 통화가 진행되는 동안 통화를 번역합니다. 여기서는 페이지, 그것을 만든 회의, 파일, 이력이 하나의 기록이고, 각 멤버가 그것을 자기 언어로 읽습니다.

질문 채널도 반대 방향에서 같은 대우를 받습니다. 멤버 자신의 어시스턴트(Claude, ChatGPT, Copilot, Gemini)를 MCP 커넥터로 연결하면, 요약, 전사본, 채팅, 공유 파일의 텍스트를 질문 하나로 검색합니다. 예를 들어 "독일 보험사가 받아 주는 영수증은 어떻게 발급하지?"라고 물으면, 각 구절이 나온 회의, 날짜, 파일과 함께 해당 구절을 돌려줍니다. 이 기능은 AI 기능을 켠 조직에서 동작하며, 어시스턴트를 통한 열람은 해당 멤버가 참여한 회의와 채널로 제한됩니다. 채팅 자체에도 검색이 있고, 위키 전체를 통째로 꺼낼 수도 있습니다. 모든 플랜에서 설정의 백업이 채널을 메시지, 전사본, 파일과 함께 ZIP으로 내보냅니다. 소유권의 문제를 페이지 단위가 아니라 조직 단위에서 해결하는 것입니다.

팀의 지식을 가진 사람이 모두 직원인 것은 아닙니다. 보험사의 청구 담당자, 장비 기술자, 독일 영수증 규칙을 아는 프리랜서 회계사가 그렇습니다. 채널의 외부 멤버는 이메일로 무료 계정에 가입해 참여하며 다른 멤버와 똑같이 페이지와 그 이력을 읽습니다. 계정이 없는 사람은 회의 하나의 게스트입니다. 링크로, 휴대전화에서도 무료로 통화에 참여하고, 자기 언어로 실시간 통역을 들으며, 그 뒤에는 기록이 남지 않습니다. 호스트가 공간을 제공하고, 유료 플랜에서는 지난 28일간 활성 상태였던 멤버에 대해서만 요금을 냅니다. 회의에 참여했거나, 채팅에 글을 썼거나, 어시스턴트에게 질문한 멤버가 활성 멤버입니다. 조용해진 멤버는 비용 없이 접근 권한을 유지하며, 이것이 위키에 필요한 조건입니다. 2년 전에 페이지를 쓴 사람이 여전히 채널에 있을 수 있어야 합니다.

• 완성된 요약 열어 보기 — 여러분의 요약을 작성하는 것과 같은 코드가 렌더링한 실제 기록입니다.
• 라이브 데모 체험하기 — 가입 없이, 말하면 그 자리의 모든 청취자에게 각자의 언어로 번역되어 들립니다.

기본기로서의 사내 위키는 어떤 도구에서도 살아남습니다. 누군가는 여전히 질문을 모으고, 구조를 섹션 일곱 개로 유지하고, 모든 페이지에 이름과 날짜를 적고, 다이렉트 메시지가 아니라 채널에서 답해야 합니다. 살아남지 않아도 되는 것은 두 번째 일입니다. 회의에서 결정된 내용을 위키에 다시 입력하는 일, 다른 언어를 읽는 동료를 위해 모든 페이지의 번역본을 한 언어씩 손으로 관리하는 일입니다.

FAQ

사내 위키란 무엇인가요?

사내 위키는 조직이 자기 멤버를 위해 쓰는 페이지의 모음입니다. 일을 하는 방식, 파일의 위치, 무엇이 왜 결정되었는지를 한곳에 두고, 어느 멤버든 페이지를 쓸 수 있고 어느 페이지든 다른 페이지로 연결할 수 있습니다. 공개 위키와는 독자가 고객이 아니라 동료라는 점에서 다르고, 인트라넷과는 중앙 팀이 아니라 실제로 일하는 사람들이 페이지를 쓰고 갱신한다는 점에서 다릅니다. 실제로 열리는 페이지는 사람들이 묻는 질문별로 정리되고 각각 담당자와 검토 날짜가 있는 페이지입니다.

사내 위키와 지식 베이스는 어떻게 다른가요?

위키는 누구나 어떤 구조로든 쓸 수 있는 페이지의 모음이고, 지식 베이스는 사람들이 묻는 질문별로 정리되어 질문마다 항목 하나와 지정된 담당자, 검토 날짜가 있습니다. 위키는 구조와 담당자를 더하면 지식 베이스가 됩니다. 그것이 없으면 아무도 길을 찾을 수 없고 아무도 확인하지 않은 수백 개의 페이지로 늘어납니다. 소프트웨어는 같은 경우가 많으며, 하나를 다른 하나로 30일 안에 바꾸는 방법은 지식 베이스 구축 방법에 있습니다.

사내 위키는 어떻게 만드나요?

소프트웨어 비교가 아니라 팀이 이미 읽는 곳을 기준으로 장소를 고릅니다. 사흘 동안 팀이 실제로 묻는 질문을 쓰는 표현 그대로 모읍니다. 그것을 일곱 개 이하의 섹션으로 분류하고 섹션마다, 페이지마다 담당자를 정합니다. 이미 있는 자료(채팅 답변, 회의 요약, 파일)로 처음 열다섯 페이지를 쓰되, 짧은 답, 단계, 예외, 검토 날짜가 들어간 한 페이지짜리 템플릿을 사용합니다. 그리고 섹션 목차를 팀이 읽는 곳에 고정합니다. 그 뒤에는 순환을 유지합니다. 두 번 답한 질문은 페이지가 되고, 각 페이지의 담당자는 정해진 날짜에 검토합니다.

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

질문마다 페이지 하나이고, 각 페이지에는 사람들이 쓰는 표현의 질문, 담당자, 마지막 검토 날짜와 다음 검토 날짜, 짧은 답, 적용되는 경우와 적용되지 않는 경우, 관련된 시스템이나 사람을 명시한 단계, 날짜가 붙은 규칙의 근거 결정, 예외와 그것을 결정하는 사람, 현행 파일 링크, 관련 페이지 링크가 들어갑니다. 위키 전체에는 부서가 아니라 사람들이 묻는 질문 기준으로 정리된 일곱 개 이하의 섹션 구조와, 팀이 읽는 곳에 고정된 섹션 목차가 필요합니다.

사내 위키에 가장 좋은 도구는 무엇인가요?

팀이 이미 매일 여는 도구입니다. 자체 로그인이 있는 다섯 번째 도구에 만든 위키는 월요일에 아무도 확인하지 않는 위키이기 때문입니다. Microsoft Teams에서는 페이지와 파일이 채널과 그 SharePoint 사이트에 있고 회의 노트는 Loop 구성 요소로 남습니다. Slack에서는 채널의 canvas, Google Workspace에서는 캘린더에서 링크한 Google Doc, WhatsApp에서는 그룹 채팅 자체입니다. 각각 위의 표에 적힌 문서화된 한계가 있고, 각각 페이지를 입력한 언어로 유지합니다. InterMIND는 팀의 노트, 파일, 채팅, 회의 요약을 하나의 채널에 두고 각 멤버가 자기 언어로 읽게 하며, 그 도구들을 대체하는 것이 아니라 그 옆에서 함께 씁니다.

Microsoft Teams에서 사내 위키를 만들 수 있나요?

Microsoft의 문서에 따르면 팀의 파일은 팀과 함께 만들어지는 SharePoint 사이트에 저장되고, 모든 표준 채널이 그 사이트를 공유하며 채널마다 폴더가 하나씩 있습니다. 따라서 채널의 Files 탭이 위키 문서가 놓이는 곳입니다. 회의 노트는 참석자나 주최자 누구나 편집할 수 있는 Loop 구성 요소이며, 자동 저장되고 Teams 캘린더와 회의 요약에서 접근할 수 있습니다. 위키에서 문제가 되는 문서화된 한계는 두 가지입니다. 외부 참석자는 회의 노트에 접근하거나 편집할 수 없고, 채팅과 채널 메시지는 Teams 보존 정책에 따라 일정 기간 뒤 삭제될 수 있으며 파일은 별도의 SharePoint 및 OneDrive 정책을 따릅니다(2026년 10월과 11월에 확인한 페이지 기준).

사내 위키를 최신 상태로 유지하려면 어떻게 하나요?

모든 페이지에 담당자와 검토 날짜를 두고, 그 외에는 아무것도 필요 없습니다. 담당자의 일은 분기마다 한 번 "이게 아직 맞는가?"에 답하고 날짜를 바꾸는 것입니다. 담당자가 떠난 페이지는 새 담당자를 얻거나 위키에서 빠집니다. 두 가지 습관이 페이지를 채웁니다. 팀 채널에서 두 번 답한 내용은 그 답을 한 사람이 페이지로 쓰고, 규칙을 바꾸는 모든 결정은 먼저 기록해서 페이지가 왜 바뀌었는지 링크할 수 있게 합니다. 이렇게 운영하는 위키는 질문에 답할 때마다 한 페이지씩 늘어나며, 아무도 그것을 프로젝트로 다시 쓰지 않습니다.

출처: Microsoft Learn — Teams and SharePoint integration; Microsoft Learn — Learn about retention for Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Slack — Pricing; Slack — Customize data retention in Slack; Slack — Export your workspace data; Slack — Meeting agenda template (canvas); Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; WhatsApp — How to export your chat history; WhatsApp — Privacy policy; WhatsApp blog — Introducing message translations. Microsoft Learn의 Teams–SharePoint 페이지는 2026년 11월에 확인했고, Teams 보존 정책 및 회의 노트 페이지, Slack canvas 템플릿 페이지, Google "Take notes for me" 페이지는 2026년 10월에 확인했으며, Teams 메시지 번역 및 자막 페이지, Slack 요금, 보존, 내보내기 페이지, Google Chat 번역 및 Meet 자막 페이지, WhatsApp 페이지는 2026년 8월에 확인했습니다. 벤더는 시간이 지나면서 플랜, 기능, 지원 언어 목록을 바꿉니다. 현재 상태는 각 벤더의 페이지에서 확인하세요.