데이터베이스·기초2026.07.28읽기 24분

김지명 · SSOD 대표

노션 데이터베이스 완전 정복: 속성·보기·필터·관계형·롤업·수식 설계 가이드

노션 데이터베이스는 표가 아닙니다. 같은 데이터를 목적에 따라 다르게 짜고, 그 짠 모양에 이름을 붙여 용도를 확정하는 도구입니다. 재구성과 의미부여, 이 두 가지를 손에 익히는 순간 노션은 메모장에서 시스템으로 넘어갑니다. 7년간 30개 넘는 기업의 노션을 설계하며 확인한 분기점이 정확히 여기였습니다.

이 글은 다음 순서로 갑니다. 먼저 데이터베이스를 어떻게 나눌지 정하는 설계 원칙을 잡고, 속성 타입 선택 기준을 짚습니다. 그다음 보기 8종과 필터·정렬·그룹으로 화면을 만드는 방법을 다루고, 관계형·롤업·수식으로 데이터베이스끼리 잇는 단계로 넘어갑니다. 마지막은 템플릿·자동화·권한, 그리고 데이터가 쌓였을 때 생기는 문제와 대응입니다. 처음 만드는 단계라면 위에서부터, 이미 쓰고 있다면 막힌 지점부터 골라 읽으셔도 됩니다. 노션 자체가 처음이라면 노션 사용법 익히는 순서을 먼저 훑고 오시는 편이 빠릅니다.

모든 것의 두 축: 재구성과 의미부여

노션 데이터베이스를 제대로 쓰는 사람과 메모장처럼 쓰는 사람의 차이는 기능 숙련도가 아닙니다. 두 가지 행위를 의식하느냐입니다.

재구성은 같은 데이터를 목적에 맞게 다시 짜는 일입니다. 필터로 걸러내고, 정렬로 순서를 바꾸고, 속성을 켜고 끕니다. 데이터는 그대로입니다. 보는 각도만 바뀝니다.

의미부여는 그렇게 짠 보기에 새 제목을 다는 일입니다. 고객 데이터베이스에서 미팅 상태가 '완료'인 것만 걸러 수수료 합계를 켜면, 그 화면은 더 이상 '고객 목록'이 아닙니다. '완료 고객 수수료 현황'입니다. 제목을 바꾸는 순간 그 보기의 용도가 확정됩니다.

정육면체를 어디서 보느냐

정육면체를 떠올려 보시면 이해가 빠릅니다. 정면에서 보면 사각형, 꼭짓점 방향에서 보면 육각형입니다. 도형 자체, 그러니까 본질은 변하지 않습니다. 보는 방향만 다를 뿐입니다. 쏘드는 이걸 데이터 다각화라고 부릅니다.

엑셀에 익숙한 사람일수록 이 감각이 낯섭니다. 엑셀은 가로행 세로열 평면에 셀마다 값을 박아 넣는 방식이라, 보고 싶은 각도가 생길 때마다 시트를 복사하고 데이터를 다시 붙여넣게 됩니다. 원본이 바뀌면 복사본은 어긋납니다. 노션은 원본 하나에 여러 보기를 얹습니다. 원본을 고치면 모든 보기에 즉시 반영됩니다. 같은 데이터를 캘린더로도, 보드로도, 갤러리로도 동시에, 복제 없이 봅니다.

쪼갤 것인가 합칠 것인가: 설계의 첫 단추

노션을 처음 만지는 사람이 가장 많이 하는 실수가 데이터베이스를 잘게 쪼개는 것입니다. 할 일을 관리하는데 담당자별로 홍길동 DB, 김철수 DB, 김영희 DB를 따로 만듭니다. 이러면 관리 지점이 세 배로 늘고, 전체를 한눈에 볼 방법이 사라집니다. 월별로 나누는 경우도 마찬가지입니다. 12월이 되면 데이터베이스가 열두 개입니다.

원칙은 반대입니다. 카테고리가 같으면 하나의 큰 데이터베이스로 두고 필터로 나눕니다. '할 일' DB 하나에 담당자를 속성으로 넣고, 담당자별로 필터링하면 끝입니다. 홍길동의 할 일이 필요하면 필터 하나, 김철수가 필요하면 필터 하나. 원본은 언제나 하나입니다.

그래도 분리해야 하는 네 가지 신호

무조건 합치라는 뜻은 아닙니다. 아래 중 하나에 해당하면 분리를 검토합니다.

