편집자: Deep Wave TechFlow

참고: 이 기사는 Shenchao TechFlow 특별 주제 "YC 창업 과정 중국어 노트"(매일 업데이트됨, 이 기사는 시리즈의 마지막 기사입니다.)에 포함되어 있으며, YC 과정의 중국어 버전을 수집하고 구성하는 데 전념하고 있습니다. 스물다섯 번째 기사는 기술 책임자 베르너 보겔스(Werner Vogels)가 진행하는 아마존 CEO 온라인 강좌 "기술과 스타트업에 대한 경험과 통찰"입니다.

아마존에 합류하기 전

Amazon에 합류하기 전에 저는 코넬 대학교에서 과학 연구를 하고 대규모 분산 시스템을 구축하는 데 10년을 보낸 학자였습니다. 그 전에 저는 전형적인 컴퓨터 과학자가 아니었습니다. 28세가 되어서야 학교로 돌아가겠다는 진정한 결정을 내렸습니다. 이전에는 네덜란드 암 연구소에서 암 환자들에게 방사선 치료를 제공하는 병원의 방사선 치료 업무를 맡았습니다. 어느 날 갑자기 주변 사람들의 죽음을 견딜 수 없다는 것을 깨닫고 전혀 관련 없는 일을 하기로 결심했습니다. 컴퓨터 공학은 좋은 선택인 것 같았습니다.

때는 1980년대 중반이었고, 컴퓨터 과학은 지금만큼 인기가 없었습니다. 그런데 알고 보니 당시에는 몰랐음에도 선물이 있었습니다. 그래서 저는 그것에 대해 파헤치기 시작했습니다. 그것이 제 관심을 끌었기 때문입니다. 저는 박사 학위를 취득하고 포르투갈의 한 연구 기관에서 몇 년간 근무한 후 코넬 대학에 입학하도록 초청받았습니다.

코넬에 있는 동안 연구 업무 외에도 HP 등 대기업과 잘 들을 수 없는 몇몇 회사와 자주 상담도 하고, 각종 컨퍼런스에도 참여했습니다. 한번은 Amazon에서 제가 작업 중인 자료를 발표하도록 저를 초대했습니다. 처음에는 조금 놀랐고 혼란스러웠습니다. 정말요? 이 작업을 수행해야 합니까?

그 당시에는 웹 브라우징과 데이터베이스가 얼마나 문제가 있었나요? 그러나 막상 시작하면서 이것이 실제로는 엄청난 기술적 도전이라는 것을 깨달았습니다. Amazon은 단순한 소매업체가 아닙니다. 이전에 본 적도 없고 제가 상담한 다른 회사와 비교할 수도 없는 규모로 운영되는 기술 회사입니다. 분산 시스템 연구 관점에서 볼 때 이들이 직면한 과제는 엄청납니다.

Amazon이 나에게 취업 기회를 제안했을 때 나는 주저 없이 수락했습니다.

Amazon의 대규모 운영 및 기술 리더십

대부분의 분산된 연구자들은 이러한 대기업뿐만 아니라 심지어 이러한 대기업이 운영되어야 하는 규모를 이미 인식하고 있다고 생각합니다. 인터넷 기업이든 디지털 기업이든 성공하려면 엄청난 규모로 운영되어야 합니다.

2004년을 돌이켜보면, 내가 Amazon에 입사했을 때 많은 사람들은 당시 Amazon의 규모로 운영하는 것이 상대적으로 쉽다고 느꼈을 것입니다. 그러나 이것이 직업이나 필수 인프라에 의존할 수 있다는 의미는 아닙니다. 결과적으로 클라우드 및 기타 기술이 제공하는 이점을 최대한 활용하기 위해 많은 작업이 수행되고 있습니다.

아마존은 2004년에 이를 통해 규모를 달성했지만, 확장 가능한 조직이나 회사를 구축하는 방법을 설명하는 책이나 가이드는 없었습니다. 그래서 저는 Amazon이 기술 채택, 기술 개발, 운영 규모 측면에서 5~10년 앞서 있다고 생각합니다. 이는 급속한 성장을 추구하는 기업에 특히 중요합니다.

