화면 설계서 작성과 QA

앞선 기획 과정에서 요구사항과 서비스 정책을 정리하고, IA와 메뉴 구조, 사용자 플로우까지 어느 정도 정리한 뒤에는 이 내용을 실제 화면 단위로 풀어내는 화면 설계서 작업을 진행했습니다.

처음에는 화면에 어떤 기능이 필요한지, 어떤 데이터를 보여줄지만 정리하면 화면 설계서가 충분하다고 생각했습니다. 하지만 실제 프로젝트에서 여러 화면을 작성하면서 화면 설계서에서 함께 고려해야 할 내용이 생각보다 많다는 것을 알게 되었습니다.

이후 개발 단계에 들어가서는 작성한 화면 설계서를 기준으로 기능이 구현되었는지 직접 테스트했습니다. 이 과정에서 기획 단계에서 놓쳤던 예외 상황이나 개발 과정에서 발생한 오류를 확인할 수 있었고, 기획에서 화면을 설계하고 개발한 뒤 실제 테스트까지 진행해야 하나의 기능이 제대로 완성된다는 것을 경험했습니다. 테스트 과정에서 발견한 오류를 다시 확인하고 수정하면서 서비스의 오류율을 줄이는 데에도 신경 쓰게 되었습니다.

이러한 과정을 거치면서 화면 설계와 QA 각각의 단계에서 제가 중요하게 생각하게 된 기준들이 생겼습니다. 이번 글에서는 실제 프로젝트에서 화면 설계서를 작성하고 QA를 진행하며 겪었던 시행착오와 그 과정에서 정리하게 된 기준을 소개해보겠습니다.

1. 상세 화면 기획 – 화면 설계서를 작성하면서 생긴 시행착오와 개선 과정

제가 실제로 사용했던 화면 설계서의 기본적인 구성은 다음과 같았습니다.

[표지] → [목차] → [개정 이력] → [메뉴 구조] → [화면 목록(IA)] → [권한 매트릭스] → [플로차트] → [공통 정책] → [상세 설계]

특히 아래 내용들은 중요하게 생각하고 화면 설계서를 관리하려고 했습니다.

1) 개정 이력

프로젝트를 진행하면서 의외로 많이 신경 쓰게 된 부분이 문서 버전 관리였습니다.

화면 기획은 한 번 작성하고 끝나는 작업이 아니었습니다.

개발자와 화면을 확인하면서 수정사항이 생기기도 하고, 정책이 변경되면서 기존 화면을 다시 수정하기도 했습니다.

문제는 문서가 여러 번 수정되기 시작하면서 “지금 보고 있는 문서가 최신 버전인가?”,

“이 화면은 언제 무엇이 바뀐 거지?”를 확인하는 일이 생겼다는 것입니다.

그래서 프로젝트를 진행하면서 파일명과 버전을 일정한 규칙으로 관리하기 시작했습니다.

예를 들어 다음과 같이 파일명을 통일했습니다.

프로젝트명_화면 설계서_v1.2_20260613.pdf

큰 정책 변경이나 화면 구조가 크게 바뀌는 경우에는 앞자리 버전을 올리고,

문구 수정이나 일부 컴포넌트 변경처럼 작은 수정은 뒷자리 버전을 올리는 식으로 구분했습니다.

이렇게 버전을 구분해두니 이전 문서와 현재 문서를 비교하거나 특정 시점의 화면을 확인할 때 훨씬 편했습니다.

• 버전 스케일 규칙:

-배포 및 최초 클라이언트/팀 승인본: v1.0

-UI 레이아웃 전면 개정, 코어 비즈니스 정책의 변동 등 거대 아키텍처 변경: 앞자리 카운트 업 (예: v1.0 ➔ v2.0)

-마이너한 서브 기능 추가, 얼럿 문구 변경, 일부 컴포넌트 보완: 뒷자리 카운트 업 (예: v1.0 ➔ v1.1)

버전 관리에서 또 하나 시행착오가 있었습니다.

처음에는 화면의 작은 수정사항까지 전부 히스토리 시트에 기록했습니다.

예를 들어 버튼 이름을 하나 바꾸거나 Description의 문구를 수정하는 것까지 모두 히스토리에 추가했습니다.

