프로덕트 팀의 신뢰를 ‘자산’처럼 관리해야 하는 이유

이 글을 보면 좋은 이유

• IT 제품을 만들어가는 PM, 디자이너, 개발자 들이 실무에서 은연중에 사용하는 신뢰자산에 대한 개념을 정리할 수 있어요.
• ‘신뢰자산’이라는 개념을 명확하게 인지하여, 이를 실제 프로덕트 개발을 하는 환경에서 효율적으로 사용해 보다 프로덕트 개발의 효율성을 높일 수 있어요.

들어가며

프로덕트를 만드는 사람들이라면 구성원들 간의 '신뢰'가 중요하다는 이야기들을 많이 들어보셨을 것입니다. 많은 프로덕트 매니저(PM)들의 지침서가 되는 책 <인스파이어드(Inspired)>, <스프린트(Sprint)>, <실리콘밸리의 팀장들(Radical Candor)>에서도 구성원들끼리의 '신뢰' 구축에 대해서 끊임없이 강조합니다.

유독 프로덕트를 만드는 사람들 사이에서 많이 강조되는 것 같은 이 '신뢰'란 무엇일까요? 때때로 조직의 기술적 문제보다도 '신뢰'의 문제를 해결하는 것이 제품 개발 속도를 좌우하는 키가 되기도 하는데요. 그렇다면 제품 개발 속도에도 영향을 줄 수 있을 만큼 중요한 이 '신뢰'는 어떻게 쌓아야 할까요?

이번 시간에는 여러 IT 프로덕트 조직이 관심을 두고 있는 '신뢰자산'이라는 개념을 살펴보고, 어떻게 '신뢰자산'을 활용해야 하는지에 대해 설명하겠습니다.

신뢰란 무엇인가?

먼저 ‘신뢰자산’으로 넘어가기 전에 ‘신뢰’에 대한 기본적인 정의부터 가볍게 해보겠습니다. 신뢰를 뜻하는 영 어단어 trust의 어원은 ‘편안함'을 의미하는 독일어 trost에서 출발했다고 합니다. 누군가를 믿을 때에는 마음이 편안해지죠. 그 기저에는 ‘그 사람이 나를 배신할 염려가 없다’는 생각이 있습니다. 배신을 안 할 것이라는 믿음이 있기에 배신당할 것을 예방하기 위해 시간과 노력을 들일 필요가 없습니다. 이 때문에 편안함을 느끼게 되는 것 같습니다.

조금 더 구체적으로 보자면, 심리학에서 정의하는 신뢰의 3요소는 ‘상대방에 대한 긍정적 기대, 위험을 감수할 용의, 상호의존성’입니다. 즉, 신뢰란 ‘타인이 나에게 도움이 되는 의도와 행동을 보일 것이라는 긍정적 기대를 바탕으로, 그를 돕기 위해 나의 위험을 감수하려는 심리적 상태'입니다. 우리는 이 심리적 상태, 무형의 자산을 왜 중요하게 여길까요?

신뢰를 자산(돈)처럼 관리하기

신뢰를 하나의 ‘자산’처럼 축적하고 관리해야 하는 사항으로 여겨야 한다는 개념은 꽤나 오래전부터 사용되어왔습니다. 매년 포춘지가 100대 기업을 선정할 때에도 해당 기업의 신뢰도를 자산처럼 평가하는 트러스트 인덱스(Trust Index)가 사용되어왔죠.

프로덕트 업계에서는 애자일 코칭서 <함께 자라기>, 유튜브 영상 <토스 디자이너는 이렇게 설득합니다>’등을 통해 신뢰자산이라는 개념이 많이 퍼지게 되었고, 최근 개인적인 자리에서도 토스, 크래프톤 등 여러 기업의 프로덕트 담당자들이 신뢰 ‘자산’, 신뢰 ‘부채’, 신뢰 ‘자본’이라는 표현을 통해 신뢰 자산에 대해 이야기를 나누는 것을 들을 수 있었습니다.

왜 이렇게 신뢰를 이야기할 때 ‘자산’이라는 용어를 사용할까요?

신뢰자산이란, 신뢰라는 요소에 자산과 자본이라는 회계 원리 요소를 덧붙인 용어입니다.

신뢰를 자본이 아니라 자산이라고 표현하는 이유는, 기본적으로 신뢰라는 것이 축적의 결과물이면서도 축적한 만큼의 크기를 가지고 있지 않기 때문입니다.

