당신의 '인사이트'는 혹시 그냥 잡학지식 아닌가요?

제품 회의에서 가장 남용되는 단어

요즘 프로덕트 업계에 있다 보면 '인사이트'라는 단어를 정말 자주 듣게 돼요. 마치 조미료처럼 여기저기 뿌려지는 느낌이랄까요.

PM들은 사용자 문제를 해결하는 '인사이트'를 찾아내는 걸 좋아하죠. 하지만 제 경험상 '인사이트'만큼 많이 오남용되는 용어도 없는 것 같아요. 단순한 상관관계를 인사이트라고 포장하거나, 개인 의견을 문서에 인사이트처럼 끼워 넣거나, 그냥 권위 있어 보이려고 회의에서 '인사이트'라는 단어를 남발하는 경우를 너무 많이 봤거든요.

실제로 회사에서 이런 일이 있었어요. 한 동료가 자신 있게 말했죠. "개발자들은 CLI 명령어로 앱 스캐폴딩할 필요 없어요. 그냥 깃허브에서 샘플 앱 클론하면 되니까요."

듣기엔 명쾌하고 자신감 넘치죠. 뭔가 인사이트처럼 들리기도 하고요. 그래서 제가 물었어요. "두 가지 플로우의 마찰을 실제로 테스트해봤나요? 레포를 클론한 다음 수동으로 작업 환경으로 바꾸는 개발자들과 실제로 이야기해봤나요?"

알고 보니 정성적이든 정량적이든 어떤 데이터도 없었어요. 그냥... 개인적인 생각이었던 거죠. 제가 조금 더 파고들자 그 동료는 일화적인 증거에 기대며 큰 고객사 이름을 꺼내들었어요. 마치 결정적인 카드처럼요.

그건 인사이트가 아니에요. 방어 기제죠.

그래서 우리는 실제로 테스트해봤어요. 대부분의 개발자들이 3단계에서 막혔고, 뭘 삭제해도 안전한지 확신하지 못해 헤맸어요. 두 명은 아예 포기하고 처음부터 수동으로 다시 시작했고요.

진짜 인사이트는 "개발자들이 CLI 명령어를 원한다"가 아니었어요. "샘플 앱을 클론한 개발자들은 자신의 니즈에 맞게 역설계해야 하기 때문에 바로 시작하지 못한다"였죠. 이게 결정을 바꿨어요. 우리는 단순히 스캐폴딩 명령어만 추가하지 않았어요. 최소한의 시작점을 만들고 CLI 명령어로 감쌌죠.

그 동료의 의견대로 했다면 우리는 그냥 기능 하나를 출시했을 거예요. 진짜 인사이트 덕분에 우리는 올바른 것을 출시했고요.

상관관계 찾기가 당신의 진짜 일은 아니에요

대부분의 PM들이 공유하는 '인사이트'는 사실 그냥 상관관계예요. 솔직히 말씀드릴게요. 여러분은 패턴을 공유하라고 돈을 받는 게 아니에요. 근본 원인을 설명하고 다음에 무슨 일이 일어날지 예측하는 게 여러분의 일이죠.

그래서 많은 팀들이 실제로는 인사이트를 가지고 있지 않아요. 그들이 가진 건 그럴듯하게 포장된 관찰일 뿐이에요.

저도 예전엔 그랬어요. 제 매니저가 직접 얼굴 보고 지적해주기 전까지는요. Appsmith에서 일할 때였어요. 저는 분석 데이터를 들여다보다가 뭔가를 발견했죠. 온보딩을 완료한 사용자들의 리텐션율이 더 높더라고요. 너무 신이 나서 이걸 마치 대발견처럼 포장했어요. 매니저한테 가서 말했죠. "흥미로운 인사이트를 발견했어요."

매니저는 그냥 넘어가지 않았어요. 이렇게 말했죠.

"이건 인사이트가 아니야. 잡학지식이지."

잠시 멍했어요. 가혹해서가 아니라 정확해서요. 그때 깨달았어요. 저는 제품 사고를 하고 있던 게 아니었어요. 패턴 해설을 하고 있었던 거죠. 지금도 그 피드백에 감사해요. 모든 회의에서 '인사이트'라는 단어를 듣는 방식을 바꿔놨거든요.

그럼 진짜 인사이트란 무엇인가요?

인사이트는 여러분이 관찰한 것과 그것이 왜 일어나는지 사이의 인과 관계 스토리예요. 다음에 무슨 일이 일어날지 예측할 수 있을 만큼 구체적이고, 여러분이 만드는 것을 바꿀 수 있을 만큼 실행 가능해야 하죠.

좀 복잡하게 들리나요? 더 간단하게 말하면 이래요.

인사이트는 결정을 강제하는 발견된 메커니즘이에요.