속성 구성이 절반 이상 다를 때. 고객과 채용 지원자를 한 DB에 담으면 서로 쓰지 않는 빈 칸이 절반씩 생깁니다.
접근 권한이 다를 때. 급여 정보와 프로젝트 일정은 볼 수 있는 사람이 다릅니다. 비즈니스 플랜 이상이라면 행 단위로 접근을 가를 수 있지만, 한 행이 열리면 그 행의 속성은 전부 함께 보입니다. 같은 행에 있으면 안 되는 항목이 섞여 있다면 데이터베이스를 나눕니다.
수명 주기가 완전히 다를 때. 매일 쌓이는 상담 기록과 분기에 한 번 갱신되는 계약 정보는 다루는 리듬이 다릅니다.
한쪽이 다른 쪽의 부속일 때. 프로젝트와 그 안의 할 일은 관계형으로 잇는 편이 낫습니다. 한 DB에 섞으면 집계가 어긋납니다.

업무 단위를 어떻게 끊을지 자체가 고민이라면 노션 업무 모듈화 쪽을 함께 보시면 기준이 잡힙니다.

설계 순서

데이터베이스를 만들기 전에 이 순서를 밟습니다.

필요 정의. 이 DB로 무엇을 보고 싶은지 문장으로 씁니다. "이번 주에 마감인 내 할 일", "미팅이 끝난 고객의 수수료 합계"처럼 구체적일수록 좋습니다.
입력 데이터 정리. 어떤 항목이 반복해서 쌓이는지 나열합니다.
속성 설계. 1번에서 쓴 문장을 만들려면 어떤 속성이 있어야 하는지 역산합니다. "이번 주 마감"을 보려면 날짜 속성이, "내 할 일"을 보려면 사람 속성이 있어야 합니다.

특히 상태·분류·담당자 같은 속성에 라벨을 붙여두는 일이 핵심입니다. 책에 목차와 색인이 있어야 원하는 페이지를 찾듯, DB에 구조가 있어야 원하는 정보를 꺼내 가공할 수 있습니다. 잘 규격화된 DB는 나중에 관계를 맺고 자동화를 얹을 때 그 가치가 드러납니다.

속성 설계: 무엇을 어떤 타입으로 담을까

속성 타입을 잘못 고르면 나중에 필터도, 집계도, 자동화도 걸리지 않습니다. 데이터를 넣기 전에 한 번 정리해 두는 편이 비용이 훨씬 쌉니다.

속성 타입	담는 값	쓰는 자리
제목	페이지 이름	모든 DB에 하나씩 있고 삭제할 수 없습니다
텍스트	자유 문장	메모·비고처럼 집계하지 않는 값
숫자	수치	금액·수량. 통화나 퍼센트 형식을 지정합니다
선택	값 하나	유형·등급처럼 항목이 고정된 분류
다중 선택	값 여러 개	태그처럼 겹쳐 붙는 분류
상태	진행 단계	할 일·진행 중·완료 세 그룹으로 묶여 관리됩니다
날짜	날짜와 기간	시작과 종료를 한 속성에 담고 알림도 겁니다
사람	워크스페이스 구성원	담당자·검토자
파일과 미디어	첨부	계약서·이미지
체크박스	참·거짓	완료 여부처럼 값이 둘뿐인 항목
URL·이메일·전화번호	연락 정보	눌러서 바로 연결됩니다
수식	계산 결과	다른 속성을 재료로 값을 만들어냅니다
관계형	다른 페이지 연결	데이터베이스를 잇습니다
롤업	연결된 페이지의 값	관계형이 먼저 있어야 씁니다
생성 일시·생성자·최종 편집 일시·최종 편집자	자동 기록	입력하지 않아도 노션이 채웁니다
ID	자동 증가 번호	접두어를 붙여 문서 번호로 씁니다
버튼	동작	누르면 페이지 생성이나 속성 변경이 실행됩니다

선택과 상태를 구분해서 씁니다

둘 다 목록에서 하나를 고르는 속성이지만 성격이 다릅니다. 선택은 평면 목록입니다. 상태는 옵션이 할 일·진행 중·완료 세 그룹 아래에 묶입니다. 그래서 상태 속성을 쓰면 "완료 그룹에 든 것만" 같은 조건을 옵션 이름 대신 그룹 기준으로 걸 수 있습니다. 나중에 '검수 대기'라는 단계를 추가해도 그룹만 맞춰 두면 기존 필터가 깨지지 않습니다.

