개요
이 영상(스크립트)은 치과 조직의 ‘근태/연차/오프/자격 이수/급여’ 운영을 노션 데이터베이스 + 자동화(Make/폼/슬랙)로 굴릴 때, 실제로 현장에서 터지는 예외 케이스를 어떻게 처리할지를 끝까지 “운영자 관점”에서 점검하는 세션입니다. 핵심은 ‘연차 신청’ 같은 단일 기능이 아니라, 신청 → 승인 → 스케줄 반영 → 리포트 집계 → 취소/반려/오류 처리 → 감사(로그) 유지까지 전 과정을 안정적으로 만드는 겁니다.
특히 인상적인 포인트는 두 가지예요. 첫째, 취소/오류/정정 같은 ‘지저분한 현실’을 시스템 밖으로 버리지 않고, DB에 기록으로 남기는 방식(캔슬 DB는 삭제 금지, 상태로 처리). 둘째, 노션에서 자주 놓치는 권한(특히 링크드 DB 권한)과 버튼 실행 권한 문제를 “구조적으로” 해결한 부분입니다.
결과적으로 시청자는 “템플릿”이 아니라 **운영 규칙(정책) + 데이터 모델(관계형) + 버튼/상태 머신 + 예외 처리(슬랙 노티)**로 시스템을 굴리는 감각을 얻게 됩니다.
주요 학습 포인트
•
연차/오프 취소는 ‘삭제’가 아니라 ‘상태 변경(취소/보류/진행)’으로 처리해야 로그와 감사가 살아남는다.
•
취소 요청(보류) → 관리자 확인(취소/반려) → 스케줄/집계 자동 반영의 상태 머신을 설계한다.
•
링크된 데이터베이스까지 권한을 줘야 버튼/편집이 정상 동작한다(원본 DB만 주면 절반만 된다).
•
*스케줄 오류/오프 누락 같은 진단용 결과는 “확인 후 일괄 삭제”**하는 운영 루틴이 필요하다.
•
이수교육(보수교육) ‘미이수/해당사항없음’은 자격증 취득일 기준 로직이 핵심이며, 데이터 수집 설계가 성패를 가른다.
요약
1. 연차/오프 취소의 4가지 케이스를 ‘상태 머신’으로 정리하기
핵심 개념 및 이론(운영 관점)
•
취소는 “기록 제거”가 아니라 **“기록 유지 + 상태 변경”**으로 다뤄야 분쟁/확인/감사에 강해집니다.
•
취소 케이스는 현실적으로 다음처럼 갈라집니다.
◦
(A) 신청 후, 날짜 지나기 전 취소 요청
◦
(B) 날짜가 지났지만 실제로 안 썼다고 주장하며 취소 요청
◦
(C) 취소 요청 날짜를 잘못 넣어서 관계형이 안 맺힘(오류)
◦
(D) 취소 요청 자체가 실수(취소하면 안 됨 → 반려 필요)
프로세스/단계
1.
직원이 취소 폼 제출 → 캔슬 DB에 레코드 생성
2.
캔슬 DB 레코드가 스케줄 DB와 관계형으로 매칭(이름+날짜)
3.
관리자 대시보드에서 보류 목록 확인
4.
버튼으로 최종 처리
•
취소 확인 → 스케줄 상태 “취소”
•
취소 반려(=원복) → 스케줄 상태 “진행” 유지/복귀
시각적/직관적 요소(텍스트 다이어그램)
•
상태 흐름(추천)
◦
보류(취소요청) → 취소(카운트 제외)
◦
보류(취소요청) → 반려(진행 유지)
◦
관계형 없음(날짜불일치) → 오류 노티(슬랙)
핵심 원칙: “취소는 삭제가 아니라 상태다. 상태는 곧 운영 규칙이다.”
취소 운영 체크리스트•
캔슬 DB 레코드는 삭제하지 않는다(실수 포함).
•
카운트/리포트는 ‘진행’ 상태만 집계하도록 만든다.
•
‘보류’는 “요청은 왔지만 아직 확정 아님”이라는 뜻으로 명확히 정의한다.
•
날짜 불일치로 관계형이 안 맺히면 슬랙에 오류 노티를 보내 운영자가 즉시 알아채게 한다.
흔히 하는 실수•
“실수로 취소 요청했으니 레코드 지우면 되죠?” → 지우면 감사 로그가 사라지고, 나중에 “난 요청했는데요?”에서 폭발합니다.
템플릿: 취소 정책 문구(사내 공지용)•
“취소 요청은 언제든 제출 가능하나, 시스템 반영은 관리자 확인 후 확정됩니다.”
•
“취소 요청 기록은 운영 로그로 남으며 삭제되지 않습니다(실수 요청 포함).”
•
“요청 날짜가 실제 신청 날짜와 다를 경우 자동 반영되지 않으며 오류 안내가 발송됩니다.”
2. ‘취소 확인’만 있으면 위험하다: 반려 버튼(원복) 추가 설계
핵심 개념
•
관리자 입장에서 가장 무서운 건 **“잘못 눌렀을 때 되돌릴 방법이 없는 버튼”**입니다.
•
그래서 “취소 확인”과 쌍을 이루는 “취소 반려(=원복)” 버튼이 필요합니다.
프로세스
1.
보류 목록에서 요청 내용 검증(정말 취소가 맞나?)
2.
맞으면 취소 확인
3.
아니면 취소 반려로 상태를 진행으로 돌림(요청 레코드는 유지)
버튼 네이밍 가이드•
취소 확정: 취소 확인
•
취소 거절/원복: 취소 반려(가장 명확함)
주의하세요•
“연차 맞아?” 같은 밈 네이밍은 운영자끼리는 웃기지만, 시간이 지나면 의미가 휘발됩니다. 정책 용어로 남기세요(취소/반려/보류/진행).
3. 링크드 DB 권한 이슈: “원본만 권한 주면 버튼이 안 눌린다”
핵심 개념
•
노션 대시보드는 보통 **원본 DB + 여러 개의 링크드 DB(뷰)**로 구성됩니다.
•
버튼/편집이 안 되던 원인은, 원본 DB 권한만 주고 링크드 DB 권한을 안 준 것.
프로세스/단계(해결 루틴)
1.
대시보드 하단에 존재하는 모든 링크드 DB를 식별
2.
각 링크드 DB의 ID/권한 대상 확인
3.
권한 부여(원본 + 링크드 모두)
4.
최종적으로 “대시보드에서 버튼 클릭/속성 변경”이 되는지 검증
핵심 원칙: “대시보드의 작동 범위 = 원본 DB + 링크드 DB 전체 권한의 합집합”
권한 점검 체크리스트•
버튼이 있는 페이지에서 링크드 DB가 몇 개인지 먼저 센다.
•
‘관리자만 편집 가능’과 ‘운영자는 버튼만 가능’ 같은 역할을 분리한다.
•
권한을 위임할 책임자(예: 실장/경영팀장)를 명확히 지정한다.
4. 신청 → 승인 → 스케줄 반영: 운영자가 ‘캘린더 뷰’로 보는 이유
핵심 개념
•
표 뷰는 날짜 맥락이 흐려져 승인 실수가 늘어납니다.
•
승인 업무는 캘린더 뷰로 훑고, 마지막에 일괄 승인하는 방식이 안정적입니다.
프로세스
1.
관리자 대시보드에서 신청 모음 확인
2.
캘린더로 일정 충돌/누락 감지
3.
개별 승인 또는 일괄 승인
4.
승인되면 직원 페이지/리포트에 반영
승인 운영 체크리스트•
신규 신청은 “승인 전” 상태에서만 대기열에 보이게 필터
•
승인 버튼은 “필요 조건(필터)”이 맞을 때만 작동하게 설계(오작동 방지)
•
승인 후에도 날짜 수정은 가능하되, 수정은 캘린더에서 하게 유도
5. 스케줄 오류 체크/오프 누락: ‘진단 결과는 소모품’으로 다루기
핵심 개념
•
스케줄 오류 체크는 “운영 진단”용입니다.
결과 레코드는 쌓아두면 쓰레기장이 됩니다 → 확인 후 삭제가 정답.
프로세스
1.
오류 체크 시나리오 실행(크레딧 소모 큼)
2.
결과 목록에서 진짜 오류만 확인
3.
오프 개념이 없는 대상(사무직/파트타임/고정휴무)은 “무시 규칙” 적용
4.
결과 레코드 전체 삭제
흔히 하는 실수•
오프 누락 리스트를 “진짜 누락”으로 오해하고 다 고치려 든다.
→ 파트타임/고정휴무/직군별 정책이 다르면, 누락처럼 보이는 정상 데이터가 섞입니다.
템플릿: 직군별 오프 정책 메모(운영자용)•
정직원(진료): 오프 신청 필수
•
파트타임: 고정 요일 근무 → 오프 신청 없음(오프 체크 제외)
•
사무직(주 5일): 토요일 고정 오프 → 오프 체크 제외
6. 슬랙 운영: 공지 채널 전체 + 인사 채널 제한 초대
핵심 개념
•
슬랙은 “업무 대화 저장소”가 아니라 노티 수신 장치로 쓰는 전략.
•
채널은 단순하게:
◦
공지사항(전체 초대)
◦
인사과(경영팀장 등 제한 초대)
초대 체크리스트•
팀원 초대는 이메일 기반(이름으로 검색 안 되는 경우가 많음)
•
직원은 모바일 앱 설치 유도(노티 목적)
•
메시지 보존 기간은 “노티용”이면 짧아도 괜찮음(지식은 노션에)
7. 이수교육(보수교육) 자동화: 업로드 → 드라이브 저장 → 노티 → 확인 완료
핵심 개념
•
이수증 제출은 문서 흐름입니다:
제출(폼) → 파일 저장(드라이브) → 레코드 생성(DB) → 슬랙 노티 → 관리자 확인 완료
•
노션 업데이트/필드 변경으로 자동화가 깨질 수 있으니 **“필드 변경 감지 + 시나리오 점검”**이 필요합니다.
프로세스
1.
이수증 업로드 제출
2.
자동화가 구글 드라이브 폴더에 저장
3.
DB에 레코드 생성 및 링크
4.
관리자 대시보드에서 확인 완료 처리
운영 체크리스트•
기존 종이로 받은 이수증(소량)은 “신규 레코드 수동 생성 + 파일 첨부”로 처리(7~8장 정도는 수동이 효율적)
•
확인 완료 버튼이 “상태 전환 + 집계 반영”을 하도록 일원화
8. ‘미이수/해당사항없음’ 로직의 핵심: 입사일이 아니라 ‘자격증 취득일’
핵심 개념
•
1년차 면제 같은 규정은 보통 입사일이 아니라 면허/자격 취득 시점을 기준으로 판단합니다(스크립트에서도 이 방향으로 로직 수정).
•
그래서 데이터 모델에 반드시 들어가야 하는 필드는: 자격증 타입 + 자격증 취득일.
프로세스
1.
이력서 파싱으로 들어오는 자격증명(오염됨)을 표준 값(예: 5~6개 옵션)으로 정규화
2.
자격증 사본(면허증/증명서)에서 취득일 추출
3.
취득일 기반으로
•
해당사항없음(1년차)
•
이수 대상(2년차+)
를 자동 산출
주의하세요•
이력서 OCR 결과를 그대로 쓰면 “이상한 자격증명”이 들어와서 전체 로직이 무너집니다.
→ 자격증명은 반드시 운영자가 표준 값으로 교정하게 하세요.
템플릿: 자격증 데이터 정규화 규칙•
허용 값(예시): 치위생사 / 치과기공사 / 간호사 / 간호조무사 / 기타(데스크)
•
파싱 값이 허용 값 밖이면 “확인 필요” 상태로 자동 태깅
•
확인 완료 전까지는 이수 집계에서 제외
더 읽어보기(개념 확장)•
“상태 머신(State Machine)” 관점으로 업무 프로세스를 설계하는 글/강의(워크플로우 설계에 체감이 큼)
•
“데이터 정규화(Normalization)”의 실무적 의미(완벽한 DB 이론보다 ‘표준 값 강제’가 중요)
9. 원장 대시보드 급여/오버타임: ‘입력’과 ‘정산(0으로 만들기)’를 분리
핵심 개념
•
오버타임은 매일 입력이 이상적이지만 현실적으로 어렵습니다.
그래서 전략을 분리합니다:
◦
입력: 그때그때 또는 월말에 몰아서
◦
정산: 지급 시점에 “정산 완료”로 0 처리 + 기록은 남김
프로세스
1.
오버타임 입력(업무 종료시간 기반, 분 단위 산출)
2.
개인별 누적 합산
3.
지급 시 오버타임 정산 완료 버튼 클릭
4.
대시보드에서는 사라지고, 지급 기록(히스토리)에는 남음
정산 체크리스트•
정산 버튼은 “0으로 만들기”가 아니라 **‘지급 완료 상태 전환 + 집계 제외’**가 본질
•
상반기/하반기 지급 정책이면 기간 필터를 강하게 걸어 실수 방지
흔히 하는 실수•
날짜를 잘못 넣으면 금액이 폭발(“부자 되는” 버그)
→ 날짜 입력 UI/검증 규칙을 강화하거나, 입력 범위를 제한하세요.
10. 파트타임 근태 엑셀 → 노션: 값 붙여넣기 + 자동화 실행 + 데이터 재활용
핵심 개념
•
월별 근태를 엑셀에서 가져오는 경우, 노션에는 “원본 저장”이 아니라 가공/집계용 데이터만 넣는 편이 관리가 쉽습니다.
•
붙여넣기는 서식 없이 값만(대량 붙여넣기 안정성).
프로세스
1.
엑셀에서 헤더 제거 후 전체 복사
2.
노션에 “값만” 붙여넣기(서식 제거)
3.
자동화 실행(지난달 값 추출/레코드 생성)
4.
검증 후 원본 임시 데이터 삭제 → 다음 달 재활용
운영 체크리스트•
“출근/퇴근 시간이 있는 행만” 필터링 기준을 명확히(이번 스크립트에서 이 기준이 핵심으로 떠오름)
•
자동화 결과가 너무 적게/많게 들어오면 기준부터 의심한다(사람 전체가 들어가면 기준이 잘못된 것)
11. 결근/조퇴 신청 설계: 결근은 날짜, 조퇴는 ‘시간’이 핵심
핵심 개념
•
결근: 날짜만 있으면 됨
•
조퇴: 시간이 있어야 급여 차감/추가 근무 판단이 가능
•
시간 입력은 자유도를 주면 파싱이 망가집니다 → 입력 규격을 강제해야 합니다.
프로세스(추천 입력 규격)
1.
유형 선택: 결근 / 조퇴
2.
결근: 날짜만
3.
조퇴: 날짜 + 조퇴시간(또는 시간 범위)
4.
사유(비고) 필수(최소 텍스트)
조퇴 입력 규칙 체크리스트•
분 단위는 10분 단위 정도로 절충(운영 합의)
•
시간 표기는 단일 포맷으로(예: HH:MM)
•
“9시부터 8시까지” 같은 자연어는 금지(파싱 지옥문)
템플릿: 조퇴 입력 폼 문구•
조퇴 시간은 HH:MM 형식으로 입력해 주세요. (예: 15:30)
•
분은 10분 단위로 입력해 주세요. (예: 15:10, 15:20)
12. 기타 운영 메모: 프린트, 생일 캘린더 생성 시점, ‘노션 스레드(노레드)’ 도입
핵심 개념
•
노션 출력은 기본적으로 PDF로 내보낸 뒤 인쇄(인쇄 UX는 아직 제한적)
•
생일 캘린더 같은 “연 단위 생성 데이터”는 특정 시점(예: 1월 1일)에 일괄 생성되도록 설계되어 있을 수 있음
•
직원들이 노션을 ‘쓰게’ 만드는 장치로 **사내 스레드형 게시판(노레드)**을 고민: 재미/참여가 온보딩의 연료가 된다
핵심 원칙: “도입의 본질은 기능이 아니라 ‘습관’이고, 습관의 연료는 ‘재미 + 리더의 사용’이다.”
