특강) 기능명세서 + 목적별 문서 작성법(중급)

[게시글 목차]

 

1. 기능정의서란 무엇인가

2. 좋은 기능정의서의 조건

3. 기능정의서 작성 순서

4. 실전 사례로 보는 기능정의서 작성 (댓글 / 검색 / 헤더 / 이메일 인증)

5. 목적별 문서 작성법의 핵심 원칙 : 독자 정의와 Why·How

6. 문서 유형별 작성 가이드 : PRD, 사용자 리서치 보고서, 경쟁사 분석 보고서

+) 오늘의 인사이트 / KPT 회고

 

활동 내역

• 아티클 카타) 기획 하네스로 상세기획 워크플로우 자동화+AI 그대로 복붙 STOP!
• 데이터 드리븐 기획 Part 2.(작성 중)
• Onalign(흩어진 의견을, 하나의 방향으로) 기획서_v_21(이전 내용 총합본)

 

---

 

기능명세서와 목적별 문서 작성법
-
mekite는 초급에서 중급으로 진화했다...!

 

 

1. 기능정의서란 무엇인가

• 특정 기능이 사용자 입력부터 시스템 처리, 결과 출력까지 어떤 규칙과 조건에 따라 동작하는지를 정의한 문서다.

기능정의서에 담기는 내용
UI 구성 요소	검색창, 버튼, 결과 리스트 등 무엇이 있는지
동작 규칙	클릭, 입력, 스크롤 시 어떻게 변화하는지
데이터 규칙	어떤 기준으로 데이터를 노출하는지
예외 및 상태 처리	조회수가 동일할 때, 결과가 0건일 때 등 예외 케이스

• 기획명세서(PRD)의 연장선에 있는 문서 → 디자이너·개발자가 같은 이해를 갖게 만드는 것이 본질적인 목적
• 실제로 담당자가 여러 차례 바뀌면서 기능정의서가 제대로 남아 있지 않아,
  개발자에게 코드를 역추적해 기능정의서를 다시 작성해 달라고 요청한 사례가 있을 정도로,
  이 문서의 부재는 실무에서 꽤 심각한 문제로 이어진다.

 

2. 좋은 기능정의서의 조건

• 개발자의 질문 횟수를 줄이는 문서여야 한다.
  헷갈릴 만한 내용은 예시를 함께 적는다.
• 필수 기능과 필수가 아닌 기능을 구분한다.
  필수 기능은 반드시 동일하게 구현되어야 하고,
  비필수 기능은 기획 의도만 지켜지면 구현 방식은 유연하게 열어둔다(1안/2안 제시 방식).
• 예외 케이스와 엣지케이스를 사전에 다양하게 고려한다.
• 완벽한 문서는 없다는 전제하에, 아직 정리되지 않은 고민은 비고나 댓글로 남기고 계속 업데이트한다.

 

3. 기능정의서 작성 순서

순서	내용
1	와이어프레임을 기준으로 UI 요소를 나열한다.
2	유사한 케이스를 벤치마킹한다.
3	각 요소별로 동작 규칙 혹은 데이터 규칙을 정의한다.
4	정상 케이스 이외의 예외 케이스를 보완한다.

 

4. 실전 사례로 보는 기능정의서 작성

🔹댓글 입력창

[로그인 유도 방식]

① 클릭 즉시 로그인 화면으로 이동

② 알럿 노출 후 확인 클릭 시 이동
→ 두 가지 안 중 하나를 선택해야 하는데, 이 선택 기준은 개발 리소스가 아니라 UX 관점이어야 한다는 점이 핵심이다.

 

• 글자 수 제한(예 : 300자)도 근거가 있어야 한다.

• 댓글이라는 콘텐츠의 성격과 데이터 저장 비용을 함께 고려한 결과다.

• 도배 방지 정책처럼 화면에 보이지 않는 규칙도 놓치기 쉬우므로 별도로 명시해야 한다.

※ 플레이스홀더(텍스트 미입력 시 노출되는 안내 문구)

🔹댓글 정렬과 데이터 노출

• 정렬 버튼(순공감순/최신순/공감비율순) 클릭 시 재정렬 규칙과 함께 디폴트 정렬값을 명시해야 한다.

