2020.10.16

기고 | '시킨다고 되는 게 아냐' 개발·운영 민첩성, 어떻게 달성할 것인가?

Isaac Sacolick | InfoWorld
기업 경영진이 조직에 민첩성이 필요하다고 이야기하지만, 민첩성을 강요하고 지시할 수는 없는 법이다. CIO와 IT 경영진이 애자일 방법론 표준이라고 말하는 활동, 지표 및 책임은 표준화할 수는 있지만, 모든 구성원이 애자일 문화와 마음가짐을 갖도록 강요할 수는 없다.

애자일 도구를 선택하고 데브옵스 활동을 통해 더 많은 것을 자동화하고 시민이 참여하는 데이터 과학 프로그램을 활성화할 수 있지만, 도입을 강제하고 직원 만족도를 요구할 수는 없다. IT 운영 활동에서 하이브리드 멀티클라우드 아키텍처를 운영할 수는 있지만 그렇다고 해서 비용이 최적화되거나 인프라가 마법처럼 자동으로 확장 및 축소되는 것은 아니다.

따라서 애자일 프로세스를 신속하게 표준화하거나 애자일 아키텍처로 전환하여 기적처럼 기술 부채를 해결하고, 즉흥적으로 애자일 작업 방식으로 전환하려 했다면 안타깝게도 실망스러울 것이다. 민첩성은 무료도 아니고, 저렴하지도 쉽지도 않다. 간트 차트의 민첩성은 고정된 기간이나 계획으로 관리할 수 있는 것이 아니다.

필자는 민첩성이 주로 상향식 혁신이라 생각하지만 그렇다고 해서 개발자, 엔지니어, 테스트 담당자, 스크럼 마스터 및 기타 IT 부서원이 각기 독립적으로 민첩성을 유도할 수 있는 것은 아니다. 전체로서의 부서는 협업하고 타협을 인정하며 이득에 대한 동의가 있는 애자일 운영 원칙을 정의해야 한다.

민첩성은 지시할 수도 없고 모든 구성원의 기여해야 하는 것이라면, 조직은 어떻게 민첩해질 수 있을까? 애자일 방법론, 데이터 중심적인 활동 및 데브옵스 문화 도입 정신 측면에서 IT 조직의 모두가 협업하여 민첩성을 유도할 수 있는 방법을 살펴보자.
 
ⓒ Getty Images Bank
 

애자일 방법론 사례를 만들라 

필자의 저서 ‘디지털 유도하기(Driving Digital)’ 2장의 핵심은 기본적인 스크럼 활동에서 역할 및 책임 할당, 멀티 스프린트 백로그 계획 및 예측 활동 표준화 등 더욱 포괄적인 애자일 계획 프로세스로 전환하는 것이다. 부서와 협력하면서 애자일 마음가짐과 문화를 도입할 때 릴리즈 관리 규율, 아키텍처 표준, 애자일 원칙 및 기타 민첩성 유도 지침을 도입하려 노력해야 한다.

하지만 이것이 지시에 의해 이루어지지는 않는다. 조직이 다르면 비즈니스 전략, 조직 문화, 인재, 준수성 요건 및 구형 및 현대화된 아키텍처의 혼재 수준이 다르다. 다양한 애자일 활동을 적용할 시기와 장소를 고려하면 이런 맥락은 놀라울 정도로 중요하다.

예를 들어, 경영진이 신속하게 개발하고 직원들에게 배포하고 싶어하는 모바일 애플리케이션용 API를 개발하고 있는 부서가 있다고 치자. 중앙의 복잡한 구형 시스템을 규제되고 감사되는 글로벌 비즈니스 활동으로 이전하는 업무를 담당하는 부서도 있다고 가정하자.

이 두 부서가 지시된 엄격한 애자일 활동을 똑같이 따라야 할까? 그렇게 되면 분명 더욱 민주적인 애자일 방식이 도입되고, 자기 조직적인 것을 선호하고(동시에 더 우수할 가능성이 있는) API 부서는 제약을 받을 것이고, 부서가 많은 의사결정을 하게 될 것이다. 반대로 복잡하고 업무 필수적인 구형 시스템을 개발하는 부서에 너무 많은 자유를 주면 위험이 커진다.

