1-5. 예쁜 쓰레기를 열심히 만드는 팀

1장. 노력하면 할수록 망가지는 팀

속도의 함정에서 벗어났다고 생각했을 때, 나는 더 근본적인 질문과 마주했다. 우리가 지금 만들고 있는 것이 정말 필요한 것인가? 빠르게 달리는 것보다 더 중요한 것은 올바른 방향으로 가는 것이었다.

올바르게 만들기 vs 올바른 것 만들기

우리는 일을 할 때 두 가지 질문을 분리해야 한다.
베리피케이션(Verification): 우리가 제품을 올바르게 만들고 있는가?(Are we building the product right?)
밸리데이션(Validation): 우리가 올바른 제품을 만들고 있는가?(Are we building the right product?)

NASA의 화성 기후 궤도선 실패 사례가 있다. 약 1억 2,500만 달러짜리 탐사선이 화성 대기권에 진입하다 폭발해 버렸다. 원인은 허무하게도 측정 단위 착오였다. 제작사인 록히드 마틴은 야드파운드법을 사용했고, NASA는 미터법을 사용했기 때문이다. 각자의 기준에서는 설계도대로 완벽하게 만들었으니 Verification(검증)은 통과했을지 모른다. 하지만 서로 다른 언어로 일하고 있다는 사실을 확인하지 못한 Validation(타당성 확인)의 실패가 천문학적인 비용을 낭비했다. NASA의 한 엔지니어는 이를 두고 이렇게 말했다.

“하지 말아야 할 일을 효율적으로 하는 것보다 쓸모없는 것은 없다.”

내가 미디어 제품을 개발하던 시절, 우리 팀은 경쟁사와의 출시 경쟁에서 이기기 위해 6개월 동안 야근을 했다. 나는 휴가를 단 한 번도 쓰지 않았다. 인도, 베트남, 중국, 인도네시아 개발자들과 글로벌 팀을 구성해 24시간 릴레이 개발 체제를 만들었다. 한국에서 개발한 코드를 형상관리 서버에 올린 후 퇴근하면, 아침을 맞은 인도에서 테스트를 하는 방식이다.

우리의 자부심은 품질이었다. 일반적으로 제품의 결함이 완전히 0이 되는 경우는 없다. 하지만 우리 팀은 개발팀 내에 별도의 테스트 인력까지 추가 배치하며 품질에 집착했다. 그 결과 하드웨어와 소프트웨어에서 사소한 우려사항을 제외하고 치명적 결함이 한 건도 없는 제품을 만들어냈다. 하지만 우리와 동일한 칩을 사용해 개발한 경쟁사 제품은 한 달 먼저 출시했다. 먼저 출시된 경쟁사 제품을 구매해서 분해하고 테스트해 보니, 개발자로서 양심이 있는지 의심스러울 정도로 미흡했다. 하드웨어는 양호했으나 소프트웨어는 완성도가 낮았다. 그런데 충격적인 것은 이 시기부터 내가 만든 제품군이 국내 1위 자리를 경쟁사에 내주기 시작했다는 것이다. 이유는 간단했다. 경쟁사는 시장을 고려한 제품이고, 우리는 기능적으로 높은 품질의 제품이었다. 우리가 완벽하다고 믿은 기능들은 고객이 원하는 것이 아닐 수도 있었다. 기술적으로는 우수했지만, 사야 할 이유가 없는 제품을 만든 것이다.

지식 공유 플랫폼 기획에 참여했을 때의 일이다. 임직원들의 아이디어와 노하우를 한 곳에 모으고 공유하겠다는 야심 찬 목표로 시작된 프로젝트였다. 우리는 1년에 걸쳐 아이디어 제안부터 평가, 공유, 검색, 분석에 이르기까지 생각할 수 있는 모든 기능을 빠짐없이 구현했다. 론칭과 동시에 대대적인 오픈 이벤트도 진행했다. 각 부서는 경쟁적으로 지식을 등록해야 했고, 실제로 단기간에 수백 건의 정보가 축적됐다. 시스템은 안정적이었고, 사용자 인터페이스도 직관적이었다. 그런데 오픈 이벤트의 효력이 다한 첫 달, 사용 로그를 확인한 나는 충격에 빠졌다. 월 접속자가 전사 구성원의 1%도 되지 않았고, 자발적인 지식 공유 건수는 5건이었다. 구성원들의 의견은 허무했다.

