AIOps 프롬프트 엔지니어링
에이전트의 동작을 결정하는 것은 코드가 아니라 시스템 프롬프트입니다. 이 가이드는 워크샵 전체 모듈의 프롬프트를 분석하고, 실전에서 활용할 수 있는 프레임워크를 제공합니다.
1. 프롬프트가 AIOps의 핵심인 이유
코드는 구조, 프롬프트는 행동을 결정합니다
이 워크샵의 모든 에이전트는 동일한 코드 구조를 공유합니다:
agent = Agent(
model=BedrockModel(model_id="..."),
system_prompt=system_prompt, # ← 여기가 동작을 결정
tools=tools,
)Agent 클래스, BedrockModel, MCPClient — 이들은 인프라입니다. 에이전트가 "DNS를 먼저 확인할지", "사용자 동의 없이 수정할지", "어떤 에이전트에게 위임할지"는 전적으로 시스템 프롬프트가 결정합니다.
같은 도구, 다른 프롬프트 → 완전히 다른 동작
Module 1의 TroubleshootingAgent와 Module 3의 Connectivity Agent는 동일한 dns-resolve와 connectivity 도구를 사용합니다. 그러나 프롬프트가 다르기 때문에 완전히 다르게 동작합니다:
도구
dns-resolve, connectivity, cloudwatch
dns-resolve, connectivity
"Fix" 요청 시
이슈 설명 → 동의 요청
도구 호출 없이 즉시 동의 요청
동의 후
도구 호출 → 수정 → 검증
DNS → 수정 → 검증 (동일)
시나리오 분기
없음 (일반 워크플로우)
3개 시나리오 (check/fix/confirm)
동의 강도
"CRITICAL: NEVER"
"ABSOLUTE RULE" + "VIOLATION FORBIDDEN"
핵심 교훈: 도구가 같아도 프롬프트에 따라 에이전트의 판단 흐름이 완전히 달라집니다.
프롬프트 → LLM → 도구 호출 결정 흐름
시스템 프롬프트는 위 흐름의 모든 분기점을 제어합니다. 워크플로우 순서, 제약 조건 판단, 라우팅 결정 — 모두 프롬프트에 명시된 규칙을 따릅니다.
2. 모듈별 핵심 프롬프트 결정
각 모듈에서 "왜 이 프롬프트 결정이 중요했는지"를 분석합니다.
각 모듈의 프롬프트 전문 분석은 해당 모듈의 Code Deep Dive를 참조하세요:
Module 1: 도구 사용의 기본
핵심 프롬프트 결정 4가지:
1) 역할 정의로 범위 한정
"Troubleshooting Agent"라는 역할 정의가 에이전트의 동작 범위를 한정합니다. "AWS 전문가"나 "클라우드 엔지니어"처럼 넓은 범위를 지정하면 LLM이 도구와 무관한 답변을 생성할 수 있습니다.
2) 파라미터 규칙으로 도구 오사용 방지
LLM은 DNS 해석 결과에서 instance ID, IP, ENI ID를 모두 받습니다. 어떤 값을 어떤 파라미터에 넣을지 명시하지 않으면 잘못된 조합으로 도구를 호출합니다. ALWAYS/NEVER 키워드가 파라미터 선택을 강제합니다.
3) 워크플로우 순서 강제
FIRST 키워드로 DNS → Connectivity 순서를 강제합니다. 이 규칙이 없으면 LLM이 hostname을 직접 connectivity 도구에 전달하여 실패합니다.
4) 동의 규칙 — 가장 중요한 안전장치
이 한 줄이 에이전트가 사용자 동의 없이 AWS 보안 그룹을 수정하는 것을 방지합니다. AIOps에서 자동 수정은 편리하지만, 동의 없는 수정은 보안 사고로 이어질 수 있습니다.
5) Few-shot 예시로 행동 패턴 학습
Module 1은 4가지 시나리오 예시를 포함합니다: DNS+Connectivity, Database, Direct Instance, CloudWatch. 각 예시는 도구 호출 순서와 파라미터 조합을 구체적으로 보여줍니다.
Module 2: 메모리와 프롬프트의 결합
Module 2의 핵심 혁신은 동적 프롬프트 주입입니다. 시스템 프롬프트가 고정이 아니라 매 턴마다 메모리 컨텍스트가 추가됩니다.
메모리 주입 메커니즘:
event.agent.system_prompt += — 이 한 줄이 Module 1과 Module 2의 차이입니다. 에이전트 코드(agent.py)는 변경 없이 hooks=[memory_hook]만 추가하면 됩니다.
전략별 프롬프트 규칙:
Semantic Memory
"Use the EXACT information from memory"
정확한 사실 인용 필요
User Preference
"Use stored SOP procedures"
사용자 맞춤 정보
Custom Memory
"Use the EXACT procedures and historical context"
절차 정확성
Summary Memory
"FORBIDDEN: Do NOT call dns-resolve, connectivity"
중복 분석 방지
FORBIDDEN 패턴 — Summary Memory의 도구 차단:
Summary Memory가 활성화되면 이전 세션의 분석 결과가 이미 있습니다. 같은 분석을 반복하면 시간 낭비이고, 불필요한 API 호출이 발생합니다. FORBIDDEN 키워드로 도구 사용을 완전히 차단합니다.
프롬프트 누적 효과:
초기화 (agent.py)
~3,000자
on_agent_initialized
+~1,500자 (메모리 규칙 + 세션 컨텍스트)
첫 번째 메시지
+~500자 (전략별 컨텍스트)
두 번째 메시지
+~500자 (추가 컨텍스트)
N번째 메시지
~3,000 + 1,500 + (N × 500)자
프롬프트가 누적되면 LLM의 컨텍스트 윈도우를 소비합니다. 장기 대화에서는 메모리 컨텍스트 크기를 제한하는 전략이 필요합니다.
Module 3: 멀티에이전트 프롬프트
Module 3에서는 3개의 에이전트가 각각 다른 프롬프트를 가집니다. 여기서 핵심은 프롬프트 간의 계약입니다.
Host Agent: 키워드 기반 라우팅
Connectivity Agent: 시나리오 분기 (check/fix/confirm)
Module 3의 Connectivity Agent는 Module 1보다 프롬프트가 정교합니다. 3개의 명시적 시나리오로 분기합니다:
이 시나리오 기반 설계가 중요한 이유는, LLM이 "check"와 "fix"를 혼동하지 않도록 명시적 분기점을 제공하기 때문입니다.
Performance Agent: "NEVER ask" 자동 실행 패턴
Connectivity Agent와 정반대 접근입니다. Performance 분석은 읽기 전용 작업이므로 동의가 불필요합니다. 매번 리전과 계정 ID를 묻는 것은 사용자 경험을 해칩니다. NEVER ask + IMMEDIATELY proceed 조합이 자동 실행을 강제합니다.
결과 전달: "Do NOT summarize"
Host Agent 프롬프트에는 결과 전달에 대한 명시적 규칙이 있습니다:
멀티에이전트에서 흔한 문제가 중간 에이전트(Host)가 결과를 요약하면서 중요한 세부사항을 빠뜨리는 것입니다. Do NOT summarize로 완전한 릴레이를 강제합니다.
Module 4: AWS 관리형 AI
Module 4(CloudWatch Investigations)는 코드가 없는 모듈입니다. AWS 콘솔에서 Investigation Group을 생성하고, 자연어로 조사를 시작합니다.
프롬프트 활용 포인트:
Investigation 시작 시 컨텍스트 메모를 통해 조사 범위를 한정
Q Chat에서 자연어 프롬프트로 근본 원인 분석 요청
코드 없이도 프롬프트 설계 원칙이 동일하게 적용됨
3. AIOps 프롬프트 5계층 프레임워크
워크샵 코드를 분석하면 효과적인 AIOps 프롬프트는 5개 계층으로 구성됩니다:
1층: 역할 정의 (Role Definition)
에이전트의 전문 영역과 범위를 한정합니다.
M1 Troubleshooting
"Troubleshooting Agent with DNS, connectivity, CloudWatch"
3개 도메인으로 한정
M3 Connectivity
"Troubleshooting Agent with DNS and connectivity"
2개 도메인으로 한정
M3 Performance
"NetOps Performance Analysis AI assistant"
성능 분석만
M3 Host
"Lead NetOps Orchestrator"
라우팅만, 직접 분석 안 함
2층: 도구 설명 (Tool Description)
각 도구의 파라미터, 용도, 제약사항을 설명합니다.
핵심: 파라미터의 타입과 용도를 구체적으로 명시합니다. "source_resource"에 무엇을 넣어야 하는지(instance ID vs IP vs ENI)까지 기술해야 합니다.
3층: 워크플로우 (Workflow)
도구 호출의 순서와 조건부 분기를 정의합니다.
핵심: FIRST, THEN, IF...THEN 키워드로 순서와 조건을 명시합니다.
4층: 제약 조건 (Constraints)
절대 해서는 안 되는 것과 반드시 해야 하는 것을 정의합니다.
CRITICAL
반드시 준수
"CRITICAL: NEVER use action='fix' without consent"
NEVER
절대 금지
"NEVER ask users for region or account ID"
ALWAYS
항상 수행
"ALWAYS validate fixes by calling action='check'"
FORBIDDEN
완전 차단
"FORBIDDEN: Do NOT call dns-resolve" (Summary Memory)
ABSOLUTE RULE
최고 강도
M3 동의 규칙에서 사용
MANDATORY
필수
"user consent is MANDATORY"
제약 조건 강도 스펙트럼:
5층: 예시 (Examples)
Few-shot 예시로 구체적인 행동 패턴을 학습시킵니다.
핵심: 예시에는 구체적인 값(instance ID, IP 등)을 포함하여 패턴을 명확히 합니다.
프롬프트 기법 종합 비교표
Role Setting
O
O
O
O
O
범위 한정으로 불필요한 응답 방지
Tool Description
O
O
O
O
X
파라미터 오사용 방지
Workflow Ordering
O
O
O
O
O
도구 호출 순서 보장
Hard Constraints
O
O
OO
O
O
안전장치, 동의 규칙
Few-shot Examples
O
X
O
X
O
구체적 행동 패턴 학습
Dynamic Injection
X
O
X
X
O
런타임 컨텍스트 반영
Memory Override
X
O
X
X
X
메모리 전략별 동작 변경
Scenario Branching
X
X
O
X
X
요청 유형별 분기 처리
(O: 사용, OO: 강화 사용, X: 미사용)
모듈간 상세 프롬프트 비교는 시스템 프롬프트 비교 분석을 참조하세요.
4. Kiro로 프롬프트 빠르게 작성하기
Kiro Spec → 프롬프트 매핑
Kiro의 3단계 Spec 워크플로우는 프롬프트의 5계층과 자연스럽게 매핑됩니다:
Requirements Spec
1층 역할 + 4층 제약조건
에이전트 역할, 도구 목록, 필수 규칙
Design Spec
2층 도구 + 3층 워크플로우
프롬프트 전체 구조, 파라미터 스키마
Task List
5층 예시 + 검증
테스트 시나리오, 반복 개선
실전 예시: 새 도구 추가 시 프롬프트 확장
기존 TroubleshootingAgent에 Cost Explorer 도구를 추가하는 상황을 예시로 들겠습니다.
Step 1: Kiro /spec으로 Requirements 생성
Kiro가 Requirements를 생성하면, 1층(역할)과 4층(제약조건)이 정의됩니다.
Step 2: Design Spec에서 프롬프트 구조 생성
Kiro가 2층(도구 설명)과 3층(워크플로우)을 자동으로 생성합니다.
Step 3: Task List에서 검증 및 반복
프롬프트 반복 개선 패턴
1차 (Kiro 생성): 기본 역할, 도구 설명, 워크플로우가 포함된 프롬프트를 생성합니다. 이 단계에서는 약 70%의 완성도를 기대합니다.
2차 (테스트): 실제 에이전트에 프롬프트를 적용하고 테스트합니다. 일반적인 실패:
도구 호출 순서 오류
잘못된 파라미터 전달
동의 없이 수정 실행
3차 (Few-shot 추가): 실패한 케이스를 그대로 EXAMPLES 섹션에 추가합니다. 이것이 이 워크샵에서 M1의 4가지 시나리오가 존재하는 이유입니다.
4차 (제약 강화): 여전히 실패하는 경우 CRITICAL, NEVER, ABSOLUTE RULE 등의 강한 키워드를 추가합니다. M3 Connectivity Agent의 VIOLATION IS STRICTLY FORBIDDEN이 이 단계의 결과물입니다.
Kiro Spec 프롬프트 템플릿
아래 템플릿을 Kiro에서 사용하면 AIOps 에이전트의 프롬프트를 체계적으로 생성할 수 있습니다.
Requirements Spec 템플릿:
Design Spec 템플릿:
Task List 템플릿:
Kiro의 에이전트 빌드 전체 워크플로우에 대해서는 Kiro & Claude Code 프롬프트 가이드를 참조하세요.
5. 자주 발생하는 프롬프트 문제와 해결
에이전트가 도구를 호출하지 않음
역할 정의가 너무 넓거나 도구 설명 부족
2층(도구 설명)에 파라미터와 용도를 상세히 기술
잘못된 파라미터로 도구 호출
파라미터 매핑 규칙 미비
"Source: ALWAYS use instance ID, Destination: ALWAYS use IP" 형태로 명시
동의 없이 수정 실행
제약 조건 강도 부족
CRITICAL → ABSOLUTE RULE → VIOLATION FORBIDDEN 순으로 강화
DNS 해석 없이 connectivity 호출
워크플로우 순서 미명시
"FIRST call dns-resolve BEFORE connectivity" 추가
메모리가 있는데 도구를 다시 호출
Summary Memory 규칙 미비
"FORBIDDEN: Do NOT call analysis tools" 추가
멀티에이전트에서 결과 요약
Host Agent의 전달 규칙 미비
"Do NOT summarize - relay in full detail" 추가
매번 리전/계정 ID를 질문
자동 실행 규칙 미비
"NEVER ask users for region" + "IMMEDIATELY proceed" 추가
에이전트가 도구를 과다 호출
워크플로우가 무한 루프 가능
명시적 종료 조건 추가 ("After applying fix, validate ONCE")
토론 질문
동의 규칙의 강도: M1은
CRITICAL: NEVER, M3은ABSOLUTE RULE+VIOLATION FORBIDDEN을 사용합니다. 왜 M3에서 더 강한 표현이 필요했을까요? 에이전트가 단독으로 동작할 때와 멀티에이전트 시스템에서 동작할 때 동의 규칙의 중요성이 어떻게 달라지나요?자동 실행 vs 동의 요청: Performance Agent는
NEVER ask, Connectivity Agent는ALWAYS ask입니다. 어떤 기준으로 자동 실행과 동의 요청을 결정해야 할까요? 새로운 도구를 추가할 때 이 결정을 어떻게 내리시겠습니까?메모리와 프롬프트의 상호작용: Summary Memory가 활성화되면 도구 사용이
FORBIDDEN됩니다. 이 설계가 아닌 "메모리 결과와 새 분석을 비교"하는 접근은 어떨까요? 각 접근의 장단점은 무엇인가요?프롬프트 누적의 한계: Module 2에서 매 턴마다 ~500자가 추가됩니다. 100턴 대화에서는 시스템 프롬프트가 ~53,000자가 됩니다. 이 문제를 어떻게 해결할 수 있을까요? 프롬프트 압축, 슬라이딩 윈도우, 또는 다른 전략이 있을까요?
프롬프트 테스트 자동화: 현재는 수동으로 테스트하고 실패 케이스를 Few-shot으로 추가합니다. 프롬프트의 동작을 자동으로 검증하는 테스트 프레임워크를 설계한다면 어떤 구조가 될까요?
마지막 업데이트