도메인 지식 없는 디자이너가 팀의 기준을 바꾼 방법

안녕하세요. 해외송금을 디자인한 토스뱅크 Product Designer 서자영입니다. 은행 지식도 외화 지식도 없던 디자이너가 규제와 운영 논리가 가득한 도메인에서 어떻게 팀의 기준을 바꿨는지에 대해 이야기해 보려고 해요.

해외송금에서 가장 중요한 건 정말 수수료일까?

팀에 합류하고 6개월 후에 해외송금 기능을 런칭해야 했는데, 제가 제대로 아는 건 없었어요. 해외로 돈을 보내면 하루 넘게 걸린다는 것도 팀에 들어오면서 처음 알았죠. 파트너사 선정, 전문(電文) 설계, 규제 검토 등 정할 건 산더미였어요. 그중에서도 당시 팀에서 가장 많이 고민했던 건 후발주자로서 어떤 강점을 가져야 할까였어요. 사실 이 질문에 대한 팀의 답은 어느 정도 정해져 있었어요. 수수료가 싸야 한다는 것.

저는 해외송금에 대한 이해도는 낮았지만, 어딘가 찝찝했어요. 정말 사용자가 가장 원하는 게 수수료가 싼 송금일까? 그런데 자신 있게 말할 수는 없었어요. 팀에서 제가 남들보다 잘 아는 건 하나도 없었거든요.

그렇다고 아무것도 할 수 없는 건 아니었어요. 도메인에 대한 지식은 부족해도, 사용자에게 직접 물어보는 건 할 수 있었죠. 돌이켜보니 팀원 중 누구도 실제로 해외에 돈을 보내본 사람에게 어떤 점이 불편했는지 물어본 적이 없었더라고요.

수수료보다 크게 느껴지는 불안

해외송금은 자주 하는 일이 아니다 보니 인터뷰 대상을 모으는 것부터 쉽지 않았어요. 여러 번의 스크리닝 끝에 실제로 해외로 돈을 보내본 분들을 만났어요.

수수료가 아깝다는 이야기는 나왔어요. 하지만 수수료가 조금 싸다고 해서 다른 은행으로 옮길 생각까지 하지는 않았어요. 수수료는 은행마다 크게 다르지 않고, 이미 송금 정보가 저장된 은행을 떠나는 것도 번거롭다는 거예요. 오히려 더 크게 반복되는 감정이 있었어요.

불안함이었어요.

유학생, 현지 체류자, 해외 비즈니스 담당자 등 송금하는 상황은 모두 달랐지만, 외국 은행 계좌번호를 입력하는 순간부터 돈이 도착하는 이틀 동안은 비슷한 걱정을 하고 있었어요.

• 내가 제대로 입력한 게 맞나?
• 지금 내 돈은 어디에 있지?
• 문제없이 가고 있는 걸까?

해외송금은 돈을 보내고 나면 당장 결과를 확인하기 어려워요. 그동안 무슨 일이 일어나고 있는지도 잘 보이지 않고요. 인터뷰를 통해 사용자가 원한 건 단순히 싼 송금이 아니라, 불안하지 않은 송금이라는 생각이 들었어요.

답을 찾았다고 생각해 인터뷰 결과를 팀에 공유했죠. 돌아온 첫 반응은 이거였어요.

“그래도 결국 제일 싼 곳이 이기는 것 아닌가요?”

사용자의 목소리만으로는 팀의 확신을 바꾸기 어려웠어요. 그래서 방법을 바꿔보기로 했어요.

팀이 직접 경험해보다

설득하는 대신, 직접 겪게 하기로 했어요. 한 PM 분이 직접 영국으로 돈을 보내봤어요. 송금을 신청하자마자 화면에 초록색 체크와 함께 ‘정상 송금’이라는 문구가 떴어요. 다음 날에도 ‘정상 송금’, 그다음 날에도 ‘정상 송금’. 3일 내내 같은 화면이었죠. 돈이 도착했다는 건지, 아직 도착하지 않았지만 문제없이 진행되고 있다는 건지 알 수가 없었어요. 고객센터에 물어봤더니 문제가 없다고 했어요. ‘정상 송금’이면 며칠 내에 안전하게 도착할 테니 걱정하지 않아도 된다고요. 이 경험을 팀에 공유하면서 PM 분이 이런 말을 했어요.

“걱정하지 말라고 했는데, 걱정은 그대로였어요.”

그때부터 이건 남의 이야기가 아니라 팀원이 직접 겪은 일이 됐어요. “결국 싼 곳이 이기지 않냐”라고 했던 사람들이 각자 다른 은행으로 직접 송금을 해보기 시작했죠. 그리고 팀의 기준이 바뀌었어요. ‘얼마나 싼가’에서 ‘얼마나 불안하지 않은가’로. 이제부터는 이 기준으로 하나씩 제품을 디자인하기로 했어요.

송금 과정의 불안을 줄이다

인터뷰를 통해 발견한 불안은 크게 두 가지였어요. 송금하는 순간의 불안, 그리고 돈을 보내고 기다리는 동안의 불안. 먼저 송금 과정부터 살펴봤어요.

국내 송금은 금액과 계좌번호만 입력하면 끝나지만, 해외송금은 입력해야 하는 정보가 훨씬 많아요. 은행 코드, 계좌번호, 현지 주소 등 낯선 정보가 계속 등장하죠. 특히 CHASUS33XXX 같은 은행 코드는 암호처럼 생겼어요. 이걸 제대로 입력했는지 확인할 방법도 마땅치 않았고요. 사용자는 ‘내가 잘못 입력해서 돈이 엉뚱한 곳으로 가면 어떡하지?’라는 불안함을 느끼죠.

