흔히 발생하는 상태: "◯◯을 수정해줘"라고만 전달하여 구현하게 한 뒤, 결과물을 보고 나서 "그게 아니야", "그 부분은 건드리지 않았으면 했어"라며 수정 작업을 반복하는 상황.

계획 단계에서, AI에게 "수락 조건(Acceptance Criteria)"과 "스코프 외(Out of Scope)"를 명문화하게 한다.

수락 조건 (Acceptance Criteria): 무엇이 완료되어야 하는가. 나중에 "충족함/충족하지 않음"을 판정할 수 있을 정도의 구체성으로 작성 -
스코프 외 (Out of Scope): 이번에 하지 않을 것. 건드리지 않을 파일, 바꾸지 않을 동작, 대응하지 않을 케이스

작성하는 것은 AI입니다. 인간은 그것을 보고 "해주길 바라는 것 / 해주지 않길 바라는 것"을 확인·수정하고 나서 구현을 진행하게 합니다.

태스크 "비밀번호 재설정 기능 추가" 계획서 서두의 이미지:

# 비밀번호 재설정 기능 추가
## 수락 조건
- [ ] 등록된 이메일 주소를 입력하면, 재설정용 링크가 이메일로 발송된다
...

포인트는, "미등록 사용자라도 등록 여부를 알 수 없는 응답"과 같은 보안상의 암묵적인 기대나, "기존 동작이 변하지 않았을 것"과 같은 "망가뜨리지 말 것"에 대한 조건까지 작성하는 것입니다. 인간이 머릿속에서 당연하다고 생각하는 것이야말로, 명문화하지 않으면 AI에게는 전달되지 않습니다. 스코프 외의 "디자인 변경은 하지 않음"도, AI가 센수를 발휘하여 화면을 "개선"해 버리는 사고를 방지합니다.

이 한 장의 표가 개발 흐름 전체에서 재사용됩니다.

인간이 착수 전에 확인할 수 있음 —— "해주길 바라는 것·해주지 않길 바라는 것"에 대한 인식 맞추기를 구현 후가 아니라 구현 전에 할 수 있음 -
구현 AI의 망설임이 사라짐 —— 무엇을 해야 하고, 이번에는 무엇을 하지 않는지가 명확해짐. AI의 구현이 가장 폭주하는 때는 완료 조건이 모호할 때임 -
AI가 자기 체크를 할 수 있음 —— 구현 후에 "정말로 내 업무가 끝났는가", "불필요한 일을 하지 않았는가"를 조건표와 대조하여 확인할 수 있음 -
리뷰 AI도 동일한 관점에서 볼 수 있음 —— 리뷰의 기준이 "리뷰어의 기분"이 아니라 조건표가 됨 -
인간의 최종 리뷰도 동일한 관점 —— 그리고 "이것을 충족했다면 성공". 완료 정의(Definition of Done)로 다투지 않음

즉, 관련된 모든 사람(인간·구현 AI·리뷰 AI)이 동일한 척도를 갖는다는 것입니다.

계획서의 서두에 둔다. 부록이 아니라 가장 눈에 띄는 장소에. 이후의 모든 공정이 이곳을 참조함 -
스코프 외를 빈칸으로 두지 않는다. "하지 않을 것"을 쓰지 못하는 것은 범위를 생각하지 않고 있다는 신호. "인접한 저 기능은 건드리지 않음" 정도라도 작성함 -
조건은 테스트로 연결한다. 수락 조건의 대부분은 그대로 테스트 코드(Test Code)로 만들 수 있음. "조건표를 충족하는 테스트를 작성해줘"라고까지 요청하면, 자기 체크가 기계화됨

이 기사는 이데아라이브(Idealive) 사내의 "AI 주도 개발의 사고방식" 문서(총 12편)를 시리즈로 공개하고 있는 것입니다.