팀원이 직접 써 볼 수 있는 제품이라면, 인터뷰 보고서보다 송금 한 번이 세다

토스뱅크 해외송금 팀의 사례를 우리 팀에 옮기려면 먼저 물어야 할 게 하나 있습니다. 우리 팀원이 이 제품의 사용자가 될 수 있는가. 글의 제목은 도메인 지식 없는 디자이너가 팀의 기준을 바꿨다는 건데, 사실관계를 따라가 보면 결정타는 디자이너의 질문이 아니라 PM이 영국으로 보낸 송금 한 번이었거든요. 그 방법이 통하려면 조건이 붙습니다.

인터뷰 보고서는 팀을 설득하지 못했다

출발점은 흔한 풍경이에요. Product Designer 서자영이 합류하고 6개월 뒤 런칭해야 했던 해외송금은 파트너사 선정, 전문(電文) 설계, 규제 검토가 산더미였고, 후발주자로서의 강점에 대한 팀의 답은 이미 정해져 있었습니다. 수수료가 싸야 한다.

디자이너는 실제로 해외에 돈을 보내 본 사람들을 여러 번의 스크리닝 끝에 만났어요. 수수료가 아깝다는 말은 나왔지만, 조금 싸다고 은행을 옮기지는 않겠다는 쪽이었습니다. 반복해서 나온 건 불안이었죠. 외국 은행 계좌번호를 입력하는 순간부터 돈이 도착하는 이틀 동안, 제대로 입력했는지, 내 돈이 지금 어디 있는지를 계속 걱정한다는 것. 유학생, 현지 체류자, 해외 비즈니스 담당자로 송금하는 상황은 제각각이었는데도 걱정의 모양은 비슷했어요.

이걸 팀에 공유했을 때 돌아온 반응이 "그래도 결국 제일 싼 곳이 이기는 것 아닌가요?"였어요. 저는 이 반문이 틀렸다고 보지 않습니다. 인터뷰 대상은 이미 다른 은행으로 송금해 온 사람들이었고, 그들이 옮기지 않는 이유 중 하나는 수수료가 은행마다 크게 다르지 않아서였어요. 그건 수수료가 중요하지 않다는 증거가 아니라 지금은 차이가 작다는 증거입니다. 팀의 의심은 합리적이었고, 인터뷰 보고서는 그 의심을 넘을 만큼 강하지 않았던 거죠.

팀을 움직인 건 다음 장면입니다. 한 PM이 직접 영국으로 돈을 보냈더니 화면에 초록 체크와 '정상 송금'이 떴고, 다음 날도 그다음 날도 같은 화면이었어요. 고객센터는 문제없다고 했고, PM은 이렇게 말했습니다. "걱정하지 말라고 했는데, 걱정은 그대로였어요." 그 뒤로 "결국 싼 곳이 이기지 않냐"던 사람들이 각자 다른 은행으로 송금을 해 보기 시작했죠.

공정하게 말하면 모른다는 게 쓸모 있던 순간도 있었어요. 돌이켜 보니 팀원 중 누구도 실제로 해외에 돈을 보내 본 사람에게 무엇이 불편했는지 물어본 적이 없었다는 대목이요. 도메인을 잘 아는 사람일수록 답을 안다고 생각해서 묻지 않게 되고, 그 빈자리를 모르는 사람이 메운 겁니다. 다만 거기까지가 질문의 몫이었고, 확신을 바꾼 건 그다음 장면이었어요.

보고서는 남의 경험을 믿어 달라는 요청이고, 체험은 자기 경험입니다. 이 사례에서 디자이너가 한 가장 큰 일은 좋은 질문을 던진 것보다 팀이 직접 겪을 경로를 연 것이라고 저는 읽어요.

체험이 설득이 되는 조건

이 방법이 통한 데에는 해외송금이라는 제품의 성격이 크게 작용했습니다. 계좌만 있으면 팀원 누구나 사용자가 될 수 있고, 한 번 해 보는 비용이 송금 수수료 정도로 싸요. 게다가 비교 대상이 나빴습니다. PM이 겪은 건 경쟁 은행의 '정상 송금' 3일이었으니까요.

