Amazon의 운영 탁월성 – Operational Excellence (1) 고객 중심 문화

2020-02-19 01:52:00

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

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

1. 운영 탁월성이란 무엇인가?

만약 여러분의 비즈니스가 전적으로 기술 플랫폼에 의존하고 있다면 운영 탁월성(Operational Excellence)은 매우 중요합니다. 아마존닷컴 처럼 24시간 운영되는 쇼핑몰을 비롯하여 AWS 클라우드처럼 사용자에게 서비스를 제공하는 서비스 업체에 제공하는 경우, 서비스 중단 없는 확장성 높은 운영 능력은 필수적입니다. 1995년 아마존닷컴이 온라인으로 책 판매를 시작했을 때, 이 사이트가 다운되거나 특정 시점에 유지 보수를 진행하면 전 세계 고객을 대상으로 사업을 영위하기가 어려웠을 것입니다.

Amazon.com 서점 — 1995 — Amazon.com 온라인 서점 스크린샷 — 1995

아마존닷컴은 어떻게 운영 탁월성을 확보할 수 있게 되었을까요? 자체 서비스가 아닌 제3자 기업에 클라우드 컴퓨팅 서비스를 제공하는 AWS까지 본다면, 아주 성공적인 운영 탁월성을 확보했다고 볼 수 있을 것입니다. 여기서는 아마존이 어떤 과정을 거쳐 운영 탁월성을 확보할 수 있었는지 과거의 여정을 우선 살펴보겠습니다.

초기 아키텍처 – 모놀리식(Monolithic)

초기에 amazon.com 서점을 운영하는 시스템 은 상당히 간단했습니다. 초기 웹 서비스를 만든 대부분의 회사와 같이 아래 그림과 같은 프론트 페이지, 몇 가지 내부 도구, 웹 서버 및 데이터베이스를 갖춘 단순한 3 계층 아키텍처였습니다.

상품 전시, 주문, 결제, 고객 서비스 도구 및 배송, 물류 센터 도구에서 동일한 데이터베이스를 사용했습니다. 아마존 서비스가 빠르게 성장하고 사용자가 많아짐에 따라 모든 데이터를 하나의 데이터베이스에 공유하는 아키텍처는 바로 문제가 생기기 시작했습니다. 일례로 2004년 12월 12일에 Amazon.com은 오라클 데이터베이스 버그가 발생하여, 12시간 동안 장애가 일어났었는데, DB가 단일 장애 지점이었습니다. 그 당시는 크리스마스 시즌이다 보니 매출에도 큰 타격을 주었습니다.

또한, 모놀리식 개발 방식으로 인해 개발, 테스트 및 출시 주기가 점점 오래 걸리게 되었습니다. 하나의 소스 레포지터리에서 모든 개발자들이 개발하고 있으니, 고객이 원하는 기능을 빠르게 구현해서 배포하는 일이 점점 더 어려워지게 된 것이죠. 지속적으로 시의 적절한 배포가 필요한 쇼핑몰 서비스의 경우, 이러한 지연은 고객 경험을 크게 훼손하는 것이었습니다.

서비스 지향 아키텍처로 변신

2004년부터 아마존은 빠른 서비스 기능 구현 및 장애 시 발생하는 영향력을 최소화 하기 위핸 “폭발 반경”을 줄이기 위한 조치를 취하기 시작했습니다. 이를 위해, 아마존은 모놀리식으로 운영되던 전체 애플리케이션을 비즈니스 도메인 별로 분해하여 서비스 지향 아키텍처 (SOA)로 이동하여 구성 요소를 분리하는 투자를 시작했습니다.

각 기능별 도메인은 별도의 서비스로 분리되고 네트워크를 통해 API 인터페이스를 통해 다른 서비스와 통신하게 함으로서 느슨한 연결(loosely coupled)을 통해 장애 전파가 최소화되도록 하였습니다. 또한, 장바구니 같은 쓰기/업데이트가 집중된 서비스 기능은 기존의 관계형 DB 대신 Dynamo라는 별도 키-밸류 DB를 개발해 모든 서비스가 하나의 DB를 바라보지 않도록 분산했습니다. 단지 애플리케이션과 DB 뿐만 아니라, 각 서비스는 해당 서비스를 직접 소유하고 운영하는 별도의 소규모 자율 팀에서 관리하도록 하였습니다.