처음에는 변경사항을 빠짐없이 남기는 것이 좋다고 생각했습니다.

그런데 수정이 계속 쌓이면서 히스토리 시트가 너무 복잡해졌습니다.

정작 중요한 정책 변경 내용을 확인하려고 해도 사소한 수정사항이 같이 섞여 있어서 원하는 내용을 찾는 데 오히려 시간이 걸렸습니다.

그래서 이후에는 변경사항을 두 가지로 나눠서 관리했습니다.

큰 변경사항은 문서 앞부분의 전체 히스토리에 기록하고, 단순한 문구 수정이나 컴포넌트 위치 변경처럼 작은 변경사항은 해당 화면의 Description 옆에 수정 표시를 남겼습니다.

예를 들어 해당 화면에 v1.2 수정과 수정 날짜, 변경 내용을 표시했습니다.

이렇게 바꾸고 나니 전체 문서의 주요 변경 이력과 개별 화면의 세부 변경사항을 구분해서 확인할 수 있었습니다.

특히 특정 화면을 담당하는 개발자가 해당 화면의 변경사항만 빠르게 확인하기에도 편했습니다.

2) Description

상세 화면을 설계할 때는 화면 왼쪽에 Wireframe을 그리고 오른쪽에 Description을 작성하는 방식으로 진행했습니다.

Wireframe에는 Input Box, Select Box, Radio Button, Checkbox, Data Grid 등 실제 화면에 들어갈 컴포넌트를 배치하고, 설명이 필요한 부분에는 번호를 붙였습니다.

처음에는 Wireframe을 만드는 데 집중하였으나, 화면 기획을 할수록 Description 영역이 무엇보다 중요함을 깨달았습니다.

처음 화면 기획을 할 때는 화면에 필요한 기능과 기본적인 동작을 중심으로 작성했습니다. 하지만 여러 화면을 기획하면서 예외가 발생했을 때 어떤 알럿을 보여줄지, 화면에 처음 진입했을 때나 데이터가 없을 때 어떤 상태로 표시할지처럼 정상적인 상황 외의 경우까지 미리 정의해야 한다는 것을 느꼈습니다.

화면을 작성하면서 초기 상태, 데이터 노출 방식, 사용자 인터랙션, 유효성 검사와 예외 상황을 확인하려고 했습니다.

① 초기 상태와 데이터 노출

먼저 사용자가 화면에 처음 진입했을 때 어떤 상태인지 적었습니다.

예를 들어 단순히 “테이블 표시” 라고 적는 대신, “테이블은 상태 우선순위 ‘Failed > Warning > Canceled > Running > Passed’ 순으로 정렬하고 한 테이블에 최대 20건을 노출한다.”처럼 실제 구현에 필요한 기준까지 작성했습니다.

 ② 사용자 인터랙션 및 화면 이동 정책

버튼이나 컴포넌트를 클릭했을 때 어떤 일이 발생하는지도 구체적으로 작성했습니다.

예를 들어, " [수정] 버튼 클릭 시, 화면 이동 없이 MB_01_P01 레이어 팝업을 중앙에 노출한다.", "콤보박스 선택 값을 변경할 때마다 하단 그리드 데이터가 새로고침된다."

와 같이 화면 이동 여부나 팝업 형태까지 함께 적었습니다.

③ 유효성 검사와 예외 상황

정상적인 경우에는 화면이 어떻게 동작하는지 쉽게 생각할 수 있지만,

• 입력값이 잘못된 경우

• 조회 결과가 없는 경우

• 이미 처리된 데이터를 다시 수정하려는 경우

• 권한이 없는 사용자가 접근하는 경우

처럼 정상적인 흐름에서 벗어나는 상황은 놓치기 쉬웠습니다.

그래서 화면을 작성한 뒤에는 “이 기능이 정상적으로 동작하지 않는 상황에서는 어떻게 해야 하지?”를 한 번 더 생각해보는 습관을 만들었습니다.

이 과정을 거치면서 화면 설계서가 단순히 화면을 설명하는 문서가 아니라, 개발 과정에서 발생할 수 있는 해석 차이를 미리 줄이는 문서라는 것을 알게 되었습니다.

2. QA 테스트 케이스를 직접 작성하면서 알게 된 것

