위 책은 DevOps가 개발의 간소화와 비즈니스 가치 창출에 얼마나 효과적인지를 설명하고 있으며, 그것을 실현하는 기술 요소와 방식에 대해 상세하게 다뤘습니다.
1장에서는 DevOps의 개요와 주변 지식과 역사를 배우며 기초를 익혔습니다. 2장에서는 DevOps를 실현하는 기술은 개인의 개발 환경에서도 가능하며 예를 들어, 개발 환경 구축 하나만으로도 개발 담당 및 운용 담당 팀 간의 커뮤니케이션 및 요구 분석 등 오버 헤드를 줄일 수 있음을 알게 되었습니다. 각 팀이 수행하게 되는 작업을 인수하고 개발 업무·운용 업무 모두를 개인이 담당한다고 해도, DevOps를 지원하는 기술은 수평적 전개가 가능하도록 만들어져 있어 전체적으로 보면 작업 시간이 대폭적으로 감소한다는 것을 알 수 있었습니다.
3장·4장에서는 팀 개발 프로세스나 운영 환경에서 DevOps를 실현함 으로써 적은 인원으로 고품질 서비스 제공을 가능하게 하는 기술과 방식을 배웠습니다. 5장에서는 응용편으로, DevOps를 지원하는 기술의 조합을 통해 실천 방식을 배웠습니다. 이것으로 DevOps를 실시하면 어떻게 바뀌는가, 어떤 장점이 있는가를 충분히 이해했다고 생각합니다. 하지만 앞서 언급했듯이 DevOps는 매우 폭이 넓고 추상적인 부분도 있기 때문에 배우려고 하지 않는 사람, 쌓아온 지식이 없는 사람에게 DevOps가 무엇인지 설명하는 것은 매우 어려운 일입니다.
이 장에서는 어떻게 조직이나 팀에 DevOps를 적용하는지, DevOps를 적용하면 조직이나 팀이 어떻게 변화하는지를 배워 보도록 하겠습니다.
- 새로운 조직에 DevOps를 적용한다
새로운 조직에서 서비스 개발·제품 개발을 시작할 때, DevOps에서 이용되는 기술을 적용하는 기회는 매우 많다고 할 수 있습니다. 개발 체계 및 개발 프로세스, 조직 등 DevOps를 제안하고 기존 방식과 비교하여 최적의 해결안을 이야기할 수 있는 기회가 많으며, 한정된 예산으로 최대한의 Output을 내기 위해 어떻게 하면 좋을까 생각할 때 하나의 대안으로써 DevOps가 아주 유용하기 때문입니다.
만약에 Top-Down 접근 방식을 취할 경우, 새로운 조직·개발에 있어서 DevOps를 적용하는 것은 더욱 효과적이기 때문에 반드시 실행할 것을 권고합니다. DevOps가 가지고 있는 조직 구성의 예를 알고, 자신의 조직 문화에 맞춰 조정하면 DevOps 조직 구성의 장점을 그대로 누릴 수 있습니다. 인원 수와 개발 규모에 맞춰 전략적으로 최적의 조직을 구성하면, 이후에 몇 배 이상 효율적으로 개발이 진행될 것입니다.
한편, 새로운 조직·새로운 프로젝트임에도 불구하고 Top-Down 방식의 지시 체계, 순서가 없다면 어떻게 하면 좋을까요? 그러한 경우에는 조직이나 프로젝트가 경직되지 않고 유연하기 때문에 주위에 DevOps 관련 교육을 시작하고 동료를 늘려 원하는 대로 팀을 만들어 갑니다. 방식은 바로 다음에 설명합니다. 새로운 조직은 기존 조직과 비교했을 때 기존의 규칙과 낡은 습관이 없기 때문에 새로운 조직·신개발 쪽이 훨씬 DevOps 도입이 용이합니다.
- 기존 조직에 DevOps를 적용한다
여러분이 소속되어 있는 조직의 크기는 다양합니다. DevOps에 대한 기술적인 요소가 상당히 효과적이라는 것을 알고 있지만, 이것을 기존 조직에 적용하고 침투시키는 일이 쉽지 않을 거라는 생각이 들 것입니다.
조직에는 여러 종류의 패턴이 존재합니다. 유연성이 있는 구성원과 서비스나 제품에도 특정한 제약이 없는 조직인 경우에는, 기존의 전체 구조나 조직을 재구성하여 DevOps를 도입하고 새로운 업무 형태를 비교적 쉽게 취할 수 있습니다.
그러나 이미 오랜 기간 동안 운영되고 있는 시스템에서 각 팀별로 프로세스가 상이하고 사람에게 종속적인 상태로 복잡하게 얽혀져서 운영되는 프로세스라면 어떨까요? 낡은 방식을 바꾸고 새로운 전략을 도입할 여지가 없을지도 모릅니다. 정해 놓은 절차를 중시한 나머지, 변화로 인한 문제를 우려하여 기존 프로세스 그대로 진행하고 싶다는 생각이 들 수도 있습니다.
이러한 상황에서는 DevOps의 진행을 간절하게 원한다고 하더라도 기존의 틀과 조직을 어떻게 하면 변화시킬 것인지 고민만 떠오를 것입니다. 또한 오히려 DevOps의 도입으로 인하여 도리어 업무가 힘들어진 경우도 있을 것입니다.
위와 같이 기존의 조직은 쉽게 변화시킬 수 없는 갖가지 상황이 존재합니다. 그렇다면, 실제로 DevOps를 추진하려면 어떻게 해야 할까요?
- 조직의 벽을 넘다
기존의 조직은 Top-Down 방식을 통한 대폭적인 변화가 이루어지는 경우가 매우 드뭅니다. 경영자가 바뀌고 DevOps 전도사(Evangelist)가 들어와서 체제가 변화하는 등의 특별한 경우를 제외하고는 같은 상사, 같은 팀, 같은 멤버로 비즈니스 속도의 개선이나 작업의 효율화만을 추구하는 경우가 대부분일 것입니다.
이와 같은 경우, 조직의 윗선에서 개발 스타일이나 조직이 가져야 하는 자세를 결정하여 현장으로 내려주는 Top-Down 방식의 접근보다는 현장 주도로 결정하는 Bottom-Up 방식에 의한 변혁이 요구됩니다.
Top-Down 방식의 접근법은 조직의 변화가 아닌 개선만을 요구하는 경우도 있을 수 있습니다. 경영진과 리더는 신이 아니기 때문에 항상 앞을 내다보는 올바른 결정을 내리고 있다고 할 수 없습니다.
상위 계층이 현장보다 먼저 DevOps를 배워서 이끌어 주는 것을 기대하는 것보다, 새로운 방식·새로운 기술이 현장으로부터 전해지는 것이 훨씬 빠르게 실무에 도입될 수 있습니다. 여러 프로젝트 중 하나의 프로젝트만을 변화시키고 싶을 때도 마찬가지입니다.
조직의 전체 정책에 따라 프로젝트가 운영되고 있는 가운데, 하나의 프로젝트만 개발·운용 스타일 을 변경하려고 하면, 조정과 설득의 범위에서만 봐도 Bottom-Up 방식의 접근에 의한 변화가 DevOps화의 지름길이 될 수 있습니다. Bottom-Up 방식으로 조직을 바꾸고 DevOps 방식을 도입할 때는 개인이 팀과 조직의 벽을 넘어 멤버와 동료를 단계적으로 움직여 갈 필요가 있습니다.
지금까지 본 바와 같이, 우선 자신이 DevOps 도구를 사용하여 개인의 개발 환경 도구를 바꾸며 멤버들에게 도전하는 것이 효과적입니다. 이후 팀 전체의 규칙과 팀 간의 커뮤니케이션을 바꾸어 역할 분담을 검토하고, 체제를 약간 변경하여 피드백하며 단계적으로 적용해 나가도록 합니다. 여기에서는 Bottom-Up 방식으로 조직에 DevOps를 도입할 때, 특히 주의해야 하는 점과 더불어 구체적으로 어떻게 하면 좋을지 생각해 봅니다.
<책에서 추천한 전체적인 그림>
*자세한 내용은 도서에서 볼 수 있습니다.
Goal을 선정한다
∨
정보를 수집한다
∨
현상을 분석한다
∨
본질적으로 불필요한 것을 제거한다
∨
방식을 바꿀 수 있는 포인트를 찾는다
∨
도입한다
∨
계몽한다
∨
효과를 측정하고 모두에게 피드백한다
∨
한 사람으로 안되므로 전원이 한다
∨
전체적인 Goal을 생각하면서 두 번째 정책으로 이동한다
《IT 운용 체제 변화를 위한 데브옵스DevOps》
'IT 정보' 카테고리의 다른 글
| 데이터 분석, 목적이 명확해야 성공한다! (0) | 2020.12.28 |
|---|---|
| 개발자 동료에게 큰 혼란을 주는 테스트 작성 방법! (테스트 코드 함정) (0) | 2020.12.15 |
| 주니어 개발자들, 깔끔한 코드를 쓰고 싶다면 꼭 읽어보세요! (0) | 2020.12.10 |