진행 단계를 다루는 속성은 상태로, 변하지 않는 분류는 선택으로 두는 것이 기본입니다. 고객의 '등급'은 선택, 계약의 '진행 단계'는 상태입니다.

분류를 텍스트로 입력하지 않습니다

가장 흔하고 가장 늦게 발견되는 실수입니다. 분류를 텍스트 속성에 손으로 적으면 '진행중', '진행 중', '진행중 ', '진행'이 전부 다른 값이 됩니다. 필터는 조용히 몇 건씩 빠뜨리고, 그룹은 같은 뜻의 칸을 네 개로 쪼갭니다. 항목이 반복되는 값이라면 예외 없이 선택이나 상태로 둡니다. 옵션을 나중에 추가하는 편이, 흩어진 텍스트를 뒤늦게 통일하는 것보다 훨씬 쌉니다.

자동으로 채워지는 속성을 활용합니다

생성 일시, 생성자, 최종 편집 일시는 사람이 입력하지 않아도 노션이 기록합니다. "최근 2주간 손대지 않은 건"처럼 방치된 항목을 잡아내는 필터를 이 속성으로 만듭니다. ID 속성은 자동으로 번호를 붙이고 접두어를 지정할 수 있어, 견적서 번호나 문의 접수 번호처럼 사람이 부르는 식별자로 쓰기 좋습니다.

보기 8가지와 어울리는 데이터

노션은 하나의 데이터베이스를 여덟 가지 보기로 보여줍니다. 데이터 성격에 맞는 보기를 고르는 것이 화면 설계의 출발점입니다.

보기	어울리는 데이터	대표 용도
표	속성이 많고 전체를 훑어야 하는 데이터	원본 관리 화면의 기본값
보드	상태·담당자처럼 단계로 나뉘는 데이터	칸반식 진행 관리
캘린더	날짜가 핵심인 데이터	미팅·마감·발행 일정
타임라인	기간이 있는 데이터	프로젝트 시작과 종료를 가로 막대로
갤러리	이미지가 중요한 데이터	명함·포트폴리오·제품
리스트	제목만으로 충분한 데이터	회의록·문서 모음
차트	숫자를 그림으로 볼 데이터	상태별 건수, 월별 합계
피드	최근 기록의 흐름	업무 일지, 공지

같은 고객 데이터라도 미팅 일정을 볼 땐 캘린더, 프로필 사진을 훑을 땐 갤러리, 진행 단계를 관리할 땐 보드를 씁니다. 데이터는 하나입니다.

보기마다 있는 전용 설정

보기를 고른 뒤에는 그 보기에만 있는 설정을 맞춰야 화면이 정돈됩니다.

보드: 어떤 속성으로 열을 나눌지 정합니다. 상태별·담당자별이 흔합니다. 열 아래에서 수수료 합계 같은 값을 집계할 수도 있습니다.
캘린더·타임라인: 어느 날짜 속성에 연결할지 고릅니다. 날짜 속성이 여러 개면 '마감일 기준 캘린더'와 '미팅일 기준 캘린더'를 따로 만들 수 있습니다. 이렇게 만든 캘린더를 구글 캘린더와 실제로 동기화하는 방법은 노션 구글캘린더 연동 3가지에서 다룹니다.
타임라인: 표시 단위를 시간부터 분기까지 확대·축소합니다. 왼쪽에 표를 붙여 속성을 함께 보는 설정도 있습니다.
갤러리: 카드 미리보기를 페이지 커버, 페이지 콘텐츠, 특정 파일 속성 중에서 고릅니다. 회사 로고 속성을 카드 이미지로 띄우는 식입니다.
표: 열 너비, 줄바꿈 여부, 페이지 열기 방식(사이드 팝업·전체 화면)을 정합니다.

링크된 데이터베이스 보기

대시보드를 만들 때 가장 자주 쓰게 되는 기능입니다. 원본 데이터베이스는 한 곳에 두고, 다른 페이지에서 그 원본을 불러와 필터와 정렬을 따로 건 보기를 얹습니다. 데이터를 복제하는 것이 아니라 같은 원본을 다른 각도로 비추는 것이라, 원본이 바뀌면 모든 자리에 반영됩니다.

