There’s No Such Thing as a “Devops Team” by Hubert Shin

원문보기

"성숙도가 낮은 조직에서는, 좋은 사람들이 별 생각 없이 저지른 행위가 본인들이 인지하지 못하는 상태에서 다른 이들에게 크게 피해를 주는 경우가 종종있다." — Ben Goldacre, Bad Pharma, p. xi

최근 난 우리 고객 중 한 명에게 받은 메일 내용 때문에 난 약간의 답답함을 느꼈다. 그는 Devops를 수행하고 싶다면서 "Devops라는 이름의 팀"을 만들자라고 제안했다. 난 그에게 "Devops 팀이라는 것은 세상에 없다" 라고 트윗으로 전달했다. 많은 슬로건들이 그렇듯이 보통 멋진 이름 뒤에 여러 거품이 있다. Devops 활동은 사실 기능적으로 분할된 조직(컨설팅팀, 분석/설계팀, 개발팀, 품질팀 등)이 그 기능적으로 분할된 상태를 포기하는 것을 의미한다. 그가 말한 의도는 결국 개발과 운영 사이에 또 다른 기능을 가진 조직을 사이에 만드는 것이었고, 이것을 통해 여러 문제들을 해결하는 것이었다. 이는 매우 나쁜(또는 모순된) 방법이다. 사실 Devops는, 앞에서와 같은 기능적 분할의 의미가 아니라, 기능적으로 분할된 조직간 더 나은 협업의 전략을 제시하는 것 또는, 기능적으로 분할된 조직간 관계를 넘어선 Cross-Functional Team을 만드는 활동이다.(또는 둘다 함께 진행하는 접근)

왜 기능단위로 분할된 조직(Functional Silo)이 문제인가?

보통 피할 수 없는 심각한 문제가 발생 했을때, 이에 대한 해결책으로 기능단위로 분할된 조직이 만들곤 한다. 최근에 내가 블로그에 올린 Elisabeth Hendrickson 과의 인터뷰 앞부분 내용을 읽어보면, 위와 관련된 솔루션 회사 사례를 접할 수 있을 것이다. 그녀는 심각한 품질 문제가 발생한 상황에 대해, 사람들이 어떻게 대처하고 해결했는지에 대한 경험을 들려 주고 있다. 해당 문제점의 재발방지를 위해, 그 회사는 QA를 담당할 부사장을 고용하고 QA 본부를 만들었다. 이조치는 곧바로 제품의 버그를 늘리는 결과로 이어졌다. QA조직이 생기면서 개발자들은 더 이상 품질에 대해 책임을 느끼지 않게 되었고, 대신 기능만 빨리 만들어 테스트가 될 수 있는 상태로 만드는 것에 초점을 맞추게 된 것이 주된 이유였다. 개발자들은 처음부터 높은 품질의 코드를 짜기 보다는, 어떻게든 테스터에게 작업된 내용을 던져 테스터가 알아서 하라는 식으로 일을 수행하게 되었다. 결과적으로 낮은 품질의 기능을 증가시키는 죽음의 소용돌이를 만들었고, 테스터는 더욱 더 많은 스트레스를 받는 문제가 반복되었다. Elisabeth는 2001년에 작성한 "더 나은 테스팅? - 더 낮은 품질?" 이라는 문서로 이 내용을 언급했다.

기본적인 문제는 이것이다 : 잘못된 행위는 스스로 만들어낸 행동에 대한 결과에 대해 본인이 이해하기 어려울 때 나타난다. 기능단위로 쪼개진 조직은 역할이 분할 되면서 그들의 행동의 결과에 대해 스스로 이해하기 어렵게 만든다. 위의 예처럼, 개발자들은 버그 투성이 코드를 만드는 결과에 대해 크게 신경쓰지 않게 된다.

내가 믿는 Devops 의 본질은 사람들이 그들의 행위 결과에 대해 제대로 책임질 수 있는 시스템을 만드는 것을 말한다. 그리고 제대로 일을 하는 것이 모든 것에 가장 쉬운 방법이기도 하다.

이것을 하는데 다음의 두 단계가 필요하다
  1. 모두가 자신의 행위에 대한 결과를 알게 하라. 이것은 운영팀과 개발팀의 인원을 순환 시키는 것으로 이룰 수 있다. 또는 운영인원을 개발자의 스탠드업 미팅이나 데모(Showcase)에 참여시키거나, 점심 후 함께 하며 배울 수 있는 세션을 열거나, 블로그를 쓰게 하거나 다른 기능적으로 분할된 조직의 사람들과 함께 점심을 먹거나 등의 액티비티를 통해 이룰 수 있다
  2. 사람들의 자신의 행위에 대한 결과에 책임을 지게 하라. 이것은 보다 중요한 이야기이다. 예를들어 개발자들에게 삐삐를 들고 다니게 하거나, 그들이 만든 제품과 서비스에 대해 SLA(Service Level Agreement)를 최초 정의하도록 하여 이러한 문제를 해결할 수 있다.
