기능명세서 작성법 2026: 양식·예시와 개발사에 넘기기 전 확인할 항목 정리

기능명세서를 검색하면 사내 기획자와 PM을 대상으로 쓴 문서가 자주 나와요. 회사 안에 개발팀이 있고, 옆자리에 물어볼 사람이 있다는 전제로 쓰여 있어요. 그런데 이 문서가 정작 급한 쪽은 개발팀이 없는 발주자예요. 개발사에 넘길 문서를 직접 써야 하는데, 어디까지 쓰고 어디부터 맡겨야 하는지가 어디에도 안 적혀 있어요.

이 글은 발주자 기준으로 정리했어요. 기능명세서 한 행에 어떤 칸이 들어가는지, 기능 한 줄을 어떤 문장으로 쓰는지, 발주자가 초안을 잡을 칸과 개발사가 채울 칸을 어떻게 가르는지, 그리고 명세서 없이 견적을 요청하면 무슨 일이 생기는지까지 다뤄요. 예시 문장은 그대로 옮겨 쓸 수 있게 적었어요.

기능명세서는 무엇이고, 발주자가 왜 직접 써야 하나요?

기능명세서는 만들려는 서비스가 무엇을 하는지 기능 단위로 적어둔 문서예요. 화면이 어떻게 생겼는지가 아니라, 누가 무엇을 하면 무엇이 일어나는지를 적어요. 개발사는 이 문서를 읽고 공수를 세고 견적과 일정을 뽑아요. 즉 이 문서의 정밀도가 곧 견적의 정밀도예요.

발주자가 직접 써야 하는 이유는 간단해요. 여기 적히지 않은 것은 개발사가 추정으로 채우기 때문이에요. 추정으로 채우면 이런 일이 생겨요. 개발사가 안전하게 잡아 금액이 올라가거나, 좁게 잡아 착수 뒤에 추가 비용으로 돌아와요. 개발사가 되물어 해소되는 경우도 있는데, 그건 물어볼 만큼의 뼈대가 문서에 있을 때 이야기예요.

또 하나, 업무 규칙은 개발사가 알 수 없어요. 수수료를 언제 떼는지, 환불을 며칠까지 받는지, 등급이 어떻게 올라가는지는 발주자의 사업 지식이에요. 개발사가 정해줄 수 있는 것은 구현 방법이지 사업 규칙이 아니에요. 기능명세서는 그 사업 지식을 개발사가 읽을 수 있는 형태로 옮기는 작업이에요.

완성도에 대한 부담은 내려놓아도 돼요. 처음부터 완벽한 명세서가 나오는 경우는 드물어요. 개발사가 기대하는 것은 완성도가 아니라 질문을 만들 수 있는 뼈대예요.

기능명세서와 요구사항 정의서, 화면설계서는 어떻게 다른가요?

이 세 문서가 미팅에서 자주 뒤섞여요. 개발사가 요구사항 정의서를 달라고 했는데 발주자가 화면 스케치를 보내고, 화면설계서를 기다리는데 기능 목록만 오는 식이에요. 각 문서의 정의를 외우는 것보다, 기능명세서와 무엇을 주고받는 관계인지를 잡아두는 편이 실무에서 헷갈리지 않아요.

표를 세로로 읽으면 기능명세서가 중간에서 양쪽을 잇는 문서라는 게 보여요. 앞쪽 문서에서 목적과 요구를 받아 기능 행으로 바꾸고, 뒤쪽 문서에 그 행을 그대로 넘겨줘요. 제안요청서 작성 자체가 아직 안 됐다면 RFP 뜻과 작성법 가이드를 먼저 보고 오는 편이 순서에 맞아요.

실무에서는 요구사항 정의서와 기능명세서를 한 장으로 합쳐 쓰는 경우도 흔해요. 문서 개수가 중요한 게 아니라, 기능 한 줄마다 동작과 예외가 붙어 있느냐가 중요해요.

