## 📝 한줄 요약
제안서 평가를 고도화하기 위한 아이디어로, 여러 AI API와 페르소나를 활용한 델파이 평가 방식을 기존 문서 시스템에 먼저 테스트해봤습니다.
목표는 AI에게 점수를 대신 매기게 하는 것이 아니라, 평가자마다 다르게 보는 지점과 애매한 개선 포인트를 찾는 것이었습니다.
바쁘시면 이것만 읽어도 돼요:
- 제안서 평가 고도화를 위해 델파이 평가 방식을 파일럿으로 테스트했습니다.
- 여러 API를 분리해 사용해 한 모델의 관점에 평가가 오염되지 않도록 했습니다.
- 핵심은 평균 점수가 아니라, 평가가 갈리는 축과 애매한 부분을 찾는 것이었습니다.
- 일부 API 응답 실패는 억지로 해석하지 않고 제외 패널로 기록했습니다.
- 결과적으로 아이디어로서 시도해볼 가치는 확인했습니다.
- 다음 단계는 문서 유형별 평가 루브릭을 더 고도화하는 것입니다.
## 🎯 이런 분들께 도움돼요
- 보고서나 제안서를 평가해야 하는 실무자
- 평가 기준은 있지만 실제 문서를 보면 판단이 애매해지는 사람
- AI로 문서 검토를 해보고 싶지만, 단일 AI 평가를 그대로 믿기는 어려운 사람
- 점수보다 “어디가 애매한지”, “어디를 고치면 좋은지” 알고 싶은 사람
## 😫 문제 상황: 평가 기준은 있어도, 애매한 문서는 남는다
보고서나 제안서를 평가할 때 가장 어려운 부분은 단순히 점수를 매기는 것이 아닙니다.
기준표를 만들 수는 있습니다. 항목별로 1점부터 5점까지 점수를 줄 수도 있습니다. 그런데 실제 문서를 보면 애매한 경우가 많습니다.
- 메시지는 분명한데 결재자가 바로 행동할 수 있을 만큼 구체적인가?
- 근거는 있어 보이지만 논리적으로 충분한가?
- 리스크를 언급하기는 했는데, 대응까지 다뤘다고 볼 수 있는가?
- 문서 유형상 꼭 필요한 평가 축과 그렇지 않은 축은 무엇인가?
이런 질문은 단일 평가자나 단일 AI 모델만으로는 놓치기 쉽습니다.
그래서 이번에는 제안서 평가 고도화에 적용하기 전, 기존 문서 시스템의 보고서 1건에 델파이 평가 방식을 테스트해봤습니다. 목적은 완성된 시스템을 만드는 것이 아니라, 아이디어로서 시도해볼 가치가 있는지 확인하는 것이었습니다.
## 🛠️ 사용한 도구
- 프라이드: Hermes 기반 텔레그램 업무문서 AI
- Python 평가 스크립트: 멀티 LLM 델파이 평가 실행
- 여러 AI API / 모 델: 서로 다른 관점을 얻기 위한 평가 패널
- 페르소나 평가자: 구조·논리 중심 평가자, 리스크 중심 평가자 등
- Markdown / JSON: 평가 결과와 중간 과정을 보존
이번 작업에서 가장 중요하게 본 것은 “여러 AI를 많이 쓰는 것” 자체가 아니었습니다.
핵심은 의견이 오염되지 않도록 API와 관점을 분리하는 것이었습니다.
하나의 모델에게만 평가를 맡기면 그 모델의 문체, 선호, 약점이 평가 전체를 지배할 수 있습니다. 그래서 서로 다른 API와 페르소나를 통해 독립적인 평가를 받고, 이후 어디서 의견이 갈리는지 확인하는 구조를 만들었습니다.
## 🔧 작업 과정
### 1. 바로 제안서에 적용하지 않고, 기존 문서로 먼저 테스트했습니다
처음부터 실제 제안서 평가에 적용하지는 않았습니다. 먼저 기존 문서 시스템에 있는 보고서 1건을 대상으로 테스트했습니다.
이유는 단순합니다. 평가 시스템 자체도 검증이 필요했기 때문입니다.
```text
문서 평가를 고도화하기 위해 델파이 평가를 테스트로 적용해봄
```
이번 테스트에서는 외부 사실관계 검증까지 확장하지 않았습니다. 범위를 문서 내부 품질 평가로 제한했습니다.
- 핵심 메시지가 명확한가?
- 논리와 근거가 맞물리는가?
- 의사결정자에게 필요한 So-what이 있는가?
- 리스크나 반론을 어느 정도 다루는가?
- 수치가 문서 안에서 서로 충돌하지 않는가?
이렇게 범위를 제한하니, AI 평가가 어디에 도움이 되고 어디까지는 아직 조심해야 하는지 더 분명히 볼 수 있었습니다.
### 2. 여러 API와 페르소나로 독립 평가를 받았습니다
이번 작업의 핵심은 여러 API를 통 해 다양한 관점을 얻는 것이었습니다.
```text
여러 API를 통해 의견이 오염되지 않도록 하고, 다양한 API로 다양한 관점을 얻는 점을 가장 크게 고려함
```
구조는 다음과 같았습니다.
- R1: 독립 평가
- 각 모델과 페르소나가 서로의 의견을 보지 않고 먼저 평가합니다.
- R2: 분포 공개 후 재평가
- 각 축의 평가 분포와 주요 이견을 공개한 뒤 다시 평가합니다.
- R3: 소수의견 강화와 수렴 점검
- 너무 빨리 합의된 축이 있다면, 진짜 합의인지 다수 의견에 맞춘 것인지 다시 점검합니다.
일반 평가에서는 최종 점수 하나만 남기 쉽습니다. 하지만 델파이 방식에서는 점수뿐 아니라 “왜 갈렸는지”가 남습니다.
이 차이가 중요했습니다.
### 3. 점수보다 이견을 보려고 했습니다
AI 평가를 받을 때 평균 점수만 보면 오히려 중요한 약점이 묻힐 수 있습니다.
예를 들어 어떤 문서가 전체적으로는 괜찮은 점수를 받더라도, 특정 축에서 평가가 갈릴 수 있습니다. 그 축이 실제로는 가장 중요한 개선 포인트일 수 있습니다.
이번 테스트에서도 단순히 “몇 점짜리 문서인가”보다 다음 질문이 더 중요했습니다.
- 어떤 축에서 모델들의 판단이 갈리는가?
- 구조 평가자와 리스크 평가자는 같은 부분을 다르게 보는가?
- 높은 점수를 준 패널과 낮은 점수를 준 패널은 무엇을 다르게 봤는가?
- 합의가 된 것처럼 보이는 축은 정말 충분히 검토된 것인가?
즉, 여러 API와 페르소나를 쓰는 이유는 더 그럴듯한 평균 점수를 만들기 위해서가 아니었습니다.
평가가 갈리는 지점을 찾기 위해서였습니다.
### 4. 일부 API 응답 실패도 그대로 기록했습니다
테스트 과정에서 일부 패널은 빈 응답이나 길이 문제로 실패했습니다.
이 부분이 오히려 중요한 운영 포인트였습니다. AI 평가 시스템을 업무에 쓰려면, 실패한 응답을 억지로 해석하면 안 됩니다.
이번에는 실패한 패널을 무리하게 살리지 않고 제외했습니다. 그리고 최종 결과에 “제외 패널”로 기록했습니다.
```text
실패한 AI 응답은 억지로 해석하지 않는다.
유효한 응답만 기준으로 평가하고, 실패는 별도로 기록한다.
```
이 규칙은 생각보다 중요합니다.
AI가 무언가를 반환했다고 해서 항상 평가로 쓸 수 있는 것은 아닙니다. 업무용 평가 시스템이라면 응답 실패, 빈 응답, 형식 오류를 처리하는 기준이 있어야 합니다.
### 5. 아첨 수렴도 점검했습니다
여러 AI가 비슷한 방향으로 빨리 수렴하면 좋아 보일 수 있습니다. 하지만 그것이 항상 좋은 신호는 아닙니다.
정말 근거가 있어서 합의한 것인지, 아니면 다수 의견에 맞춰가는 것처럼 보이는지 확인할 필요가 있습니다.
그래서 R3 단계에서 소수의견을 다시 강화했습니다.
이 과정은 “AI 평가를 더 믿기 위한 장치”였습니다. AI가 내놓은 평가를 그대로 받아들이는 것이 아니라, 평가 과정 자체도 다시 검토한 것입니다.
## ✅ 결과: 완성된 시스템보다, 시도해볼 가치가 있는 아이디어를 확인했습니다
이번 테스트를 통해 정량적인 시간 절약이나 완성된 시스템을 주장할 단계는 아니었습니다.
다만 아이디어로서 시도해볼 가치는 확인했습니다.
테스트 결과, 문서의 강점과 약점이 분리되어 나왔습니다. 특히 일반적인 점수표에서는 뭉개질 수 있는 개선 지점이 드러났습 니다.
예를 들어 문서가 전체적으로는 구조와 수치 정합성에서 좋은 평가를 받을 수 있습니다. 하지만 의사결정자가 보고 나서 무엇을 해야 하는지, 즉 So-what이 부족하다는 식의 지적은 별도로 드러날 수 있습니다.
이런 결과는 평균 점수 하나만 보면 놓치기 쉽습니다.
### Before vs After
- Before: 일반 평가 방식
- 기준표에 따라 점수를 매김
- 최종 점수는 나오지만, 애매한 지점은 묻힐 수 있음
- 단일 평가자의 관점이 크게 반영될 수 있음
- After: 델파이 평가 테스트
- 여러 API·모델·페르소나가 독립 평가
- 점수 차이가 나는 축을 통해 이견 확인
- 실패 패널은 제외하고 기록
- 빠른 합의는 아첨 수렴 가능성까지 점검
- 최종 점수보다 개선 포인트와 평가 쟁점을 확인
## 💬 이 과정에서 배운 AI 활용 팁
### 1. 점수보다 이견을 보세요
AI에게 평가를 맡기면 점수가 나옵니다. 하지만 점수만 보면 중요한 부분을 놓칠 수 있습니다.
여러 평가자가 어디서 갈리는지를 봐야 합니다. 그 이견이 실제 개선 힌트일 수 있습니다.
### 2. 여러 API를 쓰는 이유를 분명히 해야 합니다
여러 모델을 쓰는 목적이 “더 멋진 답변”이면 효과가 약합니다.
이번 테스트에서 여러 API를 쓴 이유는 명확했습니다.
- 관점 오염을 줄이기 위해
- 서로 다른 평가 관점을 얻기 위해
- 모델별 판단 차이를 보기 위해
- 단일 AI의 평가를 그대로 믿지 않기 위해
목적이 분명해야 결과도 해석할 수 있습니다.
### 3. 실패 응답은 실패로 처리해야 합니다
API 오류나 빈 응답이 나오면 억지로 의미를 부여하지 않는 편이 낫습니다.
업무용 자동화에서는 “실패를 감추지 않는 것”도 품질 관리입니다.
### 4. 합의도 다시 의심해볼 필요가 있습니다
여러 AI가 같은 결론을 냈다고 해서 무조건 맞는 것은 아닙니다.
특히 너무 빠르게 합의된 경우에는 다음 질문이 필요합니다.
- 정말 근거가 충분해서 합의했는가?
- 소수의견은 왜 사라졌는가?
- 다수 의견에 맞춘 수렴은 아닌가?
## 🌍 다른 업무에 적용한다면?
이 방식은 보고서뿐 아니라 여러 평가 업무에 적용해볼 수 있습니다.
- 제안서 평가
- 사업계획서 검토
- 보고서 초안 품질 점검
- 내부 발표자료 리뷰
- 심사표 기반 문서 검토
다만 모든 업무에 바로 적용하기보다는, 이번처럼 작은 파일럿부터 시작하는 편이 안전합니다.
중요한 것은 “AI가 평가해줬다”가 아닙니다.
AI 평가를 믿을 수 있도록 평가 구조를 설계하는 것입니다.
## 🚀 앞으로의 계획
다음 단계는 평가 루브릭 고도화입니다.
이번 테스트는 델파이 평가 방식이 문서 평가에서 애매한 지점을 드러낼 수 있는지 확인한 파일럿이었습니다. 이제는 보고서·제안서 유형별로 평가 축을 더 세분화해야 합니다.
모든 문서에 같은 기준을 기계적으로 적용하면 안 됩니다.
예를 들어 현황보고서, 제안서, 의사결정 요청 문서는 목적이 다릅니다. 목적이 다르면 평가 기준도 달라야 합니다.
앞으로는 이번 파일럿에서 확인한 이견 탐지 구조를 바탕으로, 문서 유형별 루브릭을 더 정교하게 설계해볼 계획입니다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 여러 관점으로 문서 평가하기
> 아래 문서를 평가해줘. 단순히 점수만 주지 말고, 평가가 애매한 부분과 판단이 갈릴 수 있는 지점을 찾아줘.
> 평가 기준은 다음 축으로 나눠줘.
> 1. 핵심 메시지 명확성
> 2. 논리와 근거의 정합성
> 3. 의사결정자 관점의 So-what
> 4. 리스크와 반론 커버리지
> 5. 수치 내부 정합성
> 각 축마다 점수, 근거, 애매한 판단 지점을 함께 써줘.
### 프롬프트 2: 점수보다 이견 찾기
> 아래 문서 평가 결과를 보고, 평균 점수보다 평가자 간 이견이 생길 가능성이 높은 축을 찾아줘.
> 특히 어떤 평가자는 높게 보고, 어떤 평가자는 낮게 볼 수 있는 부분을 구분해줘.
> 최종 결론보다 “왜 애매한지”를 중심으로 설명해줘.
### 프롬프트 3: 실패 응답 처리 기준 만들기
> AI 평가 시스템에서 일부 응답이 비어 있거나 형식이 깨졌을 때의 처리 기준을 만들어줘.
> 억지로 해석하지 않고 제외해야 하는 경우, 재시도해야 하는 경우, 최종 결과에 별도 기록해야 하는 경우를 나눠줘.
## 마무리
이번 테스트는 완성된 평가 자동화 시스템을 만든 사례라기보다, 제안서 평가를 고도화하기 위한 아이디어 검증에 가깝습니다.
그래도 의미는 있었습니다.
AI에게 점수를 맡기는 것보다, 여러 AI의 이견을 통해 애매한 부분을 찾는 방식이 더 실무적일 수 있다는 가능성을 확인했기 때문입니다.
보고서나 제안서를 평가해야 하는 실무자라면, AI에게 “몇 점이야?”라고 묻기보다 이렇게 물어보는 편이 더 유용할 수 있습니다.
> “어디서 평가가 갈릴 수 있을까?”
그 질문이 문서를 더 낫게 만드는 출발점일 수 있습니다.
