개요
이 영상은 Notion과 Make.com을 활용하여 구축된 채용 CRM/ATS 시스템의 문제점을 진단하고 개선하는 과정을 다룹니다. 주요 논의 내용은 Make.com 자동화 시나리오 오류 수정, JD 발송 및 후보자 추천 프로세스 최적화, Solapi를 이용한 알림톡 발송 문제 해결, 그리고 KPI 측정을 위한 대시보드 구조 설계 및 OKR 연동 방안입니다. 실제 사용자의 피드백을 바탕으로 시스템의 실용성을 높이고, 업무 효율성을 개선하기 위한 구체적인 해결책과 구현 방법을 단계별로 심층 분석하고 적용하는 과정을 보여줍니다.
주요 학습 포인트
•
Notion과 Make.com을 이용한 맞춤형 CRM/ATS 시스템 구축 및 디버깅 실무
•
자동화 시나리오 설계 시 발생 가능한 오류 유형 및 해결 방법 (날짜 처리, 조건 분기, 외부 서비스 연동)
•
사용자 피드백 기반 워크플로우 개선 방안 도출 및 적용 (선택적 알림 발송, 상태 관리 자동화)
•
Solapi 연동 시 변수 전달 문제 해결 및 템플릿 검증 방법
•
채용 KPI 대시보드 설계 (일간/주간/월간/분기/연간 데이터 구조화 및 지표 정의)
•
Notion 데이터베이스 템플릿 활용 시 데이터 구조화의 제약 및 대안 모색
요약
1. 자동화 점검 및 초기 문제 식별
•
주제: 프로젝트 재개 및 초기 자동화 상태 점검
•
핵심 요점:
1.
자동화 상태 확인: 월/평일마다 동작해야 하는 '데일리 리포트 날짜 입력 자동화' Make.com 시나리오가 5월 1일 이후로 멈춘 것을 확인했습니다.
2.
오류 원인 파악: 시나리오 실행 기록 확인 결과, 특정 날짜 데이터(5월)에 '주차'는 존재하지만 '월' 정보가 누락된 예외 케이스가 발생하여 시나리오가 멈춘 것으로 추정됩니다.
3.
긴급 조치: 누락된 월 데이터를 수동으로 생성하여 5월 데일리/위클리 리포트 생성을 재개했습니다.
•
부가 설명:
◦
주차 정보는 있지만 월 정보가 없는 데이터 케이스는 예상치 못한 오류 상황으로, 데이터 정합성 확인 로직 보강의 필요성을 시사합니다.
•
중요 참고사항:
◦
자동화 시나리오는 얘기치 못한 데이터 예외 케이스에 대비한 오류 처리 로직이 중요합니다.
2. CRM/ATS 워크플로우 문제점 논의
•
주제: 현재 운영 중인 CRM/ATS 시스템의 주요 문제점 공유
•
핵심 요점:
1.
상태 변경 오류: 'JD 발송' 버튼 클릭 시 상태가 '발송중'으로 변경되지 않거나, '서류 합격' 버튼 클릭 시 후보자 리스트에서 해당 후보자가 제거되지 않는 문제가 발생합니다.
2.
버튼 로직 오류: '이력서 추천 진행' 버튼 클릭 후 'CV 발송' 버튼으로 변경되어야 하나, 해당 기능이 구현되지 않았거나 작동하지 않습니다. (추후 확인 결과, '이력서 추천 진행' 버튼은 날짜 자동 입력 기능만 담당하는 것으로 정정됨)
3.
알림톡 정보 누락: Solapi를 통해 발송되는 알림톡(예: 1차 인터뷰 확정 안내)에서 회사명, 포지션명 등의 중요 정보가 누락되어 빈 칸으로 발송되는 문제가 있습니다.
•
부가 설명:
◦
이 문제들은 실제 사용자(직원)들이 시스템을 사용하지 못하게 하는 주요 원인이므로 우선적으로 해결 필요성이 제기되었습니다.
◦
더미 데이터 테스트 과정에서 발견된 문제점으로, 실제 운영 전 철저한 테스트의 중요성을 보여줍니다.
3. JD 발송 워크플로우 테스트 및 개선 방안 모색
•
주제: JD 발송 기능 테스트 및 대량 처리, 선택적 메일 발송 요구사항 논의
•
핵심 요점:
1.
JD 발송 프로세스 시연: 후보자(이바보)를 특정 프로젝트(커리어플랜 헤드헌터)에 연결하고 'JD 발송' 버튼을 클릭하는 과정을 시연했습니다.
2.
현재 로직 확인: 현재는 버튼 클릭 시 담당자(회사 내부 직원) 이메일로 JD 초안 메일이 발송되고, 후보자 상태 변경 및 데일리 리포트(CV 발송 항목)에 기록됩니다.
3.
개선 요구사항: 실제로는 여러 후보자에게 동시에 JD를 보내는 경우가 많으며, 이 때 모든 후보자에게 개별 메일을 발송할 필요는 없고 상태 변경 및 KPI 기록만 필요한 경우가 있습니다. 현재 방식은 시간이 오래 걸리는 단점이 있습니다.
4.
해결 방안 제안: 후보자 목록 옆에 '메일 발송' 체크박스를 추가하여, 체크된 후보자에게만 메일을 발송하고, 체크되지 않은 후보자는 메일 발송 과정 없이 상태 변경 및 KPI 기록만 처리하도록 Make.com 시나리오를 분기하는 방안을 제안했습니다.
•
부가 설명:
◦
Make.com 시나리오 실행 시간을 단축하고(20-30초 -> 5초 이내 목표), 사용자의 편의성을 높이기 위한 개선입니다.
•
중요 참고사항:
◦
사용자의 실제 업무 패턴(대량 처리)을 고려하여 시스템 워크플로우를 설계하는 것이 중요합니다.
4. JD 발송 '메일 발송' 체크박스 기능 구현 및 테스트
•
주제: JD 발송 시 선택적 메일 발송 기능 구현 및 검증
•
핵심 요점:
1.
Notion 속성 추가: 후보자 데이터베이스에 '메일 발송' (체크박스 타입) 속성을 추가하고, 설명을 통해 기능(체크 시 JD 초안 메일 발송)을 명시했습니다.
2.
Make.com 시나리오 수정: 'JD 발송' 버튼 트리거 시, '메일 발송' 체크박스 상태를 확인하는 필터를 추가했습니다.
•
체크된 경우: 기존 로직대로 메일 발송 모듈 실행 후 상태 변경 및 데일리 리포트 연동.
•
체크 해제된 경우: 메일 발송 모듈을 건너뛰고 바로 상태 변경 및 데일리 리포트 연동.
3.
테스트: '이바보'(체크 O)와 '김천재'(체크 X) 후보자를 대상으로 테스트하여, '이바보'에게만 메일이 발송되고 두 후보자 모두 상태 변경 및 데일리 리포트에 정상적으로 기록됨을 확인했습니다.
4.
사용자 경험 개선: 버튼 클릭 시 즉시 완료 메시지 대신, 실제 처리가 완료될 때까지 로딩 상태를 보여주고 완료 후 확인 메시지(팝업)를 표시하도록 개선했습니다. (Make.com Webhook Response 활용)
•
확인 메시지에는 어떤 후보자에 대한 작업인지 명확히 알 수 있도록 후보자 이름을 동적으로 표시 (@멘션 기능 활용).
•
부가 설명:
◦
Notion의 @멘션 기능을 활용하여 페이지 속성 값을 메시지에 동적으로 삽입할 수 있습니다.
•
중요 참고사항:
◦
Make.com에서 Webhook 응답(Response) 모듈을 사용하면, 시나리오 처리 완료 시점에 사용자에게 피드백을 주어 비동기 작업의 진행 상태를 명확히 알릴 수 있습니다.
5. '이력서 추천 진행' 버튼 기능 확인
•
주제: '이력서 추천 진행' 버튼의 기능 검증 (추천 날짜 자동 입력)
•
핵심 요점:
1.
기능 문의: '이력서 추천 진행' 버튼 클릭 시, 추천 날짜가 자동으로 입력되기를 기대했으나 현재 수동 입력 상태인지 확인 요청했습니다.
2.
기능 검증: 실제 버튼 클릭 시연 결과, 버튼 클릭 후 실행되는 Make.com 시나리오가 완료되면 해당 후보자의 '추천 날짜' 속성에 오늘 날짜가 자동으로 입력되고, 후보자는 해당 리스트에서 사라지는 것을 확인했습니다.
3.
확인 메시지 개선: JD 발송과 마찬가지로, 버튼 클릭 확인 메시지에 해당 후보자 이름이 동적으로 표시되도록 수정했습니다.
•
부가 설명:
◦
초기 문제 제기 시 언급된 'CV 발송 버튼으로 변경' 기능은 해당 버튼의 역할이 아닌 것으로 확인되었습니다.
6. 알림톡(Solapi) 정보 누락 문제 분석 및 원인 파악
•
주제: Solapi 알림톡 발송 시 회사명/포지션명 누락 문제 심층 분석
•
핵심 요점:
1.
문제 재확인: 1차 인터뷰 확정 안내 등 알림톡 발송 시, "[회사명] [포지션명]" 부분이 비어있는 상태로 수신되는 문제를 재확인했습니다. (카카오톡 메시지 확인)
2.
데이터 흐름 추적: Make.com 시나리오에서 해당 정보를 후보자(CV) 데이터 또는 프로젝트(Project) 데이터에서 가져오는 부분을 확인했습니다.
3.
근본 원인 식별: 알림톡 발송 시 참조하는 프로젝트 데이터베이스의 '프로젝트 타이틀'(포지션명) 필드가 비어있는 것을 확인했습니다. 이 값이 없기 때문에 알림톡으로 전달되지 못하는 것입니다.
4.
'프로젝트 타이틀' 입력 방식 논의: 원래는 JD 파싱 시 SEO 최적화된 제목을 자동으로 파싱하여 입력하기로 계획했으나, 현재 해당 기능의 퀄리티 문제 또는 미구현으로 인해 수동 입력이 필요한 상태입니다.
•
부가 설명:
◦
구글 Gemini 1.5 Pro 및 Perplexity AI 소개 (Side Track): 발표자가 최근 사용해 본 AI 도구(Gemini 1.5 Pro 요약 기능, Perplexity AI 슬라이드 생성 기능)의 뛰어난 성능을 잠시 소개하며 관련 경험을 공유했습니다.
•
중요 참고사항:
◦
자동화 시스템에서 데이터 누락은 연쇄적인 문제를 일으킬 수 있으므로, 데이터 생성 및 입력 단계의 정확성과 완전성이 중요합니다.
◦
외부 서비스(Solapi) 연동 시, 전달하는 데이터 필드와 해당 필드의 값이 정확히 채워져 있는지 확인하는 것이 필수적입니다.
7. 알림톡(Solapi) 문제 해결 및 추가 개선 논의
•
주제: Solapi 알림톡 문제의 임시 해결 및 추가 개선 요구사항 논의
•
핵심 요점:
1.
임시 조치: 테스트를 위해 문제가 된 프로젝트의 '프로젝트 타이틀'을 수동으로 입력했습니다. (예: "헤드헌팅 팀장")
2.
재 테스트 및 불일치 발견: 프로젝트 타이틀 입력 후 알림톡 재발송 테스트 결과, 포지션명("헤드헌팅 팀장")은 정상적으로 표시되었으나, 회사명("커리어플랜")은 여전히 누락되었습니다. 그러나 이후 다른 테스트(1차 인터뷰 확정 안내)에서는 회사명이 정상적으로 표시되는 불일치 현상이 발견되었습니다.
3.
추후 확인 필요: 회사명 누락 문제의 정확한 원인(Make 시나리오 로직 오류, Notion 데이터 불일치 등)은 추가적인 확인이 필요한 상태로 남겨두었습니다.
4.
선택적 알림 발송 요구 (1차 인터뷰): JD 발송과 유사하게, 1차 인터뷰 안내 시에도 알림톡 발송이 필요 없는 경우(예: 해외 거주 후보자)를 위해, 알림톡 발송 여부를 선택할 수 있는 기능(예: 체크박스) 추가를 요청했습니다.
5.
KPI 연동 시점 논의: 인터뷰 관련 KPI(데일리 리포트 연동)는 단순히 상태 변경 시점이 아니라, 실제 인터뷰 안내가 발송되거나 확정되는 시점에 카운팅되어야 함을 명확히 했습니다.
•
부가 설명:
◦
서류 합격 단계에서는 별도의 알림 발송 없이 상태만 변경됩니다.
◦
인터뷰 일정 확정 시 KPI 카운팅 및 데일리 태스크(리마인드 콜 등) 연동 필요성이 제기되었습니다.
•
중요 참고사항:
◦
시스템 디버깅 시, 문제 재현의 일관성을 확인하는 것이 중요합니다. 불일치 현상은 잠재적인 다른 오류를 시사할 수 있습니다.
8. 인터뷰 안내 선택적 알림 기능 구현
•
주제: 1차 및 2차 인터뷰 안내 시 선택적 알림톡 발송 기능 구현
•
핵심 요점:
1.
'정보 차단' 속성 추가: 후보자(CV) 데이터베이스에 '정보 차단 (1차)', '정보 차단 (2차)' 체크박스 속성을 추가했습니다. 체크 시 해당 단계의 알림톡/이메일 발송을 차단하는 기능입니다.
2.
Make.com 시나리오 수정:
•
'1차 인터뷰 일정 안내', '2차 인터뷰 일정 안내' 버튼 트리거 시, 해당 단계의 '정보 차단' 체크박스 상태를 확인하는 필터를 추가했습니다.
•
체크 해제된 경우: 알림톡/이메일 발송 모듈 실행 후 상태 변경, KPI 연동(데일리 리포트 관계 맺기), '발송 완료' 상태 업데이트.
•
체크된 경우: 알림톡/이메일 발송 모듈을 건너뛰고 상태 변경 및 '발송 완료' 상태 업데이트만 수행 (KPI 연동 X).
3.
'발송 완료' 상태 변경: 기존의 체크박스 대신 '발송 상태' (선택 속성: 발송 전, 발송 완료 등)를 사용하여 상태를 명확히 관리하도록 변경했습니다. (단, 영상에서는 최종적으로 체크박스로 유지된 후, 나중에 상태 속성으로 변경 제안)
4.
Solapi 템플릿 업데이트: 최신 승인된 Solapi 템플릿("인터뷰 일정이 확정되었습니다")으로 Make 시나리오를 업데이트했습니다.
5.
테스트: '정보 차단' 체크/해제 시 알림톡 발송 여부 및 '발송 완료' 상태 업데이트, KPI 연동 여부를 확인했습니다. 회사명 누락 문제는 여전히 간헐적으로 발생했습니다. (1차는 누락, 2차는 정상 발송 확인)
6.
이메일 알림 확인: 인터뷰 확정 시 이메일 알림도 함께 발송되는 것을 확인했습니다.
•
부가 설명:
◦
Make.com 시나리오 마지막에 Webhook Response 모듈(status 200)을 추가하여, 버튼 클릭 후 시나리오가 완전히 종료될 때까지 로딩 상태를 유지하고 성공 시 피드백을 주는 사용자 경험 개선을 적용했습니다.
•
중요 참고사항:
◦
여러 단계에 걸쳐 유사한 기능(선택적 알림)이 필요할 경우, 일관된 방식으로 속성명과 로직을 설계하는 것이 유지보수에 유리합니다.
9. KPI 대시보드 설계 및 구조 논의
•
주제: Daily/Weekly/Monthly/Yearly 리포트 구조 및 KPI 측정 방식 논의
•
핵심 요점:
1.
리포트 구조 확인: 데일리 리포트에는 콜리스트, 미팅, 태스크 등이 기록되며, 이 데이터는 위클리, 먼슬리, 이어리 리포트와 연동되어 집계됩니다.
2.
데이터 관계 설정: 데일리 리포트의 데이터(콜, 미팅, CV 발송, 인터뷰 등)는 해당 담당자 및 날짜(주차, 월, 년도) 정보와 함께 상위 리포트로 관계가 맺어집니다.
3.
KPI 측정 방식 정의:
•
각 KPI 항목(BD 콜, 클라이언트 미팅, CV 샌딩, 1차 인터뷰, 2차 인터뷰)은 가중치 없이 **단순 개수(Count)**로 측정합니다.
•
Task는 KPI 측정 대상에서 제외하고, 수행 내용 기록 용도로만 사용합니다.
4.
KPI 항목 명칭 정의:
•
콜: BD 콜 (BD Call)
•
미팅: 클라이언트 미팅 (Client Meeting)
•
JD 발송 완료 -> 변경: CV 샌딩 (CV Sending) 또는 후보자 추천
•
1차 인터뷰, 2차 인터뷰: 각각 명칭 유지
5.
데일리 리포트 구조 단순화: 초기 설계에 있던 '컴퍼니' 관계는 데일리 리포트에서 불필요하다고 판단하여 제거했습니다. (CV 데이터나 콜리스트 등에서 회사 정보 확인 가능)
•
부가 설명:
◦
주차(Week)는 월(Month) 경계와 정확히 일치하지 않으므로, 데일리 데이터는 위클리 및 먼슬리 리포트 양쪽에 모두 관계가 맺어지는 구조를 사용합니다.
•
중요 참고사항:
◦
KPI 측정 방식(개수 vs 가중치)과 대상 항목을 명확히 정의하는 것은 대시보드 설계의 핵심입니다.
10. 일일 업무(Task) 관리 방식 구체화
•
주제: 데일리 리포트 내 시간대별 업무(Task) 기록 및 관리 방안 설계
•
핵심 요점:
1.
요구사항: 담당자가 하루 업무를 시간대별(예: 9-10시, 10-11시 등)로 계획하고 기록하며, 이 내용을 데일리 리포트에서 확인하고 싶어합니다.
2.
구현 방안 제안:
•
별도의 'Tasks' 데이터베이스를 생성합니다.
•
데일리 리포트 페이지 내에 '테스크 생성' 버튼을 만듭니다.
•
버튼 클릭 시, 해당 날짜와 담당자가 자동으로 입력되고, 미리 정의된 시간대(9-10, 10-11, ..., 17-18)별로 8개의 Task 항목이 Tasks DB에 생성됩니다. (시간 범위 자동 설정 기능 활용)
•
데일리 리포트 페이지에는 'Tasks' DB의 링크된 데이터베이스(Linked Database)를 삽입하고, 해당 날짜의 Task만 필터링하여 보여줍니다.
3.
Task 관리: 생성된 시간대별 Task 항목에 담당자가 실제 수행할 업무 내용을 기입하고, 상태(시작 전, 진행 중, 완료)를 변경하며 관리합니다.
4.
시각화: 타임라인 보기(Timeline View) 등을 활용하여 시간대별 업무 계획 및 진행 상황을 시각적으로 파악할 수 있습니다.
•
부가 설명:
◦
Task 항목 자체는 KPI로 직접 카운트하지는 않지만, 업무 계획 및 회고 용도로 활용됩니다.
◦
Notion의 버튼 기능을 활용하여 반복적인 데이터 생성을 자동화할 수 있습니다.
◦
날짜/시간 범위 자동 계산을 위해 Notion 함수(formula)가 사용됩니다.
•
중요 참고사항:
◦
링크된 데이터베이스와 필터 기능을 활용하면, 중앙 집중식 데이터(Tasks DB)를 다양한 컨텍스트(각 데일리 리포트)에 맞게 표시할 수 있습니다.
11. OKR/KPI 연동 및 주간 목표 설정 방식 논의
•
주제: 일일 업무(Task)와 상위 목표(OKR/KPI) 연동 방식 및 주간 단위 목표 설정/측정 방법 논의
•
핵심 요점:
1.
헤드헌팅 OKR 구조:
•
궁극적인 목표(Objective): 매출 달성 (Success Fee 기준)
•
핵심 결과(Key Results): CV 발송 수, 인터뷰 진행 수, BD 콜 수, 클라이언트 미팅 수, 신규 고객 확보 수 등 (측정 가능한 활동 지표)
2.
Task와 KR 연동 방식:
•
일일 Task 자체에 목표치(Goal)와 달성치(Complete)를 기록하는 것은 가능하나, 이는 주로 담당자의 계획 수립 및 인식 개선(Training) 목적으로 활용합니다.
•
실제 KR 달성률 측정은 Task 단위가 아닌, 주간(Weekly) 리포트에서 집계된 데이터를 기반으로 합니다.
3.
주간 리포트 목표 설정:
•
위클리 리포트에 각 KPI 항목별 '목표'(Target) 필드를 추가합니다. (예: BD콜 목표, CV 목표 등)
•
주간 목표는 담당자별로 설정되며, 필요에 따라 주 단위로 수정될 수 있습니다. (수동 입력)
4.
주간 리포트 달성률 계산:
•
'달성'(Achieved) 값은 데일리 리포트에서 롤업(Rollup)되거나 관련 DB(ATS, Company) 상태 변경을 카운트하여 자동으로 집계됩니다.
•
'달성률'(%)은 (달성 값 / 목표 값) * 100으로 계산됩니다.
5.
신규 고객 KPI 측정: Company DB의 고객 등급(Grade)이 특정 단계(예: 2번 이상)로 변경된 시점을 기준으로 주간 '신규' KPI를 카운트합니다. 이는 위클리 리포트에서 직접 관계를 맺어 추적합니다.
•
부가 설명:
◦
일일 Task의 목표 설정은 개인의 성과 평가에 직접 반영되지 않으며, 주간/분기/연간 단위의 실제 KPI 달성률이 더 중요하게 관리됩니다.
◦
이 방식은 OKR의 기본 철학(상위 목표와 연계된 측정 가능한 결과 추적)을 따르면서도, 일일 업무 관리의 복잡성을 줄이는 절충안입니다.
•
중요 참고사항:
◦
OKR/KPI 시스템 설계 시, 측정 지표, 목표 설정 단위(일/주/월/분기/연), 데이터 집계 방식, 목표 설정 주체 등을 명확히 정의해야 합니다.
12. 월간/분기별 리포트 및 최종 목표 연동 논의
•
주제: 월간 및 분기별 리포트 구성 및 연간 목표와의 연동 방안
•
핵심 요점:
1.
월간 리포트 제약: 주차와 월의 경계 불일치로 인해, 위클리 리포트의 목표/달성률을 월간 리포트로 정확히 롤업하기 어렵습니다.
2.
월간 리포트 구성 방안:
•
'달성' 값: 데일리 리포트 데이터를 월 단위로 직접 집계하여 표시합니다.
•
'목표' 값: 연간 목표를 12로 나누어 월별 목표로 설정하거나, 별도로 월간 목표를 설정합니다. (연간 목표 기반 자동 계산 제안)
•
달성률 계산 가능.
3.
분기 리포트:
•
인센티브 정산 등 분기별 실적 집계가 중요합니다. (1, 2, 3월 실적 합산 -> 1분기)
•
분기 마감일(예: 3월 31일) 기준으로 정확한 집계가 필요합니다.
•
구현 방안: 월간 리포트 데이터를 합산하여 분기 리포트를 생성하는 별도의 자동화 시나리오(Make.com)를 구현합니다. (예: 4월 2일경 1분기 리포트 자동 생성)
4.
연간 목표 (매출):
•
최종 목표인 매출(Success Fee)은 후보자 출근 예정일 기준으로 집계됩니다.
•
CV(후보자) 데이터베이스의 '수수료' 및 '출근 예정일' 속성값을 활용하여 연간/분기별 실적을 추적합니다.
•
부가 설명:
◦
리포트 계층 구조(Daily -> Weekly -> Monthly -> Quarterly -> Yearly)를 설계할 때, 각 단계별 데이터 집계 방식과 목표 설정 방식을 명확히 정의해야 합니다.
•
중요 참고사항:
◦
Notion의 기본 롤업 기능만으로는 복잡한 기간별 집계(특히 주-월 불일치)에 한계가 있을 수 있으며, Make.com 등 외부 자동화 도구를 활용하여 해결할 수 있습니다.
13. Notion 템플릿 내 데이터 구조화 문제
•
주제: 회사(Company) 페이지 템플릿 내 조직도 정보 구조화 시도 및 제약 사항 확인
•
핵심 요점:
1.
요구사항: 각 회사 페이지 내에 해당 회사의 조직 구조(부서, 인원 등)를 표 형식으로 입력하고 관리하고 싶어합니다. 이를 Notion 페이지 템플릿에 구현하려고 시도했습니다.
2.
문제 발생: 템플릿 내에 데이터베이스(인라인)를 생성하여 조직도 형식을 만들었더니, 특정 회사 페이지에서 내용을 업데이트하면 템플릿 자체 또는 다른 회사 페이지의 조직도까지 함께 변경되는 문제가 발생했습니다.
3.
Notion 제약 설명:
•
템플릿 내에 데이터베이스를 직접 생성하면, 이는 모든 템플릿 인스턴스에서 공유되는 하나의 동일한 데이터베이스가 됩니다. 따라서 한 곳에서 수정하면 다른 모든 곳에 반영됩니다.
•
각 페이지(회사)마다 독립적인 표 데이터를 가지려면, 데이터베이스를 사용하는 대신 **표준 블록(텍스트, 토글 등)**을 사용하거나, 혹은 별도의 '조직 구조' 데이터베이스를 만들고 관계형(Relation) 속성으로 연결하는 방식을 사용해야 합니다.
•
부가 설명:
◦
템플릿은 페이지의 초기 구조를 제공할 뿐, 템플릿 내에 삽입된 데이터베이스는 해당 템플릿을 사용하는 모든 페이지에서 공유됩니다.
•
중요 참고사항:
◦
Notion 템플릿을 활용하여 구조화된 정보를 관리할 때, 데이터베이스와 일반 블록의 동작 방식 차이를 이해하는 것이 중요합니다. 각 페이지별 독립적인 데이터는 일반 블록이나 관계형 속성을 활용하는 것이 적합합니다.
14. 마무리 및 다음 단계
•
주제: 논의된 내용 정리 및 다음 회의 일정 조율
•
핵심 요점:
1.
대시보드 설계 완료: KPI 측정 및 리포트 구조(Daily/Weekly/Monthly/Quarterly/Yearly)에 대한 설계를 확정했습니다.
2.
다음 작업: 내일 회의에서 오늘 설계한 대시보드 구조를 Notion과 Make.com을 통해 실제로 구현하고, 이후 TRM(Talent Relationship Management) 관련 내용으로 넘어갈 예정입니다.
3.
회의 일정: 내일 오후 1시에 회의를 재개하기로 합의했습니다.
