IT회사에서 성장하는 이야기

PM이라면 요구사항 전달 전에 반드시 검토해야 할 5가지 본문

스터디

PM이라면 요구사항 전달 전에 반드시 검토해야 할 5가지

somsamtam 2025. 3. 23. 16:05

제대로 된 요구사항 정리는 개발 생산성, 일정 준수, QA 효율성의 핵심입니다.
PM으로서 요구사항을 전달하기 전에 반드시 점검해야 할 5가지 요소를 실무 중심으로 정리했습니다.

 

PM이 요구사항 전달 전에 반드시 검토해야 할 5가지

 


📑 목차: PM이 요구사항 전달 전에 반드시 검토해야 할 5가지

PRD에 들어가야 하는 내용들: https://www.notion.com/ko/templates/product-requirement-document-prd

 

  1. 기능 요구사항 vs 비기능 요구사항의 명확한 구분
      - 정의와 예시
      - 체크리스트: 사용자 시나리오 / 성능·보안 등 비기능 항목 확인
  2. 요구사항 간의 의존성과 기존 기능과의 연계 검토
      - 기능 간 선후 관계 예시
      - 체크리스트: 선행 시스템, 영향 받는 기존 기능, 구현 순서
  3. 호환성과 연동 방식 확인 (DB, API 등)
      - 외부 연동 이슈 사례
      - 체크리스트: DB 구조, API 포맷, 테스트 시나리오
  4. 요구사항 변경 가능성에 대한 사전 대응
      - 변화에 따른 영향 범위
      - 체크리스트: UX 변경, 보안 반영, API 확장 대응
  5. 기능 우선순위의 명확한 구분
      - 우선순위 기준: 핵심 vs 부가 기능, 사용자 영향도
      - 체크리스트: 필수 기능 여부, 단계적 릴리즈 계획

1. 기능 요구사항 vs 비기능 요구사항의 명확한 구분

요구사항 문서에서 가장 흔히 발생하는 오류는 기능과 비기능을 구분하지 않고 섞는 것입니다. 이는 개발자에게 혼란을 주고, 구현 범위를 명확히 판단하지 못하게 만듭니다.

  • 기능 요구사항: "사용자가 로그인할 때 OTP를 통해 다중 인증을 할 수 있게 한다."
  • 비기능 요구사항: "OTP는 3초 이내에 전송되어야 하며, 데이터는 암호화된 상태로 전송되어야 한다."

🛠 PM의 체크리스트

  • 기능 요구사항은 사용자 시나리오로 표현했는가?
  • 비기능 요구사항은 성능, 보안, 확장성, 안정성 등으로 명확히 나뉘어 있는가?

2. 요구사항 간의 의존성 및 기존 기능과의 연계 검토

요구사항은 독립적으로 보일 수 있지만, 실제 구현 시에는 다른 기능에 강하게 의존할 수 있습니다. 이를 놓치면 개발 순서가 꼬이고, 일정이 지연되며, 테스트 불가능한 기능이 생깁니다.

📌 예시:
“이벤트 캐시 수령 시 본인인증이 필요” → 본인인증 기능이 먼저 개발되지 않으면 캐시 지급 기능도 테스트할 수 없습니다.

🛠 PM의 체크리스트

  • 이 기능을 위해 선행되어야 하는 시스템이 있는가?
  • 기존 기능 중 변경되거나 영향을 받는 요소는 무엇인가?
  • 기능 간 순서를 재조정할 필요는 없는가?

3. 호환성과 연동방식 확인 (DB, API 등)

요구사항에서 기술적으로 가장 문제가 되기 쉬운 부분은 호환성입니다.
DB 테이블 형식이나 외부 시스템 연동 방식이 맞지 않으면 개발자 입장에서는 데이터 변환 로직을 따로 만들어야 하며, 이는 큰 리스크가 됩니다.

📌 예시:
다날 본인인증 API를 연동할 때, 당사 플랫폼의 인증 처리 방식과 다르다면 별도의 연동 모듈이 필요하며 테스트 방식도 달라질 수 있습니다.

🛠 PM의 체크리스트

  • DB 구조와 연동 방식이 기존 시스템과 호환되는가?
  • 외부 연동 API의 데이터 포맷 및 인증 방식은 사전 확인했는가?
  • 테스트 시나리오(성공/실패 케이스)는 준비되어 있는가?

4. 요구사항 변경 가능성에 대한 사전 대응

요구사항은 변하지 않을 것 같지만, 반드시 변합니다.
특히 기능 요구사항이 바뀌면 API 설계, UI 구조, 데이터 저장 방식까지 줄줄이 영향을 받습니다.

🛠 PM의 체크리스트

  • UI/UX 변화 가능성은 개발 초기부터 공유하고 있는가?
  • 보안 이슈가 향후 반영될 수 있음을 고려하고 설계했는가?
  • API가 확장 또는 변경되었을 때의 영향도 점검했는가?

5. 기능 우선순위의 명확한 구분

요구사항이 많을수록 개발자 리소스를 효율적으로 배분해야 합니다.
모든 걸 다 중요하다고 하면 아무것도 중요하지 않은 결과가 됩니다.

📌 구분 기준:

  • 핵심 기능 vs 부가 기능
  • 릴리즈 필수 여부
  • 사용자 경험에 미치는 영향

🛠 PM의 체크리스트

  • 이 기능이 릴리즈 일정에 꼭 필요한 핵심인가?
  • 중요도가 낮은 기능은 릴리즈 후반으로 미룰 수 있는가?
  • 우선순위에 따라 명확히 개발 단계와 일정을 나누어 전달하고 있는가?


🧭 마무리: 전달보다 중요한 건 정리된 사고

PM의 핵심 역량 중 하나는 "요구를 전달하는 사람"이 아닌, "요구를 해석하고 구조화하는 사람"이 되는 것입니다.
요구사항을 전달하기 전, 위의 5가지 항목만 체크해도 개발자와의 소통에서 훨씬 신뢰를 얻을 수 있고, 프로젝트 리스크를 최소화할 수 있습니다.

 

 

 

 

해당 내용은 파이온사나 온라인 강의를 토대로 배운점을 기록하였습니다. 

https://brunch.co.kr/@sana-create

 

파이온티어 사나의 브런치스토리

기획자 | 현직 IT PM(프로덕트 매니저)이자 PM/PO/서비스기획 강사로 교육 브랜드 '파이온티어'를 운영중인 사나입니다.

brunch.co.kr

 

 

참고 아티클

- PM이 알아야 할 4가지 우선 순위 정하기 기법

https://yozm.wishket.com/magazine/detail/520/

 

PM이 알아야 할 4가지 우선 순위 정하기 기법 - 위클리포스트(weeklypost)

현업의 프로덕트/프로그램 매니저/오너에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 늘 압도적으로 많이 차지하는 대답은 ‘실제 시장 피드백이 부족한 상태에서 로드맵에 따른 백로그

www.weeklypost.kr

- 노션 PRD 템플릿

https://www.notion.com/ko/templates/product-requirement-document-prd

 

제품 요구 사항 정의서 템플릿 제작자 Notion | Notion (노션) 마켓플레이스

업무 맥락 제공, 목표 설정, 에지 케이스 발견, 프로덕트 개선 계획 수립까지 한 곳에서 해결하세요. | 업무와 일상에서 Notion (노션)을 사용하는 새로운 방법을 알아보세요.

www.notion.com