시작

2019년 나는 프랜차이즈 회사에서 오피스 매니저로 일하고 있었다. 그전까지 내가 개발이란 것을 할 줄 생각도 못하고 있었다. 나름대로 주어진 툴로 최대한 생산성을 높이려는 시도는 했지만 만족스럽지 않았다.
결국 문제 해결 과정에서 내가 직접 만들어보자라는 생각으로 개발을 시작하게 됐다.

당시 비효율적이었던 지점과 개선하려 했던는 나의 시도는 두 단계로 나눌 수 있다.

1. 흩어져있던 툴 합치기
2. 사내 시스템 개발

이번 포스트에선 사내 시스템 개발에 대해 써보려 한다.

(흩어져있던 툴 합치기에 관한 이전 포스트는 여기에)

문제점 1. 직원 입사 프로세스

회사는 본사(오피스팀)를 중심으로 뉴질랜드 전역에 10개 지점에 매니저를 두고 직영으로 운영하는 시스템이었다. 내가 속한 본사는 지점 운영팀과 커뮤니케이션하고 그들이 사용할 툴들을 매니징하고 있었다.

툴을 합치고 나서 업무 과정이 효율적으로 개선됐지만 다른 문제점이 발생했다. 바로 직원들이 입사하고 퇴사할 때 일일이 업무를 위한 Office365 계정과 페이런을 위한 FlexiTime 계정을 생성, 삭제해줘야 한다는 점이었다.

예전엔 직원의 FlexiTime 계정만 본사에서 관리하고 나머지 업무용 툴 계정은 지점마다 하나만 있었기 때문에 계정을 생성하고 삭제할 일이 많지 않았다. 하지만 지점의 로스터링과 채팅을 Teams로 하게 되면서 전 직원이 Office365 계정을 사용해야 했고 이는 오피스의 추가적인 업무가 되었다.

직원 입사하면 다음 프로세스를 거쳤다.

1. 지점에서 직원의 필수 서류를 스캔해서 오피스에 전달
2. 오피스는 서류를 확인하고 FlexiTime와 Office365 계정을 생성
3. 직원에게 생성된 계정의 로그인 디테일과 Office365 사용법이 담긴 이메일 발송

턴오버가 높은 호스피탈리티의 특성상 이 업무는 특히 많았고 모두 수작업으로 해야 했기에 실수가 많았고 비효율적이었다.
스캔했던 직원 문서는 4년간 보관해야 한다는 법에 따라 오피스 창고에 보관 (쌓아두고) 했었다.

문제점 2. 페이런

직원 입사 프로세스와 얽혀있는 다른 문제점은 페이런이었다.
페이런은 2주마다 한 번씩 진행하고 있었다.

• '로스터를 직원에게 사인을 받아 동의했다는 사실을 기록해둬야 한다.'
• '직원 근무시간과 리브 사용 내역은 직원이 직접 작성하고 사인해야 한다'

위와 같은 뉴질랜드 고용법에 따라 직원들이 로스터에 사인하고 타임시트 템플릿에 자신의 근무시간을 수기로 적었다.

이런 타임시트 템플릿을 출력해서

이렇게 수기로 작성했다.

그리고 2주마다 아래와 같은 과정을 반복해 페이런을 진행했다.

1. 직원들이 수기로 타임시트 작성
2. 1차로 지점 운영팀에서 직원들의 타임시트를 체크하고 타임시트와 로스터를 스캔해서 본사에 전달
3. 2차로 오피스에서 전달받은 파일로 타임시트 체크
4. 페이런 진행

타임시트 체크 항목들

• 직원의 계약서에 보장된 최대, 최소 시간을 충족하는지
• 리브를 사용했다면 FlexiTime에 기입이 되어 있는지
• 공지한 로스터에 맞게 타임시트를 작성했는지
• 로스터보다 덜 일하거나, 더 일했다면 그 사유

직원수가 증가하면서 오피스에선 2주마다 거의 100개가 되는 타임시트를 체크해야 했다. 그리고 앞에서 말했던, 직원 입사 프로세스에서 빠진 문서나 정보가 있으면 받을 때까지 기다려야 했고 때문에 페이런이 밀리기 일쑤였다. 그리고 이 스캔한 파일들은 역시 본사 창고에 보관 (쌓아두고) 했었다.

시도: 마켓에 있는 솔루션들을 사용해보자

