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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

```

MEM-001 회원 목록

MEM-002 회원 상세

MEM-003 회원 등록

ORD-001 주문 목록

```

업무 영역 3자 + 일련번호면 충분하다. 이 ID가 나중에 기능 정의서·테스트 시나리오·검수 확인서에 그대로 쓰인다.

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

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

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

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

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

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

```

[저장] 버튼

조건: 필수 항목(회원명·연락처) 입력 완료 시 활성화

동작: 회원 정보 저장

성공: "저장되었습니다" 알림 → MEM-001 목록으로 이동

실패: "이미 등록된 연락처입니다" 알림 → 현재 화면 유지, 연락처 칸에 포커스

```

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

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

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

화면마다 이 표를 붙인다.

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

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

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

```

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

```

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

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

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

피그마로 만들 때 주의할 점

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

다만 두 가지를 조심한다.

① 텍스트가 검색되지 않으면 문서가 아니다

설명을 이미지로 넣으면 나중에 "연락처 형식이 어디 적혀 있더라"를 못 찾는다. 텍스트 레이어로 쓴다.

② 버전이 흘러가면 합의 시점이 사라진다

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

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

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

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

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

흔한 실수 5가지

① 화면은 그렸는데 규칙이 없다

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

② 정상 흐름만 적는다

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

③ 목록 화면의 정렬·페이징을 안 정한다

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

④ 화면 ID 없이 진행한다

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

⑤ 확정 시점을 안 정한다

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

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

```

[ ] 1. 사용자 유형과 권한 구분 확정

[ ] 2. IA로 전체 화면 목록 도출 (공통·예외 화면 포함)

[ ] 3. 화면 ID 부여 규칙 정하고 번호 매기기

[ ] 4. 화면별 와이어프레임 작성

[ ] 5. 입력 항목 표 작성 (타입·필수·형식·기본값)

[ ] 6. 버튼별 조건·동작·성공/실패 후 처리

[ ] 7. 권한별 노출 차이 표

[ ] 8. 실사용자 검토 → 확정일 지정 → PDF 보관

```

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

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

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

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

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

자주 묻는 질문

화면설계서와 화면 정의서, 뭐가 다른가요?

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

발주처가 화면설계서를 직접 써야 하나요?

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

디자인 시안이 있으면 화면설계서가 필요 없지 않나요?

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

어느 정도 분량이면 되나요?

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

피그마로 만들어도 되나요?

된다. 다만 설명을 이미지가 아닌 텍스트로 넣고, 개발 착수 시점의 상태를 PDF로 남겨야 한다.

정리

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

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

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

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