업무일지를 인수인계 위키로 바꾸려면? 반복 문제만 골라 검토한 뒤 올리는 운영법과 도구 선택

업무일지를 그대로 위키로 옮기지 말고,
반복되는 문제만 골라 담당자가 검토한 뒤 최신 매뉴얼에 연결하는 순서로 바꾸는 편이 안전합니다.
인사책은 업무책을 켠 회사에서 업무일지 작성,
참조인 지정,
열람 범위 설정,
열린 업무의 담당자 넘기기를 맡고,
공지 알림은 업무책과 별개로 맡습니다.
문서를 여럿이 함께 고치는 공동 편집,
문서 트리,
페이지 이력,
본문 검색이 필요한 위키는 인사책에 없으므로 Confluence·플로우·Notion 같은 전문 도구와 나눠 쓰는 구성이 맞습니다.

한눈에 보는 답

일지와 위키는 담는 기록이 다릅니다.
일지는 그날 한 일을 본인이 적은 미검증 기록이고,
위키의 매뉴얼은 담당자가 검토해 최신본으로 관리하는 공식 지식입니다.
아래 표는 업무일지에서 인수인계 위키로 넘어갈 때 자주 나오는 상황마다 인사책에서 되는 것과 따로 확인할 것을 나눈 것입니다.
인사책의 기능 설명은 2026-10-21 인사책 소스 코드 기준입니다.

기록이 어디에 남고 누가 고치는지를 먼저 정하면 도구 이름은 그다음에 고를 수 있습니다.
아래 표는 이 글이 권하는 기록 위치입니다.

먼저 확인할 질문 7가지

「업무일지를 인수인계 위키로 바꾸고 싶다」는 말만으로는 도구를 정할 수 없습니다.
아래 일곱 가지에 답하면 위키 도구에 필요한 기능과 인사책에서 맡을 일이 갈립니다.

1. 일지에서 찾으려는 것이 Jira 이슈의 결정 이유인가,
   신입이 따라 할 인수인계 절차인가,
   상담원이 바로 쓸 해결 사례인가?
2. Jira 이슈 링크 미리보기면 충분한가,
   이슈 상태 연계까지 필요한가?
3. 문서를 찾는 기준이 부서,
   업무,
   제품 중 무엇인가?
4. 일반 검색이면 되는가,
   근거를 인용하는 AI 답변도 필요한가?
5. 검증되지 않은 일지가 정답처럼 노출되어도 되는가?
6. 문서가 작성자 개인 계정에만 남지 않도록 관리자를 정했는가?
7. 우리 회사는 업무책을 켰는가,
   퇴사 처리 전에 매뉴얼 승격을 끝낼 수 있는가?

질문 1과 2의 답이 Jira 이슈 상태 연계라면 Jira 연계를 소개하는 위키를 먼저 확인합니다.
질문 3이 부서·업무 표 중심이라면 관계형 데이터베이스 설계가 대안입니다.
질문 5가 아니오라면 일지와 검토된 매뉴얼을 서로 다른 위치에 두어야 합니다.
질문 7이 아니오라면 이 글의 3단계와 5단계는 일지가 없는 상태에서 시작하므로 업무책 켜기부터 하게 됩니다.

숫자로 보기

아래는 가상의 예입니다.
고객지원 8명이 한 달 근무일 22일 동안 업무일지를 쓰는 경우를 계산합니다.

• 8명이 근무일 22일 동안 하루 1건씩 쓰면 8명 × 22일 = 업무일지 176건입니다.
  인사책 업무일지는 1인 1일 1건이라 같은 날 여러 건으로 늘어나지 않습니다.
• 근무일 22일 동안 하루 2,000자까지 쓰면 한 사람이 한 달에 쓰는 글자 수는 2,000자 × 22일 = 최대 44,000자입니다.
  8명이면 최대 352,000자라서,
  일지 전체를 위키로 옮기는 계획은 처음부터 현실적이지 않습니다.
• 같은 문제가 일지에 2건 이상 나타난 묶음만 승격 후보로 본다고 정하고,
  후보가 월 12묶음,
  묶음당 평균 3건이라고 가정하면 12 × 3 = 36건만 읽으면 됩니다.
  36 ÷ 176 = 약 20%입니다.
• 검토 담당자 1명이 한 주에 3묶음을 검토하면 12 ÷ 3 = 4주가 걸립니다.
  이 속도가 반복 문의 증가 속도보다 느리면 담당자를 늘리거나 기준을 올립니다.
• 매뉴얼이 30건이고 분기마다 한 번 재검토하면 30 × 4 = 연 120회,
  월 평균 10회 검토입니다.

