아마존 출근기 #1 – 근무 환경

logo_amazon

이제 아마존에 출근한 지 3개월이 지나 수습 기간이 끝났네요. 면수습을 자축하며 3개월 동안 경험한 아마존의 근무 환경과 관련된 이야기를 적어 보겠습니다.

1.

저는 8년차 개발자로, 아마존 런던 오피스의  Amazon Video iOS Client 팀에서 소프트웨어 개발자로 일하고 있습니다. Amazon Video는 넷플릭스와 유사한 서비스로, 스트리밍으로 비디오를 시청할 수 있는 서비스입니다.  참고로, 한국에는 아직 서비스되지 않고 있습니다.

2.

아마존의 기준 근무 시간은 오전 8시 30분부터 점심 시간을 제외하고 8시간입니다. 하지만 출근 시간은 거의 자율입니다. 8시 30분에 출근하면 출근해 있는 사람이 많지 않습니다. 적당한 때에 자기가 알아서 출근하는 분위기이고, 대략 10시 이후에 출근하게 되는 경우는 팀에 메일로 알려 주면 됩니다. 재택 근무도 활성화되어 있습니다. 예를 들어 오전에 택배가 도착하기로 되어 있다면 오전에는 집에서 근무하고, 오후에 출근한다던지, 아이가 아파 병원에 데려다 주고 오늘은 집에서 일하겠다던지, 메일로 알려주기만 하면 됩니다. 퇴근도 역시 마찬가지입니다. 볼 일이 있으면 좀 일찍 퇴근하고 저녁에 일을 한다던지, 굳이 팀장의 허락 혹은 협의가 필요 없이 알아서 하면 됩니다. 일을 언제 어디에서 하건 자기가 해야 할 일을 해내기만 하면 된다는 주의입니다. 결과는 성과 평가로 받게 되겠지요.

3.

근무 공간은 한국에 비해 훨씬 여유로운 편입니다. 이전에 근무했던 회사를 기준으로 뒤에 앉는 사람과의 등 간격이 약 두 배 가까이 됩니다. 회의실도 크고, 여유롭고, 많습니다. 파티션은 없습니다. 사무실의 각 섹션에는 대형 TV가 있습니다. 굳이 희의실을 잡지 않아도 간단한 회의는 자리에서 할 수도 있습니다. 시애틀과의 회의가 잦기 때문에 대부분의 회의실은 화상 회의 및 전화 회의를 위한 시설이 준비 되어 있습니다. Amazon Video의 경우 디자인 및 기획 부서는 시애틀에, 개발 부서는 대부분 런던에 있어 화상 및 전화 회의를 자주 하게 됩니다. 외부에서도 컨퍼런스 콜 시스템을 통해 회의에 참여할 수 있습니다. 저희 팀의 경우 매주 최소 한 번 시애틀의 디자이너 및 프로덕트 매니저와 회의를 합니다.

4.

영국은 공휴일이 1년에 8일로, 한국에 비해 적은 편입니다. 그래서 휴가 일수는 한국에 비해 많습니다. 휴가는 자기가 알아서 쓰면 됩니다. 제 경우 휴가를 써야 할 일이 있어 팀장에게 써도 되냐고 물어 봤더니 돌아온 답변은 휴가 신청 사이트를 알려 주며 여기서 휴가를 사용하면 자기한테도 알림이 온다는 것이었습니다. 휴가를 사용하는 데 팀장의 허락 혹은 협의가 필요 없는 것입니다. 그냥 휴가를 쓰고 팀에 메일로 알려 주기만 하면 됩니다. 한국처럼 휴가가 남았을 경우 돈으로 돌려 받는 제도는 없습니다. 아끼지 말고 열심히 써야 합니다.

2편에서는 개발 프로세스와 관련한 이야기를 해 보겠습니다.

 

아마존 출근기 #2 – 개발 프로세스

logo_amazon

근무 환경과 관련된 이야기는 아마존 출근기 #1 – 근무 환경을 보시기 바랍니다.

면수습 기념 아마존 출근기 2편입니다. 이번 편은 개발 프로세스와 관련한 이야기입니다. 참고로, 저는 아마존 런던 오피스의  Amazon Video iOS Client 팀에서 소프트웨어 개발자로 일하고 있습니다.

1.

