AI 코딩 어시스턴트에게 "스스로 검토하고 수정해"라고 촉구하면 출력의 질이 올라갑니다. 하지만 그것이 실제로 어디까지 효과가 있는지에 대해서는 연구상으로 명확한 선이 그어져 있습니다. 결론부터 말하자면, 자기 개선(Self-improvement)은 외부의 검증에 접지(grounding)되어야 비로소 효과가 나타납니다. 본고에서는 논문을 통해 이 경계선을 확인하고, 이를 바탕으로 "Copilot과 같은 사전 지시(custom instructions)에 무엇을 작성해야 하는가"를 도출합니다.

먼저, 자기 개선이 효과가 있음을 보여준 대표적인 연구부터 살펴보겠습니다. Self-Refine은 동일한 LLM이 "생성 → 스스로 피드백 → 개선"을 반복하는 것만으로도 출력이 좋아진다는 것을 보여주었습니다.

the same LLMs provides feedback for its output and uses it to refine itself, iteratively

(출처 [1])

uses a single LLM as the generator, refiner, and feedback provider

(출처 [1])

Reflexion은 가중치(weights)의 업데이트가 아니라 **언어적인 피드백(linguistic feedback)**으로 에이전트를 강화하는 프레임워크입니다.

Reflexion agents verbally reflect on task feedback signals

(출처 [2])

여기까지는 "자기 개선은 효과가 있다"라는 희망적인 이야기입니다. 하지만 두 연구 모두에 공통적인 점은, 개선이 **피드백 신호(feedback signals, 테스트 결과나 환경으로부터의 응답 등)**에 의해 뒷받침되고 있다는 점입니다. 이 지점이 다음의 함정으로 이어집니다.

"스스로 검토하기"만 하는 것, 즉 외부의 단서 없이 모델이 자력으로 수정하는 형태를 Huang 등(ICLR 2024)은 내재적 자기 수정(intrinsic self-correction)으로 분류하여 검증했습니다.

an LLM attempts to correct its initial responses based solely on its inherent capabilities, without the crutch of external feedback

(출처 [3])

그리고 추론(reasoning) 태스크에서의 결론은 다음과 같습니다.

LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction

(출처 [3])

즉, "다시 한번 잘 검토해 봐"라고 촉구하는 것만으로는 모델이 자신의 오류를 신뢰할 수 없는 방식으로 수정하게 되며, 때로는 성능이 악화됩니다. 개선을 만들어냈던 것은 성찰 그 자체가 아니라, 외부의 피드백이었던 것입니다.

검증의 효과를 더 깊이 파고들면, Let's Verify Step by Step이 시사하는 바가 큽니다. 최종 결과에만 정답 신호를 주는 결과 감독(outcome supervision)과 각 추론 단계(reasoning step)에 신호를 주는 과정 감독(process supervision)을 비교하고 있습니다.

process supervision, which provides feedback for each intermediate reasoning step

(출처 [4])

process supervision significantly outperforms outcome supervision

(출처 [4])

어디에 검증 신호를 둘 것인가에 따라 신뢰성이 달라집니다. 검증은 생성 과정의 부수적인 작업이 아니라, 독립적인 설계 대상입니다. 이는 "만드는 사람과 검수하는 사람을 분리한다(builder ≠ checker)"라는 운영상의 정석에 대해 연구 측면에서의 뒷받침을 제공합니다.

여기까지를 정리하면, 실무에서의 설계 지침은 다음 3가지가 됩니다.

• 루프의 합격 여부는 외부의 검증 신호(테스트 실행, 실제 데이터 대조, 1차 정보)로 결정한다. 모델의 자기 채점만을 완료 조건으로 삼지 않는다.
• 검수 역할을 만드는 사람으로부터 분리한다. 가능하다면 별도의 모델이나 별도의 스레드로 넘긴다.
• 검증을 수행할 수 없는 환경(채팅 전용 어시스턴트 등)에서는 인간이 검증을 수행한다는 전제를 명시하고, "확인하지 않은 것을 확인했다고 말하지 않게 한다".

3은 특히 중요합니다. 코드를 실행할 수 없는 어시스턴트에게 자기 검증 루프(self-verification loop)를 통째로 흉내 내게 하면, Huang 등이 말하는 내재적 자기 수정(intrinsic self-correction)에 대한 과신에 빠져, 모델이 머릿속으로 "테스트는 통과할 것이다"라며 초록색(성공)을 위장하게 됩니다. 따라서 "실행이 필요한 검증은 인간이 수행한다"라고 선을 그어두어야 합니다.

다행히 이 규율은 도구 고유의 기능이 아니라, 사전 지시(custom instructions)로서 작성할 수 있습니다. GitHub Copilot의 리포지토리 커스텀 명령(repository custom instructions)은 저장하면 매 요청마다 자동으로 첨부됩니다.

Instructions are automatically added to requests that you submit to Copilot

(출처 [5])

Microsoft 365 측도 선언적 에이전트(declarative agent)에 지시, 액션, 지식을 부여하여 Copilot을 맞춤 설정하는 설계입니다.

you provide the instructions, actions, and knowledge to tailor Copilot for your business scenarios

(출처 [6])

즉, "완성이라고 말하기 전에 외부 검증에 접지(grounding)하여 적대적으로 검품하라", "실행이 필요한 검증은 인간이 수행하라"라는 규율을 이러한 지시란에 상주시키면 됩니다. 연구가 보여준 함정(외부 피드백 없는 자기 수정에 대한 과신)을 운영 측면에서 미리 회피할 수 있습니다.

• 자기 개선은 효과가 있다 (Self-Refine / Reflexion). 단, 피드백(feedback)에 의해 뒷받침되어야 한다.
• 외부 피드백 없는 자기 수정은 신뢰할 수 없으며, 오히려 악화될 수도 있다 (Huang 등, 2024).
• 검증은 생성과 별개의 것이며, 신호(signal)를 어디에 두느냐가 신뢰성을 결정한다 (Let's Verify Step by Step).
• 그러므로 실무에서는 자기 개선 루프를 외부 검증에 접지하고, 검품 역할을 분리하며, 검증할 수 없는 환경에서는 인간이 수행한다는 전제를 사전 지시에 작성한다. 이것이 Copilot에게 "스스로 검품하고 수정하는" 질적 수준을 부여하는 핵심 요체입니다.

본고의 인용은 모두 1차 자료와 일대일 대조(verify_article 통과)를 거친 후 게재되었습니다 (2026-07-23 검증).

[1] https://arxiv.org/abs/2303.17651

[2] https://arxiv.org/abs/2303.11366

[3] https://arxiv.org/abs/2310.01798

[4] https://arxiv.org/abs/2305.20050

[5] https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions

[6] https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/overview-declarative-agent