목표와 제약의 이질성 때문에 민첩성을 추구하는 조직은 애자일 원칙을 정의할 때 ‘이유’를 묻고 답하는 문화를 육성해야 한다. 경영진이 이유를 설명하지 않고 방법만 지시한다면 직원이 기초가 되는 활동을 도입할 가능성이 낮아진다. 애자일 원칙(특히, 이유)에 관해 설명하면 부서가 애자일 활동을 적용할 시기, 장소 및 방법을 더욱 잘 결정하는 데 도움이 된다.
 

데이터옵스와 데이터 거버넌스로 머신러닝을 가속화하라

필자는 스파이더맨에 나온 유명한 대사 “큰 힘에는 큰 책임이 뒤따른다”를 좋아한다. 모든 조직은 데이터 사이언티스트, 데이터 시각화 마법사 및 시민 데이터 분석가가 의사결정을 지원하는 지속적인 통찰을 생성해내기를 바란다. 하지만 이런 힘을 위해서는 데이터, 분석 및 머신러닝부서가 선제적인 데이터 거버넌스와 조직의 데이터 품질, 보안, 프라이버시, 마스터 데이터 관리 및 데이터 통합 요건을 해결하는 데이터옵스 활동을 도입해야 한다. 

따라서 분석부서가 민첩성을 높이고 결과를 빈번하게 제공하며 분석에 사용되는 데이터 세트의 수를 늘리기 위해 노력하는 동안 데이터부서는 준수성 요건과 높아지는 비즈니스 기대치에 따라 근본적인 데이터 처리 기초를 강화해야 한다.

이런 민첩성은 공짜로 또는 지시를 통해 얻어지지 않는다. 데이터 및 분석 프로세스는 종합적인 부서들이 민첩성의 중요성을 인식하고 협업하여 분석 제공 및 데이터 처리 기초를 개선할 때 발전한다. 몇 가지 예를 들어보자.

• 시민 데이터 사이언스 프로그램은 참여 부서가 새로운 데이터 시각화를 배포하기 전에 데이터 카탈로그와 정의를 정의하고 유지관리해야 한다.
• 데이터 사이언스부서는 머신러닝 모델을 문서화하고 추이 파라미터를 정의하며 정의된 라이프 사이클에 기초하여 생산 모델을 유지관리 한다.
• 데이터 통합 및 품질부서는 분석부서를 고객 또는 이해관계자로 본다. 그들은 분석부서가 수행하는 데이터 논쟁을 정기적으로 검토하고 데이터 모델과 통합을 평가 및 조정하여 다운스트림 데이터 처리를 줄인다.
• 데이터 처리 허가를 받은 모든 부서는 데이터 보안, 준수성 및 프라이버시 요건의 변경사항을 정기적으로 검토한다. 그들은 보안, 데이터 또는 기술 부채 등의 공백을 포착하고 교정 작업들에 우선순위를 할당한다.
• 데이터옵스 및 클라우드 운영부서는 모니터링, 용량 계획 및 인프라 자동화 수준을 높여 증가하는 데이터 처리 및 분석부서의 성과 요건을 충족한다.

민첩성은 협업 및 원하는 작업과 필요한 작업 사이의 균형 조정을 통해 달성된다. 그렇지 않으면 이 새로운 세대의 빅데이터, 머신러닝 및 셀프서비스 BI 프로그램은 순식간에 새로운 데이터 부채, 데이터 사일로 및 데이터 보안 위험의 산을 형성하게 된다.  
 

데브옵스 성숙 단계에서 고객 입장을 적용하라

데브옵스 문화와 활동을 도입하는 조직은 오래된 IT 역설을 해결하기 위해 노력하고 있다. 애자일부서가 꾸준히 지속적으로 안전한 변경사항을 프로덕션에 적용하고, 신뢰성, 보안, 성능, 기타 운영 서비스 수준을 타협하지 않으면서 동시에 사용자를 만족시키고 비즈니스까지 개선할 수 있는 방법은 무엇일까?
 
