📑 F2. 좋은 문제 고르기 — 목업 v4 (논증 + 설명 산문)

중학생 눈높이의 '앱 기획' 교안. 한 질문("어떤 문제가 앱이 될 만한가?")을 통념→주장→왜→판별→단서→반론→결론으로 끝까지 따라갑니다. 강사가 읽고 그대로 말할 수 있는 설명 산문 중심. 🎓 교실에서는 sprint Step2(페인킬러 4축 체크)로 이어집니다.

이 장이 던지는 질문
어떤 문제가 '앱이 될 만한' 좋은 문제인가?  →  주장: 좋은 앱은 '멋진 아이디어'가 아니라 '진통제 같은 진짜 문제'에서 나온다.
F
앱 기획 · 무엇을 만들 것인가
CHAPTER F2

좋은 문제 고르기

진통제 vs 비타민  ·  '꼭 필요한 문제'를 알아보는 눈
이 장은 단 하나의 질문에서 출발한다 — "어떤 문제가 앱이 될 만한 좋은 문제인가?" 우리는 흔히 '멋지고 신기한 아이디어'가 먼저라고 답하지만, 이 장은 그 답을 7단계로 뒤집는다(통념→주장→왜→판별→단서→반론→결론). 그리고 좋은 문제를 스스로 골라내는 법(4질문 체크)으로 장을 닫는다.
F2. 좋은 문제 고르기
01 / 13
F2 · 이 장의 지도
전체 구성 — 시작 전에 길을 펼친다

하나의 질문을, 일곱 단계로 답한다

이 장은 아이디어를 마구 나열한 게 아니라 한 질문을 끝까지 따라가는 하나의 논증이다. 본론에 들어가기 전, 우리가 지나갈 전체 길을 먼저 펼쳐 둔다. 윗줄은 '왜 진짜 문제가 먼저인가'를 논증하고, 아랫줄은 그 문제를 스스로 골라내는 도구(4질문·단서)로 잇는다.

왜 '진짜 문제'가 먼저인가 — 논증  (p3–p6)
① 통념
"멋진 아이디어 먼저!"
p3 · 아이디어 함정
② 주장
진짜 문제에서 시작
p4 · 진통제 vs 비타민
③ 왜
'꼭'이 사용을 만든다
p5 · 필요 vs 호감
④ 판별
4질문으로 가른다
p6 · 진통제 체크
그 문제를 골라내는 법  (p7–p11)  +  정리·출처
⑤ 단서
내 불편이 증거다
p7 · 직접 겪은 문제
⑥ 반론
크기·범위의 함정
p8 · 너무 크게/좁게
⑦ 결론
작고 구체적일수록
p9 · 좋은예/나쁜예
실습·정리
문제 카드 → 회수
p10 실습 · p11 회수 · p12·13 출처
→ 자, 출발먼저 가장 흔한 통념부터 깬다 — "좋은 앱은 정말 '멋진 아이디어'에서 시작될까?"
F2. 좋은 문제 고르기
02 / 13
F2 · 논증 1단계
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
통념 깨기

우리는 '번뜩이는 아이디어'부터 찾는다

"앱 만들자!"고 하면 학생들은 거의 곧장 신기하고 멋진 아이디어를 떠올리려 머리를 쥐어짠다. 아이디어가 먼저 떠오르고, 거기에 '이게 왜 필요한지'를 나중에 끼워 맞춘다. 그런데 바로 이 순서가 함정이다 — 멋져 보이지만 아무도 안 쓰는 앱은 대부분 여기서 태어난다.

🗣️ 교실에서 자주 나오는 말

  • "기분에 따라 색이 바뀌는 감성 앱 어때요?"
  • "세상에 없던 걸 만들어야 멋지죠."
  • "일단 멋진 거 정하고 쓸 사람은 나중에…"

💡 그런데 — '시트콤 아이디어'

그럴듯해 보여서 드라마 작가가 지어낼 법한 아이디어. 폴 그레이엄은 이를 '시트콤 스타트업 아이디어'라 불렀다 — 말로는 그럴듯한데 실제로 원하는 사람이 없는 아이디어. 신기함이 곧 좋은 아이디어는 아니다.

🔎 한 걸음 더 폴 그레이엄(Y Combinator 창업자)은 "스타트업이 가장 흔히 저지르는 실수는 아무도 갖지 않은 문제를 푸는 것"이라 했다. 또 "어떤 아이디어에 대해 아는 게 '그럴듯하다'는 것뿐이라면, 그건 나쁜 아이디어라고 봐야 한다"고 경고한다 — 신기함은 검증이 아니다.
→ 그래서'멋짐·신기함'은 좋은 문제의 기준이 될 수 없다. 우리는 질문을 바꿔야 한다 — 그럼 무엇이 '앱이 될 만한' 좋은 문제를 만드는가?
F2. 좋은 문제 고르기
03 / 13
F2 · 논증 2단계
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
이 장의 주장

