핵심 비유
앱 평가는 상권 시뮬레이터의 한 걸음 더 나아간 모드다 — G1·G2에서 학생이 데이터로 근거를 모아 '가게'를 정했다면, 여기서는 그 가게를 알리는 홍보 앱(HTML 한 장)을 앱 빌더로 직접 만들어 제출하고, AI 채점자가 점수를 매긴다. 이때 AI는 **미술 심사위원이 아니라 '계획서 검수관'**이라고 생각하면 정확하다 — "예쁘냐/화려하냐"가 아니라 "네가 세운 계획대로 만들었나(목표 근접), 앱이 진짜로 돌아가나(완성도), 수업에서 모은 근거를 실제로 썼나(상권 반영)" 이 세 가지만 본다. 그래서 이 채점은 디자인 감각을 겨루는 게 아니라, G1·G2에서 배운 '데이터로 판단하고 그 판단을 실행으로 옮기는' 능력이 앱까지 이어졌는지를 확인하는 장치다. 배점의 무게중심(40점)이 '목표 근접'에 실린 것도 그 때문이다 — 이 도구가 상 주려는 것은 '멋진 앱'이 아니라 '자기 계획을 지킨 앱'이다.
핵심 포인트
- 채점 대상은 학생이 제출한 앱 HTML 한 장이다. 학생은 앱 빌더로 만든 홍보 앱 코드를 '앱 제출' 화면에 붙여넣어 제출하고, 잠시 뒤(큐 처리) 점수와 코멘트가 자기 화면에 뜬다. 교사는 대시보드의 앱 평가 카드에서 반 전체의 제출 현황·점수 목록을 보고, 제출을 마감하거나 잘 만든 앱을 무대 갤러리에 띄울 수 있다.
- ⭐ 채점은 정확히 3축, 총 100점이다 — 이 셋이 이 모듈의 전부다:
- **점수를 매기는 것은 AI(클로드 Sonnet 5, 실패 시 Haiku 4.5로 자동 대체)**다. 다만 총점은 AI가 아니라 서버가 세 축을 더해서 낸다(40+30+30). AI가 실수로 45점을 줘도 서버가 40점으로 잘라 맞춘다(각 축은 정해진 만점을 넘지 못한다). 즉 배점 규칙은 코드가 강제하고, AI는 각 축의 '정도'만 판단한다.
- AI가 보는 자료는 딱 네 가지다(그 밖은 안 본다): ① 학생 계획(정한 업종·가격·한줄소개) ② 학생이 담은 근거(데이터 근거는
[데이터] …, 인터뷰 근거는 [손님 주장] …으로 구분해 전달) ③ 앱 요약(서버가 자동 분석한 것 — 앱 제목, HTML이 제대로 열리는지, 버튼·입력폼·링크·클릭동작이 몇 개인지, 글자 수) ④ 앱 코드 원문(참고용). 이 네 가지를 3축에 비춰 점수와 한국어 코멘트 4개(축별 3개 + 총평 1개)를 낸다.
- ‼️ 채점기는 세 가지 안전 규칙으로 단단히 묶여 있다 — 교사가 알아두면 "AI가 이상하게 줬어요"류 질문에 답할 수 있다:
- 재제출은 최대 3번까지다. 학생은 앱을 고쳐 최대 3회 다시 제출할 수 있고(그 이상은 막힌다), 라운드가 마감되면 더는 제출할 수 없다. "한 번에 완벽"이 아니라 점수·코멘트를 보고 고쳐서 다시 내는 반복을 전제로 설계됐다.
- 교사 화면의 점수 색은 등급이 아니라 신호등일 뿐이다: 총점 80점 이상은 초록(우수)·60점 이상은 노랑(보통)·그 미만은 회색으로 표시되지만, 이건 합격/불합격 선이 아니다. 60점 미만이라고 '틀린 앱'이 아니라, 세 축 중 어디가 비었는지를 코멘트로 짚어 고치게 하는 재료다.
- 이 채점은 G1·G2의 철학을 그대로 잇는다. G2에서 "이 게임은 점수로 학생을 줄 세우는 도구가 아니다"라고 했듯, 앱 점수도 줄 세우기가 아니라 대화의 재료다. 배점이 '목표 근접(계획-실행 일치)'과 '상권 반영(근거 사용)'에 쏠려 있다는 것 자체가, 이 도구가 **"화려하게 잘 만들었냐"가 아니라 "데이터로 정한 걸 앱까지 밀고 갔냐"**를 묻는다는 뜻이다.
교사 팁
채점 결과를 나눠주기 전에 학생과 한 가지를 약속하라 — "이 점수는 잘 만든 앱을 뽑는 등수가 아니라, 네 계획이 앱까지 이어졌는지 보는 체크"라고. 그래야 60점을 받은 학생이 좌절하는 대신 코멘트를 열어 "아, 근거를 앱에 안 썼구나(상권 반영 낮음)"를 스스로 짚는다. 세 축을 학생 말로 미리 풀어 두면 좋다: 목표 근접 = "정한 대로 만들었나", 완성도 = "진짜 돌아가나(빈 껍데기 아닌가)", 상권 반영 = "수업에서 모은 근거를 앱에 담았나". 특히 세 번째가 이 수업 전체를 하나로 꿰는 지점이다 — 브리핑에서 근거 바구니에 담기만 하고 앱엔 안 쓴 학생이 흔한데, 그 학생에게 "네가 담은 '20대 45%'가 앱 어디에 보여?"라고 되물으면 근거를 '모으는 것'과 '쓰는 것'이 다르다는 걸 배운다. 점수가 낮은 축의 코멘트를 함께 읽고 재제출(최대 3회)로 그 축만 고쳐 다시 내게 하라 — 한 축을 겨냥해 고치고 점수가 오르는 경험이, 루브릭을 '심판'이 아니라 '개선 지도'로 쓰게 만든다. 그리고 절대 "예쁘게 만든 앱이 고득점"이라는 인상을 주지 마라 — 이 채점기는 디자인을 보지 않는다. 무대 갤러리에 띄울 앱도 '점수 1등'이 아니라 **'근거를 앱에 잘 녹인 앱'**을 골라, 반 전체가 "이 앱은 어떤 데이터를 어디에 썼나"를 함께 읽는 것으로 마무리하는 것이 이 모듈을 가장 깊게 쓰는 법이다.