월요일 오전 9시쯤이었습니다. 새로 온 직원이 “자료가 어디 있나요?”라고 묻는데, 순간 말이 막히더군요. 드라이브엔 폴더가 많은데 최신 파일이 뭔지 애매했고, 중요한 결정은 슬랙 대화 속에 묻혀 있었고, 노션은 누가 만들다 만 페이지가 쌓여 있었습니다. 그날 잠시 멈칫했습니다. “협업툴을 다 쓰고 있는데 왜 일이 더 느리지?”라는 생각이 들었거든요.
1) 노션·슬랙·드라이브, 역할을 먼저 나눠야 합니다
셋업을 시작할 때 가장 흔한 실수는 “노션에 다 넣자” 혹은 “드라이브만 잘 정리하면 된다” 같은 방식입니다. 그런데 실제 현장에서는 문서의 성격이 다릅니다. 원본(계약서·세금계산서·견적서)과 기준(업무규정·체크리스트)과 대화(진행/결정)는 저장 방식도, 찾는 방식도 다릅니다.
| 도구 | 무엇을 담나 | 추천 단위 | 이렇게 쓰면 망합니다 |
|---|---|---|---|
| 노션 | 업무 기준, 매뉴얼, 회의록(결정사항), 프로젝트 위키 | 페이지/DB(데이터베이스) | 원본 파일을 전부 노션에만 올리고 드라이브 원본을 없앰 |
| 슬랙 | 실시간 소통, 이슈 트래킹, 결재/승인 요청, 알림 | 채널/스레드 | 결정사항이 채팅에만 남고 문서화가 안 됨 |
| 드라이브 | 원본 문서, 증빙, 대용량 파일, 협업 파일(시트/문서) | 공유드라이브/폴더 | 개인 드라이브에 파일이 흩어져 퇴사/권한 문제가 터짐 |
2) 2시간 만에 ‘최소 셋업’ 만드는 순서(단계 리스트)
완벽하게 하려다 실패하는 경우가 많습니다. 그래서 저는 MVS(Minimum Viable Setup)부터 만듭니다. “이 정도면 이번 달부터 혼란이 줄어든다” 수준의 최소 구조를 먼저 깔고, 다음 달에 고칩니다. 그런데 이상한 건… 이렇게 가볍게 시작한 팀이 오히려 정착이 더 빠르더군요.
- 드라이브부터 ‘원본 창고’ 세팅 (폴더/권한/소유권)
- 슬랙 채널을 ‘업무 흐름’ 기준으로 재배치 (공지/프로젝트/운영/지원)
- 노션에 ‘팀 위키 홈’ 1장 만들기 (규정·양식·회의록·프로젝트 링크)
- 결정사항 기록 룰 1줄 고정 (슬랙에서 결정 → 노션 회의록/결정 DB에 남김)
- 온보딩 체크리스트 1장 배포 (신입/외주/파트타임 공통)
3) Google Drive 구조: ‘폴더’보다 ‘권한 설계’가 먼저입니다
드라이브에서 사고가 나는 지점은 폴더가 아니라 권한입니다. 특히 링크 공유를 “링크 아는 사람 누구나”로 열어두고, 파일이 외부로 퍼진 뒤에야 알아차리는 경우가 꽤 있습니다. 돌이켜보면 그날은 조금 특별했습니다. 한 고객사는 견적서가 외부 협력사에 그대로 전달되면서 단가가 노출됐고, 그 후 협상력이 급격히 떨어졌습니다. 비용보다 신뢰가 더 아팠습니다.
3-1. 추천 폴더 트리(공유드라이브 중심)
가능하면 ‘공유드라이브(Shared drive)’를 기준으로 운영하는 편이 안전합니다. 개인 소유 파일이 늘수록 퇴사/이직/휴직 때 인수인계가 깨지기 쉽습니다.
| 상위 폴더 | 하위 예시 | 원칙 |
|---|---|---|
| 01_경영관리 | 법무/계약, 인사, 회계, 정책자금 | 민감도 높음 → 최소권한 |
| 02_영업·마케팅 | 제안서, 견적, 캠페인, 레퍼런스 | 최신본 규칙(파일명/버전) |
| 03_운영·프로젝트 | 프로젝트별 폴더, 산출물, 회의자료 | 프로젝트 종료 시 아카이브 |
| 99_템플릿 | 표준 계약서, 보고서 템플릿, 체크리스트 | 수정권한 제한, 복제 사용 |
3-2. 권한은 “역할별 기본값”으로 고정합니다
권한은 매번 고민하면 팀이 피곤해집니다. 그래서 역할별 기본값을 정해두고, 예외만 처리합니다. (예외가 많아지면 구조가 잘못된 겁니다.)
- 기본값: 내부 직원은 ‘조직/그룹’ 단위로 공유하고, 개인 추가는 최소화합니다
- 외부 협력사는 “폴더 1개, 기간 1개월”처럼 범위를 작게 끊어줍니다
- 링크 공유는 기본 ‘제한(Restricted)’으로 두고, 필요할 때만 ‘링크 있는 사용자(Anyone with the link)’로 예외 처리합니다
- 문서 원본은 ‘편집자(Editor)’를 최소화하고, 검토자는 ‘댓글(Commenter)’ 중심으로 운영합니다
4) Slack 구조: 채널을 ‘사람’이 아니라 ‘업무’로 나눕니다
슬랙이 산만해지는 이유는 채널이 늘어서가 아니라, 흐름이 없어서입니다. 일단 아래 4종류만 먼저 정리해도 체감이 큽니다.
| 채널 유형 | 예시 | 규칙(짧게) |
|---|---|---|
| 공지 | #ann_공지, #ann_인사 | 공지 채널은 게시만, 질문은 스레드로 |
| 운영 | #ops_운영, #ops_재고, #ops_정산 | 하루 단위 이슈/처리 상태 공유 |
| 프로젝트 | #pj_고객사명_기간, #pj_신제품런칭 | 프로젝트 종료 시 아카이브 |
| 지원 | #help_it, #help_총무 | 요청 템플릿 고정(무엇/언제/누가) |
경고: “결정이 난 대화”가 슬랙에만 남으면, 그 팀은 3개월 뒤 같은 회의를 다시 합니다.
- 중요한 대화는 ‘스레드’로 묶어 나중에 찾기 쉽게 합니다
- 결정/정책/프로세스는 노션으로 옮기고 링크를 슬랙에 남깁니다
- 채널명은 팀이 확장돼도 흔들리지 않는 접두어(ann/ops/pj/help)로 통일합니다
5) Notion 구조: “홈 1장 + DB 3개”면 충분합니다
노션을 처음부터 멋지게 만들 필요 없습니다. 오히려 너무 예쁘게 꾸미면 운영이 무너질 때가 많습니다. 저는 보통 홈 1장에 링크를 모으고, 데이터는 DB 3개로 시작합니다.
5-1. 노션 홈(Team Wiki) 구성
- 회사 소개/조직도/연락망(최신 유지)
- 업무 기준: 결재, 보고, 회의, 파일명 규칙
- 자주 쓰는 링크: 드라이브(공유드라이브), 슬랙 주요 채널, 핵심 문서
- 신입 온보딩: 계정/권한/필수 읽을거리 체크리스트
5-2. DB 3개(실무에서 가장 오래 살아남는 형태)
| DB 이름 | 무엇을 쌓나 | 필수 속성(예시) |
|---|---|---|
| 결정·정책 DB | 회의 결과, 정책 변경, 합의 사항 | 일자, 주제, 결정내용, 적용일, 담당자 |
| 프로젝트 DB | 진행 프로젝트의 상태/리스크 | 상태, 마감일, 우선순위, 리스크, 링크(드라이브/슬랙) |
| 템플릿·양식 DB | 보고서/회의록/요청서 표준 | 유형, 사용처, 최신버전 링크, 작성 가이드(짧게) |
6) 운영 루틴: 셋업은 하루, 정착은 4주가 걸립니다
도구는 세팅보다 운영이 어렵습니다. 그래서 저는 4주를 기준으로 루틴을 고정합니다. 아주 작게요.
- 매주 월요일 10분: 이번 주 우선순위(노션 프로젝트 DB 업데이트)
- 매일 5분: 운영 이슈는 #ops 채널에 모으고 담당자를 명시
- 금요일 15분: “결정사항 3개”를 노션 결정 DB에 정리(슬랙 링크 포함)
- 월 1회 30분: 폴더/채널 정리(아카이브, 권한 점검)
- 누가 ‘최신본’ 책임자인지 정합니다(문서/양식마다 1명)
- 파일명 규칙은 짧게 고정합니다: 날짜_고객/프로젝트_문서명_v1
- 중요 자료는 “드라이브 원본 링크”를 노션에 붙여 넣는 방식으로 일원화합니다
- 회의는 늘어도 되지만, ‘결정’은 반드시 기록합니다
협업툴은 결국 사람을 바꾸는 장치가 아니라, 팀이 합의한 기준을 지키게 만드는 장치입니다. 솔직히 말하면, 저는 “이 정도면 되지”라고 넘어가고 싶을 때가 더 많습니다. 그런데 한 번만 제대로 정리해두면, 다음 분기부터는 회의 시간이 줄고, 신입이 빨리 적응하고, 대표가 보고를 덜 쫓게 됩니다. 그게 꽤 큰 차이를 만듭니다.
중소기업·소상공인 맞춤 컨설팅이 필요하다면 한국경영컨설팅으로 문의하세요.
'5. 운영관리·시스템화' 카테고리의 다른 글
| 면담·경고장·해지 절차, 중소기업 인사 리스크의 기준선 (0) | 2026.01.21 |
|---|---|
| 오픈·마감 체크리스트 만들기｜매장 실수 줄이는 운영 표준 (1) | 2026.01.20 |
| 환불·취소 정책 법적기준｜분쟁 줄이는 사장 실무 체크리스트 (1) | 2026.01.19 |
| Inspired 핵심 인사이트: 중소기업 제품이 팔리는 팀의 방식 (0) | 2026.01.17 |
| 하도급·위수탁 계약 실수 12가지｜분쟁을 막는 체크리스트 (1) | 2026.01.15 |
