리뷰 누락을 어떻게 예방할까? 알림 시스템 제작 여정

#혹시... 제 리뷰 언제까지 될...까요?

과거 재직했던 IT 스타트업에서는 코드리뷰를 필수로 진행했다. 그리고 팀 내 코드리뷰 원칙이 있었는데, 매일 오후 2시까지 리뷰를 완료할 것, 만약 리뷰가 지연될 시 별도 알림을 줄 것 등이 있었다.

하지만 원칙은 문서로만 존재했기에, 의식하지 않으면 지켜지기 어려웠다. 그래서 개발팀에서는 리뷰 할당 사실을 놓치거나, 한 사람에게 리뷰가 가중되어 리뷰 완료 시간이 넘어가곤 했다. 이 상황은 마냥 긍정적이진 않았다. 리뷰요청자는 리뷰를 기다리다가 자신의 작업에 투자할 시간이 적어지고, 리뷰어는 리뷰가 가중되면 리뷰 퀼리티가 떨어질 수 있기 때문이다.

그럼 어떻게 해야 리뷰 누락을 방지하고, 리뷰가 한 사람에게 가중되는 현상을 해소할 수 있을까? 개인이 특정 시간마다 확인하면 될까? 그런데 작업에 몰입할 때는 확인하는 걸 놓칠 수 있는데ㅜ

아아~ 그럼 리뷰 할당 현황을 채널에 알려주면 어떨까?

#매일 일정 시간에 리뷰 할당 현황을 알려주자!

팀에서는 Discord를 소통 채널로 사용하고 있었다. 그래서 Discord 채널에 할당 알림 봇을 만들어 할당 현황을 메시지로 전송해주자! 라고 생각했다. 그런데 이 시스템을 만들기 앞서 문제가 있었는데...

처음에는 디스코드 봇으로 특정 시간 알림과 더불어, 명령어로 리뷰 현황을 상시로 볼 수 있게 하려 했다. 하지만 Github API 요청 횟수에 제한이 있어 상시 알림은 어려웠다. 그래서 아쉽지만 하루에 한 번 할당 여부를 메시지로 전송해주기로 결정했다.

"그럼 더이상 문제 없겠네! 바로 시작 ㄱㄱ", "응...아니야 문제가 하나 더 있지..^^..."

또 다른 문제는 이 메시지를 어떻게, 일정 시간 마다, 전송할 건지였다. 서버를 연결해야할까? 그런데 상호 통신이 필요 없는데 서버 연결은 과한데? 그러다 예전에 Github Actions로 PR Labeler를 연결한 경험이 떠올랐고, Github Actions의 cron을 사용해 보기로 했다.

여기서 주의한 점은, cron은 UTC 시간 기준이라 한국 시간으로 바꾸려면 9시간을 빼야하는 점과 시간 오차가 있어 실제 스케쥴링한 시간보다 최대 20분 정도 차이나는 점만 빼면 괜찮았다.

그리고 대망의 아침 9시경, 예측했던 대로 9시에 바로 작동하진 않았고 6분 뒤에 스케쥴링 돌았다. 다행히 의도했던 대로 데이터가 잘 나와서 만족스러웠다.

#그 이후에는?

시스템 도입 후에는 피드백을 받았는데, "개인별로 할당된 PR로 이동했으면 좋겠다", "오후에 재알림이 있으면 좋겠다" 등이 있었다. 다만, PR로 바로 이동하는 기능은 데이터 접근은 가능하나 메시지 템플릿이 너무 길어져 보류 했다. 오후 재알림은 cron을 추가로 생성하는 방식으로 수정했다.

이 시스템을 만들면서 디스코드 Webhook과 cron도 배울 수 있었는데, 무엇보다 팀의 문제를 시스템으로 해결한 점에서 뿌듯했다.

+) 관련 자료

기술적으로 어떻게 구현한건가요? 아래 링크에 순서대로 적어두었답니다 +_+

1. Github API로 내 조직의 할당 현황 정보 가져오기 (링크)

2. Discord webhook으로 채널에 메시지 전송하기 (링크)

3. github actions로 메시지 스케쥴링하기 (링크)

4. 작업 완료한 레포(링크)

서비스 플랫폼은 왜 실패할까

