📑 F4. 화면 설계 — 목업 v4 (논증 + 설명 산문)

F. 앱 기획 챕터의 「화면 설계」 편. 논증형 교안 포맷(인디고)으로, 슬라이드마다 강사가 읽고 그대로 말할 수 있는 설명 산문을 넣었습니다. 화면 3개 흐름은 흑백 와이어프레임 목업 + 화살표로 직접 보여 줍니다. 텍스트가 잘리지 않도록 슬라이드 높이는 가변(최소 16:9)으로 두었습니다.

이 장이 던지는 질문
앱을 만들기 전에 우리는 무엇을 그려야 하는가?  →  주장: 색·꾸밈을 뺀 '뼈대(와이어프레임)'와 화면을 잇는 '흐름(화살표)'을 먼저 그린다 — 예쁨은 맨 나중이다.
F4
F. 앱 기획 · 만들기 전에 그리는 설계도
CHAPTER F4

화면 설계

와이어프레임 · UX 흐름  ·  색·꾸밈을 빼고 '구조와 흐름'을 먼저
이 장은 단 하나의 질문에서 출발한다 — "앱을 만들기 전에 우리는 무엇을 그려야 하는가?" 우리는 흔히 '처음부터 예쁘게 그려야 한다'고 생각하지만, 이 장은 그 답을 단계별로 뒤집는다(통념→주장→왜→화면 3개→흐름→반론→결론). 그리고 종이 한 장으로 직접 그려 보는 법(🎓 sprint Step4 연계)으로 장을 닫는다.
F4. 화면 설계
01 / 11
F4 · 이 장의 지도
전체 구성 — 시작 전에 길을 펼친다

하나의 질문을, 한 줄의 추론으로 답한다

이 장은 와이어프레임·흐름 이론을 나열한 게 아니라 "만들기 전에 무엇을 그리나"라는 한 질문을 끝까지 따라가는 하나의 논증이다. 본론에 들어가기 전, 우리가 지나갈 전체 길을 먼저 펼쳐 둔다. 통념(예쁘게부터)을 깨고 → 흑백 뼈대를 주장하고 → 왜 그게 싼지(설계도 비유) → 화면 3개로 핵심을 잡고 → 화면을 화살표로 잇고 → "그래도 예쁨은?" 반론에 답한 뒤 → 결론으로 닫는다.

F4 · 만들기 전에 무엇을 그리나 — 논증 사슬  (p3–p9)
① 통념
"처음부터 예쁘게?"
p3 · 순서 거꾸로
② 주장
흑백 뼈대 먼저
p4 · 와이어프레임
③ 왜
종이에서 고치는 게 싸다
p5 · 설계도 비유
④ 핵심
화면 3개면 보인다
p6 · 첫·핵심·결과
⑤ 흐름
화면을 화살표로 잇기
p7 · UX 흐름·뒤로
⑥ 반론
"예쁨도 중요하잖아?"
p8 · 충실도(fidelity)
⑦ 결론
그림이 말보다 정확
p9 · 개발자·AI
정리
한 줄로 회수 + 출처
p10 / p11
→ 자, 출발먼저 가장 흔한 통념부터 깬다 — "앱 그림은 정말 예쁜 것부터 그려야 할까?"
F4. 화면 설계
02 / 11
F4 · 논증 1단계
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
통념 깨기

우리는 '예쁜 화면'부터 그리려 한다

앱을 그려 보자고 하면 학생들은 거의 예외 없이 색을 고르고 아이콘을 찾고 글꼴을 바꾸는 일부터 시작한다. 머릿속의 '멋진 앱 화면' 이미지를 그대로 베끼려는 것이다. 그런데 이건 순서가 거꾸로다 — 어디에 무엇이 있고 버튼을 누르면 어디로 가는지(구조·흐름)가 아직 정해지지도 않았는데 색칠부터 하는 셈이기 때문이다.

