중학생 눈높이의 '앱 기획' 교안입니다. 코딩이 아니라 무엇을·누구를·어떻게 만들지 정하는 기획력을 다룹니다. 슬라이드마다 강사가 읽고 그대로 말할 수 있는 설명 산문을 넣었고, 텍스트가 잘리지 않도록 높이는 가변(최소 16:9)으로 두었습니다.
이 장은 앱에 관한 지식을 늘어놓은 게 아니라 한 질문을 끝까지 따라가는 하나의 논증이다. 본론에 들어가기 전, 우리가 지나갈 전체 길을 먼저 펼쳐 둔다. 윗줄(F1-가)은 '앱이란 무엇인가'를 6단계로 논증하고, 아랫줄(F1-나)은 그렇게 정의한 '문제 푸는 도구'를 실제로 어떻게 찾아 기획하는지의 방법으로 잇는다.
학생들에게 "어떤 앱이 좋은 앱이냐"고 물으면 거의 "기능이 많은 앱", "AI가 들어간 멋진 앱"이라고 답한다. 앱을 일종의 '기술 자랑'으로 여기는 것이다. "AI가 들어가니까 멋질 것 같아서" 기능부터 정하는 출발 — 이 통념을 깨는 데서 앱 기획 수업이 시작된다.
급식도 보고, 시간표도 보고, 게임도 하고, 채팅도 되는 앱. 기능이 가장 많은데도 첫 화면부터 복잡해 "그래서 이거 뭐 하는 앱이야?"라는 말을 듣는다. 기능 수는 좋은 앱의 증거가 아니다.
이 강의가 증명하려는 한 문장은 이것이다 — 앱은 화려한 기술이 아니라, 누군가의 '불편'을 풀어 주는 도구다. 앱은 자판기와 같다. 동전을 넣으면(입력) 원하는 음료가 나오듯(결과), 앱은 '불편'을 넣으면 '해결'을 내준다. 그래서 모든 앱 뒤에는 반드시 '풀려는 문제'가 하나 숨어 있다.
불편(입력)을 넣으면 해결(결과)이 나온다. 우리가 보는 화려한 화면은 자판기의 '겉모습'일 뿐, 진짜 핵심은 "무슨 불편을 풀어 주는가"이다.
앱이 문제 푸는 도구라면, '잘 푼다'는 건 무슨 뜻일까? 답은 '한 가지 문제를 확실히'다. 자판기에 버튼이 100개라면 음료 고르기가 오히려 힘들 듯, 앱도 핵심 버튼이 많을수록 사용자는 "뭘 눌러야 하지?"부터 헷갈린다. 그래서 잘 만든 앱은 처음엔 핵심 버튼 1~2개로 시작한다.
'배달의민족'은 "배고픈데 나가기 귀찮고, 어디서 시킬지 모른다"는 한 불편을 '주문 한 번'으로 푼다. '알람' 앱도 "아침에 못 일어난다"는 단 하나만 푼다 — 그래서 누구나 쓸 줄 안다.
풀려는 문제가 너무 많으면 첫 화면이 복잡해진다. 사용자는 도구를 쓰기도 전에 '선택'에 지친다. 기능이 늘수록 '쉬움'은 줄어드는 게 도구의 기본 성질이다.
앱 기획이 무너지는 순간은 막연하지 않다. 정확히 한 지점에서 갈린다 — '문제'가 아니라 '기술'에서 출발했는가. "AI가 들어가니까 멋질 것 같아서" 기능부터 정하면, 그 앱은 "누구의 무슨 문제를 푸는지"라는 가장 중요한 답이 비어 있다. 다 만든 뒤에야 "그래서 이건 뭐 하는 앱이야?"로 처음으로 돌아간다.
풀려는 문제 없이 기능부터 쌓는다. "AI도 되고, 채팅도 되고, 게임도 되는 앱" — 문제가 없으니 화면이 복잡해지고, 누구도 끝까지 쓰지 않는다.
→ "누구의 무슨 문제?"를 먼저 정해 막는다.
설계도 없이 집부터 짓는 격이다. 다 만든 뒤 "이게 누구 거지?"를 묻게 되면, 결국 처음으로 되돌아가 다시 만든다.
→ 기획을 코딩보다 먼저 둬서 막는다.
여기서 핵심이 드러난다. 문제를 하나 정해도 끝이 아니다 — 같은 문제라도 푸는 방법은 여러 가지이고, 그중 '내 사용자에게 가장 편한 방식'을 고르는 선택이 바로 기획이다. 예를 들어 '급식 메뉴 확인'이라는 한 문제도, 푸는 길은 셋이나 된다.
매일 등교 전, 오늘 급식을 먼저 띄워 준다. "찾을 필요 없이 먼저 알려 줘"인 사람에게 편하다.
날짜·메뉴를 직접 찾아 본다. "내가 원할 때만 본다"는 사람에게 맞다.
식단표를 찍으면 자동으로 정리. "타이핑이 귀찮다"는 사람에게 좋다.
지금까지의 논증이 한 결론으로 모인다. 예전엔 아이디어가 있어도 코딩이라는 높은 벽에 막혔다. 그런데 AI 덕분에, 코딩을 깊이 몰라도 아이디어를 앱으로 빠르게 만들 수 있는 시대가 됐다. 만드는 일이 쉬워진 만큼, 승부는 "무엇을 만들지 정하는 기획력"으로 옮겨 간다. 누구나 만들 수 있을 때, 차이를 내는 건 '무엇을 만드느냐'이다.
| 단계 | 예전 | AI 시대 (지금) |
|---|---|---|
| 아이디어 | 누구나 가질 수 있음 | 여전히 누구나 — 단, 더 중요해짐 |
| 기획 | 무엇을·누구를·어떻게 정하기 | 여기서 승부가 갈린다 |
| 만들기 | 코딩 = 높은 벽 🧱 | AI로 빠르게 — 벽이 낮아짐 |
F1-가는 "앱은 문제 푸는 도구"로 끝났다. 그런데 곧장 막히는 질문이 있다 — "그럼 그 문제를 어디서 찾지?" 책상에 앉아 머리로 짜내면 대개 '나만의 문제'가 나온다. 그래서 디자인 분야는 '사람을 관찰하는 데서' 문제를 찾는 방법을 만들었다. 이것이 디자인 씽킹(Design Thinking) — IDEO와 스탠퍼드 d.school이 다듬어 세상에 알린, '문제에서 출발하는' 5단계다.
사람을 관찰해 불편을 본다
문제를 한 문장으로
푸는 법 여러 개
대충 만들어 본다
써 보게 하고 고친다
하버드 경영학자 클레이튼 크리스텐슨은 이런 통찰을 남겼다 — 사람들은 제품을 '고용(hire)'해서 어떤 '할 일(Job)'을 시킨다. 잘하면 다시 고용하고, 못하면 '해고(fire)'하고 다른 걸 찾는다. 즉 사용자가 진짜로 사는 건 제품이 아니라 "그 제품이 대신 해 주는 일"이다. 이걸 보여 준 유명한 밀크셰이크 사례가 있다.
연구팀이 매장에서 18시간을 관찰했더니, 밀크셰이크 절반이 아침 8시 반 전에 팔렸고, 손님들은 혼자 차를 몰며 그것만 샀다. 진짜 '할 일'은 지루한 출근길을 견디고, 점심까지 배고픔을 달래는 것이었다. 그래서 맥도날드는 맛이 아니라 '더 걸쭉하게(오래 가게)·과일 조각(심심하지 않게)'으로 개선했다.
관찰로 '할 일'을 찾았다면, 마지막은 그것을 한 문장으로 못 박는 일이다. 머릿속에만 있는 흐릿한 아이디어는 다음으로 넘어갈 수 없다. 그래서 디자인 씽킹의 '정의' 단계처럼, 기획은 "누구의 / 어떤 불편을 / 어떻게 푼다"를 한 줄로 적는다 — 적히지 않은 기획은 그대로 증발한다.
"학교 앱 하나 만들고 싶어."
누구를·무슨 불편을·어떻게 푸는지가 비어 있어 다음으로 못 간다.
바쁜 우리 반 친구가 아침에 급식을 까먹는 불편을, 등교 전 알림 한 줄로 풀어 준다.
이 장은 앱에 관한 지식을 모은 게 아니라, 하나의 질문을 끝까지 따라간 추론이었다. 출발점은 "앱=화려한 기술"이라는 통념이었고, 도착점은 "앱은 문제 푸는 도구이고, 그래서 만들기 전에 기획부터 한다"는 주장이었다. 그 사이를 자판기 비유·디자인 씽킹·크리스텐슨(JTBD)이 각자의 역할로 이어 주었다.