DevOps, 법무, 피닉스 프로젝트
직업 때문인지는 몰라도 저는 애자일 (방법론이라 해야 하나?)에 대해서는 의심이 많습니다. 원래 이 동네에 오래 있다 보면, 지나치게 착한 척 하는 사람을 보면 일단 액면 그대로 받아들이지 않습니다. 게다가 컨설팅을 하면서 사람을 바꾼다거나, 문화가 중요하다거나 (기업 문화이건 뭐건) 하는 이야기를 들으면, 일단 저는 실패에 대해 미리 덫을 쳐 놓는 것 아닌가라는 생각부터 듭니다. 사람은 안바뀝니다. 문화는 사람보다 더 나쁘죠. 적어도 지표로는요. 도대체 바뀌었는지 안바뀌었는지 알 수도 없고, 언제 다시 바뀔지도 모르거든요. 절대 좋은 지표가 아닙니다. 사람에 대해서 조금 부연설명하자면 — 굳이 부연설명이 필요한 이유라면, 누군가 “사람은 본디 선하다”고 하는 성선설을 주장하면, 그게 핵심이 아닌데도 그걸 주장하는 사람도 착해 보이거든요. 역으로, 성악설을 주장하면 그 사람도 나빠 보이구요. 맹자는 착하고, 순자는 악하다는 인상이 어쩔 수 없이 남죠 — 사람은 물론 바뀝니다. 감옥에 들어가서 새 사람이 된 사람도 많구요. 그렇지만, 법과 관련된 일을 할 때는 사람은 바뀌지 않는다고 가정하는 것이 더 안전합니다. 예상치 않은 일을 피할 수 있죠.
애자일, 그러므로 나에게는 하고싶지만, 딱히 필요하지 않은 그런 것입니다. 옆집 아저씨가 교회 전도사면 좋죠. 그걸로 끝입니다.
요즘 유행하는 “DevOps,” 이것도 그런 것으로 보였습니다. 애자일의 연장으로 보였죠. 그렇지만, 그게 주는 매력이 아주 컸습니다. IT 부서에서는 개발팀과 운영팀이 있는데, 둘이 사이좋게 잘 살자는 이야기일겁니다, 아마도. 마찬가지 논리가 법무에서도 적용되거든요. 외부 변호사는 사내변호사, 더 낫게는 사내법무팀과 잘 지내야죠. 그 정도 관심을 가지고 이 책을 집어 들었습니다: Gene Kim, George Spafford, Kevin Behr. The Phoenix Project: A Novel About IT, DevOps, and Heling Your Business Win. IT Revolution Press, 2013.
꼭 읽을 책입니다. 꼭 읽었으면 좋겠습니다. 꼭 애자일 이야기는 아닙니다. 누군가는 이렇게 말하더군요. “애자일 없이도 데브옵스를 할 수 있지만, 데브옵스 없이는 애자일을 할 수 없다” Hering, DevOps for the Modern Enterprise.
이 책은 소설 형식을 빌었습니다. “더 골(The Goal)”이 생각나죠. 소설로도 손색 없습니다. 주인공 빌 팔머(Bill Palmer)는 자동자 부품 제조사에서 일하는 Ops의 일부인 소규모 IT 팀의 팀장입니다. 출근을 서두르고 있는데 뜬금 없이 인사부에서 전화를 받죠. 그는 “짤렸나?”라고 생각하는데, 인사부장은 그런 거 아니라고 말합니다. “어쩌면 좋은 소식이라고 할 수도 있겠네요.”
회사의 사장을 짤리고, 그 다음 사장 스티브 마스터스는 그를 IT 운영 부사장으로 임명합니다. 망했죠. 그는 “CIO”는 “Career Is Over”의 약자라고 합니다. 당장 책임질 일이 무지하게 많고, 뭐 하나만 잘못돼도 그냥 끝입니다. 그냥 책임지는 자리인거죠. 뭘 하는 자리가 아니라…
위기는 위기를 낳고, 상상할 수 있는 모든 문제가 다 생깁니다. 대표적으로 세 가지가 있습니다. IT 문제가 발생하면, 회사의 온갖 장비와 코드를 아는 사람이 필요한데, 그 한 사람에 의존도가 너무 높습니다. 회사가 오래되면 온갖 역사와 이력을 자랑하는 갖은 종류의 하드웨어와 코드가 쌓이게 마련인데, 이런 내밀한 사정을 아는 사람 한 사람이 있다면, 그에 대한 의존도가 너무 높아집니다. 여기서는 브렌트죠. 그러면, 그 사람이 병목이 됩니다. 최적화 이론에서 말하듯이, 그런 병목이 있을 때, 시스템 전체의 성능을 높이려면 결국 병목지점의 성능을 높이는 수 밖에 없죠. 둘째는 새로운 프로젝트입니다. DevOps의 핵심인데, 개발부서는 개발을 하고, 운영부서는 운영을 하는데, 그 둘 사이의 불화와 반목에 대한 이야기랄까… 개발팀은 자기네 일정에 따라 나름 급하게 움직입니다. 일정에 겨우 맞춰 제대로 된 코드를 주면 되지만, 그게 쉽지 않습니다. 그러다보니, 일단 주면 운영팀은 그때부터 머리가 아파집니다. 실제 서버에 올려 놓고 돌려 보면 (deploy라고 합니다) 안됩니다. 개발자는 말합니다. “제가 할 때는 됐었어요!” 개발팀에서 코드를 주면, 그게 끝이 아니라 시작인거죠. 마지막 문제는 준법감시(Security & Compliance)입니다. GDPR이다뭐다 정신이 없죠. 지켜야 할 법은 또 무지 많구요.
이 셋이 사이좋게 지내는 이야기입니다. 결국은 해피엔딩입니다. 이 해피엔딩을 위해서는 그 둘, 또는 셋이 잘 지내는 걸로 끝이 아닙니다. 거기에 제조, 재고관리, 판매 및 마케팅 팀과 잘 지내야 하고, 무엇보다도 그들에게 실제로 도움이 되어야 합니다. 그게 사실은 가장 중요한 교훈이죠. 망할 뻔 했다가 맨 마지막에 큰 교훈을 배운 (원래 큰 교훈은 망할 뻔 해야 배우는거죠) 사장이 말합니다.
너는 내가 IT는 단순한 부서가 아니라는 점을 깨닥게 해 줬어. 오히려 이것은 어디에나 있지. 전기처럼. 이것은 기술이야. 글을 읽을 줄 안다거나 산수를 할 수 있는 것과 같은… 파츠 리미티드사에는 본사에 읽기 또는 산수를 전담하는 부서가 없지. 우리는 우리가 고용하는 모두가 그걸 잘 할 거라고 기대하지. 기술이 할 수 있는 것과 할 수 없는 것을 이해하는 것은 모든 부서에서 보유해야 하는 핵심역량이 되었어.만일 특정 경영자가 이 기술 없이 팀이나 프로젝트를 이끈다면 실패할 수 밖에 없어.
모든 관리자가 계산된 위험을 받아 들어야 하지만, 그 과정에 회사 전체를 위험에 빠뜨리면 안돼지. 사업을 하는 모두가 기술을 사용하지. 따라서 이건 마치 과거 서부와 같은 상황이야. 이 새로운 세상에서 경쟁하는 것을 배우지 못한 회사는 사라지게 될거야.
이 책에는 딱 하나 그래프가 나옵니다. 다음 그래프입니다.1
한 마디로 “바쁜 사람이 있으면, 대기시간은 한없이 늘어진다”는 말입니다. 얼마나 늘어질까요? 그것은 바쁜 시간 나누기 노는 시간이라는 겁니다.
50% 바쁜 사람이라면, 대기시간은 한 시간이죠. 왜냐하면 그는 50%는 노는 시간이니까요. 위 표에서처럼 바쁜 시간이 80%를 넘어가면, 대기시간은 기하급수적으로 늘어납니다. 예를 들어, 90% 바쁘다면 아홉 시간을 기다리는거죠. 병목 이론의 핵심은 전직원이 바쁘게 정신 없이 움직인다면, 특히 병목이 움직인다면 효율은 대체로 떨어진다는거죠. 흥미로운 이야기입니다. 저도 가능한 한 노는 시간을 늘이려고 노력중입니다 (꼭 이런 수학적인 계산 때문은 아닙니다).
제가 이 이야기에 관심이 있는 이유는, 당연하게도, 이런 비슷한 상황에 많이 처하기 때문입니다. 외부변호사이기는 하나, 이런 상황으로 프로젝트에 참여하게 되는 경우가 많은데, 프로젝트 전체가 제대로 굴러가지 않으면 외부인 (변호사 뿐 아니라 컨설턴트, 회계사 등)은 곤란해 집니다. 딱히 제가 해야 하는 일이 아닌데도, 프로젝트 전체가 부드럽게 흘러가지 못하면 다 같이 곤란해지니, 왠지 좀 더 적극적으로 프로젝트에 참여해야 하게 되는거죠. 어떤 업무에 대해서? 어느 정도까지? 참 곤란한 문제입니다. 외부인으로서, 아주 곤란한 상황입니다. 프로젝트 자체에 대해서 코치 — 내지는 간섭하는 것은 제 영역을 벗어난 일이죠. 주제넘은 일이죠.
이런 문제가 DeoOps로 풀릴 수만 있다면야, 대박입니다. 사실상 외부변호사의 일과 사내법무팀의 일의 Dev와 Ops의 관계로 만들고 관리할 수 있을까요?
강추입니다. Gene Kim, George Spafford, Kevin Behr. The Phoenix Project: A Novel About IT, DevOps, and Heling Your Business Win. IT Revolution Press, 2013.