IT의 중심에서

나이 든 개발자가 살고 있는 IT 현장 이야기

Amazon의 성공스토리

6년간 Amazon에서 근무를 했고 현재 Google에서 일하고 있는 Steve Yegge가 자신의 블로그에 올렸다가 내린 글입니다. Google과 Amazon을 비교하면서 Google이 진정한 플랫폼을 만들어야 한다고 외치는 내용인데요. 여기에 Amazon의 성공스토리를 엿볼 수 있는 몇 가지가 있어 요약해 보았습니다. 심한 불평들은 논란의 소지가 있어 삭제하였습니다.


※ 출처 : Steve Yegge의 Rants 블로그, 2011.10.20(원문글은 삭제됨)
※ 저자 : Steve Yegge

Steve-Yegge-Google-Plus

1. 엉망이었던 Amazon

나는 6년 반 정도 아마존에 있었고 구글에도 그 정도 있었다. 내 머리 속에서 매일 매일 강해지는 두 회사의 이미지는 아마존이 하고 있는 것은 모두 잘못된 것이고 구글이 하고 있는 모두 옳다는 것이었다. 물론 너무 포괄적인 일반화지만 꽤 정확한 표현이다. 두 회사를 비교하는 방법이 백 만 가지 정도 있겠지만 적어도 구글은 내가 알고 있는 회사 중에서 최고이다.

아마존의 취업프로세스는 기본적으로 팀이 알아서 고용한다는 한계점이 있다. 그래서 매우 많이 노력함에도 불구하고 팀에 따라 고용수준이 현격하게 차이가 난다. 그리고 그 과정도 완전히 엉망이다. 그들은 SRE(고용을위한 레이더팀)을 가지고 있지도 않고 엔지니어가 너무 많은 모든 것을 하게 되어 있다. 그래서 코딩할 시간이 거의 없을 정도이다. (계속 아마존 비방글이라 중략)

대신 그들은 우리가 emulate해야만 하는 잘 버전화된 라이브러리 시스템을 가지고 있다. 그리고, 우리에게는 없는 ‘좋은 publish-subscribe시스템’이 있다. 하지만 대부분은 RDB 정보를 읽고 쓰는 쓰레기같은 툴들이다. 공짜로 준다고 해도 안 쓸 것들이다.

하지만 나는 ‘publish/subscribe system’과 ‘library-shelf system’ 만큼은 Amazon이 Google보다 나은 세 개 중의 두 개라고 생각한다.(중략)

2. CEO의 칙령

Jeff Bezos(아마존의 CEO) 는 별로 유명하지 않는 쫀쫀한 관리자이다. 그는 아마존 사이트의 모든 픽셀까지 관리한다. 한번은 컴퓨터 인터랙션에서 세계적인 전문가인 Larry Tesler(Apple의 Chief Scientist)를 고용한 적이 있었다. 하지만 Jeff Bezos는 3년 동안 Larry가 이야기하는 것을 모두 무시해 버렸다. 결국 Larry는 못 견디고 회사를 떠나 버렸다. Larry는 사용성을 크게 개선하고 싶어 했으며 그 빌어먹을 웹사이트를 아무도 이해할 수 없음을 증명하고 싶어 했다. 하지만 Bezos는 수백 만 pixel과 landing 페이지에 얽혀진 유의한 pixel들을 손에서 놓지 않았다. Jeff Bezos가 어린 아이처럼 거기에 얽매어 있자 Larry는 더 이상 못 견디고 떠나 버린 것이다.

그러던 Jeff Bezos가 어느 날 갑자기 회사 내에 칙령을 하나 발표한다. 예전에도 그는 갑자기 그런 발표를 자주 했는데 직원들은 그 때마다 망치로 얻어 맞는 개미들처럼 우왕좌왕했다. 하지만 이번에는 지난 사건들을 아주 사소하게 만들어 버릴 정도로 아주 큰 것이었다.

