가장 중요한 제품 결정은 '만들지 않을 것'을 정하는 일

본문

소비자용 금융 서비스 앱을 만들며 저자가 단호하게 거절해 온 두 가지가 있습니다. '문서 허브(document hub)'와 '알림 센터(notifications centre)'입니다. 둘 다 그림이 바로 그려질 정도로 흔한 요구지만, 저자는 이것들이 조직의 문제를 해결하는 대가를 사용자에게 떠넘기는 사례라고 말합니다. 사용자들이 이미 이런 형태에 익숙해져 있다는 점은 인정하면서도, 그것이 좋아서가 아니라 '형편없음에 훈련된' 결과라고 지적합니다.

'하나만 더'가 Google Drive를 다시 만드는 과정

밑바닥의 문제 자체는 실재합니다. 레거시 시스템은 우편으로 보내던 시절의 관행으로 PDF—안내문, 명세서 등—을 생산하고, 컴플라이언스 전문가들은 '지속적 커뮤니케이션 채널'을 요구합니다. 그래서 앱 안에 그것들을 둘 곳이 필요한데, 게으른 해법이 바로 파일 목록형 문서 허브입니다. 문제는 시작 이후입니다. 관련된 이해관계자마다 드라마 'Columbo'의 형사처럼 '딱 하나만 더'를 붙이고, 끝에는 태깅, 아카이빙, 인쇄, 다중 채널 공유, 문서별 보안·인증 처리까지 갖춘 사실상의 Google Drive를 다시 만들게 됩니다. 그리고 그것은 빌드 비용일 뿐입니다. 매번 iOS 릴리스 때마다 Apple이, 혹은 Google·Microsoft·Amazon이 의존하던 동작을 일방적으로 제거하면서 쌓이는 수년간의 유지 비용이 본체입니다. 알림 센터도 같은 이야기입니다. '화면 오른쪽 위에 종 아이콘과 빨간 점 하나만'이라는 요구로 시작해, 몇 달 뒤에는 형편없는 Gmail 클론을 짓고 있습니다.

빌드 비용이 아니라 유지 비용을 보여줘라

사람들이 머릿속에 쥔 멘탈 모델을 놓게 만드는 일은 쉽지 않고, 고객 포커스 그룹이 그 모델을 어느 정도 검증해 주기까지 합니다. Henry Ford의 상투적인 문장—사람들에게 물었다면 자동차가 아니라 더 빠른 말을 원한다고 답했을 것—이 떠오르는 대목입니다. 저자가 실제로 효과를 본 방법은 빌드 비용이 아니라 수년에 걸쳐 펼쳐지는 '유지 비용(running costs)'을 눈앞에 나열하는 것이었습니다. 다만 플랫폼을 무산시켜도 원래 문제—법적 의무를 충족하면서 고객에게 맞는 방식으로 소통하는 법—은 남습니다. 저자가 매번 돌아가는 답은 유스케이스를 개별적으로 엄밀하게 검토하고, 정말로 말해야 할 것과 시점을 가려낸 뒤, 그것이 '플랫폼 전체'를 지어야 할 일인지 무자비하게 시험하는 것입니다. 적용하는 테스트는 하나—'이것이 배를 더 빠르게 하는가?'입니다. 대부분의 경우, 항상은 아니지만, 답은 단순한 것 혹은 이미 존재하는 것을 쓰는 쪽입니다. 하나로 모든 것을 커버하는 만능 플랫폼의 유혹을 거부해야 한다고 강조하며, 실제로 알림 센터가 지어졌는데 정작 원래 메시지의 의도가 그 그릇에 담기지 못한 사례도 봤다고 덧붙입니다. 조언은 두 부분입니다. 시스템에 무엇을 들일지 극도로 까다롭게 골라야 하고, 무엇을 뺄지는 전투적으로 밀어붙여야 합니다.

삭제하는 사람은 승진하지 못한다