이름 자체가 갈리기도 해요. 같은 문서를 기능 정의서라고 부르는 곳도 있고 기능명세서라고 부르는 곳도 있어요. 기능정의서, 기능 명세서처럼 띄어쓰기만 다른 표기도 섞여 돌아다녀요. 개발사가 기능 정의서를 달라고 했을 때 이름이 다르다고 새 문서를 만들 필요는 없어요. 무엇을 채워 오면 되는지를 되물어서, 기능 한 줄에 동작과 예외가 붙은 표를 원하는 거라면 이 글에서 만드는 문서를 그대로 주면 돼요. 업무상 필요와 그 이유를 묻는 거라면 그건 위 표의 요구사항 정의서 쪽이에요.

기능명세서 한 행에는 어떤 칸이 필요한가요?

머릿속 아이디어에서 항목 자체를 끌어내는 순서는 앱 아이디어를 기능 명세서로 만드는 과정에 정리돼 있어요. 여기서는 그 결과를 담을 그릇, 즉 한 행이 어떤 칸으로 이루어져야 하는지를 다뤄요.

한 기능이 한 행이고, 그 행에 아래 칸들이 붙는 구조면 충분해요. 칸이 많아 보이지만 각 칸은 한 줄이면 채워져요. 오히려 칸을 줄이면 개발사가 물어볼 것이 많아지고, 물어보지 않으면 가정으로 채워져요.

발주자가 자주 비워두는 칸은 실패·예외와 권한이에요. 그런데 이 두 칸이 공수에 직접 붙어요. 예외 처리와 권한 분기는 화면 하나를 여러 벌 만드는 일에 가까워서, 비어 있으면 개발사가 범위를 좁게 잡거나 넓게 잡거나 둘 중 하나를 해요.

비고 칸도 그냥 두지 마세요. 아직 못 정한 것을 비고에 적어두면 개발사가 가정 대신 질문을 해요. 이게 비고 칸에서 발주자가 얻는 실질적인 이득이에요.

기능 한 줄은 어떤 문장으로 쓰나요?

문장 뼈대는 하나예요. 누가 + 무엇을 하면 + 무엇이 된다. 이 세 조각이 다 있으면 개발사가 공수를 셀 수 있고, 검수할 때 참과 거짓을 판정할 수 있어요. 셋 중 하나라도 빠지면 그 줄은 판정이 불가능해요.

좋은 예를 하나 보면 감이 잡혀요. "회원가입 기능"이라고만 쓰지 말고 이렇게 쓰세요. 비회원이 이메일과 비밀번호를 입력해 계정을 만든다. 이메일 형식이 아니거나 이미 가입된 이메일이면 저장하지 않고 입력칸 아래에 안내 문구를 띄운다. 가입이 끝나면 인증 메일을 보내고, 인증 전에는 결제 화면에 들어갈 수 없다.

세 문장이지만 개발사가 알아야 할 것이 다 들어 있어요. 입력값, 검증 규칙, 실패 시 동작, 후속 처리, 그리고 다른 기능과의 관계까지요. 이 정도면 개발사가 되물을 것이 줄고, 남은 질문이 무엇인지도 드러나요.

반대로 피해야 할 것은 형용사예요. 직관적으로, 빠르게, 편리하게, 깔끔하게 같은 말은 검수할 때 참과 거짓을 가릴 수 없어요. 품질을 말하고 싶으면 관찰 가능한 문장으로 바꿔야 해요.

바꾼 문장들이 길어 보이지만, 이 길이가 견적서의 항목 수를 정해요. 짧게 쓴 다섯 줄보다 이렇게 쓴 세 줄이 낫습니다.

기능 ID는 어떻게 매기고, 우선순위 칸은 어떻게 채우나요?

