기획서는 어떻게든 구체적이고 길게 쓰면 잘 쓰는 건 줄 알았습니다.
그래서 신입 시절에 기획서를 되도록 길게 써 왔어요.

배경과 목표를 쓰고, 기능 목록을 만들고, 래퍼런스 화면 캡처까지 붙이면 문서는 자동으로 길어지죠.

문서가 두꺼워지니 기획도 탄탄해진 것 같았습니다.

그렇게 기획서를 길게 쓰면서 스스로 일을 잘한다고 생각하고 있었는데
개발 착수 전날, 개발자에게서 슬랙이 왔습니다.
 

기획서 다 읽긴 했는데요, 주문을 가게가 접수한 다음에는 취소가 되는 거예요, 안 되는 거예요?

답장을 빨리 하긴 해야 되는데, 뭐라고 말을해야 할지 모르겠어서 일단 기획서를 다시 열어 봤습니다. 
계속 읽다 보니까 기능 목록에 ’주문 취소’는 있었지만, 언제 되고 언제 안 되는지는 없었습니다. 

화면 캡처에 취소 버튼은 있었지만, 그 버튼을 누르면 결제와 쿠폰이 어떻게 되는지는 없었습니다. 
배경과 목표 어디에도, 개발자가 코드로 옮길 문장은 한 줄도 없었죠.

오늘은 그 한 줄짜리 기능을 개발 가능한 문장으로 바꾸는 방법을 다뤄볼게요.
즉, 기능명세서를 어떻게 써야 기획이 탄탄해지고 
개발자가 일의 효율을 높일 수 있는지 알려드릴게요
어떤 칸을 왜 채워야 하는지, 주문 취소 기능 하나로 끝까지 따라가 봅니다.

기능명세서는 무엇을 적는 문서인가

먼저 기능명세서는 기능 하나가 어떤 조건에서, 누가, 무엇을 하면, 무엇이 되는지를 적은 문서입니다.

바로 앞 단계 문서인 PRD와 비교하면 역할이 분명해집니다.

PRD는 왜 만들고 무엇을 만드는지를 정합니다. 
“고객이 주문을 스스로 취소할 수 있어야 한다. 취소 문의가 고객센터 문의의 30%라서”
위와 같은 멘트가 PRD의 일이에요.

같은 기능이 기능명세서에서는 이렇게 적힙니다.
 

가게가 접수하기 전까지, 주문한 고객이 주문 상세에서 취소를 누르면, 
결제가 전액 취소되고 가게에 알림이 간다.

PRD가 결정의 이유와 범위를 담는다면, 
기능명세서는 그 결정을 개발자가 코드로 옮길 수 있는 조건으로 바꾸는 문서입니다. 
단순히 기능의 목록을 적는 문서가 아니라는 점이 중요합니다.

기획서가 꼼꼼해도 질문이 돌아오는 이유

그 원인부터 말씀드리자면, 
바로 기획서에 ’무엇’은 있는데 ’언제’와 ’안 되는 경우’가 없어서입니다.

배달 앱을 만드는 한 팀이 기획서에 이렇게 적었다고 해 볼게요.

기능 목록: 주문 취소 기능 
우선순위: 높음 
화면: 주문 상세 하단에 취소 버튼

이렇게 텍스트로 보면 꽤나 잘 정리된 것처럼 보입니다. 
그런데 만약 이대로 기획서가 전달되고 개발이 진행된다면 
개발자는 다시 질문을 할 가능성이 높습니다.
 

가게가 접수한 다음에도 취소돼요? 
결제는 바로 취소되는 거예요, 영업일 기준이에요? 
쿠폰 썼으면 돌려줘요? 
취소 사유는 받아요? 
가게한테는 알려줘요?

이런 질문들을 계속 받다 보면 기획자는 머리가 슬슬 아파올 겁니다.
그런데 이건 기획자가 생각을 안 한 게 아닙니다. 
머릿속에 있던 조건이 개발자가 읽을 수 있는 문장으로 적히지 않았을 뿐이죠.

그럼 같은 기획서를 AI 코딩 도구에 넣으면 어떻게 될까요.

