Prompt engineering by Quick component: Patterns and pitfalls

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Quick의 구성 요소별로 연구 목표, 자동화 단계, 분석 조건, 에이전트 역할과 지식 범위, 외부 시스템 작업 매개변수를 구체화하면 더 정확하고 실행 가능한 결과를 얻을 수 있다는 프롬프트 작성 지침이다.

📌 핵심 요약

• Quick Research는 연구 목표를 하위 주제로 나누고 기업 데이터와 외부 자료를 검색해 인용이 포함된 보고서를 만든다. 목표에 주제·기간·대상 독자·핵심 질문을 명시하고, Quick Index, 200곳 이상의 신뢰할 수 있는 뉴스 매체, 전문 데이터셋 중 적합한 출처를 선택한 뒤 초안 연구 계획을 검토하도록 권한다.
• Quick Flows는 자연어 설명을 자동화 워크플로로 변환한다. 일정·실행 조건·데이터 출처·계산·출력 형식·전달 대상을 구체화하고, 복잡한 작업은 번호를 붙인 단계로 제시하며, 새로운 데이터가 없는 경우의 처리도 명시해야 한다. 생성 후에는 대화로 필요한 단계만 수정할 수 있다.
• Quick Sight 분석 요청에는 업무 질문, 지표, 차원, 기간, 시각화 유형, 추가 분석을 포함해야 한다. 시계열·비교·관계·분포·지리 분석에 맞는 표현을 지정하고, Topics에서는 업무 성과 중심으로 질문하며, 후속 대화로 차트·필터·집계·계산 필드를 조정할 수 있다.
• Quick chat agents는 Builder Mode에서 역할·전문성·응답 범위를 정의하고, 역할에 맞는 Quick Spaces를 연결해야 한다. 정보가 부족할 때 추측하지 않고 관련 팀이나 자료로 안내하도록 명시하며, 에이전트 정체성과 연결 문서를 주기적으로 검토하고 구체적인 추천 프롬프트를 제공하도록 권한다.
• Action integrations는 Jira, Slack, Confluence, Salesforce 같은 외부 시스템과 상호작용한다. 작업 의도와 필수 매개변수, 실행 순서를 명확히 제공해야 하며, Jira 예시는 프로젝트·이슈 유형·요약·우선순위·담당자·라벨·설명을 지정한다. 제공된 원문은 작업 순서 설명 도중 잘려 후속 내용은 확인할 수 없다.

🧩 주요 포인트

1. 목표와 범위의 명시 → Quick Research의 조사 방향, Quick Sight의 분석 표현, Quick chat agents의 응답 경계를 실제 업무 목적에 맞게 좁힌다.
2. 실행 조건과 단계의 구조화 → Quick Flows와 Action integrations에서 누락된 매개변수로 인한 추가 질문이나 가정을 줄이고, 단계별 수정과 오류 위치 파악을 돕는다.
3. 출처 선택·정보 부족 대응·후속 대화 → Quick Research의 불필요한 자료를 줄이고, Quick chat agents의 근거 없는 답변을 억제하며, Quick Flows와 Quick Sight의 결과를 점진적으로 개선한다.

🧠 상세 정리

1. 공통 원칙에서 Quick Research의 목표 설정으로

원문은 앞선 Part 1에서 다룬 구체성, 맥락 설정, 소수의 예시, 복잡한 요청을 위한 CRISPE 프레임워크가 Amazon Quick 전반에 적용된다는 설명에서 출발한다. 이번 글은 같은 원칙을 각 구성 요소가 프롬프트를 해석하는 방식에 맞춰 적용하는 데 초점을 둔다. Quick Research는 사용자의 목표를 하위 주제로 나누고 기업 데이터와 외부 출처를 검색한 뒤 인용이 포함된 구조화된 보고서를 제공하므로, 모호한 목표는 피상적인 보고서로 이어진다고 설명한다. 강한 목표에는 조사 주제, 기간, 대상 독자, 중요하게 다룰 결과가 들어가며, 무엇을 누구를 위해 왜 달성하려는지를 분명히 해야 한다. 예시는 지난 12개월 동안 미국 병원 시스템의 생성형 AI 도입을 조사하되 임상 의사결정 지원과 일정·청구·기록 관리 등 행정 자동화에 집중하고, 다음 투자처를 결정하는 의료 IT 임원에게 맞춰 작성하도록 요청한다. 이런 맥락은 하위 질문과 자료 선택, 보고서 구성에 영향을 주므로, 연구가 어떤 결정에 쓰이고 누가 읽으며 어떤 결과를 필요로 하는지 먼저 정리하도록 권한다.

