앱인토스 PO가 알려주는 AI로 미니앱 만들기

이 웨비나의 핵심은 단순히 “AI로 코딩하면 미니앱을 빨리 만들 수 있다”가 아니다. 더 중요한 메시지는 개발 지식이 부족해도 AI와 대화하면서 서비스 기획을 구체화하고, 목업을 만들고, 실제 앱을 구현하고, 토스 환경에서 테스트하고, 심사 반려까지 수정하는 전체 사이클을 돌릴 수 있다는 것이다.

동시에 앱인토스에서 좋은 결과를 내려면 기술보다 먼저 어떤 사용자에게 어떤 가치를 주는지 뾰족하게 정의하고, 작지만 완결된 경험을 만드는 것이 중요하다고 반복해서 강조한다.

1. 앱인토스는 왜 만들어졌나

토스는 송금에서 시작해 대출, 쇼핑, 주식, 증명서, 예약 등으로 사용 영역을 넓혀 왔다. 하지만 토스 내부 인력과 시간만으로 사용자가 원하는 모든 서비스를 직접 만드는 데에는 한계가 있다.

앱인토스는 이 한계를 외부 제작자와 함께 풀기 위한 구조다. 좋은 아이디어를 가진 제작자가 토스 안에서 미니앱을 만들고 배포할 수 있게 함으로써, 토스가 금융 슈퍼앱에서 더 넓은 일상 슈퍼앱으로 확장되는 기반을 만들겠다는 방향이다.

파트너 입장에서 앱인토스 콘솔은 단순 업로드 화면이 아니다. 미니앱 등록, 배포, 사용 데이터 확인, 수익 확인과 정산 등 운영 전반을 관리하는 관리자 공간이며, 워크스페이스는 실제 제작과 협업의 기본 단위다.

2. 토스 사용자는 미니앱을 어디서 발견하는가

웨비나에서는 미니앱의 주요 노출 경로를 크게 다섯 가지로 설명한다.

검색

토스 검색창에서는 등록된 미니앱을 검색할 수 있다. 검색 유입은 생각보다 중요한 사용자 획득 채널이다.

여기서 핵심은 앱 이름, 설명, 키워드 같은 메타 정보의 품질이다. 단순히 검색량이 많아 보이는 키워드를 넣는 방식은 오히려 역효과가 날 수 있다.

예를 들어 명상 앱이 송금 같은 인기 키워드를 넣으면 검색 결과에 한 번 노출될 수는 있다. 하지만 사용자는 클릭하지 않거나 들어왔다가 바로 나갈 가능성이 높다. 플랫폼은 이런 반응 데이터를 보고 “이 검색어와 이 앱은 관련성이 낮다”고 판단해 노출을 낮출 수 있다.

따라서 검색 키워드는 내 앱을 찾은 사용자가 실제로 만족할 만한 단어를 넣어야 한다.

미니앱 홈

토스 안의 미니앱·게임 영역은 앱스토어나 플레이스토어와 비슷한 역할을 한다. 인기 있는 앱, 사용자 반응이 좋은 앱, 내부 큐레이션을 받은 앱 등이 발견되는 공간이다.

메이커 입장에서는 상위권에 어떤 앱들이 있고 왜 선택받고 있는지 관찰하는 것 자체가 좋은 시장조사다.

최근 사용 영역

사용자가 한 번이라도 실행한 미니앱은 최근 사용 영역에 남는다. 일종의 스마트폰 홈 화면과 비슷한 재방문 동선이다.

따라서 한 번 유입시키는 것만으로는 부족하다. 사용자가 다시 켜고 싶게 만드는 이유를 설계해야 최근 영역에서 지속적으로 살아남을 수 있다.

토스 홈 개인화 추천

토스 홈은 앱을 켜자마자 노출되는 가장 강력한 지면 중 하나다. 모든 미니앱이 동일하게 노출되는 공간은 아니며, 사용자가 실제로 얼마나 잘 쓰는지, 오래 머무는지, 다시 방문하는지 등을 바탕으로 추천이 이뤄진다.

웨비나에서는 일부 파트너가 이 지면에 노출되면서 일시적으로 트래픽이 크게 증가한 경험도 있다고 설명한다.

