Amazon의 운영 탁월성 – Operational Excellence (3) 개발 프로세스

우리가 IT 시스템을 설계, 구현 및 테스트 후 배포를 하고 나면, 전체 수명 주기에서 가장 어려운 측면이 바로 운영을 통해 서비스를 유지 관리하는 것입니다. 이 글에서는 여러분이 개발한 서비스를 탁월하게 운영하는 방법(Operational Excellence)에 대해 세계 최대 전자 상거래 서비스 및 클라우드 컴퓨팅 서비스를 구축해 운영하고 있는 아마존의 모범 사례를 개발 문화, 도구 및 프로세스 등 3가지 필수 상호 연결 요소에 중점을 두어 살펴볼 예정입니다.

1. Amazon의 운영 탁월성 – Operational Excellence (1) 고객 중심 문화
2. Amazon의 운영 탁월성 – Operational Excellence (2) 개발 도구
3. Amazon의 운영 탁월성 – Operational Excellence (3) 개발 프로세스

이 글은 AWS 클라우드 아키텍트 전담 에반젤리스트인 Adrian Hornsby의 Towards Operational Excellence Part 3 — Mechanisms 의 한국어 번역 및 편집본입니다. 좀 더 정확한 의미를 확인하고 싶으신 분은 영어 원문을 참고하시기 바랍니다.

첫번째 글에서는 아마존의 운영 탁월성에 대한 문화적 측면을 다루고 리더십 원칙 (LP)의 맥락에서 기업 문화의 중요성을 살펴보았습니다. 두번째 글에서는 개발 문화적 측면을 지원하는 기술 도구에 대해 설명하였고 마지막 글에서는 일을 하는 프로세스 또는 메커니즘이라는 측면을 다루고자 합니다.  

1. 프로세스의 중요성 – 선한 의도의 역설

개발 문화와 도구가 프로세스와 연결되는 것이 중요하다는 점을 이해하도록 돕기 위해 Amazon의 CEO 인 Jeff Bezos가 좋아하는 일화 중 하나를 공유하고 싶습니다.

본 일화는 아마존 직원에게 하는 고객 지원 센터 교육 중에 일어난 일입니다. 전 세계에서 가장 고객 중심 회사를 지향하는 사명을 가진 회사다 보니, 모든 아마존 직원들은 고객 경험 향상을 위해 직접 고객 응대를 하는 교육을 하고 직접 전화를 받는 업무를 진행합니다. 이를 통해 자신이 어느 업무를 하던지 자신이 내리는 모든 결정의 중심에 고객이 있도록 하기 위한 것입니다.

몇 년 전 Jeff Bezos 역시 예외 없이 고객 응대 교육에 참여했으며 경험이 풍부한 CS (고객 서비스) 담당자와 함께 고객으로부터 전화를 받아 직접 고객 불만 사항에 답변했습니다.

한 고객으로 부터 전화가 오자 Jeff에게 CS 담당자가 해당 고객의 주문 목록을 훝어보면서 고객이 주문한 책상을 반품 할 것이고, 진행 중이라고 이야기했습니다. 실제로 통화 중 고객은 배송 중에 물건이 손상이 있었다고 이야기했습니다. 그리고, 반품하고 싶다고 이야기했습니다.  전화 통화 후, Jeff는 CS 담당자에게 주문한 책상이  왜 손상이 있었는지 물었습니다. 고객이 한 답변을 토대로 다음과 같이 설명했습니다.

“네, 그 책상은 자주 손상되어서 반품이 됩니다.  제대로 포장되어 있지 않아서 테이블 표면이 항상 긁힙니다.”

Jeff는 실제 문제를 알고, 고객 응대를 마치고 고객 서비스 담당 임원에게 가서  더 나은 업무를 수행하도록 고객 서비스와 소매 부서 간의 피드백이 좀 더 원활하게 되도록 부탁했습니다.

그 이후에 잘 해결이 되었을까요? 놀랍게도 아무 일도 일어나지 않았습니다.  이는 Jeff가 문제를 해결해 줄 것이라는 사람들의 선한 의지에만 의존했기 때문입니다. 좋은 의도로 이야기하면, 해도 되고 안 해도 되는 것이 되는 것입니다. 누구도 아침에 일하러 가면서 “오늘 하루를 다 망칠거야!” 이러는 사람은 없습니다. 모두다 좋은 의도로 일을 잘하고 싫어합니다. 하지만, 문제는 해결되지 않았죠.

만약, 사람들의 좋은 의도가 효과가 없다면 일을 진행되는데 무엇이 중요할까요? 대답은 프로세스 혹은 메커니즘 입니다. 메커니즘은 좋은 의도보다 반복적인 문제를 해결하는 데 훨씬 도움을 줍니다. Jeff가 겪은 긁힌 테이블 이야기는 이대로 끝나지 않고, 아마존의 프로세스를 개선하는 단초를 제공했습니다.

