by
Dec 01. 2023
Enterprise 회사에서의 DevOps란?
채워Dream. DevOps is elephant.
DevOps로 전환하자.
몇 년 전부터 DX(digital-transformation)와 함께 IT 업계에서 가장 핫한 주제가 아닐까 싶다.
DevOps에 대해 구글에 검색해 보면 정말 방대한 자료와 사례가 나온다.
이번에 회사에서 DevOps 전환과 개선을 위한 TF가 꾸려졌고, 감사하게도 TF 리더로 DevOps 전환을 리딩할 기회를 부여받았다.
(DevOps의 개념, 정의, Dora 지표등은 채워Dream을 통하여 전해드릴 수 있도록 하겠습니다.)
DevOps가 뭔데?
IT 관련자 중에 DevOps가 무엇인지 모르는 사람... 별로 없다. 그러나 제대로 DevOps가 무엇인지 아는 사람? 역시 별로 없다.
구글링이나 기타 검색을 통하여 검색하면 네카라쿠배에서 말하는 신속한 비즈니스 대응을 위한 사례인 DevOps 사례와 효용성이 나온다.
하지만 나는 B2C 위주의 회사 아닌 B2B, B2G 기반의 회사의 DevOps를 전환 및 개선하는 작업을 진행해야 하고, 전사 차원에서 DevOps 전환에 대해서 고려해야 한다.
이를 위하여 다른 회사들에서 DevOps를 어떻게 적용하고 있는지 사례를 찾아보았지만 각각의 팀에서 개별로 DevOps를 정의하고, 개선하는 작업을 진행할 뿐 전사차원의 DevOps를 적용한 조직의 사례는 아직 없었다.
물론 이렇게 반문할 수 있다. DevOps란 것이 개념이고, 전사 차원보다는 개별 팀의 상황에 맞춰서 적용하는 것이 맞는 것 아닌가에 대해서 말할 수 있겠지만
나는 다음과 같이 역으로 질문드리고 싶다.
대형 항공모함(회사)이 오른쪽으로 움직이고 있는데, 항공모함에서 내가(하나의 조직, 팀) 왼쪽으로 걷는다면 그것은 오른쪽으로 가고 있는 것인가요? 왼쪽으로 가고 있는 것일까요?
DevOps is elephant
DevOps란 엄청나게 거대한 개념이고, 지금도 진화하고 있는 개념이기에 엄청나게 큰 영역이다.
만약 나에게 이런 미션이 주어졌다고 가정해 보자.
[코끼리를 보고 다른 사람에게 알려주기 위하여 특징을 정의해 보세요.]
내가 코끼리의 코를 보고 코끼리를 정의한다면 코를 강조하게 될 것이다. (DevOps is using automation)
내가 코끼리의 귀를 보고 코끼리를 정의한다면 귀를 강조하게 될 것이다. (DevOps is small deployments)
내가 코끼리의 등을 보고 코끼리를 정의한다면 등을 강조하게 될 것이다. (DevOps is treating your infrastructure as code)
코끼리는 지상 최대의 육상 동물이다. 내가 어디를 보고 특징을 정의할지에 따라서 듣는 사람은 전혀 다른 생물체를 그리게 될지 알 수 없다.
DevOps가 그렇다. 광범위한 영역이기 때문에 DevOps의 부분 중 어느 부분을 집중할 것인지에 따라서 전혀 다른 DevOps가 될 수 있다.
우리 회사는 이미 DevOps 하고 있는데요
맞다. 하고 계신 거다. 스타트업이나 중소기업에선 더 적용하기 쉽다. 새로 시작하는 프로젝트에 적용하긴 쉽다.
오히려 시스템이 잘 갖춰져 있는 대기업, 중견기업일수록 적용하기가 어렵다.
이유는 DevOps는 코끼리인데 구글링 등의 검색을 통해서 검색되는 DevOps는 B2C를 위주로 하는 회사들에 적용된 사례만 나온다.
B2C 위주의 회사들에서 DevOps를 통하여 얻고자 하는 이득은 비즈니스 민첩성이다. 이것이 B2B, B2G를 하는 기업에겐 적용하기 어렵다.
B2B의 경우 한 달에 한 번도 배포가 이뤄나지 않는 상황도 존재하는데 여기에 무슨 비즈니스 민첩성에 대해서 말할 수가 있겠는가
물론 모든 대기업, 중견기업에서 안 하고 있는 건 아니다. 하지만 팀별로 DevOps가 다르게 되는 경우가 많다.
그렇기에 전사 차원의 혹은 엔터프라이즈급의 회사에서 DevOps 전환 및 개선을 수행하려면 기준이나 지표가 명확해야 한다.
DevOps 기준, 지표
Google은 과연 훌륭한 회사다. 구글에선 Dora(DebOps Research and Assessment)라는 지표를 이용하여 DevOps를 측정하고 개선할 수 있는 지표를 제공하는 성과지표를 만들었다.
1. Deployment Frequency: 배포 빈도
2. Lead Time for Changes: 변경 리드 타임
3. Mean Time to Recover: 평균 복구 시간
4. Change Failure Rate: 변경 실패율
이상의 4가지 지표로 DevOps를 측정하고 개선할 수 있도록 돕는다.
모든 팀의 모든 서비스에 적용될 순 없겠지만 기준점을 세우기엔 부족함이 없고, 공신력도 있다. Google이니까
기준점이 꼭 필요할까?
당연하다. 정말 필요하다. 하나의 팀에서 적용을 한다고 해도 무슨 목적에 의하여 DevOps를 도입하고 개선하기 위해서 진행을 했을 텐데 전사 차원이라면 당연한 이야기이다.
이때 Dora가 훌륭한 기준, 지표가 되었다. 특히 나는 다음과 같은 질문을 받았을 때 도움이 많이 되었다.
우리 서비스는 배포 거의 안 하는데요?
우리 이미 DevOps 하고 있는데요? (지표, 모니터링을 하는지에 대해선 답변은 없다)
DevOps 하면 뭐가 좋아지는데요?