데브옵스 활동과 도구는 주요 사건, 기저 원인 분석이 필요한 복잡한 문제, 배포를 지연시키는 엄청난 인프라 의존성 및 만성적인 보안 문제로 이어지는 IT 변화 관리 프로세스의 공백을 해결한다. 성공적인 데브옵스의 예시는 다음과 같다.

• 사설 및 공공 클라우드를 사용하는 조직은 환경 배포 및 해체를 안전한 코드형 인프라를 사용하여 자동화한다.
• 애자일 개발부서는 시프트레프트 CI/CD 파이프라인을 통해 테스트를 자동화하고 빌드와 배포를 간소화한다. 더욱 발전된 부서는 파이프라인에 보안 검증을 포함시키고 데브섹옵스를 도입한다.
• IT 운영 활동은 가시성 및 사건 대응을 개선하기 위해 AIOps 플랫폼 모니터링과 배포를 강화하여 복잡한 서버리스 배포, 마이크로서비스 아키텍처 및 하이브리드 멀티클라우드 네트워크 관리 능력을 향상시킨다.

모두 IT의 애자일 및 운영 역설을 해결하기 위한 전력적인 요소지만, 그렇다고 이런 프로그램에 전략 없이 뛰어들면 비즈니스 가치가 없는 IT 성과로 이어질 수 있다. 게다가 때로는 이로 인해 IT가 비즈니스 우선순위 충족을 위해 자동화에 과도하게 투자할 수 있다.

예를 들어, 레거시 3티어 애플리케이션을 공공 클라우드로 이전하면서 현대화하고 이행할 자동화 수준을 결정해야 할 때가 있다. 무엇이 적절한지 어떻게 정의할 수 있을까? 그리고 데브옵스 관련 개선사항의 기준을 어떻게 정의해야 할까?

이 질문에 답하는 데 도움이 되는 질문과 파라미터는 서비스 레벨 요건일 수도 있고 비 기능적 요건일 수도 있다. 경우에 따라 참여도가 높은 이해관계자들은 매일 릴리즈와 99.999%의 신뢰성을 요구할 것이다. 또한 요건 정의를 위해 필요한 이해관계자 참여를 달성하기가 더 어려운 경우도 있을 것이다.

두 시나리오 모두 문제가 발생하지만 민첩성을 위해 필요한 공통 분모는 고객, 고객 성향 및 성공 기준을 정의함으로써 시작된다. 지시가 과도한 이해관계자가 있는 경우 요청하는 요건을 비즈니스적으로 합리적인 요건과 구분하는 것이 중요하다. 그리고 요구사항이 제대로 정의되지 않으면 성공의 기준을 문서화하는 것이 특히 중요하다.

많은 조직이 목표하는 성향, 성공 기준 및 비즈니스 요건을 포착하고 공유하기 위해 제품 관리 또는 비즈니스 관계의 관리 책임을 정의한다. 이러한 고객 마음가짐을 데브옵스부서와 활동에 연계시키는 것이 조직이 투자할 자동화와 그 수준을 결정하는 데 도움이 되는 모범 사례이다.

요약하자면, 민첩성은 지시할 수 없다. 민첩성은 리더와 기여자들 사이의 협업을 통해서만 달성된다. 애자일 부서는 자기 조직 원칙과 기준에 따라 운영해야 한다. 비즈니스에 요구되는 개선사항 제공과 데이터, 운영 및 기술 부채 해결을 위해 필요한 작업 사이의 균형을 맞춰야 한다. 우선순위 설정, 성공 기준 정의 및 최소한으로 실행 가능한 것을 결정하려면 고객 성향을 정의하고 그 요구사항과 가치를 파악해야 한다.

조직이 이런 유형의 활동을 도입할 때는 민첩성을 요구할 필요가 없다. 민첩성은 공유 가치이자 업무 처리를 위한 표준 접근방식이 될 것이기 때문이다. editor@itworld.co.kr 



