개요
이 영상은 “치과/병원 인사·노무 프로세스”를 Notion + Make + 쏠라피(카카오 알림톡/친구톡)로 자동화하면서, 재계약·퇴사·연차·노무사 커뮤니케이션까지 한 번에 설계하는 과정을 담고 있습니다. 단순히 “문자 보내는 자동화”가 아니라,
•
어떤 메세지는 알림톡, 어떤 메세지는 친구톡으로 보낼지,
•
재계약/퇴사 상태를 어떻게 데이터베이스로 표현할지,
•
마지막 근무일·공식 퇴직일·미사용 연차를 어떻게 연결할지,
•
노무사와의 업무 분담을 어떻게 ‘버튼 한 번’으로 정리할지
를 실제 회의와 구현 과정을 통해 구체적으로 풀어냅니다.
최종적으로 이 영상의 흐름을 따라가면, HR 담당자나 원장이 **“한 번 설계해두면, 버튼 클릭만으로 재계약·퇴사·노무 처리까지 굴러가는 시스템”**을 만들기 위한 설계 원칙과 체크리스트를 얻을 수 있습니다. 또한 직원용 대시보드, 기록물(재계약 면담지, 이수증 등) 관리, 유지보수·과금에 대한 현실적인 고민까지 포함되어 있어, 비슷한 시스템을 만들고 싶은 사람에게 “실전 설계 레퍼런스” 역할을 합니다.
주요 학습 포인트
•
알림톡 vs 친구톡: 검수, 메시지 수정 난이도, 자동화 구조를 고려한 채널 선택 전략
•
Notion 멤버/리뉴얼/연차 DB를 중심으로 재계약·퇴사 프로세스를 모델링하는 방법
•
마지막 근무일, 공식 퇴직일, 미사용 연차를 연결해 퇴사 날짜 로직을 설계하는 방법
•
노무사에게 보내야 할 정보(미사용 연차, 퇴사일, 퇴사 사유 등)를 버튼 하나로 정리하는 자동화 패턴
•
직원용 대시보드/조직도를 활용해 각 직원이 자신의 연차·재계약 피드백·이수증 등을 열람하게 하는 UX 설계 포인트
•
프로젝트 막바지에 전체 시나리오를 “끝에서 처음까지” 통으로 돌려보며 검증·유지보수 범위를 정의하는 방법
요약
1. 카카오 알림톡 vs 친구톡 전략 정리
소주제 1: 검수 부담을 줄이는 메시지 채널 선택
•
알림톡은 템플릿 검수(심사)를 거쳐야 해서, 문구를 조금만 바꿔도 다시 검수를 받아야 하는 부담이 있습니다.
•
반대로 친구톡은 검수가 없거나 상대적으로 유연해, 자주 바뀌는 안내·감성 문구·실험적인 카피에 적합합니다.
•
영상에서는
◦
원장님에게 가는 “재계약 알림”은 알림톡,
◦
직원에게 가는 “재계약/퇴사 안내”나 내부 확인용 메시지는 친구톡으로 설계하는 방향을 논의합니다.
소주제 2: 자동화 모듈을 덜 건드리는 설계
•
알림톡 템플릿이 바뀔 때마다 Make 시나리오(모듈)를 수정해야 하는 문제가 있습니다.
•
그래서 “검수 민감한 알림톡은 최소화”하고,
◦
변동 가능성이 크고
◦
문장실험을 자주 할 메시지는
→ Notion DB의 필드(텍스트)만 바꿔도 자동화를 그대로 쓸 수 있는 구조로 친구톡에 몰아넣는 전략을 씁니다.
핵심 원칙: “검수·개발자가 아니라, 운영자가 자주 바꿀 문구는 알림톡이 아니라 친구톡 텍스트 필드로 뽑아라.”
메시지 채널 설계 체크리스트•
이 메시지는 법정/계약 안내처럼 “공식 템플릿”이 필요한가? → 알림톡 후보
•
이 메시지는 연 2–3회 이상 수정될 가능성이 큰가? → 친구톡 후보
•
운영자가 Notion에서 바로 문구를 바꾸길 원하는가? → 친구톡 + Notion 텍스트 필드
•
자동화 모듈(시나리오)을 바꾸지 않고도 운영 가능한 구조인가?
흔히 하는 실수•
“왠지 더 공식적이니까” 모든 것을 알림톡으로 만들고, 나중에 사소한 띄어쓰기 수정에도 검수지옥에 빠짐
•
메시지 템플릿을 Make 안에 하드코딩해서, 운영자가 개발자에게 매번 수정을 요청해야 하는 구조로 설계
내 비즈니스에 적용하기•
우리도 고객/직원 커뮤니케이션에서 **“자주 바뀌는 메시지”와 “거의 안 바뀌는 메시지”**를 나눌 수 있는가?
•
자주 바뀌는 메시지를 Notion·구글시트 같은 데이터베이스로 빼고, 자동화는 “변수만 끼워 넣는 엔진”으로 만들 수 있는가?
더 읽어보기•
“HR 알림톡 활용 가이드”(카카오 비즈니스 센터)류 자료: 알림톡/친구톡 차이, 검수 기준, 템플릿 설계 팁을 이해하는 데 도움
2. 재계약 메시지·면담 프로세스 설계
소주제 1: 멤버 DB를 중심으로 하는 재계약 메시지 발송
•
재계약 알림은 Notion의 멤버 데이터베이스가 중심입니다.
•
재계약 대상자 필터(예: 계약 만료일이 N개월 이내, 상태 = 재직 중)를 걸어, 해당 멤버에게만 친구톡 메시지를 발송합니다.
•
재계약 알림톡과 동일한 내용을 친구톡용 필드로 분리해,
◦
원장용 알림톡(관리용)
◦
직원용 친구톡(면담 안내용)
을 각각 발송할 수 있게 설계합니다.
소주제 2: 재계약 면담 + Notion 기록 구조
•
재계약 면담을 위한 **재계약 면담 기록지(폼)**를 직원에게 링크로 전달하고, 직원이 작성·제출하게 합니다.
•
제출된 기록지는 스캔 또는 파일 형태로 리뉴얼(재계약) 데이터베이스의 해당 직원 페이지 안에 첨부합니다.
•
1차 면담에서 나온 피드백과 “앞으로 1년간의 목표·제안” 등을 리뉴얼 페이지에 계속 누적 기록하여,
◦
다음 재계약 시점에 “작년 목표 대비 성과”를 자연스럽게 회고할 수 있습니다.
핵심 원칙: “재계약은 단순 연장 버튼이 아니라, ‘지난 1년 리뷰 + 다음 1년 설계’를 남기는 학습 루프다.”
프로세스: 재계약 면담 흐름
1.
Notion에서 “재계약 대상자” 필터링
2.
Make/쏠라피를 통해 직원에게 재계약 안내 친구톡 발송 (링크 포함)
3.
직원이 재계약 면담 기록지 작성 및 스캔/파일 업로드
4.
원장이 리뉴얼 DB의 해당 페이지에서 기록지를 확인하고 연봉 협상/피드백 작성
5.
확정된 내용은 리뉴얼 페이지에 남기고, 필요시 직원에게 링크로 공유
재계약 프로세스 실행 체크리스트•
멤버 DB에 “계약 만료일”, “재계약 상태” 필드가 있는가?
•
재계약 대상자 필터(예: 만료일 - 2개월)가 설정되어 있는가?
•
재계약 면담지 링크가 Notion/폼 어디에 저장되어 있는지 명확한가?
•
리뉴얼 DB와 멤버 DB가 Relation으로 연결되어 있는가?
주의하세요: 흔히 하는 실수•
재계약 기록을 “엑셀/종이/노션 여러 곳에 분산”해서, 몇 년 지나면 누가 어떤 조건으로 재계약됐는지 찾을 수 없게 됨
•
직원에게 준 재계약 피드백을 직원만 들고 있고 회사에는 기록이 없어, 분쟁·평가 시 근거 부족
내 비즈니스에 적용하기•
우리 조직에서도 재계약(또는 연봉협상)을 “정기 리뷰 + 다음 스텝 설계”로 기록하고 있는가, 아니면 “연봉 숫자만 바뀌는 의식”인가?
•
리뷰/피드백을 어느 DB에, 어떤 Relation으로 남기면 2–3년 뒤에도 읽기 쉬울지 상상해보기
더 읽어보기•
“OKR·성과관리와 연계된 인사평가 시스템” 자료: 연봉/재계약과 목표관리·피드백을 연결하는 설계 아이디어 얻기
3. 퇴사 프로세스: 마지막 근무일·공식 퇴직일·연차 로직
소주제 1: 두 날짜를 분리해야 하는 이유
•
영상에서 중요한 포인트는 “마지막 근무일”과 “공식 퇴직일(퇴사 처리일)”을 분리하는 것입니다.
•
예를 들어,
◦
직원이 11월 1일까지만 실제로 일하고,
◦
미사용 연차 5일을 “휴가로 소진”한다면
→ 마지막 근무일 = 11/1, 공식 퇴직일 = 11/6 이 되어야 합니다.
•
이 정보는
◦
고용노동부 신고,
◦
다음 직장의 경력 조회,
◦
노무사 퇴직금 정산
등에 모두 영향을 미치므로, 시스템에서 명확히 관리해야 합니다.
소주제 2: 연차·퇴직연금 역할 분담
•
미사용 연차 정산은 이 시스템(원장/관리자)이 계산·확인합니다.
•
퇴직연금 정산은 노무사가 담당하며, 시스템은 노무사에게 필요한 자료(근무기간, 미사용 연차, 퇴사일 등)를 보내는 역할을 합니다.
•
영상에서도 “퇴직연금 정산은 우리가 직접 계산하지 않고, 노무사에게 자료만 넘긴다”는 점을 반복해서 확인합니다.
핵심 원칙: “마지막 근무일은 사람의 일정, 공식 퇴직일은 법·연차가 합쳐진 날짜다. 둘을 헷갈리면 나중에 노동법 지옥에 빠진다.”
퇴사 날짜 설계 체크리스트•
멤버 DB에 다음 세 필드가 모두 있는가?
◦
마지막 근무일(Date)
◦
공식 퇴직일(Date)
◦
미사용 연차 일수(Number)
•
“미사용 연차를 휴가로 소진할지, 돈으로 줄지”에 대한 정책이 정의되어 있는가?
•
퇴사일 입력 시, 연차 소진을 반영해 공식 퇴직일을 계산하는 규칙이 정리되어 있는가?
•
마지막 근무일/공식 퇴직일이 같을 때와 다를 때, 직원에게 나가는 안내 문구가 다르게 처리되는가?
주의하세요: 흔히 하는 실수•
마지막 근무일과 퇴직일을 같은 필드로 관리해서, 연차 소진이 반영되지 않은 상태로 법적 퇴직일이 신고됨
•
노무사에게 “퇴사일만” 보내고, 미사용 연차/근무기간 정보가 제대로 정리되어 있지 않아 추가 질의·정정 반복
내 비즈니스에 적용하기•
우리 조직의 HR 시스템(또는 엑셀)에는 “마지막 근무일”과 “퇴직일”이 분리되어 있는가?
•
미사용 연차를 휴가로 소진하는 케이스와 현금으로 정산하는 케이스를 각각 어떻게 기록할지 규칙을 적어볼 수 있는가?
더 읽어보기•
국내 노동법/근로기준법 해설서의 “연차휴가·퇴직금·퇴직일” 파트: 법적 개념을 정확히 이해하면 DB 설계를 훨씬 깔끔하게 할 수 있음
4. 퇴사 알림톡 + 노무사 메일 + 정산 리마인더 자동화
소주제 1: 한 번의 버튼으로 양쪽(직원·노무사)에 통지
•
퇴사를 확정할 때, Notion에서
◦
퇴사 사유(자진퇴사/권고사직 등)
◦
마지막 근무일
◦
공식 퇴직일
을 입력합니다.
•
“만료” 버튼을 누르면 자동으로:
◦
직원에게 퇴사 안내 친구톡 발송
◦
노무사에게 미사용 연차·퇴사일·퇴사 사유를 담은 메일 발송
이 동시에 진행되도록 설계합니다.
•
퇴사 사유는 드롭다운(권고사직 / 개인사유 등)으로 패턴화해, 나중에 통계·분석도 가능하게 합니다.
소주제 2: 2주 후 급여 정산 리마인더
•
법적으로 퇴직급여는 통상 퇴사 후 14일 이내 지급이 원칙입니다.
•
이를 놓치지 않기 위해, 퇴사일 기준 2주 후에 원장에게
◦
“[이름]님의 퇴사 후 2주가 되었습니다. 급여 정산을 완료해 주세요.”
라는 친구톡을 보내는 리마인더 시나리오를 만듭니다.
•
요일/주말은 상관 없이, 대표에게 가는 알림이므로 “퇴사일 + 14일, 오후 1시” 같은 단순 규칙으로 충분합니다.
핵심 원칙: “퇴사 버튼 한 번에 사람(직원)·전문가(노무사)·미래의 나(정산 리마인더)까지 한 번에 챙겨라.”
프로세스: 퇴사 자동화 흐름
1.
면담 후 퇴사 결정 → 멤버 DB에 마지막 근무일/퇴직일/퇴사 사유 입력
2.
Notion에서 “만료/퇴사 처리” 버튼 클릭
3.
자동화 시나리오 실행
•
직원에게 퇴사 안내 친구톡 발송
•
노무사에게 필요한 정보 메일 발송
•
퇴사일 + 14일에 대표에게 급여 정산 리마인더 예약
4.
퇴사일 당일 또는 18시 이후
•
조직도에서 해당 직원 제거
•
관련 DB 권한 회수
5.
2주 후 리마인더 수신 → 실제 급여 정산 처리
퇴사 자동화 체크리스트•
퇴사 버튼이 실행될 때 “어떤 액션들이 동시에 실행되는지” 명확히 정의되어 있는가?
•
노무사에게 보내야 할 정보 필드는 최소한 아래를 포함하는가?
◦
이름, 부서, 입사일, 마지막 근무일, 공식 퇴직일
◦
미사용 연차 일수
◦
퇴사 사유(코드화)
•
퇴사자에 대한 모든 권한 회수(조직도, 슬랙, Notion 권한 등)가 “퇴사일 기준 언제” 실행되는지 정의되어 있는가?
•
퇴사 후 14일 리마인더가 퇴사일 변경 시 자동으로 갱신되는가?
주의하세요: 흔히 하는 실수•
퇴사 안내는 보내지만, 노무사에게 보내는 정보가 매번 수작업 메일이라 빠뜨리는 항목이 생김
•
퇴사자에 대한 시스템 권한 회수와 급여 정산 리마인더가 분리되어 있어, 둘 중 하나를 잊어버리는 상황 발생
내 비즈니스에 적용하기•
지금 우리 회사에서 퇴사가 발생하면, “누가 어떤 순서로 무엇을 하는지”를 적어보면 몇 단계가 나오는지?
•
그 단계 중에서 “툴이 할 일”과 “사람이 할 일”을 나눠보고, 버튼 하나에 묶을 수 있는 덩어리는 어디까지인지 상상해보기
더 읽어보기•
자동화 도구(Make, Zapier)의 “Delay until date” 기능 설명: 퇴사일 + 14일과 같은 상대 날짜 리마인더 설계 시 필수 개념
5. 직원용 대시보드·조직도·문서 공유 UX 설계
소주제 1: 직원은 자기 것만, 관리자는 전체
•
직원에게는 개별 “대시보드 페이지”를 만들지 않고, 조직도 DB와 필터를 활용해 구현합니다.
•
각 직원은 조직도에서 자신의 카드만 보이도록 필터링하고, 그 카드 안에서:
◦
본인의 연차 사용 현황(Annual Leave)
◦
재계약 리뉴얼 페이지(피드백/목표)
◦
교육 이수증(트레이닝 이수증)
등을 Relation/링크로 엮어 열람하게 합니다.
•
이렇게 하면
◦
관리자는 전체 조직을 한 화면에서 관리하고,
◦
직원은 “자기 정보만 있는 미니 대시보드”처럼 사용할 수 있습니다.
소주제 2: 링크 공유 방식과 권한 설계
•
재계약 피드백 등 민감한 정보는 리뉴얼 DB의 개별 페이지 링크를 복사해, 해당 직원에게만 공유합니다.
•
Notion의 권한 구조를 이용해,
◦
직원은 “자기 리뉴얼/연차 현황 페이지”만 접근 가능
◦
관리자는 전체 DB 접근 가능
하게 설계합니다.
•
스캔한 재계약 면담지, 이수증 등도 각 직원의 관련 페이지에 파일로 첨부하여,
◦
나중에 찾기 쉽고
◦
직원·관리자 모두 동일한 근거를 확인할 수 있습니다.
핵심 원칙: “직원에게는 ‘딱 자기 것만 모여 있는 한 페이지’가 UX다. 그 외는 관리자 우주 안에서만 떠다녀도 된다.”
직원용 UX 체크리스트•
조직도 또는 “My Desk” 페이지에서 직원 한 명이 볼 수 있는 것은 3개 정도 핵심만 남겼는가?
◦
연차 현황
◦
재계약/피드백
◦
이수증/교육 기록
•
직원이 링크를 받으면, 추가 로그인·검색 없이 바로 자신의 페이지로 들어갈 수 있는가?
•
민감한 정보(연봉, 평가 코멘트 등)는 직원에게 보여주고 싶은 것과 숨기고 싶은 것을 구분해 필드/페이지 구조를 나눴는가?
주의하세요: 흔히 하는 실수•
“직원 친화적”을 핑계로 과도하게 많은 정보를 한 페이지에 모아, 직원이 정작 봐야 할 정보(연차/피드백)를 찾지 못하게 함
•
권한 관리를 대충 해서, 다른 직원의 평가·연봉 정보가 노출되는 사고 발생
내 비즈니스에 적용하기•
우리 조직 직원 1명이 “자기와 관련된 정보만 모여 있는 페이지”를 받는다면, 그 안에 꼭 있어야 할 3가지 정보는 무엇일까?
•
지금의 인사 시스템에서 직원이 본인이 받은 피드백/목표/연차를 스스로 확인할 수 있는 창구가 있는가?
더 읽어보기•
조직 내 “Employee Self-Service(ESS)” 포털 사례: 직원이 스스로 인사 정보를 조회하는 UX를 설계하는 힌트
6. 프로젝트 마무리, 전구간 테스트, 유지보수·과금
소주제 1: 끝에서 처음까지 ‘한 번 쭉 돌려보기’
•
영상 후반부에서는 “오늘 남은 1시간 반 안에 전 과정을 다 검증하기는 어렵다”는 판단을 내리고,
◦
별도의 날(예: 11월 29일)을 잡아
◦
입사(이력서) → 재계약 → 퇴사까지 전체 흐름을 통으로 돌려보는 세션을 계획합니다.
•
이때 자동화 결제(Make 유료 플랜 업그레이드)는
◦
실제로 시나리오를 상시 가동할 준비가 되었을 때 하자는 결정도 함께 합니다.
소주제 2: 스코프·데이터베이스 수·비용의 재정렬
•
진행하면서 당초 계획보다 더 많은 DB와 자동화 기능이 생겼고, 그에 따라 견적 조정이 필요해졌다는 대화가 나옵니다.
•
“ERP 대신 Notion·자동화로 구현했다”는 점에서
◦
어느 정도까지를 초기 계약 범위로 보고,
◦
어디부터는 추가 비용으로 볼지
를 다시 조율하기로 합니다.
•
이 부분은 기술적인 설계만큼이나, 프로젝트 매니징·클라이언트 기대치 관리의 중요성을 보여줍니다.
핵심 원칙: “자동화 프로젝트의 마지막 단계는 개발이 아니라, ‘전 구간 리허설 + 스코프 재정의’다.”
프로젝트 마무리 체크리스트•
“입사 → 재계약 → 퇴사” 전체 흐름을 실제 더미 데이터로 한 번 이상 돌려봤는가?
•
그 과정에서 발견된 버그/UX 문제를 모두 이슈 리스트로 만들었는가?
•
현재 구현된 DB 수, 자동화 시나리오 수, 유지보수 범위를 문서로 정리했는가?
•
초기 견적서/계약서와 비교해, 추가로 구현된 범위를 객관적으로 설명할 수 있는가?
주의하세요: 흔히 하는 실수•
개별 기능은 잘 돌아가지만, “처음부터 끝까지 한 직원의 라이프사이클”을 돌려보지 않아 엣지케이스가 터지는 상황
•
기능이 늘어날수록 “이 정도면 ERP” 수준이 되어가는데, 금액·운영 책임 범위를 업데이트하지 않고 양쪽이 서로 오해하게 됨
내 비즈니스에 적용하기•
내가 지금 만들고 있는 시스템(혹은 강의/템플릿)은 “유저의 어떤 전체 여정을 처음부터 끝까지” 다루고 있는가?
•
그 여정을 한 번에 시뮬레이션해 볼 날짜·시간을 캘린더에 잡아두었는가?
더 읽어보기•
프로젝트 매니지먼트 관련 도서(특히 스코프 크립, UAT(User Acceptance Test) 챕터): 자동화/시스템 도입 프로젝트에도 그대로 적용되는 개념들
