타임레코드
00:06:18 마지막 테스트 세션 시작 및 오늘 진행 방식 간단 조율
00:07:45 견적 금액이 예상보다 3배 높게 나온 이유와 데이터베이스/ERP 범위 오해 정리
00:12:03 대시보드·AI 시나리오 별도 과금 구조와 중간 정산·커뮤니케이션 개선 팁 논의
00:16:10 총 금액을 1,000만 원으로 재조정하고 교육 활용 동의, 4개월 무상 유지보수 구조 합의
00:24:17 Make 코어 구독(만 개 크레딧) 결제와 실제 사용량·비용 구조, 다른 구독 서비스 점검
00:32:06 실제 채용 케이스로 인사 프로세스 시연 시작: 구글 드라이브 인사 폴더 구조와 이력서 업로드
00:46:44 구글 드라이브에 올린 이력서를 버튼/스케줄로 OCR·파싱해 노션 DB에 자동 적재하는 흐름 확인
00:58:42 서류 합격자 상태 변경 시 Slack 인사 채널로 인터뷰 일정 조율 알림 보내는 자동화 구성
01:04:22 인터뷰 기록·평가 후 인터뷰 합격/보류/우수인재 처리와 멤버·급여 DB 연동 방식 설계
01:56:21 조직도에서 소속·직책 정리, 원장/직원 노출 정보 구분 및 관리자 대시보드 구조 점검
02:00:29 직원 전화번호·이메일·은행 계좌·주소 변경을 위한 개인정보 수정 요청 DB·폼 설계
02:11:04 개인정보 수정 요청을 파싱·입력하는 두 개의 시나리오 추가 필요성과 처리 흐름 논의
03:15:08 경영팀 온보딩 전용 DB로 인터뷰·레주메·멤버 DB 권한 일괄 부여/제거 자동화 구현
03:19:07 연차·오프·파트타임 근무기록 등 남은 인사 영역을 다음 세션에서 실제 데이터로 검증하기로 합의
03:24:47 전 직원 Gmail·노션 계정 정리, 이력서·통장 사본 스캔 준비 후 실제 10명 온보딩 테스트 계획
개요
이 영상은 치과 원장님과 컨설턴트가 Notion·Make·외부 SaaS를 활용해 채용·인사·온보딩 시스템을 실제로 구축·점검하면서,
① 견적·과금 구조에 대한 오해를 풀고,
② HR 워크플로우 전체를 자동화 가능한 단위로 쪼개고,
③ 유지보수·교육·권한 구조까지 포함한 “살아 있는 전사 시스템”을 어떻게 설계할지 정리하는 과정입니다.
단순히 화면을 만드는 수준이 아니라, 데이터베이스 구조–시나리오–대시보드–권한–운영비–유지보수를 하나의 생태계로 보고,
실제 병원에서 반복적으로 일어나는 채용·연봉·연차·교육·개인정보 변경 등의 이슈를 “버튼과 시나리오”로 흡수하는 방법을 다룹니다.
영상 전체는 “한 번 구축해서 끝”이 아니라, 실제 사용·피드백·수정이 계속 가능한 구조를 만드는 것을 목표로 합니다.
주요 학습 포인트
•
견적은 “시간이 아니라 컴포넌트(데이터베이스·시나리오·대시보드·AI)” 단위로 투명하게 쪼개서 제시해야 오해가 줄어든다.
•
HR 시스템은 “이력서 → 인터뷰 → 합격/보류 → 멤버/급여 DB 반영 → 서류 제출 → 온보딩”의 전체 흐름을 기준으로 설계해야 한다.
•
Notion·Make·Upstage·Solapi 등 구독형 툴은 실제 사용량을 기준으로 최소 플랜을 잡고, 핵심 흐름 몇 개에 집중하는 것이 비용 효율적이다.
•
권한·보안은 “대시보드 분리 + 권한 부여용 DB 분리”로 설계해, 실수로 민감 정보가 공유되지 않도록 방지해야 한다.
•
유지보수는 “초기 무상 지원 + 이후 컨설팅/정기 유지보수 플랜”으로 상품화해, 시스템이 현장에서 계속 진화할 수 있게 해야 한다.
요약
1. 견적·범위 커뮤니케이션: “DB·시나리오·대시보드”를 쪼개서 본다
소주제 1: 견적이 3배로 커 보인 이유 – 컴포넌트를 ‘한 묶음’으로 상상한 차이
•
원장님은 “ERP는 포기했고, 인사 흐름 하나만 한다”고 인식해서
→ 자연스럽게 “하나의 큰 맥락 = 거의 하나의 제품”으로 상상함.
→ 데이터베이스 여러 개도 “한 묶음 속 구조”라고 이해.
•
실제 견적서에는 데이터베이스·시나리오만 품목으로 보였고,
뒤에 대시보드·AI 시나리오가 추가 과금 항목으로 붙으면서
→ “처음 듣는 항목인데, 왜 이렇게 비싸지?”라는 심리적 괴리가 발생.
•
특히 대시보드 하나가 100만 원 단위라는 사실을 중간에 인지하지 못해,
최종 견적에서 놀람 + 오해가 동시에 발생함.
소주제 2: 앞으로의 개선 – 품목 리스트와 중간 정산을 기본 프로세스로
•
향후 B2B 견적에서는 최소한 아래를 품목화해서 미리 공유하는 것이 필요:
◦
데이터베이스(예: 이력서 DB, 인터뷰 DB, 멤버 DB, 급여 DB …)
◦
시나리오(예: OCR 파싱, 인터뷰 알림, 합격 문자 발송, 권한 부여 자동화 …)
◦
대시보드(관리자용, 원장용, 직원용 등)
◦
AI 연동(요약, 분류, 파싱, STT 등)
•
장기간 프로젝트라면 N회 중간 정산 포인트를 합의:
◦
예: 8회 미팅이면 4회차에 “여기까지 진행했고, 현재 과금은 이 정도입니다” 브리핑
◦
이 시점에서 클라이언트는 “여기까지로 마무리 / 더 확장”을 선택 가능
핵심 원칙: 견적은 “시간의 총합”이 아니라 “구현된 구조물의 리스트”로 보여줄수록 공정하다고 느낀다.
견적·범위 커뮤니케이션 체크리스트DB/시나리오/대시보드/AI를 각각 품목으로 나눠서 설명했다.
“필수” vs “옵션” 컴포넌트를 구분해서 제시했다.
미팅 횟수 기준 중간 정산·중간 브리핑 타이밍을 합의했다.
“이 정도까지 오면 대략 얼마”라는 대략 견적 범위를 중간에 다시 한 번 상기시켰다.
주의하세요: 흔히 하는 실수•
“대시보드는 당연히 하나쯤은 그냥 들어가겠지”라는 전제를 서로 공유했다고 착각.
•
“데이터가 늘면 비용이 늘 수 있다”는 추상적 표현만 하고, 실제 예시(라인 아이템)를 안 보여주는 것.
내 비즈니스에 적용하기•
지금 운영 중인 서비스/프로젝트 견적서에서 컴포넌트 리스트를 다시 작성해보자.
“이건 기본, 이건 옵션”을 구분해서 고객에게 어떻게 설명할지 문장으로 적어 본다.
2. 가격 조정·교육 활용 동의·지원 기간: 관계를 깎지 않고 가격을 깎는 법
소주제 1: 1,400만 원 → 1,000만 원 – 할인 논의의 기준 만들기
•
클라이언트는 “3배 비싸다”는 체감을 솔직하게 표현하면서도,
“가치를 깎고 싶지 않다, 진상 고객은 되고 싶지 않다”는 태도를 분명히 함.
•
결국 약 1,000만 원으로 합의:
◦
기존 계약금(235만 원)을 제외한 잔금 조정
◦
일부 시나리오·TV(화면) 항목을 제외해 구조적으로도 맞추는 방식
소주제 2: 교육용 활용 동의 추가 지원 2개월: 가치 교환 설계
추가 지원 2개월: 가치 교환 설계•
컨설턴트 입장:
◦
이번 사례는 복잡한 HR/채용 프로세스를 실제로 다룬 소중한 레퍼런스.
◦
교육용으로 흐름을 설명할 수 있게 되면 큰 자산이 됨.
•
원장님 입장:
◦
시스템을 병원에 완전히 정착시키는 것이 가장 중요.
◦
인사/채용 빈도가 낮아 “60일 안에 충분히 써보고 피드백 줄 수 있을까?”가 고민 포인트.
•
합의안:
◦
교육 목적 활용에 동의하면 무상 유지보수 2개월 + 기존 2개월 = 총 4개월 지원.
◦
이후에는
▪
컨설팅 플랜(새로운 자동화·시스템 확장용)
▪
정기 유지보수 플랜(연 120만 원, 월 15만 원, 월 최대 3회 요청)으로 전환 가능.
핵심 원칙: “가격 인하”는 가치를 깎는 행위가 아니라, “추가 제공 가치 금액”의 구조를 재설계하는 것에 가깝다.
금액”의 구조를 재설계하는 것에 가깝다. 관계를 지키는 가격 조정 체크리스트“가치를 깎고 싶은 게 아니다”라는 메시지를 서로 분명히 주고받았다.
금액 조정의 근거(빠진 기능/옵션, 교육 활용 동의 등)를 명확히 기록했다.
무료 지원 기간과 이후 유료 플랜(컨설팅/유지보수)의 조건을 구분해 설명했다.
내 비즈니스에 적용하기•
내 서비스에도 “교육/사례 활용 동의 시 추가 지원” 같은 가치 교환 옵션을 넣을 수 있을지 떠올려 보고,
구체적인 조건(지원 기간, 활용 범위)을 한 번 문서로 적어본다.
3. 채용·인터뷰·합격 프로세스: 이력서 → 멤버 DB까지 흐름 설계
소주제 1: 이력서–인터뷰–멤버까지의 전체 데이터 흐름
•
핵심 DB 구조:
◦
이력서 DB: OCR/파싱 결과가 들어오는 곳
◦
인터뷰 DB: 서류 합격 이후 인터뷰 일정·평가·합격/보류/우수인재 상태 관리
◦
멤버 DB: 최종 합격 후 실제 직원 정보, 조직도, 급여 연동
◦
급여/셀러리 DB: 연봉·수령 유형 등 민감한 급여 정보 관리
•
프로세스 개요:
1.
지원자의 이력서(PDF)를 구글 드라이브의 지정 폴더에 업로드
2.
Make 시나리오가 새벽마다(or 버튼 트리거) OCR → 파싱 → 이력서 DB 자동 입력
3.
원장님이 이력서 DB에서 서류 합격/불합격 선택
4.
서류 합격 시 인터뷰 DB로 레코드 이동 + 슬랙 알림(인사팀 채널)
5.
인사팀장이 인터뷰 일정 잡고, 인터뷰 결과(합격/보류/우수인재) 입력
6.
인터뷰 합격 시 멤버·급여 DB에 자동 등록(필요 속성만 연동)
7.
합격자에게 문자(알림톡)로 필수 서류 제출 링크 발송
소주제 2: 필드 설계와 오류 디버깅 – “정직원·아르바이트” 케이스
•
오류 사례:
◦
구분값이 “정직원, 아르바이트”처럼 콤마로 두 개 들어가면서 시나리오가 에러 발생.
•
해결 전략:
◦
이력서 단계에서는 해당 필드를 텍스트로 받아두고
◦
실제 구분(정직원/파트타임)은 인터뷰 시 수기로 확정 입력
•
추가 필드 설계:
◦
인터뷰 DB에 “구분(정직원/파트타임)”과 “소속(진료실/데스크/경영/청소/원장 등)”을 명시해
이후 자동화(수습→정직원 전환, 조직도 표시)를 위한 기준값으로 사용.
핵심 원칙: 자동화에서 가장 위험한 것은 “애매한 값”이다. 애매한 값은 최대한 인터뷰/확정 단계에서 사람의 판단으로 정제한다.
채용·인터뷰 자동화 체크리스트이력서–인터뷰–멤버–급여로 이어지는 DB 간 관계가 명확하게 정의되어 있다.
“합격/불합격/보류/우수인재” 등 상태값과 그에 따른 후속 액션이 정리되어 있다.
인터뷰 DB에 “구분·소속·입사일·희망/확정 급여” 등 필수 필드가 준비되어 있다.
합격 시 발송되는 문자 템플릿(필수 서류 안내, 제출 링크)이 정해져 있다.
주의하세요: 흔히 하는 실수•
이력서 포맷이 제각각인데도, “한 번에 완벽하게 파싱될 것”을 기대하는 것.
•
민감 정보(급여, 계좌 등)를 여러 DB에 중복 입력하게 만들어, 권한·보안 관리가 복잡해지는 것.
내 비즈니스에 적용하기•
우리 조직의 채용 흐름을
“지원 → 서류검토 → 인터뷰 → 합격/보류/불합격 → 온보딩”
5단계로 그려보고, 각 단계에 필요한 DB·필드·알림을 목록으로 적어본다.
4. SaaS 구독·운영 비용 전략: “최소 플랜 + 사용량 모니터링”
소주제 1: Make·Upstage·LLM·솔라피·노션의 역할과 비용 감각
•
Make:
◦
코어 10,000 ops 플랜(연 108달러 수준) + 필요 시 Extra 크레딧(1,000 ops당 1.13달러).
◦
컨설턴트 본인은 월 40,000 ops 정도 쓰지만, 병원은 만 개 내외로 충분할 것으로 예상.
•
Upstage OCR:
◦
10달러 충전 후 실제 차감은 0.x 달러 수준 → 사실상 장기간 사용 가능.
•
LLM(예: ChitChat/소형 모델):
◦
나노/미니 모델만 활용해 월 5달러 수준으로 운영 가능.
•
Solapi, 문자·알림톡:
◦
건당 몇십 원 단위의 사용료로, 필수 알림에만 활용.
•
Notion:
◦
AI 도입을 위해 비즈니스 플랜으로 업그레이드 권장.
◦
별도 STT 도구(Ti.ro 등)는 “실시간 요약이 꼭 필요한 경우”에만 사용.
소주제 2: 도구 개수보다 “핵심 시나리오 개수”에 집중하기
•
실제로 유지에 필요한 것은:
◦
Notion 과금 + Make 과금 + 소량의 OCR/LLM/문자 비용
◦
합산하면 대략 월 4~5만 원 선에서 핵심 프로세스 유지 가능.
•
중요한 것은 “몇 개나 쓰는가?”가 아니라,
◦
채용/인사/연차/교육 등 핵심 워크플로우 몇 개를 자동화했느냐.
•
병원 같은 오프라인 조직에서는:
◦
“완전 자동화”보다 “반자동 + 사람 컨펌” 조합이 실제 운영에 더 맞는 경우가 많음.
핵심 원칙: 자동화 인프라 비용은 “서버 비용”이 아니라 “매달 시간을 사는 구독료”다. 핵심 워크플로우 몇 개만 잘 잡아도 충분히 값어치를 한다.
구독·비용 설계 체크리스트각 도구의 역할(예: OCR, 문자, STT, DB, 오케스트레이션)을 한 줄씩 정의했다.
월 기준 목표 사용량(ops, 문자 건수 등)을 대략 계산해 보았다.
“없어도 되는 도구”와 “필수 도구”를 구분했다.
일주일에 한 번 사용량/크레딧을 체크하는 루틴을 정했다.
더 읽어보기•
“Workflow Automation for Small Teams” 류의 실전 케이스 스터디:
소규모 조직이 몇 개 도구만으로도 큰 효과를 내는 사례를 통해,
“도구 개수보다 시나리오 설계가 중요하다”는 감각을 얻을 수 있다.
5. 권한·보안·개인정보 변경: 대시보드 분리와 승인 기반 업데이트
소주제 1: 권한 구조 – 관리자 대시보드 vs 인터뷰/멤버/급여
•
인터뷰 페이지·이력서·멤버 DB는 서로 연결되어 있지만,
급여/셀러리 DB는 경영팀장이 보지 못하도록 분리.
•
인터뷰 페이지 접근:
◦
원장 + 경영팀장만 접근하도록 개별 초대.
◦
멤버 DB는 보되, 연봉 세부 정보는 별도 DB로 분리해 비노출.
•
권한 부여용 별도 DB를 만들어:
◦
“이 사람에게 인터뷰/레쥬메/멤버 DB 권한을 부여/회수한다”를 버튼 한 번으로 처리.
◦
실수로 직원 전체에게 인터뷰 DB를 공유하는 리스크를 줄임.
소주제 2: 개인정보 변경 – 폼 제출 + 관리자 승인 구조
•
직원이 바꿀 수 있는 정보:
◦
전화번호, 이메일, 은행·계좌, (추가로) 집 주소.
•
흐름:
1.
직원이 Notion 폼(개인정보 수정 요청 DB)에 변경 내용을 입력
2.
Make 시나리오가 제출을 감지 → 슬랙으로 관리자 알림
3.
관리자가 해당 레코드를 열어 내용을 확인
4.
버튼(“반영”)을 누르면 멤버 DB에 자동으로 업데이트
•
통장 사본은 별도 파일 업로드로 받아,
계좌번호 파싱 시 실수를 줄이는 패턴도 함께 사용.
핵심 원칙: 개인정보는 “직원이 직접 DB를 고치는 구조”가 아니라, “요청 → 검토 → 반영” 구조로 설계해야 사고가 안 난다.
권한·개인정보 관리 체크리스트급여·연봉 정보는 별도 DB로 분리되어 있고, 최소 인원에게만 권한이 부여되어 있다.
인터뷰/이력서/멤버 DB에 접근 가능한 사람과 이유가 명확하다.
개인정보 수정 요청용 폼·DB가 있고, 승인 후 반영 버튼이 준비되어 있다.
개인정보 수정이 발생하면 슬랙 등으로 관리자에게만 알림이 간다.
주의하세요: 흔히 하는 실수•
“직원들도 노션 잘 쓰니까 알아서 조심하겠지”라고 믿고, DB 전체 편집 권한을 부여해 버리는 것.
•
개인정보 변경을 메신저로만 받고 기록/로그를 남기지 않는 것.
내 비즈니스에 적용하기•
현재 조직의 “연봉/계좌/연차/주소” 등 민감 정보가 어디에, 누구 권한으로 있는지 그려 보고,
① 분리해야 할 DB, ② 폼+승인 구조로 바꿔야 할 항목을 표시해 본다.
6. 온보딩·조직도·다음 단계: 시스템을 ‘진짜로’ 굴려 보기
소주제 1: 실제 직원 데이터로 한 번 쭉 “리허설”하기
•
다음 미팅(예: 12월 6일)에서 할 일:
◦
직원 10명의 이력서·통장 사본 등 서류를 스캔해 준비
◦
이미 받아 둔 Gmail 계정·노션 가입 상태 점검
◦
노션 계정 이름을 “본명(성명)” 형식으로 정리
◦
슬랙 초대 및 알림 테스트
•
이 세션에서:
◦
이력서 → 파싱 → 인터뷰 → 합격 → 멤버·급여 반영 → 서류 제출 → 교육 이수 → 조직도 반영까지
한 번에 실제 데이터로 테스트.
소주제 2: 조직도·연차·교육·신규 기능의 확장 포인트
•
조직도:
◦
소속(데스크, 진료실, 경영/마케팅, 청소, 원장)을 기준으로 오거나이그램 구성.
◦
소속 없음인 사람들을 “소속 없음” 그룹에서 적절한 팀으로 이동 → 리프레시 버튼으로 반영.
•
연차·오프·이수교육:
◦
직원 대시보드에서 연차/오프 신청 → 관리자 대시보드에서 승인 처리.
◦
이수교육 증빙 업로드 → 구글 드라이브 저장 → 미이수 현황 대시보드로 관리.
•
추가 아이디어:
◦
직원 개인정보 수정 폼 버튼을 직원 대시보드에 배치.
◦
페이닥터/원장 포지션 추가 시, 자격증·소속·조직도에 반영되는 항목 점검.
핵심 원칙: 시스템은 “이론상 되는 흐름”으로 끝나지 않는다. 실제 직원 데이터를 넣고 굴려 봐야 진짜 문제와 개선 포인트가 드러난다.
다음 세션 준비 체크리스트모든 직원의 이력서와 필수 서류가 스캔 또는 PDF로 준비되어 있다.
전 직원의 Gmail·노션 가입 및 이름 정리가 끝났다.
슬랙 초대 및 기본 채널 구성이 완료되었다.
테스트 중 직원들에게 갈 알림(문자/메일/카톡)에 대한 사전 공지가 되어 있다.