대시보드에 원본 데이터베이스를 그대로 끌어다 놓는 경우를 자주 보는데, 이러면 누군가 대시보드에서 필터를 바꿨을 때 원본 화면까지 함께 바뀝니다. 대시보드에는 링크된 보기를 얹고, 필요하면 보기를 잠가 다른 사람이 설정을 건드리지 못하게 합니다.

필터·정렬·그룹으로 화면을 만듭니다

필터

필터는 단순합니다. 원하는 데이터만 보여주고 나머지는 숨깁니다. 고객 데이터에서 미팅 상태가 '완료'인 사람만 보고 싶다면 '상태 = 완료'를 겁니다. 보드에서 진행 중인 사람만, 갤러리에서 특정 분류의 카드만, 타임라인에서 수수료 30만 원 이상만. 보기 종류와 상관없이 같은 방식으로 걸립니다.

조건을 여러 개 걸 때는 AND와 OR을 섞을 수 있고, 필터 그룹으로 묶어 중첩합니다. "담당자가 나이면서, (상태가 진행 중이거나 마감일이 이번 주 안)"처럼 괄호가 필요한 조건을 이 방식으로 만듭니다.

날짜 필터에는 오늘·이번 주·지난 30일 같은 상대 조건이 있습니다. 이걸 쓰면 날짜를 손으로 고칠 일이 없어집니다. 고정 날짜로 걸어둔 필터는 다음 달이면 아무것도 걸러내지 못합니다.

정렬

오름차순과 내림차순 두 가지이고, 여러 개를 순서대로 겹칠 수 있습니다. 1차로 상태, 2차로 마감일을 걸면 상태 안에서 마감이 임박한 순으로 정렬됩니다. 갤러리나 캘린더가 어수선할 때 정렬 하나로 카드가 가지런해집니다.

그룹화

그룹화는 데이터를 접었다 펼 수 있는 덩어리로 묶습니다. 보드는 그룹화가 화면 구조 자체이지만, 표·리스트·갤러리·타임라인에서도 그룹을 걸 수 있습니다. 표 보기에서 담당자로 그룹을 걸면 담당자별 소계가 각 덩어리 아래에 붙습니다. 보드에서는 하위 그룹까지 걸어 상태와 담당자를 격자로 볼 수 있습니다.

계산 행

표 보기의 각 열 아래에는 계산 칸이 있습니다. 개수, 합계, 평균, 비어 있지 않은 값의 비율 같은 값을 즉시 얻습니다. 그룹을 걸어두면 그룹마다 소계가 따로 나옵니다. 이 하나로 별도 집계 시트가 필요 없어지는 경우가 많습니다.

의미부여: 보기에 이름을 붙이는 순간

여기서부터가 노션 사고법의 진짜입니다. 필터·정렬·속성 켜고 끄기로 데이터를 재구성했다면, 그 보기에 새 이름을 붙여 의미부여를 합니다.

고객 데이터베이스를 캘린더 보기로 바꾸고, '약속 대상' 속성을 켜고, 데이터베이스 원래 이름을 숨깁니다. 그리고 이 보기에 '약속 리스트'라는 제목을 답니다. 그 순간 같은 데이터가 더 이상 고객 명부가 아니라 약속 일정표가 됩니다.

몇 가지 예를 나란히 놓아 보겠습니다.

미팅 날짜 7월 + 표 보기 + 지원 회사만 표시 → '지원 회사 내역'
상태별 보드 + 수수료 합계 → '진행 상태별 매출'
미팅 상태 완료 + 수수료 합계 → '완료 고객 수수료 현황'

재구성한 보기에 목적에 맞는 이름을 붙이는 순간, 하나의 데이터가 여러 개의 도구로 갈라집니다. 반대로 '표', '표 1', '보기 2' 같은 기본 이름을 그대로 두면 다음 주에 그 화면을 왜 만들었는지 잊습니다. 이름은 그 보기의 사용 설명서입니다.

업무 동선에 맞춰 보기를 구성합니다

보기를 많이 만드는 것보다, 사람이 실제로 움직이는 순서대로 만드는 편이 중요합니다. 아침에 노션을 열었을 때 손이 가는 화면부터 정합니다.

사람 기준: '내 할 일'은 담당자가 나이고 상태가 완료가 아닌 조건입니다. 각자 자기 화면을 따로 만들 필요가 없습니다.
시간 기준: '오늘 마감', '이번 주', '지연'을 상대 날짜 필터로 만듭니다. 지연은 마감일이 오늘 이전이면서 상태가 완료가 아닌 조건입니다.
상태 기준: '검토 대기'처럼 다음 사람이 받아 가야 하는 단계만 모읍니다. 업무가 넘어가는 지점이 보이면 병목도 보입니다.
정리 기준: 종료된 건은 기본 화면에서 빼고 '완료 보관' 보기에만 남깁니다.

