Copilot에 '사전 프롬프트'를 활용하여 자체 검증 루프 구현하기 (Claude Code의 규율 이식)

Claude Code를 사용하면서 '출력의 질이 높다'고 느끼는 이유를 분해해보면, 숨겨진 마법이라기보다는
사전 지시(custom instructions / 시스템 프롬프트)가 담당하는 부분이 크다. 그 핵심은 '자체 검증 루프', 'builder ≠ checker (만드는 사람과 검수 역할을 분리)', '완료의 정의(품질 게이트)' 세 가지이다. 이들은 특정 도구에 국한된 것이 아니므로,
사전 프롬프트로 작성하면 M365 Copilot / GitHub Copilot에서도 유사한 동작을 끌어낼 수 있다.
다만, Copilot의 채팅 기능은 코드를 실행할 수 없다. 루프의 진정한 강점은 '실제 테스트 실행이라는 외부 검증에 기반하고 있다는 점'이므로, 이 부분을 모호하게 처리하면 '녹색 위장(green camouflage)'이 된다. 실행이 필요한 검증은 인간이 진행한다는 전제로 작성해야 한다.

마지막으로, 그대로 붙여넣을 수 있는 사전 프롬프트를 통째로 제시한다.

AI 어시스턴트의 출력 품질을 높이려고 하면, 자꾸 '더 똑똑한 모델', '더 긴 대화'에 시선이 간다. 하지만 실제로 코딩 에이전트 계열을 사용해 보면, 품질 차이를 만드는 것은 매번 로드되는 사전 지시인 경우가 많다.

구체적으로 효과가 좋았던 규율은 다음과 같다.

• 구현하고 끝내지 않고,
  구현 → 스스로 검수 → 수정을 반복한다.
• 만든 본인이 아니라 **'결함을 찾아내는 것이 임무인 비판자'**의 시각으로 재검토한다.
• '완료'라고 말하기 전에
  체크리스트에 비추어 확인하고, 통과하지 못한 것을 '통과했다'고 말하지 않는다.

이것들은 특정 도구에 묶인 기능이 아니라, 문장으로 사전에 지시하면 다른 Copilot에서도 끌어낼 수 있는 '규율'이다. 본 기사는 이를 이식한다.

태스크마다 다음 과정을 거친다.

합격 기준 동결: 착수 전에 '이것이 충족되면 완료'라고 말할 수 있는 YES/NO 판별 가능한 기준을 3~5개 작성하고 고정한다.

• 구현/제작: 기준을 만족하도록 만든다.
• L0 자체 검사 (비용 0): 기계적으로 대조할 수 있는 항목(필수 요소의 유무・형식・일관성・숫자의 합산・참조의 불일치・항목 누락)을 스스로 확인한다.
• 적대적 검증: 시점을 전환하여 허점을 찾는다 (다음 항).
• 수정하고 3→4를 반복한다. 모든 기준을 충족하는지, 상한선(예: 3회 순환)으로 멈춘다. 충족하지 못한 항목은 '미달'로 명시한다.

핵심은 '상한선을 두는 것'과 '미달을 숨기지 않는 것'이다. 끝없이 루프를 돌리지 않으면서, 남은 구멍을 정직하게 신고하도록 만든다.

만드는 사람과 검수 역할을 분리하는 것이 본질이다. 같은 시각으로 재검토해도 자신의 맹점은 그대로 남아있다. 프롬프트에서는 다음과 같이 지시한다.

시점을 전환하여, '만든 자신'이 아니라 '결함을 찾아내는 것이 임무인 비판자'로서, 동결된 기준에 하나하나 대조하며 허점을 찾으라.

기본값은 불합격이다. 기준을 충족했다는 증거를 제시할 수 없는 항목은 불합격 처리한다. 승인이 아니라 결함 발견이 임무다.

더 강하게 하려면, 검수를 별도의 스레드/별도 모델에 맡긴다. 동일 모델의 자체 검토는 같은 계통의 맹점을 공유하기 쉬우므로, 체계가 다른 두 번째 리뷰어를 투입하면 독립적인 결함이 나오기 쉽다.

여기가 가장 중요하고, 가장 속이기 쉬운 부분이다.

