기능 정의서와 화면 설계서는 어떻게 다를까?

외주 개발 프로젝트를 준비하다 보면 기능 정의서, 화면 설계서, 요구사항 정의서, 와이어프레임처럼 비슷해 보이는 문서 이름을 자주 접하게 됩니다. 특히 기능 정의서와 화면 설계서는 같은 내용을 다른 형식으로 정리한 문서처럼 느껴질 수 있습니다.

하지만 두 문서는 확인하려는 대상이 다릅니다. 기능 정의서는 시스템이 어떤 조건에서 무엇을 처리해야 하는지를 설명합니다. 화면 설계서는 사용자가 그 기능을 어떤 화면에서 보고, 누르고, 입력하며, 다음 단계로 이동하는지를 보여줍니다.

기능은 구체적인데 화면 흐름이 없으면 사용자가 서비스를 어떻게 이용할지 알기 어렵습니다. 반대로 화면은 그럴듯하게 설계되어 있지만 처리 조건이 없으면 개발자가 버튼을 눌렀을 때 정확히 무엇이 일어나야 하는지 판단하기 어렵습니다. 안정적인 개발을 위해서는 두 문서의 역할을 구분하면서 서로 연결해야 합니다.

기능 정의서란 무엇일까?

기능 정의서는 서비스가 제공해야 하는 기능과 시스템의 처리 방식을 구체적으로 설명하는 문서입니다. 기능의 목적, 사용 조건, 입력값, 처리 규칙, 결과, 권한, 예외 상황 등을 정리합니다.

예를 들어 “회원이 예약을 취소할 수 있다”는 문장만으로는 기능이 충분히 정의되지 않습니다. 예약일 몇 시간 전까지 취소할 수 있는지, 결제된 금액은 어떻게 환불되는지, 취소된 시간은 다시 예약 가능 상태가 되는지, 관리자와 사용자에게 어떤 알림을 보낼지까지 결정해야 실제 개발이 가능합니다.

기능 정의서는 주로 다음 질문에 답합니다.

• 이 기능은 왜 필요한가?

• 누가 이 기능을 사용할 수 있는가?

• 어떤 조건에서 실행할 수 있는가?

• 어떤 데이터를 입력하거나 조회하는가?

• 시스템은 입력된 데이터를 어떻게 처리하는가?

• 정상적으로 완료되면 어떤 결과가 발생하는가?

• 실패하거나 조건을 충족하지 못하면 어떻게 처리하는가?

화면 설계서란 무엇일까?

화면 설계서는 서비스에 필요한 화면의 구조와 사용자 인터페이스, 화면 사이의 이동 흐름을 설명하는 문서입니다. 와이어프레임이나 간단한 UI 형태를 사용해 각 화면에 어떤 정보와 조작 요소가 배치되는지를 보여줍니다.

화면 설계서에는 제목, 입력란, 버튼, 목록, 탭, 필터, 팝업과 같은 요소가 표시됩니다. 사용자가 버튼을 누르면 어떤 화면으로 이동하는지, 오류가 발생하면 메시지가 어디에 나타나는지, 데이터가 없을 때 어떤 상태를 보여주는지도 함께 설명할 수 있습니다.

화면 설계서는 주로 다음 질문에 답합니다.

• 사용자는 어느 화면에서 기능을 이용하는가?

• 화면에는 어떤 정보와 조작 요소가 표시되는가?

• 중요한 버튼과 입력 항목은 어디에 배치되는가?

• 사용자가 행동하면 화면은 어떻게 변하는가?

• 완료 후에는 어느 화면으로 이동하는가?

• 로딩, 오류, 빈 데이터 상태는 어떻게 보이는가?

• 모바일과 PC에서 화면 구성이 어떻게 달라지는가?

기능 정의서와 화면 설계서의 핵심 차이

두 문서의 가장 큰 차이는 시스템 동작을 설명하는지, 사용자 경험을 시각화하는지에 있습니다.