2020.10.16

기고 | '시킨다고 되는 게 아냐' 개발·운영 민첩성, 어떻게 달성할 것인가?

Isaac Sacolick | InfoWorld
기업 경영진이 조직에 민첩성이 필요하다고 이야기하지만, 민첩성을 강요하고 지시할 수는 없는 법이다. CIO와 IT 경영진이 애자일 방법론 표준이라고 말하는 활동, 지표 및 책임은 표준화할 수는 있지만, 모든 구성원이 애자일 문화와 마음가짐을 갖도록 강요할 수는 없다.

애자일 도구를 선택하고 데브옵스 활동을 통해 더 많은 것을 자동화하고 시민이 참여하는 데이터 과학 프로그램을 활성화할 수 있지만, 도입을 강제하고 직원 만족도를 요구할 수는 없다. IT 운영 활동에서 하이브리드 멀티클라우드 아키텍처를 운영할 수는 있지만 그렇다고 해서 비용이 최적화되거나 인프라가 마법처럼 자동으로 확장 및 축소되는 것은 아니다.

따라서 애자일 프로세스를 신속하게 표준화하거나 애자일 아키텍처로 전환하여 기적처럼 기술 부채를 해결하고, 즉흥적으로 애자일 작업 방식으로 전환하려 했다면 안타깝게도 실망스러울 것이다. 민첩성은 무료도 아니고, 저렴하지도 쉽지도 않다. 간트 차트의 민첩성은 고정된 기간이나 계획으로 관리할 수 있는 것이 아니다.

필자는 민첩성이 주로 상향식 혁신이라 생각하지만 그렇다고 해서 개발자, 엔지니어, 테스트 담당자, 스크럼 마스터 및 기타 IT 부서원이 각기 독립적으로 민첩성을 유도할 수 있는 것은 아니다. 전체로서의 부서는 협업하고 타협을 인정하며 이득에 대한 동의가 있는 애자일 운영 원칙을 정의해야 한다.

민첩성은 지시할 수도 없고 모든 구성원의 기여해야 하는 것이라면, 조직은 어떻게 민첩해질 수 있을까? 애자일 방법론, 데이터 중심적인 활동 및 데브옵스 문화 도입 정신 측면에서 IT 조직의 모두가 협업하여 민첩성을 유도할 수 있는 방법을 살펴보자.
 
ⓒ Getty Images Bank
 

애자일 방법론 사례를 만들라 

필자의 저서 ‘디지털 유도하기(Driving Digital)’ 2장의 핵심은 기본적인 스크럼 활동에서 역할 및 책임 할당, 멀티 스프린트 백로그 계획 및 예측 활동 표준화 등 더욱 포괄적인 애자일 계획 프로세스로 전환하는 것이다. 부서와 협력하면서 애자일 마음가짐과 문화를 도입할 때 릴리즈 관리 규율, 아키텍처 표준, 애자일 원칙 및 기타 민첩성 유도 지침을 도입하려 노력해야 한다.

하지만 이것이 지시에 의해 이루어지지는 않는다. 조직이 다르면 비즈니스 전략, 조직 문화, 인재, 준수성 요건 및 구형 및 현대화된 아키텍처의 혼재 수준이 다르다. 다양한 애자일 활동을 적용할 시기와 장소를 고려하면 이런 맥락은 놀라울 정도로 중요하다.

예를 들어, 경영진이 신속하게 개발하고 직원들에게 배포하고 싶어하는 모바일 애플리케이션용 API를 개발하고 있는 부서가 있다고 치자. 중앙의 복잡한 구형 시스템을 규제되고 감사되는 글로벌 비즈니스 활동으로 이전하는 업무를 담당하는 부서도 있다고 가정하자.

이 두 부서가 지시된 엄격한 애자일 활동을 똑같이 따라야 할까? 그렇게 되면 분명 더욱 민주적인 애자일 방식이 도입되고, 자기 조직적인 것을 선호하고(동시에 더 우수할 가능성이 있는) API 부서는 제약을 받을 것이고, 부서가 많은 의사결정을 하게 될 것이다. 반대로 복잡하고 업무 필수적인 구형 시스템을 개발하는 부서에 너무 많은 자유를 주면 위험이 커진다.

