기획이 끝난 이후, 가장 먼저 한 작업은 아이디어에 대한 화면과 유저플로우를 구체화하는 것이었다.
막연한 기능들을 실제 서비스 형태로 만들기 위해 와이어프레임과 스토리보드를 작업했다.
와이어프레임으로 기능 배치하기
만약 기획자가 있었다면 요구사항을 정리하고 화면 흐름을 먼저 설계했겠지만,
팀원 모두가 개발자였기 때문에 각자 맡은 기능을 직접 와이어프레임으로 풀어내기로 했다.
각자 하나의 기능을 맡아 아래 내용을 중심으로 와이어프레임을 작성하기로 했다.
- 사용자는 어떤 화면에서 기능을 시작하는가
- 어떤 입력이 필요한가
- 동작 이후 어떤 결과를 보게 되는가
- 다른 기능과 어떻게 연결되는가
와이어프레임을 만드는 목적은 예쁜 화면을 만드는 것이 아니라
기능을 구현 가능한 수준으로 해석하고, 팀원 간 이해를 맞추기 위함이다.
같은 ‘회고 작성’ 기능이라도 누군가는 모달을 떠올리고, 누군가는 별도 페이지를 떠올릴 수 있다.
개발작업을 시작하기 전에 동작과 플로우를 구체적으로 정의하는 과정이 필요했다.
AI를 활용한 와이어프레임 초안 작업
프로젝트 기간이 짧았기 때문에, 백지에서 시작하기보다
AI를 활용해 초안을 빠르게 만들어 팀원들과 공유하는 방식을 선택했다.
요구사항 명세서를 꼼꼼히 다듬어두었기 때문에, 해당 내용을 그대로 프롬프트로 활용할 수 있었다.
와이어프레임 생성은 ClaudeCode, Stitch, Figma Make 로 각각 만들어보았다.
 ClaudeCode |  Stitch |
|---|
 Figma Make (1) |  Figma Make (2) |
|---|
그 중 피그마의 결과물이 가장 안정적이었다.
클로드는 구조는 괜찮았지만 다소 인위적인 느낌이 있었고,
스티치는 결과물 자체는 좋았지만 한글 지원이 아쉬웠다.
다만 스티치는 피그마 디자인 에셋으로 변환이 가능해
초기 베이스로 활용하기에는 충분히 가치가 있다고 판단했다.
전체적인 플로우와 구성 요소는 피그마 결과를 중심으로 참고했다.
개별 와이어프레임 취합하기
초안을 토대로 와이어프레임을 작성하긴 했지만,
팀원마다 기능을 맡아 개별 작업했기 때문에 곧바로 산출물로 쓰기 충분하지 않았다.
기능 하나하나는 자연스러워 보여도 막상 서비스 전체 흐름으로 연결하면
중복되는 화면이 생기거나, 기능 간 진입 조건이 맞지 않는 문제가 생길 수 있기 때문이다.
와이어프레임 취합 과정은 프론트엔드 팀에서 주도적으로 진행했다.
백엔드 팀에서는 이전에 만든 요구사항 명세서를 기준으로 구현해야 할 기능 리스트를 정리하고,
프론트엔드에서는 와이어프레임을 취합하여 사용자 흐름을 정리하도록 역할을 분리하여 진행했다.
와이어프레임 취합 과정에서 확인해야 할 것은 크게 세 가지였다.
- 화면 간 흐름이 자연스럽게 이어지는지
- 기능 간 역할이 중복되거나 충돌하지 않는지
- 초기 요구사항 명세서와 실제 화면 구조가 어긋나지 않는지
결국 화면을 그리는 작업이라기보다 서비스 구조를 시각적으로 검증하는 과정에 가까웠다.
스토리보드로 유저플로우 설계하기
와이어프레임을 기반으로 디자인을 일부 진행하며 화면 구조를 보다 명확하게 다듬을 수 있었다.
하지만 화면이 정리되었다고 해서 사용자 흐름까지 자연스럽게 정의된 것은 아니었다.
와이어프레임이 ‘어디에 무엇이 있는지’를 정의했다면,
스토리보드는 ‘사용자가 어떻게 움직이는지’를 정의하는 단계였다.
 메인화면 |  대시보드 |
|---|
스토리보드를 작성하면서 화면 단위로 보았을 때는 보이지 않던 문제들도 드러났다.
- 특정 기능으로 진입하는 경로가 모호한 경우
- 한 번의 행동 이후 다음 행동이 자연스럽게 이어지지 않는 경우
이러한 부분을 미리 발견하고 수정할 수 있었고, 화면 설계를 사용자 경험 관점에서 검증하는 과정이 되었다.
다음 글에서는 실제 구현으로 빠르게 옮기기 위해 디자인을 정리하고,
React 컴포넌트에 적용할 수 있는 디자인 시스템을 구축한 과정을 정리해보려고 한다.
