안전한 변경을 위한 GitHub Copilot Agent Prompt 하나

Source: Dev.to

핵심 아이디어

변경하고 싶은 내용을 설명한 뒤, 프롬프트를 다음 문장으로 마무리합니다:

Before you do any changes, show me your detailed step by step implementation plan for approval.

먼저 에이전트에게 계획을 요청합니다—아직 코드를 수정하지 않고, 명확한 단계 목록만 받습니다. 계획을 검토한 뒤 승인, 수정, 혹은 거부할 수 있습니다.

왜 도움이 되는가

“먼저 계획” 패턴은 워크플로우를 개선합니다:

• 코드를 수정하기 전에 명확한 의도 전달
• 원시 diff 대신 단계 목록을 보게 되어 리뷰가 쉬워짐
• 반쯤 진행된 리팩터링 위험 감소

에이전트가 “fire and forget”에서 “제안 후 실행”으로 전환되어 범위와 방향을 사용자가 직접 제어할 수 있습니다.

작은 예시

프롬프트

I want to extract logging concerns from this C# class into a separate service.

Steps:
1. Identify all logging calls.
2. Introduce an IAppLogger interface.
3. Inject IAppLogger into the constructor.
4. Replace direct logging calls with the new abstraction.

Before you do any changes, show me your detailed step by step implementation plan for approval.

에이전트가 제시할 수 있는 계획

Step 1: Scan the class and list all logging calls, grouped by log level.
Step 2: Propose the IAppLogger interface signature which covers the current usage.
Step 3: Add the new interface and a concrete implementation in a Logging folder.
Step 4: Update the target class constructor to accept IAppLogger through dependency injection.
Step 5: Replace direct logging calls with calls to IAppLogger.
Step 6: Update the composition root to register the concrete logger.
Step 7: Propose unit test updates for the new abstraction.

그 후 누락된 부분이나 위험 요소를 발견할 수 있습니다. 예:

• 구조화된 로깅에 대한 언급 없음
• 로그 컨텍스트에 대한 언급 없음
• 다른 클래스에서의 교차 관심사에 대한 언급 없음

응답

Good start.

Extend the plan with:
- Structured logging support
- Log context (correlation id, user id)
- Follow‑up steps for other classes using logging in this project

Then show me the updated plan. Do not change any code yet.

계획이 충분히 탄탄해 보일 때만 에이전트에게 적용을 요청합니다.

프롬프트 변형

안전 및 리뷰

Before you do any changes, show me your detailed step by step implementation plan for approval. Wait for my confirmation before you start.

페어 프로그래밍

Before you do any changes, propose a detailed step by step implementation plan. Ask me questions if anything in my request is unclear.

대규모 리팩터링

Before you do any changes, outline a detailed step by step implementation plan with milestones. Mark risky steps explicitly.

공통 구조

• 상세 계획 요청
• 순서가 있는 단계 요구
• 수정 전 일시 정지 요구
• 질문할 여지 제공

일상 사용 팁

• 변경 요청을 짧고 집중되게 유지
• 번호 매긴 단계 요청
• 큰 변경에는 위험 요소 강조 요청
• 계획에 테스트 영향 요청
• 좋아하는 프롬프트 변형을 스니펫이나 노트에 저장
• 팀 전체에서 일관성을 위해 동일한 패턴 사용

이 패턴이 빛을 발하는 경우

다음 상황에서 한 줄 프롬프트가 가장 효과적입니다:

• 레거시 코드 리팩터링
• 공유 라이브러리 수정
• 공개 API 변경
• 익숙하지 않은 코드베이스 작업
• 팀원과 채팅이나 풀 리퀘스트에서 계획을 검토

이러한 경우, 실제 수정이 이루어지기 전에 작업 범위, 위험, 테스트 영향을 모두 파악할 수 있어 에이전트를 지시하는 것이 아니라 가이드하게 됩니다.