가설이 아니에요. 직감도 아니고요. 메커니즘이에요. 행동과 동기를 연결하는 숨겨진 '왜냐하면'이죠. 그리고 그것은 결정을 강제해요. 왜냐하면 일단 보고 나면 더 이상 기존 방식을 정당화할 수 없거든요.

제가 인사이트를 구분할 때 쓰는 리트머스 테스트가 있어요. 진짜 인사이트는 이런 특징들이 있죠.

예측력이 있어요. X를 하면 어떻게 될지, Y를 하면 어떻게 될지 알려줘요. 무슨 일이 일어났는지가 아니라 무슨 일이 일어날지를요.

비자명성이 있어요. 인사이트를 발견하기 전에는 합리적인 사람이라도 정반대를 믿을 수 있었거나, 아예 거기를 들여다보지도 않았을 거예요.

메커니즘이 있어요. '무엇'뿐만 아니라 '왜'를 설명하죠.

대부분의 사람들은 처음 두 가지에서 멈춰요. 하지만 메커니즘이 진짜 핵심이에요.

"온보딩을 완료한 사용자가 더 높은 리텐션을 보인다." 이건 상관관계예요. 잡학지식이고요. 오해하지 마세요. 상관관계가 쓸모없다는 건 아니에요. 좋은 신호죠. 하지만 그 신호가 왜 존재하는지 설명할 수 있기 전까지는 인사이트라고 부를 수 없어요.

'왜'를 메커니즘에 도달할 때까지 물어보세요

어쩌면 온보딩을 완료한 사용자들의 리텐션이 높은 건, 온보딩이 고의도 사용자를 걸러내기 때문일 수 있어요. 그렇다면 온보딩을 아예 제거하고 자가 선택하게 해도 같은 리텐션을 얻을 수 있겠죠.

아니면 온보딩이 실제로 제품을 이해하게 만드는 멘탈 모델을 가르쳐서, 온보딩을 줄이면 리텐션이 급락할 수도 있어요.

같은 상관관계예요. 정반대 결정이고요.

메커니즘을 설명할 수 없으면 확신을 가지고 결정할 수 없어요. 그냥 패턴이 반복되길 바라는 거죠.

"3단계에서 이탈이 증가한다. 왜? 양식이 너무 길어서. 왜 그게 문제지? 사용자들은 노력을 들이기 전에 즉각적인 가치를 기대해. 왜? 그들이 사용하는 다른 모든 제품이 정보를 요청하기 전에 가치를 제공하니까. 그래서? 흐름을 뒤집어야 해. 가치 먼저, 양식은 나중에."

메커니즘에 도달했는지는 결정으로 현금화될 때 알 수 있어요. 그러니 "그래서 뭐?"로 테스트해보세요. 이게 사실이라면 무엇을 다르게 만들 건가요? 이게 사실이라면 무엇을 중단할 건가요? 답할 수 없다면 여전히 잡학지식이에요.

이게 회의에서 사람들을 정직하게 만드는 방법이에요. 누군가 "인사이트"라고 말하면 "그래서 뭐?"를 붙잡고 놓지 마세요. "음, 제 생각엔..." 이나 "큰 고객이 말하길..."로 무너진다면, 그건 인사이트로 위장한 의견을 발견한 거예요.

어떻게 진짜 인사이트를 얻을 수 있을까요?

인사이트는 구상되는 게 아니에요. 머릿속에서 두 가지 대립하는 관점이 충돌하는 거예요. 둘 다 그럴듯하고, 둘 다 불완전하죠. 실제로 무슨 일이 일어나고 있는지 설명할 수 있을 때까지 놓지 않게 만드는 뭔가예요.

저는 예전에 개발자 도구에는 더 많은 설정 가능성이 항상 더 낫다고 생각했어요. 그러다 Auth0 SDK를 샘플 앱에서 직접 써보다가 제 가정이 실시간으로 무너지는 걸 봤죠. 커서가 또 다른 설정 옵션 위에 떠 있었는데 이상한 망설임이 느껴졌어요. "완전한 설정 가능성"이 힘을 실어줄 거라 기대했는데, 오히려 끌어당기는 느낌이 들었어요. 옵션이 나빠서가 아니에요. 그 순간 제가 추구한 건 통제가 아니라 속도였거든요.

그때 깨달았어요. "개발자들은 완전한 설정 가능성을 원한다"는 제 믿음은 그냥 편안한 기본값이었다는 걸요. 모멘텀을 위해 제한된 설정을 원하는 개발자 세그먼트가 있어요.

둘 다 맞아요. 둘 다 틀리고요.

한 그룹에게 설정 가능성은 힘을 의미해요. 다른 그룹에게는 마찰을 의미하고요.

진짜 인사이트는 "사용자들이 X를 원한다"가 아니에요. "어떤 사용자들이, 어떤 순간에, 무엇을 최적화하는가"예요.

진짜 인사이트는 불편해야 해요

진짜 인사이트는 여러분을 불편하게 만들어야 해요. 신나게 하는 게 아니에요. 검증해주는 것도 아니고요. 불편하게요.

