☰ 분류

프로덕션 AI 에이전트 설계 프롬프트

자동화할 업무, 산출물, 데이터 소스, 도구, 주기, 제약과 위험을 넣으면 15단계로 AI 에이전트 아키텍처를 설계합니다.

분류개발 › 배포·운영
태그초안작성분석개발자체크리스트
프롬프트 (영어 본문 · 답은 한국어로 옵니다)
ROLE
You are a senior architect of production-ready AI agents and a business process automation specialist.

TASK
Help design an AI agent for the process described below.
The agent must be reliable, controllable, token-efficient, and suitable for regular use.

CONTEXT
Process:
${process:Describe the current manual task in detail}

Expected output:
${expected_output:What should the agent produce?}

Data sources:
${data_sources:Websites, spreadsheets, CRM, Telegram, email, files}

Available tools:
${tools:APIs, MCP, scripts, browser, database}

Run frequency:
${frequency:Scheduled, event-triggered, or manual}

Constraints:
${constraints:Budget, time, API rate limits, security requirements}

Critical risks:
${risks:Data deletion, publishing, payments, access credentials}

---

WORKFLOW
First, ask any clarifying questions that are essential for designing a reliable system.
After receiving answers, proceed through all 15 steps:

1. Break the process into discrete stages
2. Identify where LLM is needed vs. where a simple script is enough
3. Define input and output data for each stage
4. List all required tools, APIs, and access credentials
5. Propose a memory and state management structure
6. Design the main agent loop
7. Add result verification after each critical stage
8. Add error handling, retries, and fallback routes
9. Define stopping conditions and rate limits
10. Identify actions that require human approval
11. Propose a logging, metrics, and alerting system
12. Describe a safe self-improvement mechanism via error analysis
13. Create a list of test scenarios
14. Propose a project file structure
15. Prepare a step-by-step development plan

---

DELIVERABLES
Split the solution into three versions:

🟢 MVP — minimal working agent (fast to ship)
🟡 STABLE — reliable version for regular production use
🔵 PRO — advanced version with memory, monitoring, and self-improvement

Then output:
- System architecture overview
- Data flow diagram (text-based)
- Full tool and API list
- Pseudocode for the main loop
- Recommended folder structure
- Step-by-step development roadmap
- Security checklist
- Testing checklist
- Agent readiness criteria

어떤 프롬프트인가

반복 사용 가능한 업무 자동화 에이전트를 설계할 때 쓰기 좋다. MVP, STABLE, PRO 세 버전으로 나누고 검증, 승인, 로깅, 보안, 테스트 체크리스트까지 요구한다.

모델 비교

Claude는 가장 충실하고 구체적이며, ChatGPT는 더 간결하지만 일부 질문이 빠졌다. Gemini는 필수 확인 절차를 어기고 미확인 비용·정확도·도구를 단정했으며 답도 중간에 끊겼다.

ChatGPT종합 1위
47/ 50

+ 필수 질문을 간결하고 운영 중심으로 정리했다.

- 실행 인프라와 개발 일정 확인이 빠져 있다.

Claude
46/ 50

+ 핵심 설계 변수와 안전한 기본값을 구체화했다.

- 첫 확인 단계치고 질문과 설명이 다소 길다.

Gemini
21/ 50

+ 데이터 흐름과 구현 요소를 매우 구체화했다.

- 답변 전 설계를 강행했고 수치와 가정을 지어냈다.

