2018.07.10

“핵심은 문화” 데브옵스 도입 전략

Bianca Wright | IDG Connect

기트랩(GItLab)의 ‘2018 글로벌 개발자 보고서(Global Developer Report)’가 밝혀낸 중요한 사항 중 하나는 데브옵스(DevOps)를 도입한 조직들이 애자일(Agile)을 실천하기보다 수요에 따라 도입하고 자동화에 우선순위를 두는 경향이 있다는 것이다. 데브옵스는 개발자와 소프트웨어 담당자의 워크플로를 개선하는 데 도움을 주는 ‘나이스 투 해브(갖고 있으면 좋은 것)’에서 ‘머스트 해브(반드시 갖고 있어야 하는 것)’가 되고 있다. 기트랩(GitLab)이 5,200명이 넘는 개발자, CTO, IT종사자를 설문 조사한 결과에 따르면, 데브옵스가 개발 프로세스의 시간을 많이 절약해준다고 대답한 비율이 2/3에 달한다. 또한 약 30%는 올 한 해 데브옵스에 투자할 계획이 있다고 답했다.

뉴 렐릭(New Relic)이 지난 해 실시한 조사는 데브옵스 사고방식 도입이 증가하면서 팀 간 커뮤니케이션 같은 핵심 지표의 만족도가 높아졌음을 보여준다. 실제 데브옵스 도입 후 가장 크게 개선된 부분을 묻는 질문에 커뮤니케이션을 꼽은 비율이 23-57%였다. 뉴 렐릭의 시장 전략:EMEA 책임자인 에버린 올리치는 “팀 간 효과적인 커뮤니케이션이 업무 관계와 더 창의적인 문화를 촉진한다. 이는 데브옵스 성공의 핵심 구현 요소들이다”고 강조했다.



사고방식의 변화
그러나 데브옵스를 올바르게 실천하기 쉽지 않다. 또한 애자일과 데브옵스는 배타적이지 않다. 서로 조화롭게 작동을 한다. 클라우드 파운드리 파운데이션(Cloud Foundry Foundation)의 CTO 칩 칠더스는 데브옵스는 돈을 주고 살 수 있는 것이 아니라고 강조한다. 그는 “데브옵스를 판매하려 시도하는 회사들이 많지만, 데브옵스는 도구나 제품이 아니다. 데브옵스는 문화적인 변화가 아주 중요하다. 문화적인 맥락에서 새로운 프로세스와 기존 시스템이 조화되도록 기술과 도구, 제품을 도입해야 한다”고 설명했다.

기트랩의 수장인 마크 푼드색은 문화가 데브옵스 성공을 가로막는 장애물이 될 수 있지만, 반드시 올바르게 구현해 실천하는 것이 중요하다고 강조했다. 그는 “개발(Dev)과 운영(Ops)이라는 기능이 서로 교차하면서 조화롭게 작동하도록 만들기 쉽지 않다. 여기에 더해 툴링(tooling)이 문제를 복잡하게 만들 수 있다. 흐트러진 툴체인은 프로세스를 단절시키고, 커뮤니케이션을 방해해 협력을 저해한다. 이것이 데브옵스의 ‘난제’이다”고 설명했다.

캡제미니(Capgemini) 산하 소게티(Sogeti)의 피터 베팅 데브옵스 커뮤니티 글로벌 리더 겸 VP는 전체 데브옵스 프로세스에 운영(Ops)이 중요하다고 강조했다. 이는 클라우드 환경에서의 배포와 유지관리에 초점이 맞춰지는 경우가 많다.

그는 “프로젝트를 시작할 때부터 운영 엔지니어들을 참여시켜 각 스프린트에서 개발된 제품을 올바르게 배포해야 한다. 생산화 단계에서 제품을 배포하는 경우 코드와 함께 필요한 사양(명세)과 자동화된 스크립트를 전달해야 한다. 이렇게 해야 적절히 유지관리를 하고, 해당 제품을 개선할 때 신속히 스프린트를 다시 시작할 수 있다”고 설명했다.

