Typefy를 토스 앱 안으로 옮기며 배운 것들#

Typefy는 무료 심리 테스트 플랫폼입니다. MBTI, 여행 DNA, 직업 성향처럼 가볍게 시작할 수 있는 테스트를 제공하고, 결과를 저장해 다시 볼 수 있게 만드는 것이 핵심입니다.

이번에는 이 Typefy를 웹이 아니라 토스 앱 안에서 돌아가는 미니앱으로 다시 만들었습니다. 단순히 화면을 줄이는 작업은 아니었습니다. 로그인 방식도 달라졌고, 저장 방식도 달라졌고, 목록을 보여주는 전략도 다시 짜야 했습니다.

결론부터 말하면, 이번 개발은 "기능 이식"보다 "환경 재설계"에 가까웠습니다. 공식 소개 문서 기준으로 Apps in Toss는 토스 앱 내부에서 파트너 서비스가 앱인앱 형태로 동작하는 플랫폼이고, 누적 3,000만 사용자 기반 위에서 빠르게 검수와 출시까지 이어갈 수 있는 구조를 제공합니다.

왜 웹이 아니라 토스 인앱이었나#

웹의 장점은 분명합니다. 링크 공유가 쉽고, 검색 유입을 만들기 좋고, 이미 운영 중인 페이지도 있었습니다. 실제로 Typefy 웹은 테스트 목록, 검색, 카테고리, 결과 저장, 추천 테스트까지 한 흐름으로 갖추고 있습니다.

하지만 제품 관점에서 보면 다른 문제가 있었습니다. 테스트는 진입 장벽이 낮을수록 참여율이 올라가는데, 결과 저장이나 재방문까지 연결하려면 로그인 전환이 반드시 필요했습니다. 스프린트 문서에서도 Typefy의 이번 목표를 "Toss InAPP 개발"과 "회원가입을 진행하여 참여할 수 있게 운영"으로 명시해 두었습니다.

토스 인앱은 이 지점을 해결할 가능성이 있었습니다. 토스 안에서 이미 로그인 컨텍스트가 있고, 공식 SDK가 로그인과 저장 인터페이스를 제공하니 "테스트는 가볍게, 저장은 자연스럽게"라는 흐름을 만들기 더 좋다고 판단했습니다.

여기서 중요한 포인트는 하나였습니다.

1. 테스트 참여는 최대한 빠르게 시작해야 합니다.
2. 결과 저장은 억지 회원가입처럼 보이면 안 됩니다.
3. 재방문 시에는 지난 결과를 즉시 복원해야 합니다.

이 세 가지를 만족시키려면 웹을 그대로 포팅하는 방식으로는 부족했습니다.

가장 먼저 바뀐 것은 로그인과 저장 방식이었습니다#

웹의 Typefy는 브라우저 기준으로 동작합니다. 로그인 전에는 로컬 스토리지에 임시 답변을 넣어두고, 로그인 후 돌아오면 그 답변을 복원해 자동 저장하는 흐름을 택했습니다. 실제 구현에도 typefy-pending-save-{slug} 키로 답변을 보관한 뒤, 로그인 후 복구하는 로직이 들어가 있습니다.

반면 토스 인앱은 저장 기준이 달랐습니다. 여기서는 일반적인 AsyncStorage 대신 Apps in Toss SDK의 Storage를 써야 했고, 로그인도 브라우저 리다이렉트가 아니라 appLogin() 호출로 시작했습니다.

실제로 인앱 프로젝트에서는 아래 흐름을 별도 세션 프로바이더로 분리했습니다.

1. 앱 부팅 시 Storage.getItem("typefy.toss.auth.session")으로 세션을 복원합니다.
2. 로그인 버튼을 누르면 appLogin()으로 인가 코드를 받습니다.
3. 서버에서 토큰 교환을 마친 뒤 세션을 Storage.setItem(...)으로 저장합니다.
4. 로그아웃 시에는 원격 해제 실패와 무관하게 로컬 세션을 먼저 정리합니다.

이 차이는 생각보다 컸습니다. 웹에서는 "페이지 이동 후 복귀"가 기본 흐름이었다면, 인앱에서는 "앱 내부 상태를 유지하면서 세션만 갈아끼우는 흐름"이 더 자연스러웠습니다. 그래서 인증 코드를 받는 순간보다, 인증 뒤 상태를 얼마나 안정적으로 복원하느냐가 훨씬 중요해졌습니다.

