AI로 모호한 요구사항을 개발 작업 목록으로 분해

서두

제품 담당자가 요구사항을 한 문장으로 던졌다.

사용자는 상품을 즐겨찾기할 수 있고, 개인 센터에서 즐겨찾기 목록을 볼 수 있다.

매우 간단한 기능처럼 보인다.

많은 개발자는 곧바로 이렇게 떠올린다.

- 즐겨찾기 테이블 하나 만든다.

- 즐겨찾기 추가와 해제 인터페이스를 추가한다.

- 즐겨찾기 목록 인터페이스를 추가한다.

- 프런트엔드에 즐겨찾기 버튼 하나 놓는다.

그리고 코딩을 시작한다.

하지만 실제로 개발에 들어가면 문제는 보통 하나씩 이어져 나타난다.

- 로그인하지 않은 사용자가 즐겨찾기할 수 있는가?

- 같은 상품을 중복 즐겨찾기하면 오류를 내야 하는가, 아니면 멱등하게 성공 처리해야 하는가?

- 상품이 판매 중지되거나 삭제된 뒤에는 즐겨찾기 목록을 어떻게 보여주는가?

- 즐겨찾기 목록은 무슨 기준으로 정렬하고, 페이징하는가?

- 사용자가 즐겨찾기를 해제할 때 대상 레코드가 존재하지 않으면 어떻게 하는가?

- 상품별로 즐겨찾기 수를 기록해야 하는가?

- 기록해야 한다면, 카운트가 동시성 문제로 어긋나지 않게 어떻게 막는가?

- 자신의 상품을 즐겨찾기하도록 허용하는가, 아니면 모든 상품을 동일하게 처리하는가?

이런 질문들은 '구현 세부사항'이 아니라 요구사항의 일부다.

개발 전에 이런 것들이 드러나지 않으면, AI가 인터페이스와 데이터 테이블을 빠르게 생성해 준다 해도 그것은 그저 우리 대신 모호한 요구사항을 더 빠르게 코드로 옮긴 것에 불과하다.

이 글에서는 AI가 완성된 모듈을 한 번에 생성하게 하는 방법을 논하지 않는다.

우리가 실천하려는 것은 이것이다.

어떻게 하면 AI가 우리를 도와 한 문장의 모호한 요구사항을 확인 가능하고, 개발 가능하고, 테스트 가능한 작업 목록으로 분해하게 할 수 있는가.

이 글에서 논하지 않는 것

시작하기 전에 이 글의 경계를 먼저 분명히 하자.

- AI의 제안을 최종 비즈니스 규칙으로 삼지 않는다.

- 프로덕션 환경에 그대로 복사할 수 있는 완전한 코드를 바로 제시하지 않는다.

- 모든 프로젝트가 동일한 테이블 구조를 써야 한다고 가정하지 않는다.

- 권한, 멱등성, 데이터 일관성, 예외 상황을 무시하지 않는다.

- 제품, 비즈니스, 개발자 사이의 확인 과정을 건너뛰지 않는다.

요구사항 분해 단계에서 AI가 가장 가치 있는 역할은 우리가 빠뜨린 것을 발견하고, 문제를 정리하고, 논의할 수 있는 후보 방안을 생성하도록 돕는 것이다.

최종 규칙은 여전히 비즈니스와 납품을 실제로 책임지는 사람이 확인해야 한다.

1. 원본 요구사항을 왜 바로 코딩으로 넘길 수 없는가

먼저 이 원본 요구사항을 보자.

그것은 사용자 의도 하나만 표현했을 뿐, 구현에 필요한 핵심 사실은 정의하지 않았다.

만약 AI에게 곧바로 코드를 쓰게 하면,

Java + Spring Boot로 상품 즐겨찾기 기능을 구현해 줘. 즐겨찾기, 즐겨찾기 해제, 즐겨찾기 목록 인터페이스를 포함해서.

AI는 아마도 Controller, Service, Repository와 테이블 구조를 생성할 것이다.

하지만 아래 문제들은 여전히 기본 가정으로 채워진다.

