모두가 옳았다

기능을 추가하기로 한 사람은 대개 나쁜 사람이 아니다. 문제는 그 개별적으로 옳은 판단들이 쌓이는 방식이다.

지난 글에서 본 로드맵 회의를 기억할 것이다. 다음 분기에 추가될 기능 23개. 하나씩 뜯어보면 반박할 구석이 없다. 사용자가 오래 요청해온 것이고, 경쟁사가 먼저 넣은 것이고, 데이터가 근거를 대주는 것이다. 팀장은 어느 하나도 쉽게 반대하지 못한다. 그런데 그 23개가 다 들어간 제품 앞에서, 처음 써보는 사람은 무엇부터 눌러야 할지 모른다.

이 간극이 낯선 이유는 하나다. 나쁜 결정이 하나도 없었다는 것. 완성의 함정은 판단력 부족에서 오지 않는다. 오히려 매 순간 합리적으로 판단한 결과로 온다. 그렇다면 질문을 바꿔야 한다. 나쁜 판단이 아니라면, 무엇이 이 합리적인 판단들을 같은 방향, 오직 '더하기'로만 밀어붙이는가.

답은 한 가지 원인이 아니라 네 가지 압력이다. 소비자, 경쟁사, 팀, 그리고 두려움. 각각은 서로 다른 곳에서, 서로 다른 언어로 온다. 소비자는 요청으로, 경쟁사는 비교로, 팀은 성과로, 두려움은 침묵으로 온다. 그런데 이 네 갈래가 향하는 방향은 정확히 하나로 수렴한다. 더하는 쪽으로. 그리고 이 네 가지가 동시에 작동할 때, 그 어느 하나도 회의실 안에서 논박당하지 않는다는 사실이 완성의 함정을 특히 끈질기게 만든다.

여기서 짚어야 할 것이 하나 있다. 이 네 압력은 나쁜 의도의 산물이 아니라는 것. 소비자의 말을 듣는 것, 경쟁 상황을 살피는 것, 성과를 내려는 것, 사용자를 실망시키지 않으려는 것 — 이 넷은 모두 좋은 제품팀의 기본 자질이다. 함정은 이 미덕들이 없어서 생기지 않는다. 오히려 이 미덕들이 각자의 자리에서 최선을 다하는데, 그 최선들을 한자리에서 조율하는 눈이 없을 때 생긴다. 각 부서는 자기 몫의 최적화를 완수하고, 그 결과물이 합쳐진 전체는 아무도 설계하지 않은 형태로 굳어진다.

소비자가 원한다고 말할 때

가장 거부하기 어려운 압력은 소비자의 입에서 나온다. "이 기능이 있으면 좋겠다"는 말을 무시하는 것은, 소비자의 말을 안 듣는 일처럼 느껴진다. 그래서 요청은 곧잘 그 자체로 추가할 충분한 이유가 된다. 경청의 함정과 완성의 함정이 만나는 지점이 정확히 여기다.

문제는 소비자가 요청하는 단위와, 제품이 실제로 경험되는 단위가 다르다는 데 있다. 소비자는 기능 하나하나를 개별로 요청한다. 그 모든 요청이 한 제품 안에 동시에 실현됐을 때 전체가 어떻게 느껴질지는, 요청한 사람도 상상하지 못한다. 그가 원한 것은 기능이지, 그 기능들이 모여 만드는 복잡성이 아니다. 그래서 요청받은 것을 전부 들어주는 순간, 역설적으로 아무도 원하지 않던 제품이 완성되는 일이 생긴다.

아이폰 이전의 스마트폰 시장이 정확히 이 실험이었다. 그 시절 소비자에게 원하는 기능을 물었다면, 답은 뻔했을 것이다. 더 긴 배터리 수명, MMS, 3G, 복사·붙여넣기. 그리고 그 모든 답을 이미 충족한 스마트폰들이 시장에 있었다. 그런데 소비자는 그 완비된 제품 대신, 몇 가지가 빠진 아이폰을 골랐다. 요청을 가장 많이 들어준 제품이 이긴 게 아니었다.

