성숙한 프로젝트에서 AI 리서치 에이전트에게 “이 기능을 위한 도구를 찾아줘”라고 하면 종종 새 도구를 설계하거나 존재하지 않는 도구를 추천한다. Microsoft ISE 블로그가 이 문제를 해결하는 검증 중심 프롬프트(Verification-Driven Tooling Prompts) 방법론을 소개했다.

문제: 에이전트는 새 도구를 설계하려 한다

Microsoft ISE 팀이 성숙한 코드베이스에서 죽은 코드 탐지 스크립트를 AI 에이전트로 리서치했을 때, 에이전트는 새로운 탐지기를 처음부터 설계하는 방향으로 진행했다. 실제로는 대부분의 생태계에 이미 성숙한 툴링이 존재함에도 불구하고.

빠르게 변하는 코드베이스에서 팀은 새 도구를 만드는 것이 아니라 기존 도구들 중 최선을 선택해야 할 때가 많다. 질문의 형태를 바꿔야 한다.

해결책: 검증 체크리스트 먼저 정의

에이전트에게 새 도구를 설계하도록 요청하는 대신, 검증 체크리스트를 먼저 정의하고 그 기준을 충족하는 기존 도구를 추천하도록 한다.

검증 체크리스트 4단계

0단계: 탐지 유스케이스 수집 코드베이스에서 실제로 탐지해야 하는 케이스가 무엇인지 먼저 정리한다.

1단계: 제외 조건 정의 처음부터 배제해야 하는 도구 유형을 명시한다. 예: “프로덕션 의존성을 추가하는 도구 제외”, “현재 언어 지원 없는 도구 제외”

2단계: 탐지 클래스 정의 찾으려는 패턴의 분류를 명확히 한다. 예: “미사용 함수”, “참조 없는 변수”, “미사용 임포트”

3단계: 검증 케이스 생성 각 도구가 실제로 이 케이스들을 처리하는지 확인하는 구체적 테스트 케이스를 만든다.

에이전트에게 전달하는 프롬프트 형태

죽은 코드 탐지를 위한 최선의 기존 도구를 추천해줘.
요구사항:
- 추가 의존성 없이 기존 프로젝트에 통합 가능
- TypeScript + JavaScript 지원 필수
- 미사용 함수, 미사용 임포트를 탐지 가능해야 함
- CI 파이프라인에서 실행 가능
새 도구 설계 금지. 기존 도구 중에서만 추천.

지시 드리프트(Instruction Drift) 주의

상속된 프롬프트 템플릿을 사용할 때 원래 지시 의도가 흐려질 수 있다. 팀 간에 공유되는 프롬프트 템플릿에 검증 체크리스트를 명시적으로 포함시켜 에이전트가 일관된 방향으로 리서치하도록 유도한다.

핵심 원칙

특정 도구가 목표가 아니다. 신뢰할 수 있는 반복 가능한 프로세스가 목표다. 코드 생산이 빨라지면 검증이 병목이 된다. 검증 체크리스트는 툴링 프롬프트를 추측에서 계약으로 바꾼다.

참고 자료

• Verification-driven tooling prompts for fast-moving codebases — ISE Developer Blog (2026-05-28)