보통 두 번째 스텝(결과에 대해 책임지도록)으로 나아가지 못하는 주요 원인은, 대부분의 큰 조직들이 이것을 가능하게 하는 방식으로 조직을 구성하지 않기 때문이다. 다른 표현으로 말하면 그들은 소프트웨어 개발을 마치 토목사업을 하는 것처럼 여긴다. 프로젝트가 종료되면, 만들어진 시스템을 운영 사람들에게 던져버리고, "원래 그런거지 뭐" 라는 식으로 알아서 운영하게 하고, 개발했던 팀은 새로운 일을 찾아 모두가 뿔뿔이 흩어져 떠난다. 이 프로젝트 모델은 기본적으로 잘못되었다. 우리는 소프트웨어 개발을 하는 방식에 맞게 일을 해야 한다. 소프트웨어 개발은 토목사업이 아닌 제품개발(Product Development)로 인지되어야 한다.

가장 좋은 방법은 Cross-Functional Team을 만들어 각 제품이나 서비스에 대해 사람들이 자신의 행동에 대한 결과를 책임지게 하는 것이다. Amazon의 CTO인 Werner Vogels 는 다음과 같이 말했다. "당신이 만들고 당신이 실행하라"(전체 인터뷰를 읽어보는 것은 매우 가치있을 것이다)

때문에 위의 고객이 의도한 것처럼 개발자와 운영 팀 사이에 "Devops 팀" 이란 조직을 만들어 쓸데없이 또 다른 레이어를 사이에 집어 넣는 것은 문제를 해결하는데 최악의 선택이다. 더 명확히 말하면, 개발팀과 운영팀 사이에 또 다른 "Devops 팀"을 만드려는 시도는 잘못된 것이다. 이렇게 되면, 새로 만들어진 팀은 철저하게 시스템의 디플로이만 담당하는 것이 될 것이다. (이들 팀은 Devops 란 용어가 유행이 되기 전에는 전통적으로는 "릴리즈 관리" 라고 불리었다)

왜 책임을 나누면 일이 진행되지 않는가?

때때로, 사람들은 이 모델(지속적 딜리버리)이 법이나 제도 때문에 불가능하다고 이야기 한다. (예를들어 Sarbanes-Oxley, PCI-DSS등이 있다) 또는 특정 프레임웍(ITIL, COBIT)등이 책임을 필수적으로 나누어 버리기 때문에 어쩔 수 없다고 말한다. 물론, 책임의 분할은 여우가 닭장을 지키는 말도 안 되는 상황을 만들지 않기 위해 필수적인 아이디어이다. 테스트나 운영 그룹은 분명히 개발자가 만든 제품을 한번 더 검증하여 릴리즈 되기 전에 혹시, 버그가 있거나 문제를 만든 것은 아닌지 체크하고 확인해야 할 의무가 있다.

Elisabeth Hendrickson의 문서를 보면 책임이 제대로 분배되지 않았을 때, 일이 진행되지 않는 경우를 찾을 수 있다. "위험관리를 가장한 연극(실제로 위험관리를 하지 않으면서 하는 것처럼 보이는)"(이는 보안을 가장한 연극과 아주 유사하다) 이라고 표현한 예제를 보면, "엄청난 비용으로 아무것도 이룰 수 없는 경우"의 예로 TSA사례를 말한다. 마치 TSA가 공항의 보안을 강화하는 사례와 같이, 변경관리를 강화하면, 마치 변경에 대해 관리를 잘하는 것처럼 보일 수는 있더라도 실제로는 상황을 더 많은 문제투성이로 만들 수 있다.

예전에 은퇴한 동료 한 명(그가 은퇴해 정말 다행이다)에게 유럽의 큰 제조회사의 변경관리 프로세스에 대해 들은 적이 있다. 스프레드시트 안에 개발자들이 채워야 하는 7개 정도의 탭이 있고 이 탭을 채우면 이메일을 통해 다른 나라에 있는 변경 관리자에게 전달된다. 그리고 그가 이 변경을 승인할 지 안 할지에 대해 의사결정한다. 이 변경관리자는 개발자들이 스프레드시트에 채운 내용이 무엇인지 다 알 수 있는 방법이 없다. 때문에 변경이 어떤 위험이고 어떤 위험 완화 계획이 있는지 결국 개발자와 다시 이야기해야 한다. 이 개발자들은 위 사항(결국 다시 이야기할 수 밖에 없다는 사실)들에 대해 이미 너무도 잘 알기에 스프레드시트안에는 가장 제한적인 정보만 기술한다. 게다가, 변경관리자 또한 개발자들이 작성한 스프레드시트안에 내용이 별로 의미가 없고, 스프레드시트에 있는 내용 이외에도 관련된 다른 많은 작업들이 이루어지고 있다는 것을 알고 있다. 하지만 여전히 스프레드시트는 작성되고 서로에게 전달된다.

