Stephen Orban – 클라우드를 통해 실험할 때 해야 할 일과 하지 말아야 할 일 4가지

“막대기가 휘어져 있음을 보여 주는 가장 좋은 방법은 막대기에 관해 논쟁하거나 비난하는 데 시간을 허비하는 것이 아니라 곧은 막대기를 옆에 놓는 것이다” ― D.L. Moody

지난 게시물에서 규모와 형태를 막론하고 모든 회사에게 클라우드를 통해 실험이 얼마나 쉬워지고 저렴해지며 덜 위험해지는지 설명했습니다. 회사가 오늘날의 시장에서 실험 문화를 가지고 있다는 것은 경쟁력을 유지할 수 있는 기반이 됩니다. 실험은 혁신을 키우며, 지금처럼 새로운 아이디어를 실천하기에 좋은 때는 없었습니다.

그럼 어디서부터 시작해야 할까요? 조직에서 실험 문화를 구축할 때 고려해야 할 네 가지와 피해야 할 네 가지를 알려 드리겠습니다.

1. 기대수준을 관리하십시오.

예상과 다른 결과가 나오는 실험도 있지만 모든 실험은 배우고 운영을 개선할 수 있는 기회입니다. 조직이 “배우기 위한 실패”라는 개념에 익숙하지 않다면 작은 것부터 시작하고 실험이라고 생각하는 프로젝트를 모두에게 알리십시오. 실험의 목표, 바라는 결과, 결과를 측정하고 테스트할 방법, 이를 통해 배우고자 하는 것을 명확히 함으로써 이해관계자의 기대치를 관리하십시오. 제가 이 과정을 통해 발견한 것은 실험을 해보고 뭔가를 배움으로써 조직이 어떻게 발전하는지 알게 되면 대부분의 임원도 결과가 불확실한 실험의 가치를 이해한다는 것입니다.

모두가 구체적인 성과를 바라보고 있는 프로젝트부터 시작하지 마십시오.

실험 문화를 조성하기 위해 노력하는 변화 관리자 역할을 맡고 있다면  초기에는 이해 관계자들이 구체적인 성과를 요구하는 프로젝트로 실험을 시작하지 마십시오. 예를 들어, 연말 거래 총액 집계로 실험을 시작하는 것은 권장하지 않습니다. 제가 예전에 함께 일했던 한 CEO는 실험에 대해 이렇게 말했습니다. “실패해서는 안 될 때가 아니라면 실패해도 괜찮다”. 점진적 발전에 만족하고 실행하는 실험의 수를 천천히 늘리되 조직보다 앞서가지는 마십시오.

2. 팀의 실험 제안을 독려하십시오.

조직마다 기술 자원을 어떤 프로젝트에 할당할 지 결정하는 고유의 방식이 있습니다. 불행히도 현재 일부 조직은 기술 또는 IT 부서를 코스트 센터로 취급하고 있습니다.  또한 아이디어 생성 과정이 아이디어를 실행하는 사람들과  동떨어져 분리되어 있습니다. 좋은 아이디어는 어디서나 나올 수 있으며, 외부 프로젝트와 관련하여 대부분의 기술 전문가는 독특한 시각을 드러내곤 합니다. 막 클라우드를 시작하는 조직에서는 특히 그렇습니다. 클라우드 고유의 기능을 활용하여 비즈니스에 가치를 가져다 주는 실험을 제안할 적임자는 바로 클라우드를 사용하는 개개인입니다. 팀의 제안을 장려하고 경영진이 어떤 프로젝트에 투자하는지에 영향을 미칠 수 있는 위치에 직원들을 배치하십시오.

측정 방법을 알기 전까지는 실험을 추진하지 마십시오.

여러분은 적절한 실험에 시간을 쏟고 실험에서 얻은 교훈을 통해 조직과 제품이 개선되기를 바랄 것입니다. 팀의 실험 진행을 허락하기 전에 실험 도중 무엇을 어떻게 측정할지 합의해야 합니다. 웹사이트의 새 기능을 테스트한다면 성공적인 웹사이트의 지표는 무엇입니까? 페이지 뷰 수입니까? 클릭 수입니까? 포기율입니까? 이 작지만 중요한 실사 작업은 애초에 팀이 실험을 제안하는 이유를 곱씹어 보도록 합니다. 또한 팀으로 하여금 적절한 실험 우선순위를 정하도록 합니다.

3. 실험을 제도화할 DevOps를 고려하십시오.

DevOps 문화는 실험을 조직의 규범으로 만드는 강력한 방법이 될 수 있습니다. 자산 개발 및 운영(run-what-you-build)과 자동화의 결합은 변경 사항을 적용하는 데 드는 시간을 크게 줄여 더 자주 더 빨리 적용하고 효과 없는 변경 사항은 빠르게 롤백할 수 있습니다. 성숙한 DevOps 조직은 서로 다른 사용자 집단을 이용해 조금씩 다른 사용자 경험을 실험하여 가장 효과적인 것을 찾을 수 있는 A/B 테스트 프레임워크도 개발합니다.

팀을 의심하지 마십시오.

의심은 팀의 사기를 꺾고 실패의 문을 여는 가장 강력한 방법입니다. 적절히 실험 범위를 정하고 측정하며 빠르게 반복하는 방법을 배움에 따라 의심에 앞서 자신의 방법을 조정할 수 있어야 합니다. 팀이 올바른 실험 측정 방법에 대해 생각하도록 하고 어려운 질문을 하는 것이 건전하다는 것을 주지시켜야 하지만, 문제를 해결할 수 있는지 의심하기보다는 팀이 문제를 해결하도록 돕는 방법을 찾아야 합니다. 사람들은 성공하리라 믿는 리더를 따르는 경향이 있습니다.

4. 전체 조직의 참여를 독려하십시오.

실험을 통해 보다 빠르게 결과를 내기 시작하면 조직의 다른 부서들도 여러분의 방법에 끌리게 됩니다. 이런 사람들을 참여시키십시오. 다양한 비즈니스 분야를 포함하는 해커톤을 시도하고, 이해관계자가 실험 측정을 돕도록 하며, 조직에게 항상 실험하고 싶었던 분야를 물어보십시오. 직원들에게 실험할 시간을 주지 않는 회사도 있겠지만 일반적으로는 이를 경쟁력으로 선전합니다. 적어도 이런 종류의 포괄적 활동은 직원들의 사기와 직원 보유율을 높입니다. Amazon에서의 짧은 근무 기간 중에 저는 실험에 대해 깊이 생각하고 이를 글로 명확히 표현할 수 있는 사람이라면 누구나 일반적으로 시도할 기회를 얻게 된다는 것을 알게 됐습니다. 이것은 우리 문화의 특별한 부분이며, 혁신가와 구축가를 끌어들이고 유지하는 훌륭한 도구입니다.

실험이라고 결과가 늦게 나오거나 중단되어서는 안 됩니다.

실험이라는 이유만으로 팀이 결과에 소홀해지지 않도록 하십시오. 실패하고 배우는 것은 좋지만 실험이라 하여 미흡한 결과를 내도 되는 것은 아닙니다. 테스트할 소프트웨어는 여전히 제공되어야 하고, 프로덕션에서 실제 트래픽으로 측정되어야 합니다. 실험이라는 이유로 측정을 늦게 시작하거나 품질이 떨어져도 되는 것은 아닙니다. 어쨌든 여전히 비즈니스를 운영하고 있다는 점을 잊지 마십시오.

실험 문화를 가능케 하기 위해 여러분의 회사는 무엇을 합니까? 꼭 듣고 싶습니다.

– Stephen;
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.