그럼 역으로 질문이 안 돌아옵니다. 
AI는 ’주문 취소 기능’이라는 한 줄을 읽고, 
접수 후 취소도 되게, 쿠폰은 복구 없이, 가게 알림은 없이 만들어 옵니다. 
묻지 않고 알아서 정한 겁니다. 그 결정은 QA에서, 운이 나쁘면 출시 뒤에 발견됩니다.

Sonar가 2026년 1월 개발자 1,100명에게 물은 결과, 
커밋되는 코드의 42%를 이미 AI가 쓰고 있고 2027년에는 65%가 될 거라고 답했습니다. 
같은 조사에서 96%는 AI가 쓴 코드가 기능적으로 맞는지 완전히 믿지 못한다고 했고, 
커밋 전에 항상 확인한다는 응답은 48%였습니다.

<출처: Sonar, State of Code Developer Survey Report 2026, sonarsource.com>

되묻는 개발자든 안 묻는 AI든, 비어 있는 조건은 누군가가 정해야됩니다.
기획자가 정하지 않으면 개발자가 정하고, 개발자도 안 정하면 AI가 정합니다. 
기능명세서는 그 ’누군가’가 팀이 되게 하는 문서입니다.

그럼 기능명세서가 있으면 뭐가 달라지는데요?

우선 아까부터 계속 언급했던
개발자가 다시 되물어 볼 질문이 줄어들겁니다. 
그런데 이건 딱히 큰 변화는 아니죠.

더 큰 변화는 기획자가 한 번 적은 문장을 세 사람이 그대로 쓴다는 점이에요.

기능명세서에 이렇게 한 줄이 있다고 해 볼게요.

가게가 접수하기 전 주문에서 고객이 취소를 누르면, 
주문 상태가 '취소'로 바뀌고 결제가 전액 취소된다.

개발자는 개발을 시작하기 전에 이 문장을 읽고 할 일의 크기를 가늠합니다.
"결제 취소까지 들어가면 결제 모듈 쪽 작업이 하나 더 생기네요"처럼요.

기획서에 '주문 취소 기능' 한 줄만 있었다면 위의 말은 개발 도중에 나왔을 겁니다.

QA(제품 테스트)는 개발이 끝난 뒤 같은 문장을 체크리스트로 씁니다.

1. 접수 전 주문에서 취소를 누른다
2. 상태가 '취소'로 바뀌었는지 본다
3. 결제 취소 내역이 생겼는지 본다.

문장을 그대로 따라 하면 테스트가 되니까 따로 테스트 항목을 만들 필요가 없어요.

AI 코딩 도구는 같은 문장을 읽고 그대로 만듭니다.
'언제, 누가, 무엇을 하면, 무엇이 된다'가 한 문장에 있어서 묻지 않아도 되거든요.

한 번 적은 조건이 개발 전 설명, 개발 후 검증, 구현에 그대로 쓰이니
기획자가 같은 말을 세 번 하지 않아도 됩니다.
기획서를 길고 꼼꼼하게 쓰는 것과 기능명세서를 쓰는 것의 차이는 문장 단위에서 드러납니다.

왼쪽은 기능 목록이고 오른쪽이 기능명세서입니다.
오른쪽 문장은 개발자가 읽고 만들 수 있고, 
QA 할 때 확인할 수 있고, AI가 그대로 구현할 수 있습니다.

기능 한 개의 항목에 들어가는 다섯 칸

정리하자면 기능명세서는 기획서를 더 길게 쓰는 게 아니라, 두 단계를 거치는 일입니다.
먼저 기능 한 줄을 항목으로 나누고, 그다음 항목 하나하나에 같은 다섯 칸을 채우는 것이죠.
그 항목들이 뭔지 이제 알려드릴게요.

[1단계: 기능 하나에 일어날 수 있는 여러 케이스를 생각해본다.]

'주문 취소 기능' 한 줄은 사실 기능 하나가 아니라 묶음입니다.
앞에서 개발자가 던진 질문 다섯 개를 그대로 항목으로 바꾸면 이렇게 됩니다.

접수 전 취소: 고객이 직접 취소한다