2. Quick Research의 하위 질문과 출처 선택

Quick Research는 목표를 자동으로 하위 주제로 분해하지만, 여러 측면을 가진 조사에서는 사용자가 답을 원하는 질문을 직접 나열하면 방향이 더 명확해진다고 설명한다. 이 방식은 에이전트가 주변 논점으로 벗어날 가능성을 줄이는 데 도움이 된다. 자료 출처에는 Quick Index를 통한 기업 데이터, 200곳 이상의 신뢰할 수 있는 뉴스 매체, S&P Global·FactSet·IDC·미국 특허 데이터·PubMed의 전문 데이터셋이 포함된다. 목표를 입력한 뒤에는 사용할 출처를 선택하고 초안 연구 계획을 검토해야 하며, 모든 출처를 일괄적으로 포함하는 방식은 권하지 않는다. 원문은 경쟁 분석에는 PubMed가 필요하지 않고 임상 문헌 검토에는 뉴스 기사가 필요하지 않다는 예시로 조사 목적과 자료 유형의 적합성을 강조한다. 출처 범위를 좁히는 것은 에이전트의 집중도를 높이고 불필요한 정보를 줄이는 수단으로 제시된다.

3. Quick Flows의 구체적 조건, 단계 구조와 대화형 수정

Quick Flows는 자연어 설명을 자동화 워크플로로 바꾸지만, 무엇을 원하는지만 적고 방법·시점·대상을 빠뜨리면 결과도 모호해진다고 설명한다. 판매 보고서 예시는 매주 월요일 오전 8시에 CRM에서 지난주 데이터를 가져와 총매출과 판매 수량 기준 상위 10개 제품을 계산하고, 한 페이지 PDF를 만들어 판매 관리자 배포 목록에 이메일로 보내도록 구체화한다. 트리거는 일정뿐 아니라 발생 시스템과 새로운 데이터의 정의, 실행 시 새로운 데이터가 없는 경우의 처리까지 명시해야 한다. 두세 개를 넘는 작업은 번호 순서로 작성하는 것이 권장되며, Quick Flows가 지원하는 조건 분기·반복 루프·사용자 입력은 이런 단계 구조와 자연스럽게 연결된다. 경비 처리 예시는 PDF나 이미지에서 금액·판매자·날짜·경비 범주를 추출하고, 총액이 500달러를 넘으면 재무팀 Slack 채널로 승인을 요청한 뒤 승인 시각과 함께 Google Sheets에 기록하도록 구성한다. 생성 후에는 agentic runtime이 기존 맥락을 유지하므로 전체 프롬프트를 다시 쓰기보다 필요한 부분을 대화로 수정할 수 있다. 예를 들어 데이터 출처가 결과를 반환했는지 확인하는 단계를 추가하고, 조회 결과가 비어 있으면 이후 작업 대신 알림을 보내도록 요청할 수 있다.

4. Quick Sight의 분석 질문과 시각화 패턴

Quick Sight에서는 업무 질문, 지표, 차원, 기간, 시각화 유형, 추가 분석을 함께 지정해야 하며, 요소가 빠지면 시스템이 추정해 기술적으로는 맞지만 업무에 유용하지 않은 시각화를 만들 수 있다고 설명한다. 시계열 예시는 지난 12개월의 고객 지원 티켓 수를 우선순위별 누적 선 그래프로 표시하고 전체 물량의 추세선을 추가하도록 요청한다. 비교 예시는 2025년 4분기의 평균 계약 규모를 산업 분야와 영업 담당자별로 묶은 막대그래프로 나타내고, 내림차순 정렬과 평균 5만 달러 미만인 분야의 강조를 지정한다. 관계 분석은 고객 생애 가치와 제품 사용 빈도의 산점도에 구독 등급별 색상과 회귀선을 넣어 사용 빈도의 예측 관계를 살펴보도록 구성한다. 분포 분석은 최근 6개월의 프로젝트 완료 기간을 2주 간격으로 묶은 히스토그램에 목표 완료 기간을 기준선으로 표시하고, 프로젝트의 20%를 넘게 차지한 구간을 짚도록 요청한다. 지리 분석은 북미 고객 분포를 열지도로 보여주면서 색의 강도로 매출 집중도를 표현하고, 전체 매출의 10%를 넘게 기여하는 지역에 데이터 라벨을 추가하도록 한다.