• 탈퇴 회원 처리는 일반적으로 댓글을 자동 삭제하지 않는 쪽이 통상적인 정책인데, 그 근거는 탈퇴 후에는 동일인임을 증명할 방법이 없다는 데 있다.

→ 그래서 탈퇴 시점에 '게시글은 삭제해주지 않는다'는 동의 절차가 선행되어야 한다.

• 삭제된 댓글의 표기 방식(완전 삭제 vs '삭제된 댓글입니다' 표기), 답글 연동 여부까지 함께 고려 대상이 된다.

→ 일반화된 정책이 존재하긴 하지만, 서비스 특성에 따라 달라질 수 있다는 점은 참고하되 맹신해서는 안 된다.

🔹헤더와 검색 영역

• 로고 클릭 시 이동 방식(현재창/새창), 향후 로고 변경 가능성 같은 세부 사항도 비고로 남긴다.
• 반응형 분기(PC/모바일에서 햄버거 메뉴 노출 여부)는 반드시 명시해야 하는 항목이다.
• 검색은 클릭 이동과 엔터 입력 이동, 두 경로 모두를 적어야 하는데 엔터 케이스는 눈에 보이지 않아 누락되기 쉽다.
• 태그로 찾기 영역의 노출 개수 기준(고정 10개 vs 최소~최대)은 관리 편의성 관점에서 판단한다.

🔹검색 결과 리스트

• 검색 대상 범위(제목/본문 등)를 명시하고, 노출 요소별 필수 여부를 구분한다(썸네일 필수 등).

• 노출 순서 기준(정확도순/최신순)과 기본 노출 개수, 초과 시 더보기 버튼 규칙을 정의하고, 검색 결과 0건인 케이스는 별도로 정의해야 한다.

🔹이메일 인증(회원가입)

• 인증 버튼 클릭 → 인증 메일 발송 → 제한시간 카운트 → 인증번호 입력창 생성이라는 흐름 순서대로 정의한다.

• 유효성 체크는 이메일 형식 오류와 중복 가입 이메일, 두 케이스 각각의 알럿 처리를 나눠서 적는다.

 

5. 목적별 문서 작성법의 핵심 원칙 : 독자 정의와 Why·How

• 문서를 쓰기 전에 읽는 사람을 먼저 정의한다.
  '내가 쓰고 싶은 것'이 아니라 '읽는 사람이 알아야 할 것'을 쓰는 것이 원칙이다.

확인해야 할 질문
이 문서를 읽는 사람은 누구인가	의사결정자(C-Level, 팀장)인가, 실행자(개발자, 디자이너)인가, 협업자인가. 같은 정보라도 읽는 사람에 따라 깊이가 달라진다.
독자가 이 문서에서 무엇을 얻어야 하는가	승인이 필요하면 판단 근거 중심으로, 개발이 필요하면 구현 스펙 중심으로, 방향 설정이 필요하면 공통 인식 형성 중심으로 구성이 달라진다.
독자의 현재 지식 수준은 어디인가	배경을 모른다면 맥락 설명이 먼저 필요하다. (내가 안다고 남들도 당연히 알 것이라는 생각을 버려야만 한다!)

• 여기서 중요한 건 수준의 높고 낮음이 아니라, 나와 얼마나 많은 맥락을 공유하고 있는가라는 관점이다.
  같이 오래 일한 동료에게는 생략해도 되는 설명이, 처음 만나는 임원에게는 반드시 필요한 설명일 수 있다.
  '이 사람이 모든 걸 알고 있을 것'이라는 가정 자체가 잘못된 전제가 될 수 있다는 점을 유의해야 한다.
• Why + How : 결론이나 액션 아이템만 던지면 '그래서 뭘 하라는 거야'라는 반응이 나온다.
  ex. QA 리포팅에서 '파란색 버튼이 활성화되지 않습니다'라고만 쓰면, 작성자는 이해하지만 개발자는 어떤 상황에서 발생한 문제인지 알 수 없다.
  → 문제가 발생한 맥락(무엇을 입력했을 때, 어떤 상태에서)까지 적어야 개발자가 원인을 찾을 수 있다.
  이 역시 '내가 쓰고 싶은 것'이 아니라 '읽는 사람이 알아야 할 것'이라는 원칙의 연장선이다.

 