프로그래밍이란 옵션은 생각하지도 않았고 나는 당연히 마켓에 나와있는 HR 솔루션들을 먼저 알아봤다. 회사의 필요사항을 어느 정도 만족시켜주는 제품들은 많았지만 다들 뭔가 하나씩은 아쉬웠다.

일단 Office365와 연동되는 솔루션이 없었다. 마켓에 있는 HR 솔루션을 그대로 사용한다면 고생해서 2가지로 통합한 툴을 하나 더 추가하는 것이기에 도입하기 부담스러웠다. 툴이 하나 더 늘어나는 것이기에 결국 직원들의 계정을 만들고 삭제해야 하는 업무는 더 가중되는 것이었다. 그리고 여러 개의 지점에서 일하는 직원들의 근무 시간을 합산해서 계산해줘야 하는데 이것을 지원하는 솔루션도 없었다.

해결책(?) 또 다른 시작

역시 요구사항을 모두 충족하는 제품은 마켓에 없었다. 주위에 의견을 구해보니 Office365와 FlexiTime 모두 API라는 것을 제공해줘서 웹 어플리케이션을 만들면 해결할 수 있을 것이라는 조언을 들었다.

그래서 결국 내가 만들기로 했다. 나는 이참에 본사 창고에 쌓여있던 종이를 없애버리고 싶었다. 그게 내가 프로그래밍을 시작한 이유였다.

첫 번째 목표는 직원 입사 프로세스를 자동화하는 것. 페이런은 법적인 문제와 과정이 복잡하기 때문에 잠시 미뤄두고 입사 프로세스를 자동화하는 것을 첫 번째 목표로 삼았다. 계정 생성과 직원 필수 서류 체크만 자동화되어도 오피스 업무량이 줄고 휴먼 에러가 발생해 페이런이 밀리는 상황은 좀 덜해질 것이라고 생각했다.

웹 애플리케이션이 정확히 뭔지도 모르던 그때, 누구나 강의만 몇 달 들으면 웹앱을 만들 수 있다는 코스를 찾아 퇴근 후, 출근 전, 주말에 프로그래밍 공부를 시작했다. 막상 시작해보니 역시 내 생각보다 배워야 할 것들이 훨씬 많고 어려웠다. 모르는 내용 투성이라 진도를 따라가기도 벅찼지만 일단 내가 배워서 만들 수 있는 만큼 만들기로 했다. 약 3개월간 빡빡한 공부 끝에 프로토타입을 만들 수 있었다.

2019년 나는 HTML, CSS, 자바스크립트를 배워 Express 서버와 Pug 템플릿 엔진을 이용해 Garage의 프로토타입을 만들었다. 배포는 Heroku에 했는데, 배포에 대한 이해가 부족해 6시간 넘도록 걸린 기억이 난다. 결국 내가 원했던 신규 직원 입사 프로세스는 자동화할 수 있었다.

Garage를 통해 지점 운영팀이 신규 직원 이메일과 포지션 등을 입력하면 Office365 계정이 생성되고, 직원 이메일로 계정 로그인 정보와 안내 메일이 발송된다. 그리고 그 안내 메일에 따라 Garage로 접속해 직원이 직접 필수 서류와 정보를 기입하면 오피스에선 확인만 하면 됐다.

상당히 귀여웠던 초창기 Garage

많이 발전한 2022년 Garage

회사에 프로토타입을 보여주고, 프로젝트 승인을 받을 수 있었다. 꾸준히 공부해 어플리케이션을 발전시켰고 결국 지금은 회사의 핵심 솔루션이 되었다.물론 이젠 페이런 과정도 자동화되어 페이런이 밀리는 일도 없다. 하지만 여전히 개선할 점들이 눈에 들어온다.
프로그래밍 시작할 때 "딱 저만큼만 프로그래밍 할 수 있으면 많은 것을 해결할 수 있을텐데"라고 생각했는데, 그 때 목표했던 것 보다 훨씬 많은 것을 할 줄 아는 지금도 같은 마음이다.

회고

오피스 매니저였던 내가 개발을 시작한 이유를 돌아봤다.
나는 문제 해결의 도구로써 프로그래밍을 시작했다. 하다 보니 개발이 재밌고 적성에 맞아 지금까지도 해오고 있다. 계속해 새로운 것을 배우고 활용해서 나와 남의 문제를 해결할 수 있다는 점이 프로그래밍이 나에게 매력적인 이유다.