• 기능 정의서: 시스템이 처리해야 하는 규칙과 조건을 중심으로 작성합니다.

• 화면 설계서: 사용자가 기능을 이용하는 화면과 상호작용을 중심으로 작성합니다.

기능 정의서에서 “사용자는 주문 상태가 결제 완료일 때만 주문을 취소할 수 있다”고 정의할 수 있습니다. 화면 설계서에서는 결제 완료 상태의 주문 상세 화면에 취소 버튼이 표시되고, 버튼을 누르면 확인 팝업이 나타나는 모습을 표현합니다.

기능 정의서는 취소 가능 조건, 환불 처리, 재고 복원, 알림 발송 같은 내부 규칙을 설명합니다. 화면 설계서는 취소 버튼의 위치, 확인 과정, 처리 중 상태, 완료 메시지와 이동 경로를 설명합니다. 하나의 기능을 서로 다른 관점에서 다루는 것입니다.

기능 정의서에 포함해야 할 항목

기능 정의서는 기능 이름만 모아 놓은 목록이 되어서는 안 됩니다. 개발자가 별도의 추측 없이 처리 방식을 이해할 수 있도록 다음 항목을 포함하는 것이 좋습니다.

1. 기능의 목적

기능을 통해 해결하려는 사용자 문제와 운영 목적을 설명합니다. 목적을 알면 여러 구현 방법 중 적절한 방식을 선택하기 쉬워집니다.

2. 사용자와 권한

일반 회원, 관리자, 파트너 등 어떤 사용자가 기능을 실행할 수 있는지 정의합니다. 본인이 만든 데이터만 수정할 수 있는지, 관리자는 모든 데이터를 처리할 수 있는지도 구분해야 합니다.

3. 실행 조건

기능을 사용할 수 있는 상태와 선행 조건을 적습니다. 로그인 여부, 결제 상태, 승인 여부, 이용 기간처럼 기능 실행에 영향을 주는 조건을 포함합니다.

4. 입력 데이터

사용자가 입력하거나 시스템이 전달받는 데이터를 정의합니다. 필수값과 선택값, 데이터 형식, 글자 수, 파일 크기, 허용 범위와 중복 가능 여부 등을 정리합니다.

5. 처리 규칙

입력된 데이터를 검증하고 저장하거나 계산하는 방식을 설명합니다. 상태가 변경되는 순서, 외부 서비스 호출, 관련 데이터의 동시 변경 여부도 처리 규칙에 포함될 수 있습니다.

6. 결과와 후속 처리

기능이 성공했을 때 생성되거나 변경되는 데이터와 후속 작업을 적습니다. 사용자 화면의 변화뿐 아니라 알림 발송, 로그 저장, 관리자 상태 변경도 확인해야 합니다.

7. 예외와 오류

잘못된 입력, 권한 부족, 중복 요청, 네트워크 실패, 외부 API 오류처럼 정상적으로 완료되지 않는 상황을 정의합니다. 재시도 가능 여부와 데이터 복구 방식도 필요합니다.

화면 설계서에 포함해야 할 항목

화면 설계서는 보기 좋은 이미지를 만드는 문서가 아닙니다. 사용자가 기능을 이해하고 완료할 수 있도록 정보와 행동을 구조화하는 문서입니다.

1. 화면 식별 정보

화면 이름과 고유 ID, 화면의 목적, 접근 가능한 사용자 유형을 표시합니다. 화면이 많아질수록 고유 ID가 있어야 기능 정의서와 개발 작업을 정확하게 연결할 수 있습니다.

2. 화면 구성 요소

제목, 설명, 이미지, 입력란, 버튼, 목록, 필터, 탭, 페이지 구분 등 화면에 필요한 요소를 표시합니다. 각 요소가 필수인지, 어떤 데이터를 보여주는지도 설명해야 합니다.

3. 사용자 행동과 화면 반응

