스티브 예기는 구글이 플랫폼을 이해하지 못한다고 비판했다

스티브 예기(Steve Yegge)는 2011년 구글 내부에만 공개하려던 글을 실수로 공개했다. 아마존에서 약 6년 반, 구글에서도 그만큼 일한 예기는 아마존이 모든 면에서 구글보다 뒤처진다는 통념을 비꼬면서, 아마존이 서비스 중심 구조를 도입해 플랫폼으로 발전한 과정과 구글이 플랫폼을 소홀히 한다는 자신의 견해를 길게 풀어냈다. 이 글은 원문이 사라진 뒤 복사본으로 보존됐다.

예기는 아마존의 채용은 팀마다 기준이 달라 일관성이 없고, 운영도 혼란스러워 엔지니어가 코딩 외의 일까지 맡는다고 썼다. 자선이나 지역사회 기여에는 관심이 없고, 사무실 시설과 급여·복지도 구글보다 뒤처지며, 코드베이스에는 팀별로 정한 것 외에 공통 엔지니어링 기준이 없다는 평가도 내놨다. 다만 아마존에는 구글이 본받을 만한 버전 관리 라이브러리 시스템과 구글에 동등한 것이 없던 발행-구독(pub-sub) 시스템이 있다고 인정했다. 예기는 이 둘을 아마존이 구글보다 잘하는 세 가지 중 두 가지라고 꼽았다. 나머지 하나로 일찍 출시하고 빠르게 개선하는 방식을 들 수 있지만, 유지율과 엔지니어링 규율을 희생해 장기적인 문제를 낳을 수도 있어 확실한 장점이라고 단정하기 어렵다고 덧붙였다.

그가 아마존의 가장 큰 강점으로 꼽은 것은 플랫폼을 만들게 한 제프 베이조스의 명령이었다. 예기의 묘사에 따르면 베이조스는 아마존 소매 사이트의 화면 요소 하나하나를 직접 관리하는 미시적 관리자였다. 애플의 수석 과학자이자 인간-컴퓨터 상호작용 전문가였던 래리 테슬러(Larry Tesler)는 사용성 조사에서 사람들이 사이트를 이해하지 못한다는 점을 보여줬지만, 베이조스는 그 의견을 3년 동안 받아들이지 않았고 테슬러는 결국 회사를 떠났다. 예기는 베이조스가 공개석상에서 직원들이 아마존에서 일하는 대가로 자신에게 돈을 내야 한다고 말했고, 의견이 맞서면 자신의 이름이 적힌 노란 메모지를 건네 ‘누가 회사를 운영하는지’ 상기시켰다고 썼다. 그는 베이조스가 매우 똑똑하지만 평범한 통제광을 온순한 사람처럼 보이게 한다고 비꼬았다.

아마존의 서비스 중심 전환

예기의 기억으로는 2002년 전후, 베이조스는 아마존 모든 팀에 다음과 같은 원칙을 요구했다.

• 모든 팀은 데이터와 기능을 서비스 인터페이스로 공개한다.
• 팀끼리는 이 인터페이스를 통해 통신한다.
• 직접 연결, 다른 팀의 데이터 저장소 직접 읽기, 공유 메모리, 비공개 우회 경로 등 다른 프로세스 간 통신은 허용하지 않는다. 허용되는 통신은 네트워크를 통한 서비스 인터페이스 호출뿐이다.
• HTTP, Corba, Pubsub, 자체 프로토콜 등 어떤 기술을 쓰는지는 상관없다.
• 예외 없이 모든 서비스 인터페이스는 처음부터 외부 개발자에게 공개할 수 있도록 설계한다.
• 이를 따르지 않는 사람은 해고한다.

예기는 마지막 항목 다음에 ‘고맙다, 좋은 하루 보내라’는 말을 농담으로 덧붙였지만, 해고 위협은 실제였다고 썼다. 베이조스는 진행 상황을 감독할 책임자로 ‘최고 불독’ 몇 명을 배정했고, 그중에는 리크 달젤(Rick Dalzell)이 있었다. 예기는 달젤을 육군 레인저 출신이자 웨스트포인트 졸업생, 전직 복서, 월마트의 전 CIO로 소개하며, 그가 ‘견고한 인터페이스’라는 말을 자주 썼다고 회고했다. 그의 존재 때문에 팀들은 일을 빠르게 진행하고 성과를 알리려 했다는 것이 예기의 묘사다.

그 뒤 몇 년 동안 아마존은 내부적으로 서비스 지향 아키텍처(SOA)로 전환했다. 예기는 아마존의 규모에서는 기존 SOA 문서와 경험담만으로 충분하지 않았고, 직원들이 실무에서 여러 문제를 발견했다고 설명했다.