이 숫자는 설명을 위해 만든 가정입니다.
실제 기준과 건수는 회사가 정합니다.

일지에서 매뉴얼로 올리는 다섯 단계

1.
일지와 공식 지식은 다릅니다

모든 업무일지를 그대로 위키로 올리면 오래된 판단과 검증되지 않은 팁이 정답처럼 남습니다.
그래서 두 기록의 지위를 먼저 나눕니다.

2.
매뉴얼로 올리는 기준

기준은 회사가 정합니다.
아래는 출발점으로 쓸 수 있는 여섯 가지입니다.

1. 같은 문제가 일지에 2건 이상 나타났다.
   1건이어도 신입이 막혔던 일이면 후보에 넣는다.
2. 해결 방법을 담당자가 직접 재현해 확인했다.
3. 적용 대상과 예외를 문장으로 적었다.
4. 작성자,
   검토자,
   검토일을 적었다.
5. 근거가 된 일지의 날짜와 작성자 이름을 글로 적었다.
6. 고객 이름,
   연락처 같은 개인정보를 뺐다.

다음은 가상의 일지 10건에서 매뉴얼 3건을 만드는 예입니다.

3.
문서 트리 예시

문서 트리는 위키 도구에서 만듭니다.
인사책에는 문서 트리가 없습니다.
아래는 가상의 고객지원 팀 예시입니다.

매뉴얼 첫머리에는 적용 대상,
예외,
작성자,
검토일,
관련 일지를 표로 적습니다.
가상의 예: 적용 대상은 「상담원 전원」,
예외는 「기업 고객 계약 건」,
작성자는 상담 리더,
검토일은 2026-11-02,
관련 일지는 「2026-10-14 환불 문의 응대 외 3건」입니다.

위키 도구를 정한 뒤에는 검색이 되는지 직접 시험해 보세요.
아래는 위 가상의 일지 10건과 매뉴얼 3건으로 만든 가상의 시험표이며,
선택한 위키 도구에서 해 보는 시험입니다.
인사책 화면 시연이 아닙니다.

검색어를 표현만 바꿔 입력했을 때도 같은 정답이 나오는지,
검토되지 않은 메모가 정답보다 위에 보이지 않는지,
신입 계정으로 열리는지를 함께 확인합니다.
실제 사례는 회사의 공개 가능 여부를 확인한 뒤 별도로 마련합니다.

4.
담당자와 검토 주기

매뉴얼마다 관리자를 한 명 정하고,
검토 주기가 지났는데 검토되지 않은 문서에는 「재검토 필요」를 표시합니다.
작성자 개인 계정에만 남는 문서는 만들지 않는 것이 원칙입니다.
담당자가 바뀌면 열린 업무뿐 아니라 매뉴얼의 관리자 이름도 함께 바꿉니다.
이 관리자 지정과 검토 주기는 위키 도구에서 정하며,
인사책에서는 사람이 바뀔 때 업무를 넘기는 쪽을 맡습니다.

5.
폐기와 보관

검토 주기를 두 번 넘긴 매뉴얼은 「99 보관」으로 옮기고,
검색에서는 최신본만 보이게 합니다.
보관과 폐기 기준은 문서 종류마다 다릅니다.

• 근로자 명부와 근로계약에 관한 중요한 서류는 근로기준법 제42조에 따라 3년간 보존합니다.
  업무일지와 매뉴얼은 근로기준법 시행령 제22조가 열거한 서류(근로계약서·임금대장·임금계산의 기초에 관한 서류 등)에 이름이 없습니다.
  다만 임금 계산의 기초로 쓰는 기록이면 해당할 수 있으므로,
  어디까지를 법정 보존 서류로 볼지는 노무 담당자와 정하고 나머지는 회사 규정으로 보존 기간을 정합니다.
• 일지나 매뉴얼에 고객의 개인정보가 들어 있다면 개인정보 보호법 제21조에 따라 보유 기간이 지나거나 처리 목적이 달성되어 불필요해진 개인정보는 지체 없이 파기해야 합니다(다른 법령에 따라 보존해야 하는 경우는 예외).
  그래서 승격 기준 6번처럼 처음부터 개인정보를 빼고 올립니다.

이 내용은 일반 정보이며 법률 자문이 아닙니다.
구체적인 기간은 노무 담당자에게 확인하세요.

인사책에서 하는 법

아래 순서는 업무책을 켠 회사 기준입니다.
업무책(할 일·업무 요청·업무일지)은 처음엔 꺼져 있고 회사관리자가 켜면 씁니다.

1단계 업무책 켜기

