← 홈으로
RFPilot · 데이터

3주 · 5인 팀 프로젝트 · 데이터 담당

AI가 받은 점수는, 누가 매겼을까?

공공기관 입찰 공고서를 AI가 대신 읽고 답해주는 챗봇 RFPilot을 5명이 함께 만들었습니다. 저는 그중 AI를 채점할 ‘정답지’와 문서에 붙이는 ‘이름표’를 맡았습니다.

100건
입찰 공고서
14,606
문서 조각
1,017
직접 만든 정답
3주
2026.06.17 ~ 07.08
01

이런 제품입니다

공공기관 입찰 공고서는 수백 쪽짜리 한글 파일입니다. 제안서를 쓰려면 사람이 전부 읽어야 했죠. 아래는 팀이 만든 실제 챗봇 화면입니다. “내 데이터 표시”를 켜면 이 화면의 어느 부분이 제 손을 거쳤는지 보입니다.

화면 재현 · 내용은 가명
+ New Chat
대화 이력 제한
10개
검색 방식
CHAT HISTORY
○○공사 ERP 예산

RFPilot

RFP 문서에서 핵심 요구조건·대상기관·예산·제출방식을 빠르게 찾아드립니다.

Chat Terminal
RFP 문서에 대해 무엇이든 물어보세요…
○○공사 통합정보시스템 구축 예산 얼마야?
응답 시간 12.43초 문서 3건 참고
14,107,009,000원
○○ 차세대 통합정보시스템 구축.hwp, 사업개요
참고 문서 3건
[재공고] ○○ 차세대 통합정보시스템(ERP) 구축
△△항만공사 차세대 ERP시스템 구축 사업(재공고)
□□관광공단 경영관리시스템 기능 고도화 용역
입찰 마감일 언제야? 요구사항 전부 뽑아줘 발주기관 어디야?

데이터가 흘러가는 길

팀원 담당 원본 공고서 100건 · HWP 96 / PDF 4 문서 조각 14,606개 본인 담당 이름표 조인 14필드 · 실패 0 정답지 질문 63 · 라벨 954 자동 검사 12축 게이트 채점 검색 · 생성 · 추출 성능 지표 0.940 · 0.905 · 0.886 검색·생성 팀이 이 숫자로 개선 방향을 정함
02

“성능 0.940” ― 이 점수는 어디서 나왔나

시험 점수를 매기려면 정답지가 있어야 합니다. AI도 똑같습니다. 사람이 미리 “정답은 이 문서 이 부분”이라고 정해둔 목록이 없으면 성능은 측정이 안 되는 게 아니라 계산식 자체가 성립하지 않습니다.

정답지 1: 평가 질문 63개를 어떻게 짰나

golden_dataset · 실측
단일 문서20
여러 문서15
이어지는 질문15
거절해야 함13

“거절” 13개는 일부러 넣었습니다 ― 챗봇이 모르는 걸 지어내지 않는지 보려고.

메타에서 자동 생성53 84%
직접 작성10 16%

예산·마감일처럼 계산으로 정답이 나오는 건 자동 생성, 서술형 10개는 손으로 썼습니다. 정답 위치까지 달린 건 50개(거절 13개는 정답 문서가 없는 게 정답).

이 63개가 검색·생성 점수 전부의 분모입니다. 0.940도 0.905도 0.608도 여기서 나옵니다.

03 · 맡은 일 1

이름표 붙이기 ― 흩어진 표기를 하나로

문서마다 발주 기관 이름이 제각각 적혀 있습니다. 사람은 같은 곳인 줄 알지만 AI는 글자가 다르면 다른 곳으로 봅니다. 100건 전부의 기관명·사업명·예산·마감일을 하나의 표기로 정리해 문서 조각 14,606개에 붙였습니다.

(주)○○대학교 산학협력단 입찰공고
○○대학교산학협력단(용역)
○○대 산학협력단
○○대학교 산학협력단
? ? ?
정리된 기관 이름표
예시 · 가명

붙인 이름표가 실제로 몇 칸이나 채워졌나

