트위터(Twitter), 투 시그마(Two Sigma), 옐프(Yelp), 잘란도(Zelando)로부터 자체 소프트웨어 개발 플랫폼을 구축한 이유와 그 과정에서 배운 교훈을 들어봤다.
소프트웨어를 더 빠르게 빌드해 배포하길 원하는 기업 사이에서 ‘내부 개발자 플랫폼(Internal Developer Platform; IDP)’이 소프트웨어 엔지니어링 문화의 중요한 구성요소로 부상했다.
물론 내부 개발자 플랫폼 자체는 기업마다 다르겠지만 목적은 동일하다. 소프트웨어 개발자가 번거로운 인프라 관련 의사결정을 내리지 않도록 만들고, 데브옵스 팀의 과도한 운영 부담을 줄이는 것이다.
그렇다고 해서 모든 기업이 자체적인 내부 개발자 플랫폼을 구축해야 한다는 건 아니다. 하지만 복잡성 문제에 직면해 있거나 계속해서 레거시 시스템과 씨름하고 있고 또는 비즈니스 부문의 니즈를 충족하기 위해 엔지니어링 팀을 확대할 수 없는 기업이라면 IDP가 해결책이 될 수 있다.
내부 개발자 플랫폼 구축을 지원하는 스타트업 휴머니테크(Humanitec)의 CEO 카스파 폰 그룬버그는 “풀뿌리 수준에서 시작해야 한다. 유능한 엔지니어들로 구성된 작은 그룹에서 시작한다. 이들에게 분리된 툴 체인에서 접착제 역할을 하라고 요구한다. 그다음 팀이 다룰 수 있는 공통 API를 중심으로 중앙화를 시작하고, 이 구조를 비구조화된 도구들에 적용한다”라고 말했다.
한편 IDP로 전환하는 데 필요한 문화적 변화를 과소평가해서는 안 된다. 내부 개발자 플랫폼이 기업에서 의도한 목표를 달성할 수 있도록 하려면 투명성, 정기적인 커뮤니케이션, 제품 우선적 사고방식 등이 필요하다.
심지어 넷플릭스(Netflix)와 같은 엔지니어링 역량이 뛰어난 회사도 이러한 문화적 변화는 힘든 일이었다고 말한다. 넷플릭스의 시니어 소프트웨어 엔지니어 프랑크 샌 미구엘은 넷플릭스 기술 블로그에서 “모두가 사고방식을 바꿔야 했다. 애플리케이션 개발자 입장에서 플랫폼 팀이 자신의 니즈에 제대로 집중하지 못한다고 느끼는 순간도 있었고, 플랫폼 팀은 사용자 니즈에 과도하게 부담을 느끼는 순간도 있었다”라면서, “서로에게 솔직하고 개방적인 태도를 취해 이 어려운 문제를 극복했다”라고 언급한 바 있다.
인포월드(InfoWorld)에서는 자체적인 내부 개발자 플랫폼을 구축한 4개 기업과 이야기를 나눠봤다. 이를 통해 왜 IDP를 구축했는지, 어디서부터 시작해야 하는지, 그 과정에서 배운 교훈은 무엇인지, 이를 구축했을 때 얻는 것은 무엇인지 등에 관해 들어봤다.
잘란도(Zalando): “너무 빠른 성장과 많은 시스템이 초래한 문제 때문에 IDP를 구축”
독일의 이커머스 대기업 잘란도에는 전 세계적으로 수천 명의 개발자가 있고, 이들은 모두 내부 플랫폼을 사용해 코드를 배포한다. 물론 처음부터 이렇게 했던 건 아니다.
2014년 잘란도는 엄청난 속도로 성장했고, 급증하는 수요를 맞추기 위해 매주 70명의 엔지니어를 채용했다. 하지만 빠른 성장세가 내부 병목 현상으로 이어졌고, IT 운영팀이 요청을 감당하지 못하는 문제가 발생하기 시작했다. 단순하게 인력을 더 많이 채용하는 방법으로는 장기적인 관점에서 이 문제를 해결할 수 없었다.
잘란도의 전 플랫폼 책임자이자 현재는 플렉스(Plex)의 CTO인 잔 로에플러는 “더 빨리 릴리즈해야 한다면 장애물을 치우고 병목 현상을 없애야 한다. 그리고 근본 원인을 해결할 전략을 수립해야 한다. 이는 소프트웨어를 출시하는 데 걸리는 리드 타임을 단축하고 신속하게 피드백을 받는 것부터 시작할 수 있다”라고 전했다.
당시 잘란도의 주된 기술 스택은 모든 종류의 인프라에서 실행되고 있던 자바와 파이썬이었다. 애플리케이션과 서비스를 컴파일, 빌드, 테스트하기 위한 중앙 플랫폼은 없었다. 팀들은 각자의 방식으로 CI/CD를 하고 있었고, 전사적인 제어 및 감사 기능은 제한적이었다.
이를 해결하고자 시도한 첫 번째 방법은 퍼블릭 클라우드, 도커(Docker) 컨테이너, 중앙 CI/CD 파이프라인에 대한 대규모 투자였다. 몇 년 동안의 반복을 통해 지금의 IDP로 통합되었다고 그는 말했다.
로에플러는 “잘란도가 소프트웨어를 개발하는 방식 그리고 패스트 팔로워(편집자 주: 선발주자가 만든 신제품이나 기술을 빠르게 따라가는 전략 또는 기업)에서 시장 선두주자로 성장할 방법과 관련해 문화적 변화가 필요했다”라면서, “즉 인력 채용, 온보딩 방식, 혁신 문화 육성 방식에 많은 변화가 필요했고 이를 위해 확장과 혁신을 지원할 플랫폼이 요구됐다”라고 설명했다.
다행스럽게도, 기존의 업무 방식이 초래한 문제점은 비즈니스 부문이 IDP 개념을 수용하도록 유도하는 충분한 동기부여 요소가 됐다. 그래서 잘란도는 플랫폼 팀에 참여해 요구사항을 수집할 핵심 엔지니어들을 파악했다.
로에플러는 “어두운 구석에서 혼자 일하는 별도의 팀이 되어서는 안 된다”라면서, “처음부터 개발자 팀을 참여시키고 함께 회의해야 신뢰를 얻을 수 있다”라고 조언했다.
그 결과는 인상적이었다. 지난 2016년 로에플러가 잘란도를 떠났을 당시 약 70명으로 구성된 중앙 플랫폼 관리팀이 있었다. 이 팀은 수천 명의 내부 개발자들이 매일 170개의 프로덕션 릴리즈를 할 수 있도록 지원했다.
투 시그마(Two Sigma): “제품 중심 사고방식을 바탕으로 IDP를 구축”
미국 헤지펀드이자 금융 서비스 기업인 투 시그마는 약 580억 달러의 자산을 관리하고 있으며, 트레이딩 전략에 첨단기술을 활용하는 것으로 잘 알려져 있다.
지금으로부터 5년 전, 투 시그마는 온프레미스에서 실행되는 자체 개발한 레거시 소프트웨어부터 구글 클라우드나 AWS에 구축된 복잡한 머신러닝 프로젝트까지 모든 작업을 수행하면서 발생하는 복잡성 때문에 수백 명의 개발자가 어려움을 겪고 있다는 사실을 파악했다.
투 시그마의 플랫폼 엔지니어링 부문 책임자 카밀 포니어는 “자체 플랫폼을 구축해야 할 이유가 명백히 드러났다. 확장 측면에서 한계에 봉착했고, 팀들이 분리돼 각자의 방식으로 일하는 걸 보게 됐다”라고 말했다.
그에 따르면 현재 투 시그마의 IDP 플랫폼은 코드를 빌드하고, 테스트하며, 리뷰하기 위한 깃(Git) 환경 그리고 코드를 하나의 컨테이너로 패키징하기 위한 내부 실행 환경으로 구성돼 있다. 이를 통해 개발자들이 운영, 모니터링, 컴플라이언스를 크게 신경 쓰지 않을 수 있도록 했다.
포니어는 “제품 중심 사고방식으로 접근하는 게 가장 중요하다. 엔지니어는 자신의 도구를 제품으로 생각하지 않는 경우가 많다. 협력하는 방식도 마찬가지다. 내부 플랫폼 팀이 실제로 비틀거리는 지점이 여기다”라고 지적했다.
일단 내부 팀이 구성됐다면 다음 과제는 개발자들의 주요 고충을 파악하고, 이들에게 줄 적절한 ‘당근’을 식별해 IDP를 널리 도입시키는 것이다. 운영 용이성, 코드 배포와 관련된 부담 절감 등을 예로 들 수 있다. 또 이러한 여정에 동참할 수 있도록 충분한 트레이닝과 지원을 제공해야 한다고 그는 덧붙였다.
또 다른 과제가 있다. 바로 기술 부채다. 포니어는 “많은 문제가 내부 플랫폼에 쉽게 적용할 수 없는 레거시 시스템과 관련돼 있다”라면서, “모든 코드를 다시 쓰지 않고 IDP 플랫폼에 반영하는 방법을 파악하려면 팀들과 협력해야 한다”라고 조언했다.
트위터(Twitter): “IDP를 사용해 개발자 생산성이 2배 향상될 것이라 기대”
트위터는 개발자 생산성과 만족도를 높이기 위해 2011년부터 빌드팀을 중앙 집중화하기 시작했다. 이는 내부 엔지니어링 효율성 팀(Engineering Effectiveness)을 구성했던 2014년보다 훨씬 더 거슬러 올라가는 시점이다.
트위터의 플랫폼 책임자 닉 토르나우는 “현재 우리는 속도(Velocity)를 확보하고자 한다. 이는 엔지니어가 특정 시간 단위에 딜리버리할 수 있는 기능의 수로 정의되며, 2023년 말까지 2배로 향상시킬 계획이다”라고 언급했다.
트위터처럼 엔지니어링 역량이 뛰어난 기업일지라도 대규모로 이런 야심 찬 목표를 달성하는 일은 어려운 과제였다. IDP를 활용하는 대부분의 기업처럼, 이를 극복하는 열쇠는 문제를 관리할 수 있도록 잘 쪼개는 것이었다.
토르나우는 “엔지니어가 해결해야 할 공통된 우려사항을 찾아야 한다”라면서, 많은 플랫폼 기업과 마찬가지로 트위터는 IDP를 개발자가 따를 수 있는 일련의 경로를 제공하는 것으로 간주한다고 밝혔다.
이어서 그는 “만약 테스트용 베젤(Bezel)이나 스트리밍 데이터 파이프라인용 카프카(Kafka)와 같은 오픈소스 소프트웨어에 의해 이런 경로가 이미 구축돼 있다면 더 좋을 것이다”라면서, “대안이 없는 경우에만 자체적인 방식을 추구해야 한다”고 덧붙였다.
토르나우와 그의 팀은 개발자들이 코드에만 집중할 수 있도록 보안, 신뢰성, 컴플라이언스와 같은 기본적인 우려사항을 없애고자 한다. 그는 “플랫폼이 이러한 기본적인 우려사항을 없애는 일을 한다. 우리는 개발자가 코드를 빠르게 작성한 다음 테스트와 카나리아 배포, 모니터링 등의 모든 단계를 자동화할 수 있길 바란다”라고 설명했다.
때때로 개발자와 플랫폼 팀 사이에 긴장 관계가 발생하기도 한다. 토르나우는 “복잡한 목표를 가진 사람들과 이야기하고 있다는 걸 아는 게 중요하다”라고 말했다.
그에 따르면 서로의 말을 경청하는 한편 니즈를 명확하고 투명하게 설명해야 한다. 이렇게 하면 긴장을 완화하고 합의점을 찾는 데 도움이 될 수 있다. 토르나우는 “왜 이런 결정이 내려졌는지 이해할 때 공감대를 형성할 수 있다”라고 전했다.
마지막으로 그는 새 플랫폼으로 모든 것을 다시 구축하는 대신, 이미 가진 것을 중심으로 구축하는 게 좋다고 조언했다. 토르나우는 “기존 플랫폼을 점진적으로 확장하고 현재 보유하고 있는 툴부터 시작하는 게 더 쉽다. 몇몇 사람을 선별하고 이들을 중심으로 구축한다. 이것이 출발점이다”라고 말했다.
엘프(Yelp): “IDP를 진화시키다”
인기 리뷰 사이트인 엘프의 내부 개발자 플랫폼은 매우 잘 구축돼 있다. 심지어 멋진(아니면 맛있는?) 이름까지 있다. 바로 ‘PaaSTA’다.
2014년에 처음 개발된 엘프의 IDP는 전담 운영팀이 수동으로 배포하는 프로세스에서 엔지니어들을 해방시키는 방법으로 등장했다.
옐프의 인프라 엔지니어링 부문 VP 조지 바쉬는 “IDP의 필요성이 분명했다. 인프라와 관련 없는 개발자들이 인프라에 너무 많은 시간을 소비하고 있었고, 우리가 원하는 만큼 빠르게 움직이지 못했다. 또 기술 부채가 걷잡을 수 없어졌다. 이는 모두 느린 릴리즈 프로세스에 묶여 있었기 때문이었다”라고 전했다.
이름에서 알 수 있듯이 ‘PaaSTA’는 옐프의 자체적인 서비스형 플랫폼(Paas)이다. 옐프의 전 사이트 안정성(SR) 엔지니어이자 현재는 넷플릭스에서 일하고 있는 카일 엔더슨은 지난 2015년 11월 블로그에서 “이를 사용하면 개발자가 깃 리포지토리의 코드를 빌드, 배포, 라우팅, 모니터링하는 방법을 정확하게 구성 파일에서 선언할 수 있다”라고 설명했다.
당시 플랫폼은 코드 딜리버리 및 컨테이너화를 위한 도커(Docker), 코드 실행 및 스케줄링을 위한 아파치 메소스(Apache Mesos), 장기 실행 서비스 관리를 위한 메소피어 마라톤(Mesosphere Marathon), 배치 작업을 위한 크로노스(Chronos), 서비스 등록 및 검색을 위한 스마트스택(SmartStack), 모니터링 및 알림을 위한 센수(Sensu), CD를 위한 젠킨스(Jenkins)가 혼합된 형태로 구축됐다.
바쉬는 “그 이후로 플랫폼이 많이 진화했다. 모든 구성 요소를 교체했기 때문이다. 메소스는 쿠버네티스(Kubernetes)로, 스파크는 플링크(Flink)로, 스마트스택은 엔보이(Envoy)로 바뀌었다. 이것이 우리가 IDP를 구축한 이유 가운데 하나다. 비유하자면 우리가 비행하는 동안 인프라팀은 비행기 날개를 교체하고, 개발자들은 물건을 만들면 된다”라고 말했다.
한편 엘프는 플랫폼 팀과 개발자 사이에 일정 수준의 신뢰가 형성되길 원하지만, 한 팀이 여기서 벗어나 자체적으로 진행하고 싶다면 그렇게 할 수 있는 자율성을 지원한다. 바쉬는 “만약 이런 일이 일어난다면 우리는 왜 신뢰를 잃었는지 묻고, 이 문제를 해결하기 위해 투자해야 한다”고 언급했다.
이어서 그는 “많은 것이 기본적인 제품 관리로 귀결된다. 사용자와 계속해서 연락을 취해야 한다. 상아탑을 만들어서는 안 된다”고 덧붙였다.