2008년 Amazon.com의 마이크로 서비스 아키텍처 – 출처: Werner Vogels

이를 통해 Amazon.com은 우리가 아는 대로 수천 개의 서로 다른 서비스로 구성된 아키텍처에서 수억 명의 활성 고객을 빠르고 쉽게 지원할 수 있게 되었습니다. 하지만, 여러분이 보시다시피 수천 개의 서비스팀이 수천 개의 서비스를 어떻게 독자적으로 문제 없이 운영할 수 있을까요? 이러한 복잡성을 어떻게 해결하는 것일까요?

운영 탁월성을 확보하는 방법

솔직히 운영 탁월성을 확보했다는 것을 정의하는 것은 매우 어려운 일입니다. 단순히 여러분이 하고 있는 작업에 대한 체크 리스트의 목록을 만들고 그걸 다 했다고 한다고 이루어질 수 없습니다. 아리스토텔레스가 탁월성이란 한번하고 마는 행동이 아니라 우리가 반복적으로 습관에 달려 있습니다.

Wikipedia에 따르면, 습관은 “규칙적으로 반복되고 무의식적으로 일어나는 경향이 있는 행동이라고 합니다. 운영 탁월성은 이러한 행동 습관, 같은 사고 방식, 문제 해결을 통해 지속적인 개선을 중요하게 생각하고, 목표를 일관되게 초과하려는 의지에 달려있습니다. 이를 통해, 문제를 예측하고 해결하며 효과적으로 대응할 수 있는 방법입니다. Amazon의 경우, 전 세계 수만명의 개발자와 수백만 대의 서버에서 운영되는 수천 여개의 서비스를 지속적으로 만들고, 배포하고 운영하고 있는 대규모 통합 서비스입니다.

따라서, 더 좋은 질문은 “기술 조직이 운영 탁월성을 확보하는데 필요한 습관은 무엇인가”입니다. 아마존의 그간 경험을 통해 본다면, 서비스를 성공적으로 운영하기 위해서는 세 가지 필수 상호 연결 요소가 필요합니다.

먼저, 구성원들이 동의하는 올바른 기업 문화가 필요합니다. 개발, 테스트, 배포, 운영 및 온콜 같은 단순한 반복 작업이 고객에게 그리고 개발자 자신에게 주는 가치를 우선 공유해야 합니다. 두번째는 각 자율 독립팀들이 모든 것을 다 할 수 없기 때문에 훌륭한 개발 도구가 겸비되어야 합니다. 마지막으로 언제든지 오류를 수정할 수 있는 완전한 개발 프로세스 가 필요합니다.

이 글에서는 운영 탁월성을 위한 구성원들이 공유할 수 있는 기업 문화의 중요성을 먼저 알아보겠습니다.

2. 기업 문화의 중요성

아마존의 기업 문화는 유명한 14가지 리더십 원칙을 통해 매우 잘 이해할 수 있습니다. 이들 원칙들은 상징적인 선언이 아니라, 아마존의 모든 구성원들이 일상 업무에서 직접 적용하고 있 핵심 가치, 즉 회사의 DNA이기 때문입니다.

다른 회사와 달리 아마존의 리더십 원칙은 벽에 걸려 있는 구호가 아닙니다. 아마존 직원들이 메일을 쓰거나, 미팅을 하거나, 고객과 이야기할 때, 심지어 채용 인터뷰, 신규 아이디어를 논의하거나 미래 계획을 짤때도 이 원칙들을 적용합니다. 게다가 기술적인 의사 결정을 할 때, 심지어 간단한 버그를 고치거나, 서비스 패치를 할 때도 가장 좋은 방법을 결정 할 때 리더십 원칙은 가장 중요한 지침입니다.

“리더십 원칙”이라고 하니 리더들에게만 적용된다고 오해하기 쉬운데, 아마존에서는 모든 직원을 리더로 서로 대우합니다. 개발자이든 매니저든 임원이든 누구나 동등하게 적용됩니다. 이것이 아마존을 독특하게 만드는 것 중 하나입니다.

이들 14가지 리더쉽 원칙 모두 아마존의 개발 문화에도 바로 영향을 끼치는 것이지만, 그 중에서도 가장 중요한 세 가지를 먼저 살펴 보고자 합니다. (향후에 다른 글에서 추가적으로 설명하도록 하겠습니다.)

