to tell the truth
Brand · 제품전략 · 미니멀리즘 — No.22-early-iphone-lesson

천 개의 거절

최고의 제품은 무엇을 넣었는지가 아니라 무엇을 거절했는지로 정의된다
이 글이 답하는 질문
  • 초기 아이폰은 MMS도 복사·붙여넣기도 없이 왜 성공했는가?
  • 스티브 잡스가 말한 "1000가지 아이디어에 아니오"는 무슨 뜻인가?
  • 최소 실행 가능 제품(MVP)은 왜 작동하는가?
  • 제품에서 '빼는 것'을 실제로 어떻게 설계하는가?
이런 분께기능을 더할지 뺄지 고민하는 제품 기획자·브랜드 담당자

스티브 잡스는 아이폰에 MMS도, 복사·붙여넣기도 넣지 않았다. 못 넣은 게 아니라, 넣지 않기로 했다.

2007년 1월, 잡스가 무대에서 첫 아이폰을 소개했다. 발표 직후 기술 전문가들의 평가는 냉정했다. MMS 문자를 보낼 수 없다. 복사한 텍스트를 붙여넣을 수 없다. 3G 네트워크를 지원하지 않는다. 외부 개발자가 만든 앱을 설치할 수도 없다. 당시 블랙베리와 노키아 N시리즈, 윈도우 모바일 폰은 이 기능들을 이미 갖추고 있었다. 스펙 표만 놓고 보면 아이폰은 경쟁에서 밀리는 제품이었다.

결과는 정반대였다. 스펙에서 뒤진 전화기가 스마트폰이라는 카테고리 자체를 다시 썼다. 이 반전을 설명하는 문장은 하나다. 기능의 개수와 제품의 완성도는 다른 것이었다.

당시 소비자들에게 "스마트폰에 원하는 기능이 무엇인가"라고 물었다면 어떤 답이 나왔을까. 아마 배터리 수명, MMS, 3G, 복사·붙여넣기 같은 항목들이었을 것이다. 그리고 그것들을 이미 다 갖춘 스마트폰도 시장에 있었다. 그런데 소비자는 모든 기능을 갖춘 기존 스마트폰 대신, 몇 가지가 빠진 아이폰을 골랐다. 요청받은 것을 다 채우는 일과 실제로 선택받는 일이, 늘 같은 방향을 가리키지는 않는다는 증거였다.

여기서 헷갈리기 쉬운 지점이 있다. 아이폰의 부족함이 문제가 안 됐던 게 아니라, 그 부족함이 다른 무언가로 상쇄됐다는 것이다. 상쇄한 것은 화려한 대체 기능이 아니라 명확함이었다. 무엇을 못 하는지보다, 무엇을 확실히 잘하는지가 소비자의 판단을 앞섰다. 완성도를 기능의 총합으로 재는 순간에는 보이지 않던 셈법이다.

없어서 이긴 전화기

What the missing features actually bought

잡스가 발표 내내 반복한 문장은 셋뿐이었다. 혁신적인 인터넷 통신기기, 혁신적인 아이팟, 그리고 전화기. 이 셋이 하나로 합쳐진 것. 경쟁사들이 카메라 화소 수와 배터리 시간, 멀티태스킹 목록을 나열하는 동안, 애플은 스무 줄짜리 스펙 대신 세 줄짜리 역할을 말했다.

이 차이는 소비자의 머릿속에서 다르게 작동했다. 스무 개의 기능을 다 이해하려면 시간이 필요하다. 세 개의 역할은 즉시 이해된다. 이해할 수 있어야 원할 수 있고, 원할 수 있어야 산다. 초기 아이폰이 판 것은 기능의 총합이 아니라 즉시 이해되는 세 문장이었다.

서드파티 앱이 없다는 것도 약점이 아니라 조건이었다. 모든 기능이 애플이 설계한 방식 하나로만 작동했다. 그 덕에 전화를 거는 경험, 음악을 듣는 경험, 웹을 보는 경험이 어떤 경쟁 기기보다 매끄러웠다. 기능의 수가 아니라 각 기능의 경험 품질이 차이를 만들었고, 그 매끄러움이 소비자로 하여금 없는 기능들을 기꺼이 감수하게 만들었다.