이렇게 만든 보기들을 한 페이지에 링크된 보기로 모아 두면 업무 시작 화면이 됩니다. 여러 데이터베이스에서 각각 '오늘 할 일'만 뽑아 한 페이지에 얹는 구성도 같은 방식입니다.

관계형: 데이터베이스를 잇는 다리

여기서부터가 메모장과 시스템을 가르는 진짜 분기점입니다. 데이터베이스를 따로 쓰면 메모, 연결하면 시스템입니다. 세 기능을 한 문장으로 외워두면 됩니다. 관계형으로 이어주고, 롤업으로 모아주고, 수식으로 판단합니다.

관계형은 두 데이터베이스를 잇습니다. '프로젝트'와 '할 일'을 관계형으로 묶으면, 할 일에서 프로젝트를 고르고 프로젝트에서 그 할 일 목록을 봅니다. 고객과 계약, 프로젝트와 할 일이 서로를 들여다보게 만드는 다리입니다.

양방향과 단방향

관계형을 만들 때 상대 데이터베이스에도 대응 속성을 표시할지 고를 수 있습니다. 표시하면 양방향이라 한쪽에서 연결한 내용이 반대쪽에도 똑같이 생깁니다. 표시하지 않으면 단방향이고, 연결한 쪽에서만 보입니다.

기본은 양방향입니다. 프로젝트에서 할 일을 봐야 하고, 할 일에서 프로젝트를 봐야 하기 때문입니다. 단방향은 참조용 데이터베이스를 붙일 때 씁니다. 예를 들어 여러 DB가 공통으로 참조하는 '거래처 마스터' 같은 경우, 거래처 쪽에 연결 속성이 계속 늘어나면 화면이 지저분해집니다.

연결 개수 제한

관계형은 연결할 페이지 개수를 하나로 제한하거나 제한 없이 둘 수 있습니다. 할 일 하나가 반드시 프로젝트 하나에만 속해야 한다면 제한을 1개로 걸어 둡니다. 입력 단계에서 실수를 막고, 롤업 결과가 흔들리지 않습니다.

자기 참조와 하위 항목

같은 데이터베이스 안에서 상위와 하위를 잇는 하위 항목 기능이 있습니다. 큰 할 일 아래에 세부 할 일을 접어 넣는 구조입니다. 타임라인에는 선후 관계를 잇는 종속성 기능이 따로 있어, 앞 작업이 밀리면 뒤 작업 막대가 함께 밀리게 설정할 수 있습니다.

계층이 두세 단계를 넘어가면 화면이 복잡해집니다. 하위 항목으로 감당이 안 되는 깊이라면 데이터베이스를 나누고 관계형으로 잇는 편이 낫습니다.

관계형으로 둘지, 선택 속성으로 둘지

가장 자주 받는 질문입니다. 판단 기준을 표로 정리했습니다.

판단 기준	선택·다중 선택으로	관계형으로
그 값 자체에 딸린 정보가 필요한가	필요 없습니다	연락처·주소·이력이 따라붙습니다
항목이 계속 늘어나는가	거의 고정입니다	계속 추가됩니다
반대쪽에서도 조회하는가	하지 않습니다	양쪽에서 서로를 봅니다
집계가 필요한가	그룹화와 계산 행으로 충분합니다	롤업으로 합계·개수를 냅니다
유지 비용	낮습니다	연결을 계속 관리해야 합니다

정리하면 이렇습니다. 등급·유형처럼 이름만 있으면 되는 값은 선택으로 둡니다. 담당 거래처처럼 그 대상에 연락처와 거래 이력이 붙어야 하는 값은 관계형으로 뺍니다. 애매할 때는 "이 값을 클릭해서 열어볼 일이 있는가"를 물어보시면 됩니다. 열어볼 것이 있으면 관계형입니다.

롤업: 이어진 값을 모으기

롤업은 관계로 이어진 상대 DB의 값을 끌어와 모읍니다. 프로젝트에 연결된 할 일이 몇 개인지 세고, 그중 완료가 몇 개인지, 지연이 몇 개인지 집계합니다. 돋보기를 상대 DB에 갖다 대는 것에 가깝습니다.

