만들어진 UI 검증하기
UI 작업까지 완료된 이후, 기능을 다시 한 번 정리할 필요가 있었다.
이전에는 화면을 기준으로 기능을 정의하면서 유즈케이스를 놓치는 경험을 여러 번 했기 때문이다.
그래서 이번에는 요구사항 명세를 기반으로 기능을 리스트업하고,
백엔드 팀에서 정리해둔 API 리스트와 매핑하는 방식으로 진행했다.
이 과정을 진행하면서 UI만으로는 드러나지 않던 문제들이 자연스럽게 드러났다.
특정 기능에 필요한 API가 정의되어 있지 않거나,
초기에 설계하지 않았던 UI 요소가 필요하다는 것도 확인할 수 있었다.
AI를 활용한 기능 명세서 작성 방식
기능 명세서는 처음부터 직접 작성하기보다,
GPT를 활용하여 스토리보드를 기반으로 초안을 생성하는 방식으로 접근했다.
스토리보드 캡쳐본을 GPT에 입력하기 전에, 먼저 기능 명세서가 어떤 역할을 수행할지
해당 역할을 수행하기 위해 어떤 속성들이 필요할지에 대해 논의했다.
치열한 토론 끝에 템플릿이 완성되었고, 도메인별 기능들을 몇개 작성해보니
API 문서와 1:1 매핑하여 기능을 정의할 수 있는 수준으로 만들어진 것 같다.
만들어진 이후에는 잘 만들어진 스토리보드 캡쳐본을 GPT에 전송하여
명세서를 템플릿에 맞추어 작성하도록 요청하였다.
기능명세서 작성 시간을 보면 5시간 30분이 소요되었다.
이 중 40% 정도는 템플릿을 만드는데 소요된 시간이지만,
앞으로 진행할 프로젝트에서도 유용하게 쓰일 것 같아서 의미있는 시간이다.
 개인적으로 사용하는 시간관리 도구 |
|---|
기능 명세서 템플릿 설계
템플릿은 Notion을 활용하여 테이블과 본문으로 나누었다.
테이블 속성은 연관 화면 도메인 기능명 시작 상태 종료 상태 기능 설명 으로,
본문 요소는 선행조건 트리거 동작 예외/제한사항 으로 구성했다.
테이블 속성은 어떤 기능들이 있는지 한 눈에 파악하기 쉬운 것들로 구성되어있으며,
각 기능간의 관계를 알 수 있도록 상태도 테이블 속성으로 빼두었다.
본문에는 각 기능이 어떤 전제에서 시작되는지, 어떻게 동작하고 어떤 결과를 내는지,
그리고 어떤 예외를 고려해야하는지를 한 눈에 볼 수 있도록 구성했다.
[ 기능 명세서 템플릿 공유 ]
 테이블 속성 |  본문 템플릿 |
|---|
파라미터 대신 ‘선행조건’?
특정 기능을 수행하기 위해 넘겨받을 값이 필요한 경우가 많다.
처음에는 파라미터를 작성할까 고민했었지만, 제외하고 선행조건 중심으로 작성해보았다.
파라미터를 기능 명세서에 함께 적게 되면,
요구사항이 변경될 때 기능 명세서와 API 명세서를 모두 수정해야 하는 문제가 생긴다.
반면 선행조건 중심으로 정리하면 기능의 전제 상태와 흐름을 중심으로 이해할 수 있기 때문에,
이후 API 설계 단계에서도 참고할 수 있는 기준으로 활용할 수 있다.
상태값을 설계 단계에서 정의한 이유
또 하나 중요하게 다룬 부분은 상태값이었다.
이전에 진행했던 사이드 프로젝트에서는 상태에 대한 정의 없이 개발을 했었고,
프론트와 연동 시점에 상태값을 계속 수정해야 하는 문제가 있었다.
그래서 이번에는 기능 명세 단계에서부터 상태값을 함께 정리했다.
예를 들어 타이머 기능은 시작 일시정지 종료 로만 구분하는 것이 아니라,
IDLE → RUNNING → PAUSED → COMPLETED 와 같은 상태 전이 관점에서 이해할 수 있도록 정리했다.
이를 통해 프론트와 백엔드가 동일한 기준으로 상태를 해석하고,
추후 구현 단계에서 발생할 수정 비용도 줄일 수 있기를 기대하고있다.
도메인 기준으로 기능 재정의
기능을 정리하는 과정에서는 각 기능이 어떤 도메인에 속하는지에 대한 고민도 함께 필요했다.
예를 들어 회원탈퇴 기능의 경우 user 도메인에 포함시킬지,
auth 도메인에 포함시킬지 명확하지 않았다.
이런 지점들을 하나씩 정리하면서 각 기능이 어떤 책임을 가지는지,
어떤 도메인에 속해야 하는지를 정리할 수 있었다.
기능 명세서를 통해 발견한 문제들
기능 명세서를 작성하면서 초기 설계에서 놓쳤던 문제들도 자연스럽게 드러났다.
- 특정 기능에 필요한 API가 정의되어 있지 않은 경우
- UI에는 존재하지만 실제 동작이 정의되지 않은 요소
- 상태 전이가 불분명한 기능
이전에는 화면이 있으면 설계가 어느 정도 끝난 것처럼 느껴졌는데,
막상 기능을 도메인과 상태 기준으로 다시 정리해보니 논리적인 허점을 찾을 수 있었다.