5. Quick Sight의 업무 중심 질문과 계산 필드

Topics는 대화형 질의에 맞게 선별된 데이터 모음이며, 이를 사용할 때에는 데이터 처리 방식보다 업무 성과를 중심으로 질문하도록 권한다. 원문은 단순히 사용자 수 표를 요청하는 대신 일간 활성 사용자 수와 세션 길이를 기준으로 모바일 앱 참여도가 가장 높은 고객 세그먼트를 묻는 예시를 제시한다. 초기 시각화가 생성된 뒤에는 후속 대화로 차트 유형을 바꾸거나 필터를 추가하고, 집계 방식을 수정하거나 계산 필드를 요청할 수 있다. 계산식도 자연어로 설명할 수 있으며, 예시는 ‘Customer Health Score’에 갱신 확률 40%, 제품 사용 추세 35%, 지원 티켓 빈도 25%의 가중치를 적용하도록 요청한다. 이때 티켓 빈도는 적을수록 더 건강한 고객으로 해석하는 역방향 조건을 명시하고, 최종 결과를 0~100 지수로 표시하도록 지정한다. 이 사례는 계산 필드 이름뿐 아니라 구성 요소, 가중치, 해석 방향, 표현 척도까지 설명하면 분석 의도를 더 구체적으로 전달할 수 있음을 보여준다.

6. Quick chat agents의 정체성과 응답 경계

Quick chat agents는 조직에 대화형 AI를 제공하며, 사용자는 에이전트의 정체성, 회사 지식 연결, 행동 가드레일을 설정한 뒤 팀에 공개할 수 있다. Builder Mode의 정체성 필드는 모든 응답의 기반이 되므로 역할, 전문 영역, 명확한 경계를 함께 정의해야 한다고 설명한다. 원문의 예시는 FinOps 팀을 위한 Cloud Cost Optimization Advisor로서 AWS 비용 관리, 예약 인스턴스 계획, Savings Plans 분석, 리소스 적정 규모 조정을 전문 영역으로 지정한다. 동시에 클라우드 비용 최적화 질문에만 답하고 범위 밖의 질문에는 그 사실을 알린 뒤 적절한 팀을 제안하도록 요구한다. 이런 경계가 없으면 에이전트가 전문성 밖의 질문에도 자신 있게 답하면서 신뢰하기 어려운 응답을 내놓는 경향이 있다고 경고한다. 팀의 우선순위, 도구, 조직 구조가 바뀔 수 있으므로 정체성을 주기적으로 검토해야 하며, 6개월 전에 작성한 설명이 현재 필요를 반영하지 못할 수 있다는 점도 짚는다.

7. Quick Spaces, 정보 부족 대응과 추천 프롬프트

Quick Spaces 연결은 에이전트가 활용할 수 있는 정보를 결정하므로, 조직의 모든 공간을 연결하기보다 정의된 역할에 맞는 지식 출처를 선택하도록 권한다. 모든 공간에 연결된 에이전트는 관련 없는 내용을 제시할 수 있으며, 정보가 부족할 때의 행동을 명시하지 않으면 그럴듯하지만 조작된 답변으로 빈틈을 채울 수 있다고 설명한다. 예시는 현재 지식 기반에 해당 정보가 없음을 밝히고 관련 팀이나 특정 자료에서 최신 안내를 확인하도록 응답하며, 추측하거나 답을 만들어내지 말라는 지침을 포함한다. 연결된 공간도 주기적으로 검토해야 하며, 오래된 문서는 에이전트가 자신 있게 인용할 수 있어 문서가 없는 것보다 나쁠 수 있다는 이유로 낡은 출처의 제거와 새 출처의 추가를 권한다. 추천 프롬프트는 사용자가 처음 보는 질문 예시이므로, 모호한 비용 질문 대신 운영 계정의 EC2 인스턴스군 중 지난 30일간 활용도가 가장 낮은 대상과 규모 조정에 따른 절감액처럼 구체적인 요청을 보여줘야 한다. 또 다른 예시는 온디맨드 RDS 사용을 1년 예약 플랜 또는 3년 Savings Plan으로 전환할 때의 비용 영향을 비교하고, 절감과 유연성의 균형을 묻는 형태다.

