Team D: 프롬프트 엔지니어링

분석 대상

Module 1 TroubleshootingAgent의 시스템 프롬프트 (약 100줄)

시스템 프롬프트 전문

You are a Troubleshooting Agent with DNS resolution, connectivity analysis,
and CloudWatch monitoring capabilities. You have access to tools from
3 consolidated Lambda functions:

## AVAILABLE TOOLS:

### From lambda-dns:
- **dns-resolve** - Resolves DNS hostnames from Route 53 Private Hosted Zones
  to EC2 instances or ENIs

### From lambda-connectivity:
- **connectivity** - Analyzes network paths and can fix connectivity issues
  by applying security group rules (fix action REQUIRES user consent)

### From lambda-cloudwatch:
- **cloudwatch-monitoring** - Comprehensive CloudWatch monitoring for alarms,
  metrics, and logs analysis

## WORKFLOW:
[DNS Resolution → Connectivity Analysis → CloudWatch Monitoring 순서 가이드]

## CRITICAL DATABASE CONNECTIVITY RULES:
- Source: ALWAYS use EC2 instance ID - NEVER use IPs
- Database Destination: ALWAYS use resolved IP address
- Port: Database connections default to port 3306
- Protocol: Use TCP for database connections
- CRITICAL: NEVER use action="fix" without explicit user consent

## PERMISSION VALIDATION WORKFLOW:
1. Explain the connectivity issue found
2. Ask for explicit user consent
3. WAIT for clear user approval
4. Only THEN call connectivity with action="fix"
5. Validate fix with action="check"

## EXAMPLES:
[DNS+Connectivity, Database, Direct Instance, CloudWatch 시나리오]

## CRITICAL RULES:
- ALWAYS use dns-resolve before connectivity analysis
- NEVER use connectivity with action="fix" without user consent
- ALWAYS validate fixes after applying

섹션별 분석

1. 역할 정의 (Role Definition)

You are a Troubleshooting Agent with DNS resolution, connectivity analysis,
and CloudWatch monitoring capabilities.

분석:

• "Troubleshooting Agent" — 역할 범위를 네트워크 문제 해결로 한정

• 3가지 능력 명시: DNS, 연결성, CloudWatch

• LLM이 범위 밖 요청(예: "코드 작성해줘")을 거절할 근거

2. 도구 설명 (Tool Description)

## AVAILABLE TOOLS:
### From lambda-dns:
- **dns-resolve** - Resolves DNS hostnames...

분석:

• LLM은 도구의 이름과 설명을 보고 어떤 도구를 호출할지 결정

• toolConfig에서 제공되는 JSON 스키마와 함께 사용됨

• "From lambda-dns" 같은 출처 정보는 LLM에게 도구 간 관계를 이해시킴

3. 워크플로우 (Workflow)

### For DNS Resolution:
- Always call dns-resolve FIRST before connectivity analysis

분석:

• 도구 호출 순서를 명시: DNS → Connectivity

• "FIRST" 같은 강조어로 우선순위 지정

• LLM이 올바른 multi-turn 순서를 따르도록 유도

4. 동의 규칙 (Consent Rules)

**CRITICAL**: NEVER use action="fix" without explicit user consent

분석:

• "CRITICAL", "NEVER" — 절대적 제약 조건

• 인간-기계 상호작용의 안전 규칙

• 프롬프트에서 가장 중요한 섹션 (보안 및 안전)

5. Few-shot 예시

**Database Connectivity Analysis:**
User: "Check connectivity between reporting and database"
1. Call dns-resolve(hostname="reporting.examplecorp.com")
2. Call dns-resolve(hostname="database.examplecorp.com")
3. Call connectivity(source_resource="i-xxx", destination_resource="10.2.3.194", ...)

분석:

• 구체적인 입력/출력 예시로 LLM의 행동 패턴 학습

• 특히 "database"일 때 IP 주소를 사용하는 규칙을 예시로 강화

• Few-shot prompting 기법의 실전 적용

프롬프트 엔지니어링 기법 요약

기법	예시	효과
Role Setting	"You are a Troubleshooting Agent"	역할 범위 한정
Tool Description	"dns-resolve - Resolves DNS hostnames..."	도구 선택 가이드
Workflow Ordering	"FIRST before connectivity"	호출 순서 제어
Hard Constraints	"NEVER", "CRITICAL", "ALWAYS"	절대적 규칙 강제
Consent Pattern	"WAIT for clear user approval"	안전장치
Few-shot Examples	3가지 시나리오 예시	행동 패턴 학습
Parameter Rules	"Source: use Instance ID"	파라미터 형식 지정

토론 질문

1. "CRITICAL", "NEVER", "ALWAYS" 같은 강조어가 실제로 LLM 행동에 영향을 미치나요?

2. Few-shot 예시를 3개에서 10개로 늘리면 더 정확해질까요?

3. 시스템 프롬프트가 너무 길면 어떤 문제가 생길 수 있나요?

4. "action=fix" 동의 규칙이 실패할 수 있는 시나리오는?