01. 문제와 완료 조건

목표

‘기능을 고쳐 주세요’ 같은 요청을 에이전트와 사람이 같은 기준으로 검토할 수 있는 작업 계약으로 바꿉니다.

핵심 설명

좋은 작업 요청은 구현 방법을 미리 고정하는 문서가 아닙니다. 누가 어떤 변화를 경험해야 하는지, 무엇을 유지해야 하는지, 무엇으로 완료를 확인할지를 분명히 하는 계약입니다. 코드가 생겼다는 사실만으로는 완료를 판단하기 어렵습니다.

가상의 문의 폼 작업이라면 목표를 다음처럼 정할 수 있습니다.

요청을 처리하는 동안 같은 폼의 추가 제출이 새 네트워크 요청으로 이어지지 않는다. 기존 API 형식과 입력 필드는 유지하고, 실패하면 입력값을 남긴 채 재시도할 수 있어야 한다.

클라이언트의 버튼 잠금은 서버의 멱등성이나 보안 경계를 대신하지 않는다는 제외 범위도 적습니다.

작업 브리프에는 다섯 요소를 둡니다.

사용자 결과: 사용자가 경험할 변화
포함 범위: 이번에 바꿀 동작
제외 범위: 이번에 해결하지 않을 문제
제약: 유지할 계약, 권한, 데이터 경계
완료 증거: 자동 검사와 실제 동작에서 확인할 사실

체크리스트

• 구현 수단이 아니라 사용자에게 생길 변화를 먼저 적었습니다.
• 포함 범위와 제외 범위를 구분했습니다.
• 기존 API, 데이터, UI 중 유지할 계약을 적었습니다.
• 성공·실패·재시도 같은 중요한 상태를 포함했습니다.
• 각 완료 조건을 확인할 방법이 있습니다.
• 판단이 필요한 미결정 사항을 숨기지 않았습니다.

직접 해보기

00단계에서 고른 작업을 다음 형식으로 작성합니다.

목표
-

유지할 것
-

필요한 동작
-

제외 범위
-

안전 제약
-

완료 증거
-

작성한 뒤 “이 문서만 읽은 사람이 완료 여부를 예/아니오로 판단할 수 있는가?”를 확인합니다. 판단할 수 없다면 결과나 증거를 더 구체화합니다.

완료 근거

• 사용자 결과와 코드 변경 자체가 구분되어 있습니다.
• 모든 완료 조건에 대응하는 검증 방법이 있습니다.
• 제외 범위가 있어 작업이 불필요하게 넓어지지 않습니다.
• 미결정 사항은 질문 또는 사람 승인 지점으로 남아 있습니다.

다음은 현재 시스템에서 무엇을 읽어야 하는지 좁히는 02. 필요한 컨텍스트 고르기입니다.