신뢰는 갑자기 생기는 게 아니라 축적되는 것입니다. 내가 한 행동의 총합이 타인이 나에게 가지는 신뢰의 크기에 영향을 줍니다. 동시에 신뢰는 내가 한 행동들만으로 평가되지 않습니다. 앞으로 어떤 일을 잘 해낼 수 있겠다는 타인의 나에 대한 기대, 즉 신뢰부채가 한 개인의 신뢰를 평가하는 데 영향을 줍니다. 신뢰는 축적되는 자본의 성격과 선 반영되는 부채의 성격을 동시에 가지기 때문에 ‘신뢰자산’으로서 관리될 수 있습니다.

신뢰자본은 개인의 행동에 따라 정직하게 쌓이기 때문에, 시간과 노력을 통해 차곡차곡 쌓을 수 있습니다. 하지만 신뢰부채는 타인의 기대를 충족시키지 못하는 경우 감소하게 됩니다. 예를 들어 리더임에도 불구하고 리더의 모습을 보여주지 못할 때, 외부의 평판에 비춰 큰 퍼포먼스를 낼 수 있을 것으로 예상했지만 실제로는 그러지 못했을 때 등의 경우를 가정해보겠습니다. 처음에는 신뢰부채를 덕에 높아진 신뢰자산을 기반으로 일을 추진할 수 있었겠지만, 이후에는 신뢰부채에 대한 책임을 지지 못했기 때문에 오히려 신뢰자산이 적은 상태에서 일을 진행할 수밖에 없게 될 것입니다.

결과적으로 우리가 한 개인을 신뢰한다는 것은 ‘그 사람의 과거 행동을 기반으로 다져진 최소한의 믿음’과 ‘그의 평소 행동, 지위, 일하는 스타일, 태도, 지향하는 가치를 통해 아직 겪어보지 않은 일을 해결하는 능력에 대해 타인이 가지는 어림짐작’의 합입니다. 이를 프로덕트 개발 문화에서는 ‘신뢰자산’으로 다루고 있습니다.

신뢰자산이 프로덕트 개발에 중요한 이유

신뢰자산이 프로덕트 개발에서 중요한 이유는 크게 두 가지가 있습니다.

1) 커뮤니케이션 비용 절약

프로덕트를 개발하는 과정에서는 끊임없이 ‘모호함’의 영역이 발생합니다. ‘기획이 정리해야 하는 것인가, 개발이 정리를 해야 하는 것인가’처럼, ‘닭이 먼저 인지 달걀이 먼저인지’와 같은 답을 알 수 없는 문제들이 생깁니다.

단적인 예를 들어보겠습니다. 정해진 기간 내에 개발을 완료해야 하는데, 갑작스럽게 보안 혹은 사업 쪽에서 너무 작지도 크지도 않은 요구사항을 추가하는 상황을 가정해봅시다. 이때 ‘이 요구사항을 수용할지를 결정할 주체는 누구일까요? 이에 대해 PM도 개발자도 섣부르게 대답할 수 없을 것입니다. 이 상황에서 만약 서로가 서로를 신뢰하지 않는다면, 서로의 입장만을 고수하며 일을 떠넘기는 형태로 커뮤니케이션이 길어질 것입니다. 하지만 서로 신뢰자산이 어느 정도 형성이 되어있다면, 다를 것입니다. 개발자보다 기획자가 더 큰 신뢰자산을 가지고 있다면 기획자가 전체적인 상황을 보고 빠르게 정리할 것이고, 기획자보다 개발자가 더 큰 신뢰자산을 가지고 있다면 개발자가 개발 피저빌리티 체크를 통해 빠르게 정리할 수 있을 것입니다. 만약 두 사람 모두가 서로에 대한 신뢰자산을 비슷한 수준으로 두텁게 형성하고 있다면, 가장 현명한 방법이 무엇인지 빠르게 논의하고 상황을 정리하겠죠.

프로덕트 개발에서 ‘신뢰자산’은 나와 협업하는 타인이 해낼 수 있을 것으로 기대되는 능력치의 징표 역할을 합니다. ‘이 정도 일은 잘 해낼 수 있을 것이다’ 하는 기대를 담는 그릇이죠. 이를 통해서 ‘모호한’ 영역이 발생해 커뮤니케이션 비용이 소모될 때, 상황을 빠르게 정리할 수 있도록 도와줍니다.

2) 담대한 도전 독려(프로덕트 성공의 불확실성에 대한 안전망)

성공하는 프로덕트를 기획하고 만드는 것은 매우 어려운 일입니다. 대개 우리는 소비자의 말과 행동을 참고하여 제품을 기획합니다. 가정을 반복하는 것에서 기획이 출발하죠. 물론 예측을 하지만 그것은 예측에 불과합니다. 가벼운 제품의 경우에는 빠르게 시도할 수 있어 함께 만들어가는 사람들이 ‘결과를 보고 판단하자’는 마음만 같이 가진다면, 특별한 설득 과정이 필요 없습니다. 하지만 최소 3개월 이상 진행되는 무거운 프로덕트의 경우에는 책임이 막중해져서 설득이 필요한 과정이 빈번하게 발생합니다.

