토스 2,000만 사용자 앞에 내 앱을 띄우려면? 미니앱 개발자가 먼저 부딪히는 3가지 벽

1. 2,000만 사용자라는 숫자보다 먼저 물어야 할 것

토스 이용자 2,000만 명 앞에 서비스를 띄우면 광고비 없이 곧바로 검증할 수 있을까요? 숫자만 보면 가능해 보이지만, 개발 전에 먼저 답해야 할 질문이 있습니다. 이 서비스가 토스 안에 있어야 할 만큼 절박한 문제를 해결하는가입니다.

이 질문에 답하지 못한 채 React부터 설치하면 개발은 시작돼도 검증은 뒤로 밀립니다. ‘많은 사람이 들어올 수 있다’와 ‘내 문제를 해결하려고 반복 사용하거나 결제한다’ 사이에는 큰 차이가 있죠.

먼저 2,000만 명이라는 이용자 규모가 최신 공식 자료와 일치하는지 확인해야 합니다. 수치가 맞더라도 전체 이용자가 잠재 고객이 되는 것은 아닙니다. 토스를 자주 사용하는 사람, 특정 금융 상황을 겪는 사람, 새로운 미니앱을 눌러볼 사람은 서로 다를 수 있습니다.

기술을 선택하기 전에는 다음 네 가지를 나눠 확인합니다.

• 사용자 문제: 지금 겪는 불편을 토스 미니앱이 아니면 해결하기 어려운가?
• 개인정보 흐름: 이름·연락처·거래 정보가 정말 필요한가? 수집·보관·삭제·접근 권한을 설명할 수 있는가?
• 운영 비용: 서버·외부 API·데이터베이스·오류 대응 비용을 감당할 수 있는가?
• 심사 가능성: placeholder 화면이나 미완성 흐름 없이 최신 심사 조건을 충족할 수 있는가?

‘토스 이용자에게 노출되면 좋을 것 같아서’가 이유의 전부라면 아직 개발할 때가 아닙니다. 사용자가 토스 안에서 바로 확인하고, 계산하고, 신청해야 하는 이유가 분명할 때 React·TypeScript, Granite 기반 번들, TDS, 뒤로가기 처리, 개인정보 최소화 순서를 검토하면 됩니다.

첫 검증은 개발보다 작게 시작할 수 있습니다. 고객 인터뷰나 간단한 랜딩 페이지로 사용자가 어떤 상황에서 이 기능을 찾는지 확인해 보세요. 실제로 사용하겠다는 반응이 나오는지도 함께 살펴야 합니다.

📌 먼저 보는 핵심 답변 (30초 요약)

• **토스 미니앱은 React/TypeScript와 Granite 프레임워크를 기반으로 번들을 구성하는 것부터 시작해야 한다.**: 토스 미니앱은 React/TypeScript와 Granite 프레임워크를 기반으로 번들을 구성하는 것부터 시작해야 한다.
• **안드로이드 뒤로가기 처리와 TDS 기반 UI 일체감은 기능 구현만큼 중요한 출시 조건으로 확인된다.**: 안드로이드 뒤로가기 처리와 TDS 기반 UI 일체감은 기능 구현만큼 중요한 출시 조건으로 확인된다.
• **개인정보 수집을 최소화하고 미완성 placeholder를 제거한 뒤 공식 심사 기준을 점검해야 시행착오를 줄일 수 있다.**: 개인정보 수집을 최소화하고 미완성 placeholder를 제거한 뒤 공식 심사 기준을 점검해야 시행착오를 줄일 수 있다.

2. 일반 앱과 비교하면 장점보다 먼저 보이는 조건

토스 미니앱은 별도 설치 없이 실행될 수 있다는 점이 매력적입니다. 다만 설치 장벽이 낮아지는 것과 서비스가 발견되고, 다시 방문하고, 결제로 이어지는 것은 별개의 문제입니다.

| 구분 항목 | 일반 모바일 앱 | 토스 미니앱 | 1인 개발자에게 의미 |