빼는 것을 단순히 덜 만드는 일로 보면 이 사례를 오해하게 된다. 빼는 것은 핵심에 집중하기 위해 비핵심을 의도적으로 배제하는 일이다. 그 배제가 경험의 일관성을 만들고, 일관성이 소비자의 이해와 신뢰를 만든다. 그리고 소비자는 자신이 이해하고 신뢰하는 것을 산다. 기능표에서 뒤진 전화기가 신뢰에서는 앞선 셈이다.

1000가지 아이디어에 아니오

Saying no to a thousand good ideas

잡스는 이 태도를 포커스라고 불렀다. 그의 표현을 옮기면 이렇다.

포커스한다는 것은 1000가지 좋은 아이디어에 '아니오'라고 말하는 것이다.
Focus means saying no to a thousand good ideas.
— 스티브 잡스

이 말에서 놓치기 쉬운 단어가 있다. '나쁜' 아이디어가 아니라 '좋은' 아이디어라는 것. 나쁜 아이디어를 거절하는 데는 용기가 필요 없다. 반박할 이유가 이미 충분하니까. 진짜 어려운 결정은 그 자체로 타당하고, 매력적이고, 누군가는 분명 반길 아이디어에 아니오라고 말하는 순간에 온다.

로드맵 회의를 떠올려보면 이 말의 무게가 더 분명해진다. 회의실에 올라오는 아이디어 하나하나는 대개 근거를 갖고 있다. 사용자가 요청했다, 경쟁사가 이미 한다, 데이터가 필요성을 뒷받침한다. 어느 것도 반대하기 쉽지 않다. 그런데 그 타당한 아이디어들을 전부 받아들인 제품이 오히려 아무에게도 명확하지 않은 제품이 되는 역설이 있다. 잡스의 '아니오'는 이 역설에 대한 답이었다.

여기 이름을 붙일 만한 원칙이 있다. 의도된 결핍 — 소비자가 요청할 법한 것들을 모두 담는 대신, 핵심이 아닌 것에 의도적으로 아니오라고 답하는 설계 태도다. 결핍은 예산이나 기술이 부족해서 생기는 게 아니다. 무엇이 핵심인지 이미 알고 있을 때만, 나머지에 아니오라고 말할 자격이 생긴다. 핵심을 모르는 팀은 모든 요청에 예라고 답하고, 그 예들이 쌓여 아무도 이해하지 못하는 제품이 된다.

완성도의 기준을 옮겨라

Whose definition of "done" counts

'아니오'를 말하려면 먼저 무엇을 기준으로 판단할지부터 정해야 한다. 만드는 사람에게 완성도는 대개 기능의 충실함이다. 이만큼 갖췄으니 잘 만든 것이라는 감각. 그런데 쓰는 사람에게 완성도는 다르게 정의된다. 내가 원하는 것을 얼마나 쉽게 할 수 있는가. 이 두 정의는 제품이 단순할 때는 겹치지만, 기능이 늘어날수록 서로 벌어진다.

이 간극을 좁히는 실질적인 방법은 관찰이다. 제품을 만든 사람이 아니라 처음 접하는 사람을 지켜보는 것. 어디서 머뭇거리는지, 어떤 기능을 아예 못 보고 지나치는지, 어떤 화면 앞에서 다음 버튼을 못 찾는지를 본다. 그 관찰이 '무엇을 빼야 하는가'에 대한 답을 준다. 내부 팀의 논리가 아니라 외부 사용자의 실제 행동이 기준이 될 때, 비로소 어디를 덜어낼지가 보인다.

이 전환이 어려운 이유는 만든 사람이 이미 너무 많이 알기 때문이다. 모든 기능의 존재 이유를 알고, 어디에 있는지 알고, 어떻게 쓰는지 안다. 그 깊은 이해가 역설적으로 처음 보는 사람의 눈을 가린다. 잘 아는 사람에게는 명확한 스무 개의 기능이, 처음 접하는 사람에게는 압도적인 목록으로만 보인다. 완성도의 기준을 옮긴다는 것은 결국 이 앎을 잠시 내려놓고, 모르는 채로 제품을 다시 마주해보는 일이다.

처음 5분을 설계하라

Designing the first five minutes

빼는 것을 실행에 옮기는 구체적인 방법이 있다. 처음 제품을 접하는 사람이 5분 동안 무엇을 경험하는지를 그려보는 것이다. 그 5분 안에 "이 제품이 나에게 무엇을 해주는지 알겠다"는 확신이 서는가. 기능이 아무리 많아도 이 5분이 혼란스러우면 소비자는 그대로 떠난다.

