레거시 교체! 달리는 기차의 바퀴를 갈아 끼우다

글 작성자: 모두의 근삼이

나는 작년에 당근마켓 사내 개발자 플랫폼인 Kontrol의 배포 기능의 핵심 툴인 GoCD를 ArgoWorkflows라는 툴로 바꾸었다. 지난 2년을 회고하면서 가장 기억에 남았던 일이라 따로 글을 남겨본다.

사실 당근마켓 SRE밋업에서도 발표했던 사례이다.
(원래 나도 발표 중 하나의 세션이 이 주제로 할 계획이었는데 개인사정으로 인해 당일 발표를 하지 못하게 되어서 같은 팀 동료인 알프레드가 대신 나의 주제를 함께 발표해주었다.)

원래 발표하려고 했던 발표자료

지난 포스팅에서 설득력을 갖추기 위해 노력한 이후로 팀에 영향력을 주게 된 기억에 남는 가장 대표적인 사례이기도 했다.

사실 Kontrol의 배포 백엔드가 GoCD였던 가장 큰 이유는 배포 시스템 개발을 처음 고민할 때 고민에 참여했던 엔지니어가 토스 출신이라서, 해당 툴에 대한 이해도가 높았던 덕에 사용하게된 것이 가장 큰 이유였다.

그런데 Kontrol이 간단한 배포 시스템에 불과했던 상황이었던 것에 비해, 지금에 와서는 굉장히 다양한 역할을 수행하는 플랫폼이 되어가는 과정에서 우리 팀은 처음 고민과는 다른 방향의 고민과 선택을 하게되었다.

예를들면 처음에는 관리의 편의성을 위해 DB 없이 사용하던 시스템 이었던것에 반해 기능 확장을 위해 플랫폼을 위한 자체 DB를 구성하고 사용하게 되기도 했다.

그러고 나서 보니, 때마침 글로벌 배포에 대한 니즈가 확대되기 시작했고, 배포시스템에는 더 유연하고 동적인 파이프라인 생성 / 관리의 필요 가 생기게 되었다.

기존에 GoCD를 활용하던 방식은 단일 템플릿을 상속받아 재사용하는 패턴이었는데, 기존의 일차원적인 3단계의 배포 구성(ci -> alpha 배포 -> prod 배포)을 모든 프로젝트가 공유하고 재사용 하던 단일 리전 배포 정적인 배포환경에서는 충분히 괜찮은 툴이었다.

하지만 그에 비해서 프로젝트마다 배포하는 리전의 범위가 달라지는 글로벌 배포에서는 하나의 템플릿을 공유하고 찍어내는 방식을 유지하기 어려워졌다.

그러고 나서 보니, 기존에 의존하고 있었던 GoCD에 외면해 왔던 불편한 점들도 눈이 밟히기 시작했다.

고민 끝에 나는 이러한 결론에 다다르게 되었다.

막상 툴을 바꾸자고 결정은 했는데, 새로운 툴을 고르는 일은 당연하지만 쉬운 일이 아니었다.
그래서 배포 플랫폼 개발을 위해 차세대 툴로 적합한 기능의 목록을 만들어 봤더니 다음과 같았다.

내가 생각해낸 적합한 툴은 바로 ArgoWorkflows였다.

대충 설명하자면, 쿠버네티스에 CRD로 설치하여 사용하는 CNCF Graduated 프로젝트 소속의 툴로써, Yaml 기반으로 다양하고 복잡한 워크플로우를 컨테이너 기반으로 생성하여 관리할 수 있는 툴인데, 대충 사용하는 모습은 다음과 같다.

내가 ArgoWorkflows가 Kontrol의 새로운 니즈에 적합한 툴이라고 생각한 배경에는 바로 yaml 기반으로 매우 다양한 요구사항을 충족할 수 있는 유연성을 가지고 있다는 점이었다.

단일 yaml에 모든 의도를 담아서 전달 할 수 있기 때문에, 다양한 니즈에 맞게 동적으로 yaml을 생산해내도록 하는 로직을 Kontrol에서 담당하게 되면 모든 배포들을 stateless하고 유연하게 템플릿의 제약을 받지 않고 자유롭게 생산하고 폐기할 수 있다.