|---|---|---|---|

| 사용자 접근 경로 | 앱스토어 검색·설치·업데이트 필요 | 토스 이용자 환경 안에서 실행 | 별도 설치 장벽을 낮춰 초기 사용성을 확인할 여지 |

| 개발 환경 | iOS·Android 네이티브 또는 크로스플랫폼 | React·TypeScript와 Granite 기반 구성 확인 필요 | 기존 웹 기술을 활용할 여지 |

| 배포·심사 | 앱스토어별 등록과 심사 | 토스의 공식 심사와 출시 조건 확인 필요 | 배포 채널을 줄일 수 있지만 심사 의존성이 생김 |

| UI 제약 | 플랫폼 가이드 안에서 비교적 자유롭게 설계 | TDS와 토스 실행 환경에 맞춰 구성 | 디자인 시스템을 새로 만드는 부담을 줄일 수 있음 |

| 개인정보·운영 | 서버·분석·권한·고지를 직접 관리 | 필요한 정보 최소화와 토스 정책 확인 필요 | 기능과 데이터 수집 범위를 좁힐 수 있음 |

첫 번째 벽: 간단해 보이는 서비스도 법적·운영 조건을 가진다

계산기나 조회 도구라도 개인정보를 받거나 결제·금융 관련 정보를 다루는 순간 확인할 항목이 달라집니다. 어떤 데이터를 왜 수집하는지, 얼마나 보관하고 어떻게 삭제하는지, 이용자에게 무엇을 고지해야 하는지부터 정리해야 합니다.

수익이 발생하면 세금과 정산 구조도 따로 확인해야 합니다. 토스 안에서 실행된다고 해서 법적 책임이나 사업자 의무가 사라지지는 않습니다. 적용 범위와 최신 심사 기준은 출시 전에 공식 자료와 필요한 전문가 검토로 확정합니다.

두 번째 벽: 익숙한 기술 스택과 익숙한 화면 동작은 다르다

React와 TypeScript를 안다고 바로 배포할 수 있는 것은 아닙니다. Granite 기반 번들 구성, 현재 버전과의 호환성, 최신 API와 기술 제약을 확인해야 합니다. 안드로이드 뒤로가기처럼 사용자가 당연하게 기대하는 동작도 토스 실행 환경에서 따로 점검해야 하죠.

TDS와 어울리지 않는 버튼·간격·로딩·오류 상태는 화면의 완성도를 떨어뜨립니다. 일반 웹앱처럼 모든 동작을 자유롭게 정할 수 있다고 가정하면 개발 후반에 구조를 다시 바꿀 가능성이 큽니다.

세 번째 벽: 토스의 사용자 기반과 내 서비스 데이터는 자동으로 이어지지 않는다

‘2,000만 사용자에게 노출된다’는 표현만으로 활성 사용자나 결제를 예상할 수는 없습니다. 실제 유입 경로와 이탈 지점, 재방문 여부는 허용된 분석 범위와 데이터 연결 방식에 달려 있습니다. [실제 테스트/경험 보완 권장: 유입 경로, 이탈 지점, 재방문 여부를 확인한 사례가 있다면 추가]

첫 버전은 개인정보를 거의 받지 않아도 핵심 가치를 전달하도록 설계하는 편이 안전합니다. 접근·뒤로가기·오류 상태를 실제 실행 환경에서 확인하고, 반복 사용 이유와 서버·운영 비용이 보이지 않는다면 사용자 규모에 대한 기대보다 프로젝트 중단 여부를 먼저 검토해야 합니다.

3. 기능보다 먼저 검증할 것은 뒤로가기와 화면 일체감이다

사용자가 토스 안에서 미니앱을 열고 입력을 끝내기 직전 안드로이드의 뒤로가기 버튼을 눌렀다고 가정해 보겠습니다. 미니앱이 갑자기 닫히거나 입력 중인 값이 사라지면 핵심 기능이 작동해도 다시 사용할 가능성은 낮아집니다.

