화면설계서 작성법 2026 — 화면 정의서 항목·예시와 IA·와이어프레임 연결 8단계

화면설계서와 화면 정의서는 같은 문서다

먼저 용어부터 정리한다. 찾을 때 헷갈리는 이유가 이름이 여러 개이기 때문이다.

다섯 다 같은 것을 가리킨다. 화면 하나하나가 어떻게 생겼고 어떻게 동작하는지를 적은 문서다.

굳이 구분하자면 「설계서」는 개발에 넘기는 완성본, 「정의서」는 좀 더 이른 단계라는 뉘앙스가 있지만 현업에서는 섞어 쓴다. 발주처가 어느 쪽으로 부르든 같은 것을 요구하는 것이니 용어에 걸려 시간 쓸 필요가 없다.

「화면 명세서」만 한 번 짚어 둔다. 공공·금융 발주에서는 요구사항명세서·인터페이스명세서처럼 산출물 이름을 「명세서」로 통일하는 경우가 있어, 같은 문서를 화면 명세서로 부른다. 이때도 요구하는 내용은 아래 8가지로 동일하다. 다만 요구사항명세서와는 다른 문서다 — 요구사항명세서는 "무엇이 필요한가"를 요구사항 단위로 적고, 화면 명세서는 그 요구가 화면에서 어떻게 보이고 동작하는지를 화면 단위로 적는다. 상류 문서의 작성법은 요구사항정의서 쓰는 법에 정리했다.

문서 전체 지도가 필요하다면 외주 개발 산출물 문서 총정리에 누가 언제 무엇을 쓰는지 정리했다.

이 문서가 프로젝트 비용을 결정한다

화면설계서를 대충 넘기면 비용이 뒤에서 몇 배로 돌아온다.

⚠️ 위 배수는 업계에서 통용되는 경험칙이고 프로젝트마다 다르다. 다만 방향은 예외 없다 — 늦게 고칠수록 비싸다.

그래서 화면설계서 검토는 발주처가 가장 시간을 많이 써야 하는 단계다. 그런데 실무에서는 여기를 가장 빨리 넘긴다.

화면설계서에 반드시 들어가는 8가지

문서 형식은 자유지만 아래 항목이 빠지면 개발이 못 나간다. 하나씩 본다.

1. 화면 ID — 규칙부터 정한다

번호가 없으면 "회원 목록 화면 말고 그 옆에 있는 거요" 같은 대화가 오간다.

MEM-001  회원 목록
MEM-002  회원 상세
MEM-003  회원 등록
ORD-001  주문 목록

업무 영역 3자 + 일련번호면 충분하다. 이 번호를 메뉴 구조도(IA)의 트리에 그대로 달아 두면 화면 목록과 메뉴가 한 장에서 맞춰진다. 이 ID가 나중에 기능 정의서·테스트 시나리오·검수 확인서에 그대로 쓰인다.

규칙을 정할 때 지켜야 할 것이 세 가지 있다.

팝업·모달에도 번호를 준다. MEM-003-P01처럼 부모 화면 뒤에 붙이면 어디서 뜨는 팝업인지가 ID 만으로 드러난다. 번호 없는 팝업이 검수 때 "이건 화면 수에 포함이냐"로 다툼이 되는 단골 항목이다.

4. 입력 항목 정의 — 여기가 가장 많이 빈다

화면에 입력칸이 있으면 칸마다 아래를 적어야 한다.

"연락처 필수"만 적혀 있으면 개발자가 형식을 임의로 정한다. 나중에 010-1234-5678과 01012345678이 섞여 들어가고, 그걸 정리하는 비용이 다시 든다.

5. 버튼 동작 — 누르면 무슨 일이 나는가

버튼마다 세 가지를 적는다.

• 조건 — 언제 활성화되는가 (예: 필수 항목이 다 찼을 때)
• 동작 — 무엇을 하는가 (저장 / 삭제 / 조회)
• 이후 — 어느 화면으로 가는가, 무슨 메시지가 뜨는가

[저장] 버튼
  조건: 필수 항목(회원명·연락처) 입력 완료 시 활성화
  동작: 회원 정보 저장
  성공: "저장되었습니다" 알림 → MEM-001 목록으로 이동
  실패: "이미 등록된 연락처입니다" 알림 → 현재 화면 유지, 연락처 칸에 포커스