빠르게 성장하는 회사가 되고 싶다면 전통적인 비즈니스와 같을 수는 없습니다. 전통적인 기업은 일단 성공하면 매우 느려지는 혁신가의 딜레마에 직면하는 경우가 많습니다.

지속적으로 빠르게 성장하는 회사를 구축하는 방법은 완전히 다른 이야기이므로 비즈니스를 신중하게 평가해야 합니다. 예를 들어, 효율성이 주요 목표이기 때문에 전통적인 기업에서는 기술적 부채를 생성하거나 재발하는 것을 용인하는 것이 불가능합니다.

Amazon에서는 속도, 혁신, 장기적인 실험 파이프라인이 무엇보다 중요합니다. 따라서 당신은 그것을 갚아야 한다는 것을 아는 한 일부 반복되는 일을 기꺼이 용인하고 일부 기술적 부채가 발생하도록 허용할 것입니다.

따라서 전통적인 MBA 서적에서는 아마존이 기꺼이 만들고자 하는 이러한 절충안을 찾기가 어렵습니다. 대부분의 경우 Amazon은 자체 기술, 프로세스 및 비즈니스 프로세스를 개발해야 했습니다. 물론, 미래가 어떤 모습일지, 현대 세계가 어떤 모습이어야 하는지 진정으로 이해하고 있는 Jeff Bezos와 같은 비전 있는 리더들이 있습니다.

성장의 열쇠

Amazon은 대규모로 큰 성공을 거두었지만 더 큰 성장을 달성하는 데는 여전히 어려움에 직면해 있습니다. 다음 단계의 성장으로 나아가기 위해서는 좀 더 엄격하게 생각하고 행동해야 합니다.

한 가지 예는 성능 문제입니다. 성과를 측정하는 방법은 무엇입니까? 측정을 수행하려면 어떤 인프라가 필요합니까? 진정한 데이터 기반 기업이 되고 데이터 기반 의사결정을 내리려면 먼저 데이터를 소유하고 이러한 측정값을 평가하고 해석하는 방법에 대한 문화를 구축해야 합니다.

웹 페이지 로드 시간이 1.2초만 지연되어도 고객 경험에 부정적인 영향을 미칠 수 있습니다. 이는 단지 고객 경험의 50%가 더 나쁘다는 것을 보여주며, 그것이 얼마나 나쁜지 이해해야 합니다. 엔지니어링 관점에서 볼 때 99% 또는 99.9%와 같은 제어도 더욱 중요해집니다. 그런 다음 엔지니어링 분야의 99%를 실제로 포착하고 이를 비즈니스 의사결정에 연결할 수 있는 메커니즘을 구축해야 합니다.

2004년에는 우리의 신뢰도가 꽤 높았던 것 같아요. 특정 지역(SEA)의 데이터 센터를 사용해야 하는 등 우리를 묶는 몇 가지 규칙이 있습니다. 이러한 SEA 데이터 센터에서 수행하는 작업은 다른 데이터 센터에 복제되어야 하나의 데이터 센터가 중단되더라도 고객이 영향을 받지 않습니다.

고객에게 지연이 발생할 수 있지만 기능에는 영향을 미치지 않습니다. 어느 날 데이터 센터 중 하나의 연결을 끊고 무슨 일이 일어나는지 알아보기로 결정하기 전까지 우리는 이러한 모든 규칙을 매우 잘 처리했습니다. 네트워크를 약간만 조정하면 하나의 데이터 센터를 다른 데이터 센터와 격리할 수 있습니다.

그러나 실제로는 종이에 멋지게 보이는 이 모든 것들이 실제로는 생각만큼 잘 작동하지 않습니다. 수동 데이터베이스 장애 조치와 같은 첫 번째 시도에는 여전히 많은 수동 프로세스가 포함되어 있었지만 우리는 이를 일년 내내 연습해 왔습니다. 그리고 세 번째 또는 네 번째 실행에 도달할 때쯤에는 실제로 사람의 개입 없이 거의 자동화할 수 있는 지점에 도달한 것입니다. 이는 시스템의 고가용성과 내결함성을 보장하는 데 중요합니다.