개발이 어느 정도 마무리된 이후에는 제가 작성한 화면 설계서대로 서비스가 구현되었는지 확인하기 위해 테스트 시나리오를 작성했습니다.

처음 QA를 진행할 때는 단순히 기능이 정상적으로 동작하는지만 확인하면 된다고 생각했습니다.

하지만 실제로 테스트 시나리오를 작성해보니 “무엇을 테스트할 것인가”를 미리 정의하는 것 자체가 중요하다는 것을 알게 되었습니다.

그래서 테스트 케이스에는 다음과 같은 내용을 정리했습니다.

• 테스트 ID

• 기능 및 모듈

• 화면 ID

• 테스트 계정 및 데이터

• 테스트 전제 조건

• 테스트 절차

• 기대 결과

• 실제 결과

• 테스트 상태

• 결함 조치 내용

테스트 절차와 기대 결과는 최대한 구체적으로 나눠서 작성했습니다.

실제 테스트를 수행하는 사람이 그대로 따라 할 수 있는 수준으로 작성했습니다.

이렇게 작성하니 테스트를 진행하면서 빠뜨리는 항목도 줄어들었고, 개발자에게 결함을 전달할 때도 어떤 상황에서 문제가 발생했는지 설명하기 쉬웠습니다.

테스트 결과는 PASS, FAIL, BLOCK, TO DO로 상태를 구분했습니다.

정상적으로 동작하면 PASS로 처리하고, 기대 결과와 다르게 동작하면 FAIL로 기록했습니다.

FAIL이 발생한 경우에는 단순히 “안 됨”이라고 적는 것이 아니라 실제로 어떤 동작이 발생했는지를 기록하였습니다.

예를 들어 기대 결과가 “승인 완료된 데이터는 수정 버튼이 노출되지 않는다.”였는데 실제 화면에서 수정 버튼이 노출된다면, “승인 완료 상태의 데이터 조회 시 [수정] 버튼이 노출됨”

과 같이 실제 결과를 작성했습니다.

이렇게 기록해두면 개발자도 어떤 조건에서 문제가 발생했는지 바로 확인할 수 있었습니다.

또한 로그인 오류처럼 선행 기능에 문제가 있어서 다음 테스트를 진행할 수 없는 경우에는 BLOCK으로 처리했습니다.

이 과정을 반복하면서 QA는 단순히 기능을 눌러보는 작업이 아니라, 기획 단계에서 정의했던 요구사항과 실제 구현 결과를 비교하는 과정이라는 것을 경험하게 되었습니다.

3. 마무리

프로젝트를 처음 시작했을 때는 화면 설계서를 화면의 모양과 기능을 설명하는 문서라고 생각했습니다. 하지만 실제로 여러 화면을 작성하고 개발자분들과 협업하면서 생각이 많이 바뀌었습니다.

화면 하나를 기획할 때도 “화면에 무엇이 보이는가?”에서 끝나는 것이 아니라, “처음 들어왔을 때는 어떤 상태인가?”, “데이터가 없으면 어떻게 되는가?”, “권한이 다르면 무엇이 달라지는가?”, “잘못된 입력이 들어오면 어떻게 되는가?”까지 생각하게 되었습니다.

또한 화면 설계가 끝났다고 해서 하나의 기능이 완성되는 것은 아니라는 것도 경험했습니다. 개발 이후에는 작성한 설계서를 기준으로 실제 구현 결과를 확인하고, 테스트 과정에서 발견된 오류나 누락된 부분을 다시 확인하고 수정하는 과정이 필요했습니다. 기획 단계에서 정의한 내용과 실제 구현 결과를 비교하면서 QA까지 진행해야 비로소 하나의 기능이 완성된다고 생각하게 되었습니다.

특히 처음부터 모든 상황을 완벽하게 정의하려고 하기보다는, 개발자에게 질문을 받고, QA에서 누락된 부분을 발견하고, 문서 관리에서 불편함을 겪으면서 하나씩 기준을 만들어갔습니다.

결과적으로 제가 생각하는 좋은 화면 설계서는 프로젝트에 참여하는 사람들이 같은 화면과 같은 동작을 바라볼 수 있도록 기준을 맞춰주는 문서이며, QA는 그 기준대로 실제 서비스가 구현되었는지 확인하는 과정이라고 생각합니다.

ryu