클릭, 입력, 선택, 스크롤과 같은 행동 이후 화면이 어떻게 변하는지 정의합니다. 버튼 활성화 조건, 팝업 표시, 입력 오류 안내, 로딩 상태도 포함합니다.

4. 화면 이동

사용자가 어디에서 들어오고 작업 완료 후 어디로 이동하는지 표시합니다. 이전 화면으로 돌아갈 때 입력한 데이터가 유지되는지와 같은 조건도 확인해야 합니다.

5. 화면 상태

화면은 정상적인 데이터가 있을 때만 존재하지 않습니다. 로딩 중인 상태, 데이터가 없는 상태, 오류 상태, 접근 권한이 없는 상태와 처리 완료 상태를 함께 설계해야 합니다.

6. 반응형 기준

PC, 태블릿, 모바일에서 구성 요소가 어떻게 배치되는지 정의합니다. 단순히 화면 폭만 줄이는 것이 아니라 메뉴, 표, 팝업과 주요 행동의 위치가 어떻게 달라지는지 검토해야 합니다.

하나의 기능을 두 문서로 연결하는 방법

두 문서를 따로 작성하더라도 서로 연결되지 않으면 관리하기 어렵습니다. 기능마다 고유한 기능 ID를 부여하고, 해당 기능이 사용되는 화면 ID를 연결하는 방식이 실무적으로 유용합니다.

예를 들어 예약 취소 기능을 다음처럼 나눌 수 있습니다.

• 기능 정의: 예약 확정 상태이고 이용 시작 24시간 전인 경우 사용자가 취소할 수 있다.

• 처리 규칙: 취소 수수료를 계산하고 결제 취소를 요청한 뒤 예약 시간을 다시 활성화한다.

• 예외 조건: 이용 시간이 임박했거나 이미 사용한 예약은 취소할 수 없다.

• 화면 구성: 예약 상세 화면에 취소 가능 여부와 수수료를 표시한다.

• 사용자 행동: 취소 버튼을 누르면 확인 팝업이 나타나고 최종 동의 후 요청을 전송한다.

• 결과 화면: 완료 메시지와 환불 예정 정보를 보여준다.

이렇게 기능 규칙과 화면 동작을 연결하면 디자이너는 필요한 상태를 빠뜨리지 않고, 개발자는 각 버튼이 실행해야 할 로직을 정확히 이해할 수 있습니다. QA 담당자도 기능 조건과 화면 결과를 함께 검증할 수 있습니다.

어떤 문서를 먼저 작성해야 할까?

일반적으로는 요구사항을 정리한 뒤 핵심 기능의 규칙을 정의하고, 이를 바탕으로 화면 흐름과 구성을 설계하는 순서가 자연스럽습니다.

1. 프로젝트 목적과 사용자 요구사항을 정리합니다.

2. 핵심 기능과 사용자 역할을 구분합니다.

3. 기능별 조건, 데이터, 권한과 예외를 정의합니다.

4. 사용자 흐름과 필요한 화면 목록을 만듭니다.

5. 각 화면의 구성 요소와 상호작용을 설계합니다.

6. 기능 정의와 화면 설계가 일치하는지 함께 검토합니다.

다만 실제 프로젝트에서는 두 문서를 완전히 순차적으로 작성하기 어렵습니다. 기능을 정의하다 보면 필요한 화면이 발견되고, 화면을 설계하다 보면 빠진 기능이나 예외 조건이 드러납니다. 따라서 한 문서를 완성한 뒤 다음 문서로 넘어가기보다 서로 반복해서 검토하는 방식이 효율적입니다.

두 문서가 맞지 않을 때 발생하는 문제

기능 정의와 화면 설계가 서로 다르면 개발 과정에서 추가 질문과 재작업이 발생합니다. 화면에는 버튼이 있지만 실행 조건이 없거나, 기능 정의서에는 처리 규칙이 있지만 해당 상태를 보여줄 화면이 없는 상황이 대표적입니다.