🗣️ 그릴 때 자주 나오는 말

  • "배경색은 무슨 색으로 할까?"
  • "이 버튼 아이콘 예쁜 거 없나?"
  • "글꼴부터 멋있게 바꿔야지."

🌀 그런데 — 색칠부터 한 대가

한 화면을 예쁘게 칠한 뒤에야 "어? 결과 화면을 빼먹었네", "여기서 뒤로 갈 길이 없네"를 깨닫는다. 그러면 예쁘게 칠한 걸 다시 지우고 처음부터 손봐야 한다 — 꾸미기에 쓴 시간이 통째로 날아간다.

🔎 한 걸음 더 디자이너들은 이 흑백 뼈대 단계를 '낮은 충실도(low-fidelity)'라 부른다. 발사믹(Balsamiq)의 설명처럼, 색을 빼는 건 못 칠해서가 아니라 '시각적 방해(distraction)'를 일부러 줄여 구조와 정보 위계에만 집중하기 위해서다. (출처: Balsamiq, What Are Wireframes?)
→ 그래서'예쁨'은 화면 설계의 출발점이 될 수 없다. 그럼 무엇부터 그려야 할까? — 색·꾸밈을 다 뺀 '뼈대'부터다.
F4. 화면 설계
03 / 11
F4 · 논증 2단계 · 근거: 와이어프레임
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
이 장의 주장

먼저 그릴 것은 색이 아니라 '뼈대'

이 강의가 증명하려는 한 문장은 이것이다 — 앱은 만들기 전에 '와이어프레임(흑백 뼈대)'부터 그린다. 와이어프레임은 색·그림·꾸밈을 다 빼고, "어디에 무엇이 있고, 버튼을 누르면 어느 화면으로 가는가"만 네모와 글씨로 표시한 흑백 스케치다. 손으로 네모를 그려도 충분하다. 중요한 건 예쁨이 아니라 구조와 흐름이다.

🎨 시안(예쁜 화면) — 나중 일

색·아이콘·글꼴·이미지가 다 들어간 완성에 가까운 그림. 보기엔 그럴듯하지만 고치기가 무겁다 — 한 곳을 바꾸면 색·정렬·여백을 다시 맞춰야 한다. (= 높은 충실도)

🦴 와이어프레임 — 지금 할 일

네모 + 글씨만. 어디에·무엇이·어디로만 표시한다. 1분이면 한 화면을 그리고, 틀리면 지우고 다시 그리면 된다. (= 낮은 충실도, low-fidelity)

🔎 한 걸음 더 발사믹은 와이어프레임을 "디지털 프로젝트의 골격(skeleton)"이라 부른다. 골격은 살(색·이미지)을 입히기 전의 뼈대 — 즉 와이어프레임은 '덜 그린 그림'이 아니라 '먼저 그려야 하는 그림'이다. (출처: Balsamiq · Figma, What is Wireframing?)
→ 그래서그런데 왜 굳이 흑백 뼈대부터 그려야 할까? 그냥 처음부터 예쁘게 그리면 안 되는 걸까? — 이유는 '고치는 비용'에 있다.
F4. 화면 설계
04 / 11
F4 · 논증 3단계 · 메커니즘
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
메커니즘 — 왜 뼈대가 먼저인가

종이에서 고치는 게, 다 지은 집을 고치는 것보다 싸다

건물을 떠올려 보자. 설계도 단계에서 벽 위치를 바꾸는 건 지우개로 선 하나 지우면 끝이다. 하지만 다 지은 집의 벽을 옮기려면 부수고 다시 쌓아야 한다 — 시간도 돈도 몇 배다. 앱도 똑같다. 그리기 단계에서 화면을 고치는 게 가장 싸고 빠르다. 와이어프레임이 일부러 흑백·네모로 '대충' 생긴 이유가 여기 있다 — 버리기 쉬워야 마음 편히 고친다.

🏗️ 설계도(=와이어프레임)에서 고치기

  • 선 하나 지우고 다시 → 1분
  • "결과 화면을 빼먹었네" → 네모 하나 추가
  • 버려도 안 아깝다 (들인 게 적으니까)

