안녕하세요, 데이터플랫폼/인프라셀의 데브옵스 엔지니어로 일하고 있는 원대영입니다.
이 글은 제가 DevOps 엔지니어로 지내면서 읽어본 많은 글 중 가장 마음에 두고 오래오래 읽어보았던 글이었습니다. 2018년 6월의 글로 벌써 4년 전의 글인데, DevOps 세계에선 4년이란 시간이 짧지 않은데도 이 당시에 이런 이야기를 할 수 있었다는 건 참 대단하다고 생각하고, 동시에 지금 읽어봐도 여전히 통찰력있는 글이라고 생각합니다. 언젠가 책 ‘어린 왕자' 를 어릴 때 읽는 것과 성인이 되어 읽을 때 다르게 읽힌다는 말을 들은 적이 있는데, 제게 기술 관련 글에선 이 글이 그랬습니다. 시간을 두고 한 번씩 읽어볼 때마다 다르게 읽히며 마음 저리게 다가온 글이었고, DevOps 엔지니어의 조직구조나 역할, 방향성을 치열하게 고민해봤다면 뼈아픈 글일 거라고도 생각합니다.
- 원저자의 허락을 구했으며, 이 글을 번역할 수 있게 허락해준 Matt Klein에게 감사 인사를 남깁니다. 저자에 대한 소개를 안 할 수가 없는데, Matt는 무려 DevOps 엔지니어라면 많이 알 Envoy 의 창시자입니다. 그의 개인 홈페이지에는 읽어보면 좋을 다양한 글도 많으니 한 번 방문해보는 것 또한 추천합니다. Thank you, Matt!
- 저는 전문 번역가도 아니고 영어가 그리 능숙하지도 않기 때문에 많은 의역을 거쳤습니다. 한국어 번역이 애매하거나 더 어렵게 느낄 만한 표현들은 영어를 그대로 쓰거나 영어 발음대로의 한국어로 썼으니 양해 부탁드리며, 오역에 대한 의견은 tech_blog@devsisters.com로 주시면 언제든 감사하게 받겠습니다.
원문: https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a
최근 트위터에 썼듯, 저는 요즘 꽤 많은 시간을 들여 “DevOps”의 인적 확장(human scalability)에 대해 생각하고 있습니다. (“DevOps”에다가 따옴표를 붙인 건, 이에 대해 추후 서술할 다양한 정의가 있기 때문입니다.) 그렇게 내려본 결론은, DevOps는 작은 엔지니어링 조직들에서 굉장히 잘 돌아갈 수도 있지만, 신중한 생각과 관리 없이는 큰 인적/조직적 확장(scaling) 문제를 일으킨다는 것입니다.
DevOps란 무엇인가 (What is DevOps)
DevOps라는 용어에 대해선 많은 사람들이 다양한 의미로 말합니다. 제가 이 글을 본격적으로 시작하기 전에, 제가 어떤 의미로 DevOps라는 용어를 쓰는지 정리하는 게 중요해 보입니다.
Wikipedia에서 정의하는 DevOps는 다음과 같습니다:
DevOps(“Development”와 “Operations”의 합성어) 는 소프트웨어 개발(Dev)과 운영(Ops)을 융합한 소프트웨어 개발 문화와 관행(practice)을 말한다. DevOps movement의 주요 특징은 통합, 테스팅, 릴리징부터 배포, 인프라 관리까지 소프트웨어를 만드는 모든 과정에서의 자동화 및 모니터링을 강력하게 추구하고 제안하 는 것이다. DevOps는 짧은 개발 사이클, 잦은 배포 주기, 더 신뢰할 수 있는 릴리즈를 추구하여 비즈니스 목표와 방향성을 더 밀접하게 맞춘다.
저는 보다 더 좁고, 살짝 다른 형태로 DevOps를 정의하는데요,
DevOps는 개발자가 프로덕션 환경에서 24시간 365일 서비스가 운영되도록 책임지게 하는 방법(practice)이다. 이것은 공용 인프라 기반기술을 사용한 개발, 테스팅, 상시 장애대응, 신뢰성 엔지니어링(reliability engineering), 장애 복구, SLO 정의, 모니터링 셋업 및 알람 설정, 디버깅 및 성능 분석, 장애 근본 원인 분석(root cause analysis), 프로비저닝 및 배포 등을 포함한다.
Wikipedia의 정의와 제 정의와의 구분(‘개발 철학’ 대 ‘운영 방식’)은 저의 업계 경험을 바탕으로 만든 중요한 내용입니다. DevOps “movement” 일부는 느리게 움직이는 “오래된" 회사들에게 고도로 자동화된 최신 인프라와 개발 방법의 장점들을 설명하는 것입니다. 예를 들면, 서로 느슨하게 연결된(loosely-coupled) 서비스와 API 및 팀들, 지속적 통합(continuous integration), master에서 일어나는 작고 잦은 배포, 애자일 커뮤니케이션 및 플래닝, 클라우드 기반의 유연한 인프라 등입니다.
제 최근 10년의 커리어를 보면, AWS EC2, 상장 이전의 Twitter, Lyft 같은 급성장하는 인터넷 회사(hyper-growth Internet companies)에서 일을 해왔습니다. 더불어 Envoy를 만들고 알리기 위한 지난 2년간, 수많은 급성장 인터넷 회사들의 기술 아키텍처와 조직 구조를 마주하고 배웠습니다. 그 기업들에게 자동화, 애자일 개발/플래닝, 기타 DevOps “best practice”를 받아들인다는 건 당연한 일인데, 그건 이들이 생산성 향상에 대해 잘 이해하고 있기 때문입니다. 그 대신, 이러한 엔지니어링 조직이 갖는 당면 과제는 ‘비즈니스 성장, 개인의 성장 및 (비즈니스/채용에 대한) 경쟁 등에 대한 극심한 압박과 시스템 신뢰성(reliability) 간의 균형을 어떻게 맞추는가’ 입니다. 이 글의 이후 부분은 저의 개인적 경험에 근거한 것으로, 맞지 않는 경우가 있을 수 있고, 특히 분기마다 한 번씩 monolithic 소프트웨어를 배포하는 천천히 움직이는 회사들이나 더 빠르고 애자일한 개발 방법을 도입하고자 하는 회사같은 경우엔 맞지 않을 수 있습니다.
인터넷 어플리케이션 운영의 역사 (A brief history of operating Internet applications)
제가 현대 인터넷 시대(modern Internet era)라고 일컫는 최근 30여년 동안, 인터넷 어플리케이션 개발 및 운영은 (제 생각에) 세 가지 뚜렷한 단계를 거쳤습니다.
- 첫 번째 단계에선, 인터넷 어플리케이션은 만들어지면 “꼼꼼하게 포장(shrink-wrapped)” 된 프로그램이 배송되는 것처럼 배포됐습니다. 어플리케이션을 개발하고 운영하기까지의 아주 긴 엔지니어링 주기에 걸쳐 세 가지 서로 다른 직무(개발, QA, 운영)가 협업했습니다. 이 기간 동안 각 어플리케이션은 전용 데이터 센터나 공용 데이터 센터(colocation facility)에 배포되므로, 해당 장소의 네트워크/하드웨어/시스템 관리에 익숙한 운영 인력이 추가로 필요했습니다.
- 두 번째 단계에선, 90년대 후반 ~ 2000년대 초반의 Amazon, Google을 필두로 빠르게 급성장하는 회사의 인터넷 어플리케이션들이 loosely-coupled 서비스, 빠른 개발 및 배포, 자동화 등 현대 DevOps movement와 비슷한 형태의 시도를 시작했습니다. 이런 기업들은 여전히 큰 자체 데이터 센터를 운영하고 있는데, 이런 규모 때문에 모든 서비스에 필요한 공통 문제( 네트워킹, 모니터링, 배포, 프로비저닝, 데이터 스토리지, 캐싱, 물리 인프라 등)를 해결하는 중앙 집중식 인프라 팀들을 만들기도 했습니다. 그러나 Amazon과 Google은 그러한 역할들을 하나의 개발 직무로 완전히 통합하진 않았는데 (이를 테면 Amazon의 Systems Engineer, Google의 Site Reliability Engineer처럼), 각 직무가 요구하는 능력과 관심사가 다르다고 인식했기 때문입니다.
- 세 번째 단계는 클라우드 네이티브 단계라고 할 수 있습니다. 인터넷 어플리케이션은 이제 “Big 3” 퍼블릭 클라우드가 제공하는 유연한 아키텍처에 기반하여 만들어집니다. 시장에서의 높은 실패 가능성을 감안하다보니 제품을 가능한 빠르게 시장에 내놓는 것이 기업의 최우선 목표가 되어왔는데, 클라우드 네이티브 시대에선 “즉각" 제공되는 기반기술들을 통해 이를 이전보다 훨씬 더 빠른 속도로 반복하는 게 가능해졌습니다. 이 시대에 시작한 기업의 또 다른 특징은 소프트웨어 개발 역량을 보유하지 않은 엔지니어 역할을 두는 것을 지양한다는 것입니다. 사용할 수 있는 인프라 기반이 (그들 생각에) 상대적으로 탄탄하다보니, 스타트업의 인건비를 엔지니어링과 운영을 동시에(DevOps) 할 수 있는 소프트웨어 개발자를 위해 쓰는 게 더 낫습니다.
세 번째 단계의 기업들이 운영 전담 인력을 뽑지 않는 방향으로 변화한다는 건 아주 중요합니다. 분명 이러한 회사가 공용 데이터 센터의 기기를 다룰 풀타임 시스템 관리자를 필요로 하진 않지만, 이전에 그런 업무를 수행했던 사람은 보통 시스템 디버깅, 성능 프로파일링, 운영에 대한 직관(Intuition) 등 다른 20%의 스킬 들을 제공했습니다. 신규 회사들은 이제 중요하고 쉽게 대체되지 않는 스킬셋을 보유한 인력 없이도 만들어집니다. (역자 주: 여기서 신규 회사가 갖지 않는 스킬셋이란, 데이터 센터의 네트워크 설치, 사전 부팅 실행 환경(PXE) 구성, 장소의 항온항습이나 바닥 관리 등 서버실을 관리하던 운영 전담 엔지니어가 해왔던 것들을 의미한다고 볼 수 있겠습니다.)
왜 DevOps가 현대 인터넷 스타트업에서 잘 돌아갈까? (Why does DevOps work well for modern Internet startups?)
위에서 정의한 DevOps는 현대 인터넷 스타트업에서 정말 잘 동작할 수 있는데, 그 이유는 다음과 같습니다.
- 제 경험 상, 성공한 스타트업의 초기 엔지니어는 엔지니어 중에서도 특별한 부류입니다. 그들은 위험을 감내할 수 있고(risk tolerant), 아주 빠르게 배우며, 기술부채의 증가가 있더라도 아주 빠르게 무언가를 만들어내는 것에 익숙하고, 여러 시스템과 언어로 작업할 수 있으며, 보통 시스템 관리나 운영에 대한 경험이 있고, 계속 배우길 원하는 사람입니다. 다시 말해, 보통의 스타트업 엔지니어들은 DevOps 엔지니어가 되기 아주 적합한 사람들입니다. 물론, 그들이 그렇게 불리길 원하는지와는 별개입니다. (전 아닙니다 😉)
- 위에서 서술했듯, 현대 퍼블릭 클라우드들은 기반이 되는 인프라들을 아주 훌륭하게 제공합니다. 과거에 진행하던 가장 기본적인 운영 작업은 자동화되어, MVP를 만들어서 시장에 적합한지 확인할 수 있을 만큼의 좋은 기반이 만들어졌습니다.
- 저는 개발자들이 자신이 작성한 코드에 대해 책임을 지고 장애대응을 할 때 그 시스템의 퀄리티가 향상된다고 굳게 믿는 사람입니다. 누구도 장애로 호출 받는 걸 좋아하진 않지만, 이런 피드백 루프는 더 나은 제품을 만들어냅니다. 또한 1번에서도 설명했듯 보통 초기 스타트업에서 일하는 것에 매력을 느끼는 엔지니어는 배우는 것과 운영 업무를 하는 걸 꺼리지 않는 사람들입니다. 특히 제품 신뢰성이 낮아도 큰 영향을 받지 않는 초기 스타트업의 경우에는 이런 경향이 더욱 두드러지게 나타납니다. 초기 스타트업의 경우에는 제품이 적절한 시장을 찾아 급성장할 수 있는 국면에 진입할 정도만 제품의 신뢰성이 있어도 충분하기 때문입니다.
현대 인터넷 스타트업이 급성장하면 무슨 일이 벌어지는가? (What happens when a modern Internet startup undergoes hyper-growth?)
대부분의 스타트업은 실패합니다. 그게 현실입니다. 초기 스타트업이 Google을 상상하며 인프라를 만들어나간다면, 그건 시간 낭비일 뿐입니다. 제가 사람들에게 늘 말하는 건, 인적 확장 문제(의사 소통, 계획 산정, 강한 의존성 등)로 인해 보다 의존성이 적은 아키텍처로 전환하기 전까진, 다른 걱정은 하지 말고 그냥 현재의 monolithic 아키텍처를 유지하라는 것입니다.
그러면 현대의 (위에서 말한 세 번째 단계의) 스타트업이 성공을 거두며 급성장 시기를 맞이하면, 어떻게 될까요? 몇 가지 흥미로운 일들이 동시에 일어나기 시작합니다.
- 인력 증가 속도가 빠르게 늘어나며, 커뮤니케이션과 엔지니어링 효율에 심각한 부담이 오기 시작합니다. 이 주제에 대해서는 맨먼스 미신(The Mythical Man-Month) 을 꼭 읽어보길 권합니다. (거의 50여년 전 책인데도 여전히 아주 좋은 책입니다.)
- 위 내용으로 인해 거의 대부분 monolithic 아키텍처에서 microservice 아키텍처로 전환하며, 개발 팀들을 분리하고 커뮤니케이션 및 엔지니어링 효율을 높이려고 합니다.
- Monolithic 아키텍처에서 microservice 아키텍처로의 전환은 시스템 인프라 복잡성을 몇 배나 증가시킵니다. 네트워킹, 시스템 가시성, 배포, 라이브러리 관리, 보안 등 이전에는 그리 어렵지 않았던 수백가지 문제가 불거지고, 해결해야 할 주요 문제가 됩니다.
- 동시에, 급성장으로 인해 트래픽이 증가하고 그로 인한 기술적인 확장 문제를 겪게 되며, 완전한 실패(complete failure)와 작은 사용자 경험 문제들이 생기기 시작, 점점 큰 사용자 영향이 나타납니다.
중앙 인프라 팀 (Central infrastructure teams)
이런 초기 스타트업 단계에서, 거의 대부분 현대 인터넷 급성장 회사(modern Internet hyper-growth companies)들은 엔지니어링 조직들을 비슷하게 만들기 시작합니다. 공통적으로 나타나는 구조는 중앙 인프라 팀을 만들어, DevOps랑 비슷한 일을 하고 있는 다양한 제품 팀을 지원하는 구조입니다. 각 팀은 DevOps라고 불리지 않을 수도 있습니다.
중앙 인프라 팀이 보편적으로 생기는 이유는, 위에서 이야기했듯 급성장이 사람과 기술 양 측면에서 여러 변화를 야기하는데, 모든 제품 엔지니어링 팀이 각각 개별적으로 네트워킹, observability, 배포, 프로비저닝, 캐싱, 데이터 저장 등의 문제를 풀고자 최신의 클라우드 네이티브 기술들을 사용하긴 너무 어렵기 때문입니다. 전체 엔지니어링 조직이 거의 비즈니스 로직에만 집중하여, 아주 신뢰할 수 있는, 대규모의, 실시간 인터넷 어플리케이션을 만들도록 탄탄하게 지원하는 그런 “서버리스” 기술은 아직 수십년은 멀었습니다.
그리하여, 클 라우드 네이티브 인프라 기반기술들이 제공해주는 것 너머의 이런 대규모 엔지니어링 조직들이 갖고 있는 문제들을 해결하기 위해 중앙 인프라 팀이 탄생했습니다. 분명 Google의 인프라 팀은 Lyft같은 회사보다는 몇 배는 더 큽니다. Google은 데이터 센터 수준에서의 근본적인 문제들을 해결하는 반면, Lyft는 공개적으로 사용할 수 있는 많은 기반기술들에 의존하고 있기 때문입니다. 그러나, 두 회사 모두 중앙 인프라 조직을 만드는 근본적인 이유는 동일합니다. 바로 어플리케이션/제품 개발자가 비즈니스 로직에 집중할 수 있도록 가능한 많은 인프라들을 추상화하기 위함입니다.
대체 가능성에 대한 착오 (The fallacy of fungibility)
마지막으로 “대체 가능성(Fungibility)", 조직의 엔지니어 숫자가 어느 수준 이상으로 커지며 단일(pure) DevOps 모델의 실패로 이어지게 되는 핵심에 대해 이야기해보려 합니다. (역자 주: 단일 DevOps 모델이라는 번역이 적절한가 고민했는데, 뒤에서 제안하는 개발팀을 포함하는 복합적인 DevOps 모델과 대비되는 단어로 선택했습니다) 대체 가능성은 모든 엔지니어가 똑같이 태어나 모든 것들을 다 할 수 있다는 개념입니다. (적어도 Amazon이나 다른 회사들처럼) 채용 대상을 아주 분명하게 적어뒀든, 아니면 “부트캠프" 같이 엔지니어를 어떤 팀이나 역할에 염두하지 않고 뽑아 이후에 명확하게 검증해보든, 대체 가능성은 지난 10년-15년간 많은 회사들에서 현대 엔지니어링 철학의 가장 인기 있는 요소입니다. 왜 그럴까요?
- 위에서 말했듯, 현대 클라우드 네이티브 기술 및 추상화는 기능이 아주 풍부한 어플리케이션들을 더 정교한 인프라 추상화로 구축할 수 있게끔 합니다. 그래서 자연스럽게, 대부분의 회사들에서는 데이터 센터 설계나 운영 같은 종류의 전문 기술은 더 이상 필요하지 않게 되었습니다.
- 지난 15년간, 업계는 소프트웨어 엔지니어링이 모든 분야의 근본이라는 생각에 집중해왔습니다. 예를 들어, Microsoft는 전통적인 QA 엔지니어들을 소프트웨어 테스트 엔지니어로 대체했습니다. 수동으로 진행하는 QA는 더 이상 효율적이지 않고 모든 테스트는 자동화되어야 한다고 생각했기 때문입니다. 마찬가지로, 기존의 운영 역할은 SRE(Site reliability engineering) 등으로 대체되었습니다. 수동으로 운영하는 건 더 이상 효율적이지 않으며, 확장할 수 있는 방법은 소프트웨어 자동화가 유일하다고 생각했기 때문입니다. 물론, 저도 이런 시대적 흐름에 동의합니다. 보다 더 효율적으로 확장하는 방법이, 바로 자동화입니다.
그러나, 많은 신생 스타트업들의 경우, 이런 아이디어를 극한까지 적용하여 제너럴리스트 소프트웨어 엔지니어들“만” 채용하는 결과로 이어지기도 했습니다. 이들이 개발, QA, 운영 모두 담당해줄 수 있다는 기대와 함께 말이지요.
대체 가능성과 제네럴리스트 채용은 초기 스타트업에서는 대체로 잘 맞는 개념입니다. 그러나, 어느 규모 이상으로 가면 모든 엔지니어가 대체 가능하다는 생각은 다음과 같은 이유로 거의 터무니없는 말이 됩니다.
- 제네럴리스트 vs 스페셜리스트 (Generalist vs Specialists)
- 더 복잡한 어플리케이션과 아키텍처들은 프론트엔드, 인프라, 클라이언트, 운영, 테스팅, 데이터 사이언스 등 다양한 분야에서 더 전문화된 기술들을 필요로 합니다. 이건 제네럴리스트가 더 이상 유용하지 않거나 제너럴리스트가 전문가가 될 수 없다는 말이 아니라, 단지 더 큰 엔지니어링 조직이 성공하기 위해선 다양한 유형의 엔지니어들을 필요로 한다는 걸 말합니다.
- 어떤 엔지니어도 모든 일을 다 하는 것을 좋아하지 않는다 (All engineers do not like doing all things)
- 어떤 엔지니어들은 제네럴리스트가 되길 원합니다. 어떤 엔지니어는 스페셜리스트가 되길 원합니다. 누구는 코드를 작성하는 걸 좋아하고, 누구는 디버깅을 하는 걸 좋아합니다. 누구는 UI를 좋아하고, 누구는 시스템을 좋아합니다. 스페셜리스트를 지원하는 엔지니어링 조직이라면, 구성원의 행복이 때로는 특정 종류의 문제와는 연관되고 다른 종류의 문제와는 연관되지 않는다는 사실을 극복하려고 노력해야 합니다.
- 어떤 엔지니어도 모든 일을 잘 하지는 못한다 (All engineers are not good at doing all things)
- 제 커리어 동안 저는 정말 대단한 사람들을 만났습니다. 그 중 일부는 IDE의 빈 파일에서부터 시작해서 놀라운 시스템을 만들어내기도 합니다. 그렇지만 동시에, 그 똑같은 사람들은 신뢰할 수 있는 시스템을 만드는 방법이나 시스템을 디버깅하는 방법, 모니터링하는 방법은 잘 모릅니다. 반대로, 아주 뛰어난 운영 엔지니어로 디버깅에 대한 전문 지식을 가지며 신뢰 가능한 시스템을 어떻게 운영할 수 있는지 선천적인 직관으로 알아 조직 전체에 어마어마한 이점을 줄 수 있는 사람이, 단지 “충분한 코딩 기술"을 보여주지 못했다는 이유로 인터뷰에서 거절당하는 것을 보는 격분할 만한 인터뷰도 많이 겪었습니다.
아이러니하고 위선적이게도, Amazon이나 Facebook같은 조직들은 소프트웨어 엔지니어링 역할의 대체 가능성을 우선시하지만, 개발과 운영 간에 각각 서로 다른 커리어 패스를 제공하며 둘의 나눠진(그렇지만 일부는 겹치는) 스킬셋을 더 중요시합니다.
붕괴 (The breakdown)
단일 DevOps 모델은 어느정도의 조직 규모에서 어떻게 무너질까요? 무엇이 잘못되었을까요?
- Move to microservices. 엔지니어링 조직이 75명쯤 되면, 중앙 인프라 팀이 거의 무조건 존재하여, microservice를 만드는 각 제품팀을 지원하기 위한 공통 기반을 만듭니다.
- Pure DevOps. 동시에, 제품 팀이 DevOps를 하라는 이야기를 듣습니다.
- Reliability consultants. 이런 조직 규모에선 인프라 작업에 관심을 갖는 엔지니어는 이전에 운영 경험을 가진 엔지니어거나 해당 분야에서 뛰어난 직관을 가진 엔지니어일 가능성이 높습니다. 필연적으로 이러한 엔지니어는 사실상의 SRE/프로덕션 엔지니어가 되어, 조직의 나머지 부분을 지원하는 동시에 비즈니스 운영에 필요한 인프라를 지속적으로 구축해나갑니다.
- Lack of education. 이제 우리는 스스로가 직접 개입해서 인터넷 서비스를 개발하고 운영할 수 있는 사람을 고용하길 기대합니다. 그러나, 새로운 채용과 저런 일을 수행하기 위한 지속적인 교육을 같이 하는 걸 우린 보통 너무나도 못합니다. 우리가 그런 기술들을 가르치지 않는데 운영에 대한 직관을 엔지니어들이 가지길 기대할 수 있을까요?
- Support breakdown. 엔지니어링 조직이 점점 많은 사람을 고용하며, 중앙 인프라 팀이 더 이상 비즈니스 성공에 중요한 인프라를 구축 및 운영하기 버거워지는 지점이 옵니다. 그러나 각 제품 팀의 운영 업무를 지원해야하는 부담은 여전히 유지됩니다. 중앙 인프라 조직은 기존 워크로드에 더해 조직 전체의 SRE 컨설턴트로서의 이중 역할을 수행하기 시작합니다. 교육 및 문서화 작업이 중요하다는 것은 누구나 알고 있지만, 이 두 가지 작업을 위해 그런 시간을 내는 걸 우선시하는 일은 잘 일어나지 않습니다.
- Burnout. 더 문제인 건, 앞서 설명한 상황들이 인적 희생을 유발하며 조직 전체의 사기를 떨어뜨리는 일을 만든다는 것입니다. 제품 엔지니어는 자신들이 하기 싫거나 배우지 않은 일들을 하도록 요구받는다고 느낍니다. 인프라 엔지니어는 회사 전반의 기존 시스템을 높은 신뢰성을 가지고 유지하는 동시에, 교육과 문서화가 필요하다는 것은 인지하지만 이걸 진행하는 걸 우선시하긴 어렵다는 걸 알며 지원 업무의 무게로 점점 번아웃되기 시작합니다.
엔지니어링 조직의 규모가 일정 수준이 되면 중앙 인프라팀이 단일 DevOps 모델을 진행하며 조직에서 인적 확장 문제를 겪기 시작하고, 이런 문제들을 기점으로 상황이 급격히 나빠집니다. 이 크기는 퍼블릭 클라우드 기반 기술들이 얼마나 성숙한가에 따라 달라지며, 저는 이 글을 쓰는 현재 시점(역자 주: 2018년입니다)에선 전체 엔지니어가 100~200명(low hundreds)인 수준이라고 생각합니다.
“오래된 방식”과 DevOps 방식의 중간지점? (Is there a middle ground between the “old way” and the DevOps way?)
약 10년 이상 된 회사의 경우, 사이트 신뢰성(site reliability)이나 제품 엔지니어링 모델은 흔해집니다. 구현 형태는 회사마다 다르지만, 공통적으로 추구하는 바는 제품 관리자에게 매이지 않고 온전히 신뢰성 엔지니어링에 집중할 수 있는 엔지니어를 고용하자는 것입니다. 구현 형태의 디테일도 연관성이 꽤 있는데, 이를테면 이런 부분들입니다.
- SRE만 장애 대기 를 함께 하는가, 아니면 소프트웨어 엔지니어도 장애 대기를 함께 하는가?
- SRE는 실제 엔지니어링 및 자동화를 하고 있는가, 아니면 배포/반복되는 장애 해소 등 수동으로 진행되고 반복적인 작업들을 수행하는가?
- SRE는 중앙 컨설팅 조직의 일부인가, 아니면 제품 팀에 포함되어 있는가?
보통 위의 질문들에 대한 대답에 따라, 프로그램의 성공과 그 성공이 전체 엔지니어링 조직에 미치는 영향은 달라집니다. 하지만, 저는 특정 규모 이상에선 SRE 모델만이 단일 DevOps 모델이 망가지는 시점을 넘어 엔지니어링 조직의 규모를 훨씬 크게 확장할 수 있는 유일한 방법이라고 믿습니다. 보다 솔직하게는, 여기에서 설명한 인적 확장의 한계 시점 이전에 SRE 모델을 성공적으로 도입하는 것이 현대 급성장 인터넷 회사들의 엔지니어링 조직 리더십이 가져야할 아주 중요한 책임이라고 생각합니다.
올바른 SRE 모델이란 무엇인가? (What is the right SRE model?)
현재 업계에서 구현된 수많은 사례들을 볼 때, 이 질문에 대한 정답은 없으며, 모든 모델은 각각의 빈틈과 그로 인한 문제들이 있습니다. 제가 지난 10년간 관찰한 결과를 바탕으로, 제가 생각하는 SRE 모델의 핵심(sweet spot)을 간략히 설명해보면 다음과 같습니다.
- 운영 및 신뢰성 엔지니어링은 개별적이고 매우 가치있는 스킬셋이라는 걸 인지합니다. 모든 것을 자동화하려는 시도와 소프트웨어 엔지니어가 대체 가능하다는 생각은, 소프트웨어 엔지니어와 동등한 (어쩌면 더 나은) 가치가 있는 엔지니어링 인력 일부를 소외되게 만듭니다. 소프트웨어 엔지니어가 스트레스가 심한 장애 상황에서 디버깅하고 불을 끄는 일에 편안함을 느껴야할 필 요는 없는 것처럼, 똑같이 운영 엔지니어는 빈 소스파일에 편안함을 느끼지 않아도 됩니다. 운영 엔지니어와 소프트웨어 엔지니어는 서로 대체할 수 있는 톱니바퀴같은 존재가 아니라, 파트너입니다.
- SRE는 장애 대기하고, 대시보드를 만들고, 배포를 하는 원숭이가 아닙니다. 이들은 제품 업무가 아닌 신뢰성 업무에 집중하는 소프트웨어 엔지니어들입니다. 이상적인 구조는 모든 엔지니어가 장애 대응, 배포, 모니터링 등의 기본적인 운영 업무를 수행하는 것입니다. 이건 아주 중요한 이야기로, 신뢰성 엔지니어와 소프트웨어 엔지니어 간의 직업 계층화를 방지하고, 소프트웨어 엔지니어가 제품 품질에 대해 보다 직접적으로 책임을 지게 만들기 때문입니다.
- SRE들은 구조적으로는 제품 팀에 속하나, 제품 팀의 엔지니어링 매니저에게 보고하진 않아야 합니다. 이를 통해 SRE는 자신이 속한 팀에서 스크럼을 하고, 상호 신뢰를 얻으며, 상호 적절한 견제와 균형을 유지하며 신뢰성과 기능 사이를 저울질할 수 있는 진짜 대화를 이뤄나갈 수 있습니다.
- 각 제품 팀에 포함된 SRE의 목표는 각 제품의 신뢰성을 올리는 것입니다. 이는 신뢰성을 중시하는 기능 및 자동화, 운영 모범 사례에 대해 다른 팀을 멘토링하고 교육하는 것, 제품 팀과 인프라 팀 간의 소통(문서에 대한 피드백, Pain points, 필요 기능 등) 등을 통해 달성할 수 있습니다.
위에서 설명한 성장 시기의 초기에 SRE 모델을 성공적으로 구현하면, 신규 채용에 대한 투자와 지속적인 교육 및 문서화를 바탕으로 조직 전체의 엔지니어링 기준을 높이는 동시에, 앞서 설명한 많은 인적 확장 문제들을 완화할 수 있습니다.
결론 (Conclusion)
이 글에 서술한 내용들을 바로 적용할 수 있는 급성장 회사들은 거의 없습니다. 상당수 기업들은 현대 클라우드 네이티브 기반기술에 기초한 단일 DevOps 모델로도 충분한 숫자의 엔지니어 수, 필요한 시스템 안정성, 비즈니스에서 요구하는 제품의 반복 속도를 만들 수도 있습니다.
이 글을 적용할 수 있는, 비교적 적은 숫자의 회사를 위해 이 글의 주요 내용을 요약해보면 다음과 같습니다.
- 경쟁하고자 하는 신기술 회사에는 DevOps 스타일의 애자일한 개발 및 자동화가 필요합니다.
- 소규모 중앙 인프라 팀이 퍼블릭 클라우드 네이티브 기반기술을 사용하면, 교육 부족 및 역할 특수성 부족으로 인한 운영 문제가 발생하기 전까지 엔지니어링 조직을 수백명 수준으로 확장할 수 있습니다.
- 운영 인력 확장 문제를 위해서는 신규 채용 및 지속적 교육, 문서화, 제품 팀과 인프라 팀 사이의 가교 역할을 할 수 있을만한 제품 팀 내의 SRE팀 만들기 등의 실질적인 투자가 필요합니다.
현대의 급성장 인터넷 회사들은 (제 생각엔) 말도 안되게 많은 숫자의 번아웃을 겪고 있는데, 이는 주로 가혹할 정도의 제품 요구사항과 운영 인프라에 대한 부족한 투자 때문입니다. 이 문제가 더 커져서 조직 안정성에 큰 걸림돌이 되기 전에, 저는 엔지니어링 리더십들이 이 문제를 선제적으로 개선할 수 있을 것이라고 믿습니다.
신생 기업들은 클라우드 네이티브 자동화의 발전으로 인해 기존의 전통적인 운영 엔지니어가 필요 없어졌다고 착각할 수도 있는데, 이는 사실과 아주 다릅니다. 분명 미래에 가장 최신 기술들을 쓰고 있다 하더라도, 운영 및 신뢰성을 전문으로 하는 엔지니어는 다른 방법으로는 얻을 수 없는 아주 중요한 스킬셋들을 갖고 있다고 인식되고 평가받아야 합니다. 그리고 그들의 이런 중요한 역할은 성장 시기 초기의 엔지니어링 조직에 제대로 구성되어야 할 것입니다.
다시 본 글의 옮긴이, 원대영입니다. 데브옵스라는 업무 형태나 일하는 방식은 역사가 수 년밖에 되지 않은 분야라 '어떻게 더 잘 일할 수 있는지'에 대해선 전 세계 수많은 조직이 공통적으로 고민하는 문제라고 생각합니다. 지금 번역한 이 글에서 다루고 있는 문제 또한 저희 데브시스터즈 내부에서도 수 년간 진화를 거듭하며 배운 것과 굉장히 유사하다고 느꼈습니다. 이런 사례가 계속 공유되고 다함께 더 좋은 방법을 찾다보면 데브옵스라는 직무의 일하는 방식이 점차 잡혀갈 것이라 생각합니다.
더불어 저를 비롯한 데브시스터즈의 여러 데브옵스 엔지니어들이 이 글을 기반으로 많은 생각과 의견을 나눠봤습니다. 그 부분에 대해서는 별도의 글로 찾아오도록 하겠습니다. 다음 글을 기대해주세요!