더 스케일 팩토리(The Scale Factory)의 존 토퍼는 데브옵스는 개발자와 운영 엔지니어가 서로 협력해 소프트웨어를 배포하는 업무 방식이라고 강조했다. 두 분야를 통합하려 시도할 때 직면하는 큰 도전과제 중 하나는 때론 다른 언어를 사용하고, 과거 상반되는 생각을 갖고 있었던 개발 및 운영 팀원들이 협력하도록 만드는 방법을 찾는 것이다. 그는 “데브옵스는 전개하는 것이 아니라 규정하는 것이다”고 말했다.

단계별 접근법
시그널Fx(SignalFx)의 앤디 호킨스 기술 운영 VP는 데브옵스 도입에는 3가지 핵심 단계가 있다고 언급했다. 첫 번째는 시험과 실험을 할 팀을 구성, 데브옵스 방법론과 프랙티스(실천 사례)를 시험 및 실험하는 단계이다. 그는 “또한 데이터와 매트릭스(지표)를 획득할 수 있어야 한다. 반드시 필요한 역량이지만, 이를 간과하는 경우가 많다. 측정과 평가를 해야 관리를 할 수 있다”고 설명했다.

두 번째는 더 광범위한 데브옵스 팀을 조직하는 것이다. 그는 “이들의 업무를 중앙에서 관리하지 않는 기업과 기관이 많은 것이 문제이다. 범위가 중요하다. 그런데 초기에 너무 복잡하게 제품을 선택하는 기업과 기관이 아주 많다. 너무 크지 않으면서 유의미한 것을 구현하려 시도해야 한다”고 말했다.

마지막으로 체계화된 구현 요소를 갖춰야 한다. 워크플로에 관리와 구현 요소가 통합되어 있어야 한다. 이 단계에서는 자동화와 테스트, 모니터링 등 기능과 역량을 도입하는 팀에 초점을 맞춰야 한다.

푼드색은 기업은 데브옵스 도입 시 개발과 운영만 생각해서는 안 된다고 덧붙였다. 제품 매니저, 비즈니스 부문 종사자, 보안 전문가 등 여러 분야의 사람들이 협력해야 우수한 소프트웨어를 전달할 수 있다. 좋은 데브옵스 문화는 이런 부서 간 협력을 가로막는 벽을 무너뜨린다.

푼드색은 데브옵스에 ‘쉬프트-레프트’를 적용해야 한다고 말했다. 도구나 지식을 개발 프로세스의 이전 단계로 옮기는 것을 의미한다. 그는 “예를 들어, 기능이 거의 완성되거나 (더 나쁜 경우)생산화 단계에 배포된 지 몇 주가 지난 후에야 보안 감사를 실시해서는 안 된다. 첫 코드 커밋 단계에서 자동으로 보안을 테스트해야 한다”고 설명했다.

푼드색은 데브옵스를 올바르게 실천하기 위해 가장 먼저 할 일은 개발과 QA, 보안, 운영 등 여러 기능을 교차해 수행하는 팀이 직면하는 문화적 도전과제를 파악해 극복하는 것이라고 덧붙였다. 그는 “목표와 성과 지표가 불일치하는 경우가 많다. 따라서 시작하기 전, 기능적인 사일로(단절 또는 고립)에서 자주 발견되는 최적화되지 못한 목표 대신 완전한 사이클 타임(데브옵스) 단축을 추구하도록 팀에 동기를 부여하고 있는지 여부를 물어야 한다”고 설명했다.