고객 중심 (Customer Obsession)

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

높은 수준의 기준 목표 (Insist on the Highest Standards)

리더들은 끊임없이 높은 수준의 목표를 가지고 있습니다. 많은 사람들이 그 기준이 너무 높다고 생각할 수도 있습니다. 하지만, 리더는 지속적으로 그 기준을 높이고 팀을 이끌고 고품질 제품, 서비스 및 프로세스를 제공합니다. 리더는 결함을 지속적으로 살펴보고, 문제가 해결되도록 합니다.

주인의식(Ownership)

리더는 스스로 주인이라고 생각합니다. 장기적으로 생각하고 단기 결과를 위해 장기적인 가치를 희생하지 않습니다. 자신의 팀을 넘어 회사 전체를 대표하여 행동합니다. 리더는 결코“이건 내 일이 아니다”라고 말하지 않습니다.

아마존은 고객 중심 회사가 되는 것을 비전으로 삼을 만큼 가장 큰 회사 전체의 핵심 가치입니다. 고객 중심이라는 원칙은 흔히 생각하는 고객 만족 또는 고객 행복 이상의 것으로, 처음 부터 고객의 입장에서 거꾸로 생각하고 옳은 일을 하는 것입니다. (이와 관련해서 Amazon의 Working Backward 문화에 대해 참고하세요. )

엔지니어링 영역에서도 고객을 최우선으로 삼고 “필요는 발명(Invention)의 어머니”라는 격언에 따라 고객에게 필요한 다양한 기능들을 만들어내고 있습니다. 운영 탁월성을 고객 중심과 결부해서 설명하기에 가장 좋은 예는 바로 Amazon Flywheel(선순환 구조) 입니다.

이 구조는 제프 베조스가 회사를 만든 후, 온라인 쇼핑에서 어떻게 하면 고객의 경험을 가속화 수 있을까 하는 아이디어를 더 저렴한 가격과 다양한 제품 선택의 고객 니즈를 통해 구현하는 방법을 도식화해서 보여줍니다.

고객 경험이 매우 중요한 지점이며, 모든 것이 시작된 곳입니다.
고객 경험이 향상되면, Amazon.com으로 더 많은 트래픽을 유도합니다. (예: 원 클릭 구매 , 하루 배송 및 Go Store )
많은 고객들이 Amazon.com을 사용함에 따라 더 많은 판매자를 유치합니다.
더 많은 판매자가 자연스럽게 고객에게 더 많은 제품을 제공합니다.
Amazon.com의 판매 증가로 규모의 경제를 통해, 비용 구조를 낮추고 이를 제품 가격 인하로 고객의 경험을 높여 줍니다. 경험이 향상되면 다시 트래픽이 증가합니다.

이러한 선순환 구조가 작동하기 시작하면, 눈덩이 같은 네트워크 효과가 일어납니다. 고객 트래픽이 지속적으로 증가하여 판매 규모는 커지면서, 비용 구조는 더 낮아집니다.

아마존닷컴 CTO인 버너 보겔스(Werner Vogels) 블로그에서 설명하는 것처럼 혁신이라는 것이 미지의 영역을 발견하는 것이 아니라, 이러한 Flywheel이 입증 한 바와 같이 저렴한 가격, 다양한 제품 선택, 빠른 배송, 물론 편의성 등 아주 기본적인 아이디어를 고객에게 중요한 차원에서 수행하는 것이 바로 혁신입니다.

“고객은 자신이 어떤 것을 원하는지 알지 못하지만 항상 더 나은 것을 원하며, 그러한 고객을 기쁘게 하려는 목적으로 고객을 대신하여 발명하는 것이 필요합니다.” — Jeff Bezos, 2016 주주에게 보내는 편지

AWS의 경우, 아마존과 같이 고객에게 중요한 아이디어 즉, 확장 가능한 규모있는 컴퓨팅 서비스, 서비스 안정성, 더 높은 보안 및 성능, 사용자 편의성 및 종량제를 기반한 더 낮은 가격과 같은 운영 탁월성을 수행하고 있습니다.

