테스트는 통과했는데, 6개의 물건은 고를 수 없었다 — 시니어 인지 게임 개발기
팀 마실 · 팀장 강모세, 조원 조영현 (영진전문대학교 컴퓨터정보공학과)
AICU 시니어 인지기능 향상 게임 개발 해커톤 장려상
TL;DR
- 손님을 집에 초대해 준비하는 생활 장면 하나에 기억력·주의력·언어능력·시공간능력·실행기능 활동을 담은 오프라인 Android 태블릿 게임입니다. Kotlin과 Jetpack Compose로 만들었습니다.
- 앱에 인터넷 권한이 없습니다. 기기 안의 작은 TensorFlow Lite 모델이 다음 판에 목표 물건 표시 힌트를 줄지 정합니다.
- 가장 크게 배운 것은 기획 의도를 실제 동작으로 확인하는 방법이었습니다. 빌드와 자동화 테스트를 통과한 상태에서도 "모든 품목을 고를 수 있다"와 "설정이 게임을 바꾼다"는 의도는 구현되어 있지 않았습니다.
한 판을 마치면 오늘 준비한 물건을 돌아보고, 다음 판 방식을 안내받습니다.
1. 카드 뒤집기가 아닌, 손님맞이
처음 인지 훈련 게임을 떠올렸을 때 제 머릿속에 있던 것은 카드 뒤집기나 숫자 맞히기였습니다. 저희는 다른 방향을 골랐습니다. 건강한 노인 대상 다영역 인지훈련 연구(Gajewski 외, 2020)와, 경도인지장애 노인을 위해 대형마트 장보기·계산·정리 과제를 묶은 시리어스 게임의 설계·파일럿 연구(Ortega Morán 외, 2024)를 참고해, 과제를 영역별로 쪼개지 않고 생활 장면 하나 안에 여러 활동을 연결하기로 설계 방향을 정했습니다.
‘우리 집에 놀러와’의 한 판(목표 5~8분)은 이렇게 흘러갑니다.
- ① 계획 세우기 — 손님 맞을 준비물을 직접 고릅니다. (언어·기억)
- ② 동선 계획 — 매장 지도(입구·코너 3곳·계산대)에서 들를 코너와 순서를 정합니다. (시공간능력·실행기능)
- ③ 물건 찾기 — 비슷하게 생긴 미끼 상품 사이에서 고른 물건을 찾습니다. (기억·주의)
- ④ 계산(선택) — 담은 물건 값의 합계를 보기 3개 중에서 고릅니다. (실행기능)
- ⑤ 손님 맞이 — 오늘 준비한 물건을 돌아보고 다음 판 방식을 안내받습니다.
괄호 안은 설계상 주로 쓰는 인지 영역입니다.
점수를 깎는 장치는 없습니다. 예산을 넘겨도 다음으로 넘어갈 수 있습니다.
화면은 본문 22sp, 선택 라벨 20sp, 주요 버튼·카드 최소 높이 48dp로 구성했습니다. 조작은 탭으로 고르고 스크롤로 목록을 넘기는 두 가지뿐입니다.
연구는 규칙 설계의 참고 자료로만 썼습니다. 이 게임은 치매 예방·치료 같은 의료적 효과를 주장하지 않으며, 위 표의 영역 매핑도 설계 의도이지 측정 결과가 아닙니다.
실제 앱 화면(공구·생활수리 테마). 계획 → 동선 → 찾기 → 계산 → 손님 맞이.
2. 요리 재료와 ‘심부름’ 서사를 바꾼 이유
초기안은 요리 재료 중심의 장보기, 그리고 누군가 시킨 일을 하는 ‘심부름’ 서사였습니다. 두 가지를 바꿨습니다.
- 요리 재료 단일 테마 → 요리 경험에 따라 기억해 낼 품목의 난이도가 크게 달라질 수 있다고 봤습니다.
- 심부름 서사 → 플레이어가 지시받는 사람처럼 느낄 수 있다고 판단했습니다. 기획안 14.3(“시니어 사용자를 비하하거나 부정적으로 묘사하는 내용” 감점)을 참고하면서, 준비물을 플레이어가 직접 정하는 ‘손님맞이’ 구성을 선택했습니다.
이 결정은 코드 구조에도 반영됐습니다.
테마를 데이터로 일반화했습니다. 요리 하나에 묶여 있던 품목 데이터를 ShoppingTheme으로 일반화했습니다. 요리, 공구·생활수리, 원예·화초, 약국·생필품, 문구·우편, 반려동물의 6개 테마를 두고, 처음 실행할 때 익숙한 테마를 고르게 했습니다. 테마마다 목표 품목 10개와 헷갈리는 미끼 짝, 매장 코너 3곳이 있습니다. 그림은 목표 60개, 미끼 60개, 장면 2개로 모두 122장이며, ChatGPT 이미지 생성 기능으로 팀이 직접 만들어 앱에 넣었습니다.
틀렸을 때 알려주기만 합니다. 초기 버전은 미끼를 눌러도 아무 반응이 없었습니다. 지금은 경고색이나 감점 없이 “비슷하지만 목록에 없는 물건이에요”라고만 안내합니다.
미끼(LED등)를 누르면 다른 점만 알려줍니다. 목표 품목 옆의 ·가 3절의 AI가 켜고 끄는 힌트입니다.
동선 화면도 같은 원칙을 따릅니다. 진행을 막는 경우에도 무엇을 빼거나 더하면 되는지 문장으로 알려줍니다.
되돌아갈 수 있게 했습니다. 진행 중 ‘← 이전 단계’로 돌아가도 고른 물건과 담은 물건은 그대로 남습니다. 이때 상태 문제가 하나 있었습니다. AI가 정한 “다음 판 힌트 여부”를 결과가 나오자마자 반영하면, 계산대에서 찾기 화면으로 돌아갔을 때 같은 라운드 안에서 힌트가 바뀔 수 있었습니다. 그래서 판단을 보류값(pendingHideHint)에 담아 두고, 라운드를 넘길 때만 적용하게 했습니다.
fun advanceRound() {
pendingHideHint.value?.let { hideHintNextRound.value = it } //여기서만 적용
pendingHideHint.value = null
...
}
3. 인터넷 없는 AI가 맡은 딱 한 가지 일
대회 규정상 완성된 앱은 외부 생성형 AI API나 외부 AI 서버를 호출할 수 없었고, 주요 기능이 인터넷 없이 돌아가야 했습니다. 저희 앱은 매니페스트에 INTERNET 권한 자체가 없습니다.
AI의 역할은 일부러 하나로 좁혔습니다. 다음 판의 물건 찾기 화면에서 목표 물건 옆에 표시(·)를 붙여줄지, 아니면 표시 없이 스스로 떠올려 찾게 할지입니다.
- 입력: 이번 판 정답률(목표 수 ÷ (목표 수 + 미끼 오탭 수)), 품목당 평균 소요 시간, 라운드 번호
- 모델: 팀이 직접 학습한 소형 분류 모델
difficulty_model.tflite(TensorFlow Lite 2.16.1). 학습은 PC에서, 앱은 추론만 .tflite는 압축하지 않고(noCompress) 번들해 메모리 매핑으로 읽습니다. 모델이 아직 초기화되지 않은 상태에서 예측을 요청하면 힌트를 유지하는 기본값을 돌려줍니다. 다만 모델 로딩 중 예외를 복구하는 처리는 구현하지 않았습니다.- 설정에서 “난이도 자동 조절 (AI)”을 끄거나 “목록 다시 보기 항상 허용”을 켜면 모델 판단보다 사용자 선택이 우선합니다.
한계도 같은 무게로 적습니다. 실제 플레이 기록이 없었기 때문에, 설계 의도(정답률이 높고 빠르며 라운드가 쌓일수록 힌트를 줄인다)를 점수식으로 만들고 노이즈를 섞은 합성 데이터로 학습한 초기 모델입니다. 개발 문서에는 합성 검증 정확도 95.9%로 기록했지만, 이는 모델이 우리가 정한 규칙을 잘 따라 한다는 뜻입니다. 사용자에게 맞는 난이도라는 증거가 아니고, 지금은 규칙식과 본질적으로 같은 판단을 합니다. 실사용 데이터로 재학습한 모델을 같은 입출력 형식으로 다시 번들하는 것이 다음 방향입니다. 학습용 기록 수집과 모델 갱신 절차는 아직 없습니다.
4. 고를 수 없던 6개의 물건 — 테스트를 통과한 결함
저희는 처음부터 빌드, 단위 테스트, 그리고 온보딩부터 결과 화면까지 한 판 전체를 자동으로 진행하는 에뮬레이터 UI 테스트를 돌리고 있었습니다. 기능이 어느 정도 갖춰졌을 때, 구현을 진행한 작업 흐름과 분리된 새 컨텍스트의 리뷰 세션에 코드베이스 전체 검토를 맡겼습니다. 작성자가 자기 결과물을 채점하지 않게 하려는 장치였습니다. 점검한 오프라인·외부 API 관련 항목에서는 위반이 없었습니다. 대신 테스트가 모두 통과한 상태에서 결함 두 개가 나왔습니다.
켜지기만 하던 설정. 설정 화면의 토글 3개(난이도 자동 조절 (AI), 이중과제(계산 단계) 사용, 목록 다시 보기 항상 허용)는 화면 안의 지역 상태(remember)에만 값을 갖고 있어서, 바꿔도 게임은 그대로였습니다. 이 값들을 게임 상태(GameSession)로 올려 DataStore에 저장하고, 힌트 노출, 모델 호출 여부, 계산대 건너뛰기에 실제로 연결했습니다.
10개 중 4개만 고를 수 있던 계획 화면. theme.items.take(4) 한 줄 때문에 테마당 품목 10개 중 앞의 4개만 후보로 나왔고, 나머지 6개는 고를 방법이 없었습니다. “준비물을 플레이어가 정한다”는 2절의 설계가 정작 화면에서는 빠져 있었던 셈입니다. 10개 전부를 보여주도록 고쳤습니다.
UI 테스트는 “한 판을 끝까지 진행할 수 있는가”를 확인하고 있었습니다. 그래서 몇 번째 품목까지 고를 수 있는지, 설정을 바꾸면 무엇이 달라지는지는 묻지 않았습니다. 테스트 통과와 기획 의도 충족은 같은 말이 아니었습니다.
5. 테스트가 확인하는 것과 확인하지 않는 것
제출 시점에는 단위 테스트 39개(테마 데이터, 게임 상태, AI 추론 래퍼, 계산 보기 생성, 동선 평가, 품목 그림 번들 여부)와 UI 테스트 4개(전체 흐름, 설정 테마 변경, 진행 중 나가기, 이전 단계로 돌아가기)가 통과했습니다.
이 글을 쓰며 다시 보니 같은 종류의 틈이 남아 있었습니다. ‘이전 단계로 돌아가기’ 테스트는 담은 물건의 ✓ 표시로 상태 유지를 확인하는데, ✓는 힌트가 꺼져 있어도 담은 물건에 표시됩니다. 그러니 이 테스트는 담은 물건의 유지는 확인하지만, 힌트가 라운드 안에서 유지되는지는 증명하지 못합니다. 10개 품목 전부의 선택 가능 여부나 설정 토글 3개의 실제 화면 효과도 아직 테스트로 고정되어 있지 않습니다.
그래서 지금 기능을 검토할 때 저는 한 가지를 같이 적습니다. 이 단언이 실패하려면 어떤 버그가 있어야 하는가. 답이 “없다”면 그 테스트는 아직 의도를 지키고 있지 않은 것입니다.
함께 만든 방식. 팀장인 저는 기획과 개발을, 조영현 팀원은 개발·테스트·검토를 맡았습니다. 개발에는 Claude Code를 쓰면서 단계별 체크리스트와 대회 규정 조항 원문을 프로젝트 지침으로 고정해 두었습니다. 생성 이미지 35장을 원본 시트에서 다시 잘라내는 작업은 Codex에 맡겼습니다.
어느 도구를 쓰든 완료의 기준은 사람이 정했고, 그 기준이 충분하지 않았다는 사실도 위의 리뷰로 알게 됐습니다.
남아 있는 제한사항
- 실제 태블릿 기기와 실제 시니어 사용자 대상 테스트는 하지 못했습니다. 앱 실행 검증은 Android 에뮬레이터(Pixel Tablet, API 34)에서, 단위 테스트는 JVM에서 했습니다.
- AI는 합성 데이터 모델이고, 조절하는 것은 목표 표시 힌트 하나입니다. 결과 화면은 “다음엔 목록 없이 떠올려서 찾아볼 거예요”라고 안내하지만, 실제로 바뀌는 것은 찾기 화면의 표시입니다. 안내 문구와 동작을 맞추는 것이 다음 과제입니다.
- 효과음과 음성 안내가 없습니다.
- 품목·코너 데이터는 화면과 분리해 두었습니다. 하지만 여행 준비 같은 새 장면으로 넓히려면 안내 문구와 장면 이미지도 함께 바꿔야 합니다.
다음 기능을 만들 때는 버튼이 화면에 보이는지뿐 아니라, 누른 뒤 바뀌어야 할 상태와 그다음 화면까지 확인하고 그 확인을 테스트로 남기려 합니다. 이번 해커톤이 남긴 습관입니다.
참고
- Gajewski, P. D., Thönes, S., Falkenstein, M., Wascher, E., & Getzmann, S. (2020). Multidomain Cognitive Training Transfers to Attentional and Executive Functions in Healthy Older Adults. Frontiers in Human Neuroscience, 14, 586963. https://doi.org/10.3389/fnhum.2020.586963
- Ortega Morán, J. F., Pagador, J. B., Gilete Preciado, V., Moyano-Cuevas, J. L., Rodríguez Domínguez, T., Santurino Muñoz, M., & Sánchez Margallo, F. M. (2024). A Serious Game for Cognitive Stimulation of Older People With Mild Cognitive Impairment: Design and Pilot Usability Study. JMIR Aging, 7, e41437. https://doi.org/10.2196/41437
- ㈜에이아이씨유. 「시니어 인지기능 향상 게임 개발 해커톤」 기획안, 14.3항 중 "시니어 사용자를 비하하거나 부정적으로 묘사하는 내용"(감점 기준).
