앱인토스 소개 – 앱인토스 검수 통과 전 점검 체크리스트

앱인토스 검수 전에 대조할 기준은 주로 공식 문서 세 곳에 있습니다. 비게임 출시 가이드, 서비스 오픈 정책, 미니앱 등록하기 문서의 앱 정보 안내예요. 이 글은 그중 검수 요청 전에 손이 가는 기준을 골라 항목마다 맞추는 방법을 적고, 미니앱을 운영하며 남은 실제 검수 기록을 근거로 한두 줄씩 붙였습니다.

출시 가이드 10개 구역 전체를 훑는 내용과 버전 관리·롤백(Rollback) 절차는 출시 전 체크리스트와 버전 관리 글에 정리해 두었습니다. 여기서는 같은 표를 다시 만들지 않고 “이 기준을 이렇게 맞춘다”에만 집중해요. 공식 문서는 모두 2026년 10월 21일에 다시 받아 확인했습니다.

기획 전에 출시 불가 분야부터 대조한다

서비스 오픈 정책 3장 “출시 불가 서비스 · 콘텐츠”는 앱인토스 검수에서 기능을 잘 만들어도 맞출 수 없는 기준입니다. 문서는 미니앱이 토스 플랫폼 정책, 관련 법령, 사용자 보호 기준에 맞는지 미리 점검하라고 하고, 해당하는 서비스는 출시할 수 없다고 적어요. 그래서 이 항목은 개발이 아니라 기획 단계에서 맞춥니다.

표는 3장 항목 중 일부만 추린 것입니다. 부동산 쪽은 매물 검색과 시세 조회뿐 아니라 청약/분양, 세금 계산, 인테리어/리모델링, 이사까지 범위에 들어 있어서 생각보다 넓어요.

앱 정보는 상세 설명과 스크린샷 규격을 맞춘다

미니앱 등록하기 문서는 앱인토스 검수에 함께 올라가는 앱 정보 칸마다 기준을 따로 둡니다. 상세 설명은 사용자가 처음 실행한 뒤 핵심 기능을 경험하기까지의 과정을 “서비스 접속 → 행동 → 결과” 흐름의 문장으로 적으라고 안내해요. 상세 설명을 바탕으로 토스 홈 광고 대상으로 선정될 수 있다는 문장도 있어서, 기능 이름만 나열하기보다 무엇을 보고 누르는지까지 쓰는 편이 기준에 맞습니다.

주요 기능은 한국어 이름 10자, 영어 이름 15자 이내이고 특수문자는 :과 .만 쓸 수 있습니다. 이동할 intoss://pages 주소에 정상 접속되지 않으면 반려될 수 있다고 문서에 적혀 있어서, 제출 전에 주소를 하나씩 열어 보면 이 항목은 확인됩니다. 카테고리는 실제 서비스와 다르면 검토 과정에서 알맞은 것으로 바꾼 뒤 안내한다고 합니다.

뒤로가기는 토스 내비게이션 바 하나로 처리한다

내비게이션 바 구역의 뒤로가기 기준은 두 문장으로 정리됩니다. 토스 내비게이션 바의 뒤로가기 버튼과 미니앱이 자체 구현한 뒤로가기 버튼이 동시에 보이면 안 되고, 최초 화면에서 뒤로가기를 누르면 미니앱이 종료돼야 해요. 내비게이션 바 설정 문서에는 withBackButton 옵션으로 뒤로가기 버튼 표시 여부를 정하는 방법이 있습니다.

맞추는 방법은 자체 헤더와 뒤로가기 버튼을 화면에서 빼고, 토스 뒤로가기를 SDK 이벤트로 받는 것입니다. graniteEvent.addEventListener("backEvent", …)는 구독을 해제하는 함수를 돌려주므로 화면을 떠날 때 그 함수를 부르면 돼요. 원본 디자인 기준 문서에는 화면을 떠날 때 해제하지 않으면 메인에서 앱이 종료되지 않는다는 주의와, 홈에서는 열린 시트가 없으면 구독 자체를 하지 않는다는 규칙이 적혀 있습니다.