왜냐하면 그건 이런 의미거든요.

여러분이 인정하고 싶은 것보다 오랫동안 뭔가에 대해 틀렸다는 것. 바라던 쉬운 길은 안 통한다는 것. 더 어려운 일이 이제 여러분의 몫이 됐다는 것. 이제 못 본 척할 수 없고 행동해야 한다는 것.

그 불편함은 여러분이 가장 좋아하던 설명을 잃는 느낌이에요. 여러분을 통제하고 있다고 느끼게 했던, 이미 가지고 있던 로드맵을 정당화했던 그 설명이요.

'인사이트'가 기분 좋게 느껴지고, 이미 믿고 있던 걸 확인해주고, 이미 하고 있던 걸 정당화하고, 이해관계자들이 고개를 끄덕이게 만든다면, 그건 아마 인사이트가 아닐 거예요. 그건 분석으로 포장된 자기 축하죠.

최고의 인사이트는 긴장을 만들어요. 보통 이런 식으로 들리죠.

"우리가 하고 있는 일은 안 통할 거예요. 왜냐하면....."

"우리는 틀린 문제를 풀고 있어요. 왜냐하면....."

"우리가 무시해왔던 경쟁사가 진짜 위협이에요. 왜냐하면...."

그래서 대부분의 팀들이 진짜 인사이트를 피하는 거예요. 정치적으로 비용이 많이 들거든요. 리더십에게 현재 계획에 결함이 있다고 말해야 하죠. 편한 대화가 아니라 어려운 대화를 해야 하고요.

하지만 그 긴장이 바로 핵심이에요. 긴장이 없으면 강제되는 결정도 없어요. 강제되는 결정이 없으면 여러분은 그냥 세상을 묘사하고 있는 거예요. 여러분이 만드는 것을 바꾸는 게 아니라요.

가짜 인사이트가 가져오는 비용

가짜 인사이트로 운영되는 팀에서 무슨 일이 일어나는지 아세요? 로드맵이 "말이 되는" 기능들로 채워지지만 지표는 움직이지 않아요. 출시는 이뤄지지만 아무것도 바뀌지 않죠.

글로벌 PM 커뮤니티 조사에 따르면, 제품 출시의 약 40%가 기대했던 비즈니스 임팩트를 만들어내지 못한다고 해요. 마이크로소프트의 연구에서도 비슷한 결과가 나왔는데요, A/B 테스트 중 겨우 3분의 1만이 실제로 긍정적인 결과를 보였다고 합니다. 나머지는 효과가 없거나 오히려 역효과를 냈죠.

그동안 기능을 출시한 PM은 출시한 것에 대해 인정받아요. 실패는 시장 상황, 타이밍, 또는 엔지니어링 실행 탓으로 돌려지고요. 가짜 인사이트는 문서에서 엄밀해 보였기 때문에 비난받지 않아요.

이렇게 똑똑한 팀들이 평범한 제품을 만드는 거예요. 게으름 때문이 아니에요. 패턴 해설을 전략적 사고로 받아들이자는 집단적 합의 때문이죠.

기준을 높여야 합니다

상관관계, 일화, 의견 모두 회의실에 있을 자격이 있어요. 그건 원재료예요. 하지만 메커니즘을 설명하고 그 메커니즘을 결정으로 바꿀 수 있기 전까지는 인사이트라고 부를 자격이 없어요.

다음번에 회의에서 "여기 인사이트가 있습니다"라고 말하려고 할 때 잠깐 멈춰보세요. 스스로에게 물어보세요.

이게 일어났다는 것만이 아니라 왜 일어나는지 설명할 수 있나요? X를 하면 어떻게 될지, Y를 하면 어떻게 될지 예측할 수 있나요? 이게 결정을 강제하나요, 아니면 그냥 세상을 묘사하는 건가요?

세 가지 모두에 예라고 답할 수 없다면, 있는 그대로 부르세요. 관찰, 가설, 직감이라고요. 괜찮아요. 정직한 거예요. 하지만 인사이트라고 부른다면, 누군가 "그래서 뭐?"를 붙잡고 놓지 않을 준비를 하세요.

핵심 요약

진짜 인사이트는 여러분을 불편하게 만들고, 메커니즘을 설명하며, 결정을 강제해요. 단순한 패턴 발견이나 상관관계 공유는 여러분의 진짜 일이 아니에요. "왜"를 끝까지 파고들어 인과관계를 밝히고, "그래서 뭐?"로 실행 가능성을 검증하세요. 가짜 인사이트는 똑똑한 팀을 평범한 제품으로 이끌어요. 여러분이 다음번에 회의에서 입을 열기 전에, 그게 정말 인사이트인지 스스로에게 물어보세요. 패턴 해설을 전략적 사고로 착각하지 마세요. 그 차이를 아는 것, 그게 바로 여러분의 일이에요.