넷플릭스가 이 설계를 보여주는 사례다. 콘텐츠는 수만 개지만, 첫 화면에 그걸 다 늘어놓지 않는다. 개인화된 추천으로 '지금 볼 만한 것'을 좁혀서 보여준다. 수만 개가 있다는 사실은 가입할 이유를 만들고, 그것을 개인화된 소수로 줄이는 일은 실제로 시청 결정을 하게 만든다. 완성도와 진입 장벽 제거는 따로 작동하지 않는다. 함께 설계된다.

게임 업계도 같은 원리를 쓴다. 아무리 복잡한 게임도 튜토리얼은 조작법 하나로 시작한다. 그것을 숙달해야 다음 단계가 열린다. 전체 복잡성은 그대로 두고, 그 복잡성을 만나는 순서만 바꾸는 것이다. 소프트웨어의 온보딩 플로우가 처음엔 핵심 기능 두세 개만 안내하고 나머지를 점차 드러내는 것도 같은 설계다. 기능을 없애는 게 아니라, 지금 당장 보여줄 필요가 없는 것을 뒤로 미루는 것.

이 원칙은 제품 밖, 마케팅 언어에도 그대로 옮겨진다. "20가지 고급 편집 도구를 제공합니다"보다 "전문가처럼 사진을 편집할 수 있습니다"가 더 멀리 닿는다. 전자는 만드는 사람의 자랑이고, 후자는 쓰는 사람의 경험이다. 제품에서는 결핍을 설계해놓고, 광고 카피에서 다시 스펙표로 돌아가는 브랜드가 적지 않다.

기능의 개수를 그대로 둔 채로도 이 설계는 가능하다. 관건은 무엇을 없애는가가 아니라 무엇을 언제 보여주는가다. 처음 사용하는 사람에게는 핵심만 보이고, 익숙해진 사람에게는 나머지가 서서히 드러나는 구조. 복잡성은 그대로 있지만, 그 복잡성을 마주치는 순서가 다르면 같은 제품도 전혀 다르게 경험된다.

이 순서 설계가 향하는 목적지는 하나다. 처음 5분 안에 "이 제품이 나에게 무엇을 해주는지 알겠다"는 문장을 스스로 완성하게 만드는 것. 이 문장을 만든 사람이 대신 채워주는 제품과, 사용자가 5분 안에 직접 채우는 제품은 전혀 다른 확신을 남긴다. 초기 아이폰이 세 문장으로 그 확신을 만들었듯, 좋은 설계는 언제나 이 한 문장의 완성 시점을 앞당기는 일이다.

검색창 하나만 남았을 때

When only the search box remained

구글이 등장하기 전, 검색 엔진들은 포털이었다. 뉴스, 날씨, 쇼핑, 메일을 한 화면에 욱여넣었다. 구글은 검색창 하나만 남겼다. 다른 건 다 뺐다. 그 극단적인 단순함이 '검색하러 왔을 때 검색만 하면 된다'는 한 문장짜리 경험을 만들었다. 야후, 라이코스, 알타비스타와의 싸움에서 승부를 가른 건 기능의 개수가 아니라 핵심의 명확함이었다.

빼는 것이 어려운 이유는 분명하다. 어떤 기능이든 그것을 아끼는 사용자가 있다. 그들의 불만은 눈에 보이고, 빠진 자리는 소리를 낸다. 반면 무언가를 더했을 때 생기는 복잡성의 무게는 조용히, 누적으로만 드러난다. 그래서 조직은 언제나 더하는 쪽으로 기운다. 줄이는 결정에는 그 불균형을 거스를 용기가 필요하다.

구글의 검색창이 특별했던 이유도 여기 있다. 포털을 만들던 경쟁자들 눈에는 검색창 하나만 남긴 화면이 미완성으로 보였을 것이다. 뉴스도, 날씨도, 메일도 없으니까. 그러나 그 미완성처럼 보이는 화면이 실은 가장 정확하게 완성된 화면이었다. 검색이라는 단 하나의 용건에 대해서는, 그 어떤 포털보다 더 완결된 경험이었기 때문이다. 무엇을 뺐는가로 완성도를 재면, 가장 단순한 화면이 가장 완성된 화면일 수 있다.

MVP는 왜 '최소'가 아니라 '실행 가능'인가?

Why Is MVP About "Viable," Not "Minimum"?

이 원칙을 방법론으로 정리한 것이 최소 실행 가능 제품, MVP다. 에릭 리스가 '린 스타트업'에서 정리한 개념으로, 핵심 기능만으로 먼저 시장에 나가 반응을 확인하고 반복해서 개선하는 접근이다.

