아마존 CTO와의 대화: 아마존 내부에서 들려오는 이야기, 통찰과 비밀
번역: TechFlow
참고: 본 문서는 TechFlow 특별 기획 『YC 창업 강의 중문 노트』(매일 업데이트, 이번 편이 해당 시리즈의 마지막 편)에 수록되었으며, YC 강의의 중문 버전을 수집·정리하는 것을 목적으로 합니다. 제25편은 아마존 최고기술책임자(Werner Vogels)의 온라인 강의 『기술과 스타트업에 대한 경험과 통찰』입니다.
아마존 입사 전
아마존에 합류하기 전 저는 학자로서 코넬 대학교에서 10년간 대규모 분산 시스템 연구를 수행했습니다. 그 이전에는 전형적인 컴퓨터 과학자는 아니었습니다. 28세가 되어서야 비로소 진지하게 공부하러 돌아가기로 결정했죠. 그 전에는 병원에서 방사선 치료사로 일하며 네덜란드 암연구소 환자들을 치료하고 있었습니다. 그러던 어느 날, 주변 사람들이 하나둘씩 세상을 떠나는 모습을 더 이상 견딜 수 없다는 생각이 들었고, 그래서 전혀 다른 일을 시작하기로 결심했습니다. 컴퓨터 과학은 좋은 선택처럼 보였습니다.
당시는 1980년대 중반으로, 오늘날처럼 컴퓨터 과학이 대중화되어 있진 않았습니다. 하지만 운 좋게도 저에게는 재능이 있었던 것으로 밝혀졌습니다. 물론 그 당시엔 그런 줄 몰랐지만 말이죠. 그래서 제가 진심으로 관심을 갖는 분야를 깊이 파고들게 되었고, 박사 학위를 취득한 후 포르투갈의 한 연구기관에서 몇 년간 근무하다가 코넬 대학교에서 초청을 받았습니다.
코넬 재직 당시 저는 연구 외에도 HP 같은 대기업들뿐 아니라 이름이 잘 들리지 않는 다른 회사들의 자문도 종종 맡았으며 다양한 컨퍼런스에 참여했습니다. 어느 때는 아마존이 제가 연구 중인 내용을 소개해달라고 요청했죠. 처음엔 다소 당황스럽고 혼란스러웠습니다. 정말 내가 해야 할 일인가?
그 당시만 해도 웹 브라우징과 데이터베이스는 얼마나 어려운 문제였습니까? 그러나 실제로 작업을 시작하면서, 이것이 실로 거대한 기술적 도전이라는 것을 깨달았습니다. 아마존은 단순한 유통업체가 아니라 기술 회사이며, 운영 규모가 제가 이전에 접했던 어떤 회사와도 비교할 수 없을 정도였습니다. 분산 시스템 연구 관점에서 보면 그들이 직면한 문제들은 놀라울 정도였습니다.
아마존에서 일자리를 제안받았을 때 저는 망설임 없이 수락했습니다.
아마존의 대규모 운영과 기술 선도성
대다수의 분산 시스템 연구자들은 이제 이러한 대기업들이 얼마나 큰 규모로 운영되어야 하는지를 인식하게 되었으며, 이는 단지 대기업에 국한되지 않습니다. 인터넷 기업이나 디지털 기업이라면 성공하기 위해 반드시 거대한 규모로 운영되어야 합니다.
2004년 제가 아마존에 합류했을 당시를 돌아보면, 당시 아마존의 규모로 운영하는 것은 비교적 쉬워 보일 수 있습니다. 하지만 그렇다고 해서 특정 직책이나 필수 인프라에 의존할 수 있는 것은 아닙니다. 따라서 클라우드 기술 및 기타 기술 분야에서 많은 작업을 통해 제공되는 장점을 충분히 활용할 수 있도록 했습니다.
2004년 아마존은 오직 실천을 통해 일정한 규모에 도달했으며, 확장 가능한 조직이나 회사를 구축하는 방법을 설명해주는 책이나 가이드는 존재하지 않았습니다. 따라서 아마존은 기술 적용, 기술 발전, 운영 규모 측면에서 5~10년 앞서가는 위치에 있었다고 생각합니다. 이는 급속한 성장을 추구하는 기업에게 특히 중요합니다.
신속하게 성장하는 기업이 되고 싶다면 전통적인 기업처럼 행동해서는 안 됩니다. 전통 기업은 일반적으로 '혁신자의 딜레마'에 빠지며, 일단 어떤 일이 성공하면 매우 느려지는 경향이 있습니다.
지속적으로 빠르게 성장하는 기업을 만드는 것은 완전히 다른 이야기이며, 사업을 신중하게 따져봐야 합니다. 예를 들어 기술 부채를 만들거나 반복되는 상황을 감내하는 것 등은 전통 기업에서는 불가능합니다. 효율성이 그들의 주요 목표이기 때문입니다.
아마존에서는 속도가 빠르고, 혁신 속도도 빠르며 장기적인 실험 파이프라인이 가장 중요합니다. 따라서 반복되는 일을 일부 감내하고 기술 부채를 발생시키는 것도 용인되지만, 반드시 이를 갚아야 한다는 것을 알고 있어야 합니다.
따라서 전통적인 MBA 교재에서는 아마존이 감수하는 이러한 타협을 찾기 어렵습니다. 대부분의 경우 아마존은 자체적으로 기술, 프로세스, 비즈니스 프로세스를 개발해야 했습니다. 물론 제프 베조스처럼 미래의 형태와 현대 사회가 어떻게 되어야 할지 진정으로 이해하는 비전 있는 리더가 있었기에 가능했습니다.
성장을 실현하는 핵심
아마존은 이미 규모 면에서 큰 성공을 거두었지만, 더 큰 성장을 실현하기 위한 도전에 여전히 직면해 있습니다. 다음 성장 단계로 나아가기 위해서는 더욱 철저하게 사고하고 행동해야 합니다.
예를 들어 성능 문제가 있습니다. 어떻게 성능을 측정할 것인가? 측정을 위해 어떤 인프라가 필요한가? 진정한 데이터 기반 기업이 되고 데이터 기반 의사결정을 하기 위해서는 먼저 데이터를 확보하고, 측정 데이터를 평가하고 해석하는 문화를 만들어야 합니다.
웹페이지 로딩 시간이 1.2초만 늦어져도 고객 경험에 부정적인 영향을 미칩니다. 이는 고객 경험의 50%가 악화된다는 의미이며, 얼마나 심각한 상황인지 이해해야 합니다. 공학적 관점에서 보면 99% 또는 99.9%의 제어도 점점 더 중요해집니다. 그리고 99%의 엔지니어링 분야를 진정으로 장악할 수 있는 메커니즘을 구축하고 이를 비즈니스 의사결정과 연결해야 합니다.
2004년 당시 우리의 신뢰성은 상당히 높았다고 생각합니다. 우리는 특정 지역(SEA) 데이터센터를 사용해야 한다는 규칙을 지켜야 했습니다. SEA 데이터센터에서 수행하는 모든 작업은 다른 데이터센터에서도 복제되어야 했으며, 이렇게 함으로써 하나의 데이터센터에 장애가 발생하더라도 고객에게 영향을 주지 않도록 했습니다.
고객은 지연의 영향을 받을 수 있지만 기능에는 영향을 받지 않습니다. 이러한 모든 규칙을 처리하는 데 매우 능숙했으며, 어느 날 하나의 데이터센터 연결을 끊고 무슨 일이 벌어질지 실험하기로 결정했습니다. 네트워크를 약간 조정하면 한 데이터센터를 다른 데이터센터로부터 격리시킬 수 있습니다.
그러나 실제로는 종이 위에서 보기엔 훌륭해 보이는 모든 것이 실전에서는 사람들의 예상만큼 순조롭지 못했습니다. 첫 시도 때는 수동 데이터베이스 장애 조치와 같은 수많은 수동 프로세스가 포함되어 있었고, 그 해 동안 우리는 계속 연습했습니다. 세 번째나 네 번째 실행 시에는 거의 인간 개입 없이 자동화하여 실행할 수 있는 수준에 도달하게 됩니다. 이는 시스템의 고가용성과 내결함성을 보장하는 데 매우 중요합니다.
노력 과정에서 우리는 또한 데이터 분석과 인사이트 개발에 주력했습니다. 아마존은 방대한 양의 데이터를 보유하고 있지만, 여기서 가치 있는 통찰을 얻는 것은 도전입니다. 고객 행동, 시장 동향, 비즈니스 기회를 이해하는 데 도움이 되는 강력한 데이터 분석 도구와 모델을 구축하기 위해 노력했습니다. 이러한 데이터 중심 접근법은 우리가 더 나은 의사결정을 내리고 맞춤형 제품과 서비스를 제공할 수 있게 해줍니다.
또한 사용자 경험 개선에도 힘썼습니다. 우리는 고객이 쇼핑하는 과정에서의 요구사항과 선호도를 심층적으로 연구하여 디자인 최적화, 인터페이스 개선, 개인화 추천 등을 통해 사용자 경험을 향상시켰습니다. 고객의 기대를 충족시키고 그들의 충성도를 얻기 위해 단순하고 직관적이며 매끄러운 쇼핑 경험을 추구했습니다.
CTO 역할의 변화
기술 공급업체가 된 이후 CTO의 역할은 변화합니다.
저는 한 블로그 글에서 이 문제를 언급한 바 있습니다. 제 생각에 CTO는 네 가지 유형의 책임을 가집니다.
- 첫째는 기업형 CTO로, 일반적으로 인프라 관리를 담당하며 CIO에게 보고하고 대규모 인프라를 관리합니다.
- 둘째는 젊은 기업에서 흔히 볼 수 있는 기술 공동창업자형 CTO로, 기술적 비전을 갖추고 있습니다. 그러나 이 역할은 일정한 위험이 있다고 생각합니다. 왜냐하면 엔지니어링 팀 관리 등 많은 다른 업무들이 이 역할에 포함되기 때문입니다. CTO가 반드시 이런 일들을 잘 처리할 수 있다는 보장은 없으며, 이 부분은 잠시 후 자세히 다루겠습니다.
- 셋째는 큰 아이디어를 가진 '사상가'형 CTO로, 혁신을 추진합니다. AT&T나 루슨트(Lucent) 같은 회사의 CTO 또는 CTO 오피스처럼 차세대 기술을 연구하고 실험하는 역할을 수행합니다.
- 넷째는 외부 지향적인 기술 전문가형 CTO로, 다른 기업에 기술을 제공할 때 고객과 심층적인 기술적 소통을 하며 고객이 제품을 어떻게 사용하는지 이해하고, 더 깊고 광범위한 패턴과 고객의 고통점을 찾아냅니다. 이 역할은 자체 기술뿐만 아니라 전체 상황을 더욱 중시합니다.
이러한 역할들은 기술 중심보다 고객 중심에 더 가깝다는 점에 주목해야 합니다. 고객의 피드백을 회사로 가져와 어떤 새로운 기능이나 제품을 개발해야 하고, 어떤 프로세스를 변경해야 고객을 더 잘 지원할 수 있을지 생각하는 것이 중요합니다.
따라서 기술 공급업체로서의 CTO 역할은 기술 자체보다 고객 중심성이 더욱 강조됩니다.
아마존만의 독특한 문화
아마존은 제 첫 번째 본격적인 직장이었기 때문에 오랫동안 다른 회사들도 아마존과 비슷한 문화에서 일한다고 생각했습니다. 하지만 실제로는 그렇지 않았습니다.
아마존은 빠르게 성장하는 기업에 매우 효과적인 독특한 문화를 가지고 있습니다. 그들은 팀이 가능한 한 독립적으로 운영되기를 원하며, 조직의 계층과 구조를 최소화합니다. 그들에게 있어서 계급 구조는 자연스럽지 않은 것으로 여겨집니다.
그들은 자기조직화 팀을 원하며, 스스로 독립적으로 일하고 제품에 주인의식을 가진 사람들을 고용합니다. 젊은 기업일수록 추종자나 코더보다 이런 인재가 필요합니다.
아마존에는 고객 집착, 책임감, 심층 분석 등 14가지 리더십 원칙이 있으며, 이는 그들의 문화를 형성하는 데 기여합니다.
아마존에서는 채용 면접도 주로 문화 적합성 중심으로 이루어집니다. 왜냐하면 문화에 어울리지 않는 직원은 소규모 팀에 큰 방해가 되기 때문입니다. 아마존은 일반적으로 10~12명으로 구성된 소규모 팀을 매우 중시하며, 각 구성원은 자신의 역할을 명확히 알고 있습니다.
기업이 성장함에 따라 CTO의 역할도 변합니다. 처음에는 모든 기술 관련 업무를 담당하지만, 점차 팀 관리와 엔지니어들이 필요한 기술과 제품을 제공할 수 있도록 보장하는 데 집중하게 됩니다.
공학 부사장(VP of Engineering)과 비교하면 CTO는 올바른 기술 구축과 적절한 도구 사용 등 기술 측면에 더욱 집중합니다.
아마존은 어떻게 성장했는가?
아마존 내부에서는 여러 변화가 있었습니다. 그들은 마치 스타트업처럼 보이는 독립적인 팀을 만들었으며, 각 팀은 자체 목표와 혁신 계획을 수립했습니다. 그러나 과거에는 빠른 성장을 위해 아키텍처 원칙을 위반하여 백엔드 데이터베이스 인프라가 취약해지고 더 이상 성장할 수 없는 상태가 되었습니다.
효율성이 저하되는 문제를 해결하기 위해 서비스 지향 아키텍처(SOA)로 전환하여 시스템을 독립적인 기능 블록인 마이크로서비스로 분리했습니다.
그러나 팀이 증가함에 따라 각 서비스가 자체 데이터베이스를 관리해야 하면서 소통은 늘었지만 혁신은 줄어들었습니다.
상황을 개선하기 위해 그들은 공유 서비스 플랫폼을 만들었으며, 서버 관리를 위해 가상화 기술과 API를 사용했습니다. 먼저 내부적으로 이러한 기술을 구축한 후 Amazon S3와 EC2 같은 제품을 외부에 출시했는데, 저장 및 컴퓨팅 능력을 프로그래밍 가능하고 확장 가능한 형태로 만들어 기업 입장에서 매우 비용 효율적이었습니다.
아마존의 목표는 인터넷 규모의 저장 및 컴퓨팅 능력을 실현하고 다양한 유형의 기업에 서비스를 제공하는 것입니다.
혁신의 길
아마존의 혁신은 두 가지 수준으로 나뉩니다.
- 첫째는 팀 수준의 혁신으로, 각 팀은 다음 해의 혁신 계획을 수립하고 독립적으로 작업을 수행합니다. 예를 들어 추천 엔진을 개선하여 반품 수량을 줄이는 작업을 담당합니다. 그들은 로드맵을 작성하고, 새로운 데이터 소스를 확보하며, 고객과 다른 방식으로 상호작용하는 책임을 맡습니다.
- 다른 하나는 Kindle, Amazon Prime과 같이 대규모 자본 투자가 필요한 혁신입니다. 이러한 프로젝트는 막대한 자금을 필요로 합니다. 아마존은 혁신 프로젝트가 성공할 가능성이 있고 회사의 재무제표에 중대한 영향을 미칠 수 있을 때만 대규모 자본 투자를 진행한다는 규정을 정했습니다.
아마존은 기술 초기에 내린 일부 결정들이 매우 현명했다는 것을 깨달았으며, 규모가 커짐에 따라 아키텍처를 다시 검토하고 변화에 적응할 수 있는 소프트웨어를 개발해야 했습니다. 이것은 저장 엔진 등의 기술적 도전 과제를 처리하기 위해 여러 아키텍처와 버전을 사용하는 것을 포함합니다.
또한 다른 회사들과 마찬가지로 아마존도 기술 확장 외에도 판매, 솔루션 아키텍처, 기술 고객 관리자, 고객 지원 등 기술과 무관한 요소들을 해결해야 한다는 것을 알게 되었습니다. 이러한 요소들은 성공적인 기업을 구축하는 데 필수적입니다.
새로운 서비스를 출시하는 방법
우리는 모든 팀이 고객과 긴밀한 연락을 유지하기를 원합니다. 왜냐하면 우리가 제공하는 기능과 서비스의 약 95%는 고객의 직접적인 요구에 응답하기 위한 것이기 때문입니다. 초기에 우리가 구축한 최초의 서비스들은 기본 IT 인프라, 저장, 컴퓨팅, 데이터베이스, 네트워크, 보안 등 고객의 거의 모든 기대를 충족시켰습니다.
그러나 시간이 지남에 따라 고객은 분석 기능, 클라우드 기술, 모바일 개발, 현재는 블록체인 등 다른 다양한 요구를 제기했습니다. 그들은 이러한 기술을 관리하지 않고도 사용할 수 있기를 원했습니다. 따라서 고객이 올바른 기능과 도구를 구축하도록 돕는 것이 매우 중요해졌습니다.
새로운 제품과 서비스를 출시할 때 우리는 최소 기능 세트(MVP)로 출시하는 강력한 문화를 따릅니다. 그러나 이것은 비즈니스에 필요한 기술을 구축하기 위한 시작점일 뿐입니다. 우리는 얇은 기능 덩어리만 출시해서는 안 되며, 안정적이고 신뢰할 수 있도록 해야 합니다. 그런 다음 고객과 함께 추가 기능에 대한 요구를 논의합니다.
제품 초기 단계에서는 고객이 어떤 추가 기능을 원하는지 항상 알 수 없습니다. 예를 들어 DynamoDB를 출시했을 때, 고객이 보조 인덱스를 원한다는 것을 몰랐습니다. 처음부터 제공하지 않았지만, 고객이 원한다는 것은 분명했습니다. 우리는 최소 기능 세트로 서비스를 시작하여 고객이 제품을 어떻게 사용하는지 관찰하고 점진적으로 반복하며 새 기능과 서비스를 추가합니다.
예를 들어 Lambda를 출시했을 때, 서버리스 환경으로 개발이 매우 간단해졌습니다. 코드만 작성하여 S3에 배포하면 서버 관리 등의 다른 사항을 고려할 필요가 없습니다. 실제 사용한 만큼만 비용을 지불하면 되며, 유휴 시간 등의 문제를 걱정할 필요가 없습니다.
이 방식은 개발 과정을 변화시켰고, 우리는 고객이 제품을 어떻게 사용하는지 관찰할 수 있었습니다. 고객들은 곧 X-ray 디버깅 환경과 같은 방식으로 반복 작업을 시작했으며, 스테이지 기능을 사용해 더 복잡한 애플리케이션을 구축했습니다. 고객의 사용 습관을 관찰함으로써 그들의 요구를 이해할 수 있었고, 예를 들어 DynamoDB에서 보조 인덱스가 고객에게 보조 데이터센터보다 더 중요하다는 것을 깨달았습니다.
기본적으로 고객이 우리의 로드맵을 다시 정의했으며, 우리는 고객에게 가장 중요한 기능을 제공하기 시작했습니다. 이는 매우 중요한 부분입니다. MVP처럼 보일지라도 그것을 MVP로 간주해서는 안 됩니다. 왜냐하면 사람들은 그 위에 비즈니스를 구축하고 그것에 의존하기 때문입니다. 따라서 제품 주변에는 다른 문화 구조가 형성됩니다.
지난해 우리는 1,400개의 새로운 기능과 서비스를 출시했으며, 팀 수가 증가함에 따라 이 숫자는 당연히 계속 늘어날 것입니다. AWS에서도 동일한 구조를 사용하며, 각 팀은 특정 고객 그룹과 협력하고 그들의 요구에 따라 로드맵을 구축합니다. 서비스가 많아질수록 로드맵도 많아집니다.
그러나 이것은 빠르게 진행되는 환경이며, 소프트웨어 구축 방식은 크게 변화했습니다. 우리가 고객이 어떻게 소프트웨어를 개발해야 하는지 결정할 수 있다면, 아마도 지금도 5년 또는 10년 전과 같은 방식으로 개발하고 있을 것입니다. 오히려 우리는 고객과 긴밀히 협력하여 그들이 우리의 혁신 엔진을 이끌도록 해야 하며, 2020년이나 2025년부터 시작하는 소프트웨어 개발 방식을 따라야 합니다.
따라서 우리는 고객을 위해 결정을 내릴 수 없으며, 그들과 긴밀히 협력하여 그들이 우리의 혁신 엔진을 이끌도록 해야 합니다. 우리는 고객이 우리 제품을 어떻게 사용하는지 면밀히 관찰하고 그들의 피드백에 따라 지속적으로 반복하고 개선해야 합니다.
총괄하면 아마존 웹 서비스(AWS)는 팀 수준과 자본 투자라는 두 가지 수준에서 혁신을 추진합니다. 고객과 긴밀히 협력하여 그들의 요구를 이해하고 사용 방식을 관찰함으로써 AWS는 고객의 요구를 충족시키는 기능과 서비스를 제공할 수 있습니다. 동시에 AWS는 새로운 제품, 서비스, 기능을 개발하고 출시하기 위해 막대한 자본을 투자하여 끊임없이 변화하는 시장 수요에 대응합니다.
이러한 혁신 방식은 AWS가 고객과 긴밀한 관계를 유지하고 안정적이며 신뢰할 수 있고 고객 기대에 부합하는 솔루션을 제공할 수 있게 합니다. 최소 기능 세트 출시 전략과 지속적인 반복 방식을 통해 AWS는 고객의 요구에 빠르게 대응하고 점점 더 진보된 기능과 서비스를 제공할 수 있습니다.
아마존의 혁신 여정은 끊임없이 진화하고 발전하는 과정이며, 항상 고객 중심을 지향합니다. 고객의 요구를 깊이 이해하고, 고객의 사용 습관을 관찰하며, 지속적인 R&D 투자를 통해 AWS는 기술과 비즈니스를 계속해서 전진시키며 고객에게 뛰어난 클라우드 컴퓨팅 솔루션을 제공하고 있습니다.
고객 중심 제품 구축
우리는 어디에서든 고객으로부터 시작하거나 아마존 내부에서 시작합니다. 기술 기업으로서 우리는 고객에게 진정으로 중요한 것을 개발하는 데 매우 주력합니다. 우리는 중량급 기술 기업이지만, 설계와 엔지니어들도 리스크를 감수합니다.
우리가 주목하는 것은 기술이 아니라 제품입니다. 우리는 고객을 위해 무엇을 할 수 있는지 알고 싶습니다. 우리는 놀라운 기술을 구축하는 데 힘쓰지만, 그것이 우리의 유일한 동기력은 아닙니다. 우리는 고객의 문제를 해결하는 데 관심이 있습니다.
고객 중심성을 지속적으로 유지하기 위해 우리는 '역방향 작업(R逆向工作)'이라고 불리는 프로세스를 사용합니다. 먼저 우리가 구축할 것을 명확하고 간결하게 설명하는 뉴스레터를 작성합니다. 그런 다음 20개의 일반적인 질문을 포함하는 문서를 준비하고, 쉬운 언어로 답변합니다. 더 복잡한 경우에는 이 두 문서를 여러 번 수정하면서 우리가 정확히 무엇을 구축할 것인지 명확히 할 때까지 반복합니다.
다음으로 사용자 경험(UX) 문서를 작성하여 고객이 제품을 어떻게 사용하고 제품과 어떻게 상호작용하는지를 상세히 설명합니다. 사용자 매뉴얼, 용어 사전 등 기타 관련 문서도 작성합니다.
마지막으로 우리가 할 일을 정확하게 설명하는 네 가지 문서 세트를 얻게 됩니다.
아마존으로서 우리는 항상 이 원칙을 따릅니다. 우리의 청구서는 우리가 약속한 것을 넘지 않습니다. 우리는 두 번째 버전의 기능을 첫 번째 버전에 마음대로 추가하지 않습니다. 우리는 약속한 기능 구축에 집중하며, 그것에만 주목합니다. 이 방법은 고객 요구, 제품 경험, 기술 등을 사고하는 데 강력한 구조를 제공합니다.
아마존 회의에서는 슬라이드나 발표를 사용하지 않습니다. 대신 '6페이지 메모'라는 문서를 사용하는데, 회의 시작 30분 전에 모두가 조용히 읽습니다. 이 메모는 매우 중요하며, 참석자 모두가 논의 내용을 명확히 이해하도록 보장합니다.
이야기를 쓰는 것은 어렵기 때문에 우리는 협업과 피드백을 장려합니다. 특성, 제품 또는 비즈니스 분야를 명확히 설명할 때까지 메모를 여러 번 수정하고 완성합니다. 30분간의 독서 후 회의실 안의 모든 사람이 동일한 페이지에 도달하게 되며, 이는 고품질 토론을 가능하게 합니다.
결론적으로 우리는 고객의 문제를 해결하고 탁월한 제품과 서비스를 제공하기 위해 독특한 문화와 프로세스를 갖추고 있습니다.
컨테이너 기술
점점 더 많은 기업들이 컨테이너 기술을 건너뛰고 있으며, 특히 마이크로서비스 환경을 추구하는 경우 그렇습니다. 컨테이너 기술이 인기를 끈 이유 중 하나는 컴포넌트의 확장과 축소가 용이하여 마이크로서비스 개념과 잘 맞기 때문입니다. 많은 사람들이 전통적인 모놀리식 구조에서 벗어나 컨테이너 기반 개발을 시작했으며, 특히 서버리스 환경 중심으로 개발하고 있습니다.
그러나 Fargate 출시 이전에는 컨테이너 기술 사용에 몇 가지 문제가 있었습니다. 여러 가용 영역에 걸쳐 여러 컨테이너를 운영해야 하며, 이를 가상 머신에 매핑해야 했습니다. 따라서 컨테이너는 훌륭한 개발 선택지이지만, 여전히 많은 작업이 필요하여 운영과 관리가 어려웠습니다. 이 과정을 단순화하기 위해 우리는 Fargate라는 솔루션을 제공했으며, 이는 기본 가상 머신의 모든 관리를 제거하고 컨테이너를 그 안에 넣기만 하면 실행됩니다.
앞으로는 더 복잡한 서버리스 환경을 구축할 수 있는 능력을 중심으로 더 많은 도구, 지원 플랫폼, 인프라가 개발될 것이라고 생각합니다. 다른 서비스와의 통합도 중요한 방향이 될 것입니다.
*TechFlow 주석: Fargate는 아마존 웹 서비스(Amazon Web Services, AWS)가 제공하는 컴퓨팅 서비스로, 서버리스(serverless) 컴퓨팅 엔진입니다. Fargate를 통해 개발자는 컨테이너화된 애플리케이션을 더 쉽게 관리하고 배포할 수 있으며, 기본 인프라와 서버를 신경 쓸 필요가 없습니다.
컨테이너 기술은 애플리케이션과 그 종속 항목을 독립적이고 이식 가능한 컨테이너에 패키징하여 애플리케이션의 빠른 배포와 이식성을 실현하는 가상화 기술입니다. 컨테이너 기술은 Docker와 같은 컨테이너 엔진을 사용하여 컨테이너를 생성, 관리, 실행하며, 애플리케이션이 서로 다른 컴퓨팅 환경에서도 일관된 방식으로 실행되도록 보장합니다. 컨테이너 기술은 현대 애플리케이션 개발 및 배포에서 널리 사용되며, 더 높은 유연성, 확장성, 이식성을 제공합니다.
고객 보호
그러나 저는 보안 문제가 사람들이 주목할 핵심이 될 것이라고 생각합니다. 앞으로 5년간 CEO, CTO, 엔지니어 누구나 보안을 최우선 과제로 삼아야 하며, 보안 의식을 갖고 모두가 보안 엔지니어의 역할을 해야 합니다. 지난 몇 년간 매주 대규모 데이터 유출 사건이 발생하고 있는데, 기술 전문가이자 디지털 비즈니스 리더로서 우리는 부끄럽고 분노해야 합니다. 고객 데이터 보호는 우리의 책임이며, 고객을 보호하지 못한다면 비즈니스 자체가 존재할 수 없습니다.
우리는 고객으로부터 수집한 데이터를 어떻게 보호할지 생각하기 시작해야 합니다. 렌터카 이용이든 다른 소비 서비스든 말입니다. 보안은 기본적으로 포함되어야 하며, 예를 들어 지속적 통합 및 지속적 배포(CI/CD) 파이프라인에서 보안 이벤트를 트리거하여 새로운 오픈소스 라이브러리를 추가할 때 검토 및 평가를 수행해야 합니다.
개발 파이프라인 자체도 보안이 확보되어야 하며, 다양한 자동화 도구를 갖춰 취약점 테스트를 수행해야 합니다. 특히 의료 및 금융 분야에서는 다양한 규정과 규제 요건을 준수해야 합니다.
5년 안에 우리 모두가 보안 문제에 대해 높은 의식을 갖고 고객 보호를 최우선으로 삼기를 바랍니다. 아마존에서는 지적 자본이든 금융 자본이든, 고객 보호는 언제나 우리의 최우선 투자 분야입니다.
스타트업이 AWS를 사용할 때 흔히 범하는 실수
첫째, 전통적인 데이터센터 경험이 있는 사람들은 처음 AWS를 사용할 때 자신감이 부족할 수 있습니다. AWS는 탄력성과 활용 가능성에서 이점을 가지고 있지만, 보안, 데이터 분석, 모바일과 같은 고급 서비스를 사용하지 않으면 특히 고신뢰성의 대규모 개발에서 그 잠재력을 충분히 발휘할 수 없습니다.
둘째, 회사의 유형과 목표를 명확히 설정하는 것이 중요합니다. 두 가지 다른 회사 스타일이 있습니다. 하나는 빠른 성장과 다수의 고객을 추구하는 회사로, 수익보다는 대규모 투자를 통해 빠르게 확장하고 인수될 가능성이 있는 회사입니다. 다른 하나는 지속 가능한 성장을 추구하며 장기적인 사업을 구축하고 인수보다는 지속 가능성을 중시하는 회사입니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
深潮TechFlow
