Stay hungry, Stay foolish

팀원들을 행복하게 만들어주는 과정은 생각보다 간단할 수도 있습니다 본문

개발 이야기

팀원들을 행복하게 만들어주는 과정은 생각보다 간단할 수도 있습니다

Jake2 2022. 5. 6. 00:46

지금은 팀원들을 위한 어드민 운영 툴을 만드는 입장이지만, 작년까지만 하더라도 저 또한 어드민 운영툴을 사용하는 직원이었습니다.

당시에는 루틴하게 자주 쓰는 기능인데도 반복적으로 불필요한 작업들이 반복되어야만 해서 굉장히 투덜거리면서 일을 했었습니다. 정확히 1년 10개월 정도 재직했었는데, 퇴사하기 몇 개월 전 해당 운영툴이 획기적으로 바뀌더군요. 감동이었습니다. 불필요하게 낭비되는 시간도 많이 줄었고 이미 퇴사는 마음먹었지만 이상하게 약간의 애사심..? 도 생기더군요 ㅎㅎ..


현재 다니고 있는 회사의 상황을 보자면, 일단 팀원들이 야근을 너무 많이 합니다... 그리고 그걸 당연하게 생각하는것도 너무 가슴 아프더군요... 그래서 저는 옆자리에 야근 자주 하는 팀원을 계속 염탐했습니다 👀

 

사실 기존에 개발되었던 기능들 중 비효율 적인 기능들이 있다고 인지는 하고 있었으나 개발자가 1~2 명으로 유지되는 상황에서 우선순위가 항상 뒤로 밀리기 일쑤였습니다. 근데 저도 입사하고 6개월 정도가 되니, 신규 프로젝트를 진행하면서 팀원들을 위한 운영툴 개선 작업을 같이 진행할 수 있는 여유가 생기더라고요.

 

야근하는 팀원을 염탐하며 루틴 하게 진행하는 업무지만 가장 자동화가 이뤄져 있지 않은 업무를 찾았습니다.

설문조사에 대한 기능이었습니다. 설문조사를 위해 현재 저희 서비스는 타입폼이라는 saas 프로그램을 사용 중이었습니다.

 

저희 서비스에 대해 간략히 말씀드리면 B2B2C 로 학교 취업지원처와 계약 후 학생들에게 현직자와 취업에 관련된 멘토링을 진행시켜주는 서비스를 운영 중입니다. 이 과정에서 야근하는 팀원의 업무 루틴을 보면


멘토링 클래스 진행 전

운영툴에서 멘토링 클래스 생성 -> 타입폼 어드민에서 설문조사 그룹 생성 -> 설문조사 페이지 생성 -> 설문조사 링크 자사 운영툴 클래스 페이지에 기입 -> 생성한 설문조사 publish 설정


클래스 종료 후

학생들에게 설문 안내 문자 발송 -> 데이터 누락 있을 시 개발팀에 데이터 연동 요청 -> 개발팀 데이터 수동 연동 진행 -> 타입폼 페이지에서 설문 데이터 엑셀 파일 다운로드 및 재가공 -> 멘토님께 설문조사 결과 발송 -> 고객사에게 보낼 결과보고서 작성

 

참 이렇게 써놓고 보니까 민망할 정도로 개발자 입장에서 톡 하고 손대면 개선될 수 있는 것들이 너무 많이 보이더군요.

그래서 일단 당장 할 수 있는 작업을 잘게 쪼개서 메인 프로젝트를 진행하면서 남는 시간에 같이 개선 작업을 진행했습니다.


일단 클래스 진행 전의 과정들은

기존 설문조사 템플릿을 하나 세팅해놓고 운영툴에서 클래스를 생성하면 해당 설문조사 템플릿이 duplicate 되도록 구현,

운영팀에서 클래스만 생성하면 나머지 다섯 단계를 자동으로 진행되도록 만들었습니다.

이 정도만 되어도 팀원들은 정말 기뻐하더라고요. 정말 죄송했습니다 진작에 좀 해드릴걸...

클래스 진행 후 안내 문자는 클래스 종료 시간과 종료 후 익일에 2회 설문 독려 알림톡을 스케줄러를 통해 발송되도록 했습니다.

 