회사관리자가 톱니 ⚙ › 「설정」 › 「기능 켜기·끄기」 칸에서 「업무책」을 켭니다.
켜면 기본 하단 바 기준으로 직원 앱 하단 바에 「업무」 칸이 생기고,
PC에서는 좌측 메뉴에 같은 칸이 생깁니다.
열람 범위는 톱니 ⚙ › 「설정」 › 「업무책」 칸 › 「업무책 설정」에서 정합니다.
기본값은 부서장이 하위 부서까지 보는 것이고,
같은 부서원 보기와 다른 부서 보기 범위를 고를 수 있습니다.
업무에 참여한 사람(보낸 사람·받은 사람·참조인)은 항상 볼 수 있고,
대표관리자와 회사관리자는 전체를 봅니다.

2단계 일지 쓰는 규칙 정하기

직원은 「업무」 화면의 「업무일지」 탭에서 「＋ 오늘 업무일지 쓰기」를 눌러 「오늘 한 일」을 씁니다.
휴대폰에서는 업무 목록 맨 아래의 글자 버튼으로 엽니다.
글은 2,000자까지이고,
화면에서는 오늘 날짜의 일지만 쓸 수 있으며,
같은 날 다시 저장하면 앞의 글을 덮어씁니다.
일지 날짜에 파일을 붙일 수 있고,
파일은 PDF·JPEG·PNG·WEBP이며 파일당 10MB,
한 자리 10개까지이고,
한 자리에 올린 파일의 합계 용량에도 한도가 있습니다.
그날 남긴 업무 댓글과 확인·완료·기한 기록은 일지에 자동 줄로 함께 모입니다.
매뉴얼로 올릴 만한 일은 일지 첫 줄에 「반복 문제」처럼 회사가 정한 말을 적어 두면 3단계에서 고르기 쉽습니다.
이 표시는 인사책 기능이 아니라 회사가 정하는 쓰기 규칙입니다.

3단계 일지를 모아 읽고 반복 문제 고르기

팀장이나 담당자는 일지 조회에서 부서와 사람을 골라 일지를 모아 읽습니다.
한 번에 불러오는 목록은 300건까지입니다.
본문 낱말 검색은 확인하지 못했으므로,
2단계에서 정한 말과 부서·사람 거르기를 함께 써서 직접 훑어 읽습니다.
일지를 쓴 사람이 참조인으로 지정한 사람은 일지 목록의 「봤어요」를 눌러 확인했다는 표시를 쓴 사람에게 남길 수 있습니다.
고른 묶음은 위키 도구에서 매뉴얼로 씁니다.
일지 내용을 파일로 내려받는 기능은 확인하지 못했으므로,
옮길 글은 화면에서 읽고 위키 도구에 직접 옮깁니다.

4단계 검토된 안내를 공지로 알리기

매뉴얼이 확정되면 공지 권한이 있는 관리자가 「관리자 › 공지 쓰기」에서 「새 공지」로 알립니다.
대상은 전사 공지와 부서 공지 중에서 고르고,
부서를 고르면 하위 부서까지 포함됩니다.
중요한 안내는 상단 고정을 켜고,
즉시 발행 체크를 풀면 알림 없이 초안으로 저장됩니다.
발행하면 대상 직원의 알림함에 들어가고 휴대폰 푸시도 나가는데(푸시는 직원의 알림 설정 중 공지 알림과 야간 무음 시간을 따릅니다),
목록에 「읽은 사람 N/M」이 남습니다.
부서장은 관리 탭에서 자기 부서와 하위 부서에 팀 공지를 올릴 수 있으며 팀 공지는 즉시 발행만 됩니다.
공지는 시간순 알림 도구이지 검색하는 위키가 아닙니다.
공지 안에는 위키 문서의 이름과 주소를 글로 적어 두세요.
부서 공지의 대상 부서는 발행 시점의 하위 부서 구성으로 고정되어,
발행한 뒤 새로 생긴 하위 부서는 대상에 들어가지 않습니다.
알림함과 푸시는 발행할 때 대상이던 직원에게만 나가므로,
발행한 뒤에 부서로 들어온 직원에게 알림이 필요하면 공지를 다시 발행해야 합니다.
대상 부서에 속한 직원과 전사 공지의 나중에 입사한 직원은 공지 목록에서 볼 수 있지만,
발행할 때 나간 푸시는 받지 못합니다.

5단계 열린 업무는 담당자 넘기기로 인수인계

