워드로 팀 문서 검토와 버전 관리 작업 흐름 운영하기

과외 동아리가 여러 지점으로 커지면서 코디네이터 팀이 생겼어요. 지점 안전 정책을 고칠 때마다 다섯 명이 의견을 내요. 작성자, 지점 코디네이터 두 명, 승인하는 센터장, 그리고 게시하는 사람이요. 계획 없이 진행하면 최종이라는 이름의 첨부 파일이 여섯 개 생기고, 답이 달리지 않은 메모가 남고, 게시된 PDF에는 센터장의 마지막 수정이 빠져 있곤 해요.

이 튜토리얼에서는 검토를 반복할 수 있는 작업 흐름으로 바꿔요. 단계를 정하고, 누가 무엇을 할지 정하고, 공유 파일 하나를 유지하고, 모두가 같은 뜻으로 읽는 버전 규칙을 쓰고, 단계마다 알맞은 피드백을 받도록 워드의 검토 도구를 설정해요. 같은 흐름을 보조금 제안서, 연간 보고서, 자원봉사자 매뉴얼에도 쓸 수 있어요.

초안부터 배포까지 단계 정하기

검토 작업 흐름은 중요한 문서가 차례로 거치는 짧은 단계 목록이에요. 단계마다 목적, 담당자, 그리고 통과 조건이 있어요. 통과 조건은 다음 단계로 넘어가기 전에 꼭 충족돼야 하는 조건이에요. 대부분의 팀은 다섯 단계면 충분해요.

두 가지 규칙이 단계를 지켜 줘요. 첫째, 내용에 대한 질문은 4단계가 아니라 2, 3단계에서 다뤄요. 최종 확인 담당자가 내용 문제를 찾으면 문서는 승인자에게 돌아가요. 몰래 고쳐 쓰지 않아요. 둘째, 통과 조건이 충족됐을 때만 다음으로 넘어가요. 열린 메모가 세 개 남은 문서는 마감이 아무리 가까워도 동료 검토가 끝난 게 아니에요.

단계, 담당자, 마감일은 문서 안에 적어 두세요. 첫 페이지나 부록에 짧은 문서 관리 표를 두면, 파일을 연 사람 누구나 묻지 않고도 지금 어느 단계인지 알 수 있어요.

누가 무엇을 할지 정하기

검토 문제는 대부분 사실 역할 문제예요. 두 사람이 서로 상대가 승인하는 줄 알거나, 아무도 최종 확인을 맡지 않는 거죠. RACI 표는 단계마다 사람마다 글자 하나를 정해서 이 문제를 해결해요.

• R, 실행: 이 단계의 일을 직접 해요.
• A, 최종 책임: 결정하고 승인해요. 단계마다 꼭 한 명이에요.
• C, 협의: 결정 전에 의견을 줘요. 보통 메모로 줘요.
• I, 통보: 단계가 끝나면 소식을 들어요.

표는 작게 유지하세요. 직책만 쓰지 말고 실제 이름을 써야 누구를 말하는지 헷갈리지 않아요. 한 사람의 행에 모든 열이 A라면 그 사람이 병목이 되니 일을 나누세요. 어떤 열에 A가 없다면 아무도 그 단계가 끝났다고 말할 수 없어요.

RACI 표는 문서 관리 부분이나, 팀 전체가 열 수 있는 짧은 검토 계획 문서에 넣으세요. 이 튜토리얼의 연습 파일에서 직접 하나를 채워 봐요.

원본 하나와 버전 규칙 유지하기

가장 쓸모 있는 규칙은 이거예요. 작업 파일은 하나뿐이고, 모두가 같은 곳에서 그 파일을 고쳐요. 팀이 들어갈 수 있는 OneDrive나 SharePoint 사이트에 저장하고, 메일에 사본을 첨부하는 대신 링크로 공유하세요. 그러면 모두가 같은 글을 보고, 자동 저장이 파일을 저장해 주고, 워드가 버전 기록을 남겨 줘요.

모두가 같은 뜻으로 읽는 버전 번호를 쓰세요.

날짜는 YYYY-MM-DD(2026-11-02)로 쓰세요. 어느 나라에서 봐도 헷갈리지 않고, 어떤 폴더에서든 이름순으로 정확히 정렬돼요. 파일 이름에 최종, 새버전, 최신은 쓰지 마세요. 다음 검토 차례가 오면 늘 틀린 말이 돼요.

버전 번호는 어디에 적을까요? 공유 작업 파일은 파일 이름을 바꾸지 말고, 버전은 문서 관리 표와 머리글에 적으세요. 검토 차례마다 공유 파일 이름을 바꾸면 링크를 저장해 둔 사람들이 헷갈려요. 버전과 날짜는 배포한 PDF나 꼭 메일로 보내야 하는 사본처럼 공유 폴더 밖으로 나가는 파일에만 이름에 넣어요. 예: 지점 안전 정책 v0.4 - 센터장 검토용.docx.

검토 단계마다 워드 설정하기

단계마다 필요한 피드백이 다르니 워드도 거기에 맞게 설정하세요. 도구 자체는 중급 6번 튜토리얼에서 배웠어요. 여기서는 단계마다 어떤 도구를 쓸지 정해요.