8. Action integrations의 필수 매개변수와 원문 범위

Action integrations의 커넥터를 사용하면 Quick이 Jira, Slack, Confluence, Salesforce 같은 외부 시스템과 상호작용할 수 있다. 효과적인 작업 프롬프트에는 명확한 의도, 필요한 모든 매개변수, 적절한 실행 순서가 포함되어야 한다고 설명한다. 매개변수가 불완전하면 시스템이 추가 질문을 하거나 가정해야 하므로, 필요한 정보는 처음부터 제공하는 것이 권장된다. Jira 이슈 생성 예시는 프로젝트를 CUSTOMER-SUPPORT, 이슈 유형을 Bug, 우선순위를 High로 지정하고, 요약에는 고객 이름과 간략한 설명을 넣으며 담당자는 당직 지원 엔지니어로 설정한다. 라벨은 customer-reported와 needs-triage를 사용하고, 설명에는 재현 단계, 기대 동작과 실제 동작의 차이, 고객 계정 등급을 포함하도록 요청한다. 이어지는 작업 순서 항목은 여러 단계의 워크플로를 구조화하라는 설명 도중 잘려 있으므로, 제공된 원문만으로는 구체적인 후속 순서 지침이나 글의 결론을 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 구체성의 형태는 구성 요소마다 다르다. Quick Research에는 조사 목적과 출처가, Quick Flows에는 실행 조건과 단계가, Quick Sight에는 분석 요소와 표현 방식이 핵심이므로 동일한 질문 형식을 모든 기능에 그대로 적용하기 어렵다.
• 입력 범위를 넓히는 것만으로 품질이 높아지는 것은 아니다. Quick Research의 출처 선택과 Quick chat agents의 Quick Spaces 연결은 업무 목적에 맞게 범위를 좁히는 것이 관련성과 신뢰성에 도움이 된다는 공통 논리를 가진다.
• Quick Flows와 Quick Sight의 대화형 수정은 초기 요청에 필요한 구조를 갖춘 뒤 특정 단계나 표현을 점진적으로 개선하는 방식이다. Quick chat agents에서는 역할 경계와 정보 부족 시 대응을 명시하는 것이 자신 있게 제시되는 부정확한 답변을 줄이는 핵심 조건으로 제시된다.

✅ 액션 아이템

• Quick Research의 연구 목표에 주제·기간·대상 독자·핵심 질문을 명시하고, 목적에 맞는 출처와 초안 연구 계획을 검토한다.
• Quick Flows의 일정·실행 조건·데이터 출처·출력 형식·전달 대상을 구체화하고, 새로운 데이터가 없는 경우의 처리와 복잡한 작업의 번호 순서를 명시한다.
• Quick chat agents의 역할·전문성·응답 범위에 맞춰 Quick Spaces를 연결하고, 정보가 부족할 때의 안내 방식과 연결 문서의 최신성을 검토한다.

❓ 열린 질문

• Quick Research의 연구 목표에는 어떤 주제·기간·대상 독자·핵심 질문을 명시해야 실제 업무 결정에 필요한 보고서를 얻을 수 있는가?
• Quick Flows의 실행 조건이 충족됐지만 새로운 데이터가 없는 경우에는 어떤 처리를 수행해야 하는가?
• Quick chat agents가 정보 부족을 알릴 때 안내할 관련 팀이나 자료는 무엇이며, 연결된 Quick Spaces의 문서는 최신 상태인가?