“좋은 의도는 효과가 없습니다. 어떤 일이 일어나게 하려면 좋은 메커니즘이 필요합니다.” — 제프 베조스

2. 안단 코드(Andon Cords) 메커니즘

일본의 유명 자동차 생산 업체인 토요타(Toyota)라는 회사로 원래 의류 제작 회사였습니다. 1902년에 토요타는 아래와 같은 실크 직조기를 통해 의류를 생산했습니다.

당시 토요타는 게이샤들을 위해 실크 의류를 만들었고 게이샤들은 실밥이 터지거나 하는 결함이 있는 기노모는 불량품으로 반품했습니다. 토요타의 창시자는 직기에서 기모노를 제작하는 도중에 실이 끊어지면 직기 전체를 멈추고 옷 제작 거부하는 작은 메커니즘을 발명했습니다.

이 작은 아이디어는 높은 품질의 생산품을 만들기 위해 필수적이고 강력하면서도 간단한 철학으로 시작했습니다. 이후로 Toyota는 자동차 제조 라인에서 불량이 나오는 것을 허용하지 않습니다.

이를 현장에서 구현하기 위해, 토요타 공장에는 누구나 조립 라인에서 사람이 당길 수 있는 줄을 가지고 있습니다. 결함이 발견된 경우, 이를 수정하기 위해 줄을 잡아 당기면 생산 라인이 중지됩니다 (아래 그림의 빨간색 화살표).

이를 우리는 안단 코드(Andon Cords) 라고 부릅니다. 마치 산업 안전 장비라고 생각하지만 실제로는 작은 결함이더라도 제조 라인으로 불량품이 나오는 것을 방지하는 방법입니다. 토요타의 모든 직원은 결함을 발견하거나 발생했을 때 줄을 당길 수 있다는 기대가 있습니다. Andon Cord를 당긴 직후, 팀장은 문제가 있는 작업장에서 문제를 직접 “살펴 보고” 결함이 제조 라인으로 이동하는 것을 막은 사람에게 보상을 합니다.

이것이 바로 일이 제대로 작동하게 하는 실제 메커니즘입니다. 이를 통해 직원들은 제품 결함을 막고 고객에게 품질 높은 제품을 제공할 수 있게 됩니다. 그러나 이는 실제 메커니즘입니다. 회사의 모든 직원이 결함을 막고 고객에게 도달하기 전에 이를 수정할 수 있도록 합니다.

아마존 고객 서비스 안단 코드 사례

아마존은 이처럼 단순하지만 강력한 아이디어를 고객 서비스에 적용해서 CS 담당자가 고객에게 문제가 발생했을 때 중단할 수 있는 통계를 중단할 수 있는 안단 코드 고객 서비스 기능을 구축했습니다 . 결함이 발견되면, 몇 분 안에 Amazon 소매 웹 사이트의 모든 제품을 구매 불능 상태로 만듭니다. 이는 현재에도 여전히 운영되고 있으며 매우 성공적이었습니다.

아래 페이지는 안단 코드가 실제 적용된 예입니다. 문제를 해결할 때까지 상품 구매가 일시적으로 중단되었습니다.

아마존은 고객 서비스 이외에도 여러 가지의 안단 코드 프로세스를 구축했습니다. 예를 들어, 고객에게 선제적으로 환불하는 절차가 있습니다. Jeff Bezos는 그의 2012 주주 서한에서 아래와 같이 이러한 프로세스를 공유했습니다.

“Amazon Video On Demand 에서 대여한 영화 카사 블랑카를 시청하는 동안 동영상 재생이 좋지 않은 것으로 나타났습니다. 불편을 끼쳐 드려 죄송합니다. $2.99에 대한 환불이 처리되었습니다. 곧 다시 뵙기를 바랍니다.”

아래는 실제로 고객에게 동영상 시청 문제가 발생했을 때, 미리 환불과 관련된 메일을 고객에게 알려드리기도 했습니다.

즉, 안단 코드 기반 자동 환불 프로그램은 동영상 전송 경험이 일반적으로 낮은 경우, 고객의 신뢰를 해결하고 유지하기 위해 구현되었습니다. 이러한 접근은 아마존 리더쉽 윈칙에 기반합니다.

고객 중심 (Customer Obsession)

리더는 고객의 관점으로 시작하여 거꾸로 일을 시작합니다. 고객의 신뢰를 얻고 유지하기 위해 적극적으로 노력합니다. 리더는 경쟁 업체에 주의를 기울이지만, 무엇 보다 고객에 더욱 집중합니다.