접수 후 취소: 고객은 취소 요청만 하고, 가게가 승인해야 취소된다

결제 취소: 취소가 확정되면 결제를 전액 취소한다

쿠폰 복구: 취소가 확정되면 사용한 쿠폰을 돌려준다

취소 사유: 고객이 사유를 하나 고른다

가게 알림: 취소가 확정되면 가게 앱에 알림을 보낸다

한 줄이 여섯 항목이 됐습니다.
개발자가 물었을 질문이 곧 항목이라, 질문을 먼저 적어 보면 항목은 저절로 나옵니다.

[2단계: 항목마다 다섯 칸을 채웁니다]

이제 항목 하나를 놓고, 개발자가 그대로 만들 수 있을 만큼 적습니다.
적을 건 다섯 가지예요.

언제, 누가, 무엇을 하면, 무엇이 된다, 어떻게 확인하나.

앞에서 본 "가게가 접수하기 전 주문에서 고객이 취소를 누르면, 
주문 상태가 '취소'로 바뀌고 결제가 전액 취소된다"는 
문장이 바로 이 다섯 가지를 한 줄로 이어 붙인 겁니다.
여섯 항목 중 '접수 전 취소' 하나로 따라가 볼게요.

1. 언제: 동작 조건

'주문 취소'라고만 적으면 개발자는 모든 주문에서 취소되는 걸로 만듭니다.
그래서 첫 칸에는 조건부터 적습니다.

주문 상태가 '결제 완료'이고, 가게가 아직 접수하지 않았을 때.

이 한 줄이 있으면 "접수 후에도 돼요?"가 사라집니다.
접수 후는 '취소 요청' 항목이 따로 맡으니까요.

2. 누가: 주체

주문한 고객.

짧지만 빠지면 큰 칸입니다.
가게 사장도 취소할 수 있는지, 고객센터 상담원도 되는지가 여기서 갈리거든요.
이 항목에는 고객만 적고, 가게와 상담원의 취소는 별도 항목으로 뺍니다.

3. 무엇을 하면: 사용자의 행동

주문 상세 화면에서 '주문 취소'를 누르고, 취소 사유를 하나 고른다.

"취소 사유는 받아요?"의 답이 여기 있습니다.
받는다, 필수다, 하나만 고른다. 결정 세 개가 한 문장에 들어 있어요.

4. 무엇이 된다: 결과

주문 상태가 '취소'로 바뀐다. 
결제가 전액 취소된다. 
사용한 쿠폰은 돌아온다. 
가게 앱에 취소 알림이 간다.

결과는 한 문장에 하나씩 적습니다.
"쿠폰 돌려줘요?"와 "가게한테 알려줘요?"가 여기서 사라지고,
AI 코딩 도구도 네 가지를 네 가지로 읽습니다.

5. 어떻게 확인하나: 완료 기준

가장 자주 비는 칸입니다.

접수 전 주문에서 취소를 누르면 상태가 '취소'로 바뀌고 결제 취소 내역이 생긴다.
접수 후 주문에서는 '주문 취소' 버튼이 보이지 않고 '취소 요청' 버튼만 보인다.

이 두 줄이 있으면 개발자는 이 상태가 될 때까지만 만들면 되고,
QA를 할 때는 이 두 줄을 그대로 체크리스트로 쓰면 됩니다.
없으면 "이 정도면 된 거죠?"를 서로 물어보다가 끝나거든요.

하나 더: 왜 이렇게 정했나

다섯 칸 옆에 칸 하나를 더 두면 좋습니다.

접수 후 취소를 막은 이유는 조리를 시작한 뒤 취소가 들어오면 
손실이 가게에 돌아가기 때문. 9월 12일 회의에서 결정.

지금 만드는 사람보다 다음에 읽는 사람을 위한 칸이에요.
담당자가 바뀌어도 "이거 왜 이렇게 했어요?"가 안 돌아오고,
조건이 바뀌었을 때(가게 손실을 플랫폼이 보존하기로 했다면) 
어느 결정을 다시 봐야 하는지 바로 보이거든요.

그럼 어디까지 써야 할까요?