두 번째가 훨씬 어려운데, 그것은 단순한 비겁함이 아닙니다. Gerry McGovern이 오랫동안 말해 온 바를 인용합니다. 만들고 출시하는 사람이 보상받고 우러러보이는 문화이며, 검토·유지·제거는 하찮은 일로 취급된다는 것입니다. 그의 Top Tasks 연구에 따르면 사이트 콘텐츠의 대략 80~90%를 덜어냈을 때 기업은 더 많이 팔고, 지원 전화는 줄고, 사람들은 원하는 것을 더 빨리 찾았습니다. 제거가 사후 정리가 아니라 개선 그 자체라는 주장입니다. 더 깊은 층에서는 Klotz 등이 Nature에 발표한 8개의 실험이 있습니다. 사람들은 빼는 쪽이 분명히 더 나은 해법일 때도 체계적으로 '감산적 변경'을 간과했습니다. 덧셈 아이디어는 빠르고 싸게 떠오르지만 뺄셈에는 실제 인지적 노력이 든다는 것—즉 우리는 이 방향으로 하드와이어링되어 있다는 겁니다. 그래서 성공이 진짜 무엇인지 곱씹는 데 뇌를 써야 하고, 성공은 대개 '조직의 세계'가 아니라 '고객의 세계'에 있다고 말합니다.

에이전트 시대, 빌드는 거의 공짜다?

DHH는 에이전트 시대의 무한한 실행 가능성—모든 아이디어와 직감과 실험이 즉시 손에 닿는 상태—에 크게 고무되어 있습니다. 저자는 그것을 '항상 더 많이 만들라'는 주장으로 오해하기 쉽다고 봅니다. 에이전트를 쓰는 더 현명한 방법은 가지치기와 유지보수, 그리고 사람이 손으로 할 수 있는 것보다 더 신중한 제거에 두는 것이라고 주장합니다. Stewart Brand의 'Maintenance of Everything'이 붙잡는 역설—유지보수는 절대적으로 필요하면서 동시에 완전히 선택적이라는 것—도 소개하며, 정확히는 '필수가 되기 전까지는 선택적'이라고 고쳐 씁니다.

검은 터틀넥 속의 코끼리

맞춤 제작된 Issey Miyake 검은 터틀넥을 입은 코끼리, 즉 누구나 떠올리는 사례는 Steve Jobs의 1997년 매트릭스입니다. 소비자 제품 둘, 프로 제품 둘, 각 칸에 뛰어난 제품 하나씩. 그는 나머지 모든 제품 라인을 종료해 얇게 퍼져 있던 엔지니어링 역량을 한곳에 모았고, 그 대담한 결정은 통했습니다. Apple이 지금 52개 안팎의 제품과 서비스를 팔고 있으므로 종착지가 '네 가지만 팔기'는 아니었습니다. 요점은 조직을 가장 중요한 것에 집중시켜 기회비용을 헛되이 쓰지 않게 만드는 것이었습니다. 한 번에 한 가지, 'Une chose à la fois'입니다.

Hacker News 반응

• @andsoitis — 그렇습니다. 기능추가병(featuritis)에 굴복하지 마세요. 따개비들을 제거하세요.
• @swader999 — 제가 끊임없이 듣는 요구가 '커스텀 리포팅'입니다. 그게 도대체 뭔데요? 왜, 왜, 왜 필요한데요? 저는 그냥 실제로 사용할 새 기능을 만들고 '커스텀 리포팅'은 또 한 달 미룹니다.
• @pelagicAustral — 어디서나 보는 패턴입니다... 커스텀 리포팅, 리포트... 수많은 곳에서 봤고 사람들이 왜 그걸 요구하는지 모르겠습니다. 대부분 무엇을 리포트하고 싶은지, 데이터가 어떤 모양이어야 하는지 거의 모릅니다. 거의 100% 그들이 말하는 리포팅이란 '외래 키가 있는 테이블은 전부 조인하고, 없는 테이블은 억지로 union해서 모든 걸 엑셀 시트에 쏟아붓는 것'입니다. 대부분의 사람들이 향하는 황금 표준이죠.
• @randochatter — 그럼 제가 올바른 데이터를 찾으려고 vlookup은 어디다 돌리라는 거죠?
• @tytho — 커스텀 리포팅 도구와 파이프라인을 전문으로 하는 사람과 일한 적이 있습니다. 그에 따르면 커스텀 리포팅을 요구하는 경우 대부분은 앱에 내장된 정렬·필터·집계 도구가 사람들이 던지는 질문에 답해주지 못하기 때문입니다. 이제 누군가 그 얘기를 꺼내면 저는 '어떤 질문에 대한 답을 원하는가'를 묻습니다. 보통 새 기능으로 이어지거나 그 질문에 이미 답할 수 있는 위치를 명확히 해주게 됩니다.

원문: Liam Nugent 블로그 / 번역·요약: Trawling