배포 효율화를 위한 자동화 슬랙봇 개발

배포 효율화를 위한 자동화 슬랙봇 개발

시작하며

안녕하세요. 카카오페이 SRE (Site Reliability Engineering1)팀2 RE (Release Engineering3)파트4 아리입니다. 배포 업무 효율화와 자동화를 담당하고 있습니다. 그 쉽지 않았던 사건들을 쭉 풀어 나가겠습니다.

“11,156 건”

카카오페이에서 2022년 한 해 동안 진행된 배포의 횟수입니다. 신규 서비스의 추가와 기존 서비스의 버그 수정을 신속하고 안정적으로 유저들에게 전달한 횟수이기도 합니다. 이처럼 배포는 개발한 서비스가 실질적으로 유저들에게 반영되는 과정입니다. 서비스를 개발한 개발자와 배포를 진행하는 배포자가 신속하게 의사소통해야 하며, 정보 전달이 누락되어서는 안 됩니다.

하지만, 사람이 하는 만큼 신속하지 못할 때가 있고, 정보 전달이 누락되기도 합니다. 또한, 중요한 만큼 배포 상황을 “빈번하게 지속적으로 확인하고 공유하는 배포 과정” 은 개발자와 배포자 모두에게 상당한 피로감을 누적시킵니다. 이런 피로감으로 인해 개발자와 배포자의 업무 성취도와 업무능력이 저하되기도 합니다.

저희는 “빈번하게 지속적으로 확인하고 공유하는 배포 과정” 의 문제를 슬랙 봇을 활용해 해결했습니다. 배포 구조가 비슷한 곳이 많을 거라 예상합니다. 유사한 문제를 겪는 많은 분들께서 해당 문제를 해결하는 데 작은 도움이 되었으면 합니다!

기획 배경

카카오페이는 개발자와 배포자를 분리해서 운영하고 있습니다. 먼저 업무 분리의 배경을 짧게 설명드리려고 합니다.

핀테크 산업과 전자금융감독규정

핀테크라는 용어를 들어보신 적이 있을 겁니다. 핀테크는 금융과 기술의 합성어로, 금융 서비스와 정보기술(IT)의 융합을 통한 금융 서비스 및 산업의 변화를 통칭합니다. 핀테크 산업의 대표적인 규율 법령으로 전자금융거래법이 있고, 이는 전자금융감독규정에 세부적인 등록 요건을 위임하여 실시되고 있습니다. 다시 말해서, 모든 금융회사와 전자금융업자가 전자금융감독규정의 규제를 받고 있습니다.

카카오페이와 전자금융감독규정

전자금융감독규정(제2018-36호)

제26조 (직무의 분리) 금융회사 또는 전자금융업자는 다음 각 호의 업무에 대하여 직무를 분리/운영하여야 한다.

개정 2013. 12. 3.

  1. 프로그래머와 오퍼레이터

카카오페이는 우리나라의 대표적인 핀테크 기업으로 전자금융업자에 속합니다. 전자금융감독규정 제26조에는 프로그래머(개발)와 오퍼레이터(운영) 업무에 대하여 직무를 분리/운영해야 한다는 내용이 있습니다. 따라서 카카오페이는 전자금융감독규정에 의거하여, 개발 조직과 운영(배포) 조직을 분리해 운영하고 있습니다.

기존 배포 절차의 문제점

카카오페이에서는 SRE팀 RE파트에서 전사 대고객 서비스의 배포를 담당하고 있습니다. 하지만 배포의 현황을 한눈에 파악할 수 있는 대시보드나, 배포자가 쉽게 인지할 수 있는 알림 시스템이 없다는 문제가 있습니다.

기존 배포 절차의 문제점
기존 배포 절차의 문제점

RE파트에서는 배포 요청이 들어오면, 다양한 준비 절차를 거쳐서 배포를 진행했습니다.

배포 담당자 지정
배포 담당자 지정

배포 일정 조율 및 배포 순서 확인
배포 일정 조율 및 배포 순서 확인

예를 들어, 배포 담당자 지정, 배포 순서 확인, 배포 일정 조율 등의 준비 절차가 필요합니다. 기존에는 이러한 절차들이 수작업으로 진행되어 시간과 인력이 많이 소모되었습니다. 업무 시간 내내 긴장 상태를 유지해야 했기에, 피로도가 높기도 했고요.

휴먼 에러로 인한 배포 지연 ㅠ.ㅠ
휴먼 에러로 인한 배포 지연 ㅠ.ㅠ

게다가, 휴먼 에러나 커뮤니케이션 미스로 인해 배포가 지연되거나 누락될 수 있는 위험도 존재했습니다. 이에 따라, 수작업으로 진행되는 배포 절차를 자동화하고 효율적으로 관리할 수 있는 방법을 고민하게 됐습니다.

자동화가 필요한 영역 찾기

기존 배포 절차의 문제점 및 해결 방법
기존 배포 절차의 문제점 및 해결 방법

