일하는 방식
사양을 먼저 확정하고,
그다음 동작하는 프로토타입을 만듭니다.
이 사이트의 사례는 모두 같은 순서로 진행했습니다. 제도의 규칙을 익히고, 업무를 맡은 분들과 사양을 못 박고, AI-Figma MCP로 화면을 만든 뒤, 개발자가 직접 눌러 볼 수 있는 프로토타입을 전달합니다. 속도는 도구가 아니라 첫 단계에서 나옵니다.
- 사양 검토
- AI-Figma MCP
- 동작하는 프로토타입
순서
내부 이해관계자와 사양 검토
업무를 맡은 분들과 마주 앉아 무엇을 만들지 문장 단위로 못 박습니다. 여기서 남은 애매함은 나중에 전부 재작업으로 돌아옵니다. 가장 느려 보이지만 뒤의 모든 단계를 결정하는 자리입니다.
AI-Figma MCP 프롬프트
확정된 사양을 프롬프트로 옮깁니다. 사양이 분명하면 프롬프트는 짧습니다. 분명하지 않으면 프롬프트를 아무리 길게 써도 결과가 흔들립니다. 프롬프트의 품질은 대부분 앞 단계에서 정해집니다. *
동작하는 프로토타입
정지된 시안이 아니라 직접 눌러 볼 수 있는 화면을 만듭니다. 검토자는 결과를 상상하지 않고 확인합니다. 원래 설계가 답하지 않는 지점도 여기서 드러나고, 그때마다 판단한 내용과 이유를 기록해 나중에 되돌릴 수 있게 둡니다.
개발자 인계
프로토타입은 사양 문서를 대신하지 않습니다. 문서 옆에서 개발자와 제가 같은 결과물을 놓고 이야기하는 기준이 됩니다. 설명할 것이 줄어드는 만큼 해석이 갈릴 여지도 줄어듭니다.
* AI-Figma MCP는 AI 어시스턴트가 Figma에서 직접 화면을 만들 수 있게 연결하는 MCP(Model Context Protocol)입니다.
결과
이 순서를 갖춘 뒤 내부 프로젝트의 사양 전달과 화면 기획에 걸리는 기간이 평균 1–2개월에서 1–1.5주로 줄었습니다. 내부 기준 수치이고, 조건이 있습니다. 사양 검토를 먼저 했을 때만 성립하며, 그 회의를 건너뛰면 같은 프롬프트가 같은 결과를 내지 않습니다. 이 순서를 끝까지 적용한 사례가 신재생에너지 융복합지원사업입니다. Figma 화면 12장이 한 달 만에 동작하는 모바일 프로토타입이 됐습니다.
여기서 만난 한계
만드는 속도가 병목에서 빠지면 다음 병목은 이해관계자가 소화할 수 있는 양입니다. 아무도 요청하지 않은 시점에 동작하는 프로토타입을 보여줬더니, 논의가 정리되는 대신 혼란이 생겼습니다. 만들 수 있다는 것과 지금 보여도 된다는 것은 다른 문제였습니다. 그 뒤로는 무엇을 언제 보여줄지 의식적으로 정합니다.
문제를 보는 세 가지 시선
얽힌 문제가 설계 과제가 되기까지.
사양을 검토하기 전에 같은 문제를 세 방향에서 봅니다. 누가 어떤 규칙 아래 누구에게 의존하는지, 사용자가 무엇을 하려 하고 어디서 막히는지, 근거가 실제로 무엇을 말하는지. 아래 도식은 이 세 가지 읽기가 한 덩어리의 상황을 사양으로 적고 검증할 수 있는 과제로 바꾸는 과정입니다.
관점을 선택하면 그 관점이 문제의 어느 부분을 집어내는지 볼 수 있습니다.
01 / 얽혀 있는 복잡함
02 / 구조화 · 분류
Systems Thinking
행위자 · 규칙 · 의존성
User Empathy
목표 · 맥락 · 장벽
UX Research
정성적 관찰 · 정량적 측정 · 근거와 패턴
03 / 풀 수 있는 설계식
세 관점의 연결
시스템의 관계, 사용자의 맥락, 리서치의 근거를 함께 놓으면 막연한 복잡함이 구체적인 설계 과제로 바뀝니다.
검증 가능한 해결 가설
이 사용자가 이 제약 안에서 목표를 이루려면, 무엇을 바꿔야 할까?
확인할 것가설을 프로토타입으로 만들고, 사용자 피드백과 행동 지표를 함께 확인합니다.
검증 → 학습 → 문제를 다시 정의하기
세 관점의 연결