Day 1 Step 5
회의록, 기능 요구사항, 미결 질문을 통합하고 AI Lint를 실행하여 이메일 공유
requirements-specification.md
Day 2 · 시스템 흐름, 일관성 & 변경 관리
오늘 우리는 단순한 요구사항 명세서 작성에 머무르지 않았습니다. 상호작용을 시각화하고, 모순을 검출하며, 변경의 연쇄 영향을 추적하고, 의사결정 이력을 보존하는 프로젝트 운영 시스템으로 확장했습니다.
단순 문서 생성을 넘어 Codex를 시스템 설계 검토자, 변경 관리자, 프로젝트 감사관으로 활용했습니다.
Day 1의 산출물을 하나의 요구사항 명세서로 통합하고 AI Lint를 실행했습니다. 그 후 사용자-클라이언트-서버-DB 상호작용 및 데이터 흐름을 설계하고, 프로젝트 문서 간 모순과 누락을 교차 검증하였으며, UI/API/DB/문서 전반의 변경 요청 영향을 추적하고, 대화에서 의사결정과 후속 과제를 추출했습니다.
요구사항을 기준점(Baseline)으로 확정한 후, 시스템 설계와 프로젝트 통제 단계로 순차적으로 확장했습니다.
회의록, 기능 요구사항, 미결 질문을 통합하고 AI Lint를 실행하여 이메일 공유
requirements-specification.md
사용자-클라이언트-서버-DB 상호작용 및 예외 흐름을 시퀀스 다이어그램으로 표현
Mermaid + Data Flow
회의록, 요구사항, 화면 명세서를 비교하여 모순, 누락, 최상위 권한 문서 도출
consistency-report.md
요구사항 변경의 UI/API 영향과 미팅 대화에 숨겨진 의사결정 및 미결 사항 기록
impact-analysis.md + decision-log.md
화면, API, DB, 문서 영향도 및 주요 이슈의 긴급도와 우선순위 보고
project-issue-report.md
각 실습은 독립된 파일을 만드는 것에 그치지 않고, 하나의 요구사항 생애주기를 통합적으로 통제합니다.
상호작용 및 데이터 이동 설계
기획 삼각 모순 오디터 (Design Auditor)
meeting-notes.md + requirements.md + screen-specification.mdconsistency-report.md변경 통제 & 영향 추적 (Change Control)
impact-analysis.md의사결정 보존 & 과제 추적
messenger-chat.md시스템 전반 파급 효과 분석
프로젝트 추적 & 이슈 관리
요구사항의 품질은 문장 표현보다 깨진 문서 링크와 관리되지 않은 변경 때문에 무너집니다.
모순을 찾는 것만으로는 부족합니다. 팀은 무엇을 수정할지 결정하기 전에 어떤 문서가 최종 권한을 가졌는지 먼저 정해야 합니다.
단 하나의 인증 방식 변경이 UI 컴포넌트, API 페이로드, DB 스키마, 테스트, 사용자 안내문까지 바꿉니다.
결론만 기록하면 똑같은 논쟁이 반복됩니다. 배경, 근거, 담당자, 날짜, 상태를 명확히 보존하세요.
수업에 사용된 원본 프롬프트입니다. 클릭하여 펼쳐보고 실습에 활용하세요.
다음 3개 파일을 읽고, 이를 하나로 통합한 요구사항 정의서인 requirements-specification.md 파일을 작성해 줘. - meeting-notes.md - functional-requirements.md - open-questions.md 동시에 아래 6가지 규칙에 따라 요구사항 문서의 오류를 분석해 줘. [검증 규칙] 1. 요구사항 ID 중복 여부 2. 요구사항 ID 누락 여부 3. 사용자 역할(Role) 누락 여부 4. 정상 흐름과 예외 흐름 누락 여부 5. 검증 기준(Verification Criteria) 누락 여부 6. 모호한 표현 사용 여부 (모호한 단어: 편리하게, 신속하게, 필요시, 적절히, 정상적으로) 오류 검증 결과는 출력 창 맨 위에 아래 형식으로 표시하고, 그 아래에 requirements-specification.md 파일 내용을 결합하여 출력해 줘. [출력 형식] PASS: 요구사항 ID 중복 없음 ERROR: FR-004 검증 기준 누락 WARNING: FR-007 모호한 표현 "편리하게" 사용
Gmail 플러그인을 사용하여 방금 검증한 requirements-specification.md 파일 내용과 open-questions.md의 미결 질문 목록을 바탕으로 아래 조건에 맞게 이메일을 발송해 줘. - 수신자(To): [피드백을 받을 대표 또는 의사결정자의 이메일 주소 입력] - 이메일 제목: [승인 요청] 전문 상담 서비스 요구사항 정의서 검토 및 미결 정책 조율 건 - 본문 구조: - 기획 문서 통합 검증 완료 보고 - 긴급 기획 결정이 필요한 주요 미결 질문 (Q-001 ~ Q-004 요약) - 피드백 회신 기한 안내
프로젝트 폴더의 'meeting-notes.md', 'requirements.md', 'screen-specification.md' 3개 문서를 비교 분석해 줘. 각 문서 간 상충되거나 불일치하는 항목, 또는 한 문서에는 있지만 다른 문서에는 누락된 항목을 찾아 정리해 줘. 아래 요구사항에 따라 결과를 출력해 줘. 1. 결과를 다음 열을 포함하는 Markdown 표 형식으로 정리: '구분(기능/화면/정책/용어 등)', '발견사항 및 모순점', '영향도(상/중/하)', '최상위 권한 기준 문서', '권장 조치사항'. 2. 개발 및 테스트 진입 시 치명적인 재작업을 유발할 수 있는 사항은 영향도를 '상'으로 표시. 3. 임의의 답변을 만들어내지 말고, 문서 텍스트에 기반한 사실만을 바탕으로 비교 분석 결과를 도출할 것.
먼저 프로젝트 폴더의 'requirements-before.md'와 'requirements-after.md' 파일을 비교하여 어떤 정책이 변경되었는지 분석해 줘. 그 후 v1.0 수준에 머물러 있는 'screen-specification-v2.md' 및 'api-specification.md' 문서 중 변경된 정책 내용이 반영되어야 할 부분을 분석해 줘. 결과는 아래 형식에 맞추어 Markdown 표 형식으로 출력해 줘: 1. '변경 항목', '변경 전', '변경 후', '영향 범위(화면/API)', '조치사항(구체적 수정 가이드 필요)' 2. 추가로 v2.0 요구사항을 기준으로 수정을 요하는 부분의 중요도를 '상/중/하' 순으로 분류하여 열에 표시할 것.
프로젝트 폴더의 'messenger-chat.md' 대화 로그를 읽고 프로젝트 관리 및 추적을 위한 Decision Log와 Pending Items를 작성해 줘. 아래 조건에 따라 분석을 수행해 줘. 1. 결정된 사항에 대해서는 'Decision Log' 표를 작성해 줘. 열에는 '결정 항목', '결정 내용', '결정 배경/근거', '결정 일자', '담당자/주체', '상태'를 포함해야 함. 2. 아직 결정되지 않고 후속 검토가 필요하거나 보류된 사항은 'Pending Items' 표에 정리해 줘. 열에는 '미결 항목', '후속 검토 내용', '담당자', '검토 예정일'을 포함할 것. 3. 대화 로그 텍스트에 기반하지 않은 허구의 날짜나 의사결정 주체를 작성하지 말 것.
회원가입 시 휴대폰 본인인증 기능이 추가될 경우 영향받는 모든 화면, API, DB, 문서를 찾아 영향 분석 보고서를 작성해 줘.
현재 프로젝트의 주요 이슈를 요약하고 긴급도와 우선순위가 포함된 프로젝트 이슈 리포트를 작성해 줘.
두 영상이 전달하는 공통 메시지: 첫 번째 답변을 정답으로 취급하지 마세요. 다양성과 반복을 통해 사고의 품질을 높이세요.
Jeremy Utley · EO · 13분
단 13분 만에 AI 창의성을 마스터하는 방법AI를 정답 자판기가 아닌 아이디어 파트너로 활용하세요. 하나의 프롬프트에 의존하는 대신 문제를 다양한 각도에서 재정의하고, 많은 후보를 생성한 뒤 비판적으로 선택할 때 창의성이 극대화됩니다.
Jeremy Utley · EO
AI 생산성을 10배 높이는 5단계 플레이북AI 생산성은 도구의 개수가 아닌 문제 정의, 충분한 맥락, 대화적 반복, 결과 검증, 그리고 재사용 가능한 워크플로우에서 나옵니다. 오늘 Codex 실습이 바로 이 원칙을 프로젝트 문서에 적용한 예시입니다.