이러한 차원에서 개선 사항은 AWS 고객에게 장기적이고 즉각적인 혜택을 제공합니다. 예를 들어, AWS 고객이 늘어남에 따라 서비스 플랫폼이 성장함으로서 AWS의 글로벌 인프라 규모를 확장하여 클라우드 서비스를 보다 효율적으로 운영 할 수 있습니다. 이러한 규모의 경제로 이룬 낮은 비용 구조를 고객에게 다시 요금 인하라는 혜택으로 제공할 수 있습니다. 200년 AWS가 출시 된 이후, 지금까지 79회의 가격 인하가 있었으며 이것은 지금도 계속되고 있습니다. 고객은 사용만 해도 서비스 요금은 인하됩니다.

3. 독특한 고객 문화

이렇듯 Amazon은 매일 다양한 일을 수행하여 고객을 위해 더 나은 서비스를 제공하고, 더 빠르게 혁신함으로서 고객의 비용까지 절감합니다. 이러한 아마존의 “독특한 방식(Peculiar Ways)”를 위해 다른 사람들과 다르게 업무를 해야 합니다.

때로는 그렇게 하는 것이 조금 이상하거나 이해하기 어려워 보일 수도 있습니다. 예를 들어 그 독특한 방법 중 몇 가지를 살펴 보겠습니다.

모든 고객은 평등하다

아마존 사람들은 우리의 서비스 기준을 높이는 데 도움을 주는 고객을 진심으로 중요하게 생각합니다. AWS 초기에 Low-Flying-Hawk 라는 아이디를 가진 사람이 정기적으로 포럼에서 새로운 기능을 제안했으며, AWS 팀은 회의에서 요청할 수 있는 많은 피드백을 기대하기 시작했습니다.

재미있는 사실은 Low-Flying-Hawk 라는 아이디를 가진 분이 AWS를 한 달에 $3 정도 밖에 사용하지 않았지만, 그 분의 의견은 매우 중요했기 때문에, 아이디를 따서 건물 이름으로 명명하였습니다.

훌륭한 제품과 서비스는 고객에 대한 깊은 이해에서 비롯됩니다. 만약 고객의 요구에 귀를 기울이고, 문제 해결로 바로 넘어 가면 고객에게 즐거운 경험을 제공 할 수 있는 선택이 제한되므로 선순환 구조(Flywheel)을 지속하기가 어렵습니다.

투-피자(Two Pizza) 팀

앞서 설명드린 대로 아마존은 서비스를 쪼개면서 하나의 자율적인 단일 팀을 구성하여, 고객을 위해 일하고 있습니다. 많은 기업이 운영과 개발을 분리하는 기능적인 사일로 조직을 만드는 반면, 아마존은 하나의 서비스 한 지붕 아래 개발과 운영 모든 것이 존재합니다. 고객 요구에 초점을 맞춘 고객 중심의 조직 모델이 최상의 결과를 얻는다고 믿기 때문입니다.

이러한 단일 개발 운영팀을 소위 투-피자(Two Pizza)팀이라고 부립니다. 이는 하나의 서비스를 구축, 배포, 유지 관리 및 운영할 때 필요한 팀의 크기가 피자 두판으로 식사를 할 수 있는 정도의 크기 즉, 8-12 명보다 크지 않기 때문입니다.

팀 내에서 직접 개발, 테스트, 배포 및 운영을 직접 수행합니다. 이는 개발자들이 좋아하는 것이 아닐 수 있지만, 많은 경우 기술 부채를 최소화하기 위해 필수적입니다. 그러나, 잘못하면 각 팀의 개발 및 운영 비용이 증가하고 관리되지 않은 서비스 종속성 및 팀의 복잡성이 늘어날 수 있습니다.

따라서, 투-피자팀은 아래 그림에서 볼 수 있듯이 개발 도구를 만들거나 운영하는데 대한 책임은 없습니다. 이러한 셀프 서비스 도구를 만들고 제공하기 위해 전담 팀이 있습니다.

개발과 배포의 연속성 제공

아마존은 리더쉽 원칙에서 부터 강력한 주인 의식 문화를 가지고 있으며, 개발 및 배포를 직접 소유합니다. 개발이 끝난 결과물을 “벽 뒤로 던지는 것”처럼 운영하지 않습니다.

즉, 개발자는 프로덕션 환경에서 코드가 어떻게 작동하는지 확인할 수 있습니다. 중요한 이점 중 하나는 개발자가 발생하는 운영 문제의 원인을 즉시 이해하고 해결할 수 있는 통찰력을 개발자에게 제공한다는 것입니다.

