《나는 아마존에서 미래를 다녔다》를 읽고,

출처 : yes24

세계에서 제일 혁신적인 기업

세계에서 가장 혁신적인 회사라고 하면 떠오르는 기업에 아마존이 있다. 세상에서 가장 고객 중심적인 회사라는 미션 스테이트먼트를 가진 아마존에 대한 나의 첫기억은 인터넷으로 전공책을 사던 서점이였다. 그리고선 꽤 오랜시간이 흘렀고, 아마존은 어느샌가 모든것을 파고, 어디로든(그게, 미국 -> 한국이던) 배달해주는 온라인 마켓이 되어 있었다. 또한, AWS(Amazon Web Service)라는 IT인이라면 반드시 알아야 하는 세계적인 클라우드 플랫폼 회사가 되어 있었다.

to be Earth’s most customer centric company.

Amazon UK : Our Mission (아마존 미션 스테이트먼트)

이 책은 아마존의 거의 모든 성장을 직접 보고 배운 한국인 아마조니언(아마존 직원)의 기록이다. 저자는 이 책에서 아마존(회사)을 다니면서 보고, 듣고, 직접 일했던 경험을 이야기 해준다. 책에서 저자는 꽤나 날 것(raw)의 이야기를 많이 해주는 데 이전 글인 《이기적인 직원들이 만드는 최고의 회사》를 읽고, 와 달리 같은 IT인으로써 많은 부분 공감이 되었다.

그중 몇가지만 고르자면, 아마존이 소프트웨어 회사라는 이야기를 하면서 이에 대해서 월마트와 비교하는 부분이였다.

당시 월마트에 비하면 구멍가게 수준인 아마존이 왜 앞으로 월마트를 앞지를 수밖에 없는지를 명쾌하게 한마디로 농증한 것인데, 이유인즉 땅값은 시간이 지나면 오르는데 컴퓨터는 갈 수록 싸지기 때문이라는 것이다.

나는 아마존에서 미래를 다녔다, P26

이 부분은 저자도 처음 입사때 들은 이야기지만 아직까지 기억에 남을 정도로 강렬한 이야기였다고 한다. 나 또한 공학인으로써 내용을 곱씹어보게 되는 부분이였다. 역설적이게도, 책을 더 읽다보면, 아마존은 새로운 사옥을 지을 때 땅값이 매우 비싼곳에 짓는다.(p46. 아마존이 비싼 도심으로 간 이유)

개밥먹기(Dogfooding)

개밥먹기(Dogfooding), 소프트웨어 개발에서 자사에서 만든 서비스를 직접 사용해보는 것을 말한다.

또한 인상깊었던 곳은 개밥먹기였다. 개밥 먹기는 자사의 제품이나 서비스를 실제로 직접 사용하는 것을 의미하는데, 게임 업계에서도 자기가 개발한 게임을 직접 플레이하는 걸 개밥먹기라고 부르곤 했는데 아마도 여기서 유래된 것 같다.

‘네가 만든 개밥을 먹어봐(Eat your own dog food)’ 또는 도그 푸딩(dogfooding)이라고도 부르는 재미있는 미국 숙어는 (…중략…), 주로 기업들이 자사의 제품이나 서비스를 회사 내에서 사용하거나 사용하지 않는 경우를 빗대어 쓰는 말이다.

나는 아마존에서 미래를 다녔다, p204

아마존에서 예를 든 개밥 먹기는 AWS에 대한 부분이였다. AWS서버가 다운되도 아마존 사이트가 다운되지 않아, 사람들이 항의를 하자 피하지않고, 아마존 사이트를 마이크로서비스 아키텍쳐로 변화시켰고 완전히 AWS 서비스로 이주하게 되었다는 이야기가 있었다.

개밥먹기에 대한 개인적인 일화를 소개하면, 게임에선 직접 개발하는 게임의 기능이나 전체 플레이해보는 걸 의미하게 되는데, 생각보다 많은 게임 회사에서 개밥 먹기를 하지 않는다. (충격적일 수 있지만 실화다)

내가 이전 회사에 있을 때, 대규모 패치를 앞두고 있었던 적이 있다. 이 회사에선 충격적이게도 아무도 테스트를 하지 않고 개발한 내용을 일단 올리고, QA에서만 개밥먹기를 하는 완전한 분업화(?)를 이뤘었다. 그래서 내부적으로도 직군팀끼리 기획은 요청한 기능 테스트도 안해 라던가, 엔지니어팀은 만든 기능 테스트 한번 안해보나? 라는 식으로 헐뜯기 시작했고, 두 팀간의 거리는 점점 더 멀어졌던 기억이 있다. 즉 팀 간의 의사소통이 점점 더 경직되는 경험을 했었다.

추후에 퇴사 후 개인적으로 서로 친해지면서 알게된 충격적인 사실은 실제로 기획팀과 클라팀에선 개밥먹기를 했었다는 것이고, 이게 서로의 관점에서 이뤄진 개밥먹기여서 다른팀 관점에서 보기엔 전혀 테스트를 안하는 것처럼 보였다는 것이다. 예를 들면, 기획팀은 퀘스트 진행 경로라던가, 밸런스에 집중을 했다면, 엔지니어팀은 기능적으로 발생하는 버그나 문제점에 집중을 했었다. 지금 생각해보면 내 작업에만 관심을 가졌던 게 문제 였던 것 같기도 하고, 해당 기능에 대한 설명이나 바라보는 관점이 다른데서 나온 문제가 아니였나 싶다. 뭐, 결국엔 의사소통의 문제였던 것 같다.

이 책을 마무리하면서 든 여러가지 생각중 하나는 비전(Vision)이라는 신념이 어떤 일을 하건, 많은 영향을 줄 수 있다는 점이였다. 물론, 비전 없는 회사는 없다곤 하지만 지킬 수 있는 비전이나, 꿈꿀수 있는 비전을 가진 회사가 과연 얼마나 될지 다시 한번 고민하게 되는 책이였다.

답글 남기기

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

WordPress.com 로고

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

Google photo

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

Twitter 사진

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

Facebook 사진

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

%s에 연결하는 중