이번에 사내에 구축한 Github Actions을 주제로 회사 블로그에 게시글을 작성하게 되었다. Github Actions에 대해서는 하고 싶은 이야기들이 많다.
내가 카카오 엔터프라이즈에 입사해서, 처음으로 내가 주담당자로서 맡게된 과제는 Github Actions으로 사내 서비스들의 CI 파이프라인을 구축하는 것이었다. 이전 부스트캠프 프로젝트에서도 미약하게나마 Github Actions으로 무중단 배포를 자동화해본 경험이 있었고, DevOps에 흥미도 많았기에 흔쾌히 과제를 받게 되었다.
하지만 그 과정이 결코 쉽지는 않았다.
우선 사내에서 사용하는 다양한 인프라들에 대한 이해가 필요했다. 자세한 설명은 하지 않겠지만, 사내 인프라들의 관계 때문에 요구되는 다양한 제약사항이나 설정들이 필요했다. 대표적으로 ACL, Proxy가 그 예이다. Github Actions 과제를 맡았을 때는 입사한지 얼마 되지 않았을 때이기에, 당연히 이러한 인프라들과 그로 인한 설정 등에 대해 잘 모를 수 밖에 없었다. 그래도 직접 부딫혀가면서 궁금점이 생기는 부분들은 팀원들에게 질문하면서 빠르게 파악할 수 있었다.
사실 더 힘들었던 점은 그 당시 사내에서 Github Actions을 지원한지 얼마 되지 않았다는 점이다. 우리 회사는 Github Enterprise를 사용하는데, 그 당시 DevOps팀이 Github Enterprise를 Github Actions를 지원하는 버전으로 업그레이드한지 얼마 되지 않았었다. 그래서 사실상 DevOps팀의 Github Actions 인프라 구축과 같이 Github Actions 파이프라인을 개발하게 되었다. 당연히 워크플로우 파일 자체의 문제가 아닌 인프라 자체의 문제도 많이 발생했었고, 그로인해 기존 방식을 사용하지 못하거나 추가적인 개발이 필요한 경우도 많이 발생했다. 이렇듯 개발 시기 때문에 더 힘들어지기도 했지만, 오히려 덕분에 나는 더 좋은 경험을 했다고 생각한다. 문제를 해결하는 과정에서 DevOps팀과 많은 이야기를 할 수 있었는데, 다른 팀과 이렇게 주도적으로 이야기하면서 문제를 해결하는 과정이 재미있었고 자신감도 얻을 수 있었다. 또 인프라적인 문제를 직접 겪으면서, 사내 인프라들에 대해 더 깊게 파악할 기회가 되었었다. 초반에 문제가 많던 부분들이 차근차근 해결되면서, 마지막에는 모두가 잘 쓰고 있는 모습을 보면서 기분도 좋았고 말이다.
이렇게 힘든 점들이 있었지만, 그 과정은 정말 값진 경험이었다. Github Actions 파이프라인을 개발하면서, 나는 이것이 내가 맡은 하나의 서비스라는 마음가짐으로 개발을 하였고, 이 서비스를 꾸준히 개선하고 관리하면서 개발자로서 한층 더 성장함을 느꼈다.
실제로 CI 파이프라인은 이미 구축이 완료되었지만, 이후의 성능 개선과 사용성 개선을 위해 더 많은 시간을 할애하였다. 그 노력의 일부가 사내 블로그에 작성했던 게시글에서 소개한 병렬 처리와 커스텀 액션이다. 병럴 처리에 대해서는 이미 자세히 설명했었고, 커스텀 액션 중에서 캐시 액션에 대해서는 조금 더 이야기하고 싶다.
성능 개선을 위해 빌드 과정에서 캐시를 다는 것은 필수라고 생각했고, 어떻게 캐시를 달지 많은 고민을 했었다. Github Actions에서 제공해주는 캐시 액션이 있지만, 이는 그 당시 Github Enterprise에서는 지원되지 않았고, 캐시 동작을 직접 구현해야 했다. 처음에는 단순히 로컬에 캐시하는 방식을 생각했었다. 하지만 이는 여러가지 사정으로 인해 적용하기 힘들었다. 그래서 사내의 Kakao I Cloud의 Object Storage를 사용하여 캐시를 구현하기로 결정하고, 어떻게 개발할지에 대해 설계하기 시작했다. 설계할 때 가장 신경 썼던 것은 사용성이었다. 나는 캐시 액션을 단순히 나 혼자 쓰는게 아니라 다른 팀도 같이 쓸 수 있도록 개발하고 싶었고, 그를 위해서는 최대한 쉽고 범용성있게 사용할 수 있어야 했다. 그래서 이러한 관점을 가지고 설계와 개발을 완료했고, 우리 서비스들에서 사용하게 되었다. 그리고 결국 내 바램대로 몇달 뒤 DevOps팀에서 내가 개발한 캐시 액션을 개량하여 전사적으로 사용가능한 캐시 액션을 제공하게 되었다. 앞에서 말했던 것처럼 나는 Github Actions 파이프라인을 개발하면서 이것이 내 서비스라는 마음가짐으로 개발을 했었는데, 당연히 캐시 액션도 같은 마음가짐이었다. 그런데 이 캐시 액션을 전사적으로 제공한다는 사실이 나에게 굉장히 큰 행복이자 보람으로 다가왔다.
성능과 사용성 개선을 위해 앞에서 말한 두가지 말고도 더 많은 작업들을 해왔었다. 워크플로우가 종료된 이후 결과를 알림으로 보내주거나 빌드 결과물을 바로 확인할 수 있게 만들고, 캐시 사용여부나 빌드 수행여부 등도 선택적으로 수행할 수 있게 바꾸어 왔다. 또, Github Actions 뿐만 아니라 우리 서비스 자체에 대해서도 관련하여 작업을 많이 했었다. Warning을 완전히 제거하기 위해 서비스의 Warning 코드를 모두 제거하고 빌드 과정에서 Warning을 Error로 출력하게 하고, 테스트 성능 개선을 위해 테스트의 Async 처리 역시 진행하였다. 이렇듯 기능의 개발은 이미 완료되었음에도, 추가적인 개선을 위해 개발을 꾸준히 진행하면서 개발자로서의 마음가짐이 한층 더 성장한 것을 느낄 수 있었다.
이렇듯 Github Actions 파이프라인을 구축하면서 여러 경험들을 얻고, 한층 더 성장할 수 있었다. 그것만으로도 나에게는 너무 좋은 경험이었는데, 이번에 회사 블로그에 글까지 쓰게 되면서 정말 너무 좋은 경험이 되었다. Github Actions 개발을 시작할 때부터 블로그에 글을 쓰기까지 정말 많은 일들이 있었고, 좋은 사람들을 많이 만났고, 많은 성장을 할 수 있었다. 앞으로도 개발자로서 많은 개발을 하게 될 것이고, 때때로 개발이 잘 안될 때도 많을 것이다. 하지만 이번 경험을 떠올리면 그러한 상황에서도 꿋꿋이 문제를 해쳐나가며 성장할 수 있을 것이다.
