이 블로그 포스트는 AWS Quick을 기반으로 구축된 에이전트를 사용하고 프로세스에 사람의 승인을 포함시켜 AI가 제품 개발 수명 주기를 개선하고 가속화할 수 있는 방법에 초점을 맞춥니다.
AI 기반 소프트웨어 전달은 팀이 그 어느 때보다 빠르게 제품을 출시하도록 돕고 있습니다. 구현이 가속화될수록 상류의 제품 개발 프로세스는 더욱 중요해집니다. 코딩 에이전트는 명확한 요구사항을 작동하는 소프트웨어로 이전보다 빠르게 변환할 수 있지만, 잘못된 제품을 만드는 것을 만회할 수는 없습니다. 구현이 쉬워짐에 따라 경쟁 우위는 네 가지 핵심 활동인 올바른 고객 문제 발견, 어떤 기회를 추구할지 결정, 올바른 경험 설계, 그리고 프로토타입을 통한 검증이라는 상류 단계로 이동합니다.
그러한 결정을 내리는 데 필요한 신호들은 곳곳에 흩어져 있습니다. 고객은 Slack에 피드백을 남기고, 영업팀은 Salesforce에 인사이트를 기록하며, 시스템은 ServiceNow에 장애를 기록하고, 이해관계자들은 Microsoft SharePoint에 요구사항을 문서화하며, 엔지니어는 Jira에서 작업 항목을 추적하고, 팀은 Outlook 회의와 이메일 스레드에서 결정을 내립니다. 팀이 이러한 도구 사이를 이동할 때, 맥락은 그것이 뒷받침해야 할 결정과 분리되고, 전달이 반복될 때마다 더 많이 잃어버리게 됩니다.
AWS Quick는 단절된 지식을 연결하는 계층을 제공합니다. 연결된 엔터프라이즈 데이터를 기반으로 사용자 지정 챗 에이전트를 구현하고 그 산출물을 공유 스토리지에 저장함으로써 Spaces, AWS Quick은 팀이 빈 페이지에서 매번 새로 시작하는 대신 기존 조직의 지식을 활용하여 구축할 수 있도록 도와줍니다.
AI 기반 제품 개발 수명 주기(AI-PDLC)는 전문화된 기술을 갖춘 여섯 개의 AWS Quick 에이전트 제품군을 통해 이러한 역량을 적용하고, 각 단계에서 추적 가능한 산출물 세트를 생성하는 프레임워크입니다. 에이전트는 컨텍스트를 수집하고 구조화하며, 격차를 드러내고, 산출물 초안을 작성합니다. 사용자와 팀은 판단을 더하고 모든 결정을 승인합니다. 목표는 문서를 더 빨리 만드는 것이 아닙니다. 팀이 더 잘 사고하도록 돕고, 각 결정이 이루어진 이유를 보존하며, 고객 근거에 기반한 사양을 엔지니어링 및 코딩 에이전트에 제공하는 것입니다. AWS Quick에서 여섯 에이전트 AI-PDLC 제품군을 구성하고, 분산된 고객 신호에서 검증된 프로토타입으로 이동하는 방법을 보여드리겠습니다. 전 과정에서 첫 통찰부터 엔지니어링 인수인계까지 컨텍스트가 보존됩니다.
아키텍처
이 다이어그램은 AI-PDLC 프레임워크의 엔드투엔드 흐름을 보여줍니다.
그림 1: 흩어진 기업 신호부터 AWS Quick 에이전트를 거쳐 코딩 에이전트 인계에 이르는 엔드투엔드 AI-PDLC 흐름
대부분의 팀이 놓치기 쉬운 신호들, 즉 결정의 배경과 고객이 실제로 말한 내용을 담고 있는 Slack 스레드, Jira 티켓, 문서, 통화 전사 기록에서 시작됩니다. 엔터프라이즈 커넥터는 Slack, Outlook, Jira, Salesforce, SharePoint, ServiceNow 등 수많은 엔터프라이즈 소스에서 그러한 맥락을 가져옵니다.
그림 2: AWS Quick는 연결된 앱과 폴더 전반에서 사람, 프로젝트, 의사결정을 연결하는 개인 지식 그래프를 구축합니다
AWS Quick는 연결된 앱과 폴더에서 개인 지식 그래프를 구축하여 도구 전반에 걸친 사람, 프로젝트, 의사결정을 연결해 줄 수 있습니다.
이러한 신호는 브레인(뇌)에 공급됩니다: Orchestrator가 Discovery, Prioritize, Working Backwards, Spec Generator, Designer를 실행하는 AWS Quick의 에이전트 집합입니다. 이들이 생성하는 모든 것은 하나의 공통 언어로 모입니다: a prototype_spec.md 인수 기준, 페르소나, 화면, 데이터 모델을 담고 있습니다. 모든 결정은 출처로 거슬러 올라갈 수 있습니다.
AWS Quick은 개발 작업을 AI 코딩 에이전트에게 위임할 수 있습니다. 이 기능은 에이전트 클라이언트 프로토콜(Agent Client Protocol, ACP). ACP는 벤더 종속성이 없는 공개 JSON-RPC 2.0 표준입니다. 고객은 Kiro 또는 Claude Code 같은 선호하는 코딩 에이전트를 사용하여 AI-PDLC가 생성한 사양을 기반으로 개발할 수 있습니다.
그 모든 것의 이면에는 모든 단계마다 인간의 승인 관문이 흐르고 있습니다. 페인 포인트를 검증하고, 우선순위를 승인하고, 명세에 서명하고, 빌드를 통제하고, 리뷰를 수락합니다. 그런 다음 프로덕션 데이터가 Discovery로 다시 흘러 루프를 닫습니다. 에이전트가 작업을 수행하는 동안 판단은 당신이 내리며, 아무도 자신의 도구를 떠날 필요가 없습니다.
솔루션 개요
AI-PDLC 수명 주기는 Discover, Decide, Design, Prototype, Engineer, Ship, Operate, Learn의 8개 단계로 구성됩니다. 이 글은 제품 팀이 작업하는 처음 4개 단계에 초점을 맞춥니다. 마지막 4개 단계는 상위 단계에서 생성한 사양을 바탕으로 구축하는 Kiro와 같은 코딩 에이전트가 처리합니다. 상위 단계는 AWS Quick에서 6개의 에이전트로 구현됩니다.
그림 3: AWS Quick에서 6개의 에이전트로 구현된 상류 AI-PDLC 단계
사용자는 오케스트레이터(Orchestrator)와만 상호작용하며, 오케스트레이터는 실행 시점에 각 전문가의 질문 프레임워크를 읽어 현재 단계에 맞는 표적화된 질문을 하고, 산출물 생성을 알맞은 전문가에게 전달합니다. 하나의 대화가 전체 과정을 주도하며, 파이프라인은 워크플로의 각 단계에서 인간의 승인을 받은 후에만 진행됩니다.
그림 4: 단일 Orchestrator 대화가 파이프라인을 주도하며, 각 게이트에서 사람의 승인을 받은 후에만 진행된다
1단계: 발견
The Discovery agent 는 대화형 Q&A, URL 수집, 그리고 Slack, Jira, 지원 티켓, Salesforce, 연구 저장소와 같은 연결된 엔터프라이즈 소스에서의 직접 가져오기를 통해 구조화된 페인 포인트 분석을 안내합니다. 모든 페인 포인트의 심각도와 빈도를 점수화하여, 고객이 무엇에 어려움을 겪는지에 대한 근거 기반의 단일 시각을 팀에 제공하는 Pain Point Board 를 생성합니다.
그림 5: Discovery agent가 심각도와 빈도로 점수화된 Pain Point Board를 생성합니다
2단계: Decide
The Prioritize agent 는 두 가지 투명한 0–10 프레임워크를 사용하여 가중치 기준에 따라 각 사용 사례의 점수를 매깁니다. 하나는 에이전트형 사용 사례를 위해 특별히 설계된 프레임워크(대규모 언어 모델(LLM) 역량 적합성, 도구 가용성, 사용자 수용성)이고, 다른 하나는 전통적인 애플리케이션용 프레임워크(실현 가능성, 비즈니스 영향, 노력)입니다. 팀은 Scoring Matrix 를 열어 하나의 사용 사례가 왜 다른 사용 사례보다 우선순위를 갖는지 정확히 추적할 수 있습니다.
그림 6: Prioritize agent의 Scoring Matrix는 하나의 사용 사례가 왜 다른 사용 사례보다 우선순위를 갖는지 보여줍니다
최상위 사용 사례가 선택되면, the Working Backwards agent 가 Amazon Working Backwards 방식을 사용하여 고객 FAQ와 단위 경제성, 실패 모드, 규제 위험, 경쟁 환경을 다루는 내부 FAQ를 포함한 전체 PR/FAQ를 생성합니다. 어떤 컨셉이 이러한 검증을 통과하지 못하면, 팀은 엔지니어링 리소스를 투입하기 전에 종이 위에서 그 사실을 알게 됩니다.
그림 7: Working Backwards agent가 최상위 사용 사례에 대한 전체 PR/FAQ를 생성합니다
3단계: Design
The Spec Generator agent 는 검증된 사용 사례와 PR/FAQ를 빌드 준비가 완료된 사양으로 변환하며, 에이전트형 사용 사례와 애플리케이션 사용 사례를 위한 별도의 템플릿과 UX 팀을 위한 Design Handoff Brief 를 제공합니다. 각 사양에는 수용 기준, 사용자 흐름, 제약 조건, 그리고 모든 요구 사항을 원래의 페인 포인트, 우선순위 점수, 그리고 이를 검증한 PR/FAQ까지 거슬러 올라가 추적할 수 있는 메타데이터가 포함되어 있습니다. 이러한 수용 기준은 이중 목적을 수행합니다. 즉, 코딩 에이전트가 따르는 빌드 계약인 동시에 검토 에이전트가 감사하는 기준 검토 루브릭입니다. 여러 스프린트에 걸친 초안 작성과 검토에 걸리던 작업이 이제 집중된 한 번의 세션으로 바뀌며, 엔지니어링 팀이 설계 사양에서 즉시 빌드할 수 있을 만큼 상세하고, 명확화 회의가 거의 또는 전혀 필요하지 않습니다.
그림 8: Spec Generator agent가 검증된 사용 사례를 빌드 준비가 완료된 사양으로 변환합니다
4단계: Prototype
The Designer agent 는 journey maps, 와이어프레임, 그리고 클릭 가능한 HTML 프로토타입 AWS Quick 내부에서 직접 작동합니다. Design Handoff Brief, Discovery의 페르소나, PR/FAQ의 사용자 흐름, 설계할 화면, 브랜드 컨텍스트, 그리고 고객 인용문에서 도출된 감정적 목표를 바탕으로 작동하므로, 팀은 Figma나 기타 디자인 도구에 투자하기 전에 이해관계자와 함께 개념을 검증할 수 있습니다. 스펙이 승인되면 개발을 위해 엔지니어링 팀에 전달됩니다.
그림 9: Designer 에이전트가 AWS Quick 내부에서 여정 맵, 와이어프레임, 클릭 가능한 프로토타입을 생성합니다
전체 루프는 반복적이며, 모든 게이트에서 사람이 검토하고 승인합니다. 명시적인 사인오프 없이는 아무것도 출시되지 않습니다. 전통적으로 프로토타이핑과 반복에 여러 주가 걸리던 작업이, 문제의 복잡도에 따라 며칠 또는 단 몇 시간의 가이드된 에이전트 협업으로 단축될 수 있습니다.
모든 결정은 두 가지 수준에서 기록됩니다. 각 전문 에이전트는 자신이 생성하는 아티팩트 안에 자신의 결정, 점수, 근거를 기록하고, Orchestrator는 해당 항목들이 존재하는지 독립적으로 확인하면서 전체 파이프라인에 걸친 공유 로그를 유지합니다. 한 계층에서 누락이 발생하더라도 다른 계층에 완전한 기록이 남아 있으므로, 게이트 승인이 추적되지 않는 일은 없습니다.
AI-PDLC는 두 가지 페이싱 모드로 실행할 수 있습니다. Deep Discovery는 단계당 8–12개의 질문을 하며 모호성과 엣지 케이스를 추구합니다. 이는 팀이 철저한 탐색을 원하는 새로운 문제 공간에 적합합니다. Fast Track은 각 단계를 3–5개의 필수 질문으로 줄이고, 이미 보유한 컨텍스트에서 기본값을 제안하여 각각을 확인하거나 재정의할 수 있게 해줍니다. 이는 팀이 해당 공간을 잘 알고 빠르게 진행해야 하는 시간 제한 세션에 적합합니다.
에이전트 구현 세부 사항: 단계별 안내
에이전트 생성 및 구현 과정의 세부 사항을 살펴보겠습니다.
사전 요구 사항
- Desktop 클라이언트가 설치된 AWS Quick 워크스페이스.
- 팀이 사용하는 Slack, Jira, SharePoint 또는 기타 도구에 대해 Enterprise 커넥터가 구성된, AWS Quick에서 커스텀 에이전트를 생성할 수 있는 권한.
그림 10: Enterprise 커넥터가 구성된 AWS Quick 워크스페이스
단계 1: AI-PDLC 리포지토리 복제
전체 에이전트 스위트, 참조 아키텍처, 프롬프트 템플릿, 설정 지침은 다음에서 확인할 수 있습니다. AI-PDLC GitHub 리포지토리.
이 리포지토리에는 다음이 포함되어 있습니다:
- 여섯 개의 모든 에이전트를 위한 에이전트 지침 파일.
- 각 전문 에이전트를 위한 질문 프레임워크 샘플.
- 구성 파일 및 설정 가이드.
단계 2: 전문 에이전트 생성
AWS Quick에서 리포지토리의 지침을 사용하여 전문 에이전트를 생성합니다:
단계 2.1: 다음에서 JSON 파일을 다운로드합니다 에이전트 빌딩을 위한 GitHub 리포지토리.
단계 2.2: 로 이동합니다 Quick Desktop → Customize → Agents → Create, 그런 다음 Create from File을 선택합니다.
그림 11: Quick Desktop에서 Create from File로 전문가 에이전트 생성하기
단계 2.3: 채팅 창이 열립니다.
그림 12: 에이전트 생성 중에 열리는 채팅 창
단계 2.4: 다음 여섯 개의 에이전트가 지침과 함께 생성됩니다:
그림 13: 지침과 함께 생성된 여섯 개의 AI-PDLC 에이전트
Orchestrator는 중앙 아키텍처 구성 요소입니다. 런타임에 각 전문가의 지침을 동적으로 읽어 들입니다:
그림 14: Orchestrator가 런타임에 각 전문가의 지침을 동적으로 읽어 들이는 모습
단계 3: Quick Spaces(아티팩트 저장소) 구성
파이프라인 아티팩트를 저장하기 위한 공유 Quick Space를 생성합니다:
- 열기 Quick Spaces 및 선택 Create New Space.
- 이름: AI-PDLC Artifacts.
- 관련 팀 구성원에게 접근 권한을 부여합니다.
그림 15: AI-PDLC Artifacts Space 생성 및 팀 구성원에게 접근 권한 부여
단계 4: 파이프라인 실행
- AWS Quick Desktop을 엽니다.
- 에이전트 선택기에서 AI-PDLC Orchestrator 를 선택합니다.
- 다음을 입력합니다: “Run the full pipeline”(또는 요약된 세션의 경우 “Fast Track”).
- Orchestrator가 각 단계를 안내하는 동안 구조화된 질문에 답변합니다.
- 각 게이트에서 산출되는 아티팩트를 검토합니다.
그림 16: 파이프라인 실행 및 각 게이트에서 산출되는 아티팩트 검토
그림 17: AI-PDLC Orchestrator로 파이프라인 실행 시작
필요에 따라 진행 속도인 Deep Discovery 또는 Fast Track을 선택할 수 있습니다.
그림 18: 필요에 따라 진행 속도인 Deep Discovery 또는 Fast Track 선택
실제 작동 모습 보기
고객 인사이트부터 네 단계 전체를 거친 동작하는 프로토타입까지 AI-PDLC의 실제 작동 모습을 보여주는 라이브 데모는 YouTube 동영상 워크스루를 시청하세요:
이 영상에서 다루는 내용:
- 에이전트 스위트 설정하기.
- 실제 사용 사례를 통해 전체 Orchestrator 파이프라인 실행하기.
- 실시간 아티팩트 생성의 실제 모습.
- 코딩 에이전트로의 ACP 인계.
- Deep Discovery 모드와 Fast Track 모드 중에서 선택할 때 참고할 팁.
AI-PDLC 시나리오
AI-PDLC 프레임워크를 적용할 수 있는 몇 가지 일반적인 시나리오를 살펴보겠습니다:
시나리오 1: 제로베이스에서 시작하는 신제품 개발
팀이 새로운 시장 기회나 충족되지 않은 고객 니즈를 발견하면, 전형적인 콜드 스타트 문제에 직면하게 됩니다. 흩어진 신호들, 경쟁하는 아이디어들, 그리고 인사이트를 실행으로 옮길 구조화된 방법이 없는 상황입니다. AI-PDLC는 팀이 상류 전 과정을 통과하도록 안내하며, 실제 고객 데이터에서 페인 포인트를 도출하고 투명한 기준에 따라 경쟁 아이디어를 평가 점수화합니다. 또한 엄격한 PR/FAQ를 통해 컨셉을 검증하고 빌드 준비가 완료된 명세를 산출하여, 첫 번째 코드가 직감이 아닌 검증된 계획을 기반으로 작성되도록 합니다.
시나리오 2: 기존 제품에 대한 기능 추가, 로드맵 주도 또는 고객 주도
제품 팀은 다음에 무엇을 만들지 결정하는 신호를 지속적으로 수신합니다: 지원 채널의 고객 피드백, 영업팀의 기능 요청, 이탈 지점을 보여주는 사용 데이터, 또는 경영진의 전략적 우선순위 등이 그것입니다. AI-PDLC는 연결된 도구(Slack, Jira, Salesforce, AWS Quick Sight)에서 이러한 신호를 끌어와 이 과정을 가속화합니다. 이 프레임워크는 근거 기반 스코어링을 통해 이를 우선순위가 매겨진 백로그로 구조화하고, 각 기능의 'why(이유)'를 보존하는 스펙을 생성함으로써, 엔지니어링 팀이 의도가 제거된 한 줄짜리 Jira 티켓이 아닌 풍부한 맥락을 갖춘 작업 항목을 받도록 합니다.
시나리오 3: 버그 수정 및 장애 기반 개선
고객 불만, 모니터링 알림, 또는 지원 에스컬레이션을 통해 프로덕션 문제가 발생했을 때, 대응은 종종 구조화된 분석을 건너뛰고 바로 코드 수정으로 넘어갑니다. AI-PDLC는 근본 원인을 문서화된 pain point로 기록하고, 해당 수정이 더 광범위한 설계 변경을 요하는지 아니면 표적화된 패치로 충분한지를 평가함으로써 이러한 반응적 워크플로우에 규율을 부여합니다. 이는 테스트 가능한 수용 기준이 포함된 범위가 명확한 spec을 산출하여 수정이 단순히 증상이 아닌 근본적인 문제를 다루도록 하며, 의사 결정 과정은 향후 참조를 위해 보존됩니다.
각 시나리오는 동일한 파이프라인(Discover → Decide → Design → Prototype)을 따르지만 진입 깊이가 다릅니다. 신규 제품은 전체 과정을 거치고, 기능 추가는 심층 디스커버리를 생략할 수 있으며, 버그 수정은 한 번의 집중된 사이클로 압축될 수 있습니다. 방법론은 유연하게 조정되지만 감사 기록과 거버넌스는 상황과 무관하게 일관되게 유지됩니다.
정리
이 워크스루가 생성하는 리소스는 유휴 상태에서 비용이 전혀 발생하지 않으므로, 파이프라인을 다시 실행할 계획이라면 AI-PDLC 스위트 전체를 그대로 유지해도 안전합니다.
더 이상 필요하지 않은 것을 제거하려면 다음 위치 아래의 6개 에이전트를 삭제하십시오. 사용자 지정 → 에이전트 Quick Desktop에서 삭제하십시오 AI-PDLC 아티팩트 Space(또는 그 안의 테스트 아티팩트만)를 삭제하고 부여했던 팀 액세스를 취소하며, 이 연습을 위해서만 추가했던 Enterprise 커넥터나 코딩 에이전트 연결을 모두 연결 해제할 수 있습니다. 또한 로컬 머신에서 복제한 GitHub 저장소를 제거할 수도 있습니다.
결론
제품 개발의 병목은 이동했습니다. 코딩 에이전트 덕분에 구현은 빨라졌습니다. 그러나 상류 업무가 여전히 팀을 제약합니다: 고객 문제 발견, 무엇을 만들지 결정, 컨셉 검증, 명확한 명세 작성이 그것입니다. 이 상류 사이클을 압축하는 팀은 복리 효과를 얻을 수 있습니다: 더 적은 비용이 드는 방향 전환으로 올바른 제품을 더 빨리 만들어내는 것입니다.
AI-PDLC는 이 문제를 직접적으로 해결합니다. AWS Quick에서 에이전트 모음으로 구현된 이 구조화되고 AI 네이티브한 프레임워크는 제품 팀이 Discover, Decide, Design, Prototype 단계를 진행할 수 있도록 하며, 모든 게이트에 거버넌스를 내장하고 있습니다. AI-PDLC는 모든 의사결정의 근거를 남깁니다. 모든 산출물은 고객 증거로 거슬러 올라갈 수 있습니다. 그리고 스펙이 엔지니어링 팀에 전달될 때, 왜 존재하는지, 누가 검증했는지, "완료"가 무엇을 의미하는지에 대한 전체 맥락을 함께 담고 있습니다.
제품 팀의 역할은 코드를 작성하는 것이 아닙니다. 무엇을, 왜 만들지에 대해 올바른 결정을 빠르고 추적 가능한 방식으로 내리는 것입니다. AI-PDLC가 그것을 가능하게 합니다.
오늘 바로 시작하세요
- 다음을 복제하세요 저장소.
- 저장소의 설정 가이드를 따라 5개의 전문 에이전트와 1개의 오케스트레이터(Orchestrator)를 생성하세요.
- 에이전트 선택기에서 “AI-PDLC Orchestrator”를 선택하고 “Run the full pipeline”이라고 입력하세요.