둘째, 도구와 툴체인을 자세히 파악해야 한다. 여러 ‘포인트’ 솔루션을 사용하고 있어, 통합 해야 하는 경우가 많다. 통합하지 않을 경우 마찰과 오버헤드가 초래된다. 푼드색은 “’규모의 경제’를 실현시키기 위해 소수 도구를 중심으로 단순화 및 표준화를 하는 것이 중요하다. 10개 도구를 5개, 5개 도구를 3개나 1개로 줄이면 팀의 효율성을 높일 수 있다”고 강조했다.

아리센트(Aricent)의 나빈 쿠마르 기술 혁신 VP는 데브옵스 도입을 원하는 기업이 고려해야 할 사항들을 소개했다.

• 책임: 일부 기업은 중앙화된 팀이 데브옵스를 책임지게 만든다. 시작 단계에서는 효과가 있을 수 있지만, 지속적으로 효과가 있지는 않다.

• 사일로(Silo): 데브옵스를 ‘사일로’화 해서는 안 된다. 확산 및 침투를 시켜야 한다. 그래야 전사적으로 개발 팀이 기본적으로 데브옵스를 도입해 활용할 수 있다. 데브옵스를 확대 전개하기 원할 경우 아주 중요한 부분이다.

• 품질: 품질 점검에 대한 일정을 수립하고, 이를 체계화시켜야 한다. 소프트웨어 릴리스 툴체인이 선언적이고 정책에 기반을 둘 수 있기 때문이다. 품질, 사용 코드가 적절한지 지속적으로 파악하는 것이 중요하다.

• 보안: 기반이 되는 데브옵스 도구와 상관없이 반복할 수 있도록 지속적으로 릴리스를 자동화할 수 있는지 테스트하고, 보안을 점검해야 한다.

• 투명성 미흡: 데브옵스를 배타적, 또는 독점적으로 취급하지 않아야 한다. 데브옵스 프로세스와 활동을 평가하고, 모든 이해 당사자에게 투명하게 공개한다.

• 문화: 반드시 필요한 새로운 것을 시도하는 경우, 시험과 실험을 용인하는 문화를 조성해야 한다. 이는 기존의 기준과 프로세스에 변화를 가져온다.



2018.07.10

“핵심은 문화” 데브옵스 도입 전략

Bianca Wright | IDG Connect

기트랩(GItLab)의 ‘2018 글로벌 개발자 보고서(Global Developer Report)’가 밝혀낸 중요한 사항 중 하나는 데브옵스(DevOps)를 도입한 조직들이 애자일(Agile)을 실천하기보다 수요에 따라 도입하고 자동화에 우선순위를 두는 경향이 있다는 것이다. 데브옵스는 개발자와 소프트웨어 담당자의 워크플로를 개선하는 데 도움을 주는 ‘나이스 투 해브(갖고 있으면 좋은 것)’에서 ‘머스트 해브(반드시 갖고 있어야 하는 것)’가 되고 있다. 기트랩(GitLab)이 5,200명이 넘는 개발자, CTO, IT종사자를 설문 조사한 결과에 따르면, 데브옵스가 개발 프로세스의 시간을 많이 절약해준다고 대답한 비율이 2/3에 달한다. 또한 약 30%는 올 한 해 데브옵스에 투자할 계획이 있다고 답했다.

뉴 렐릭(New Relic)이 지난 해 실시한 조사는 데브옵스 사고방식 도입이 증가하면서 팀 간 커뮤니케이션 같은 핵심 지표의 만족도가 높아졌음을 보여준다. 실제 데브옵스 도입 후 가장 크게 개선된 부분을 묻는 질문에 커뮤니케이션을 꼽은 비율이 23-57%였다. 뉴 렐릭의 시장 전략:EMEA 책임자인 에버린 올리치는 “팀 간 효과적인 커뮤니케이션이 업무 관계와 더 창의적인 문화를 촉진한다. 이는 데브옵스 성공의 핵심 구현 요소들이다”고 강조했다.



