기능정의서·기능명세서 작성법 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인가
• 탈퇴 회원도 나오는가
• 부분 일치인가 완전 일치인가
• 결과가 없으면 무엇을 보여주는가

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

기능마다 우선순위를 매긴다

기능 목록이 40개인데 예산이 30개치라면, 무엇을 먼저 버릴지는 착수 전에 정해야 한다. 개발 중반에 정하면 이미 손댄 기능을 버리게 되고, 그 공수는 돌려받지 못한다.

등급은 세 단계면 충분하다. 국제 표기로는 MoSCoW(Must / Should / Could / Won't)를 쓰지만, 실무에서는 한글 세 단계가 더 잘 굴러간다.

⚠️ 필수가 전체의 80%를 넘으면 등급을 안 매긴 것과 같다. 실제로 자주 이렇게 된다 — 발주처 입장에서는 전부 필요해 보이기 때문이다. 이럴 때 쓰는 질문이 「이 기능 없이 오픈하면 무슨 일이 생기나」다. 「불편하다」면 권장이고, 「서비스가 안 된다」여야 필수다.

「범위 밖」을 목록에서 지우지 않는 이유는 앞서 말한 것과 같다. 지운 기능은 나중에 「당연히 포함인 줄 알았다」로 돌아온다. 등급 칸에 「범위 밖 — 2차」라고 적어 두면 그 대화가 안 생긴다.

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

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

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

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

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

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

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

BR-001  재고가 0인 상품은 주문할 수 없다
BR-002  VIP 등급은 배송비가 면제된다
BR-003  주문 취소는 결제 후 24시간 이내만 가능하다

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

성능·보안 같은 비기능 요구사항은 어디에 적나

기능 정의서는 무엇을 만드는가만 센다. 「3초 안에 응답」·「동시접속 500명」·「개인정보 암호화」는 기능이 아니라 조건이다. 그래서 기능 목록에 한 줄로 끼워 넣으면 공수 산정이 망가진다 — 개발사가 그걸 기능 하나로 보고 0.5일을 잡는다.

비기능이 특정 기능에만 걸릴 때는 그 기능 행에 각주로 남긴다. 예를 들어 「엑셀 일괄 업로드」에 「1만 행 기준 30초 이내」가 붙으면 공수가 2일에서 5일로 바뀐다. 전역 조건은 따로 적고, 기능에 매달린 조건은 그 기능 옆에 적는 것이 맞다.

⚠️ 비기능을 아예 안 적으면 개발사는 최소 사양으로 만든다. 그게 틀린 것이 아니라, 적혀 있지 않으면 그게 합의된 범위이기 때문이다.

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

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

요구사항 정의서  →  기능 정의서  →  화면설계서
   (발주처)         (개발사)        (개발사)
 "무엇이 필요"     "무엇을 만듦"    "어떻게 동작"

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

표기도 조직마다 갈린다. 기능 정의서·기능명세서·기능 목록은 대체로 같은 문서를 가리킨다. 공공 사업에서는 「기능 명세서」, SI 에서는 「기능 정의서」, 스타트업에서는 그냥 「기능 목록」이나 「스펙 시트」로 부르는 식이다. 이름이 다르다고 다른 문서를 또 만들 필요는 없고, 계약서와 산출물 목록에 적힌 이름 하나로 통일하면 된다. 헷갈리는 것은 이름이 아니라 앞 표의 「쓰는 사람」과 「관점」 칸이다.

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

발주처가 검토할 때 볼 것

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

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

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

1번(요구사항 대조)은 눈으로 훑으면 반드시 빠뜨린다. 요구사항 정의서의 항목 번호를 한 칸 만들어 기능 ID 를 적어 넣는 방식이 확실하다.

빈 칸이 나오는 행이 곧 누락이다. 요구사항 30개짜리 프로젝트면 30분이면 끝나고, 이 30분이 개발 후반의 범위 협의 몇 번을 없앤다. 반대로 기능 ID 쪽에 대응 요구사항이 없는 행도 봐야 한다 — 요청하지 않은 기능이 들어가 있으면 그만큼 공수가 다른 데서 깎였다는 뜻이다.

흔한 실수 5가지

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

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

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

④ 상태 전이를 나중에 정한다 이력 구조에 영향을 주므로 뒤에 넣으면 재작업이 크다.

⑤ 기능 ID를 중간에 바꾼다 문서 간 연결이 전부 끊어진다. 번호가 비어도 그냥 두고, 재사용하지 않는다.

기능 정의서 완성 7단계

[ ] 1. 요구사항 정의서에서 "할 일"을 전부 뽑는다
[ ] 2. 할 일을 기능 단위로 쪼갠다 (CRUD는 각각 별도)
[ ] 3. 기능 ID 규칙 정하고 번호 부여
[ ] 4. 기능별 입력·처리·출력·예외 작성
[ ] 5. 상태가 있는 기능은 전이표 추가
[ ] 6. 비즈니스 규칙 번호화 후 기능에 연결
[ ] 7. 제외 범위 명시 → 발주처 검토 → 확정

실무에서 막히는 지점은 2번과 6번이다.

2번(기능 단위로 쪼개기) 에서는 쪼개는 기준이 흔들린다. 기준은 하나다 — 공수를 매길 수 있으면 그만 쪼갠다. 「회원 관리」는 공수를 못 매기니 더 쪼개고, 「저장 버튼 클릭」은 매길 필요가 없으니 위로 합친다. 앞서 말한 0.5~5일 구간이 이 기준의 다른 표현이다.

6번(비즈니스 규칙 연결) 에서는 규칙을 어디까지 뽑을지가 문제다. 여러 기능에 걸치면 규칙으로 빼고, 한 기능에만 있으면 그 기능의 「처리」에 그냥 적는다. 규칙 번호를 남발하면 참조가 늘어 오히려 관리가 안 된다.

3번(ID 부여)은 뒤로 미루고 싶어지지만 그러면 안 된다. ID 없이 4~6번을 진행하면 나중에 전부 다시 연결해야 한다.

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

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

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

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

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

자주 묻는 질문

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

발주처가 기능 정의서를 써야 하나요? 아니다. 개발사가 만들고 발주처가 검토한다. 발주처가 직접 쓰는 것은 요구사항 정의서다.

기능을 얼마나 잘게 쪼개야 하나요? 공수를 산정할 수 있는 단위까지다. 「회원 관리」는 너무 크고, 「저장 버튼 클릭」은 너무 작다. 대략 0.5~5일 사이로 떨어지면 적당하다.

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

기능이 나중에 추가되면 어떻게 하나요? 변경 관리 절차를 계약서에 미리 넣어둔다. 기능 ID를 새로 부여하고 공수·일정 영향을 산정해 합의한다.

정리

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

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

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

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

기능 목록이 실제로 어떤 서버·외부 연동 위에 올라가는지는 시스템 구성도 작성법을 참고하면 된다.

기능 ID 가 검수 단계에서 실제로 어떻게 쓰이는지는 테스트 케이스 작성법 — 검수 확인서 7단계에 정리했다.