• 장애 신고가 여러 서비스를 거쳐야 실제 담당 팀에 도달할 수 있었다. 신고가 20번의 서비스 호출을 통과할 수도 있었고, 각 단계의 응답 시간이 15분이면 올바른 팀이 알기까지 몇 시간이 걸릴 수 있었다. 이를 줄이려면 보조 도구와 지표, 보고 체계를 갖춰야 했다.
• 모든 동료 팀의 서비스가 잠재적인 서비스 거부(DoS) 공격자가 될 수 있었다. 모든 서비스에 엄격한 할당량과 요청 제한을 마련하기 전에는 팀들이 제대로 진척을 내기 어려웠다.
• 모니터링과 품질 보증(QA)은 연속선에 있었다. 서비스가 정상이라고 응답하더라도 실제 기능은 멈췄고 ‘정상’이라고 말하는 작은 부분만 살아 있을 수 있다. 서비스가 제대로 응답하는지 확인하려면 개별 호출을 해야 한다. 이 검사를 재귀적으로 넓히면 전체 서비스와 데이터의 의미를 확인하는 모니터링이 되고, 이는 자동화된 QA와 구별하기 어려워진다.
• 수백 개 서비스가 다른 팀의 코드와 서비스로 통신한다면 서비스 검색 기능이 필요하다. 이를 위해서는 서비스 등록 기능도 필요하며, 등록 기능 자체도 또 하나의 서비스다. 예기는 아마존에 모든 서비스와 API, 현재 가동 여부와 위치를 프로그램으로 확인할 수 있는 범용 서비스 레지스트리가 있었다고 설명했다.
• 다른 팀 코드의 문제를 디버깅하기가 훨씬 어려워졌다. 모든 서비스를 디버깅 가능한 샌드박스에서 실행하는 보편적인 표준이 없으면 사실상 디버깅이 불가능하다는 것이 예기의 설명이다.

예기는 이를 아마존이 경험을 통해 발견한 수십, 어쩌면 수백 가지 교훈 중 일부라고 했다. 서비스를 외부에 공개하면서 생긴 문제도 있었지만, 서비스 구조로 조직을 바꾸면 팀들은 외부 개발자를 대할 때처럼 다른 팀을 신뢰하지 않는 방법을 배우게 된다고 덧붙였다.

예기가 2005년 중반 구글로 옮길 때에도 전환 작업은 진행 중이었지만 상당히 진척된 상태였다. 그는 베이조스의 명령 이후 아마존이 외부에 공개하지 않을 내부 설계까지 서비스 우선으로 생각하는 문화로 바뀌었다고 회고했다. 직원들이 해고를 두려워해서만 서비스를 만드는 것은 아니었다. SOA의 단점도 있지만, 서비스 중심 설계가 플랫폼을 가능하게 하므로 전체적으로 옳은 선택이라고 이해하게 됐다는 것이 예기의 주장이다.

베이조스가 기술이나 팀의 복지보다 플랫폼을 염두에 두고 있었다는 게 예기의 해석이다. 온라인 서점에 확장 가능한 프로그래밍 플랫폼이 왜 필요하겠느냐는 질문을 던지면서, 베이조스가 깨달은 첫 번째 점은 책과 여러 상품을 판매·배송하는 데 구축한 인프라를 다른 용도로 쓸 수 있는 컴퓨팅 플랫폼으로 바꿀 수 있다는 것이었다고 설명했다. 그는 아마존이 이후 Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon Relational Database Service 등 AWS 서비스를 제공하게 됐으며, 여러 기업의 백엔드가 이 서비스를 사용한다고 썼다. 레딧(reddit)을 그가 개인적으로 좋아하는 사례로 들었다.

두 번째 깨달음은 한 회사가 모든 사람에게 맞는 제품을 항상 만들 수는 없다는 점이었다. 예기는 테슬러가 베이조스에게 어머니조차 웹사이트를 쓰지 못한다고 말한 일이 영향을 줬을 수 있다고 추측했지만, 베이조스가 어떻게 그 결론에 도달했는지는 확실하지 않다고 밝혔다. 그는 모든 사람에게 맞는 제품을 한 번에 만드는 대신 다른 개발자가 각자의 사용자에게 맞는 인터페이스와 작업 흐름을 제공하도록 해야 한다고 주장했다.

예기는 이 문제를 접근성(Accessibility)이라고 부르며 컴퓨팅에서 가장 중요한 문제라고 강조했다. 여기서 접근성은 장애가 있는 사람을 위한 기능에만 국한되지 않는다. 소프트웨어나 아이디어가 어떤 이유로든 누군가에게 전달되지 않거나 이용되지 않는다면, 실패한 쪽은 소프트웨어 또는 아이디어를 설명하는 방식이라는 주장이다. 그는 접근성과 보안(Security)이 서로 충돌할 때가 있지만, 접근성을 완전히 없애면 제품이 존재하지 않는 것과 같고 보안이 없더라도 플레이스테이션 네트워크처럼 성공한 제품이 있을 수 있으므로 접근성이 더 중요하다고 썼다.