사고방식의 변화
그러나 데브옵스를 올바르게 실천하기 쉽지 않다. 또한 애자일과 데브옵스는 배타적이지 않다. 서로 조화롭게 작동을 한다. 클라우드 파운드리 파운데이션(Cloud Foundry Foundation)의 CTO 칩 칠더스는 데브옵스는 돈을 주고 살 수 있는 것이 아니라고 강조한다. 그는 “데브옵스를 판매하려 시도하는 회사들이 많지만, 데브옵스는 도구나 제품이 아니다. 데브옵스는 문화적인 변화가 아주 중요하다. 문화적인 맥락에서 새로운 프로세스와 기존 시스템이 조화되도록 기술과 도구, 제품을 도입해야 한다”고 설명했다.

기트랩의 수장인 마크 푼드색은 문화가 데브옵스 성공을 가로막는 장애물이 될 수 있지만, 반드시 올바르게 구현해 실천하는 것이 중요하다고 강조했다. 그는 “개발(Dev)과 운영(Ops)이라는 기능이 서로 교차하면서 조화롭게 작동하도록 만들기 쉽지 않다. 여기에 더해 툴링(tooling)이 문제를 복잡하게 만들 수 있다. 흐트러진 툴체인은 프로세스를 단절시키고, 커뮤니케이션을 방해해 협력을 저해한다. 이것이 데브옵스의 ‘난제’이다”고 설명했다.

캡제미니(Capgemini) 산하 소게티(Sogeti)의 피터 베팅 데브옵스 커뮤니티 글로벌 리더 겸 VP는 전체 데브옵스 프로세스에 운영(Ops)이 중요하다고 강조했다. 이는 클라우드 환경에서의 배포와 유지관리에 초점이 맞춰지는 경우가 많다.

그는 “프로젝트를 시작할 때부터 운영 엔지니어들을 참여시켜 각 스프린트에서 개발된 제품을 올바르게 배포해야 한다. 생산화 단계에서 제품을 배포하는 경우 코드와 함께 필요한 사양(명세)과 자동화된 스크립트를 전달해야 한다. 이렇게 해야 적절히 유지관리를 하고, 해당 제품을 개선할 때 신속히 스프린트를 다시 시작할 수 있다”고 설명했다.

더 스케일 팩토리(The Scale Factory)의 존 토퍼는 데브옵스는 개발자와 운영 엔지니어가 서로 협력해 소프트웨어를 배포하는 업무 방식이라고 강조했다. 두 분야를 통합하려 시도할 때 직면하는 큰 도전과제 중 하나는 때론 다른 언어를 사용하고, 과거 상반되는 생각을 갖고 있었던 개발 및 운영 팀원들이 협력하도록 만드는 방법을 찾는 것이다. 그는 “데브옵스는 전개하는 것이 아니라 규정하는 것이다”고 말했다.

단계별 접근법
시그널Fx(SignalFx)의 앤디 호킨스 기술 운영 VP는 데브옵스 도입에는 3가지 핵심 단계가 있다고 언급했다. 첫 번째는 시험과 실험을 할 팀을 구성, 데브옵스 방법론과 프랙티스(실천 사례)를 시험 및 실험하는 단계이다. 그는 “또한 데이터와 매트릭스(지표)를 획득할 수 있어야 한다. 반드시 필요한 역량이지만, 이를 간과하는 경우가 많다. 측정과 평가를 해야 관리를 할 수 있다”고 설명했다.

두 번째는 더 광범위한 데브옵스 팀을 조직하는 것이다. 그는 “이들의 업무를 중앙에서 관리하지 않는 기업과 기관이 많은 것이 문제이다. 범위가 중요하다. 그런데 초기에 너무 복잡하게 제품을 선택하는 기업과 기관이 아주 많다. 너무 크지 않으면서 유의미한 것을 구현하려 시도해야 한다”고 말했다.

마지막으로 체계화된 구현 요소를 갖춰야 한다. 워크플로에 관리와 구현 요소가 통합되어 있어야 한다. 이 단계에서는 자동화와 테스트, 모니터링 등 기능과 역량을 도입하는 팀에 초점을 맞춰야 한다.

