DevOps vs SRE , 차이점과 공통점에 대해

DevOps와 SRE, 어떤 차이가 있나요?

 

라는 질문은 항상 뜨겁습니다. DevOps 모임에서 이 질문이 나오면, 아마 모두가 각자 다른 대답을 할 것 같네요.

이 질문의 정답은 정답이 없다는 것입니다. 개인마다 이해와 생각이 다르니 비즈니스, 회사, 팀과 합의를 통해 개념을 정의하고 어떻게 받아들일지 정해야 하죠.

 

 다만 이 질문에 대해서 각자 생각하는 정답지 하나 정도는 만들어 두는 게 좋죠. 세상을 바꾼 빅테크 SRE 챌린지라는 책에서 커뮤니티의 사람들이 생각하는 DevOps와 SRE에 대한 의견들을 받아 정리해 둔 부분 중 의미 있다고 생각된 몇 개의 의견들을 가져왔습니다. 여러 의견들 중 여러분에게 의미 있고 공감되는 글귀들을 중심으로 정리해보시길 바랍니다.

세상을 바꾼 빅테크 SRE 챌린지 | - 교보문고

 

책 광고는 아닙니다. 개인적으로 번역 부분이 많이 아쉬워서, 책에서 가져온 번역된 부분들을 더 매끄럽게 다듬었습니다.

---

DevOps와 SRE는 모두 실패를 용납하는 문화에서 시작한 협업과 자동화에 중점을 둔 엔지니어링 방법론이다. DevOps는 애자일 방식으로 사용자에게 기능을 더 자주, 빠르게 전달하는 데 중점을 두는 데에 비해, SRE는 DevOps 팀의 전문성을 지원해 가-능한 한 안정적으로 프로덕트를 릴리스하는 데 집중한다.

-ING IT 부서 리드 -

 

직함에 DevOps 라는 용어를 넣는 것은 말도 안 되게 비현실적인 것이다. DevOps는 애자일과 마찬가지로 철학, 방법론, 프랙티스에 가깝다. 애자일 엔지니어 라는 직책이 터무니없어 보이듯이 언젠가는 DevOps 엔지니어라는 직책도 그 뒤를 따르게 될 것이다.

-카디널 헬스, Infra&DevOps 시니어 관리자

 

DevOps는 운영을 덜 책임지면서도 SDLC(소프트웨어 개발 수명주기) 파이프라인에 집중하고,

SRE는 SDLC 파이프라인을 덜 책임지고 신뢰성 있는 프로덕션 운영에 집중하는 것이다. 결국 둘의 차이점은 어떤 것을 강조하는지에 있다.

 

-전 구글 SRE, 스텍 오버플로우 SRE 매니저

 

운영을 소프트웨어 관점에서 바라보며 누락된 것을 찾아 최대한 가져오는 것이 SRE다. SRE팀은 시스템 관리를 next level로 발전시키고 최신 인프라, 플랫폼, 툴, 개념을 중심으로 계속 성장하는 팀이다.

DevOps는 소프트웨어 개발자에게 운영 마인드를 소개하고, 운영 팀에게 소프트웨어 사고방식과 이해를 제공한다. DevOps에서 가장 가치 있는 점 중 하나는 모든 팀이 문화적 변화와 함께 공유되는 오너십을 구축하는 것이다.

DevOps와 SRE는 공존할 수 있다. 다만 공존해야만 하는가는 상황에 따라 다르다. 비즈니스, 회사, 팀의 목표는 무엇인지 고민해야 한다.

-에지와이즈 네트워크, 인프라 설계자

 

DevOps라는 용어는 SRE보다 최소 6년 이상 오래 사용되면서 SRE와 관련된 책,블로그,컨퍼런스,전문가들이 영향력을 발휘할 시간이 DevOps 분야보다 훨씬 적었다. 즉, 현재까지는 DevOps와 SRE의 주제와 조언들이 대부분 중복되었다는 것이다. SRE와 DevOps를 이름만 다른 같은 용어로 여기는 건 잘못된 것이다. DevOps는 운영보다 SDLC의 개발, 릴리즈 부분에 더 집중하는 경향이 있고 SRE는 운영 개선을 서비스가 실존하기 위한 가치로 여긴다.

 SRE는 시스템의 프로덕션을 운영하고 확장할 때 생기는 새로운 병목을 완화하기 위해 개입한다. 우스갯소리로 SRE는 DevOps가 아니라는 의미로, SRE라는 명칭이 담긴 직책을 주는 게 좋다. 왜냐하면 실제 장애상황에서 있는 엔지니어들이 SRE의 개입만으로 슈퍼맨을 본 것 처럼 즉각적인 사기를 높일 수 있기에.

-액센츄어, 수석 이사

 

 SRE는 SLO를 기반으로 하는 DevOps이다. 둘 다 같은 목표를 추구하지만 다른 길을 택한다. 스타트업에서는 가능한 한 빨리 프로덕션에 배포하려는 동기가 신뢰성이나 가용성보다 분명히 능가하기에 DevOps를 활용하는 것이 일반적이다. 반면 SRE는 혁신과 신뢰성 간의 트레이드 오프 관계에서 갈등이 막 나타나기 시작하고 있으면서도 DevOps가 잘 구축되어 있는 기업에 더 적합하다.

-잴란도, 수석 SRE 엔지니어

 

SRE 모델은 문제를 해결하기 위해 더 전략적이고 엔지니어링 중심의 접근 방식을 취하지만 DevOps는 문화적 측면에서 더 집중해 충돌을 줄이고 엔지니어들이 문화적 장벽을 넘어 업무를 수행하게 한다는 생각을 가지고 있다.

한 가지 흥미로운 측면은, 현재 SRE와 DevOps 아이디어를 채택한 패턴으로 고통받는 사람들이 많다는 것이다. DevOps 측면에서 보면 DevOps 용어와 관련해 알려진 것 중 과장된 것이 너무 많고, 또 많은 회사가 자기 입맛에 맞게 DevOps를 왜곡하려 해서 (역주: 우스갯소리로 k-DevOps라고도 한다..) DevOps 문화가 진정으로 의미하는 것을 희석시키고 있다.

아이러니하게도 SRE 쪽에서도 보면 SRE 관련 정보들은 이제 구글이 발표한 정보가 지배적이어서 구글과 규모가 다르고 구글과 같이 운영하진 않는 회사(즉, 거의 모든 기업들)에서 SRE를 적용해도 구글이 주장하는 best practices를 기대할 수 없다는 것이다.

내 희망은 이런 주제에 대한 대화가 많아져서 사람들이 자신이 속한 조직이 어떤 태도를 보이든 조직에 필요한 방식을 택하고 혜택을 얻게 하는 것입니다.

-옴니TI, CEO

 

SRE가 된다는 것은 프로덕션 시스템을 관리하고, 신뢰할 수 있게 하며, 규모를 조정해 자동화하는 것입니다. 여기서 DevOps 직책이 개발과 프로덕션 간의 연결점이라 생각합니다. 이 연결에는 사용 가능한 스테이징 환경, CI/CD 파이프라인, 자동화 테스트 등 많은 측면에서 개발을 돕는 것을 포함합니다. 전반적으로 제가 생각하는 데브옵스 엔지니어는, 개발자가 코딩에 집중할 수 있도록 가능한 모든 것을 지원해야 한다고 생각합니다.

-키위.ki, SRE