[일지] 2026.01.24

김재만·2026년 1월 24일

작업한 것

  • TDD 연습
    • 스텁 구현 > 리팩토링 > times 구현
  • in c
    • AI Agent와 협업 구조화를 위한 문서 플로우 설계
      • 효율적인 문서 파악 ⇒ 규제 심사관 입장에서 바라보기
      • RTM → QMS

배운 것

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

마무리

profile
듣는 것을 좋아하는 개발자입니다

0개의 댓글