실패 케이스를 안 적으면 그 경우 화면이 멈춘다. 개발자가 상상해서 만들거나, 아예 처리를 안 한다.

6. 권한별 노출 — 나중에 넣는 기능이 아니다

"일단 다 보이게 하고 권한은 나중에"가 가장 비싼 요청이다. 권한은 데이터를 가져오는 구조 자체에 들어가기 때문에 뒤에 넣으면 대부분을 다시 짠다.

화면마다 이 표를 붙인다.

⚠️ "안 보인다"와 "못 바꾼다"는 다르다. 화면에서 버튼만 숨기고 서버에서 막지 않으면 보안 구멍이 된다. 문서에 "조회 전용은 삭제 불가"라고 적혀 있어야 개발자가 서버에서도 막는다.

화면설계서 예시 — 회원 등록 화면 하나를 끝까지

항목 설명만 읽으면 감이 안 잡힌다. 화면 한 장이 문서에서 실제로 어떻게 생겼는지를 통째로 본다. 아래가 개발에 그대로 넘길 수 있는 최소 단위다.

MEM-003 · 회원 등록

레이아웃

┌──────────────────────────────────────────┐
│  회원 등록                                │
├──────────────────────────────────────────┤
│  회원명   [________________]  *필수       │
│  연락처   [________________]  *필수       │
│  가입일   [2026-09-21    ▾]  *필수       │
│  등급     [ 일반        ▾ ]              │
│  메모     [________________]             │
│           [________________]             │
├──────────────────────────────────────────┤
│                      [취소]  [저장]       │
└──────────────────────────────────────────┘

입력 항목

버튼 동작

예외 처리 — 여기가 빠지면 개발자가 지어낸다.

데이터 출처

이 한 장이 있으면 개발자가 물어볼 것이 없다. 반대로 「회원 등록 화면 필요」 한 줄만 있으면 위 표의 모든 칸을 개발자가 임의로 정한다. 그 결정들이 나중에 전부 수정 요청이 된다.

예시로 만들 화면을 고를 때는 입력이 가장 많은 화면 하나를 먼저 완성해 보길 권한다. 그 한 장을 템플릿 삼아 나머지를 채우면 항목 누락이 크게 준다.

IA(정보구조도)에서 화면 목록을 뽑는 순서

화면설계서를 바로 그리기 시작하면 화면이 빠진다. 먼저 전체 구조를 세운 뒤 화면을 나열하는 편이 안전하다.

1. 사용자 유형 나열          관리자 / 담당자 / 조회 전용
2. 유형별 할 일 나열          "회원을 등록한다", "월별 통계를 본다"
3. 할 일 하나당 화면 도출      등록 → 입력 화면 + 완료 화면
4. 공통 화면 추가            로그인 / 오류 / 권한없음 / 검색결과 없음
5. 화면 ID 부여
6. 메뉴 구조도(IA)로 묶기

4번을 빠뜨리는 경우가 많다. 로그인 실패, 권한 없음, 검색 결과 0건, 네트워크 오류 — 이런 화면이 문서에 없으면 개발자가 임의로 만들거나 빈 화면이 나온다.

와이어프레임·프로토타입과 무엇이 다른가

화면설계서는 와이어프레임에 규칙을 붙인 것이라고 보면 정확하다. 그림만 있으면 와이어프레임이고, 그림 옆에 입력 규칙·버튼 동작·권한이 붙으면 화면설계서다.

피그마로 만들 때 주의할 점

요즘은 문서 도구 대신 피그마에서 화면설계서를 만드는 경우가 많다. 그림과 설명을 한 화면에서 보는 이점이 크다.

다만 두 가지를 조심한다.

① 텍스트가 검색되지 않으면 문서가 아니다 설명을 이미지로 넣으면 나중에 "연락처 형식이 어디 적혀 있더라"를 못 찾는다. 텍스트 레이어로 쓴다.

② 버전이 흘러가면 합의 시점이 사라진다 피그마는 계속 수정되므로, 개발 착수 시점의 상태를 PDF로 내려 계약 산출물로 남긴다. 나중에 "그때 이렇게 합의했다"의 근거가 된다.

표지와 수정 이력 — 가장 먼저 넘겨보는 두 장