핵심은 플랫폼이 단순 설치 수가 아니라 사용자 만족의 신호를 본다는 점이다.

혜택 탭과 프로모션

미니앱에서 토스 포인트를 지급하는 프로모션 기능을 활용하면 혜택 탭에 노출될 수 있다.

다만 리워드는 그 자체가 목적이 아니라 사용자가 앱의 핵심 가치를 경험하도록 유도하는 수단으로 써야 한다.

예를 들어 실손보험 환급 서비스라면 단순 접속 시 포인트를 주기보다 병원비 조회를 완료하거나 실제 환급 경험을 한 순간에 보상을 연결하는 방식이 더 적절하다. 사용자가 서비스의 본질적 가치를 경험하는 시점과 프로모션을 연결해야 재사용으로 이어질 가능성이 높다.

3. 잘 노출되는 미니앱의 네 가지 조건

웨비나에서 정리한 조건은 다음 네 가지다.

1) 작지만 완결된 기능

처음부터 많은 기능을 넣는 것보다, 사용자가 하나의 일을 빠르게 끝낼 수 있는 작은 서비스를 만드는 편이 좋다.

앱인토스가 지향하는 경험은 사용자가 필요가 생겼을 때 별도 앱을 설치하지 않고 토스를 열어 검색하고, 필요한 미니앱에서 목적을 해결한 뒤 깔끔하게 빠져나오는 것이다.

따라서 기능 수보다 한 번의 사용에서 가치가 완결되는가가 중요하다.

2) 구체적이고 뾰족한 타깃

“모든 사람을 위한 앱”은 추천 시스템 입장에서도 누구에게 보여줘야 할지 알기 어렵다.

예를 들어 남성보다 30대 남성, 그보다 테니스에 관심 있는 30대 남성처럼 타깃이 구체적일수록 플랫폼이 사용자를 이해하고 적절한 사람에게 추천하기 쉬워진다.

타깃을 좁히면 사용자 수가 줄 것 같지만, 오히려 추천 정확도가 올라가 실제 사용자가 늘어날 수 있다는 설명이다.

3) 자연스러운 사용자 경험

앱을 켜자마자 불필요한 로그인부터 요구하거나, 예상하지 못한 광고를 띄우는 식의 경험은 지양해야 한다.

사용자는 “내가 하려던 일”을 최대한 빨리 해결할 수 있어야 한다. 토스 특유의 간결하고 빠른 경험과 잘 맞는 서비스일수록 플랫폼 방향과도 맞는다.

4) 충실한 메타 정보

앱 이름, 부제, 상세 설명, 카테고리, 검색 키워드, 로고, 썸네일, 스크린샷을 대충 채우면 안 된다.

이 정보들은 단순 등록 서류가 아니라 검색과 추천이 내 앱을 이해하는 데이터다. 특히 상세 설명에는 실제 사용자가 무엇을 할 수 있는지를 구체적으로 적는 것이 중요하다.

4. 리워드 앱만 잘 되는가

앱인토스 초기에 리워드성 미니앱들이 상위권을 많이 차지하면서 “앱인토스에서 성공하려면 리워드 앱을 만들어야 하는가”라는 인식이 생겼다고 한다.

웨비나의 답은 그렇지 않다는 것이다.

리워드 앱을 좋아하는 사용자는 분명 존재하고 실제 사용량도 많지만, 경쟁이 과열되면 서비스의 본질적 가치보다 보상 크기 경쟁으로 흐를 수 있다. 플랫폼 입장에서는 이것이 지속 가능한 구조가 아니다.

그래서 리워드성 서비스는 포인트 관련 영역에서 잘 찾을 수 있게 하고, 다른 유형의 서비스도 별도의 추천·노출 기회를 얻을 수 있도록 구조를 나누는 방향을 취하고 있다.

중요한 것은 리워드 유무가 아니라 사용자에게 실제 가치를 주는지, 그리고 그 가치가 누구에게 필요한지 플랫폼이 이해할 수 있는지다.

5. AI 미니앱 제작에서 가장 중요한 것은 코딩이 아니라 기획이다