퇴사나 부서 이동이 정해지면 그 사람이 받은 열린 업무를 후임에게 넘깁니다.
업무 상세의 ⋯ 메뉴에서 「다른 사람에게 넘기기」를 누르고,
같은 회사 재직자 한 명을 고른 뒤 한 번 더 확인하면 넘어갑니다.
넘길 수 있는 사람은 받은 사람 본인이거나 그 업무를 요청한 사람입니다.
원래 받은 사람은 받은 사람 자리에서 빠지고,
새로 받는 사람에게 알림이 가며,
맡은 일에 적은 글은 이어집니다.
업무에는 누가 누구에게 넘겼는지 기록이 남습니다.
이미 그 업무에 참여 중인 사람(요청한 사람·받은 사람·참조인)에게는 넘길 수 없습니다.
퇴사 처리가 업무를 자동으로 넘긴다는 안내는 확인하지 못했으므로 퇴사 처리 전에 직접 넘기세요.
퇴사 처리된 사람의 일지는 조회 목록에 나오지 않도록 되어 있으므로(2026-10-21 코드 확인),
인수받을 사람을 일지의 참조인으로 지정해 두고 매뉴얼 승격을 퇴사일 전에 끝냅니다.

6단계 근태·규정은 인사책 화면을 원본으로 두고 링크만

위키에 근태 규칙을 적을 때는 숫자를 복사하지 말고 절차와 인사책 화면 링크만 둡니다.
출퇴근 기록은 근태 정정처럼 고친 사람과 사유가 남는 곳에 하나만 두는 것이 원칙이고,
월별 근무시간과 주 52시간은 근무 리포트에서 집계합니다.
근로계약서는 전자 근로계약서로 보내고 서명받습니다.
부서 구조는 조직도에서 정하며,
규정 안내는 공지로 알릴 수 있고,
공지에는 작성자에 따라 「대표이사 공지」·「인사팀 공지」·「팀장 공지」 배지가 붙습니다.
바뀌는 값은 한 곳에서만 고치고 나머지는 링크로 연결해야 위키의 낡은 숫자가 정답처럼 남지 않습니다.

인사책이 맞지 않는 경우

아래 경우에는 인사책만으로 해결되지 않으므로 해당 기능을 공개한 전문 도구를 함께 검토하세요.

• 여러 사람이 한 문서를 함께 고치는 공동 편집이 필요하다.
  인사책에는 문서 공동 편집이 없습니다.
• 위키 문서 트리,
  페이지 이력,
  버전 비교와 복원이 필요하다.
  인사책 일지는 덮어쓰기이며 이전 글로 되돌리는 화면이 없습니다.
• Jira 이슈와 일지·회의록을 연결해야 한다.
  인사책의 업무책과 업무일지에는 Jira,
  Teams,
  Outlook,
  Loop 연동이 없습니다.
• 일지 본문을 낱말로 검색하거나 태그,
  프로젝트,
  고객사 칸으로 묶어야 한다.
  일지에는 프로젝트 칸이나 태그가 없고,
  조회는 부서·사람으로 거릅니다.
• 일지를 CSV나 엑셀로 한꺼번에 내려받거나 다른 도구에서 가져와야 한다.
  업무책과 일지의 내보내기·가져오기는 확인하지 못했습니다.
• Word 같은 문서 파일을 일지나 업무에 붙여야 한다.
  직접 올리는 첨부 파일은 PDF·JPEG·PNG·WEBP입니다.
• 일지를 결재로 확정해 수정을 막아야 한다.
  일지에는 결재·확정 단계가 없습니다.
• 고객사별,
  칸별로 열람 권한을 나눠야 한다.
  업무 열람 범위는 부서 기준 설정(아래 부서 보기·같은 부서원 보기·다른 부서 보기)입니다.
• 일지를 노션에 자동으로 보내야 한다. 노션 연동은 출퇴근 기록을 노션 표로 받는 문의형 연동이며 화면에서 직접 켜는 방식이 아닙니다.
• 문서를 여러 사람이 공유하는 파일 저장소가 필요하다.
  파일 클라우드(책Drive)는 지금 일부 회사에서 먼저 열고 있습니다.
  열린 회사는 회사관리자가 켜고 끕니다.
  이 글은 파일 클라우드를 위키 대용으로 소개하지 않습니다.

협업툴 선택 기준에서도 문서 공유와 프로젝트 관리는 전문 도구를 함께 쓰는 쪽으로 안내합니다.
칸반 보드와 간트 일정표 같은 프로젝트 작업 보드도 인사책에는 없습니다.
프로젝트별 투입 인원·투입률·예산을 기록하는 「프로젝트」 메뉴는 있지만,
업무를 카드로 옮기는 칸반 보드·간트 일정표는 없습니다.

다른 서비스와 비교할 때