🧱 다 지은 집(=완성 앱)에서 고치기

  • 코드·디자인 다 바꿔야 → 며칠
  • "이미 예쁘게 칠했는데…" → 못 버린다
  • 들인 게 많을수록 고치기 싫어진다
🔎 한 걸음 더 발사믹은 와이어프레임이 "아이디어가 충분히 익기 전에 너무 많이 투자하지 않게(don't invest too much before the idea is fully baked)" 막아 주고, 그래서 "값비싼 수정·코드 재작성을 예방한다"고 말한다. 일찍 틀리고 싸게 고치는 것 — 그게 뼈대 단계의 핵심이다. (출처: Balsamiq)
→ 그래서고치기 쉬운 뼈대부터 그린다는 건 알겠다. 그런데 화면이 수십 개라면? 다 그려야 하나? — 아니다. 핵심은 딱 3개면 보인다.
F4. 화면 설계
05 / 11
F4 · 논증 4단계 · 핵심
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
핵심 규칙 — 화면 3개면 앱이 보인다

'첫 화면 · 핵심 화면 · 결과 화면', 이 셋부터다

화면을 처음부터 다 그릴 필요는 없다. 어떤 앱이든 딱 세 화면이면 핵심이 드러난다 — 앱을 열면 보이는 ①첫 화면, 주된 일을 하는 ②핵심 기능 화면, 끝나면 나오는 ③결과 화면. 아래는 '오늘 급식 확인 앱'을 흑백 뼈대로만 그린 예다. 색도 아이콘도 없이 네모와 글씨뿐인데도 앱이 무엇을 하는지 한눈에 보인다. 그리고 화면마다 버튼은 1~2개로 시작한다 — 화면마다 "여기서 할 가장 중요한 한 가지"를 정하면 사용자가 헤매지 않는다.

① 첫 화면
6월 23일 (월)
로고 / 앱 이름
오늘 급식 보기
누르면
② 핵심 기능 화면
← 뒤로
오늘의 급식
급식 없는 날
③ 결과 화면
← 뒤로
오늘은
급식이 없어요
🎓 교실에서 A4 한 장을 세 칸으로 접게 한 뒤, 각 칸에 '첫 화면 / 핵심 기능 화면 / 결과 화면'을 네모와 글씨만으로 그리게 한다. "예쁘게 그리지 마세요, 네모랑 글씨만!"이라고 강조하면 미술 부담이 사라지고 구조에 집중한다.
→ 그래서화면 3개를 그렸다. 그런데 이 화면들은 따로 떨어진 그림이 아니다 — 버튼을 누르면 다음 화면으로 '이동'한다. 그 이동을 어떻게 그릴까?
F4. 화면 설계
06 / 11
F4 · 논증 5단계 · 근거: Wireflow (NN/g)
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
화면 사이의 이동 = UX 흐름

화면과 화면 '사이'에 길을 그린다 — 돌아갈 길까지

화면 하나하나도 중요하지만, 진짜 앱 경험은 화면과 화면 '사이'에서 일어난다. "버튼을 누르면 → 다음 화면"을 화살표로 잇는 것 — 이것이 UX 흐름이다. 그리고 반드시 '돌아갈 길(뒤로 가기)'도 함께 그려야 한다. 들어갔는데 나올 길이 없으면 사용자는 그 화면에 갇힌다.

➡️ 앞으로 가는 길 (화살표)

각 버튼 옆에 "누르면 가는 화면"을 화살표로 잇는다. 첫 화면의 [오늘 급식 보기] → 급식 화면, 급식 없는 날 → 결과 화면처럼.

⬅️ 돌아오는 길 (뒤로 가기)

들어간 화면마다 ← 뒤로를 둔다. 결과 화면에서 첫 화면으로 못 돌아오면 사용자는 앱을 끄는 수밖에 없다 — 흐름의 가장 흔한 구멍이다.

