AWS, 아마존의 탄생 비밀:좋은 위기를 낭비하지 마세요

"최고의 기업은 모든 도전을 기회로 보고, 그 사고방식을 그들의 문화에 새깁니다"

- 2000년 닷컴 버블 시절 아마존의 가장 큰 비용은 데이터센터의 비싼 Sun 서버들
- 1년에 걸쳐서 Sun을 걷어내고 HP/Linux로 교체한 것이 AWS의 기초가 되었음
- 그 시절 아마존의 모토는 "Get big fast". 사이트가 다운되면 바로 손실로 이어졌기에 안정성이 중요했음
ㅤ→ 그래서 Sun 장비가 비싸고 독점적이지만, 가장 신뢰할 수 있었기에 모든 인터넷 회사들이 사용했음
- 2000년도에 VC한테 투자받은 스타트업들이 사업을 중단하면서, 새 Sun서버들이 ebay 에 1달러도 안되는 가격으로 등장하기 시작
- 이때 아마존은 Sun과 더 나은 거래를 협상할 수도 있었지만, Jeff는 더 급진적인 접근방식을 택함
- 그시절 아마존의 CTO는 월마트 출신의 Rick Dalzell로, 그는 전체 기술조직을 중심으로 Sun을 HP/Linux로 대체
- 리눅스 커널은 Jeff가 아마존을 시작한 같은 해인 94년에 출시되었음. 6년이 지난뒤, 새롭고 위험한 접근 방식으로 회사를 베팅
- 전환하는 동안 제품 개발이 중단되고, 1년 이상 새로운 기능 출시를 동결했음. 엄청난 백로그가 있었지만, Linux로의 전환을 완료할 때까지 아무것도 ship 할수 없었음.
- 또한 현금소진을 줄이기 위해 가격을 올리면서 수익 성장이 둔화. 안 좋은 순환이었고, 돈이 줄어들면서 시간이 부족했음. 이러다 파산하기 몇분기 전 이었음
- 그러나 Linux 전환을 시작하자 돌아갈수 없었음. 코드베이스를 리팩토링하고, 서버를 교체하면서, 컷오버(빠른 단계 전환)을 준비함
- 작동한다면 인프라 비용이 80+% 이상 감소하고, 실패하면 웹사이트가 무너지고 회사가 망할 것
- 마침내 제 시간내에 문제없이 전환을 완료. 전체 기술팀에게 큰 성과였음. 사이트는 중단없이 계속되었고, CAPEX(설비 투자 비용)가 하루밤 새에 대폭 감소.
ㅤ→ 그리고 갑자기 무한 확장 가능한 인프라가 생김
- 그러자 더 흥미로운 일이 생김. 리테일러로서 매년 11/12월마다 트래픽과 매출이 급증하는 큰 계절적 상황을 겪고 있음

ㅤ→ Jeff는 "우린 연간 46주는 초과한 서버 용량을 보유하고 있는데, 이걸 다른 회사에 임대하는 건 어떨까 ?" 라고 생각하기 시작
- 같은 시기에 Jeff는 내부 종속성을 분리(Decoupling)해서 팀들이 다른 팀의 통제없이 개발하도록 하는데 관심이 있었음
ㅤ→ 이 느슨한 결합 모델을 활성화 하는데 필요한 아키텍처 변경이 AWS를 위한 API 기본 요소가 되었음- 2000년 닷컴 버블 시절 아마존의 가장 큰 비용은 데이터센터의 비싼 Sun 서버들
- 1년에 걸쳐서 Sun을 걷어내고 HP/Linux로 교체한 것이 AWS의 기초가 되었음
- 그 시절 아마존의 모토는 "Get big fast". 사이트가 다운되면 바로 손실로 이어졌기에 안정성이 중요했음
ㅤ→ 그래서 Sun 장비가 비싸고 독점적이지만, 가장 신뢰할 수 있었기에 모든 인터넷 회사들이 사용했음
- 2000년도에 VC한테 투자받은 스타트업들이 사업을 중단하면서, 새 Sun서버들이 ebay 에 1달러도 안되는 가격으로 등장하기 시작
- 이때 아마존은 Sun과 더 나은 거래를 협상할 수도 있었지만, Jeff는 더 급진적인 접근방식을 택함
- 그시절 아마존의 CTO는 월마트 출신의 Rick Dalzell로, 그는 전체 기술조직을 중심으로 Sun을 HP/Linux로 대체
- 리눅스 커널은 Jeff가 아마존을 시작한 같은 해인 94년에 출시되었음. 6년이 지난뒤, 새롭고 위험한 접근 방식으로 회사를 베팅
- 전환하는 동안 제품 개발이 중단되고, 1년 이상 새로운 기능 출시를 동결했음. 엄청난 백로그가 있었지만, Linux로의 전환을 완료할 때까지 아무것도 ship 할수 없었음.
- 또한 현금소진을 줄이기 위해 가격을 올리면서 수익 성장이 둔화. 안 좋은 순환이었고, 돈이 줄어들면서 시간이 부족했음. 이러다 파산하기 몇분기 전 이었음
- 그러나 Linux 전환을 시작하자 돌아갈수 없었음. 코드베이스를 리팩토링하고, 서버를 교체하면서, 컷오버(빠른 단계 전환)을 준비함
- 작동한다면 인프라 비용이 80+% 이상 감소하고, 실패하면 웹사이트가 무너지고 회사가 망할 것
- 마침내 제 시간내에 문제없이 전환을 완료. 전체 기술팀에게 큰 성과였음. 사이트는 중단없이 계속되었고, CAPEX(설비 투자 비용)가 하루밤 새에 대폭 감소.
ㅤ→ 그리고 갑자기 무한 확장 가능한 인프라가 생김
- 그러자 더 흥미로운 일이 생김. 리테일러로서 매년 11/12월마다 트래픽과 매출이 급증하는 큰 계절적 상황을 겪고 있음
ㅤ→ Jeff는 "우린 연간 46주는 초과한 서버 용량을 보유하고 있는데, 이걸 다른 회사에 임대하는 건 어떨까 ?" 라고 생각하기 시작
- 같은 시기에 Jeff는 내부 종속성을 분리(Decoupling)해서 팀들이 다른 팀의 통제없이 개발하도록 하는데 관심이 있었음
ㅤ→ 이 느슨한 결합 모델을 활성화 하는데 필요한 아키텍처 변경이 AWS를 위한 API 기본 요소가 되었음ㅤ