문제 가능한 다른 답변 확인하지 않을 때의 위험 즐겨찾기 주체 반드시 로그인 / 비회원도 즐겨찾기 가능 권한과 데이터 귀속 불일치 중복 즐겨찾기 오류 / 멱등 성공 프런트엔드 재시도와 사용자 경험 불일치 상품 상태 판매 중지 시 보존 / 미표시 / 자동 제거 목록 결과가 비즈니스 기대와 불일치 목록 정렬 즐겨찾기 시간 역순 / 상품 인기 / 수동 정렬 인터페이스 결과를 검수할 수 없음 존재하지 않는 즐겨찾기 해제 오류 / 멱등 성공 클라이언트 재시도 로직 불안정 즐겨찾기 수 유지 안 함 / 실시간 집계 / 비동기 카운트 성능과 일관성 방안이 달라짐

요구사항 분해를 하나의 변환 과정으로 이해할 수 있다.

사용자의 한 문장 ↓ 확인이 필요한 비즈니스 질문 ↓ 실행 가능한 비즈니스 규칙 ↓ 인터페이스, 데이터, 상태 설계 ↓ 개발 작업과 테스트 시나리오

AI는 우리 대신 이 사슬을 건너뛰는 역할이 아니다.

AI는 우리가 이 사슬을 더 빨리 통과하도록 도와야 한다.

2. 요구사항 분해를 시작하려면 AI에게 먼저 어떤 정보를 주어야 하는가

원본 요구사항만 AI에게 보내지 말라.

첫 번째 라운드의 목표는 답을 얻는 것이 아니라, AI가 '알려진 사실'과 '알려지지 않은 문제'를 구분하게 하는 것이다.

다음은 이번 예시의 최소 컨텍스트다.

원본 요구사항: 사용자는 상품을 즐겨찾기할 수 있고, 개인 센터에서 즐겨찾기 목록을 볼 수 있다. 프로젝트 배경: - 백엔드는 Java + Spring Boot를 사용한다. - 사용자는 반드시 로그인해야 개인 센터에 접근할 수 있다. - 상품 모듈은 이미 존재하며, 상품 상태는 상架(판매 중), 下架(판매 중지), 삭제를 포함한다. - 현재 프런트엔드 설계는 다루지 않고, 백엔드와 인터페이스 작업만 분해한다. - 비즈니스 오류는 일괄적으로 DomainException을 사용한다. 이번 라운드 요구: 1. 코드를 쓰지 말 것. 2. 요구사항에서 확인이 필요한 문제를 나열할 것. 3. '비즈니스 규칙, 권한, 데이터, 인터페이스, 예외, 성능과 일관성'으로 분류할 것. 4. 개발 전에 반드시 확인해야 할 것과 잠시 가정해도 되는 것을 구분할 것. 5. 불확실한 부분을 스스로 결정하지 말 것.

이 Prompt의 핵심은 역할 설정이 아니라, AI의 작업을 명확히 제한한다는 데 있다.

코드 쓰지 않기 ↓ 먼저 문제 찾기 ↓ 공학적 차원으로 분류 ↓ 불확실성 표시

이렇게 얻는 것은 겉보기에 완성된 구현이 아니라, 제품, 비즈니스, 팀과 확인해야 할 목록이다.

3. AI로 모호한 요구사항을 5가지 문제 유형으로 분해하기

아래에서는 이 즐겨찾기 요구사항을 예로 들어, 첫 번째 라운드 분해에서 무엇을 얻어야 하는지 보여준다.

1. 비즈니스 규칙: 즐겨찾기가 정확히 무엇을 의미하는가

먼저 AI가 비즈니스 의미에 집중하게 하자.

'사용자는 상품을 즐겨찾기할 수 있고, 개인 센터에서 즐겨찾기 목록을 볼 수 있다'는 요구사항을 바탕으로, 확인이 필요한 비즈니스 규칙만 나열해 줘. 요구: 1. 기술 구현은 논하지 말 것. 2. 각 질문에 대해 왜 확인이 필요한지, 다른 답변이 어떤 차이를 만드는지 설명할 것. 3. 사용자 경험과 데이터 의미에 영향을 주는 문제를 우선 나열할 것.

이런 질문들은 보통 다음을 포함한다.