목표와 제약의 이질성 때문에 민첩성을 추구하는 조직은 애자일 원칙을 정의할 때 ‘이유’를 묻고 답하는 문화를 육성해야 한다. 경영진이 이유를 설명하지 않고 방법만 지시한다면 직원이 기초가 되는 활동을 도입할 가능성이 낮아진다. 애자일 원칙(특히, 이유)에 관해 설명하면 부서가 애자일 활동을 적용할 시기, 장소 및 방법을 더욱 잘 결정하는 데 도움이 된다.
 

데이터옵스와 데이터 거버넌스로 머신러닝을 가속화하라

필자는 스파이더맨에 나온 유명한 대사 “큰 힘에는 큰 책임이 뒤따른다”를 좋아한다. 모든 조직은 데이터 사이언티스트, 데이터 시각화 마법사 및 시민 데이터 분석가가 의사결정을 지원하는 지속적인 통찰을 생성해내기를 바란다. 하지만 이런 힘을 위해서는 데이터, 분석 및 머신러닝부서가 선제적인 데이터 거버넌스와 조직의 데이터 품질, 보안, 프라이버시, 마스터 데이터 관리 및 데이터 통합 요건을 해결하는 데이터옵스 활동을 도입해야 한다. 

따라서 분석부서가 민첩성을 높이고 결과를 빈번하게 제공하며 분석에 사용되는 데이터 세트의 수를 늘리기 위해 노력하는 동안 데이터부서는 준수성 요건과 높아지는 비즈니스 기대치에 따라 근본적인 데이터 처리 기초를 강화해야 한다.

이런 민첩성은 공짜로 또는 지시를 통해 얻어지지 않는다. 데이터 및 분석 프로세스는 종합적인 부서들이 민첩성의 중요성을 인식하고 협업하여 분석 제공 및 데이터 처리 기초를 개선할 때 발전한다. 몇 가지 예를 들어보자.

• 시민 데이터 사이언스 프로그램은 참여 부서가 새로운 데이터 시각화를 배포하기 전에 데이터 카탈로그와 정의를 정의하고 유지관리해야 한다.
• 데이터 사이언스부서는 머신러닝 모델을 문서화하고 추이 파라미터를 정의하며 정의된 라이프 사이클에 기초하여 생산 모델을 유지관리 한다.
• 데이터 통합 및 품질부서는 분석부서를 고객 또는 이해관계자로 본다. 그들은 분석부서가 수행하는 데이터 논쟁을 정기적으로 검토하고 데이터 모델과 통합을 평가 및 조정하여 다운스트림 데이터 처리를 줄인다.
• 데이터 처리 허가를 받은 모든 부서는 데이터 보안, 준수성 및 프라이버시 요건의 변경사항을 정기적으로 검토한다. 그들은 보안, 데이터 또는 기술 부채 등의 공백을 포착하고 교정 작업들에 우선순위를 할당한다.
• 데이터옵스 및 클라우드 운영부서는 모니터링, 용량 계획 및 인프라 자동화 수준을 높여 증가하는 데이터 처리 및 분석부서의 성과 요건을 충족한다.

민첩성은 협업 및 원하는 작업과 필요한 작업 사이의 균형 조정을 통해 달성된다. 그렇지 않으면 이 새로운 세대의 빅데이터, 머신러닝 및 셀프서비스 BI 프로그램은 순식간에 새로운 데이터 부채, 데이터 사일로 및 데이터 보안 위험의 산을 형성하게 된다.  
 

데브옵스 성숙 단계에서 고객 입장을 적용하라

데브옵스 문화와 활동을 도입하는 조직은 오래된 IT 역설을 해결하기 위해 노력하고 있다. 애자일부서가 꾸준히 지속적으로 안전한 변경사항을 프로덕션에 적용하고, 신뢰성, 보안, 성능, 기타 운영 서비스 수준을 타협하지 않으면서 동시에 사용자를 만족시키고 비즈니스까지 개선할 수 있는 방법은 무엇일까?
 
