데브옵스, 장기적으로 성공하려면 기초부터 탄탄히 다져야
팀원 지지 확보 등 조직 문화 바꿔놓을 구체적 조언들 정리
[보안뉴스 오다인 기자] 데브옵스(DevOps)는 지난 몇 년 간 매우 빠른 속도로 도입되어왔다. 소프트웨어 개발 팀 수가 많아지는 만큼 데브옵스는 업무 방식의 표준처럼 굳어지고 있다. 그러나 조직들이 데브옵스라는 시류에 신나게 편승하는 한편으로, 데브옵스 이니셔티브를 시작하는 것과 장기적으로 데브옵스를 지원해나가는 건 완전히 다른 문제임을 파악하기 시작한 사람들도 많이 나타나고 있다.
세계적 신용카드 및 결제 서비스 회사 바클리카드(Barclaycard)의 소프트웨어 공학 부사장인 프레마난드 찬드라세카란(Premanand Chandrasekaran)은 어느 인터뷰에서, 많은 조직이 토대부터 먼저 튼튼하게 구축하지 않은 채로 데브옵스라는 태풍 속에 들어가고 있다고 말했다. 찬드라세카란은 “데브옵스 이니셔티브의 장기적인 성공은 해당 프로그램의 기반이 협력적으로 구축돼있는지 분명히 할 때 가장 확실하게 보장될 수 있다”면서 데브옵스에 참여하는 사람들이 각각의 기능이 어떻게 작동하는지 이해하고 있을 때 최선의 결과를 기대할 수 있다고 설명했다.
데브옵스 이니셔티브를 계획하고 구조화할 때는 다양한 배경을 가진 전문가들이 선별돼야 한다. 조직의 목표를 향해 전체적이면서도 전인적으로 접근하기 위함이다. 찬드라세카란은 “오픈소스 소프트웨어를 가치 있게 여길 줄 아는 경영진과 교차수분(cross-pollinating)의 가치를 이해하는 개발자 및 운영 전문가들이야말로 데브옵스 프로그램을 구축할 때 최고의 인재들”이라고 말했다.
데브옵스에 푹 빠져 있는 조직 중에는 지나치게 많은 멤버들로 팀을 구성하는 경우도 있다. “많은 기업들이 50명 정도로 팀을 구성합니다. 하지만 데브옵스 팀원들이 함께 협력하기에 가장 좋은 규모는 8명에서 12명 정도입니다. 즉, 50명을 이 정도 규모의 팀으로 쪼개서, 사업 결과물에 집중할 수 있도록 만들어야 한다는 뜻이죠.” 미국 시카고에 있는 클라우드 자문 회사 어헤드(AHEAD)의 기술 아키텍트인 팀 컬리스(Tim Curless)가 권고한 사항이다.
컬리스는 “개개인의 역할을 이해하는 것과 더불어, 팀원들은 다른 팀 멤버들의 역할도 이해해야 한다”고 말했다. 그래야 협업과 소통이 조직 전체에 활성화될 수 있다는 것이다.
데브옵스는 문화에서 시작된다
데브옵스는 기술이 아니라 문화에서부터 시작된다. 보안 컨설팅 회사 싸이브릭(CYBRIC)의 CTO이자 야후(Yahoo)의 전직 CIO였던 마이크 케일(Mike Kail)은 “어느 날 갑자기 누가 ‘데브옵스를 하자’고 해서 데브옵스가 시작되는 게 아니”라고 말했다. “데브옵스 이니셔티브는 경영진의 지원이 필요한 일인 동시에, 측정과 추적이 가능한 잘 정의된 목표들이 필요한 일입니다.”
데브옵스라는 여정은 조직이 문화, 툴, 절차적 관점을 실행하는 데 익숙해지도록 만드는 것부터 시작될 수 있다. 공학 디자인 회사 아리센트(Aricent)의 기술 혁신 부사장보(AVP)인 지텐드라 테티(Jitendra Thethi)는 “이런 방식으로 조직들은 어떤 이니셔티브가 가장 큰 가치를 낳을 것인지 제대로 파악할 수 있고, 소프트웨어 구현 방식과 관련해서도 기존 방식에 과도한 지장을 주지 않는 선에서 추진할 수 있다”고 설명했다.
성공적인 조직들 상당수가 데브옵스를 점진적으로 추진해왔다. 각기 다른 이해관계자들이 데브옵스라는 실행 방식의 가치를 확인하고 또 이해할 수 있도록 하기 위해서다. 장기적으로 이는 “조직 내 데브옵스 도입을 가속화하는 일”이라고 테티는 덧붙였다.
데브옵스를 빠르게 시작할 방법을 찾으면서, 많은 기업들이 기존의 운영 인력을 단순히 리브랜딩한 뒤 데브옵스 팀으로 만드는 방식을 택하고 있다. “이렇게 하지 마세요. 사일로(silo: 담 쌓은 듯 외부와 소통하지 않는 부서를 일컫는 말)가 현상 유지될 뿐이거든요.” 온라인 강의 사이트 린다닷컴(Lynda.com)의 데브옵스 과정 강사이자 클라우드 보안 플랫폼 제공업체 시그널 사이언스(Signal Sciences)의 연구 팀장인 제임스 위케트(James Wickett)는 “그 대신, 데브옵스라는 야심한 목표들을 중심으로 팀을 결집시키고, 지속적 배포, 자동화, 계측(instrumentation)을 통해 소프트웨어를 더욱 빠르게 배포할 수 있도록 만들어야 한다”고 제안했다.
지지를 형성하고, 저항을 극복하라
직원들이 데브옵스에 대해 열정적으로 뛰어들리라 기대하지 마라. 데브옵스도 관리 방식일 뿐이기 때문이다. 미국 샌프란시스코의 홀버튼 소프트웨어 공학 학교(Holberton School of Software Engineering) 공동 설립자인 실베인 칼라치(Sylvain Kalache)는 “데브옵스는 대부분 절차와 업무 및 협업 방식에 대한 것이기 때문에 가장 큰 장애물 중 하나가 바로 데브옵스라는 새로운 방법론을 이해하거나 이런 방식으로 일하기 거부하는 팀원들로부터 나온다”고 경고했다. 칼라치는 “데브옵스가 무엇이고 왜 해야 하는지 팀을 교육하는 것이 중요하다”고 덧붙였다.
내부적인 반발은 다양한 방식으로 표출될 수 있다. 시그널 사이언스의 위케트는 “언제나 대기해야 하는 상황에 대해 개발자들이 반발할 수도 있고, 운영 팀 직원들이 개발자 툴을 사용하는 걸 거부할지도 모른다”고 말했다. 이런 반응은 정상적인 것이므로 관리자들은 반발이 느껴진다 하더라도 놀라서는 안 된다. 위케트는 “그러나 모든 사람이 하나의 생각에 동조하고 있다는 기대감은 필요하다”고 말했다. “자신이 만들고, 자신이 배포하고, 자신이 운영한다”는 생각 말이다.
최대한의 효과를 얻으려면, 데브옵스라는 개념을 이해하고 이것의 가치를 확신하는 누군가가 데브옵스 이니셔티브를 이끌 필요가 있다. 칼라치는 “차세대 소프트웨어 엔지니어들은 모두 데브옵스를 사용하고 있다”면서 “그들에게 데브옵스는 통상적인 업무 방식”이라고 설명했다. 그는 “젊은 인재를 채용한다면 데브옵스에 필요한 새로운 사고방식을 조직 내부로 들여올 수 있을 것”이라고 말했다.
아리센트의 테티에 따르면, 데브옵스 이니셔티브는 최고제품책임자(CPO) 같은 기술 경영진이 적극적으로 옹호해서 조직 내 개별 그룹들이 이 프로젝트의 중요성에 대해 이해할 수 있도록 만들어야 한다. 이런 고위직 책임자들은 부서 간 협업을 격려하는 경향이 있기도 하다. 테티는 “경영의 최전선에 있는 엔지니어링 부사장은 이 같은 데브옵스 전략에 강한 드라이브를 걸고 데브옵스 이니셔티브의 지표와 핵심성과지표(KPI) 등을 측정해야 한다”고 말했다.
모멘텀을 유지하는 것
테디는 데브옵스를 한때의 유행이나 잠깐 반짝하고 마는 프로젝트로 여겨서는 안 된다고 조언했다. 제한된 범위나 시간으로 바라봐서는 안 된다는 뜻이다. 그 대신 테티는 “조직 내 문화적인 변화를 만들어냄으로써 소프트웨어를 빠르고 지속적으로 구현하게 하고, 나아가 하나의 표준으로까지 진화하게 하는 방법론으로 데브옵스 이니셔티브를 바라봐야 한다”고 말했다.
또한, 데브옵스 이니셔티브의 동기와 목표를 명확히 하는 것도 반드시 필요한 부분이다. “데브옵스로의 전환은 지속적인 여정이지 어느 하나의 목표점이 아니라는 사실을 시작부터 분명히 맥락에 포함시켜야 합니다.” 싸이브릭의 케일은 “데브옵스 문화의 핵심 원리인 협업, 자동화, 측정과 공유를 항상 명심하라”고 말했다.
덧붙이는 작은 조언 하나: 데브옵스의 진도를 측정해라
결과를 측정하는 건 프로젝트의 성패를 판단하는 핵심 단계다. 이 원리는 데브옵스에도 적용된다. 데브옵스 이니셔티브는 “업무 효율성과 제품 안정성을 높이고, 심지어 팀 분위기까지 향상시킬 수 있다”고 홀버튼 학교의 칼라치는 설명했다. “진도(Progress)는 측정된 뒤 팀원들과 공유돼야 합니다. 그래서 팀원 모두가 목표에 집중할 동력을 얻을 수 있도록 해야 하죠.”
아리센트의 테티는 향상된 협업 수준과 지표가 KPI를 기초로 구성돼야 한다고 말했다. 정확한 측정은 더 긴밀한 협업을 이끌어낼 수 있고, 각 팀이 더 효과적으로 일하거나 역할을 재정의할 수 있도록 돕는다. 테티는 “데브옵스와 빠른 배포 주기가 직원 개개인과 회사에 어떻게 도움이 되는지 각 팀에서 분명하게 확인할 수 있어야 한다”고 지적했다.
바클리카드의 찬드라세카란은 생산에 들어가기 전에 문제를 발견하려면 자동화한 테스팅이 반드시 필요하다고 덧붙였다. “(자동화를 통해) 기본적인 것들이 모두 처리되고, 프로세스도 효율적이고 협업적으로 구축된다면, 전반적인 데브옵스의 질은 훨씬 높아질 것입니다.”
글 : 존 에드워즈(John Edwards)
[국제부 오다인 기자(boan2@boannews.com)]
팀원 지지 확보 등 조직 문화 바꿔놓을 구체적 조언들 정리
[보안뉴스 오다인 기자] 데브옵스(DevOps)는 지난 몇 년 간 매우 빠른 속도로 도입되어왔다. 소프트웨어 개발 팀 수가 많아지는 만큼 데브옵스는 업무 방식의 표준처럼 굳어지고 있다. 그러나 조직들이 데브옵스라는 시류에 신나게 편승하는 한편으로, 데브옵스 이니셔티브를 시작하는 것과 장기적으로 데브옵스를 지원해나가는 건 완전히 다른 문제임을 파악하기 시작한 사람들도 많이 나타나고 있다.
[이미지=iclickart]
세계적 신용카드 및 결제 서비스 회사 바클리카드(Barclaycard)의 소프트웨어 공학 부사장인 프레마난드 찬드라세카란(Premanand Chandrasekaran)은 어느 인터뷰에서, 많은 조직이 토대부터 먼저 튼튼하게 구축하지 않은 채로 데브옵스라는 태풍 속에 들어가고 있다고 말했다. 찬드라세카란은 “데브옵스 이니셔티브의 장기적인 성공은 해당 프로그램의 기반이 협력적으로 구축돼있는지 분명히 할 때 가장 확실하게 보장될 수 있다”면서 데브옵스에 참여하는 사람들이 각각의 기능이 어떻게 작동하는지 이해하고 있을 때 최선의 결과를 기대할 수 있다고 설명했다.
데브옵스 이니셔티브를 계획하고 구조화할 때는 다양한 배경을 가진 전문가들이 선별돼야 한다. 조직의 목표를 향해 전체적이면서도 전인적으로 접근하기 위함이다. 찬드라세카란은 “오픈소스 소프트웨어를 가치 있게 여길 줄 아는 경영진과 교차수분(cross-pollinating)의 가치를 이해하는 개발자 및 운영 전문가들이야말로 데브옵스 프로그램을 구축할 때 최고의 인재들”이라고 말했다.
데브옵스에 푹 빠져 있는 조직 중에는 지나치게 많은 멤버들로 팀을 구성하는 경우도 있다. “많은 기업들이 50명 정도로 팀을 구성합니다. 하지만 데브옵스 팀원들이 함께 협력하기에 가장 좋은 규모는 8명에서 12명 정도입니다. 즉, 50명을 이 정도 규모의 팀으로 쪼개서, 사업 결과물에 집중할 수 있도록 만들어야 한다는 뜻이죠.” 미국 시카고에 있는 클라우드 자문 회사 어헤드(AHEAD)의 기술 아키텍트인 팀 컬리스(Tim Curless)가 권고한 사항이다.
컬리스는 “개개인의 역할을 이해하는 것과 더불어, 팀원들은 다른 팀 멤버들의 역할도 이해해야 한다”고 말했다. 그래야 협업과 소통이 조직 전체에 활성화될 수 있다는 것이다.
데브옵스는 문화에서 시작된다
데브옵스는 기술이 아니라 문화에서부터 시작된다. 보안 컨설팅 회사 싸이브릭(CYBRIC)의 CTO이자 야후(Yahoo)의 전직 CIO였던 마이크 케일(Mike Kail)은 “어느 날 갑자기 누가 ‘데브옵스를 하자’고 해서 데브옵스가 시작되는 게 아니”라고 말했다. “데브옵스 이니셔티브는 경영진의 지원이 필요한 일인 동시에, 측정과 추적이 가능한 잘 정의된 목표들이 필요한 일입니다.”
데브옵스라는 여정은 조직이 문화, 툴, 절차적 관점을 실행하는 데 익숙해지도록 만드는 것부터 시작될 수 있다. 공학 디자인 회사 아리센트(Aricent)의 기술 혁신 부사장보(AVP)인 지텐드라 테티(Jitendra Thethi)는 “이런 방식으로 조직들은 어떤 이니셔티브가 가장 큰 가치를 낳을 것인지 제대로 파악할 수 있고, 소프트웨어 구현 방식과 관련해서도 기존 방식에 과도한 지장을 주지 않는 선에서 추진할 수 있다”고 설명했다.
성공적인 조직들 상당수가 데브옵스를 점진적으로 추진해왔다. 각기 다른 이해관계자들이 데브옵스라는 실행 방식의 가치를 확인하고 또 이해할 수 있도록 하기 위해서다. 장기적으로 이는 “조직 내 데브옵스 도입을 가속화하는 일”이라고 테티는 덧붙였다.
데브옵스를 빠르게 시작할 방법을 찾으면서, 많은 기업들이 기존의 운영 인력을 단순히 리브랜딩한 뒤 데브옵스 팀으로 만드는 방식을 택하고 있다. “이렇게 하지 마세요. 사일로(silo: 담 쌓은 듯 외부와 소통하지 않는 부서를 일컫는 말)가 현상 유지될 뿐이거든요.” 온라인 강의 사이트 린다닷컴(Lynda.com)의 데브옵스 과정 강사이자 클라우드 보안 플랫폼 제공업체 시그널 사이언스(Signal Sciences)의 연구 팀장인 제임스 위케트(James Wickett)는 “그 대신, 데브옵스라는 야심한 목표들을 중심으로 팀을 결집시키고, 지속적 배포, 자동화, 계측(instrumentation)을 통해 소프트웨어를 더욱 빠르게 배포할 수 있도록 만들어야 한다”고 제안했다.
지지를 형성하고, 저항을 극복하라
직원들이 데브옵스에 대해 열정적으로 뛰어들리라 기대하지 마라. 데브옵스도 관리 방식일 뿐이기 때문이다. 미국 샌프란시스코의 홀버튼 소프트웨어 공학 학교(Holberton School of Software Engineering) 공동 설립자인 실베인 칼라치(Sylvain Kalache)는 “데브옵스는 대부분 절차와 업무 및 협업 방식에 대한 것이기 때문에 가장 큰 장애물 중 하나가 바로 데브옵스라는 새로운 방법론을 이해하거나 이런 방식으로 일하기 거부하는 팀원들로부터 나온다”고 경고했다. 칼라치는 “데브옵스가 무엇이고 왜 해야 하는지 팀을 교육하는 것이 중요하다”고 덧붙였다.
내부적인 반발은 다양한 방식으로 표출될 수 있다. 시그널 사이언스의 위케트는 “언제나 대기해야 하는 상황에 대해 개발자들이 반발할 수도 있고, 운영 팀 직원들이 개발자 툴을 사용하는 걸 거부할지도 모른다”고 말했다. 이런 반응은 정상적인 것이므로 관리자들은 반발이 느껴진다 하더라도 놀라서는 안 된다. 위케트는 “그러나 모든 사람이 하나의 생각에 동조하고 있다는 기대감은 필요하다”고 말했다. “자신이 만들고, 자신이 배포하고, 자신이 운영한다”는 생각 말이다.
최대한의 효과를 얻으려면, 데브옵스라는 개념을 이해하고 이것의 가치를 확신하는 누군가가 데브옵스 이니셔티브를 이끌 필요가 있다. 칼라치는 “차세대 소프트웨어 엔지니어들은 모두 데브옵스를 사용하고 있다”면서 “그들에게 데브옵스는 통상적인 업무 방식”이라고 설명했다. 그는 “젊은 인재를 채용한다면 데브옵스에 필요한 새로운 사고방식을 조직 내부로 들여올 수 있을 것”이라고 말했다.
아리센트의 테티에 따르면, 데브옵스 이니셔티브는 최고제품책임자(CPO) 같은 기술 경영진이 적극적으로 옹호해서 조직 내 개별 그룹들이 이 프로젝트의 중요성에 대해 이해할 수 있도록 만들어야 한다. 이런 고위직 책임자들은 부서 간 협업을 격려하는 경향이 있기도 하다. 테티는 “경영의 최전선에 있는 엔지니어링 부사장은 이 같은 데브옵스 전략에 강한 드라이브를 걸고 데브옵스 이니셔티브의 지표와 핵심성과지표(KPI) 등을 측정해야 한다”고 말했다.
모멘텀을 유지하는 것
테디는 데브옵스를 한때의 유행이나 잠깐 반짝하고 마는 프로젝트로 여겨서는 안 된다고 조언했다. 제한된 범위나 시간으로 바라봐서는 안 된다는 뜻이다. 그 대신 테티는 “조직 내 문화적인 변화를 만들어냄으로써 소프트웨어를 빠르고 지속적으로 구현하게 하고, 나아가 하나의 표준으로까지 진화하게 하는 방법론으로 데브옵스 이니셔티브를 바라봐야 한다”고 말했다.
또한, 데브옵스 이니셔티브의 동기와 목표를 명확히 하는 것도 반드시 필요한 부분이다. “데브옵스로의 전환은 지속적인 여정이지 어느 하나의 목표점이 아니라는 사실을 시작부터 분명히 맥락에 포함시켜야 합니다.” 싸이브릭의 케일은 “데브옵스 문화의 핵심 원리인 협업, 자동화, 측정과 공유를 항상 명심하라”고 말했다.
덧붙이는 작은 조언 하나: 데브옵스의 진도를 측정해라
결과를 측정하는 건 프로젝트의 성패를 판단하는 핵심 단계다. 이 원리는 데브옵스에도 적용된다. 데브옵스 이니셔티브는 “업무 효율성과 제품 안정성을 높이고, 심지어 팀 분위기까지 향상시킬 수 있다”고 홀버튼 학교의 칼라치는 설명했다. “진도(Progress)는 측정된 뒤 팀원들과 공유돼야 합니다. 그래서 팀원 모두가 목표에 집중할 동력을 얻을 수 있도록 해야 하죠.”
아리센트의 테티는 향상된 협업 수준과 지표가 KPI를 기초로 구성돼야 한다고 말했다. 정확한 측정은 더 긴밀한 협업을 이끌어낼 수 있고, 각 팀이 더 효과적으로 일하거나 역할을 재정의할 수 있도록 돕는다. 테티는 “데브옵스와 빠른 배포 주기가 직원 개개인과 회사에 어떻게 도움이 되는지 각 팀에서 분명하게 확인할 수 있어야 한다”고 지적했다.
바클리카드의 찬드라세카란은 생산에 들어가기 전에 문제를 발견하려면 자동화한 테스팅이 반드시 필요하다고 덧붙였다. “(자동화를 통해) 기본적인 것들이 모두 처리되고, 프로세스도 효율적이고 협업적으로 구축된다면, 전반적인 데브옵스의 질은 훨씬 높아질 것입니다.”
글 : 존 에드워즈(John Edwards)
[국제부 오다인 기자(boan2@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
오다인기자 기사보기
[2024-04-18] 
.jpg)
