중소기업에서 DevOps 도입이 실패하는 이유, 그리고 실제로 효과가 있는 실용적 경로

22명 규모 스타트업의 CTO가 한 분기 안에 Kubernetes, 완전한 CI 플랫폼, Terraform, 그리고 최신 관측 스택을 모두 도입합니다. 6개월 후 온콜 로테이션은 개선되기는커녕 더 나빠집니다. 배포는 여전히 금요일 오후에 실패하고, 파이프라인을 실제로 이해하는 두 명의 엔지니어는 조용히 특정 리포지토리를 피하기 시작합니다. 이것은 드문 이야기가 아닙니다. 소규모 엔지니어링 팀이 Netflix가 사용하는 툴링을 구매하는 방식으로 DevOps를 도입하려 할 때 나타나는 기본 결과입니다.

중소기업에 가장 큰 비용을 치르게 하는 통념

중소기업 엔지니어링에서 가장 비싼 통념은 DevOps가 쇼핑 목록이라는 것입니다. 팀은 Spotify나 Google의 사례 연구를 읽고, 툴 스택을 보고, 그 스택을 재현하면 결과도 재현될 것이라 가정합니다. 그렇지 않습니다. 그 회사들은 Kubernetes를 도입했기 때문에 안정적이 된 것이 아닙니다. 이미 이를 운영할 수 있는 운영 근육을 갖췄고, 규모가 실제로 그 오버헤드를 정당화했기 때문에 Kubernetes를 도입한 것입니다.

중소기업의 DevOps는 툴링 문제가 아닙니다. 툴링의 옷을 입은 워크플로 문제입니다.

자동화는 운영 성숙도와 같지 않습니다

대부분의 팀이 뭉뚱그리는 유용한 구분이 있습니다. 자동화와 운영 성숙도는 같지 않습니다. 배포 파이프라인은 자동화했지만 "왜 새벽 3시에 프로덕션이 망가졌는가"에 답할 수 없는 팀은 안전성을 더하지 않은 채 속도만 산 것입니다. 이제 나쁜 코드를 더 빨리 배포할 뿐입니다.

운영 성숙도는 장애를 지루하게 만드는 습관의 집합입니다. 한 명령으로 끝나는 롤백, 실제로 중요한 세 가지 지표를 보여주는 대시보드, 온콜 엔지니어가 새벽 3시에도 따를 수 있는 런북, 다음 주에 무언가를 실제로 바꾸는 사후 리뷰가 그것입니다. 자동화는 이미 향하고 있는 방향을 증폭시킵니다. 습관이 흔들린다면, 자동화는 추락 소리를 더 크게 만들 뿐입니다.

자주 보이는 네 가지 실수

실천을 다지기 전에 플랫폼부터 사는 것. 엔지니어 15명 팀에는 Kubernetes가 필요하지 않습니다. 아마도 서비스당 하나의 평범한 가상 머신, 헬스 체크, 그리고 자동 롤백이 필요할 것입니다. Kubernetes는 아직 존재하지도 않는 문제를 해결하는 동시에, 팀이 아직 디버깅할 준비가 되지 않은 새로운 문제를 도입합니다.

파이프라인을 1인 프로젝트로 만드는 것. 많은 중소기업에서 한 엔지니어가 조용히 DevOps 담당자가 됩니다. 그 사람만 이해할 수 있는 아름다운 파이프라인을 만듭니다. 그가 휴가를 가면 배포가 얼어붙습니다. 그가 떠나면 파이프라인은 나머지 팀이 손대기 두려워하는 부채가 됩니다. 공동 소유는 있으면 좋은 것이 아닙니다. 인프라가 자산이 될지, 인질 상황이 될지를 결정하는 차이입니다.

잘못된 것을 측정하는 것. 변경 실패율이 오르고 있다면 배포 빈도는 허영 지표에 불과합니다. 소규모 팀은 먼저 두 숫자를 관찰해야 합니다. 배포가 장애를 얼마나 자주 유발하는가, 그리고 장애가 발생했을 때 복구에 얼마나 걸리는가. 이 둘을 무시한 채 속도만 최적화하는 것이 바로 안정적인 제품을 흔들리는 제품으로 바꾸는 방법입니다.

지루한 기반을 건너뛰는 것. 버전 관리되는 인프라, 재현 가능한 로컬 개발 환경, 시크릿을 위한 단일 진실 원천은 화려하지 않습니다. 또한 20분 만에 끝나는 장애와 이틀이 걸리는 장애의 차이이기도 합니다.