안단 코드 매커니즘의 기본 개념은 구매 행동을 유도하는 것이 아니라 고객 만족도를 해결하기 위한 것으로 아마존 고객 포럼 및 언론 등에서 계속해서 긍정적인 피드백을 받고 있습니다. 저희가 직원을 채용할 때도, 안단 코드 프로그램을 더욱 향상시킬 수 있는 분들을 찾고 있습니다.

AWS 클라우드 내에서도 이런 메카니즘이 잘 동작합니다. 대표적인 것이 바로 컴퓨팅 자원의 규모가 커짐에 따라 나온 비용 절감이 발생할 때 마다, AWS 서비스 가격을 계속 인하하는 선순환(Flywheel)을 통해서 안단 코드 효과를 확인할 수 있습니다.

3. 오류 수정(Corrections of Error)

이러한 메커니즘을 일단 수립하게 되면 전체 프로세스는 도구, 채택 및 감사 의 세 단계로 구성 됩니다. 개발 도구를 만든다고 잠시 상상해보세요. 도구에 대한 교육 프로그램이 있어야 하고 이를 채택해야 하도록 유도 하는 방법이 있어야 합니다. 또한 도구가 설계된 대로 작동하도록 보장하는 일종의 지속적인 감사 메커니즘이 있어야 합니다.

이러한 메카니즘이 아마존의 운영 탁월성에 잘 작동하기 위해, 아마존이 오랫동안 개발한 메커니즘 중에 하나가 바로 오류 수정 과정(Corrections of Error, COE) 입니다. 이것은 개별 팀이 어떤 문제(예상치 않은 오류 또는 소프트웨어 배포 실패)가 발생했을 때, 문제의 원인과 향후 문제를 회피하는 방법을 문서화하는 프로세스입니다.

아마존은 COE 메커니즘을 사용하여 개발 도구, 프로세스 또는 조직의 결함 여부에 관계없이 실수로부터 배울 수 있습니다. 즉, COE 메커니즘을 사용하여 실패에 기여하는 요인을 식별하고 더 중요한 것은 지속적인 개선을 추진합니다.

COE도 아마존에서 만든 것은 아니지만 (1999년부터 개념은 시작됨), 아마존에서 더 체계적으로 진행되고 있습니다. COE 문서에는 5 가지 주요 섹션이 있습니다.

1 — 어떤 문제가 발생했습니까?

2 — 문제 원인 분석을 위해 어떤 데이터가 필요합니까?

3 — 고객에게 미치는 영향은 무엇입니까?

4 — 문제 요인은 무엇입니까?

5 — 무엇을 배웠으며 앞으로 다시 발생하지 않도록 어떻게 할 것입니까?

COE 프로세스에 대해 자세히 알아 보려면 AWS 수석 수석 엔지니어인 Becky Weiss의 re:Invent 2019 강연을 살펴 보시면 좋습니다.

이렇게 아마존 직원들에게 COE 프로세스가 익숙한 것인 이 프로세스가 아래의 두 가지 아마존 리더십 원칙에 해당하기 때문입니다.

신뢰 얻기 (Earn Trust)

리더는 다른 사람의 이야기를 주의 깊게 듣고, 솔직하게 말하고, 존중합니다. 스스로 창피한 일 있더라도 솔직하게 자신의 잘못된 것을 말할 수 있습니다. 리더들은 자신이나 팀의 잘못된 점을 드러내지 않습니다. 오히려 자신과 팀을 벤치마킹합니다.

딥 다이브 (Deep Dive)

리더는 모든 영역에서 세부 정보에 파악하고, 지속적으로 데이터를 감시하면서, 모든 데이터에 대해 회의적인 시각을 견지합니다.

COE 동안 성공의 열쇠는 무엇이 잘못되었는지에 대해 공개적이고 투명해야 합니다. 즉, 문제에 대해 주의 깊게 살펴 볼 필요도 있지만, 각자 자발적으로 스스로 비판적어야 당면한 문제에 대해 깊이 이해할 수 있습니다. 그리고, 그러한 잘못에 대해 책임을 물리면 안됩니다. 일반적으로 COE 프로세스를 통해 운영 탁월성을 얻는 것이 핵심이지, 잘못을 드러내 책임을 묻는 환경에서는 이러한 프로세스가 작동하기에는 매우 어려울 수 있습니다.

지속적인 감사를 통해 확인하기

COE 메커니즘을 완전한 프로세스로 만들기 위해서는 개별 팀이 고위 경영진 앞에서 주간 운영 통계 검토 회의 형태의 지속적인 검사를 실시합니다 .

