💡 핵심 인사이트
인수 기준(Acceptance Criteria)은 백로그에 적혀있는 짧은 사용자 스토리(기능)가 **"정확히 어떤 조건들을 모두 충족해야만 사장님(PO)과 고객이 '이건 완벽하게 다 만들어졌다(Done)'라고 인정(Accept)하고 도장을 찍어줄 것인가?"를 명시한 구체적이고 깐깐한 체크리스트(채점표)**입니다.

Ⅰ. 사용자 스토리의 모호함과 인수 기준의 필요성

앞서 배운 사용자 스토리 카드는 매우 짧습니다.

• 스토리: "나는 쇼핑몰 회원으로서, 보안을 위해 비밀번호 변경 기능을 원한다."

개발자의 딜레마: 개발자가 이 문장 하나만 보고 코딩을 시작합니다. "비밀번호 변경 창 대충 만들었음 끝!" ➔ 리뷰 시간에 PO가 기겁합니다. "아니, 특수문자 강제 포함 로직은요? 예전에 썼던 번호 또 쓰면 막는 기능은요?" ➔ 개발자: "스토리에 그런 말 없었잖아요!" (재개발 지옥).

스토리 카드는 "우리가 이것에 대해 대화를 나누자"는 초대장일 뿐, 상세한 요구사항 명세서가 아닙니다. 이 빈틈을 완벽하게 메워주는 뒷장의 깐깐한 계약서가 바로 **인수 기준(A/C)**입니다.

Ⅱ. 인수 기준(A/C) 작성법과 효과

스토리 카드의 뒷면이나 Jira 티켓의 Description 하단에 불릿 포인트(Bullet point)나 BDD(Given/When/Then) 형태로 구체적인 검증 조건을 적습니다.

훌륭한 인수 기준의 예 (비밀번호 변경 스토리)

• 기존 비밀번호를 입력하지 않으면 새 비밀번호로 변경할 수 없어야 한다.
• 새 비밀번호는 최소 8자 이상이며, 숫자와 특수문자를 각각 1개 이상 반드시 포함해야 한다.
• 최근 3번 이내에 사용했던 과거의 비밀번호는 재사용을 거부하는 에러 메시지가 붉은색으로 떠야 한다.
• 비밀번호 변경이 성공하면 즉시 유저의 모든 기존 기기(모바일/PC)에서 강제 로그아웃 처리되어야 한다.

인수 기준이 주는 마법의 효과

1. 경계선 긋기 (Scope Creep 방지): 개발자가 엉뚱하게 지문 인식 로그인까지 오버해서 개발하는 헛수고를 막아줍니다. 딱 저 체크리스트만 통과하면 칼퇴근할 수 있는 '종료선(Finish Line)'이 생깁니다.
2. 테스트 코드의 청사진 (TDD/BDD): QA 테스터나 개발자는 저 한글 문장을 보고, 토씨 하나 안 틀리고 그대로 자동화된 if문 테스트 코드(Assert)로 바꿔치기만 하면 완벽한 무결점 코드가 됩니다.

Ⅲ. 완료의 정의(DoD)와의 헷갈림 주의

시험에서 단골로 속이는 함정입니다.

• 인수 기준 (A/C, Acceptance Criteria):
  • 개별 스토리(기능)마다 내용이 다릅니다. (로그인 기능의 채점표 다르고, 장바구니 기능의 채점표가 다름). '비즈니스 요건'에 초점을 맞춥니다.
• 완료의 정의 (DoD, Definition of Done):
  • 로그인 기능이든 장바구니 기능이든, 이 팀에서 개발한 '모든' 일감에 무조건 공통적으로 일괄 적용되는 최후의 철통 방어 룰입니다.
  • 예: "모든 코드는 유닛 테스트 커버리지 80%를 넘겨야 한다. 모든 코드는 동료 2명의 코드 리뷰 승인을 받아야 한다." (품질 보증 요건).

📢 섹션 요약 비유: 제품 책임자(PO)가 선생님이고 스토리가 '국어 시험'이라면, **인수 기준(A/C)은 "1번 문제 정답은 3, 2번 문제 정답은 4"라고 적힌 '과목별 세부 채점표'**입니다. 그리고 **완료의 정의(DoD)는 "모든 시험은 무조건 컴퓨터용 사인펜으로 마킹해야 하고, 부정행위 시 0점 처리한다"는 과목 불문 '학교 공통 시험 규정'**입니다. 둘 다 통과해야 학생(기능)이 성적을 인정받아 졸업(배포)할 수 있습니다.