저희 팀은 스크럼을 적용하고 있습니다. 매일 오전 약 15분 간 스탠드업 미팅을 진행합니다. 말 그대로 서서 하는 회의입니다. 주로 어제 한 일과 오늘 할 일을 공유합니다. 대부분의 업무 내용은 이슈 트래커를 통해 공유됩니다. 또 다른 회의로는 스프린트 계획 회의가 있습니다. 이슈 트래커에 등록된 이슈 중 이번 스프린트에 포함할 것들을 정리하고, 우선 순위를 조정합니다. 참고로, 스프린트는 배포 주기라고 생각하시면 됩니다.

2.

아마존의 대부분 개발 조직은 코드 리뷰를 필수로 거치게 되어 있습니다. 저희 팀의 경우 최소 두 명 이상이 코드 변경에 동의해야 코드를 내보낼 수 있습니다. 당연한 이야기지만, 내 코드가 잘 리뷰되기 위해서는 나 역시도 동료들의 코드를 잘 리뷰해 줘야 합니다. 개인적으로 코드 리뷰는 반드시 필요한 프로세스라고 생각합니다. 코드가 잘 리뷰되기 위해서는 요구사항이 명확하게 문서화 되어 있어야 하고, 작성된 코드의 아키텍쳐 및 디자인 등도 잘 문서화 되어 있어야 합니다. 개발자들은 보다 나은 코드 리뷰를 위해 좀 더 주의해서 코드를 작성하게 되고, 본인이 작성하지 않은 코드라 하더라도 대략적으로는 구성을 알 수 있게 되는 등 긍정적인 부수 효과도 생겨나게 됩니다.

코드 리뷰의 가장 좋은 점은 코드 퀄리티 및 팀원의 실력 향상이라고 할 수 있습니다. 개발자는 다른 개발자의 코드를 보는 게 가장 좋은 공부라고 생각하는데, 이를 위해서는 코드 리뷰가 가장 좋은 방법인 것 같습니다.

3.

아마존은 위키를 통해 대부분의 문서화를 진행합니다. 요구사항, 시스템 아키텍쳐, 유지 보수 가이드 등 많은 것들이 위키로 문서화되어 있고, 잘 구조화 되어 있습니다. 팀에 합류한 첫 날, 저는 뉴비들이 해야 할 일들이 적힌 위키 페이지 URL을 전달 받아 혼자서 개발 환경 및 각종 사내 시스템을 셋팅할 수 있었습니다. 문서에 부정확한 정보가 포함되어 있거나, 업데이트가 필요할 경우 직접 편집할 수도 있고, 문서 작성자 혹은 관련자에게 알림을 보낼 수도 있게 되어 있어 문서가 항상 최신 상태로 유지될 수 있도록 노력합니다.

4.

빌드 및 유닛 테스트는 CI 서버를 통해 자동으로 실행됩니다. 테스트가 실패할 경우 알림이 오도록 되어 있어 유닛 테스트 역시 최신 상태를 유지합니다. 유닛 테스트 외에도 실제 앱의 UI 를 통한 테스트 역시 많은 부분 자동화 되어 있습니다. 팀에 개발자 외에 별도의 테스트 엔지니어들이 있어 UI 테스트 자동화를 담당하고 있습니다. 이런 자동화된 테스트로 커버되지 못하는 부분은 QA엔지니어들이 담당합니다. UI 테스트의 경우 배포 시스템과 연동되어 있어 UI 테스트를 통과해야 앱을 애플에 검수 요청하게 됩니다.

5.

배포된 앱은 다양한 방법을 통해 모니터링됩니다. 대부분의 수치들은 갑작스런 변화를 보일 경우 자동으로 알림이 오도록 설정되어 있습니다. 각 팀은 당직과 비슷한 On call이 지정되어 있는데, 장애 발생의 1차적인 대응 및 처리를 담당합니다. 장애가 발생했을 경우 On call에게 자동으로 연락이 가고, On call은 최대한 빠른 시간 안에 장애 내용 및 원인을 파악해 문제를 해결해야 합니다. On call은 각 개발자가 돌아가며 담당하는데, 저는 아직 뉴비이기 때문에 로테이션에는 들어가 있지 않습니다.

 

이상으로 3개월 동안 보고 느낀 점을 마칩니다.

아마존에 개발자로 취업하기까지 #3

logo_amazon

1.