6. 문서 유형별 작성 가이드

CASE 1. 기획서(PRD / 서비스 기획서)

• 읽는 사람은 개발자, 디자이너, 유관 부서다. 목적은 두 층위로 나뉜다.

• 무엇을, 왜 만드는지 공통으로 이해하는 상위 기획, 그리고 어떻게 만들지 실행 기준을 제공하는 상세 기획이다.

🔹상위 기획에 들어가야 할 요소

• 배경과 문제 정의 : 왜 이 기능을 지금 만들어야 하는지. 시장 상황이나 경쟁 구도 변화 같은 배경 설명 없이 결론만 던지면, 같은 정보를 공유하지 않은 사람은 '왜 갑자기 이걸 하냐'는 반응을 보이게 된다.
• 왜 지금 해결해야 하는가 : 지금 해결하지 않았을 때의 리스크나 손실
• 목표와 성공 지표 : 막연한 목표가 아니라 측정 가능한 기준
• 타겟 사용자 : 전체 사용자를 다 커버할 수는 없으므로, 어떤 사용자군을 우선 타깃으로 삼을지
• 범위 : 이번에 할 것과 하지 않을 것의 경계

🔹상세 기획에 들어가야 할 요소

• 화면 흐름(선택 사항, 필요한 경우에만) : 어떻게 진입하고 이탈하는지, 문제가 되는 지점
• UI 구성 요소, 동작 규칙, 상태 정의(기능정의서 파트와 동일한 내용)
• 정책별 예외 처리와 디자이너가 커버해야 할 화면들(에러 페이지, 팝업 등)
• 일정과 우선순위 : 일정이 먼저 고정되어 있다면 스펙을 덜어내야 하고, 일정에 여유가 있다면 스펙을 기준으로 합리적인 일정을 산정한다. 이 우선순위 판단은 앞서 정의한 목표에 근거해야 한다.

CASE 2. 사용자 리서치 보고서

• 읽는 사람이 의사결정자이므로 '무엇을 발견했는가'보다 '그래서 무엇을 해야 하는가'가 핵심이다.

• 발견 자체가 목적이 아니라, 발견을 근거로 어떤 의사결정을 내려야 하는지가 최종 목적지다.

• 요약 : 핵심 발견 3~5개와 시사점을 맨 앞에 배치
• 리서치 목적과 알고자 했던 질문
• 방법론 : 인터뷰/설문/사용성 테스트 등 조사 방식, 대상자 수와 특성, 기간(신뢰도를 판단하는 근거).
  ex. 보상 없는 설문조사와 시간당 상당한 보상을 지급한 UT는 응답의 신뢰도 자체가 다르다.
• 주요 발견 : 데이터와 인용으로 뒷받침하되, 해석과 사실을 명확히 구분한다.
  사용자의 발언을 그대로 인용하는 것과 그 발언을 작성자가 해석한 내용은 다른 층위이므로 섞지 않는다.
• 페인포인트 / 니즈 / 행동 패턴
• 시사점 : 발견이 제품 방향에 주는 의미
• 제안 : 우선순위가 매겨진 실행 제안
• (선택) 페르소나, 저니맵, 한계점과 추가 조사 필요 사항

  ⇒ '사용자가 이렇더라'에서 끝내지 않고 '따라서 제품은 이 방향으로 가야 한다'까지 연결!

CASE 3. 경쟁사 분석 보고서

• 전략기획·경영진 대상이므로 나열이 아니라 '우리의 판단'으로 귀결되어야 한다.

• 경쟁사 분석이 필요한 이유도 목적에 따라 갈린다.

→ 같은 시장을 두고 직접 경쟁하는 곳을 보는 이유와, 특정 역량(예 : 개인화)을 잘하는 곳을 벤치마킹 대상으로 보는 이유는 서로 다른 기준이므로, 선정 기준 자체를 구분해서 밝혀야 한다.

 