우선순위 칸부터 정리할게요. 어떤 기능을 필수로 볼지 판정하는 절차 자체는 MVP 범위 확정 절차와 경계 기능 판단에 질문 순서와 경계 사례까지 정리돼 있어요. 기능명세서에서 할 일은 그 판정 결과를 우선순위 칸에 옮겨 적는 것까지예요. 명세서 안에서 범위를 다시 논쟁하기 시작하면 문서가 회의록이 돼요.

칸에 적는 값은 세 단계면 충분해요. 필수는 이것이 없으면 사용자가 핵심 행동을 끝까지 이어갈 수 없는 기능, 2차는 초기에 사람이 수동으로 대신할 수 있는 기능, 이번 범위 아님은 이번 계약에서 만들지 않기로 명시해 두는 기능이에요. 단계를 늘리면 중간 등급이 애매해져서 무엇을 뺄지 정하기 어려워져요.

기능 ID는 영역 약자와 번호를 붙이면 끝이에요. 이 ID는 명세서 안에서만 쓰는 이름이 아니라, 견적서와 변경 요청서와 검수표가 같은 기능을 가리키게 만드는 열쇠예요. ID가 없으면 회의록마다 기능 이름이 조금씩 달라지고, 나중에 무엇을 합의했는지 되짚기 어려워져요.

번호는 10 단위로 띄워 두세요. 중간에 기능이 하나 끼어도 뒤를 전부 다시 매기지 않아도 돼요. 그리고 한 번 부여한 ID는 그 기능이 빠지더라도 다른 기능에 재사용하지 않아요. 몇 달 뒤 회의록에서 "그 알림 건"이 어느 것인지 되짚을 때 번호가 겹치면 소용이 없거든요.

정산, 통계, 쿠폰 발급 같은 기능은 초기에는 스프레드시트와 수동 처리로 버틸 수 있는 경우가 자주 있어요. 이걸 2차로 옮기면 첫 견적에서 빠지는 항목이 생겨요. 다만 삭제하지 말고 2차 칸에 남겨 두세요. 나중에 붙일 때 처음부터 다시 설명하지 않아도 되고, 개발사도 그 자리를 비워 둔 채 설계할 수 있어요.

예외와 실패 상황은 어디까지 적어야 하나요?

발주자가 쓴 명세서는 성공 경로만 적혀 있는 경우가 반복적으로 관찰돼요. 로그인하고, 담고, 결제하고, 끝. 그런데 개발 공수는 그 사이의 어긋난 경우들에 붙어요. 결제가 중간에 끊겼을 때 주문을 어떻게 둘지 정해두지 않으면, 그 판단을 개발사가 대신 하게 돼요.

예외를 전부 적을 필요는 없어요. 아래 네 가지 축부터 훑으세요. 입력이 틀렸을 때, 권한이 없을 때, 외부 서비스가 응답하지 않을 때, 이미 처리된 것을 다시 요청했을 때예요.

마지막 축이 실무에서 값이 커요. 결제 버튼을 두 번 누르면 두 번 결제되는지, 같은 신청을 두 번 넣으면 두 건이 되는지는 발주자가 정해야 할 정책이에요. 개발사가 알아서 막아준다고 가정하지 말고, 중복 요청은 뒤엣것을 무시한다처럼 한 줄로 적어두세요.

외부 서비스가 죽었을 때의 문구도 발주자 몫이에요. 결제사가 응답하지 않을 때 사용자에게 무엇을 보여줄지, 다시 시도하게 할지 아니면 접수만 하고 나중에 처리할지는 사업 판단이에요.

권한과 역할은 왜 따로 적어야 하나요?

기능 목록만 쭉 적으면 관리자 쪽이 통째로 빠지는 일이 자주 생겨요. 발주자는 사용자 화면을 떠올리며 쓰고, 그 화면을 관리하는 뒤쪽 화면은 당연히 있는 것으로 여기기 때문이에요. 그런데 관리자 화면은 사용자 화면과 별개로 만들어야 하는 대상이에요.