본문 화면부터 그리는 경우가 많은데, 검토자가 실제로 가장 먼저 보는 건 표지와 이력이다. 이 두 장이 없으면 "어느 버전을 보고 있는지" 부터 헷갈린다.

표지에 들어갈 것은 문서 제목, 프로젝트명, 버전(v1.0), 작성일, 작성자, 그리고 승인자 서명란이다. 승인자 칸이 없으면 "이 문서로 확정한다"는 순간이 문서에 남지 않는다.

수정 이력은 표로 관리한다.

⚠️ 변경 내용을 "수정"이라고만 적으면 이력이 아니다. 무엇이 몇 개 늘었는지를 적어야 나중에 추가 개발 범위를 다툴 때 근거가 된다. 화면이 42개에서 45개로 늘어난 게 기록에 있으면 그건 협상이 아니라 사실 확인이다.

피그마·파워포인트·노션 — 무엇으로 만들 것인가

툴은 취향이 아니라 프로젝트 성격으로 고른다.

⚠️ 툴이 무엇이든 PDF 스냅샷을 버전마다 남겨라. 피그마 링크만 넘기면 나중에 "그때 그 화면"을 못 되살린다. 링크는 항상 최신을 가리키기 때문이다. 계약 시점의 v1.0 PDF가 있어야 범위 분쟁에서 기준이 생긴다.

AI로 화면설계서 초안을 만드는 법 — 그리고 맡기면 안 되는 부분

생성형 AI로 화면설계서 초안을 뽑는 시도가 늘고 있다. 결론부터 말하면 초안 작성에는 확실히 쓸모가 있고, 확정에는 쓰면 안 된다.

AI가 잘하는 것

AI에 맡기면 안 되는 것

실무 순서는 이렇게 잡는 편이 안전하다.

1. 사람이 화면 목록과 업무 규칙을 먼저 쓴다. 여기서 AI를 쓰면 그럴듯한 가짜 규칙이 섞인다.
2. AI에게 각 화면의 입력 항목·예외·검증 규칙 초안을 채우게 한다. 이 단계가 가장 손이 많이 가고, AI가 가장 잘한다.
3. AI에게 누락 점검을 시킨다. "이 화면 목록에서 빠진 공통 화면은?", "예외가 안 적힌 항목은?"
4. 사람이 전수 검토한다. 특히 업무 규칙과 권한은 한 줄씩 확인한다.

⚠️ AI가 만든 초안을 그대로 계약 부속서로 넘기는 것이 가장 위험하다. 검증되지 않은 규칙이 과업 범위로 굳어지고, 나중에 "문서에 그렇게 적혀 있다"가 근거가 된다. 과업 범위를 문서로 묶는 방법은 과업지시서 작성 가이드에 따로 정리했다.

발주처가 검토할 때 봐야 할 것

개발사가 화면설계서를 주면 아래 다섯 가지만 확인해도 대부분의 사고를 막는다.

1. 내가 매일 쓸 화면이 다 있는가 — 없으면 지금 말한다
2. 입력 칸마다 형식이 적혀 있는가 — 비어 있으면 개발자가 정한다
3. 실패했을 때 화면이 적혀 있는가 — 중복 등록, 권한 없음, 값 오류
4. 권한별 차이가 적혀 있는가 — 특히 "보이면 안 되는 것"
5. 숫자가 어디서 오는지 적혀 있는가 — 통계 화면의 각 수치

⚠️ 실제로 그 화면을 쓸 사람이 봐야 한다. 결재자만 검토한 문서는 현장에서 안 쓰이는 시스템이 된다.

흔한 실수 5가지

① 화면은 그렸는데 규칙이 없다 가장 흔하다. 예쁜 와이어프레임만 있고 입력 형식·버튼 동작이 없으면 개발자는 결국 물어보거나 상상한다.

② 정상 흐름만 적는다 실무에서 문제가 되는 건 예외다. 중복 데이터, 권한 없음, 값 없음, 통신 실패 — 예외 화면이 전체의 절반이라고 보는 편이 맞다.

③ 목록 화면의 정렬·페이징을 안 정한다 "회원 목록"이라고만 적으면 몇 건씩 보여줄지, 무엇으로 정렬할지, 검색 조건이 뭔지가 빠진다. 목록 화면은 이 셋을 반드시 적는다.