기준ChatGPTClaudeGemini앞선 모델
지시 준수10102동점
정확성993동점
구체성9108Claude +11%
구성·가독성996동점
분량 적정성1082ChatGPT +25%

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력
[붙여 넣은 자료]
process: 고객센터에 접수되는 CS 티켓을 담당자가 수작업으로 읽고 카테고리(배송/환불/제품불량/기타)를 분류한 뒤 담당 부서에 수동으로 전달하고 있음. 하루 평균 200건, 분류에만 2명이 3시간씩 씀.
expected_output: 티켓별 카테고리 태그, 우선순위(긴급/보통/낮음), 담당 부서 배정 결과를 CRM에 자동 기록
data_sources: Zendesk 티켓 API, 내부 고객 DB(PostgreSQL), 상품 카탈로그 스프레드시트
tools: Zendesk API, Slack 알림 webhook, 사내 CRM REST API
frequency: 신규 티켓 생성 시 이벤트 트리거
constraints: 월 예산 30만원 이내, 오분류 시 담당자가 5분 내 재배정 가능해야 함, 고객 개인정보는 외부로 전송 금지
risks: 잘못된 부서 배정으로 인한 응대 지연, 긴급 환불 건을 낮은 우선순위로 오분류할 위험
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

신뢰성 있는 설계를 위해 아래 사항을 먼저 확인해야 합니다.

  1. 분류 기준

    • 배송/환불/제품불량/기타의 공식 판정 규칙이나 예시 티켓이 있나요?
    • 한 티켓에 여러 이슈가 있을 때 단일 카테고리만 지정하나요, 복수 태그를 허용하나요?
  2. 우선순위 기준

    • 긴급 판정 조건을 정의해 주세요. 예: 환불 금액, 안전 문제, 배송 지연 일수, 욕설·법적 위협, VIP 고객 등
    • 긴급 티켓은 자동 배정하되 Slack 알림만 보내면 되나요, 아니면 담당자 승인 후 CRM에 기록해야 하나요?
  3. 부서 배정

    • 각 카테고리별 담당 부서 매핑이 고정인가요?
    • 고객 등급, 상품 유형, 지역, 주문 상태 등에 따라 예외적으로 다른 부서에 배정되는 규칙이 있나요?
  4. 개인정보 및 AI 실행 환경

    • 사용할 LLM은 사내 구축 모델이어야 하나요? 외부 API를 사용할 수 있다면 어떤 사업자·리전까지 허용되나요?
    • 티켓 본문에서 이름, 전화번호, 주소 등을 마스킹한 뒤 LLM에 전송하는 방식이 가능한가요?
  5. CRM 연동

    • CRM REST API가 이미 제공하는 필드와 엔드포인트가 있나요?
    • 분류 결과에 카테고리, 우선순위, 부서 외에 신뢰도, 분류 근거, 모델 버전, 처리 시각도 저장할 수 있나요?
    • 기존 담당자 분류 결과를 덮어써도 되나요, 아니면 자동 분류 전용 필드에 기록해야 하나요?
  6. 이벤트 및 재처리

    • Zendesk 신규 티켓 이벤트는 webhook으로 받을 수 있나요? 중복 이벤트와 티켓 수정 이벤트도 발생하나요?
    • 처리 실패나 CRM 기록 실패 시 재시도할 수 있고, 미처리 티켓 큐를 운영할 수 있나요?
  7. 정확도와 운영 기준

    • 현재 사람이 분류한 과거 티켓 데이터가 얼마나 있으며, 정답 데이터로 사용할 수 있나요?
    • 자동 처리 허용 기준을 정할 수 있나요? 예를 들어 신뢰도 0.9 미만이면 “검토 필요”로 보내고 담당자가 확인하도록 하는 방식입니다.
    • 목표 정확도 또는 허용 가능한 오분류율이 있나요?

답변이 없는 항목은 안전한 기본값을 적용해 설계할 수 있습니다. 기본값은 단일 카테고리, 보수적인 긴급 판정, 개인정보 마스킹, 낮은 신뢰도 자동 보류, 자동 재시도와 담당자 재배정 가능 구조로 두겠습니다.

같은 분류의 프롬프트

AI 에이전트 보안 점검 프롬프트
AI 제공자 요금 조사 프롬프트
상자 탈출 AI 역할을 맡기는 프롬프트
보안 경고 분석 프롬프트
Android AI 보안 설정 프롬프트