화면설계서는 서비스의 화면을 한 장씩 그림과 글로 적어 둔 문서예요. 개발사에 견적을 요청할 때 기준이 되고, 개발이 끝난 뒤 검수할 때도 기준이 됩니다. 그런데 검색해서 나오는 자료는 기획자와 디자이너가 문서를 예쁘게 만드는 방법에 치우쳐 있어요. 발주자가 무엇을 요구하고 무엇을 확인해야 하는지는 잘 나오지 않습니다.
이 글은 비개발 창업자와 발주 담당자 관점으로 씁니다. 직접 그리는 방법도 다루지만, 더 중요한 것은 개발사가 만들어 온 화면설계서를 받아 들고 어디를 짚어야 하는가예요. 용어 구분부터 정리하고, 화면 한 장의 구성과 양식 예시, 작성 순서, 화면 수와 견적의 관계, 도구 선택, 검수 질문 순으로 갑니다.
화면설계서는 세 가지를 한 문서에 담습니다. 첫째는 이 서비스에 어떤 화면이 몇 개 있는가라는 화면 목록, 둘째는 각 화면에 무엇이 어디에 놓이는가라는 배치, 셋째는 그 화면의 각 요소가 눌리거나 입력되었을 때 무슨 일이 일어나는가라는 동작 설명이에요. 세 번째가 빠지면 그건 화면설계서가 아니라 그림 모음입니다.
부르는 이름은 회사마다 다릅니다. 화면정의서, UI 설계서, 스토리보드, SB, 화면기획서 같은 말이 같은 문서를 가리키기도 하고 서로 다른 문서를 가리키기도 해요. 그래서 견적 미팅 첫머리에 이름을 확인하는 것보다 내용을 확인하는 편이 정확합니다. 산출물 목록에 문서 이름만 적히고 그 안에 무엇이 들어가는지 합의되지 않으면, 나중에 받은 문서가 기대와 달라도 계약 위반이라고 말하기 어려워요.
발주자 입장에서 이 문서의 쓸모는 세 가지입니다. 견적을 같은 기준으로 비교하는 근거, 개발 중에 만들 것과 만들지 않을 것을 가르는 선, 완성 후 검수할 때 대조할 원본이에요. 이 셋 중 하나라도 필요하다면 화면설계서는 개발 착수 전에 나와 있어야 합니다.
이 세 용어는 자료마다 다르게 쓰여서, 미팅에서 같은 말을 서로 다르게 이해하는 일이 생겨요. 개발사가 와이어프레임을 보여주면서 설계가 끝났다고 말하는 경우가 있는데, 그건 배치만 정해진 상태입니다. 반대로 발주자가 스토리보드를 요청했더니 영상 콘티 이야기로 이어지는 경우도 있어요. 그래서 아래 표는 정의가 비교적 안정적인 네 가지만 나란히 놓았습니다.
| 구분 | 주로 담는 것 | 담지 않는 것 | 완성되는 시점 | 이게 확정되면 정해지는 것 |
|---|---|---|---|---|
| 와이어프레임 | 요소의 위치와 크기, 화면 뼈대 | 동작, 분기, 예외, 색과 폰트 | 기획 초반, 여러 안을 빠르게 비교할 때 | 화면의 큰 구조 |
| 화면설계서 | 배치 + 요소별 동작 설명 + 분기 + 예외 + 데이터 출처 | 최종 색상, 아이콘, 애니메이션 같은 시각 디테일 | 개발 착수 직전 | 개발 범위와 견적, 검수 기준 |
| 디자인 시안(GUI) | 실제 색, 폰트, 이미지가 적용된 화면 | 예외 화면과 동작 규칙이 빠지는 경우가 있음 | 화면설계서 확정 이후 | 보이는 결과물의 모양 |
| 프로토타입 | 클릭해서 화면 사이를 이동해보는 형태 | 서버 동작, 실제 데이터, 예외 처리 | 설계 검증 단계 | 흐름이 말이 되는지 여부 |
스토리보드를 표에서 뺀 이유가 있어요. 국내 개발 현장에서 스토리보드는 화면설계서와 같은 뜻으로 쓰이는 경우가 있지만, 정의가 회사마다 달라서 담는 것과 완성 시점을 한 줄로 적을 수가 없습니다. 웹에서 스토리보드를 검색하면 영상 제작 자료가 먼저 나오는 이유도 여기 있어요. 산출물 목록에 스토리보드라고 적혀 있으면 이름이 아니라 그 안에 무엇이 들어가는지를 먼저 물어보세요.
실무에서 가르는 기준은 간단해요. 개발자가 이 문서만 보고 코드를 작성할 수 있으면 화면설계서, 배치를 보고 이야기를 나누는 용도면 와이어프레임입니다. 디자인 시안이 아무리 예뻐도 버튼을 눌렀을 때 무슨 일이 일어나는지 적혀 있지 않으면 화면설계서를 대체하지 못해요. 와이어프레임을 어느 정밀도까지 그릴지는 기획 단계 판단이라 MVP 기획 단계에 뭘 들고 가야 하나에서 따로 다뤘습니다.
화면 한 장은 그림 하나가 아니라 블록 여러 개의 묶음이에요. 그림은 그중 하나일 뿐이고, 나머지 블록이 개발 지시의 실체입니다. 아래 표는 화면 한 장에 들어가야 할 블록과, 그 블록이 비어 있을 때 어떤 상황이 생기는지를 함께 적었어요.
| 블록 | 적는 내용 | 비었을 때 생길 수 있는 일 |
|---|---|---|
| 화면 ID와 이름 | 고유 번호와 화면 이름 | 미팅에서 어느 화면 이야기인지 서로 다르게 이해하는 일이 생김 |
| 진입 경로 | 어느 화면에서 무엇을 눌러야 여기 오는지 | 어디에서도 갈 수 없는 고아 화면이 만들어지는 일이 생김 |
| 레이아웃 | 요소의 위치와 번호 | 설명과 그림을 서로 연결하지 못하는 일이 생김 |
| 요소별 설명 | 번호마다 무슨 일이 일어나는지 한 줄 | 개발자가 추측으로 만들고 검수에서 다투는 일이 생김 |
| 분기 | 조건에 따라 다르게 보이거나 다르게 이동하는 경우 | 로그인 여부, 권한, 결제 상태별 화면이 통째로 빠지는 일이 생김 |
| 예외와 오류 | 실패, 빈 목록, 시간 초과일 때 보이는 것 | 추가 개발로 잡히거나 그대로 출시되는 일이 생김 |
| 데이터 출처 | 이 화면의 값이 어디서 오는지, 누가 입력하는지 | 관리자 화면이 없어 데이터를 넣을 방법이 남지 않는 일이 생김 |
| 권한 | 누가 이 화면을 볼 수 있는지 | 회원 등급 기능이 착수 후 추가 견적으로 넘어가는 일이 생김 |
| 연결 화면 | 여기서 나갈 수 있는 화면 목록 | 흐름이 끊긴 구간을 개발 막바지에 발견하는 일이 생김 |
이 아홉 개 중에서 발주자가 직접 채울 수 있는 것이 적지 않아요. 진입 경로, 분기, 권한, 데이터 출처는 서비스를 어떻게 운영할 것인가에 대한 답이라 개발 지식이 필요하지 않습니다. 레이아웃과 요소별 설명 문장 다듬기는 개발사나 기획자에게 맡겨도 되고요. 무엇을 직접 쓰고 무엇을 맡길지는 뒤에서 다시 다룹니다.
화면설계서 양식을 찾는 검색이 많은데, 정작 중요한 건 파일 형태가 아니라 위의 블록이 다 들어 있는지예요. 어떤 양식을 받아도 요소별 설명과 예외 칸이 없으면 그 양식은 소용이 없습니다. 반대로 스프레드시트 한 장이어도 블록이 다 있으면 그건 제 역할을 해요.
양식은 보통 두 층으로 나눕니다. 첫 층은 화면 목록 시트로, 화면 ID와 이름, 상위 메뉴, 권한, 담당자, 상태를 한 줄씩 적어요. 둘째 층은 화면 상세 시트로, 화면 하나에 한 장을 쓰고 왼쪽에 그림, 오른쪽에 번호별 설명을 놓습니다. 이 두 층이 서로 화면 ID로 연결되어 있으면 어떤 도구로 만들어도 문제가 없어요.
양식을 고를 때 빠지기 쉬운 항목이 세 개 있습니다. 버전과 수정일을 적는 칸, 이 화면이 어느 요구사항에서 나왔는지 적는 칸, 그리고 확정 여부를 표시하는 칸이에요. 이 세 칸이 없으면 문서가 여러 벌 돌아다니기 시작할 때 어느 것이 기준인지 가리기 어려워집니다.
양식이 실제로 어떻게 생겼는지 감이 잡히지 않을 때는 화면 한 장을 먼저 채워 보는 편이 빠릅니다. 아래는 로그인 화면에 MB-01 이라는 화면 ID를 붙였다고 가정하고, 상세 시트의 오른쪽 칸을 채워 본 예시예요. 왼쪽에는 번호가 적힌 그림을 두고, 오른쪽에 이렇게 적으면 됩니다.
| 번호 | 화면 요소 | 동작 설명(분기와 예외 포함) |
|---|---|---|
| 1 | 이메일 입력란 | 형식이 맞지 않으면 입력란 아래에 안내 문구를 표시하고 다음 단계로 넘기지 않는다 |
| 2 | 비밀번호 입력란 | 입력값을 가려서 표시하고, 오른쪽 아이콘을 누르면 누르고 있는 동안만 원문을 보여준다 |
| 3 | 로그인 버튼 | 성공하면 홈(HM-01)으로 이동한다. 실패하면 입력란 위에 안내 문구를 노출하고 비밀번호 칸만 비운다 |
| 4 | 비밀번호 찾기 링크 | 비밀번호 재설정 화면(MB-03)으로 이동한다 |
| 5 | 회원가입 링크 | 회원가입 화면(MB-02)으로 이동한다 |
| 6 | 화면 전체 | 이미 로그인된 상태로 진입하면 홈으로 바로 보낸다. 통신에 실패하면 재시도 버튼이 있는 오류 문구를 노출한다 |
여섯 줄뿐이지만 이 안에 진입 경로, 요소별 동작, 분기, 예외가 모두 들어 있어요. 여기에 화면 ID와 이름, 권한(비로그인 사용자), 데이터 출처(입력값은 사용자가 직접 입력) 칸이 붙으면 이 한 장이 그대로 개발 지시가 되고 검수 항목이 됩니다. 나머지 화면도 같은 형식으로 채우면 그게 화면설계서예요. 그림 실력이나 도구 이름은 여기서 아무 역할도 하지 않습니다.
작성 순서를 정해 두면 중간에 되돌아가는 일이 줄어요. 순서 자체는 다섯 단계면 충분하고, 각 단계에서 다음으로 넘어가도 되는지 판단하는 기준이 더 중요합니다.
| 단계 | 이 단계에서 만드는 것 | 다음으로 넘어가도 되는 기준 |
|---|---|---|
| 1. 화면 목록 | 메뉴 구조를 펼친 화면 이름 목록 | 사람이 보게 될 화면이 전부 한 줄씩 적혀 있는가 |
| 2. 화면 ID 부여 | 영역 약자와 순번으로 만든 고유 번호 | 모든 줄에 번호가 있고, 같은 번호가 두 번 나오지 않는가 |
| 3. 화면별 블록 채우기 | 화면 한 장씩 아홉 개 블록 | 요소마다 눌렸을 때의 결과가 한 줄씩 적혀 있는가 |
| 4. 분기와 예외 훑기 | 화면별 예외 목록과 해당 없음 표시 | 비어 있는 칸이 없는가, 해당 없음도 적었는가 |
| 5. 확정 표시 | 버전, 확정일, 확정본 보관 위치 | 최신본이 어디에 있는지 한 곳으로 정해졌는가 |
순서를 지키는 이유는 하나예요. 화면 ID를 붙이기 전에 상세를 그리기 시작하면, 나중에 번호를 붙일 때 문서 전체를 다시 손봐야 합니다. 반대로 목록과 번호가 먼저 서 있으면 상세는 한 장씩 독립적으로 채울 수 있고, 여러 명이 나눠 써도 충돌하지 않아요.
1단계와 2단계는 아래 화면 목록 절에서, 3단계는 위의 블록 표와 예시에서, 4단계는 예외 절에서 각각 자세히 다룹니다. 5단계의 확정 표시는 문서 작업이 아니라 계약 이야기에 가까워서 뒤쪽 수정 요청 절에 따로 두었어요.
설명의 기준은 문장을 읽고 두 사람이 같은 결과를 떠올릴 수 있는가입니다. 눌리면 다음으로 넘어간다는 문장은 그 기준을 통과하지 못해요. 무엇이 저장되는지, 어디로 가는지, 실패하면 어떻게 되는지가 함께 있어야 합니다.
| 모호한 문장 | 왜 문제인가 | 확정 가능한 문장으로 |
|---|---|---|
| 확인 버튼을 누르면 저장된다 | 어디에 저장되고 다음에 무엇이 보이는지 없음 | 확인을 누르면 입력값을 서버에 저장하고 목록 화면으로 이동하며, 저장 완료 문구를 3초간 노출한다 |
| 검색 기능을 제공한다 | 무엇을 대상으로 어떻게 찾는지 없음 | 상품명과 브랜드명을 대상으로 부분 일치 검색하고, 결과가 없으면 빈 결과 화면을 보여준다 |
| 목록을 보여준다 | 정렬, 개수, 더 보기 방식이 없음 | 최신순으로 20개를 보여주고, 하단 더 보기를 누르면 20개씩 추가로 불러온다 |
| 로그인한 사용자만 이용 가능 | 비로그인 사용자가 들어왔을 때의 처리가 없음 | 비로그인 상태로 진입하면 로그인 화면으로 이동하고, 로그인 성공 후 원래 화면으로 되돌아온다 |
| 관리자가 승인한다 | 승인 화면이 어디에 있는지, 승인 후 알림이 있는지 없음 | 관리자 화면의 승인 대기 목록에서 승인하며, 승인 시 신청자에게 알림을 보낸다 |
오른쪽 문장들이 길어 보이지만, 이 정도가 적혀 있어야 견적을 내는 쪽에 추측할 자리가 남지 않아요. 왼쪽처럼 적힌 문서로 여러 곳에 견적을 받으면 회신 금액이 벌어지기도 하는데, 그때는 실력 차이보다 각 회사가 서로 다른 범위를 상상한 것이 원인일 수 있어요. 같은 문서를 받고도 다르게 읽힌다면 문서가 아직 확정되지 않은 겁니다.
여기서 말하는 수준은 그림의 정밀도가 아니라 문장의 확정 수준이에요. 손으로 대충 그린 사각형 옆에 위 오른쪽 칸 같은 문장이 붙어 있으면 그건 쓸 수 있는 문서이고, 정교한 화면 그림에 왼쪽 칸 같은 문장만 붙어 있으면 아직 아닙니다. 견적을 같은 축에 놓고 비교하는 방법은 앱 개발 견적서 뜯어보는 법에서 자세히 다뤘습니다.
화면설계서를 처음 그릴 때는 잘 풀리는 경로부터 그리게 되기 쉬워요. 회원가입하고, 상품을 담고, 결제하고, 완료 화면을 보는 흐름이요. 실제 서비스에서는 그 경로를 벗어나는 상황이 반복적으로 생기는데도 그렇습니다. 그런데 개발 공수는 잘 풀리는 경로에서만 나오지 않아요.
빠지기 쉬운 상황을 목록으로 갖고 다니면 도움이 됩니다. 화면마다 아래 항목을 훑고, 해당 없음이면 해당 없음이라고 적어두세요. 비어 있는 칸과 해당 없음이라고 적힌 칸은 검수할 때 완전히 다른 의미를 가집니다.
| 예외 상황 | 화면설계서에 적을 것 | 안 적었을 때 생길 수 있는 일 |
|---|---|---|
| 목록이 비어 있음 | 빈 화면 문구와 다음 행동 버튼 | 흰 화면만 나와 오류로 오인되는 일이 생김 |
| 불러오는 중 | 로딩 표시 위치와 형태 | 사용자가 버튼을 여러 번 눌러 중복 처리되는 일이 생김 |
| 네트워크 실패 | 오류 문구와 재시도 버튼 | 앱이 멈춘 것처럼 보이는 일이 생김 |
| 권한 없음 | 차단 문구와 이동할 화면 | 다른 사람 데이터가 그대로 보이는 사고로 이어지는 일이 생김 |
| 입력값 오류 | 어느 항목이 왜 틀렸는지 표시 위치 | 사용자가 원인을 모른 채 이탈하는 일이 생김 |
| 중복 신청 또는 중복 결제 | 기존 건을 보여줄지 막을지 | 운영에서 수동으로 처리하게 되는 일이 생김 |
| 만료와 취소 | 기한이 지난 항목의 표시와 처리 | 지난 데이터가 계속 노출되는 일이 생김 |
| 뒤로 가기와 중간 이탈 | 작성 중이던 내용을 남길지 버릴지 | 사용자 입력이 사라지고 문의가 늘어나는 일이 생김 |
이 표를 화면 목록 옆에 붙여 두고 한 화면씩 지워 나가면, 그 항목들이 착수 후에 새로 논의할 대상에서 빠집니다. 지금 문서에 적어 두는 것과 개발 중에 발견해 협의하는 것의 차이일 뿐이에요. 범위를 문서로 굳히는 절차 전반은 MVP 범위 확정 절차에 정리해 두었습니다.
화면설계서를 그리기 전에 화면 목록부터 만듭니다. 메뉴 구조를 위에서 아래로 펼치고, 각 항목에 화면 ID를 붙이는 작업이에요. 이 목록이 곧 견적서의 행이 되고, 개발 일정의 단위가 되고, 검수 체크리스트가 됩니다.
번호 체계는 복잡할 필요가 없어요. 영역을 두세 글자로 표시하고 그 안에서 순번을 붙이는 정도면 충분합니다. 예를 들어 회원 영역을 MB, 주문을 OD, 관리자를 AD로 두고 MB-01, MB-02처럼 적는 식이에요. 중요한 건 규칙의 정교함이 아니라 한 번 붙인 번호를 끝까지 바꾸지 않는 것입니다.
번호를 재사용하지 마세요. 삭제한 화면의 번호를 새 화면에 다시 쓰면, 이전 회의록과 변경 요청서가 가리키는 대상이 달라집니다. 삭제된 화면은 목록에 남겨 두고 상태만 삭제로 표시하는 편이 추적에 유리해요. 화면 흐름을 먼저 잡는 방법은 IT 프로젝트 기획 가이드에서 다뤘습니다.
국내 외주 시장의 현장 견적에서는 화면 단위로 공수를 잡는 방식이 자주 쓰여요. 공표된 표준 산정 방식이 있는 것은 아니고, 회사마다 다릅니다. 화면 수가 곱해지는 구조라면 화면 하나를 어떻게 세느냐에 따라 총액이 달라져요. 그런데 화면을 세는 규칙도 회사마다 달라서, 같은 서비스를 두고 각 회사가 적어 오는 화면 수가 서로 달라지는 상황이 생깁니다.
| 세는 방식이 갈리는 지점 | 적게 세는 쪽 | 많게 세는 쪽 | 발주자가 물어야 할 질문 |
|---|---|---|---|
| 목록과 상세와 등록과 수정 | 한 기능으로 묶어 1개 | 각각 별도 화면으로 4개 | 이 견적에서 화면 하나의 정의가 무엇인가요 |
| 팝업과 모달 | 화면으로 세지 않음 | 별도 화면으로 셈 | 팝업과 바텀시트는 화면 수에 포함되나요 |
| 예외와 빈 상태 | 포함하지 않음 | 상태별로 셈 | 오류와 빈 화면은 어느 항목에 들어가 있나요 |
| 관리자 화면 | 별도 계약으로 분리 | 같은 견적에 포함 | 관리자 화면은 몇 개이고 이 금액에 들어 있나요 |
| 모바일과 PC | 반응형 하나로 셈 | 화면당 두 벌로 셈 | PC 화면은 별도로 설계하나요 반응형인가요 |
| iOS와 안드로이드 | 공통 1벌 | 플랫폼별 2벌 | 플랫폼별로 화면설계서가 나뉘나요 |
견적을 비교할 때는 금액보다 이 정의를 먼저 맞춰야 해요. 화면 목록을 우리가 만들어서 여러 곳에 같은 파일로 보내면, 회신 금액을 같은 축에서 읽을 수 있습니다. 그렇게 하지 않으면 낮은 금액을 부른 곳이 실은 화면을 적게 세었을 뿐인 경우를 걸러내지 못해요.
참고로 화면 수는 개발 공수의 유일한 변수가 아닙니다. 화면이 적어도 결제, 정산, 외부 연동, 권한 체계가 들어가면 공수는 화면 수와 별개로 늘어나요. 화면 수는 비교의 출발점이지 결론이 아니라는 점을 견적서에 함께 확인해 두는 편이 안전합니다.
정답은 하나가 아니고, 우리 쪽에 결정된 것이 얼마나 있느냐로 갈립니다. 서비스 흐름과 운영 규칙이 머릿속에 이미 서 있다면 초안을 직접 그리는 편이 빠르고, 아직 흐름 자체를 탐색 중이라면 설계를 유상 계약으로 분리해 맡기는 편이 낫습니다. 문제는 아무것도 정하지 않은 채 개발사에 던지면서 비용은 개발비에 포함되기를 기대하는 경우예요.
발주자 몫과 개발사 몫을 어떻게 가르는지는 화면설계서만의 문제가 아니라 기획 전반의 문제라서 MVP 기획 단계에 뭘 들고 가야 하나에서 따로 다뤘어요. 여기서는 화면설계서에 한정해, 방식을 정한 뒤 계약에서 무엇을 문장으로 남겨야 하는지만 봅니다.
| 방식 | 맞는 상황 | 발주자가 감수할 것 | 계약에서 확인할 것 |
|---|---|---|---|
| 발주자가 직접 작성 | 운영 규칙과 흐름이 이미 정해져 있음 | 작성 시간과 초안 품질 편차 | 우리 문서를 기준 문서로 인정하는지, 개발사가 검토 의견을 언제 주는지 |
| 설계를 별도 계약으로 위탁 | 흐름 자체를 함께 정리해야 함 | 설계 비용이 별도로 발생 | 산출물 목록과 수정 횟수, 설계 문서의 저작권과 반출 가능 여부 |
| 개발 계약에 포함해 개발사가 작성 | 범위가 작고 참고할 유사 서비스가 뚜렷함 | 범위 해석이 개발사 쪽으로 기울 수 있음 | 확정 시점과 확정 이후 수정 처리 방식 |
| 공동 작성 | 운영 규칙은 우리가, 화면 구성은 개발사가 아는 경우 | 회의 횟수 증가 | 누가 최종본을 보관하고 버전을 관리하는지 |
어느 방식이든 계약 문서에 문장으로 남겨야 하는 항목은 다섯 가지입니다. 설계 산출물의 목록(화면 목록 시트와 화면 상세를 각각 몇 장 받는지), 설계 확정 시점, 확정 이후 수정 요청을 어떻게 처리하는지, 수정 횟수 상한과 그 이상은 어떻게 계산하는지, 그리고 설계 문서의 저작권과 반출 가능 여부예요.
설계를 별도 계약으로 분리했다면 한 줄을 더 적어 두세요. 그 계약이 끝난 뒤 산출물을 다른 개발사에 넘겨 개발 계약을 맺을 수 있는지입니다. 설계만 받고 개발은 다른 곳에 맡길 가능성이 조금이라도 있다면 이 문장이 있어야 해요. 공동 작성일 때는 최종본 보관 주체와 버전 관리 주체가 자주 비어 있는 칸이니, 계약서에 없으면 킥오프에서라도 정해 두는 편이 좋습니다.
도구 이름을 먼저 정하는 순서는 권하지 않습니다. 문서를 주고받는 방식이 정해지면 도구는 따라오는 편이 자연스러워요. 도구 종류는 크게 네 갈래이고, 각자 잘하는 지점이 다릅니다.
첫째는 문서와 스프레드시트예요. 화면 목록과 설명 표를 관리하기에 좋고, 누구나 열 수 있으며, 이력이 남습니다. 그림은 이미지로 붙이게 되어 배치 수정이 번거로워요. 둘째는 슬라이드 도구입니다. 화면 한 장에 한 슬라이드를 쓰는 방식이 직관적이고 인쇄와 공유가 쉬운데, 요소별 설명이 길어지면 슬라이드가 넘칩니다.
셋째는 화면 설계 전용 협업 도구입니다. 요소 위에 직접 코멘트를 달 수 있고 여러 명이 동시에 보는 데 강해요. 대신 계정이 있어야 열람할 수 있어서 계약 종료 후 접근권이 문제가 됩니다. 넷째는 다이어그램 도구로, 화면 사이의 이동 흐름을 그리는 데 적합하고 화면 내부 설명에는 약합니다.
| 확인할 기준 | 왜 중요한가 | 미리 물어볼 문장 |
|---|---|---|
| 열람 권한 | 계약이 끝난 뒤에도 우리가 열 수 있어야 함 | 계약 종료 후에도 이 문서를 우리 계정으로 계속 볼 수 있나요 |
| 내보내기 | 도구를 바꾸거나 개발사를 교체할 때 필요 | PDF나 이미지로 전체를 내보낼 수 있나요 |
| 버전 이력 | 무엇이 언제 바뀌었는지 확인할 근거가 됨 | 확정본 시점으로 되돌려 볼 수 있나요 |
| 코멘트 위치 | 어느 요소 이야기인지 오해를 줄임 | 화면 요소에 직접 의견을 달 수 있나요 |
| 비개발자 접근성 | 운영팀과 대표가 직접 봐야 함 | 설치 없이 링크로 열리나요 |
| 소유 계정 | 파일이 개발사 계정에만 있으면 인수인계가 막힘 | 원본 파일의 소유자를 우리 계정으로 둘 수 있나요 |
도구 선택에서 발주자가 실제로 손해를 보는 지점은 기능이 아니라 마지막 두 줄이에요. 문서가 개발사 계정 안에만 있으면, 개발사를 바꾸는 순간 설계서를 다시 만들어야 합니다. 계약서에 산출물로 화면설계서 원본 파일을 명시하고 소유 계정을 우리 쪽으로 두면, 개발사가 바뀌어도 문서는 우리 손에 남아요. 산출물 목록과 인수인계 항목을 통째로 합의하는 자리는 킥오프 미팅이라, 전체 목록은 킥오프 미팅 체크리스트에 정리돼 있습니다.
AI 기능이 들어간 화면은 결과가 매번 달라서 정상 화면을 하나로 그릴 수 없습니다. 그래서 화면설계서에 결과 예시만 붙여 두면 검수 단계에서 기준이 사라져요. 이 화면에서 적어야 할 것은 결과물이 아니라 결과를 둘러싼 규칙입니다.
구체적으로는 다섯 가지를 적습니다. 입력에 어떤 제한이 있는가, 처리 중에는 무엇이 보이는가, 실패하거나 답변을 거절할 때 어떤 화면이 나오는가, 결과의 근거를 어디까지 보여주는가, 사람이 개입해서 고칠 수 있는 경로가 있는가. 이 다섯 개가 적혀 있으면 결과가 매번 달라도 검수가 가능해요.
AI 자체가 제품의 중심인 경우는 설계 방식이 또 달라집니다. 챗봇, 문서 검색, RAG처럼 모델과 데이터 파이프라인이 핵심인 프로젝트는 화면보다 데이터와 평가 기준을 먼저 설계해야 해요. 포텐랩은 MVP와 앱, 웹 프로덕트 개발을 맡고, AI 자체가 제품인 영역은 트리숲(TreeSoop)이 맡습니다. 우리 프로젝트가 화면 중심인지 모델 중심인지 먼저 가르면 맞지 않는 쪽에 견적을 요청하느라 시간을 쓰지 않아도 돼요.
세 문서는 같은 내용을 다른 층에서 적습니다. 요구사항은 무엇이 필요한가, 기능 명세는 그래서 무슨 기능을 만드는가, 화면설계서는 그 기능이 어느 화면에서 어떻게 동작하는가예요. 층이 다르니 하나로 합치려 하면 어느 층이 비게 됩니다.
연결은 번호로 합니다. 요구사항에 번호를 붙이고, 기능 명세에 그 요구사항 번호를 적고, 화면설계서에 기능 번호를 적어 두는 식이에요. 이렇게 해 두면 화면 하나를 지웠을 때 어떤 요구사항이 갈 곳을 잃는지 바로 보입니다. 반대로 어떤 요구사항이 어느 화면에도 매핑되지 않았다면 그건 아직 설계되지 않은 거예요.
발주자 입장에서 이 추적표는 검수할 때 쓰입니다. 완성본을 받아 들고 요구사항 번호를 따라가면, 무엇이 구현되었고 무엇이 빠졌는지 감이 아니라 목록으로 확인할 수 있어요. 이 절이 소유하는 것은 세 문서를 번호로 잇는 추적표까지이고, 각 문서를 실제로 쓰는 방법은 다른 글에 있습니다. 기능 명세를 정리하는 방법은 앱 아이디어를 기능 명세서로 만드는 방법에서 다뤘어요.
받은 문서를 처음부터 끝까지 읽는 방식은 시간이 오래 걸리고 놓치는 것도 많아요. 대신 아래 질문을 순서대로 던지면 빈 곳이 빠르게 드러납니다. 오른쪽 칸은 그 답이 문서에 없을 때 생기는 상황이고, 반복적으로 관찰되는 자리이기도 해요.
| 확인 질문 | 답이 문서에 없으면 생길 수 있는 일 |
|---|---|
| 화면 목록의 개수와 상세 장수가 일치하나요 | 목록에는 있는데 상세가 없는 화면을 착수 후에 발견하는 일이 생김 |
| 모든 버튼에 눌렀을 때의 목적지가 적혀 있나요 | 화면 목록만 있고 동작 설명이 없어 견적에는 쓰이지만 개발 지시로는 못 쓰는 일이 생김 |
| 빈 목록과 오류 화면이 문서에 있나요 | 예쁜 화면 여러 장이 왔는데 예외가 한 장도 없는, 디자인 시안이 설계를 대체한 상태가 되는 일이 생김 |
| 관리자 화면이 있고 그 안에서 데이터를 넣고 고칠 수 있나요 | 출시 후 데이터 수정을 개발사에 계속 요청하게 되는 일이 생김 |
| 로그인과 회원 상태에 따른 분기가 적혀 있나요 | 등급과 권한별 화면이 착수 후 추가 견적으로 넘어가는 일이 생김 |
| 화면에 보이는 값이 어디서 오는지 적혀 있나요 | 데이터를 넣을 경로가 설계에 없는 채로 개발이 끝나는 일이 생김 |
| 안내 문구와 오류 문구가 실제 문장으로 확정되어 있나요 | 문구 확정이 밀리면서 개발과 검수가 함께 밀리는 일이 생김 |
| 표지에 버전과 날짜가 있고 최신본 위치가 한 곳으로 정해져 있나요 | 메일과 메신저와 협업 도구의 문서가 조금씩 달라, 개발자가 자기가 본 버전대로 만드는 일이 생김 |
답이 문서 안에 없으면 그 자리가 나중에 추가 견적이 될 자리예요. 여덟 번째 항목은 특히 관리 문제로 보이지만 실제로는 개발 결과를 가릅니다. 최신본 위치를 한 곳으로 정하고 나머지는 링크만 두면 됩니다.
화면설계서를 어떻게 쓰고 어떻게 관리하는지 자체가 개발사를 판별하는 질문이기도 해요. 같은 항목이 개발사 기술 역량 검증 체크리스트에도 들어 있으니 업체를 고르는 단계라면 함께 보세요. 완성물을 받는 단계의 검수 절차 전반은 산출물 검수와 사인오프 가이드에 정리했습니다.
설계 없이도 견적은 나옵니다. 다만 나오는 견적의 성격이 달라져요. 같은 서비스를 두고 문서가 있을 때와 없을 때 무엇이 달라지는지 정리하면 아래와 같습니다.
| 항목 | 화면설계서가 있을 때 | 없을 때 |
|---|---|---|
| 견적서의 형태 | 화면 목록이 그대로 행이 되어 항목별로 갈라짐 | 총액 한 줄이나 기능 대분류 몇 줄로 옴 |
| 여러 곳 비교 | 같은 문서를 기준으로 회신을 나란히 놓을 수 있음 | 각 회사가 상상한 범위가 달라 같은 축에서 읽기 어려움 |
| 착수 후 논의 | 문서에 없는 것만 새로 논의함 | 무엇이 범위 안이었는지부터 다시 이야기하게 됨 |
| 검수 기준 | 문서와 결과물을 한 항목씩 대조함 | 대조할 원본이 없어 서로 다르게 기억한 내용을 맞춰 보게 됨 |
| 일정 확인 | 화면 단위로 진척을 셀 수 있음 | 완료 여부를 개발사 설명에 의존하게 됨 |
그래서 설계 없이 받은 견적은 금액이 아니라 가정을 읽어야 해요. 견적서 어딘가에 화면 수나 기능 목록이 적혀 있다면 그게 그 회사가 상상한 범위입니다. 적혀 있지 않다면 물어서 받아 적으세요. 회신을 받아 적는 것만으로도 나중에 범위를 다툴 때 기준이 하나 생깁니다.
설계를 아직 만들지 못한 단계라면 설계를 별도 항목으로 분리한 견적을 요청하는 방법도 있어요. 설계 비용과 개발 비용이 한 덩어리로 오면 설계가 얼마나 들어가는지 보이지 않고, 설계만 받고 다른 곳에 개발을 맡기는 선택지도 사라집니다. 분리해서 받으면 두 가지가 다 보여요.
화면설계서는 확정 시점이 있는 문서예요. 그 시점 이후의 변경은 일정과 금액에 영향을 주고, 그래서 처리 절차가 필요합니다. 확정이라는 단어가 계약서 어디에도 없으면 개발 내내 설계가 흔들려요.
확정본을 어떻게 잠그고, 변경을 어떤 문서로 요청하며, 영향 회신을 언제까지 받을지는 변경 관리 절차 전체의 문제라 변경 요청서(CR) 작성 가이드에서 단계별로 다뤘습니다. 여기서는 화면설계서 쪽에서만 지켜야 하는 것을 봅니다.
변경 요청은 화면 ID를 기준으로 적으세요. 어느 화면의 몇 번 요소를 어떻게 바꾸는지 적고, 그 변경이 다른 화면에 미치는 영향을 함께 적는 것입니다. 로그인 화면(MB-01)의 3번 버튼 동작을 바꾸면 회원가입 화면과 재설정 화면의 진입 경로가 함께 흔들리는 식이에요. 앞의 아홉 개 블록 중 연결 화면 칸이 바로 이 단계에서 쓰입니다. 그 칸이 채워져 있으면 영향 범위를 문서에서 읽을 수 있고, 비어 있으면 사람의 기억에 의존하게 돼요.
변경을 반영한 뒤에는 버전과 확정일을 올리고, 이전 확정본은 지우지 말고 남겨 두세요. 무엇이 언제 바뀌었는지 대조할 자리가 필요합니다. 문제가 되는 건 변경 자체가 아니라, 변경이 구두로 오간 뒤 서로 다르게 기억하는 상황이에요.
화면설계서 이야기를 처음 꺼내는 자리라면 문서를 요구하기 전에 정의부터 맞추세요. 우리 쪽에서 화면설계서라고 부르는 문서에 무엇이 들어가는지 아홉 개 블록으로 말하고, 그 형태로 주고받자고 제안하면 됩니다. 정의를 먼저 맞춰 두면 견적과 개발, 검수가 같은 문서를 기준으로 돌아가요.
그다음 요구할 문장은 두 개면 시작할 수 있습니다. 이 견적에서 화면 하나의 정의가 무엇인지 알려주세요, 그리고 원본 파일의 소유 계정을 우리 쪽으로 두는 것이 가능한지 알려주세요. 앞의 질문은 회신 금액을 같은 축에 올려놓기 위한 것이고, 뒤의 질문은 개발사를 바꾸게 될 때 문서가 우리 손에 남는지를 정하는 것이에요. 관리자 화면과 예외 화면의 포함 여부는 위 검수 질문 표에 그대로 있으니, 그 표를 미팅에 들고 가면 됩니다. 이 두 가지에 대한 답변을 받아 보면 개발사마다 일하는 방식이 드러납니다.
화면설계서를 아직 만들지 못한 상태라도 괜찮아요. 포텐랩은 착수 전에 화면 목록과 예외 화면을 문서로 합의하고, 그 합의문을 검수 기준으로 씁니다. 화면 목록 초안과 운영 규칙 메모만 있으면 나머지는 함께 채워 나갈 수 있어요. 참고로 자체 집계 기준 수행완수율은 97%인데, 이건 회사 전체 프로젝트 실적이지 이 절차 하나의 효과로 측정한 값은 아닙니다.
와이어프레임은 요소의 위치와 크기를 잡은 화면 뼈대이고, 화면설계서는 그 배치에 요소별 동작 설명과 분기, 예외, 데이터 출처까지 붙인 문서예요. 가르는 기준은 개발자가 그 문서만 보고 코드를 작성할 수 있는가입니다. 배치를 보며 논의하는 용도면 와이어프레임, 개발 지시로 쓸 수 있으면 화면설계서라고 보면 됩니다. 스토리보드는 국내 개발 현장에서 화면설계서와 같은 뜻으로 쓰이는 경우가 있지만 정의가 회사마다 달라서, 이름보다 그 안에 무엇이 들어가는지를 확인하는 편이 정확해요.
화면 목록을 먼저 만들고, 각 화면에 화면 ID를 붙이고, 화면별로 아홉 개 블록을 채우고, 분기와 예외를 훑고, 버전과 확정일을 표시하는 다섯 단계입니다. 각 단계에서 다음으로 넘어가는 기준은 그 단계의 칸이 비어 있지 않은가예요. 예외 항목은 해당 없음이라고 적은 칸과 아예 비어 있는 칸이 검수할 때 의미가 다르니 해당 없음도 적어 둡니다. 화면 ID를 붙이기 전에 상세부터 그리기 시작하면 나중에 번호를 붙일 때 문서 전체를 다시 손봐야 해서, 순서를 지키는 편이 좋아요.
화면 ID와 이름, 진입 경로, 레이아웃, 요소별 설명, 분기, 예외와 오류, 데이터 출처, 권한, 연결 화면 아홉 개 블록이 기본입니다. 여기에 버전과 수정일, 이 화면이 나온 요구사항 번호, 확정 여부 표시 칸을 더하면 문서가 여러 벌 돌아다닐 때 어느 것이 기준인지 가릴 수 있어요. 파일 형태보다 이 블록이 다 있는지가 기준이라, 화면 목록 시트와 화면 상세 시트를 화면 ID로 연결해 두면 스프레드시트 한 장으로도 제 역할을 합니다.
우리 쪽에 운영 규칙과 흐름이 이미 정해져 있으면 직접 초안을 그리는 편이 빠르고, 흐름 자체를 탐색 중이라면 설계를 별도 계약으로 맡기는 방식이 낫습니다. 어느 방식을 택하든 계약 문서에는 다섯 가지를 문장으로 남겨 두세요. 설계 산출물의 목록, 설계 확정 시점, 확정 이후 수정 요청 처리 방식, 수정 횟수 상한과 초과분 계산, 설계 문서의 저작권과 반출 가능 여부입니다. 공동 작성이라면 최종본을 누가 보관하고 버전을 관리하는지도 함께 적습니다.
국내 외주 시장의 현장 견적에서는 화면 단위로 공수를 잡는 방식이 자주 쓰여서 화면 수가 총액에 영향을 줍니다. 다만 공표된 표준 산정 방식이 있는 것은 아니고 회사마다 다릅니다. 목록과 상세를 한 개로 세는지 네 개로 세는지, 팝업과 예외 화면과 관리자 화면을 포함하는지가 갈리기 때문에, 견적을 비교하기 전에 화면 목록을 우리가 만들어 같은 파일로 보내고 이 견적에서 화면 하나의 정의가 무엇인지 물어야 해요. 결제나 외부 연동, 권한 체계가 들어가면 공수는 화면 수와 별개로 늘어납니다.
넣어야 합니다. 빈 목록, 로딩 중, 네트워크 실패, 권한 없음, 입력값 오류, 중복 처리, 만료와 취소, 뒤로 가기 같은 상황은 화면설계서에서 반복적으로 빠지고, 빠진 항목은 착수 후에 새로 논의할 대상이 됩니다. 화면마다 이 목록을 훑고 해당 없음이면 해당 없음이라고 적어 두세요. 비어 있는 칸과 해당 없음이라고 적힌 칸은 검수할 때 의미가 완전히 다릅니다.