웨비나 시연은 Claude Code를 사용했지만, 발표자는 Codex 같은 다른 코딩 에이전트에서도 유사한 방식으로 작업할 수 있다고 설명한다.

일반 대화형 AI와 코딩 에이전트의 차이는 명확하다. 일반 챗봇은 질문에 답하는 데 집중하지만, Claude Code나 Codex 같은 도구는 내 컴퓨터의 파일을 만들고 수정하며 실제 프로젝트를 구성할 수 있다.

하지만 발표자가 가장 강조한 부분은 “코딩을 잘하는 방법”이 아니다.

AI가 코드를 잘 쓰기 때문에 바로 만들기 시작하면 오히려 더 많이 돌아갈 수 있다.

먼저 내가 무엇을 만들고 싶은지 충분히 정리하지 않으면, 결과물이 나온 뒤 “내가 원한 건 이게 아닌데”라는 상황이 생긴다. 그러면 구현을 다시 뜯어고쳐야 한다.

따라서 가장 먼저 해야 할 일은 AI와 대화하면서 요구사항 명세서를 만드는 것이다.

6. 실전 제작 흐름

웨비나에서 시연한 전체 과정은 다음과 같이 정리할 수 있다.

단계 1. 개발 문서를 AI에게 읽힌다

앱인토스 개발자 센터에는 콘솔 사용법, 도구 설치, 배포 등 방대한 문서가 있다.

이를 처음부터 사람이 다 읽기보다 개발자 센터 링크를 Claude Code에 주고 다음처럼 요청한다.


이 문서를 읽고 앱인토스 미니앱을 출시하는 과정을 단계별로 정리해줘.

설명이 너무 어렵거나 길면 다시 단순하게 요구하면 된다.


이해가 잘 안 돼. 더 쉽게 설명해줘.
HTML로 시각화해서 보여줘.

핵심은 전문 용어를 모두 이해하려고 멈추지 않는 것이다. 필요한 순간에 AI에게 다시 설명시키면 된다.

단계 2. 아이디어를 바로 코딩하지 말고 요구사항 명세로 만든다

시연에서는 “레트로 감성의 명상·호흡 앱”이라는 막연한 아이디어에서 시작했다.

AI에게 단순히 “이 앱 만들어줘”라고 하지 않고, 먼저 생각을 정리해 달라고 한다.


앱인토스 미니앱을 만들 건데 내가 무엇을 만들고 싶은지 아직 생각 정리가 잘 안 돼.
하나씩 질문하면서 핵심 가치, 타깃 사용자, 기능, 화면, 디자인 방향을 구체화해줘.
마지막에는 요구사항 명세서로 정리해줘.

AI가 선택지를 주고, 사용자는 그중 마음에 드는 방향을 고른다.

이 과정을 통해 다음과 같은 내용이 정리된다.

핵심 가치
만들지 않을 것
타깃 사용자
주요 기능
화면 흐름
세션 길이
수익화 여부
디자인 콘셉트
색상과 비주얼 가이드
사운드 방향

발표자는 이 기획 대화를 짧게 끝내지 말고 충분히 길게 가져가는 편이 결과가 좋았다고 설명한다. 실제로 20~60분 정도 대화하며 요구사항을 다듬는 방식을 소개했다.

완성된 명세서는 반드시 직접 읽어보고 자신이 원하는 방향과 맞는지 확인해야 한다. AI가 잘 정리했다고 그대로 믿고 넘어가면 이후 구현 단계에서 크게 돌아갈 수 있다.

단계 3. 인터랙티브 목업을 만든다

요구사항이 정리되면 바로 전체 앱을 개발하기보다, 먼저 눌러보고 흐름을 확인할 수 있는 인터랙티브 목업을 만든다.


이 폴더의 요구사항 명세를 읽고 내가 원하는 서비스가 맞는지 확인할 수 있는 인터랙티브 목업을 만들어줘.

정적인 이미지가 아니라 버튼을 눌러 다음 화면으로 넘어가고, 실제 사용자 흐름을 미리 경험할 수 있는 형태다.

이 과정의 목적은 세 가지다.

전체 개발 전에 방향이 맞는지 빠르게 확인한다.
주변 사람에게 보여주고 피드백을 받을 수 있다.
잘못된 디자인이나 흐름을 저렴한 비용으로 수정한다.