우리는 노력의 일환으로 데이터 분석 및 통찰력 개발에도 중점을 두고 있습니다. Amazon에는 많은 데이터가 있지만 그로부터 귀중한 통찰력을 얻는 것은 어려운 일입니다. 우리는 고객 행동, 시장 동향 및 비즈니스 기회를 이해하는 데 도움이 되는 강력한 데이터 분석 도구와 모델을 구축하기 위해 최선을 다하고 있습니다. 이러한 데이터 기반 접근 방식을 통해 우리는 더 나은 결정을 내리고 개인화된 제품과 서비스를 제공할 수 있습니다.

또한, 우리는 사용자 경험을 개선하기 위해 최선을 다하고 있습니다. 쇼핑 과정에서 사용자의 요구와 선호도를 심층적으로 조사하고, 디자인 최적화, 인터페이스 개선, 개인화된 추천을 통해 사용자 경험을 개선했습니다. 우리는 고객의 기대에 부응하고 충성도를 높이는 간단하고 직관적이며 원활한 쇼핑 경험을 추구합니다.

CTO의 역할 변화

기술 공급업체가 된 후에는 CTO로서의 역할이 달라집니다.

나는 블로그 게시물 에서 이것 에 대해 이야기 했습니다 . 제 생각에는 CTO에게는 네 가지 유형의 책임이 있습니다.

• 첫 번째는 일반적으로 인프라 관리를 담당하고 CIO에게 보고하며 대규모 인프라 관리를 담당하는 엔터프라이즈 수준의 CTO입니다.
• 두 번째 유형은 젊은 기업에서 흔히 볼 수 있는 기술 공동 창업자 CTO로 기술적인 비전을 가지고 있습니다. 하지만 이 역할에는 엔지니어링 팀 관리 등 다른 많은 것들이 포함되기 때문에 약간의 위험이 있다고 생각합니다. CTO가 반드시 이러한 문제를 잘 처리할 수는 없지만 이에 대해서는 나중에 자세히 설명하겠습니다.
• 세 번째 유형은 혁신의 발전을 촉진하는 Big Thinker의 특성을 지닌 CTO입니다. 예를 들어 AT&T나 Lucent와 같은 회사에는 차세대 기술을 연구하고 실험하는 데 전념하는 CTO 또는 CTO 사무실이 있습니다.
• 마지막 유형은 다른 회사에 기술 공급업체 역할을 하면서 고객과 심층적인 기술 상호 작용을 수행하고, 고객이 제품을 사용하는 방식을 이해하고, 더 깊고 광범위한 패턴과 패턴을 찾는 일을 담당하는 외부 기술 전문가 CTO입니다. . 고객의 불만 사항. 이런 역할은 자신의 기술에만 집중하는 것이 아니라 전체적인 상황에 더 많은 관심을 기울이는 역할이다.

이러한 역할은 기술 중심이 아닌 고객 중심이라는 점을 기억하는 것이 중요합니다. 고객 피드백을 회사에 다시 전달하고 고객에게 더 나은 서비스를 제공하기 위해 어떤 새로운 기능이나 제품을 개발해야 하는지, 어떤 프로세스를 변경해야 하는지 생각하는 것이 중요합니다.

따라서 기술 공급업체로서 CTO의 역할은 기술 자체에만 초점을 맞추는 것이 아니라 고객 지향적입니다.

아마존의 독특한 문화

아마존은 저의 첫 실제 직업이었기 때문에 다른 곳의 직장 문화도 아마존과 비슷할 거라고 오랫동안 생각했는데 사실은 그렇지 않더라고요.

Amazon은 빠르게 성장하는 회사에 매우 잘 맞는 독특한 문화를 가지고 있습니다. 그들은 팀이 가능한 한 독립적이 되도록 장려하고 조직 계층과 구조를 줄입니다. 그들에게는 계층 구조가 부자연스러워 보입니다.

