Self-Growth·실행·2026-01-12

개발자와 대화하는 법 (2편): 기획서에 꼭 들어가야 할 기술 요구사항 체크리스트

“이 기능은 사업적으로 중요합니다”보다 중요한 건 “정확히 언제 실행되나요?”입니다. 개발자가 “바로 작업 들어갈 수 있어요”라고 말하는 기획서의 필수 항목을 정리했습니다.

“사업적으로 중요합니다”는 개발자에게 중요하지 않다

슬랙에 메시지가 도착합니다.

“○○ 기능 개발 부탁드려요. 기획서 첨부합니다.”

개발자가 문서를 엽니다. 첫 페이지: “시장 배경 및 사업 중요성” 두 번째 페이지: “타겟 고객 분석” 세 번째 페이지: “기대 효과”

4페이지에 가서야 기능 설명이 나옵니다. 하지만 정작 중요한 건 없습니다.

“쿠폰 발급 기능을 추가한다.”

그래서… 정확히 언제 발급되는 건가요? 중복 발급은 안 되나요? 쿠폰 재고가 떨어지면요?

개발자는 다시 슬랙을 엽니다.

“확인했는데, 몇 가지 질문이 있어요…”

이 패턴, 너무 익숙하지 않나요?

1편에서는 개발자가 “기술적으로 어렵다”고 할 때 어떻게 물어볼지 다뤘습니다. 이번 2편은 아예 그런 상황을 줄이는 법입니다.

“이 기획서면 바로 작업 들어갈 수 있어요.”

이 한 마디를 듣는 순간, 기획자로서 느끼는 안도감과 신뢰 구축의 시작점을 경험해보셨나요? 오늘은 그 방법을 정리합니다.

왜 기획서를 3번씩 고치게 되는가

개발자와 기획자는 같은 문서를 다른 방식으로 읽습니다.

기획자가 중요하게 생각하는 것:

왜 이 기능이 필요한가 (Why)
어떤 가치를 만드는가 (Value)
사업 목표와 어떻게 연결되는가 (Impact)

개발자가 기획서에서 찾는 것:

정확히 언제 실행되는가 (When)
어떤 조건일 때 동작하는가 (Condition)
예외 상황은 어떻게 처리하는가 (Exception)

기획자는 ‘왜’를 설명하는데 5페이지를 쓰고, 개발자는 ‘언제’를 찾는데 10분을 씁니다.

제가 3년차 때 실제로 있었던 일입니다.

기획서 제목: “푸시 알림 개선 기획”

1페이지: 현재 알림 오픈율 분석
2페이지: 경쟁사 벤치마킹
3페이지: 개선 시 예상 효과
4페이지: (드디어) 기능 설명 “개인화된 알림을 보낸다”

개발자 질문:

“개인화는 어떤 기준인가요?” “알림은 언제 보내나요?” “사용자가 알림 끄면요?” “하루에 몇 번까지 보낼 수 있나요?”

저는 이렇게 답했습니다.

“그건… 사용자 행동 패턴에 따라 다를 것 같은데요.” “알림을 끈 고객은 거의 없을 거예요.”

개발자는 답답했을 겁니다. “거의 없다”를 코드로 어떻게 짜나요?

그날 이후 깨달았습니다. 사업 배경 5페이지보다, 명확한 트리거 조건 3줄이 개발자에게는 더 중요하다는 것을.

💬 개발자 시점 인터뷰

포스팅을 쓰면서, 실제 개발자 3명에게 물어봤습니다. “기획서 받았을 때 가장 먼저 뭘 찾아보세요?”

5년차 백엔드 개발자Q. 기획서에서 가장 먼저 찾아보는 게 뭔가요?

A. “이 기능이 언제 실행되는지요. 트리거가 명확하지 않으면 코드 짤 수가 없거든요. ‘주문 완료 시’라고만 쓰여 있으면, 결제 완료 직후인지, 상품 준비 완료 후인지, 배송 시작 시점인지 알 수가 없어요. 그럼 다시 물어봐야죠.”

Q. 가장 답답한 순간은?