예를들면 A프로젝트는 한국리전만 배포하고, B프로젝트는 한국/일본/영국, C프로젝트는 한국/일본/영국/캐나다 에 배포를 하는 등 제각각으로 배포를 수행하고, 심지어는 다음날 배포할 대상을 바꾸는 상황이 오더라도 DB에 정보만 업데이트 해주면 템플릿에 의지하지 않고 실시간으로 배포할 파이프라인을 찍어내는 생산공장이 있다면 매우 기분이 좋아지는 것이다.

물론 설득하는 일은 쉽지 않았다.

내가 팀에 갑자기 이 의견을 들고 왔을 때에는 다들 다양한 반응이었던 것으로 기억한다.
갑자기 ArgoWorkflows를 도입하기에는

Kontrol에서 사용하기 적합한지 검증이 되지 않았고
사용하던 익숙한 툴인 GoCD를 사용해도 개발이 불가능 하지 않았기 때문에
불확실성이 많은 ArgoWorkflows를 도입한다는 선택을 섣불리 하기 어려웠던것이 그 이유였다.

사실 내가 팀원의 입장에서 갑작스럽게 누군가 이런 주장을 시작하면 완벽히 동일한 반응을 보였을 것 같다. 회사는 탐구 동아리가 아니라 실적을 만들어내야 하는 이익 집단이고, 나는 그 이익을 극대화 하기 위해 시간과 노력을 비용으로 보고 이들을 효율적으로 사용해야하기 때문이다.

하지만 나는 그럼에도 불구하고 툴을 교체하는 작업이 궁극적으로 우리 팀이 배포 플랫폼을 개발하고 발전시키는데 장기적으로 큰 비용 감소를 가지고 올 것이라고 생각했고 설득을 이어나갔다.

글로벌 배포를 위한 계획을 논의하는 과정을 포함해 배포툴을 어떻게 할 것인지에 대한 논의를 여러번 진행했지만 결론이 나지않았고, ArgoWorkflows를 도입하고 싶다는 의지를 팀에 처음 공개하고 결론에 도달하기까지는 무려 3개월의 시간이 걸렸다.

여러번의 논의 끝에 선택할 수 있는 선택지는 두가지가 있었다.

글로벌 지원 일정과 함께 ArgoWorkflows를 도입한다.
GoCD를 커스텀하게 활용하여 글로벌 지원을 소화하고, 그 후에 ArgoWorklflows를 도입

여러번의 툴에 대한 소개와 툴의 적합성을 증명하는 PoC를 진행한 끝에 팀은 합리적인 결론에 도달하게 되었다.

우리팀은 약 한달간 두가지 선택지 중 하나를 결정하기 위해 개발을 병행하는 선택을 했다.
두 방향중 하나의 방향은 반영되지 않을 선택지였지만, 팀의 생각은 이렇게 진행되는 작업이 시간을 낭비하는 행위라고 생각하지 않는다 였던것으로 기억한다.
결과적으로 더 안전한 선택을 하면서도 잘못된 결정을 되돌리는데 소비되는 시간을 방지할 수 있는 결정이라고 판단했다.

당연히 고민을 이미 오랜기간 해왔고 ArgoWorkflows 도입을 위해 입에 거품을 물고 달려들었던 나는 다른 방향에 비해 빠른 속도로 개발을 완료할 수 있었고, 툴에 대한 결정은 결국 ArgoWorkflows를 도입하는 방향으로 결정이 되었다.
(여담이지만, 개발 과정에서 Kontrol과 ArgoWorkflows를 연동하는 과정에서 핵심적이 되는 ArgoWorkflows의 일부 기능에 버그가 있었는데, 너무 툴을 도입하고 싶었던 나머지 ArgoWorkflows에 버그를 해결하는 기여를 시작한 것으로 계기로 컨트리뷰터가 되어서 이후에 오픈소스 컨트리뷰톤에 멘토로 참가한 이야기는 다른 포스팅에서 풀었다.)