모든 서비스 팀은 요청에 따라 운영 지표를 제시 할 준비가 되어 있어야 합니다. 이를 통해 모든 사람이 자신의 서비스 수행 방식을 더 잘 알 수 있습니다. 매주 회의에 발표할 팀은 아래와 같은 돌림판을 돌려서 무작위로 선택됩니다.

해당 팀으로 선택되면, 미팅에서 서비스 운영 담당이 개별 서비스 통곛치에 대해 15분 동안 심층 분석을 합니다. 임원진들이 하는 일반적인 질문은 다음과 같습니다.

“ 오류가 일어나는 비율은 어느 정도입니까?”

“충분히 모니터링하고 있습니까?”

“무엇을 배웠습니까?”

이렇게 배운 점들은 계속 축적됩니다. 이렇게 만들어진 대표적인 사례가 AWS Well-Architected 프레임 워크입니다. AWS 내부 각 팀이 만든 COE 프로세스와 문제 감사 과정에서 얻어진 것들을 모범 사례로 정리하고, 이를 다시 AWS 고객들은 기술 백서 및 서비스 도구로 사용하고 있습니다.

지속적인 개선하기

COE 프로세스와 주간 운영 통계 검토 회의를 갖추면 좋은 메커니즘을 만든 것일까요? 그렇지 않습니다. 한 팀의 COE와 주간 회의가 끝나면, 이 팀에서 발견 한 문제가 다른 팀이 즉시 알아채고 사전에 해결될 수 있을까요? 다시 한 번 좋은 의도를 요구하고 있습니다!

발견된 문제와 해결점이 다른 팀에도 확산할 수 있는 지속적은 개선을 위한 또 다른 메커니즘이 필요했습니다. 이를 위해 새로운 도구인 정책 엔진(Policy Engine)을 구축했습니다 .

정책 엔진은 인프라와 해당 구성을 검색하여 잠재적인 위험과 비용 절감 기회가 있는지 살펴 볼 수 있습니다. 즉, COE 프로세스 중에 식별된 문제-목록화할 수 있는 문제를 기반으로 정책을 생성합니다. 이 도구는 쉽게 확장 가능하므로 새로운 문제가 발견되면 누구나 사용할 수 있는 새로운 정책이 만들어지고 도구에 추가됩니다.

이를 기반으로 만들어진 정책 엔진 대시 보드에서 잠재적 및 발견된 위험과 비용 절김 기회 절약 측면에서 팀의 성과를 전체적으로 보여줍니다. 이를 통해 개별 팀은 지속적으로 서비스를 개선하고 비용 효율적인 선순환 구조를 만들 수 있습니다.

아마존에서는 이러한 메커니즘은 AWS Config , AWS Trusted Advisor 및 Well-Architected 도구 등 AWS 서비스 개발에 영감을 주었습니다 .

AWS Config를 사용하면 AWS 리소스의 구성을 조사 , 감사 및 평가할 수 있습니다. 리소스 구성을 지속적으로 모니터링하고 기록 할 수 있으므로 자원의 구성 변화를 확인할 수 있습니다. 또한, 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결을 단순화합니다.

AWS Trusted Advisor는 AWS 모범 사례에 대한 실시간 지침을 제공합니다. 비즈니스 및 엔터프라이즈 지원 고객은 전체 Trusted Advisor 점검 및 권장 사항에 접근하여 인프라 최적화, 보안 및 성능 향상, 비용 절감 및 서비스 제한 모니터링에 도움을 줄 수 있습니다.

마지막으로 AWS Well-Architected Tool 은 고객이 워크로드를 검토하고 AWS 모범 사례에 따라 지침을 제공합니다. 고객이 AWS 솔루션 아키텍처 팀이 수행 한 수만 건의 워크로드 검토를 통해 설계된 안전하고 성능이 뛰어나고 신뢰할 수 있으며 비용 효율적인 애플리케이션을 AWS에 구축 할 수 있도록 개발 된 AWS Well-Architected 프레임 워크를 기반으로합니다 .

마무리

아마존이 성공적이고 지속적인 서비스를 제공하기 위한 운영 탁월성을 얻기 위해서는 3개의 상호 연결 요소가 필요하다는 점을 소개했습니다. 고객 중심의 문화와 개발 도구 그리고 이를 위한 프로세스입니다.

마지막으로, 좋은 의도는 작동하지 않으며 프로세스가 작동하기 위한 메커니즘이 필요합니다.

• Amazon의 운영 탁월성 – Operational Excellence (1) 고객 중심 문화
• Amazon의 운영 탁월성 – Operational Excellence (2) 개발 도구
• Amazon의 운영 탁월성 – Operational Excellence (3) 개발 프로세스

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)