물론 투-피자 팀에는 서로 다른 품질 보증 및 운영 리소스가 있지만 동일한 서비스 팀에 속하며 개발자와 긴밀히 협력합니다. 많은 회사들이 개발과 운영 사이의 혼란의 벽을 데브옵스 (DevOps)라는 방식으로 연결하거나 조정하는데 초점을 맞추고 있지만, 아마존은 처음부터 이러한 벽이 존재하지 않았습니다.

배울점

아마 여러분들은 아마존의 독특한 기업 문화에 대해 알게 되셨을 것이고, 어떤 부분을 응용할 수 있을지 궁금하실 것입니다. 먼저 아셔야할 점은 이것은 아마존의 문화일 뿐 여러분 회사의 조직이나 문화를 아마존처럼 모두 바꿀 필요가 없다는 것입니다. 오히려, 고객 중심이라는 중요한 아이디어에 집중해야 합니다.

혹시 새로운 신규 사업이나 서비스가 고객 중심으로 운영해야 한다면, 단일 팀 또는 소규모 프로젝트에서 먼저 시도하고 그 결과를 살펴 보시길 권장합니다. 기능을 정의하고 구현하기 앞서 고객에게 꼭 필요한 것인지 고객에게 상당한 이익이 되는지 솔직하게 토론해 보세요. (아마존의 고객 중심 기획 방식인 거꾸로 일하기(Working Backward), PR-FAQ 문화, 내러티브 문화, 높은 기준의 적용, 장기적인 관점에서 실패 수용 등 Amazon의 혁신 문화에 대해 많은 정보를 제공하고 있습니다.)

고객을 직접 만나 이야기를 들어보고 더 많은 시간을 보내야 합니다. 개발자가 고객과 직접 대화 할 수 채널이 필요합니다. 고객으로부터 개발자에게 피드백을 받아 기능을 개선하는 통로가 있는지 실제 동작하고 개선하는 방법을 살펴보십시오.

다음으로, 민첩성을 확보하기 위해 서비스 아키텍처와 개발팀을 세분화하는 방법을 생각하십시오. 내부적으로 투-피자 팀 아이디어를 실험 해보시기 바랍니다. 분할된 서비스를 소규모 팀이 초기 설계부터 개발, 출시 및 유지 보수까지 전체 개발 및 운영 프로세스를 직접 하도록 해보세요. 대부분의 개발자들은 자신의 아이디어를 직접 구현하고 외부 사용자에게 직접 서비스를 하고 싶어합니다. 주인 의식을 가진 헌신적 인 소규모 팀이 기적을 행할 수 있습니다.

이러한 서비스 개발 문화와 조직 실험이 어느 정도 정착이 되었다면, 아마존의 리더쉽 원칙들을 공유해서 팀원들에게 큰 영감을 주는 몇 가지를 선정해서 실천해 보시길 권장합니다.

“기업 문화를 몇 가지 문장으로 정의해서 보여 줄 수 있지만, 그런식으로 올바른 문화를 발견할 수 없습니다. 기업 문화란 시간이 지남에 따라 구성원들과 그들이 만들어 일련의 사건들, 즉 과거의 성공과 실패로 얻은 경험에 의해 천천히 만들어집니다.” — Jeff Bezos, 2015 Amazon.com 주주에게 보내는 편지

마무리

아마존이 추구하는 문화와 조직 구조에서는 각자 적은 비용으로 고객에게 고품질 서비스를 제공하기 위해 운영 효율성을 높여야 합니다. 점진적인 개선 및 작은 변경에 집중함으로써 운영의 효율성과 효과를 높여 비즈니스 성공을 빠르게 실현할 수 있습니다.

만약 여러분의 회사가 하는 비즈니스나 서비스에서 운영의 탁월성을 얻고 싶다면, 가장 먼저 조직의 문화를 고객 중심으로 일회성이 아닌 지속적으로 건강한 습관으로 형성하는 방식에 대해 신중하게 생각하시면 좋겠습니다.

다음 글에서는 아마존의 자율적인 각 소규모 팀이 서비스 개발 및 배포 시 효율성을 높이기 위해 어떠한 개발 도구를 활용하는지 살펴보도록 하겠습니다.

더 읽어 볼 글

- 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.)