기능 정의서 작성법 2026 — 기능 ID·상태 정의와 화면설계서 역할 분담 7단계

# 기능 정의서 작성법 2026 — 기능 ID·상태 정의와 화면설계서 역할 분담 7단계

기능 정의서는 "무엇을 만드는가"의 목록이다

기능 정의서를 한 줄로 말하면 만들 기능을 빠짐없이 세어 놓은 표다.

화면설계서와 헷갈리기 쉬운데, 둘은 보는 축이 다르다.

한 기능이 여러 화면에 걸치고, 한 화면에 여러 기능이 들어간다. 그래서 둘 다 필요하다.

예를 들어 「회원 등록」이라는 기능 하나가 입력 화면·확인 화면·완료 화면 세 개에 걸친다. 반대로 「회원 목록」 화면 하나에 조회·검색·정렬·엑셀 다운로드 네 기능이 들어간다.

화면 쪽 작성법은 화면설계서 작성법 — 항목·예시 8단계에 따로 정리했다.

견적이 여기서 나온다

발주처가 기능 정의서를 과소평가하는 이유는 문서가 밋밋해 보이기 때문이다. 그런데 실제로 견적을 산정하는 근거가 이 표다.

개발사는 대략 이렇게 계산한다.

기능이 40개면 견적이 나오고, 기능 목록이 없으면 견적이 안 나온다. 그래서 목록이 비어 있으면 개발사는 리스크를 얹어 부르거나, 싸게 부르고 나중에 추가 비용을 청구한다.

⚠️ 위 공수는 시장에서 통용되는 범위이고 프로젝트·스택에 따라 달라진다. 업체 간 비교 기준으로만 쓰는 것이 맞다.

기능 ID — 추적성의 시작

기능마다 번호를 붙인다. 이게 없으면 검수 단계에서 "그 기능이 되는 거냐"를 확인할 방법이 없다.

```

MEM-F-001 회원 등록

MEM-F-002 회원 목록 조회

MEM-F-003 회원 검색 (이름·연락처·가입일)

MEM-F-004 회원 등급 변경

ORD-F-001 주문 접수

```

영역 3자 + F + 일련번호면 충분하다. 규칙보다 중요한 건 한번 부여한 번호를 바꾸지 않는 것이다.

이 ID가 아래 네 곳에 그대로 연결된다.

추적성(traceability)이라고 부르는 게 이것이다. 요구사항 → 기능 → 화면 → 테스트 → 검수가 한 줄로 이어져야 나중에 "이 요구사항이 어디서 구현됐나"를 답할 수 있다.

기능 하나에 적어야 할 6가지

입력·처리·출력이 핵심이고, 예외가 실무에서 가장 자주 빠진다.

「회원 검색」이라고만 적혀 있으면 개발자는 이런 것들을 알 수 없다.

• 검색 조건을 여러 개 넣으면 AND인가 OR인가
• 탈퇴 회원도 나오는가
• 부분 일치인가 완전 일치인가
• 결과가 없으면 무엇을 보여주는가

→ 결국 물어보거나, 안 물어보고 임의로 정한다. 후자가 더 비싸다.

상태가 있는 기능은 상태 전이를 그린다

주문·결제·승인처럼 상태가 바뀌는 기능은 목록만으로 부족하다. 어떤 상태에서 어떤 상태로 갈 수 있는지 정의해야 한다.

표에 없는 전이는 불가능하다는 뜻이다. 이게 명시돼 있어야 "완료된 주문을 되돌릴 수 있나요?" 같은 질문이 개발 중반에 안 나온다.

⚠️ 되돌리기(rollback) 가능 여부를 반드시 정한다. 나중에 넣으려면 이력 테이블 구조를 다시 짜야 하는 경우가 많다.

비즈니스 규칙은 어디에 적나

「재고가 0이면 주문 불가」 같은 업무 규칙이 문서 여기저기 흩어지면 관리가 안 된다.

규칙에도 번호를 붙여 한곳에 모으고, 기능에서 참조한다.

```

BR-001 재고가 0인 상품은 주문할 수 없다

BR-002 VIP 등급은 배송비가 면제된다

BR-003 주문 취소는 결제 후 24시간 이내만 가능하다

```

규칙이 바뀔 때 한 곳만 고치면 되고, 영향받는 기능을 바로 찾을 수 있다. 실무에서 규칙은 반드시 바뀐다.

요구사항 정의서·명세서와의 관계

문서 셋의 관계가 자주 헷갈린다. 순서로 보면 명확하다.

```

요구사항 정의서 → 기능 정의서 → 화면설계서

(발주처) (개발사) (개발사)

"무엇이 필요" "무엇을 만듦" "어떻게 동작"

```

기능 정의서는 요구사항 명세서의 핵심 부분을 표로 뽑아낸 것이라고 보면 대체로 맞다. 조직에 따라 둘을 하나로 합치기도 한다.

발주 문서 전체 지도는 요구사항 정의서 작성법 — 외주 문서 7단계에 정리했다.