면접을 통과하면 계약에 대한 오퍼를 받는다. 아마존의 오퍼는 기본 연봉, 계약 보너스, 주식 세 가지로 구성되어 있다. 계약 보너스는 입사 1주년과 2주년에 현금으로 지급된다. 주식은  1~2년차에도 지급되긴 하지만, 대부분은 3년차와 4년차에 지급되도록 구성되어 있다. 이 외에도 401k (퇴직 연금과 유사), 교통비 혹은 주차비 지원, 휴가 일수, 이사 비용 지원 등등이 계약 조건으로 제시된다.

자신이 받은 조건이 마음에 들지 않으면 협상을 통해 조건을 조정할 수 있다. 글래스도어에 가면 연봉과 관련된 유용한 자료가 아주 많다.

2.

하지만 이 모든 과정 중 가장 중요한 과정이 남았으니 그것은 바로 취업 비자를 받는 것이다. 한국인이 미국 회사에서 일을 하는 경우, 대부분은 H1B 비자(전문직 비자)가 필요하다. H1B 비자는 나를 채용하려는 회사에서 스폰서를 해줘야 하기 때문에 회사에 합격한 뒤 비자 신청을 하는 것이다. H1B 비자는 4월 1일부터 신청할 수 있으며, 비자를 받은 사람은 10월 첫 주부터 출근을 해야 한다.

H1B 비자는 한 해에 85,000개가 발행된다. 이 중 20,000개는 미국 석사학위 이상 소지자에게 먼저 발행되고, 65,000개가 석사학위 이상 소지자와 학사학위 소지자에게 발행된다. 접수는 4월 1일부터 시작하며, 약 일주일 간 신청한 사람이 정원보다 많으면 접수를 마감하고 추첨을 진행한다. 몇 년 전까지만 해도 신청자가 적어 7~8월까지도 신청할 수 있었다고 하는데, 최근의 추세는 지원자가 점점 많아져 경쟁률이 올라가고 있다. 추첨은 완전 랜덤으로 진행되기 때문에 큰 회사에 지원을 했다고 해서 선택될 확률이 더 올라가거나 하지는 않는다. 다만 미국 석사학위 이상 소지자의 경우는 추첨이 두 번 진행되기 때문에 그나마 가능성이 높은 편이다.

3.

추첨이 시작된 지 약 3개월이 지난 7월 경, 나는 추첨에서 탈락했다는 연락을 받았다. 최종 경쟁률은 2.5:1 정도 됐던 것 같다. 나의 경우 만약 당첨이 되면 일주일 안에 연락이 오게 돼 있었기 때문에, 연락이 없는 것으로 보아 탈락할 것을 예상하고 있었다.

아마존 혹은 구글, 마이크로소프트와 같은 글로벌 기업의 경우는 이런 경우가 자주 있기 때문에 취업 비자를 받지 못한 경우 해외 지사에서 근무할 수 있게 해준다. 나의 경우 아마존의 해외 지사에 내 이력서 및 면접 결과를 전달해 채용 의사가 있다는 영국 지사로부터 연락을 받았다. 아마존 채용 페이지에서 마음에 드는 곳에 지원을 할 수도 있지만, 고려해야 될 것이 너무 많아서 그렇게 하지는 않았다.

4.

영국의 런던 오피스에서는 총  네 군데의 팀에서 나를 채용하겠다는 의사를 보냈다. 별도의 면접은 없었고, 각 팀의 매니저들과 전화 통화를 통해 팀이 하는 일이나 인원 및 기술 구성에 대해 얘기를 나누었다. 나는 아마존 비디오의 iOS 어플리케이션 개발팀에서 일하기로 정하고 연봉 협상을 다시 진행했다. 아마존 비디오는 얼마 전 한국에도 서비스를 시작한 넷플릭스와 유사한 서비스로, 스트리밍으로 영화나 드라마를 시청할 수 있는 서비스다.

5.

이렇게 나는 계획에는 없었던 런던에서 일을 하게 되었다. 글로벌 기업의 해외 지사에서 1년 이상 근무했을 경우 L1 비자(주재원 비자)를 받아 미국에서 일을 할 수도 있지만, 이 경우 이직은 제한된다. 자유로운 이직을 위해서는 H1B 비자가 필요하다. 다만, L1 비자는 H1B 비자에 비해 쉽게 발행이 된다는 장점이 있다.

 


이 뒤에도 이야기할 거리가 좀 더 있기는 하지만, 공유하고자 했던 내용은 어느 정도 된 것 같아 이렇게 마무리하겠습니다. 해외 취업을 계획하거나 준비하시는 분들에게 도움이 되길 바랍니다.

아마존에 개발자로 취업하기까지 #2

logo_amazon

1.

