[번역] 만든 건 직접 관리하라
넷플릭스의 풀 사이클 개발자 전략
아래 넷플릭스(Netflix) 개발 블로그의 글을 번역하였습니다.
https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249
때는 2012년이었다. 넷플릭스에서 서비스를 관리하는 것은 시간이 많이 걸리는 작업이었다. 개발하는 동안 종종 젖은 모래 위를 걷고 있는 거 같은 기분이 들었다. 소규모의 사용자에게 신규 기능을 테스트하는 방식으로 “일주일이 지나도 아무 문제도 발견되지 않았으니, 일단 출시하자”라는 형태로 검증을 하고 있었으나, 제대로 작동하는지 확인하는 것과는 거리가 멀었다. 문제를 조사하는 작업은 마치 팀 사이에서 고무공을 주고받는 것 같았다. 진짜 문제의 원인을 찾기는 너무 힘들었고, 문제의 원인을 다른 팀으로 떠넘기는 걸 멈추기란 더 힘들었다. 이 모든 것이 변화가 필요하다는 신호였다.
다시 2018년으로 빨리 감기를 해보면, 넷플릭스는 1억 2500만 명이 매일 1억 4000만 시간을 시청하는 서비스로 성장했다. 우리는 개발 과정과 그 후에 이어지는 시스템 운영* 과정을 개선하는데 굉장히 많은 시간을 투자했다. 넥플릭스를 만들고 운영하는 과정에서 이뤄졌던 다양한 실험들 중에서 한 가지 방법을 장점과 단점과 함께 공유하고자 한다. 우리는 우리의 경험을 공유하는 과정이 다른 이들이 더 나은 대안에 대해서 토론하고 우리의 고민에서 배울 수 있는 기회가 되길 기대한다.
* 역주: 소프트웨어 개발에서 운영이란 일반 비즈니스 관련 운영을 의미하는 것이 아니라, 개발 이후의 기능 배포 및 성능 모니터링 등의 과정을 의미한다.
한 팀의 여정
Edge Engineering 팀은 넷플릭스의 스트리밍 서비스가 제대로 작동하기 위해 AWS 상에 존재하는 서비스들의 첫 번째 단계를 담당하는 역할을 하고 있다. 과거에는 Edge Engineering 팀은 운영 중심의 팀과 출시, 운영, 지원 업무를 도맡아 하는 사이트 안정화 엔지니어(이하 SRE, Site Reliability Engineer) 전문가들로 구성이 되어 있었다. 새로운 기능을 하나 출시한다는 것은 개발팀이 운영팀과 함께 다양한 지표, 위험 수준, 트래픽 소화 가능 수준 등을 함께 고려해야 한다는 의미였고, 개발팀은 관련 내용을 전달하고 나면 운영 팀이 배포와 운영을 할 수 있도록 손을 떼면 그만이었다. 코드를 운영하고, 파트너를 지원을 효과적으로 하기 위해서는 운영팀은 새로운 기능과 버그 수정에 관해서 끊임없이 교육을 받아야 했다. 이렇게 운영팀이 따로 분리되어 있을 때 주된 장점은 별다른 문제가 없을 때 개발자들이 자신의 일에만 집중할 수 있다는 점이었다.
하지만 무엇인가 문제가 있을 때는 그 문제를 해결하는데 더 많은 시간이 필요했다. 개발팀과 운영팀 간에 커뮤니케이션을 하는 과정과 관련 지식을 전달하는 과정은, 문제를 해결하고 파트너의 질문에 답변을 하는데 중간 단계를 늘렸고, 시간 낭비로 이어졌다. 개발 관련 문제들은 운영팀이 출시된 기능에 대해서 잘 알지 못했기 때문에 문제를 발견하고 그 문제를 해결하는데 훨씬 더 오랜 시간이 걸렸다. 그리고 요즘처럼 매일매일 새로운 기능이 출시되는 것이 아니라, 코드를 작성하고 출시되기까지 몇 주까지도 걸리는 등 요즘보다 더 많은 시간이 걸렸다. 위험 경고 신호나 모니터링 혹은 성능 이슈나 속도 느려짐 등을 직접적으로 경험하고 있는 운영팀에서 그걸 간접적으로 느낄 수밖에 없는 개발팀으로 피드백이 전달되었다.
이걸 개선하기 위해서, Edge Engineering 팀은 개발자가 필요할 때 코드를 스스로 출시하고 그 이후 발생하는 이슈와 지원 업무를 수행할 수 있도록 하는 혼합된 형태를 테스트했다. 이런 과정은 개발자들이 고객들로부터 어떤 피드백이 오는지, 그리고 배포까지 개발 전체 흐름을 배우는 과정을 개선할 수 있었다. 하지만 여전히 부분적으로는 이런 개발과 운영 사이에는 간극이 존재했다. 예를 들어서, 개발팀이 각자 개발을 마치고 전체 프로세스 상에서 문제점을 찾았더라도, 개발팀은 운영팀의 배포 전문가에게 이 일을 부탁해야 하는 경우가 많았다. 그리고 운영 업무를 주로 하는 사람들에게는 굳이 자신들이 매일 하고 있는 일을 자동화해서 다른 사람들이 자신들을 더 이상 필요 없는 상황을 만들 동기가 없었다.
더 나은 방법을 찾던 중에, 우리는 한 발 뒤로 물러서서 첫 번째로 고민했던 원칙들에서 다시 시작하기로 결정했다. 우리가 무엇을 이루기 위해서 노력하고, 우리는 왜 실패했는가?
소프트웨어 개발의 생명 주기
소프트웨어 개발의 생명 주기를 구분하는 이유는 ‘아이디어가 실제로 고객이 사용할 수 있게 배포되는 데까지 걸리는 시간(time to value)’를 개선하기 위해서다. 소프트웨어 서비스를 개발을 하고 운영하는 일은 아래와 같은 역할을 필요로 한다.
Design > Develop > Test > Deploy > Operate > Support
우리는 이렇게 역할을 구분했다. 그리고 이것은 각각의 역할을 다른 사람이 나눠 갖는다는 것을 의미했다. 이런 전문화된 포지션은 각각의 역할 안에서 효과적으로 업무를 개선해 나갔지만, 한편으로는 전체 소프트웨어 개발의 생명 주기의 관점에서는 비효율성이 커져만 갔다. 전문가들은 자신의 분야에 전문성을 쌓아갔고, 자신의 분야에 필요한 것들을 개선해나갔다. 각자는 자신의 퍼즐 조각을 맞추는데 더 효과적으로 변해갔다. 하지만 소프트웨어는 고객에게 가치를 전달하기 위해서 전체 소프트웨어 생명 주기를 잘 관리하는 것이 필요했다. 소프트웨어 생명 주기의 일부분만 책임지는 전문가로 구성된 팀은 전체 프로세스를 늦추고 있었다. 다양한 전문가들을 한 팀에 넣는 것으로 이런 문제를 줄일 수 있었지만, 다양한 사람을 한 팀에 넣는 것은 커뮤니케이션 비용 증대로 이어졌고, 종종 업무 진행이 막히거나 효율적인 피드백 전달을 막았다.
개발한 것을 직접 운영하라
우리가 취했던 접근 방식을 다시 생각해보기 위해서, 아래의 글에서 인사이트를 얻었다.
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
우리는 기존의 나눠져 있던 업무 구분을 없애는 방식을 통해서 업무에 대한 이해를 높이고 피드백 방식을 개선할 수 있고, 전체 소프트웨어 개발 사이클에서 다 함께 주인 의식을 가질 수 있도록 동기 부여할 수 있었다.
“개발한 것을 직접 운영하라”라는 문장은 개발팀이 자신이 개발한 코드와 관련한 운영과 지원 업무에 함께 참여함으로써, DevOps 원칙을 직접 실천하도록 했다. 이런 운영 업무에 대한 책임을 운영팀에 전가하는 것이 아니라 각 개발 팀이 직접 수행하면서 즉각적인 피드백의 흐름을 만들었고, 인센티브 제도도 만들었다. 운영 업무의 고통을 느끼게 된 개발팀은 그 고통을 줄이기 위해서 시스템 디자인과 코드를 바꿀 수 있는 권한도 부여받으면서 책임과 함께 권한을 가지게 되었다. 각 개발팀은 각자의 개발 이슈와 함께, 성능 버그, 가용성에 대한 계획, 위험 경고 방식, 파트너 지원 등의 업무를 모두 가져가게 되었다.
개발자 도구로 확장성까지 고려하자
전체 개발 라이프 사이클에 대한 주도권은 개발자들이 더 적극적으로 운영 작업에 참가하는데 도움을 주었다. 그리고 일반 개발 과정을 단순화하고 자동화하는 도구들이 기존의 개발 업무와 이런 운영 업무의 균형을 갖추는데 도움을 주었다. 예를 들어, 만약 개발자가 이미 배포한 서비스를 이전 버전으로 되돌려야 한다면, 잘 갖춰진 도구들이 이 작업이 일으킬 수 있는 문제를 미리 발견하고 알림을 줘서, 이 작업을 도울 수 있게 되는 것이다.
넷플릭스에서는 클라우드 플랫폼 팀, 성능 및 안정성 팀, 개발 도구 팀 등 중앙 집중화된 팀을 만들고, 모든 개발팀이 가지고 있는 공통의 문제를 해결할 수 있는 도구와 인프라를 갖춘다는 목표를 세웠다. 이런 팀들은 각자가 가지고 있는 지식을 재사용 가능한 단위로 만들어 놓으면서 생산성의 기폭제 같은 역할을 했다.
이런 도구들의 세례를 받은 개발팀은 자신이 맡고 있는 제품의 문제에만 집중할 수 있었다. 그리고 추가적인 개발 도구가 필요하다는 요청을 받으면, 이런 집중화된 팀에서는 그 요구가 여러 개발팀 전체에서 필요한 것인지를 판단했다. 그리고 이것이 여러 팀에서 필요하다는 판단이 서면, 다 함께 협력해서 도구를 만들었다. 가끔 특정 개발 도구 요청이 특별한 팀에서만 필요하다는 판단이 들면, 각 개발팀에서 그런 문제의 해결 방식을 알아서 결정하게 했다.
이렇게 필요한 도구를 중앙 집중식으로 만들 것인지 혹은 개별 팀에게 맡길 것인지 균형을 맞추는 것은 우리의 접근 방식에서 매우 어려운 점 중에 하나였다. 지금까지 경험에 비춰보건대, 개발자의 수요에 따라서 새로운 해결책을 찾아내는 방식의 이점은 여러 팀이 각자의 방식을 찾아서 나중에 그 여러 방식을 통합해야 할지도 모른다는 어려움을 감안하더라도 값어치가 있는 작업이었다. 그리고 커뮤니케이션과 협업이 이런 성공에 이르는 핵심이었다. 수요를 명확하게 파악하고, 다양한 팀의 수요에서 공텅점이 어떤 것인지 확인하는 작업에서 시작해서, 우리는 투자 시간 대비 효용을 점자 증대시킬 수 있었다.
풀 사이클 개발자 Full Cycle Developers
이런 생각들을 종합해서, 우리는 개발팀이 훌륭한 개발자 생산성 도구로 무장한 채 전체 소프트웨어 개발 생명 주기(디자인, 개발, 테스트, 배포, 운영, 지원)를 처리하는 모델에 도착할 수 있었다.
풀 사이클 개발자는 개발 과정 전반에 대해서 충분히 이해하고 효과적으로 일할 수 있어야 한다. 그래서 넷플릭스에 새로 입사한 개발자들은 그동안 이전 회사에서는 하지 않았던 많은 일들을 새롭게 배워야 했다. 우리는 사내 개발자를 위한 개발 부트캠프를 열고, 이런 전반적인 지식을 전달하기 위한 다양한 트레이닝 세션을 운영했다. 단순히 지식을 가지고 있는 것만으로는 충분하지 않았다. Spinnaker과 같은 개발 파이프라인과 Atlas 같은 모니터링 툴을 능숙하게 사용하는 것은 넷플릭스에서 전체 개발 범위를 아우르며 주도적으로 일하는데 꼭 필요한 요소이다.
풀 사이클 개발자는 이렇게 받은 훈련들을 소프트웨어 개발 과정에 적용한다. 개발자들은 개발자의 관점에서 문제를 평가하고, “어떻게 이 시스템을 운영하기 위한 일들을 자동화할 수 있지?”라고 질문하게 되었다. 그리고 “어떤 서비스를 만들면 우리 파트너가 내가 직접 관여하지 않더라도 자신의 질문에 대한 답변을 찾을 수 있을까?”라는 질문을 할 수 있게 되었다. 이것을 통해 개발팀은 주도적으로 사람의 손을 타야 하는 수많은 작업들에서 자동화 방식으로 많은 일을 개선할 수 있었고, 이 덕분에 우리 팀은 손쉽게 더 많은 일을 할 수 있게 되었다.
풀 사이클 개발자 모델로 옮겨가는 일은 마인드의 변화가 필요하다. 어떤 개발자들은 이런 풀 사이클 개발자 모델을 디자인과 개발, 그리고 테스트까지로 보기도 한다. 그런데 이런 관점은 운영이라는 과정을 개발자가 집중을 방해하는 시간이라고 오해하게 만든다. 이 결과 작은 문제 수정은 운영팀이나 지원 팀에 미루고, 자신들은 “진짜 일”을 할 수 있다고 생각하게 한다. 그런데 풀 사이클 개발자에게 “진짜 일"이란 개발 전반에 대한 과정에서 여러 문제를 해결하기 위해 자신의 소프트웨어 개발 전문성을 사용하는 것을 의미한다. 풀 사이클 개발자는 엔지니어이자, 테스트 전문가이자, 서비스 안정성 기술자처럼 생각하고 일한다. 그들은 비즈니스에서 발생하는 문제를 해결하기 위해 소프트웨어를 개발하는 동시에, 테스트 코드를 짜고, 운영의 관점에서 시스템을 자동화하기 위해 시간을 쏟는다.
이런 모델이 성공하기 위해서는, 개발팀이 이런 변화가 가져오는 가치에 대한 확신과 함께, 이런 변화가 가져오는 비용에 대한 이해가 있어야 한다. 각 팀은 우선 개발, 배포, 문제 대응, 파트너 지원 등에 대한 업무를 담당하기에 충분한 인원을 배치해야 한다. 그리고 훈련에 쏟을 시간을 따로 배정하는 것도 중요하다. 거기에 맞는 도구가 적절히 활용하고, 필요하다면 개발되어야 한다. 그리고 재사용 가능한 도구를 개발하는 팀들과의 신뢰 관계 구축도 중요하다. 개발 업무의 전 과정은 계획 과정과 사후 평가 시간에 반드시 충분히 논의되어야 한다. 또 자동화된 알림 시스템이나 파트너 지원 도구 개발과 같은 “투자”는 반드시 다른 비즈니스 프로젝트와 함께 우선순위에 위치해야 한다. 적절하게 팀을 꾸리고, 우선순위를 결정하고, 신뢰 관계를 쌓으면, 개발 팀은 각자가 개발한 기능을 운영하는 데 성공할 수 있다. 그렇지 않다면 개발팀은 업무 과중, 심하면 번아웃(burnout)에 시달릴 수도 있다.
이 모델을 다른 회사에서 적용하기 위해서, 여러 변화가 필수적일 것이다. 여러 개발 팀은 배포 과정, 모니터링 등 공통적인 문제를 가지고 있다. 하지만 많은 회사들은 넥플릭스 같은 이런 도구를 개발할 수 있는 집중화된 팀에 투자하기 위한 인원이 없거나, 넷플릭스가 경험하고 있는 정도의 스케일 복잡성이 필요 없을 수도 있다. 넷플릭스에서 사용하는 도구들은 대부분 오픈소스인데, 대체로는 처음에는 이런 오픈소스를 사용한다. 하지만 넷플릭스에서 사용하는 것이 아니더라도, 다른 오픈소스나 다른 업체의 솔루션이 많은 회사들의 요구를 충족할 수도 있다. 얻게 될 가치와 비용을 잘 분석해서 이런 도구들을 사용하는 것을 시작하라. 무엇이 필요한 지 잘 평가하고, 복잡도를 낮추기 위해서 주의하라.
얻는 것과 잃는 것
테크 산업은 개발과 운영 과정에서 발생하는 수요를 충족시키기 위한 다양한 방법이 존재한다. 풀 사이클 모델은 넷플릭스에서 활용하는 방법이지만, 단점도 존재한다. 한 개발 모델을 선택해서 사용함에 있어서 얻는 것과 잃는 것을 잘 이해하는 것이 성공의 가능성을 높일 수 있다.
풀 사이클 개발자 모델에서 가장 중요한 것은 다양한 도구를 사용하면서 넓은 범위에 대한 주인 의식을 키우고 효과적인 업무 진행이 가능하도록 하는 것이다. 다양한 업무 범위를 소화하는 것은 관심과 재능이 모두 필요한 일이다. 몇몇 개발자들은 특정 분야에서 세계 최고가 되는 것을 선호하기도 한다. 그리고 IT산업에서 특정 업무에서는 이런 전문성이 필요한 것도 사실이다. 이런 전문가들은 넓은 범위에 적당한 수준의 깊이의 지식을 쌓는 것을 불편하게 생각하거나 싫어할 수도 있다. 넷플릭스에서도 몇몇 개발자도 한 분야에 깊은 전문성을 쌓기를 원하고, 넓은 분야에 업무를 수행하거나 지원 업무를 하고 싶지 않아하는 경우도 있다. 물론 다른 사람들은 이런 넓은 업무 범위를 반기기도 한다.
지금까지 클라우드 기반의 시스템을 개발하고 운영해오면서, 개발자가 개발 전체 범위를 담당할 때 효율성이 증대하는 것을 지켜봤다. 그러나 이런 업무 범위가 넓어지면 파악해야 하는 범위가 많아지고, 한 범위에 집중할 때보다 더 많은 중요 업무를 처리해야 할 일이 많다진다는 의미이기도 하다. 우리는 이런 어려움을 해결하기 위해서 개발, 운영, 지원 업무를 번갈아가면서 업무를 진행하기도 한다. 이런 풀 사이클 개발은 잘 진행된다면, 업무가 잘 집중되고 최고의 역량을 발휘하고 있다고 느낄 수 있는 일인 반면, 잘 되지 않는다면 개발자들이 항상 번아웃에 빠지기 쉬운 집중력이 분산되는 환경이 되어버릴 수도 있다.
도구를 잘 개발하고 자동화하는 것은 전문성을 잘 활용하는데 도움이 된다. 넷플릭스는 잘 닦아놓은 도구들을 가지고 있고, 중앙 집중화된 팀에 의해 지원되는 다양한 훈련들이 제공되고 있다. 우리는 이런 도구들을 사용하는 것을 강제하지는 않지만, 이런 도구를 사용하는 것이 개발과 운영 훨씬 더 나은 개발 경험이 될 수 있도록 지원하고 있다. 우리 접근 방식의 문제는 “모든 팀이 우리의 가장 중요한 문제를 해결하기 위해 모든 도구 안의 모든 기능을 사용하는 것“이 사실상 불가능에 가깝다는 것이다. 넷플릭스 스타일의 중앙 집중 방식이 많은 노력과 협력, 그리고 끊임없는 변화가 필요하다는 것을 인식할 필요가 있다.
글을 마치며
2012년에서부터 오늘날까지 우리는 다양한 것을 실험하고 배우고 변화시켜왔다. 더 나은 모델을 찾기 위해 노력해온 Edge Engineering 팀은 풀 사이클 개발자 모델을 정착시키기 위해서 노력하고 있다. 개발은 반복적이고 지속적으로 일어나는 일이고, 일부의 사용자에게만 사전 테스트를 해보는 것은 며칠이 걸리던 것이 이제는 몇 시간으로 줄어들었다. 개발자들은 쉽게 이슈를 확인하고, 여러 팀 간에 의사소통으로 시간을 낭비하는 것 대신에 빠르게 문제를 해결할 수 있다. 개발 이외의 팀들도 비슷한 이익을 누리고 있다. 하지만 우리는 다양한 방법을 적용하고 배우는 과정에서 여기까지 올 수 있었다는 사실을 알고 있다. 그리고 우리는 미래에 또 다른 개발 과정에서 발생하는 문제 혹은 수요가 또 다른 혁신을 가져다줄 것이라고 기대한다.