자 보라, 이것은 실제 위험관리가 아니다. 위험관리를 가장한 연극이다.

그리고 기능 조직간의 협업을 하려고 하는 것이든 Cross Functional Team을 만들든 하려는 시도가 규제나 "BP"들에 의해 불가능하다고 말하는 것은, 컨설팅 산업에 '연기가 모락모락 나는 고물스크린(Bullshit Smokescreen)' 을 방치하는 것이나 마찬가지이다. 더 분명히 말하고 싶은 것이 있다. Sarbanes-Oxley, ITIL 그리고 COBIT에 어디에도 역할을 반드시 분리해야만 한다는 말은 없다. COBIT v5에도 역시 "책임의 분리"라고 하는 제어(Control)조건이 없다. PCI-DSS에는 현재 형태에서는 역할이 분리되어야 한다고 말하고 있긴 하지만, 사람들이 협업해선 안 된다라는 말은 없다. 이는 분명히 다르다. 최근 난 Etsy의 운영 최고 책임자인 Michael Rembetsy과의 대화를 촬영한 적이 있다. 그는 이 대화를 통해 Etsy안에서 PCI-DSS 컴플라이언스를 이루기 위해 어떻게 역할을 분리했는지에 대해 말하고 있다.

운영팀의 역할

그래, 사실 처음부터 내가 그 고객에게 Devops 팀이란 것이 없다고 이야기한 것은 거짓이었다고 치자.

개발자들에게 그들이 만들어낸 시스템에 대해 책임을 져야 한다는 것은 개발자들이 운영하는 사람들에게 다음과 같은 것을 이해시켜야 한다는 의미이다. 즉, 하나하나 신뢰하긴 어려운 플랫폼에 어떻게 지속적인 디플로이를 가능하게 하여 신뢰할 만한 소프트웨어를 만들 수 있는지에 대해 말이다. 운영하는 사람 또한 스스로 개발환경에 대해 디플로이를 수행할 수 있어야 한다. 그들은 코드가 어떻게 테스트 가능하고, 유지가능해 지는지에 대해 이해해야 한다. 그들은 어떻게 패키징을 하는지, 디플로이 하는지, 디플로이 뒤에 어떠한 지원을 해야 하는지 분명히 알아야 한다.

누군가가 위와 같은 내용에 대해 개발자들의 도움이 필요한 경우, 누가"Devops 팀"에서 일하고 있고 해야할 일에 대해 잘 알고 있다면, 난 그 용어를 쓰는 것에 굳이 반대하지 않는다. 다만 중요한 것은 "Devops 팀" 만이 시스템의 빌드를 담당하고, 디플로이하고, 디플로이 스크립트를 쓰고 이들을 위한 시스템을 운영하는 사람들이 아니란 점이다. 또한 개발 팀안에 "Devops 전문가" 란 역할이 없어야 한다. Devops의 일은 가장 중요한 개발자의 역할 중 하나다. 마치 코드를 쓰는 것처럼 그것을 소유해야 한다.


핑백

덧글

  • hi.shin 2013/04/24 09:05 # 삭제 답글

    번역글 잘 읽고 갑니다.

    자기가 만든 건 자기가 책임져야 한다는 것엔 100% 동의합니다.
    품질을 위해 품질 부서의 규모가 커지는 것에 대해선 저도 동의하지 않습니다.
    관리를 위한 관리, 또 그 관리를 위한 관리가 많아지는 것이 일부 기업의 현실이기도 한 것 같습니다.
    품질을 위해선 무엇보다 능력있는 개발자를 채용하는 것이 가장 좋은 길이 아닐까 합니다.
    구글의 SET (Software Engineer in Test) 롤도 그런 의미라고 판단되구요.

    이러한 개념이 DevOps에도 적용된다는 것이 조금 놀라웠습니다.
    최근 DevOps에 매력을 느끼고 있었는데...
    형상관리에 관심이 있어 자료 찾아보면서도
    역할의 분리가 왜 굳이 필요한가 의문이 들면서도 필요할 것 같다는 생각도 들었었는데...

    좋은 글 감사합니다.
  • Hubert Shin 2013/04/24 22:37 # 답글

    좋은 말씀 감사합니다. 작성하신 모든 내용에 공감이 가네요.

    저 또한 DevOps 또는 보다 잘 정리된 CD가 그저 툴 셋인 줄만 알았습니다.
    추후에 Organization Structure 가 함께 변화해야 하는 사실을 깨닫게 되었습니다.

    대부분의 큰 조직이 위와 같은 패턴으로 Control 을 중시하는 형태로 기능단위로 분할된 조직을 만들어 내는 것 같습니다. 실용보다 명분 때문인 경우가 많은 것 같고요, 제가 다니는 회사에서도 비슷한 일이 벌어지고 있습니다.

    어떻게 개선해야 하는지는 정말 어려운 숙제가 되겠죠. 하지만 시도해 볼 만한 가치있는 활동이라 생각합니다.
댓글 입력 영역