# SEF-2026 사용 프롬프트 예시집 > 작성일: 2026-03-27 --- ## 이 문서를 읽기 전에 이 문서의 예시들은 참고용 시작점일 뿐, 정해진 형식이 아닙니다. 스킬(SKILL.md)은 Claude에게 "이렇게 처리하라"는 지시이지, 사용자를 가두는 틀이 아닙니다. LLM의 강점은 자연어를 자유롭게 이해하는 것에 있습니다. 형식에 얽매이지 말고 하고 싶은 말을 자연스럽게 표현하세요. 같은 요청도 맥락, 부연 설명, 제약 조건을 자유롭게 추가할수록 더 좋은 결과를 얻을 수 있습니다. "이렇게만 써야 한다"가 아니라 "이런 것도 된다"를 보여주는 문서입니다. 모든 스킬은 `/명령어 자연어` 형식으로 호출합니다. 옵션(--flag)은 자연어로 전달할 수 있습니다. --- ## A. 초기 설정 (/sef-setup) ### A1. 첫 프로젝트 설정 **상황**: 새 에너지 관리 프로젝트에 플러그인을 처음 적용할 때 **프롬프트**: ``` /sef-setup ``` **실행 흐름**: VCS 감지 → sector 선택 → 도구 확인 → 인증 → 빌드/테스트 설정 → 완료 요약 --- ### A2. 공공 프로젝트 재설정 **상황**: sector를 민간에서 공공으로 변경하고 싶을 때 (예: 공공 에너지 관리 시스템) **프롬프트**: ``` /sef-setup ``` **실행 흐름**: `/sef-setup` 실행 후 sector 선택 단계에서 "공공" 선택 → 공공 표준 패턴(eGovFrame, MyBatis, WAR 배포) 기준으로 재구성 --- ## B. 전체 개발 사이클 (/sef-dev) ### B1. 에너지 모니터링 대시보드 개발 (전체 파이프라인) **상황**: 공공 프로젝트에서 발전량 모니터링 대시보드를 처음부터 개발 **프롬프트**: ``` /sef-dev 에너지 모니터링 대시보드 개발해줘. 실시간 발전량, 누적 발전량, 설비별 가동 현황 카드, 일별 발전량 차트가 필요해. ``` **실행 흐름**: 모드 선택 질문 → "전체 파이프라인" 선택 → PO가 Q&A → architect 설계 → coder 구현 → 리뷰 → 커밋/PR --- ### B2. 발전설비 관리 REST API 개발 (민간) **상황**: 민간 프로젝트에서 발전설비 관리 API 개발 **프롬프트**: ``` /sef-dev 발전설비 관리 REST API 개발해줘. 설비 유형별 필터링, 설치일 범위 검색, 가동률 집계가 필요해. ``` **실행 흐름**: 전체 파이프라인 → sector=private 감지 → JPA Entity + Repository → Redis 캐싱 검토 → RESTful Controller 생성 --- ### B3. 프론트+백엔드 동시 개발 (사이트 관리) **상황**: 발전소 사이트 관리 화면과 API를 함께 개발 **프롬프트**: ``` /sef-dev 발전소 사이트 관리 CRUD 추가해줘. 백엔드 API랑 프론트엔드 화면 모두 필요해. 사이트별 계약 전력, 설치 용량 정보 포함해줘. ``` **실행 흐름**: 전체 파이프라인 → backend-builder + frontend-builder 병렬 실행 → 통합 검증 → 커밋/PR --- ### B4. 특정 브랜치 기반 작업 **상황**: develop 브랜치에서 분기하여 발전 데이터 집계 기능 개발 **프롬프트**: ``` /sef-dev develop 브랜치 기반으로 월별 발전량 집계 기능 개발해줘 ``` **실행 흐름**: develop 브랜치에서 feature 브랜치 생성 → 전체 파이프라인 실행 → develop 대상 PR 생성 --- ### B5. 긴급 버그 수정 — 계량 데이터 수집 오류 **상황**: 계량 데이터 수집 배치가 특정 사이트에서 오류 발생 **프롬프트**: ``` /sef-dev 계량 데이터 수집 배치 오류 긴급 수정해줘. 특정 인버터에서 null 데이터가 들어올 때 NPE 발생해. ``` **실행 흐름**: HOTFIX 모드 자동 감지 → 경량 PRD → 구현 → 인수검증 → 커밋/PR --- ### B6. 긴급 수정 — 자연어 트리거 **상황**: 발전량 API 응답이 갑자기 0을 반환하는 버그 **프롬프트**: ``` /sef-dev 발전량 집계 API가 0 반환하는 거 빨리 고쳐줘 ``` **실행 흐름**: "빨리 고쳐" 키워드로 HOTFIX 자동 감지 → 최소 PRD → 즉시 구현 → 검증 --- ### B7. 구현만 실행 **상황**: 설비 이상 알림 기능의 설계가 이미 끝나서 코드만 작성하면 됨 **프롬프트**: ``` /sef-dev 구현만 해줘. 설계는 이미 끝났어. ``` **실행 흐름**: IMPLEMENT 모드 → setup → implement → complete (PRD/설계 단계 스킵) --- ### B8. 설계만 실행 — 전력 요금 정산 아키텍처 **상황**: 전력 요금 정산 모듈의 코드 작성 전에 아키텍처 설계서만 먼저 받고 싶을 때 **프롬프트**: ``` /sef-dev 설계만 해줘. 전력 요금 정산 모듈 아키텍처를 잡아줘. 계시별 요금제, 수요 반응 할인, 초과 전력 위약금 로직 포함해야 해. ``` **실행 흐름**: DESIGN 모드 → architect 에이전트 투입 → 설계 문서 생성 → 사용자 확인 → 구현은 별도 요청 --- ### B9. PRD만 작성 — 설비 관리 시스템 **상황**: 발전설비 관리 시스템 요구사항 정리만 하고 싶을 때 **프롬프트**: ``` /sef-dev PRD만 작성해줘. 인버터, 접속반, 모듈 등 발전설비 유지보수 관리 시스템에 대한 요구사항이야. ``` **실행 흐름**: PRD 모드 → PO 에이전트 Q&A → 요구사항 문서 생성 → context/에 저장 --- ### B10. 진행 상태 확인 **상황**: 현재 개발 파이프라인이 어디까지 진행됐는지 확인 **프롬프트**: ``` /sef-dev 지금 어디까지 됐어? ``` **실행 흐름**: 현재 세션 상태 조회 → 완료/진행 중/대기 단계 요약 출력 --- ### B11. 이전 작업 이어서 하기 **상황**: 계량 데이터 API 작업이 중단됐다가 재개 **프롬프트**: ``` /sef-dev 아까 하던 작업 이어서 해줘 ``` **실행 흐름**: 마지막 체크포인트 복원 → 중단 시점부터 파이프라인 재개 --- ### B12. Q&A 루프 응답 예시 (에너지 도메인) **상황**: `/sef-dev` 실행 중 PO 에이전트가 요구사항을 질문할 때 답변하는 방법 **PO 질문 예시**: - "계량 데이터 수집 주기는 몇 분 간격인가요?" - "발전소 사이트당 인버터 최대 몇 대까지 등록 가능한가요?" - "관리자와 현장 운영자의 권한 차이가 있나요?" - "발전량 단위는 kWh인가요, MWh인가요?" **답변 예시**: - "15분 단위로 수집해요. 실시간 모니터링은 1분 단위 폴링도 지원해야 해요." - "사이트당 최대 100대까지 등록 가능해야 해요." - "맞아요. 현장 운영자는 조회와 유지보수 요청만 가능하고, 관리자는 설비 등록/삭제까지 할 수 있어요." - "kWh로 수집하고, 대시보드에서 MWh로 변환 표시해줘요." **실행 흐름**: 답변 완료 후 PO가 요구사항 문서 생성 → architect 설계 단계로 자동 진행 --- ### B13. 기존 코드에 기능 추가 — 알림 기능 추가 **상황**: 이미 완성된 발전설비 관리 API에 이상 감지 알림 기능을 추가 **프롬프트**: ``` /sef-dev 기존 발전설비 관리 모듈에 이상 감지 알림 기능 추가해줘. 발전량이 예측치의 70% 이하로 떨어지면 관리자에게 이메일/SMS 발송해야 해. ``` **실행 흐름**: 기존 코드 분석 → 알림 트리거 조건 설계 → 알림 서비스 레이어 추가 → 기존 API에 훅 연결 → 테스트 코드 추가 --- ### B14. 리팩토링 요청 — 코드 정리 **상황**: 계량 데이터 처리 로직이 Service에 뭉쳐 있어서 분리가 필요 **프롬프트**: ``` /sef-dev MeteringDataService 리팩토링해줘. 데이터 수집, 집계, 보정 로직이 한 클래스에 다 몰려 있어서 분리해줘. 단일 책임 원칙 맞춰서. ``` **실행 흐름**: 기존 코드 분석 → 책임 분리 설계 → DataCollector / DataAggregator / DataCorrector로 분리 → 기존 테스트 통과 확인 --- ### B15. 다른 사람 코드 이해 + 수정 **상황**: 전임자가 만든 전력 단가 계산 로직을 이해하고 수정해야 함 **프롬프트**: ``` /sef-dev ElectricityTariffCalculator.java 이 클래스 이해하고, 여기에 피크 시간대 할증 요금 로직 추가해줘. 코드가 어떻게 동작하는지 먼저 설명해줘. ``` **실행 흐름**: 코드 분석 → 동작 원리 설명 → 수정 지점 식별 → 피크 할증 로직 추가 → 기존 테스트 유지 확인 --- ## C. 커밋 & PR ### C1. 기본 커밋 **상황**: 계량 데이터 API 작업 완료 후 커밋 **프롬프트**: ``` /sef-commit ``` **실행 흐름**: 변경 파일 확인 → 빌드 검증 → 브랜치명에서 타입 파싱 → 커밋 메시지 자동 생성 → 커밋 --- ### C2. 메시지 지정 커밋 **상황**: 커밋 메시지를 직접 지정 **프롬프트**: ``` /sef-commit 발전설비 이상 감지 임계값 설정 기능 추가 ``` **실행 흐름**: 지정 메시지로 Conventional Commits 형식 변환 → 빌드 검증 → 커밋 --- ### C3. 기본 PR 생성 **상황**: 커밋 후 PR 생성 **프롬프트**: ``` /sef-pull-request ``` **실행 흐름**: 커밋 히스토리 분석 → 제목/본문 자동 생성 → push → PR 생성 --- ### C4. 베이스 브랜치 지정 PR **상황**: develop 브랜치를 대상으로 PR **프롬프트**: ``` /sef-pull-request develop ``` **실행 흐름**: develop 브랜치 대상으로 PR 생성 → PR 본문에 변경 요약 자동 포함 --- ### C5. 커밋 후 바로 PR (체이닝) **상황**: 커밋과 PR을 한 번에 **프롬프트**: ``` 커밋하고 PR 올려줘 ``` **실행 흐름**: `/sef-commit` 완료 → `/sef-pull-request` 자동 실행 → PR URL 반환 --- ## D. 도메인 컨텍스트 관리 ### D1. 코드베이스 스캔으로 자동 생성 **상황**: `context/` 디렉토리가 없는 신규 에너지 관리 프로젝트 **프롬프트**: ``` /sef-context ``` **실행 흐름**: 코드베이스 분석 → 도메인 자동 감지 → 초안 생성 → 사용자 확인 → `context/` 디렉토리에 저장 --- ### D2. 에너지 분석 도메인 등록 **상황**: 전력 사용량 분석 도메인을 새로 등록 **프롬프트**: ``` /sef-context 전력 사용량 분석 도메인 등록해줘 ``` **실행 흐름**: Q&A 5개 질문 → 답변 품질 판단 → 문서 생성 (README, PROJECTS, glossary, architecture, status) --- ### D3. 문서 기반 — 발전소 운영 요구사항 파일 기반 **상황**: 현장 담당자가 정리한 발전소 운영 요구사항 파일로 도메인 생성 **프롬프트**: ``` /sef-context 발전소 운영 도메인 docs/plant-operation-req.md 기반으로 만들어줘 ``` **실행 흐름**: 파일 분석 → 내용 추출 → 검증 질문 → 문서 생성 → `context/plant-operation/` 저장 --- ### D4. 기존 도메인 갱신 — 전력 단가 용어 추가 **상황**: 전력 요금 도메인에 계시별 요금제 관련 용어를 추가 **프롬프트**: ``` /sef-context 전력 요금 도메인 용어 추가해줘. 계시별 요금제, 경부하, 중간부하, 최대부하 용어 넣어줘. ``` **실행 흐름**: 기존 glossary 로드 → 추가 용어 Q&A → `context/electricity-tariff/glossary.md` 갱신 --- ### D5. Git 히스토리 동기화 **상황**: `/sef-dev` 없이 직접 개발한 계량 데이터 수집 기능을 `status.md`에 반영 **프롬프트**: ``` /sef-context 계량 데이터 도메인 동기화해줘 ``` **실행 흐름**: `git log` / PR 분석 → `status.md`의 미반영 항목 매칭 → 사용자 확인 → 갱신 --- ## E. 백엔드 생성 ### E1. 공공 — 유지보수 요청 API **상황**: 공공 프로젝트에서 발전설비 유지보수 요청 백엔드 생성 **프롬프트**: ``` /sef-backend-builder 유지보수 요청 관리 API 만들어줘 ``` **실행 흐름**: sector=public 감지 → Controller(GET/POST only) → Service(interface+Impl) → Mapper → MyBatis XML → DTO 생성 --- ### E2. 민간 — 발전설비 관리 REST API **상황**: 민간 프로젝트에서 발전설비 CRUD API 생성 **프롬프트**: ``` /sef-backend-builder 발전설비 관리 REST API 만들어줘 ``` **실행 흐름**: sector=private 감지 → Controller(RESTful) → Service → Repository(JPA) → Entity → DTO + Redis 캐싱 검토 --- ### E3. 검색 포함 — 발전 데이터 조회 API **상황**: 기간/사이트/설비 조건이 포함된 발전 데이터 목록 API **프롬프트**: ``` /sef-backend-builder 발전 데이터 조회 API 만들어줘. 사이트, 설비, 기간 범위로 검색 가능해야 해. ``` **실행 흐름**: 검색 조건 DTO 설계 → 공공: MyBatis dynamic SQL / 민간: QueryDSL Predicate → 페이지네이션 포함 --- ### E4. 특정 레이어만 — Entity와 Repository만 **상황**: 계량 데이터 도메인 Entity와 Repository만 필요 **프롬프트**: ``` /sef-backend-builder 계량 데이터 도메인 Entity와 Repository만 만들어줘 ``` **실행 흐름**: 레이어 범위 파싱 → Entity + Repository만 선택 생성 → 나머지 레이어 스킵 --- ## F. 프론트엔드 생성 ### F1. 마크업 — 발전량 모니터링 대시보드 **상황**: 실시간 발전량 모니터링 대시보드 레이아웃만 필요 **프롬프트**: ``` /sef-frontend-builder 발전량 모니터링 대시보드 마크업 짜줘. 실시간 발전량 카드, 오늘 누적 발전량 카드, 설비 가동률 카드, 일별 발전량 차트 영역 필요해. ``` **실행 흐름**: Markup 모드 → 그리드 레이아웃 설계 → shadcn-vue Card + Chart 마크업 → 스타일만 포함 (API 연동 없음) --- ### F2. 마크업 — 설비 현황 화면 **상황**: 발전설비 목록 정적 레이아웃만 필요 **프롬프트**: ``` /sef-frontend-builder 발전설비 현황 목록 페이지 마크업 만들어줘 ``` **실행 흐름**: Markup 모드 → shadcn-vue Table + Pagination 마크업 생성 (API 연동 로직 없음) --- ### F3. Full — 발전설비 등록 폼 **상황**: 발전설비 등록 폼 전체 구현 (유효성 검사 포함) **프롬프트**: ``` /sef-frontend-builder 발전설비 등록 폼 컴포넌트 만들어줘. API 연동까지 포함해줘. 설비 유형, 설치일, 정격 용량, 소속 사이트 필드가 필요해. ``` **실행 흐름**: Full 모드 → vee-validate + Zod 스키마 → API composable → toast 알림 → 에러 핸들링 --- ### F4. Full — 계량 데이터 테이블 **상황**: 계량 데이터 CRUD 테이블 전체 구현 **프롬프트**: ``` /sef-frontend-builder 계량 데이터 조회 테이블 컴포넌트 만들어줘. 기간 검색, 페이지네이션, CSV 내보내기 버튼 포함. ``` **실행 흐름**: Full 모드 → 검색 필터 composable → 페이지네이션 상태 관리 → CSV 내보내기 연동 → 로딩/에러 처리 --- ## G. 정책 분석 (/sef-lens) ### G1. 전력 요금 정책 확인 **상황**: 전력 요금 계산 관련 코드 정책을 파악 **프롬프트**: ``` /sef-lens 전력 요금 정책 확인해줘 ``` **실행 흐름**: 키워드 추출 → 코드 탐색 → 정책 보고서 생성 → "변경 아이디어가 있나요?" 질문 --- ### G2. 계약 전력 한도 상세 분석 **상황**: 계약 전력 한도 관련 로직을 더 깊이 분석 **프롬프트**: ``` /sef-lens 계약 전력 한도 정책 상세하게 분석해줘 ``` **실행 흐름**: 상세 분석 모드 → 더 넓은 범위 탐색 → 관련 클래스/메서드 전체 추적 → 상세 보고서 --- ### G3. 영향도 — 전력 단가 변경 시 **상황**: 전력 단가를 변경할 때 시스템 전체 영향도를 파악하고 싶을 때 **프롬프트**: ``` /sef-lens 전력 단가를 kWh당 110원에서 130원으로 바꾸면 어떻게 돼? ``` **실행 흐름**: 정책 보고서 → 영향도 분석 자동 실행 (architect + security-auditor 병렬) → PO 보고서 생성 --- ### G4. 설비 상태 판정 로직 분석 **상황**: 인버터 정상/이상/경고 상태를 판정하는 로직의 현황 파악 **프롬프트**: ``` /sef-lens 인버터 상태 판정 로직 분석해줘. 어떤 조건으로 정상/경고/이상을 구분하는지 알고 싶어. ``` **실행 흐름**: 상태 판정 관련 코드 탐색 → 판정 기준 추출 → 조건 분기 다이어그램(텍스트) 생성 → 개선 제안 여부 질문 --- ## H. 리서치 ### H1. 에너지 관련 기술 비교 — SCADA vs IoT **상황**: 발전소 데이터 수집 방식을 비교하고 싶을 때 **프롬프트**: ``` /sef-research SCADA vs IoT 기반 발전소 데이터 수집 방식 비교해줘 ``` **실행 흐름**: 비교표 형태 선택 → 웹 검색 → 교차 검증 → `.research/` 에 결과 저장 --- ### H2. 종합 — 공공 에너지 관리 시스템 트렌드 **상황**: 최신 공공 에너지 관리 기술 트렌드 조사 **프롬프트**: ``` /sef-research 2026년 공공 신재생에너지 관리 시스템 트렌드 조사해줘 ``` **실행 흐름**: 종합 리포트 모드 → 다중 출처 수집 → 요약 + 원문 링크 포함 → `.research/` 저장 --- ### H3. 빠른 핵심 — 시계열 DB 비교 **상황**: 발전 데이터 저장에 적합한 시계열 DB를 빠르게 비교 **프롬프트**: ``` /sef-research InfluxDB vs TimescaleDB vs OpenTSDB 비교해봐. 빠르게 핵심만. ``` **실행 흐름**: "빠르게 핵심만" 키워드 → 요약 모드 → 불릿 리스트 형식으로 핵심 3~5가지 반환 --- ### H4. 결과를 context에 반영 **상황**: 시계열 DB 리서치 결과를 도메인 지식에 반영 **프롬프트** (리서치 완료 후): ``` /sef-context 계량 데이터 도메인 .research/timeseries-db-20260327.md 기반으로 갱신해줘 ``` **실행 흐름**: 리서치 파일 분석 → 기존 `context/metering-data/` 문서와 비교 → 변경 항목 diff 확인 → 갱신 --- ## I. 패턴 검증 ### I1. 코드 검증 **상황**: 최근 변경 코드가 패턴을 준수하는지 확인 **프롬프트**: ``` /sef-verify ``` **실행 흐름**: 변경 파일 수집 → MANIFEST CHECKLIST 대조 → CRITICAL/WARNING/INFO 분류 → 교정 선택 --- ### I2. 패턴 검증 후 자동 교정 **상황**: 위반 항목을 자동으로 수정하고 싶을 때 **프롬프트**: ``` /sef-verify ``` **실행 흐름**: 검증 결과 확인 후 → "전체 교정" 선택 → CRITICAL 항목부터 순차 수정 → 재검증 --- ### I3. Reference 문서 동기화 **상황**: reference 문서의 코드 예시가 실제 코드와 달라졌을 때 **프롬프트**: ``` /sef-verify 문서 동기화해줘 ``` **실행 흐름**: reference 문서 로드 → 실제 코드 비교 → 불일치 항목 목록화 → 문서 갱신 --- ## J. AI 글쓰기 교정 ### J1. 감지만 (audit) **상황**: 어떤 AI 패턴이 있는지 확인만 **프롬프트**: ``` /sef-humanizer docs/energy-proposal.md 감지만 해줘 ``` **실행 흐름**: 파일 읽기 → 40+ 패턴 스캔 → P1/P2/P3 분류 리포트 (수정 없음) --- ### J2. 자동 교정 (rewrite) **상황**: AI 티를 제거해서 자연스럽게 고치기 **프롬프트**: ``` /sef-humanizer docs/plant-operation-guide.md 자연스럽게 고쳐줘 ``` **실행 흐름**: 감지 → P1 우선 교정 → 원문 대비 diff 확인 → 파일 저장 --- ### J3. 특정 부분만 교정 **상황**: 보고서의 결론 부분만 교정 **프롬프트**: ``` /sef-humanizer docs/energy-analysis-report.md 결론 부분만 고쳐줘 ``` **실행 흐름**: 섹션 감지 → 해당 섹션만 스캔 및 교정 → 나머지 섹션 유지 --- ## K. DB 스키마 조회 ### K1. 전체 스키마 **상황**: 에너지 관리 시스템 DB 구조를 처음 파악 **프롬프트**: ``` /sef-db-schema-query 전체 테이블 구조 보여줘 ``` **실행 흐름**: 스키마 목록 → 테이블 목록 → 주요 테이블 상세 → 관계 요약 --- ### K2. 발전설비(plant_equipment) 테이블 상세 **상황**: `plant_equipment` 테이블의 컬럼과 인덱스 확인 **프롬프트**: ``` /sef-db-schema-query plant_equipment 테이블 상세 구조 확인해줘 ``` **실행 흐름**: `plant_equipment` 테이블 조회 → 컬럼 목록 + 타입 + 제약조건 → 인덱스 목록 → 관련 FK 표시 --- ### K3. 계량 데이터(metering_data) FK 관계 **상황**: 계량 데이터 관련 테이블 간 FK 관계 확인 **프롬프트**: ``` /sef-db-schema-query metering_data 테이블 관련 FK 관계 보여줘 ``` **실행 흐름**: `metering_data` 기준 FK 탐색 → 연관 테이블 목록 → 관계 다이어그램(텍스트) 출력 --- ## L. 스킬 조합 패턴 ### L1. 분석 → 개발 (전력 요금 분석 → 개선) **상황**: 기존 전력 요금 정책을 분석한 후 개선 **프롬프트 순서**: ``` 1. /sef-lens 전력 요금 정책 확인해줘 2. /sef-context 전력 요금 도메인 등록해줘 3. /sef-dev 전력 요금을 계시별로 분리해서 계산하도록 개선해줘 ``` **실행 흐름**: 정책 현황 보고서 → 도메인 지식 정리 → 설계 기반 전체 개발 사이클 실행 --- ### L2. 리서치 → 개발 (시계열 DB 조사 → 적용) **상황**: 시계열 DB 조사 후 계량 데이터 저장에 적용 **프롬프트 순서**: ``` 1. /sef-research TimescaleDB vs InfluxDB 비교해줘 2. /sef-dev 계량 데이터 수집 모듈에 TimescaleDB 적용해줘 ``` **실행 흐름**: 리서치 보고서 `.research/` 저장 → `/sef-dev` 실행 시 리서치 결과 컨텍스트 자동 참조 --- ### L3. 화면정의서 → 프론트엔드 **상황**: 공공 프로젝트에서 화면정의서 기반 개발 **프롬프트 순서**: ``` 1. 유지보수 요청 화면정의서 작성해줘 2. /sef-frontend-builder 화면정의서 기반으로 유지보수 요청 목록 페이지 만들어줘 ``` **실행 흐름**: screen-spec-writer 에이전트가 화면정의서 작성 → `/sef-frontend-builder`가 화면정의서 파싱 → 컴포넌트 생성 --- ### L4. DB → 백엔드 → 프론트엔드 (에너지 도메인) **상황**: 계량 데이터 테이블 기반 풀스택 생성 **프롬프트 순서**: ``` 1. /sef-db-schema-query metering_data 테이블 구조 확인해줘 2. /sef-backend-builder metering_data 테이블 기반 계량 데이터 API 만들어줘 3. /sef-frontend-builder 계량 데이터 조회/관리 화면 만들어줘 4. /sef-verify 5. 커밋하고 PR 올려줘 ``` **실행 흐름**: 스키마 파악 → 백엔드 생성 → 프론트엔드 생성 → 패턴 검증 → 커밋 + PR 체이닝 --- ### L5. 전체 프로세스 (에너지 분석 신규 진입) **상황**: 에너지 분석 도메인에 새로 진입할 때 전체 프로세스 **프롬프트 순서**: ``` 1. /sef-context 2. /sef-lens 전력 사용량 분석 정책 정리해줘 3. /sef-research 에너지 데이터 분석 플랫폼 패턴 조사해줘 4. /sef-dev 에너지 사용량 분석 기능 개발해줘 5. /sef-verify 6. 커밋하고 PR 올려줘 ``` **실행 흐름**: 코드베이스 스캔 → 현황 파악 → 기술 리서치 → 전체 개발 사이클 → 패턴 검증 → 배포 준비 --- ## M. 공공 프로젝트 특화 ### M1. eGovFrame 기반 발전소 관리 기능 **상황**: 공공 프로젝트에서 발전소 관리 기능 개발 **프롬프트**: ``` /sef-dev 발전소 관리 기능 개발해줘. 공공 표준 프레임워크 패턴 맞춰줘. 발전소 등록, 현황 조회, 가동 이력 관리 필요해. ``` **실행 흐름**: sector=public 기반 → GET/POST only → EgovAbstractServiceImpl 상속 → MyBatis XML → 공공 표준 응답 형식 준수 --- ### M2. 유지보수 요청 화면정의서 **상황**: 공공 프로젝트 산출물로 유지보수 요청 화면정의서 필요 **프롬프트**: ``` 유지보수 요청 화면정의서 작성해줘 ``` **실행 흐름**: screen-spec-writer 에이전트 투입 → 화면 ID, 입출력 필드, 버튼, API 명세 표 생성 → `docs/` 저장 --- ### M3. WAR 배포 설정 **상황**: 공공 환경 WAR 배포 시 설정 추가 **프롬프트**: ``` /sef-dev WAR 배포 설정 추가해줘 ``` **실행 흐름**: sector=public 확인 → `build.gradle` WAR 플러그인 설정 → `web.xml` 생성 → 배포 스크립트 추가 --- ## N. 민간 프로젝트 특화 ### N1. JPA + Redis — 설비 카탈로그 **상황**: 민간 프로젝트에서 발전설비 카탈로그 개발 **프롬프트**: ``` /sef-dev 발전설비 카탈로그 기능 개발해줘. 인버터, 접속반, 태양광 모듈 유형별 카탈로그야. Redis 캐싱 적용해줘. ``` **실행 흐름**: sector=private → JPA Entity + Repository → `@Cacheable` 적용 → REST API → 캐시 무효화 전략 포함 --- ### N2. Docker 배포 설정 **상황**: 민간 에너지 관리 플랫폼 Docker 컨테이너화 **프롬프트**: ``` /sef-dev Docker 배포 환경 구성해줘 ``` **실행 흐름**: sector=private 확인 → Dockerfile 생성 → `docker-compose.yml` → 환경변수 분리 → `.dockerignore` 설정 --- ## O. 장애 대응 ### O1. 에러 디버깅 **상황**: 계량 데이터 수집 배치에서 500 에러 발생 **프롬프트**: ``` 계량 데이터 수집 배치에서 500 에러 나는데 왜 그래? ``` 또는 ``` NullPointerException 스택트레이스 분석해줘 — 인버터 응답값이 null일 때 발생하는 것 같아 ``` **실행 흐름**: incident-manager 자동 투입 → 스택트레이스 분석 → 근본 원인 식별 → 수정 제안 → HOTFIX 파이프라인 연결 --- ### O2. 빌드 실패 해결 **상황**: Gradle 빌드가 실패 **프롬프트**: ``` 빌드가 안 돼. 에러 메시지 확인해줘. ``` **실행 흐름**: 빌드 로그 분석 → 의존성 충돌 / 컴파일 에러 분류 → 수정 방안 제시 → 재빌드 검증 --- ### O3. 성능 이슈 — 발전 데이터 집계 쿼리 **상황**: 월별 발전량 집계 API 응답이 10초 이상 걸릴 때 **프롬프트**: ``` 월별 발전량 집계 API가 너무 느려. 쿼리가 10초 걸리는데 원인 분석해줘. ``` **실행 흐름**: 쿼리 분석 → N+1 문제 / 인덱스 누락 탐지 → `/sef-lens`로 집계 정책 확인 → 집계 테이블 분리 또는 인덱스 추가 방안 제시 --- ### O4. 배포 후 롤백 **상황**: 배포 후 발전량 집계 오류 발생으로 롤백 필요 **프롬프트**: ``` 방금 배포한 거 롤백해줘 ``` **실행 흐름**: 이전 커밋 확인 → 롤백 전략 제시 (git revert vs 재배포) → 사용자 확인 → 실행 --- ## P. 고급 활용 ### P1. 대규모 리팩토링 **상황**: 에너지 데이터 수집 모듈 전체를 레거시에서 새 구조로 리팩토링 **프롬프트**: ``` /sef-dev 에너지 데이터 수집 모듈 전체 리팩토링해줘. 지금은 Polling 방식인데 Event-Driven으로 바꾸고, DataCollector/DataProcessor/DataStore 레이어로 분리해줘. 기존 테스트는 깨지면 안 돼. ``` **실행 흐름**: 기존 코드 전체 분석 → 의존성 맵 생성 → 단계별 리팩토링 계획 수립 → 레이어 순서대로 분리 → 각 단계마다 테스트 통과 확인 --- ### P2. DB 마이그레이션 **상황**: 기존 MySQL 기반 계량 데이터 테이블을 TimescaleDB로 마이그레이션 **프롬프트**: ``` /sef-dev 계량 데이터 테이블을 MySQL에서 TimescaleDB로 마이그레이션해줘. 데이터 손실 없이, 기존 API는 그대로 동작해야 해. ``` **실행 흐름**: 기존 스키마 분석 → TimescaleDB 하이퍼테이블 설계 → 데이터 마이그레이션 스크립트 → 롤백 계획 → 기존 API 호환성 테스트 --- ### P3. 성능 최적화 — 발전 데이터 집계 쿼리 **상황**: 발전량 집계 쿼리 성능을 집중적으로 튜닝 **프롬프트**: ``` /sef-dev 발전량 집계 쿼리 성능 최적화해줘. 현재 1,000만 건 테이블에서 월별 집계가 30초 걸려. 목표는 1초 이하야. ``` **실행 흐름**: 실행 계획 분석 → 인덱스 전략 수립 → 파티셔닝 검토 → 집계 캐시 테이블 설계 → before/after 성능 비교 --- ### P4. 환경별 설정 분리 **상황**: dev/staging/prod 환경 설정이 뒤섞여 있을 때 **프롬프트**: ``` /sef-dev 환경별 설정 파일 분리해줘. dev, staging, prod 필요해. DB 접속 정보, MQTT 브로커 주소, 수집 주기 설정이 환경마다 달라. ``` **실행 흐름**: 현재 설정 분석 → `application-{profile}.yml` 생성 → 민감 정보 환경변수 분리 → 가이드 문서 생성 --- ### P5. 중간에 방향 전환 — 설계 변경 **상황**: 인버터 상태 관리를 Polling에서 WebSocket으로 바꾸기로 결정 **프롬프트**: ``` 아까 인버터 상태 조회를 Polling으로 설계했는데, WebSocket으로 바꿔줘. 실시간성이 더 중요하다고 결정났어. ``` **실행 흐름**: 이전 설계 파악 → Polling 관련 코드 식별 → WebSocket 설계로 전환 → 변경 영향도 안내 → 재설계 및 구현 --- ### P6. 특정 파일 리뷰 요청 **상황**: 코드 리뷰가 필요할 때 **프롬프트**: ``` /sef-dev src/main/java/com/sqi/energy/tariff/ElectricityTariffService.java 리뷰해줘 ``` **실행 흐름**: 파일 분석 → 패턴 준수 여부 → 잠재적 버그 → 개선 제안 --- ### P7. 테스트 코드 생성 **상황**: 구현 후 테스트 코드가 없을 때 **프롬프트**: ``` /sef-dev ElectricityTariffService 단위 테스트 만들어줘. 계시별 요금제 경계값 테스트 꼭 포함해줘. ``` **실행 흐름**: 대상 클래스 분석 → 공공: JUnit4 + Mockito / 민간: JUnit5 + MockMvc → 경계값 포함 엣지 케이스 --- ### P8. API 명세 문서화 **상황**: Swagger/OpenAPI 명세가 필요 **프롬프트**: ``` /sef-dev 발전설비 관리 API Swagger 명세 추가해줘 ``` **실행 흐름**: Controller 분석 → `@Operation`, `@ApiResponse` 어노테이션 추가 → 요청/응답 스키마 문서화 --- ### P9. 프레임워크 마이그레이션 **상황**: Spring Boot 2.x 기반 프로젝트를 Spring Boot 3.x로 마이그레이션 **프롬프트**: ``` /sef-dev Spring Boot 2.7에서 3.2로 마이그레이션해줘. javax → jakarta 패키지 변경 포함. 에너지 데이터 수집 모듈 먼저 해줘. ``` **실행 흐름**: 현재 의존성 전체 분석 → 호환성 이슈 목록화 → 우선순위 순서대로 마이그레이션 → 각 단계 빌드/테스트 확인 --- ### P10. 대규모 여러 파일 변경 **상황**: 에너지 도메인 전체의 용어를 변경해야 할 때 **프롬프트**: ``` /sef-dev 코드 전체에서 'SolarPlant'를 'EnergyPlant'로 리네이밍해줘. 클래스명, 변수명, DB 컬럼명, API 경로 전부 바꿔줘. 마이그레이션 스크립트도 포함해줘. ``` **실행 흐름**: 영향 범위 전체 탐색 → 변경 계획 수립 → 파일별 순차 변경 → DB 마이그레이션 스크립트 → 빌드/테스트 통과 확인 --- ## 마치며 — 프롬프트의 가능성 이 문서에 담긴 예시들은 가능성의 일부입니다. SEF-2026의 스킬들은 여러분이 자연스럽게 표현하는 말을 이해하도록 설계되어 있습니다. 복잡한 요구사항일수록 더 많은 맥락을 담아 말하면 됩니다. "이렇게만 써야 한다"는 규칙은 없습니다. 이 문서는 "이런 것도 된다"를 보여주는 지도일 뿐입니다. 발전소 운영 데이터 분석, 설비 수명 예측, 전력 거래 최적화, 탄소 배출량 추적, 에너지 저장 시스템(ESS) 관리 — 에너지 도메인의 수많은 문제를 자연어로 표현하고, 스킬을 통해 구체적인 코드로 만들어가는 과정 자체가 여러분의 개발 프로세스입니다. 가능성은 무궁무진합니다.