구글의 플랫폼과 접근성 문제

예기는 구글이 잘하지 못하는 한 가지가 플랫폼이라고 주장했다. 구글은 범용 서비스를 우선순위 낮은 일로 취급하며, 대부분의 팀은 데이터와 연산에 프로그램으로 접근할 수 있는 작은 서비스조차 제공하지 않거나 제한적으로만 생각한다고 했다. 구글의 Stubby는 서비스 구축에 유용하지만, 아마존의 경험에서 나온 문제들을 해결해주는 완성된 플랫폼은 아니며 자동차가 필요한 상황에서 부품만 주는 것과 같다고 비유했다.

예기의 플랫폼 원칙은 ‘자신이 만든 것을 직접 사용하라(Eat Your Own Dogfood)’는 것이다. 구글+는 이 원칙을 어긴 사례라고 했다. 출시 당시 API가 전혀 없었고, 그가 글을 쓸 무렵 확인했을 때는 API 호출이 하나뿐이었다. 그 호출은 다른 사람의 게시물 스트림을 가져오는 것이었다. 예기는 팀원이 출시를 알렸을 때 ‘스토커 API냐’고 농담했고, 팀원이 그렇다고 답했다고 회고했다.

그는 마이크로소프트가 최소 20년 동안 이 원칙을 문화로 삼아 왔다고 주장했다. 개발자에게 일반 사용자용 제품이 아니라 제한된 제품만 제공하면 장기적인 플랫폼 가치를 단기 성과와 맞바꾸게 된다는 것이다. 예기는 페이스북이 성공한 까닭도 훌륭한 단일 제품을 만들었기 때문이 아니라, 다른 사람들이 다양한 앱을 만들 수 있도록 해 제품군을 확장했기 때문이라고 봤다. Mafia Wars나 Farmville 같은 게임을 비롯해 수백, 어쩌면 수천 가지 선택지가 있어 사용자마다 페이스북을 다르게 쓸 수 있다는 설명이다.

반면 구글+ 팀은 외부 개발자가 만들 수 있는 환경을 조성하기보다 게임이 필요하다고 판단해 외부 업체에 게임 제작을 맡겼다고 예기는 비판했다. 회사가 사람들이 원하는 것을 예측해 직접 제공하려는 접근은 믿을 만한 방법이 아니며, 역사적으로 이를 꾸준히 해낸 사람은 거의 없고 스티브 잡스가 그중 하나였다고 했다. 베이조스는 자신이 잡스처럼 될 필요 없이 제삼자 개발자가 다양한 사용자를 위한 제품을 만들도록 하면 된다는 점을 깨달았다는 것이 예기의 해석이다.

예기는 플랫폼과 접근성은 사실상 같은 문제라고 주장했다. 플랫폼이 여러 사람이 필요에 맞는 기능을 만들도록 해 접근성을 해결한다는 뜻이다. 그는 마이크로소프트, 아마존, 애플, 페이스북이 플랫폼의 가치를 이해한다고 비교했다. 마이크로소프트의 개발자 사이트에는 수천 개의 API가 있고, 아마존의 AWS는 다양한 서비스를 제공하며, 애플은 모바일 플랫폼에서 개방성을 제한하는 선택을 했지만 제삼자 개발과 자체 플랫폼 사용의 중요성을 이해한다고 썼다. 애플의 API는 마이크로소프트의 API보다 깔끔하다고 평가했다.

페이스북의 플랫폼 역량이 예기를 특히 걱정하게 만들었다고 했다. 그는 구글이 성공하길 바라기 때문에 불편한 비판을 쓴다고 설명했다. 구글 개발자 사이트를 경쟁사와 비교하면 외부 개발자에게 공개된 기능이 빈약해 보이고, 지도 API도 보이지 않으며, 자신이 살펴본 API도 제한적이었다고 지적했다. 다만 구글의 개발자 관계 팀은 외부 공개 기능을 확보하기 위해 힘써 왔으며, 플랫폼에 대한 이해가 있는 팀이라고 옹호했다. 문제는 그들이 플랫폼에 무관심하거나 적대적인 조직 환경에서 일한다는 것이 예기의 견해다.