단계 4. 마음에 안 드는 부분은 화면 캡처로 지적한다

AI에게 디자인을 수정시키기 위해 전문 용어를 쓸 필요는 없다.

화면을 캡처해 붙여 넣고 다음처럼 말하면 된다.


이 캐릭터가 마음에 들지 않아. 더 단순하고 귀여운 2D 캐릭터로 바꿔줘.
옆의 이상한 네모도 없애줘.

발표자는 AI를 “아주 똑똑한 비서”처럼 생각하고 자연어로 계속 피드백하라고 조언한다.

단계 5. 참고 디자인을 이미지로 준다

디자인 방향을 말로 표현하기 어렵다면 앱스토어, 잘 만든 미니앱, 핀터레스트 등에서 참고 이미지를 찾고 캡처해 전달할 수 있다.


이 이미지와 비슷한 분위기로 디자인을 다시 잡아줘.

다만 참고와 복제는 다르다. 웨비나에서도 특정 디자인이나 캐릭터를 그대로 복사하는 것은 피하고, 분위기와 감성의 참고 자료로 활용해야 한다고 강조한다.

단계 6. 실제 미니앱으로 구현한다

목업이 충분히 마음에 들면 요구사항 명세와 목업을 바탕으로 실제 앱을 구현한다.


이 폴더에 요구사항 명세와 인터랙티브 목업이 있어.
이걸 참고해서 실제 앱인토스 미니앱으로 만들고 토스 앱에서 테스트할 수 있게 해줘.

이후 AI가 개발 문서와 필요한 도구를 참고하면서 프로젝트 파일을 생성하고 구현을 진행한다.

이 단계는 실제 코드를 작성하기 때문에 시간이 가장 오래 걸릴 수 있다. 시연에서는 구현이 진행되는 동안 앱 정보 등록 같은 다른 작업을 병렬로 처리했다.

단계 7. 콘솔에 앱 정보를 등록한다

개발 중 기다리는 시간에는 콘솔에서 앱 정보를 등록한다.

모르는 화면이 나오면 캡처해서 AI에게 그대로 물어보면 된다.


여기까지 들어왔어. 이제 뭐 해야 해?

AI가 화면을 보고 어느 버튼을 눌러야 하는지, 어떤 값을 넣어야 하는지 안내하게 한다.

앱 등록에서 특히 중요한 정보는 다음과 같다.

앱 이름
앱 식별자
부제
상세 설명
카테고리
앱 로고
썸네일
스크린샷
검색 키워드

이 과정은 단순 행정 작업이 아니다. 앞에서 설명한 검색과 추천에 직접 영향을 주는 사용자 획득 준비 단계다.

단계 8. 필요한 이미지 자산도 AI로 만든다

로고, 썸네일, 스크린샷 같은 에셋도 AI에게 만들게 할 수 있다.

웨비나에서는 AI가 파일을 프로젝트 폴더 안에 생성하게 하고, 만들어진 결과물을 콘솔에 직접 업로드했다.

다만 생성된 결과물의 품질이 마음에 들지 않으면 그대로 쓰지 말고 반복해서 수정하는 것이 중요하다.

단계 9. 빌드와 배포를 한다

구현이 끝나면 앱인토스에서 사용할 수 있는 빌드 파일을 만들고 콘솔에 올린다.

시연에서는 두 가지 방식을 보여줬다.

콘솔에서 빌드 파일을 직접 업로드
CLI를 이용해 AI가 배포 과정을 수행하도록 하기

CLI나 API 키 같은 개념이 어렵더라도, 발표자는 필요한 순간에 AI에게 절차를 물어보며 따라갈 수 있다고 설명한다.

다만 API 키는 비밀정보이므로 한 번 표시될 때 안전하게 보관하고 외부에 노출하지 않아야 한다. 웨비나 시연에서도 공개 화면에 노출된 키는 즉시 폐기할 예정이라고 언급했다.

단계 10. 빌드 실패는 정상적인 과정으로 본다

라이브 시연 중 실제로 빌드 실패와 SDK 버전 문제 등이 발생했다.

