스토리보드·플로우차트·다이어그램까지 — 개발자·기획자·창업자 필독

"이거 와이어프레임으로 먼저 뽑아주세요."

앱 개발을 처음 시작하면 이런 말을 자주 듣게 됩니다.
와이어프레임? 프로토타입? 핸드오프?
비슷한 것 같지만 완전히 다른 개념입니다.

이 용어들을 모르면 개발자, 디자이너, 기획자와 대화가 안 됩니다.
반대로 이 6가지만 정확히 알면 협업이 훨씬 매끄러워집니다.

 

① 와이어프레임  —  뼈대 설계도

② 프로토타입  —  동작하는 시제품

③ 핸드오프  —  개발자에게 넘기기

④ 스토리보드  —  화면 흐름 문서

⑤ 플로우차트  —  논리 흐름도

⑥ 다이어그램  —  구조 시각화 도표

 

---

1.  와이어프레임 

"아이콘이나 그림 위주로 뼈대만 대략적으로 잡은 정적인 화면 설계도"

쉽게 말하면: 건물 짓기 전 건축 도면. 어디에 문이 있고, 어디에 창문이 있는지 위치만 잡는 것.

 

이것이다	이것이 아니다
·  회색·흑백 박스로 레이아웃만 표현 ·  버튼·텍스트·이미지 위치 표시 ·  클릭해도 반응 없는 정적 화면 ·  예쁠 필요 없음 — 구조가 핵심	·  색상·폰트 디자인이 완성된 것 ·  클릭하면 다음 화면 넘어가는 것 ·  실제 앱처럼 동작하는 것

 

▶  포함되는 요소

·  네비게이션 바·메뉴 위치

·  버튼, 입력창, 리스트 배치

·  이미지·텍스트가 들어갈 공간 표시

·  화면 간 기본 연결 흐름

·  주석 (이 버튼을 누르면 어디로 이동하는지 메모)

▶  실전 도구

·  Figma — 무료, 협업 최적, 가장 많이 사용

·  Balsamiq — 손그림 스타일, 저렴

·  Excalidraw — 무료, 가볍게 쓰기 좋음

·  종이+펜 — 가장 빠름, 초기 아이디어에 최적

▶  언제 사용하나

기획 초반, 디자인 시작 전에 만듭니다.
개발자·디자이너·기획자가 '화면 구조'에 대해 같은 그림을 그리기 위해 씁니다.
이 단계에서 충분히 수정해야 나중에 디자인 수정 비용을 아낄 수 있습니다.

 최종 산출물: 화면별 레이아웃 설계도 (보통 10~50장)

---

2.  프로토타입 (Prototype)

"버튼을 누르면 다음 화면으로 넘어가는 등 실제 앱처럼 동작을 구현한 시제품"

 

쉽게 말하면: 자동차 출시 전 만드는 시험 차량. 실제로 타볼 수 있지만 아직 양산품은 아닌 것.

 

이것이다	이것이 아니다
·  클릭·스와이프 등 인터랙션 구현 ·  화면 전환 애니메이션 포함 ·  사용자가 실제로 사용해볼 수 있음 ·  디자인이 어느 정도 완성된 상태	·  실제 서버나 데이터베이스 연결 ·  개발(코딩)된 실제 앱 ·  배포·출시 가능한 제품

 

▶  포함되는 요소

·  화면 간 전환 인터랙션

·  버튼 클릭 → 다음 화면 이동

·  실제 콘텐츠와 유사한 더미 데이터

·  로딩·에러 상태 화면

·  사용자 흐름 전체 시뮬레이션

▶  실전 도구

·  Figma — 프로토타입 기능 내장, 무료

·  ProtoPie — 고급 인터랙션, 정밀한 애니메이션

·  Marvel — 간단한 클릭형 프로토타입

·  InVision — 디자인팀 협업에 강점

▶  언제 사용하나

와이어프레임이 완성된 후, 개발 시작 전에 만듭니다.
실제 사용자에게 테스트할 때 가장 많이 사용합니다.
"이 버튼이 어디 있어야 자연스러운가?"를 코딩 없이 확인할 수 있습니다.
투자자에게 아이디어를 설명할 때도 프로토타입이 있으면 훨씬 설득력이 높아집니다.

최종 산출물: 인터랙티브 화면 시뮬레이션 링크 (Figma 공유 링크 등)

---

3.  핸드오프 

"기획·디자인이 끝나고 개발자가 코딩을 시작할 수 있도록 결과물을 넘겨주는 과정"

 

쉽게 말하면: 건축 설계사가 시공사에 완성된 도면 전달하는 것. '이 도면대로 지어주세요'.

 

이것이다	이것이 아니다
·  디자이너 → 개발자로의 공식 인수인계 ·  디자인 스펙·수치·색상코드 전달 ·  개발자가 보는 설계 가이드 제공 ·  기획 단계의 마무리이자 개발 단계의 시작점	·  단순히 파일을 이메일로 보내는 것 ·  구두로 설명하고 넘기는 것 ·  개발이 시작된 이후 단계

 