그래서 은행 코드를 입력하면 바로 ‘JP Morgan Chase’처럼 은행 이름이 보이도록 했어요. 단순히 이름 하나를 보여주는 인터랙션이지만, 실제로는 은행 코드와 은행 이름을 연결하는 별도의 작업이 필요했어요. 송금 자체만 놓고 보면 없어도 되는 기능이에요. 은행 코드를 정확하게 입력하기만 하면 송금은 되니까요. 이전의 기준이었다면 “굳이 필요한가?”라는 질문으로 끝났을지도 몰라요. 하지만 불안하지 않은 송금이 목표라면, 사용자가 입력한 정보가 맞다는 확신을 주는 일도 꼭 필요하다고 생각했어요.

또 하나는 현지 주소였어요. 나라마다 주소 체계가 무척 다르잖아요. 어떤 곳은 거리명과 숫자로 되어있는데, 어떤 곳은 건물 번호도 필요하고 아예 유닛이라는 새로운 체계로 이루어진 곳도 있어요. 실제로 살아보지 않으면 너무 생소하죠. 어떻게 주소 입력창을 만들어야 할지 고민하고 있는데, 개발자분이 주소를 입력할 때 지도 앱처럼 몇 글자만 입력해도 검색해서 정확한 주소를 고르게 하면 어떻겠냐고 제안해 주셨어요. 지도 API를 연동해야 하고 호출 비용도 드는 일이었어요. 다른 은행에서는 자유 입력으로 받는 정보이기도 했고요. 하지만 이 방식을 쓰면 더 정확한 정보를 받을 수 있다는 이점도 있어요. 결과적으로 오타로 인한 반송도 줄게 되죠. 사용자의 편의와 운영 효율성 측면에서도 꼭 필요한 일이라고 설득해서 지도 API를 사용하게 되었어요.

송금 후의 불안을 줄이다

송금 후의 불안은 더 컸어요. 인터뷰에서 많은 사용자가 공통으로 이야기한 건, 돈을 보낸 순간부터 도착할 때까지 하루이틀을 아무것도 모른 채 그냥 기다려야 한다는 것이었어요.

실제로 해외송금은 그사이에 고객 확인, 외국환거래 규정 확인, AML·제재 스크리닝, 수취 은행 검사, 입금, 사후 모니터링 등 여러 단계를 거쳐요. 그렇다고 이 과정을 사용자에게 모두 보여주는 게 답은 아니라고 생각했어요. 내부에서 어떤 일이 일어나는지 전부 보여주면 오히려 더 불안해질 수도 있으니까요. 그래서 서버 개발자와 송금 상태를 하나씩 짚어봤어요.

‘이건 사용자가 알아야 하는 정보인가, 아니면 우리만 알고 있으면 되는 정보인가?’

돈이 제대로 송금되지 않는 경우에도 여러 가지 원인과 내부 로직이 있었지만, 그걸 하나하나 설명하기보다는 사용자가 실제로 알아야 하는 결과에 집중했어요. 여러 논의를 거쳐 아홉 개였던 송금 상태를 세 개로 줄였어요.

송금 처리 중 → 해외 은행 도착 → 완료

모든 과정을 보여주는 대신, 지금 내 돈이 어디까지 갔는지 알 수 있는 정보만 남긴 거예요. 보여주고 싶었던 건 복잡한 송금의 과정이 아니라, 내 돈이 지금 어떻게 되고 있는지였어요. 그래서 해외송금의 캐치프레이즈도 자연스럽게 정해졌어요.

‘보내면 보이는 해외송금.’

수수료를 낮추는 것도 물론 중요하지만, 팀이 만들고 싶었던 건 단순히 싼 송금이 아니었어요. 돈을 보내고 나서도 무슨 일이 일어나고 있는지 알 수 있고, 기다리는 동안 막연하게 불안해하지 않아도 되는 경험이었어요.

적용해보기

제가 한 일은 외화 지식을 빠르게 공부해 전문가가 되는 게 아니었어요. 오히려 잘 몰랐기 때문에 당연하게 여겨지는 것들을 한 번 더 사용자에게 물어볼 수 있었어요. 그리고 그 답을 팀이 직접 확인할 수 있도록 만들었고요.

처음에는 ‘얼마나 싼가’를 고민하던 팀이 ‘사용자가 무엇을 불편해하는가’를 기준으로 제품을 바라보기 시작한 것. 저에게 이 프로젝트에서 가장 의미 있었던 변화였어요.

이번 프로젝트에서 디자이너는 도메인 지식을 가장 잘 아는 사람이 아니라, 좋은 질문을 던지고 사용자의 경험을 기준으로 답을 찾는 사람이란 것을 배웠어요. 그리고 팀 전체가 사용자 관점으로 생각하기 시작하면 더 좋은 해결책이 나올 수 있다는 것도요.

도메인 지식이 없거나, 팀의 관점을 바꿔야 하는 디자이너라면 이런 질문을 던져보면 좋겠어요.

• 도메인 지식을 더 쌓아야 한다는 이유로, 사용자에게 직접 물어보는 일을 미루고 있진 않나요?
• 사용자의 목소리를 팀에 전달하는 데서 끝내고 있진 않나요? 팀이 직접 겪어볼 방법은 없을까요?
• 어떻게 하면 디자이너 혼자가 아니라 팀 전체에서 더 좋은 해결책을 고민할 수 있을까요?