데브옵스 활동과 도구는 주요 사건, 기저 원인 분석이 필요한 복잡한 문제, 배포를 지연시키는 엄청난 인프라 의존성 및 만성적인 보안 문제로 이어지는 IT 변화 관리 프로세스의 공백을 해결한다. 성공적인 데브옵스의 예시는 다음과 같다.

• 사설 및 공공 클라우드를 사용하는 조직은 환경 배포 및 해체를 안전한 코드형 인프라를 사용하여 자동화한다.
• 애자일 개발부서는 시프트레프트 CI/CD 파이프라인을 통해 테스트를 자동화하고 빌드와 배포를 간소화한다. 더욱 발전된 부서는 파이프라인에 보안 검증을 포함시키고 데브섹옵스를 도입한다.
• IT 운영 활동은 가시성 및 사건 대응을 개선하기 위해 AIOps 플랫폼 모니터링과 배포를 강화하여 복잡한 서버리스 배포, 마이크로서비스 아키텍처 및 하이브리드 멀티클라우드 네트워크 관리 능력을 향상시킨다.

모두 IT의 애자일 및 운영 역설을 해결하기 위한 전력적인 요소지만, 그렇다고 이런 프로그램에 전략 없이 뛰어들면 비즈니스 가치가 없는 IT 성과로 이어질 수 있다. 게다가 때로는 이로 인해 IT가 비즈니스 우선순위 충족을 위해 자동화에 과도하게 투자할 수 있다.

예를 들어, 레거시 3티어 애플리케이션을 공공 클라우드로 이전하면서 현대화하고 이행할 자동화 수준을 결정해야 할 때가 있다. 무엇이 적절한지 어떻게 정의할 수 있을까? 그리고 데브옵스 관련 개선사항의 기준을 어떻게 정의해야 할까?

이 질문에 답하는 데 도움이 되는 질문과 파라미터는 서비스 레벨 요건일 수도 있고 비 기능적 요건일 수도 있다. 경우에 따라 참여도가 높은 이해관계자들은 매일 릴리즈와 99.999%의 신뢰성을 요구할 것이다. 또한 요건 정의를 위해 필요한 이해관계자 참여를 달성하기가 더 어려운 경우도 있을 것이다.

두 시나리오 모두 문제가 발생하지만 민첩성을 위해 필요한 공통 분모는 고객, 고객 성향 및 성공 기준을 정의함으로써 시작된다. 지시가 과도한 이해관계자가 있는 경우 요청하는 요건을 비즈니스적으로 합리적인 요건과 구분하는 것이 중요하다. 그리고 요구사항이 제대로 정의되지 않으면 성공의 기준을 문서화하는 것이 특히 중요하다.

많은 조직이 목표하는 성향, 성공 기준 및 비즈니스 요건을 포착하고 공유하기 위해 제품 관리 또는 비즈니스 관계의 관리 책임을 정의한다. 이러한 고객 마음가짐을 데브옵스부서와 활동에 연계시키는 것이 조직이 투자할 자동화와 그 수준을 결정하는 데 도움이 되는 모범 사례이다.

요약하자면, 민첩성은 지시할 수 없다. 민첩성은 리더와 기여자들 사이의 협업을 통해서만 달성된다. 애자일 부서는 자기 조직 원칙과 기준에 따라 운영해야 한다. 비즈니스에 요구되는 개선사항 제공과 데이터, 운영 및 기술 부채 해결을 위해 필요한 작업 사이의 균형을 맞춰야 한다. 우선순위 설정, 성공 기준 정의 및 최소한으로 실행 가능한 것을 결정하려면 고객 성향을 정의하고 그 요구사항과 가치를 파악해야 한다.

조직이 이런 유형의 활동을 도입할 때는 민첩성을 요구할 필요가 없다. 민첩성은 공유 가치이자 업무 처리를 위한 표준 접근방식이 될 것이기 때문이다. editor@itworld.co.kr 

X