A. “기획자가 **’당연히 그렇게 되어야죠’**라고 할 때요. 개발자는 ‘당연함’을 코드로 못 짜요. 명확한 조건이 필요해요. ‘당연히 중복 결제 안 되게 막아야죠’라고 하는데, 10초 안에 두 번 누르면? 동시에 두 개 탭에서 결제하면? 이런 거 하나하나가 코드 한 줄 한 줄이거든요.”

4년차 프론트엔드 개발자Q. 기획서에서 제일 아쉬운 부분은?

A. “화면 상태 정의가 없는 거요. 버튼 하나만 해도, 기본 상태 / 비활성 상태 / 로딩 상태 / 에러 상태가 있거든요. 기획서에는 ‘저장 버튼’이라고만 쓰여 있는데, 저장 중일 때는? 네트워크 끊겼을 때는? 사용자가 연타하면? 다 물어봐야죠.”

Q. 기획자에게 바라는 게 있다면?

A. “스크린샷이나 레퍼런스 링크를 넣어주세요. ‘○○처럼 만들어주세요’보다, ‘배달의민족 앱 주문 화면처럼’이라고 하면 훨씬 빨라요. 백 마디 말보다 하나의 예시가 명확하거든요.”

7년차 풀스택 개발자Q. 가장 시간 낭비라고 느낄 때는?

A. “기획서 앞부분에 마케팅 내용이 3페이지인데, 정작 기능 스펙은 반 페이지일 때요. ‘이 기능이 왜 중요한지’는 킥오프 미팅에서 듣고 싶어요. 문서에는 ‘무엇을, 어떻게’만 명확하게 적어주세요.

그리고 **’그런 고객은 없을 거예요’**라는 말… 정말 자주 듣는데, 개발자는 ‘없을 거야’로 코드 못 짜요. 만약 생기면? 그게 예외 처리거든요.”

Q. 좋은 기획서의 기준은?

A. “첫 페이지에 기능 요약이 3줄로 있고, 바로 다음에 트리거 조건 / 데이터 명세 / 예외 케이스가 나오는 문서요. 읽고 5분 안에 ‘아, 이렇게 짜면 되겠다’는 그림이 그려지면 좋은 기획서예요.”

개발자가 기획서를 펼치는 순간부터 코드를 짜기까지

한번 상상해봅시다. 개발자가 기획서를 받고, VS Code를 열고, 첫 번째 함수를 작성하기 시작하는 그 순간까지의 과정을.

1. 기획서를 연다 → “이 기능이 뭐지?” (기능 요약을 찾음)

2. 코드 구조를 떠올린다 → “언제 실행되지?” (트리거를 찾음)

