화면 설계서 작성법

화면 설계서(UI 설계서, 규격서, 와이어프레임 등으로도 불림)는 기획·디자인 단계의 결과물을 개발 조직과 그래픽 디자이너에게 전달하기 위한 문서다. 명칭은 프로젝트나 클라이언트마다 다르지만, 서비스의 규모와 구조, 화면을 구성하는 기능과 요소, 각 화면의 관계와 사용 흐름을 담아 서비스의 골격(IA)과 기능별 작동 방식, 상황별 예외를 관계자들이 정확히 이해할 수 있게 하는 것이 목적이다. 전통적으로는 키노트·파워포인트로, 최근에는 스케치·XD 같은 프로토타이핑 툴로도 작성된다.

화면 설계서는 크게 7가지 성분으로 구성된다. (1) 표지에는 프로젝트명, 문서 버전, 작성일, 작성자만 간략히 담는다. (2) 히스토리는 버전이 올라갈 때마다 언제·누가·무엇을 수정했는지 추적할 수 있게 기록하는 페이지다. (3) 목차는 페이지 제목이나 화면 이름을 순서대로 나열하며, 작성 진행 상태(수정·삭제·신규)를 함께 표시할 수 있다. (4) 인터랙션 가이드는 탭·더블 탭·스크롤·클릭·호버 등 인터랙션을 문서 내에서 어떻게 표기했는지 설명하는 범례 페이지다. (5) IA(Information Architecture)는 서비스 구조를 보여주는 페이지로 프로젝트 성격에 따라 생략되기도 한다. (6) 키스크린은 리서치·분석 결과가 구체적 화면 형태로 드러나는 핵심 산출물로, 디자인 소스가 입혀지지 않은 화면과 각 구성 요소의 동작을 설명하는 디스크립션으로 구성된다. (7) 플로우(시나리오, 워크플로우)는 완성된 키스크린들을 인터랙션 표기와 함께 연결해 서비스가 어떤 순서로 흘러가는지 보여준다.

화면 설계서는 기획자·개발자·디자이너·사업 담당자 간 커뮤니케이션 문서이므로, 같은 표현도 역할에 따라 다르게 해석될 수 있다는 점을 항상 염두에 두어야 한다. 애매모호한 표현이나 근거 없는 가정을 배제하고, 고정 영역과 유동 영역, 스크롤·버튼 동작의 결과와 순서를 최대한 명확하면서도 간결하게 설명해야 한다.

이러한 문서 작성 이전에는 UX 프로젝트가 어떤 방법론으로 진행되는지 이해할 필요가 있다. Lean, Agile, Sprint 같은 방법론은 디자인·빌드·테스트를 짧은 주기로 반복하며 검증과 개선을 거듭하는 반면, UCD(User Centered Design)·전통적 Waterfall 방식은 리서치 → 분석 → 문제 정의 → 컨셉·전략 → 디자인 → 빌드 → 테스트 순서로 한 단계씩 검증하며 넘어가는 선형적 진행 방식이다. 방법론 자체보다 이를 프로젝트 상황(인력, 비용, 협업 환경)에 맞게 선택하고 잘 운영하는 것이 실제 성패를 좌우한다. 아이디어 발산과 생각 정리를 위한 포스트잇 활용도 여전히 유효한 도구지만, 수단이 목적이 되지 않도록 주의가 필요하다.

SpecSaver: 키스크린 디스크립션을 대신 써 주는 Figma 플러그인

키스크린의 두 요소 중 화면을 그리는 일은 눈에 보이는 결과가 쌓이지만, 요소마다 번호를 매기고 "무슨 버튼이고 누르면 어떻게 되는지"를 한 줄씩 적는 디스크립션은 반복 노동이 크고, 초벌을 넘긴 뒤에도 정책·화면이 바뀔 때마다 몇 주~몇 달을 고치는 팔로업이 실제로 가장 오래 걸리는 작업이다. pxd가 만든 Figma 플러그인 SpecSaver는 이 디스크립션 작성·팔로업을 자동화한다. 화면 한 장의 초안을 손으로 쓰면 30분~1시간이 걸리지만 SpecSaver로 초안을 뽑고 검토·보완까지 마치면 10분 안팎으로 줄어든다.

SpecSaver의 첫 버전은 Figma의 레이어 트리를 읽어 "여기는 버튼, 저기는 입력창"을 판별했지만, 레이어 이름이 정리되지 않은 현실의 파일(예: `Frame 42085672169`)에서는 시각적으로 한 덩어리인 영역도 레이어 구조상 흩어져 있어 잘못 인식하는 문제가 있었다. 도구가 사람에게 "레이어를 깔끔히 정리해 달라"고 요구하는 대신, 화면을 통째로 이미지로 인식하는 멀티모달(비전) 모델 방식으로 전환해 레이어 정리 상태와 무관하게 사람이 눈으로 훑듯 요소를 인식하게 했다.