코딩 시험을 통과했으면 이제 면접이다. 마지막 면접을 본 것은 2008년이었다. ‘준비 해 온 자기 소개’ 부터 시작하는 한국 회사 면접이었다. 외국 회사들의 면접은 어떤지 전혀 알 수가 없었다. 구글링을 통해 이런 저런 면접 후기들을 찾아보고, 예상되는 질문들에 대한 답변을 준비했다. 하지만 무엇보다 가장 큰 문제는 영어였다. 영어가 벼락치기로 준비한다고 실력이 늘진 않을테니 별다른 방법은 없었다. 미드라도 열심히 보는 수밖에.

2.

담당 리크루터가 해준 조언은 아주 큰 도움이 되었다. 대학 시절 배운 자료 구조, 알고리즘, 객체 지향 프로그래밍 등에 대한 질문을 할 것이라는 것과, 화이트보드 코딩에 준비를 하라는 것. 화이트보드 코딩은 단순히 수도 코드가 아니라 컴파일 에러, 버그가 없는 프로덕션 레벨의 코드를 요구할 것이라는 내용이었다. 나는 화이트보드 코딩에 대비해 주요 알고리즘(예를 들면 그래프 탐색 알고리즘 등)을 펜으로 노트에 작성해보며 면접을 준비했다.

3.

면접은 남산에 있는 하얏트 호텔에서 진행되었다. 면접은 1:1로 네 명의 면접관과 진행되는데, 한 명당 한 시간 정도다. 나는 인터뷰룸에서 기다리고 있고, 면접관이 돌아가며 내 인터뷰룸에 들어 온다. 면접관은 들어 와서 자기 소개를 하고, 내게 질문을 한다. 질의 응답 시간 후에는 화이트보드 코딩 문제를 낸다. 화이트보드 코딩이 끝나면 다른 질문이 있는지 묻고 인터뷰가 끝난다. 질의 응답과 화이트보드 코딩 시간의 비율은 6:4 정도 된다. 예상한 것보다는 화이트보드 코딩 시간이 길었다. 물론 면접은 모두 영어로 진행된다. 내가 한국인이어서 그런지 말은 비교적 천천히, 발음도 꽤 명확하게 해주어 질문을 이해하는 데는 크게 어려움이 없었다. 물론 답변을 하는 것은 정말 힘들었다. 영어 공부좀 많이 해둘껄.

4.

질문은 주로 기술적인 것이나 내 경험과 관련한 것이었다.

기술적인 질문들은 주로 scalability, caching, distributed system 등 웹서비스에 관련한 질문들을 많이 한다. 또한 객체지향에 대한 개념을 묻는 질문도 있다.

경험에 관련된 질문은 최근에 진행했던 프로젝트, 대규모 웹서비스를 개발해 본 경험, 일반 대중을 상대로 하는 시스템을 개발해 본 경험, 자신의 보스와 의견 충돌이 있었던 경험, 기술적으로 가장 큰 도전이 필요했던 경험 등이다. 성공담이냐 실패담이냐는 중요하지 않은 것 같다. 하지만 실패담일 경우 그것으로 부터 무엇을 배우는지에 대해서는 중요하게 생각하는 것 같다.

이 외에도 간단한 수도 코드로 작성할 수 있는 알고리즘을 말로 설명하라는 질문도 있다. 예를 들면 고유한 id를 갖는 상품이 100만 개 있을 때 특정 id가 캐싱되어 있는지 여부를 가장 빠르게 알 수 있는 방법은 무엇일까 하는 것과 같은 질문들이다.

5.

화이트보드 코딩 문제는 알고리즘 작성부터 클래스 추출, 아키텍쳐 설계까지 다양한 레벨에 걸쳐 있다.

문제 중 하나는 n개의 레코드를 저장할 수 있는 LRU 기반의 캐싱 담당 클래스를 구현해 보라는 것이었는데, 나는 2-레벨의 해쉬맵을 통해 구현을 했더니 면접관이 해쉬맵과 링크드리스트를 같이 사용하면 더 좋지 않겠냐고 커멘트를 하면서 잠시 동안 토론을 한 기억이 있다.

다른 질문은 요구 사항을 읽어 주고 필요한 클래스와 인터페이스를 추출해 보라는 질문이 있었고,