신뢰자산은 여기서 빛을 발합니다. 출발점이 되는 논리가 타당하고, 발제자의 신뢰 자산이 충분하다면 구성원들을 설득하는 과정이 크게 줄어들게 됩니다. 구성원들이 발제자의 신뢰자본을 인정해주고 있다면, 최종 의사결정자를 설득하는 것만으로 충분합니다. 구성원 하나하나를 설득할 필요가 없는 것이죠. 또한 이는 프로덕트 개발 과정에서 발생할 수 있는 모호하고 불안한 영역들을 해결해 나가는 데에 큰 도움이 됩니다. 이때문에 함께 만들어가는 사람들이 도전적인 프로덕트를 만들어나가는 데에 더욱 열정적으로 참여할 수 있습니다.

신뢰자산을 쌓는 세 가지 방법

1) 본업을 잘하는 모습을 보여준다

기획자라면 사용자의 문제를 해결해주는 제품의 PRD를 명확하게 작성해야 합니다. 디자이너라면 요구사항에 부합하며 사용자를 고려한 디자인을 제시해야 하고, 개발자라면 최종 기획 사항에 대해 최선을 다해 개발해야 합니다.

각자가 자신의 영역에서 책임 있는 역할을 다하는 모습을 보여주는 것이 ‘신뢰자산’이 형성되는 데 기본이 됩니다. 결국 우리가 ‘신뢰자산’을 쌓는 이유는, 모호한 영역의 일을 자율적이고 신속하게 해결하기 위함입니다. 그러려면 서로 믿을 수 있는 존재라는 전제가 있어야 하고 그때 필요한 게 신뢰자산인 것입니다. 라포를 형성하는 것이나 단순한 커뮤니케이션만으로는 신뢰가 생기기 어렵습니다.

TIP: 만약 자신의 본업에 대해 아직 자신감이 없는 경우, 현재 내가 프로덕트를 어떻게 최선을 다해 만들고 있는지를 구성원들과 이야기 나누세요. 이야기를 나누다 보면 서로 간의 기대치를 확인할 수 있고, 이를 기점으로 보다 빠르게 본업에 대한 신뢰를 쌓아 나갈 수 있을 것입니다.

2) 도전적인 일을 약속하고, 이를 지킨다

신뢰자산의 개념을 다시 한번 복습해봅시다.

이 정의를 보면, 신뢰부채를 쌓는 것은 곧 신뢰자산을 쌓는 것으로 이어집니다. 행동을 통해 신뢰자본을 쌓을 수도 있지만 보다 어려운 일에 도전해 타인의 기대에 기반한 신뢰부채를 쌓을 수도 있습니다. 나의 신뢰자본을 넘어서는 일에 도전할 때, 처음엔 구성원이 의심의 눈초리를 보낼 수 있습니다. 하지만 그 상황에서 주도적으로 책임감 있게 일을 진행하고, 최선을 다해 목표를 달성한다면 그 신뢰부채는 곧 신뢰자본으로도 이어질 것입니다. 

3) 라포를 형성한다

라포 형성을 통해 서로가 서로의 맥락을 이해한다면, 신뢰 자산이 증가할 수 있습니다. 서로가 수행한 작업이나 추구하는 방향을 이해하는 과정은 기존 신뢰 자산의 크기를 증대시킬 수 있습니다. 그러나 라포 형성만으로 신뢰 자산이 증가되는 것은 아닙니다. 라포 형성 과정에서 서로의 맥락을 이해하면서 신뢰 자산이 증대되는 것이 핵심입니다.

라포 형성에 가장 효과적인 방법은 구글, 넷플릭스, 메타 등의 실리콘 밸리 기업에서 활용되고 있는 1 대 1 대화인 '원온원 미팅'입니다. 팀원들이 함께 업무나 경력 개발, 성장에 대해 깊이 있는 대화를 나누는 것입니다.

TIP: 원온원을 어떻게 잘 해야 할까 고민이 되신다면, 아래 두 가지 방법을 참고하시기를 추천합니다.

• 코칭 대화 모델에서 가장 많이 사용하는 GROW 모델(출처: 책 <원온원>)
• Goal(목적 형성 및 합의) → Reality(현실 인지) → Option(선택지 모색) → Will(실행 의지 확인)
• Goal 이전에 Rapport(라포 형성)을 먼저 하고, Will 이후에 Follow-up (후속 조치)을 추가해 진행할 수도 있습니다.
• 구글의 원온원 템플릿

