미래를 꿈꾸고 성공을 희망하며

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

- 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 기본 요소가 되었음ㅤ

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

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

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