그들은 자기 조직화 팀을 갖고 싶고, 진정으로 독립적으로 일하고 제품을 소유하고 싶어하는 사람들을 고용하기를 원합니다. 추종자나 코더가 아닌 젊은 기업에는 특히 이것이 필요합니다.

아마존은 고객 집착, 주인의식, 딥 마이닝 등 14가지 원칙을 포함한 일련의 리더십 원칙을 갖고 있으며 이는 기업 문화 발전을 주도합니다.

Amazon에서는 문화적으로 부적절한 직원이 소규모 팀에 매우 지장을 줄 수 있기 때문에 채용 인터뷰도 주로 문화 적합성에 중점을 두고 있습니다. Amazon은 일반적으로 10~12명으로 구성된 소규모 팀을 높이 평가하며, 각 구성원은 자신의 작업을 알고 있습니다.

비즈니스가 성장함에 따라 CTO의 역할은 처음에는 모든 기술 관련 문제를 담당하는 것에서 점차적으로 팀 관리에 초점을 맞추고 엔지니어가 필요한 기술과 제품을 제공할 수 있도록 하는 것으로 진화합니다.

엔지니어링 부사장에 비해 CTO는 올바른 기술 구축 및 올바른 도구 사용과 같은 기술적 측면에 더 중점을 둡니다.

아마존은 어떻게 성장했나요?

Amazon은 내부적으로 일련의 변화를 겪었습니다. 그들은 스타트업처럼 보이는 독립적인 팀을 만들고 자신의 목표와 혁신 의제에 대한 소유권을 갖습니다. 그러나 과거 Amazon은 빠르게 성장하기 위해 아키텍처 원칙을 위반하여 백엔드 데이터베이스 인프라가 취약하고 성장할 수 없는 결과를 낳았습니다.

효율성 저하 문제를 해결하기 위해 그들은 서비스 지향 아키텍처로 전환하여 시스템을 마이크로서비스라고 알려진 독립적인 기능 빌딩 블록으로 분할했습니다.

그러나 팀이 성장함에 따라 각 서비스는 자체 데이터베이스를 관리해야 하므로 커뮤니케이션은 증가하지만 혁신은 감소합니다.

이러한 상황을 개선하기 위해 가상화 기술과 API를 사용해 서버를 관리하는 공유 서비스 플랫폼을 만들었습니다. 먼저 내부적으로 이러한 기술을 구축한 다음 Amazon S3 및 EC2와 같은 외부 제품을 출시했습니다. 이러한 서비스는 스토리지 및 컴퓨팅 성능을 프로그래밍 및 확장 가능하게 만들어 기업에 매우 비용 효율적입니다.

Amazon은 인터넷 규모의 스토리지 및 컴퓨팅 성능을 달성하고 모든 유형의 비즈니스에 서비스를 제공하는 것을 목표로 합니다.

혁신으로 가는 길

Amazon의 혁신은 두 가지 수준으로 나뉩니다.

• 첫 번째는 팀 차원의 혁신으로, 각 팀은 내년을 위한 자체 혁신 계획을 개발하고 추천 엔진을 개선하여 반품 횟수를 줄이는 등 독립적으로 작업을 완료하는 책임을 맡습니다. 그들은 로드맵을 매핑하고, 새로운 데이터 소스를 확보하고, 다양한 방식으로 고객과 상호 작용하는 일을 담당합니다.
• 또 다른 수준은 Kindle 및 Amazon Prime과 같이 상당한 자본 투자가 필요한 혁신입니다. 이러한 프로젝트에는 상당한 재정적 지원이 필요합니다. 아마존은 혁신적인 프로젝트가 성공할 가능성이 있고 회사의 대차대조표에 상당한 영향을 미칠 경우에만 대규모 자본 투자를 한다는 규칙을 세웠습니다.

Amazon은 기술 초기에 내린 결정 중 일부가 현명한 결정이라는 것을 깨달았고, 규모가 확장됨에 따라 아키텍처를 재검토하고 변화에 적응할 소프트웨어를 개발해야 했습니다. 여기에는 스토리지 엔진과 같은 기술적 문제를 처리하기 위해 여러 아키텍처와 버전을 사용하는 것이 포함됩니다.