확인이 필요한 질문 먼저 확인하도록 권장하는 이유 한 사용자가 같은 상품을 여러 번 즐겨찾기할 수 있는가 유일성과 인터페이스 멱등 전략을 결정함 즐겨찾기 후 상품이 판매 중지되면 목록에 여전히 표시하는가 조회 조건과 사용자 기대를 결정함 상품 삭제 후 즐겨찾기 레코드를 어떻게 처리하는가 데이터 보존과 표시 전략을 결정함 즐겨찾기 폴더 그룹, 메모 또는 정렬이 필요한가 데이터 모델에 필드를 미리 둘지 결정함 즐겨찾기 수가 비즈니스 지표인가 카운트를 유지할지와 갱신 방식을 결정함

이 글의 예시에서는 먼저 다음 규칙을 약정한다.

1. 사용자는 반드시 로그인해야 상품을 즐겨찾기할 수 있다. 2. 같은 사용자는 같은 상품에 대해 즐겨찾기 레코드를 하나만 가질 수 있다. 3. 중복 즐겨찾기는 멱등 성공으로 간주하고, 현재 즐겨찾기 상태를 반환한다. 4. 판매 중지된 상품은 즐겨찾기 목록에 보존하고, 구매 불가로 표시한다. 5. 삭제된 상품은 즐겨찾기 목록에 표시하지 않는다. 6. 이번 기수에서는 즐겨찾기 폴더 그룹, 메모, 수동 정렬을 지원하지 않는다. 7. 이번 기수에서는 상품 즐겨찾기 수를 유지하지 않는다.

주의: 이 규칙들은 AI가 자동으로 내놓은 표준 답이 아니라, 예시 속의 비즈니스 결정이다.

2. 권한과 상태: 누가 할 수 있고, 어떤 상황에서 할 수 있는가

즐겨찾기 기능은 표면상 '추가'와 '해제' 두 동작만 있지만, 여전히 권한과 상태 판단이 관련된다.

계속해서 AI에게 상태 분석을 요구할 수 있다.

다음과 같이 확인된 규칙을 바탕으로, 상품 즐겨찾기 기능의 권한과 상태 문제를 분석해 줘. [확인된 규칙 붙여넣기] 다음을 출력해 줘: 1. 각 동작의 실행 주체. 2. 동작 전에 검증해야 할 대상과 상태. 3. 실행이 허용되지 않을 때 반환해야 할 비즈니스 결과. 4. 빠뜨릴 수 있는 동시성 또는 권한 초월 상황.

더 검토하기 쉬운 규칙 표를 얻을 수 있다.

동작 실행 주체 사전 검증 결과 상품 즐겨찾기 로그인한 사용자 상품이 존재하고 삭제되지 않음 즐겨찾기 생성 또는 기존 즐겨찾기 반환 즐겨찾기 해제 로그인한 사용자 즐겨찾기 레코드가 현재 사용자 소유 삭제 또는 멱등하게 성공 반환 즐겨찾기 목록 조회 로그인한 사용자 사용자 신원 유효 현재 사용자의 즐겨찾기만 반환 판매 중지 상품 조회 로그인한 사용자 상품이 삭제되지 않음 상품 반환, 단 구매 불가로 표시

여기 놓치기 쉬운 점이 하나 있다.

'즐겨찾기 해제'는 즐겨찾기 레코드 ID로만 삭제해서는 안 되고, 반드시 그 레코드가 현재 사용자 소유인지 확인해야 한다.

그렇지 않으면 권한을 초월한 삭제 문제가 생긴다.

3. 데이터와 인터페이스: 규칙이 어떻게 납품 가능한 계약이 되는가

규칙이 확인된 뒤에는, AI에게 데이터와 인터페이스 초안을 제안하도록 한다.

다음 비즈니스 규칙을 바탕으로, 상품 즐겨찾기 기능의 최소 데이터 모델과 인터페이스 계약을 설계해 줘. 제약: - 백엔드는 Java + Spring Boot. - 상품 테이블은 이미 존재하고, 이번 기수에는 즐겨찾기 수 필드를 추가하지 않는다. - 구체적인 ORM이나 SQL은 논하지 말 것. - 완전한 코드는 주지 말 것. 다음을 출력해 줘: 1. 즐겨찾기 레코드에 저장해야 할 필드와 용도. 2. 권장하는 유일성 제약. 3. 즐겨찾기, 즐겨찾기 해제, 목록 조회 세 인터페이스의 입력과 출력. 4. 페이징, 정렬, 상품 상태 반환 규칙. 5. 사람이 확인해야 할 인터페이스 세부사항.

