1장. 개발자를 위한(또는 개발자를 반대하는) DevOps
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
네가 여기서 코골이 거짓말을 하는 동안 눈을 뜨고 음모를 꾸미는 동안 그분의 시간은 걸리네. 인생의 경우 조심하십시오, 잠을 떨쳐내고 조심하라: 깨어, 깨어!
윌리엄 셰익스피어, 템페스트
DevOps 운동이 단순히 개발자에 대한 운영팀의 음모가 아니냐고 묻는 사람도 있을 것입니다.이렇게 질문하는 사람 대부분은(전부는 아니지만) 진지한 대답을 기대하지 않을 것입니다. 왜냐하면 이런 질문은 혀를 차는 놀림으로 의도하기 때문입니다. 또한 개발 또는 운영 쪽 출신에 관계없이 누군가가 DevOps에 대해 대화를 시작하면 "하지만 DevOps가 실제로 무엇인가?"라고 질문할 때까지 약 60초가 걸리기 때문입니다.
이 용어가 만들어진 지 11년(업계 전문가들이 이 용어에 대해 말하고 토론하고 외쳤던 10년)이 지났으니 우리 모두 말도 안 되는 표준적이고 일반적으로 이해되는 정의에 도달했을 것이라고 생각할 수 있습니다. 하지만 그렇지 않습니다. 실제로 DevOps 인력에 대한 기업의 수요가 기하급수적으로 증가하고 있지만, 무작위로 뽑은 DevOps 직함을 가진 직원 5명이 DevOps가 무엇인지 정확히 말할 수 있을지 의문이 듭니다.
따라서 이 주제가 떠오를 때 여전히 머리를 긁적이는 자신을 발견하더라도 당황하지 마세요. 개념적으로 DevOps는 이해하기가 쉽지 않을 수 있지만 불가능하지도 않습니다.
하지만 이 용어를 어떻게 논의하든, 어떤 정의에 동의하든, 무엇보다도 명심해야 할 한 가지 중요한 사실이 있습니다: DevOps는 완전히 새로 만들어진 개념이며, 그 창시자는 운영 쪽에서 왔다는 사실입니다.
DevOps는 운영 측에서 만든 개념입니다.
DevOps에 대한 저의 전제는 도발적일 수 있지만 증명할 수도 있습니다. 사실부터 말씀드리겠습니다.
사례 1: 피닉스 프로젝트
거의 10년 전에 출간된 이후 고전이 된 진 김 외(IT 혁명) 저자의피닉스 프로젝트 ( )는 (전통적인 의미의) 방법론 매뉴얼이 아니라, 문제가 많은 한 기업과 그 IT 관리자가 갑자기 예산을 초과하고 예정보다 몇 달 늦어진 기업 이니셔티브를 실행해야 하는 임무를 맡게 된 이야기를 다룬 소설입니다.
소프트웨어 분야에 종사하는 분이라면 이 책의 나머지 주인공들도 친숙하실 것입니다. 하지만 지금은 이들의 전문 직함을 살펴보겠습니다:
-
IT 서비스 지원 담당 이사
-
분산 기술 담당 이사
-
소매 영업 관리자
-
수석 시스템 관리자
-
최고 정보 보안 책임자
-
최고 재무 책임자
-
최고 경영자
그들 사이의 연결 조직이 눈에 띄시나요? 이들은 지금까지 쓰여진 DevOps에 관한 가장 중요한 책 중 하나의 주인공인데 그중 한 명도 개발자가 아닙니다. 개발자가 줄거리에 등장하더라도 특별히 빛나는 용어로 언급되지는 않는다고 가정해 보겠습니다.
승리가 찾아오면, ...