또한 다른 회사와 마찬가지로 Amazon은 기술 확장 외에도 판매, 솔루션 아키텍처, 기술 계정 관리자, 고객 지원과 같은 비기술적 요소를 해결해야 할 필요성을 발견했습니다. 이러한 요소는 모두 성공적인 회사를 구축하는 데 필요합니다.

새로운 서비스를 출시하는 방법은 무엇입니까?

우리가 제공하는 기능과 서비스의 약 95%가 직접적인 고객 요구에 부응하기 때문에 우리는 모든 팀이 고객과 긴밀한 접촉을 유지할 것으로 기대합니다. 처음에 우리가 구축한 초기 서비스는 기본 IT 인프라, 스토리지, 컴퓨팅, 데이터베이스, 네트워크 및 보안을 포함하여 거의 모든 고객 기대를 충족할 수 있었습니다.

그러나 시간이 지남에 따라 고객은 다양한 다른 요구 사항을 제시했습니다. 그들은 분석 기능, 클라우드 기술, 모바일 개발은 물론 블록체인과 같은 다른 기술도 원하며 이러한 기술을 관리할 필요 없이 사용할 수 있기를 원합니다. 따라서 고객이 올바른 기능과 도구를 구축하도록 돕는 것이 매우 중요합니다.

새로운 제품과 서비스를 출시할 때 우리는 최소 기능 세트(MVP)를 사용하여 출시하는 강력한 문화를 따릅니다. 그러나 이는 비즈니스에 필요한 기술을 구축하기 위한 시작점일 뿐입니다. 우리는 불안정한 것을 출시할 수는 없으며 그것이 안정적이고 신뢰할 수 있는지 확인해야 합니다. 그런 다음 고객과 협력하여 추가 기능의 필요성을 탐색합니다.

제품의 초기 단계에서는 고객에게 어떤 추가 기능이 필요할지 항상 알 수는 없습니다. 예를 들어 DynamoDB를 출시했을 때 고객이 보조 인덱스를 원하는지 전혀 몰랐습니다. 우리가 처음부터 이를 제안하지는 않았지만 이것이 고객이 원하는 바임은 분명했습니다. 최소한의 기능 세트로 서비스를 출시하여 고객이 제품을 어떻게 사용하는지 관찰하고, 점차적으로 새로운 기능과 서비스를 반복하고 추가합니다.

예를 들어, Lambda를 출시했을 때 서버와 같은 다른 사항을 생각할 필요 없이 코드를 작성하고 S3에 배포하는 것만 큼 간단하게 개발할 수 있는 서버리스 환경이었습니다. 실제로 사용한 만큼만 비용을 지불하고 유휴 시간 등에 대해 걱정할 필요가 없습니다.

이는 고객이 제품을 어떻게 사용하는지 관찰할 수 있다는 점에서 개발 프로세스를 변경합니다. 그들은 X-Ray 디버깅 환경과 유사한 방식으로 빠르게 반복을 시작했으며 래더링 기능을 사용하여 보다 복잡한 애플리케이션을 구축했습니다. 고객의 사용 습관을 관찰하여 고객의 요구 사항을 이해합니다.예를 들어 DynamoDB에서는 보조 데이터 센터보다 보조 인덱스가 고객에게 더 중요하다는 것을 깨달았습니다.

기본적으로 고객은 로드맵을 재정의했고 우리는 고객에게 가장 중요한 기능을 제공하기 시작했습니다. 이것은 매우 중요한 부분입니다. MVP처럼 보이더라도 사람들이 그 위에 비즈니스를 구축하고 의존할 것이기 때문에 MVP로 간주할 수 없습니다. 결과적으로 제품을 중심으로 다른 문화 구조가 발전합니다.