[참고 : 아마존 역사에서 가장 중요한 제프베조스의 2002년 사내 메일 ] 지금의 AWS가 있게한 메일로 시작해서 다양한 조직의 구조에 대해서 설명한 글 제프 베조스의 2002년 메일 내용 1) 모든 팀은 서비스 인터페이스로 데이터와 기능을 공개하세요. 2) 팀들은 이 인터페이스로 통신 하세요. 3) 직접 링킹, 다른팀 저장소에 직접 억세스, 공유메모리, 백도어 등, 다른 어떤 통신방법도 허용되지 않습니다. 네트워크를 통한 서비스 인터페이스 호출만 허용합니다. 4) 어떤 기술을 사용하는가는 중요하지 않습니다. HTTP, Corba, Pubsub, 커스텀 프로토콜 다 괜찮습니다. 5) 모든 서비스 인터페이스는 예외없이 기초부터 모두 외부에서 사용 가능하도록 설계되어야 합니다. 즉, 팀들은 인터페이스를 외부 개발자가 이용가능하도록 계획하고 설계해야 한다는 것입니다. 예외는 없습니다. 6) 이를 지키지 않는 사람은 해고 될것입니다. 7) 고맙습니다. 좋은 하루 되세요! 조직 구조의 형태 Functional : Apple Divisional : Amazon Function + Divisonal = Hybrid : Netflix 사내 커뮤니케이션 프레임워크 - 동기 vs 비동기 - Co-located 동기 / 비동기 - Distributed 동기 / 비동기 - Remote 비동기

- 이것들이 AWS를 만든 기본 Insight. Jeff가 전사 미팅(All-hands)에서 전력그리드 관점에서 이 아이디어를 설명한 것을 기억함
ㅤ→ "1900년대에 기업은 상점을 열기 위해서 자체 발전기를 가져야 했습니다. 2000년대에 기업이 자체 데이터 센터를 구축해야할 이유는 뭘까요 ?"
- 클라우드 인프라는 AWS 없이도 등장 했을 것(예를 들어, Tesla 없는 전기자동차 처럼) 하지만 얼마나 후에 어떤 기회비용으로 가능 했을지는 모름
ㅤ→ AWS가 회사를 시작하는 비용을 크게 줄인 후 혁신이 폭발하고, 현대적인 VC 에코시스템이 탄생 했음
- 아마존은 2000~2003년에 거의 죽을뻔 했지만, 이런 위기가 없었다면 완전히 새로운 아키텍처로 전환하는 어려운 결정을 내리지 않았을 것
ㅤ→ 이 변화가 없었다면 AWS는 만들어 지지 않았을 것. "좋은 위기를 낭비하지 마세요"

- PS : 아마존은 최근 Oracle을 뜯어 내는데 몇년이 걸렸음. 힘든 일을 하려면 근육이 필요하고, 힘든 일을 함으로써 근육이 만들어짐
ㅤ→ "최고의 기업은 모든 도전을 기회로 보고, 그 사고방식을 그들의 문화에 새깁니다"

---

기회=리스크, 성공=성장, 실패=미래의 재실패를 막을 수 있는 기초.. 우리는 도전을 받아들이고, 문제를 찾아다니면서 성장한다. Struggle하자.