같은 문서가 여러 곳에 있어서 오히려 일이 느려졌다
처음에는 협업 도구를 많이 쓰면 일이 빨라질 줄 알았습니다. 정책은 Notion에 정리하고, 파일은 Google Drive에 올리고, Slack에서는 링크를 주고받으면 충분하다고 생각했습니다.
그런데 실제로는 같은 내용이 Notion에도 있고, Google Drive에도 있고, Slack 검색에도 남아 있었습니다. 누군가 “이게 최신본 맞나요?”라고 물으면 저도 바로 대답하지 못하는 경우가 생겼습니다.
적용 기간은 2026년 3월 10일 ~ 2026년 4월 21일, 총 6주였습니다. 업무 환경은 재택근무 3일, 사무실 2일이었고, 사용 도구는 Notion, Google Drive, Slack, Google Docs, Gmail이었습니다.
하루 평균 업무 시간은 약 8시간 20분이었습니다. Slack과 Gmail 알림은 하루 평균 84건 정도였고, 문서를 찾느라 흐름이 끊기는 날에는 집중 시간이 2시간도 안 되는 경우가 있었습니다.
Notion에도 있고 Drive에도 있고 Slack에도 있었다
가장 흔한 문제는 캠페인 정책 문서였습니다. Notion에 요약본이 있고, Google Docs에는 초안이 있고, Slack에는 결정사항이 대화로 남아 있었습니다.
팀원 입장에서는 어디를 봐야 최신인지 헷갈릴 수밖에 없었습니다. 저도 회의 중에 “잠시만요, 그 문서가 Drive였나요, Notion이었나요?”라고 말한 적이 여러 번 있었습니다.
특히 재택근무일에는 바로 옆자리에서 물어볼 수 없으니 Slack 재질문이 늘었습니다. 자료 재질문 횟수는 적용 전 주 13회까지 올라갔습니다.
최신본을 찾는 데 시간이 계속 들었다
SSOT를 적용하기 전 문서 검색 평균 시간은 9분 20초였습니다. 문서 하나 찾는 데 10분 가까이 쓰는 일이 반복되니 생각보다 피로했습니다.
업무 누락도 생겼습니다. 적용 전 2주 동안 “결정사항 반영 누락”이나 “오래된 링크 공유”로 생긴 업무 누락이 6건 있었습니다.
처음에는 “검색을 잘하면 되겠지”라고 생각했습니다. 그런데 문제는 검색 능력이 아니라, 팀 안에서 원본 위치를 합의하지 않았다는 점이었습니다.
142개 문서를 먼저 점검했다
SSOT 원칙을 바로 적용하기 전에 문서부터 세어봤습니다. 점검한 문서 수는 142개였습니다.
이 숫자를 보고 조금 당황했습니다. 매일 쓰는 문서는 몇 개 안 된다고 생각했는데, 실제로는 Notion, Drive, Slack 링크, Google Docs가 서로 얽혀 있었습니다.
중복 문서 31개를 찾았다
점검 결과 중복 문서 수는 31개였습니다. 같은 정책을 다룬 문서가 이름만 다르게 존재하거나, Google Docs 초안이 복사본으로 여러 개 남아 있었습니다.
오래된 문서 링크도 18개 있었습니다. Slack에서 예전에 공유한 링크를 눌렀더니 권한이 없거나, 이미 대체된 문서로 연결되는 경우가 있었습니다.
아래는 점검한 문서 유형표입니다.
| 문서 유형 | 점검 수량 | 주로 있던 위치 | 문제로 느낀 점 |
|---|---|---|---|
| 정책·운영 기준 문서 | 24개 | Notion, Google Docs | 최신 기준이 어디인지 헷갈렸습니다 |
| 캠페인 기획 문서 | 28개 | Google Drive, Slack 링크 | 초안과 최종본이 섞였습니다 |
| 회의록·결정사항 | 21개 | Notion, Slack | Slack에만 남은 결정이 많았습니다 |
| 디자인·소재 파일 | 19개 | Google Drive | 파일명 규칙이 제각각이었습니다 |
| 외부 공유 문서 | 16개 | Google Docs, Gmail | 오래된 링크가 남아 있었습니다 |
| 성과·정산 자료 | 18개 | Google Sheets, Drive | 복사본이 여러 개였습니다 |
| 업무 요청·체크리스트 | 16개 | Notion, Slack | 요청 내용이 대화에 묻혔습니다 |
| 합계 | 142개 | Notion·Drive·Slack 혼재 | 원본 기준이 없었습니다 |
표로 정리하고 나니 문제가 명확해졌습니다. 도구가 많아서 문제가 아니라, 도구별 역할이 정해져 있지 않은 것이 문제였습니다.
원본 위치가 불명확한 문서도 22개였다
중복 문서보다 더 애매했던 건 원본 위치가 불명확한 문서였습니다. 이런 문서가 22개였습니다.
Notion 문서가 최신인지, Drive에 있는 Google Docs가 최신인지, Slack에 올라온 파일이 최종본인지 판단하기 어려웠습니다. 팀원도 각자 다른 문서를 보고 있었습니다.
또 Slack에만 남아 있던 결정사항이 15건 있었습니다. 회의 후 Slack 대화에서 결정은 됐는데, Notion이나 Drive 문서에는 반영되지 않은 상태였습니다.
SSOT 기준을 업무 유형별로 나눴다
처음에는 모든 자료를 Notion에 모으려고 했습니다. 하지만 이 방식은 금방 막혔습니다.
Google Sheets 원본, 디자인 파일, 외부 전달용 Google Docs까지 Notion에 넣으려 하니 오히려 링크만 가득한 페이지가 됐습니다. 결국 “한 곳에 다 넣기”가 아니라 “원본 위치를 정하기”로 방향을 바꿨습니다.
정책과 결정사항은 Notion
정책, 운영 기준, 회의 결정사항은 Notion을 원본으로 정했습니다. 이유는 검색과 수정 이력, 팀 공유가 비교적 쉬웠기 때문입니다.
회의 중 결정된 내용은 Slack에 남기지 않고, 회의 후 Notion 결정사항 페이지에 옮겼습니다. Slack에는 “Notion에 반영 완료”라는 링크만 남겼습니다.
파일 원본은 Google Drive
파일 원본은 Google Drive에 두기로 했습니다. 특히 Google Docs, Google Sheets, 디자인 파일, 외부 공유 자료는 Drive가 더 맞았습니다.
Notion에는 파일 자체를 복사하지 않았습니다. 대신 Drive 원본 링크와 문서 상태만 붙였습니다.
이 방식으로 바꾸니 문서 수정 위치가 명확해졌습니다. Drive 파일을 고치면 되고, Notion은 기준과 설명을 보는 곳으로 역할이 나뉘었습니다.
대화와 알림은 Slack
Slack은 진행 대화와 알림만 남기기로 했습니다. 결정사항 원본이나 파일 보관소로 쓰지 않기로 했습니다.
물론 현실적으로 모든 대화를 문서화할 수는 없었습니다. 그래서 “결정이 된 순간”만 Notion에 옮기기로 했습니다.
아래는 적용 전 문제 현황표입니다.
| 문제 항목 | 적용 전 수치 | 실제로 생긴 불편 |
|---|---|---|
| 점검한 문서 수 | 142개 | 문서 위치가 흩어져 있었습니다 |
| 중복 문서 수 | 31개 | 최신본 판단이 어려웠습니다 |
| 오래된 문서 링크 수 | 18개 | Slack과 Gmail 링크가 자주 틀렸습니다 |
| 원본 위치 불명확 문서 | 22개 | 팀원마다 보는 문서가 달랐습니다 |
| Slack에만 남은 결정사항 | 15건 | 결정사항 반영 누락이 생겼습니다 |
| 자료 재질문 횟수 | 주 13회 | 같은 링크를 반복해서 물었습니다 |
| 문서 검색 평균 시간 | 9분 20초 | 집중 흐름이 끊겼습니다 |
| 알림 스트레스 점수 | 10점 만점 7점 | 문서 확인 요청이 부담됐습니다 |
이 표를 팀에 공유했을 때 피드백이 꽤 현실적이었습니다. “정리는 좋은데 너무 복잡하면 다시 안 쓴다”는 말이 가장 기억에 남았습니다.
6주 적용 후 달라진 수치
SSOT 정리 작업에 쓴 시간은 총 7시간 30분이었습니다. 하루에 몰아서 한 것이 아니라, 6주 동안 문서 유형별로 나눠 정리했습니다.
처음에는 이 시간이 아깝게 느껴졌습니다. 하지만 문서 검색과 재질문에 쓰던 시간을 생각하면 필요한 투자였습니다.
중복 문서가 31개에서 9개로 줄었다
SSOT 적용 후 중복 문서 수는 31개에서 9개로 감소했습니다. 완전히 0으로 만들지는 못했습니다.
일부 문서는 외부 공유용 복사본이 필요했고, 과거 프로젝트 보관용 문서도 남겨야 했습니다. 그래서 삭제보다 상태값 표시를 우선했습니다.
가장 효과 있었던 개선은 문서 제목 앞에 상태값 표시였습니다.
예를 들면 [원본], [참고],
[보관], [폐기예정]처럼
붙였습니다.
자료 재질문이 주 13회에서 5회로 줄었다
자료 재질문 횟수는 주 13회에서 주 5회로 감소했습니다. 특히 “최신본 어디에 있나요?”라는 질문이 줄었습니다.
Slack에서 질문이 오면 예전에는 제가 링크를 다시 찾아서 보냈습니다. 이제는 Notion 원본 페이지나 Drive 원본 폴더를 안내하면 됐습니다.
검색 시간도 절반 이하로 줄었다
문서 검색 평균 시간은 9분 20초에서 3분 40초로 감소했습니다. 이 차이는 체감이 컸습니다.
문서를 찾다가 흐름이 끊기는 일이 줄었습니다. 하루 평균 집중 시간도 적용 전 2시간 10분에서 적용 후 3시간 25분 정도로 늘었습니다.
SSOT 적용 전후 비교표
| 항목 | 적용 전 | 적용 후 | 변화 |
|---|---|---|---|
| 중복 문서 수 | 31개 | 9개 | 22개 감소 |
| 자료 재질문 횟수 | 주 13회 | 주 5회 | 주 8회 감소 |
| 문서 검색 평균 시간 | 9분 20초 | 3분 40초 | 5분 40초 감소 |
| 오래된 문서 링크 | 18개 | 6개 | 상태값 표시 후 줄어듦 |
| 원본 위치 불명확 문서 | 22개 | 5개 | 기준표 적용 효과 |
| Slack에만 남은 결정사항 | 15건 | 3건 | Notion 반영 규칙 적용 |
| 업무 누락 건수 | 2주 6건 | 2주 2건 | 결정사항 누락 감소 |
| 할일 관리 유지율 | 67% | 84% | 원본 링크가 명확해짐 |
| 알림 스트레스 점수 | 7점/10점 | 4점/10점 | 재질문 부담 감소 |
| 하루 평균 집중 시간 | 2시간 10분 | 3시간 25분 | 검색 시간이 줄었습니다 |
전후 비교표를 보면서 느낀 건, SSOT가 문서를 예쁘게 정리하는 작업은 아니라는 점이었습니다. 팀이 같은 원본을 보게 만드는 일이었습니다.
적용하면서 실패한 부분
SSOT 적용이 처음부터 잘 된 것은 아니었습니다. 오히려 첫 2주는 욕심이 많아서 더 복잡해졌습니다.
저는 모든 문서를 Notion에 넣으면 해결될 줄 알았습니다. 하지만 실제 업무에서는 파일 원본과 요약 문서가 다르게 움직였습니다.
모든 자료를 Notion에 넣으려다 실패했다
Google Docs 원문을 Notion에 복사해 넣고, Drive 파일 링크도 붙이고, Slack 결정사항까지 옮기려 했습니다. 그러자 Notion 페이지가 너무 길어졌습니다.
팀원들은 오히려 “그래서 실제 파일은 어디서 수정하나요?”라고 물었습니다. 이 피드백을 받고 방향을 바꿨습니다.
Notion은 정책과 결정사항 원본으로 쓰고, Drive는 파일 원본으로 남기는 것이 더 맞았습니다. 모든 것을 한 도구에 넣는 게 SSOT가 아니라는 걸 뒤늦게 알았습니다.
파일 원본과 요약 문서를 구분해야 했다
가장 헷갈렸던 부분은 요약 문서와 원본 파일의 구분이었습니다. 예를 들어 캠페인 운영 기준은 Notion이 원본이고, 실제 광고 소재 파일은 Drive가 원본이었습니다.
이 둘을 구분하지 않으면 Notion에도 파일이 있고 Drive에도 파일이 있는 상태가 됩니다. 결국 다시 중복 문서가 생깁니다.
그래서 문서 제목 앞에 상태값을 붙였습니다. 이 방법이 팀에서 가장 빠르게 받아들여졌습니다.
지금 내가 쓰는 문서 원본 위치 기준
지금은 문서를 만들기 전에 먼저 묻습니다. “이 문서의 원본은 어디에 둘 것인가?”
이 질문을 정하지 않으면 나중에 Slack에 링크가 흩어지고, Notion에 요약이 생기고, Drive에 복사본이 생깁니다.
문서 원본 위치 기준표
| 문서 유형 | 원본 위치 | Slack 역할 | 제목 상태값 예시 |
|---|---|---|---|
| 정책·운영 기준 | Notion | 변경 알림과 링크 공유 | [원본] 운영 정책 |
| 회의 결정사항 | Notion | 회의 후 반영 완료 알림 | [원본] 4월 2주차 결정사항 |
| Google Docs 초안 | Google Drive | 검토 요청 링크 공유 | [초안] 제안서 v1 |
| 최종 외부 전달 파일 | Google Drive | 발송 완료 알림 | [원본] 외부 전달용 최종본 |
| Google Sheets 성과표 | Google Drive | 업데이트 알림 | [원본] 4월 성과표 |
| 디자인 파일 | Google Drive | 피드백 스레드 운영 | [원본] 배너 소재 |
| 종료된 프로젝트 자료 | Google Drive 보관 폴더 | 보관 위치 안내 | [보관] 2026 Q1 캠페인 |
| 임시 의견·진행 대화 | Slack | 진행 상황 공유 | 원본으로 보지 않음 |
이 기준표를 만든 뒤 문서 생성 속도는 조금 느려졌습니다. 하지만 나중에 찾는 시간은 훨씬 줄었습니다.
특히 팀원이 새 문서를 만들 때 “이건 Notion 원본인가요, Drive 원본인가요?”라고 먼저 묻기 시작한 것이 가장 큰 변화였습니다.
팀 피드백을 반영하며 고친 것
SSOT 적용 중 팀원 피드백은 총 8건이었습니다. 대부분 “좋은데 너무 복잡하면 유지가 안 된다”는 방향이었습니다.
그래서 규칙을 줄이고, 상태값을 명확히 하고, Slack 공지 문구를 짧게 바꿨습니다.
| 팀 피드백 | 반영 전 문제 | 반영한 방식 |
|---|---|---|
| 원본 위치 기준이 너무 길다 | 문서마다 예외가 많아 보였습니다 | 문서 유형별로 8개 기준만 남겼습니다 |
| Notion 페이지가 너무 길다 | 원본과 요약이 섞였습니다 | 정책·결정사항만 Notion 원본으로 제한했습니다 |
| Drive 폴더명이 제각각이다 | 검색이 어려웠습니다 | 프로젝트명과 상태값을 앞에 붙였습니다 |
| Slack에서 결정이 묻힌다 | 나중에 찾기 어려웠습니다 | 결정사항은 Notion에 옮긴 뒤 링크만 남겼습니다 |
| 외부 공유 문서가 헷갈린다 | 최종본과 초안이 섞였습니다 |
[초안], [원본],
[보관] 상태값을 붙였습니다
|
| 검색어가 통일되지 않았다 | 같은 문서를 다르게 불렀습니다 | 문서 제목 규칙을 통일했습니다 |
| 너무 많은 문서를 옮기려 한다 | 정리 작업이 부담됐습니다 | 신규 문서부터 기준을 적용했습니다 |
| 상태값 표시가 가장 보기 쉽다 | 링크 설명만으로 부족했습니다 | 제목 앞 상태값 표시를 기본 규칙으로 정했습니다 |
가장 효과 있었던 개선은 역시 문서 제목 앞에 상태값 표시였습니다. 설명을 길게 하지 않아도 제목만 보고 원본인지 참고용인지 알 수 있었습니다.
내가 만든 SSOT 운영 체크리스트
SSOT 기준은 한 번 정한다고 끝나지 않았습니다. 새 문서를 만들 때마다 다시 흔들릴 수 있었습니다.
그래서 짧은 체크리스트를 만들었습니다. 문서 작성자와 요청자가 모두 볼 수 있는 기준입니다.
| 번호 | 체크 항목 | 확인 내용 |
|---|---|---|
| 1 | 이 문서의 원본 위치가 정해졌는가 | Notion인지 Drive인지 먼저 정합니다 |
| 2 | Slack에만 결정사항을 남기지 않았는가 | 결정되면 Notion에 옮깁니다 |
| 3 | 파일 원본과 요약 문서를 구분했는가 | Drive 원본, Notion 요약을 혼동하지 않습니다 |
| 4 | 제목 앞 상태값을 붙였는가 |
[원본], [초안],
[참고], [보관]을
표시합니다
|
| 5 | 오래된 링크를 닫거나 보관 처리했는가 | Slack과 Gmail의 과거 링크를 확인합니다 |
| 6 | 외부 공유 문서의 최신본이 명확한가 | Drive 원본 링크만 공유합니다 |
| 7 | 팀원이 같은 위치를 볼 수 있는가 | 권한과 접근 가능 여부를 확인합니다 |
| 8 | 새 복사본을 만들 필요가 있는가 | 필요 없으면 원본 링크로 대체합니다 |
| 9 | 문서 요청 방식이 정해졌는가 | Slack 요청 시 원본 링크를 함께 남깁니다 |
| 10 | 주 1회 정리 시간이 있는가 | 오래된 링크와 중복 문서를 점검합니다 |
이 체크리스트를 쓰면서 새 문서를 만들 때 한 번 멈추게 됐습니다. “일단 복사해서 새로 만들자”는 습관이 조금 줄었습니다.
FAQ
Q1. SSOT를 적용하면 모든 문서를 Notion에 넣어야 하나요?
제 경험상 그렇지 않았습니다. 모든 문서를 Notion에 넣으려다 오히려 실패했습니다.
정책과 결정사항은 Notion이 맞았지만, Google Docs, Google Sheets, 디자인 파일 같은 원본 파일은 Google Drive에 두는 편이 더 자연스러웠습니다.
Q2. Slack은 SSOT에서 어떤 역할로 남겼나요?
Slack은 원본 저장소가 아니라 진행 대화와 알림 채널로 남겼습니다. 결정사항이 생기면 Notion에 반영하고, Slack에는 해당 링크를 공유했습니다.
Slack 검색에 의존하면 시간이 지나면서 최신본을 찾기 어려웠습니다.
Q3. 가장 효과가 컸던 개선은 무엇이었나요?
가장 효과 있었던 개선은 문서 제목 앞에 상태값 표시였습니다.
[원본], [초안],
[보관] 같은 표시만으로도 팀원들이 문서 성격을 빠르게
파악했습니다.
복잡한 규칙보다 제목 규칙 하나가 더 잘 유지됐습니다.
Q4. 다시 적용한다면 무엇부터 할 건가요?
저라면 처음부터 142개 문서를 모두 정리하려고 하지 않을 겁니다. 먼저 최근 2주 동안 자주 쓰는 문서부터 원본 위치를 정하겠습니다.
그다음 중복 문서와 오래된 링크를 줄이는 방식으로 단계적으로 적용할 것 같습니다.
마무리하며, 스마트워크는 도구보다 원본 기준이었다
2026년 3월 10일부터 2026년 4월 21일까지 총 6주 동안 SSOT 원칙을 적용해봤습니다. 점검한 문서 수는 142개였고, 중복 문서는 31개, 오래된 문서 링크는 18개, 원본 위치가 불명확한 문서는 22개였습니다.
Slack에만 남아 있던 결정사항도 15건이나 있었습니다. 이 상태에서는 Notion, Google Drive, Slack을 모두 써도 오히려 일이 느려졌습니다.
SSOT 적용 후 중복 문서는 31개에서 9개로 줄었습니다. 자료 재질문은 주 13회에서 주 5회로 줄었고, 문서 검색 평균 시간은 9분 20초에서 3분 40초로 줄었습니다.
물론 완벽하게 정리된 것은 아닙니다. 아직도 외부 공유용 복사본이나 보관 문서는 남아 있습니다. 다만 이제는 무엇이 원본이고 무엇이 참고용인지 구분할 기준이 생겼습니다.

댓글 쓰기
광고성 링크, 무관한 홍보, 욕설, 비방, 개인정보가 포함된 댓글은 사전 고지 없이 삭제될 수 있습니다.
댓글은 운영자 확인 후 공개될 수 있습니다.