개요
이 영상은 노션(Notion)을 활용하여 복잡한 비즈니스 데이터(ATS, KPI, 목표 관리 등)를 체계적으로 관리하고 시각화하는 대시보드를 구축하는 과정을 상세히 다룹니다. 특히, 연간 목표부터 분기, 월간, 주간 단위까지 이어지는 KPI 설정 및 실적 추적, 데이터베이스 간의 관계 설정, 자동화(Make 연동), 복잡한 수식(Formula) 활용법, 그리고 데이터 복구 방법(버전 기록) 등 실무적인 내용을 심층적으로 논의하고 시연합니다.
컨설턴트와 클라이언트 간의 대화 형식으로 진행되며, 실제 구축 과정에서 발생하는 문제(예: 뷰 사라짐, 데이터 정합성 문제, 수식 오류)와 해결 방안을 실시간으로 보여줍니다. 이를 통해 단순한 기능 소개를 넘어, 실제 비즈니스 요구사항에 맞춰 노션 시스템을 설계하고 구현하는 전반적인 프로세스와 노하우를 학습할 수 있습니다. 최종 목표는 검색 가능하고 실용적인 지식 자료로 활용될 수 있는 통합 대시보드를 완성하는 것입니다.
주요 학습 포인트
•
노션 버전 기록 활용: 예기치 않은 데이터 변경 또는 삭제 시 이전 상태로 복구하는 방법 및 주의사항 학습
•
복합 데이터베이스 설계: 연간-분기-월간-주간 목표 및 실적 추적을 위한 다중 데이터베이스 구조 설계 및 관계형 연결 설정
•
자동화 연동 (Make): 버튼 클릭 등 노션 내 이벤트를 트리거로 사용하여 다른 데이터베이스에 데이터를 자동으로 생성하거나 업데이트하는 방법 (예: 최종 합격 시 월간 실적 자동 등록)
•
고급 수식 활용: join, toNumber 등 노션 함수를 조합하여 배열 데이터를 숫자로 변환하고 계산하는 방법, 조건부 서식(그래프 표시) 구현 방법 학습
•
동적 대시보드 구축: 필터, 롤업, 관계형 속성 등을 활용하여 KPI 달성률, 진행 상태 등을 시각적으로 표현하고 동적으로 업데이트되는 대시보드 구성 요소 설계
요약
1. 노션 데이터 복구 및 페이지 잠금 기능
•
구간 주제: 실수로 변경/삭제된 노션 뷰 복구 방법 및 예방책
•
1. 문제 발생: ATS 페이지에서 '2차 인터뷰' 뷰가 사라진 상황 발생. 컨트롤+Z로 복구되지 않음.
◦
오전에 직원들에게 업데이트 내용을 보여주다 발생한 것으로 추정.
•
2. 해결 시도 (버전 기록): 노션의 '페이지 기록' (Version History) 기능을 사용하여 문제 발생 이전 시점(예: 어제 오후 3시 17분)으로 복원 시도.
◦
주의사항: 버전 복원 시, 복원 시점 이후에 입력된 데이터의 처리 방식을 선택해야 할 수 있음 (데이터 유지 또는 덮어쓰기). 이 영상에서는 해당 선택지가 명확히 나타나지 않았으나, 일반적으로 존재함.
◦
복원 결과: 사라졌던 '2차 인터뷰' 뷰가 성공적으로 복구됨. 단, 복원 시점 이후의 데이터(오늘 오전에 입력된 데이터)는 유실될 수 있음을 인지. (영상에서는 어제가 공휴일이라 영향이 적었음)
•
3. 예방책 (페이지 잠금): 유사 문제 방지를 위해 '페이지 잠금' 기능 고려.
◦
장점: 페이지 구조나 속성 변경을 막아 실수로 인한 수정을 방지.
◦
단점: 페이지가 잠기면 데이터 입력 등 모든 편집이 불가능해져 보기 전용 페이지가 됨. 버튼 등도 비활성화됨.
◦
대안: 사용할 때만 잠금을 해제하고 사용 후 다시 잠그는 방식도 가능하나, 매우 번거로울 수 있음. 근본적으로는 사용자의 주의가 필요.
•
4. 사라진 뷰의 위치: 뷰가 사라졌을 경우, '토글' 안에 숨겨졌을 가능성이 있으나 이번 경우에는 토글 내에서도 찾을 수 없었음.
2. 오디오 이슈 해결 및 연간/분기 목표 설정 기초
•
구간 주제: 오디오 문제 해결 및 연간/분기 목표 데이터베이스 구조 설정 논의
•
1. 오디오 문제 점검: 발표자의 마이크 소리가 간헐적으로 끊기거나 뭉개지는 현상 발생.
◦
줌(Zoom)의 소음 제거 기능 또는 마이크 자체의 지향성 문제로 추정.
◦
마이크 설정을 조정하여 문제 해결 시도. (결국 다른 마이크 사용 고려)
•
2. 목표 관리 구조 설정: 연간(Annual), 분기(Quarterly), 월간(Monthly), 주간(Weekly) 목표 및 실적 관리를 위한 데이터베이스 구조 논의 시작.
◦
쿼터리 메뉴 추가: '2025년 Q1', '2025년 Q2' 등 분기별 항목 생성 제안.
◦
KPI 항목 정의: 연간 목표를 분기/월간/주간으로 쪼갤 핵심 KPI 항목 정의 (신규 DB, BD콜, 미팅, 이력서, 인터뷰 등).
◦
개인별/전체 목표: KPI 목표는 개인별로 설정하며, 이를 합산하여 회사 전체 목표도 관리할 필요성 확인. 이를 위해 '오브젝티브(Objective)' 개념 도입 고려.
•
3. '성공(Success)' 지표 정의: KPI 달성 외 최종적인 성공 지표(예: 수수료 발생하는 최종 실적, Sales Amount, GP)를 추적할 필요성 제기.
◦
기존 KPI는 정량적이긴 하나, 최종 실적과는 별개로 움직일 수 있음.
◦
이 '성공' 지표는 주 단위보다는 월/분기/연 단위로 추적하는 것이 적합.
•
4. '성공' 지표 데이터 소스: ATS의 CV 데이터베이스에서 '최종 합격' 또는 '석세스(Success)' 상태의 후보자 데이터를 기반으로 '성공' 지표 값을 가져오는 방안 논의.
3. '성공' 지표 연동 방식 설계 및 자동화 준비
•
구간 주제: ATS에서 월간 리포트로 '성공' 실적을 자동으로 연결하는 방법 설계
•
1. '성공' 데이터 연결: ATS의 CV 데이터베이스에서 '최종 합격' 상태가 된 후보자의 정보(특히, 수수료 관련 값)를 월간 리포트 데이터베이스와 연결해야 함.
◦
월별 '성공' 카운트 및 합산 필요.
•
2. 자동 연결 방식 (버튼 + 자동화): CV 데이터베이스에 '성공 등록' 버튼을 추가하고, 이 버튼을 클릭하면 해당 후보자 정보가 해당 월의 리포트와 자동으로 관계형 연결(Relation)되도록 설정.
◦
트리거 시점: '최종 합격' 상태 변경 시 또는 별도 버튼 클릭 시. 레퍼런스 체크를 건너뛰고 바로 합격하는 경우도 고려하여, 최종 합격 단계 이후 (예: 출근 확인 후) 버튼을 누르는 시나리오 고려.
◦
버튼 명칭: '성공 등록', '출근 성공' 등 명확한 이름 제안. (이모지 활용 팁: 윈도우 + 마침표(.) 키)
•
3. 관계형 연결 준비: 월간/주간 리포트 데이터베이스에 직원 이름 속성이 정확히 입력되어 있어야 관계형 연결이 제대로 작동함 (자동화 시 이름으로 매칭).
•
4. 자동화 설정 (Make/Integromat): 버튼 클릭을 트리거로 Make 시나리오 실행 준비.
◦
필요 정보: 각 데이터베이스의 고유 ID. (노션 URL에서 추출 가능: notion.so/ 다음의 슬래시(/)와 물음표(?) 사이의 값)
◦
자동화 로직: 버튼 클릭 -> 해당 CV 데이터 확인 -> 해당 월의 해당 직원 리포트 페이지 찾아 관계형 연결.
4. Make 자동화 상세 설정 및 데이터 처리
•
구간 주제: Make를 이용한 노션 데이터베이스 간 자동 관계형 연결 설정 상세 및 데이터 입력 방식 논의
•
1. Make 'Map' 기능 설명: Make 모듈 설정 시 'Map' 옵션의 역할 설명.
◦
Map 비활성화: 고정된 값(Static Data)을 사용. 예를 들어 특정 페이지나 특정 상태 값으로 고정하여 연결.
◦
Map 활성화: 동적인 값(Dynamic Data)을 사용. 이전 단계에서 가져온 데이터나 변수를 사용하여 연결 대상을 유동적으로 결정. (예: 버튼을 누른 CV에 해당하는 월간 리포트 페이지를 찾아 연결)
◦
활용: 대부분의 자동화에서는 데이터가 계속 변하므로 Map 기능을 활성화하여 동적 데이터를 사용해야 함.
•
2. 자동화 시나리오 실행 확인: ATS에서 '성공 등록' 버튼 클릭 -> Make 시나리오 실행 -> 월간 리포트에 해당 CV와의 관계형 연결 생성 확인.
•
3. 예외 처리 (지난 달 데이터 입력): 만약 4월 말 성공 건을 5월 초에 등록해야 할 경우, 월간 리포트 페이지에서 직접 해당 관계형 연결을 수동으로 추가/수정할 수 있도록 설계.
◦
월간 리포트 페이지에 관계형 속성(예: '성공 CVs')을 직접 표시하여 확인 및 수정 용이성 확보.
•
4. 최종 실적 지표 명칭 확정: '성공' 지표의 필드명을 '세일즈 어마운트(Sales Amount)' 또는 'GP'로 사용하는 것을 고려. (파이낸스 용어에 맞춰 'GP'로 설정 제안)
•
5. 더미 데이터 입력: 연간 목표 KPI 값들에 대한 예시(더미) 데이터 입력 (신규 48개 -> 200개로 수정, BD 2500개, 미팅 52개 등). 이는 추후 분기/월간/주간 목표 계산의 기준이 됨.
5. 노션 수식(Formula) 심층 분석: Join & ToNumber
•
구간 주제: 노션 관계형 속성 값(배열)을 계산 가능한 숫자로 변환하는 수식(join, toNumber) 활용법 설명
•
1. 문제 상황: 관계형 속성을 통해 가져온 값(예: 연간 목표 값)은 '숫자 목록'(배열) 형태이기 때문에 직접적인 사칙연산(예: 나누기 4)이 불가능함. 오류 발생 ("배열과 숫자는 연산할 수 없다").
•
2. 해결 과정 (단계별 설명):
◦
1단계: 배열을 텍스트로 변환 (join): join 함수를 사용하여 숫자 배열을 하나의 텍스트 문자열로 합침. 구분자(separator)로 빈 문자열 ""을 사용하면 숫자들을 그대로 이어붙인 텍스트가 됨. (예: [100] -> "100")
▪
prop("연간 목표").join("")
◦
2단계: 텍스트를 숫자로 변환 (toNumber): toNumber 함수를 사용하여 텍스트 형식의 숫자를 실제 숫자(Number) 데이터 타입으로 변환.
▪
prop("연간 목표").join("").toNumber()
◦
3단계: 연산 수행: 숫자로 변환된 값에 원하는 연산(예: / 4)을 수행.
▪
prop("연간 목표").join("").toNumber() / 4
•
3. 추가 함수 (round, floor, ceil): 나누기 결과 소수점이 발생할 경우, 정수로 처리하는 방법.
◦
round(): 반올림
◦
floor(): 내림 (소수점 버림) - 영상에서 사용
◦
ceil(): 올림
•
4. 자동 관계형 연결의 복잡성: 연간-분기-월간-주간 데이터베이스 간 목표치를 자동으로 연결하고 계산하는 로직은 상당히 복잡하며, 추후 Make 시나리오 등을 통해 구현될 예정임을 시사.
•
5. 성능 우려: 관계형 연결과 수식이 많아질 경우 노션의 성능 저하 가능성에 대한 우려 제기. 실제 사용하면서 모니터링 필요.
6. 데이터 흐름 정리 및 주간 목표 설정 방식 재정의
•
구간 주제: 목표와 실적 데이터의 흐름(하향식 vs 상향식) 정리 및 주간 목표 설정 방식 확정
•
1. 데이터 흐름 명확화:
◦
목표(Goals): 연간(Annual) -> 분기(Quarterly) -> 월간(Monthly) -> 주간(Weekly) 순서로 **하향식(Top-down)**으로 설정 및 배분됨. (주로 수식 이용)
◦
실적(Actuals): 일간(Daily - 여기서는 명시적 DB 없음) 또는 주간(Weekly) 활동 결과 -> 월간(Monthly) -> 분기(Quarterly) -> 연간(Annual) 순서로 **상향식(Bottom-up)**으로 집계(Rollup)됨.
•
2. 주간 목표 유연성 논의: 이전에 주간 목표는 조율 가능하다고 논의했으나, 연간/분기 목표에서 자동으로 계산되어 내려오는 방식과 충돌.
◦
만약 주간 목표를 임의로 수정하면 상위 목표(월간, 분기, 연간)와 정합성이 맞지 않게 됨.
•
3. 주간 목표 고정 결정: 혼란을 피하기 위해 주간 목표도 연간 목표를 기반으로 수식을 통해 자동으로 계산되도록 고정하기로 결정.
◦
만약 목표 조정이 필요하다면, 연간 목표 자체를 수정하고 그 변경 사항이 하위 단위로 자동 반영되도록 함.
◦
모든 시간 단위(연간, 분기, 월간, 주간)의 목표 설정을 수식 기반으로 통일하여 일관성 유지.
•
4. 성능 우려 재확인: 주간 데이터가 연간 약 52주 x 직원 수만큼 생성되므로, 많은 데이터와 관계형 연결/수식으로 인한 성능 저하 가능성 재차 인지. 사용하면서 최적화 방안 모색 필요.
•
5. 목표 계산 오류 수정: 주간 목표 계산 시 연간 목표를 52주로 나누면서 일부 KPI(예: 신규) 값이 1 미만으로 나오는 문제 발견. 더미 데이터(연간 신규 목표)를 현실적으로 수정(48 -> 200)하여 해결.
7. 주간/월간 데이터 경계 처리 및 대시보드 시각화 구상
•
구간 주제: 월말/월초에 걸치는 주간 데이터의 월별 귀속 문제 해결 및 대시보드 KPI 시각화 방식 구상
•
1. 주간-월간 경계 문제: 특정 주(Week)가 두 개의 월에 걸쳐 있는 경우(예: 3월 마지막 주가 4월 며칠 포함), 해당 주의 실적을 어느 월에 귀속시킬지 결정 필요.
◦
문제점: 만약 3월 31일에 시작하는 주를 3월 실적으로 집계하면, 4월 4일에 발생한 신규 모집 건도 3월 실적으로 잡히게 되어 혼란 발생 가능.
◦
KPI vs GP: KPI 값(콜 수, 미팅 수 등)은 약간의 오차가 있어도 흐름 파악에 큰 문제가 없지만, GP(성공 실적)는 정확한 월별 귀속이 중요.
•
2. 해결 방안 결정:
◦
GP: 월간 단위로 별도 집계되므로 주간-월간 경계 문제에서 자유로움.
◦
KPI: 해당 주의 시작일이 속한 월을 기준으로 해당 주의 실적을 귀속시키기로 결정. (예: 3월 31일 시작 주는 3월 실적, 4월 28일 시작 주는 4월 실적)
▪
이로 인한 약간의 월별 KPI 오차는 감수하기로 함 (전체 흐름 파악에는 큰 영향 없을 것으로 판단).
•
3. 노션의 한계 인지: 노션은 기본적으로 '달력 기준' 월별 집계를 완벽하게 자동 지원하지 않으므로, 관계형 연결과 기준 설정(예: 주 시작일 기준)을 통해 구현해야 함.
•
4. 대시보드 시각화 준비 (갤러리 뷰): KPI 달성률을 시각적으로 보여주기 위한 준비.
◦
필요 속성: 목표값, 달성값, 달성률(%), 시각화용 수식(그래프).
◦
그래프 형태: 진행 상태 바(Progress bar) 형태의 시각화 고려 (수식으로 구현). 좁은 공간에도 표시하기 좋은 스타일 선택.
◦
갤러리 뷰 구상: 각 주차/월별/분기별 카드에 담당자 이름, KPI 항목, 목표, 달성, 달성률 그래프가 표시되는 형태 구상.
•
5. 필터링 위한 '생성일' 속성 추가: '이번 달', '지난 달' 등 기간별 필터링을 위해 각 데이터베이스 항목(주간, 월간, 분기, 연간 리포트)에 '생성일' 속성 추가 필요성 인지.
8. 동적 필터링 및 KPI 명칭 표준화, 대시보드 구조 확정
•
구간 주제: '생성일' 기반 동적 필터 설정, KPI 명칭 표준화 및 반복적인 대시보드 구조 확인
•
1. '생성일' 기반 동적 필터 설정:
◦
각 시간 단위 리포트(Weekly, Monthly, Quarterly, Annual) 데이터베이스에 '생성일' 속성 추가 및 값 입력.
◦
'이번 달', '지난 달'을 동적으로 판단하는 수식 속성 추가 (예: formatDate(prop("생성일"), "YYYYMM") == formatDate(now(), "YYYYMM") -> 이번 달).
◦
이 수식 속성을 활용하여 뷰 필터 설정 (예: '지난 달' 탭에서는 '지난 달' 속성이 체크된 항목만 보이도록 설정).
•
2. KPI 명칭 표준화: 대시보드 및 데이터베이스에서 사용할 KPI 명칭 통일.
◦
순서 및 명칭: 1. BD 콜 (DB 콜) 2. CV Sent (이력서) 3. 인터뷰 4. 신규 유치 (New Client) 5. 미팅
◦
영문/국문 혼용보다는 일관성 있는 표기(여기서는 영문 위주로 정리)가 가독성에 좋음.
•
3. 대시보드 구조 반복 확인:
◦
갤러리 뷰 형태로 각 KPI 항목(BD콜, CV Sent 등)에 대해 목표, 달성, 달성률(그래프 포함)이 표시되는 구조를 주간, 월간, 분기, 연간 리포트에 동일하게 적용할 것임을 확인.
◦
각 시간 단위 리포트 페이지 내에서 탭(Tabs)을 이용해 '이번 달', '지난 달' 등으로 필터링된 뷰를 제공할 예정.
•
4. 반복 작업 위임: 동일한 구조(목표, 달성, 달성률 표시)가 5개 KPI 항목에 대해 반복되므로, 이 부분의 실제 구현(수식 복사, 속성 설정 등)은 컨설턴트가 오프라인에서 작업하기로 함.
9. 작업 마무리, 향후 일정 조율 및 CRM/TRM 범위 논의
•
구간 주제: 대시보드 구축 현황 정리, 다음 미팅 일정 조율, CRM 및 TRM 구축 범위 논의
•
1. 대시보드 작업 현황 및 계획:
◦
KPI 달성률 시각화(갤러리 뷰, 그래프) 및 동적 필터링 구현 등 반복적인 작업은 컨설턴트가 다음 미팅 전까지 완료하기로 함.
◦
필요시 차트 형식의 시각화도 추가 고려.
•
2. 다음 미팅 일정 조율: 5월 중순 이후(15일, 21일, 23일, 28일, 29일, 30일) 가능한 날짜를 조율하여 5월 말까지 대시보드 및 후속 작업을 완료하는 것을 목표로 함.
•
3. 후속 작업 범위 (CRM, TRM, 통합 대시보드):
◦
CRM: 기존 구축 내용 점검 및 보완 (템플릿 적용 오류 해결, 회사 소개서 발송 연동 등). 스티비(Stibee) 연동 방안 논의 필요.
◦
TRM (Talent Relationship Management): 후보자 풀 관리 방안 논의. 후보자 데이터를 피플 데이터베이스 내에서 관리하되, 특정 프로젝트와 연결하거나 검색 가능하도록 구조화 필요. 스티비 연동 가능성 모색.
◦
통합 대시보드: ATS, CRM, TRM 데이터를 종합하여 대표가 볼 수 있는 최종 대시보드 구축. 기존 컴포넌트를 재활용하되 대표 맞춤형으로 커스터마이즈.
•
4. 난이도 예상: ATS 구축이 가장 복잡했고, 현재 진행 중인 대시보드도 복잡도가 높음. CRM, TRM은 상대적으로 덜 복잡할 것으로 예상.
•
5. 클라이언트 피드백: 현재까지 구축된 대시보드 구조(연간-분기-월간-주간 연동 및 KPI 추적 방식)가 원하는 방향과 일치하며 만족스러움을 표현.
•
6. ATS 자동화 이슈 재확인: 카카오톡 메시지 파싱 관련 자동화(회사명 추출 등)가 다시 작동하는 것을 클라이언트가 확인. 지속적인 모니터링 필요. 클라이언트가 직접 테스트 후 직원들에게 사용 공지 예정.