작년에 우리는 1,400개의 새로운 기능과 서비스를 출시했으며, 팀 수가 늘어남에 따라 그 숫자도 계속해서 늘어날 것입니다. 우리는 AWS에서도 동일한 구조를 사용합니다. 각 팀은 특정 고객 그룹과 협력하고 고객의 요구 사항에 따라 로드맵을 구축합니다. 서비스가 성장함에 따라 로드맵도 성장했습니다.

그러나 이는 빠르게 발전하는 환경이며 소프트웨어가 구축되는 방식도 크게 바뀌었습니다. 고객이 소프트웨어를 개발하는 방법을 결정할 수 있다면 우리는 여전히 5년 또는 10년 전과 같은 방식으로 소프트웨어를 개발하고 있을 것입니다. 대신, 고객과 긴밀히 협력하고 고객이 혁신 엔진을 구동할 수 있도록 하여 2020년 또는 2025년에 소프트웨어 개발을 시작해야 합니다.

따라서 고객을 대신하여 결정을 내리는 대신 고객과 긴밀히 협력하여 고객이 혁신 엔진을 구동하도록 해야 합니다. 우리는 고객이 제품을 어떻게 사용하는지 면밀히 관찰하고 피드백을 기반으로 지속적으로 반복하고 개선해야 합니다.

일반적으로 Amazon Web Services(AWS)는 팀 수준의 혁신과 자본 투자에 대한 이중 접근 방식을 취합니다. AWS는 고객과 긴밀히 협력하고, 고객의 요구 사항을 이해하고, 사용 습관을 관찰함으로써 고객 요구 사항을 충족하는 기능과 서비스를 제공할 수 있습니다. 동시에 AWS는 변화하는 시장 요구 사항을 충족하기 위해 연구 개발과 새로운 제품, 서비스 및 기능 출시에 많은 자본을 투자합니다.

이러한 혁신적인 접근 방식을 통해 AWS는 고객과 긴밀한 관계를 유지하여 고객의 기대에 부응하는 안정적이고 신뢰할 수 있는 솔루션을 제공할 수 있습니다. AWS는 최소한의 기능 세트와 지속적인 반복 접근 방식을 기반으로 한 출시 전략을 통해 고객 요구에 신속하게 대응하고 더욱 발전된 기능과 서비스를 지속적으로 제공할 수 있습니다.

Amazon이 혁신을 향한 길은 항상 고객을 중심으로 하는 끊임없는 진화와 개발의 과정입니다. 고객 요구 사항을 깊이 이해하고, 고객 사용 습관을 관찰하고, 연구 개발에 지속적인 투자를 통해 AWS는 지속적으로 기술과 비즈니스 발전을 촉진하고 고객에게 우수한 클라우드 컴퓨팅 솔루션을 제공하고 있습니다.

고객 중심 제품 구축

우리는 고객 옆에서 일하든 Amazon 내부에서 일하든 어디에나 있습니다. 기술 회사로서 우리는 고객에게 진정으로 중요한 것을 개발하는 데 중점을 두고 있습니다. 우리는 중공업 기업이지만 엔지니어링과 엔지니어도 위험을 안고 있습니다.

우리는 기술뿐만 아니라 제품에도 집중합니다. 우리는 고객을 위해 무엇을 할 수 있는지 알고 싶습니다. 우리는 놀라운 기술을 구축하기 위해 최선을 다하고 있지만 그것이 우리 행동의 유일한 동기는 아닙니다. 우리가 관심을 갖는 것은 고객의 문제를 해결하는 것입니다.

우리는 계속해서 고객에게 초점을 맞추기 위해 역방향 작업이라는 프로세스를 사용합니다. 먼저, 우리는 우리가 구축할 제품을 명확하고 간결하게 설명하는 보도 자료를 작성합니다. 그런 다음 20가지 자주 묻는 질문이 포함된 문서를 준비하고 간단하고 명확한 언어로 답변합니다. 더 복잡한 경우에는 우리가 만들고 싶은 것이 무엇인지 명확하게 알 때까지 두 문서를 반복해야 할 수도 있습니다.