푼드색은 기업은 데브옵스 도입 시 개발과 운영만 생각해서는 안 된다고 덧붙였다. 제품 매니저, 비즈니스 부문 종사자, 보안 전문가 등 여러 분야의 사람들이 협력해야 우수한 소프트웨어를 전달할 수 있다. 좋은 데브옵스 문화는 이런 부서 간 협력을 가로막는 벽을 무너뜨린다.

푼드색은 데브옵스에 ‘쉬프트-레프트’를 적용해야 한다고 말했다. 도구나 지식을 개발 프로세스의 이전 단계로 옮기는 것을 의미한다. 그는 “예를 들어, 기능이 거의 완성되거나 (더 나쁜 경우)생산화 단계에 배포된 지 몇 주가 지난 후에야 보안 감사를 실시해서는 안 된다. 첫 코드 커밋 단계에서 자동으로 보안을 테스트해야 한다”고 설명했다.

푼드색은 데브옵스를 올바르게 실천하기 위해 가장 먼저 할 일은 개발과 QA, 보안, 운영 등 여러 기능을 교차해 수행하는 팀이 직면하는 문화적 도전과제를 파악해 극복하는 것이라고 덧붙였다. 그는 “목표와 성과 지표가 불일치하는 경우가 많다. 따라서 시작하기 전, 기능적인 사일로(단절 또는 고립)에서 자주 발견되는 최적화되지 못한 목표 대신 완전한 사이클 타임(데브옵스) 단축을 추구하도록 팀에 동기를 부여하고 있는지 여부를 물어야 한다”고 설명했다.

둘째, 도구와 툴체인을 자세히 파악해야 한다. 여러 ‘포인트’ 솔루션을 사용하고 있어, 통합 해야 하는 경우가 많다. 통합하지 않을 경우 마찰과 오버헤드가 초래된다. 푼드색은 “’규모의 경제’를 실현시키기 위해 소수 도구를 중심으로 단순화 및 표준화를 하는 것이 중요하다. 10개 도구를 5개, 5개 도구를 3개나 1개로 줄이면 팀의 효율성을 높일 수 있다”고 강조했다.

아리센트(Aricent)의 나빈 쿠마르 기술 혁신 VP는 데브옵스 도입을 원하는 기업이 고려해야 할 사항들을 소개했다.

• 책임: 일부 기업은 중앙화된 팀이 데브옵스를 책임지게 만든다. 시작 단계에서는 효과가 있을 수 있지만, 지속적으로 효과가 있지는 않다.

• 사일로(Silo): 데브옵스를 ‘사일로’화 해서는 안 된다. 확산 및 침투를 시켜야 한다. 그래야 전사적으로 개발 팀이 기본적으로 데브옵스를 도입해 활용할 수 있다. 데브옵스를 확대 전개하기 원할 경우 아주 중요한 부분이다.

• 품질: 품질 점검에 대한 일정을 수립하고, 이를 체계화시켜야 한다. 소프트웨어 릴리스 툴체인이 선언적이고 정책에 기반을 둘 수 있기 때문이다. 품질, 사용 코드가 적절한지 지속적으로 파악하는 것이 중요하다.

• 보안: 기반이 되는 데브옵스 도구와 상관없이 반복할 수 있도록 지속적으로 릴리스를 자동화할 수 있는지 테스트하고, 보안을 점검해야 한다.

• 투명성 미흡: 데브옵스를 배타적, 또는 독점적으로 취급하지 않아야 한다. 데브옵스 프로세스와 활동을 평가하고, 모든 이해 당사자에게 투명하게 공개한다.

• 문화: 반드시 필요한 새로운 것을 시도하는 경우, 시험과 실험을 용인하는 문화를 조성해야 한다. 이는 기존의 기준과 프로세스에 변화를 가져온다.



X