구구단 미니앱을 어디까지 만들었나? 6개 테스트와 9장 스크린샷으로 점검한 구구단히어로

왜 구구단히어로를 만들었나

구구단히어로는 "구구단을 반복해서 연습할 때, 학습자가 군더더기 없이 짧은 문제를 풀며 자신의 정답을 직관적으로 확인할 수 있는가?"라는 질문에서 출발했습니다. 구구단은 단순히 공식을 암기하는 것보다, 여러 번 문제를 풀고 오답을 바로바로 점검하는 짧은 인터랙션 루프가 훨씬 효과적이기 때문입니다.

처음 서비스를 구상할 때는 부모 리포트, 학생 간 반 랭킹, 캐릭터 성장 시스템 등 다양한 기능을 떠올렸습니다. 하지만 처음부터 너무 많은 요소를 담으려다 보면 정작 가장 중요한 "문제 풀이 경험이 매끄러운가"를 검증하기 어려워집니다.

그래서 이번 1차 프로토타입에서는 복잡한 욕심을 내려놓고, 단 하나의 핵심 질문에만 집중하기로 결정했습니다.

① 학습자가 미니앱에 들어와 막힘없이 문제를 풀고, 자신의 결과를 즉시 확인할 수 있는가?

이 기본 흐름이 매끄럽게 돌아가지 않는다면 그 어떤 차별화 기능도 무의미하다고 보았기 때문입니다. 화려한 시장성이나 거창한 비전을 내세우기보다, 실제로 동작하는 구구단 연습 루프를 만들어 첫 번째 가설을 검증하는 것이 이번 개발의 진짜 출발점입니다.

무엇을 넣고 무엇을 뺐나: 핵심 결정과 범위

초기 개발 단계에서 가장 중요했던 작업은 "지금 만들 것"과 "다음으로 미룰 것"의 경계를 명확히 긋는 일이었습니다.

① 핵심 문제 풀이 루프에 100% 집중했습니다.

퀴즈 카드에서 문제가 출제되고, 시간 내에 답을 입력하면 즉시 정오답을 확인하고 다음 문제로 넘어가는 기본 흐름을 최우선으로 완성했습니다. 사용자가 조작 과정에서 버벅거리거나 이탈하지 않도록 UI 반응성과 직관적인 화면 전환을 다듬었습니다.

② 매력적이지만 무거운 부가 기능은 과감히 다음 단계로 분리했습니다.

부모님이 아이의 학습 현황을 확인하는 '부모 리포트', 경쟁 요소를 더하는 '반 랭킹', 주간 리포트를 전달하는 '토스 푸시 알림', '학습 인증서', '캐릭터 수집 요소' 등은 모두 유용한 아이디어입니다. 하지만 기본 문제 풀이 경험이 검증되기 전까지는 계획 단계로 남겨두고 이번 1차 구현 범위에서는 제외했습니다.

③ 앱인토스 표준 규격에 맞춘 기본 안정성을 확보했습니다.

미니앱이 토스 환경 안에서 안정적으로 실행되도록 표준 설정(`apps-in-toss.config.ts`, `granite.config.ts`)을 맞추고, 코드 수준의 정적 검사와 테스트를 통과하는 실행 기반을 먼저 탄탄히 정비했습니다.

기능의 개수보다 중요한 것은 "지금 만든 핵심 기능이 제대로 작동하는가"였습니다. 1차 검증 범위와 후속 개발 범위를 명확히 나누었기에, 프로토타입의 완성도에만 온전히 몰입할 수 있었습니다.

실제 화면과 사용 흐름

구구단히어로는 사용자가 앱을 열어 연습을 시작하고 최종 결과를 확인하기까지 군더더기 없는 흐름으로 설계되었습니다.

① 연습 시작 화면

앱을 실행하면 복잡한 메뉴 대신 바로 구구단 연습에 몰입할 수 있는 깔끔한 진입 화면이 표시됩니다. 학습자가 망설이지 않고 연습을 시작할 수 있도록 직관적인 시작 버튼을 배치했습니다.

② 인터랙티브 문제 풀이

연습이 시작되면 상단에 남은 시간과 진행 상태가 깔끔하게 안내되며 문제가 제시됩니다. 사용자가 보기를 선택하거나 답을 입력하면 시각적인 효과와 함께 정오답 피드백이 즉시 주어집니다.

③ 결과 요약 및 재도전

정해진 문제 풀이가 끝나면 총 풀이 시간, 맞힌 개수, 정확도가 한눈에 정리되어 표시됩니다. 자신이 얼마나 잘했는지 확인하고 바로 다시 도전할 수 있도록 유기적인 재시작 동선을 제공합니다.

