배경#
라이드플럭스에서 진행한 모든 메인 업무보다도 오히려 가장 뿌듯했던 작업이다.
스타트업인 라이드플럭스에는 근태 관리를 위해 사용하는 툴이 딱히 없었다.
일주일에 두번 재택근무를 사용할 수 있고, 하드웨어를 다루는 업무를 하시는 분들은 출장도 빈번했다.
근무시간도 제각각이다보니 각자 자유롭게 출근할 수 있다는 점은 최고의 업무 환경이지만, 협업하기에는 불편한 점들이 있었다.
당시 오늘 근태 상황은 각자가 구글 캘린더에 직접 작성하는 방식이었는데, 아래와 같은 문제들이 있었다.
- 가끔 race condition이 발생해서 작성한 근태가 사라지곤 했다.
- 늦게 출근하는 사람들이 재택인지 출근하는건지 알 수가 없다.
- 휴가인지 모르고 멘션했는데 캘린더를 보니 휴가여서 사과하는 일이 빈번했다.
- 사람이 많아져서 캘린더를 보기 더 어려워졌다. 재택 뿐만 아니라 출장 위치도 다양했고 주근무지가 아닌 다른 근무지에서 일하는 것도 캘린더에 적었기 때문에 확인하기 쉽지 않았다.
flex와의 연동 시도#
어쨌든 회사 메신저로 슬랙을 사용하기 때문에 최선의 방법은 슬랙의 상태 이모지에 근태 상태를 표시하는 것이었다.
다만 아무래도 매일 상태 이모지를 바꾸는건 귀찮기 때문에 자율적으로 수행하면 일부 인원들은 하지 않을 것이 자명했다.
따라서 어딘가에 입력한 근태를 자동으로 슬랙에 이모지로 표시할 수 있어야했다.
마침 그 당시에 flex라는 근태관리 플랫폼을 도입하기 시작했고, flex에 올린 근태로 근무시간을 계산하여 월급을 주기 시작했다.
근태를 올리지 않으면 월급이 안나오기 때문에 모두가 강제로 입력해야 하는 구조여서 이거다 싶었다.
그때부터 flex와 슬랙을 연동할 방법을 찾기 시작했다.
여담이지만 역시 돈은 최고의 강제성이다.
flex API 사용?#
가장 간단한 방법은 flex에서 제공하는 API를 사용하는 것이었다. 다만 flex API 사용을 위해서는 요금이 청구됐다.
이게 인원당으로 청구되기도 하고 돈이 꽤나 나갔다. 회사에서 공식적으로 하라고 한 일이 아니고 필요는 하겠지만 수요가 있었던 상황은 아니었기에 고작 근태관리 연동을 위해 큰 돈을 쓰자고 주장할 수는 없는 일이었다.
API 문서도 deprecated된 느낌이라 제대로 관리가 되어있었는지도 의문이었다.
그래서 API를 사용하지 않고 연동할 수 있는 방법을 먼저 찾아봤다.
flex - 구글 캘린더 연동을 활용#
신기하게도 flex와 구글캘린더 연동은 무료 요금제에서도 가능했다.
다만 보기 좋게 정리해주는건 아니고, 입력된 모든 근태를 각각 하나의 이벤트로 구글 캘린더에 입력하는 형태였다.
그래서 회사의 K님이 해당 구글 캘린더를 보기 편한 형태로 정리하는 스크립트를 만들어주셨다. 이후에는 사람들이 직접 근태를 입력할 필요는 없어졌다.
1분마다 flex와 상태를 동기화하는데 K님 말로는 구글 캘린더 API 사용횟수는 문제가 없다고 하고 슬랙의 경우에도 현재까지 잘 쓰고 있는걸 보면 문제가 없는 듯 하다.
구글 캘린더와는 연동이 되더라도 여전히 다른 직원의 근태를 확인하기 위해 구글 캘린더를 열어봐야한다는 불편함은 존재했기 때문에 슬랙과 연동할 필요성은 있었다.
대신 flex - 슬랙을 직접 연동할 필요 없이 정리된 구글 캘린더와 슬랙을 연동하는 것으로 목표가 바뀌었다.
개발#
슬랙 이모지 설정 스크립트#
각 근태 상태 별로 이모지를 만들고, 연동된 구글 캘린더 상태를 각자의 슬랙 계정에 상태 이모지로 띄우도록 하는 스크립트를 만들었다.
재택 시간의 경우 각자가 시간을 정해서 올리긴 하지만 자유출퇴근의 특성상 일찍 일을 시작하는 사람과 늦게 일을 시작하는 사람이 모두 있었기 때문에 동일하게 9-1시를 오전 재택, 1-6시를 오후 재택으로 설정했다.
실제로 11시부터 오전 반차를 쓰는 사람이 있었고, 11시까지 오전반차를 쓰는 사람도 존재했다.
출장의 경우 오전, 오후로 나눠진게 아니라 각자가 출장 시간을 정확히 입력했기 때문에 해당 출장 시간에만 이모지가 뜨도록 했다.
토큰 발급을 위한 슬랙 OAuth 서버#
이모지를 스크립트에서 바꾸기 위해서는 이모지 변경 권한이 있는 user token이 필요했다.
slack 관리자 요금제에서는 관리자 토큰만 있으면 다른 사람의 이모지도 바꿀수 있었는데 당시 회사에서는 무료 요금제를 사용하고 있었기 때문에 이건 불가능했다.
이후에 pro 요금제로 바뀌긴 했으나 놀랍게도 pro 요금제로도 불가능한 권한이었다
그래서 각자의 token을 받아올 수 있도록 구글 폼을 작성했다.
귀찮아서 안하는 사람이 생길까봐 이런 강제성이 없었으면 했는데 아쉬운 부분이었다.
하지만 한번 토큰을 받으면 내가 연동할 토큰 목록에 추가하는 것 외에 사용자들이 할건 없었기에 별 불만은 없었다.
인사팀장 분도 근태 연동에 대해 관심이 많았기 때문에 안한 사람들을 채근하는 등 꽤나 밀어주셔서 토큰 수집을 수월하게 할 수 있었다.
어쨌든 자신의 토큰을 바꿀 수 있는 권한을 나에게 주는 것이기 때문에 개인정보 수집에 대한 걱정이 있어서 어짜피 token 받는 링크를 만들 겸 신청서라는 이름으로 개인정보 수집 동의도 받았다.
user token을 받기 위해서는 권한 요청 페이지에서 승인을 누르면 우리가 가진 oauth 서버에 redirect해서 토큰이 발급되는 형태였다.
도메인이 필요했기 때문에 회사 NAS에 oauth 서버를 돌리고 redirect URL로 사용했다.
이모지 복구 로직#
만들기 전부터 기존의 이모지가 사라지는 것에 대해 불만을 가지겠다 싶어서 복구 로직을 생각했다.
이를 위해 기존의 이모지를 저장하는 메모리 역할을 하는 json 파일을 만들었다.
코드에서 변수로 만들지 않은 이유는 갑자기 꺼졌을때 기존 상태를 저장할 수 없기 때문이다.
친하던 L님에게 근태 연동하라고 영업할때 바로 내가 원하는 이모지가 바뀌는게 싫다는 얘기가 나와서 그럴 줄 알고 미리 준비했다고 말할때 꽤나 뿌듯했다.
배포#
배포는 회사 NAS에 했다.
oauth 서버는 그냥 백그라운드로 실행해놨고
구글 캘린더 연동 스크립트가 1분마다 nas의 잡 스케줄러에서 실행된다.
후기#
처음에는 10명 정도 베타테스터를 모았는데, 이모지 색깔을 시인성 좋게 바꿔달라거나 새로운 상태를 추가해달라는 것 외에는 다들 만족했다.
그래서 타운홀 미팅 때 공식적으로 도입하자고 얘기를 꺼냈고 어짜피 돈이 드는 것도 아니라서 도입하게 되었다.
많은 분들이 생기고 너무 편해졌다고 얘기해주셔서 개발의 즐거움을 많이 느꼈다.
일부 로직 상의 버그를 수정한 이후에는 서버가 꺼지는 것 외에는 이슈가 생긴 적이 없었다.
여담이지만 회사의 서버 관리를 주로 하시는 N님이
상태 이모지를 비우는 자동화 스크립트를 만드신 것으로 추측되어 이상한 근태 (당산근무)를 계속 해놓으셔서 나도 질 수 없어서 1초마다 근태를 비우는 스크립트를 돌리는 기싸움을 했다.