curiositech/windags-skills

자동 상태 저장 프롬프트 개선기

결정 포인트

프롬프트 평가:
├── 간단한 질문/명령 (무엇, 언제, 어떻게)
│   └── 최적화 건너뛰기 → 직접 답변
├── 복잡한 작업 (멀티스텝, 추론, 기술적)
│   ├── 토큰 예산 < 1000
│   │   └── APE: 3-5회 반복
│   ├── 토큰 예산 1000-5000
│   │   └── OPRO: 5-10회 반복
│   └── 토큰 예산 > 5000
│       └── DSPy 컴파일: 10-20회 반복
└── 재사용 가능한 템플릿/시스템 프롬프트
    └── 기록 검색을 통한 전체 최적화

최적화 기법 선택:
├── 지침 재작성 필요
│   └── APE 사용 (자동 프롬프트 엔지니어)
├── 제약 조건이 있는 매개변수 튜닝
│   └── OPRO 사용 (프롬프트 기반 최적화)
├── 여러 모듈이 있는 복잡한 파이프라인
│   └── DSPy 컴파일 패턴 사용
└── 알 수 없거나 탐색적 도메인
    └── 하이브리드 APE→OPRO→DSPy 캐스케이드

반복 제어:
├── 3라운드 연속 개선율 < 1% → 중단
├── 품질 점수 > 0.95 → 중단
├── 최대 반복 횟수 도달 → 중단
├── 사용자 만족 확인 → 중단
└── 계속 → 다음 반복

피드백 통합:
├── 작업 성공 (사용자 확인/지표 양호)
│   └── 긍정 피드백 기록 + 검색용 임베딩
├── 작업 실패/낮은 품질
│   └── 부정 피드백 기록 + 실패 모드 분석
└── 결과 불명확
    └── 기록 전 사용자에게 명시적 피드백 요청

실패 모드

과최적화 나선

• 증상: 프롬프트가 500+ 토큰으로 증가하며 중첩된 제약 조건이 많음
• 진단: '충분히 좋은' 수준에서 멈추지 않고 미미한 개선을 추구
• 해결: 80/20 규칙 적용 - 반복당 개선율이 5% 미만이면 중단

템플릿 집착

• 증상: 작업 명확성 대신 형식/구조에 반복을 소비
• 진단: 프레젠테이션과 성능을 혼동
• 해결: 템플릿 일치도가 아닌 실제 작업 성공 측정

기록 과적합

• 증상: 최적화된 프롬프트가 과거 예제에서는 잘 작동하지만 새 입력에서는 실패
• 진단: 검색된 너무 좁은 데이터셋으로 훈련
• 해결: 최적화에 다양한 예제 포함, 보류 사례 테스트

능력 오판

• 증상: 모델이 기본적으로 처리하는 작업에 과도한 스캐폴딩 추가
• 진단: 테스트 없이 모델 한계 가정
• 해결: 과중한 프롬프팅 전에 기본 능력 테스트

측정 맹목

• 증상: 명확한 성공 지표 없이 여러 번 반복
• 진단: '더 나은' 것이 무엇인지 모르고 최적화
• 해결: 첫 단계에서 측정 가능한 성공 기준 정의

작업 예제

예제 1: 코드 최적화 요청

원본: "이 코드를 더 좋게 만들어"

def process_data(data):
    results = []
    for item in data:
        if item > 0:
            results.append(item * 2)
    return results

결정 포인트 탐색:

1. 평가: 복잡한 작업 (코드 분석 필요) → 최적화 트리거
2. 기법 선택: 코드 리뷰 + 개선 → APE 5회 반복
3. 검색된 컨텍스트: 기록에서 유사한 코드 최적화 프롬프트
4. 최적화된 프롬프트: "이 Python 함수를 성능, 가독성, Pythonic 패턴 측면에서 분석하십시오. 알고리즘 복잡성, 메모리 사용, 엣지 케이스, 스타일 등 구체적인 개선 사항을 식별하십시오. 설명과 함께 리팩토링된 코드를 제공하십시오."

초보자가 놓치는 점: 모호한 "더 좋게"는 기준을 명시하지 않음 전문가가 파악하는 점: 명시적인 차원 (성능, 스타일, 엣지 케이스) 필요

결과: 리스트 컴프리헨션 기회, 엣지 케이스 처리, 타입 힌트에 대한 명확한 분석

