요구사항부터 QA까지: WGM·FTM CLI 한 사이클

WGM과 FTM을 각각 이해해도, 실제 업무에서 언제 무엇을 써야 하는지는 남는 질문입니다. Task를 등록한 뒤 곧바로 FTM을 써야 할까요? 테스트가 통과하면 Checkpoint를 만들어도 될까요? Git commit에는 무엇을 남기고 WGM에는 무엇을 남겨야 할까요?

이 글에서는 "관리자가 팀원의 표시 이름을 바꿀 수 있게 해 달라"는 하나의 기능 요청을 따라갑니다. 목적은 모든 단계를 도구로 기록하는 것이 아닙니다. 각 단계에서 지금 필요한 경계와 근거만 남기는 것입니다.

사례의 범위와 완료 기준

요구는 간단해 보입니다.

관리자는 팀원 이름을 수정할 수 있어야 한다. 일반 사용자는 다른 사람의 이름을 바꿀 수 없어야 한다.

이 기능의 완료 기준은 화면이 보이는 데서 끝나지 않습니다.

• 관리자는 대상 팀원의 이름을 바꿀 수 있다.
• 일반 사용자의 변경 요청은 거절된다.
• 잘못된 입력은 저장되지 않는다.
• 성공·실패 모두 기존 권한과 다른 사용자 데이터에 영향을 주지 않는다.
• QA가 끝난 뒤에만 팀이 검토 가능한 기준점으로 확정한다.

이 기준은 이후 WGM·FTM·Git이 각각 무엇을 남길지 결정하는 기준이 됩니다.

첫날: 요구를 Task와 Turn으로 묶기

요구를 받았다고 바로 컴포넌트를 열지 않습니다. 먼저 결과 단위인 Task와, 지금 다룰 한 가지 주제인 Turn을 나눕니다.

Task: 팀원 표시 이름 변경 기능
├── Turn 1: 권한·입력 규칙 조사
├── Turn 2: API와 UI 설계 확정
├── Turn 3: 구현
└── Turn 4: 테스트와 QA

WGM에는 Task의 목표, 범위, 완료 기준, 관련 결정을 남깁니다. 실제 조사를 시작하기 전에는 해당 Turn을 Active로 결속합니다. 그러면 이후의 코드 읽기, 명령 실행, 테스트 결과가 어떤 작업을 위한 것인지 연결됩니다.

Git에는 아직 commit할 변경이 없습니다. FTM도 아직 필요하지 않을 수 있습니다. 단순한 요구 확인 단계에서 중요한 것은 복잡한 판단을 만들어 내는 일이 아니라, 범위를 사실대로 정하는 일입니다.

둘째 날: 권한 경계가 설계에 들어오는 순간

조사 결과 API가 현재 로그인 사용자만 확인하고 대상 팀원의 소속은 검증하지 않는다고 가정해 보겠습니다. 이제 기능은 입력 폼 하나가 아니라 권한과 데이터 상태가 얽힌 변경이 됩니다.

이 시점에는 FTM으로 판단 조건을 분리할 이유가 생깁니다.

현재 상태: 요청자와 대상 사용자가 같은 팀인지 아직 검증하지 않았다.
입력: 요청자 ID, 대상 사용자 ID, 새 표시 이름
제약: 일반 사용자는 다른 사람을 수정할 수 없다.
불변조건: 권한 검증 실패는 대상 사용자 데이터를 바꾸지 않는다.
Effect: 이름 업데이트와 감사 로그 기록
검증: 거절 응답 뒤 대상 이름과 감사 로그가 변하지 않는다.

FTM은 "관리자만 수정 가능"이라는 문장을 테스트 가능한 조건으로 바꿉니다. 테스트가 아직 없으면 불변조건은 검증된 사실이 아니라, 구현과 QA에서 확인할 약속으로 남습니다.

WGM에는 설계 Turn에서 결정한 역할·범위·보류한 질문을 남깁니다. 예를 들어 "감사 로그는 이번 기능에 포함하되 알림 발송은 별도 Task"라는 결정이 있다면, 다음 담당자가 범위를 다시 추측하지 않게 됩니다.

