앱인토스 미니앱 저장 기능을 9월 10일 저녁에 붙였습니다.
자동 테스트 321건이 전부 통과한 번들을 실기기에서 한 시간 돌리자 결함이 5건 나왔습니다.
이 글은 「교통비 환급 계산기」에 자주 가는 길과 환급 장부를 넣은 기획 의도, 로그인을 붙이지 않은 이유, 실기기에서 잡힌 5건과 그 뒤에 세운 자동 게이트의 기록입니다.
숫자는 전부 9월 10일 앱인토스 콘솔·서버 DB·실기기 화면의 조회값이고, 전망이나 수익 보장은 아닙니다.
저장할 데이터가 없는 계산기는 다시 열 이유가 없고, 저장할 데이터는 로그인이 아니라 익명키로 충분했습니다.
앱인토스 미니앱 저장 기능은 리텐션 0%의 답으로 시작했습니다
이 앱의 첫날 재방문율은 2.5%였습니다.
답을 주는 순간 관계가 끝나는 계산기의 구조가 그대로 숫자로 나온 것이었습니다.
그래서 기능이 아니라 데이터부터 정했습니다.
사용자가 저장하고 싶을 데이터의 조건을 셋으로 두었습니다.
다시 넣기 귀찮은 것, 쌓일수록 값이 커지는 것, 바깥 세상이 바꾸는 것입니다.
기존 입력인 월 통행 수와 요금은 첫 조건만 약하게 만족해서 마지막 입력 한 벌만 기기에 남고 끝났습니다.
세 조건을 겹쳐 만족하도록 고른 데이터가 셋입니다.
길은 월 통행 수와 평균 요금이 되어 슬라이더를 다시 만질 일을 없애고, 장부는 매달 두 번 열 이유를 만듭니다.
토스 미니앱 익명키가 있어서 로그인은 붙이지 않았습니다
처음 검토한 것은 토스 로그인이었습니다.
콘솔의 토스 로그인 설정에서 필수 항목은 이름 하나였고, 나머지 여섯 항목은 사용 안 함이었습니다.
그런데 로그인이 새로 해주는 일이 이 앱에는 없었습니다.
익명키는 토스 계정 기준 해시라 앱을 지우거나 기기를 바꿔도 같은 값이고, 서버 식별에는 그것으로 충분합니다.
로그인만 되는 것은 두 번째 미니앱에서 같은 사람으로 이어 보는 것뿐인데, 그 앱은 보류 중입니다.
반대로 비용은 분명했습니다.
체류 30~40초짜리 앱의 첫 화면에 로그인 시트가 끼고, 이용약관 URL과 개인정보 처리방침이 새로 필요하며, 개인정보 0건이던 검수 이점이 사라집니다.
여기부터는 제 해석입니다.
로그인은 수단이고, 먼저 있어야 할 것은 저장하고 싶은 데이터였습니다.
서버를 먼저 올리고 번들은 한 번만 내기로 했습니다
앱인토스는 번들을 바꿀 때마다 검수를 다시 받습니다.
그래서 서버와 동의문처럼 검수가 없는 것부터 올리고, 화면은 한 번에 담았습니다.
서버에는 테이블 3개와 엔드포인트 3개를 만들었습니다.
길과 조건을 통째로 저장하는 것, 지난달 환급액을 적는 것, 그리고 저장된 내용을 돌려주는 것입니다.
예상 환급은 앱이 보낸 값을 받지 않고 서버가 저장된 길과 조건으로 다시 계산합니다.
앞서 배너를 붙일 때 클라이언트 값을 그대로 저장했다가 되돌린 적이 있어서, 이번에는 처음부터 서버가 계산하게 두었습니다.
배포 뒤 80초 만에 새 경로가 응답했고, 실기기에서 저장한 길 2개와 9월 예상 환급 76,950원이 DB에 그대로 있었습니다.
실기기 테스트 한 시간에 결함 5건이 잡혔습니다
자동 테스트는 119건에서 시작해 전부 통과했습니다.
그런데 실기기에서 첫 화면을 열자마자 첫 지적이 나왔습니다.
실기기 캡처 · 2026-09-10 22:09 · 번들 20260910-21
실기기 스크린샷 한 장이 심사의 유일한 증거가 된 일은 앱인토스 심사 반려 글에 따로 적었습니다.
첫 번째, “60통행까지만 적립돼요"는 현행 제도에 없는 문장이었습니다.
K-패스 누리집 적립안내에는 월 15회 이상 조건만 있고 60회 상한은 없었습니다.
옛 규칙을 기억으로 넣은 제 오류였고, 이 앱의 요구사항 문서는 이미 횟수 상한을 두지 않는다고 적고 있었습니다.
두 번째, “25통행부터는 더 타도 내는 돈이 그대로예요"가 표와 달랐습니다.
실기기 캡처 · 2026-09-10 22:16 · 번들 20260910-22
같은 화면 아래 「통행 수를 바꿔 보면」 표는 30통행에서 23,250원, 40통행에서 30,000원이었습니다.
내는 돈이 30통행에서 아직 늘고 있는데 문장은 25통행부터 그대로라고 말한 것입니다.
실기기 캡처 · 2026-09-10 22:22 · 번들 20260910-22
원인은 문장이 시차 시간대 가산을 빼고 기본 환급률 20%로만 계산한 데 있었습니다.
이 사용자는 시차 시간대 대부분이라 환급률이 50%였고, 그 조건에서 내는 돈이 30,000원에 닿는 통행 수는 39였습니다.
표는 시차를 반영해 계산하고 문장은 빼고 계산해서 서로 어긋난 것이고, 9월 7일부터 있던 결함이었습니다.
세 번째, 10월 탭에서는 같은 문장이 80통행으로 바뀌어 근거를 알 수 없었습니다.
산식을 전수 대조하자 조합 180개 중 15개에서 공식과 실제 계산이 1통행씩 어긋났습니다.
닫힌 공식을 버리고, 표와 같은 계산을 통행 수 1씩 올려 가며 돌려 내는 돈이 기준금액에 처음 닿는 통행을 찾도록 바꿨습니다.
다음 날 원문을 다시 대조하다가 이 80통행에 원인이 하나 더 있다는 걸 찾았습니다.
시차 출퇴근 환급률 상향은 2026년 4월 1일부터 9월 30일까지 이용분에만 붙는 한시 정책인데, 계산기가 10월 이용분에도 가산을 붙이고 있었습니다.
가산을 빼면 10월은 시차 비중과 상관없이 50통행부터 최대치에 닿고, 이 결함은 9월 11일 새벽 정정 번들로 고쳤습니다.
네 번째, 그래도 문장이 어려웠습니다.
“몇 통행부터 그대로"가 아니라 “한 달에 내는 돈은 9월 최대 30,000원, 10월부터 최대 62,000원"으로 바꿨습니다.
먼저 다 내고 다음 달 돌려받는 구조라 “청구"라는 말은 쓰지 않았습니다.
다섯 번째, 직접 입력 모드에서 합계 행이 길 합계가 아니라 입력값을 보여줬습니다.
길은 9통행인데 합계가 1통행으로 찍혔고, 같은 김에 길 행에서 바로 지우는 버튼도 붙였습니다.
번들은 여섯 번 다시 등록했습니다.
실기기에서만 잡히는 것을 자동 게이트로 앞당겼습니다
5건 중 제도 사실 오류 하나를 뺀 4건은 자동화로 막을 수 있는 종류였습니다.
세 층을 같은 밤에 넣었습니다.
번들 검증은 일부러 실패시켜 실제로 막는지 확인했습니다.
그 게이트가 첫날 잡은 것이 하나 있습니다.
메인 저장소의 의존성이 갱신 전이라 SDK 3.2.0으로 찍힌 번들이 나왔고, 매니페스트 대조가 걸러냈습니다.
테스트는 119건에서 321건이 됐고, 번들 20260910-26은 23시에 검토 요청을 넣었습니다.
로컬 렌더 · 2026-09-10 23:10 · 번들 20260910-26 · QA 표시 모드(예시 값)
정리
- 저장 기능의 출발은 기능이 아니라 데이터였고, 조건은 재입력 비용·누적 가치·외부 변화 셋입니다.
- 로그인은 붙이지 않았습니다. 익명키가 기기 변경 뒤에도 같아 저장·복원에 충분합니다.
- 서버를 먼저 올리고 예상 환급은 서버가 계산하며, 번들은 한 번만 검수받게 했습니다.
- 자동 테스트가 전부 통과한 뒤에도 실기기에서 5건이 나왔고, 그중 하나는 제도 사실 오류였습니다.
- 그 뒤 번들 검증·컴포넌트 테스트·산식 전수 대조 세 층을 넣어 테스트가 321건이 됐습니다.
다음 글은 저장한 길이 실제로 재방문을 만드는지, 검수 승인 뒤 출시 첫 주의 저장률과 장부 기재율을 콘솔 이벤트로 읽는 편입니다.
새 글은 최신 글 목록이나 RSS에서 확인할 수 있습니다.
새 글이 이웃새글 목록에 뜹니다.
이어서 볼 글
업데이트 · 2026-09-10 밤 기준. 번들 20260910-26은 검토 중이며, 승인·출시 결과는 다음 글에 적습니다.
이 글은 개인 개발 기록이며 앱인토스 정책·검수 기준은 토스가 예고 없이 바꿀 수 있습니다. K-패스 환급 규칙은 누리집 적립안내를 기준으로 했고, 개인 조건에 따라 환급액은 다릅니다.
참고자료
- K-패스 누리집 적립안내 — 15회 이상 조건·세 방식 계산법 원문
- 앱인토스 개발자 문서 — 인앱 광고 — 콘솔 SDK 업데이트 안내가 연결되는 페이지
- 앱인토스 개발자 문서 — 비게임 검수 체크리스트 — 토스 로그인 항목 4개가 여기 있습니다