공식 문서도 이 방향과 맞닿아 있습니다. Apps in Toss 문서는 로그인과 인증 기능을 SDK 기반으로 붙이도록 안내하고 있고, 파트너사는 빌드 결과물을 업로드한 뒤 검수 절차를 거쳐 출시하는 구조를 전제로 합니다. 즉, 브라우저 웹앱처럼 아무 라이브러리나 붙이는 방식보다 플랫폼이 기대하는 경로를 따르는 편이 안정적입니다.

웹과 같은 기능을 넣되, 화면 전략은 다르게 가져갔습니다#

겉으로 보면 웹 Typefy와 인앱 Typefy는 비슷합니다. 둘 다 테스트 목록이 있고, 검색이 되고, 결과를 저장하고, 추천 테스트를 보여줍니다. 하지만 내부 전략은 일부러 다르게 설계했습니다.

가장 대표적인 예가 목록 노출 방식입니다.

• 웹 Typefy는 한 번에 10개씩 목록을 불러오고, 랭킹 섹션을 만들기 위해 100개까지 별도 조회합니다.
• 인앱 Typefy는 최초 노출 수를 3개로 제한하고, 스크롤이 바닥에 가까워질 때 조금씩 더 보여줍니다.

왜 이렇게 했냐면, 인앱에서는 "많이 보여주는 것"보다 "빠르게 읽히는 것"이 더 중요했기 때문입니다. 작은 화면에서 긴 목록을 한 번에 밀어 넣으면 첫 진입의 집중력이 바로 깨집니다. 대신 처음엔 적게 보여주고, 사용자가 직접 더 보도록 만들면 탐색 피로가 줄어듭니다.

결과 화면도 같은 원칙으로 봤습니다. 웹은 결과 카드 이미지를 PNG로 내려받을 수 있게 했고, 공유 모달과 로그인 유도 모달까지 한 흐름에 넣었습니다. 인앱은 다운로드보다 결과 저장, 재조회, 추천 테스트 이동을 더 앞에 뒀습니다.

이 차이는 단순한 UI 취향 문제가 아닙니다. 플랫폼의 기대 동작이 다르기 때문입니다. 웹은 공유와 링크 확산이 강하고, 인앱은 세션 유지와 다음 행동 유도가 강합니다. 같은 Typefy라도 채널이 바뀌면 좋은 플로우도 달라집니다.

인앱에서는 실패를 숨기지 않고, 진단 가능하게 만드는 일이 더 중요했습니다#

인앱 개발을 하면서 가장 크게 느낀 점은 "문제가 생겼을 때 브라우저 개발자도구처럼 바로 보기 어렵다"는 점이었습니다. 그래서 이번 프로젝트에서는 기능 구현만큼 진단 설계를 신경 썼습니다.

예를 들면 부팅 단계에서 세션 복원이 시작됐는지, 완료됐는지, 실패했는지를 Sentry 브레드크럼과 진단 이벤트로 남기도록 했습니다. 앱이 5초 이상 부팅 상태에 머물면 현재 deploymentId를 포함한 경고도 기록합니다.

이런 장치는 사소해 보이지만 인앱에서는 체감이 다릅니다.

1. 사용자는 "왜 안 뜨는지" 설명을 기다려주지 않습니다.
2. 토스 샌드박스와 실서비스 환경의 차이를 로그 없이 재현하기 어렵습니다.
3. 검수나 운영 단계에서는 "가끔 안 된다"를 숫자와 이벤트로 바꿔야 대응할 수 있습니다.

공식 출시 문서에서도 이런 운영 감각이 드러납니다. 검수 가이드와 체크리스트를 먼저 확인해야 하고, 번들은 압축 해제 기준 100MB 이하여야 하며, 리소스는 빌드와 분리해 관리하라고 안내합니다. 다시 말해 인앱은 "되면 올리는" 플랫폼이 아니라, 작은 실패 가능성까지 운영 가능한 형태로 다듬어야 통과하기 쉬운 플랫폼입니다.

그래서 이번 개발에서는 기능 체크리스트를 이렇게 봤습니다.

• 로그인 실패 시에도 앱이 죽지 않는가
• 원격 로그아웃 실패 시 로컬 로그아웃은 되는가
• 저장된 결과를 다시 열었을 때 답변과 결과가 일치하는가
• 첫 화면이 느릴 때 원인을 추적할 수 있는가

제품은 결국 동작해야 하고, 운영 가능한 상태여야 합니다. 인앱에서는 두 번째 조건이 특히 더 무겁습니다.