롤업을 만들려면 세 가지를 지정합니다. 어느 관계형을 통해서(관계), 상대의 어느 속성을(속성), 어떻게 계산할지(계산)입니다. 관계형 속성이 없으면 롤업은 만들 수 없습니다.

계산 방식	결과
원본 표시	연결된 페이지의 값을 그대로 나열합니다
고유값 표시	중복을 지우고 나열합니다
전체 개수 / 값 개수 / 고유값 개수	세는 대상이 각각 다릅니다
비어 있음·비어 있지 않음 개수와 비율	입력 누락을 잡아냅니다
합계·평균·중앙값·최솟값·최댓값·범위	숫자 속성에만 걸립니다
가장 이른 날짜·가장 늦은 날짜·기간	날짜 속성에만 걸립니다

롤업에서 자주 어긋나는 지점

'값 개수'와 '전체 개수'를 헷갈려 숫자가 안 맞는 경우가 가장 많습니다. 값이 비어 있는 항목까지 셀지 말지에 따라 결과가 달라집니다.

롤업 위에 롤업을 다시 얹는 다단 구조도 조심해야 합니다. 계산이 몇 단계를 거치면 어느 단계에서 값이 틀어졌는지 추적하기 어려워집니다. 중간 단계의 판정을 수식 속성으로 한 번 고정해 두면 검증이 쉬워집니다.

수식: 모은 값으로 판단하기

수식은 모은 값으로 판단을 내립니다. 할 일이 완료면 1, 아니면 0을 반환하는 수식, 마감일이 지났는데 시작 전이면 '지연'으로 표시하는 수식을 만듭니다. 이 값을 상위 프로젝트에서 롤업으로 합치면, 지연 비율이 과반을 넘는 프로젝트를 자동으로 '위험'으로 띄울 수 있습니다.

실무에서 반복해서 쓰게 되는 계산 유형은 대략 이 정도입니다.

경과일과 남은 일수: 두 날짜 사이의 간격을 구해 '접수 후 며칠', 'D-3' 같은 값을 만듭니다.
조건부 라벨: 마감일과 상태를 함께 보고 정상·임박·지연을 판정합니다.
완료 플래그: 상태가 완료면 1, 아니면 0. 상위에서 롤업으로 합치면 완료 건수가 나옵니다.
비율: 완료 건수를 전체 건수로 나눠 진척률을 냅니다. 분모가 0일 때를 반드시 따로 처리합니다.
표시 문구 조합: 여러 속성을 이어 붙여 카드에 한 줄로 보여줍니다.

수식이 다룰 수 있는 것과 없는 것

수식은 계산 결과만 표시하는 속성입니다. 사람이 값을 직접 입력할 수 없고, 재료가 되는 속성이 바뀌면 결과도 따라 바뀝니다. 수식 결과에 손으로 예외를 넣고 싶다면 별도 속성을 하나 두고 수식이 그 속성을 참고하게 만들어야 합니다.

노션 수식이 개편되면서 달라진 점도 있습니다. 수식을 여러 줄로 쓰고 중간값에 이름을 붙일 수 있게 됐고, 관계형으로 연결된 페이지의 속성을 수식 안에서 직접 다룰 수 있게 됐습니다. 결과 타입은 문자, 숫자, 참·거짓, 날짜, 사람, 페이지 목록으로 나뉘고 타입이 맞지 않으면 오류가 납니다. 날짜를 문자와 그냥 이어 붙이면 안 되고 형식을 지정해 문자로 바꿔야 하는 이유가 여기 있습니다.

수식을 짤 때 지킬 것

조건을 한 수식 안에 계속 덧붙이면 어느 지점에서 틀어졌는지 찾기 어려워집니다. 중간 판정을 별도 속성으로 빼두면 각 단계를 눈으로 확인할 수 있고, 나중에 다른 사람이 넘겨받기도 쉽습니다. 수식 하나가 화면을 넘어가기 시작하면 쪼갤 시점이라고 보시면 됩니다.

작성 자체가 막힐 때는 노션 AI에 원하는 계산을 말로 설명해 수식을 받아볼 수 있습니다. 다만 받은 수식은 반드시 실제 데이터에서 결과를 확인하고 쓰셔야 합니다. 조건이 조금만 복잡해져도 그럴듯하지만 틀린 수식이 나옵니다. 검색·에이전트·MCP 연동까지 노션 AI 활용법 전반은 노션 AI 완전 가이드에서 이어 볼 수 있습니다.