그 칙령Big Mandate에는 이런 것들이 포함되어 있었다.

1) All teams will henceforth expose their data and functionality through service interfaces.
이 시간 이후로 모든 팀은 자기 팀의 데이터와 기능을 서비스 인터페이스를 통해 오픈한다.

2) Teams must communicate with each other through these interfaces.
그리고 팀은 이 인터페이스를 통해서만 커뮤니케이션 한다.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
직접 연결, 다른 팀의 Data Store에 직접 연동, shared-memory, back-door등 다른 커뮤니케이션 프로세스는 용납하지 않는다. 오직 서비스 인터페이스 호출만 허락한다.

4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
무슨 기술을 쓰는지는 중요하지 않다. http, corba, pubsub, 변경프로토콜 등등 아무거나 써라.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
예외없이 모든 서비스 인터페이스는 외부에서도 호출될 수 있게끔 만들어져야 한다. 즉, 각 팀은 인터페이스를 바깥 세상의 개발자들에게 노출시키도록 설계되고 계획되어져야 한다.
예외없다 !!!

6) Anyone who doesn’t do this will be fired.
이를 어길 시 누구든 해고다 !!!!!!

Bezos는 실행여부를 확인하기 위해 두 명의 감시자를 배정했다. 첫번째 사람이 Rick Dalzell 이었다. 그는 수색대 출신이었고 웨스트 포인트 대학 졸업자이면서 권투선수였고 월마트의 전문 고문 기술자였다. 그는 ‘엄격한 인터페이스’라는 단어를 매우 자주 사용하는 ‘다정한 폭군’이었다. 그는 스스로에게도 엄격한 “인터페이스er”였다. 두말할 필요도 없이 모두가 프로세스를 잘 지켰고 보고도 잘했다.

3. 조직이 학습하다.