• 화면에 없는 기능을 개발해야 하는 상황

• 동일한 기능이 화면마다 다르게 동작하는 문제

• 권한이 없는 사용자에게 버튼이 노출되는 문제

• 오류와 빈 데이터 상태가 디자인에서 누락되는 문제

• 기능 변경 후 이전 화면 설계가 그대로 남는 문제

• QA와 클라이언트가 서로 다른 기준으로 검수하는 문제

이러한 문제를 막으려면 기능과 화면 사이의 연결 관계를 확인할 수 있어야 합니다. 기능이 변경되면 영향을 받는 화면과 테스트 항목을 함께 확인하고, 화면이 추가되면 필요한 기능과 데이터가 정의되어 있는지 검토해야 합니다.

기능 정의서와 화면 설계서의 변경을 함께 관리해야 한다

프로젝트 중간에 기능 조건이 바뀌면 화면도 영향을 받을 가능성이 큽니다. 예를 들어 회원가입 필수 항목이 추가되면 가입 화면, 입력 검증, 데이터베이스, 관리자 화면, 개인정보 처리 내용까지 변경될 수 있습니다.

따라서 변경 요청에는 단순히 “필드를 하나 추가한다”는 내용만 기록해서는 부족합니다. 어떤 기능과 화면, 데이터, 권한, 알림, 테스트가 영향을 받는지 확인해야 합니다.

• 변경되는 기능과 화면의 ID

• 변경 전 내용과 변경 후 내용

• 변경 사유와 요청자

• 디자인, 개발, QA에 미치는 영향

• 추가 일정과 비용 발생 여부

• 검토자와 최종 승인자

• 반영 버전과 현재 진행 상태

기능 정의서는 최신인데 화면 설계서가 이전 버전이거나, 반대로 화면만 수정되고 기능 규칙이 그대로라면 팀은 서로 다른 기준으로 일하게 됩니다. 두 문서의 버전과 변경 이력을 연결해서 관리하는 것이 중요합니다.

실무에서 확인할 문서 검토 체크리스트

• 모든 핵심 기능이 하나 이상의 화면과 연결되어 있는가?

• 화면의 모든 버튼과 입력 요소에 처리 규칙이 있는가?

• 사용자 역할별 권한이 기능과 화면에 동일하게 반영되어 있는가?

• 성공, 실패, 로딩, 빈 데이터 상태가 정의되어 있는가?

• 필수 입력값과 오류 메시지가 서로 일치하는가?

• 화면 이동 후 데이터와 상태가 어떻게 유지되는지 정리되어 있는가?

• 기능 변경 시 영향을 받는 화면을 찾을 수 있는가?

• 최신 버전과 승인된 변경사항을 확인할 수 있는가?

기능과 화면은 분리해서 정의하고 연결해서 관리해야 한다

기능 정의서와 화면 설계서는 어느 하나로 다른 하나를 완전히 대신할 수 없습니다. 기능 정의서는 시스템의 규칙과 처리 방식을 명확하게 만들고, 화면 설계서는 사용자가 그 기능을 실제로 이용하는 경험을 구체화합니다.

두 문서를 구분하면 각 담당자가 필요한 정보를 빠르게 찾을 수 있습니다. 동시에 기능 ID와 화면 ID, 변경 이력과 승인 기록을 연결하면 문서 사이의 불일치와 누락을 줄일 수 있습니다.

Pronika는 기능, 화면, 요구사항, 담당자, 일정과 변경 이력을 하나의 프로젝트 흐름에서 연결할 수 있도록 돕습니다. 문서를 많이 만드는 것보다 서로 연결된 최신 기준을 유지하는 것이 중요합니다. 기능과 화면의 관계를 명확히 관리하면 외주 개발 과정의 질문과 재작업, 검수 분쟁을 크게 줄일 수 있습니다.