[일지] 2026.01.23

김재만·2026년 1월 23일

in C

작업한 것

TDD 연습
- 스텁 구현 > 리팩토링 > times 구현
in c
- BDD 도입 BDD 첫번째 설명입니다.
  - 유저 플로우 → 플로우차트 → 유스케이스 명세 → 거킨 작성
    1. 유저플로우: 진입 페이지 → 로그인 버튼 → 로그인 양식 작성 → [성공] 대시보드 / [실패] 에러 메시지
    2. 유스케이스 명세
      - 유스케이스명: 사용자 로그인
      - 액터: 미인증 사용자
      - 기본 흐름(Main Success Scenario):
        
        사용자가 이메일과 비밀번호를 전송한다.
        
        시스템은 데이터 유효성을 검증한다.
        
        시스템은 암호화된 비밀번호를 비교한다.
        
        시스템은 JWT 토큰을 발급하고 성공 응답을 보낸다.
      - 예외 흐름(Alternative Flows):
        
        (2a) 입력 형식이 틀린 경우: 422 응답을 반환한다.
        
        (3a) 비밀번호가 틀린 경우: 401 응답을 반환하고 실패 횟수를 기록한다.
    3. 플로우차트
```
graph TD
    A[시작: 로그인 정보 입력] --> B{이메일 형식 확인}
    B -- 무효 --> C[422 에러: 입력 오류]
    B -- 유효 --> D{DB 사용자 존재?}
    D -- No --> E[401 에러: 인증 실패]
    D -- Yes --> F{비밀번호 일치?}
    F -- No --> G[로그인 실패 횟수 증가]
    G --> H{5회 이상 실패?}
    H -- Yes --> I[계정 잠금 및 알림]
    H -- No --> E
    F -- Yes --> J[JWT 토큰 생성]
    J --> K[200 OK: 성공 응답]
```
    4. 와이어프레임
    5. 거킨
```
Feature: 사용자 로그인 인증

  Background:
    Given "test@example.com" 사용자가 DB에 등록되어 있다.

  Scenario: [성공] 올바른 정보로 로그인
    When 사용자가 이메일 "test@example.com"과 비밀번호 "pass123"을 입력한다
    Then HTTP 200 응답을 받아야 한다
    And 응답에 "access_token"이 포함되어야 한다

  Scenario: [실패] 잘못된 비밀번호 입력
    When 사용자가 이메일 "test@example.com"과 비밀번호 "wrong999"를 입력한다
    Then HTTP 401 응답을 받아야 한다
    And 에러 메시지가 "Incorrect email or password"여야 한다

  Scenario: [실패] 입력 형식 오류 (Validation)
    When 사용자가 이메일 필드를 빈칸으로 두고 로그인을 시도한다
    Then HTTP 422 응답을 받아야 한다
    And 에러 상세 정보에 "email" 필드 누락이 명시되어야 한다
```
    6. (AI)예외상황 검토 지시
    7. (AI)시나리오에 대한 테스트 지시(pytest-bdd 등 활용)
      
      1. 상호 배제와 전체 포괄 (MECE 원칙)
      
      가장 강력한 신뢰 기준입니다. 작성한 거킨 시나리오들이 "빠진 구멍은 없고, 서로 겹쳐서 충돌하진 않는가?"를 보는 것입니다.
      - 확인 방법: AI에게 "이 시나리오들 중에서 논리적으로 충돌하거나, 내가 놓친 예외 상황(Exception)이 있는지 반례를 들어봐"라고 시킵니다.
      - 신뢰 포인트: AI가 "모든 케이스가 정의되었습니다"라고 하거나, 우리가 몰랐던 '중복 신청의 예외 조건'을 찾아낸다면 그 설계는 신뢰할 수 있는 단계로 올라갑니다.
      2. 실행 가능한 명세 (Executable Specification)
      
      거킨으로 쓴 문장이 단순한 소설이 아니라, 기계가 읽어서 '참/거짓'을 판별할 수 있는 수준인가를 확인하는 것입니다.
      - 확인 방법: "이 거킨 문장을 보고, 바로 pytest 코드로 변환해봐"라고 시켰을 때, AI가 주저 없이 코드를 뽑아낸다면 그 문장은 '명확한 규격'을 갖춘 것입니다.
      - 신뢰 포인트: 모호한 문장("상담이 잘 되어야 한다")은 코드로 안 바뀝니다. 명확한 문장("상태값이 'PENDING'이면 400을 뱉는다")만 코드가 됩니다. 즉, 코드로 변환 가능하다는 것 자체가 논리의 신뢰성을 증명합니다.
      3. 추적 가능성 (Traceability Check)
      
      "이 테스트가 성공하면, 진짜로 우리 회사의 규정 제5조가 만족되는가?"를 연결해 보는 것입니다.
      - 확인 방법: 추적성 매트릭스를 뽑아서 [규정] - [유스케이스] - [거킨 시나리오]가 1:1:1로 매칭되는지 눈으로 확인합니다.
      - 신뢰 포인트: "아, 이 시나리오가 통과되면 식약처의 중복 민원 규정을 지킨 셈이 되는구나!"라는 확신이 들 때, 비로소 그 설계를 신뢰하게 됩니다.
    8. TDD 사이클
    9. QMS 플로우