위에서 설명한 자동화로 해결하려는 문제는 두 가지였습니다. 첫 번째로 수작업으로 진행되는 배포 절차, 두 번째로 휴먼 에러 및 커뮤니케이션 미스인데요. 아래에서 이 문제들이 왜 문제인지, 어떻게 해결했는지 실제 사례를 바탕으로 설명드리겠습니다!

배포 절차 시퀀스 다이어그램(배포 실패나 롤백 등 예외 케이스가 없는 이상적인 케이스)
배포 절차 시퀀스 다이어그램(배포 실패나 롤백 등 예외 케이스가 없는 이상적인 케이스)

배포 준비 절차

시퀀스 다이어그램을 보면, 실제 배포를 위해 필요한 여러 가지 준비 절차를 확인할 수 있습니다.

배포 절차 시퀀스 다이어그램 일부 1
배포 절차 시퀀스 다이어그램 일부 1

신규 배포 요청서가 들어오면, 배포 담당자를 결정하고, 배포 진행 스레드를 생성해 배포 요청자에게 배포 시각이나 순서를 확인하는 일련의 절차가 필요한데요. 이 준비 절차의 피로도가 매우 높았습니다. 문제를 차근차근 살펴보겠습니다.

배포 건 수가 성과 평가에 이어짐

배포는 SRE팀 RE파트의 가장 중요한 업무이자, 파트 내 모든 크루가 담당하는 공통 업무입니다. 배포 건 수에 따라 성과 평가에 가산점을 받을 수 있기 때문에, 배포 담당자를 정하는 과정에서 경쟁이 발생했습니다. 하나의 배포 요청서를 다수의 배포 담당자가 담당하려고 하기 때문입니다.

그러면 왜 공통 업무를 한다고, 평가에 가산점을 주게 됐을까요?

배포에 소홀해짐

평가에 가산점을 주게 된 배경에는 배포에 소홀해지는 것을 방지하고자 했던 목적이 있었습니다. 담당자가 별도로 없는 공통 업무는 책임이 분산되어 다소 소홀해지기 쉽습니다. 저희뿐만이 아니라, 다른 곳에서도 유사한 문제가 있을 거라고 생각합니다.

혹시 제노비스 신드롬 또는 방관자 효과에 대해 알고 계시나요? 주위에 사람이 많을수록 어려움에 처한 사람을 돕지 않게 되는 현상을 뜻하는 심리학 용어입니다. 목격자의 수가 많을수록 어느 누구도 도움을 받을 가능성이 적다는 건데요. 실제로 목격자가 많을수록 한 사람이 받는 책임감이 적어진다고 합니다. 그래서 우리는 위기 상황 등에서 도움을 요청할 때, 특정인을 지목해서 요청해야 한다고 배웁니다.

저는 방관자 효과가 공통 업무에도 해당된다고 생각했습니다. 물론 위기 상황에서 모두가 방관자가 되는 게 아닌 것처럼, 모두가 공통 업무를 소홀하게 여겼다는 건 절대 아닙니다.

다만 업무의 중요도에 대비해서 책임감을 적게 받을 수밖에 없는 구조고, 그러니 특정 인원이 공통 업무의 우선순위가 개별 업무보다 낮다고 생각해도 이상하지 않다는 거죠. 그래서 처음에는 공통 업무 참여를 독려하기 위해 평가 기준으로 포함했지만, 그 결과 업무 피로도가 높아지게 되었습니다. 언제 공통 업무가 들어올지 모르지만 건 수는 채워야 하니, 계속 긴장한 상태로 대기하고 있어야 했기 때문입니다.

이를 개선하기 위해서는 구조적인 개선이 필요했습니다. 따라서 공통 업무에 개별 업무처럼 책임감을 느낄 수 있도록, 특정인을 지목해서 업무를 요청하는 시스템을 개발하게 되었습니다.

(아래의 기능 소개 - 배포 담당자 자동 배정 기능을 구현하여 해결했습니다.)

배포 커뮤니케이션

배포 절차 시퀀스 다이어그램 일부 2
배포 절차 시퀀스 다이어그램 일부 2

시퀀스 다이어그램에 유난히 배포 요청자와 담당자의 직접적인 커뮤니케이션이 많아 보이는 구간이 있습니다. 이 구간에서 휴먼 에러나 커뮤니케이션 미스로 인한 배포 지연이 종종 발생하곤 했습니다.

주원인은 한 가지 상태 변경에 대해 두 가지 동작 필요(VROOM 배포통제시스템5 처리, 슬랙 공유)하기 때문인데요. 예를 들어보겠습니다.

ex1. 모듈 배포 종료 공유 O, 모듈 배포 종료 처리 X → 배포 요청자 검증 진행 불가

VROOM 배포통제시스템5에서는 배포 담당자만 모듈 배포 종료 처리를 할 수 있습니다. 배포 담당자가 모듈 배포가 종료됐다고 공유 후 자리를 비웠는데, 배포 종료 처리가 안 되어있다면? 배포 요청자는 배포 담당자가 돌아와 배포 종료 처리를 해 줄 때까지 기다려야 합니다.

ex2. 모듈 배포 종료 공유 X, 모듈 배포 종료 처리 O → 배포 요청자 모듈 배포 종료 대기

