Notion 리뷰
Notion, 문서와 데이터베이스를 함께 쓸 때
Notion은 문서, 데이터베이스, 위키를 한 워크스페이스에 묶는 생산성 도구입니다. 개인이 쓰는 방식과 팀이 쓰는 방식이 꽤 다릅니다. 이 리뷰는 위키와 프로젝트 기록을 한곳에 모으려는 팀이 무엇을 먼저 정해야 하는지에 초점을 맞춥니다.
문서와 블록 구조
문서는 블록 단위로 구성되며, 문단, 목록, 표, 데이터베이스 등을 자유롭게 배치할 수 있습니다. 자유도가 높은 만큼 구조 없이 쓰면 문서가 흩어집니다. 처음부터 페이지 계층을 정해두는 편이 좋습니다.
실제로 흩어지는 지점은 대개 두 곳입니다. 하나는 최상위 페이지를 계속 새로 만드는 습관이고, 다른 하나는 하위 페이지를 몇 단계까지 허용할지 정하지 않은 상태입니다. 최상위 페이지 수를 열 개 안쪽으로 유지하고, 하위 깊이를 세 단계로 제한해두면 새 문서가 어디로 들어갈지 헷갈리는 일이 줄어듭니다.
블록을 옮기고 복제하는 방식은 자유롭지만, 같은 내용을 여러 페이지에 복사해두면 나중에 원본을 찾기 어려워집니다. 반복되는 내용은 별도 페이지 하나를 두고 링크로 연결하는 편이 관리하기 쉽습니다.
데이터베이스와 뷰
같은 데이터를 표, 보드, 캘린더, 갤러리 등 여러 뷰로 볼 수 있습니다. 상태와 담당자를 속성으로 두면 간단한 작업 관리도 가능합니다. 데이터베이스 설계를 잘못하면 나중에 속성을 바꾸는 데 시간이 들기 때문에 초기 설계가 중요합니다.
속성을 늘리는 일보다 줄이는 일이 어렵습니다. 처음부터 모든 항목을 속성으로 만들기보다, 실제로 필터나 정렬에 쓰는 항목만 남기는 편이 유지보수에 유리합니다. 담당자, 상태, 마감일처럼 반복적으로 쓰는 값부터 정하고 나머지는 본문에서 다루는 방식이 무난합니다.
뷰는 목적별로 나누는 편이 좋습니다. 전체 목록을 보는 표 뷰, 진행 상황을 확인하는 보드 뷰, 일정을 확인하는 캘린더 뷰를 각각 두면 같은 데이터를 다시 입력하지 않아도 됩니다. 반대로 뷰를 너무 많이 만들면 어느 뷰가 기준인지 헷갈리므로, 팀 단위로 쓰는 뷰는 두세 개로 제한하는 편이 안전합니다.
위키는 한 번 만들고 끝나지 않습니다. 정리 주기와 담당자가 정해져야 유지됩니다.
위키로 쓰기
팀 규칙, 온보딩 문서, 회의록을 위키 형태로 모을 수 있습니다. 검색이 문서 전체를 대상으로 동작하기 때문에 흩어진 정보를 찾기 쉽습니다. 다만 오래된 문서를 정리하는 주기가 없으면 위키가 금방 지저분해집니다.
정리 주기는 분기 단위가 다루기 쉽습니다. 분기마다 최근에 열리지 않은 문서를 확인하고, 더 이상 쓰지 않는 문서는 보관 페이지로 옮기는 방식이면 큰 부담 없이 유지됩니다. 문서마다 최종 수정 시점을 확인할 수 있으니, 오래 손대지 않은 문서부터 보는 편이 효율적입니다.
회의록은 날짜별로 쌓기보다 프로젝트 페이지 아래에 모아두면 나중에 맥락을 따라가기 쉽습니다. 결정 사항과 다음 할 일을 문서 상단에 남겨두면 검색 결과에서도 바로 확인할 수 있습니다.
템플릿 활용
자주 쓰는 문서 형식을 템플릿으로 만들어 반복 작업을 줄일 수 있습니다. 회의록, 프로젝트 개요, 온보딩 문서처럼 형식이 정해진 문서에 적합합니다. 팀 템플릿을 지정해두면 새로 합류한 사람도 같은 형식을 따르게 됩니다.
회의록
참석자, 결정 사항, 다음 할 일 항목을 미리 채워두면 회의 중에 형식을 다시 만들지 않아도 됩니다.
프로젝트 개요
목표, 범위, 담당자, 일정 항목을 고정해두면 새 프로젝트를 시작할 때 같은 기준으로 정리됩니다.
온보딩 문서
계정 설정, 권한 요청, 첫 주에 읽을 문서 순서를 담아두면 안내를 반복하지 않아도 됩니다.
권한과 공유
페이지 단위로 공개 범위를 설정할 수 있고, 외부 공개 링크를 만들 수도 있습니다. 민감한 정보가 포함된 페이지는 공개 범위를 별도로 확인해야 합니다. 팀 워크스페이스와 개인 워크스페이스의 경계도 정해두는 편이 좋습니다.
외부 공개 링크는 편리하지만, 한 번 만들어두면 누가 언제 열었는지 확인하기 어렵습니다. 계약서, 인사 기록, 고객 정보처럼 외부에 나가면 곤란한 문서는 처음부터 공개 링크 대상에서 빼두는 편이 안전합니다. 공개 링크를 쓸 때는 목적과 만료 시점을 문서 안에 함께 적어두는 습관이 도움이 됩니다.
공개 범위를 정할 때 확인할 항목
- 문서 성격
- 팀 내부 참고용인지, 외부 협력사와 공유할 문서인지 먼저 구분합니다.
- 공유 대상
- 워크스페이스 구성원 전체에게 열지, 특정 인원에게만 열지 정합니다.
- 링크 사용 여부
- 외부 공개 링크가 필요한 문서인지, 필요하다면 언제까지 유지할지 함께 적어둡니다.
- 개인 공간 분리
- 개인 워크스페이스에 둘 문서와 팀 워크스페이스에 둘 문서를 나눠둡니다.
어떤 팀에 맞는가
문서와 데이터를 함께 관리하고 싶은 팀에 적합합니다. 반대로 구조를 잡을 여력이 없는 팀은 처음에 혼란을 겪을 수 있습니다.
문서만 다루는 팀이라면 기능 대부분이 남습니다. 반대로 회의록, 프로젝트 진행 상황, 담당자별 업무를 한 화면에서 보고 싶은 팀이라면 데이터베이스와 문서를 같이 쓰는 구조가 잘 맞습니다. 도입 초기에 계층과 속성 기준을 정할 사람을 한 명 지정해두면 이후 정리 비용이 줄어듭니다.
반대로 문서 형식이 이미 다른 도구에 자리 잡았거나, 담당자가 자주 바뀌는 조직이라면 구조를 유지하기 어려울 수 있습니다. 이 경우에는 특정 프로젝트 하나에서 먼저 시험해보고 범위를 넓히는 편이 낫습니다.
도입 전 확인 사항
도입을 결정하기 전에 네 가지를 문서로 남겨두면 첫 달의 시행착오를 줄일 수 있습니다.
- 1 페이지 계층과 데이터베이스 설계 기준을 정합니다.
- 2 문서 정리 주기와 담당자를 지정합니다.
- 3 외부 공개 링크 사용 정책을 정합니다.
- 4 개인·팀 워크스페이스 분리 기준을 정합니다.
검토 기준과 갱신
이 리뷰는 제품 공식 문서를 근거로 작성했습니다. 확인되지 않은 사용자 수치는 기재하지 않으며, 주요 기능이 바뀌면 갱신 여부를 검토합니다.
검토 항목과 작성 방식을 더 자세히 확인하려면 검토 기준 페이지를 함께 보시기 바랍니다.
검토 기준 확인하기자주 묻는 질문
개인 사용자도 데이터베이스를 쓸 필요가 있나요?
문서만 쓴다면 없어도 됩니다. 다만 읽을 목록, 지원 기록, 일정처럼 같은 형식이 반복되는 항목이 있다면 표 하나만 만들어도 정리가 쉬워집니다.
위키가 지저분해지는 걸 막으려면 어떻게 해야 하나요?
정리 주기와 담당자를 정해두는 것이 가장 확실합니다. 분기마다 오래 열리지 않은 문서를 확인하고, 더 이상 쓰지 않는 문서는 보관 페이지로 옮기는 방식이 유지하기 쉽습니다.
템플릿은 몇 개나 만들어야 하나요?
많을 필요는 없습니다. 회의록, 프로젝트 개요, 온보딩 문서처럼 반복해서 쓰는 형식 세 가지 정도로 시작하고, 실제로 자주 쓰이는 것이 확인되면 늘리는 편이 낫습니다.
외부 공개 링크는 언제 쓰면 되나요?
외부 협력사나 고객에게 특정 문서 하나를 보여줘야 할 때 씁니다. 계약서나 인사 기록처럼 민감한 문서는 처음부터 공개 링크 대상에서 빼두는 편이 안전합니다.
다른 도구와 함께 쓸 수 있나요?
문서와 데이터베이스를 한곳에서 다루는 것이 핵심이므로, 이미 쓰고 있는 도구의 역할을 먼저 정리하는 편이 좋습니다. 어떤 도구를 함께 쓸지는 팀의 업무 흐름에 따라 달라집니다.
문서 관리 도구를 더 살펴보려면
비슷한 문서·협업 도구를 함께 비교하면 어떤 구조가 우리 팀에 맞는지 판단하기 쉽습니다. 각 리뷰는 공식 문서를 근거로 작성했으며, 확인되지 않은 수치는 기재하지 않습니다.
궁금한 점이 있으면 문의해 주세요
이 리뷰에서 다루지 않은 항목이나 팀 환경에 맞는 활용 방법이 궁금하다면 문의 페이지의 상담 접수 양식을 이용하실 수 있습니다. 확인 가능한 범위 안에서 답변드립니다.