Typefy를 옮긴 것이 아니라, Typefy의 우선순위를 다시 정했습니다#

이번 작업을 하면서 얻은 가장 큰 교훈은 이것입니다. 플랫폼 이식은 화면 복사가 아니라 우선순위 재정렬입니다.

웹 Typefy에서는 검색 유입, 리스트 탐색, 결과 공유가 중요한 축이었습니다. 토스 인앱 Typefy에서는 로그인 연결, 저장된 결과 복원, 짧은 스크롤 탐색, 안정적인 세션 유지가 더 중요한 축이 됐습니다.

같은 서비스인데도 이렇게 달라졌습니다.

• 웹은 "많이 보게 하는 구조"가 강합니다.
• 인앱은 "빨리 시작하고, 자연스럽게 남게 하는 구조"가 강합니다.

이 차이를 인정한 뒤부터 구현이 빨라졌습니다. 웹에서 잘 되던 방식을 억지로 유지하려고 할 때는 결정이 느렸는데, 인앱에서 중요한 지표가 무엇인지 정하자 코드도 단순해졌습니다.

앞으로는 여기서 더 나아가려 합니다. 토스 인앱 안에서 테스트 시작률, 저장률, 결과 재방문율이 각각 어디서 떨어지는지 더 잘 보이게 만들고, 추천 테스트 연결도 지금보다 촘촘하게 다듬을 계획입니다. 제품의 완성도는 기능 수보다, 한 번 들어온 사용자가 다음 행동을 얼마나 자연스럽게 하느냐에서 갈린다고 보기 때문입니다.

마무리하며#

Typefy의 토스 인앱 개발기는 새 플랫폼에 서비스를 얹는 작업이 아니었습니다. "이 환경에서 사용자는 무엇을 가장 편하게 느끼는가"를 다시 묻고, 그에 맞게 로그인, 저장, 목록, 진단을 다시 설계한 과정이었습니다.

특히 이번 작업은 하나를 다시 확인하게 했습니다. 서비스의 본질은 테스트 콘텐츠가 아니라, 사용자가 결과를 끝까지 보고 다시 돌아오게 만드는 경험이라는 점입니다. 플랫폼이 바뀌면 그 경험을 만드는 수단도 바뀌어야 합니다.

비슷한 작업을 준비하고 있다면, 처음부터 모든 기능을 옮기려 하지 않는 편이 좋습니다. 대신 아래 세 가지부터 먼저 정하는 편이 훨씬 낫습니다.

1. 이 플랫폼에서 가장 중요한 한 번의 행동은 무엇인가
2. 로그인과 저장은 어디서 가장 자연스럽게 연결되는가
3. 장애가 났을 때 개발팀이 무엇을 바로 볼 수 있어야 하는가

이 세 질문만 선명해도, 인앱 전환은 생각보다 훨씬 덜 막막해집니다.

궁금하시면 지금 바로 Typefy 토스 미니앱으로 들어와 보세요. https://minion.toss.im/vob9kZ6b

WegglePlus의 다른 서비스도 보고 싶다면#

Typefy - 나를 발견하다: MBTI·여행 DNA·직업 성향 등 다양한 무료 심리 테스트로 나 자신을 탐색해 보세요. Versus - 오늘의 선택, 당신의 생각: 매일 새로운 A vs B 밸런스 게임에 참여하고, 다른 사람들의 선택과 비교해보세요. Nomad's - 세상을 탐색하다: 전 세계 디지털 노마드들이 추천하는 지역 리뷰와 실제 체류 경험을 확인해 보세요. Nomad'With - 일상을 나누다: 디지털 노마드들의 여행, 원격 근무, 한달살기 이야기를 피드에서 만나보세요. JobSkill - 역량을 키우다: 현직자가 직접 진행하는 직무 스킬 세미나로 실전 커리어 경쟁력을 높여보세요. ThingsInThing - 미디어 속 숨겨진 것들을 발견하세요: 책, TV 프로그램 속에 등장하는 숨겨진 것들을 발견하고 탐색하세요. staglit - 무대 위의 모든 순간: 국내외 공연과 페스티벌 정보를 한 곳에서 확인하세요. 별짓 - 오늘의 운명을 읽다: 별자리 일간 운세로 매일의 흐름을 확인하세요. 셀링페이퍼 - 독후감으로 수익 만들기: 책을 읽고 독후감을 작성하세요. 다른 사람이 내 독후감을 통해 책을 구매하면 수수료를 받을 수 있습니다.

비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️ 📩 ksy90101@gmail.com