배포 담당자가 모듈 배포 종료 처리를 했지만, 배포 요청자에게 공유는 하지 않으면? 배포 요청자는 배포 담당자의 모듈 배포 종료 공유를 기다립니다.

두 경우 모두 얼마나 기다려야 하는지도 모르지만, 모니터링을 위해 계속 대기해야 하기 때문에 다른 업무에 지장이 갈 수밖에 없습니다 😞

(아래의 기능 소개 - 배포 커뮤니케이션 효율화를 구현하여 해결했습니다.)

기능 소개

슬랙봇을 이용해 크게 두 가지 기능을 개발하여 문제를 해결했습니다.

배포 담당자 자동 배정

배포 담당자 자동 배정 기능
배포 담당자 자동 배정 기능

신규 배포 요청서가 생성되면 알고리즘에 의해 배포 담당자가 배정되고, 슬랙 채널을 통해 배포 정보가 공유되도록 했습니다. 배포 담당자 배정 알고리즘은 각 배포 담당자 별 누적 배포 횟수를 기반으로 동작하는데요. 배포 누적 횟수가 하위권인 크루 중에서 랜덤으로 담당자를 배정하는 방식입니다.

배포 가능, 불가능 설정
배포 가능, 불가능 설정

참고로 담당하는 배포 요청서가 너무 많거나, 회의 또는 휴식시간으로 배포가 불가능한 경우에는 슬랙봇을 통해 신규 배포 요청서를 받을 수 없는 상태로 쉽게 변경할 수 있습니다. 배포 담당자 자동 배정 기능을 통해 RE파트의 모든 크루가 균등하게 배포를 진행하게 되었고, 배포 준비 절차의 피로를 줄일 수 있었습니다. 🙂

배포 커뮤니케이션 효율화

배포 커뮤니케이션 효율화
배포 커뮤니케이션 효율화

배포 요청서 상태 변경을 추적해서, 배포 과정에서 필요한 커뮤니케이션(배포 시작 전에 필요한 정보 요청이나 배포 상태 변경 공유 등)을 대신하도록 했습니다. 즉, 상태 변경이 발생했을 때 배포 요청서에서 상태 변경 처리만 하면 슬랙 공유는 자동으로 되게 했는데요. 이를 통해 배포 과정에서 불필요한 커뮤니케이션을 줄여, 휴먼 에러나 커뮤니케이션 미스로 발생할 수 있는 문제를 최소화 할 수 있었습니다.

마치며

배포 담당자 배정 자동화를 통해, 배포 담당자들은 정말 집중해야 하는 업무에 집중할 수 있게 되었습니다. 배포 커뮤니케이션 효율화를 통해, 공유 누락 같은 단순 실수로 인한 배포 지연을 방지할 수 있었습니다.

시작은 배포 업무에서 떠올린 작은 의문이었습니다. “왜 이렇게 해야 하는 거지?” “이렇게 해봐도 되지 않을까?” 이런 의문과 해결 방법을 정리해 같은 팀 크루들에게 공유하니, 직접 개선해 보는 게 어떻겠냐는 지지를 받을 수 있었습니다.

최근 한 달 동안 받은 피드백, 칭찬 메시지(매주 하나씩 받은 것 같습니다😃!)
최근 한 달 동안 받은 피드백, 칭찬 메시지(매주 하나씩 받은 것 같습니다😃!)

개발 과정에서도 활발한 피드백(기능적인 부분, UX 적인 부분 등)과 칭찬을 받았고, 덕분에 처음 계획보다 더 나은 결과를 만들 수 있었습니다. 정말 감사합니다. 🙏 마지막으로 카카오페이 크루 여러분, 배포 과정에서 불편한 부분이나 개선되었으면 하는 부분이 있으면 언제든 편하게 말씀 부탁드립니다!

Footnotes

  1. SRE (Site Reliability Engineering)는 시스템, 서비스 및 제품의 적절한 수준의 신뢰성을 지속적으로 달성하기 위한 엔지니어링 분야입니다.

  2. SRE팀은 카카오페이 서비스의 신뢰성 확보를 위한 조직입니다.

  3. RE (Release Engineering)는 소프트웨어의 안정적인 릴리스와 운영을 위한 엔지니어링 분야입니다.

  4. RE파트는 카카오페이의 안정적인 서비스 운영을 위한 조직입니다. 빠르고 효율적인 소프트웨어 배포의 모든 것들을 운영/관리/개발하는 것을 목표로 하고, 특히 소프트웨어 배포 프로세스 운영/관리를 주로 담당하고 있습니다.

  5. VROOM 배포통제시스템은 카카오페이의 IT 내부 통제 관점에서 절차와 권한에 맞게 프로그램 변경(애플리케이션 배포)이 이뤄질 수 있도록 하기 위한 시스템입니다. 2

ari.a
ari.a

카카오페이 SRE팀 RE파트 아리입니다. CI/CD (Continuous Integration/Continuous Delivery)에 관심이 많고, 자동화를 좋아합니다. 🙂

태그