좋은 앱은 진통제 같은 진짜 문제에서 나온다

이 장이 증명하려는 한 문장은 이것이다 — 아이디어가 아니라 '진짜 문제'가 먼저다. 문제에는 두 종류가 있다. 진통제는 아프면 '꼭' 먹어야 하는 것, 비타민은 '있으면 좋고 없어도 그만'인 것. 좋은 앱 아이디어는 언제나 진통제 쪽이다. 사람들이 진짜 불편해서 '꼭' 풀고 싶어 하는 문제일수록, 그 앱을 계속 쓴다.

💊 진통제 — 꼭 필요한 문제

지금 당장 아파서 '꼭' 해결해야 하는 불편. 사람들이 이미 "아 진짜 귀찮아", "누가 좀 해 줬으면" 하고 불평하고 있는 문제. 한 번 쓰면 계속 쓴다.

🍬 비타민 — 있으면 좋은 문제

없어도 살 수 있는 '있으면 좋겠다' 정도의 것. 멋져 보여도 한두 번 써 보고 지워지기 쉽다. "있으면 좋을 것 같아요"는 위험 신호다.

🔎 한 걸음 더 '진통제 vs 비타민'은 실리콘밸리 투자자들이 아이디어를 평가할 때 쓰는 유명한 틀이다(벤처 투자자 마크 앤드리슨이 널리 퍼뜨림). 핵심은 '있으면 좋은 것(nice-to-have)'이 아니라 '꼭 있어야 하는 것(must-have)'을 만들라는 것 — 사람은 진통제엔 기꺼이 돈·시간을 쓰지만, 비타민은 쉽게 건너뛴다.
→ 그래서좋은 기획은 "무엇을 만들까"가 아니라 "어떤 진짜 불편을 풀까"에서 시작한다. 그런데 *왜* 진통제여야만 앱이 살아남는가?
F2. 좋은 문제 고르기
04 / 13
F2 · 논증 3단계 · 근거: 폴 그레이엄
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
메커니즘 — 왜 '꼭'이 중요한가

'있으면 좋고'는 손이 안 가고, '꼭 필요해'는 매일 켠다

진통제가 살아남는 이유는 단순하다. '꼭 필요한' 문제는 사람이 그 불편을 매일·매주 다시 겪기 때문에, 앱을 자꾸 열게 된다. 반대로 '있으면 좋겠다' 정도면 잠깐 신기해서 깔았다가, 불편을 다시 안 겪으니 그냥 잊혀진다. 앱의 운명은 '얼마나 멋진가'가 아니라 '얼마나 자주, 꼭 필요한가'에서 갈린다.

💊 필요(need)가 앱을 다시 켜게 한다

매일 급식 메뉴를 확인해야 하면, 그 앱을 매일 연다. 동아리 회비를 매주 정산해야 하면, 매주 연다. 불편이 반복되니 앱도 반복해서 쓰인다.

🍬 호감(like)은 한 번 쓰면 끝난다

"오 신기하다" 하고 한 번 눌러 본 뒤엔 다시 열 이유가 없다. 좋아하긴 했지만 '꼭' 필요하진 않으니, 며칠 뒤 화면에서 사라진다.

🔎 한 걸음 더 폴 그레이엄은 좋은 아이디어를 '깊은 우물(well)'에 비유했다 — 많은 사람이 살짝 원하는 것보다 적은 사람이 간절히 원하는 것이 낫다. 간절함(=진통제)이 있어야 입소문이 나고, 거기서부터 사용자가 넓어진다. 넓고 얕은 호감(비타민)에서는 그 시작점이 생기지 않는다.
🎓 교실에서 "최근에 깔았다가 며칠 만에 지운 앱"을 떠올리게 하고, "왜 지웠어?"를 물어보라. 대부분 "딱히 다시 쓸 일이 없어서"가 나온다 — 그게 바로 비타민의 증상이다.
→ 그래서관건은 '꼭 필요한가'를 판단하는 것이다. 그런데 그걸 느낌이 아니라 기준으로 어떻게 가려내는가?
F2. 좋은 문제 고르기
05 / 13
F2 · 논증 4단계 · 진통제 판별
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
핵심 도구 — 진통제 4질문

진통제인지, 네 칸을 채워 보면 안다

