와이어프레임·스토리보드·IA는 뭐가 다를까요 | 기획 산출물
기획 문서는 이름이 아니라 확정하는 대상이 달라요. IA는 구조를, 와이어프레임은 배치를, 스토리보드는 동작과 예외를 정해요. 셋 중 무엇이 빠지면 어디서 분쟁이 나는지, 단순 웹 2～6주 기준으로 기획에 얼마가 잡히는지 정리했어요.
핵심 요약 — 기획 문서는 이름이 여러 개인데, 서로 다른 걸 정해요. IA는 무엇이 어디에 있는지(구조)를, 와이어프레임은 한 화면에 무엇이 놓이는지(배치)를, 스토리보드는 누르면 어떻게 되는지(동작과 예외)를 확정해요. 견적서에 “기획 포함”이라고만 적혀 있으면 이 셋 중 어디까지인지 확인하셔야 해요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“기획서는 저희가 드리면 되나요?”
이 질문에 서로 다른 답을 하고 착수한 프로젝트는 대개 첫 달을 통째로 날려요. 발주자는 화면을 그린 그림을 기획서라고 생각하고, 개발사는 버튼마다 무슨 일이 일어나는지 적힌 문서를 기획서라고 생각하거든요.
웹기획 용어가 유난히 헷갈리는 데는 이유가 있어요. IA, 와이어프레임, 스토리보드, 화면설계서, 프로토타입이 다 비슷한 그림처럼 보이는데 정하는 대상이 서로 달라요. 하나씩 갈라볼게요.
1. 기획 문서 이름이 왜 이렇게 많을까요
만드는 순서가 달라서예요.
집을 짓는다고 생각하면 쉬워요. 방을 몇 개 두고 어디에 배치할지 정하는 도면이 있고, 방 하나에 가구를 어디 놓을지 그리는 그림이 있고, 문을 열면 어느 방으로 이어지는지 적는 설명이 있어요. 셋 다 필요한데 하나로 합칠 수는 없어요.
소프트웨어도 같아요. 그래서 문서가 나뉘고, 나뉜 문서마다 이름이 붙었어요. 문제는 실무에서 이 이름들이 섞여 쓰인다는 점이에요. 어떤 회사는 스토리보드를 화면설계서라고 부르고, 어떤 곳은 와이어프레임까지만 그려놓고 스토리보드라고 해요. 그래서 이름으로 확인하면 안 되고 내용으로 확인해야 해요.
2. IA는 무엇을 정하나요
무엇이 어디에 있는지를 정해요.
IA는 정보 구조(Information Architecture)의 줄임말이에요. 서비스 안에 어떤 화면들이 있고, 그것들이 어떤 계층으로 묶이는지를 표나 나뭇가지 형태로 그려요. 메뉴가 몇 단계까지 들어가는지, 마이페이지 아래에 무엇이 붙는지가 여기서 정해져요.
발주자 입장에서 IA가 중요한 이유는 개수가 여기서 확정되기 때문이에요. 견적의 뼈대는 화면 수인 경우가 많아요. IA가 없으면 개발사는 화면이 몇 개인지 모른 채로 값을 부르게 되고, 그 숫자는 나중에 반드시 움직여요.
IA에서 자주 빠지는 게 관리자 화면이에요. 사용자가 보는 화면만 그려놓고 나중에 “관리자에서 상품 등록은 어떻게 하죠?”가 나오면, 그때부터 화면이 통째로 늘어나요.
3. 와이어프레임은 무엇을 정하나요
한 화면 안에 무엇이 어디에 놓이는지를 정해요.
색도 없고 이미지도 없이 네모와 선으로만 그려요. 일부러 그렇게 해요. 색과 폰트가 들어가면 사람들이 예쁜지 아닌지를 이야기하기 시작해서, 정작 정해야 할 배치 논의가 뒤로 밀리거든요.
와이어프레임에서 확정되는 건 이런 것들이에요. 목록이 위에 오는지 검색창이 위에 오는지, 버튼이 몇 개인지, 한 화면에 담을 정보가 얼마나 되는지. 여기까지 정해지면 화면당 작업량이 대충 보여요.
용어 정리 — 와이어프레임과 프로토타입, 디자인 시안 셋은 다른 물건이에요. 와이어프레임은 배치만 그린 흑백 뼈대예요. 프로토타입은 그 뼈대를 눌러볼 수 있게 연결한 것이라 실제로 화면이 넘어가요. 디자인 시안은 색과 이미지가 입혀진 최종 그림이고요. 실무에선 “시안 주세요”가 세 가지 중 아무거나를 뜻할 때가 있어서, IT기획 회의에서는 어느 단계를 말하는지 한 번 되물어보는 게 좋아요.
4. 스토리보드는 무엇을 정하나요
누르면 어떻게 되는지를 정해요.
여기가 개발자가 실제로 보는 문서예요. 화면 그림 옆에 설명이 붙어요. 이 버튼을 누르면 어디로 이동하는지, 입력값이 비어 있으면 무슨 문구가 뜨는지, 통신이 실패하면 어떻게 되는지가 적혀요. 화면설계서, 작업지시서라고 부르는 것도 대개 이걸 말해요.
스토리보드의 값어치는 정상 흐름이 아니라 예외에서 나와요. 로그인 화면을 예로 들면 성공했을 때는 다들 같은 그림을 떠올려요. 갈리는 건 비밀번호를 다섯 번 틀렸을 때, 이미 가입된 이메일일 때, 인증 문자가 안 올 때예요. 이 칸이 비어 있으면 개발자는 자기 판단으로 채우고, 검수 때 “이건 이렇게 되면 안 되는데요”가 나와요.
저희가 만들었던 건설장비 쇼핑 플랫폼에서는 작업일보에 서명을 받는 흐름이 있었어요. 현장 책임자가 확인하고 기사가 확인하는 단계가 이어지는 구조였는데, 이 순서와 각 단계에서 되돌릴 수 있는지를 문서로 정리하는 데 시간이 꽤 들었어요. 화면 수로 세면 몇 개 안 되는데 실제 일은 그 사이의 규칙에 있었거든요.
5. 세 문서를 한 표로 비교하면요
한눈에 보면 이래요.
| 구분 | 정하는 것 | 없으면 생기는 일 | 주로 쓰는 사람 |
|---|---|---|---|
| IA(정보 구조) | 화면이 몇 개고 어떻게 묶이나 | 견적의 기준이 되는 화면 수가 흔들려요 | 기획·발주자 |
| 와이어프레임 | 한 화면에 무엇이 어디 놓이나 | 디자인 단계에서 배치를 다시 논의해요 | 기획·디자인 |
| 스토리보드 | 누르면 어떻게 되고 실패하면 어떻게 되나 | 검수 때 “생각과 다르다”가 나와요 | 개발·QA |
셋 중 하나만 골라야 한다면 스토리보드예요. 개발이 실제로 참조하는 문서라서요. 다만 IA 없이 스토리보드부터 쓰면 빠진 화면이 생기기 쉬워서, 순서를 지키는 편이 결국 빨라요.
6. 어떤 순서로, 얼마나 걸리나요
요구사항 정리 → IA → 와이어프레임 → 스토리보드 순서예요.
앞 단계가 정해져야 뒤 단계를 그릴 수 있어서 순서를 건너뛰기 어려워요. 다만 규모가 작으면 IA와 와이어프레임을 한 문서에서 같이 처리하기도 해요.
공식 외부 기준 (공개 시장 자료 종합, 기획~검수/출시 전체 기간)
| 프로젝트 유형 | 전체 기간 |
|---|---|
| 단순 웹 | 2～6주 |
| 중소기업 홈페이지 | 3～8주 |
| 쇼핑몰 | 1～6개월 |
| 단순 앱 | 6～10주 |
| 커머스·예약 앱 | 3～5개월 |
| 플랫폼·실시간 앱 | 4～6개월 이상 |
자사 실무 기준 예시 (저희가 일정 짤 때 쓰는 배분이에요. 실거래 통계가 아니라 내부 기준이에요.)
| 단계 | 전체 대비 비중 |
|---|---|
| 요구사항 정리·IA | 5～10% |
| 와이어프레임·스토리보드 | 15～20% |
| 개발·디자인 | 50～60% |
| 테스트·검수·배포 | 15～20% |
기획에 20～30%를 쓰는 게 아까워 보일 수 있어요. 그런데 이 기간을 줄이면 개발 기간이 그만큼 늘어나는 쪽으로 옮겨가요. 총량이 줄지 않고 자리만 바뀌는데, 뒤로 갈수록 수정 비용이 비싸져서 손해가 커져요.
직접 운영해보니 저희가 자체 서비스를 만들 때도 스토리보드를 건너뛰고 싶은 순간이 있어요. 우리끼리 아는 내용이니까요. 그런데 몇 달 지나서 그 기능을 다시 손댈 때 결국 문서를 찾게 되더라고요. 만든 사람이 기억하는 기간이 생각보다 짧아요. 그래서 요즘은 화면이 적어도 예외 처리만큼은 문서로 남겨둬요.
7. 이 문서가 없으면 어디서 문제가 생기나요
착수할 때가 아니라 끝날 때 터져요.
기획 문서 없이 시작하면 초반은 오히려 빨라요. 회의에서 말로 정하고 바로 만들기 시작하니까요. 문제는 개발 막바지예요. “이건 당연히 되는 거 아니었나요”와 “그런 요청은 받은 적이 없는데요”가 부딪치고, 일정이 계속 밀려요.
흔한 실수를 정리하면 이래요.
- 화면 그림만 있고 설명이 없는 경우 — 예쁘게 그려진 시안을 받았는데 동작 설명이 없으면 개발은 시작 못 해요.
- 관리자 화면이 빠진 경우 — 사용자 화면만 그리다가 뒤늦게 관리자 요구가 붙으면 화면 수가 통째로 늘어나요.
- 기획 주체가 안 적힌 경우 — 견적서에 “기획 포함”이라고만 있으면 어디까지인지 확인하셔야 해요. IA만 그려주는 것과 스토리보드까지 쓰는 건 공수가 다르거든요.
- 문서를 만들고 갱신을 안 하는 경우 — 회의에서 바뀐 내용이 문서에 안 들어가면, 문서가 있어도 없는 것과 같아져요.
앱 개발비나 웹 개발 견적을 비교할 때 기획 항목이 유난히 싼 곳이 있다면 대개 범위가 좁은 거예요. 금액만 보지 마시고 산출물 이름을 물어보세요. 견적서에서 어떤 항목을 확인해야 하는지에 관련 기준을 정리해뒀어요.
8. 자주 묻는 질문 (FAQ)
와이어프레임만 있으면 개발을 시작할 수 있나요?
화면이 단순하면 가능하지만 대개는 부족해요. 와이어프레임은 한 화면에 무엇이 놓이는지까지만 정해요. 버튼을 눌렀을 때 어디로 가는지, 값이 비어 있으면 어떻게 되는지는 안 적혀 있어요. 개발자가 그 빈칸을 자기 판단으로 채우게 되고, 검수 단계에서 생각과 다르다는 말이 나와요.
기획서는 개발사가 만들어주나요, 우리가 만들어야 하나요?
둘 다 가능한데 견적서에 어느 쪽인지 적혀 있어야 해요. 발주자가 만들어 오면 기획비가 빠지는 대신 그 문서의 정확도만큼 견적이 정확해져요. 개발사가 만들면 비용이 붙지만 개발 가능한 형태로 정리돼요. 문제는 둘 다 안 적힌 경우예요. 서로 상대가 할 거라 생각하고 착수하면 첫 달이 그대로 비어요. 요구사항을 어디까지 적어야 하는지는 요구사항 정의서 가이드를 참고하세요.
기획 단계는 보통 얼마나 걸리나요?
전체 기간의 20～30%를 잡는 경우가 많아요. 단순 웹은 기획부터 출시까지가 2～6주라 기획이 1주 안쪽인 경우도 있고, 커머스나 예약 앱처럼 3～5개월짜리는 기획에만 3～4주가 들어가요. 기간이 왜 밀리는지는 개발 기간 산정 기준에 더 적어뒀어요.
9. 마무리 — 문서 이름 대신 확정 대상을 물어보세요
정리하면 이래요. IA는 무엇이 어디에 있는지, 와이어프레임은 한 화면에 무엇이 놓이는지, 스토리보드는 누르면 어떻게 되는지를 정해요. 이름은 회사마다 다르게 부르지만 이 세 가지 질문에 답이 있으면 개발은 시작할 수 있어요.
그래서 견적서를 받으셨을 때 물어볼 말은 하나면 충분해요. “기획 산출물로 무엇을 받게 되나요?” IT기획자 없이 발주를 준비하는 상황이라면 이 질문만으로도 범위가 꽤 또렷해져요.
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 남이 쓴 기획서로 만들어보기도 하고 직접 써보기도 해서, 어떤 칸이 비면 나중에 손이 많이 가는지 알아요. 지금 준비 중인 문서가 개발에 넘길 수 있는 수준인지 애매하시면 어디가 비어 있는지 같이 봐드릴게요 →
관련 글