노션으로 신청-승인 구조의 휴가 시스템 만들기

결론은 그냥 Flex 돈 주고 쓰세요 제발.

얼마 전에 노션 초보자들에게 바치는 꿀팁 10가지라면서 노션의 자잘한 기능들을 소개했다. 이 글을 읽은 사람이라면 이렇게 생각했을 가능성이 높다. 잘 쓰면 좋다는데 그래서 어떻게 쓴다는 건데? 궁금증만 커진다. 그래서 이번에는 한 가지 사례를 소개해보려고 한다.

최근에 이전 직장 동료가 연락이 왔다. 하는 말이 회사에서 쓸 연차대장이 필요한데, 노션으로 구현을 해보려고 한다는 것이었다. 여차저차 얘기를 하다고 흥미가 생겨 내가 만들어주겠다고 했다.

사실 정확히는 내가 만든 건 아니고 기존의 노션 연차대장 템플릿이라면서 돌아다니는 좋은 것들이 많기 때문에 그것을 살짝 변형한 거라 할 수 있다. 여튼 이 연차대장 만들기에 있어서 몇 가지 조건들이 있었는데 다음과 같았다.

조건

1. 연차 신청 후 담당자의 승인 과정이 필요하다. (신청 - 승인 구조)

2. 서로의 연차 잔여 개수를 공유되지 않아야 한다.

3. 구성원들이 노션을 사용하는데 익숙치 않으므로 사용법이 단순해야 한다.

위와 같은 3가지 조건을 충족하는 연차대장을 만들 필요가 있었고, 기존의 노션으로 만든 연차대장 템플릿을 검색하여 적합한 것을 골랐다.

---

1. 기존 템플릿 분석 (포스타입 연차대장)

우선, 검색하여서 선택한 템플릿을 분석할 필요가 있었다.(구현 원리를 알아야 활용을 할 수 있으므로) 적합한 템플릿으로는 포스타입 팀에서 만든 연차대장 템플릿을 사용하기로 했다. 포스타입 팀의 연차대장 템플릿에는 휴가 사용 리스트와 연차 현황이라는 두 개의 table로 구성되어 있다.

먼저, 휴가 사용 리스트 table부터 확인해보면 사용 개수를 휴가 기간과 종류에 따라 자동으로 계산하도록 수식이 만들어져있다. 사용 개수 수식부터 천천히 살펴보면,

① 사용개수 / dateBetween(end(prop("일자")), start(prop("일자")), "days") + 1

→ 시작하는 날짜 - 끝나는 날짜 +1 (입력 날짜일 수만큼 연차 사용 개수가 늘어남)

→ 예를 들어 2021.06.03~2021.06.04이면 4-3+1 = 2로 사용 개수가 2가 됨

→ 2일 미만의 연차의 경우 2021.06.03~2021.06.03이므로 3-3+1 = 1로 사용 개수가 1이 됨

→ 2일 미만인 경우 일자에 날짜를 입력하지 않더라도 0-0+1 = 1이기에 만들기만 하면 사용 개수가 1이 됨

② 사용개수 / - toNumber(contains(prop("종류"), "반차")) / 2

→ 휴가 종류를 반차로 선택하면 1로 바뀜, 그것을 2로 나눈 다음에 ①에서 뺌 

→ 그러므로 휴가 종류를 반차로 선택하면 1-1/2 = 0.5로 사용 개수가 0.5가 됨

→ 반반차와 시차도 이하 동일한 원리로 적용

그 다음은 유급 체크 그리고 유급 체크 property와 연결되어 있는 연차 현황 table이다.

③ 유급 체크(Related to 연차현황), 사용(Rollup / Related to 휴가 사용 리스트, 사용 개수, Sum)

→ 유급 체크(Relation): 총 사용한 연차 개수를 계산하기 위해 휴가 사용 리스트와 연차 현황을 연결

→ 사용(Rollup): 휴가 사용 리스트에서 사용 개수의 총합(Sum)을 표시

