flyte 기반의 workflow 에서 argo workflow 기반으로 작업 변환하기
AI 와 데이터 분야의 발달로 소프트웨어 개발 관점에서 사용할 수 있는 데이터 파이프라인 솔루션도 꾸준히 출시되는 것들이 늘고 있다.
개발자가 많이 없는 회사에서는 클라우드에서 제공하는 파이프라인을 통째로 사용하는 경우도 볼 수 있고, 비용 절감과 개발 인력이 넉넉한 경우에는 자사에 별도의 파이프라인을 구축하는 경우도 흔히 볼 수 있다.
현재 내가 소속되어 있는 크래프트 테크놀로지스에서는 사내 모든 개발 인력이 온프레미스 쿠버네티스 클러스터에 배포되어 있는 애플리케이션들을 사용하고 있으며, 지난 2023년 9월부터 이 클러스터에 Argo workflow를 배포한 뒤, 사내 파이썬 SDK인 Qworkflow를 배포해서 Argo workflow를 통해 실행할 작업들을 모두 파이썬 스크립트로 자산화하고 있다.
우선 결과부터 말하자면, 이 과정으로 두 팀을 제외한 사내 모든 개발 팀이 자동화가 필요한 업무에 Argo workflow를 사용하기 시작했고 남은 두 팀도 현재 논의 중에 있다.
무엇보다 Argo workflow와 Qworkflow를 사내에 공개 후 얼마 안되어 제일 뿌듯했던 순간을 꼽으라 한다면, 그 동안 회사에서 사용하는 AI ETF 모델들의 포트폴리오 리밸런싱이 매월 말 ~ 초에 이뤄지는데 이 기간에 리서치 엔지니어들이 사무실에서 밤을 새고 새벽에 AI 모델을 수동으로 돌려 결과물을 정오까지 받아 고객사에 전달했다(…)
Argo workflow & Qworkflow를 개발하고 배포하는 과정도 무척 재밌었지만, 내가 아무리 개발을 잘해서 배포한다고 한들 사용하는 사람이 없으면 아무 의미없는 애플리케이션이 되므로, 전사적으로 사용을 장려하기 위해 개발 팀을 한팀씩 식사 요청을 하면서 사용해보는 것이 어떻냐고 발품을 팔았다.
이 때 Argo workflow라는 전사 파이프라인을 홍보하기 위해 발품 팔면서 앞으로는 업무 프로세스를 어떻게 잡아야할지 많은 생각들을 해주게 했는데
첫번째, 각 팀의 Workload와 일정, 그리고 업무에 필요한 컴퓨팅 리소스가 얼마나 필요한지 알고 있어야한다는 점이다.
MLOps 엔지니어이지만, 소속은 인프라팀으로 되어 있다보니 회사 인프라를 모두 알고 있는 것은 나뿐이고 각 팀의 Workload를 명확하게 알고 있지 못하면 다른 팀이 충분한 리소스가 필요한 상황에서 팀 사이에 리소스를 두고 Race Condition이 발생할 수 있다.
두번째, 팀 별 업무 사항을 파악하고 있으면 어떤 애플리케이션을 우선 순위를 두고 배포할지 대략적인 업무 우선순위가 정해진다.
이것도 인프라팀 관점이긴한데, 개발 업무와 쿠버네티스 위에 애플리케이션 배포 업무, 그리고 호스트 서버 추가까지 (즉, 하드웨어 구매부터 클러스터 편입하는 과정) 모두 내가 하므로 전사적으로 필요한 서비스가 무엇인지에 대해서는 나 혼자서 고민하기보다 실제 내부 고객인 각 팀 개발 부서의 얘기를 듣는 것이 1년 업무 방향성과 성과 지표를 잡는 것에 훨씬 수월하다.
약간의 여담이지만, 현재 내가 근무하는 회사는 아무래도 AI 보다 퀀트 트레이딩 분야에서 더 큰 두각을 드러내고 있는 것으로 보이는데 이 팀에서도 상반기에는 데이터 파이프라인 자동화가 필요하고, 7월부터는 본격적으로 ML을 퀀트 트레이딩에 접목해서 사용하는 것을 목표로 하고 있어서 Argo Workflow를 적극적으로 사용하고 있다.
마지막 세번째는, 전사 인프라를 담당하는 사람의 입장에서 모든 팀의 업무 상황과 개요를 알 수 있다는 점이다.
개발 부분에 있어 내가 스스로 자부할 수 있는 것 하나는 각 팀의 업무 상황을 제일 잘 알고 있는 것은 경영진 분들도 아닌 나라는 것이다.
모니터링 솔루션도 충분히 붙여놔서 문제가 발생했을 때 제일 먼저 대응할 수 있는 것도 나이고, 업무 서포트를 지원하는 것도 나이기 때문이다.
(참고로 2024년 1월 기준으로 우리팀은 나를 제외한 모든 팀원이 퇴사했거나 퇴사 예정이다.)
회사 CTO도 부재한 상황이고, 기술적으로 통합을 위해 강력하게 Drive를 걸어줄 사람이 없기 때문에 나 나름대로 이 상황을 타개하기 위한 물밑 작업 중 하나로 “각 팀 별로 필요한 업무가 없는지” 수요 조사를 하는 것이 가장 효과적이라고 판단했던 것 같다.
사실 개발 부분에 있어서는 지금 회사가 첫 회사이다보니 (이전에 근무했던 제네시스랩은 제외) 지금처럼 일하는 내 방식이 맞는지는 잘 모르겠다.
하지만 적어도 나중에 팀장 이상급의 개발 인력 또는 담당자가 온다면 내가 수행한 업무들로 인해 관리하는 부분들이 많이 줄어들기를 희망한다.
그래서 결과적으로 Argo Workflow는 전사적으로 필요한 자동화 업무의 85% 정도를 이관한 것으로 파악되었고, 대표님하고도 최근에 1:1 면담을 해보니 자동화 프로세스 정립을 해서 작업을 다 이관하라고 답변을 받았다.
이 포스팅을 Part.1 이라고 언급했는데, Argo workflow에 대한 포스팅은 총 3개 챕터로 도입 이유와 개발 과정에서 주로 해결하고자 했던 부분들, 그리고 사용 과정에서 문제와 한계 등을 언급하고자 한다.
그리고 추가로 도입 이유를 언급할 땐, 회사에서 원래 사용 중이던 자동화 파이프라인으로 Flyte를 Deprecate한 이유와 목적도 언급할 예정이다.
Flyte 관련 글
마지막으로 첫번째 직장이었던 멋쟁이 사자처럼 베트남 사업부에서 근무할 때 개발 관련 기사를 읽었는데, “가장 좋은 코드는 많은 사용자가 이용하는 애플리케이션에 적용된 코드"라는 것이 요새 많이 떠오른다.
내가 아무리 OOP 를 준수해서 개발하거나, 기술적으로 의미 있는 스택 & 최신 트렌드를 반영해서 서비스를 배포한다고 해도 사용하는 사람이 전무하면 그 코드의 수명은 끝이다.
개발하면서 많은 사용자들이 이용하는 코드에 대해 이렇게 깊이 고민하는 것은 이번이 처음인 것 같고, 사실 처음 Qworkflow 배포할 때 버그도 많았다.
(아직 테스트 코드는 추가하지 못했다. 필요한 기능들이 계속 떠올라서 정리하고 하나씩 추가 중이다.)
사내 모듈 개발은 이번이 두번째인데, 막상 개발해보니 회사에 필요한 게 이것저것 많다.
우아한 스터디 참여하면서 DB 캐시 서버에 대해서도 많이 배워서 시간 되면 이것도 배포해서 개발자나 리서치 엔지니어가 직접 DB에 붙는 상황도 모두 없애야겠다.
뭔가 2년차가 되어서 이제 본격적으로 개발에 대해 이해하고 접근해 나가는 느낌이 든다.
Ryan