가장 기억에 남는 질문은 책 판매 사이트의 아키텍쳐를 설계해 보라는 것이었다. 웹페이지 로딩 속도를 더 높이기 위해서는 어떻게 하는 게 좋을지, 대량의 트래픽을 처리하기 위해서는 어떻게 해야 할지, 특정 몇 권의 책에 대한 트래픽이 전체의 대부분을 차지할 경우 캐싱 알고리즘은 어떻게 할 것인가에 대한 추가 질문이 이어지는 등 가장 까다로웠던 질문이었다.

6.

면접일로부터 2주일 후 메일이 왔다. 오퍼에 대해 얘기해야 하니 연락처를 알려달란다. 이번에도 합격했다 떨어졌다 이런 말은 없다. 얘네는 이런 식인가보다. 어쨌든 면접은 통과한 모양이다.

 

면접 이후의 이야기는 3편에서 진행하겠습니다.

아마존에 개발자로 취업하기까지 #1

logo_amazon

1.

2014년 10월 말, 링크드인(Linkedin)을 통해 자신을 아마존의 킨들&디지털프로덕트 그룹의 리크루터라고 소개하는 사람으로부터 메시지를 받았다. 12월에 서울에서 채용 행사를 개최하는데, 심사를 거쳐 초대를 받은 사람만 참여할 수 있으니 관심이 있으면 이력서를 보내 달라는 내용이었다.

2.

채용 행사를 통해 합격이 되면 시애틀에 있는 아마존 본사에서 일하게 된다는 조건에 마음이 끌려 이력서를 이메일로 보냈다. 말이 이력서지 사실은 링크드인 프로필을 그대로 복사해서 붙여 넣은 것이었다. 만약 내가 적극적으로 구직을 하던 시기였다면 신경 써서 이력서를 작성했을 테지만, 그렇지 않은 상태였기 때문에 크게 신경은 쓰지 않았다. 되면 좋고 아님 말고 식이었다. 돌이켜 보면 정말 무모한 행동이었다.

3.

이력서를 통해 기본 자격을 갖춘 것이 확인되면 다음 순서는 코딩 시험이다. 코딩 시험을 준비하는 데 있어 코딩 인터뷰 완전 분석이라는 책이 정말 많은 도움이 되었다. 코딩 시험을 준비하는 분들께 정말 강추한다. 이 책은 코딩 시험 뿐만 아니라 회사 별 면접 전략, 면접 후의 전략까지 아주 유용한 내용들로 가득하다.

코딩 시험은 Interview Zen이라는 사이트를 통해 진행되었다. 아무 때나 내가 편한 때에 시작하면 되지만, 내게 할당된 문제를 확인하는 순간부터 결과를 제출하기까지의 시간이 측정된다. 코드는 Java ,C++ 혹은 C#으로 작성해야 하며, 별도의 편집기로 작성을 하고 붙여 넣으면 된다. 작성한 함수의 Worst/Average 시간 및 공간 복잡도를 분석해야 하며, 테스트 코드 또한 함께 작성해야 한다. 담당자 얘기로는 대부분 1.5 ~ 2 시간 정도 걸린다고 하는데, 나는 완성 코드를 제출하기 까지 네시간 삼십분이 걸렸다.

4.

11월 중순에 코딩 시험을 봤다. 문제는 주차장 시스템을 구현하라는 것이었다. 주차장에 n개의 주차 공간이 있고, 입구로부터의 거리가 주어져 있다. 주차장에 차가 들어오면 입구에서 가장 가까운 빈 공간을 알려 주면 된다. 차량이 주차장을 빠져나가면 해당 차량이 주차했던 자리는 빈 공간으로 할당된다. 주요 클래스(Car, Space)의 멤버 변수 및 인터페이스는 예시로 제공되어 있다. 핵심은 어떤 자료구조 및 알고리즘으로 주차 공간을 할당/반납하는가이다.

5.

코딩 시험의 결과가 나오기 전에 전화 통화를 통해 코딩 시험에 대한 피드백을 받고, 내 백그라운드 체크를 진행한다. 백그라운드 체크는 주로 최근에 대한 내용이다. 최근에 진행한 가장 큰 프로젝트는 무엇인지, 주로 사용하는 라이브러리는 무엇인지,  하루에  몇 시간을 코딩을 하는지 등등이다. 이게 코딩 시험의 합격 여부에 영향을 미치는지는 모르겠다. 이력서 만으로는 부족한 부분을 보완하기 위한 작업이 아니었을까 생각한다.

6.

