카카오페이증권이 플랫폼 엔지니어링으로 얻은 것
플랫폼 엔지니어링은 인프라 조직이 비즈니스 경쟁력을 강화하는 데 어떻게 기여할지 다양한 방법을 고민하는 노력이다. 데브옵스와 사이트신뢰성엔지니어링(SRE)의 기반에서 각 기업 환경에 맞는 셀프서비스를 제품으로 만들어서 개발조직의 개발생산성을 높이는 게 결국 비즈니스를 잘 되게 하는 밑바탕이다.” 조지훈 카카오페이증권 기술플랫폼실 실장은 최근 본지와 인터뷰에서 자사에서 추진해온 플랫폼 엔지니어링의 의미에 대해 이같이 밝혔다. 지난 19일 열린 'AWS서밋서울 2024' 기조연설 무대에 올랐던 조지훈 실장은 카카오페이증권에서 사내 개발자를 위한 개발 플랫폼을 구축하고 제공하는 업무를 총괄하고 있다. 개발자가 개발 업무를 즉시 시작하는데 활용할 수 있는 다양한 IT서비스를 셀프서비스형 제품으로 만들어 제공하는 플랫폼 엔지니어링을 이끌고 있다. 플랫폼 엔지니어링은 데브옵스, SRE 등에 이어 등장한 소프트웨어 엔지니어링 방법론이다. 기존 인프라조직에서 진화한 형태인 플랫폼엔지니어링 조직은 개발 수명 주기의 복잡성을 관리하기 위해 중앙화된 도구와 자원을 내부 개발 조직에 제공하는 데 집중한다. 조지훈 실장은 “데브옵스와 SRE는 비즈니스 개발과 서비스 출시 프로세스를 생산성있게 변화시키고 개선하는 과정에서 개발과 운영 조직을 문화적으로 바꾸는 시도”라며 “전통적인 개발 방식을 더 개선하고 효율화하는 것으로, 플랫폼 엔지니어링은 그 효율화에 그치지 않고 소프트웨어 개발팀에서 개발 수명주기를 처음부터 끝까지 셀프서비스로 직접 다루게 하는 방식”이라고 설명했다. 조 실장은 “일반적으로 클라우드를 도입하더라도 개발팀은 운영이나 클라우드 담당팀에 업무를 요청하고 응답과 결과물을 받아 진행하는 과정을 필요로 한다”며 “그 영역을 개발팀이 셀프서비스로 시작하게 되면 업무 병목은 더 줄어들고, 생산성이 효율화된다”고 덧붙였다. 카카오페이증권 플랫폼개발실은 온프레미스와 퍼블릭 클라우드 환경을 혼용하는 IT 환경에서 개발팀과 여러 조직의 사용자 경험을 동일하게 제공할 방안을 고민했다. 이를 위해 쿠버네티스 기반과 아마존 EKS 기반을 통합하는 CI/CD 플랫폼 '월가(Wallga)'를 만들었다. 사용자경험을 젠킨스로 단일화하고, 기술스택 지원에 제한을 없게 했다. 개발조직은 배포하는 서비스와 앱이 아마존 EKS에 배포되는지 온프레미스에 배포되는지 모르지만, 코드 테스트와 빌드, 통합 등의 작업은 지속적으로 유지되게 한다. 쿠버네티스 이벤트 플랫폼인 '호크아이(Hawk-Eye)', 쿠버네티스 API 프록시인 '헬라(Hela)' 등도 만들었다. 월가는 2022년 중반부터 서비스를 시작했다. 이후 조금씩 기능을 늘려가며 다른 플랫폼으로 확장되고 있다. 조 실장은 “지엽적으로 보면, 퍼블릭 클라우드는 확장성의 장점을 가지니 그를 최대한 활용하기 위해 자동으로 자원을 늘렸다가 줄였다 하는 시스템도 제공하는 등 계속 개선하고 있다”고 말했다. 그는 “그리고 개발자 생산성 플랫폼으로 '위캔(Wecan)'이란 시스템을 구성해 그 안에 CI/CD 플랫폼이나 자원을 추천하는 시스템도 접목시켜 통합시켰다”며 “장기적인 목표는 하나의 대시보드 형태에서 개발자가 버튼 하나로 원하는 행위를 완료할 수 있는 것”이라고 강조했다. 월가의 기본베이스는 깃허브, 젠킨스, 아르고CD 등 세 툴을 이용해 통합 관리된다. 조 실장은 “아직 완전히 구현된 건 아니지만, 사용자 입장에서 젠킨스와 아르고CD 존재 자체는 크게 중요하지 않다고 생각한다”며 “사용자가 뒷단의 어느 기술, 어떤 오픈소스 툴이 사용되는지 모르게 만드는게 우리의 꿈이자 목표”라고 밝혔다. 플랫폼 엔지니어링 영역에서 개발자는 하나의 고객이다. 그리고 그 고객에게 제공하는 개발자 플랫폼은 '제품'이다. 개발자 플랫폼은 애플리케이션 라이프사이클 전체에서 코드를 개발, 배포, 유지 관리하는 데 필요한 셀프서비스 도구와 기술의 표준화된 세트로 구성된다. 개발자 플랫폼에 통합된 도구체인은 개발자에게 긍정적이고 생산적인 워크플로우를 지원하고 보안 및 확장성과 같은 요소에 초점을 맞춰 궁극적으로 기업이 더 많은 고객 가치를 창출하는 데 도움을 줄 수 있다. 조 실장은 “여기서 셀프서비스란 건 고객 관점과 제품관점에 초점을 둔다는 것”이라며 “회사 내부 제품이지만, 내부 사용자 기반에 더 완성도 높은 제품을 제공하고자 한다”고 말했다. 그는 “플랫폼 엔지니어링 영역이 데브옵스와 SRE 기반에서 출발하다보니 일반적으로 제품을 개발하던 개발팀 경험자보다 인프라와 데브옵스 엔지니어 비중이 많다”며 “그러다보니 제품으로서 완성도를 높이고 만드는 과정을 좀 생소하게 여길 수 있다”고 설명했다. 그는 “제품을 만드는 과정에서 고객을 생각하기보다 만드는 사람 위주로 제품을 바라보고 시도하다가 좋은 의도에서 만든 결과물이 고객에게 필요하지 않은 것도 있는 등 시행착오도 많이 겪었다”며 “플랫폼 엔지니어링을 수행하는 엔지니어도 고객지향적인 개발을 하는 팀처럼 제품 관점에서 관심을 갖고 고객에게 집착하는 걸 배워나가는 게 중요한 포인트였다”고 덧붙였다. 국내에서 플랫폼 엔지니어링은 자주 등장하지 않는 용어다. 생소할 수 있는 이 개념을 조지훈 실장은 어떻게 접하게 됐을까 물어봤다. 그는 데브옵스와 SRE를 하다보니 자연스레 필요성을 느끼게 됐다고 했다. 그는 “처음에 플랫폼 엔지니어링이란 개념을 접했다기보다 데브옵스와 SRE 업무를 하면서 더 편리한 환경을 개발자나 내부 조직에게 제공하는 걸 목표로 하다보니 생각하게 됐다”며 “편리하다에서 끝나지 않고 개발팀과 고객이 제품의 가치를 느끼고 이걸 쓰는게 자기 일을 더 효율적으로하게 하고 비즈니스 개발과 사업에 기여하는 경쟁력을 더 좋게 한다는 걸 느끼게 해야 한다고 생각했다”고 말했다. 그는 “그 점에 집중하다보니 제품으로서 셀프서비스가 필요해졌고, 증권회사란 기업 성격과 그 IT에 맞는 환경의 제품이 필요했다”며 “고민 와중에 플랫폼 엔지니어링을 화두로 아마존웹서비스(AWS)에서 지속적으로 정보를 공유하는 자리를 마련하는 것을 알았고, AWS의 다양한 밋업이나 기술교류를 통해 고민하던 것과 그 개념의 기치가 잘 맞는다는 걸 알게 돼 여러 기술트렌드를 찾아보면서 연구했다”고 덧붙였다. 카카오페이증권은 플랫폼 엔지니어링 조직을 별도로 구성해 시작하지 않았다고 한다. 개발 지원업무 담당자들이 기존 업무를 수행하면서 점진적으로 중앙집중화된 서비스 플랫폼을 구축하기 시작했다. 조 실장은 “기존 팀이 플랫폼을 만들어가는 것”이라며 “조직을 새로 세팅하는 게 아니라 서버 개발자나 백엔드 개발자가 퍼블릭 클라우드로 비즈니스 속도에 맞게 RNR 없이 주인없는 일을 하면서 시작하다가 플랫폼 구현 기술이나 관점을 자기 커리어로 만들고자 하는 엔지니어가 점점 많아져 업무가 확장되는게 좋다고 생각한다”고 말했다. 그는 “카카오페이증권도 목표를 구체화하고 팀을 세팅해 시작하기보다 그 업무를 좋아하고 가치있다고 믿는 두세명의 인원끼리 하게 됐다”며 “당장 비즈니스를 빠르게 출시하는데 필요한 미션을 같이 수행하면서 점차 조직을 확장시키고 업무 범위를 구체화하면서 더 많은 목표나 미션을 잡고 점진적으로 발전했다”고 강조했다. 회사 내 고객으로서 개발자는 각자 다양한 선호와 역량을 갖고 있다. 때문에 중앙집중형으로 서비스 도구를 제공받고 익숙하지 않은 기술을 활용하게 되는 것을 비판적으로 바라볼 수 있다. 플랫폼팀의 제품이 고객에게 자칫 외면받아 공전할 수 있는 것이다. 조 실장은 “개발팀이나 다른 조직에게 도움될 것으로 여겨서 만들었지만 아닌 경우도 있어서 사용을 강제하거나 하는 다양한 접근방식도 많이 시도했다”며 “그러나 모든 제품이 그렇듯 사용자 본인이 쓰면서 장점과 이득을 실제로 느껴야 흥행이 되는 것”이라고 말했다. 그는 “그 부분에 초점을 두고 지속적으로 우리 제품으로 얻는 이득과 정점을 개발팀에 홍보하는 행위와 테크토크를 지속했다”며 “결국 플랫폼팀이 제공한 제품을 사용하니 더 편해지고 더 안정성을 느껴고 더 효율화된다는 포인트를 같이 느끼는 사례를 하나둘씩 늘려나가는 게 중요했다”고 밝혔다. 플랫폼개발실의 CI/CD 플랫폼 서비스 기획은 기존 개발팀을 대상으로 한 설문조사에서 시작됐다. 여러 오픈소스 소프트웨어와 도구 중 호불호를 조사하고, 어떤 기술을 제공받고 싶은지 의사를 물었다. 그 결과를 기반으로 범용적인 것을 목표로 삼아 개발하고 조금씩 기능을 추가했다고 한다. 그는 “시간이 지나면서 기본베이스는 범용 제품이지만, IT 기반의 증권사란 기업 특성에 맞게 자유도를 높일 수 있는 기능을 계속 추가하기 시작했다”며 “예를 들면, 서비스 담당자가 본인 담당 앱을 배포할 때 배포되는 자원을 조정할 수 있게 하는 기능이 있다”고 소개했다. 그는 “배포된 자원을 실수로 잘못 조정하면 장애나 다른 영향을 줄 수 있으므로, 어느정도 제어는 두되 사용자 액션을 가두는 방식을 지양하기 위해 앱의 방식을 세분화해 표준으로 지정된 자원을 선택적으로 사용하게 열어두거나 하는 식”이라고 설명했다. 현재 새로운 제품 개발을 위한 아이디어 선택은 '바텀업' 방식으로 이뤄진다. 각 팀에서 우선순위를 조정하고 구현해야 할 기능과 아이디어를 지정한다. 조직 관점에선 가고자 하는 로드맵이나 주요 포인트 정도만 잡고, 우선순위 조정은 각 실무자가 한다. 사용자 반응은 지속적으로 살핀다. 처음도 그랬고 지금도 모든 사용자에게 호응을 얻는 건 아니기 때문이다. 조 실장은 “개발팀, 사용자와 계속 적극적으로 소통하는게 중요하다”며 “일반적인 제품이 AB 테스트도 하고 사용자 반응을 보려 여러 시도를 하듯, 우리도 사용자 반응을 알기 위해 AB테스트까진 아니어도 운영 개시 전 기능을 사전에 오픈해서 반응을 보며 개선하고, 오픈하기 직전까지 사용자 반응을 개선해서 오픈하는 전략을 많이 사용한다”고 했다. 개발자 플랫폼도 '제품'이기에 그 자체도 지속적 개발과 배포란 틀에서 벗어나지 않는다. 조 실장은 “CI/CD 플랫폼도 제품으로서의 신뢰성 관리, 릴리스 관리 등을 챙기고 있다”며 “계속 변경되는 릴리스나 버그픽스를 일반적인 소프트웨어 개발관리와 동일 수준으로 관리하고, 사용자 가이드 문서나 업데이트 문서도 체계적으로 관리하려고 노력한다”고 말했다. 기업은 출시한 제품이나 서비스의 성과를 관리한다. 개발자 플랫폼도 일종의 제품이고, 투자를 수반하기에 성과 관리가 이뤄질 수밖에 없다. 데브옵스도 그 성과를 측정하기 위해 'DORA(DevOps Research and Assessment) 메트릭스'가 활용되곤 한다. DORA 메트릭은 데브옵스가 변경 사항에 얼마나 빠르게 대응할 수 있는지, 코드를 배포하는 평균 시간, 반복 빈도 및 실패에 대한 인사이트에 대한 정보를 제공한다. 조 실장은 “JIRA나 깃허브에서 개발자의 활동지표를 메트릭으로 모아 관리하는 기술적으로 DORA 지표를 기반으로 유의미한 생산성 지표를 모아서 어떻게 실제 효과가 잘 보일 수 있을지 먼저 시도하고 고민하고 있다”며 “다만, DORA가 완벽하다 보지는 않고, 우리에게 맞는 걸 찾으려 여러 시도를 하고 있다”고 말했다. 그는 “개발주기가 기획부터 개발, 테스트하는 과정이 우리 내부의 업무 툴로 이뤄지니, 그 저변에서 어떤 생산적인 유의미한 지표를 활용할 수 있을까 보고 그 중 하나를 DORA라고 보고 시도하는 것”이라고 덧붙였다. 성과 관리에 대한 부분은 조지훈 실장이 플랫폼 엔지니어링을 시도하거나, 현재 수행중인 기업 담당자에게 하고 싶은 조언으로 이어진다. 그는 “처음부터 구체적인 목표를 설정하고 그를 달성하기 위해 시작하기보다 기업에 존재하는 병목 지점을 찾아서 안정성과 생산성, 효율성 등을 높일 것으로 보이는 부분을 먼저 개선하고 시도했으면 좋겠다”며 “개발팀이나 운영팀이나 플랫폼팀이나 전체 기술조직에 이뤄지는 작은 개선의 결과가 '우리에게 도움되는구나', '소프트웨어 개발주기에 장점으로 느껴지고 도움되는구나' 라고 피부로 느끼는 게 중요하다”고 말했다. 그는 “그렇게 되면 자연스럽게 조직이나 미션이 더 많이 생길 것이고, 그것에 집중하다 보면 기술적으로나 비즈니스적으로 더 좋은 효과가 난다고 생각한다”고 밝혔다. 기업 내부 고객과 플랫폼개발조직 간의 공감대 형성이 선행된 후 목표가 자연스럽게 구체화되는 게 바람직하다는 게 그의 의견이다. 그는 “플랫폼에서 주는 가치를 KPI나 여러 목적과 성과로 표현해야 하는데, 그것을 수치 하나로만 처음부터 보지 않았으면 좋겠다”며 “기업마다 적용 방식과 결과물이 다 다를 것이므로, 기업의 가치에 집중하고 목표와 성과는 그에 따라서 만들어간다고 이해하길 바란다”고 강조했다. 그는 “리소스, 인력을 투자해야 하는데 그 부분에 대해 초기에 조직적 신뢰, 그리고 믿음, 가치가어느 정도 나오기까지 믿음을 갖는게 필요하다고 생각한다”며 “초반의 작은 결과와 가치에 공감하는 느낌없이 우린 어떤 플랫폼을 만드는 게 목표고, 몇개월만에 만들겠다고 생각하고 시작하면 압박감을 느끼게 될 것”이라고 덧붙였다. 향후 계획에 대해 조 실장은 입사자의 빠른 온보딩 지원을 꼽았다. 그는 “막 입사한 개발자가 최초의 장비를 받아서 개발을 시작할 때부터 끝까지 개별적으로 활용되는 플랫폼을 하나로 연결하는 작업을 하고 있다”며 “개발자가 입사하면 튜토리얼과 업무 가이드, 인수인계 등을 받지 않으면 내부 시스템 사용하기 어려운 상황 많은데, 어떤 시스템에 들어와서 시작하면 큰 가이드 없이 일반 서비스 사용하듯 소프트웨어를 개발, 테스트하고 지표를 보고 릴리스하는 과정을 유기적으로 연결하는 작업을 준비중”이라고 밝혔다.