④ 화면 ID 없이 진행한다 소통 비용이 계속 든다. 검수 단계에서 "어느 화면 얘기냐"로 시간이 나간다.

⑤ 확정 시점을 안 정한다 계속 고칠 수 있으면 개발이 못 나간다. "이 날짜 이후 변경은 변경 관리 절차를 탄다"를 정해야 한다.

화면설계서 완성 8단계 체크리스트

[ ] 1. 사용자 유형과 권한 구분 확정
[ ] 2. IA로 전체 화면 목록 도출 (공통·예외 화면 포함)
[ ] 3. 화면 ID 부여 규칙 정하고 번호 매기기
[ ] 4. 화면별 와이어프레임 작성
[ ] 5. 입력 항목 표 작성 (타입·필수·형식·기본값)
[ ] 6. 버튼별 조건·동작·성공/실패 후 처리
[ ] 7. 권한별 노출 차이 표
[ ] 8. 실사용자 검토 → 확정일 지정 → PDF 보관

화면이 아니라 기능 단위로 범위를 세는 문서는 따로 있다 — 기능 정의서 작성법 — 기능 ID·상태 정의 7단계에 견적이 산정되는 방식과 함께 정리했다.

AI-Native 팀이 화면설계서를 다루는 방식

트리숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 화면설계서는 만드는 것보다 구현과 어긋나지 않게 유지하는 것이 어렵다.

• 문서와 코드 대조 — 화면설계서의 입력 규칙과 실제 검증 로직이 일치하는지 화면 단위로 확인해, 문서만 남고 구현이 다른 상태를 막는다
• 예외 케이스 도출 — 정의된 규칙에서 빠질 수 있는 예외를 뽑아내 "이 경우 화면이 정의돼 있지 않다"를 미리 잡는다
• 테스트 시나리오 생성 — 화면 ID와 입력 규칙에서 검증 목록을 만들어 검수 단계에 그대로 쓴다

화면설계서의 가치는 분량이 아니라 개발자가 물어볼 일이 없는가에 있다. 반복 대조를 자동화해 사람이 업무 규칙 자체에 시간을 쓰게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

화면설계서와 화면 정의서, 뭐가 다른가요? 같은 문서다. SI·공공 쪽은 「화면설계서」, 스타트업은 「화면 정의서」를 주로 쓴다. 용어에 걸려 시간 쓸 필요가 없다.

발주처가 화면설계서를 직접 써야 하나요? 아니다. 개발사가 만들고 발주처가 검토·승인한다. 다만 발주처는 그 앞 단계인 요구사항 정의서를 직접 써야 한다.

디자인 시안이 있으면 화면설계서가 필요 없지 않나요? 필요하다. 시안은 어떻게 보이는지를 정하고, 화면설계서는 어떻게 동작하는지를 정한다. 입력 형식·버튼 조건·권한은 시안에 담기지 않는다.

어느 정도 분량이면 되나요? 분량 기준은 없다. 개발자가 그 문서만 보고 물어볼 일이 없으면 충분하다. 반대로 100장이어도 예외 처리가 없으면 부족하다.

피그마로 만들어도 되나요? 된다. 다만 설명을 이미지가 아닌 텍스트로 넣고, 개발 착수 시점의 상태를 PDF로 남겨야 한다.

정리

화면설계서는 그림이 아니라 규칙 문서다. 와이어프레임에 입력 형식·버튼 동작·권한 차이·예외 처리가 붙어야 개발 지시서가 된다.

실무에서 결과를 가르는 지점은 셋이다.

1. 예외 화면을 적었는가 — 정상 흐름만 있으면 절반이 빈 문서다
2. 권한별 차이를 처음부터 넣었는가 — 나중에 넣으면 구조를 다시 짠다
3. 실사용자가 검토했는가 — 결재자만 본 문서는 안 쓰이는 시스템이 된다

이 셋만 챙겨도 개발 중반의 재작업이 크게 줄어든다.

화면 한 장이 아니라 시스템 전체가 어떻게 연결돼 있는지는 시스템 구성도 작성법에서 다룬다.

화면설계서의 입력 규칙에서 검증 항목을 뽑는 방법은 테스트 케이스 작성법을 참고하면 된다.

권한을 조직도가 아니라 업무 흐름으로 설계하는 이유는 사내 관리 시스템 구축 가이드에 정리했다.