이때의 대응법이 오히려 웨비나의 중요한 포인트다.

오류 화면이나 메시지를 캡처한다.
AI에게 그대로 전달한다.
이 오류가 났어. 원인을 찾아서 고쳐줘.라고 요청한다.
다시 빌드한다.
같은 방식으로 반복한다.

즉, 에러를 피하는 것이 아니라 에러를 AI와 함께 해결하는 루프를 익히는 것이 중요하다.

단계 11. 토스 앱에서 직접 테스트한다

빌드가 완료되면 콘솔에서 테스트를 실행하고, 워크스페이스 멤버가 실제 토스 앱 환경에서 미니앱을 사용할 수 있다.

테스트 링크가 있다고 아무나 들어갈 수 있는 것은 아니며, 웨비나 시연 기준으로는 워크스페이스에 속한 멤버가 테스트할 수 있었다.

협업자나 지인을 워크스페이스에 초대하고 직접 써보게 한 뒤 피드백을 받는 것이 중요하다.

발표자는 자신이 만든 것을 주변 사람에게 계속 보여주고 “이거 어때?”, “이상한 부분 없어?”라고 묻는 과정을 적극적으로 활용한다고 설명한다.

단계 12. 충분히 테스트한 뒤 검토 요청한다

앱인토스에서는 테스트를 하지 않으면 검토 요청을 할 수 없도록 되어 있다.

테스트 후 출시 노트와 앱 내 기능 정보를 작성해 검토를 요청한다. 승인되면 출시 가능한 상태가 되고, 실제 출시를 눌렀을 때 토스 사용자에게 공개된다.

라이브 시연에서는 브랜드 아이콘 설정 누락으로 즉시 반려됐다. 이 또한 같은 방식으로 처리한다.


심사에서 이런 이유로 반려됐어.
개발자 문서를 다시 확인하고 필요한 부분을 수정한 뒤 다시 빌드해줘.

즉, 심사 반려도 개발 프로세스의 끝이 아니라 또 하나의 피드백 입력이다.

7. AI 코딩을 잘 쓰는 실전 패턴

웨비나 전체에서 반복되는 사용 패턴은 매우 단순하다.

모르면 “모르겠다”고 말한다


이게 무슨 뜻인지 모르겠어.
내가 개발을 모른다고 가정하고 설명해줘.

전문 용어를 억지로 이해하려고 멈추기보다 AI에게 다시 풀어 쓰게 한다.

처음 보는 화면은 캡처해서 묻는다


여기까지 왔어. 이제 뭘 해야 해?
이 화면에서 어떤 값을 넣어야 해?

설정 화면, 오류 화면, 콘솔 화면 모두 같은 방식으로 처리할 수 있다.

결과가 마음에 안 들면 감상 수준으로 말해도 된다


이 디자인 별로야.
캐릭터가 거슬려.
조금 더 차분하고 단순하게 바꿔줘.

구체적인 전문 용어보다 원하는 느낌을 솔직하게 전달하고 반복 수정한다.

긴 작업은 여러 세션으로 나눌 수 있다

대화가 너무 길어져 맥락이 흐려지면 기존 대화에서 다음과 같이 요청한다.


지금까지 한 작업을 새 대화에서 이어갈 수 있도록 핵심 맥락과 현재 상태를 요약해줘.

그 요약을 새 세션에 붙여 넣고 작업을 계속하면 된다.

시간이 오래 걸리는 작업은 병렬로 진행한다

코딩이나 빌드가 진행되는 동안 앱 메타 정보 작성, 디자인 에셋 제작, 다른 검토 작업을 별도 세션에 시킬 수 있다.

발표자는 실제로 여러 개의 대화를 띄워 병렬로 작업한다고 설명했다. 다만 초보자는 헷갈릴 수 있으므로 처음에는 1~2개 작업만 병렬로 돌리는 편이 낫다.

8. 권한 설정은 편의보다 안전이 우선이다

Claude Code가 외부 문서를 읽거나 로컬 파일을 수정할 때 권한을 요청할 수 있다.

웨비나에서는 빈 테스트 폴더처럼 위험 요소가 거의 없는 환경에서 권한 확인을 건너뛰는 모드를 시연했지만, 동시에 매 작업마다 허용하는 방식이 가장 안전하다고 설명한다.

