[object Object]

Cross Validation은 말 그대로 여러 LLM에게 같은 질문을 보내고, 결과를 서로 비교해 신뢰도를 올리려는 시도입니다. 아이디어 자체는 단순하지만, 실제로 도구로 만들면 생각보다 많은 예외가 생깁니다.

왜 단일 응답으로는 부족했나

하나의 모델만 쓸 때 가장 큰 문제는 사용자가 정답인지 아닌지 판단하기 위해 다시 직접 읽어야 한다 는 점입니다. 결국 시간을 줄이려고 LLM을 쓰는데, 마지막 판단 비용이 그대로 남아 있었습니다.

그래서 Prompt Combo에서는 다음 흐름을 기본 패턴으로 잡았습니다.

1. 같은 질문을 Claude와 GPT에 동시에 보냅니다.
2. 두 응답을 각각 구조화합니다.
3. 합의한 부분과 충돌한 부분을 분리합니다.
4. 마지막 요약 프롬프트에서 차이점만 다시 검토합니다.

합의가 항상 품질을 의미하지는 않는다

처음에는 두 모델이 같은 답을 하면 정확도가 올라간다고 생각했습니다. 하지만 실험을 해보니 꼭 그렇지는 않았습니다.

• 질문이 모호할수록 둘 다 비슷한 추측을 하는 경우가 있습니다.
• 최신성이 필요한 정보는 둘 다 낡은 지식을 답할 수 있습니다.
• 코드 수정 제안은 둘 다 같은 버그를 놓치는 경우가 있습니다.

즉, Cross Validation은 정확성을 자동 보장하는 장치가 아니라, 리뷰 범위를 줄이는 장치 에 가깝습니다.

그래서 비교 기준을 따로 만들었다

응답을 그냥 문장 단위로 비교하면 신호보다 잡음이 많았습니다. 대신 아래 기준을 분리해서 보게 했습니다.

• 사실 주장
• 제안된 행동
• 가정과 전제
• 미해결 위험

이렇게 나누면 "같은 말을 다르게 표현한 경우"와 "실제로 결론이 다른 경우"를 구분하기 쉬워집니다.

type ValidationBlock = {
  claims: string[]
  actions: string[]
  assumptions: string[]
  risks: string[]
}

유용했던 실제 사례

코드 리뷰 프롬프트에서는 효과가 꽤 좋았습니다. 한 모델은 보안 취약점을 잘 잡고, 다른 모델은 회귀 가능성을 더 잘 짚는 식으로 분업이 생겼기 때문입니다.

특히 아래처럼 역할을 나눌 때 결과가 좋았습니다.

• Model A: 버그와 예외 처리 집중
• Model B: DX, 유지보수성, 테스트 갭 집중

결론적으로 Prompt Combo의 Cross Validation은 정답 제조기 보다는 리뷰어 두 명을 동시에 붙이는 장치 에 가깝습니다. 이 관점으로 접근했을 때 훨씬 현실적으로 동작했습니다.

남은 과제

아직도 해결 중인 문제는 두 가지입니다.

1. 두 모델이 모두 틀렸을 때는 합의가 오히려 자신감을 높인다는 점
2. 긴 응답에서는 비교 비용이 다시 커진다는 점

그래서 앞으로는 분야별 템플릿과 비교 스키마를 더 세밀하게 나눌 계획입니다. 범용 모드 하나로는 한계가 분명했습니다.