구독자님, 반가워요. 지은이에요.
지난 호 투표에서 "협업 문서 3종 세트"를 선택해주신 구독자 분께 감사드려요.
그런데 이 주제로 글을 준비하면서, 조금 고민이 되더라고요.
왜냐면 "협업 문서 잘 쓰는 법"은 이미 인터넷에 많거든요.
제가 또 그런 글을 한 편 더 보태는 건 의미가 없겠더라고요.
그래서 한 번 더 생각해봤어요.
2026년의 프로덕트 디자이너(UX/UI 디자이너)에게 진짜 필요한 건 뭘까?
저는 이거라고 생각해요.
"문서를 전부 손으로 쓰는 시대는 끝났다. 이제 우리가 해야할 일은 'AI에게 맡길 것'과 '내가 잡아야 할 것'을 구분하는 것이다."
어떠신가요?
공감되시나요?
오늘은 이 이야기를 해볼게요.
한 호에 다 담기엔 양이 많아서, 이번 호에서는 첫 번째 문서인 UX 화면 설계서를 중심으로 다룰게요. (UI 가이드와 개발 핸드오프 노트는 다음 호에 이어집니다.)
1. 협업 문서 3종 세트
먼저 3종이 뭔지 한 줄로 정리하고 갈게요.
| 문서 | 질문 | AI 활용도 |
|---|---|---|
| UX 화면 설계서 | 기획 요구사항이 화면 위에서 어떻게 작동하는가? | 높음 (초안, 예외 케이스, 문구) |
| UI 가이드 | 프로덕트 전반을 어떤 규칙으로 일관되게 만드는가? | 매우 높음 (Figma Variables 추출) |
| 개발 핸드오프 노트 | 실제로 어떻게 구현해야 하는가? | 매우 높음 (Figma MCP 연동) |
3종 모두 이제는 AI가 상당 부분 도와줄 수 있어요.
하지만 도와줄 수 있는 영역과 사람이 잡아야 하는 영역은 분명히 다릅니다.
- AI를 안 쓰고 다 손으로 쓰면서 야근한다 → 시간이 사라진다.
- AI에게 다 맡겨서 "그럴듯한 헛소리 문서"가 나온다 → 신뢰가 사라진다.
이 사이에서 균형점을 찾는 게 중요해요.
2. UX 화면 설계서 - "이건 PM이 쓰는 거 아닌가요?"
답을 먼저 드릴게요.
화면의 정책을 정하는 건 기획자 또는 PM의 일이고, 그 정책이 화면 위에서 어떻게 보이고 작동할지 설계하는 건 디자이너의 일이에요.
이 구분이 흐릿한 조직이 정말 많을 거예요.
그래서 디자이너가 어느새 정책까지 정하고 있고, 회의 때 "이 케이스 어떻게 처리해요?"라는 질문을 받게 되는 거죠.
기획자가 정해야 하는 것 (정책)
비밀번호 5회 오류 시 10분 제한, 휴면 계정의 본인 인증 처리, 탈퇴 계정의 재가입 가능 여부, 사용자 권한별 접근 범위, 데이터 노출 조건과 비즈니스 로직.
이러한 내용은 대충 정하면 위험한 영역이에요.
법적 이슈, 비즈니스 영향, 운영 정책이 얽혀 있거든요.
디자이너가 정해야 하는 것 (화면과 경험)
그 정책이 화면에서 어떻게 보이는지, 사용자가 어떤 순서로 정보를 이해해야 하는지, 어떤 상태가 필요한지 (Default / 입력 중 / 로딩 / 에러 등), 로딩·빈 화면·에러는 어떻게 보여줄지, 안내 문구는 사용자가 이해할 수 있는지.
기획자가 "무엇을 할지"를 정한다면, 디자이너는 "그것을 어떻게 보여줄지"를 정하는 거죠.
이걸 분명히 해둬야 회의에서 정책 질문이 나왔을 때 이렇게 말할 수 있어요.
"이건 디자인보다는 정책 영역이라, PM님이 한 번 정해 주시면 화면에 어떻게 녹일지 제가 다음 회의에 가져올게요."
3. AI 시대에 UX 화면 설계서, 이렇게 만들자.
이제부터 핵심을 얘기해 볼게요.
예전 방식 vs 지금 방식
| 단계 | 예전 방식 | AI 시대 방식 |
|---|---|---|
| 1 | PRD 읽기 | PRD를 AI에게 넣기 |
| 2 | 화면별 목적 정리 | AI가 화면별 초안 생성 |
| 3 | 상태, 예외 케이스 도출 | AI가 누락 가능 케이스까지 체크리스트로 |
| 4 | UX 라이팅 직접 작성 | AI가 후보 문구 5개 제안 → 디자이너가 선택 |
| 5 | 개발자 질문 정리 | AI가 "확인 필요 항목"으로 자동 표시 |
여기서 중요한 건, 5단계 모두 디자이너의 검수가 들어간다는 점이에요.
AI는 초안을 빠르게 만드는 도구지, 최종 결정을 내리는 도구가 아니에요.
AI가 잘하는 것 vs AI에게 맡기면 안되는 것
| AI가 잘하는 것 | AI에게 맡기면 안 되는 것 |
|---|---|
| 화면 목적 한 줄 요약 | 비즈니스 정책 확정 |
| 사용자 시나리오 단계 정리 | 권한·결제·환불·인증 정책 |
| 상태값 도출 (Default/로딩/에러 등) | API 명세 확정 |
| 누락되기 쉬운 예외 케이스 체크리스트 | 법무·개인정보 관련 문구 |
| UX 라이팅 후보 문구 생성 | 프로덕트 맥락에 맞는 최종 판단 |
| 개발자 확인 질문 리스트업 | 디자인 시스템 최종 원칙 |
오른쪽을 AI에게 맡기면 어떻게 되냐구요?
"그럴듯한 헛소리 문서"가 나오죠.
그게 무서운 건, 누군가는 그걸 믿고 일을 시작한다는 거예요.
바로 써먹는 프롬프트
기획서나 회의록을 가지고 있다면, 이 프롬프트를 그대로 써보세요.
이 프롬프트의 핵심은 "정책은 [확인 필요]로 표시해줘" 한 줄이에요.
이렇게 만든 초안을 받아서 디자이너가 하는 일은 :
- 화면 의도가 우리 프로덕트 맥락에 맞는지 검수
- [확인 필요]로 표시된 정책 항목을 PM에게 전달
- UX Writing 후보 중 우리 톤에 맞는 것 선택
- 빠진 화면별 특수 케이스 보완
이렇게 AI를 활용하면 처음부터 빈 페이지에 쓰는 것보다 5배는 빨라져요.
4. 한 단계 더 나아간 방식 - Figma MCP 살짝 맛보기
최근에 Figma가 MCP(Model Context Protocol)라는 걸 지원하기 시작했어요.
이 Figma MCP를 한 줄로 설명하면 이렇게 얘기할 수 있어요.
AI(Claude, Cursor 등)가 Figma 파일을 직접 읽을 수 있게 해주는 연결고리
예전에는 디자이너가 Figma 보고 손으로 옮겨 적었던 정보를(컴포넌트 이름, 사용된 컬러 토큰, 상태별 화면, 레이아웃) AI가 직접 읽고 문서로 정리해줄 수 있게 된거죠.
다만 솔직히 말씀드리면, 1인 디자이너는 당장 도입할 필요가 없어요.
셋업이 가볍지는 않거든요.
그래서 이번 호에서는 "이런 게 있다" 정도만 알려드리고, 다음 호에서 본격적으로 다룰게요.
지금 단계에서는 Claude나 ChatGPT에 PRD 붙여넣고 초안 받기만 해도 충분히 큰 변화예요.
5. AI 시대, 디자이너의 역할이 바뀐다.
오늘 글에서 가장 강조하고 싶은 한 가지가 이거예요.
문서를 쓰는 사람 → 기준을 세우고 검수하는 사람
디테일하고, 빠짐없고, 읽기 쉬운 디자인 문서를 쓰는 능력이 곧 시니어의 증거였죠.
하지만 이제는 달라요.
- 문서 작성 자체는 AI가 빠르게 처리해요
- 디자이너가 진짜 해야 하는 일은 "무엇을 검수하고 무엇을 잡아야 하는지"를 아는 것
- 그리고 "이건 디자이너의 영역이 아니에요"라고 말할 줄 아는 것
5분 미션 - 내 협업 워크플로우 자가 진단
지금 작업 중인 프로젝트 하나를 떠올리면, 다음 질문에 답해보세요.
- 기획서가 비었을 때 "이건 정해 주셔야 해요"라고 말한 적이 있는가?
- 화면 설계를 쓸 때 AI 초안을 한 번이라도 활용해본 적이 있는가?
- 내가 쓴 문서에 상태와 예외 케이스가 별도 섹션으로 분리되어 있는가?
- 모든 텍스트(제목, placeholder, 에러 메시지 등)가 확정된 문구로 적혀 있는가?
- AI가 만든 문서를 그대로 쓰지 않고 검수 단계를 거치는가?
오늘의 한 줄 요약
이제 디자이너의 문서 작업은 쓰는 게 아니라, AI에게 맡길 것과 사람이 잡을 것을 구분하는 것
문서 작성 자체는 점점 AI의 영역으로 넘어가고 있어요.
하지만 "무엇을 검수할지, 어디서 멈출지, 누구에게 정책을 되돌려 보낼지" 이 판단력만큼은 사람의 영역으로 남아 있어요.
다음 호 예고
앞으로 차근차근 협업 문서 3종 세트의 나머지 두 편을 다룰 예정이에요.
- UI 가이드 - Figma Variables 한 번에 추출해서 AI로 가이드 문서 만드는 법
- 개발 핸드오프 노트 - Figma MCP 연동으로 AI가 직접 Figma 파일을 읽고 핸드오프 문서를 만드는 워크플로우
특히 Figma MCP는 협업 풍경 자체를 바꿀 수 있는 도구라, 셋업부터 활용까지 차근차근 풀어볼게요.
이번 호에 다룬 UX 화면 설계서를 직접 써보시면서 막힌 부분이 있다면, 언제든 댓글을 달아주세요.
그럼, 2주 뒤에 또 만나요!
지은 드림
의견을 남겨주세요