요구사항·완료 조건: 원하는 동작 합의하기

왜 필요한가

“장바구니를 만들어줘”라는 말은 같은 책을 두 번 넣는 순간부터 모호해집니다. 누군가는 두 줄을, 누군가는 수량 2를, 다른 사람은 중복 금지를 기대합니다. 코드는 어느 쪽이든 구현할 수 있지만 사용자가 원한 결과와는 다를 수 있습니다. 내부 자료구조를 고르기 전에 눈에 보이는 동작부터 합의해야 하는 이유입니다.

어떻게 해결하는가

1. 먼저 한 가지 목표를 적습니다. 예를 들어 독자가 고른 책을 잃지 않고 주문을 준비하는 것입니다. 누가 어디서 시작하는지, 첫 출시에서 하지 않을 일은 무엇인지도 정합니다. 추천 상품이나 할인 행사는 이번 목표에 필요하지 않다면 뒤로 미룹니다. 기능 이름보다 사용자가 끝내려는 일을 기준으로 범위를 나눕니다.
2. 실제 값으로 한 번 따라갑니다. 빈 장바구니에 책 A를 넣고 다시 넣었을 때 한 줄에 수량 2가 되는 것으로 합의합니다. 한 권을 빼면 수량 1인지, 재고가 부족하면 기존 상태를 유지하는지도 정합니다. 이것은 제품 동작입니다. 배열과 맵 중 무엇으로 저장할지는 AI가 이 동작에 맞춰 결정할 수 있습니다.
3. 불편한 경로도 살펴봅니다. 저장 중, 네트워크 실패 뒤, 버튼을 연달아 눌렀을 때 무엇이 보일까요? 의도적으로 두 권을 추가하는 행동과 같은 요청이 두 번 전달되는 상황은 다릅니다. 결과가 미정이라면 내부 구현 용어를 묻기보다 사용자가 기대하는 결과를 확인합니다. 실패를 성공처럼 표시해서는 안 됩니다.
4. 합의한 내용을 확인 가능한 문장으로 바꿉니다. 처음 장바구니와 재고가 이럴 때, 이 행동을 하면, 줄·수량·안내가 이렇게 된다고 적습니다. “빠르게”라는 표현도 대상 환경과 측정 가능한 기준으로 바꿉니다. 어느 제품에나 맞는 성능 수치를 임의로 붙이지 말고, 필요한 수준을 먼저 합의합니다.
5. AI가 시나리오와 남은 질문, 확정된 결정을 문서로 작성하게 합니다. 요구사항에 고유 번호를 붙이면 구현 작업과 검증 결과를 연결하기 쉽습니다. 범위가 바뀌면 영향받는 확인 조건과 변경 이유도 함께 갱신합니다. 이미 맞지 않는 테스트가 조용히 제품 정책을 대신 결정하게 두지 않습니다.

작성한 예시만 가지고 다른 사람과 결과를 예측해 보세요. 성공·실패·반복 입력에서 같은 답을 낼 수 있다면 구체적인 구현 계획으로 넘어갈 준비가 된 것입니다. 문서가 길어도 중요한 동작에 서로 다른 답을 내면 아직 합의가 부족합니다. 모르는 부분은 미정으로 남기고 결정할 사람과 필요한 정보를 적는 편이 낫습니다.

무엇이라 부르는가

관찰 가능한 동작과 제약을 적고 인수 조건으로 확인하는 일이 요구사항 명세입니다. SRS는 그 합의를 정리하는 형식 중 하나입니다. 사용자 스토리나 시나리오는 보조 수단이며 사용자가 문서 형식부터 선택할 필요는 없습니다. NASA의 요구사항 점검표는 명확하고 검증 가능한 표현을 강조합니다. AI는 중요한 선택의 맥락과 결과도 기록하고, 제품 결정은 사용자에게 남깁니다.