데이터베이스는 질문에 답해야 한다
지난 장에서 만든 '업무 관리' 데이터베이스는 아직 단순한 목록에 가깝다. 업무명, 상태, 마감일, 우선순위 정도만 있어도 기록은 가능하지만, 업무가 늘어나면 금방 복잡해진다.
이때 필요한 것이 속성, 보기, 필터다.
속성은 각 항목을 설명하는 기준이다. 보기는 같은 데이터를 다른 화면으로 보여주는 방식이다. 필터는 전체 데이터 중에서 지금 필요한 것만 남기는 조건이다. 이 세 가지를 조합하면 데이터베이스는 지저분한 목록이 아니라 다음 질문에 답하는 도구가 된다.
오늘 내가 해야 할 일은 무엇인가?
진행 중인 업무만 보면 무엇이 남았는가?
이번 주 안에 마감되는 항목은 무엇인가?
담당자별로 일이 얼마나 나뉘어 있는가?
고객별로 다음 연락일이 지난 건은 없는가?
좋은 데이터베이스는 많은 정보를 담는 곳이 아니다. 필요한 순간에 필요한 정보만 꺼내 볼 수 있는 구조다.
AI 생성 이미지
속성은 항목을 설명하는 기준이다
노션 데이터베이스의 각 항목은 하나의 페이지다. 속성은 그 페이지에 붙는 정보표라고 생각하면 쉽다. 업무 항목 하나를 예로 들면 다음과 같다.
| 업무명 | 상태 | 마감일 | 우선순위 | 담당자 |
|---|---|---|---|---|
| 제안서 초안 작성 | 진행 중 | 6월 20일 | 높음 | 민수 |
여기서 '제안서 초안 작성'은 항목의 제목이고, 상태·마감일·우선순위·담당자는 속성이다. 이 속성들이 있어야 나중에 필터를 걸고, 정렬하고, 보드나 캘린더로 바꿔 볼 수 있다.
처음부터 속성을 많이 만들 필요는 없다. 다만 어떤 속성이 어떤 상황에 맞는지는 알아두는 것이 좋다.
한 가지를 먼저 구분해두자. 속성 이름과 속성 유형은 다르다. 예를 들어 '담당자'는 우리가 붙인 속성 이름이고, 실제 유형은 노션 워크스페이스 멤버를 지정하는 '사람' 속성일 수 있다. '마감일'도 속성 이름이고, 유형은 '날짜'다. 이 차이를 알면 데이터베이스를 만들 때 훨씬 덜 헷갈린다.
기본 속성 유형을 업무 예시로 이해하기
업무 관리에서 자주 쓰는 속성 유형은 텍스트, 숫자, 선택, 다중 선택, 상태, 날짜, 사람, 체크박스다. 이름만 보면 비슷해 보이지만 역할이 다르다.
| 속성 유형 | 어울리는 정보 | 예시 |
|---|---|---|
| 텍스트 | 짧은 설명이나 메모 | 요청 배경, 참고 메모 |
| 숫자 | 계산하거나 비교할 수 있는 값 | 예상 소요 시간, 예산, 수량 |
| 선택 | 하나만 골라야 하는 분류 | 우선순위: 높음·보통·낮음 |
| 다중 선택 | 여러 개가 동시에 붙을 수 있는 태그 | 채널: 블로그·뉴스레터·SNS |
| 상태 | 업무 흐름 단계 | 할 일·진행 중·검토·완료 |
| 날짜 | 일정과 마감 | 마감일, 회의일, 발행일 |
| 사람 | 워크스페이스 안의 담당자 | 담당자, 검토자, 승인자 |
| 체크박스 | 예/아니오로 끝나는 표시 | 결재 필요, 확인 완료 |
텍스트 속성은 자유롭게 적는 칸이다. 하지만 너무 중요한 정보를 텍스트에만 넣으면 나중에 정리하기 어렵다. 예를 들어 우선순위를 텍스트로 "급함", "중요", "빨리"처럼 제각각 적으면 필터링이 힘들다. 반복해서 분류할 정보라면 선택 속성으로 만드는 편이 낫다.
숫자 속성은 계산 가능성이 있을 때 쓴다. 예상 소요 시간을 숫자로 넣어두면 이번 주 업무량을 대략 볼 수 있다. 예산, 수량, 점수처럼 크고 작음을 비교해야 하는 정보도 숫자가 적합하다.
선택 속성은 하나의 답만 필요할 때 쓴다. 우선순위는 보통 하나만 정하면 된다. '높음', '보통', '낮음'처럼 옵션을 제한하면 사람마다 다른 표현을 쓰는 문제를 줄일 수 있다.
다중 선택 속성은 여러 태그를 붙일 때 쓴다. 하나의 콘텐츠가 '블로그'이면서 'SNS'에도 쓰일 수 있다면 다중 선택이 맞다. 다만 태그가 너무 많아지면 정리가 아니라 소음이 된다. 실제로 자주 묶어 보는 기준만 남기는 것이 좋다.
상태 속성은 업무의 흐름을 보여줄 때 유용하다. 단순 선택과 비슷하지만, 할 일·진행 중·완료처럼 단계가 있는 작업에 더 잘 맞는다. 보드 보기와 함께 쓰면 칸반 보드처럼 업무 흐름을 한눈에 볼 수 있다.
날짜 속성은 마감일, 시작일, 회의일처럼 시간과 연결된 정보에 쓴다. 날짜가 있어야 캘린더 보기에서 확인할 수 있고, "이번 주 마감" 같은 필터도 만들 수 있다.
사람 속성은 워크스페이스 안의 멤버를 지정할 때 쓴다. 업무 데이터베이스에서는 이 속성의 이름을 '담당자', '검토자', '승인자'처럼 붙이는 경우가 많다. 팀원이 함께 쓰는 데이터베이스라면 사람 속성이 있어야 "내가 맡은 일"이나 "민수가 담당한 일"처럼 걸러 볼 수 있다.
체크박스 속성은 단순한 확인용이다. "고객에게 공유 완료", "세금계산서 발행 완료"처럼 예/아니오로 끝나는 정보에 적합하다. 진행 단계를 체크박스 여러 개로 쪼개기 시작하면 보기 어려워질 수 있으므로, 업무 흐름은 상태 속성으로 관리하는 편이 더 안정적이다.
연락처와 CRM에는 다른 속성이 필요하다
업무 관리가 내부 실행을 위한 데이터베이스라면, 연락처나 CRM은 사람과 회사 정보를 다루는 데이터베이스다. CRM은 고객, 파트너, 거래처와의 관계를 관리하는 목록이라고 이해하면 된다.
이런 데이터베이스에는 사람, 파일과 미디어, URL, 이메일, 전화번호 속성이 자주 쓰인다.
| 속성 유형 | 사용 예시 | 주의할 점 |
|---|---|---|
| 사람 | 내부 담당자, 협업자 | 노션 워크스페이스 멤버를 지정할 때 적합 |
| 파일과 미디어 | 제안서, 계약서, 견적서 | 최종본과 초안을 구분할 이름 규칙 필요 |
| URL | 회사 홈페이지, 참고 링크 | 링크만 모으지 말고 용도를 함께 적기 |
| 이메일 | 고객 이메일, 대표 메일 | 복사와 연락에 편리 |
| 전화번호 | 고객 연락처, 회사 번호 | 국가번호나 내선 규칙을 정하면 좋음 |
여기서 중요한 점은 내부 담당자와 고객 이름을 구분하는 것이다. 노션의 사람 속성은 보통 워크스페이스 안의 멤버를 지정할 때 쓴다. 예를 들어 "이 고객사는 지현이 관리한다"라고 할 때 '내부 담당자'라는 이름의 사람 속성에 지현을 넣는다.
반면 고객사의 실제 연락 담당자는 텍스트, 이메일, 전화번호 속성으로 관리하는 편이 자연스럽다. 고객이 우리 노션 워크스페이스 멤버가 아니라면 사람 속성에 넣을 수 없기 때문이다. 예를 들어 CRM 데이터베이스는 다음처럼 구성할 수 있다.
| 회사명 | 내부 담당자 | 고객 이름 | 이메일 | 전화번호 | 단계 | 다음 연락일 | 제안서 |
|---|---|---|---|---|---|---|---|
| 한빛상사 | 지현 | 김도윤 | [email protected] | 010-0000-0000 | 제안 중 | 6월 18일 | 파일 첨부 |
이 구조가 있으면 "다음 연락일이 이번 주인 고객", "제안 중인 고객", "지현이 담당하는 고객"을 쉽게 골라 볼 수 있다.
보기는 같은 데이터를 다른 관점으로 보는 창이다
노션에서 보기를 바꾼다고 데이터가 복사되는 것은 아니다. 같은 데이터베이스를 표, 보드, 캘린더 등 다른 화면으로 보는 것이다.
예를 들어 '업무 관리' 데이터베이스 하나를 다음처럼 여러 보기로 만들 수 있다.
| 보기 | 적합한 상황 |
|---|---|
| 표 보기 | 속성을 한꺼번에 확인하고 수정할 때 |
| 보드 보기 | 상태별 진행 흐름을 볼 때 |
| 캘린더 보기 | 마감일과 일정을 날짜 중심으로 볼 때 |
| 리스트 보기 | 복잡한 속성 없이 할 일 목록처럼 볼 때 |
표 보기는 가장 기본적인 보기다. 속성을 빠르게 입력하고, 여러 항목을 비교하기 좋다. 처음 데이터베이스 구조를 만들 때는 표 보기가 편하다.
보드 보기는 상태나 담당자처럼 그룹으로 나눌 수 있는 속성과 잘 맞는다. 상태별로 '할 일', '진행 중', '검토', '완료' 칸을 만들면 업무가 어디에 몰려 있는지 보인다.
캘린더 보기는 날짜 속성이 있을 때 힘을 발휘한다. 마감일이 있는 업무, 발행 일정, 회의 일정, 고객 연락일을 달력 위에서 확인할 수 있다.
중요한 것은 보기마다 목적을 정하는 것이다. 모든 보기에 모든 속성을 다 보여줄 필요는 없다. 오늘 할 일 보기에는 업무명, 마감일, 우선순위 정도면 충분하다. 전체 관리 보기에는 담당자, 상태, 링크, 파일까지 보여줘도 된다.
필터, 정렬, 그룹은 함께 써야 힘이 난다
데이터베이스가 커지면 보기만 바꿔서는 부족하다. 이때 필터, 정렬, 그룹을 함께 사용한다.
필터: 조건에 맞는 항목만 남긴다.
정렬: 남은 항목의 순서를 정한다.
그룹: 항목을 기준별로 묶어 보여준다.
예를 들어 "오늘 할 일" 보기를 만든다고 해보자. 전체 업무를 모두 보여주면 오늘 집중해야 할 일이 묻힌다. 이때 필터를 사용한다.
오늘 할 일 보기
조건은 이렇게 잡을 수 있다.
상태가 '완료'가 아니다.
마감일이 오늘이거나 오늘보다 이전이다.
담당자가 나다.
여기서 "오늘보다 이전"을 포함하는 이유가 중요하다. 마감일이 어제였지만 아직 끝내지 못한 일은 오늘도 봐야 한다. 필터를 "마감일이 오늘"로만 걸면 밀린 일이 사라져 버린다.
그다음 정렬을 추가한다.
마감일이 빠른 순서
우선순위가 높은 순서
이렇게 하면 오늘 봐야 할 일 중에서도 급한 일이 위로 올라온다.
진행 중 프로젝트 보기
진행 상황을 보려면 필터와 그룹을 다르게 쓴다.
필터: 상태가 '진행 중' 또는 '검토'
그룹: 담당자별 또는 상태별
정렬: 마감일 빠른 순서
팀에서 사용한다면 담당자별 그룹이 유용하다. 누가 어떤 일을 맡고 있는지 보이기 때문이다. 개인이 사용한다면 상태별 그룹이 더 편할 수 있다. 지금 시작만 한 일과 검토를 기다리는 일을 나눠 볼 수 있기 때문이다.
마감 임박 보기
마감 관리에는 날짜 필터가 핵심이다.
상태가 '완료'가 아니다.
마감일이 비어 있지 않다.
마감일이 오늘까지 지났거나, 오늘부터 7일 이내다.
마감일이 비어 있는 항목까지 섞이면 "임박"이라는 보기의 의미가 흐려진다. 날짜가 없는 업무는 별도 보기에서 관리하는 편이 낫다. 예를 들어 "마감일 미정" 보기를 만들어 주기적으로 확인하면 된다.
하나의 업무 데이터베이스를 여러 보기로 나누기
업무 데이터베이스를 여러 개 만들지 말고, 먼저 하나의 원본 데이터베이스를 잘 만들자. 그런 다음 목적별 보기를 추가한다.
추천 구조는 다음과 같다.
| 보기 이름 | 보기 형태 | 주요 조건 |
|---|---|---|
| 전체 업무 | 표 | 필터 없음 또는 보관 항목 제외 |
| 오늘 할 일 | 리스트 또는 표 | 담당자=나, 상태≠완료, 마감일≤오늘 |
| 진행 현황 | 보드 | 상태별 그룹 |
| 마감 캘린더 | 캘린더 | 날짜 속성=마감일 |
| 마감 임박 | 표 | 상태≠완료, 마감일 있음, 마감일≤7일 이내 |
이렇게 만들면 같은 업무를 여러 번 입력하지 않아도 된다. '제안서 초안 작성'이라는 항목 하나가 오늘 할 일에도 보이고, 진행 현황 보드에도 보이고, 마감 캘린더에도 나타난다. 원본은 하나이고, 보는 방식만 달라지는 것이다.
이 원리를 이해하면 노션이 훨씬 단순해진다. 데이터베이스를 많이 만드는 것이 실력이 아니라, 하나의 데이터베이스를 필요한 관점으로 나누어 보는 것이 핵심이다.
속성 이름과 옵션은 일관되게 정한다
데이터베이스가 지저분해지는 가장 흔한 이유는 기능 부족이 아니다. 이름이 제각각이기 때문이다.
예를 들어 완료 상태를 어떤 항목에는 '완료', 어떤 항목에는 '끝', 어떤 항목에는 'Done'으로 적으면 필터가 정확히 작동하지 않는다. 우선순위도 '높음', '긴급', '상', '중요'가 섞이면 나중에 정리하기 어렵다.
처음부터 단순한 규칙을 정하자.
상태: 할 일 / 진행 중 / 검토 / 완료
우선순위: 높음 / 보통 / 낮음
업무 유형: 기획 / 디자인 / 개발 / 운영 / 회의
날짜 이름: 마감일, 시작일, 발행일처럼 역할이 드러나게 쓰기
담당자: 내부 책임자를 지정할 때 사용하기
속성 이름도 짧고 분명해야 한다. '날짜'보다 '마감일'이 낫다. '사람'보다 '담당자'가 낫다. '링크'보다 '관련 링크'나 '홈페이지'가 낫다. 이름만 보고도 어떤 값을 넣어야 하는지 알 수 있어야 한다.
옵션은 적게 시작하는 것이 좋다. 태그와 선택값을 많이 만들면 처음에는 세밀해 보이지만, 시간이 지나면 관리가 어려워진다. 자주 필터링하거나 그룹으로 볼 기준만 옵션으로 남기자.
이 일관성은 나중에 자동화와 검색에서도 중요해진다. "상태가 완료가 되면 완료일을 기록한다" 같은 자동화를 만들려면 상태 이름이 일정해야 한다. 검색할 때도 같은 이름으로 정리된 속성이 훨씬 잘 찾아진다.
작은 실습: 업무 관리 데이터베이스 정리하기
이제 지난 장에서 만든 업무 관리 데이터베이스를 다음 구조로 다듬어보자.
| 속성 이름 | 속성 유형 | 예시 값 |
|---|---|---|
| 업무명 | 제목 | 제안서 초안 작성 |
| 상태 | 상태 | 할 일, 진행 중, 검토, 완료 |
| 마감일 | 날짜 | 2026년 6월 20일 |
| 우선순위 | 선택 | 높음, 보통, 낮음 |
| 담당자 | 사람 | 나 또는 팀원 |
| 예상 시간 | 숫자 | 2 |
| 확인 필요 | 체크박스 | 체크 또는 미체크 |
| 관련 링크 | URL | 참고 문서 링크 |
| 자료 | 파일과 미디어 | 제안서, 이미지, 첨부 파일 |
그다음 보기를 네 개 만든다.
전체 업무: 표 보기로 만들고 모든 속성을 확인한다.
오늘 할 일: 상태가 완료가 아니고, 마감일이 오늘 이전 또는 오늘인 항목만 보여준다.
진행 현황: 보드 보기로 만들고 상태별로 그룹화한다.
마감 캘린더: 캘린더 보기로 만들고 마감일 기준으로 표시한다.
이 정도만 만들어도 업무 데이터베이스는 훨씬 쓸모 있어진다. 전체 목록을 뒤지는 대신, 상황에 맞는 보기로 들어가면 된다.
아침에는 '오늘 할 일'을 보고, 회의 전에는 '진행 현황'을 보고, 주간 계획을 세울 때는 '마감 캘린더'를 보면 된다. 같은 데이터라도 보는 관점이 달라지면 행동이 달라진다.
정리: 데이터는 한곳에, 화면은 여러 개로
속성은 데이터를 정리하는 기준이다. 보기는 데이터를 바라보는 화면이다. 필터, 정렬, 그룹은 그 화면을 더 정확하게 만드는 장치다.
노션 데이터베이스를 잘 쓰려면 처음부터 거대한 시스템을 만들 필요가 없다. 업무명, 상태, 마감일, 우선순위처럼 핵심 속성부터 시작하면 된다. 그리고 오늘 할 일, 진행 중, 마감 임박처럼 실제로 자주 묻게 되는 질문에 맞춰 보기를 나누면 된다.
기억할 원칙은 하나다.
데이터는 한곳에 모으고, 필요한 화면은 여러 개로 만든다.
이 원칙을 지키면 노션 데이터베이스는 단순한 기록장이 아니라 매일 판단과 실행을 도와주는 작업 도구가 된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.