'진통제 같다'는 느낌만으로는 부족하다. 그래서 우리는 문제를 네 가지 질문에 통과시킨다. 네 칸이 전부 채워지면 진통제일 확률이 높고, 한 칸이라도 비면 비타민을 의심해야 한다. 이건 막연한 직감을 구체적 진단으로 바꿔 주는, 디자이너·기획자의 사고법이다.

질문 ①
자주 반복되는 불편인가?
매일? 가끔? — 자주 겪을수록 앱을 자주 연다.
질문 ②
누가, 얼마나 많이 겪는가?
나만? 우리 반? 우리 학교 전체? — 사용자 수.
질문 ③
지금은 어떻게 해결하나?
현재 방법이 있어야 '대체할 거리'가 보인다.
질문 ④
그 방법의 한계는 무엇인가?
불편·느림·실수… 한계가 곧 앱이 들어설 틈.
🔎 예시로 채워 보기 "급식 메뉴를 매번 학교 홈페이지에서 찾기 귀찮다" → ①전교생이 매일 겪고(자주) ②여러 명(전교생) ③지금은 홈페이지를 뒤짐(현재 방법) ④느리고 번거롭다(한계). 네 칸이 전부 채워진다 = 진통제.
🎓 교실에서 학생 아이디어를 칠판 두 칸(진통제 / 비타민)에 나눠 붙이는 분류 게임. "방과후 셔틀 도착 시간 앱"은 진통제, "내 기분에 맞는 색 추천 앱"은 비타민 쪽으로 자연스레 갈린다. 학생이 "왜 이건 비타민이죠?"라고 따지기 시작하면 성공이다.
→ 그래서이제 문제를 가를 자가 생겼다. 그런데 좋은 문제는 어디서 찾아오는가? — 가장 믿을 만한 사냥터가 따로 있다.
F2. 좋은 문제 고르기
06 / 13
F2 · 논증 5단계 · 근거: 폴 그레이엄
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
단서 — 가장 좋은 문제는 가까이 있다

남의 불편은 추측이고, 내 불편은 증거다

좋은 문제를 멀리서 찾을 필요가 없다. 내가 직접 겪는 불편이 가장 강한 단서다. 남이 불편할 것 같다는 건 내 추측이지만, 내가 실제로 겪은 불편은 증거다. "PT 끝나고 준비물 까먹음", "동아리 회비 누가 냈는지 헷갈림"처럼 구체적일수록 좋다 — 막연한 큰 문제보다 손에 잡히는 작은 불편이 기획하기 쉽다.

"스타트업 아이디어에 어울리는 동사는 '생각해 내다(think up)'가 아니라 '알아채다(notice)'이다. 좋은 아이디어는 자기가 겪은 진짜 문제에서 자연스럽게 자란다."— 폴 그레이엄, 「How to Get Startup Ideas」 (Y Combinator)

✅ 내가 겪은 구체적 불편 (증거)

  • "동아리 회비 누가 냈는지 매주 헷갈려"
  • "준비물을 자주 깜빡해서 혼나"
  • "버스가 언제 오는지 몰라 오래 기다려"

🤔 막연히 추측한 불편 (가설)

"사람들이 ~하면 불편하지 않을까?" — 직접 안 겪었으니 진짜인지 알 수 없다. 추측에서 출발하면 비타민이 되기 쉽다. 꼭 추측에서 시작해야 한다면, 그 사람에게 직접 물어 증거로 바꿔라.

🔎 한 걸음 더 그레이엄은 좋은 아이디어를 '억지로 짜내는 것'이 아니라 '미래에 살며 빠진 것을 알아채는 것'이라 했다. 거창한 발명이 아니라, 내 일상에서 매번 걸리는 그 작은 지점이 출발점이다.
→ 그런데여기서 흔한 반론이 나온다. "그럼 문제는 크면 클수록 좋은 거 아닌가요? 학교 전체를 바꾸는 앱처럼!"
F2. 좋은 문제 고르기
07 / 13
F2 · 논증 6단계 · 반론 처리
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
반론 처리 — "문제는 클수록 좋지 않나?"

너무 크면 손도 못 대고, 너무 좁으면 쓸 사람이 없다

"이왕이면 큰 문제!"라는 반론은 오해다. 문제 크기에는 두 방향의 함정이 있다. 너무 크면 한 문장으로 정의되지 않아 무엇부터 만들지 못 정하고, 너무 좁으면(나만 겪는 특이한 불편) 쓸 사람이 없다. 좋은 문제는 그 사이, "나도 겪고 옆 친구도 고개를 끄덕이는" 딱 그만큼이다.