▶  포함되는 요소

·  화면별 정확한 크기·여백·간격 수치

·  색상 코드 (HEX, RGB 값)

·  폰트 종류·크기·굵기·행간

·  아이콘·이미지 에셋 파일

·  인터랙션 설명 (hover, click, scroll 동작)

·  반응형 레이아웃 가이드 (모바일/PC 대응)

▶  실전 도구

·  Figma Dev Mode — 개발자용 수치 자동 추출 (무료)

·  Zeplin — 핸드오프 전문 도구, 팀 협업에 강함

·  Notion — 스펙 문서 정리 및 공유

·  Confluence — 기업용 문서 협업 도구

▶  언제 사용하나

디자인이 완전히 확정된 후, 개발을 시작하기 직전에 진행합니다.
핸드오프가 불완전하면 개발자가 임의로 만들거나 디자이너에게 매번 물어봐야 합니다.
이 과정을 제대로 하면 개발 중 커뮤니케이션 비용이 50% 이상 줄어듭니다.

 최종 산출물: 개발 스펙 문서 + 에셋 파일 패키지

---

4.  스토리보드 

"화면 흐름과 각 기능의 상세 설명을 포함한 서비스 기획 문서"

쉽게 말하면: 영화 촬영 전 감독이 그리는 콘티. 장면 순서·대사·카메라 각도를 모두 정리한 것.

 

이것이다	이것이 아니다
·  화면 순서와 전환 조건 서술 ·  각 화면에서 일어나는 기능 설명 ·  예외 케이스·에러 상황 포함 ·  기획 의도와 UX 설명 텍스트 포함	·  단순 화면 이미지 나열 ·  개발 코드나 기술 명세서 ·  와이어프레임만 있는 것 (설명 없으면 스토리보드 아님)

 

▶  포함되는 요소

·  화면 번호와 화면 이름

·  각 화면의 와이어프레임 또는 스크린샷

·  화면에서 가능한 사용자 행동

·  버튼 클릭 시 발생하는 결과

·  조건 분기 (로그인 여부에 따라 다른 화면 등)

·  서버 연동 필요 항목 표시

▶  실전 도구

·  Notion — 텍스트+이미지 혼합, 협업에 최적

·  Google Slides — 화면+설명 병렬 배치 용이

·  PowerPoint — 전통적인 기획서 작성

·  Confluence — 팀 기술 문서 관리

▶  언제 사용하나

와이어프레임·프로토타입이 완성된 후, 개발 전 전체 팀이 공유하는 기준 문서입니다.
특히 외주 개발이나 팀 협업 시 필수입니다.
개발자가 '이 기능이 왜 이렇게 동작해야 하는지' 맥락을 이해할 수 있게 해줍니다.
나중에 QA(품질 검증) 기준으로도 활용됩니다.

최종 산출물: 화면 기준 기획 문서 (보통 50~200페이지)

---

5.  플로우차트 

"서비스의 논리적 흐름, 조건 분기, 데이터 처리 순서를 도형과 화살표로 표현한 흐름도"

 

쉽게 말하면: 음식점 주문 처리 흐름도. 주문 → 재고 확인 → 있으면 조리, 없으면 품절 안내.

 

이것이다	이것이 아니다
·  시작→끝까지 논리 흐름 표현 ·  Yes/No 분기 조건 포함 ·  프로세스·데이터 흐름 시각화 ·  개발자가 로직 구현에 직접 참고	·  화면 디자인이나 레이아웃 표현 ·  사용자 감정·경험 표현 ·  구체적인 UI 위치 설명

 

▶  포함되는 요소

·  시작·종료 (타원형)

·  처리 단계 (사각형)

·  조건 분기 (마름모: Yes / No)

·  데이터 입출력 (평행사변형)

·  연결 화살표와 방향

▶  실전 도구

·  Figma — 도형+화살표로 자유롭게 제작

·  draw.io (diagrams.net) — 무료, 플로우차트 전문

·  Miro — 온라인 화이트보드, 팀 협업 최적

·  Lucidchart — 기업용 다이어그램 도구

▶  언제 사용하나

로그인·결제·알림 등 복잡한 로직이 있는 기능을 개발하기 전에 그립니다.
기획자가 로직을 설계하고 개발자가 이를 코드로 옮길 때 기준이 됩니다.
팀원 간 '이 경우엔 어떻게 해야 하나?' 논의를 할 때도 플로우차트가 있으면 훨씬 명확합니다.

최종 산출물: 기능별 로직 흐름도 (기능당 1~3장)

---

6.  다이어그램

"시스템 구조, 데이터 관계, 아키텍처 등을 도형과 선으로 시각화한 도표의 총칭"

 

쉽게 말하면: 회사 조직도. 누가 누구에게 보고하는지, 부서 간 관계가 어떻게 되는지 한눈에 보여주는 것.

 