셋째 날: 구현 결과를 Git과 WGM에 다르게 남기기

구현 Turn을 Active로 결속한 뒤 API 권한 검사, 유효성 검사, UI 입력 폼, 테스트를 수정합니다. 이때 Git commit은 파일 변경 이력입니다.

Git commit
  - 권한 검사와 이름 변경 API
  - 입력 폼과 오류 표시
  - 단위·통합 테스트

반면 WGM은 commit의 파일 목록을 복사하지 않습니다. "권한 검증은 쓰기 Effect보다 먼저 실행한다", "알림 발송은 이번 범위에서 제외한다"처럼 작업의 맥락과 판단을 남깁니다.

FTM은 구현 중 판단이 흔들리는 지점을 다룹니다. 예를 들어 이름 변경과 감사 로그 쓰기 중 하나가 실패했을 때, 부분 성공을 허용할지 되돌릴지를 결정해야 한다면 상태·입력·Effect·검증 조건을 다시 확인합니다. 단순한 스타일 수정처럼 이 질문이 없다면 FTM을 억지로 추가할 필요가 없습니다.

넷째 날: QA 결과는 다음 행동을 바꿉니다

QA에서 관리자의 성공 경로와 일반 사용자의 거절 경로를 모두 확인합니다. 여기서 테스트 결과는 단순 보고가 아닙니다. 다음 행동을 바꾸는 입력입니다.

권한 거절 테스트 실패
  → 상태: QA 보류
  → 다음 행동: 구현 Turn으로 돌아가 권한 검사 수정

모든 완료 기준 통과
  → 상태: 검토 후보
  → 다음 행동: Stage와 리뷰·승인 확인

WGM의 Stage는 이 작업을 다음 확정 지점에 포함할 후보로 표시합니다. Stage 자체는 완료 선언이 아닙니다. 테스트·QA·리뷰·승인 조건이 남아 있다면 후보 상태로 두는 편이 정확합니다.

Git commit도 QA 통과를 자동으로 의미하지 않습니다. commit은 코드가 바뀐 이력이고, QA는 그 변경이 완료 기준을 충족하는지 확인한 근거입니다.

다섯째 날: Checkpoint로 확정하고, 다음 세션에서 재개하기

팀이 요구 범위와 QA 결과를 검토하고 확정을 승인했다면, Stage된 Task를 Checkpoint에 포함할 수 있습니다. Checkpoint는 "코드가 존재한다"가 아니라 "여기까지를 검토 가능한 기준점으로 삼는다"는 확정 이력입니다.

그 뒤 다음 요구가 들어온다면, 새 세션에서 다음 순서로 시작합니다.

Task context로 과거 목표와 결과를 읽는다.
  → Track log로 마지막 Checkpoint를 확인한다.
    → 새 요구가 기존 확정 결과를 바꾸면 새 Task를 만든다.
      → 현재 Turn을 Active로 결속한 뒤 조사·설계·구현을 시작한다.

이 흐름에서는 과거 Task를 조용히 재사용하지 않습니다. "팀원 이름 변경" 뒤에 "이름 변경 알림 전송"이 추가됐다면, 완료 기준과 검증이 달라졌으므로 새 Task가 더 정확합니다. 과거 Checkpoint는 출발점으로 읽되, 새 변경의 완료 선언으로 쓰지 않습니다.

한 사이클을 위한 최소 기준

모든 기능에 다섯 날짜리 절차가 필요한 것은 아닙니다. 하지만 여러 권한·상태·외부 효과가 얽힌 기능에서는 다음 질문을 차례로 답할 수 있어야 합니다.

WGM·FTM·Git을 함께 쓴다는 말은 세 도구에 같은 내용을 세 번 적는다는 뜻이 아닙니다. Git은 변경을, WGM은 작업의 관계와 확정 경계를, FTM은 복잡한 판단의 조건과 검증을 맡깁니다. 이 경계가 유지되면 세션이 바뀌어도 다음 사람이 같은 근거에서 일을 이어갈 수 있습니다.