🔭 너무 큰 문제 정의 불가

"학교를 더 좋게", "전교생 모든 고민 해결" — 한 문장으로 못 쓴다. 무엇부터 만들지 안 잡힌다.

쪼개기: '점심시간 매점 줄이 김'처럼 한 장면으로.

🔬 너무 좁은 문제 사용자 없음

"나만 쓰는 특수 글씨체 키보드" — 나 말곤 겪는 사람이 없다. 아무리 진짜 불편이어도 혼자면 앱이 아니다.

넓히기: 옆 친구도 끄덕이는지 확인.

🔎 한 걸음 더 — 한 문장 테스트 문제를 "누가 + 언제 + 무엇이 불편하다" 한 문장으로 못 쓰면, 아직 너무 큰 문제다. 이건 디자인 씽킹의 문제 정의문(Problem Statement)과 같은 방식 — "[사용자]는 [무엇]이 필요하다, 왜냐하면 [이유] 때문에." 한 문장으로 적히는 순간, 만들 것이 보인다.
→ 따라서반론은 틀렸다. 문제는 큰 게 아니라 '알맞은 크기'가 좋다. 그럼 그 알맞은 크기란 정확히 무엇인가?
F2. 좋은 문제 고르기
08 / 13
F2 · 논증 7단계 · 결론
① 통념② 주장③ 왜④ 판별⑤ 단서⑥ 반론⑦ 결론
결론 — 좋은 문제는 작고 구체적이다

"있으면 좋겠다"는 위험 신호, "진짜 귀찮아"는 좋은 신호

지금까지의 논증을 한 장면으로 정리하면 이렇다 — 좋은 문제는 작고 구체적이며, 여러 명이 자주 겪고, 지금 방식이 불편한 문제다. 그리고 그 신호는 사람들의 말투에서 들린다. "있으면 좋겠다"가 들리면 비타민을 의심하고, "아 진짜 귀찮아"가 들리면 진통제일 확률이 높다.

판단예시왜 그런가 (4질문 기준)
✅ 좋은 예급식 메뉴를 매번 홈페이지에서 찾기 귀찮다전교생이·매일·홈페이지를 뒤지며·느리다 — 4칸 다 참
✅ 좋은 예동아리 회비 누가 냈는지 헷갈림총무가 매주 겪는 진짜 진통제, 한 문장으로 적힘
❌ 나쁜 예기분에 따라 화면 색이 바뀌는 감성 앱'꼭' 필요한 사람 없음 → 한 번 쓰고 지움 (비타민)
❌ 나쁜 예전교생의 모든 고민을 해결하는 앱너무 커서 한 문장 정의 불가 → 뭘 만들지 못 정함
🔎 O/X 퀴즈 "멋지고 새로운 아이디어일수록 좋은 앱 아이디어다." → 정답: X. 새로움보다 '진짜 불편(진통제)'인지가 핵심이다. 멋지기만 한 아이디어(비타민)는 아무도 꾸준히 쓰지 않는다.
🎯 그래서 당신은 문제를 고를 때 이렇게 물어라 — "자주? 여러 명? 지금 방법? 그 한계?" 네 칸이 채워지고 한 문장으로 적히면 그게 좋은 문제다.
F2. 좋은 문제 고르기
09 / 13
F2 · 직접 해보기
관찰을 자산으로 — 문제 카드 만들기

포스트잇 3장에서, 문제 카드 1장으로

배운 걸 바로 손으로 옮긴다. 핵심은 머릿속 아이디어가 아니라 내가 진짜 겪은 불편에서 출발하는 것이다. 포스트잇 3장에 불편을 적고, 각각을 4질문에 통과시킨 뒤, 네 칸이 가장 잘 채워지는 1개를 골라 문제 카드로 남긴다. 이 카드 한 장이 다음 차시 페르소나의 출발점이 된다.

📝 5~10분 실습 순서

  • ① 포스트잇 3장에 '내가 최근 겪은 진짜 불편' 3개
  • ② 각 불편 옆에 진통제 4질문 답을 적기
  • ③ 4칸이 가장 잘 채워지는 1개 고르기
  • ④ 그 1개를 '문제 카드' 한 장으로 정리

🗂️ 문제 카드 (채울 칸)

  • 한 문장: 누가·언제·무엇이 불편한가
  • 자주?: 매일 / 주 N회 / 가끔
  • 여러 명?: 나·우리 반·우리 학교
  • 지금 방법 & 한계: 지금은 ___, 그런데 ___