→ 휴가 종류 중 유급 휴가에 해당하는 경우, 유급 체크란에 휴가자의 성함을 입력하면 자동으로 연차 현황에서 연차 개수가 소모되어 표시됨

ⓓ 완료 / smaller(end(prop("일자")), now( ))

→ 휴가 사용으로 입력한 날짜가 오늘보다 전이면 체크(true)

→ 당일 기준으로 휴가가 이미 사용되었다면 완료(true) 아직 사용 전이라면 완료X (false)를 나타냄

2. 기존 템플릿 변형 - 특성(property), 수식(fomula)

이렇게 기존 템플릿의 구조를 분석해 보았는데, 나의 경우는 이렇게 쓰지 않고 다른 방식으로 변형하여 사용했다. 그래서 아래 변형한 수식에 대해서 정리해보았다.  

① property 순서 변경, 추가 및 제거

→ 날짜 - 이름 - 연차 현황(유급 체크) - 종류 - 사용 개수로 변경

→ 기존 완료 제거, 새로 담당자 추가

② 종류 내용 수정

→ 연차, 오전 반차, 오후 반차, 생일 오전 반차, 생일 오후 반차로 구분

→ 이후 캘린더에 원활한 표시를 위해 오전, 오후로 나눠서 구분

③ 사용 개수 / dateBetween(end(prop("날짜")), start(prop("날짜")), "days") + 1

→ 기존과 동일

④ 사용 개수 / - toNumber(prop("종류") == "오전 반차") / 2

→ 휴가 종류를 오전 반차로 선택하면 0.5로 계산 그것을 ①에서 빼서 0.5로 적용

→ 오후 반차도 오전 반차와 동일하게 0.5로 적용

⑤ 사용 개수 / - toNumber(prop("종류") == "생일 오전 반차")

→ 휴가 종류를 생일 오전 반차로 선택하면 1로 계산 그것을 ①에서 빼서 0으로 적용

→ 생일 오후 반차도 생일 오전 반차와 동일하게 0으로 적용

→ 이후 무급 형태의 휴가 종류 추가 시 ⑤를 복붙하고 생일 오전 반차 부분을 해당 휴가 종류로 변경

⑤ 연차 현황(Related to 연차 현황)

→ 기존에는 유급 휴가 시에만 연차 현황과 연동시켰으나, 지금은 관계없이 모두 연동 (무급은 0으로 설정)  

그리고 여기서 이후 신청 - 승인 구조를 만들기 위해 '휴가 신청'이라는 table을 새로 추가했다. 이 table은 바로 위의 휴가리스트를 duplicate한 다음, 연차 현황만 delete 시켰다.

3. 기존 템플릿 변형 - 구조

이제 여기까지 왔다면, 세 개의 table이 만들어진 걸 확인할 수 있다.(연차 현황, 휴가 리스트, 휴가 신청)  이제 페이지 구조를 변경해서 앞서 말했던대로 휴가 신청 - 휴가 승인 구조를 만들면 된다. 먼저 큰 구조를 보자면 아래와 같다.

언뜻 봤을 때는 구조가 다소 복잡해 보일 수도 있지만 실은 간단하다. 즉, 휴가 신청 table에서 휴가를 신청하고, 그걸 휴가 리스트로 옮겨서 승인, 그렇게 소모된 연차를 연차 현황에서 보여주는 형태라고 생각하면 된다. 각 샘플 페이지를 덧붙여 놓았으니 클릭해서 위에 말한 구조를 확인해보자. (휴가 신청(김만화) / 휴가 신청(WORKSPACE) / 휴가 승인(담당자용))

① 휴가 신청(김만화) / 신청자 개인 (private page)

→ 해당 페이지는 김만화 개인으로 filtering 된 private page

→ 가장 상단의 위치한 휴가 신청 table에서 휴가로 신청할 날짜와 연차의 종류를 입력하면 되는 방식

→ 신청한 휴가가 담당자에 의해서 승인될 시 휴가 리스트 table에 나타나고, 소모된 연차 개수는 연차 현황에서 반영

