오늘은 데이터 엔지니어링의 기술이 아닌 코드 리뷰에 관한 글을 리뷰해보고자 한다. 흔히 개발자는 혼자서 일한다고 생각하기 쉽지만 그렇지 않다. 여러 팀이 유기적으로 묶여있고 같은 팀 내에서도 배포와 유지보수를 꾸준히 해야 하기 때문에 단순히 코드만 잘 작성하는 것이 능사는 아니다. 토스페이먼츠는 결제의 다양한 맥랑을 다루는 회사로, 코드 변경과 배포가 신중하게 이루어져야 한다. 이를 위해 코드 리뷰를 진행하고 있는데, 피드백의 속도와 PR 코멘트로 이루어지는 대화의 양이 가장 중요한 조건이라고 한다. 이를 위해 Github Actions로 코드 리뷰 문화를 개선했다고 한다. 어떤 부분을 중요하게 생각하고 개선했는지 알아보자.
기술 블로그 출처
https://toss.tech/article/25431
GitHub Actions로 개선하는 코드 리뷰 문화
자동화를 통해 코드 리뷰 문화를 개선하고 편의를 높였던 경험을 공유해요.
toss.tech
Github Actions
토스페이먼츠에서는 피드백의 속도와 PR 코멘트로 이루어지는 대화의 양이 가장 중요한 조건이라고 했다. 따라서 리뷰어 할당부터 개선을 진행했고 Github Actions를 사용하여 리뷰어 자동 할당 기능을 개발했다. Github Actions는 기능 구현과 유지보수가 간편하고, 개발자들의 워크플로우에 잘 맞아 커스터마이징에 용이하다.
Github Actions 이란?
빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있는 지속적 통합 및 지속적 배포(CI/CD) 플랫폼으로, 레포지토리에 대한 모든 풀 요청을 빌드 및 테스트하는 워크플로를 생성하거나 머지된 풀 요청을 프로덕션에 배포할 수 있다.
Github Actions는 커뮤니티에서 많은 템플릿과 작업을 공유하고 있어 다른 사용자들이 개발한 액션을 사용하여 쉽게 프로젝트에 통합할 수 있다. 또한, 워크플로우 파일을 작성하여 여러 단계의 작업을 정의하고 실행할 수 있다.
Github Actions의 구성 요소
- Workflows
- Github Actions의 기본 구성 단위
- yaml 파일에 정의되고, workflow는 하나 이상의 작업을 포함할 수 있으며 레포지토리에서 푸시 또는 풀 요청과 같은 이벤트에 의해 트리거 된다.
- Events
- 워크플로를 시작하는 트리거
- 일반적인 이벤트에는 푸시, 풀리퀘스트 및 일정이 포함된다.
- Jobs
- 워크플로 내에서 실행되는 개별 작업
- 러너라는 가상 머신에서 실행되며 하나 이상의 단계를 포함할 수 있다.
- 작업은 종속성에 따라 병렬 또는 순차적으로 실행될 수 있다.
- Steps
- 작업 내 가장 작은 작업 단위
- 각 단계는 셀 명령을 실행하거나 작업을 실행할 수 있다.
- step은 워크플로 파일에 지정된 순서대로 실행되며 각 단계는 동일한 실행기 인스턴스 내에서 실행된다.
- Actions
- 작업 흐름에서 공유 및 결합할 수 있는 재사용 가능한 코드 단위
- Github 커뮤니티에서 개발 및 게시하거나 자체적으로 사용할 수 있도록 만들 수 있다.
- 일반적으로 별도의 레포지토리에 저장되며 해당 레포지토리 이름으로 워크플로 파일에서 참조된다.
- Runners
- 작업이 실행되는 가상 머신 또는 자체 호스팅 환경
- Github은 다양한 운영 체제 및 하드웨어 구성을 호스팅 러너에 제공하거나 보다 전문적인 요구 사항을 위해 자체 호스팅 러너를 설정할 수 있다.
1. 리뷰어 지정하기
토스페이머느는 내부 워크 플로우를 주로 타입스크린트로 개발하는데, 유지보수의 편의성을 위해 타입스크립트로 개발했다. 이 워크플로의 로직은 정해진 리뷰어 목록에서 PR 생성자를 제외하고 랜덤으로 리뷰어를 선정하는 방식이다. 이 후 Github에서 제공하는 toolkit이라는 SDK를 통해 해당 리뷰어를 할당한다.
* Github toolkit: Github에서 제공하는 도구 모음으로, 타입스크리트로 Github Actions 워크플로를 작성할 때 사용할 수 있는 라이브러리이다. 이 toolkit은 Github Actions를 사용하여 CI/CD 워크플로를 작성할 때 일반적으로 필요한 작업들을 간편하게 수행할 수 있도록 도와준다.
리뷰어 후보는 yaml 파일에 정의되어 있으며, 이 파일은 리뷰어가 될 사용자들의 Github username과 Slack userid 쌍의 간단한 구조로 이루어져있다. 만약 새로운 리뷰어가 추가되면 yaml 파일만 수정하면 된다. 이 워크플로를 적용한 결과, PR리뷰가 짧아지고 코멘트 수가 증가했으며, 팀 내 맥락 공유가 강화되어 운영 이슈 대응 시간이 크게 줄었다.
2. 리뷰어에게 알림 보내기
리뷰어가 되면 Github이 메일로 알림을 보내는데 이메일을 자주 확인하지 않으면 본인이 리뷰어인 것을 인지하기 어려웠다. 그래서 슬랙봇으로 리뷰어가 되었다는 메시지를 보내는 기능을 추가했다.
기존 yaml 파일에 이미 리뷰어의 username과 userid 정보가 있었기 때문에 slackClient를 호출하는 코드만 추가해 문제를 해결했다. 이를 통해 실제로 팀원들이 리뷰를 시작하는 시점이 빨라졌다.
3. 오늘 안에 리뷰할 수 있게 하기
PR 리뷰 지연으로 인해 리뷰가 누락되는 상황을 방지하기 위해 리마인드 워크플로우를 개발했다. 이 워크플로우는 평일 오후 2시에 팀 채널로 알림을 전송하여 리뷰되지 않은 PR을 다시 알려준다. GitHub Actions의 cron 표현식을 이용하여 매주 월요일부터 금요일까지 오후 2시에 워크플로우가 실행되도록 설정했다.
* cron 표현식: 리눅스와 유닉스 시스템에서 주기적인 작업을 실행하기 위해 사용되는 시간 표현식
4. 공휴일에는 리뷰 건너뛰기
PR 리마인드 워크플로우는 cron 표현식을 기반으로 동작하는데, 주말뿐만 아니라 공휴일에도 동작하고 있었던 문제가 있었다. 이를 해결하기 위해 토스페이먼츠의 PG 회사 속성을 활용하여 공휴일 정보를 확인하는 유틸리티를 사용했다. 이를 통해 공휴일일 경우에는 알림을 보내지 않도록 코드를 수정했다.
후기
토스페이먼츠에서 효율적인 코드 리뷰를 위해 어떻게 해결했는지 알 수 있었다. 팀 내부의 업무 효율화를 위해 문제를 해결했을 때 받는 긍정적인 피드백은 큰 원동력이 된다고 한다. 역시 개발 또한 혼자가 아닌 여럿이서 하는 업무이고 같이 성장해 나가는 매력이 큰 직업인 거 같다.