“슬랙에서 바로 물어보는 게 더 빨라요.”

그들에게 지식은 거창한 시스템에서 검색하는 것이 아니었다. 실시간 업무 메신저인 슬랙(Slack)을 통해 동료에게 즉각적으로 질문을 던지고, 대화하듯 빠르게 답을 얻는 것이 훨씬 효율적이었던 것이다.

“노션에 우리 팀 자료 다 있는데 왜 또 올려야 해요?”

팀원들은 이미 노션(Notion)이라는 업무공유 플랫폼에서 문서를 정리하고 팀 단위의 지식을 축적하고 있었다. 결국 1년 반 만에 플랫폼은 서비스를 중단했다. 더 아이러니한 건 폐기 과정이었다. 축적된 데이터를 다른 시스템으로 이관하기 위해 단기임시직을 고용해 한 달간 작업해야 했다. 대체 누구를 위해, 무엇을 위해 만든 것인지 자괴감이 들었다.

예쁜 쓰레기를 만드는 팀의 공통점

내 실패에는 공통점이 있었다. 바로 ‘고객 없는 완벽주의’였다.

나는 Verification에만 집착했다. 개발 프로세스를 준수한 안정적인 개발, 버그 제로, 응답 속도, 아름다운 디자인, 빈틈없는 제도 등 제품이나 서비스를 ‘올바르게’ 만드는 데만 몰두했다. 하지만 정작 고객이 원하는 ‘올바른 제품’을 만들고 있는지는 확인하지 않았다. Validation이 부족했던 것이다.

팀장은 자신의 팀이 무엇을 만들고 있는지, 그것이 정말 고객이 원하는 제품인지 끊임없이 점검해야 한다.

뒤늦게 깨달은 진실이 있다. 고객이 원하는 70% 완성도의 제품이, 아무도 원하지 않는 100% 완성도의 제품보다 훨씬 가치 있다는 것. 다소 엉성해 보여도 실제 문제를 해결하는 제품이, 기술적으로 완벽하지만 쓸모없는 제품보다 낫다는 것. 맹목적인 완벽함을 추구하는 것은 결국 팀장의 자기만족에 불과했다. 이것이 바로 전략적 무개입과 만나는 지점이다. 제품을 ‘올바르게’ 만들려면 끊임없는 개입과 통제가 필요하다. 하지만 ‘올바른 제품’을 만들려면 오히려 한 발 물러서야 한다. 팀원들이 고객과 직접 대화하며 스스로 방향을 찾아가도록 내버려 두는 것이 결과적으로 고객이 진짜 원하는 제품을 만들 가능성이 높다.

전략적 무개입은 방치가 아니다. 완벽을 강요하는 개입을 멈추고, 실패하며 배울 수 있는 환경을 만드는 것이다. 예쁜 쓰레기보다 못생긴 보석의 가치가 높다. 이러한 Verification과 Validation의 구분은 제품 개발뿐만 아니라 조직 내 모든 제도와 시스템에도 동일하게 적용된다. 완벽한 평가 제도를 설계하는 것보다 구성원들이 실제로 성장할 수 있는 평가가 중요하고, 세밀한 규정을 만드는 것보다 현실에서 작동하는 단순한 원칙이 더 효과적이다. 결국 ‘올바른 일을 하는가?’라는 질문이 ‘일을 올바르게 하는가?’보다 선행되어야 한다.

팀장의 역할은 모든 것을 통제하는 것도, 모든 것을 아는 것도, 빨리 달리는 것도, 완벽을 추구하는 것도 아니었다. 올바른 일을 찾은 후 개입하지 않는 것이다.