이 글의 약정 아래에서는 다음 최소 모델을 형성할 수 있다.

필드 역할 id 즐겨찾기 레코드 식별자 user_id 즐겨찾기 소유 사용자 product_id 즐겨찾기된 상품 created_at 즐겨찾기 시간, 기본 정렬에 사용

가장 중요한 제약은 이것이다.

user_id + product_id 유일

그것은 '같은 사용자, 같은 상품은 한 번만 즐겨찾기할 수 있다'는 규칙을 표현함과 동시에, 동시 요청 시 데이터베이스가 최종 일관성을 유지하도록 도울 수 있다.

인터페이스 초안은 우선 이렇게 정할 수 있다.

인터페이스 목적 핵심 입력 핵심 출력 POST /products/{productId}/favorite 상품 즐겨찾기 현재 로그인 사용자, 상품 ID 현재 즐겨찾기 상태, 즐겨찾기 시간 DELETE /products/{productId}/favorite 즐겨찾기 해제 현재 로그인 사용자, 상품 ID 동작 결과 GET /me/favorites 즐겨찾기 목록 조회 페이징 파라미터 상품 정보, 상품 상태, 즐겨찾기 시간

여기서 모든 필드의 이름을 서둘러 확정할 필요는 없다.

더 중요한 것은 확인하는 것이다. 호출자가 무엇을 필요로 하는가, 인터페이스가 반드시 보장해야 하는 것은 무엇인가, 예외 상황은 어떻게 표현하는가.

4. 예외와 멱등성: 어떤 '실패'는 사실 사용자를 실패하게 만들어서는 안 되는가

AI는 예외와 경계 상황을 나열하도록 돕는 데 특히 적합하다.

이렇게 질문할 수 있다.

상품 즐겨찾기 기능의 예외와 멱등성 시나리오 목록을 설계해 줘. 확인된 규칙: [규칙 붙여넣기] '사용자 입력, 권한, 데이터 상태, 중복 요청, 동시 요청, 조회 결과'로 분류해 줘. 각 항목은 트리거 조건, 예상 동작, 오류를 반환해야 하는지를 포함할 것.

다음은 이 예시에서 중점적으로 확인해야 할 시나리오다.

시나리오 예상 동작 오류 여부 미로그인 상태에서 즐겨찾기 접근 거부 예 상품이 존재하지 않음 즐겨찾기 생성 안 함 예 상품이 이미 삭제됨 즐겨찾기 생성 안 함 예 중복 즐겨찾기 현재 즐겨찾기 상태 반환 아니오, 멱등 성공 존재하지 않는 즐겨찾기 해제 성공 반환 아니오, 멱등 성공 중복 해제 성공 반환 아니오, 멱등 성공 같은 상품 동시 즐겨찾기 최종적으로 레코드 하나만 보존 아니오, 결과 일관됨 즐겨찾기 목록이 비어 있음 빈 페이징 결과 반환 아니오

왜 여기서 중복 즐겨찾기와 중복 해제를 성공으로 정의하는가?

사용자가 여러 번 클릭할 수 있고, 클라이언트가 타임아웃 재시도할 수 있으며, 네트워크 때문에 요청이 중복 도착할 수도 있기 때문이다.

만약 매번 중복 동작에 오류를 반환하면, 호출자는 불필요한 분기를 많이 추가로 처리해야 한다.

물론 멱등 성공을 채택할지는 여전히 비즈니스 결정이다.

AI의 가치는 이 결정을 미리 드러나게 하는 데 있다.

5. 개발 작업과 테스트: 규칙을 팀이 실행할 수 있는 목록으로 만들기

규칙, 인터페이스, 예외가 모두 확인된 뒤에야 AI에게 개발 작업을 출력하게 하는 것이 적절하다.

아래 상품 즐겨찾기 기능 규칙을 백엔드 개발 작업 목록으로 분해해 줘. [확인된 규칙, 인터페이스 초안, 예외 전략 붙여넣기] 요구: 1. '데이터 계층, 도메인/서비스 계층, 인터페이스 계층, 테스트, 문서와 연동'으로 분류할 것. 2. 각 작업에 목표, 의존성, 인수 조건을 명확히 쓸 것. 3. 병렬로 진행할 수 있는 작업을 표시할 것. 4. 구체적인 구현 코드는 쓰지 말 것. 5. 마지막에 릴리스 전 점검 항목을 나열할 것.

