기능 명세서와 화면 설계서, 무엇이 다를까?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 기능 명세서는 서비스의 동작과 조건을 설명하는 문서입니다.

• 화면 설계서는 사용자가 보는 구성과 화면 사이의 흐름을 설명합니다.

• 두 문서를 연결하면 화면에 보이지 않는 규칙도 개발·검수 범위에 담을 수 있습니다.

기능 명세서는 서비스가 무엇을 어떤 조건에서 처리하는지 적는 문서이고, 화면 설계서는 사용자가 보는 화면 구성과 이동 흐름을 설명하는 문서입니다. 예를 들어 예약 버튼의 위치는 화면 설계에서, 예약 가능한 조건과 중복 신청 처리는 기능 명세에서 구체화할 수 있습니다. 문서 이름과 담는 범위는 회사나 프로젝트마다 달라 두 내용을 한 문서로 관리하기도 합니다.

화면만으로 저장 조건을 알기 어렵고, 기능 목록만으로 조작 흐름을 파악하기도 어렵습니다. 오늘은 기능 명세서와 화면 설계서의 차이를 예약 기능 예시로 비교하고, 개발 요청에 활용할 연결 방법을 정리해보겠습니다.

1. 두 문서는 어떤 질문에 답하나요?

기능 명세서에는 서비스의 처리 규칙을 적습니다. 누가 요청할 수 있는지, 어떤 값을 받아 무엇을 저장하는지, 실패하면 어떻게 되는지 적습니다. ‘예약하기’처럼 이름만 있는 목록에서 한 걸음 더 들어가, 구현하고 시험할 수 있는 동작으로 풀어 쓰는 것입니다.

화면 설계서는 사용자에게 보이는 구성을 설명합니다. 입력란과 버튼의 배치, 안내 문구, 다른 화면으로 이동하는 경로가 주요 내용입니다. 초기 와이어프레임에 상세 설명과 상태별 화면을 덧붙일 수 있습니다.

문서 이름보다 설명 범위를 보면 됩니다

문서 양식은 달라도 설명 범위를 팀이 찾을 수 있으면 됩니다. 아래 표는 두 내용을 구분하는 예시입니다.

두 설명을 분리해 관리하더라도 요구사항과 화면 자료를 연결해 두면 같은 기능을 함께 검토하기 쉽습니다. 목표·범위·화면 자료를 한곳에서 연결하는 방법은 Atlassian의 제품 요구사항 문서 가이드에서 구체적으로 살펴보실 수 있습니다.

2. 예약 버튼 하나에는 무엇이 필요할까요?

회의실 예약 기능을 만든다고 가정해 보겠습니다.
사용자가 날짜와 시간을 고른 뒤 예약 버튼을 누르면 완료 화면으로 이동하는 흐름입니다.

화면 설계에서는 날짜·시간 선택과 결과 안내를 살펴봅니다. 선택하지 않은 항목이 있으면 어디에서 알려줄지, 처리 중에는 어떤 표시를 보여줄지, 성공한 뒤 예약 내용을 어디에서 다시 볼지 정합니다. 같은 화면도 입력 전·처리 중·실패 후에 보여줄 내용이 달라집니다.

기능 명세에서는 예약 성립 조건을 적습니다. 선택한 시간에 빈 회의실이 있는지, 누가 예약할 수 있는지, 요청이 겹쳤을 때 어느 신청을 받아들일지 정하는 것입니다. 화면에 빈 시간이 표시됐어도 저장 직전에 다른 사람이 예약할 수 있으므로, 화면 표시와 최종 처리 결과는 구분해 설명합니다.

보이지 않는 규칙도 사용자 결과에 영향을 줍니다

‘실패하면 오류 표시’만으로는 개발자가 실패 이후의 동작을 결정하기 어렵습니다. 선택한 날짜를 유지할지, 다른 시간대를 다시 보여줄지, 저장 여부를 먼저 확인하고 다시 시도하게 할지까지 정해야 합니다. 이런 조건을 화면 주석이나 기능 설명에 담으면 서로 다른 기대를 가진 채 개발하는 일을 줄일 수 있습니다.

프로토타입에서는 화면을 눌러 보며 이런 흐름을 검토할 수 있습니다. 다만 화면이 이동한다고 실제 서버의 예약 처리가 구현된 것은 아닙니다. 프로토타입의 종류와 시험 용도를 구체적으로 살펴보고 싶다면 GOV.UK의 프로토타입 제작 안내를 참고해 보세요. 화면 탐색과 실제 처리 검수는 목적을 나눠 진행할 수 있습니다.

3. 기능·화면·검수 조건은 어떻게 연결하나요?

각 기능에 같은 식별자를 붙이면 연결이 쉬워집니다. 예를 들어 ‘예약 생성’ 항목에 해당 화면 링크와 업무 정책, 검수 조건을 함께 적는 방식입니다. 문서 표 한 행에 관련 링크를 모아 두면 설명을 찾아가기 편해집니다.

‘사용자가 예약할 수 있다’는 요구를 확인 가능한 결과로 바꿔 보세요. 신청 자격이 있는 사용자가 비어 있는 시간을 고르면 예약 내역에 나타나고, 이미 찬 시간을 고르면 새 예약을 만들지 않는다는 식입니다. 검수 조건은 사용자의 필요를 충족했는지 확인하는 결과 목록이라는 GOV.UK의 설명과도 연결됩니다. 작성 예시는 사용자 이야기와 인수 조건 안내에서 더 자세히 보실 수 있습니다.

변경한 이유와 영향을 함께 남기면 됩니다

정책을 바꾸면 연결된 화면과 검수 조건도 같이 살펴봅니다. 예약 가능 시간을 바꿨는데 화면의 선택 범위나 오류 문구가 그대로라면 설명과 실제 동작이 어긋날 수 있기 때문인데요. 문서마다 긴 설명을 복사해 두면 수정할 때 놓치기 쉽습니다. 정책 원본을 연결하고 바뀐 항목을 표시하면 고칠 곳을 찾기 수월합니다.

개발을 요청하거나 문서를 검토할 때 다음 질문을 사용해 보세요.

• 기능을 사용할 사람과 필요한 결과가 적혀 있나요?

• 정상·처리 중·실패 상태를 화면에서 구분할 수 있나요?

• 권한과 중복 요청처럼 보이지 않는 조건도 설명돼 있나요?

• 변경된 규칙을 어떤 화면과 검수 항목에 반영할지 알 수 있나요?

미정인 내용은 결정한 내용과 구분해 남겨 두는 것이 좋습니다. 취소 가능 시간이 미정이라면 결정 시점과 견적에 적용한 가정을 함께 확인합니다. 화면 완성과 규칙 확정을 구분하는 데 도움이 됩니다.

기획과 개발이 이어지도록 함께 정리합니다

똑똑한개발자는 웹·앱과 관리자 시스템 등 프로덕트의 기획·디자인·개발·운영을 연결해 서비스를 만듭니다. 자체 서비스 pluuug를 운영한 경험도 갖고 있는데요. 이 경험을 바탕으로 화면을 만들 때 서비스의 업무 조건과 운영자의 사용 흐름도 함께 살펴봅니다.

화면은 준비했지만 개발에 필요한 설명이 충분한지 고민되시나요? 아래 똑똑한개발자 링크로 이야기 나눠주시면 서비스 기획과 개발 범위를 함께 검토하겠습니다.

감사합니다. :)

📚 이어서 읽어보세요

• UI 키트·컴포넌트·디자인 시스템 차이

• 와이어프레임·목업·프로토타입의 차이와 활용 방법