진입 화면과 네트워크 대기 시간은 웹뷰 기준으로 잡는다

앱인토스 출시 가이드의 UX 구역은 미니앱에 진입하자마자 토스 로그인이나 알림 동의문 같은 바텀시트가 자동으로 나타나지 않아야 한다고 적습니다. 기준 원문은 출시 전 체크리스트 글에 정리해 두었고, 바텀시트 컴포넌트를 “사용자가 탭했을 때만 열린다”로 만들어 두면 이 기준에 맞출 수 있습니다.

놓치기 쉬운 쪽은 이전 실행의 상태입니다. 원본 디자인 기준 문서에는 지난 실행에서 열려 있던 시트 상태를 복원한 것이 실제 재심사 사유였다고 적혀 있어요. 같은 문서는 이 경우를 진입 시 자동 모달·바텀시트 금지 항목 아래에 함께 묶어 두었어요. 원본 시트 컴포넌트의 주석도 “진입 시 자동으로 열거나 지난 실행 상태를 복원하지 않는다”로 이 규칙을 적어 두었고요.

네트워크 대기 시간도 같은 원리입니다. 출시 가이드는 호출 실패 시 재시도 횟수와 간격을 제어하고, 인터랙션 반응이 2초 이상 지연되지 않게 하라고 해요. 원본 기록에는 데스크톱 기준으로 짧게 잡은 타임아웃이 웹뷰의 정상 응답을 실패로 처리한 것이 재심사 사유였다고 남아 있습니다. 같은 문서는 읽기·인증 15초, 네이티브 브리지 8초를 출발점으로 잡는데, 이 숫자는 공식 기준이 아니라 원본 작업 기준이에요.

인앱 광고 ID는 빌드 종류로 나눈다

앱인토스 검수에서 광고 기준은 두 문서에 나뉘어 있습니다. 인앱 광고 문서는 개발 단계에서 반드시 테스트용 광고 ID를 쓰라고 하고, 실제 광고 ID로 테스트하면 정책 위반으로 간주해 불이익을 받을 수 있다고 적어요. 출시 가이드에는 테스트 광고가 아닌 실제 인앱 광고가 정상적으로 노출돼야 한다는 항목이 있습니다. 개발 중에는 테스트 ID, 출시 번들에는 실제 ID가 들어가야 둘 다 맞출 수 있죠.

고친 코드의 핵심은 아래 함수입니다. 실행 환경이 샌드박스면 테스트 ID를, 토스 앱이면 콘솔에서 발급한 실제 ID를 돌려주고, 그 밖에는 빈 값을 돌려줘요.

export function selectAdGroupId(
  format: AdFormat,
  environment: RuntimeEnvironment,
  liveId: string,
  testIds: Partial<Record<AdFormat, string>> | undefined = TEST_AD_GROUP_IDS,
): string {
  if (environment === 'sandbox') return testIds?.[format] ?? '';
  if (environment === 'toss') return liveId;
  return '';
}

광고 종류와 load·show 호출 순서는 인앱 광고 글에 따로 정리했습니다.

앱인토스 검수 요청 직전에 확인할 순서

앞의 항목을 다 맞췄다면 검토 요청 전에 아래 순서로 한 번 더 봅니다. 순서는 미니앱 등록하기 문서의 번들 업로드·토스앱 테스트·검토 요청 단계에 이 글의 점검 항목을 끼워 넣은 것이에요.

승인 뒤 출시하기와 새 버전 업데이트, 롤백은 출시 전 체크리스트와 버전 관리 글의 순서를 따르면 됩니다.

업무에 맞춘 AI 설계 상담은 AI특별시에서 받습니다.

앱인토스는 토스 앱 안에서 미니앱을 서비스하는 플랫폼이고, 공식 안내는 앱인토스 개발자센터에 있습니다.

이 글은 공식 자료와 실제 화면을 기준으로 정리했습니다. 정책·가격은 기준일 이후 바뀔 수 있습니다.