이득:
- AI 지원을 통해 모호한 비즈니스 요청을 명확하고 테스트 가능한 소프트웨어 요구 사항 및 사용자 스토리로 변환하는 기능
- 시스템 설계, 데이터 모델, 아키텍처 결정의 장단점을 AI를 통해 체계적으로 비교할 수 있는 능력
- 요구 사항, 확장성 및 제약 조건에 대해 AI가 제안한 설계를 비판적으로 검증하는 능력
대부분의 소프트웨어 프로젝트가 실패하는 이유는 잘못된 코드 때문이 아니라 요구 사항을 잘못 이해했기 때문입니다. "사용자가 보고서를 다운로드할 수 있게 해주세요"와 같은 한 문장 요청에는 답변할 수 없는 수십 가지 질문이 남습니다. 어떤 형식인가요? 책임자는 누구입니까? 얼마나 많은 기록이 있습니까? 느리면 어떡하지? 요구 사항 분석(비즈니스 요청을 명확하고 테스트 가능한 기술 요구 사항으로 변환) 및 소프트웨어 설계(이러한 요구 사항을 충족하기 위해 종이에 구조를 구성)는 코드를 작성하기 전에 가장 비용이 많이 드는 실수를 방지하는 단계입니다. 이 단원에서는 이 단계에서 AI를 "사고 파트너"로 사용하는 방법을 배웁니다. 즉, 불확실성을 이해하고 옵션을 분류하지만 최종 결정은 사용자에게 맡기는 파트너입니다.
AI는 여기서 두 가지 큰 가치를 생산한다. 첫째, 건너뛴 질문을 묻습니다. 이는 요청의 숨겨진 가정과 극단적인 사례를 표면으로 가져옵니다. 둘째, 디자인 결정의 장단점을 신속하게 도표화합니다. 그러나 그것은 위험합니다. AI는 상황(예산, 팀, 기존 시스템, 법적 제약)을 완전히 알지 못한 채 "모범 사례"로 일반적인 권장 사항을 제공합니다. 이 조언을 자신의 진실과 대조하여 필터링하는 것이 귀하의 임무입니다.
개념: 사용자 스토리: "... as, 나는 할 수 있기를 원합니다... 왜냐하면..." 형식으로 필요성을 표현하는 짧은 문장입니다. 수락 기준: 작업이 "완료"된 것으로 간주되기 위해 충족되어야 하는 테스트 가능한 조건입니다. 비기능적 요구사항: 속도, 보안, 확장성 등 "무엇을 할 것인가"보다는 "어떻게 동작할 것인가"와 관련된 요구사항입니다.
모호한 요청에서 테스트 가능한 요구사항으로
좋은 요구사항은 측정 가능하고 검증 가능합니다. "시스템을 빠르게 하라"가 아니라 "검색 결과가 500ms 이내에 반환되도록 하라". AI를 사용하여 불확실성을 좁히는 단계별 방법은 다음과 같습니다.
- 요청을 있는 그대로 제공하고 질문을 생성합니다. AI에게 해결책을 묻는 것이 아니라 먼저 "이 요청에서 불분명한 내용을 질문으로 나열"하는 것입니다.
- 당신은 대답을 제공합니다. 오직 당신만이 맥락을 알고 있습니다. 실제 비즈니스 제약 조건으로 AI의 질문에 답하세요.
- 이를 사용자 스토리와 수용 기준으로 변환하세요. 명확한 요구 사항을 테스트 가능한 항목으로 변환합니다.
- 극단적인 경우와 부정적인 시나리오를 추가합니다. "빈 결과", "인증되지 않은 사용자", "파일이 너무 큽니다" 등
모호성 추출 프롬프트: "다음 비즈니스 요청을 소프트웨어 요구 사항으로 변환합니다. 아직 솔루션을 제안하지 마십시오. 먼저 이 요청에서 답변되지 않은 모든 모호성과 숨겨진 가정을 질문 목록으로 추출합니다. 질문을 범위, 사용자/권한, 데이터 볼륨, 성능, 오류 조건, 보안 제목 아래에 그룹화합니다. 요청: '사용자가 주문 내역을 보고서로 다운로드하도록 허용하세요.'"
사용자 스토리 + 수용 기준 프롬프트: "다음의 명확한 요구 사항을 INVEST 원칙을 준수하는 사용자 스토리로 나눕니다. 각 스토리에 대해 3~5개의 테스트 가능한 수용 기준을 작성합니다(Give-When-Then 형식). 최소 2개의 부정적인 시나리오(무단 액세스, 빈 데이터)를 추가합니다. 요구 사항: [여기에 명확한 요구 사항 작성]"
디자인 결정을 AI와 비교
디자인은 속도 대 유연성, 단순성 대 확장성 등 끊임없는 절충안입니다. AI는 이러한 절충안을 빠른 스프레드시트에 넣습니다. 예를 들어 "알림 보내기" 기능의 경우 동기(요청 시 보내기) 접근 방식을 사용할지 아니면 비동기(큐, 백그라운드에서 보내기) 접근 방식을 사용할지 논의할 수 있습니다.
디자인 비교 프롬프트: "'사용자에게 이메일 알림 보내기' 기능을 설계 중입니다. 두 가지 접근 방식을 비교합니다. (A) HTTP 요청 중 동기 전달, (B) 메시지 대기열에 배치하여 백그라운드에서 비동기 전달. 다음 축에 대한 표를 만듭니다: 사용자 대기 시간, 내결함성, 복잡성, 인프라 비용, 디버깅의 어려움. 결국 어떤 경우에 선택할 것인지 2개의 문장으로 요약합니다. 나를 위해 결정하지 마세요."
축
동기 전송
비동기식(큐)
사용자 대기시간
롱(발송 대기 중)
짧음(즉시 반환)
내결함성
낮음(전송이 폭발하면 요청도 폭발함)
높음(재시도 가능)
복잡성
낮음
중간 높음(큐 인프라)
인프라 비용
낮음
추가 구성요소 필요
어디에 맞는지
저용량, 간단한 적용
대용량, 중요한 전달
팁: AI에게 "나를 위해 결정을 내리지 말고 옵션과 조건만 보여주세요"라고 말하면 생각을 하게 되고 제안을 맹목적으로 받아들이는 위험이 줄어듭니다. 최고의 디자인 결정은 귀하의 상황을 아는 사람(당신)이 내리는 결정입니다.
약한 프롬프트 / 강한 프롬프트
약점: "주문 시스템을 위한 데이터베이스를 설계합니다." (결과: 규모, 관계, 제약이 명확하지 않음. 일반적이고 비현실적인 계획.) STRONG: "소규모 전자 상거래를 위한 초안 데이터 모델을 제안합니다. 개체: 고객, 주문, 제품, 주문 항목. 제약: 주문에 여러 제품이 있을 수 있습니다. 제품 가격은 시간이 지남에 따라 변경될 수 있지만 현재 가격은 과거 주문에서 유지되어야 합니다. 하루에 최대 500개의 주문이 예상됩니다. 관계와 그 이유를 설명합니다. 결정. 가격 내역 문제를 어떻게 해결했는지 지정하십시오. 코드가 아닌 엔터티 및 필드 목록으로 제공하세요."
강력한 프롬프트의 차이; 규모(일일 500개 주문), 비즈니스 규칙(과거 가격을 유지해야 함) 및 원하는 출력 형식. "과거 가격을 유지해야 한다"는 한 문장이 디자인을 완전히 바꿔놓는다. 이를 지정하지 않으면 AI는 부정확하지만 그럴듯해 보이는 다이어그램을 생성합니다.
미니 케이스
사례 1 - 숨겨진 가정. 팀은 "사용자가 프로필 사진을 업로드할 수 있습니다" 요청을 직접 코딩합니다. 또 다른 팀은 AI에게 불확실성에 대해 물었다. "최대 크기? 허용되는 형식? 부적절한 콘텐츠 제어? 오래된 사진 삭제?" 다음과 같은 8개의 질문이 생성됩니다. 첫 번째 팀은 20MB 파일이 서버를 가득 채울 때 프로덕션 문제를 알게 됩니다. 두 번째 팀은 이를 디자인으로 해결합니다.
사례 2 - 잘못된 척도 가정. AI는 보고 기능을 위해 복잡한 캐싱 계층을 제안합니다. 실제 데이터는 하루 30건에 불과하다는 점을 엔지니어가 지적하면 AI가 제안을 단순화한다. 규모를 지정하지 않으면 불필요한 복잡성이 발생합니다. 지정하면 2주간의 불필요한 작업이 절약됩니다.
사례 3 — 허용 기준 격차. "결제가 실패하면 어떻게 되나요?" 질문을 한 적이 없기 때문에 결제가 실패할 경우에도 주문 시스템은 해당 주문을 "확인됨"으로 표시합니다. AI가 생성한 부정적인 시나리오 목록은 이러한 격차를 포착합니다. 1줄 승인 기준으로 실제 금전적 손실을 방지할 수 있습니다.
일반적인 실수
- 요청을 코드에 직접 전달합니다. 모호성이 해결되기 전에 작성된 코드는 잘못된 문제를 빠르게 해결합니다.
- AI의 일반적인 "모범 사례"를 맹목적으로 취하는 것입니다. 컨텍스트(규모, 예산, 팀)를 지정하지 않으면 권장 사항이 작동하지 않습니다.
- 비기능적 요구 사항을 건너뜁니다. 속도, 보안, 규모를 지정하지 않으면 디자인이 불완전해집니다.
- 행복한 시나리오만 생각하면 됩니다. 빈 데이터, 권한 없는 사용자, 오류 상태 등 부정적인 시나리오가 설계에 포함되어야 합니다.
- AI에 결정을 위임합니다. AI는 옵션을 생성합니다. 귀하의 비즈니스에 어떤 절충안이 적합한지 결정하세요.
요약하면
요구사항 분석 및 설계는 가장 저렴한 오류가 포착되는 단계입니다. 여기에서 AI는 불확실성을 드러내는 질문을 생성하고, 사용자 스토리와 수용 기준 초안을 작성하며, 디자인 균형을 차트로 만듭니다. 하지만 당신만이 맥락을 알고 있습니다. 규모, 예산, 팀 및 법적 제약을 기반으로 AI의 권장 사항을 필터링하고 최종 결정을 내리는 것이 귀하의 임무입니다. "나를 위해 결정을 내리지 말고 나에게 옵션을 보여주십시오"라는 규율은 더 나은 디자인과 더 깊은 학습으로 이어집니다.
응용과제
귀하의 상황에 맞는 한 문장의 작업 요청을 선택하십시오. 먼저, 모호성 프롬프트를 AI에 적용하고 실제 제약 조건으로 질문에 답하세요. 그런 다음 명확한 요구 사항을 최소 2개의 사용자 스토리와 각각에 대한 3개의 승인 기준으로 변환합니다. 부정적인 시나리오를 1개 이상 포함하세요. 마지막으로 설계 결정(동기/비동기, 테이블 구조 등)에 대한 비교표를 작성하고 자신의 결정을 2문장으로 작성하세요.
체크리스트
- [ ] 요청을 코드에 전달하기 전에 질문의 모호성을 제거했습니다.
- [ ] AI에 컨텍스트(규모, 권한, 성능, 법적 제약)를 부여했습니다.
- [ ] 나는 사용자 스토리를 테스트 가능한 수용 기준으로 나누었습니다.
- [ ] 하나 이상의 단점/모호한 시나리오를 추가했습니다.
- [ ] 절충표를 사용하여 설계 결정을 평가했습니다.
- [ ] 내 상황에 따라 최종 결정을 내렸으며 AI에 맡기지 않았습니다.