노션 템플릿 복사 전에 정할 7개 속성: 한 데이터베이스로 업무 시스템 만드는 법
템플릿이 오래가지 않는 이유는 디자인보다 구조에 있습니다
노션 템플릿을 복사한 첫날에는 대시보드가 완성된 것처럼 보입니다. 예쁜 아이콘, 정돈된 보드, 주간 캘린더, 목표 페이지가 이미 준비돼 있으니 바로 일을 시작할 수 있을 것 같습니다.
하지만 며칠 뒤부터 문제가 생깁니다. 같은 할 일이 여러 페이지에 중복되고, 완료한 작업이 캘린더에는 남아 있는데 보드에서는 사라지며, 새 프로젝트를 추가할 때마다 속성을 다시 만들어야 합니다.
이 문제는 템플릿이 부족해서가 아니라 무엇을 한 번만 저장하고 무엇을 화면마다 다르게 보여줄지 정하지 않았기 때문입니다. 노션에서는 화면 모양보다 데이터베이스의 속성과 관계가 먼저입니다.
Notion의 데이터베이스 공식 안내에 따르면 데이터베이스의 각 항목은 하나의 페이지이며, 같은 데이터 소스를 표·보드·캘린더·리스트 등 여러 뷰로 볼 수 있습니다. 즉, 좋은 업무 시스템은 페이지를 많이 복사하는 구조가 아니라 하나의 원본을 여러 목적에 맞게 바라보는 구조에 가깝습니다.
먼저 한 문장으로 관리 대상을 정합니다
속성을 만들기 전에 데이터베이스 한 줄이 무엇을 뜻하는지 정해야 합니다. 한 줄이 업무인지, 프로젝트인지, 회의인지, 콘텐츠인지가 섞이면 속성이 빠르게 늘어납니다.
예를 들어 콘텐츠 운영 데이터베이스라면 한 줄은 “발행 가능한 콘텐츠 한 건”으로 정할 수 있습니다. 프로젝트 관리 데이터베이스라면 한 줄은 “완료 여부를 판단할 수 있는 업무 한 건”이 더 적합합니다.
다음 문장을 채워보면 기준이 선명해집니다.
정의: 이 데이터베이스의 한 항목은 ______이며, ______가 되면 완료로 봅니다.
완료 기준까지 적는 이유는 상태값을 단순히 ‘진행 중’으로 남기지 않기 위해서입니다. 결과물이 무엇인지 모르면 데이터베이스는 기록 창고가 되고, 매일 봐야 할 작업판이 되지 못합니다.
처음에는 7개 속성이면 충분합니다
템플릿을 복사하면 속성이 15개나 20개씩 붙어 있는 경우가 많습니다. 하지만 실제로 꾸준히 입력할 수 있는 속성은 많지 않습니다.
업무와 콘텐츠 운영에 공통으로 쓰기 쉬운 최소 구조는 다음과 같습니다.
| 속성 | 권장 유형 | 답해야 하는 질문 |
|---|---|---|
| 이름 | Title | 무엇을 끝내야 하나요? |
| 상태 | Status | 지금 어느 단계인가요? |
| 날짜 | Date | 언제 하거나 언제 내보내나요? |
| 영역 | Select | 어떤 종류의 일인가요? |
| 담당 | Person 또는 Select | 누가 다음 행동을 하나요? |
| 다음 행동 | Text | 가장 가까운 한 단계는 무엇인가요? |
| 관련 프로젝트 | Relation | 이 일이 어떤 큰 결과에 연결되나요? |
혼자 쓰는 데이터베이스라면 담당 속성이 불필요해 보일 수 있습니다. 이때는 담당 대신 ‘실행 환경’을 넣어도 좋습니다. 예를 들어 컴퓨터, 전화, 외출, 15분 작업처럼 실제 행동 장소를 구분할 수 있습니다.
중요한 기준은 입력하지 않을 속성을 만들지 않는 것입니다. 우선순위, 예상 시간, 에너지 수준, 비용, 채널, 검토자 같은 속성은 실제로 필터나 정렬에 사용할 때만 추가합니다.
상태는 많을수록 정확해지는 것이 아닙니다
상태값은 업무 흐름을 보여주는 핵심 속성이지만, 단계가 너무 많으면 매번 어디에 놓을지 고민하게 됩니다. 개인 업무라면 다음 네 단계로도 충분합니다.
- Inbox: 아직 정리하지 않은 입력입니다.
- Ready: 조건이 갖춰져 바로 시작할 수 있습니다.
- Doing: 지금 실제로 진행하고 있습니다.
- Done: 완료 기준을 충족했습니다.
검토와 승인이 꼭 필요한 팀이라면 Review를 추가할 수 있습니다. 콘텐츠 운영이라면 Draft, Edit, Scheduled 같은 흐름이 필요할 수 있습니다.
다만 상태값은 역할이 달라질 때만 늘려야 합니다. ‘거의 완료’, ‘조금 남음’, ‘다시 확인’처럼 감정이나 진행률을 표현하는 상태가 많아지면 보드가 판단을 대신하지 못합니다.
하나의 원본 데이터베이스에 여러 뷰를 만듭니다
업무 목록, 오늘 할 일, 이번 주 캘린더, 프로젝트별 보드를 각각 다른 데이터베이스로 만들 필요는 없습니다. 같은 원본에 필터와 정렬을 달리한 뷰를 만들면 됩니다.
Notion의 뷰·필터·정렬 공식 문서는 각 뷰가 독립적인 설정을 가질 수 있다고 설명합니다. 한 뷰에서 숨긴 속성이나 적용한 필터가 다른 뷰에 자동으로 적용되는 것은 아닙니다.
실무에서는 아래 정도로 나누면 충분합니다.
- Inbox 뷰: 상태가 Inbox인 항목만 보여줍니다.
- 오늘 뷰: 날짜가 오늘 이전이고 Done이 아닌 항목을 보여줍니다.
- 이번 주 캘린더: 날짜 속성을 기준으로 일정을 봅니다.
- 진행 보드: 상태별로 그룹화해 병목을 확인합니다.
- 완료 기록: Done만 모아 최신 완료 순으로 정렬합니다.
이렇게 하면 항목 하나를 수정했을 때 모든 화면이 함께 바뀝니다. 복사된 목록을 여러 군데에서 따로 관리하는 문제도 줄어듭니다.
운영 원칙: 새 화면이 필요할 때 데이터베이스를 먼저 복제하지 말고, 기존 원본에 새 뷰를 추가할 수 있는지부터 확인합니다.
템플릿은 속성보다 본문 반복에 사용합니다
데이터베이스 템플릿은 새 항목을 만들 때 반복되는 본문 구조와 기본값을 넣는 데 유용합니다. 회의록이라면 참석자·결정사항·후속 작업 섹션을, 콘텐츠라면 독자·검색 의도·근거 자료·검수 항목을 미리 넣을 수 있습니다.
반대로 템플릿마다 서로 다른 상태 속성이나 카테고리 속성을 새로 만들면 원본 구조가 흔들립니다. 속성은 데이터베이스 전체의 공통 언어이고, 템플릿은 특정 유형의 항목을 빠르게 시작하게 해주는 양식으로 나누는 편이 좋습니다.
반복 업무에는 Notion의 반복 데이터베이스 템플릿을 사용할 수 있습니다. 주간 회고, 월간 정산, 월요일 계획처럼 일정한 주기로 새 페이지가 필요한 경우에 적합합니다.
다만 자동 생성된 페이지가 다른 자동화를 다시 실행시킬 것이라고 가정하면 안 됩니다. Notion 데이터베이스 자동화 공식 안내는 자동화가 만든 페이지나 반복 템플릿이 다른 데이터베이스 자동화를 작동시키지 않는 경우를 설명합니다. 또한 데이터베이스 자동화의 생성·편집은 요금제와 권한 조건을 확인해야 합니다.
프로젝트와 업무는 Relation으로 나눕니다
프로젝트 이름을 모든 업무에 텍스트로 적으면 철자와 표현이 조금씩 달라집니다. 프로젝트 자체의 상태, 목표일, 담당자를 함께 관리하기도 어렵습니다.
이때 프로젝트 데이터베이스와 업무 데이터베이스를 분리하고 Relation으로 연결할 수 있습니다. Notion의 Relation과 Rollup 안내에 따르면 Relation은 서로 다른 데이터베이스 항목을 연결하고, Rollup은 연결된 항목의 값을 집계합니다.
예를 들어 다음 구조를 만들 수 있습니다.
- 프로젝트 데이터베이스: 프로젝트명, 목표일, 상태, 책임자
- 업무 데이터베이스: 업무명, 상태, 날짜, 다음 행동, 관련 프로젝트
- Relation: 각 업무가 어느 프로젝트에 속하는지 연결
- Rollup: 프로젝트별 전체 업무 수, 완료 업무 수, 가장 늦은 날짜 집계
Rollup은 연결된 숫자나 날짜를 합계·평균·최솟값·최댓값 등으로 보여줄 수 있습니다. 다만 집계를 많이 붙이기 전에 실제 의사결정에 쓰는 숫자인지 확인해야 합니다.
프로젝트 페이지에서 완료율을 매일 보지 않는다면 복잡한 수식보다 ‘남은 업무 수’ 하나가 더 유용할 수 있습니다.
복사한 템플릿은 데이터 없이 시험합니다
Notion은 데이터베이스를 복제할 때 콘텐츠를 포함하거나 구조만 복제할 수 있습니다. 기존 예시 데이터가 많으면 구조를 이해하기 쉬운 대신, 무엇이 샘플이고 무엇이 내 업무인지 섞이기 쉽습니다.
새 템플릿을 가져왔다면 실제 업무를 전부 옮기기 전에 시험용 항목 세 개만 넣어보는 편이 좋습니다.
- 오늘 끝낼 수 있는 작은 업무 하나를 넣습니다.
- 일주일 이상 걸리는 프로젝트 업무 하나를 넣습니다.
- 날짜가 없고 나중에 판단할 Inbox 항목 하나를 넣습니다.
- 각 항목이 오늘 뷰, 보드, 캘린더에서 의도대로 보이는지 확인합니다.
- 한 번도 쓰지 않은 속성을 제거합니다.
- 같은 정보를 두 번 입력하게 만드는 부분을 찾습니다.
이 테스트를 통과하지 못한 상태에서 기존 업무 수백 개를 옮기면 정리 비용이 더 커집니다. 템플릿의 완성도보다 세 가지 실제 사례가 자연스럽게 흐르는지가 중요합니다.
콘텐츠 운영 예시로 보면 구조가 선명해집니다
콘텐츠를 관리한다고 가정하면 한 데이터베이스에 Topic, Status, Publish Date, Channel, Next Action, Campaign 정도를 둘 수 있습니다. 같은 원본으로 아이디어 수집함, 작성 보드, 발행 캘린더, 채널별 목록을 만들면 됩니다.
새 글을 쓸 때는 콘텐츠 템플릿을 적용해 독자, 검색 의도, 근거 자료, 내부 링크, 썸네일 점검 항목을 불러옵니다. 발행일이 되면 별도 캘린더로 옮기는 것이 아니라 같은 항목의 상태와 날짜만 바꿉니다.
이 구조는 1인 운영자를 위한 AI 콘텐츠 파이프라인에서 다룬 수집·기획·초안·편집·배포 흐름과도 연결됩니다. 자동화가 필요해지면 n8n과 Notion 연동 가이드처럼 원본 데이터베이스에 새 항목을 추가하는 방식으로 확장할 수 있습니다.
중심 데이터가 하나이면 자동화도 단순해집니다. 어느 보드에 쓸지 고민하는 대신, 원본에 쓰고 상태와 날짜를 기준으로 필요한 뷰에서 보이게 만들면 됩니다.
템플릿 복사 전 체크리스트
새 템플릿을 복사하기 전에 아래 질문에 답하면 버릴 속성과 남길 구조가 빨리 보입니다.
- 데이터베이스 한 줄은 정확히 무엇을 뜻하나요?
- 완료를 판단하는 기준은 무엇인가요?
- 같은 정보가 다른 페이지에도 중복 저장되나요?
- 속성 중 실제 필터·정렬·그룹에 쓰는 것은 무엇인가요?
- 원본 하나와 여러 뷰로 해결할 수 있나요?
- 프로젝트와 업무를 Relation으로 분리해야 하나요?
- 반복 템플릿이 필요한 주기가 실제로 있나요?
- 자동화 기능의 요금제와 권한 조건을 확인했나요?
- 시험 항목 세 개가 모든 뷰에서 자연스럽게 보이나요?
좋은 노션 템플릿은 처음부터 많은 것을 보여주는 템플릿이 아닙니다. 입력은 한 번만 하고, 필요한 순간에 다른 모습으로 꺼내 볼 수 있는 템플릿이 오래갑니다.