🎓 교실에서 — sprint 연계 이 문제 카드를 들고 sprint의 Step 2 '진짜 진통제 1개 정하기'로 넘어간다. 거기서 페인킬러 4축 체크(빈도·대상·기존 방식·한계)를 누르면, 4축을 모두 만족할 때만 "진통제 판별됨"이 뜨고 발표 문장이 자동 완성돼 Step 3로 넘어간다 — F2의 4질문이 그대로 화면 도구가 된 것이다.
🎯 그래서 당신은 아이디어를 떠올리기 전에 '내가 겪은 불편'부터 적는다. 검증된 문제 1개가 멋진 아이디어 10개보다 낫다.
F2. 좋은 문제 고르기
10 / 13
F2 · 정리
F2가 증명한 것 — 한 줄의 논증

멋진 아이디어에서 출발해, '진짜 문제'에 도착했다

이 장은 아이디어를 나열한 게 아니라, 하나의 질문을 끝까지 따라간 추론이었다. 출발점은 "멋진 아이디어가 먼저"라는 통념이었고, 도착점은 "진통제 같은 진짜 문제가 먼저"라는 주장이었다. 그 사이를 진통제 비유·4질문·내 불편이라는 단서가 이어 주었다.

통념멋지고 신기한 아이디어부터 찾는다 ('시트콤 아이디어')
↓ 그런데
주장좋은 앱은 진통제 같은 진짜 문제에서 나온다 — 문제가 먼저, 아이디어는 그 다음
↓ 왜냐면
'꼭 필요'는 매일 다시 켜게 하고, '있으면 좋고'는 한 번 쓰고 지워지니까
↓ 그래서 가른다
판별4질문(자주? 여러 명? 지금 방법? 한계?)을 다 채우면 진통제
↓ 어디서 찾나
단서내가 직접 겪은 구체적 불편이 가장 강한 증거(남의 불편은 추측)
↓ 단, 크기는
결론작고 구체적일수록 좋다 — 한 문장으로 적히고, 옆 친구도 끄덕이는 만큼
🎯 한 문장 요약 좋은 앱은 멋진 아이디어가 아니라 '자주·여러 명이 겪고 한 문장으로 적히는 진짜 불편'에서 나온다 — "있으면 좋겠다"는 위험 신호, "진짜 귀찮아"는 좋은 신호.
F2. 좋은 문제 고르기
11 / 13
더 읽을거리 · 검증된 1차 자료

근거가 된 자료 & 다음 단계

  • 폴 그레이엄, 「How to Get Startup Ideas」(Y Combinator) — '진짜 문제는 think up 아닌 notice', '시트콤 아이디어', '그럴듯함=나쁜 신호', '깊은 우물' · ①③⑤단계 근거
  • 진통제 vs 비타민 — 스타트업 아이디어 평가 틀(마크 앤드리슨이 대중화). must-have vs nice-to-have · ② 주장 근거
  • Interaction Design Foundation, Problem Statements — "[사용자]는 [무엇]이 필요하다, 왜냐하면 [이유]"(POV), 디자인 씽킹 Define 단계 · ⑥ 한 문장 테스트 근거
  • Google Design Sprint, Understand 단계 — 해결책보다 '문제·사용자'를 먼저 이해 · '문제 먼저' 원칙 근거
다음 단계 — sprint Step 2 · F2에서 만든 문제 카드를 들고 '진짜 진통제 1개 정하기'로 간다: 페인킬러 4축 체크(빈도·대상·기존 방식·한계) → 진통제 판별 → 발표 문장 자동 완성 → Step 3(페르소나).
F2. 좋은 문제 고르기
12 / 13
F2 · 한 장으로 기억하기

💊 진통제 4질문, 한 장 요약

좋은 문제는 멋진 아이디어가 아니라 '꼭 필요한 진짜 불편'이다. 아래 네 칸이 다 채워지고 한 문장으로 적히면 — 그게 앱이 될 만한 문제다.
  • ① 자주?  매일·매주 반복되는 불편인가 — 자주 겪을수록 앱을 자주 연다
  • ② 여러 명?  나만? 우리 반? 우리 학교? — 옆 친구도 고개를 끄덕이는가
  • ③ 지금 방법?  사람들은 지금 이 불편을 어떻게 버티고 있나
  • ④ 그 한계?  그 방법이 느리거나·번거롭거나·실수가 나는 지점 = 앱이 들어설 틈
기억할 신호 — "있으면 좋겠다" 🍬는 위험 신호(비타민), "아 진짜 귀찮아" 💊는 좋은 신호(진통제).
F2. 좋은 문제 고르기
13 / 13