여기에는 조용한 왜곡이 하나 더 얹힌다. 조직에 도달하는 요청이 소비자 전체의 목소리를 고르게 대표하지 않는다는 것이다. 가장 자주, 가장 크게, 가장 논리정연하게 요구하는 목소리가 가장 먼저 로드맵에 오른다. 영업팀을 통해 들어오는 요청은 특히 힘이 세다. 계약을 앞둔 고객사 하나가 "이 기능만 있으면 계약합니다"라고 말하는 순간, 그 한 사람의 요청은 조용히 제품을 써온 다수의 무언(無言)보다 무겁게 다뤄진다. 말하지 않는 사용자는 카운트되지 않는다. 그래서 제품에 쌓이는 요청은 '소비자가 원하는 것'의 평균이 아니라, '가장 크게 말한 소수가 원하는 것'의 합에 가까워진다.

이 왜곡은 요청을 다루는 절차가 잘못돼서가 아니라, 절차가 애초에 그런 질문을 하도록 설계되어 있지 않아서 생긴다. 고객 인터뷰든 만족도 조사든, 대개 묻는 질문은 "무엇이 있으면 좋겠는가"다. "지금 있는 것 중 무엇이 방해가 되는가"를 묻는 조사는 훨씬 드물다. 더하는 것에 대한 질문만 반복하면, 더하는 것에 대한 답만 쌓인다. 조사 설계 자체가 이미 한쪽으로 기울어 있는 셈이다.

그리고 요청이 거절당하는 방식에도 비대칭이 있다. 기능을 추가해달라는 요청을 거절하면, 그 사람 한 명이 실망한다. 눈에 보이는 크기다. 그런데 이미 있는 복잡함 때문에 조용히 떠난 사람의 수는 눈에 보이지 않는다. 두 손실 중 하나만 체감되는 조직은, 체감되는 쪽을 피하는 데 자원을 쓴다. 보이지 않는 손실은 예산 배분에서 언제나 뒷전으로 밀린다.

경쟁사가 먼저 넣었다는 이유

두 번째 압력은 옆자리에서 온다. 경쟁사 제품에 있는 기능이 우리 제품에 없으면, 그 빈자리는 곧장 '부족함'으로 읽힌다. 경쟁의 함정이 완성의 함정에 기름을 붓는 지점이다.

이 압력은 누적되는 방식이 특히 고약하다. 경쟁사가 기능을 하나 추가할 때마다, 우리 쪽 로드맵에도 대응 항목이 하나씩 쌓인다. 이 과정이 몇 분기 반복되면, 제품은 어느새 경쟁사 기능들의 집합소가 되어 있다. 어느 것 하나 특별히 뛰어나지 않고, 모든 항목이 남보다 살짝 부족하거나 비슷한 상태. 그리고 그사이, 애초에 이 제품을 고르게 했던 이유 — 처음의 뾰족함 — 는 조용히 희석된다. 남을 따라잡으려던 노력이 결국 자기 자신을 지운다.

이 압력이 유독 힘이 센 이유는, 그것이 논리가 아니라 두려움의 언어로 조직에 도착하기 때문이다. 영업 현장에서 "경쟁사 제품엔 있는데 왜 우리는 없나요"라는 질문 하나가 들어오면, 그 질문은 곧장 로드맵의 상위 순번으로 이동한다. 이 기능이 실제로 거래를 성사시키는지, 얼마나 많은 고객이 그것 때문에 이탈하는지는 종종 따져지지 않는다. 놓치고 있다는 감각 자체가 이미 충분한 근거로 취급된다. 그리고 이 감각은 상대편 조직에서도 똑같이 작동한다. 양쪽 팀이 서로를 보며 같은 두려움으로 움직이면, 두 제품은 서로를 향해 수렴한다. 경쟁은 둘을 더 다르게 만들 것 같지만, 실제로는 종종 둘을 더 닮게 만든다.

기능 비교표는 이 압력을 가장 선명하게 드러내는 물건이다. 체크 표시가 채워진 칸은 눈에 보이고, 그 기능을 실제로 몇 명이 쓰는지는 표에 나타나지 않는다. 그래서 의사결정은 자연스레 '표를 채우는 방향'으로 흐른다. 표를 채우는 것과 제품을 좋게 만드는 것은 다른 일인데, 회의실 안에서는 둘이 자꾸 같은 일처럼 다뤄진다.