3. 함수 이름을 작성한다 → function sendCoupon() {

4. 조건문을 쓴다 → “어떤 조건일 때 실행되지?” (조건을 찾음)

5. 막힌다 → “데이터를 어디서 가져오지?” (데이터 명세를 찾음)

6. 다시 막힌다 → “쿠폰 재고가 없으면?” (예외 처리를 찾음)

7. 기획서에 없음 → 슬랙을 연다: “질문 있어요…”

이 과정에서 막히는 지점들이 바로 기획서에 빠진 항목입니다.

✅ 개발자가 바로 작업 들어가는 기획서 체크리스트

이제 본론입니다. 아래 체크리스트는 개발자가 기획서를 보고 “바로 코드 짤 수 있다”고 말하는 필수 항목들입니다.

섹션 A: 기능 동작 정의

1. “정확히 언제” 동작하나요? (트리거 조건)

기획자가 가장 많이 놓치는 부분입니다.

❌ 나쁜 예	✅ 좋은 예
“쿠폰을 발급한다”	“회원가입 완료 후 5초 이내에 쿠폰을 발급한다”
“알림을 보낸다”	“주문 상태가 ‘배송 중’으로 변경된 시점에 푸시 알림을 보낸다. 단, 사용자가 알림 수신 동의한 경우에 한함”
“포인트가 적립된다”	“결제 완료 후 24시간 이내에 포인트가 자동 적립된다. 환불 시에는 적립 취소”

핵심 질문:

이 기능은 “어떤 이벤트 발생 시” 실행되나요?
사용자가 버튼을 누를 때? 시스템이 자동으로? 특정 시간에?
실행 조건을 한 문장으로 쓸 수 있나요?

2. 예외 상황은? (경계값, 에러 케이스)

“그런 고객은 없을 거예요”라고 말하는 순간, 예외 케이스가 생깁니다.

반드시 정의해야 할 예외 상황:

네트워크가 끊겼을 때
데이터가 없을 때 (null, 빈 값)
사용자가 중복 실행할 때 (연타, 새로고침)
동시에 여러 명이 접근할 때
시스템 에러가 발생했을 때

실전 예시: 쿠폰 발급 기능

Advertisement본문 중간 · 반응형본 도메인에서만 게재

상황	처리 방법
쿠폰 재고가 0개일 때	“쿠폰이 모두 소진되었습니다” 메시지 표시 + 버튼 비활성화
이미 발급받은 사용자가 다시 시도	“이미 발급받은 쿠폰입니다” 토스트 메시지 표시
발급 API 호출 실패 시	3회까지 재시도, 실패 시 “잠시 후 다시 시도해주세요” 표시
비회원이 접근 시	로그인 화면으로 이동

섹션 B: 데이터 명세

3. 어떤 데이터를 어디서 가져오나요?

“사용자 이름”이라고만 적으면 안 됩니다.

명확하게 정의해야 할 것:

데이터가 저장된 위치 (회원 정보? 주문 정보? 외부 API?)
데이터 형식 (텍스트? 숫자? 날짜?)
필수값인가, 선택값인가

실전 예시: 주문 알림 발송

항목	설명
받는 사람	주문자 정보 테이블 > 휴대폰 번호 (필수값)
메시지 내용	“주문번호 {order_id}가 배송 중입니다”
order_id	주문 테이블 > 주문번호 (8자리 숫자)
배송업체명	주문 테이블 > delivery_company (텍스트, 최대 20자)

4. 데이터가 없을 때는? (Null 처리)

모든 데이터에는 “없을 수도 있다”는 가능성이 있습니다.

예시:

데이터	없을 때 처리
프로필 사진	기본 아바타 이미지 표시 (URL: /assets/default-avatar.png)
전화번호	“전화번호 미등록” 텍스트 표시 + 등록 버튼 활성화
주소	주문 불가 안내 + “배송지 등록하기” 버튼 표시
쿠폰 사용 기한	“기한 없음” 표시

섹션 C: 화면 상태와 권한

5. 누가 이 화면을 볼 수 있나요?

권한 분기는 보안의 기본입니다.

권한별 분기 예시: 주문 상세 화면

사용자 유형	접근 권한	표시 항목
비회원	접근 불가	로그인 화면으로 리다이렉트
일반 회원 (본인)	조회 가능	주문 정보, 배송 조회, 취소 버튼
일반 회원 (타인)	접근 불가	“권한이 없습니다” 에러 페이지
관리자	전체 조회 + 수정	추가로 “주문 상태 변경” 버튼 표시

6. 버튼 상태 정의

하나의 버튼에도 최소 4가지 상태가 있습니다.

예시: “결제하기” 버튼

상태	조건	표시
기본	결제 가능한 상태	파란색 버튼 “결제하기”
비활성	필수 정보 미입력 (주소, 결제수단)	회색 버튼 + “배송지를 입력해주세요” 툴팁
로딩	결제 API 호출 중	버튼 안에 로딩 스피너 + “결제 중…” 텍스트
중복 클릭 방지	한 번 클릭 후	버튼 비활성화 (3초간)

섹션 D: 외부 연동

7. 제3자 서비스 연동 정보

결제, 지도, 소셜 로그인 등 외부 API를 쓴다면 필수입니다.

체크 항목:

API 문서 URL
테스트 계정 / API 키 발급 여부
개발 환경 / 운영 환경 분리 여부
응답 실패 시 처리 방법

예시: 카카오 로그인 연동

항목	내용
API 문서	https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api
필요한 정보	카카오 앱 키 (REST API 키)
발급 담당자	김개발 ([email protected])
응답 실패 시	“카카오 로그인에 실패했습니다” 토스트 메시지 + 일반 로그인 화면으로 이동

섹션 E: 성능/정책 고려사항

8. 예상 사용량

“하루 100명”과 “하루 10만 명”은 개발 방식이 완전히 다릅니다.

물어볼 것:

동시 접속자는 몇 명 정도 예상되나요?
데이터는 얼마나 쌓이나요? (일별, 월별)
트래픽이 몰리는 특정 시간대가 있나요? (예: 이벤트 시작 시각)

예시:

이벤트 쿠폰 선착순 1000명 → 동시 접속 5000명 예상 → 서버 부하 대비 필요
일반 회원가입 기능 → 하루 평균 50명 → 기본 구조로 충분

9. 데이터 보관 기간

GDPR, 개인정보보호법 등 법적 이슈와 연결됩니다.

정의해야 할 것:

사용자 로그는 언제까지 보관하나요?
회원 탈퇴 시 데이터는 즉시 삭제? 30일 후?
결제 정보는 법적으로 5년 보관 필요 (전자상거래법)

실전 템플릿: 기획서 자가진단 체크리스트

아래 체크리스트를 기획서 마지막 페이지에 붙여놓고, 개발자에게 전달하기 전에 체크해보세요.


[ ] 이 기능은 "누가" "언제" "무엇을" 하는 건가요? (한 문장 요약)

[ ] 트리거 조건을 명확하게 정의했나요?
    예: "○○ 버튼 클릭 시", "매일 오전 9시", "주문 완료 후 5초 이내"

[ ] 예외 상황 3가지 이상 정의했나요?
    (네트워크 에러, 데이터 없음, 중복 실행, 권한 없음 등)

[ ] 사용할 데이터의 출처를 명시했나요?
    (어느 테이블? 어느 API? 어떤 형식?)

[ ] 데이터가 없을 때 처리 방법을 적었나요?
    (기본값? 에러 메시지? 다른 화면으로 이동?)

[ ] 권한/상태별 분기를 표시했나요?
    (비회원 vs 회원, 본인 vs 타인, 관리자 등)

[ ] 버튼/UI 요소의 상태를 정의했나요?
    (기본, 비활성, 로딩, 에러 상태)

[ ] 외부 API 사용 시 문서 링크와 계정 정보를 첨부했나요?

[ ] 예상 사용량과 트래픽을 공유했나요?
    (동시 접속자, 데이터 증가량 등)

[ ] 개발자가 참고할 레퍼런스를 첨부했나요?
    (타 서비스 링크, 스크린샷, 유사 기능 사례)

[ ] 마케팅/사업 배경 설명은 1페이지 이내로 줄였나요?
    (개발자는 '왜'보다 '무엇을, 어떻게'가 필요합니다)

Before & After: 실전 기획서 비교

같은 기능을 두 가지 방식으로 작성한 예시입니다.

❌ Before: 재질문 받는 기획서

제목: 쿠폰 자동 발급 기능 개발 요청

1. 배경 현재 우리 서비스의 신규 가입자 전환율은 35%입니다. 경쟁사 A는 50%를 기록하고 있으며, 이는 신규 가입 시 즉시 쿠폰을 제공하기 때문으로 분석됩니다.

2. 목표 신규 가입자에게 쿠폰을 즉시 발급하여 첫 구매 전환율을 15%p 향상시킵니다.

3. 기대 효과

신규 회원 첫 구매율 증가
마케팅 비용 절감
브랜드 호감도 향상

4. 기능 설명 회원가입 시 자동으로 5000원 쿠폰을 발급합니다.

→ 개발자의 질문:

“회원가입 완료 직후? 이메일 인증 후?”
“쿠폰 재고가 없으면?”
“중복 가입 시도하면?”
“발급 실패 시에는?”

After: 바로 작업 들어가는 기획서

제목: 쿠폰 자동 발급 기능 개발 요청

[기능 한 줄 요약] 회원가입 완료 후 5초 이내에 5000원 쿠폰을 자동 발급하는 기능

[트리거 조건]

실행 시점: 회원가입 API 응답 성공 후 5초 이내
발급 대상: 신규 회원 (회원 상태 = ‘active’)
발급 쿠폰: “신규가입 축하 쿠폰” (쿠폰 ID: NEW_USER_2024)

[데이터 명세]

사용자 정보: users 테이블 > user_id (PK)
쿠폰 정보: coupons 테이블 > coupon_id = ‘NEW_USER_2024’
발급 기록: issued_coupons 테이블에 insert
- user_id (bigint)
- coupon_id (varchar 20)
- issued_at (datetime)

[예외 처리]

상황	처리 방법
쿠폰 재고 0개	“쿠폰이 모두 소진되었습니다” 팝업 표시. 발급 기록은 남기지 않음
이미 발급받은 회원	중복 발급 차단 (DB unique 제약). 에러 로그만 기록
발급 API 실패	3회 재시도 (1초 간격). 3회 실패 시 관리자 알림 발송
비활성 회원 (탈퇴/정지)	발급하지 않음

[화면 노출]

회원가입 완료 화면에서 “5000원 쿠폰이 발급되었습니다!” 토스트 메시지 3초간 표시
쿠폰함으로 이동하는 버튼 함께 표시

[성능 고려사항]

예상 발급량: 하루 평균 200건, 이벤트 기간 최대 1000건
동시 가입 시나리오: 거의 없음 (일반 가입 flow)

[레퍼런스]

무신사 앱: 회원가입 후 쿠폰 자동 발급 화면 (스크린샷 첨부)
배달의민족: 쿠폰 재고 소진 시 처리 방식 (링크)

[비즈니스 배경] (참고용) 신규 가입자 전환율 35% → 50% 목표. 경쟁사 벤치마킹 결과 쿠폰 즉시 발급이 효과적.

→ 개발자의 반응: “네, 이 정도면 바로 작업 들어갈 수 있어요. 예상 소요 시간 2일입니다.”

핵심 원칙 3가지

모든 체크리스트를 외울 필요는 없습니다. 아래 3가지 원칙만 기억하세요.

1. “당연함”을 코드로 못 짠다

“당연히 중복 방지해야죠” → 어떻게? “당연히 에러 처리해야죠” → 어떤 에러를?

“당연함”을 구체적 조건으로 바꾸세요.

2. “없을 거예요”는 없다

“그런 고객은 없을 거예요” “그렇게 안 팔 거예요” “그런 경우는 생기지 않아요”

모두 예외 케이스가 됩니다. 미리 정의하세요.

3. 마케팅 3페이지 < 트리거 3줄

개발자는 기능의 가치를 이해하고 싶어 합니다. 하지만 기획서에서는 ‘무엇을, 어떻게’가 우선입니다.

사업 배경은 킥오프 미팅에서, 기술 스펙은 문서에서.

마지막 팁: 개발자에게 먼저 물어보기

기획서를 다 쓰고 나서 개발자에게 던지기 전에, 초안 단계에서 15분만 시간을 내서 물어보세요.

“이 기능 기획 중인데, 개발 관점에서 꼭 정의해야 할 게 뭐가 있을까요?”

이 한 마디가 3번의 수정을 막아줍니다.

맺음말

“이 기능은 비즈니스에 정말 중요합니다”는 PM에게 중요한 말입니다. 하지만 개발자에게는 “정확히 언제 실행되나요?”가 더 중요합니다.

기획서의 목적은 설득이 아니라 실행입니다. 개발자가 기획서를 덮고 바로 키보드를 두드릴 수 있게 만드는 것. 그게 좋은 기획서입니다.

1편에서 “기술적으로 어렵다”는 말에 대응하는 법을 배웠다면, 2편에서는 그런 상황 자체를 줄이는 법을 배웠습니다.

다음 기획서를 쓸 때, 위 체크리스트를 옆에 두고 하나씩 체크해보세요. 개발자로부터 “이 기획서면 바로 작업 들어갈 수 있어요”라는 말을 듣는 순간, 협업의 새로운 단계가 시작될 겁니다.