지난 3년간 IT 스타트업에서 일을 하면서 프로덕트의 흥망성…쇠를 다 본 거 같다. 어디서도 경험할 수 없는 귀한 경험이었다. 나는 이 경험 속에서 토스팀의 '유난한 도전', 피터 드리커의 '프로페셔널의 조건'을 읽고 서비스 플랫폼의 실패를 3가지로 간단히 요약해봤다.(개인 경험에 기반한 요약입니당..ㅇㅅㅇ)

1. 프로젝트의 목표가 없는 무 목표형

• 서비스의 존재 이유가 무엇일까. 그리고 조직은 왜 서비스를 만들까. 나는 조직이 새로운 것을 창조하여, 사회를 개선한다고 생각한다. 그리고 그 수단이 서비스이다. 조직의 1차적인 목적은 '돈'이지만, 그 차원 이상의 목적을 지녀야 한다. 그렇다면 프로젝트의 목표는? 서비스 플랫폼을 운영하는 조직은 고객에게 궁극적인 가치를 주고 고객의 삶을 향상시켜야 한다. 프로젝트는 그 가치를 기준으로 결정되어야 한다.

• 프로젝트에서 목표 가치, 달성 기준, 성공 지표가 없다면 그 핵심 가치가 없는 것과 다름 없다.

• 서비스 플랫폼은 이 가치에 따라 제품이 동작하는 지 알기 위해 검증된 지표를 사용한다. 대표적인 지표 중 하나인 'AARRR'은 스타트업의 성장을 가늠할 수 있다.

• 오늘 날 많은 조직이 목적 중심으로 팀 프로세스를 바꾸고 있다. 이게 단순히 '트렌드를 따라가는 멋진 팀이' 되기 위함이 아니다. 목적 중심의 팀은, AARRR을 잘 달성할 확률이 높기 때문이다. 목적 중심으로 모인 팀은 마치 하나의 모듈과 같다. 하나의 목표만 두고 그 안에서 각자의 역할을 수행한다.

• 물론 목적 중심의 팀 빌딩에 앞서, 리소스가 걱정될 수 있다. 스타트업의 특성상 리소스는 제한되어 있고 빠른 시간내에 프로덕트를 만들어야 하니까. 하지만 리소스를 걱정하기에 앞서, 올바르게 리소스가 분배되었는지 살펴볼 필요는 있다. 컨텍스트 스위칭만큼 큰 비용도 없기에 트레이프 오프를 잘 해야하지 않을까.

2. 프로젝트 성공, 실패의 이유를 회고하지 않는 무 회고형

• 사람이 성장할 수 있는 방법 중 하나는 '회고'라고 생각한다. 그리고 프로젝트 실패율을 낮춰 서비스 성장을 이끄는 것도 '회고'라고 생각한다. 토스 팀은 실패를 하면 좌절에 그치지 않고 회고를 한다. 그리고 그 회고를 바탕으로 실패에서 얻은 배움을 나눠 새로운 도전을 독려한다. 그럼 성공했다면? 축하만 할까? 아니다. 성공을 확신할수록 오류를 발견하여 바로 잡을 기회가 줄어든다. 그래서 제품을 출시한 뒤에 자축 하기보다는 1 ~ 2주 단위로 데이터를 분석해 사용자가 많이 이탈하는 단계를 찾아내 개선하는 게 중요하다.

3. 팀과 소통 부재나 누락이 만연한 무 소통형

• 요즘에는 이런 유형이 많이 없...?을 것이다..(아마?) 프로젝트를 진행하거나 의사결정을 할 때 공유되지 않는 경우가 있다. 휘발되는 논의는 리소스 낭비다. 어떤 논의를 하든 어딘가에 기록으로 남아 있어야 한다. 그 당시에는 가볍게 생각했던 사안이 나중에는 큰 결정을 하는 근거가 된다.

• 한 예시로 기술적 한계로 서비스 최적화를 미뤄두었다 가정하자. 만약 2개월 뒤 기술적 한계가 사라졌다면 최적화를 통해 고객의 사용성을 높여야 한다. 하지만 이 사안이 기록으로 남아있지 않다면? 우리는 고객의 사용성을 높여 활성화를 높일 수 있는 기회를 놓치게 된다.

• 개인마다 선호하는 소통 방식은 다르지만, 의사 결정의 결과는 기록되어야 한다.