고객의 말대로 바꿨는데, 왜 더 나빠졌을까

서비스를 만든 개발자라면 그 서비스를 가장 많이 쓰는 사람도 나여야 한다고 생각합니다. 내가 불편해서 만든 서비스라면 더 그렇습니다. 남들에게는 써달라고 하면서 정작 나는 다른 서비스를 쓰고 있다면, 이유부터 생각해봐야겠죠.

자기가 만든 제품을 직접 쓰는 걸 도그푸딩이라고 합니다. 저는 이게 제품을 판단하는 가장 기본적인 출발점이라고 생각합니다.

이야기를 조금 바꿔보겠습니다. 개발자의 정석 루트대로 제가 개발자로 먹고살기 어려워져 고향에 내려가 치킨집을 차렸다고 해보겠습니다.

처음에는 장사가 제법 됩니다. 한두 달쯤 지났을 때 손님 열 명 중 한 명이 리뷰를 남깁니다.

“너무 짜요. 이 집은 염지를 어떻게 하길래 이렇게 짜나요?”

염지까지 언급하는 걸 보니 좀 아는 사람 같습니다. 이 손님의 말을 듣고 염지를 줄입니다. 그런데 그다음부터 매출이 반토막 납니다.

왜 이럴까요?

맛집에 가보면 사장님들이 자기 음식에 대한 자부심이 참 강하다는 생각이 듭니다. 제 입에 맛있든 맛없든 그렇습니다. 저는 별로라고 생각했는데 손님은 계속 들어오는 집도 있습니다.

그런 집을 보면 사장님은 자기가 어떤 맛을 내고 싶은지, 어떤 손님들이 그 맛을 좋아해서 오는지 알고 있다는 생각이 듭니다. 제 입맛에는 맞지 않아도 그 맛을 좋아하는 사람들은 있는 거죠.

그런데 치킨집 사장이 된 저는 제 치킨이 어떤 맛인지, 손님들이 왜 찾아오는지도 충분히 알아보지 않고 한 사람의 말에 염지를 바꿨습니다. 염지를 안다는 말이 그 사람의 입맛까지 모든 손님을 대표하게 해주지는 않는데 말입니다.

리뷰를 남긴 한 명의 말은 들리지만, 나머지 아홉 명의 생각은 들리지 않습니다. 맛있어서 아무 말도 안 했을 수도 있고, 맛없어서 다신 안 오기로 했을 수도 있습니다. 말하기를 선택한 사람들의 의견만 모이다 보니 전체 손님의 생각과 차이가 생길 수 있습니다. 이런 것을 자기선택 편향이라고 합니다.

그럼 “짜다”는 리뷰를 무시하면 될까요? 저는 여기서 사장이 자기 치킨을 얼마나 먹어봤는지가 중요하다고 생각합니다.

평소에도 먹어봤다면 오늘따라 염지가 과했는지, 원래 이 정도 간으로 만들었는지부터 확인할 수 있습니다. 전자는 고쳐야 할 문제입니다. 후자라면 이 간을 좋아해서 오는 손님까지 생각하며 판단해야겠죠. 자기 치킨도 안 먹어보는 사장이라면 이 둘을 구분하기가 어렵습니다.

내 제품에 대한 확신은 이런 데서 나와야 한다고 생각합니다. 내가 만들었으니 옳다는 자신감보다, 왜 이렇게 만들었고 실제로 어떤 경험을 주는지 아는 데서요. 그래야 고객이 내가 놓친 문제를 알려주는 건지, 내가 의도한 선택에 다른 취향을 제안하는 건지 판단할 수 있습니다.

서비스로 옮겨보면 어떨까요. 제가 매일 쓰는 화면에 “버튼이 너무 많다”는 의견이 들어왔다고 가정해봅시다.

화면을 깔끔하게 만들려고 버튼을 메뉴 안에 넣었습니다. 그런데 자주 쓰던 기능을 실행하려면 이제 한 번 더 눌러야 합니다.

겉으로는 요청을 반영했고 화면도 정리됐습니다. 하지만 매일 그 기능을 쓰던 사람에게는 전보다 불편해졌습니다. 저부터 매일 쓰고 있었다면, 버튼을 숨기기 전에 그 한 번을 생각했을 겁니다. 피드백을 받으면 곧바로 수정 목록에 넣기 전에 어떤 불편에서 나온 말인지부터 알아봐야 합니다.

직접 쓴다고 모든 답을 알게 되는 것도 아닙니다. 저는 제가 만든 블로그를 매일 읽습니다. 그런데 독자들이 제 생각도 읽고 싶다고 해서 Notes를 만들었고, 이메일로 받아보고 싶다는 요청이 반복돼 뉴스레터도 만들었습니다.

저는 제 생각을 이미 알고 있고 사이트를 직접 열어보는 사람입니다. 혼자만 썼다면 두 기능의 필요성을 지금처럼 느끼기 어려웠을 겁니다. 직접 쓰면서 쌓은 이해가 있어야 의견을 판단할 수 있고, 다른 사람의 의견이 있어야 내 사용 방식 밖의 필요도 보입니다.

다시 치킨집으로 돌아가보겠습니다. 매주 주문하던 손님이 어느 날부터 주문하지 않습니다. 리뷰도 없습니다.

이제야 사장은 조용한 손님의 이야기가 궁금해집니다.

치킨이 질렸을까요? 다른 집이 더 맛있었을까요? 우리 집 치킨 맛이 달라졌을까요?

주문 기록이 있다면 질문을 조금 좁힐 수 있습니다. 염지를 바꾸기 전부터 오던 손님들의 재주문이 줄었는지, 새로 온 손님들은 다시 주문하는지 비교해볼 수 있겠죠. 비슷한 시기에 온 손님들을 묶어 다시 오는 비율을 보는 겁니다.

그래도 기록에 “싱거워져서 떠났음”이라고 적혀 있지는 않습니다. 대신 어느 손님에게 무엇을 물어보고, 어떤 변화를 작게 시험해볼지 정할 수 있습니다.

제가 블로그에서 페이지에 머무는 시간이나 클릭, 많이 읽히는 콘텐츠를 보는 이유도 비슷합니다. 이 글을 읽고 다음 글로 넘어갈 거라고 생각했는데 실제로는 그 전에 나간다면, 제가 예상한 흐름과 다른 일이 벌어지고 있는 겁니다. 내용을 다 읽었을 수도 있고 다음 글로 가는 길을 못 찾았을 수도 있습니다. 로그는 그 이유를 확인할 곳을 알려줍니다.

뉴스 소스에 접근이 되는지, 예약 작업이 어디서 실패했는지 같은 운영 로그도 함께 봅니다. 읽을 만한 글을 찾기 어려워서 떠난 줄 알았는데 새 글 수집부터 멈춰 있었다면, 화면만 고쳐서는 해결이 안 되니까요.

저는 제품을 만드는 사람이 사용자 의견에 따라 움직이기만 해서는 안 된다고 생각합니다. 어떤 의견을 왜 반영할지 설명할 수 있어야 합니다. 그러려면 직접 써보고, 들려오는 말을 듣고, 말없이 남겨진 행동도 확인해야겠죠.

AI로 데이터를 분석하는 일은 무척 쉬워졌습니다. 하지만 무엇을 기록하고, 무엇을 분석할지 정하는 일은 아직 개발자의 몫이 아닐까 생각합니다.