템플릿: 입력 규격을 미리 박아둡니다

데이터베이스 템플릿은 새 항목을 만들 때 속성 값과 페이지 본문을 미리 채워 넣습니다. 회의록 템플릿에 안건·결정사항·후속 작업 골격을 넣어두면, 회의 때마다 누가 만들어도 같은 형태의 기록이 남습니다.

템플릿이 실제로 하는 일은 시간 절약이 아니라 규격 유지입니다. 사람마다 다른 방식으로 적기 시작하면 그 데이터베이스는 반년 뒤에 집계가 불가능해집니다.

보기마다 기본 템플릿을 지정할 수 있어서, '영업 보기'에서 항목을 추가하면 영업용 서식이, '지원 보기'에서 추가하면 지원용 서식이 뜨게 만들 수 있습니다. 반복 설정을 걸어 주간 회의록처럼 정해진 주기로 항목이 생기게 하는 것도 가능합니다.

자동화와 API가 올라서는 토대

관계와 수식까지 짜인 데이터베이스는 자동화의 출발선이 됩니다. 버튼 하나로 상태를 '완료'로 바꾸면 상위 프로젝트의 완료율이 즉시 갱신되고, 정해진 시간에 지연된 항목을 시스템이 읽어 표시하게 둘 수도 있습니다. 여기에 외부 연동을 붙이면 지연 건만 골라 슬랙이나 텔레그램으로 알림이 나가게 만듭니다.

실제로 1년간 함께한 한 노무·세무 전문 법인은 상태값과 진행 경과일을 기준으로 고객에게 맞춤 알림 문자가 나가도록 세팅한 뒤 접수율이 두 배가 됐습니다. 여기서 일한 것은 알림 도구가 아닙니다. 그 알림을 가능하게 한 규격화된 DB입니다. 데이터가 일정한 규칙으로 정리돼 있어야 자동화도, AI도 그 위에 얹힙니다. 토대가 흔들리면 그 위에 무엇을 올려도 무너집니다.

노션 안에서 걸 수 있는 자동화와 외부 도구를 붙이는 자동화의 경계는 노션 자동화 완전 가이드에서, 실제 워크플로를 짜는 절차는 노션 + n8n 자동화 실전 가이드에서 이어 보실 수 있습니다.

API로 다룰 때 알아둘 제약

외부 도구를 붙이기로 했다면 미리 알아둬야 몇 시간을 아낍니다.

항목	내용
한 번에 가져오는 개수	요청당 최대 100건입니다. 그 이상은 커서를 받아 이어서 요청합니다
요청 빈도	평균 초당 3회 수준으로 제한됩니다
수식·롤업 값	읽기만 됩니다. 외부에서 값을 써 넣을 수 없습니다
접근 범위	통합을 페이지에 연결해 줘야 그 하위에만 접근합니다
텍스트 길이	텍스트 한 덩어리에 담기는 글자 수에 상한이 있어, 긴 본문은 나눠 보내야 합니다
하위 블록	페이지 안의 중첩된 블록은 단계별로 따로 요청해 받습니다

수식과 롤업이 읽기 전용이라는 점이 설계에 영향을 줍니다. 외부에서 값을 넣어야 하는 항목이라면 수식이 아니라 일반 속성으로 두고, 계산은 노션 안에서 하거나 외부에서 계산한 결과를 일반 속성에 기록하는 구조로 잡습니다.

규모가 커지면 생기는 문제와 대응

데이터가 쌓이면 처음엔 없던 문제가 생깁니다. 보기를 여는 데 시간이 걸리고, 필요한 항목이 스크롤 아래로 사라지고, 오래전에 만든 필터가 지금은 아무것도 걸러내지 못합니다.

대응은 대체로 이런 순서입니다.

기본 보기에 필터를 먼저 겁니다. 완료된 건과 오래된 건을 기본 화면에서 뺍니다. 전체가 필요할 때만 '전체' 보기를 엽니다.
보기마다 표시 속성을 줄입니다. 원본 표에는 속성이 스무 개여도, 일하는 화면에는 대여섯 개면 충분합니다.
롤업 단계를 줄입니다. 계산이 겹칠수록 화면이 무거워지고 확인도 어려워집니다.
보관 기준을 정합니다. 종료된 건을 다른 데이터베이스로 옮기면 연결해 둔 관계형이 끊깁니다. 대개는 옮기지 않고 상태와 필터로 걸러내는 편이 안전합니다.