이번에 점검한 화면 구성은 불필요한 단계를 최대한 덜어내고 학습에만 집중할 수 있는 최소한의 필수 동선으로 채웠습니다.

만들면서 부딪힌 현실: 설정과 타입 안정성

구구단히어로를 개발하면서 마주한 가장 큰 허들은 새로운 화면을 그리는 것보다 "프레임워크 표준 규격과 코드의 타입 안정성을 맞추는 일"이었습니다.

① 미니앱 프레임워크 설정 정합성 맞추기

`package.json`의 앱 식별자부터 시작해 `@apps-in-toss/web-framework`가 요구하는 설정 속성들을 표준 미니앱 규격에 정확히 맞추는 작업이 필요했습니다. 설정 파일의 구조가 조금만 어긋나도 실행과 패키징 단계에서 예기치 못한 문제가 발생할 수 있기 때문입니다.

② 타이머 인터벌과 TypeScript 타입 정리

퀴즈 화면(`QuizCard.tsx`)에서 제한 시간을 처리하는 타이머 로직의 타입을 엄격하게 정비했습니다. 브라우저 환경과 리액트 상태 관리 사이에서 발생할 수 있는 타입 불일치를 바로잡아, 린트 검사(`npm run lint`)에서 오류 0개로 깔끔하게 통과하도록 다듬었습니다.

③ 자동화된 검증 파이프라인 확인

코드 수정이 다른 기능에 영향을 주지 않도록 단위 테스트 6종 전체를 작성하여 통과시켰고, 최종 빌드 및 패키징 명령어(`npm run build`)를 통해 `gugudan-hero.ait` 배포 패키지 생성이 정상적으로 완료되는 것을 확인했습니다.

겉으로 보이는 화려한 기능 이전에, 코드가 안정적으로 빌드되고 검증을 통과하는 튼튼한 뼈대를 갖추는 것이 실제 출시를 위한 가장 중요한 첫걸음이었습니다.

지금 상태와 다음 계획

현재 구구단히어로는 핵심 기능 구현 및 1차 패키징 검증을 마친 단계입니다.

• **린트 검사**: TypeScript 린트 에러 0개 통과
• **단위 테스트**: 핵심 로직 및 컴포넌트 6종 테스트 전체 통과
• **빌드 및 패키징**: 앱인토스 표준 패키지(`gugudan-hero.ait`) 빌드 성공
• **화면 검증**: 제출용 스크린샷 9장 준비 완료

지금까지의 과정이 코드와 패키징 수준의 준비 상태를 입증한 것이라면, 다음 단계는 "실제 사용자가 이 흐름을 어떻게 느끼는가"를 확인하는 일입니다.

앞으로 진행할 후속 개발 과제:

1. 실제 학습자가 문제 풀이 과정에서 멈칫하거나 어려워하는 지점이 어디인지 사용성을 점검합니다.

2. 매일 조금씩 학습을 이어갈 수 있는 '오늘의 미션'과 '9×9 수집 지도'의 우선순위를 정해 개발합니다.

3. 부모님이 아이의 학습 현황과 정답률을 편하게 확인할 수 있는 '부모 리포트' 화면을 설계합니다.

4. 캐릭터 성장 요소와 주간 학습 알림 등 장기 리텐션을 돕는 기능들을 순차적으로 검토합니다.

하나의 미니앱을 완성해 나가는 과정은 끊임없이 가설을 세우고 작은 단위로 검증해 나가는 여정인 것 같습니다. 여러분이라면 다음 업데이트에서 '오늘의 미션/수집 지도'와 '부모 리포트' 중 어떤 기능부터 먼저 만나보고 싶으신가요?

첨부한 실제 화면

• 이미지 1: 01.png (실제 화면 1)
• 이미지 2: 02.png (실제 화면 2)
• 이미지 3: 03.png (실제 화면 3)
• 이미지 4: 04.png (실제 화면 4)

이 개발기를 참고할 때

이 글은 제가 직접 만든 제품의 개발 과정을 정직하게 공유하는 기록입니다.

• 스크린샷과 설명은 작성 시점의 실제 상태 기준이며, 이후 업데이트로 달라질 수 있습니다.
• "다음 계획"으로 표시한 기능은 아직 완성된 기능이 아닙니다.
• 참고하거나 인용할 때는 이 글의 URL을 출처로 남겨주세요.
• 궁금한 점이나 피드백은 댓글로 남겨주시면 다음 개발과 다음 글에 반영하겠습니다.