2016.12.01

진정한 데브옵스 조직의 구별하는 3가지 기준

Don Jones | InfoWorld
요즘은 너도나도 "데브옵스"를 외쳐댄다. 이제 고집을 꺾고 슬슬 데브옵스라는 트렌드를 도입해야 하나 생각이 들기도 하지만, 문제는 물건을 구입하듯 간단한 일이 아니라는 점이다.

물론 데브옵스 조직을 원활하게 운영하는 데 도움이 되는 여러 가지 도구가 있지만, 데브옵스의 중심은 그 원칙을 실행하는 팀이다. 데브옵스를 실행한다는 것은 팀 조직, 책임, 기대 측면에서 새롭고 때로는 살 떨리는 전략을 수용하는 것을 의미한다. 올바른 방향을 향한 데브옵스 팀을 알아보기 위한 세 가지 신호를 알아보자.

1. 팀의 기반은 제품이어야
진정한 데브옵스 조직은 일반적으로 그 팀이 제공하는 제품을 중심으로 IT 팀을 조직한다. 이는 많은 사람들이 수십 년 동안 고수해온 방법, 즉 사일로식 접근법을 버린다는 것을 의미한다. 데브옵스 스타일의 제품 팀에는 제품 관리자, 개발자, 인프라 전문가, 시스템 관리자, 그리고 그 제품의 실제 생산에 필요한 기타 모든 인력이 포함된다.

물론 모든 프로젝트마다 전담 전문가가 필요하다는 뜻은 아니다. 한 명의 네트워크 인프라 전문가가 조직의 우선 순위에 따라 시간을 분배해가며 여러 제품 기반 팀에서 일하는 것은 흔한 일이다.

또한, 분야별 조직에는 풍부한 가치가 있다. 모든 운영자가 모든 현황에 대해 전체적인 시각을 유지하면 원활한 운영이 보장되고, 모든 개발자가 자주 "모이면" 새로운 기술과 습득한 교훈, 기타 유용한 정보를 보다 쉽게 공유할 수 있다. 각 분야의 구성원이 종종 모여서 대화하고 정보를 나누는 교차 상품(cross-product) 조합에서 이러한 형태를 볼 수 있다.

2. 실패해도 우아하게
진정한 데브옵스 팀은 실패를 방지하기 위해 변화 속도를 늦추는 방법을 사용하지 않는다. 대신 빠르게 움직인다. 실패에서 신속하게 회복할 수 있는 팀의 역량을 신뢰하기 때문이다. 소규모의 통제된 스프린트에 상품을 배치하면 변수는 항상 최소화되고, 따라서 팀은 위험을 완화하고 빠른 회복을 촉진할 수 있게 된다.

데브옵스 팀은 실패를 큰 배움의 경험으로 기꺼이 받아들인다. 자동화된 딜리버리 파이프라인과 자동 단위 테스트를 통해 각각의 실패는 빌드 프로세스에 흡수되는 또 다른 테스트로 활용된다. 데브옵스는 규격화된 지식과 경험에 의존해 향후 동일한 실패를 방지하기보다는, 모든 것을 프로세스로 코드화함으로써 실패 반복을 자동으로 차단한다.

데브옵스 팀 역시 사전 예방적인 측면에서 최대한 실패를 예견하고 방지하기 위해 노력하지만, 종종 일어나는 사고를 부끄럽게 생각하지는 않는다. 문화적 측면에서 이는 조직이 실패에 대해 성숙한 태도를 도입하고, "탓하기 문화"를 없애며 예측, 학습, 방지를 프로세스의 근본적인 요소로 두고 여기에 초점을 맞춰야 함을 의미한다.

3. 강박적 자동화
진정한 데브옵스 팀은 인간의 실수가 모든 프로세스에서 가장 큰 실패 지점이며 빠른 이동을 방해하는 가장 큰 병목 지점이라는 사실을 안다. 이러한 팀은 실패하지 않는 일관성과 놀라운 속도를 제공하는 자동화에 집착한다. 코드 체크인 규칙 및 분석부터 테스트 환경 가동, 실제 단위 테스트와 최종 프로덕션 배치에 이르기까지, 데브옵스 팀은 자동화가 바로 정답이라는 것을 안다.

