우리는 누구의 기준으로 보는가

다음 주 출시를 앞둔 기능에 대해 전사 QA를 진행했다. 판매와 직결된 기능이었고, 다양한 결제 상황을 포함한 테스트가 필요한 영역이었다. 다행히 치명적인 버그는 없었다. 문제는 예상치 못한 곳에서 나왔다. 반복적으로 올라온 의견이 있었다. 특정 버튼이 잘 보이지 않는다는 것, 어디를 눌러야 할지 헷갈린다는 것이었다. 이 피드백을 팀에 공유했을 때 돌아온 반응은 거의 비슷했다. "버튼이 있는데 왜 못 찾지?" "딱 보이는데 굳이 대응해야 할까?" 틀린 말은 아니었다. 버튼은 실제로 존재했고, 확인도 가능했다. 하지만 상황을 다시 들여다보니 이유는 금방 드러났다. PC 환경에서는 문제가 없었지만, 많은 사람들이 모바일로 테스트를 진행했고, 모바일에서는 좌우 스크롤을 해야만 그 버튼이 화면에 나타났다. 버튼은 "있었다". 하지만 사용자에게는 "없는 것"과 같았다. 이 간단한 사실을 앞에 두고도 팀의 첫 반응이 "왜 못 찾지?"였다는 것, 그게 이 이야기의 핵심이다. --- 사용자 피드백을 받을 때 팀원들이 가장 먼저 꺼내는 말은 겉으로는 "왜 저 사람은 이걸 못 찾지?"처럼 들리지만, 실제 톤은 "눈에 보이는데 왜 못 찾아?"에 가깝다. 버튼도 있고, 화면에도 뜬다. 그러니 이상한 쪽은 사용자인 것처럼 들린다. 이 질문은 자연스럽게 느껴지지만, 사실 문제를 만든 사람이 문제를 겪는 사람에게 책임을 넘기는 질문이다. 이 질문에서 출발하면 제품은 바뀌지 않는다. 사용자가 바뀌기를 기다리게 된다. 질문은 반대 방향이어야 한다. "이걸 왜 못 찾게 만들었지?" 이 한 문장의 차이가 제품을 바꾼다. 우리는 오랫동안 자신이 만든 구조 안에서 살아왔기 때문에, 그 구조가 당연하게 느껴진다. "이건 당연히 보이는 거 아닌가?" "이 정도면 충분히 직관적이지 않나?" 이런 말이 입에서 나오는 순간, 우리는 이미 사용자의 자리에서 멀리 벗어나 있다. 사용자는 우리의 설계 의도를 이해하려고 노력하지 않는다. 그냥 쓰다가 막히면 떠난다. 그것이 전부다. --- 관련해서 우리는 자꾸 "더 좋아 보이는 것"을 만들려 한다. 더 깔끔한 레이아웃, 더 세련된 인터페이스, 더 완성도 있어 보이는 구조. 그런데 우리는 예술을 하는 조직이 아니다. 우리는 비즈니스를 한다. 겉으로 보기에 어색하거나 비효율적으로 보이는 설계라도, 그게 실제로 매출을 만들고 핵심 지표를 움직이고 있다면 그건 이유가 있는 설계다. 반대로 아무리 깔끔하고 완성도 있어 보여도, 사용자가 선택하지 않으면 그건 실패한 제품이다. "작동한다"는 말의 의미를 다시 생각해야 한다. 기능이 오류 없이 돌아가는 것은 작동의 최소 조건일 뿐이다. 진짜 작동은 따로 있다. 사용자가 좋다고 느끼고, 실제로 선택하고, 다시 돌아오는 것. 그게 작동하는 제품이다. 그리고 제품은 우리의 의도가 아니라, 사용자의 행동으로만 증명된다. --- 이론과 실제 사이에는 항상 간격이 있다. 그래서 기존 경제학 이론들이 실제 경제를 표현하지 못해 행동경제학이 나왔듯이, 우리도 설계의 논리와 사용자의 실제 행동 사이에 같은 종류의 간격을 마주한다. 우리는 더 나은 구조와 더 좋은 경험을 이야기하지만, 사용자는 우리의 논리대로 움직이지 않는다. 그 간격을 인정하지 않으면, 우리는 계속해서 "맞다고 믿는 제품"만 만들게 된다. 다른 좋은 서비스를 볼 때도 마찬가지다. 우리는 보고 싶은 부분만 본다. 잘 설계된 것처럼 보이는 요소만 가져와서 "우리도 이렇게 해야 한다"고 말한다. 하지만 그건 맥락이 제거된 복사일 뿐이다. 그 제품이 어떤 상황에서 만들어졌는지, 어떤 사용자를 위한 것인지, 어떤 지표를 위해 그 설계를 택했는지까지 봐야 한다. 전체를 보지 않으면, 배운 게 아니라 오해한 것이다. 그리고 이 오해가 반복되는 데는 이유가 있다. 우리는 이미 가지고 있는 생각을 확인해줄 근거만 찾는 데 익숙해져 있기 때문이다. 좋아 보이는 것만 골라 보고, 불편한 피드백은 예외로 처리하고, 맞지 않는 데이터는 맥락 탓으로 돌린다. 그렇게 쌓인 확신은 단단해 보이지만, 실제로는 검증된 적 없는 전제 위에 서 있다. 지금 우리에게 가장 필요한 것은 확증편향을 인식하는 일이다. 이미 결론을 가지고 있는 상태에서 피드백을 들으면, 논의가 아니라 방어가 된다. 자신의 생각을 지키기 위해 벽을 세우기 시작하면, 주변 사람들은 결국 설득을 포기한다. 그 순간을 우리는 쉽게 착각한다. 내가 옳았으니까 아무도 반박하지 않는다고. 하지만 실제로는 그냥 나를 포기한 것이다. 함께 더 나은 답을 찾을 기회를 잃은 것이다. --- 좋은 팀은 멋지게 보이는 제품을 만드는 팀이 아니다. 함께 일할 때 옳고 그름을 가리는 자리가 아니라 자신의 전제를 의심하고, 더 나은 질문을 찾아가는 팀이다. 피드백 앞에서도 그 질문은 같다. 못 찾았다는 사용자를 예외로 묶어 "저 사람만 그렇다"로 돌릴 것인가, 요구의 근본까지 내려가 더 잘 보이게 하고 "못 찾는다"는 말 자체가 나오지 않게 하려면 무엇을 바꿀 것인가. 어떻게든 되게 만드는 쪽으로 생각을 돌릴 때 그건 방어가 아니라 설계다. 우리가 만드는 제품은 기획자의 것도, 개발자의 것도, 디자이너의 것도 아니다. 사용자의 것이다. 그 사실을 잊지 않는 것, 그리고 그 사실로 계속 돌아오는 것. 그게 태도의 문제다. 기술이 아니라, 태도가 제품을 결정한다.