DevOps가 어떤 것인지, DevOps의 도구를 알고 싶고 빠르게 개선하고 싶다는 생각으로 Bottom-Up 방식을 통해 성급하게 도입하려고 한다면, 동료가 늘어나기는커녕 아무도 따라오지 않고 팀장에게도, 멤버에게도 DevOps를 제대로 이해시키지 못하는 일이 일어날 수 있습니다. 이처럼 좋은 취지에서 시작했지만 결과가 좋지 못하게 나왔다면 Antipattern에 빠져 있지 않은지 확인해 보세요!
- 목적과 수단을 잘못 알아듣는다
사람들을 설득했음에도 불구하고 아무도 시도하려고 하지 않는다면 DevOps화하는 목적이 무엇이었는지 생각해 보세요. Ansible을 도입하는 것이 목적이었는지, Jenkins에서 Deploy를 자동화하는 것이었는지 등 침착하게 다시 생각해 보세요. 도구 도입·구조 도입은 어디까지나 수단입니다.
DevOps의 방식을 도입하는 목적은 다른 곳에 있습니다. ‘업무 속도를 올리고 싶다’, ‘적은 인원으로 운영해 갈 수 있는 체제를 만들고 싶다’, ‘더 나은 서비스를 만들어 가고 싶다’ 이러한 목적에 비추어 봤을 때 지금 도입하고자 하는 방식은 맞는 것일까요?
극히 좁은 범위의 Bottom-Up 방식이라면 수단이 선행하는 것은 물론 가능합니다. 그러나 사람을 움직일 때에는 목적과 도입한 것을 통해 어떤 결과가 일어나는지, 그 앞에 무엇이 기다리고 있는지에 대한 시나리오가 반드시 필요합니다. 좋은 도구와 좋은 방식이 어떤 것인가를 생각하는 것이 아니라 나은 세계를 실현하기 위해 어떤 도구와 수단이 적합한지를 검토하는 것입니다.
- 도입은 했지만 사용되지 않는다
크든 작든 DevOps 도구를 도입할 수 있었음에도, 실제 운영에서 아무도 사용하지 않고 수용되어야 하는 정책이 전혀 반영되지 않고 있나요? 그 이유는 간단합니다. 그것은 이전의 방식에 비해 너무나 과격한 “지나친 변화” 때문입니다.
현재의 개발과 운용을 버리고 새로운 구조에 적응할 사람이 도대체 몇 명이나 있을까요? ‘나는 다를 것이다’라고 생각할 수 있습니다. 물론 정말 그럴지도 모릅니다. 멤버들은 어떤가요? 모두가 선진적이고 유연합니까? 만일, 전원이 이것을 긍정적으로 여겼다고 하더라도, 당장 해야 하는 다른 일들이 많다면 지나치게 변경된 개발·운용에 적응하기 위한 체력과 정신력이 남아 있을까요?
Bottom-Up 방식의 도입에서 조심해야 하는 것은 아직 DevOps 방식이 익숙하지 않은 초반에, 수단을 대체하는 부분의 Input과 Output은 반드시 기존 수단의 Input 및 Output과 맞춰 두어야 한다는 것입니다. 약간의 변경이 수반되는 것조차 허용되지 않을지도 모릅니다.
대체하려고 하는 단계가 시작하는 부분이라면, 도입한 단계에 의해 수행된 결과가 원래의 규칙을 벗어나지 않도록 배려해 주어야 합니다. DevOps 방식에 익숙해져 있지 않은 멤버와 팀이 새로운 구조를 따라가려면, 지금까지 해 왔던 일을 ‘완전히’ 바꾸지 않아도 새로운 구조가 도입될 수 있도록 하는 것이 중요합니다.
- 오히려 운용이 힘들다
DevOps 방식과 도구를 도입한 결과, 할 일이 많아진 것은 아닌가요? 신규로 도입된 도구를 가동하기 위해서 매번 2개~3개 이상의 단계가 늘어나고 DevOps 도구를 사용하기 위해서 수작업으로 Format을 변환해야 하는 웃지 못할 이야기도 있습니다.
DevOps 방식과 도구를 도입할 때는 반드시 도입한 결과가 어떻게 될 것인지 전체적인 관점에서 진단해야 합니다. 부분적인 이상을 추구함에 따라 전체적으로는 점점 할 일이 커지고 기존 작업과 병행으로 수행해야 하며, 병행하는 것에 의해 추가적인 작업이 증가하는 등 도입 후에 유지될 수 없는 방식은 피해야 합니다.
- DevOps 팀이 권위가 되다
DevOps 팀의 도입·시작이 성공했다고 합시다. 과연 DevOps는 언제나 정확하고 절대적인 정의일까요?
물론, DevOps는 좋은 방법이고 그것을 지원하는 도구도 풍부합니다. 개선 정책을 위한 열정적인 마음과 팀의 시작에는 상당한 수고가 요구됩니다. 여기서 중요한 것은 DevOps를 적용한 팀과 자신 모두, 내가 하고 있는 것과 ‘다른 것’은 나쁘다고 생각하지 말아야 합니다.
DevOps의 목적 중 하나는 사일로(Silo, 수직적 조직에서 부서 간 연계가 결여된 상태)를 끊는 것입니다. 자신들이 자신들의 정의를 너무 믿어서, 혹은 개선이 너무 잘 진행되어 권위를 갖게 됨에 따라, 새로운 사일로를 만들어 버리게 되면 본말전도라고 할 수 있습니다.
DevOps는 항상 열려 있어야 합니다. 만들어진 DevOps 팀은 항상 유연하게 다른 팀과 의사소통이 가능하게 유지해야 함을 잊어서는 안됩니다.
- DevOps 인재가 육성되지 않는다고 한탄한다
DevOps를 추진함에 있어서 개발도 알고 운용도 아는 슈퍼맨을 늘리지 않으면 안 된다고 생각하고 있나요?
DevOps는 Dev(개발)과 Ops(운용)의 장점을 결합한 체제이며, 모두가 동일한 Skill을 가지는 것은 아닙니다. 또한 DevOps 방식의 도입으로, 즉각적으로 Skill Set이 통일되고 오버헤드가 줄어들며 사일로가 파괴되는 등 모든 것이 바로 해결되는 것은 아닙니다. 서로의 기술을 이해하고 배우며 불필요한 커뮤니케이션 문제를 해소, 효율화하고 사일로를 제거해 가는 그 생각 자체가 DevOps라고 할 수 있습니다.
개발도 알고 운용도 아는 슈퍼맨은 불필요하다는 것인가 라는 문제에 대해서는 No라고 말하고 싶습니다. 한 사람이라도 좋으니 모든 것을 아는 사람이 있으면 DevOps를 시작, 정착하는 것이 몇 배나 빨라지게 될 것입니다. 가장 힘든 것은 개발이 운용을, 운용이 개발을 이해하는 쌍방향의 이해관계를 만들어 내는 것입니다. 이 모든 것을 이해하고 있는 중간자가 쌍방의 이해관계를 도모하면 도입의 길이 훨씬 순조로울 것입니다.
- DevOps 도입 후 실패가 발생했기 때문에, 우리에게 DevOps는 적합하지 않다고 생각한다
DevOps 방식을 도입했지만 실패했다고 가정해 봅니다. 예를 들어, 개발이 운용에 필요한 Resource 이용량을 신경 쓰지 않고 구현하여 출시 후 몇 시간 만에 문제가 발생했다고 생각해 봅시다. 실패 원인에 대해서 다양한 의견이 나올 것입니다. “DevOps야말로 우리한테는 무리다”, “우리 개발팀은 운용의 본질을 이해하지 못할 것이다”, “DevOps가 아니라 전문가(Expert)를 갖춘 전문 부대원끼리의 승인 행위가 필요한 것 아닌가?” 등 실망이나 반발, 혹은 노력 자체를 의문시하는 목소리가 있을지도 모릅니다.
문제가 발생한 경우에는 개발과 운용을 아울러 되돌아보는 것이 절대적으로 필요합니다. 이것은 DevOps에 국한된 것은 아닙니다. 문제 대응을 할 때에는 어딘가에서부터 반드시 문제점을 되돌아보아야 합니다. 되돌아봄으로써 어디가 문제이고 어떻게 고쳐 나갈 것인가를 검토하는 것입니다. DevOps는 개선을 쌓아 올려 완성해 가는 것이며, 짧은 기간에 도입의 성공·실패를 판단하는 것이 아닙니다. 게다가 본인들과 동떨어진 의견이 나왔다고 하더라도 주춤거리는 일은 없어야 합니다.
DevOps로 하지 못하면 안 되는 것은 본질적으로 단순한 협력 체제입니다. 어느 조직이나 회사에 있는 필수적인 능력입니다. 단순히 못한 것에 대한 개선책을 검토하여 차기 대책으로 넣어 주면 좋습니다.
《IT 운용 체제 변화를 위한 데브옵스DevOps》
'IT 정보' 카테고리의 다른 글
| AI에 필요한 수학을 공부하고 싶다면? 이 책을 꼭 읽어보세요! (0) | 2021.01.19 |
|---|---|
| 수집한 데이터, 적절하게 입력하는 방법! (0) | 2021.01.05 |
| 나는 어떤 데이터 분석 방법을 택해야 할까? (0) | 2020.12.30 |