가장 비싼 문제는 속도가 아니라 규격입니다. 초기에 분류를 텍스트로 받았거나 담당자를 이름 문자열로 적어뒀다면, 데이터가 수천 건 쌓인 뒤에 고치는 비용이 처음의 몇십 배가 됩니다. 항목이 백 건을 넘기기 전에 속성 구조를 한 번 점검하시는 편을 권합니다.

멀티소스 데이터베이스와 권한

노션은 멀티소스 데이터베이스로 데이터베이스의 근간을 바꿨습니다. 예전엔 블록 하나에 데이터베이스 하나였습니다. 이제는 한 블록 안에서 보기를 누를 때마다 서로 다른 원본 데이터베이스로 전환됩니다. '메모' 탭을 누르면 메모 DB, '태그' 탭을 누르면 태그 DB가 같은 블록에서 열립니다. 대시보드를 만들 때 보기 이름을 일일이 바꾸고 제목을 숨기던 수고가 줄어듭니다.

다만 권한을 함께 생각해야 합니다. 노션에서 데이터베이스 권한은 그 데이터베이스가 놓인 페이지의 권한을 따르고, 하위 페이지가 이를 상속합니다. 권한은 블록 단위로 부여되므로, 민감한 데이터는 같은 블록에 묶지 말고 분할해 관리해야 합니다. 자동화를 정교하게 설계할 때도 블록 하나에 데이터베이스 하나를 유지하는 편이 안전합니다.

링크된 보기를 다른 페이지에 얹어도 원본 접근 권한이 없는 사람에게는 내용이 보이지 않습니다. 대시보드를 만들었는데 누군가에게만 빈 화면이 뜬다면 대부분 원본 권한 문제입니다.

한 문장으로 줄이면 이렇습니다. 페이지는 단정하게, 맥락은 한 화면에서, 권한 부여는 신중하게.

자주 보는 잘못된 설계와 대안

지금까지 다룬 내용을 실패 패턴 쪽에서 다시 정리했습니다. 하나라도 짚이면 그 부분부터 손보시면 됩니다.

자주 보는 설계	무슨 일이 생기는가	대안
담당자별·월별로 DB를 나눔	전체를 한 화면에서 볼 수 없고 관리 지점이 배로 늘어납니다	하나로 두고 필터와 그룹으로 나눕니다
분류를 텍스트로 입력	표기가 조금만 달라도 필터에서 빠집니다	선택이나 상태로 옵션을 고정합니다
같은 값을 두 DB에 각각 입력	한쪽만 고쳐져 조용히 어긋납니다	관계형으로 잇고 롤업으로 가져옵니다
보기 이름을 기본값 그대로 둠	무엇을 위한 화면인지 곧 잊습니다	목적을 이름으로 박아둡니다
대시보드에 원본 DB를 직접 넣음	누가 필터를 바꾸면 원본 화면까지 바뀝니다	링크된 보기를 얹고 보기를 잠급니다
민감 항목을 권한이 다른 데이터와 한 행에 담음	행을 가려도 열린 행의 속성은 전부 보입니다	민감 항목을 별도 DB로 떼어냅니다
수식 하나에 조건을 계속 덧붙임	오류 지점을 찾지 못합니다	중간 판정을 별도 속성으로 분리합니다
고정 날짜로 필터를 걸어둠	다음 달이면 아무것도 걸러내지 못합니다	오늘·이번 주 같은 상대 조건을 씁니다

노션 데이터베이스의 기준은 결국 두 단어로 돌아옵니다. 재구성과 의미부여. 같은 데이터를 목적에 맞게 다시 짜고, 그 모양에 이름을 붙여 용도를 확정하는 감각입니다. 속성 타입을 고르는 일도, 관계형을 걸지 말지 정하는 일도, 뷰를 몇 개 만들지 정하는 일도 결국 이 두 가지로 수렴합니다.

이 감각이 손에 붙으면 템플릿을 사지 않아도, 페이지가 산더미처럼 쌓여도 원하는 정보를 언제든 꺼내 쓰는 시스템을 직접 만들게 됩니다. 메모장 노션은 여기서 끝납니다.

지금 쓰는 데이터베이스가 이 글에서 짚은 실수 위에 서 있는지 궁금하다면, 컨설팅 신청으로 구조를 보내 주세요. 어디부터 손대야 하는지 확인해 드립니다.