작업한 것
- TDD 연습
- in c
- AI Agent와 협업 구조화를 위한 문서 플로우 설계
- 효율적인 문서 파악 ⇒ 규제 심사관 입장에서 바라보기
- RTM → QMS
배운 것
- BDD-TDD-QMS 개발 구조의 문서별 예상 독자
- 의도정리1
- 유저플로우
- 정성적 의도를 정량적 요구사항으로 변환
- 서비스의 목적과 범위를 이해해야 하는 사람들(비즈니스 이해관계자, 현업 부서)
- 의도정리2
- 유스케이스(SRS)
- 정성적 의도를 정량적 요구사항으로 변환
- 서비스의 목적과 범위를 이해해야 하는 사람들(비즈니스 이해관계자, 현업 부서)
- 로직설계
- 플로우차트
- 모든 분기점(Branch)의 MECE 여부 검토
- 화면 설계와 데이터 흐름을 실제 구현할 담당자(UX 디자이너, 프론트엔드 개발자)
- UI/UX 증거
- 와이어프레임
- 규제 관련 필수 노출 항목 누락 체크
- 화면 설계와 데이터 흐름을 실제 구현할 담당자(UX 디자이너, 프론트엔드 개발자)
- 명세화
- 거킨
- 플로우차트의 모든 경로를 시나리오로 변환
- "공용어". 비즈니스 로직과 테스트 기준의 합의점(PO, 개발자, QA 엔지니어)
- 리스크 분석
- (AI)예외검토
- AI 제안 → PO 승인 로그 필수 포함
- 신뢰성 증거. 시스템의 무결성을 검증하는 사람(QA 매니저, 규제/인증 심사관)
- 추적성 구축
- RTM
- SRS-거킨-TDD 간의 ID 매핑 자동화
- 신뢰성 증거. 시스템의 무결성을 검증하는 사람(QA 매니저, 규제/인증 심사관)
- 검증실행
- TDD(테스트 And Code)
- 거킨 시나리오와 1:1 매칭된 테스트 실행
- 코드의 품질과 유지보수 편의성을 보는 기술진(개발자, 테크 리드)
- 최종 품질
- QMS
- 버전 히스토리 및 최종 승인 서명 자동 생성
- 최종 승인자. 제품의 출시/배포 가능 여부를 판단(CTO, 품질 책임자(RA), 외부 심사 기관)
- 참고사항 각 단계를 마칠 때마다 아래 질문에 "Yes"라고 답할 수 있어야 다음으로 넘어갑니다.
- [Step 2→3]: 모든 유스케이스가 플로우차트의 '시작-끝' 노드와 연결되는가?
- [Step 5→6]: 거킨 시나리오에 '정상(Happy)'뿐만 아니라 '예외(Sad)' 상황이 최소 30% 이상 포함되었는가?
- [Step 6→7]: AI가 찾아낸 예외 중 PO가 '기각'한 항목에 대해 타당한 사유를 적었는가?
- [Step 7→8]: RTM의 모든 시나리오 ID가 실제 테스트 코드의 함수명과 일치하는가?
- '허점' 지적에 대한 대응 전략
- 데이터 유실 방지 (ID 시스템): 모든 요구사항에
REQ-001 같은 고유 ID를 부여합니다. 이 ID는 코드의 주석과 QMS 리포트까지 문신처럼 따라다니게 하여 유실을 막습니다.
- AI 판단의 객관화: AI에게 "이게 최선이야?"라고 묻는 대신, "ISO-XXXX 규정에 근거해서 이 로직의 취약점을 분석해줘"라고 지시하여 AI의 답변에 '규격 근거'를 강제로 입힙니다.
- 와이어프레임 필수화: 모든 화면이 아니라, '데이터 입력/출력/동의'가 일어나는 핵심 인터페이스는 반드시 시각적 증거를 남깁니다.

- 유저플로우 검증을 위한 사고 도구
- 역추적(Sad Path)
- '에러 나면 어쩌지?'라고 막연히 걱정함
→ 모든 실패 분기가 거킨(Gherkin) 시나리오로 변환됨
- 매핑(Value Link)
- '이게 필요하겠지?'라고 직관으로 판단함
→ 모든 단계가 RTM상의 규정/의도와 1:1로 매칭됨
- 테스트(So What?)
- '이정도면 됐나?' 하고 마무리함
→ 데이터의 최종 상태(Final State)가 QMS 리포트에 기록됨
마무리