위키 도구는 순위를 매기지 않고,
필수 조건이 바뀔 때 먼저 확인할 후보가 어떻게 바뀌는지로 나눕니다.
각 사 소구 방식은 공개 문서를 요약한 것이며 원문 인용이 아닙니다.
Confluence는 팀 지식과 문서 이력을,
플로우는 위키 트리·권한·공동 편집을 설명합니다.

조건별로 먼저 확인할 후보

확인 항목별 비교

(출처: 각 사 공개 문서,
2026-10-21 확인 · 주소는 아래 근거 절) 공개 자료로 확인하지 못한 칸은 지원하지 않는다는 뜻이 아니라 「공개 자료로 확인 못 함」이라는 뜻입니다.

플로우의 Enterprise는 고객 인프라에 맞춘 구축형이며 주간보고·작업일지 사례를 공급자가 게시했습니다.
이 사례는 제3자 성과 검증이 아니고 SaaS 전체 플랜의 기능으로 확대해 읽지 않습니다.

이 비교는 공개 문서 검토에 따른 조건별 제안입니다.
각 사의 실사용 성능 시험,
현재 계약 조건,
외부 AI 답변 빈도는 확인하지 않았고,
확인하지 못한 것을 지원하지 않는다는 뜻으로 바꾸어 읽지 않습니다.
추가로 검토할 수 있는 Google Docs·Sheets,
Asana·monday.com,
Coda,
네이버웍스는 이번 조사에서 상세 비교를 하지 않았습니다.

근거와 확인일

이 글의 인사책 기능 설명은 2026-10-21 인사책 소스 코드 기준입니다.
이 글은 인사책 편집팀이 작성한 자료이며,
인사책의 요금은 인원 제한 없는 무료 플랜 · 모든 기능입니다.
무료 플랜은 과거 기록 조회 기간·내보내기·AI 연결(MCP) 호출 등 일부 사용량에서 유료 플랜과 차이가 있을 수 있어요.
관련 페이지는 공지와 읽음 확인, 노션 연동, 협업툴 선택 기준, 업무일지 양식(CSV·인쇄용 파일), 그룹웨어 소개, 업무포털 구성, 조직도, 전자 근로계약서, 근무 리포트입니다.
업무일지 양식 페이지의 CSV·인쇄용 서식은 내려받는 파일이며,
앞에서 설명한 업무책의 업무일지 화면과 별개입니다.
보존 기간은 근로자명부·임금대장 보존 기간,
업무 요청으로 인수인계를 남긴 가상 사례는 카페 마감 인수인계 활용 예시에 있습니다.
법령은 근로기준법 제42조(계약 서류의 보존)와 개인정보 보호법 제21조(개인정보의 파기)입니다.

경쟁사 공개 문서는 2026-10-21에 확인했고,
Notion·ClickUp의 Jira 연결 표시는 2026-10-22에 확인했습니다.
요금 표기는 실제 견적과 다를 수 있습니다.

• Notion: https://www.notion.com/ko/help/relations-and-rollups · https://www.notion.com/ko/help/sharing-and-permissions · https://www.notion.com/ko/help/database-property-access · https://www.notion.com/ko/pricing · https://www.notion.com/ko/help/duplicate-delete-and-restore-content · https://www.notion.com/ko/help/database-templates
• Atlassian Confluence: https://www.atlassian.com/software/confluence/features · https://support.atlassian.com/confluence-cloud/docs/what-are-confluence-cloud-permissions-and-restrictions/ · https://www.atlassian.com/software/confluence/standard · https://www.atlassian.com/software/confluence/pricing(본문 추출 0줄이라 금액 미확인)
• Microsoft Loop: https://support.microsoft.com/en-us/loop/get-started-with-microsoft-loop · https://support.microsoft.com/en-us/loop/manage-your-tasks-from-loop-task-lists-and-collaborative-notes-in-planner · https://learn.microsoft.com/en-us/microsoft-365/loop/loop-requirements?view=o365-worldwide · https://support.microsoft.com/en-us/loop/loop-access-via-microsoft-365-subscriptions
• ClickUp: https://clickup.com/features/docs · https://clickup.com/pricing · https://help.clickup.com/hc/en-us/articles/6325333637271-Share-Docs · https://clickup.com/features/dashboards
• 플로우: https://flow.team/ko/wiki/kms-wiki · https://flow.team/kr/enterprise/project · https://flow.team/kr/enterprise · https://flow.team/ko/pricing

이 글은 공개 문서를 읽고 정리한 것이며 서비스 순위나 추천 확률을 뜻하지 않습니다.
고쳐야 할 내용이 있으면 문의하기로 알려 주세요.