🔎 한 걸음 더 · 와이어플로우(Wireflow) 닐슨 노먼 그룹(NN/g)은 와이어프레임에 흐름을 결합한 것을 '와이어플로우(wireflow)'라 부른다 — "화면 디자인(wireframe) + 화면 사이 이동을 표현하는 단순한 흐름도(flowchart)를 합친 설계 형식"이다. 추상적 기호 대신 화면 그림 자체가 흐름도의 칸이 된다. 특히 화면이 많이 바뀌는 모바일 앱에 잘 맞는다. (출처: NN/g, Wireflows)
🎯 그래서 당신은 화면을 그렸으면 항상 묻는다 — "이 버튼을 누르면 어디로 가지? 그리고 여기서 어떻게 돌아오지?" 두 질문에 화살표로 답할 수 있어야 흐름이 완성된 것이다.
F4. 화면 설계
07 / 11
F4 · 논증 6단계 · 근거: 충실도(fidelity)
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
반론 처리 — "그래도 예쁨은 중요하잖아요?"

예쁨이 안 중요한 게 아니다 — '순서'가 나중일 뿐

"색도 디자인도 결국 중요하지 않냐"는 반론은 맞다. 완성된 앱은 당연히 예뻐야 하고, 색·아이콘·글꼴도 사용자 경험의 일부다. 다만 디자이너는 그림을 '충실도(fidelity)' 단계로 나눠 그린다 — 처음엔 낮은 충실도(흑백 뼈대)로 구조를 잡고, 구조가 굳은 다음에 색·이미지를 입혀 높은 충실도(시안)로 올린다. 예쁨을 빼는 게 아니라, 자리를 뒤로 미루는 것이다.

단계무엇을지금 정하는 것 / 미루는 것
1낮은 충실도 와이어프레임구조·흐름·버튼 위치를 정한다 / 색·꾸밈은 미룬다
2중간 — 회색조·실제 글정보 위계·글 분량을 본다 / 최종 색은 아직
높은 충실도 시안(예쁨)← 구조가 선 다음에 색·아이콘·이미지를 얹는다
⚠️ 핵심 단서 — 흑백 뼈대 단계에서 색을 칠하기 시작하면, 사람들은 구조 대신 색을 평가하기 시작한다("이 파랑 별로다"). 그래서 일부러 색을 빼는 것이다. 예쁨은 토대(구조·흐름)가 선 뒤에 얹어야 제 힘을 낸다.
→ 따라서반론은 절반만 맞다. 예쁨에도 분명한 자리가 있다 — 단, 맨 앞이 아니라 토대 위에. 그렇다면 이 흑백 뼈대는 결국 누구를 위해 그리는 걸까?
F4. 화면 설계
08 / 11
F4 · 논증 7단계 · 결론
① 통념② 주장③ 왜④ 핵심⑤ 흐름⑥ 반론⑦ 결론
결론 — 왜 그려야 하는가

그림은 말보다 정확하다 — 그래서 더 잘 만들어진다

왜 굳이 그려야 할까? 그림이 말보다 정확하기 때문이다. "여기에 큰 버튼이 있고, 누르면 결과 화면으로 가요"라고 말로만 설명하면 듣는 사람마다 다르게 상상한다. 하지만 네모로 그려서 보여 주면 모두가 같은 그림을 본다. 그래서 그 그림을 받은 사람 — 개발자나 AI — 가 훨씬 정확하게 만든다. 와이어프레임은 '내 머릿속 앱'을 남에게(그리고 AI에게) 정확히 건네는 공용 언어다.

🗯️ 말로만 — 제각각 상상

"급식 보는 앱 만들어 줘"라고만 하면, 받는 쪽은 첫 화면도·버튼 위치도·결과 화면도 멋대로 상상한다. 내 머릿속과 다른 앱이 나온다.

🖼️ 그림으로 — 같은 그림 공유