셋 중 하나만 빠져도 얘기가 달라집니다. 사업자 정산 도구나 자격 요건이 있는 금융 상품처럼 팀원이 사용자가 될 수 없는 제품이라면, 팀원이 직접 써 보는 건 사용자를 연기하는 데 그칩니다. 그럴 땐 실제 사용 현장에 동행하는 쪽이 체험에 더 가깝고요. 기존 서비스들이 이미 꽤 괜찮은 시장이라면 체험은 "생각보다 괜찮네"로 끝나 오히려 원래 가설을 굳혀 줄 수도 있습니다.

기준이 바뀌면 통과하는 비용이 바뀐다

기준 전환의 효과는 디자인 결정보다 예산 결정에서 더 잘 보여요. 은행 코드 입력칸이 대표적입니다. CHASUS33XXX 같은 코드를 입력하면 곧바로 'JP Morgan Chase'가 뜨게 했는데, 이를 위해 코드와 은행 이름을 잇는 별도 작업이 필요했고 송금 자체에는 없어도 되는 기능이었어요. 이전 기준이었다면 "굳이 필요한가?"에서 끝났을 거라고 디자이너 스스로도 적었습니다.

주소 입력도 같습니다. 개발자가 지도 앱처럼 검색해 고르는 방식을 제안했지만 지도 API 연동과 호출 비용이 들었고, 다른 은행은 자유 입력으로 받는 정보였어요. 이 비용은 사용자 편의에 더해 오타로 인한 반송이 줄어든다는 운영 효율 논리로 통과했습니다. 불안이라는 기준이 이런 비용에 '왜 써야 하는지'를 붙여 준 셈이에요. 좋은 제품 기준의 쓸모는 결국 어떤 지출이 리뷰를 통과하느냐에서 드러납니다.

세 칸 중 첫 칸이 길다면

송금 후의 불안에 대한 답은 상태를 줄이는 것이었습니다. 고객 확인, 외국환거래 규정 확인, AML·제재 스크리닝, 수취 은행 검사, 입금, 사후 모니터링. 서버 개발자와 '이건 사용자가 알아야 하는 정보인가, 아니면 우리만 알고 있으면 되는 정보인가?'를 하나씩 따져 아홉 개였던 상태를 송금 처리 중 → 해외 은행 도착 → 완료의 세 개로 줄였어요.

질문 자체는 훌륭하다고 봅니다. 다만 PM이 겪은 문제를 다시 떠올려 보면, 그건 상태가 많아서가 아니라 '정상 송금'이라는 한 상태에 3일을 머문 것이었어요. 상태를 세 개로 줄이면 각 칸에 머무는 시간은 오히려 길어집니다. 앞의 검사 단계들이 '송금 처리 중' 한 칸에 모인다면(제 추정입니다), 그 칸이 PM이 본 '정상 송금'을 닮아 갈 위험이 있어요. 불안을 덜어 주는 건 칸의 개수가 아니라 이 칸이 언제 넘어가는지 아는 것이고, 글에는 각 상태에 예상 시각이나 체류 시간을 보여 주는지가 나오지 않습니다. '보내면 보이는 해외송금'에서 보이는 게 위치뿐이라면 절반만 보이는 셈이죠.

이 사례를 들여오려는 팀에 권하고 싶은 건 순서 하나예요. 기준을 세울 때 쓴 체험을 출시한 뒤에도 똑같이 반복하는 것. 이번에는 경쟁 은행이 아니라 자기 제품으로, 팀원 몇 명이 실제로 송금을 걸어 두고 '송금 처리 중'을 하루 동안 지켜보는 겁니다. 그 하루가 PM의 3일과 다르게 느껴진다면 기준은 제품에 들어간 거고, 같게 느껴진다면 아직 슬로건에만 들어가 있는 거예요.