다음으로 고객이 제품을 사용하는 방법과 제품과 상호 작용하는 방법을 자세히 설명하는 사용자 경험(UX) 문서를 작성합니다. 우리는 또한 사용자 매뉴얼, 용어집 및 기타 관련 문서를 작성합니다.

결국 우리는 우리가 원하는 작업을 정확하게 설명하는 4개의 문서 세트를 얻게 됩니다.

Amazon으로서 우리는 항상 약속한 것보다 더 많은 비용을 청구하지 않는다는 원칙을 준수합니다. 우리는 두 번째 버전의 기능을 첫 번째 버전에 임의로 추가하지 않습니다. 우리는 약속한 기능을 구축하는 것에만 집중합니다. 이 접근 방식은 고객 요구, 제품 경험 및 기술에 대해 생각할 수 있는 강력한 구조를 제공합니다.

Amazon 컨퍼런스에서는 슬라이드나 기조연설을 사용하지 않습니다. 6페이지짜리 메모라는 문서가 있는데 회의 30분 전에 모두가 조용히 읽어요. 이 메모는 모든 사람이 우리가 논의하는 내용을 명확하게 이해할 수 있도록 하기 때문에 매우 중요합니다.

스토리를 작성하는 것은 어렵기 때문에 협업과 피드백을 장려합니다. 우리는 기능, 제품 또는 사업 영역에 대한 명확한 설명이 나올 때까지 이 메모를 여러 번 수정하고 개선합니다. 30분 동안 책을 읽고 나면 방에 있는 모든 사람이 같은 생각을 하게 되어 양질의 토론이 가능해집니다.

요약하자면, 우리는 고객 문제를 해결하고 탁월한 제품과 서비스를 제공하는 데 계속 집중할 수 있는 고유한 문화와 프로세스를 보유하고 있습니다.

컨테이너 기술

특히 더 많은 마이크로서비스 환경을 추구함에 따라 점점 더 많은 기업이 컨테이너 기술을 건너뛰고 있습니다. 컨테이너 기술이 인기를 얻은 이유 중 하나는 구성 요소를 쉽게 확장 및 축소할 수 있다는 점인데, 이는 마이크로서비스 개념과 일치합니다. 많은 사람들이 특히 서버리스 환경에서 개발을 위해 모놀리식 단계에서 컨테이너를 분리하기 시작했습니다.

그러나 컨테이너 기술을 사용하기 전, 특히 Fargate가 제공되기 전에는 몇 가지 문제가 있었습니다. 여러 가용성 영역에서 실행되는 여러 컨테이너를 관리하고 이를 가상 머신에 매핑해야 합니다. 따라서 컨테이너는 훌륭한 개발 옵션이지만 컨테이너를 실행하고 관리하는 데는 많은 작업이 필요합니다. 이 프로세스를 단순화하기 위해 우리는 기본적으로 기본 가상 머신의 모든 관리를 제거하고 실행을 위해 컨테이너를 여기에 놓기만 하는 Fargate라는 솔루션을 제공합니다.

앞으로는 더욱 복잡한 서버리스 환경을 구축할 수 있는 능력을 중심으로 개발된 도구, 지원 플랫폼, 인프라가 점점 더 많아질 것이라고 생각합니다. 다른 서비스와의 더 나은 통합은 개발 방향 중 하나가 될 것입니다.

*딥 트렌드 노트: Fargate는 Amazon Web Services(AWS)에서 제공하는 컴퓨팅 서비스로, 서버리스 컴퓨팅 엔진입니다. Fargate를 사용하면 개발자가 기본 인프라 및 서버에 대해 걱정할 필요 없이 컨테이너화된 애플리케이션을 더 쉽게 관리하고 배포할 수 있습니다.

컨테이너 기술은 애플리케이션과 해당 종속성을 독립적인 휴대용 컨테이너에 패키징하여 애플리케이션의 신속한 배포와 이식성을 가능하게 하는 가상화 기술입니다. 컨테이너 기술은 컨테이너 엔진(예: Docker)을 사용하여 컨테이너를 생성, 관리 및 실행하므로 기본 인프라의 차이에 대한 걱정 없이 다양한 컴퓨팅 환경에서 애플리케이션이 일관되게 실행될 수 있습니다. 컨테이너화 기술은 최신 애플리케이션 개발 및 배포에 널리 사용되어 더 뛰어난 유연성, 확장성 및 이식성을 제공합니다.