이 압력의 또 다른 얼굴은 시장을 다루는 매체와 애널리스트의 평가다. 카테고리를 비교하는 리포트나 리뷰가 기능 목록을 기준으로 순위를 매기는 순간, 그 기준은 곧 조직 내부의 목표가 된다. 외부의 평가 기준이 내부의 우선순위를 대신 정해주는 셈이다. 정작 그 기준이 실제 사용자의 만족과 얼마나 관련이 있는지는 따로 검증되지 않은 채로.

팀 안에서 일어나는 일

세 번째 압력은 조직의 안쪽에서 온다. 무언가를 새로 만드는 일은 눈에 보이는 성취로 기록된다. 반면 있던 것을 없애거나 단순화하는 일은, 성과처럼 보이지 않는다. 성과 지표가 대개 '추가된 기능 수'나 '출시한 업데이트 수'로 세어지는 한, 이 기울기는 우연이 아니라 구조다.

빼는 일에는 눈에 보이는 보상이 없다. 오히려 위험만 보인다. 그 기능을 쓰던 사용자들의 항의가 예상되니, 내부 회의에서부터 반대가 앞선다. 그래서 인센티브와 의사결정 구조 둘 다 같은 방향을 가리킨다 — 더하는 쪽. 팀이 게을러서가 아니라, 조직이 더하는 일에만 박수를 쳐주기 때문이다.

여기에 개인의 동기까지 겹친다. 어떤 기능을 만든 사람은 그 기능을 자신의 성과로, 이력의 한 줄로 남긴다. 반면 어떤 기능을 없앤 사람은 무엇을 남기는가. 실패를 인정한 사람으로 기억되기 쉽다. 이미 투입된 개발 시간과 리소스도 발목을 잡는다. 몇 달을 들여 만든 것을 없애자는 제안은, 그 몇 달이 헛되었다고 말하는 것처럼 들린다. 이 매몰비용의 감각 앞에서 '일단 두자'는 언제나 가장 무난한 결론이 된다.

더 근본적인 문제는, 제품 전체의 일관성을 책임지는 자리가 조직도 어디에도 명확히 없다는 것이다. 각 팀은 자기가 맡은 기능의 완성도를 책임진다. 그런데 그 기능들이 한 화면, 한 사용자 여정 안에서 어떻게 함께 작동하는지, 처음 쓰는 사람에게 그 총합이 어떻게 느껴지는지를 통째로 들여다보는 사람은 따로 있지 않다. 모두가 자기 몫을 성실히 완수했는데도 전체가 무거워지는 것은, 바로 이 전체를 보는 자리의 공백 때문이다.

왜 빼는 것이 더하는 것보다 두려운가?

네 번째 압력은 두려움 그 자체다. 어떤 기능이든, 그것을 소중히 쓰는 소비자 집단은 반드시 존재한다. 사용률이 아무리 낮아도, 그 소수의 반발은 구체적이고 즉각적으로 예상된다. 그 반발을 피하려고 팀은 결국 기능을 그대로 남겨두는 쪽을 택한다.

이 선택이 한 번, 두 번, 스무 번 반복되면 결과는 하나다. 어떤 기능도 제거되지 않는 상태. 제품은 그렇게 한 방향으로만 자란다. 더하는 것은 언제나 허용되고, 빼는 것은 매번 재판에 부쳐진다. 이 비대칭이 오래 쌓이면 조직은 빼는 근육 자체를 잃는다. 나중에 정말 필요한 순간이 와도, 그 결정을 내릴 훈련이 되어 있지 않다.

이 두려움에는 또 하나의 비대칭이 숨어 있다. 기능을 없앴을 때 항의하는 사람은 눈에 보인다. 이름과 계정, 항의 메일과 리뷰가 남는다. 반대로 그 기능이 없어져서 제품이 더 쉬워졌을 때 조용히 만족하는 사람, 혹은 애초에 그 복잡함 때문에 떠났을 잠재 사용자는 흔적을 남기지 않는다. 목소리를 내는 소수와 침묵하는 다수 사이에서, 조직은 언제나 들리는 쪽의 손을 들어준다. 책임 소재도 이 비대칭을 거든다. 무언가를 없앴다가 문제가 생기면 그 결정을 내린 사람이 특정된다. 반면 그대로 두었다가 제품이 서서히 무거워지는 것에는, 누구도 그 순간을 결정한 사람으로 지목되지 않는다. 안전한 선택은 언제나 아무것도 하지 않는 쪽이다.