그러나 진정으로 효과적인 데브옵스 팀은 어느 한 가지 자동화 도구나 기술에 집착하지 않는다. 이들은 그 작업에 맞는 도구를 찾는 데 집중하며, 비즈니스 목표에 더 매끄럽게 다가갈 수 있는 길만 제공한다면 기꺼이 도구를 바꾼다. 요즘은 보통 데브옵스 팀을 설명할 때 "이종(heterogeneous)"이라는 단어가 사용된다. 특정 플랫폼이나 접근 방법에 깊숙이 전념하는 레거시 조직에게는 넘어야 할 큰 장벽이 될 수 있다.

효과적인 데브옵스 팀은 IT의 핵심이 사용자에게 애플리케이션과 서비스를 제공하는 데 있으며(기능만이 아니라 사용자 경험을 제공하는 것), 그 사이의 모든 것은 잠재적인 속도 저하 요인이라는 점을 안다. 이들은 데브옵스의 역할이 개발자의 키보드에서 출발해 상품 배치에 이르는 가장 매끄럽고 안전하고 빠르고 안정적인 길을 제공하는 것임을 알고, 따라서 새로운 각 코딩 스프린트가 테스트를 거친 프로덕션 배치로 신속하게 이어질 수 있다.

데브옵스는 "노옵스(no-ops)"가 아니다. 최대한 많은 '옵스'를 자동화하기 위한 강박적인 노력이다.

데브옵스라는 커다란 변화 수용하기
변화를 싫어하고 억제하며, 수동 배치에 의존하고, 수동 QA 프로세스를 통해 문제를 포착하는 데 집중하며, 사일로 기반 조직 차트를 유지하는 기업에게 데브옵스는 낯설고 논란의 여지가 많은 것, 심지어 미친 짓으로 보일 수 있다.

그러나 확실한 것은 오늘날 가장 민첩하고 빠르게 움직이는 기술 기업 중에는 데브옵스 스타일의 접근 방법을 통해 과거 어느 때보다 더 많은 상품을 고객의 손에 전달하는 기업들이 있다는 점이다. 이들의 특징은 관료적인 내부 구조를 줄이고, 결과물과 고객 경험에 더 강하게 집중하며, 일반적으로 직원 이직률이 낮은 더 행복한 IT 기업이라는 것이다. editor@itworld.co.kr 



2016.12.01

진정한 데브옵스 조직의 구별하는 3가지 기준

Don Jones | InfoWorld
요즘은 너도나도 "데브옵스"를 외쳐댄다. 이제 고집을 꺾고 슬슬 데브옵스라는 트렌드를 도입해야 하나 생각이 들기도 하지만, 문제는 물건을 구입하듯 간단한 일이 아니라는 점이다.

물론 데브옵스 조직을 원활하게 운영하는 데 도움이 되는 여러 가지 도구가 있지만, 데브옵스의 중심은 그 원칙을 실행하는 팀이다. 데브옵스를 실행한다는 것은 팀 조직, 책임, 기대 측면에서 새롭고 때로는 살 떨리는 전략을 수용하는 것을 의미한다. 올바른 방향을 향한 데브옵스 팀을 알아보기 위한 세 가지 신호를 알아보자.

1. 팀의 기반은 제품이어야
진정한 데브옵스 조직은 일반적으로 그 팀이 제공하는 제품을 중심으로 IT 팀을 조직한다. 이는 많은 사람들이 수십 년 동안 고수해온 방법, 즉 사일로식 접근법을 버린다는 것을 의미한다. 데브옵스 스타일의 제품 팀에는 제품 관리자, 개발자, 인프라 전문가, 시스템 관리자, 그리고 그 제품의 실제 생산에 필요한 기타 모든 인력이 포함된다.

물론 모든 프로젝트마다 전담 전문가가 필요하다는 뜻은 아니다. 한 명의 네트워크 인프라 전문가가 조직의 우선 순위에 따라 시간을 분배해가며 여러 제품 기반 팀에서 일하는 것은 흔한 일이다.

또한, 분야별 조직에는 풍부한 가치가 있다. 모든 운영자가 모든 현황에 대해 전체적인 시각을 유지하면 원활한 운영이 보장되고, 모든 개발자가 자주 "모이면" 새로운 기술과 습득한 교훈, 기타 유용한 정보를 보다 쉽게 공유할 수 있다. 각 분야의 구성원이 종종 모여서 대화하고 정보를 나누는 교차 상품(cross-product) 조합에서 이러한 형태를 볼 수 있다.