이것이다	이것이 아니다
·  플로우차트를 포함하는 상위 개념 ·  시스템 구조·관계 시각화 ·  데이터베이스 구조 표현 (ERD) ·  서버·API 아키텍처 표현	·  단순 흐름도만 의미하는 것 (플로우차트와 구분) ·  UI 화면 설계도 ·  텍스트만으로 구성된 문서

 

▶  포함되는 요소

·  서비스 아키텍처 다이어그램 — 서버·앱·DB 관계 표현

·  ERD (Entity Relationship Diagram) — 데이터베이스 구조

·  클래스 다이어그램 — 개발 객체 구조

·  시퀀스 다이어그램 — 시스템 간 메시지 흐름

·  사이트맵 다이어그램 — 페이지 계층 구조

▶  실전 도구

·  draw.io — 무료, 다양한 다이어그램 템플릿

·  Lucidchart — 팀 협업용 다이어그램

·  Miro — 자유도 높은 시각화

·  dbdiagram.io — ERD(데이터베이스 설계) 전문

▶  언제 사용하나

개발 설계 단계에서 주로 사용합니다.
기획자보다 개발자·아키텍트가 주도적으로 작성하지만,
창업자나 PM이 읽을 수 있어야 개발팀과 소통이 가능합니다.
특히 외주 개발 발주 시 '이런 구조로 만들어 주세요'를 설명할 때 필수입니다.

최종 산출물: 시스템 구조 설계 문서 (ERD, 아키텍처 다이어그램 등)

---

7.  6가지 한눈에 비교 — 언제 무엇을 써야 하나

헷갈릴 때 이 표 하나로 정리하세요.

용어	한 줄 정의	동작 여부	제작 단계	주요 독자
와이어프레임	뼈대 레이아웃 설계도	정적 (❌)	기획 초반	기획자·디자이너
프로토타입	동작하는 시제품	동적 (✅)	디자인 완성 후	기획·디자이너·투자자
핸드오프	개발자에게 인수인계	과정 (🔄)	개발 직전	디자이너→개발자
스토리보드	화면 흐름 기획 문서	문서 (📄)	기획 완성 후	팀 전체
플로우차트	논리 흐름 도식화	정적 (❌)	개발 설계 전	기획자·개발자
다이어그램	구조·관계 시각화 총칭	정적 (❌)	개발 설계 전	개발자·PM

---

8.  실전 활용 순서와 추천 무료 도구

6가지를 다 만들어야 하는 건 아닙니다.
프로젝트 규모에 따라 필요한 것만 선택하면 됩니다.
아래 순서가 대부분의 앱·웹 프로젝트에서 권장되는 흐름입니다.

1단계  |  플로우차트 · 다이어그램

가장 먼저 서비스의 전체 흐름과 구조를 잡습니다.
로그인, 결제, 알림 등 핵심 로직을 먼저 도식화합니다.

추천 도구: draw.io / Miro (무료)

2단계  |  와이어프레임

흐름이 정해지면 각 화면의 레이아웃을 잡습니다.
이 단계에서 팀 전체가 화면 구조에 합의해야 합니다.

추천 도구: Figma / Excalidraw (무료)

3단계  |  스토리보드

와이어프레임 + 기능 설명을 합쳐 기획 문서를 완성합니다.
외주 개발이라면 이 문서가 발주서 역할을 합니다.

추천 도구: Notion / Google Slides (무료)

4단계  |  프로토타입

실제 사용자에게 테스트할 인터랙티브 시제품을 만듭니다.
사용자 테스트를 최소 5명 진행하고 피드백을 반영합니다.

추천 도구: Figma 프로토타입 기능 (무료)

5단계  |  핸드오프

디자인이 확정되면 개발자에게 스펙 문서와 에셋을 전달합니다.
이 단계부터 개발이 시작됩니다.

추천 도구: Figma Dev Mode (무료)

 

▶  추천 무료 도구 한눈에 보기

 

도구명	주요 용도	특징
Figma	와이어프레임·프로토타입·핸드오프	무료, 협업, 웹 기반 — 가장 추천
draw.io	플로우차트·다이어그램	완전 무료, 다양한 도형 템플릿
Notion	스토리보드·기획 문서	무료, 글+이미지 혼합 최적
Miro	플로우차트·아이디어 매핑	무료 플랜, 팀 실시간 협업
Excalidraw	빠른 와이어프레임 스케치	완전 무료, 손그림 느낌
dbdiagram.io	데이터베이스 ERD	무료, 코드로 다이어그램 생성

 

---

 

6가지 용어, 이제 헷갈리지 않습니다.

 

와이어프레임으로 뼈대를 잡고,
프로토타입으로 동작을 테스트하고,
스토리보드로 팀과 공유하고,
플로우차트로 로직을 설계하고,
다이어그램으로 구조를 그리고,
핸드오프로 개발자에게 넘깁니다.

이 순서가 제대로 지켜질수록 개발 후 수정 비용이 줄어들고
팀 간 커뮤니케이션 실수가 사라집니다.

 

관련 글

https://aetba.tistory.com/29]

앱·웹 서비스 창업 전

https://aetba.tistory.com/28

회사 브랜딩 방법 5단계