enriched 청크 14,606개 · 실측
기관명14,606 100%
사업명14,606 100%
입찰 마감일13,535 92.7%
예산13,532 92.6%
공고번호11,877 81.3%
기관 별칭4,840 33.1%

조인 실패는 0건입니다. 빈 칸은 붙이기에 실패한 게 아니라 원본 공고에 그 값이 없던 경우입니다 ― 예산 미공개 7건이 그대로 드러납니다. 별칭 33%는 약칭이 생기는 기관(대학 등)에만 붙였기 때문입니다.

공고 예산은 이렇게 흩어져 있다

100건 · 실측
28
43
12
6
4
7

중앙값 1.96억, 최대 141억. “예산 10억 이상인 사업” 같은 질문의 정답이 이 분포에서 계산됩니다. 1원짜리 이상치 1건은 발견해서 비교·최저 질문에서 뺐습니다.

공고서는 문장이 아니라 표였다

조각 14,606개 · 실측
표 9,793 67.0% 본문 4,713 32.3% 요약 100 0.7%

조각의 3분의 2가 표입니다. 그래서 배점·자격 같은 질문의 정답을 “표 조각”으로 라벨링해야 했고, 자동 검사에도 그 규칙을 넣었습니다.

솔직한 단서 하나 ― 정리 전후로 기관 고유 수는 87개 그대로였습니다. 정규화의 목적은 문서끼리 합치는 게 아니라, 사용자가 입력한 표기를 문서의 표기에 맞추는 것이었으니까요. 11개 기관이 2건 이상 발주했고, 그게 “같은 기관 사업 다 보여줘” 질문의 정답 근거가 됩니다.
경계 이름표를 사용하는 3단계 검색 필터는 검색 담당자가 구현했습니다. 제 몫은 필터가 먹는 재료입니다.

04 · 맡은 일 2

정답지 만들기 ― 954개를 직접 판정했다

앞의 체크리스트 화면이 잘 뽑았는지 채점하려면 항목 단위 정답지가 필요합니다. 공고서 8건을 처음부터 끝까지 읽으며 하나하나 판정했습니다. 기준은 하나 ― “입찰에 참여하는 회사가 알고 대비해야 할 일인가?”

직접 해보세요. 네 항목 중 채점 대상은 몇 개일까요? 예시 · 가명

공고서 8건, 954개 항목의 실제 구성

v5_gold_labels · 실측
공고서 A183 /경계 12
공고서 B149 /경계 9
공고서 C149 /경계 1
공고서 D126 /경계 10
공고서 E94 /경계 7
공고서 F92 /경계 7
공고서 G86 /경계 8
공고서 H75 /경계 8
채점 대상 937 대상 아님 17 문서 이름은 가명 · 개수는 실측

같은 “공공 입찰 공고서”인데 항목 수가 75개에서 183개까지 2.4배 차이 납니다. 그래서 한 문서만 보고 “이 정도면 되겠지” 하면 안 되고, 8건을 전수로 읽어야 했습니다.

954개를 무엇으로 갈랐나

실측
지켜야 할 일716
내야 할 서류202
점수 받는 기준36

판정 근거를 원문에 그대로 적힌 것 790개와 맥락으로 읽어낸 것 147개로 나눠 기록했습니다 ― 나중에 다투게 될 항목을 미리 표시해두려고.

갈릴 만한 62개는 두 사람이 따로 판정

두 사람 일치율 · 실측
채점 대상 여부1.000
누가 할 일인가0.941
중요도 6단계0.457

채점에 실제로 쓰는 축은 완전 일치라 점수를 믿을 수 있습니다. 반면 중요도는 일치율이 낮아 점수에서 빼고 기록용으로만 남겼습니다. 공동 작업

05 · 맡은 일 3

정답지가 조용히 망가지는 순간

정답지는 “몇 번째 문서 조각”으로 정답 위치를 가리킵니다. 팀이 문서 자르는 방식을 바꾸면 그 번호가 통째로 어긋납니다. 정답지는 멀쩡해 보이는데 엉뚱한 곳을 가리키게 되죠. 눈으로는 못 잡습니다. 그래서 자동 검사를 만들었습니다.

