반복적이고 귀찮은 일은 Bot에게! (feat. ChatOps)
안녕하세요. 네이버 파이낸셜 통합조회 & 인증 FE팀의 이한주입니다.
열면서
회사에서 업무를 수행하다 보면, 간단하지만 반복적이고 번거로운 일을 매일 하고 있는 자신을 발견하게 됩니다. 특히 개발 업무 외적으로 신경을 써야 하는부분이 꽤 많습니다.
예를 들어 평소에 배포 완료 후 관련 이슈에 확인 요청을 드리거나, 배포 후 브랜치 정리 등 다른 사람의 확인을 받아야 하는 경우 업무의 호흡이 길어지고 불편한 경우가 많습니다.
평소에 신경 써야 하는 업무도 많은데 간단하지만, 반복적이고 귀찮은 일들을 자동화해 업무의 효율성을 높일 수 없을까? 라는 의문에서 이번 프로젝트를 기획하고 진행하고 있습니다.
현재 네이버 파이낸셜에서는 협업 도구로 네이버 메신저인 Works를 사용하고 있는데요.
이번 글을 통해 네이버 Works Bot과 ChatOps를 통한 자동화 사례를 소개해 드리고자 합니다.
ChatOps 구성도
저희 팀에서 사용하는 Bot 의 구성도 입니다.
먼저 Bot이 포함된 채팅방에 채팅을 치면, Bot Sever로 채팅 내용이 전달됩니다. 전달된 사용자의 채팅을 분석해 사용자가 원하는 기능을 대신 수행해줍니다.
네이버 파이낸셜에서는 Github Enterprise를 사용하고 있어, 자동화에 필요한 정보는 Github API를 통해 가지고 오고 있습니다. 사용자가 시킨 작업이 완료되면 작업 결과를 Works API를 통해 채팅방으로 전달합니다.
위와 같은 구성도로 봇 개발을 완료했습니다. 그럼 저희 봇이 대신해주는 일을 알아볼까요?
평소
방금 배포로 해결된 이슈가 뭐지?
실제 서비스가 배포가 나가기 전, 해당 서비스에 대한 QA 진행을 해야 합니다. QA 이슈가 등록되면, 해당 기능을 수정 및 개발하고 배포하는 프로세스를 거치게 되는데요.
그 과정에서 실제 테스트 서버에 배포가 되었는지, 배포 되었으면 무슨 이슈가 배포 되었는지 등등 확인하고 공유해야 하는 번거로움이 있습니다.
저희 팀에서 사용하는 배포 툴에는 배포 시작 및 완료 알림을 설정하는 기능이 있는데요. 왼쪽의 사진을 보면 배포를 누가 했는지, 어떤 이슈에 대한 배포인지 한눈에 확인하기 어려운 점이 있습니다.
QA에서 확인하기 위해선, 어떤 이슈가 배포되었는지 확인해야 하고 공유해야 하는 번거로움이 있는데요. 아이콘을 통해 한눈에 상태를 파악하고, 배포자가 누군지, 관련된 이슈나 PR이 무엇인지 확인하기 편하도록 자동화를 했습니다.
배포 전
오늘 배포나가는 이슈가 뭐지?
저희 팀에서 진행하고 있는 배포 프로세스는 다음과 같습니다.
배포 담당자가 배포를 준비하기 위해선 배포 나갈 마일스톤을 확인하고,
마일스톤에 할당된 있는 이슈들을 살펴보며 해당 이슈의 진행 상황을 담당자한테 확인하고,
배포 전까지 QA가 완료되었는지를 다 확인한 후에 배포가 이루어집니다.
위와 같이 배포를 나가기 전에 확인해야 할 사항들이 많은데요. 아침부터 배포 전까지 계속 마일스톤을 확인하고, 제외하거나 추가할 이슈를 확인해야 하는 불편함이 있습니다.
네이버 파이낸셜 FE에서는 주로 Github 이슈를 통해 이슈를 등록하고 해결하고 있습니다.
husky라는 Git Hook을 이용해 브랜치 이름에 따라 [owner/repo이름#이슈번호] 와 같은 형태로 커밋을 생성하고 있는데요.
이렇게 Commit Ground Rule을 잘 지키면, 오늘 배포 나갈 release 브랜치와 저번 배포가 반영된 master 브랜치의 Diff Commit을 확인해보면 실제 반영된 이슈만 골라서 확인할 수 있습니다.
이렇게 release 브랜치에 실제 반영된 이슈만 골라서 확인하면, 마일스톤에 이슈가 할당되어있지 않더라도 쉽게 확인할 수 있습니다.
배포 후
배포는 잘 마무리 되었는데… 브랜치 정리는 언제 다하지?
현재 네이버 파이낸셜 FE 팀은 공통으로 Git 브랜치 정책을 Git-Flow를 사용하고 있습니다.
Git Flow를 사용하여, 배포하는 시나리오는 다음과 같습니다.
- 배포 완료
- release 브랜치로 release 태그 및 release note 작성
- release 브랜치 > master 브랜치로 PR 생성 후 Merge
- 3번이 Approve 되면, master 브랜치 > develop 브랜치로 PR 생성 후 머지
- 배포한 Repo가 여러 개라면, 그만큼 n회 반복
배포가 늦게 끝나 3번 단계의 PR이 다른 개발자에 의해 Approve가 되지 않는다면, 배포가 끝났음에도 다음날까지 배포 정리를 해야 되는 등 많은 시간과 노력이 쓰입니다.
배포가 성공적으로 완료되었기 때문에 위와 같은 명령어를 통해 다음 3개의 작업을 자동화했습니다.
- release 브랜치 > master 브랜치 머지 자동화
- release 태그 및 release note 생성 자동화
- master > develop으로 PR 생성
위와 같은 자동화를 통해, 배포 후 브랜치 정리를 편하게 할 수 있게 되었습니다.
팀 자랑
업무로도 충분히 바쁜데, 언제 이런 걸 만들고 자동화를 했을까요? 비밀은 저희 팀의 문화에 있습니다.
저희 통합조회 & 인증 FE 팀에는 2주에 하루 하고 싶은 개발을 하는 날이 있는데요. 업무에서 벗어나 하고 싶었던 공부나 개발을 할 수 있습니다.
마치며
이상으로 저희 팀에서 반복적이고 번거로운 일을 자동화한 것에 대해 설명해 드렸습니다.
간단하지만 반복적이고 번거로운 일을 매일 하고 있는 자신을 발견했다면, 자동화를 해보는 건 어떨까요?
긴 글 읽어주셔서 감사합니다. 🙇♂️