이 문제를 출시 직전에 발견하면 수정 비용이 커집니다. 기능 목록을 정리하기 전에 화면이 열리고 닫히는 경로부터 정의해야 합니다.

실제 사용자 시나리오

1. 토스 안에서 미니앱을 연다.

2. 첫 화면의 버튼을 눌러 입력 화면으로 이동한다.

3. 버튼 위치, 입력창 간격, 전환 속도가 토스의 다른 화면과 지나치게 다르지 않은지 확인한다.

4. 입력 중 안드로이드 뒤로가기를 누른다.

5. 미니앱이 닫히는지, 이전 화면으로 이동하는지, 작성 중인 값이 유지되는지 확인한다.

6. 다시 미니앱에 진입해 입력 화면으로 돌아간다.

7. 입력을 완료하고 결과를 확인한 뒤, 이전 화면으로 갔다가 같은 입력 화면에 재진입한다.

화면이 예상과 다르게 닫히거나 상태가 엉키면 해당 문제부터 해결해야 합니다. 정확한 뒤로가기 처리 방식은 Granite 구성과 최신 공식 문서를 기준으로 정하고, 에뮬레이터뿐 아니라 실제 안드로이드 기기에서도 반복 확인합니다. [실제 테스트/경험 보완 권장: 기기별 테스트 결과와 발견된 오류를 추가]

화면 일체감은 색상만 맞추는 작업이 아닙니다. TDS 적용 가능 범위를 확인하면서 버튼·입력창·여백·문구·로딩·오류 상태와 화면 전환 흐름을 함께 조정해야 합니다. 토스 안에서 이질적으로 보이는 화면은 사용자가 오류로 오해할 수 있습니다.

| 검증 대상 | 확인할 흐름 | 통과 기준 |

|---|---|---|

| 화면 이동 | 첫 화면 → 입력 화면 → 결과 화면 | 사용자가 다음 행동을 이해할 수 있음 |

| 뒤로가기 | 입력 중 뒤로가기 → 재진입 | 의도하지 않은 종료나 상태 손실이 없음 |

| 재진입 | 이탈 → 미니앱 재실행 → 입력 화면 | 화면 상태가 꼬이지 않음 |

| 화면 일체감 | 버튼·간격·문구·오류 상태 확인 | 토스 실행 환경에서 낯선 동작이나 표현이 없음 |

| 실행 환경 | 에뮬레이터와 실제 안드로이드 기기 | 환경별 차이를 기록하고 대응함 |

최소 테스트 기록은 `첫 접속 → 입력 화면 이동 → 입력 중 뒤로가기 → 재진입 → 입력 완료 → 결과 확인`으로 남깁니다. 이 흐름이 실제 기기에서 안정적으로 통과되지 않으면 새 기능을 추가하지 말고, 화면 수와 상태 관리 범위부터 줄여야 합니다.

4. 처음부터 다시 만들지 않도록 개발 순서를 쪼갠다

첫 MVP의 목표는 회원가입·알림·결제·추천을 모두 갖추는 데 있지 않습니다. 사용자가 토스 안에서 한 가지 문제를 해결하고 오류 없이 빠져나오는 흐름을 검증하는 것이 핵심입니다. 앞 단계가 통과되지 않으면 다음 단계로 넘어가지 않는 방식으로 범위를 관리합니다.

1단계: 실행 환경부터 통과시킨다

화면을 만들기 전에 프로젝트가 실제 미니앱 실행 환경에서 빌드되는지 확인합니다. 일반 개발 서버에서 화면이 잘 뜨는 것만으로는 부족합니다. Granite의 공식 지원 범위와 번들 방식, 현재 React·TypeScript 버전과의 호환성을 점검해야 합니다.

2단계: 핵심 문제를 해결하는 최소 화면만 만든다

사용자가 입력하고 결과를 확인하는 한 가지 목적만 남깁니다. 성공 기준은 화면 수가 아니라 사용자가 실제로 문제를 해결했는지에 있습니다. 결제나 재사용과 직접 연결되지 않는 부가 기능은 ‘있으면 좋아 보여서’ 추가하지 않습니다.

