
최근 플랫폼 서비스가 빠르게 확장되면서 앱 안에서 실행되는 인앱 서비스(Mini App) 형태가 많이 등장하고 있습니다.
특히 금융 플랫폼에서는 사용자가 앱을 떠나지 않고 다양한 서비스를 이용할 수 있도록 하는 구조가 중요해지고 있습니다.
그중 대표적인 사례가 토스 인앱(Toss Mini App)입니다.
이번 글에서는 토스 인앱을 실제로 기획하고 개발하면서 경험한 과정을 서비스 기획자의 관점에서 정리해보려고 합니다.
단순한 기능 설명이 아니라 기획 → 개발 협업 → 실제 구현 과정까지의 실무 경험 중심으로 작성했습니다.
1. 토스 인앱(Mini App)이란 무엇인가
토스 인앱은 쉽게 말해 토스 앱 내부에서 실행되는 웹 기반 서비스입니다.
외부 서비스가 토스 플랫폼 안으로 들어와 다음 기능을 활용할 수 있습니다.
- 토스 사용자 인증
- 토스 결제
- 토스 사용자 기반 트래픽
- 토스 앱 내부 UX
즉 구조적으로 보면 다음과 같습니다.
토스 앱
↓
WebView
↓
Mini App (웹 서비스)
↓
외부 서비스 서버
이 구조 덕분에 서비스 제공자는 별도의 앱을 만들지 않고도 토스 사용자에게 서비스를 제공할 수 있습니다.
2. 왜 토스 인앱을 선택했는가
프로젝트 초기 단계에서 가장 먼저 고민했던 것은
“이 서비스를 왜 토스 안에서 제공해야 하는가?”
였습니다.
토스 인앱의 장점은 다음과 같습니다.
1. 사용자 확보 비용 감소
토스는 이미 수천만 사용자를 확보하고 있기 때문에
서비스는 플랫폼 내부 유입을 활용할 수 있습니다.
2. 인증 / 결제 인프라 활용
일반 서비스에서는
- 회원가입
- 본인 인증
- 결제 연동
을 모두 직접 구현해야 합니다.
하지만 토스 인앱에서는
- 토스 계정 인증
- 토스 결제 시스템
을 활용할 수 있습니다.
3. 앱 설치 없이 서비스 제공
사용자는 별도의 앱을 설치하지 않고 토스 앱에서 바로 서비스 이용이 가능합니다.
3. 기획 단계에서 가장 중요했던 것
토스 인앱 기획에서 가장 중요한 것은 플랫폼 제약을 이해하는 것이었습니다.
일반 웹 서비스처럼 자유롭게 설계할 수 있는 것이 아니라
토스 UX 가이드와 정책 안에서 서비스가 동작해야 합니다.
그래서 기획 초기에는 다음을 먼저 정리했습니다.
- 사용자 인증 구조
- 인앱 UX
- 플랫폼 정책
특히 UX를 최대한 단순하게 만드는 것이 중요했습니다.
토스 사용자들은 보통
- 빠르게 실행
- 빠르게 완료
하는 경험을 기대하기 때문입니다.
그래서 대부분의 기능 흐름을 3~4 step 안에서 끝나도록 설계했습니다.
4. IA(정보 구조) 설계
인앱 서비스는 구조가 복잡하면 바로 이탈이 발생합니다.
그래서 IA는 매우 단순하게 구성했습니다.
홈
├ 서비스 소개
└ 시작하기
서비스
├ 기능 실행
└ 결과 확인
설계 원칙은 다음과 같았습니다.
- 메뉴 depth 최소화
- 핵심 CTA 명확하게
- 주요 기능 바로 접근
특히 인앱 서비스에서는 “탐색 UX”보다 “즉시 실행 UX”가 더 중요합니다.
5. 실제 개발 구조
토스 인앱은 대부분 웹 기반으로 개발됩니다.
제가 진행한 프로젝트에서는 다음과 같은 구조를 사용했습니다.
[클라이언트]
- Next.js
- 토스 SDK 호출
- API 통신
[서버]
이번 프로젝트의 서버 구조는 일반적인 서비스처럼
복잡한 비즈니스 로직을 처리하는 구조가 아니라
AI 프롬프트를 입력하고 그 결과를 노출하는 형태의 단순한 API 구조로 구성했습니다.
즉 서버의 역할은 다음과 같습니다.
- 클라이언트에서 전달된 요청 수신
- AI 프롬프트 전달
- AI 응답 결과 반환
- 결과 데이터 포맷 정리
전체 흐름은 다음과 같습니다.
Client (Mini App)
↓
Server API
↓
AI Prompt 요청
↓
AI 응답 생성
↓
Client 결과 전달
이 구조 덕분에 서버는 복잡한 비즈니스 로직 없이도 빠르게 기능을 구현할 수 있었습니다.
6. 이번 프로젝트에서 느낀 가장 큰 변화
이번 프로젝트를 하면서 가장 크게 느낀 것은
“개발의 진입 장벽이 많이 낮아졌다”는 점이었습니다.
특히 다음 세 가지 덕분입니다.
1. 플랫폼 가이드 문서
토스에서는 Mini App을 위한
- 개발 가이드
- API 문서
- 샘플 코드
가 잘 정리되어 있습니다.
덕분에 초기 개발 세팅이 어렵지 않았습니다.
2. API 중심 구조
대부분의 기능이 API 호출 기반 으로 동작하기 때문에
- 인증
- 결제
- 사용자 정보
등을 비교적 쉽게 연동할 수 있습니다.
3. 바이브 코딩(Vibe Coding)의 등장
최근에는 AI 기반 개발 방식, 흔히 말하는 바이브 코딩이 많이 활용되고 있습니다.
예를 들어
- 코드 생성
- API 연동
- 오류 해결
- UI 구현
등을 AI가 도와주면서 개발 생산성이 크게 올라갔습니다.
7. 이제는 개발 비전공 기획자도 가능한 수준인가?
결론부터 말하면
“가능하다”고 생각합니다.
특히 다음 조건이 있다면 충분히 가능합니다.
- 기본적인 웹 구조 이해
- API 개념 이해
- 플랫폼 가이드 문서 활용
- AI 개발 도구 활용
예전에는
- 서버 구축
- 인증 구현
- 결제 연동
이 모두 큰 장벽이었습니다.
하지만 지금은
- 플랫폼 인프라 제공
- API 문서 제공
- AI 코드 생성
덕분에 기획자도 프로토타입 수준의 서비스는 직접 구현할 수 있는 시대가 되었습니다.
8. 개인적인 생각
저는 컴퓨터공학 전공이라 개발 경험이 있는 편이지만
이번 프로젝트를 진행하면서 느낀 점은 하나였습니다.
“이 정도면 비전공 기획자도 충분히 시도해볼 수 있다.”
특히 다음과 같은 분들에게 추천합니다.
- 플랫폼 서비스 기획자
- 프로토타입을 직접 만들어보고 싶은 기획자
- API 기반 서비스를 이해하고 싶은 PM
요즘은 기획자가 단순 문서를 만드는 역할을 넘어서
- 프로토타입 제작
- 서비스 구조 설계
- 기술 이해
까지 할 수 있는 환경이 만들어지고 있습니다.
마무리
토스 인앱 프로젝트는 단순한 서비스 개발이 아니라
플랫폼 기반 서비스 설계 경험이었습니다.
특히 다음 세 가지를 많이 배울 수 있었습니다.
- 플랫폼 서비스 기획 방식
- WebView 기반 UX 설계
- API 중심 서비스 구조
그리고 무엇보다 느낀 점은
“지금은 기획자도 충분히 서비스를 직접 만들어볼 수 있는 시대다.”
입니다.
앞으로 기획자에게 필요한 역량은
- 플랫폼 이해
- API 구조 이해
- 데이터 흐름 설계
라고 생각합니다.
이 글이 토스 인앱을 준비하거나 플랫폼 서비스를 기획하는 분들께 작은 참고가 되었으면 좋겠습니다.
'기타 (회고, 생각, 기획 등)' 카테고리의 다른 글
| Claude Code 해커톤이 보여준 개발의 변화 (0) | 2026.03.06 |
|---|---|
| IA(Information Architecture)란 무엇인가 (0) | 2026.02.27 |
| Principle of Least Privilege (최소 권한 원칙) (0) | 2026.02.19 |
| Single Source of Truth (SSOT) (0) | 2026.02.10 |
| WBS, 간트차트, 마일스톤의 차이 (2) | 2026.01.13 |