→ 김만화 개인은 가장 상단의 휴가 신청 table 외에 휴가 리스트 table, 연차 현황 table은 수정할 수 없음

②  휴가 일정(workspace) / 멤버 전체 (full access)

→ 해당 페이지는 Workspace 내에서 멤버 전체가 볼 수 있는 페이지

→ 신청된 연차(휴가 신청)와 승인된 연차(휴가 리스트)를 확인할 수 있음

→ 마찬가지로 휴가 신청 table 외 휴가 리스트(캘린더)는 수정할 수 없음

③  휴가 일정(workspace) / 멤버 전체 (full access)

→ 해당 페이지는 휴가 관련 담당자만 볼 수 있는 private page

→ 휴가 신청 table에서 신청된 휴가 내용을 드래그해서 휴가 리스트로 옮긴 뒤 연차 현황에 신청자 이름을 입력하면 승인 처리

→ 휴가 신청 table의 내용은 신청 내용일뿐이므로 연차 현황에 반영되지 않음

→ 휴가 리스트 table과 연차 현황 table은 담당자 페이지 외 다른 페이지에서는 수정할 수 없음

→ 단, 다른 페이지에서 확인은 가능하게 해야 하므로 휴가 리스트와 연차 현황의 share to web을 on시켜줘야 함

위 설명한 내용들을 바탕으로 실제로 사용해보면 다음과 같이 작동된다.

4. 결론

지금까지 포스타입 연차 대장 템플릿을 활용해 신청 - 승인 구조로 된 휴가 관리 시스템을 만들어 보았다. 앞서 말한 세 가지 조건을 대부분 충족했다.(2번, 연차 개수의 경우 수정 권한이 없어도 filter를 풀 수 있기 때문에 완전히 충족했다고 보긴 어렵다)

사실, 여기서 보여주고자 했던 것은 수식이 아니라 이전 글에서 소개했던 노션 팁들이 어떻게 활용되는지 그 사례였다. 잘 살펴보면 아래와 같은 팁들이 이 시스템을 만드는데 활용되었다.

3. calendar의 내용은 table로 입력하는 것이 더 편하다.

4. database마다 share 설정을 다르게 할 수 있다.

7. Select property의 sorting 순서는 항목의 배열 순서대로이다.(오전 반차, 오후 반차 캘린더 view에서 노출될 때 활용)

8. filter 기능을 이용해 고정적으로 반복되는 값을 복사할 수 있다.

이렇듯 노션의 자잘한 원리들을 알고 있으면 이런 식으로 유용하게 활용할 수 있다는 것이다. 다만, 이것에 대한 결론을 얘기하자면, 연차표 하나 만들겠다고 이렇게 복잡하게 노션을 쓸 필요는 없다. 이전 글에서도 얘기하지만 나는 노션을 복잡하고 어렵게 쓰는 것에 반대하는 편이다. 특히 relation&rollup이나 저런 복잡한 수식들 같은 경우가 그렇다.

물론, 잘 찾아보고 살펴보면 저런 수식도 누구나 다 이해할 수 있고 적용할 수 있다. 하지만 사내 모든 팀 구성원이 그럴 것이라는 보장은 없다. 그래야 할 의무도 없다. 노션은 누구나 이해하기 쉽게 단순하게 쓰는 것이 좋다.

그러므로 이 연차 시스템은 앞서 말한 여러 팁이 활용된 사례로 보인 것이며, 이전 글에서 소개했던 내용들은 이런 복잡한 수식이나 기능 활용 없이 다양한 곳에 활용할 수 있다.

그리고 끝으로 말하자면 이런 연차 시스템을 굳이 노션으로 만들 필요가 있을까 싶다. 요즘 유료 툴 중에 휴가 시스템 같은 것들을 깔끔하게 처리해주는 툴이 많다. 대표적으로 flex 같은 툴이 그렇다. 그냥 돈 조금 더 주고 flex 같이 깔끔한 툴을 쓰는 게 현실적으로 더 도움이 된다. 돈 조금만 쓰셔라. 그럼 편하다.