개요
이 영상은 채용 자동화 시스템(ATS) 구축 과정의 일부로, Make(구 Integromat)를 활용하여 Notion 및 Google Drive와 연동되는 워크플로우를 개선하고 문제 해결하는 기술 컨설팅 세션을 기록한 내용입니다. 주요 논의 내용은 이력서 파싱 시 연락처 누락 오류 처리, Google Drive를 이용한 오류 이력서 관리, Make의 오류 처리 메커니즘(Ignore 모듈)의 한계점 탐색, 그리고 Notion 기반의 KPI 대시보드 설계 및 구현 방안입니다.
특히, 이력서 파싱 과정에서 발생하는 다양한 예외 상황(연락처 부재, 파일 자체 오류, 이메일 형식 오류, 중복 이력서)에 대한 견고한 처리 로직을 구축하고, Make의 운영(Operation) 비용 구조에 대한 오해를 바로잡습니다. 더 나아가, 실제 운영에 필요한 KPI(콜 수, 미팅 수, 신규 고객 확보, 인터뷰 진행, 최종 합격)를 정의하고, 이를 Notion에서 효과적으로 추적 및 시각화하기 위한 대시보드 구조와 데이터 연동 방안을 심도 깊게 논의합니다. 최종 목표는 데이터 기반의 의사결정을 지원하고, 팀원들의 업무 효율성을 높이는 통합적인 ATS 및 성과 관리 시스템을 구축하는 것입니다.
주요 학습 포인트
•
Make 시나리오에서 이력서 파싱 시 전화번호/이메일 누락 예외 처리 방법
•
Make의 'Ignore' 에러 핸들링 지시어의 기능과 한계점 이해 (오류 발생 시 분기 처리 불가)
•
Google Drive를 활용하여 처리 오류가 발생한 파일을 자동으로 분류 및 관리하는 방법
•
Make의 오퍼레이션 개념 및 요금제 구조 이해 (오퍼레이션 만 개당 비용)
•
Notion 데이터베이스를 활용한 KPI 대시보드 설계 (콜, 미팅, 신규 고객, 인터뷰, 합격 등)
•
Notion 버튼과 Make 시나리오를 연동하여 KPI 데이터를 자동으로 집계하는 방법
•
주간 KPI와 월간 누적 KPI 추적 방식의 차이점 및 구현 시 고려사항
•
자동화된 리포트(일간, 주간, 월간) 생성 시 멤버별 데이터 분리 및 날짜/주차 처리 로직 설계
요약
1. 이력서 파싱 오류 수정 및 테스트 (0:00 - 5:30)
•
핵심 요점 1: 문제 정의 - 연락처 없는 이력서 처리 불가
◦
기존 '03 이력서 입력 노션' Make 시나리오에서 전화번호 또는 이메일 정보가 없는 이력서는 파싱 후 노션 People 데이터베이스에서 해당 인물을 찾거나 생성하지 못해 입력 프로세스가 멈추는 문제가 있었습니다. (오류 메시지 없이 중단)
◦
이는 이력서 처리 전 People 데이터베이스에서 이름과 연락처를 기반으로 중복 여부를 확인하는 로직 때문이었습니다.
•
핵심 요점 2: 해결 방안 - 연락처 없어도 입력되도록 로직 수정
◦
Make 시나리오(영상에서는 '메이크 3번'으로 지칭) 로직을 수정하여, 이메일 주소나 휴대폰 번호가 없는 경우에도 해당 이력서 정보를 노션에 입력하도록 변경했습니다.
◦
연락처 유무에 따라 노션 내 다른 위치(데모에서는 위/아래 섹션으로 분리됨)에 표시될 수 있지만, 데이터 자체는 누락 없이 입력되도록 하는 것이 목표입니다.
•
핵심 요점 3: 테스트 및 확인
◦
연락처가 있는 이력서와 없는 이력서를 각각 시나리오에 투입하여, 수정된 로직이 두 경우 모두 정상적으로 이력서 정보를 노션에 입력하는 것을 시연하고 확인했습니다.
•
중요 참고사항:
◦
기존에는 연락처 없는 이력서 입력을 제한하기로 했으나, 실무적 요구에 따라 정책을 변경하여 모든 이력서를 우선 입력하는 방향으로 수정되었습니다.
2. Google Drive 연동 오류 처리 및 Make 'Ignore' 모듈 논의 (5:30 - 15:00)
•
핵심 요점 1: Google Drive 기반 오류 파일 관리
◦
다른 시나리오(Google Drive 연동)에서는 오류 발생 시 해당 파일을 특정 Google Drive 폴더로 이동시키는 방식으로 처리하고 있었습니다. (이력서 중복, 파일 자체 오류, 이메일 주소 형식 오류 등)
◦
이 방식은 문제가 된 파일을 별도로 관리하고 추후 원인 파악 및 수동 처리를 가능하게 합니다.
•
핵심 요점 2: Make 'Ignore' 지시어의 한계
◦
Make 시나리오 내에서 오류 발생 시 'Ignore' 지시어를 추가하면 해당 오류를 무시하고 다음 단계로 진행할 수 있습니다.
◦
하지만, 'Ignore'를 사용하면 오류 발생 사실 자체를 인지하기 어렵고, 오류가 발생했을 때 특정 로직(예: 오류 파일을 다른 폴더로 이동)으로 분기하는 기능을 지원하지 않습니다.
◦
즉, 오류를 무시하거나 시나리오 전체를 멈추게 하는 것 외에, 오류 유형에 따른 맞춤형 처리가 어렵다는 한계가 있습니다.
•
핵심 요점 3: 오류 처리 전략 결정
◦
오류 발생 시 무시해도 되는 경우(단순 알림 등)는 'Ignore'를 사용할 수 있지만, 원인 파악 및 후속 조치가 필요한 경우(데이터 누락, 중요 프로세스 실패 등)는 'Ignore'를 사용하지 않고 시나리오가 멈추도록 하여 관리자가 인지하고 직접 처리하는 것이 더 나을 수 있다는 의견이 제시되었습니다.
◦
현재 Google Drive 연동 시나리오에서는 중복 오류 발생 시 특정 폴더로 파일을 이동시키는 커스텀 에러 핸들링이 구현되어 있으나, 이는 'Ignore'가 아닌 별도 로직으로 구성된 것입니다. 다른 유형의 오류(파일 오류, 이메일 형식 오류)에 대해서도 유사한 처리(오류 파일을 특정 폴더로 이동)를 원하지만, Make의 표준 기능으로는 구현이 어렵다는 점을 확인했습니다.
•
주목할 발언: "이그노에는 이거를 붙일 수가 없다 그러더라고요... 라우터를 걸어 가지고 에러가 나면은 이 다음에서도 뭐 붙일 수 있는게 있으면 좋은데 이거는 그냥 지원을 안 하더라고요." (Make의 오류 처리 분기 기능 부재 확인)
3. Make 오퍼레이션 및 비용 구조 이해 (15:00 - 25:00)
•
핵심 요점 1: 대량 처리 시 경고 메시지 발생
◦
짧은 시간 동안 많은 수의 작업(약 100개 이력서 처리 시도)을 실행했을 때, Make에서 경고 메시지(이전 경험상 40분 또는 49분 이상 연속 실행 시)가 발생했던 경험을 공유했습니다. 이는 Make의 단일 실행 시간 제한과 관련될 수 있습니다.
◦
이러한 경고 발생 시, 잠시 후 다시 실행하면 정상 작동하는 경우가 많습니다.
•
핵심 요점 2: Make 오퍼레이션 및 비용 개념 명확화
◦
사용자는 Make의 오퍼레이션 1만 개당 비용을 약 10만 원으로 잘못 인지하고 있었으나, 실제로는 월 1만 오퍼레이션에 약 10달러(약 1만 1천 원 ~ 1만 4천 원, 부가세 포함 시 변동 가능) 수준임을 확인했습니다.
◦
이는 이전에 예상했던 비용보다 훨씬 저렴한 것으로, 자동화 운영 비용 부담에 대한 우려를 크게 해소했습니다.
•
핵심 요점 3: 요금제 및 추가 오퍼레이션 구매 옵션
◦
Make는 사용량에 따라 다양한 요금제를 제공하며 (예: 월 2만 개 34), 필요시 현재 요금제 이상으로 오퍼레이션을 추가 구매할 수 있습니다.
◦
자동 충전 옵션(Auto-top up)은 오퍼레이션 소진 시 자동으로 추가 구매해주지만, 단가가 약간 높습니다(만 개당 $13).
◦
수동으로 미리 오퍼레이션을 구매(Buy additional operations)하면 더 저렴한 단가(만 개당 $10.6)로 필요한 만큼 구매할 수 있습니다.
•
주목할 발언: "오퍼레이션 만개는 만 원인데... 아 그 만 개가 그 10만 원이 그거... 아 저 십자를 10만원이라고 생각해 가지고 혼자 막 아 더 아깝다 이거 나이 다 써야 돼..." (비용 오해 해소 과정)
•
중요 참고사항: 비용은 영상 녹화 시점 기준이며, 현재 Make 요금제는 변동될 수 있으므로 공식 웹사이트 확인이 필요합니다.
4. KPI 대시보드 설계 및 핵심 지표 정의 (25:00 - 35:00)
•
핵심 요점 1: 대시보드 목적 정의
◦
Notion 기반의 대시보드를 통해 직원들의 업무 성과(KPI)를 추적하고, 팀 전체의 진행 상황을 파악하며, 데이터 기반의 전략 수립 및 업무 계획을 지원하는 것을 목표로 합니다.
◦
기존에 사용하던 개별 관리용 스프레드시트나 복잡한 구조보다는, ATS와 연동되어 실제 활동을 자동으로 반영하고 시각적으로 파악하기 쉬운 '게임 판'과 같은 형태를 구상합니다.
•
핵심 요점 2: 핵심 KPI 정의
◦
ATS 및 CRM 활동을 기반으로 추적해야 할 핵심 성과 지표(KPI)를 다음과 같이 6가지로 정의했습니다.
1.
BD 콜 (영업 콜): 고객사 대상 영업/관계 형성 콜 수 (콜리스트 기반)
2.
CV 제출: 후보자 이력서(CV)를 고객사에 제출한 횟수 (ATS 내 CV 발송 상태 변경 기준)
3.
미팅: 고객사 또는 후보자와의 미팅 횟수 (온/오프라인 포함, 별도 미팅 DB 생성 제안됨)
4.
신규 고객 확보: 새로운 고객사와의 거래 시작 (Company DB의 그레이드(GD) 값 2 이상 변경 기준)
5.
인터뷰 진행: 제출된 후보자가 면접을 진행한 횟수 (CV DB의 상태가 '1차 인터뷰' 이상으로 변경 기준)
6.
석세스 (최종 합격): 후보자가 최종 합격하여 채용이 성사된 횟수 (CV DB의 상태가 '합격'으로 변경 기준)
•
핵심 요점 3: 데이터 소스 및 추적 기준 구체화
◦
각 KPI를 추적하기 위한 데이터 소스(Notion DB)와 구체적인 상태 값 또는 조건(예: GD 값, 상태 필드 변경)을 명확히 했습니다.
◦
신규 고객의 경우, 단순 회사 등록이 아닌 실제 거래 가능성이 있는 관계 형성(GD 2 이상)을 기준으로 삼기로 했습니다.
◦
인터뷰는 1차, 2차 등을 구분하지 않고 '1차 인터뷰' 상태로 변경되는 시점부터 카운트하기로 했습니다.
5. '콜 리스트(BD 콜)' KPI 추적 방안 상세 논의 (35:00 - 50:00)
•
핵심 요점 1: 콜 리스트 관리 방식 (사용자 경험)
◦
사용자는 개인적인 업무 방식으로 큰 달력에 월별 콜 대상 고객 리스트를 미리 작성하고, 주 단위 목표 콜 수를 정해 리스트를 업데이트하며 관리합니다. (후보자 면담 중 얻는 정보 활용 등)
◦
이러한 '기록' 기반의 꾸준한 활동이 장기적인 관계 형성과 성과로 이어진다는 경험을 공유하며, 시스템이 이러한 방식을 지원하기를 원합니다. (호혜성 원칙 언급)
•
핵심 요점 2: 콜 리스트 Notion DB 연동 방안
◦
Notion의 People 데이터베이스에서 콜 대상자를 검색 후, '콜 리스트 생성' 버튼을 클릭하면 콜 리스트 DB에 해당 인물 정보와 함께 통화 예정 항목이 생성됩니다.
◦
이때, 콜 리스트 항목 이름(타이틀)은 자동으로 People DB의 인물 이름으로 생성됩니다. (다른 속성값 추가 가능)
•
핵심 요점 3: 콜 완료 처리 및 KPI 집계
◦
생성된 콜 리스트 항목에서 실제 통화 완료 후 '통화 완료' 상태를 체크(또는 버튼 클릭)하면, 해당 활동이 당일의 데일리 리포트에 '콜 1회'로 기록되도록 Make 시나리오를 구성할 예정입니다.
◦
'진행 중' 상태는 불필요하다고 판단하여 제거하고, '시작 전'과 '통화 완료' 두 상태만 사용하기로 합니다.
•
핵심 요점 4: 후속 콜 예약 처리
◦
통화 중 "3개월 뒤에 연락 달라"는 요청을 받은 경우, 현재 콜 항목을 '통화 완료'로 처리하고, 새로운 콜 리스트 항목을 생성하여 3개월 뒤 날짜를 수동으로 지정하는 방식을 제안했습니다.
◦
기존 항목을 재활용하는 것보다 명확성을 위해 신규 생성하는 것이 좋다는 의견입니다. (Make에서 3개월 후 자동 알림 기능은 별도로 구현 가능성 있음 - Next Contact 필드 관련 언급)
•
중요 참고사항: 콜 리스트는 신규 영업 대상뿐 아니라 기존 고객사 담당자와의 통화도 기록하여 전반적인 고객 관리 활동을 포함하는 개념으로 사용합니다.
6. 데일리/주간/월간 리포트 자동 생성 (50:00 - 1:05:00)
•
핵심 요점 1: 리포트 DB 구조 및 자동 생성 필요성
◦
KPI를 집계하고 추적하기 위해 Notion에 Daily Reports, Weekly Reports, Monthly Reports, Annual Reports 데이터베이스를 사용합니다.
◦
매일, 매주, 매월, 매년 각 멤버별로 해당 기간의 리포트 페이지가 자동으로 생성되어야 KPI 데이터가 관계형으로 연결될 수 있습니다.
•
핵심 요점 2: 주간 리포트 기준 설정 (ISO vs. 단순 주차)
◦
주간 리포트 생성 시, ISO 표준 주차(연초/연말에 주가 걸치는 경우 복잡) 대신, 단순히 **1년 52주를 순서대로 카운트하는 방식 (1주차, 2주차 ... 52주차)**을 사용하기로 결정했습니다. 이는 계산이 단순하고 오류 가능성이 적기 때문입니다.
◦
월요일부터 금요일까지를 한 주로 간주합니다.
•
핵심 요점 3: Make 시나리오를 이용한 리포트 자동 생성 구현
◦
매일 새벽 특정 시간(예: 6시 30분)에 Make 시나리오가 실행되어, 당일의 Daily Report 항목을 멤버별로 생성합니다.
◦
이때, 해당 날짜가 속한 주, 월, 연도의 Weekly, Monthly, Annual Report 항목이 아직 없다면 함께 생성하고, 이미 있다면 기존 항목에 Daily Report를 연결합니다.
◦
Make 시나리오 내에서 멤버 정보를 가져오고, 각 멤버별로 오늘 날짜, 주차, 월, 연도를 계산하여 해당 DB에 리포트 페이지를 생성/연결하는 로직을 구현했습니다. (필요시 특정 팀 제외 필터링 가능 - 예: '컨텐츠 제작팀' 제외)
◦
리포트 제목 형식은 이름 - 날짜 (예: 김민웅 - 2024-04-19) 또는 이름 - 주차 등으로 설정합니다.
•
핵심 요점 4: 멤버 필터링 및 관리
◦
Members 데이터베이스에 '리포트 생성' 체크박스 또는 '팀' 속성을 두어, 리포트를 생성할 멤버(예: 헤드헌터 팀)와 생성하지 않을 멤버(예: 콘텐츠 제작팀, 퇴사자)를 구분합니다.
◦
Make 시나리오는 이 필터링 조건에 맞는 멤버들의 리포트만 생성합니다.
•
주목할 발언: "먼스보다 중요한게 주거든요... 1년은 무조건 52주로 쪼개져 있거든요... 그냥 다 산수해 가지고 52로 쭉 쪼개가지고... 후자로 가져가요 아 그러면 괜찮죠" (주간 리포트 기준을 단순 52주 카운트로 결정)
7. KPI 데이터 자동 집계 로직 연결 (1:05:00 - 1:25:00)
•
핵심 요점 1: 콜/미팅 완료 시 데일리 리포트 연동
◦
콜 리스트 DB에서 '통화 완료'를 체크하면, 해당 콜이 발생한 날짜의 Daily Report 페이지와 자동으로 관계형 연결이 맺어지고, 콜 카운트가 집계되도록 Make 시나리오를 구성합니다. (이전 단계에서 논의)
◦
미팅 리스트 DB (신규 생성 또는 기존 활용)에서도 유사하게 '미팅 완료' 버튼을 클릭하면, 해당 날짜의 Daily Report에 미팅 카운트가 집계되도록 구현합니다. 완료 버튼 클릭 시점의 날짜를 기준으로 연결됩니다. (다음날 누르면 다음날 실적으로 잡힐 수 있으나, 주/월 단위 집계에서는 큰 문제없다고 판단)
•
핵심 요점 2: 신규 고객 확보 시 데일리 리포트 연동
◦
Company 데이터베이스에서 특정 회사의 그레이드(GD)를 2 이상으로 변경한 후, '신규 거래' 버튼을 클릭하면, 클릭한 날짜의 Daily Report에 해당 회사 정보가 연결되고 신규 고객 카운트가 집계되도록 구현합니다.
◦
자동 트리거(GD 값 변경 감지) 대신 버튼 클릭 방식을 사용하는 이유는, GD 값 변경과 실제 신규 거래 확정 시점 사이에 차이가 있을 수 있고, 사용자 실수를 방지하기 위함입니다.
◦
클릭한 사람(담당자) 정보도 함께 기록됩니다.
•
핵심 요점 3: CV 제출 및 인터뷰 진행 시 데일리 리포트 연동
◦
ATS(Notion) 내 CV 데이터베이스에서 특정 액션(버튼 클릭)을 통해 상태가 변경될 때 KPI를 집계합니다.
▪
CV 제출: '이력서 추천 진행' 버튼 클릭 시 (Make 시나리오 4-1 연동), 해당 CV 항목이 생성/업데이트되며, 이 시점에 해당 날짜의 Daily Report와 연결하여 CV 제출 카운트를 집계합니다.
▪
인터뷰 진행: '1차 인터뷰 통과' 버튼 클릭 시 (Make 시나리오 5번 연동), 해당 CV 상태가 업데이트되며, 이 시점에 해당 날짜의 Daily Report와 연결하여 인터뷰 카운트를 집계합니다.
▪
최종 합격(석세스): '합격' 관련 버튼 클릭 시(별도 시나리오 필요), 해당 날짜의 Daily Report와 연결하여 합격 카운트를 집계합니다. (이번 세션에서는 상세 구현 미언급)
•
핵심 요점 4: 데이터 유효성 검사 및 알림 제어
◦
CV 제출과 같이 자동 알림(예: 카카오 알림톡)이 발송되는 단계에서는, 필요한 정보(예: 포지션 내용, 연락처 등)가 모두 입력되었는지 Make 시나리오 내에서 조건(필터)을 걸어 확인한 후 알림을 발송하도록 설정할 수 있습니다. 정보가 누락된 경우 알림 발송을 막아 불완전한 정보 전달을 방지합니다.
8. 추가 논의 및 다음 단계 설정 (1:25:00 - End)
•
핵심 요점 1: '태스크(Task)' 관리 범위
◦
기존에 만들어둔 Task 데이터베이스의 활용 방안에 대해 논의했으나, 현재 설계 중인 KPI 추적 시스템(콜, 미팅, CV, 인터뷰 등)이 주요 활동을 대부분 커버하므로, 별도의 세부 태스크 관리는 당분간 보류하기로 합니다.
◦
단, 후보자 서칭(TRM - Talent Relationship Management) 관련 활동은 현재 KPI 시스템에서 빠져 있으므로, 추후 TRM 시스템 구축 시 연동 방안을 고려해야 합니다.
•
핵심 요점 2: 목표 설정 기능 추가
◦
데일리 또는 위클리 단위로 KPI 목표치를 설정하고, 실제 달성률을 비교하여 볼 수 있는 기능을 대시보드에 추가하는 것을 다음 단계 과제로 남겨둡니다. (회사 차원의 기본 목표는 주 단위 설정, 개인 목표는 일 단위 설정 가능성 언급)
•
핵심 요점 3: 다음 작업 및 일정 조율
◦
현재까지 구현된 KPI 추적 로직을 바탕으로 실제 Notion 대시보드를 구성하고 시각화하는 작업을 다음 세션에서 진행하기로 합니다.
◦
다음 미팅 일정을 조율합니다. (4월 28일 확정, 5월 1일, 2일은 추후 확정)
•
주목할 발언: "테스크보다는 네 근데 굳이 저는 테스크가 여기서는 필요 없다고 보여지거든요... 여기에 있는 얘네들만 잘 트래킹을 하면은 충분히 의미 있는 값을 뽑아낼 수 있으니까..." (현 단계에서는 KPI 트래킹에 집중하기로 결정)