발주처가 검토할 때 볼 것

개발사가 기능 정의서를 주면 다섯 가지만 확인해도 범위 다툼의 대부분을 막는다.

1. 내가 요청한 것이 다 있는가 — 요구사항 정의서와 하나씩 대조한다
2. 없는 것이 명시돼 있는가 — 「이번 범위 아님」 표시가 있어야 나중에 다툼이 없다
3. 예외 처리가 적혀 있는가 — 정상 흐름만 있으면 절반이 빈 문서다
4. 상태가 바뀌는 기능에 전이표가 있는가
5. 기능 ID가 붙어 있는가 — 없으면 검수를 할 수 없다

⚠️ 2번이 특히 중요하다. "당연히 되는 줄 알았다"가 가장 흔한 분쟁 원인이고, 제외 항목을 문서에 적는 것이 유일한 예방책이다.

흔한 실수 5가지

① 기능명만 나열하고 끝낸다

「회원 관리」 한 줄로는 아무것도 정해지지 않는다. 등록·조회·수정·삭제·검색·권한변경이 각각 다른 기능이다.

② 예외를 안 적는다

중복 데이터, 값 없음, 권한 없음, 외부 연동 실패. 실무 사고는 전부 여기서 난다.

③ 제외 범위를 안 적는다

있는 것만 적고 없는 것을 안 적으면, 발주처는 "당연히 포함"이라고 생각한다.

④ 상태 전이를 나중에 정한다

이력 구조에 영향을 주므로 뒤에 넣으면 재작업이 크다.

⑤ 기능 ID를 중간에 바꾼다

문서 간 연결이 전부 끊어진다. 번호가 비어도 그냥 두고, 재사용하지 않는다.

기능 정의서 완성 7단계

```

[ ] 1. 요구사항 정의서에서 "할 일"을 전부 뽑는다

[ ] 2. 할 일을 기능 단위로 쪼갠다 (CRUD는 각각 별도)

[ ] 3. 기능 ID 규칙 정하고 번호 부여

[ ] 4. 기능별 입력·처리·출력·예외 작성

[ ] 5. 상태가 있는 기능은 전이표 추가

[ ] 6. 비즈니스 규칙 번호화 후 기능에 연결

[ ] 7. 제외 범위 명시 → 발주처 검토 → 확정

```

AI-Native 팀이 기능 정의서를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 기능 정의서에서 어려운 것은 작성이 아니라 빠진 것을 찾아내는 일이다.

• 누락 기능 도출 — 요구사항 정의서와 기능 목록을 대조해 "이 요구사항에 대응하는 기능이 없다"를 찾는다
• 예외 케이스 확장 — 정의된 입력·처리 규칙에서 빠질 수 있는 경우를 뽑아 예외 항목을 보강한다
• 추적성 유지 — 기능 ID가 화면설계서·테스트·검수 문서에서 어긋나지 않는지 대조한다

기능 정의서의 품질은 개발이 끝난 뒤 "이건 범위에 없었다"는 말이 나오지 않는가로 판가름난다. 대조 작업을 자동화해 사람이 업무 규칙 판단에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

기능 정의서와 화면설계서 중 뭐가 먼저인가요?

기능 정의서가 먼저다. 무엇을 만들지 정해야 화면을 그릴 수 있다. 다만 실무에서는 병행하며 서로 보완하는 경우가 많다.

발주처가 기능 정의서를 써야 하나요?

아니다. 개발사가 만들고 발주처가 검토한다. 발주처가 직접 쓰는 것은 요구사항 정의서다.

기능을 얼마나 잘게 쪼개야 하나요?

공수를 산정할 수 있는 단위까지다. 「회원 관리」는 너무 크고, 「저장 버튼 클릭」은 너무 작다. 대략 0.5~5일 사이로 떨어지면 적당하다.

제외 범위는 어떻게 적나요?

「이번 범위 아님 — 2차 검토」처럼 목록에 함께 남긴다. 아예 안 적는 것보다 제외로 적어 두는 편이 분쟁을 막는다.

기능이 나중에 추가되면 어떻게 하나요?

변경 관리 절차를 계약서에 미리 넣어둔다. 기능 ID를 새로 부여하고 공수·일정 영향을 산정해 합의한다.

정리

기능 정의서는 견적과 범위 합의의 근거 문서다. 화면설계서가 "어떻게 동작하는가"를 다룬다면, 기능 정의서는 "무엇을 만드는가"를 센다.

실무에서 결과를 가르는 지점은 셋이다.

1. 예외를 적었는가 — 정상 흐름만 있으면 절반이 빈 문서다
2. 제외 범위를 적었는가 — "당연히 되는 줄 알았다"를 막는 유일한 방법이다
3. 기능 ID가 끝까지 유지되는가 — 검수와 변경 관리가 여기에 걸려 있다

이 셋만 챙겨도 개발 후반의 범위 다툼이 대부분 사라진다.