신뢰자산을 쌓기 위해서는 조직의 구조 또한 중요해요. 

지금까지 글을 보신 분이라면, 누군가는 이렇게 말할 수도 있습니다. "신뢰자산이 조직에서 지원을 받지 못한다면, 그걸 열심히 쌓아도 의미가 없지 않나요?" 맞습니다. 신뢰자산을 형성하고 활용하려 해도, 조직 구조가 이를 방해한다면 프로덕트를 만드는 과정에서 "신뢰"를 쌓는 것이 무의미할 수 있습니다. 구성원들의 신뢰 자산을 조직에서 활용하기 위해서는 다음 3가지가 중요합니다.

1) 과도하게 영역 구분을 하지 않는다

조직 내 각 담당자들 사이에서 과도하게 영역을 구분하는 경우가 종종 벌어집니다. 프로덕트를 함께 잘 만들려고 원온원 미팅을 요청하거나 커뮤니케이션을 하려고 하는데, 월권이라고 생각하거나 내 담당이 아니라고 생각하는 것들이 그에 해당합니다. ‘개발이 알아서 해야 하는 일’ ‘기획이 알아서 해야 하는 일’이라고 선을 긋듯 구분해버리는 것이죠. 좋은 조직에서는 구성원들이 “이런 경우 어떻게 처리할까?”에 관해 이야기하지, “이건 그 팀이 알아서 정리해주세요”라며 서로에게 책임을 떠넘기지 않습니다. 서로 신뢰자산을 쌓고 이를 기반으로 원활하게 소통할 수 있도록 조직이 지원해줄 수 있어야 합니다.

과도한 영역 구분의 예 

• PM이 UX에 대한 사항을 디자이너의 전적인 책임의 영역으로 설정하는 행동
• PM 이 프로덕트를 함께 개발하는 백엔드 개발자와 원온원 미팅을 하려 하는데 개발 리드가 이를 월권으로 생각하고 막는 행동.

2) 신규 입사자에게 신뢰 부채를 부여한다

신규 입사자는 아직 보여준 것이 없기 때문에, 신뢰자산을 0부터 차근차근 쌓게 만들어야 한다고 생각할 수 있습니다. 그렇게 하는 조직을 종종 보는데요. 이는 생각보다 조직의 비효율성을 증가시킵니다. 새로 입사한 사람이 처음부터 신뢰자산을 쌓는 것은 당연히 어려운 일입니다. 회사에 적응하는 시간을 주는 것도 당연하지만, 0부터 시작하게 하는 것은 일의 진행을 더디게 만듭니다. 오히려 그에게 신뢰부채를 부여해 일을 진행하게 하고, 그 결과에 따라 신뢰자산을 관리하는 것이 더 효과적이고 효율적인 방법입니다.

3) 실패에 대해 낙인을 찍지 않는다

누구나 실패할 수 있습니다. 그런데 실패를 한 사람은, 조직 내에서 신뢰자산의 많은 부분을 잃게 됩니다. 이때 조직이 그 사람을 실패자로 낙인을 찍는다면, 조직이 그의 신뢰자산을 0으로 만들어버리는 것입니다. 조직은 오히려 실패를 통해 신뢰자산을 잃은 구성원이 신뢰자산을 회복할 수 있도록 돕는 것입니다. 실패를 회고하도록 해 스스로 신뢰자산을 회복할 수 있는 기회와 안전망을 주어야 합니다. 그래야 구성원들이 서로의 신뢰를 기반으로 더욱 자율적으로 도전적인 일을 실행할 수 있을 것입니다.

마치며

2001년 등장한 ‘애자일 선언서’에서는 완벽한 계획과 문서를 마련하는 것보다, 작동하는 소프트웨어를 우선시하며 그를 위해 변화에 대응하기 위한 협력 과정을 구축하는 것을 중요하게 생각합니다. 특히 IT 프로덕트는 여러 사람이 함께 만들기 때문에 사람 사이의 상호작용과 소통이 스킬보다 더 중요합니다. 함께 일하는 사람들이 서로가 얼마나 신뢰하는지에 따라 개발 속도가 결정될 수 있습니다. 그래서 IT 프로덕트 개발에서는 ‘신뢰자산’이 프로덕트의 런칭과 운영의 효율성을 높이는 데에도 매우 중요합니다. 모두 효과적인 ‘신뢰자산’ 관리를 통해서 좋은 프로덕트들을 빠르게 만들어 낼 수 있기를 응원합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.