앱을 만들기 전에,
문제부터 찾습니다

심사는 세 축, 코딩은 그중 하나

세 가지를 같은 배점으로 심사합니다. 코딩은 그중 하나. 나머지 둘은 어떤 문제를 골랐는가, 사용자가 쓸 수 있게 풀었는가입니다. 좋은 문제를 고르는 일이 잘 짜는 일과 같은 무게입니다.

세 축 동일 배점. 전국 공통 주제는 없고, 실제 지역 문제를 푸는 '작동하는 앱'이 좋은 평가를 받아 왔습니다.

그래서 아이디어부터 다룹니다. 이 규모에서 눈에 남는 앱은 기능이 화려한 앱이 아니라, 우리 지역 문제를 실제 데이터로 짚어 낸 앱입니다. 문제를 찾는 일이 발상의 핵심입니다.

넓히고 좁히기, 두 번 — 더블 다이아몬드

좋은 아이디어는 한 번에 떠오르지 않습니다. 정해진 네 단계를 거칩니다. 먼저 문제를 넓게 모아 하나로 좁히고, 다음으로 해결책을 넓게 펼쳐 하나로 좁힙니다. 다이아몬드 두 개가 그 리듬입니다.

초반 몇 주간 코드를 짜지 않아도 정상입니다. 지금은 문제를 찾고 다듬는 단계. 이 과정을 건너뛴 앱이 대회에서 가장 흔한 출품작입니다.

어디서든 같은 다섯 걸음, 출발은 우리 지역구

이 대회는 지역구별로 따로 심사합니다. 출발점은 '요즘 뜨는 앱'이 아니라 '우리 지역구가 뭘 힘들어하는가'. 아래 다섯 걸음은 어느 지역구에나 적용되는, 이 대회 전용 조사 순서입니다.

A단계는 거주지·재학 학교가 어느 지역구에 속하는지 확인하는 일입니다. 자격과 지역구 확인은 학부모 안내(일정·자격)에 정리해 두었습니다.

문제는 네 곳에서, 근거와 함께

'어떤 문제를 풀까'를 상상으로 정하지 않습니다. 네 갈래로 실제 자료를 모으고, 반복되는 불편을 문제 후보로 적습니다. 여기서 나온 공공 통계와 현장 관찰이 아이디어의 근거가 됩니다.

이 단계 규칙: 아직 앱 얘기는 없습니다. "어르신들이 44번 버스를 40분씩 기다린다"까지만 적고, "버스 앱 만들자"로 건너뛰지 않습니다. 해결책으로 서두르지 않는 절제 — 발상에서 가장 어렵고, 우승작과 흔한 출품작을 가르는 지점입니다.

같은 소재라도, 문제 정의와 해결의 깊이가 중요

모은 문제 중 하나를 골라 누가·왜·무엇을 못 하는지 분명히 씁니다. 같은 소재라도 얼마나 구체적으로, 근본 원인까지 파고들었느냐에 따라 만들 수 있는 문제가 되기도, 손댈 수 없는 문장이 되기도 합니다.

증상 말고 원인 — '왜'를 다섯 번

증상에서 멈추지 않고 "왜?"를 반복해 진짜 원인까지 내려갑니다. 원인이 바뀌면 만들 앱도 달라집니다.

사실 확인, 세 가지로

확인된 문제 → 앱 컨셉

여기까지 오면 앱은 상상이 아니라 근거의 연결에서 나옵니다. 아래는 앞의 언어 접근성 문제가 앱으로 이어지는 예시. 왼쪽에서 오른쪽으로 읽습니다.

'이길 만한 아이디어'의 모양

후보마다 다섯 가지를 점수로 매겨, 한 축이라도 약하면 버리거나 고칩니다. 강한 아이디어는 다섯 축이 고르게 찬 모양. 근거로 걸러 내는 이 판단이 발상의 마지막 단계입니다.

앞의 한 달은 '생각하는 시간' — 계획된 순서

CIT는 주 1회 90분, 16회차(15주) 과정입니다. 아래 표의 붉은·노란 구간이 지금까지 설명한 조사와 발상, 앱을 짜는 초록 구간은 그 뒤에 옵니다. 10월 26일 마감에서 역산하면 한 기수는 7월 초에 시작해야 합니다.

초반 4주는 화면에 보이는 결과물이 적을 수 있습니다. 이 시기에 쌓은 지역 브리프와 문제 정의가 뒤 8주의 개발을 지탱합니다. 8주차 중간 점검에서 진도가 늦으면, 기능을 늘리는 대신 범위를 줄여 완성도를 지킵니다.

대회 결과와 별개로 남는 힘

이 발상 과정은 대회용 기술로 끝나지 않습니다. 문제를 데이터로 읽고, 사람을 관찰하고, 근거로 결정하는 훈련은 학교 과제와 이후 프로젝트에도 그대로 쓰입니다.

가정에서 크게 도우실 것은 없습니다. 아이가 "우리 동네에서 뭐가 제일 불편하세요?"라고 물으면 겪은 그대로 들려주시고, 주말에 동네를 함께 걸으며 이야기 나눠 주시면 충분합니다. 아이가 관찰한 문제 하나가 앱의 출발점이 됩니다.