MVP가 유효한 이유는 단지 빠르게 출시해서가 아니다. 만드는 사람의 완성도 기준이 아니라 쓰는 사람의 가치 기준을 먼저 확인하기 때문이다. 어떤 기능을 실제로 쓰는지, 어떤 기능은 처음부터 필요하고 어떤 기능은 나중에 더해도 되는지 — 이 정보 없이 완성된 제품을 만들면, 아무도 쓰지 않는 기능들로 가득 찬 복잡한 제품이 나올 확률이 높다.

이 순서는 초기 아이폰이 이미 보여준 순서와 같다. 잡스도 처음부터 모든 답을 알고 세 문장을 고른 것이 아니었다. 무엇이 핵심인지에 대한 확신을 갖고 비핵심을 걷어낸 다음, 시장의 반응으로 그 확신을 검증했다. MVP는 이 과정을 방법론으로 만든 것뿐이다. 다른 점은 확신을 먼저 세우느냐, 확신을 시장과 함께 만들어가느냐의 속도 차이일 뿐, 방향은 같다 — 완성도를 기능의 총합이 아니라 명확함으로 정의하는 것.

이 구분을 놓치면 MVP는 변명이 된다. "일단 빠르게 내놓고 나중에 고치겠다"는 말이, 소비자에게 나쁜 첫 경험을 주는 것을 정당화하는 논리로 둔갑한다. 진짜 MVP는 핵심에서는 탁월하고 비핵심은 과감히 걷어낸 것이다.

이 논리는 소프트웨어 바깥에서도 똑같이 반복된다. 자동차 메이커가 콘셉트카를 먼저 내놓고 반응을 보는 것, 패션 브랜드가 소량 한정으로 먼저 풀어 보는 것, 식음료 기업이 한 지역에서 먼저 출시해 시장의 반응을 확인하는 것. 형태는 산업마다 다르지만 순서는 같다. 완성된 것을 한꺼번에 대규모로 내놓는 대신, 소비자가 핵심 가치를 경험할 수 있는 형태로 먼저 나가 반응을 듣는 것이 완성도를 포기하는 일이 아니라 완성도에 이르는 경로라는 것.

MVP가 결국 증명하는 것은 하나다. 완성도는 먼저 갖춰야 하는 조건이 아니라, 반응을 보면서 다시 정의해가는 과정이라는 것. 이 순서를 받아들이면 '더 갖춘 다음 내놓는다'는 익숙한 직관이 뒤집힌다. 먼저 내놓고, 무엇이 핵심이었는지를 시장에게서 배운다.

초기 아이폰이 남긴 질문

아이폰도, 구글도, MVP도 결국 같은 질문으로 수렴한다. 무엇을 더할까가 아니라 무엇을 빼도 되는가. 이 질문에 답하려면 먼저 핵심이 무엇인지 알아야 한다. 핵심을 모르는 팀에게는 모든 기능 요청이 똑같이 타당해 보이고, 그래서 아무것도 거절하지 못한다. 핵심을 아는 팀만이 나머지에 아니오라고 말할 수 있다.

빼는 것은 포기가 아니다. 무엇이 핵심인지에 대한 답이다. 그 답이 명확할수록 소비자에게 전달되는 가치도 명확해진다. 제품을 만드는 과정에서 가장 어려운 질문은 대개 "무엇을 더할까"가 아니라 "무엇을 빼도 되는가"다.

이 질문은 한 번 답했다고 끝나지 않는다. 제품이 자라고 조직이 커질수록 더하자는 목소리는 계속 늘어난다. 요청은 쌓이고, 경쟁자는 앞서가고, 팀은 만들고 싶어 한다. 그 목소리들 앞에서 매번 다시 물어야 한다. 이것이 우리가 세 문장으로, 하나의 검색창으로 지키려 했던 그 명확함을 강화하는가, 아니면 흐리는가. 답이 흐리다는 쪽이라면, 아무리 좋은 아이디어라도 이번엔 아니오다.

지금 만들고 있는 제품이나 캠페인을 떠올려보자. 그 안에 담긴 것 중, 빠지면 오히려 더 선명해질 것이 있는가. 있다면, 그것을 빼는 결정이 이번 분기 로드맵에서 가장 어려운 동시에 가장 중요한 항목일 것이다.

Less is not the failure of ambition. It is the shape of it.