정답지가 가리키는 위치
공고서 61번 · 조각 #248
실제 그 자리에 있는 내용
자동 검사 12가지 전체 보기
01항목 개수·문서 수가 그대로인가
0213개 정보 칸이 빠짐없이 채워졌나
03정해둔 값만 쓰였나 (오타·임의 값 차단)
04문서 자른 버전이 정답지와 같은가
05가리키는 조각이 실제로 존재하는가
06“누가 할 일인가”와 채점 대상 판정이 맞물리나
07최종 판정이 채점 대상과 어긋나지 않나
08대상 아닌 항목에 중요도가 잘못 붙지 않았나
09허용된 분류 안에서 골랐나
10같은 항목이 중복 등록되지 않았나
11인용한 문장이 원문에 실제로 있나
12확정 당시 통계와 지금이 일치하나

참고용 검사 1가지를 더해 13가지. 하나라도 걸리면 스크립트가 실패를 반환하고 그 아래 채점 작업을 아예 돌리지 않습니다.

06

결과

각 칸에 마우스를 올리면 그 점수를 매기는 데 쓰인 정답지가 선명해집니다. 전부 제가 만든 정답지 위에서 나온 숫자입니다.

거절 질문 13개는 위 점수의 분모에서 빠지고, “제대로 거절했는가”를 따로 채점하는 데 쓰입니다. 의무항목 추출의 문서별 성적은 0.831~0.922 범위로 안정적이었습니다(개별 문서 수치는 비공개).

07

숨기지 않는 숫자

0.286

정확도가 낮아 보이는 이유

챗봇은 문서 하나에서 480~1,706개 항목을 뽑습니다. 제 정답지는 같은 문서를 75~183개로 묶어 정리했고요. 잘게 쪼갠 쪽을 묶어 센 쪽으로 나눈 값이라 낮게 나옵니다. 틀린 게 아니라 세는 단위가 다른 것이고, 그걸 숫자로 확인한 게 이번 정답지의 성과입니다.

0.457

기준을 늦게 정했다

중요도 6단계는 두 사람의 판정이 충분히 모이지 않았습니다. 그래서 점수에서 뺐습니다. 다시 한다면 판정을 시작하기 전에 기준 예시를 더 많이 고정해두겠습니다.

8 / 100

정답지는 8건뿐

100건을 전부 채점하려면 약 18시간이 걸려 8건을 골라 썼습니다. “공고서 전반에서 89%를 찾아낸다”고 말할 수 있는 근거는 여기까지입니다.

3주 동안 배운 것

  • 측정할 수 없으면 개선했는지도 모른다. 정답지가 늦으면 팀 전체가 감으로 일하게 된다.
  • 기준 데이터는 하나로 고정해야 한다. 원본이 여러 개면 정답이 조용히 어긋난다.
  • 검사는 사람이 아니라 스크립트가 해야 한다. 눈으로 하는 검수는 세 번째부터 안 하게 된다.
08

역할

PM DE ― 문서 쪼개기 · 의무항목 추출 DE ― 이름표 · 정답지 (본인) RE ― 검색 SD ― 답변 · 챗봇 화면

직접 만든 것

  • 정답지 빌더 ― 평가 질문 63개 자동 생성
  • 정답지 954개 판정 (공고서 8건 전수)
  • 무결성 자동 검사 12가지
  • 문서 이름표 14종 + 조각 14,606개 조인
  • 개인정보 가리기 (연락처·주민번호 등)

같이 한 것

  • 갈리는 항목 62건 이중 판정·일치율 ― 다른 DE와
  • 의무항목 채점 ― 정답지는 본인, 실행 코드는 팀원
  • 이름표 붙인 문서 조각 ― 조각내기는 팀원

팀원이 만든 것

  • 문서 쪼개기 · 품질 검사 · 마스킹 검증 테스트
  • 검색 엔진과 기관명 3단계 필터 구현
  • 챗봇 파이프라인 · 답변 생성 · 웹 화면