조직의 기억도 이 두려움을 오래 지속시킨다. 한 번 어떤 기능을 없앴다가 일부 사용자의 거센 반발을 겪은 경험이 있는 팀은, 그 이후 모든 제거 논의 앞에서 그 기억을 먼저 떠올린다. "지난번에 그거 뺐다가 어떻게 됐는지 기억하죠." 이 한 문장이 이후의 모든 제거 시도를 미리 얼어붙게 만든다. 정작 그 한 번의 반발이 전체 사용자 중 얼마나 되는 비율이었는지, 반발 이후 제품이 실제로 얼마나 개선되었는지는 다시 따져지지 않는다. 한 번의 나쁜 기억이 이후의 모든 판단을 대신한다.

소비자가 원하고, 경쟁사가 하고 있고, 팀이 만들고 싶어 하고, 제거하면 불만이 생긴다 — 이 네 가지가 동시에 작동하는 조직에서, 기능을 추가하지 않는다는 결정은 이미 힘겹다.

네 압력의 공통점은, 그 각각이 회의실에서 논박당하지 않는다는 데 있다. 소비자 요청을 무시하자고 말하는 사람은 없다. 경쟁사를 무시하자는 사람도, 성과 지표를 포기하자는 사람도, 소수의 반발을 감수하자는 사람도 드물다. 그래서 완성의 함정은 나쁜 결정들의 축적이 아니라, 각자 옳은 결정들이 한 방향으로 정렬된 결과로 온다. 누구도 잘못하지 않았는데, 제품은 분기마다 조금씩 무거워진다.

더 정확히 말하면, 이 네 압력은 서로를 강화한다. 소비자 요청이 쌓이면 그것이 곧 경쟁사와의 격차로 언급되고, 그 격차는 팀의 성과 목표로 번역되고, 그렇게 만들어진 기능은 누군가에게는 곧 없어서는 안 될 것이 된다. 하나의 압력만 있었다면 조직은 그것을 걸러낼 여지가 있었을 것이다. 그런데 넷이 동시에, 서로를 인용하며 작동할 때는 걸러낼 지점 자체가 사라진다. 이것이 완성의 함정이 개인의 실수가 아니라 구조의 문제인 이유다.

그래서 이 함정에 빠진 조직을 탓하기는 쉽지 않다. 게으른 팀이 만드는 함정이 아니라, 부지런한 팀이 만드는 함정이기 때문이다. 요청에 성실히 응답하고, 경쟁사를 부지런히 살피고, 성과를 부지런히 쌓고, 사용자를 부지런히 배려한 결과가 이 함정이다. 완성의 함정 앞에서 "더 열심히 하자"는 처방은 통하지 않는다. 열심이 문제의 원인이기 때문이다. 필요한 것은 더 많은 노력이 아니라, 그 노력이 향하는 방향을 판단하는 다른 기준이다.

이 구조를 알아채는 것 자체가 첫걸음이다. 압력의 존재를 안다고 압력이 사라지지는 않는다. 소비자는 여전히 요청할 것이고, 경쟁사는 여전히 무언가를 먼저 넣을 것이고, 팀은 여전히 새로 만들고 싶어 할 것이고, 반발은 여전히 두려울 것이다. 그러나 이 네 가지가 각기 다른 방향에서 오는 독립된 신호가 아니라, 결국 같은 결론으로 수렴하도록 설계된 구조라는 것을 알면, 적어도 한 가지는 달라진다. 새 기능 하나를 두고 "이게 왜 필요한가"만 묻던 회의가, "이게 왜 필요하다고 느껴지는가"까지 묻는 회의로 바뀐다. 필요와 필요하다는 느낌은 다르다. 후자를 만든 것은 종종 논리가 아니라 저 네 압력이다.

다음에 로드맵 회의에서 새 기능이 하나 올라올 때, 그 기능의 타당성을 묻기 전에 먼저 물어야 할 것이 있다. 이 기능은 저 네 압력 중 무엇에서 왔는가. 그리고 우리는 그것을 알면서 넣고 있는가, 모른 채 떠밀리고 있는가. 이 질문에 답할 수 있을 때만, 다음 질문 — 무엇을 뺄 것인가 — 도 비로소 의미를 갖는다.

Every added feature had a reason. That's exactly the problem.