2. 실패해도 우아하게
진정한 데브옵스 팀은 실패를 방지하기 위해 변화 속도를 늦추는 방법을 사용하지 않는다. 대신 빠르게 움직인다. 실패에서 신속하게 회복할 수 있는 팀의 역량을 신뢰하기 때문이다. 소규모의 통제된 스프린트에 상품을 배치하면 변수는 항상 최소화되고, 따라서 팀은 위험을 완화하고 빠른 회복을 촉진할 수 있게 된다.

데브옵스 팀은 실패를 큰 배움의 경험으로 기꺼이 받아들인다. 자동화된 딜리버리 파이프라인과 자동 단위 테스트를 통해 각각의 실패는 빌드 프로세스에 흡수되는 또 다른 테스트로 활용된다. 데브옵스는 규격화된 지식과 경험에 의존해 향후 동일한 실패를 방지하기보다는, 모든 것을 프로세스로 코드화함으로써 실패 반복을 자동으로 차단한다.

데브옵스 팀 역시 사전 예방적인 측면에서 최대한 실패를 예견하고 방지하기 위해 노력하지만, 종종 일어나는 사고를 부끄럽게 생각하지는 않는다. 문화적 측면에서 이는 조직이 실패에 대해 성숙한 태도를 도입하고, "탓하기 문화"를 없애며 예측, 학습, 방지를 프로세스의 근본적인 요소로 두고 여기에 초점을 맞춰야 함을 의미한다.

3. 강박적 자동화
진정한 데브옵스 팀은 인간의 실수가 모든 프로세스에서 가장 큰 실패 지점이며 빠른 이동을 방해하는 가장 큰 병목 지점이라는 사실을 안다. 이러한 팀은 실패하지 않는 일관성과 놀라운 속도를 제공하는 자동화에 집착한다. 코드 체크인 규칙 및 분석부터 테스트 환경 가동, 실제 단위 테스트와 최종 프로덕션 배치에 이르기까지, 데브옵스 팀은 자동화가 바로 정답이라는 것을 안다.

그러나 진정으로 효과적인 데브옵스 팀은 어느 한 가지 자동화 도구나 기술에 집착하지 않는다. 이들은 그 작업에 맞는 도구를 찾는 데 집중하며, 비즈니스 목표에 더 매끄럽게 다가갈 수 있는 길만 제공한다면 기꺼이 도구를 바꾼다. 요즘은 보통 데브옵스 팀을 설명할 때 "이종(heterogeneous)"이라는 단어가 사용된다. 특정 플랫폼이나 접근 방법에 깊숙이 전념하는 레거시 조직에게는 넘어야 할 큰 장벽이 될 수 있다.

효과적인 데브옵스 팀은 IT의 핵심이 사용자에게 애플리케이션과 서비스를 제공하는 데 있으며(기능만이 아니라 사용자 경험을 제공하는 것), 그 사이의 모든 것은 잠재적인 속도 저하 요인이라는 점을 안다. 이들은 데브옵스의 역할이 개발자의 키보드에서 출발해 상품 배치에 이르는 가장 매끄럽고 안전하고 빠르고 안정적인 길을 제공하는 것임을 알고, 따라서 새로운 각 코딩 스프린트가 테스트를 거친 프로덕션 배치로 신속하게 이어질 수 있다.

데브옵스는 "노옵스(no-ops)"가 아니다. 최대한 많은 '옵스'를 자동화하기 위한 강박적인 노력이다.

데브옵스라는 커다란 변화 수용하기
변화를 싫어하고 억제하며, 수동 배치에 의존하고, 수동 QA 프로세스를 통해 문제를 포착하는 데 집중하며, 사일로 기반 조직 차트를 유지하는 기업에게 데브옵스는 낯설고 논란의 여지가 많은 것, 심지어 미친 짓으로 보일 수 있다.

그러나 확실한 것은 오늘날 가장 민첩하고 빠르게 움직이는 기술 기업 중에는 데브옵스 스타일의 접근 방법을 통해 과거 어느 때보다 더 많은 상품을 고객의 손에 전달하는 기업들이 있다는 점이다. 이들의 특징은 관료적인 내부 구조를 줄이고, 결과물과 고객 경험에 더 강하게 집중하며, 일반적으로 직원 이직률이 낮은 더 행복한 IT 기업이라는 것이다. editor@itworld.co.kr 

X