• 요약 및 핵심 결론 : 시장에서 우리의 위치와 권고 방향
• 분석 목적과 범위 : 어떤 시장, 어떤 경쟁사를 왜 봤는지
• 경쟁사 선정 기준 : 직접·간접·잠재 경쟁자 구분
• 비교 프레임워크 : 기능, 가격, 타깃, UX, 비즈니스모델 등 축을 정해 표로 비교(기능은 한쪽이 만들면 금방 따라잡히므로, 오히려 타깃과 비즈니스 로직 차이가 더 본질적인 비교 축이 되는 경우가 많다)
• 시장·환경 분석 : 시장 규모, 트렌드 → (선택) SWOT, 포지셔닝 맵
• 경쟁사별 강점·약점과 전략적 움직임
• 기회와 위협, 갭 분석 : 경쟁사가 채우지 못한 공백
• 우리의 포지셔닝 제언과 전략적 시사점 : 차별화 방향, 대응 옵션
  → (선택) 리스크와 근거 데이터 출처

 

  ⇒ 정보 정리가 아니라 '그래서 우리는 어떻게 포지셔닝하고 대응할 것인가'라는 인풋을 제공!

 

 

---

오늘의 인사이트

 

특강은 나뉘어 있지만 결국...

어떤 문서이든 '누가, 왜 이 문서를 읽는가?'를 충족하느냐가 중요하다는 게 강조된다.

 

내가 얼마나 열심히 준비를 했는가보다는 요점만 적는 게 좋다는 건데...

문제는 독자가 튜터라면...?이다.

과제로 문서를 작성하다보니 데스크 리서치부터 문제 정의, 해결방안까지

모든 걸 다 근거 있게 작성해야 한다면

문서가 자연스레 길어지는 데 이걸 어떻게 분량조절을 해야 할지 막막하다.

이전 과제에서 '튜터님이니까 이 부분은 아시겠지 룰루~♬'하고 제출했다가

서면 피드백에서 보강할 부분으로 언급됐었다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

(근데 토글로 상세 내용 접어서 작성해도 PDF로 변환하면 다 열려서 이상하게 되든데...)

 

그리고 아마도 개인차일 가능성이 높지만

특강별로 문서화 형식이 달라서 참고하는 재미가 있다.

(참고로 나는 기획명세서 특강이 작성하기 좋아 보였음
cuz 공문서와 형식이 비슷해서...ㅋㅋㅋ)

 

 

---

 

오늘의 KPT 회고

 

Keep	• 기능정의서·PRD·리서치보고서·경쟁사분석까지 서로 다른 문서 형식을 관통하는 하나의 원칙('독자가 누구고 무엇을 얻어야 하는가')으로 정리해낸 점 • 특강별 문서 형식 차이를 비교해보면서 내가 편하게 느끼는 스타일을 파악한 점 → 향후 문서 작성 시 강점을 살릴 포맷 판단에 활용 가능
Problem	• 독자가 튜터인 과제의 경우, 실제로는 '이미 다 아는 사람'이 아니라 '근거를 채점해야 하는 사람'이라는 이중 역할이라 일반적인 독자 정의 원칙을 그대로 적용하기 애매함 • 데스크리서치 → 문제정의 → 해결방안까지 전부 근거를 갖추려다 보니 분량 조절 기준이 없었음(무엇을 생략해도 되는지 판단 근거 부재) • 토글로 접어서 분량을 줄이는 방식이 PDF 변환 시 전부 펼쳐져 버려 실제로는 분량 조절 수단으로 작동하지 않음(도구적 한계)
Try	• 제출 전 '이 튜터가 이 문서에서 확인하려는 게 뭘까'를 먼저 리스트업하고, 그 리스트에 없는 내용은 쳐내는 연습을 별도로 진행 • 분량 조절이 필요할 땐 토글 대신 '요약 섹션 + 상세 부록' 구조로 물리적으로 문서를 분리(아예 진짜 공문서처럼 별첨 처리해버릴까...?) • 다음 과제 제출 전, 이번에 정리한 두 특강 원칙(독자 정의, Why·How)을 체크리스트 형태로 만들어 자가 점검에 활용