고객 보호

하지만 보안 문제가 초점이 될 것이라고 생각합니다. 향후 5년 동안 모든 사람은 보안을 최우선 과제로 삼아야 하며, CEO, CTO, 엔지니어 등 우리 모두는 보안에 대해 인식하고 보안 엔지니어의 역할을 수행해야 합니다. 기술 전문가이자 디지털 비즈니스 리더로서 우리는 지난 몇 년간 매주 발생한 대규모 데이터 유출 사고에 당황하고 분노해야 합니다. 고객을 보호하지 않으면 비즈니스가 없기 때문에 고객의 데이터를 보호하는 것은 우리의 책임입니다.

우리는 자동차 렌트든 다른 소비자 서비스든 고객으로부터 수집한 데이터를 보호하는 방법에 대해 생각해야 합니다. 지속적인 통합 및 지속적인 배포 파이프라인에서 보안 이벤트를 트리거하는 등 보안이 기본 부분이 되어야 하며, 추가 시 새로운 오픈 소스 라이브러리를 검토하고 평가해야 합니다.

개발 파이프라인 자체도 안전해야 하며 취약성 테스트를 위한 다양한 자동화 도구를 갖추고 있어야 합니다. 특히 의료 및 금융 분야에서는 준수해야 할 다양한 규정과 규제 요구 사항이 있습니다.

5년 후에는 우리 모두가 보안 문제를 극도로 인식하고 고객 보호를 최우선으로 생각하기를 바랍니다. Amazon에서는 지적 자본과 금융 자본 측면에서 고객을 보호하는 것이 항상 최고의 투자 영역이 될 것입니다.

스타트업이 AWS를 사용할 때 저지르는 일반적인 실수

첫째, 기존 데이터 센터 경험이 있는 사람들이 처음으로 AWS를 사용하면 자신감이 부족할 수 있습니다. AWS는 복원력과 가용성 측면에서 장점이 있지만, 특히 높은 안정성을 추구하는 대규모 개발에서는 보안, 데이터 분석, 모빌리티 등 더 높은 수준의 서비스를 사용하지 않으면 AWS의 잠재력을 최대한 발휘할 수 없습니다.

둘째, 회사의 유형과 목표를 결정하는 것이 핵심입니다. 기업 스타일에는 두 가지가 있는데, 하나는 빠른 성장과 다수의 고객을 추구하는 회사로, 수익보다는 빠른 확장과 가능한 인수에 많은 투자를 하는 회사이고, 다른 하나는 지속 가능한 발전을 추구하는 회사입니다. 인수에만 집중하기보다는 장기적인 비즈니스를 구축하세요.

이 두 유형의 회사는 완전히 다른 방식으로 AWS를 사용합니다. 빠른 성장을 추구하는 기업이라면 비용 문제에 대해 크게 걱정할 필요가 없기 때문에 AWS가 제공하는 용량과 서비스를 더욱 안심하고 활용할 수 있습니다. 지속 가능한 개발을 추구하는 기업의 경우 다양한 아키텍처를 구축하고, 비용 관리에 더 많은 주의를 기울이고, 비용과 고객 확보 사이에 명확한 관계가 있는지 확인해야 합니다.

스타트업 창업자에 관해 제프 베조스는 종종 용병과 선교사를 구별합니다. 용병은 돈을 추구하기 위해 기업가 정신을 시작하는 반면, 선교사는 제품에 대한 사랑 때문에 사업을 시작합니다. 둘 다 사업을 시작하는 유효한 방법이지만 구축된 기술 지원과 기술 아키텍처는 다릅니다.

따라서 귀하가 어떤 유형의 회사인지 명확히 파악하고 이에 따라 적합한 기술 지원 및 아키텍처를 선택하십시오.