12월 초, 코딩 인터뷰 결과가 발표되었다. 담당자가 보낸 메일은 코딩 시험을 통과했다는 내용이 아니라 서울에서의 면접 일정이 잡혔다는 내용이었지만, 어쨌든 코딩 시험은 합격한 것이었다.

 

면접 관련 내용은 다음 편에서 진행하겠습니다.

 

남자의 옷장 어플리케이션 개발기 #14

즐겨찾기 기능을 넣고 싶은데 어떤  UI를 사용해야 할 지 고민이다.

크게 (1)즐겨찾기 추가/제거와 (2)즐겨찾기 목록 조회 이 두 가지 기능이면 될 것 같은데,

(1) 즐겨찾기 추가/제거 -> 아이템 세부 보기의 상단 제목 영역의 우측에 버튼을 추가하면 해결이 될 듯 하다.

2013-12-30 17.31.22

(2) 즐겨찾기 목록 조회 화면은 어떻게 진입 시켜 주는 게 좋을지 모르겠다.

하단에 탭바를 넣는 방식과, 메인 페이지에서 버튼을 눌러 모달뷰 형태로 보여 주는 방식 등을 생각해 볼 수 있는데, 이 방법들 모두 어느 것 하나 최적의 방법은 없는 것 같다.

  • 하단 탭바는 탭의 개수가 3개 ~ 5개가 존재할 때 가장 균형이 있어 보인다.
  • 상단에 버튼을 두자니 공간이 여의치가 않다. 이것 때문에 네비게이션 바를 넣고 버튼을 넣는 것 역시도 이상하다.
  • 하단에 탭바 대신 화면 넓이 만큼의 버튼을 넣는 방법도 있지만 이건 가용한 화면 영역이 줄어 들기 때문에 별로 마음에 들지 않는다.

역시나 가장 중요한 것은 핵심 가치이다.

남자의 옷장이 아이패드 전체 무료 앱 순위에서 상위에 랭크된 사건은 내게 많은 생각을 하게 했다.

이 어플리케이션에는 별다른 기능이 없다.

그저 사람들이 아이템을 선택해 상세 설명을 보고, 관련된 이미지를 보는 게 전부다.

하지만 꽤 많은 사람들이 좋아하는 것 같다.

마그나랩을 통해 사람들에게 얻고자 했던 것을 너무 쉽고 간단하게 얻은 것 같은 기분이다.

깊게 고민한 UI도 아니고, 여러 후보 중에서 선택한 색깔도 아니다. 화면 흐름 역시 마찬가지다. 너무 간단해 Flow라고 부르기도 민망할 정도다. 아이콘은 온라인에서 판매하는 유료 이미지를 사서 그대로 사용했고, 몇 안되는 다른 이미지들은 그냥 내가 포토샵으로 만들었다. 글자 크기는 그냥 적당히 봐가면서 보기에 괜찮은 사이즈를 선택했고, 글씨체는 아무 고민 없이 시스템 기본 폰트를 사용했다.

하지만 꽤 많은 사람들이 이 앱을 설치했고, 긍정적인 리뷰를 남겨 주었다.

그 동안 마그나랩을 통해 여러 서비스를 개발하면서 어떻게 하면 사용자들이 쓰기 쉽고, 우리가 원하는 액션을 더 많이 하게 할 수 있을까 고민했고, 어떤 색깔을 선택해야 서비스 컨셉과 잘 어울릴 것이며, 글씨 크기는 어떻게 정하는 것이 많은 사용자들에게 편안함을 줄 수 있을까로 많은 논쟁을 벌였다. 아이콘과 스플래시 화면을 정하는 것은 서비스의 다른 화면을 디자인하는 것과 맞먹는 정도의 노력과 시간을 들여야만 했다.

하지만 정작 사람들이 이 서비스를 왜 써야 하며, 사람들은 이 서비스를 정말 원할까에 대한 고민은 상대적으로 적게 했던 것은 아닐까?

나는 새로운 앱을 발견하면 앱을 켜서 버튼을 몇 번 눌러 보아 어떤 앱인이 파악한 후 재미가 없으면 앱을 지운다. 가입을 해야 사용할 수 있는 서비스라면 스크린샷 만으로 어떤 앱인지 판단한다.

 

버튼 모양도, 색깔도, 폰트도 크게 중요하지 않다. 가장 중요한 것은 ‘뭘 하는 앱인가’이다.

내가 필요한 것, 내가 원했던 것, 내가 재미 있는 것이 가장 큰 요인이다.

이게 만족된다면 다른 건 참아줄 수 있다.