코딩 에이전트 버전의 루프가 강력한 것은 실제 테스트 실행이라는 외부 기계 판정에 기반하고 있기 때문이다. 반면, M365 Copilot이나 GitHub Copilot의 채팅은 (에이전트 모드의 일부를 제외하고) 코드를 실행할 수 없다. 따라서 루프를 액면 그대로 따라 하면, 모델이 내부적으로 '테스트는 통과할 것이다'라고 판단하여 녹색으로 위장한다.

이를 방지하기 위해 프롬프트에 경계를 명확히 기재해야 한다.

• 실행 가능한 검증(테스트・린트・타입 체크・빌드・실제 데이터 대조)이 있다면,
  인간이 진행할 수 있는 절차와 명령어로 구체적으로 제시하고, 결과를 기다린 후에 판정한다.
• 사실은 1차 정보에 근거하여,
  출처・전제・반증 가능성을 병기한다. '추측'과 '확인 완료'를 구분한다.
• 확인하지 않은 것을 '확인 완료'라고 말하지 않는다. 건너뛴 점은 한 줄로 보고한다.

루프의 자체 검증은 어디까지나 '동결 기준에 대한 자기 대조'까지만 방어 범위이며, 실행을 수반하는 검증은 인간이 요새가 되어야 한다. 이 역할 분담을 작성해 두면, 거짓 완료 보고가 급감한다.

'완료'라고 말하기 전의 체크리스트를 고정시킨다.

• 동결된 합격 기준을 모두 충족했는가?
• 필수 요소・형식・일관성은 갖추었는가? (L0)
• 연쇄적으로 수정해야 할 부분은 없는가? (관련 문서・전제・의존성・테스트・타입 정의)
• 미달・미확인・건너뛴 점은 없는가? → 있다면 한 줄로 명시
• 다음 단계는 명확한가?

아래 내용을 Copilot의 지시(Instructions)란(후술)이나 대화 서두에 붙여넣으세요. 응답 스타일의 세부 사항은 취향에 따라 가감해도 좋습니다.

당신은 "만들고 끝"이 아니라 "만들기→직접 검품→수정"을 반복하는 제작 어시스턴트입니다.
코드든 문서든 설계든, 생성물의 품질을 자기 검증 루프 (Self-verification loop)를 통해 담보합니다.
## 대원칙
...

M365 Copilot: Agent Builder (Copilot Studio의 에이전트 빌더)에서 선언적 에이전트 (Declarative Agent)를 만들고, 그 "지시 (Instructions)"란에 붙여넣습니다. 이렇게 하면 마이 에이전트 (My Agent)로서 매번 해당 규율에 따라 기동합니다. 지시란에는 글자 수 제한이 있으므로, 내용이 길 경우 핵심 (자기 검증 루프 + 완료의 정의) 위주로 압축합니다. 대화 단위로 충분하다면 채팅 서두에 붙여넣는 것만으로도 효과가 있습니다. -
GitHub Copilot: 리포지토리 바로 아래의 .github/copilot-instructions.md에 두면, 해당 리포지토리의 Copilot Chat 전체에 적용됩니다. 개인 설정의 커스텀 인스트럭션 (Custom instructions)에 붙여넣으면 모든 리포지토리에 적용됩니다.

별도의 자동 리뷰 연동 기능은 없습니다. 계통이 다른 제2의 모델을 통한 검품은 강력하지만, 툴 측면의 자동 연동이 없는 환경에서는 "검품을 별도의 스레드/별도의 모델로 넘기는 것"을 수동 운영 방식으로 적용합니다. -
실행·CI·알림의 자동화는 실행 권한을 가진 코딩 에이전트 (Coding Agent) 고유의 기능입니다. Copilot Chat에서는 사람이 직접 수행하는 절차로서 제시하는 형태로 대체합니다.

출력 품질은 "숨겨진 똑똑함"이 아니라 **사전 지시 (Config/Pre-prompt)**가 결정합니다.

• 자기 검증 루프 (구현→검품→수정)
• builder≠checker (만드는 이와 검품 역할을 분리)
• 완료의 정의 (품질 게이트, 거짓으로 통과하지 않기)

이 세 가지를 사전 프롬프트 (Pre-prompt)에 작성하여 Copilot에 영구적으로 부여하는 것만으로도, "만들고 끝"인 단계에서 한 단계 더 올라설 수 있습니다. 요점을 한마디로 정리하면, "완성이라고 말하기 전에, 스스로 적대적으로 검품하게 만드는" 문장을 툴에 상주시키는 것입니다.