그는 이를 구글 내부의 문화적 갈등으로 묘사했다. 플랫폼을 중시하는 팀은 소수이고, 자금 지원을 받는 제품 중심 팀이 우세하다는 것이다. 구글 지도와 문서도구, 그리고 그런 방향을 모색 중인 지메일을 플랫폼 지향 사례로 들었다. 하지만 구글 문서도구가 마이크로소프트 오피스와 경쟁하려면 스크립트 기능을 맞춰야 하는데 충분한 지원을 받지 못하고 있다고 추정했다. 예기는 당시 Apps Script가 스프레드시트에서만 작동하고 API에 키보드 단축키도 포함하지 않았다는 점을 근거로 들었다.

Wave는 좋은 플랫폼이었지만 플랫폼을 만들었다고 곧바로 성공하는 것은 아니라고도 했다. 플랫폼에는 이를 뒷받침하는 핵심 애플리케이션이 필요하다. 페이스북의 경우 담벼락과 친구 기능을 제공하는 기본 서비스가 페이스북 플랫폼의 핵심 앱이었으며, 플랫폼 없이 페이스북 앱이 같은 성공을 거뒀을 것이라고 생각하는 것은 큰 착오라고 주장했다.

예기는 구글이 모든 사람에게 완벽한 제품을 설계할 수 있다고 믿는 태도를 오만이나 순진함으로 부를 수 있지만, 무엇보다 어리석은 생각이라고 했다. 모든 사람에게 완벽한 제품은 없다는 것이다. 그는 기본 글꼴 크기를 설정할 수 없는 브라우저를 접근성의 실패 사례로 들었다. 본인은 평생 근시였고 40세가 넘으면서 가까운 것을 보는 일이 어려워져 글꼴 선택이 제품을 이용할 수 있는지 좌우한다고 썼다. 그런데 크롬 팀은 설정이 필요 없는 제품을 만들겠다는 목표를 고집해 시각·청각 장애가 있는 사람에게 페이지마다 Ctrl-+를 누르라고 하는 셈이라고 비판했다.

그는 이 문제가 특정 팀만의 일이 아니라 구글 전체가 제품 회사라는 점에서 비롯된다고 봤다. 검색이라는 폭넓은 성공을 거둔 제품이 회사의 사고방식을 편향시켰다는 설명이다. 아마존은 수익성이 줄어드는 외부 압박을 받으면서 베이조스가 플랫폼을 고민하게 됐고, 엔지니어와 컴퓨터를 수익화할 방법을 찾는 과정에서 AWS에 이르렀다고 예기는 되짚었다. 마이크로소프트는 플랫폼 사업으로 시작해 오랫동안 경험을 쌓았다. 페이스북이 제품에서 플랫폼으로 어떻게 전환했는지는 자신도 정확히 모른다고 덧붙였다.

플랫폼은 처음부터 설계해야 한다는 주장

예기는 구글이 내부 서비스 플랫폼과 외부 플랫폼을 모두 제대로 만들지 못하는 문제가 회사 전반에 퍼져 있다고 주장했다. 제품 관리자, 엔지니어, 제품 팀이 플랫폼을 이해하지 못하며, 일부 개인이 이해하더라도 회사가 전사적 우선순위로 다루지 않으면 바뀌지 않는다는 것이다. 제품을 먼저 출시한 뒤 나중에 확장 가능한 플랫폼으로 바꾸겠다는 방식은 이미 시도했지만 효과가 없었다고 썼다.

‘자신이 만든 것을 직접 사용하라’는 원칙은 ‘플랫폼부터 만들고 모든 것에 그것을 사용하라’는 뜻으로 바꿔 말할 수 있다고 예기는 했다. 플랫폼을 나중에 덧붙이는 일은 쉽지 않으며, 처음부터 제대로 설계하는 것보다 열 배는 많은 작업이 들 수 있다고 주장했다. 마이크로소프트 오피스와 아마존에서 플랫폼화를 경험한 사람에게 물어보라는 말도 덧붙였다. 내부 애플리케이션만 특별히 우선 접근하도록 하는 비밀 우회 경로를 허용해서도 안 되며, 어려운 문제를 처음부터 해결해야 한다고 했다.

예기는 구글에 기회가 전혀 남지 않았다고 말하는 것은 아니지만, 기다릴수록 너무 늦을 가능성이 커진다고 글을 맺었다. 그는 일부 제품이나 팀, 사람을 잘못 묘사했을 수 있고 자신이 접하지 못했을 뿐 구글이 플랫폼 작업을 많이 하고 있을 수도 있다고 사과하면서도, 제대로 시작해야 한다는 주장은 거두지 않았다.

원문은 2011년 구글+에 게시됐으며, 처음에는 구글 내부에서만 보이도록 하려다가 실수로 공개된 뒤 빠르게 삭제됐다. 원문이 남아 있지 않아 복사본이 게시됐다.

원문

후속 글

Hacker News 토론