요구사항과 검증 기준 작성법

실습 시간: 60분

산출물: 요구사항 문서 한 편과 배포 전 확인할 수용 기준

PRD와 TDD를 구분합니다

PRD(Product Requirements Document)는 왜 무엇을 만들지 정하는 문서입니다. TDD(Test-Driven Development)는 소프트웨어의 기대 동작을 테스트로 먼저 표현하고 구현을 검증하는 개발 방식입니다. 둘을 모두 ‘AI에게 정확히 시키는 문서’라고 부르면 역할이 흐려집니다.

AI를 활용하더라도 요구사항, 수용 기준, 테스트, 배포 승인은 사람의 책임입니다. OpenAI는 제품 기능의 프롬프트를 코드·테스트·평가와 함께 관리하라고 안내하고, Anthropic은 프롬프트 개선 전에 성공 기준과 시험 방법을 정하라고 권합니다.

요구사항 문서에 필요한 정보

항목	확인할 질문
문제	지금의 사용자가 무엇을 못 하고 있나?
목표	무엇이 달라지면 성공인가?
범위	이번 변경에 포함하고 제외할 일은 무엇인가?
근거	어떤 원문·정책·데이터를 사용할 수 있나?
수용 기준	누가 어떤 방법으로 완료를 확인하나?
위험	개인정보, 권한, 외부 발송, 되돌리기는 어떻게 다루나?

실습: Agent Lab 강의 최신화 요구사항

현재 배포된 앱에서 실제로 수행할 수 있는 작업을 예시로 듭니다.

# AI for Work 강의 최신화

## 문제

도구별 강의에 모델명, 가격, 기능처럼 빠르게 변하는 표현이 남아 있다.
독자가 오래된 정보를 현재 사실로 이해할 위험이 있다.

## 목표

공식 문서로 확인한 내용만 남기고, 모든 개정 강의에서 검토 날짜와 공식 참고 자료를 확인할 수 있게 한다.

## 범위

- 포함: 프롬프트, 모델, 가격, API, 제품 기능을 다루는 강의의 표현·예시·링크 정비
- 제외: 공식 문서로 확인할 수 없는 제품 가격이나 미래 기능의 추정

## 수용 기준

- 각 개정 강의에 최종 검토 날짜와 공식 참고 자료가 있다.
- 확인하지 못한 기능·가격·모델명은 단정하지 않는다.
- 가상 예시는 가상이라고 표시한다.
- 로컬 빌드와 공개 페이지에서 링크·레이아웃을 확인한다.

## 위험과 승인

- 외부 서비스에 계정 정보나 비공개 문서를 넣지 않는다.
- 공개 배포 전에는 사람이 수정 내용과 렌더링을 승인한다.

AI에 문서를 검토시킬 때

AI에게 요구사항의 누락을 점검하게 할 수는 있지만, AI가 요구사항을 확정하게 두면 안 됩니다. 다음처럼 역할을 좁혀 요청합니다.

아래 요구사항 문서에서 모호한 표현과 검증할 수 없는 수용 기준을 찾아줘.

규칙
- 제공된 문서 밖의 사실을 추가하지 않는다.
- 각 문제에 원문 인용, 문제가 되는 이유, 더 검증 가능한 표현을 제안한다.
- 기능 구현이나 배포 승인은 제안하지 않는다.

개발 변경에는 테스트를 붙입니다

소프트웨어를 바꾸는 경우에는 사람 말로 쓴 수용 기준을 테스트나 확인 절차로 바꿉니다. 예를 들어 Agent Lab의 콘텐츠 메타데이터 변경은 다음처럼 확인할 수 있습니다.

• 콘텐츠 스키마가 새 검토일과 공식 링크를 허용하는지 확인합니다.
• 페이지가 검토일과 참고 자료를 실제로 표시하는지 확인합니다.
• 빌드가 성공하고, 공개 URL에서 데스크톱·모바일 화면을 확인합니다.
• 링크가 의도한 공식 문서로 이동하는지 확인합니다.

완료 체크리스트

• 문제와 목표가 측정 가능한 문장으로 쓰였다.
• 포함 범위와 제외 범위를 구분했다.
• 수용 기준에 확인자와 확인 방법이 있다.
• AI가 제안한 내용과 확정한 결정을 구분했다.
• 테스트·빌드·공개 화면 확인이 배포 기준에 포함됐다.