2년이 지나자 아마존은 내부적으로 완전히 ‘서비스 지향형 아키텍쳐’로 바뀌어 있었다. 그들은 이 변화를 만들기 까지 엄청난 학습을 했다. 이미 그 때에도 SOA에 대한 엄청난 량의 문서와 팁들이 있었다. 하지만 아마존의 광대한 스케일에서 그것들은 인디아나 존스가 길을 건너기 전에 양쪽을 잘 살펴라고 말하는 것에 지나지 않았다. 아마존은 개발팀들은 수많은 개척을 했다. 아래에 몇 개의 사례들이 있다.

  • pager호출 방식(연쇄호출방식의 구조)은 일을 더 어렵게 만든다. 왜냐하면, ticket이 실제 owner가 확인되기 전까지는 20개의 서비스call을 지나면서 튕겨버릴 수 있기 때문이다. 만일 각 bounce가 한 팀에 도달하는데 응답시간이 15분 걸린다면, 해당팀에 도착하기까지 한 시간이 걸릴 수도 있다.
  • 당신 팀의 구성원이 갑자기 잠재적인 DOS 공격자가 될수도 있다. Quotas와 Throttling이 모든 서비스에 준비될때까지 아무도 프로세스를 진행할 수 없게 된다.
  • 모니터링하고 QA는 같은 것이다. 아마 큰 SOA를 만들 때까지는 그렇게 생각하지 않았을 것이다. 하지만 당신의 서비스가 ‘OK’라고 응답했을 때 사실은 ‘OK’라고 대답하는 작은 컴포넌트 하나가 그 서버에서 살아있는 마지막 function일 수 있다. 서비스가 실제로 동작하는지 알기위해서는 individual call을 만들어야만 한다. 모니터링이 전체 서비스와 데이터에 대해 체크할 수 있도록 의미를 가지는 시점까지 문제는 계속 발생될 것이다. 그리고 그렇게 되는 시점에는 자동화된 QA와 구별되지 않을 것이다.
  • 당신이 만일 수많은 서비스를 가지고 있다면 코드는 모두 호환될 수 있어야 한다. 만일 코드가 다르다면 service discovery mechanism없이 아무 것도 할 수 없기 때문이다. 그래서, 아마존은 모든 서비스에 대해 ‘그 API가 무엇이고 현재 어떻게 운영되고 있는지’ 알 수 있는 전 세계 Service Registery를 가지고 있다.
  • 위의 것들은 많은 교훈들 중의 몇 개일 뿐이다. 수많은 교훈들이 있었다. 외부에서 서비스를 호출하게 하는 수많은 이상한 방법들이 있다. 하지만 사실 생각하는 것 만큼은 많지는 않다.

    ‘서비스를 조직화하기 위해서는 다른 팀들을 믿지 않아야 한다. 외부 개발자들을 믿지 않는 것처럼 말이다.’

    4. Amazon은 왜 변해야 했을까?

    내가 2005년 중반 구글에 입사했을 때에도 Amazon은 이렇게 일하고 있었다. 어느덧 Amazon은 기업문화가 모든 것을 서비스 방식으로 생각하는 기업이 되어버렸다. ‘즉 외부에 공개하지 않을 내부 디자인이라도 모든 디자인에 어울리도록 만들어졌다.’

    이제 그들은 잘리지 않기 위해서 일하지 않는다. 물론 여전히 해고를 두려워하고 있다. 해적 Bezos를 위해 일하고 있기는 하지만 적어도 올바로 일하고 있다고 믿게 되었기 때문에 제대로 된 서비스를 하고 있는 것이다. SOA 접근에 대해서는 별다른 이견들이 없다. 그런 인식은 꽤 오래되었다. SOA기반의 디자인이 플랫폼을 가능하게 했기 때문이었다.

    글쎄… Jeff Bezos는 책과 건어물을 팔고 운송하기 위한 인프라 구조가 훌륭한 목적을 가진 컴퓨팅 플랫폼이 될 거라는 것을 미리 알았을 것이다. 그래서 이제 그는 Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon RDB 서비스등을 플랫폼으로 가지게 되었다. 이 서비스들은 꽤 많은 회사의 backend 시스템으로 운영되고 있다.
    두번째로 그는 ‘항상 좋게 만들 수는 없다’는 생각을 했던 것 같다. 나는 Larry Tesler가 자기 엄마가 이 빌어먹을 웹사이트를 사용할 수 없다는 사실을 이야기해서 Bezos가 힌트를 얻은 것이 아닐까 생각했다. 사실 누구의 엄마인지는 분명치 않다. 어쨌든 나는 웹사이트가 매우 위축되어 있다는 것을 알고 있었지만 반세기 넘게 타성에 젖어 일했던 것 같다. 나는 일종의 눈감기를 배웠고 페이지 중간의 pixel들에 집중했다. Bezos가 어떻게 이 인식을 하게 되었는지는 확실치 않다. 그가 한 제품만 만들지 않고 모두를 위한 제품을 만들게 된 동기 말이다. 어쨌든 그는 가지게 되었다.

    5. Platform = Accessibility

    이 현상을 부르는 공식적인 용어가 있다. 그것은 “Accessibility” 이다. 그것은 컴퓨팅 세상에서 가장 중요한 것이다.

    나는 Accessibility가 Security보다 중요하다고 생각한다. Accessibility가 없다는 것은 당신이 가진 제품이 하나도 없다는 뜻이다. Security가 없어도 당신은 플레이스테이션 네트워크와 같은 성공적인 제품을 가질 수 있다.

    제품은 플랫폼이 없으면 쓸모가 없다. 더 정확하게 말하자면, 플랫폼 없는 제품은 플랫폼화된 제품에 의해 항상 교체될 수 있다는 것이다.

    마이크로소프트는 적어도 20년간 dog food rule에 대해 알고 있었다. 그것은 전 세대에 걸쳐 그들 문화의 일부분이었다. 당신은 사람들이 먹는 걸 먹지 말고 개발자들이 먹는 걸 먹어야 한다. 그렇게 하는 것이 단기간에 오랜 플랫폼을 훔치는 가장 간단한 방법이다. 플랫폼은 오래된 고민에 대한 모든 것들이다.

    구글 플러스팀이 페이스북의 “마피아 게임”과 같은 애프터마켓을 한 번 둘러보고 이렇게 말한 적이 있다. “이런 우리도 이런 게임을 몇 개 만들어야겠는데요. 우선 게임을 계약해야 할 것 같아요.” 이 생각은 무엇이 문제일까? 문제는 우리가 사람들이 원하는 것과 다운받기 원하는 것을 “예상”하려고 한다는 것이다.

    우리는 “예측”을 할 수 없다. 진짜로, 믿어도 좋다. 전 역사를 통털어 그럴 수 있는 사람은 없다. Steve Jobs는 그렇게 할 수 있는 유일한 사람이다. 하지만 우리한테는 Jobs가 없다. Jeff Bezos는 모든 사람에게 좋은 제품을 제공하기 위해 Steve Jobs가 될 필요가 없다는 것을 깨달았다. 자신들이 좋아하고 쉽다고 느끼는 인터페이스와 워크플로우를 3rd party개발자들도 사용할 수 있게 하고 싶었다. 그래서 자연스럽게 그렇게 되었다.

    내가 너무 사실만 말하고 있어서 다른 사람들에게 조금 미안하다. 하지만 우리가 그렇게 하고 있지 않다는 것만 제외한다면 사실 너무 명백하다.

    우리는 플랫폼이 없다. 그래서 우리는 Accessibility가 없다. 두 가지는 기본적으로 같다. 왜냐하면 platform은 accessibility를 풀어주기 때문이다. 플랫폼이 accessibility이다.

    6. Apple이나 Facebook처럼 Dog Fooding하라 !!!

    애플도 분명히 플랫폼을 가지고 있다. 그들은 기본적으로 폐쇄형 구조를 선택했다, 특히 모바일 플랫폼에 대해서는! 하지만 그들은 accessibility를 이해했고, 3rd party개발자들의 힘을 이해했고, 기꺼이 dog fooding했다. 그리고 그걸 꽤 잘했다. 그들의 API는 MS보다 엄청 깨끗했으며, 태고적부터 그랬다.

    페북도 플랫폼을 가지고 있다. 사실 나는 Facebook이 두렵다. 그게 내가 이 글을 쓰게 만든 이유이다. 나는 정말 블로깅을 싫어한다. 당신이 구글플러스에 대해 심한 욕을 하고 있더라도 어쨌든 쓰고 있는 것이 아닌가? 왜냐하면 당신은 결국 구글이 성공하길 진심으로 바라고 있기 때문이다.

    페이스북은 처음에 product로 시작했다. 그렇게 꽤 오랫동안 성공을 누렸다. 그래서 나는 어떻게 그들이 플랫폼으로 갈아탔는지 잘 알지 못한다. 하지만 분명히 오랫동안 준비했음에 틀림없다. 왜냐하면 마피아 게임을 만들려면 플랫폼이 있어야 하기 때문이다.

    Advertisements

    Amazon의 성공스토리”에 대한 1개의 댓글

    1. 핑백: 플랫폼캠프 2012-세션7: 플랫폼의 DNA : API관점에서 플랫폼 전략과 생태계 « 플랫폼전문가그룹

    답글 남기기

    아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

    WordPress.com 로고

    WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Twitter 사진

    Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Facebook 사진

    Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Google+ photo

    Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    %s에 연결하는 중

    정보

    이 엔트리는 2011년 11월 1일에 님이 API와 기술에 게시하였으며 , , 태그가 지정되었습니다.

    내비게이션

    %d 블로거가 이것을 좋아합니다: