토스가 특허 낸 리서치툴, TNS (Toss Navigation Score) 제작기

제품의 진입점을 사용자가 잘 찾는지 알고 싶을 때, 어떻게 하시나요?

토스는 자체 리서치 도구로 알아봐요. 사용자가 원하는 기능을 얼마나 잘 찾아가는지를 수치로 측정하는 툴로, 이름은 TNS(Toss Navigation Score)예요.

“토스에 있는 모든 서비스를 보려면 어디를 눌러보시겠어요?”라는 질문을 주면, 사용자는 실제 앱 화면 위에서 직접 그 기능을 찾아가요. 이때 사용자가 얼마나 헤매지 않고 빠르게 도달했는지를 점수로 계산해요. 내비게이션이 잘 설계돼 있을수록 점수가 높아지는 거죠.

사실 이런 정성적인 경험을 수치화해서 제품 개선에 활용하는 리서치 툴은 리서치 업계에서도 쉽게 보기 힘든 방식이라, 특허까지 출원했어요.

이렇게 생소한 개념의 툴을 어떻게 처음부터 만들어낼 수 있었을까요? 레퍼런스 하나 없는 상태에서 처음 길을 만들어간 TNS 길드 팀원을 만나 이야기를 들어봤어요.

TNS의 시작

명화 (UX Researcher)

TNS는 "사용자가 어떤 경로를 거쳐 기능에 도달하는지"를 실제 라이브 앱에서 추적하기 위해 만들어졌어요. 기존에 쓰던 EVR(Entrance conVersion Rate) 이라는 툴을 쓰고 있었는데요. 화면 단위로 사용자의 클릭을 측정할 수는 있었지만, 사용자가 여러 화면을 거치는 실제 여정을 담기엔 한계가 있었어요.

예를 들어, EVR은 캡처된 특정 화면을 보여준 뒤 사용자가 어디를 클릭했는지를 확인하는 방식이에요. 정답을 클릭한 비율로 점수를 매기는 일종의 무인 사용자 테스트인 셈이죠.

하지만 이 방식은 A → B → C 같은 실제 사용자의 탐색 경로를 파악할 수 없고, 정해진 화면 내에서만 행동을 측정해야 해요. 그러다 보니 복잡한 내비게이션 이슈, 즉 사용자가 어떤 경로를 헤매다 기능에 도달하는가를 이해하기 어려웠죠.

실제 앱 안에서 사용자가 어떤 경로를 통해 목표에 도달했는지를 추적할 수 있는 새로운 툴이 필요하다고 생각했고, 그게 TNS예요.

라이브 앱에서 테스트하는 방법을 찾다

지수 (Data Analyst)

처음에는 이게 되겠어? 싶은 마음이 컸어요. 기존처럼 캡처 화면으로만 실험하던 방식이 아니라, 실제 앱 환경에서 사용자가 자유롭게 탐색하는 걸 측정해야 하니까요. 이걸 하려면 앱을 아예 복제해서 별도 환경을 만들어야 하는 건가 고민도 했었고요.

명화 (UX Researcher)

맞아요. 저도 두세 달 동안 엔지니어분들한테 하나하나 찾아다니면서 이걸 어떻게 구현할 수 있을지 방법을 찾아다녔거든요. 그런데 대부분 "그건 안 되지 않나요"라는 답을 들었어요. 토스에 와서 이렇게 많이 안 된다는 말을 들어본 건 처음이었어요.

그런데 어느 날 서진님이 아이디어를 주셨어요. TNS 설문에 참여 중인 사용자를 로그 상에서 별도로 식별할 수 있게 하자. 앱 로그에 TNS ID를 심어서, 이 사용자가 어떤 경로를 탐색했는지 일반 사용자의 로그와 분리해서 기록하는 방식이었어요. 이걸로 결국 라이브 앱 환경을 그대로 쓰면서도 실험 사용자의 행동만 따로 추적할 수 있게 됐어요.

이게 돌파구였어요. 이걸 계기로 프로젝트가 본격적으로 시작될 수 있었죠.

개발 | 코드보다 무거웠던 책임감

우재 (iOS Developer)

사실 TNS는 구현 자체가 엄청 복잡하진 않았어요. 그런데 이게 앱 전체에 적용되는 시스템이다 보니까 심리적인 부담이 컸어요. 만약 오류가 나면 송금 중에도 앱이 종료될 수 있거든요. 영향 범위가 전체 서비스로 퍼진다는 게 계속 신경 쓰였어요. 실제로 QA 과정에서 앱이 강제 종료되는 이슈가 생겨서 밤새 수정하기도 했고요. 결국 개발 난이도보다는 전체 시스템을 건드릴 때 느껴지는 심리적인 압박감이 더 컸던 것 같아요.

윤지 (Android Developer)

Android도 비슷했어요. 토스 앱에 존재하는 모든 화면 위에서 동작하는 플로팅 UI를 만들어야 해서 문제가 생기면 앱 전체에 영향이 갈 수 있었거든요. 또 사용자가 TNS 테스트를 하는 동안 생성되는 모든 앱 로그는 기존의 앱 로그와 격리해서 적재해야 해서, 테스트 전후로 로그 처리에 문제가 생기지 않도록 주의를 기울여야 했어요.

사실 저는 어려움보다는 처음부터 제품을 만든다는 뿌듯함이 더 컸던 것 같아요. 토스에 입사한 후 이미 만들어져 있던 제품에 기능을 추가하거나 유지보수 하는 역할을 주로 해왔는데, 새로운 제품의 초기 기획 단계부터 참여해 완성에 다다르는 과정 전반을 온전히 맡아본 것은 처음이었거든요. 그래서 오히려 더 애착이 생겼어요. 버그 수정이나 QA 과정은 확실히 힘들긴 했는데, 덕분에 "이 제품을 내가 제일 잘 안다"는 감각도 많이 생겼어요.

디자인 | 사용자에게서 답을 찾다

세린 (Product Designer)

보통 새로운 기능을 디자인할 땐 비슷한 서비스 사례를 참고하면서 시작하잖아요. 이건 그런 레퍼런스가 아예 없었어요. 그래서 처음엔 많이 막막했죠. 제가 찾은 답은 "직접 사용자에게 검증해보자"였어요. TNS를 디자인하면서 만난 사용자가 거의 100여 명 정도 될 거예요. 사용자에게 답을 찾아서 개선한 부분 중에 크게 두 가지가 기억에 남아요.

1. 사용법을 쉽게 이해할 수 있게 하기

사용자가 헷갈려하던 기존 화면

첫 번째는, 사용자가 TNS라는 서비스를 쉽게 조작할 수 있도록 화면을 고친 거예요. 기존 화면은 인트로 → 문제 → 토스 화면 순이었는데, 글을 자세히 읽지 않은 사용자들은 토스 화면이 갑자기 뜨면 “뭘 해야 하지?” 하고 당황하더라고요. 현재 테스트 중이라는 걸 인지시키기도 어렵고, ‘문제 다시 보기 / 스킵 / 끝내기’ 같은 흐름을 자연스럽게 안내하는 것도 쉽지 않았어요. 테스트 도중 다른 서비스를 눌러버리는 실수도 자주 발생했죠.

개선된 화면

그래서 “이건 테스트고, 지금 토스 화면에서 문제를 풀어야 한다”는 점을 직관적으로 이해할 수 있도록 만드는 커스텀 UI를 직접 만들었어요. TDS(Toss Design System) 기반 UI만으로는 한계가 있다고 생각했거든요.

• 상단에서 문제지가 펼쳐졌다가 줄어드는 인터랙션으로, 사용자가 어디서 문제를 봐야 할지 직관적으로 알 수 있게 했고
• 토스 화면을 블러 처리한 뒤 문제지를 띄우고, 이후 블러를 해제하는 흐름을 통해 “이 화면에서 문제를 풀어야 한다”는 점을 명확히 전달했어요.

인터랙션을 적용하다 보니 사람마다 글을 인지하는 속도가 다른 문제가 새로 생겼었는데요. 적절한 타이밍을 찾기 위해 관련 논문도 찾아보고, 연령대별로 UT를 많이 했어요. 그래서 누구나 이해할 수 있는 타이밍을 찾아낼 수 있었죠. 덕분에 연령과 관계없이 대부분의 사용자가 작동 방식을 직관적으로 이해할 수 있었어요.

2. 테스트의 의도 정확히 전달하기

라이브 앱을 기반으로 테스트한다는 게 사실 생소하잖아요. 많은 사용자가 이 서비스를 광고라고 생각하더라고요. 토스 개선을 위한 실험 목적이라는 걸 알려주기 위해, “더 나은 서비스를 만들기 위한 테스트”라고 구체적으로 알려줘 보기도 하고, 아예 아무 설명 없이 진행해 보기도 하고, 게임처럼 재미있게 구성해 보기도 했죠.

시도해 본 여러 시안들

하지만 다양한 시도를 해도, 설명을 읽지 않거나, 읽더라도 금세 잊어버리는 경우가 대부분이었어요. 그래서 접근 방식을 바꿨어요. “정보가 필요하다고 느끼는 바로 그 순간”에, 핵심 키워드를 중심으로 정보를 단계적으로 제공한 거예요.

개선된 화면

인트로는 어차피 잘 읽지 않으니까, 문제지가 펼쳐져서 시선을 끈 순간 ‘더 편하게’, ‘기능찾기’ 등의 키워드로 테스트 의도를 간단하게 설명했어요. 그렇게 하니까 서비스 개선을 위한 테스트라는 점을 더 쉽게 인지하더라고요.

개선된 화면

또, 검색을 하고 싶을 것으로 예상되는 화면에서 “검색 없이 찾아주세요”라는 문구를 띄웠어요. 사용자들이 “검색 없이 잘 찾는지 보려는 테스트구나” 하고 테스트의 의도를 스스로 유추했어요.

그 결과, 광고로 오해하는 사용자가 눈에 띄게 줄었고, 이 테스트가 UX 개선을 위한 실험이라는 점을 자연스럽게 이해하게 되었어요.

데이터 | 대시보드를 보는 순간, 액선이 떠오르도록

지수 (Data Analyst)

어떤 지표를 보여줘야 사일로에서 이걸 보고 제품을 개선할 수 있을까? 를 가장 많이 고민했어요. 일반적인 전환 퍼널 데이터랑은 조금 달랐거든요. 단순히 ‘어디서 이탈했나’를 보는 게 아니라, 사용자가 어떤 경로를 시도하다가 실패했는지를 보여주고 싶었어요. 그래야 제품팀이나 디자이너가 대시보드를 보면서 "아, 이 구간에서 사용자가 헤매고 있구나"를 바로 파악할 수 있으니까요.

그래서 아래 세 가지 질문을 중심으로 구조를 설계했어요:

1. 이 서비스는 잘 찾아지고 있는가?
2. 사용자는 어디에서 헤매고 있는가?
3. 다른 어떤 서비스와 혼동되고 있는가?

TNS의 진짜 사용자는 각 팀의 메이커들이라는 걸 계속 생각했어요. 그래서 단순히 “현황을 보여주는” 수준을 넘어, “어디를 어떻게 개선해야 할지”를 짚어주는 대시보드를 만들었죠. 진단 도구를 넘어, 액션을 유도하는 도구가 될 수 있도록요.

TNS 활용 | 팀을 움직이는 내비게이션 지표로

명화 (UX Researcher)

TNS는 디자인, 네이밍 등 다양한 실험에 활용되지만, 진짜 핵심 가치는 단순히 개별 서비스의 점수를 보는 데 그치지 않아요.

토스 전체 서비스의 내비게이션 건강도를 측정하고, 각 팀이 현재 위치를 싱크할 수 있는 기준이 되어 준다는 점이 가장 중요하죠. TNS 점수는 반기 단위로 꾸준히 측정되고 있어서, 시간에 따른 변화까지 추적할 수 있고, 이를 기반으로 내비게이션 관련 논의와 실질적인 개선이 이뤄지고 있어요.

결국 TNS는 전사적인 UX 개선의 출발점이 되는 지표라고 할 수 있어요.

지수 (Data Analyst)

반년마다 정기적으로 발송해서, 전체 서비스 평균보다 TNS 점수가 낮은 서비스 중심으로 사일로에게 결과를 전달해 드릴 예정이에요.

예를 들어 ‘내게 맞는 대출 찾기’ 기능이 어디에 있는지 묻는 질문에서, 많은 분이 신용 점수 관련 서비스를 언급했어요. 살펴보니 신용 점수 홈에는 대출로 넘어가는 진입점이 있었지만, 대출 홈에는 신용 점수로 가는 길이 없더라고요. 사용자 입장에서는 대출과 신용 점수가 하나로 연결된 개념으로 느껴지기 때문에, 대출 홈에도 신용점수로 갈 수 있는 진입점을 만들어야겠다는 인사이트를 전달하고, 실제 개선까지 이어질 수 있도록 하는 거죠.

적용해 보기 | 프로젝트 협업 잘하기

명화 (UX Researcher)

각자 본업이 있는 상태라 긴 회의나 반복적인 논의에 시간을 쓰기 어려운 상황이었어요. 그래서 자연스럽게 “회의 때마다 무조건 결론을 내자”는 암묵적인 룰이 생겼죠. “길게 고민하기 어려우니, 지금 결정할 수 있는 건 여기서 정리하자”는 식으로요.

우재 (iOS Developer)

또 직군별로 한 명씩 맡다 보니까 역할이 명확했어요. 회의에서 아젠다가 나오면 각자 알아서 "이건 내가 맡아야겠다" 하고 바로 가져갔죠. 만약 사일로 경험이 없이 그냥 iOS 개발팀에만 있었다면 뭐부터 해야 할지 막막했을 텐데, 다들 혼자서 DRI를 맡아본 경험이 있어서 가능했던 것 같아요.

세린 (Product Designer)

무엇보다 다들 "사용자 경험을 최우선으로 두자"는 공감대가 확실했어요. 보통 이런 실험툴을 만들 때는 개발 난이도를 줄이려고 디자인을 많이 깎는데, 윤지 님이랑 우재 님은 최대한 제안을 그대로 구현해 주셨어요. 덕분에 디자인이 거의 다 들어갔어요.

적용해보기 | 레퍼런스 없는 제품을 만들 때의 팁

명화 (UX Researcher)

낙관적인 마음 가지기 "하다 보면 방법은 나온다"는 마음으로 계속 고민하다 보면, 결국 누군가는 또 새로운 아이디어를 주고, 그걸 바탕으로 길을 찾아가게 되더라고요.

세린 (Product Designer)

정답은 언제나 사용자에게 있다고 믿기 참고할 레퍼런스는 없어도, 실제 사용할 사람은 명확히 존재하니까요. 사용자를 관찰하면 어떤 점이 문제인지, 이 방향이 맞는지 늘 힌트를 얻을 수 있었어요. 소거법으로 아닌 걸 하나씩 제거하다 보면, 결국 길이 보이더라고요. 그러니 레퍼런스가 없다는 이유로 두려워하지 말고, 사용자를 많이 만나보세요.

윤지 (Android Developer)

기존 자원을 잘 활용하기 TNS는 세상에 없던 제품이지만, 기존 토스 앱에 잘 갖춰진 로그 시스템 인프라 덕분에 개발은 수월했어요. 낯선 요구사항이 주어지더라도 처음부터 불가능하다고 단정 짓기보단, 기존 자원을 창의적으로 활용해 보는 시도가 중요한 것 같아요. 의외의 가능성이 거기서 열릴 수 있거든요.

TNS에 대해 더 알고 싶다면

Simplicity 4 | 경험을 수치화하는 방법

TNS 메이커 김우재, 김지수, 이윤지, 장세린, 정명화 인터뷰, 편집 유아란