"이렇게 생긴 화면 3개를 이 화살표대로 이어 줘"라고 와이어프레임을 건네면, 개발자도 AI도 같은 목표를 본다. 결과물이 내 의도에 가까워진다.

🎓 교실에서 (sprint 연계) 이 와이어프레임 활동은 sprint Step4 '화면 스케치'와 그대로 이어진다. 종이에 그린 화면 3개·화살표를 Step4에 옮겨 정리하면, 다음 단계인 F5(프런트엔드 = '보이는 쪽')에서 그 화면을 실제로 만드는 다리가 된다.
🎯 그래서 당신은 만들기 전에 이 순서로 그린다 — ① 화면 3개를 네모·글씨로(뼈대) → ② 버튼마다 화살표로 잇고 뒤로 갈 길까지(흐름) → ③ 그제서야 색·꾸밈(예쁨).
F4. 화면 설계
09 / 11
F4 · 정리
F4가 증명한 것 — 한 줄의 논증

'예쁘게부터'에서 출발해, '뼈대부터'에 도착했다

이 장은 와이어프레임·흐름 이론을 모은 게 아니라, "만들기 전에 무엇을 그리나"라는 한 질문을 끝까지 따라간 추론이었다. 출발점은 "처음부터 예쁘게"라는 통념이었고, 도착점은 "색·꾸밈을 뺀 뼈대와 흐름을 먼저"라는 주장이었다. 그 사이를 설계도 비유·화면 3개·와이어플로우·충실도가 각자의 역할로 이어 주었다.

통념우리는 색·꾸밈(예쁜 화면)부터 그리려 한다
↓ 그런데
주장색·꾸밈을 뺀 '뼈대(와이어프레임)'부터 그린다 — 네모와 글씨만으로
↓ 왜냐면
종이(설계도)에서 고치는 게 다 지은 집을 고치는 것보다 싸고 빠르니까
↓ 그래서 핵심은
핵심화면 3개(첫·핵심·결과)면 앱이 보인다 — 화면당 버튼은 1~2개
↓ 그리고
흐름화면 사이를 화살표로 잇는다(UX 흐름) — 돌아갈 길(뒤로 가기)까지
↓ 하지만 예쁨은?
반론예쁨도 중요하다 — 단 '충실도' 순서상 토대가 선 다음이다
↓ 따라서
결론그림은 말보다 정확하다 — 개발자·AI가 더 잘 만든다(🎓 sprint Step4 → F5 프런트엔드)
🎯 한 문장 요약 화면 설계는 색칠이 아니라 '네모·글씨로 뼈대를 그리고 화살표로 흐름을 잇는 일'이며, 예쁨은 구조와 흐름이 선 맨 나중에 얹는다.
F4. 화면 설계
10 / 11
더 읽을거리 · 검증된 1차 자료

근거가 된 자료 & 다음 장

  • Balsamiq, What Are Wireframes? — 와이어프레임 = 디지털 프로젝트의 '골격', 낮은 충실도(흑백)로 빠르게 그려 값비싼 수정을 예방 · ①③④ 단계 근거
  • Figma, What is Wireframing? — 와이어프레임의 종류·단계·흐름 연결 입문 · ② 주장 근거
  • Interaction Design Foundation, Wireframe — '뼈대 → 시안 → 완성' 디자인 프로세스 속 위치 · ⑥ 충실도 근거
  • NN/g (Nielsen Norman Group), Wireflows — 와이어프레임 + 화면 간 이동(흐름)을 결합한 와이어플로우, 화면 많은 모바일 앱에 적합 · ⑤ 흐름 근거
다음 장 — F5. 프런트엔드(보이는 쪽) · F4에서 그린 화면 뼈대를, 이제 실제로 '보이는 쪽(프런트엔드)'으로 만든다. 🎓 교실에서는 이 와이어프레임을 sprint Step4 화면 스케치로 옮겨 잇는다. (architecture 5장 '보이는 쪽과 안 보이는 쪽' 참고)
F4. 화면 설계
11 / 11