[주간회고] 2026.01.27

작업한 것

• TDD
  • 스텁 구현 → 리팩토링 → times 반복
  • 업무 로직 확장
    • BDD → TDD → QMS
    • BDD: 플로우차트 → 거킨
      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 디자이너, 프론트엔드 개발자)
         4. 명세화
            1. 거킨
            2. 플로우차트의 모든 경로를 시나리오로 변환
            3. "공용어". 비즈니스 로직과 테스트 기준의 합의점(PO, 개발자, QA 엔지니어)
      5. 리스크 분석
         1. (AI)예외검토
         2. AI 제안 → PO 승인 로그 필수 포함
         3. 신뢰성 증거. 시스템의 무결성을 검증하는 사람(QA 매니저, 규제/인증 심사관)
      6. 추적성 구축
         1. RTM
         2. SRS-거킨-TDD 간의 ID 매핑 자동화
         3. 신뢰성 증거. 시스템의 무결성을 검증하는 사람(QA 매니저, 규제/인증 심사관)
    • TDD: 거킨 → 테스트코드 → 기능코드
      1. 검증실행
         1. TDD(테스트 And Code)
         2. 거킨 시나리오와 1:1 매칭된 테스트 실행
         3. 코드의 품질과 유지보수 편의성을 보는 기술진(개발자, 테크 리드)
    • QMS: 테스트 코드 → 기능코드 테스트 결과 → 품질문서
      1. 최종 품질
         1. QMS
         2. 버전 히스토리 및 최종 승인 서명 자동 생성
         3. 최종 승인자. 제품의 출시/배포 가능 여부를 판단(CTO, 품질 책임자(RA), 외부 심사 기관)

배운 것

• AI와 협업하는 방법
  ⇒ 내가 품질(규제) 담당자가 되는 것
  • BDD: 유저의 행위를 명세화하여 다루는 방법

이슈

• BDD → TDD가 신뢰성을 보장할지 아직 모르겠음..!
  ⇒ 빨리 대가리 박치기 고고
  

다음 작업

• TDD 기본예제(다중 화폐) 반복으로 BDD → TDD → QMS 완성해보기

마무리

과연 나는 여전히 애자일한가? 여전히 가치를 따르고 있는가?