실전에서는 다음 원칙이 적절하다.

중요한 파일이 있는 폴더에서는 권한 우회를 사용하지 않는다.
테스트용 별도 폴더를 만든다.
AI가 어떤 파일을 읽고 수정하는지 범위를 명확히 한다.
API 키나 비밀값은 채팅, 화면 공유, 저장소에 노출하지 않는다.
권한을 건너뛰기 전에 경고 내용을 이해한다.

9. 메이커 관점에서 가져갈 핵심 교훈

“많이 만드는 것”보다 “무엇을 만들지 명확히 하는 것”이 먼저다

AI가 코드를 빠르게 써준다고 해서 기획 비용이 사라지는 것은 아니다. 오히려 구현 속도가 빨라질수록 잘못된 방향으로 빠르게 달릴 위험도 커진다.

그래서 요구사항 명세와 인터랙티브 목업에 시간을 쓰는 것이 전체 제작 시간을 줄인다.

플랫폼 노출은 꼼수가 아니라 사용자 반응으로 결정된다

검색 키워드를 많이 넣거나 리워드를 크게 붙이는 방식만으로 장기적인 노출을 만들기 어렵다.

실제 사용자가 클릭하고, 머물고, 다시 방문하고, 목적을 해결하는 행동이 쌓여야 추천이 강화된다.

좁은 타깃은 약점이 아니라 추천 가능성을 높이는 정보다

누구에게나 적당히 쓸 만한 앱보다 특정 사용자가 분명히 좋아하는 앱이 추천 시스템에 더 이해하기 쉽다.

AI는 정답 생성기가 아니라 반복 작업 파트너다

좋은 결과는 한 번의 완벽한 프롬프트에서 나오지 않는다.

기획 → 목업 → 캡처 피드백 → 구현 → 오류 → 수정 → 테스트 → 사용자 피드백 → 심사 반려 → 재수정의 반복이 핵심이다.

10. 실제로 따라 할 때의 최소 체크리스트

앱인토스 콘솔 계정과 워크스페이스를 만든다.
Claude Code 또는 유사한 코딩 에이전트를 준비한다.
앱인토스 개발 문서를 AI에게 읽히고 출시 흐름을 요약시킨다.
아이디어를 바로 구현하지 말고 요구사항 명세를 만든다.
타깃 사용자와 핵심 가치를 최대한 구체화한다.
인터랙티브 목업을 만들고 충분히 수정한다.
주변 사람에게 보여주고 피드백을 받는다.
요구사항 명세와 목업을 기준으로 실제 미니앱을 구현한다.
개발 중에는 콘솔 앱 정보와 메타 정보를 병렬로 채운다.
검색 키워드와 상세 설명은 실제 사용 의도에 맞게 작성한다.
로고·썸네일·스크린샷 등 필요한 에셋을 준비한다.
빌드 오류가 나면 화면과 오류 메시지를 AI에게 전달해 반복 수정한다.
토스 앱에서 직접 테스트한다.
워크스페이스 멤버에게 테스트를 요청하고 사용자 피드백을 받는다.
충분히 수정한 뒤 검토를 요청한다.
반려 사유가 나오면 그대로 AI에게 전달해 수정하고 다시 빌드한다.

결론

앱인토스에서 AI를 활용하는 가장 좋은 방법은 “코드를 대신 써주는 도구”로만 보는 것이 아니다.

아이디어를 구체화하는 기획자, 개발 문서를 읽는 보조자, 인터랙티브 목업을 만드는 디자이너, 실제 코드를 작성하는 개발자, 오류를 해결하는 디버거, 심사 반려를 수정하는 작업 파트너로 한 흐름 안에서 계속 활용하는 것이 핵심이다.

그리고 그 모든 기술보다 앞서는 기준은 명확하다.

작지만 완결된 가치를 만들고, 누구를 위한 서비스인지 뾰족하게 정의하고, 사용자가 자연스럽게 핵심 경험에 도달하게 만드는 것.

AI는 그 방향이 명확할 때 가장 강력한 제작 도구가 된다.