3단계: 뒤로가기·재진입·이탈을 테스트한다

안드로이드 뒤로가기를 눌렀을 때 이전 화면으로 이동하는지, 입력 상태가 사라지지 않는지 확인합니다. 미니앱을 나갔다가 다시 들어와도 흐름이 꼬이지 않아야 하죠. 에뮬레이터와 실제 기기에서 반복하고, 뒤로가기 처리를 나중으로 미루지 않습니다.

4단계: 핵심 화면에만 TDS를 적용한다

TDS는 마지막에 색상만 바꾸는 작업이 아닙니다. 핵심 흐름이 통과된 뒤 버튼·간격·문구·오류 상태를 조정합니다. 모든 화면을 처음부터 완벽하게 다듬기보다 사용자가 실제로 막히는 화면부터 개선하는 편이 효율적입니다.

5단계: 개인정보를 줄이고 미완성 요소를 제거한다

서비스 작동에 꼭 필요한 정보만 수집합니다. 수집 목적과 이용 범위, 보관·파기 흐름을 구현 전에 정리하고, ‘준비 중’ 문구·임시 이미지·작동하지 않는 버튼은 심사 전에 제거해야 합니다.

중단 기준

다음 중 하나라도 해결되지 않으면 기능을 줄이거나 개발을 멈춥니다.

• Granite 빌드와 버전 호환성을 확인할 수 없음
• 핵심 사용자 흐름보다 부가 기능만 늘어남
• 개인정보 수집 이유와 파기 흐름을 설명하기 어려움
• 실제 기기에서 뒤로가기와 재진입 오류가 반복됨
• API·서버·로그 등 운영 비용을 추산할 수 없음

‘작게 시작한다’는 말은 대충 만든다는 뜻이 아닙니다. 핵심 흐름 하나가 실제 기기에서 안정적으로 작동하는지 확인한 뒤 다음 기능을 붙이는 전략입니다.

5. 심사 전에 다음 검증 과제를 끝내야 한다

심사에서 막히면 코드 수정 자체보다 ‘이 정보를 왜 수집하나요?’와 ‘이 화면은 어떤 상태인가요?’에 답하는 일이 더 오래 걸릴 수 있습니다. 미니앱이라고 해서 일단 열어두고 나중에 다듬을 수 있다고 가정해서는 안 됩니다.

출시 전에는 최신 공식 정책에서 미니앱 심사 기준, 입점 조건, 비용·수수료, 운영 제한을 다시 확인해야 합니다. 과거 글이나 다른 개발자의 경험만으로 출시 가능 여부를 단정하지 마세요.

개인정보는 서비스 작동에 꼭 필요한 범위만 받습니다. 각 입력값마다 수집 목적·이용 범위·보관 기간·파기 시점을 표로 만들고, 실제 화면과 안내문이 일치하는지 확인합니다. ‘나중에 쓰겠지’라는 이유로 이메일이나 생년월일을 미리 받지 않습니다.

비용은 API 단가만으로 계산하지 않습니다. 예상 호출량에 서버·데이터베이스·로그·모니터링·데이터 보관 비용을 더해 월 예상 비용을 산출합니다. 사용자 규모는 잠재적 도달 범위일 뿐, 모든 이용자가 설치하거나 결제한다는 의미는 아닙니다. 낙관적인 유입 가정과 보수적인 비용 가정을 분리해야 합니다.

| 확인 항목 | 실패 기준 | 다음 조치 |

|---|---|---|

| 핵심 사용자 흐름 | 첫 화면부터 완료까지 통과하지 못함 | 기능 축소 후 재검증 |

| 개인정보 | 수집 이유·이용 범위·파기 시점을 설명하지 못함 | 입력값 제거 또는 구조 변경 |

| 운영 비용 | API·서버·로그 비용을 추산하지 못함 | 호출량 제한·최소 저장 설계 |