실행 가능한 작업 목록은 대략 다음과 같아야 한다.

분류 작업 인수 조건 데이터 계층 즐겨찾기 레코드 테이블 또는 엔티티 매핑 생성 사용자, 상품, 생성 시간과 유일성 제약 포함 데이터 계층 사용자별 즐겨찾기 목록 조회 기능 추가 페이징과 즐겨찾기 시간 역순 지원 서비스 계층 상품 즐겨찾기 로직 구현 상품 상태 검증, 중복 즐겨찾기 멱등 서비스 계층 즐겨찾기 해제 로직 구현 현재 사용자 자신의 레코드만 삭제 가능, 중복 해제 멱등 인터페이스 계층 즐겨찾기, 해제, 목록 인터페이스 추가 파라미터, 인증, 응답이 인터페이스 계약에 부합 테스트 정상, 권한, 상태, 중복, 동시 시나리오 커버 핵심 규칙에 자동화 테스트 존재 연동 판매 중지, 삭제 상품의 목록 표시 확인 프런트엔드와 백엔드의 상태 필드 의미 일치 문서 인터페이스 설명과 예외 약정 갱신 호출자가 이를 바탕으로 구현하고 문제를 추적 가능

이 단계에 이르러서야 원본 요구사항이 진정으로 '한 문장'에서 팀이 개발을 시작할 수 있는 작업 패키지가 된다.

4. 완전한 Prompt: AI가 요구사항 분해와 작업 목록을 출력하게 하기

다음 Prompt는 유사한 요구사항의 출발점으로 삼을 수 있다.

원본 요구사항: 사용자는 상품을 즐겨찾기할 수 있고, 개인 센터에서 즐겨찾기 목록을 볼 수 있다. 프로젝트 배경: - 백엔드는 Java + Spring Boot를 사용한다. - 사용자는 반드시 로그인해야 개인 센터에 접근할 수 있다. - 상품 모듈은 이미 존재하며, 상품 상태는 상架(판매 중), 下架(판매 중지), 삭제를 포함한다. - 비즈니스 오류는 일괄적으로 DomainException을 사용한다. - 이번에는 백엔드와 인터페이스 작업만 분해하고, 프런트엔드 시각 디자인은 논하지 않는다. 확인된 규칙: 1. 사용자는 반드시 로그인해야 상품을 즐겨찾기할 수 있다. 2. 같은 사용자는 같은 상품에 대해 즐겨찾기 레코드를 하나만 가질 수 있다. 3. 중복 즐겨찾기는 멱등 성공으로 간주한다. 4. 판매 중지된 상품은 즐겨찾기 목록에 보존하고, 구매 불가로 표시한다. 5. 삭제된 상품은 목록에 표시하지 않는다. 6. 존재하지 않는 즐겨찾기 해제는 멱등 성공으로 간주한다. 7. 이번 기수에서는 즐겨찾기 폴더 그룹, 메모, 수동 정렬과 상품 즐겨찾기 수를 지원하지 않는다. 이번 라운드 납품 요구: 1. 코드를 쓰지 말 것. 2. 요구사항과 확인된 규칙을 다시 말할 것. 3. 여전히 사람이 확인해야 할 문제를 나열하고 영향을 설명할 것. 4. 권한과 상태 규칙 표를 출력할 것. 5. 최소 데이터 모델과 유일성 제약을 설계할 것. 6. 즐겨찾기, 즐겨찾기 해제, 즐겨찾기 목록의 인터페이스 계약을 출력할 것. 7. 예외, 멱등성, 동시성 시나리오를 나열할 것. 8. 데이터 계층, 서비스 계층, 인터페이스 계층, 테스트, 연동, 문서로 작업을 분해할 것. 9. 각 작업에 인수 조건과 의존 관계를 제시할 것. 10. 마지막에 릴리스 전 점검 목록을 출력할 것.

실제로 사용할 때에는, AI가 목록 한 부를 내놓았다고 해서 곧바로 개발을 시작하지 말라.

아래 순서대로 확인을 완료할 것을 권한다:

AI가 확인 대기 문제 출력 ↓ 제품과 비즈니스가 규칙 확인 ↓ 개발자가 시스템 경계와 기술 제약 확인 ↓ AI가 확인 결과에 따라 작업 목록 생성 ↓ 팀이 작업, 의존성, 인수 지점 리뷰 ↓ 구현과 테스트 진입

이렇게 AI를 사용해야 "요구사항 불명확"을 곧바로 "코드 복잡성"으로 전환하는 것을 피할 수 있다.

五、요구사항을 분해한 뒤, 이 작업 목록으로 착수할 수 있는지 어떻게 판단할까

AI가 생성한 작업 목록을 받은 뒤에는 아래 6가지 질문으로 점검할 수 있다:

- 규칙이 명확한가? 팀은 각 핵심 비즈니스 동작의 예상 결과를 알고 있는가?

- 경계가 나열되었는가? 중복 요청, 대상 미존재, 상태 변화, 권한 초과에 대한 정의가 있는가?

- 인터페이스 연동 테스트가 가능한가? 입력, 출력, 페이징, 예외, 상태 필드가 충분히 명확한가?

- 데이터가 규칙을 뒷받침할 수 있는가? 유니크 제약, 조회 인덱스, 데이터 보존 전략이 이미 고려되었는가?

- 작업을 인수할 수 있는가? 각 작업에 테스트하거나 리뷰할 수 있는 완료 기준이 있는가?

- 리스크에 담당자가 있는가? 어떤 문제는 제품이 확인해야 하고, 어떤 것은 백엔드, 프런트엔드, 테스트가 담당하는가?

리뷰 전에 이 목록을 그대로 복사할 수 있다:

[ ] 핵심 비즈니스 규칙과 이번 범위를 확인했다. [ ] 미확인 문제를 나열하고 확인 담당자를 지정했다. [ ] 권한, 상태, 예외, 멱등 전략을 정의했다. [ ] 인터페이스 입력, 출력, 페이징, 오류 규약을 확인했다. [ ] 데이터 모델, 유니크 제약, 동시성 리스크를 점검했다. [ ] 데이터 계층, 서비스 계층, 인터페이스 계층, 테스트 작업을 분리했다. [ ] 각 작업에 인수 지점, 의존성, 담당자가 있다. [ ] 릴리스 전에 검증해야 할 핵심 경로를 명확히 했다.

만약 이 질문들 대부분에 아직 답이 없다면, 현재는 코딩을 시작하기보다 계속 명확히 하는 것이 더 적합하다는 뜻이다.

六、정리

요구사항 단계에서 AI의 가장 가치 있는 능력은 비즈니스를 대신 결정해 주는 것이 아니라, 숨은 문제를 미리 명시적으로 드러내도록 돕는 것이다.

한 마디의 모호한 요구사항을 마주했을 때, 아래 5단계로 AI를 사용할 수 있다:

- 먼저 AI가 알 수 없는 문제를 나열하게 하고, 곧바로 코드를 작성하게 하지 않는다.

- 문제를 비즈니스, 권한, 데이터, 인터페이스, 예외, 일관성 차원으로 나눈다.

- 제품, 비즈니스, 팀과 핵심 규칙을 확인한다.

- 그다음 AI가 규칙을 인터페이스, 작업, 테스트 목록으로 전환하게 한다.

- 인수 지점과 릴리스 전 점검표로 작업 착수 가능 여부를 확인한다.

"요구사항을 받으면 코드를 쓴다"에서 "먼저 명확히 분해한 뒤 구현한다"로 바뀌면 한 단계 더 늘어난 것처럼 보인다.

하지만 그것은 보통 후반의 요구사항 변경, 인터페이스 재작업, 경계 누락이 초래하는 비용을 줄여 준다.

다음 글에서는 코딩 전 가장 중요한 단계로 들어간다:

AI가 먼저 방안을 쓰게 하고, 그다음 코드를 쓰게 하자.

이 글이 도움이 되었다면 좋아요, 즐겨찾기, 칼럼 팔로우를 환영한다.

댓글로 남겨 주는 것도 환영한다: 최근에 어떤 "보기에는 간단하지만 뜯어 보면 매우 복잡한" 요구사항을 겪었는가?

✍창작을 고수합니다, 팔로우, 좋아요, 즐겨찾기 부탁드립니다

全栈弄潮儿

풀스택 개발 엔지니어

96

글

107k

조회

82

팬