예제 2: 추론 작업 템플릿

원본: "이 결정을 생각하는 데 도와줘"

결정 포인트 탐색:

1. 평가: 재사용 가능 템플릿 + 추론 작업 → 전체 최적화
2. 기록 검색: 의사 결정 프레임워크 프롬프트 발견 (유사도 0.87)
3. 기법 선택: DSPy 컴파일 (구조화된 추론 파이프라인)
4. 반복 전략: 10라운드, 결정 품질 측정

최적화된 템플릿:

의사 결정 분석 프레임워크:
1. 상황: 제약 조건과 함께 결정을 명확히 기술
2. 이해관계자: 영향을 받는 당사자와 그들의 이익을 나열
3. 옵션: 3-5개의 뚜렷한 대안 생성
4. 기준: 성공 지표와 가중치 정의
5. 트레이드오프: 각 옵션을 기준에 따라 분석
6. 권장: 신뢰 수준과 함께 최선의 옵션 선택

적용된 품질 게이트: 템플릿 완전성, 재사용성 점수, 사용자 만족도

예제 3: 모호한 기술 요청

원본: "모니터링 설정해"

결정 포인트 탐색:

1. 평가: 불완전 명세 + 기술적 → 최적화 트리거
2. 명확화 전략: 제약 조건 도출을 통한 OPRO
3. 도메인 컨텍스트: 검색된 모니터링 설정 패턴

최적화된 프롬프트: "다음을 지정하여 모니터링 설정을 설계하십시오: (1) 인프라 범위 (서버, 컨테이너, 애플리케이션), (2) 주요 지표 (성능, 가용성, 비즈니스), (3) 알림 임계값 및 에스컬레이션, (4) 기술 스택 제약 조건, (5) 예산/복잡성 한도. 우선순위와 함께 구현 로드맵을 제공하십시오."

전후 트레이드오프:

• 이전: 끝없는 설명 요청 왕복
• 이후: 단일 교환 내 구조화된 요구사항 수집
• 비용: 더 긴 초기 프롬프트
• 이점: 한 라운드에 완전한 명세

품질 게이트

optimize_prompt 호출 전 체크리스트:

• 작업 복잡성 점수 > 3 (멀티스텝/추론 필요)
• 명확한 성공 기준 정의 또는 도출 가능
• 토큰 예산 추정 및 기법 선택
• 검색을 위한 도메인 컨텍스트 식별
• 복잡성에 기반한 반복 한도 설정

최적화 후 검증:

• 최적화된 프롬프트가 구체적이고 실행 가능
• 성공 지표가 측정 가능
• 제약 조건 일관성 확인 (모순 없음)
• 토큰 효율성: 개선이 추가 길이를 정당화
• 기록 컨텍스트가 적절히 통합됨
• 주요 변경 사항에 대한 사용자 확인 획득

품질 평가 점수 (0-100):

• 명확성: 일반 사용자가 요구 사항을 이해할 수 있는가? (25점)
• 구체성: 구체적 vs 추상적 지침? (25점)
• 완전성: 엣지 케이스와 제약 조건을 다루는가? (25점)
• 효율성: 부풀림 없이 목표를 달성하는가? (25점)

사용 금지 경계

이 기술을 다음에 사용하지 마십시오:

• 간단한 사실 질문 → 지식으로 직접 답변
• 추론 없는 파일 작업 → 파일 관리 기술 사용
• 직접 명령 실행 → 즉시 실행
• 대화형 응답 → 자연스럽게 응답
• 이미 최적화된 프롬프트 → 먼저 기록 확인하여 재최적화 방지
• 사용자가 '최적화하지 마세요'라고 명시 → 사용자 선호 존중

대신 위임:

• 수학 문제 → 계산 중심 기술 사용
• 창의적 글쓰기 → 창의적 글쓰기 기술 사용 (템플릿 생성 제외)
• 데이터 분석 → 데이터 분석 기술 사용 (복잡한 추론 필요 제외)
• 디버깅 → 디버깅 기술 사용 (체계적 개선 필요 제외)

판단이 필요한 회색 영역:

• 중간 복잡성 작업 (점수 2-4) → 먼저 기본 성능 테스트
• 도메인 전문성 요청 → 재사용 가능 템플릿 가능성이 있는 경우에만 최적화
• 후속 질문 → 범위를 크게 확장하는 경우에만 최적화