편집 제한을 쓰면 이 선택을 워드가 지키는 규칙으로 만들 수 있어요. 검토자가 추적 없이 고치거나, 메모만 받으려던 글을 고쳐 쓰는 일을 막아요.

1. 검토› 다음 보호› 다음 편집 제한으로 가요.
2. 창의 편집 제한 부분에서 문서에 이런 유형의 편집만 허용을 체크해요.
3. 동료 검토에는 변경 내용 추적을, 내용 승인에는 메모를 골라요.
4. 예, 보호를 시작합니다를 클릭해요. 원하면 암호를 입력하고, 팀이 공용 암호를 보관하는 곳에 적어 둬요.
5. 단계가 끝나면 창을 다시 열고 보호 중지를 클릭해요.

변경 내용 추적을 고르면 모든 수정이 기록되고 아무도 추적을 끌 수 없어요. 메모를 고르면 메모는 달 수 있지만 글은 전혀 고칠 수 없어요. 이 창에서 문서의 일부를 특정 사람에게만 예외로 열어 줄 수도 있지만, 대부분의 검토에는 문서 전체에 설정 하나면 충분해요.

피드백 합치고 충돌 해결하기

공유 파일을 쓸 수 없는 검토자도 있어요. 계정이 없는 이사회 위원이나 인터넷이 안 되는 기차 안에 있는 사람처럼요. 이럴 때는 버전을 넣은 이름으로 사본을 보내고, 돌아온 사본은 수정 내용을 다시 입력하지 말고 결합하세요.

1. 검토› 다음 비교› 다음 결합으로 가요.
2. 원본 문서에서 첫 번째 사본(또는 내 작업 버전)을, 수정된 문서에서 검토자의 사본을 골라요.
3. 검토자가 변경 내용 추적을 깜박했다면, 표시되지 않은 변경 내용에 붙일 이름 칸에 검토자 이름을 입력해요. 그러면 그 수정에도 누가 했는지 표시돼요.
4. 확인을 클릭해요. 워드가 모든 사람의 변경 내용과 메모를 작성자별로 표시한 결합 문서를 만들어요.
5. 세 번째 검토자가 있다면 결과를 다음 사본과 다시 결합해요. 그다음 결합한 파일을 저장하고, 그 변경 내용을 작업 파일에 반영해요.

두 사본 모두에 서식 변경이 있으면, 워드는 한 가지만 저장할 수 있어서 어느 쪽 서식 변경을 남길지 물어볼 수 있어요. 믿을 만한 쪽을 고르고 결과를 확인하세요.

충돌 해결하기. 검토자 두 명이 같은 문장을 서로 다르게 고치면 워드는 두 수정을 모두 보여 줘요. 워드가 대신 골라 주지 않고, 작성자가 짐작으로 골라서도 안 돼요. 간단한 규칙을 쓰세요.

• 사실과 정책 규칙: 내용 승인의 최종 책임자가 정해요.
• 표현과 문체: 작성자가 팀 문체 안내에 따라 정해요.
• 결정이 분명하지 않으면 두 수정을 일단 거부하고, 두 안을 인용한 메모 하나를 쓴 뒤 승인자를 @멘션해요.

승인 기록하고 배포하고 보관하기

누군가의 기억이나 긴 메일 스레드 속에만 있는 승인은 나중에 확인할 수 없어요. 문서 안에 기록하세요. 문서 관리 부분 끝에 짧은 승인 표를 두면 충분해요.

원한다면 승인자가 메모로 승인해도 돼요("v1.0 승인, 이준호, 2026-10-16"). 작성자는 메모를 지우기 전에 그 줄을 표에 옮겨 적어요. 어느 쪽이든 결정이 본문에 남아서, 마지막 정리 뒤에도 사라지지 않아요.

배포. 최종 확인이 끝나면 메모와 추적된 변경 내용을 모두 없애고, 관리 표를 v1.0으로 바꾸고, 파일› 다음 내보내기› 다음 PDF/XPS 문서 만들기로 PDF를 내보내요. 2026-10-21 지점 안전 정책 v1.0.pdf처럼 날짜와 버전을 넣어 이름을 짓고, 몇 사람만 고칠 수 있는 배포본 폴더에 저장하세요. 이 폴더가 보관함이에요. 작년 정책에 뭐라고 쓰여 있었는지 물으면 해당 PDF를 열면 돼요.

버전 기록. 작업 파일이 OneDrive나 SharePoint에 있으니 저장된 상태가 모두 남아요. 파일› 다음 정보› 다음 버전 기록으로 가면 예전 버전을 날짜와 작성자와 함께 볼 수 있고, 열어서 읽거나, 검토 차례가 잘못됐다면 복원할 수 있어요. 버전 기록은 작업 파일을 위한 안전망이에요. 공식 기록은 날짜가 붙은 PDF예요. 무엇이 배포됐는지 정확히 보여 주니까요.

최종 확인 때 검토 점검표 쓰기

최종 확인 담당자는 매번 같은 목록으로 일해서 기억에 기대지 않아요. 점검표는 검토 계획에 두고, 문서 관리 부분이나 메모에서 하나씩 체크하세요.

점검표를 다 채우면 최종 확인 담당자가 승인 표에 날짜를 적고 배포해요. 내용 때문에 어떤 항목이 통과하지 못하면, 문서는 독자에게 나가지 않고 승인자에게 돌아가요.

자주 하는 실수

연습