데이터 연동 작업은 기존에도 스케줄러가 돌면서 클래스 종료 뒤에 데이터 연동 작업을 1회 진행했는데

해당 연동 작업 후 설문조사 참여자로 인한 데이터 오차때문 이었습니다. 

사실 이건 타입폼 webhook 통해서 구현하려고 했습니다. 이미 사이드킥(스케줄러) 이 돌아가는 워커 서버의 CPU Utilization 이 눈에 띄게 튀고 있는 게 보이는 중이었고(주기적으로 80%까지 튀는 중입니다.) 현재보다 클래스 참여자가 많아지고 가져와야 할 데이터가 커지게 되면 워커 서버가 멀쩡할 거라고 장담할 수 없었습니다.

결국에는 이미 만들어져 있는 데이터 연동 작업을 최초 연동 +1일에 retry 시키는 방향으로 개발하긴 했습니다. 개발자 1인인 스타트업에서 최대한 개발 공수를 줄이기 위함이었죠.. 사실 webhook도 retry 로직을 추가하는 것도 틀린 방법은 없다고 생각합니다. 해당 CPU utilization이 99%까지 치솓을 정도면 webhook으로 개발했을 때 프로덕션 서버에도 부하가 클 것이라는 이야기니까요.

결과적으로는 일단 개발 공수는 작게 하고 추후에 MSA로 떼어내자가 되었습니다.


데이터 연동 작업 이후에는 멘토님과 고객사 측에 제공하는 보고서 작성을 위해서 타입폼 어드민에서 직접 클래스마다 데이터를 다운로드하고 가공하는 작업이었습니다. 해당 작업은 운영팀에서도 시간이 가장 많이 걸리는 과정이었고 저 또한 개발 공수가 가장 많이 들어간 작업이었습니다. 

 

일단 클래스 하나의 raw data 자체를 받아오는 건 문제가 아니었습니다만,, 

문제는 최초 해당 saas를 도입하면서 db설계를 할 당시 이러한 확장성까지 염두에 두고 모델링이 된 것이 아니었고, 100% raw data가 아닌 가공이 이뤄지고 있다는 점 그리고 그 데이터를 활용해서 csv로 제공해줘야 하는데,

설문조사 안에 경우의 수가 왜 이리도 많은지... 중복답변 가능 여부, 필수 답변(공백 제출 가능) 여부, 여러 답변 타입들 등등 

결국은 타입폼 document 을 뜯어보며 나올 수 있는 경우를 촘촘히 짜서 설계한 뒤에야 정상적으로 결과물을 볼 수 있었습니다.

 

해당 csv 가공과 더불어 멘토의 개인 페이지에서 data chart로 볼 수 있게 화면까지 구성해주고 나니 해당 11 단계의 과정이 클래스 생성 -> 결과보고서 작성(필요한 데이터 가공해서 제공까지 반 자동화) 의 두 단계로 획기적으로 줄게 될 수 있었습니다.

 

물론 이렇게 자동화를 해놓았지만 우리 팀원분들은 오늘도 어김없이 야근을 하시네요 😭 진심으로 기뻐하고 고마워하던 모습을 잊을 수 없습니다. 한참 전에 해드렸어야 할 일을 이제 와서 해드린 건데 말이죠...

 

어떻게 보면 제가 개발을 하고 싶었던 이유와도 부합하네요. 내부고객도 만족 못 시키는데 외부고객을 만족시킬 수 있을까요. 근데 생각해보면 정말 불편할 수도 있고 반복적인, 불필요하게 루틴한 업무들이 어느 회사에서나 생각보다 많을 겁니다. 단지 그게 매뉴얼이고 여태 그래 왔으니까 이게 개선이 필요한 일인가? 라고 생각할 수 있습니다.

특히 스타트업에서는 개발자가 톡 하고 손댔을 때 결과물은 생각보다 드라마틱할 수 있습니다.

개발자 하기 잘했다고 생각되는 하루였습니다.

 

그리고 마지막으로 알면서 안 하는 분들은... 직무유기라고 생각합니다... 😇

Comments