개요
•
노션 컨설팅 프로젝트 3일차의 본격적인 데이터베이스 구축 세션
•
핵심 다루는 내용 6가지
◦
멤버 vs 게스트의 과금 구조와 권한 최적화
◦
품번, 품명, 색상, 사이즈 등 아이템 필드의 설계 원칙
◦
관계형 데이터베이스의 핵심 개념과 적용 기준
◦
태스크 자동 생성을 위한 자동화 설계
◦
리스프레드(재확산) 프로젝트의 매체별 트래킹 구조
◦
유튜브/인스타 조회수 자동 수집 방안
•
핵심 가치
◦
"왜 이 필드가 필요한가", "왜 이 데이터베이스를 분리해야 하는가"에 대한 실시간 의사결정 과정
◦
단순 구축 튜토리얼이 아닌, 비즈니스 요구사항을 데이터 구조로 번역하는 컨설턴트의 사고 과정
주요 학습 포인트
•
멤버 과금 함정: 노션 "멤버로 업그레이드" 클릭 시 월 $25/인 과금, 건너뛰기로 게스트 초대 필수
•
필드명 확정의 중요성: 자동화 연결 후 필드명 변경 시 전체 시스템 꼬임, 초기 확정 필수
•
관계형 맺기 기준: "이 데이터를 가공했을 때 의미가 있나?"로 판단
•
태스크 자동 생성: 프리 태스크 템플릿 + 버튼 클릭으로 N개 아이템에 동시 태스크 생성
•
상태값 순환 버튼: 클릭할 때마다 시작 전 → 진행 중 → 컨펌 대기 → 완료로 순환
•
조회수 자동 수집: 유튜브는 기본 API로 가능, 인스타는 Apify($29/월) 필요
요약
1. 멤버 vs 게스트: 과금 구조 최적화
핵심 원칙: 멤버는 "내 자식"처럼 돈을 내고 있는 것, 게스트는 "남남". 노션 AI가 필요한 핵심 인원만 멤버로 유지
•
발견된 문제
◦
기존 워크스페이스에 19명의 멤버 존재
◦
비즈니스 계정 $25/인 × 19명 = 월 $475 (약 62만 원)
◦
실제 청구서 확인: 월 31만 원 (플러스 계정)
◦
대부분 멤버일 필요가 없는 인원
•
멤버 vs 게스트 차이점
구분 | 멤버 | 게스트 |
과금 | 인당 $25/월 | 무료 |
노션 AI | 사용 가능 | 사용 불가 |
통합 검색 | 가능 | 제한적 |
편집 권한 | 전체 | 페이지별 지정 |
초대 권한 | 가능 | 편집 허용 시 불가 |
•
멤버 초대 시 주의사항
◦
노션 초대 시 "멤버로 업그레이드" 버튼 표시
◦
절대 클릭 금지 → "건너뛰기"를 눌러야 게스트 초대
◦
예전에는 파란색 버튼이어서 실수 다발, 지금은 회색이지만 여전히 함정
•
권한 정리 실행
◦
19명 중 실제 멤버 필요: 4명 (대표, 팀장 2명, HR 담당)
◦
나머지 15명: 멤버 제거 → 게스트로 재초대
◦
1월 17일부터 추가 청구 중단
◦
월 비용: $475 → $100 이하로 절감
2. 프로젝트 데이터베이스 설계
•
프로젝트 구조 확정
◦
연간 12개 프로젝트 (월 1회 킥오프)
◦
각 프로젝트는 3개월간 병렬 진행
◦
프로젝트 유형: 에센셜, 빌드, 리빌드
•
프로젝트 필드 구성
필드명 | 유형 | 설명 |
프로젝트명 | 제목 | 예: 2월 에센셜 워드로브 |
라인 | 선택 | 에센셜/빌드/리빌드 |
기한 | 날짜 | 프로젝트 시작~종료 기간 |
•
라인 구분을 선택 속성으로 한 이유
◦
대표님 질문: "데이터베이스로 분리해야 하지 않나요?"
◦
컨설턴트 결정: 선택 속성으로 유지
◦
빌드/리빌드/에센셜은 1년에 각각 몇 번인지 카운트해도 의미 있는 데이터 아님
◦
관계형 연결 시 속도 저하 비용 발생
◦
의미 있는 가공 데이터가 없으면 선택 속성으로 충분
3. 아이템 데이터베이스 설계
•
핵심 논의: 품번 체계
◦
품번 예시: BFP303B
위치 | 예시 | 의미 |
1번째 | B | 브랜드 (빌드) |
2번째 | F | 계절 (Fall/가을) |
3번째 | P | 품목 (Pants/바지) |
4-6번째 | 303 | 일련번호 |
7번째 | B | 컬러 코드 |
•
계절 코드 규칙
◦
F: Fall (가을)
◦
W: Winter (겨울)
◦
S: Spring (봄)
◦
M: suMmer (여름)
•
품목 코드 규칙
◦
100번대: 아우터
◦
200번대: 탑
◦
300번대: 니트
◦
400번대: 셔츠
◦
500번대: 티셔츠
◦
600번대: 원피스
•
아이템 필드 구성
필드명 | 유형 | 설명 |
품번 | 제목 | 고유 식별자 |
품명(상품명) | 텍스트 | 고객 노출용 명칭 |
매입처 | 관계형 | 공장 데이터베이스 연결 |
프로젝트 | 관계형 | 소속 프로젝트 |
라인 | 롤업 | 프로젝트에서 자동 가져옴 |
•
필드명 확정의 중요성
◦
컨설턴트 반복 강조 핵심 원칙
◦
"필드명은 한번 정할 때 잘 정하는 게 중요"
◦
자동화 연결 후에는 필드명 변경 불가
◦
변경 시 전체 시스템 꼬임
4. 서브 아이템 데이터베이스 설계
•
왜 서브 아이템이 필요한가?
◦
대표님 질문: "색상과 사이즈를 아이템의 속성(필드)으로 추가하면 안 되나요?"
◦
컨설턴트 답변
▪
노션 데이터베이스는 엑셀처럼 칸을 늘리는 개념 아님
▪
필드는 고정, 값이 변하는 건 행(레코드)으로 적층
▪
색상이 2개인 아이템도 있고 4개인 아이템도 존재
▪
필드 확장 불가 → 다른 데이터베이스를 연결하여 행으로 추가
•
색상 코드 논의
◦
현재 상태: 99개의 색상 코드 (멜란지 그레이, 라이트 베이지 등 세분화)
◦
대표님 제안: "멜란지 그레이나 그레이나 코드는 같게 쓰면 안 돼요?"
◦
논의 결과
▪
한 옷에 다크 베이지와 라이트 베이지 동시 존재 없음
▪
베이지 계열 모두 '베이지' 코드로 통일 가능
▪
코드 변경 시 바코드까지 변경해야 했던 비효율 해소
▪
99개 → 10개 이내로 축소 가능
•
사이즈 체계
◦
상의: 55, 66, 77, 88, 99, 100
◦
하의: 26, 28, 30, 32, 34, 36
◦
새로운 빌드 사이즈 체계: BS, BM, BF, B1, B2, B3, B4
•
서브 아이템 필드 구성
필드명 | 유형 | 설명 |
서브 아이템명 | 제목 | 예: 블랙 BS |
아이템 | 관계형 | 상위 아이템 연결 |
색상 | 선택 | 블랙/화이트/아이보리/네이비 |
사이즈 | 선택 | BS/BM/BF/B1~B4 |
아소트 수량 | 숫자 | 초도 생산 수량 |
•
서브 아이템 자동 생성 계획
◦
아이템당 최대 색상 4개 × 사이즈 7개 = 28개 서브 아이템
◦
수동 입력 불가능 → 자동화 필수
◦
아이템에서 색상과 사이즈 선택 → "서브 생성" 버튼 클릭 → 선택된 조합만큼 자동 생성
5. 태스크 데이터베이스 설계
•
업무 프로세스 정의
순서 | 태스크명 | 담당 팀 |
1 | 마케팅 리서치 | 마케팅 |
2 | 스타일링 리서치 | 마케팅, 디자인, 웹비주얼 |
3 | 리서치 미팅 | 전체 |
4 | 기획 | 디자인 |
5 | 기획 미팅 | 전체 |
6 | 아이템 선정 | 디자인 |
7 | 디자인 | 디자인 |
8 | 샘플 | 생산 |
9 | 샘플 퀄리티 미팅 | 디자인, 생산, 마케팅 |
10 | 수정 | 마케팅, 생산 |
11 | 생산 발주 | 생산 |
12 | 입고 | 생산 |
13 | 스타일링 | 디자인, 마케팅, 스타일 |
14 | 촬영 | 스타일, 웹비주얼 |
15 | 상세 페이지 제작 | 웹비주얼 |
16 | 상품 등록 | 웹비주얼 |
17 | 프로모션 | 마케팅, 스타일, 웹비주얼 |
•
핵심 논의: 아이템별 날짜가 다른가?
◦
대표님: "10개 아이템이 있으면 각각 날짜가 다 달라요?"
◦
팀장님: "거의 비슷하게 투입되는데, 원단/공정 문제 발생 시 조금 늦게 투입되는 상품 발생"
◦
결론
▪
초기 입력: 모든 아이템에 동일한 날짜로 일괄 생성
▪
이슈 발생 시: 해당 아이템만 타임라인에서 드래그로 조정
•
태스크 자동 생성 전략
◦
프리 태스크 템플릿
▪
태스크명, 담당 팀, 기간 미리 정의
▪
버튼 클릭 시 모든 아이템에 태스크 일괄 생성
▪
아이템 10개 × 태스크 17개 = 170개 레코드 자동 생성
◦
크레딧 소모
▪
Make 기본 플랜: 월 10,000 크레딧
▪
예상 소모: 500~600 크레딧/프로젝트
▪
월 10개 프로젝트도 충분히 커버
•
상태값 설계
상태 | 색상 | 설명 |
시작 전 | 옅은 회색 | 초기 상태 |
진행 중 | 노란색 | 작업 시작 |
컨펌 대기 | 주황색 | 상위자 확인 필요 |
완료 | 파란색 | 작업 종료 |
•
버튼 설계 논의
◦
옵션 1: 상태 순환 버튼 (클릭할 때마다 다음 상태로)
◦
옵션 2: 상태별 개별 버튼 (진행 중, 컨펌 대기, 완료 각각)
◦
팀장님 의견: "창을 열어서 선택하는 것조차 어려운 사람들이 있어요"
◦
결론: 순환 버튼 채택 - 한 자리에서 클릭만으로 상태 변경
•
히스토리 기록
◦
착수 일시: 진행 중으로 변경 시 자동 기록
◦
종료 일시: 완료로 변경 시 자동 기록
◦
한 번 기록되면 상태가 바뀌어도 날짜 유지
◦
실수 시 수동 삭제 후 재입력 가능
6. 관계형 데이터베이스 핵심 개념
핵심 원칙: "관계형은 뼈를 주고 살을 취하는 것. 의미 있는 데이터를 가공하기 위해 속도를 희생. 의미 없으면 그냥 선택 속성으로"
•
컨설턴트의 관계형 강의
◦
영상의 하이라이트
◦
대리님이 "관계형이 뭐예요?" 질문 시 약 10분간 설명한 내용
•
기본 개념: 데이터베이스 합치기
◦
멤버 DB: 아이디, 이름, 전화번호
◦
프로덕트 DB: 상품ID, 상품명, 가격
◦
세일즈 DB (두 DB 합쳐서): 멤버, 상품, 수량
◦
"멤버랑 프로덕트를 합치면 어떤 고객이 어떤 상품을 샀는지 알 수 있음. 그게 세일즈"
•
고유값의 중요성
◦
관계형 연결에 고유값 필요
◦
이름? → 동명이인 존재 
◦
전화번호? → 변경 가능
◦
주민등록번호? → 저장 불가
◦
아이디 → 직접 만드는 고유값
◦
"그래서 품번이 중요. 품번이 아이템의 고유값"
•
관계형 맺기 기준
◦
핵심 질문: "이 데이터를 가공했을 때 의미가 있나?"
◦
도서관 예시
▪
라이브러리 DB (책 정보)
▪
카테고리 DB (경영, 자기계발 등)
▪
작가 DB
▪
출판사 DB
◦
카테고리 관계형: "내가 경영서를 몇 권 갖고 있지?" → 의미 있음 관계형 맺기 O
관계형 맺기 O◦
작가 관계형: "이 작가 책을 몇 권 갖고 있지?" → 의미 있음 관계형 맺기 O
관계형 맺기 O◦
출판사 관계형: "이 출판사 책을 몇 권 갖고 있지?" → 의미 없음 관계형 맺기 X
관계형 맺기 X•
관계형의 비용
◦
관계형을 맺을수록 속도 저하
◦
데이터 이동 통로를 뚫는 것, 통로 많아지면 느려짐
◦
2년 전에는 2차선밖에 안 됐지만, 지금은 5~10배 빨라짐
◦
그래도 물리적 한계 존재
•
엑셀과 데이터베이스의 차이
구분 | 엑셀 | 데이터베이스 |
데이터 적층 | 가로+세로 | 세로만 |
셀 병합 | 가능 | 불가능 |
피벗 테이블 | 만들어야 DB | 기본이 DB |
•
"엑셀은 셀 기반 프로그램. 셀 병합 이유는 보고용. 데이터베이스에서는 셀 병합 불필요. 보고용이 아니라 데이터 저장용"
•
올바른 데이터 적층 규칙
◦
무조건 세로로 적층
◦
셀 병합 금지
7. 매입처(공장) 데이터베이스
•
필요성 논의
◦
대표님: "공장별로 몇 개의 상품이 진행 중인지, 어떤 게 들어가 있는지 알면 좋겠어요"
◦
컨설턴트: "그러면 데이터베이스가 하나 더 필요. 아이템에 공장 필드가 있고, 그 공장별로 집계하려면 별도 DB로 분리 필요"
•
공장 데이터베이스 필드
필드명 | 유형 | 설명 |
공장명 | 제목 | 대깔, 솔거, 우성 등 |
담당 아이템 | 관계형 | 아이템 DB 연결 |
진행 중 | 롤업 | 현재 진행 중인 아이템 수 |
8. 리스프레드 데이터베이스 설계
•
리스프레드란?
◦
반응이 좋은 상품을 추가 프로모션하는 프로젝트
◦
트리거: 세라(Sera) 앱에서 주문율 2.7~3% 이상
◦
기간: 반응이 유지되는 동안
◦
목표: 기존 고객이 검증한 상품을 신규 고객에게 확산
•
현재 문제점
◦
트리거 시점을 아무도 모르고 지나감
◦
담당자 불명확
◦
프로세스는 있지만 실행이 안 됨
•
매체 종류
매체 | 담당자 | 성과 지표 |
인스타 피드 | 은지 | 조회수 |
인스타 릴스 | 은지 | 조회수 |
유튜브 쇼츠 | 이사님 | 조회수 |
유튜브 상품 영상 | 이사님 | 조회수 |
상세페이지 추가 | 웹비주얼 | 트래픽 |
큐레이션 변경 | 팀장 | - |
네이버 라이브 | 마케팅 | 조회수 |
•
리스프레드 필드 구성
필드명 | 유형 | 설명 |
아이템 | 관계형 | 대상 아이템 |
매체 | 선택 | 7개 매체 중 선택 |
상태 | 선택 | 시작 전/진행 중/컨펌 대기/완료 |
URL | URL | 콘텐츠 링크 |
•
의사결정 프로세스 설계
1.
세라에서 주문율 확인 (담당: 은지)
2.
기준 충족 시 노티 (슬랙 연동 예정)
3.
이사님이 매체 선택
4.
선택된 매체에 담당자 자동 배정
5.
콘텐츠 제작 → URL 입력
6.
트래킹 시작
9. 리스프레드 트래킹 데이터베이스
•
왜 별도 DB가 필요한가?
◦
대표님: "성과(조회수)를 리스프레드에 필드로 넣으면 안 돼요?"
◦
컨설턴트: "조회수는 날마다 변함. 날마다 쌓이는 데이터는 행(레코드)으로 적층 필요. 그래야 그래프로 시각화 가능"
•
트래킹 필드 구성
필드명 | 유형 | 설명 |
리스프레드 | 관계형 | 상위 리스프레드 연결 |
날짜 | 날짜 | 측정 일자 |
조회수 | 숫자 | 해당 일자 조회수 |
•
자동 수집 가능 여부
매체 | 자동 수집 | 비용 | 비고 |
유튜브 영상 | 100% | 무료 | 기본 API |
유튜브 쇼츠 | 가능 | 무료 | 기본 API |
인스타 릴스 | 가능 | $29/월 | Apify 필요 |
인스타 피드 | 가능 | $29/월 | Apify 필요 |
네이버 라이브 | 불가 | - | 수동 입력 |
•
Apify 설명
◦
인스타그램/메타의 API는 자주 변경, 직접 연동 시 유지보수 어려움
◦
Apify는 스크래핑 전문 서비스, API 변경 시 대응
◦
월 $29
◦
Make와 연동 가능
◦
조회수, 좋아요, 댓글 수 등 수집
•
트래킹 종료 조건
◦
상태가 "완료"가 되면 더 이상 조회수 수집 안 함
◦
계속 수집하면 Make 크레딧 소모
◦
완료 후에는 평균/최대/최소값만 상위로 롤업
10. 진척도 시각화
•
차트 뷰 활용
◦
태스크의 상태값을 차트로 시각화
▪
시작 전: 회색
▪
진행 중: 노란색
▪
컨펌 대기: 주황색
▪
완료: 파란색
◦
아이템별 진척도
▪
완료된 태스크 수 / 전체 태스크 수 × 100%
▪
프로그레스 바로 시각화
▪
예: "20개 중 8개 완료 = 40%"
•
D-day 표시
◦
기한 날짜 기준으로 남은 일수 계산
◦
노란색: 오늘
◦
빨간색: 기한 초과
◦
회색: 완료
11. 페이지 구성 방향
•
업무 프로세스대로 배치
◦
헤드헌팅 회사 사례를 보여주며 설명
◦
"페이지 구성은 업무 프로세스대로. 맨 위에서 업무 시작, 아래로 진행, 맨 아래에서 종료"
◦
예시 프로세스
1.
프로젝트 요청 접수
2.
이력서 생성
3.
1차 인터뷰
4.
2차 인터뷰
5.
연봉 협상
6.
계약 완료
•
유나이티드 디자이너스 적용
1.
프로젝트 킥오프
2.
리서치
3.
기획
4.
아이템 선정
5.
디자인
6.
샘플
7.
생산
8.
촬영
9.
등록
10.
프로모션
11.
(리스프레드)
12. AI 활용과 데이터 축적의 의미
•
헤드헌팅 회사 데모
◦
컨설턴트가 실제 구축한 헤드헌팅 시스템 데모
1.
JD(Job Description) 입력
2.
노션 AI가 JD 분석
3.
후보자 DB에서 적합한 인재 추천
4.
기존 2~3일 걸리던 작업이 10분으로 단축
◦
"이게 가능한 이유는 데이터가 노션에 쌓여 있기 때문. 회사 정보, 이력서 정보가 다 파싱되어 들어가 있음"
•
지금 해야 하는 이유
◦
"지금 늦었음. 일단 늦었고, 지금 해야 하는 건 노션에 데이터 쌓는 것"
◦
"그것도 AI가 잘 알아들을 수 있는 언어로 쌓는 것"
◦
마크다운 구조
▪
H1 사용 금지 (페이지 제목이 H1)
▪
H2, H3로 계층 구조
▪
불릿, 넘버링, 토글로 정보 정리
▪
일관된 필드명
•
미래 활용 시나리오
◦
"나중에는 ERP에서 가져온 판매 데이터랑 아이템 정보를 매칭해서, 비슷한 패턴 발생 시 어떻게 대응해야 하는지 AI가 알려줄 수 있음"
◦
"우리는 감각적으로 일하는데, 그걸 쌓아두면 AI는 '네가 이렇게 느꼈을 때 이렇게 했을 걸?'이라고 알려줄 수 있음"
13. 추가 도구 결제
•
Make 결제 완료
◦
플랜: Core ($9/월, 연간 결제로 ~$100)
◦
크레딧: 월 10,000개
◦
용도: 태스크 자동 생성, 조회수 수집 등
•
Magic Milk Kit 결제 완료
◦
가격: $199 (평생 1회)
◦
용도: 노션/Make로 불가능한 자동화
◦
예: 노션 권한 자동 설정
•
Apify (추후 검토)
◦
가격: $29/월
◦
용도: 인스타그램 조회수 수집
◦
시점: 리스프레드 트래킹 본격화 시
14. 다음 단계
•
내일 일정 (온라인)
◦
줌 미팅
◦
디자인팀 이사님과 페이지 구성 논의
◦
필요 시 필드 추가
•
목/금 일정 (오프라인)
◦
페이지 구성 본격 작업
◦
자동화 연결
◦
테스트 및 수정
•
핵심 확인 사항
◦
디자인팀의 태스크별 기간 확정
◦
유튜브/인스타 계정 로그인 정보
◦
이지어드민 API 가능 여부 문의
핵심 인사이트 종합
•
멤버 vs 게스트의 함정
◦
많은 조직이 노션 비용 과다 청구 이유를 모름
◦
"멤버로 업그레이드" 버튼 하나가 월 수십만 원의 차이
◦
권한 최적화만으로 월 40만 원 이상 절감 가능
•
필드명은 계약서
◦
자동화 연결 후 필드명 변경은 전체 시스템 재구축과 동일
◦
초기에 모든 이해관계자와 필드명 합의 및 문서화 필수
◦
"품번"이냐 "상품코드"냐의 차이가 나중에 큰 비용
•
관계형의 기준: 의미 있는 가공
◦
"이 데이터를 가공했을 때 의미가 있나?" 질문 하나로 불필요한 관계형 방지
◦
출판사별 도서 수는 의미 없지만, 작가별 도서 수는 의미 있음
◦
의미 없는 관계형은 속도만 저하
•
자동화는 반복의 적
◦
10개 아이템 × 17개 태스크 = 170개 수동 입력 불가능
◦
프리 태스크 템플릿과 버튼 하나로 문제 해결
◦
"버튼 클릭 한 번"이라는 경험이 시스템 채택률 결정
•
데이터는 미래의 연료
◦
"지금 늦었다"는 컨설턴트의 말은 경각심 제공
◦
노션에 쌓이는 데이터는 AI 에이전트의 학습 자료
◦
지금 구조화된 데이터를 쌓지 않으면, 나중에 AI가 와도 활용 불가
노션다움 l 노션을 나만의 비서로
노션 강의/컨설팅으로 누적 2,000명 이상의 생산성을 높였습니다.
노션다움에 대해 더 자세히 알고 싶다면 아래 채널을 확인해 주세요
•