순서를 뒤집으면 잘 빠지지 않아요. 먼저 역할 목록을 만들고, 그다음에 역할마다 할 수 있는 일을 적는 방식이에요. 비회원, 일반 회원, 판매자, 운영자, 최고관리자처럼 역할을 먼저 세우면 각 역할에 필요한 화면이 자연스럽게 따라 나와요.

역할이 늘어나면 공수도 함께 늘어난다는 점은 알고 있어야 해요. 역할 하나를 추가하면 그 역할이 보는 화면과 못 보는 화면을 전부 정해야 하거든요. 초기에는 역할을 최소로 두고, 권한을 세분화하는 것은 2차로 미루는 편이 안전해요.

여기까지 정리했다면 각 기능 행의 권한 칸에 역할 이름을 그대로 적으면 돼요. 한 기능을 여러 역할이 쓴다면 역할별로 동작이 다른지 확인하세요. 다르면 그 줄은 두 줄로 나눠야 해요.

데이터와 상태 변화는 어떻게 표현하나요?

기능명세서에서 발주자가 놓치기 쉬운 축이 상태예요. 주문, 신청, 예약, 정산처럼 시간이 지나며 단계가 바뀌는 것들은 상태값 목록과 전환 규칙이 있어야 해요. 이게 없으면 화면도, 알림도, 정산도 정할 수 없어요.

적는 방법은 어렵지 않아요. 상태 이름을 나열하고, 각 상태에서 다음으로 갈 수 있는 상태와 그 조건을 적으면 돼요. 예를 들어 주문이라면 결제대기, 결제완료, 준비중, 배송중, 배송완료, 취소, 환불 정도를 두고, 취소는 결제완료와 준비중에서만 가능하다처럼 조건을 붙여요.

누가 상태를 바꾸는지도 함께 적어야 해요. 사용자가 직접 바꾸는지, 관리자가 바꾸는지, 시간이 지나면 자동으로 바뀌는지에 따라 만들어야 할 화면과 처리가 달라져요. 자동 전환이 있다면 기준 시각도 적어두세요.

데이터 항목은 화면에 보이는 값 위주로만 적어도 충분해요. 테이블 설계와 관계 정의는 개발사 몫이에요. 발주자가 할 일은 어떤 값을 보관해야 하고 어떤 값을 나중에 검색하거나 내보내야 하는지를 알려주는 것까지예요.

한 행 안에서 발주자는 어디까지 쓰고, 어디부터 개발사가 채우나요?

기준은 한 문장으로 정리돼요. 발주자는 무엇을 왜 만드는지를 쓰고, 개발사는 그것을 어떻게 만들지를 쓰는 거예요. 프로젝트 산출물 전체를 놓고 무엇을 발주자가 만들고 무엇을 개발사가 만드는지는 MVP 기획, 개발사에 뭘 들고 가야 할까에 4종 산출물 기준으로 정리돼 있어요. 여기서는 범위를 좁혀, 기능명세서 한 행 안에서만 봅니다. 화면 배치, DB 설계, API 구조, 기술 스택, 일정 산정은 애초에 기능명세서가 담는 칸이 아니에요.

표의 네 번째 열이 이 문서의 핵심이에요. 칸을 비우는 것은 아무 일도 일어나지 않는 선택이 아니라, 그 자리에 개발사의 가정이 들어가는 선택이에요. 가정이 사업 규칙과 맞으면 운이 좋은 것이고, 어긋나면 착수 뒤에 변경 비용으로 돌아와요.

반대로 개발사 열에 적힌 것을 발주자가 미리 지정하면 더 나은 방법을 제안할 여지가 사라지고, 문제가 생겼을 때 책임 소재도 흐려져요. 초안이 완벽할 필요는 없고, 각 칸에 누가 답할 사람인지만 분명하면 돼요.

기능명세서가 없으면 견적이 어떻게 되나요?