| 심사 준비 | placeholder·미작동 버튼·테스트 메뉴가 남아 있음 | 출시 범위에서 제거 |

| 실행 안정성 | 실제 기기에서 뒤로가기·재진입 오류가 반복됨 | 상태 관리와 화면 경로 재설계 |

바로 실행할 후속 과제

1. 토스의 최신 공식 정책과 기술 문서에서 심사·입점·비용·운영 조건을 확인한다.

2. 개인정보 항목별로 수집 목적, 보관 기간, 파기 흐름을 표로 작성한다.

3. 핵심 사용자 흐름을 실제 안드로이드 기기에서 반복 테스트하고 이탈 지점을 기록한다.

4. 예상 호출량을 기준으로 API·서버·로그·모니터링의 월 비용을 계산한다.

5. 위 검증에서 실패한 항목을 기능 축소로 해결할 수 있는지 판단한다.

다음 단계로 넘어갈 조건도 명확히 둡니다. 핵심 흐름이 끝까지 이어지고, 개인정보 처리와 최신 심사 조건을 설명할 수 있으며, 운영 비용이 감당 가능한 범위로 계산될 때만 기능을 추가합니다. 하나라도 해결되지 않으면 ‘사용자 수가 늘면 나아질 것’이라는 가정 대신 프로젝트 축소 또는 중단을 선택해야 합니다.

❓ 자주 묻는 질문

Q. 토스 미니앱은 어떤 기술 스택으로 개발하나요?

A. 분석 자료 기준으로 React와 TypeScript를 사용하고 Granite 프레임워크 기반으로 번들을 구성한다. 실제 지원 버전과 설정 방식은 공식 개발 문서에서 추가 확인해야 한다.

Q. 토스 미니앱에서 안드로이드 뒤로가기를 따로 처리해야 하나요?

A. 그렇다. 일반 웹 화면처럼 브라우저 동작에만 기대지 않고 안드로이드 뒤로가기 상황에서 사용자가 예상한 화면으로 이동하는지 직접 구현하고 테스트해야 한다.

Q. 토스 미니앱 심사를 준비할 때 무엇을 먼저 확인해야 하나요?

A. 개인정보 수집을 필요한 범위로 줄이고, 화면에 남은 placeholder나 미완성 상태를 제거하는 것이 핵심 점검 항목이다. 세부 심사 요건과 최신 정책은 공식 자료로 확인해야 한다.

Q. 토스 미니앱이 일반 모바일 앱보다 1인 개발자에게 유리한 점은 무엇인가요?

A. 별도의 일반 네이티브 앱 유통 구조와 비교해 토스 이용자 기반 안에서 서비스를 검토할 수 있다는 점이 장점으로 분석된다. 다만 실제 도달 규모와 사업성은 서비스 유형과 공식 입점 조건에 따라 별도 검증이 필요하다.

이 아이디어를 참고할 때

이 글의 분석과 아이디어는 자유롭게 참고하고 활용할 수 있습니다.

두 가지만 부탁드립니다:

1. 참고했다면 이 글에 댓글 한 줄 남겨주세요. 어떤 부분이 도움됐는지, 어디까지 진행했는지 알려주시면 다음 글에 반영합니다.

2. 서비스·발표·문서에 사용할 때는 출처를 남겨주세요. 이 글의 URL 한 줄이면 충분합니다.

같이 만들거나 의견 나누고 싶은 분은 댓글로 편하게 말 걸어주세요.

공유·퍼갈 때 주의사항

• 이 글의 전체 또는 일부를 다른 곳에 게시할 때는 반드시 원문 URL을 출처로 표기해 주세요.
• 내용을 요약하거나 편집해 게시하는 경우에도 출처 표기는 동일하게 적용됩니다.
• 상업적 용도(유료 강의 자료, 유료 뉴스레터, 판매 콘텐츠 등)로 사용하려면 사전에 댓글 또는 연락을 통해 허락을 받아주세요.
• 출처 없이 전문을 복사해 게시하거나, 본인이 작성한 것처럼 게시하는 행위는 금지합니다.