작동은 분석 호출 → 사람 검토 → 생성 호출 → 사람 검토의 4단계, 두 번의 AI 호출로 이뤄진다. ① SpecSaver가 화면 전체를 분석해 요소마다 번호 배지를 생성한다. ② 사람이 번호 순서·이름·유형을 확정한다(AI가 뽑고 사람이 확정). ③ 배경 자료(사업기획서 등)와 화면별 컨텍스트(화면에는 없는 정책)를 함께 입력하면, 확정된 구조에 맥락을 얹어 디스크립션 초안을 생성한다. ④ 사람이 [확인 필요] 표시를 채우고 문장을 다듬어 완성한다. 팔로업 단계에서는 수정 요청을 입력하면 기존 디스크립션 표에서 바뀔 부분을 미리 보여주고, 확정 시 변경 부분은 빨간색, 삭제는 취소선으로 반영하며 이전 버전의 하이라이트는 일반 상태로 되돌려 최신 변경만 표시되게 한다.

이 설계는 AI 결과물에 대한 과신뢰(overreliance) 문제를 정면으로 다룬다. 완성본을 한 번에 내놓는 도구는 사람이 검토 없이 그대로 받아들이게 만들기 쉬운데, 화면 이미지가 알려주는 것은 "무엇이 어디 있는가"뿐이고 "이걸 누르면 무슨 일이 벌어지는가"·"어떤 조건에서 막히는가" 같은 디스크립션의 핵심은 화면에 없는 정책 정보라 AI가 구조적으로 틀릴 수 있다. 그래서 SpecSaver는 화면만으로 단정할 수 없는 자리를 그럴듯하게 채우지 않고 [확인 필요]로 남겨, 하버드 부친차(Buçinca) 연구진이 제안한 인지적 강제 장치(cognitive forcing function)처럼 사람이 곧바로 수용하지 못하고 스스로 판단하게 만드는 장치 역할을 한다. 스탠퍼드 Vasconcelos 연구진의 실험도 AI가 판단 근거를 드러내면 사람이 맹목적으로 따르는 정도가 줄어든다는 결과를 보여준다 — 판단의 기준을 "AI가 확신하는가"(주관)에서 "다른 그럴듯한 답이 존재하는가"(객관)로 옮기는 것이다.

보안 측면에서는 화면 이미지를 서버에 저장하지 않고 분석 순간에만 중간 서버(프록시)를 거쳐 Google Gemini로 전달한 뒤 응답이 오면 즉시 사라지도록 설계했다. AI 호출은 사용자가 자신의 API Key를 입력해 쓰는 BYOK(Bring Your Own Key) 구조라, 학습 데이터 사용 여부는 결국 사용자가 입력한 Key의 등급(무료/유료)에 달려 있다. 서버 과부하 등으로 요청이 실패하면 지수 백오프로 재시도하고, 그래도 실패하면 더 가벼운 모델로 자동 전환하되 대체 모델로 전환됐다는 사실을 배너로 숨기지 않고 알린다 — [확인 필요]와 같은 태도다.

SpecSaver는 "기획자의 역할을 얼마나 대체하는가"라는 질문에 스스로 "아니오"라고 답한다. 번호를 매기고 요소를 나열하는 판단이 거의 없는 노동은 AI가 덜어주지만, 화면이 왜 이렇게 동작해야 하는지를 정하고 어디까지 설명할지 판단하는 일은 여전히 사람의 몫으로 남긴다. 2026년 8월 기준 사내 실무에 적용해 보는 단계이며, 향후 버전 태그·변경 이력 추출, 여러 화면 배치 처리, 도구 스스로 누락·[확인 필요]를 점검하는 자가 검증, 팀·기업별 규격서 표준에 맞춘 커스터마이즈를 로드맵으로 두고 있다.

핵심 내용

  • 화면 설계서 = 표지, 히스토리, 목차, 인터랙션 가이드, IA, 키스크린, 플로우의 7가지 성분
  • 키스크린은 디자인 소스 없이 레이아웃·인터페이스와 동작 설명(디스크립션)에 집중
  • 플로우는 완성된 키스크린을 인터랙션 표기로 연결해 사용 흐름을 보여주는 단계
  • 화면 설계서는 기획·디자인·개발·사업 담당자 간 해석 차이를 줄이기 위한 커뮤니케이션 문서
  • Lean/Agile/Sprint는 짧은 반복 주기, UCD/Waterfall은 단계별 선형 진행이 특징
  • 방법론 선택보다 프로젝트 상황에 맞는 운영이 성패를 좌우
  • SpecSaver: 키스크린 디스크립션 초안·팔로업을 자동화하는 Figma 플러그인, 레이어 트리 대신 화면을 이미지로 인식(멀티모달)해 레이어 정리 상태와 무관하게 동작
  • 분석 호출(번호 배지 생성) → 사람 검토(구조 확정) → 생성 호출(맥락 반영 초안) → 사람 검토(문장 완성)의 human-in-the-loop 구조
  • 화면 이미지는 "무엇이 어디 있는가"만 알려주고 "어떻게 동작하는가"는 화면 밖 정책 정보이므로, 단정 대신 [확인 필요] 표시로 남기는 것이 인지적 강제 장치(cognitive forcing function) 역할
  • 보안 설계: 화면 이미지 서버 미저장, BYOK(사용자 자신의 Gemini API Key) 구조로 학습 데이터 사용 여부를 사용자가 통제

관련 개념

출처

최종 업데이트: 2026-09-07 | 출처 2개