여기까지 읽으셨다면 
"아니.. 모든 기능마다 이렇게까지 다 쪼개야 하나?"라는 생각이 드실 겁니다.

그렇게 생각하지 마시고 하나의 기준을 잡아보세요.
개발자나 AI가 알아서 정하게 두면 안 되는 결정만 적는다.

취소 버튼이 빨간색인지, 확인 팝업이 뜨는지는 안 적어도 됩니다.
디자이너와 개발자 재량이고, 틀려도 고치는 비용이 작거든요.

그러나 결제 취소가 실패하면 어떻게 할지는 적어야 합니다.
AI는 이 경우를 "성공했다"고 가정하고 넘어가는 일이 많아서요.

어느 항목부터 손대야 할지 모르겠으면 질문 세 개로 시작하면 됩니다.

"이 기능이 안 되는 경우는 언제지?"
"이걸 내가 정하지 않으면 누가 정하게 되지?"
"다 만들어졌는지 뭘 보고 알지?"

그럼에도 불구하고, 뭐부터 적어야 할지 막막하면, 
기능 하나를 골라 '이 기능을 쓰다가 생길만한 변수'와 같은 것들부터 적어 보세요.
접수 후, 결제 실패, 이미 배달 출발 등등. 
안 되는 경우를 적다 보면 적어야 할 조건이 저절로 나옵니다.

여기까지 오셨다면 
이제 당신의 기능명세서는 한 층 업그레이드 될 준비가 됐어요.
그런데 여기서 생각해보셔야 할 문제가 하나 더 있습니다.

조건은 어디에 흩어져 있나

그 문제는 바로 막상 칸을 채우려고 하면 
조건이나 정책들이 한 곳에 모여있지 않을 가능성이 높다는 것입니다.

예를 들어, 취소 조건은 회의록에 있고, 환불 정책은 CS 매뉴얼에 있고,
쿠폰 복구 여부는 지난 분기 슬랙 어딘가에 있죠.

이 상태에서 AI에게 파일 같은 걸 다 집어넣고서
"다 읽고 기능명세서 써 줘"라고 하면 그럴듯한 표는 나옵니다.
문제는 비어 있는 칸을 AI가 기본값으로 채운다는 점이고,
그 기본값이 팀의 결정과 다르다는 건 개발이 끝난 뒤에 알게 됩니다.

그래서 순서가 중요합니다.
AI에게 표를 그리게 하기 전에, 비어 있는 칸을 팀이 먼저 보는 것.

매니패스트는 이 순서로 기획서를 만드는 도구입니다.
PRD에서 정한 범위가 기능명세서의 항목으로 이어지고,
항목마다 비어 있는 조건을 AI가 먼저 묻고, 답은 팀이 정합니다.
채워진 문서는 유저플로우와 와이어프레임까지 같은 조건으로 이어지고,
Cursor나 Claude Code 같은 AI 코딩 도구가 그대로 읽습니다.

물론 조건을 대신 정해 주지는 않습니다.
접수 후 취소를 막을지 말지는 여전히 팀이 정할 일이에요.
다만 그 질문이 개발이 끝난 뒤가 아니라 개발 전에 나오게 됩니다.

마무리하며

기능명세서는 기획서를 더 길게 쓰는 일이 아닙니다.
팀이 정한 조건을, 개발자와 AI가 되묻지 않고 그대로 만들 수 있는 문장으로 바꾸는 일이에요.

오늘 해 볼 수 있는 건 작습니다.
기획서에서 한 줄짜리 기능 하나를 고르고, 개발자가 물을 질문부터 다섯 개 적고,
그 질문을 언제, 누가, 무엇을 하면, 무엇이 된다, 어떻게 확인하나로 옮기는 것.

그리고 한 가지만 확인해 보세요.
지금 우리 기획서의 조건은 누가 정하고 있는지.
기획자가 정하지 않은 조건은 개발자가 정하고, 개발자도 정하지 않으면 AI가 정합니다.

기획서는 있는데 개발자의 질문이 줄지 않는다면,
그 질문을 기능명세서의 첫 칸으로 옮겨 보세요.