📋 목차
노션 CRM에서 가장 자주 받는 질문이 "데이터베이스를 어떻게 나눠야 하나요?"예요. 결론부터 말하면 클라이언트·프로젝트·인터랙션 3개로 분리하고 관계형(Relation) 속성으로 연결하는 게 정답이에요. 이 구조 하나만 잘 잡아도 노션 CRM의 7할은 끝나요.
사실 저도 처음에는 데이터베이스 하나로 다 하려고 했어요. 클라이언트랑 프로젝트를 한 테이블에 다 넣었거든요. 그게 왜 망하는지, 3개로 쪼개면 뭐가 좋은지, 그리고 관계형이랑 롤업(Rollup)을 어떻게 활용해야 하는지 차근차근 풀어드릴게요.
참고로 이 글은 노션 처음 쓰는 분보다는 기본 사용법은 아는데 데이터베이스 구조 잡는 게 막막한 분들 대상이에요. 관계형이 뭔지 모르겠다 싶으면 노션 공식 도움말의 "관계형 및 롤업" 가이드를 먼저 읽고 오시는 걸 추천해요.
왜 데이터베이스를 3개로 쪼개야 할까
단일 DB로 가면 처음엔 깔끔해 보여요. 회사명, 담당자, 프로젝트명, 미팅일, 견적금액… 한 줄에 다 들어가니까 "한눈에 보인다"는 착각이 들거든요. 근데 클라이언트가 10명을 넘어가면 진짜 지옥이에요.
예를 들어 A회사랑 프로젝트 3개를 진행 중이라고 해볼게요. 단일 DB에서는 A회사가 3번 등장해야 해요. 회사명·담당자·연락처를 똑같이 세 번 입력해야 한다는 뜻이에요. 담당자 연락처가 바뀌면? 세 군데 다 수정해야 해요. 한 군데 빠뜨리면 데이터 무결성이 깨져요.
미팅 기록도 마찬가지예요. A회사랑 1년간 미팅 12번 했으면 단일 DB에서는 행이 12개로 폭증해요. 정렬·필터링이 누더기가 되죠. 이걸 데이터베이스 정규화라고 하는데, 어려운 용어 같지만 그냥 "중복 줄이려고 테이블을 나누는 것"이에요.
📊 실제 데이터
클라이언트 60명 + 프로젝트 80건 + 인터랙션 400건 규모를 단일 DB로 운영했을 때 노션 페이지 로딩 시간이 평균 4~6초까지 늘어졌어요. 같은 데이터를 3개 DB로 분리한 직후에는 1초 이내로 떨어졌고요. 단순히 깔끔함의 문제가 아니라 실제 사용성에 직결돼요.
3개로 분리하는 기준은 명확해요. "한 행이 무엇 하나를 의미하는가"를 기준으로 잡으면 돼요. 클라이언트 DB의 한 행은 회사 하나, 프로젝트 DB의 한 행은 일감 하나, 인터랙션 DB의 한 행은 접점 하나. 이 원칙만 지키면 헷갈릴 일이 없어요.
클라이언트 DB 설계 디테일
클라이언트 DB는 가장 적은 속성으로 가야 해요. 한 회사에 대한 "기본 정보"만 담는 곳이라서요. 제가 운영하는 속성은 7개예요. 회사명(제목), 메인 담당자(텍스트), 상태(선택), 업종(선택), 다음 컨택일(날짜), 메모(텍스트), 프로젝트(관계형).
담당자 연락처나 이메일은 속성으로 안 빼요. 페이지 안 본문에 적어요. 왜냐하면 한 회사에 담당자가 여러 명일 수도 있고, 사람이 바뀔 수도 있거든요. 속성으로 빼면 그때마다 구조를 손봐야 하는데, 본문에 쓰면 그냥 줄 추가하면 끝나요.
상태 속성은 클라이언트의 생애주기를 표현해요. 저는 5단계로 잡아요. 리드(처음 연락 옴) → 미팅 예정 → 견적 진행 → 계약(거래 활성) → 종료. 컬러는 시각적 직관을 위해 회색·파랑·노랑·초록·빨강 순서로 배치해요. 칸반 뷰로 봤을 때 흐름이 자연스러워요.
| 속성명 | 타입 | 역할 |
|---|---|---|
| 회사명 | 제목 | 고유 식별자 |
| 상태 | 선택 | 생애주기 5단계 |
| 다음 컨택일 | 날짜 | 팔로업 트리거 |
| 프로젝트 | 관계형 | 프로젝트 DB 연결 |
| 업종 | 선택 | 세그먼트 분석 |
"다음 컨택일" 속성은 진짜 보물이에요. 미팅 끝날 때마다 "2주 뒤" 식으로 적어두면, 대시보드에서 "이번 주에 연락해야 할 곳" 뷰가 자동 생성돼요. 영업 안 놓치는 비결의 90%가 이 속성 하나에서 나와요. 강력 추천해요.
프로젝트 DB 설계 디테일
프로젝트 DB는 클라이언트 DB보다 속성이 조금 더 많아요. 일감 하나의 실제 진행 상황을 담는 곳이라서요. 제목, 클라이언트(관계형), 시작일, 마감일, 진행률, 견적금액, 결제상태, 담당자, 우선순위 정도로 잡아요.
견적금액은 숫자 속성으로 잡고 "통화" 형식으로 KRW를 설정하세요. 그러면 자동으로 천 단위 콤마가 찍히고, 데이터베이스 하단에서 합계 계산이 가능해져요. 월별 매출 추적할 때 엑셀 안 켜고 노션에서 바로 보니까 너무 편해요.
결제상태는 별도로 빼는 게 좋아요. 진행률(완료 여부)이랑 결제(돈이 들어왔는지)는 다른 차원이거든요. 작업은 끝났는데 결제가 안 들어온 케이스가 의외로 많아요. "미청구 → 청구함 → 입금완료 → 세금계산서 발행" 4단계로 두면 미수금 추적이 깔끔해져요.
💡 꿀팁
진행률 속성은 "선택"보다 "숫자"로 만들고 "막대" 형식으로 표시하는 걸 추천해요. 0~100 사이 숫자를 입력하면 시각적으로 막대가 차오르거든요. 칸반 뷰랑 같이 쓰면 한눈에 어떤 프로젝트가 늘어지고 있는지 보여요.
마감일은 "오늘로부터 며칠 남았는지"를 보여주는 수식(Formula) 속성을 같이 만들어두면 좋아요. 수식은 dateBetween(prop("마감일"), now(), "days") 정도로 짜면 돼요. 마감일 3일 이내면 자동으로 빨갛게 표시되도록 조건부 서식까지 걸면 더 좋고요.
인터랙션 DB 설계 디테일
인터랙션 DB가 사실 진짜 핵심이에요. 클라이언트랑 주고받은 모든 접점을 기록하는 곳이거든요. 미팅·통화·이메일·메신저 다 들어와요. 한 접점당 한 행. 속성은 날짜, 유형(선택), 클라이언트(관계형), 프로젝트(관계형), 요약, 다음 액션.
유형 속성은 미팅, 통화, 이메일, 메신저, 기타 5가지로 두면 충분해요. 굳이 화상·대면 이렇게 세분화 안 해도 돼요. 처음에는 욕심 부려서 10가지로 나눴는데, 결국 안 쓰는 카테고리가 절반이더라고요.
"다음 액션" 속성이 인터랙션 DB의 알맹이예요. 미팅 끝날 때마다 "내일까지 견적서 발송"처럼 구체적으로 적어두는 거예요. 그리고 이걸 별도 To-do DB가 아니라 인터랙션 DB 안에서 관리하면 맥락이 살아 있어요. "왜 이걸 해야 하지?" 싶을 때 같은 행의 요약을 보면 바로 기억나거든요.
⚠️ 주의
인터랙션 DB의 "요약"은 본문에 길게 쓰지 말고 속성에 한 줄로 압축해야 해요. 본문에 회의록을 길게 적으면 데이터베이스 뷰에서 안 보이고, 검색도 느려져요. 회의록은 페이지 안 본문에, 핵심 요약은 속성에. 이게 원칙이에요.
한 가지 더. 인터랙션 DB는 "타임라인 뷰"로 보면 진짜 강력해요. 각 클라이언트별로 시간 흐름에 따라 어떤 일이 있었는지 한눈에 보이거든요. 6개월 뒤에 "이 사람이랑 마지막으로 뭘 얘기했더라" 싶을 때 5초 안에 찾아져요.
관계형과 롤업 실전 연결법
관계형(Relation) 속성은 두 데이터베이스를 연결해주는 다리예요. 프로젝트 DB에 "클라이언트"라는 관계형 속성을 만들면, 그 프로젝트가 어느 회사 건인지 연결돼요. 그리고 양방향 관계형으로 설정하면 클라이언트 DB에서도 그 회사의 프로젝트가 자동으로 떠요.
설정 방법은 간단해요. 프로젝트 DB에서 속성 추가 → "관계형" 선택 → 연결할 데이터베이스로 클라이언트 DB 지정 → "Notion 양방향 관계형" 토글을 켜요. 그러면 클라이언트 DB에도 자동으로 "프로젝트" 속성이 생겨요.
롤업(Rollup)은 한 단계 더 나가요. 관계형으로 연결된 다른 DB의 정보를 가져와서 계산해주는 기능이에요. 예를 들어 클라이언트 DB에 "총 매출" 롤업을 만들면, 그 회사의 프로젝트들 견적금액을 자동 합산해줘요. 클라이언트별 매출 순위가 0초 만에 나오는 거죠.
자주 쓰는 롤업 조합은 이런 거예요. 클라이언트 DB에 "진행 중 프로젝트 수"(프로젝트 DB의 개수 카운트), "총 누적 매출"(견적금액 합계), "마지막 인터랙션 날짜"(인터랙션 DB의 최신 날짜). 이 세 개만 추가해도 클라이언트별 상태가 한눈에 들어와요.
설계할 때 흔히 빠지는 함정
첫 번째 함정은 "관계형 속성을 양방향으로 안 거는 것"이에요. 단방향으로 걸면 한쪽 DB에서만 보여요. 양쪽에서 다 볼 수 있어야 진짜 가치가 나오니까, 관계형 만들 때 양방향 토글 꼭 확인하세요.
두 번째 함정은 "데이터베이스를 4개, 5개로 더 쪼개는 것"이에요. "회의록 DB도 따로 만들어야 하나?", "이메일 DB도?" 같은 욕심이 드는데, 3개 이상으로 가면 관리가 어려워져요. 회의록·이메일·통화는 다 인터랙션 DB 안에서 "유형" 속성으로 구분하는 게 깔끔해요.
세 번째 함정은 "기존 데이터 옮길 때 관계형을 안 거는 것"이에요. 엑셀에서 CSV로 가져온 직후에는 그냥 텍스트로만 들어와 있어요. 관계형 연결은 수동으로 다시 해줘야 해요. 50~100개 정도면 30분 정도 잡고 한 번에 끝내는 게 좋아요. 미루면 영영 안 해요.
자주 묻는 질문
Q. 데이터베이스를 한 페이지 안에 다 넣어야 하나요, 따로 페이지로 빼야 하나요?
각자 별도 페이지로 빼고, 대시보드 페이지에서 "링크드 뷰"로 불러오는 방식을 추천해요. 그래야 데이터베이스 본체가 무거워지지 않고, 대시보드는 가볍게 유지돼요.
Q. 관계형을 잘못 걸었는데 다시 풀 수 있나요?
관계형 속성을 삭제하면 연결도 같이 풀려요. 다만 이미 연결된 데이터는 복구가 안 되니까 신중하게요. 가능하면 관계형 삭제 전에 워크스페이스 백업을 먼저 해두세요.
Q. 롤업으로 계산한 숫자가 안 맞아요. 왜 그럴까요?
대부분은 관계형 양방향 토글이 꺼져 있거나, 롤업의 "계산" 설정이 합계가 아닌 다른 값으로 잡혀 있어요. 롤업 속성 클릭 후 계산 방식을 다시 확인해보세요.
Q. 한 프로젝트가 두 클라이언트랑 엮인 경우는 어떻게 처리하나요?
관계형 속성은 다중 선택이 가능해서 한 프로젝트에 클라이언트 여러 명 연결할 수 있어요. 다만 매출 정산이 복잡해지니까 가능하면 메인 클라이언트 하나만 걸고 협력사는 본문에 메모하는 방식을 추천해요.
Q. 처음 만들 때 속성을 한 번에 다 정해야 하나요?
아니에요. 핵심 5~7개로 시작하고 한 달 굴려보면서 진짜 필요한 속성만 추가하는 게 좋아요. 처음부터 완벽하게 설계하려고 하면 결국 시작도 못 해요.
본 포스팅은 개인 경험과 공개 자료를 바탕으로 작성되었으며, 전문적인 비즈니스·법률 조언을 대체하지 않습니다. 노션의 기능과 가격 정책은 수시로 변경될 수 있으니 공식 사이트에서 최신 정보를 확인하시기 바랍니다.
📎 함께 보면 좋은 글
노션 CRM, 더 깊이 들어가고 싶다면
아래 글들을 확인해보세요! 🙌
⚡ 자동화로 반복 업무 줄이고 싶다면
노션 자동화 + Make.com 연동 실전 세팅법📊 대시보드 디자인이 고민이라면
5초 안에 파악되는 노션 CRM 대시보드 4분할 전략🎁 무료 템플릿이 필요하다면
프리랜서 노션 CRM 무료 템플릿 5종 비교🏁 처음부터 큰 그림이 궁금하다면
Notion 클라이언트 관리 시스템 2년 운영 후기3개 DB 구조부터 자동화까지 한 번에
💡 본인 워크플로에 맞춰 하나씩 적용해보세요
결국 노션 CRM 데이터베이스 설계의 핵심은 "클라이언트·프로젝트·인터랙션 3개로 쪼개고 관계형 양방향으로 연결하는 것"이에요. 속성은 처음부터 욕심내지 말고 5~7개로 시작해서 한 달 굴려본 다음 진짜 필요한 것만 추가하세요. 롤업까지 활용하면 클라이언트별 매출이 자동으로 잡혀요.
이 글이 도움이 되셨다면 댓글로 본인의 노션 데이터베이스 설계 노하우도 공유해주세요. 다른 분들에게도 큰 도움이 됩니다 🙌
댓글 쓰기