명세서 없이 아이디어 설명만으로 견적을 요청하면, 회신에서 반복적으로 관찰되는 형태가 셋 있어요. 어느 쪽이든 발주자에게 불리해요.

첫째는 안전 마진이 얹힌 견적이에요. 개발사는 모르는 범위를 비용으로 덮을 수밖에 없어요. 나쁜 의도가 아니라, 모르는 것을 싸게 부르면 개발사가 손해를 보는 구조이기 때문이에요.

둘째는 낮게 부르고 착수 뒤에 추가로 청구하는 방식이에요. 계약서에 범위가 안 적혀 있으니 나중에 나온 요구는 전부 추가 작업이 돼요. 발주자는 처음 들은 금액을 기억하는데 청구는 계속 늘어나는 상황이 여기서 생겨요. 견적서에서 변경 요청 단가와 유지보수 포함 여부를 어떻게 확인하는지는 IT 외주 개발 견적서 완전 분석 가이드에 항목별로 정리돼 있어요.

셋째는 실무에서 특히 성가신 경우예요. 업체 세 곳이 각자 다른 범위를 가정하고 회신해서, 금액을 나란히 놓고 봐도 비교가 안 되는 상황이에요. 같은 기능 목록을 받았어야 비교가 성립하는데 그 축이 없는 거예요. 받은 견적서를 항목 단위로 뜯어보는 방법은 앱 개발 견적서 뜯어보는 법에 정리해뒀어요.

참고로 국내 외주 시장에는 공인된 평균 견적 통계가 없어요. 업체가 제시하는 금액대는 현장 견적 기준이고 공표 통계가 아니에요. 그래서 비교의 기준은 시장 평균이 아니라 우리 기능 목록에 두어야 해요.

개발사가 명세서를 달라고 할 때, 최소한 무엇을 주면 되나요?

모든 칸을 채운 문서를 기다리다 보면 착수가 계속 밀려요. 개발사가 견적을 시작할 수 있는 최소 구성은 한 장이면 돼요. 아래 일곱 블록이 있으면 개발사는 가정 대신 질문을 하기 시작해요.

이 중에서 다섯 번째와 일곱 번째가 발주자에게 특히 유리해요. 안 하는 것을 명시하면 견적 범위가 좁아지고, 못 정한 것을 명시하면 개발사가 임의로 결정하지 않아요. 두 블록 다 기능을 적는 게 아니라 경계를 적는 자리예요.

일곱 블록을 다 채우지 못한 상태로 보내도 괜찮아요. 빈 자리를 아직 못 정한 것 목록에 옮겨 적고 결정 시점만 붙이면, 개발사는 그 자리를 열어둔 채 견적을 낼 수 있어요. 문서가 완성될 때까지 견적 요청을 미루는 것보다 이 편이 나아요.

기능명세서 양식은 어떤 도구로 만드나요?

스프레드시트를 권해요. 이유는 문서가 예뻐서가 아니라 다루기 쉬워서예요. 한 기능이 한 행이면 영역별로 필터를 걸 수 있고, 우선순위로 정렬해 이번 범위만 뽑아낼 수 있어요. 견적을 요청할 때 그 시트를 그대로 보내면 개발사가 옆에 공수 칸을 붙여 회신할 수 있어요.

워드나 한글 문서로 쓰면 읽기는 좋은데 누락 확인이 어려워요. 권한 칸을 안 채운 기능이 몇 개인지 한눈에 보이지 않고, 개발사가 항목별로 회신하기도 번거로워요. 협업 도구를 쓴다면 표 형태로 관리할 수 있고 내보내기가 되는지만 확인하세요.

양식 자체는 앞서 정리한 열 개 칸이면 충분해요. 인터넷에서 받은 복잡한 양식을 억지로 채우려다 보면, 정작 중요한 동작과 예외 칸이 비는 일이 생겨요. 칸을 늘리는 것보다 각 줄의 문장을 판정 가능하게 만드는 편이 훨씬 값이 커요.

파일 관리도 미리 정해두세요. 파일명에 날짜를 넣고, 개발사와 주고받을 창구를 하나로 정하는 것만으로 충분해요. 여러 버전이 메일과 메신저에 흩어지면 어느 것이 합의된 버전인지 나중에 가릴 수 없어요.

착수 뒤 기능이 바뀌면 명세서를 어떻게 관리하나요?

기능은 반드시 바뀌어요. 문제는 바뀌는 것 자체가 아니라, 바뀐 내용이 어디에도 기록되지 않는 것이에요. 그래서 착수 시점의 명세서를 기준선으로 고정하는 절차가 필요해요.

방법은 단순해요. 계약과 함께 그 시점의 명세서를 별도 파일로 저장해 양쪽이 같은 사본을 갖고, 이후 변경은 원본을 덧칠하지 말고 변경 이력으로 남겨요. 어떤 기능이 어떻게 바뀌었고 일정과 비용에 어떤 영향이 있는지가 한 줄씩 쌓이면, 착수 뒤 두어 달이 지나도 합의 내용을 되짚을 수 있어요.

변경을 요청하는 문서 형식과 절차는 변경 요청서(CR) 작성 가이드에 따로 정리돼 있어요. 기능 ID를 명세서와 같은 값으로 쓰면 두 문서가 자연스럽게 맞물려요.

발주자가 자주 하는 걱정이 있어요. 변경을 문서로 남기자고 하면 관계가 딱딱해지지 않느냐는 거예요. 실제로는 반대예요. 기록이 없으면 나중에 기억으로 다투게 되고, 그때가 훨씬 껄끄러워요.

기능명세서를 검수 기준으로 어떻게 바꾸나요?

잘 쓴 기능명세서는 그대로 검수 기준이 돼요. 앞에서 문장 뼈대를 누가 무엇을 하면 무엇이 된다로 잡은 이유가 여기 있어요. 이 문장은 그대로 확인 절차로 바뀌거든요.

비회원이 이메일과 비밀번호를 입력해 계정을 만든다는 줄은, 검수할 때 직접 해보고 계정이 만들어졌는지 보면 끝이에요. 반면 직관적인 가입 화면을 제공한다는 줄은 확인할 방법이 없어요. 형용사를 피하라고 한 것은 문장 취향의 문제가 아니라 검수 가능성의 문제였어요.

검수 전에 할 일은 명세서에서 기능 ID와 동작 문장만 뽑아 목록으로 만드는 거예요. 여기에 확인 결과 칸과 확인자 칸을 붙이면 검수표가 돼요. 사인오프와 잔금 지급 절차까지 묶어서 보려면 산출물 검수·사인오프 가이드를 참고하세요.

한 가지만 미리 합의해두세요. 예외 동작도 검수 대상이라는 점이에요. 성공 경로만 확인하고 넘어가면 잘못된 입력이나 외부 오류 상황은 출시 뒤에 사용자가 먼저 발견하게 돼요.

기능명세서를 쓸 때 자주 나오는 실수는 무엇인가요?

현장에서 반복적으로 관찰되는 것들만 모았어요. 각각이 나중에 비용이나 분쟁으로 이어지는 지점이에요.

• 화면 목록만 있고 동작이 없어요. 화면 이름은 공수를 세는 단위가 아니에요.
• 품질을 형용사로 적어요. 빠르게, 편리하게, 깔끔하게는 검수에서 판정할 수 없어요.
• 관리자 화면과 정산, 알림이 통째로 빠져요. 역할 목록을 먼저 만들면 줄어들어요.
• 성공 경로만 적어요. 공수는 어긋난 경우에 붙는데 그 칸이 비어 있어요.
• 못 정한 것을 빈칸으로 넘겨요. 빈칸은 질문이 아니라 가정으로 채워져요.
• 여러 버전이 동시에 돌아다녀요. 합의된 버전이 무엇인지 나중에 가릴 수 없어요.
• 명세서와 견적서가 서로 다른 이름을 써요. 기능 ID를 공유하면 해결돼요.
• 기능을 잘게 쪼개기만 해요. 개수가 늘어난다고 정밀해지지는 않아요. 한 줄마다 판정 가능한지가 기준이에요.

목록이 길어 보이지만 원인은 두 가지로 좁혀져요. 판정할 수 없는 문장을 썼거나, 경계를 적지 않았거나예요. 명세서를 다 쓰고 나서 이 두 가지만 다시 훑어보세요.

AI 기능이 들어가면 명세서를 어떻게 다르게 쓰나요?

AI 기능은 같은 입력에도 결과가 매번 달라져요. 그래서 동작한다를 인수 기준으로 잡으면 검수 자체가 성립하지 않아요. 평가셋과 회귀 테스트, 환각 사고의 책임 범위, 모델이 업데이트됐을 때의 처리처럼 계약서에서 다뤄야 할 축은 AI·LLM 기능 발주 완전 가이드에 따로 정리돼 있어요. 여기서는 범위를 좁혀, 기능명세서의 칸에 무엇을 적는가만 네 가지로 봅니다.

첫째, 입력 범위와 참조할 문서 범위예요. 무엇을 근거로 답하는지가 정해져야 답의 옳고 그름을 따질 수 있어요. 둘째, 모를 때의 동작이에요. 근거를 못 찾으면 모른다고 답하고 문의로 연결한다처럼 정해두세요. 이 두 가지가 실패·예외 칸에 들어갑니다.

셋째는 사람이 개입하는 지점이에요. 결과를 그대로 사용자에게 보여줄지, 담당자가 확인한 뒤 내보낼지는 사업 판단이라 발주자가 정해야 해요. 넷째는 기록이에요. 어떤 입력에 어떤 출력이 나갔는지 남겨야 문제가 생겼을 때 재현하고 고칠 수 있어요. 이 둘은 동작 칸과 비고 칸에 나눠 적으면 됩니다.

맡길 곳을 고를 때는 무엇이 제품의 중심인지로 가르면 돼요. 앱이나 웹 서비스를 만들고 그 안에 AI 기능이 하나 붙는 형태라면 포텐랩이 맡는 영역이에요. 반대로 챗봇이나 문서 검색처럼 AI 자체가 제품인 경우에는 트리숲(TreeSoop)이 맡아요. 두 팀 다 저희 자산이고, 맞지 않는 쪽으로 보내면 서로 손해라서 기준을 먼저 밝혀요. 어느 쪽에 맡기든 위 네 칸은 발주자가 채워야 하는 자리라는 점은 같아요.

다음 미팅 전에 무엇을 준비하면 되나요?

순서는 이렇게 잡으세요. 먼저 역할 목록을 적어요. 그다음 핵심 흐름 하나를 가입부터 목표 행동까지 순서대로 씁니다. 그 흐름에 나오는 동작을 한 줄씩 기능 행으로 옮기면 뼈대가 생겨요.

그리고 각 행에 세 칸만 먼저 채우세요. 동작, 실패했을 때, 권한이에요. 나머지 칸은 개발사와 이야기하면서 채워도 늦지 않아요. 마지막으로 이번에 안 하는 것과 아직 못 정한 것을 따로 적어 문서 끝에 붙이세요.

미팅에서는 이 문서를 화면에 띄워놓고 기능 ID 순서대로 훑는 방식이 효율적이에요. 개발사가 질문하는 줄이 곧 견적이 흔들릴 줄이에요. 그 자리에서 답이 안 나오면 못 정한 것 목록으로 내리고 결정 시점을 적어두면 돼요.

완벽한 문서를 만드는 게 목표가 아니에요. 개발사가 추정 대신 질문을 하게 만드는 것이 목표예요. 그 지점을 넘으면 견적은 비교할 수 있게 되고, 착수 뒤에 나오는 추가 비용도 줄어들어요.

자주 묻는 질문

기능명세서와 요구사항 정의서는 무엇이 다른가요?

요구사항 정의서는 업무상 무엇이 필요한가와 그 이유를 기능명세서에 넘겨주고, 기능명세서는 그 요구 하나가 기능 몇 개로 갈라지는지를 돌려줘요. 요구사항 정의서가 없으면 기능 목록이 근거 없이 늘어나고, 기능명세서가 없으면 견적이 개발사의 추정으로 채워져요. 실무에서는 두 문서를 한 장으로 합쳐 쓰기도 하는데, 문서 개수보다 기능 한 줄마다 동작과 예외가 붙어 있는지가 중요해요.

기능명세서는 발주자가 직접 써야 하나요, 개발사가 대신 써주나요?

초안은 발주자가 쓰고 개발사가 보완하는 구조가 맞아요. 수수료를 언제 떼는지, 환불을 며칠까지 받는지, 등급이 어떻게 올라가는지 같은 업무 규칙은 개발사가 알 수 없는 사업 지식이거든요. 반대로 화면 배치, DB 설계, API 구조, 기술 스택, 일정 산정은 애초에 기능명세서가 담는 칸이 아니라 개발사가 정하는 영역이에요. 발주자 몫은 완성도가 아니라 개발사가 질문을 만들 수 있는 뼈대까지예요.

기능명세서 한 줄은 어떤 문장으로 써야 하나요?

누가, 무엇을 하면, 무엇이 된다 세 조각을 모두 넣으세요. 회원가입 기능이라고만 쓰지 말고, 비회원이 이메일과 비밀번호를 입력해 계정을 만들고 이미 가입된 이메일이면 저장하지 않고 안내 문구를 띄운다처럼 적는 거예요. 직관적으로, 빠르게 같은 형용사는 검수에서 참과 거짓을 가릴 수 없으니 관찰 가능한 문장으로 바꿔야 해요.

기능명세서에 예외와 실패 상황은 어디까지 적어야 하나요?

전부 적을 필요는 없고 네 가지 축부터 훑으세요. 입력이 틀렸을 때, 권한이 없을 때, 외부 서비스가 응답하지 않을 때, 이미 처리된 것을 다시 요청했을 때예요. 특히 마지막 축은 결제 버튼을 두 번 누르면 두 번 결제되는지 같은 정책이라 발주자가 정해야 해요. 실패·예외 칸을 비우면 그 판단을 개발사가 대신 하게 됩니다.

개발사가 명세서를 달라고 할 때 최소한 무엇을 주면 되나요?

한 장이면 시작할 수 있어요. 서비스 한 문장, 역할 목록, 핵심 흐름 하나, 영역별 기능 목록, 이번에 안 하는 것, 외부 연동 목록, 아직 못 정한 것 일곱 블록이에요. 안 하는 것과 못 정한 것을 적어두면 개발사가 임의로 가정하지 않고 질문을 해요. 일곱 블록을 다 채우지 못했다면 빈 자리를 못 정한 것 목록으로 옮기고 결정 시점만 붙여 보내세요.

기능명세서 양식은 어떤 도구로 만드는 것이 좋나요?

한 기능이 한 행인 스프레드시트를 권해요. 영역별 필터와 우선순위 정렬이 되고, 견적을 요청할 때 개발사가 시트 옆에 공수 칸을 붙여 그대로 회신할 수 있어요. 워드나 한글 문서는 읽기는 좋지만 권한 칸이 빈 기능이 몇 개인지 한눈에 확인하기 어려워요. 협업 도구를 쓴다면 표 형태로 관리되고 내보내기가 되는지만 확인하세요.

함께 읽으면 좋은 글

• 요구사항 정의서와 기능명세서의 차이
• 화면설계서와 와이어프레임의 차이
• 서비스 기획서에 미리 정해둘 항목