현장 사례 하나

한 지역 이커머스 클라이언트가 엔지니어 12명, 주당 세 건의 프로덕션 장애, 그리고 모든 것을 Kubernetes로 마이그레이션하려는 계획을 가지고 저희를 찾아왔습니다. 저희는 그들에게 6주 동안 마이그레이션을 멈추기를 요청했습니다.

그 6주 동안 저희는 흥미로운 일을 아무것도 하지 않았습니다. 인프라를 Terraform으로 옮기고, 팀의 어떤 엔지니어라도 실행할 수 있는 단일 배포 스크립트를 작성하고, 시크릿을 관리형 볼트로 옮기고, 자동 롤백을 트리거할 수 있는 헬스 체크를 추가하고, 매출과 직결된 지표만 보여주는 세 개의 대시보드를 설정했습니다. 주문 성공률, 결제 지연 시간, 그리고 결제 게이트웨이 오류가 그것입니다.

장애는 주당 세 건에서 10일에 한 건으로 줄었습니다. 그 후 팀은 비핵심 서비스 두 개를 Kubernetes로 마이그레이션하여 위험이 낮은 트래픽에서 학습했고, 그 이후에야 결제 경로를 옮겼습니다. 마이그레이션이 성공한 것은 툴링이 원래 계획했던 것과 달랐기 때문이 아니라, 팀이 먼저 근육을 키웠기 때문입니다.

엔지니어 30명 미만 팀을 위한 실용적 로드맵

1단계: 배포 버튼을 고치십시오. 무엇보다 먼저, 어떤 엔지니어든 한 명령으로 메인 서비스를 배포하고 다른 명령으로 롤백할 수 있는지 확인하십시오. 오늘 이 작업이 하루 이상의 채팅 조율을 요구한다면, 바로 그곳에 가장 큰 안정성 개선이 숨어 있습니다.

2단계: 인프라를 코드로 옮기십시오. Terraform이든 Pulumi든, 팀이 유창하게 읽을 수 있는 것으로. 목표는 자동화 그 자체가 아닙니다. 최악의 순간에 무언가가 잘못됐을 때 어떤 환경이든 처음부터 재현할 수 있는 능력입니다.

3단계: 시크릿과 설정을 통합하십시오. 하나의 볼트, 하나의 규칙, 키를 회전할 수 있는 하나의 장소. dotenv 파일과 채팅 메시지에 흩어진 시크릿은 놀라울 만큼 많은 프로덕션 사고의 조용한 원인입니다.

4단계: 중소기업에 중요한 두 가지 DORA 지표를 측정하십시오. 변경 실패율과 평균 복구 시간. 한 분기 동안 정직하게 추적하십시오. 트렌드 기사가 아니라 숫자가 다음에 무엇을 고쳐야 할지 알려주게 하십시오.

5단계: 오케스트레이션 전에 컨테이너를 도입하십시오. Docker는 운영 비용의 극히 일부로 재현성의 대부분의 이점을 제공합니다. Kubernetes는 40명이나 50명의 엔지니어 규모에서, 혹은 트래픽이 진정으로 요구할 때 내려야 할 결정이지, 그 이전이 아닙니다.

6단계: 지루한 런북을 작성하십시오. 각 핵심 서비스에 대해 한 페이지짜리 문서를 만드십시오. 무엇을 하는지, 정상 여부를 어떻게 확인하는지, 어떻게 재시작하는지, 그리고 돌아오지 않을 때 누구에게 연락해야 하는지. 각 런북은 위험이 낮은 게임데이 동안 신규 엔지니어가 따라 해보게 하여 검증하십시오.

정직한 결론

DevOps는 설치하는 제품이 아닙니다. 30명 이하의 팀에게는, 자신 있게 배포하는 엔지니어링 그룹과 금요일 오후를 두려워하며 사는 그룹을 가르는 워크플로 결정의 집합입니다. 툴링은 쉬운 부분입니다. 습관이 진짜 일입니다.

DevOps 개편을 고려 중이고 플랫폼에 헌신하기 전에 두 번째 의견을 원하신다면, MercTechs의 저희 팀은 이 지역 전역의 중소기업이 과도한 엔지니어링 없이 장애를 줄이는 실용적 경로를 설계하도록 도왔습니다. 저희는 필요하지 않은 값비싼 스택을 판매하기보다는, 후회할 스택을 건너뛰도록 돕는 편을 선호합니다.