OOOO 보고서 AI 검증 도구, MVP 개발 의뢰에서 계약서 완성까지

소개

상급기관에 제출할 OOOO 보고서 심사가 촉박하게 다가오던 중, 공공기관 A 교육운영팀 이수진 담당자(가명)로부터 뜻밖의 연락을 받았다. 보고서에 생성형 AI가 무단으로 활용된 것으로 의심되는 사례가 다수 발견되었고, 자체 검증 도구가 필요하다는 내용이었다. OOOO 자격으로 자문을 요청받은 나는 약 21분간의 통화를 통해 상황을 파악하고, 실제 개발 가능성과 비용 구조를 검토한 뒤 MVP 기획-개발-산출물까지 전 과정을 함께 정리했다.

이 글에서는 그 과정 전체를 단계별로 공유한다. 특히 AI 도구를 활용해 공공기관 업무 자동화 도구를 만드는 과정에서 겪을 수 있는 현실적 한계와 해결 방식을 솔직하게 담았다.

1. 배경 — 통화로 시작된 의뢰

공공기관 A(가명)는 소속 직원들이 제출한 OOOO 보고서(1인당 약 100페이지, 총 30여 건)에서 생성형 AI 무단 활용이 의심되는 정황을 포착했다. 문제는 상급기관 제출 기한이 3월 말로 촉박하게 다가왔다는 점이었다. 담당자 이수진은 빠른 자체 검증 방법을 찾고 있었다.

2. 요구사항 분석 — 할 수 있는 것과 없는 것

이수진 담당자가 요청한 검증 항목은 네 가지였다. 나는 통화 직후 각 항목의 기술적 구현 가능성을 솔직하게 분석했다. AI 도구의 특성상 과장된 기대치를 그대로 수용하는 것은 이후 신뢰 문제로 이어질 수 있기 때문이다.

중요한 전제를 이수진 담당자에게 명확히 전달했다. AI 탐지 도구의 결과는 어디까지나 참고 지표이며, 현재 어떤 AI 탐지 도구도 법적·행정적 증거 능력을 공식적으로 인정받은 것은 없다. 인사 조치의 근거로 사용하려면 반드시 별도의 검증 절차가 병행되어야 한다.

3. MVP 기획 — 세 가지 질문으로 방향 확정

기획서를 작성하기 전에 세 가지 핵심 질문의 답변을 먼저 받았다.

이 세 가지를 확정한 뒤 MVP 기획서를 완성했다. 제품의 목표는 단 하나였다.

담당자가 보고서(PDF/DOCX)를 업로드하면 이모지 건수, AI 작성 여부(%), 참고문헌 형식 오류를 자동으로 집계해 '기관 자체 검증 수행' 근거 자료를 생성하는 최소 기능 웹 도구

기능 상세

모듈 A: 이모지 검출

유니코드 BMP 외부 영역(U+1F000 이상)의 이모지만 탐지하도록 정밀하게 범위를 설정했다. ★, ✓, ■, → 같은 특수기호는 검출 대상에서 제외했다. 기술적 이유는 U+2600~U+27BF 블록이 이모지처럼 보이지만 실제로는 특수기호가 혼재하는 영역이기 때문이다.

검출 O: 😊 🌟 🎉 🔥 👍   |   검출 X: ★ ✓ ■ → ※

모듈 B: AI 사용 여부 탐지

제로GPT, X-Detector 등 외부 AI 탐지 API를 활용해 문서 전체의 AI 작성 비율(%)을 산출한다. 단, 결과 화면에 신뢰도 주의 문구를 반드시 함께 표시하도록 설계했다.

모듈 C: 참고문헌 형식 오류 검출

정규식(Regex) 기반으로 다음 네 가지 규칙을 검사한다.

한 가지 솔직한 한계: 이 방식은 형식만 검사하지 내용은 보지 않는다. '홍길동 (2099). 존재하지 않는 논문.'처럼 연도와 형식이 맞아도 가짜 참고문헌은 잡아내지 못한다. 내용 진위 확인은 담당자가 직접 해야 한다.

4. 개발 과정 — 주요 이슈와 해결

이모지 검출 범위 오류 수정

초기 버전(v1)은 특수기호(★✓■→)까지 함께 검출하는 문제가 있었다. U+2600~U+27BF 블록 전체를 이모지로 처리했기 때문이다. 이 범위를 제거하고 진짜 이모지가 위치한 U+1F000 이상의 BMP 외부 영역만 탐지하도록 수정해 v2를 배포했다.

참고문헌 검출 로직 흐름

전체 로직은 세 단계로 구성된다.

1단계: 텍스트에서 '참고문헌', 'References' 등의 헤더를 정규식으로 찾아 해당 섹션을 분리
2단계: 분리된 섹션을 [1], [2] 패턴으로 개별 항목으로 파싱
3단계: 각 항목에 대해 4가지 형식 규칙 순차 적용 → 오류 항목 리스트업

주목할 점은 외부 API, 사전, AI 모델을 전혀 사용하지 않는다는 것이다. 순수 정규식 패턴 매칭만으로 동작하기 때문에 비용 없이 완전 로컬 처리가 가능하다.

5. 산출물 — 세 가지 문서

① 구현 범위 보고서

개발 완료 후 이수진 담당자에게 전달할 구현 범위 보고서를 작성했다. 총 8개 챕터로 구성했으며 핵심은 다음과 같다.

• 완전 로컬 처리 원칙 — 보고서 데이터가 외부 서버로 전송되지 않음

• 구현 완료 항목과 미구현 항목의 명확한 구분

• 검증 결과를 인사 조치에 활용할 경우 반드시 필요한 4단계 절차

• 향후 개선 가능 기능 (난이도별)

② 수의계약서 (계약서 A)

정식 소프트웨어 납품 계약이 필요한 경우를 대비해 작성했다. 기관 예산으로 대금을 지급받는 공식 경로다. 반드시 사전에 확인해야 할 사항이 있다.

③ 업무위탁 계약서 (계약서 B)

공식 예산 없이 개인 자금으로 처리하는 민간 사적 계약 방식이다. 원천징수(3.3%) 조항과 함께 핵심 면책 조항을 반드시 포함해야 한다.

두 계약서 모두 MVP의 구현 범위(이모지 검출, 참고문헌 형식 오류 검출)와 미구현 항목(AI 탐지 정밀도 한계, 허위 참고문헌 내용 검증 불가, 환각 검출 불가)을 표 형태로 명시했다.

결과와 배운 점

요즘 생성형 AI가 못하는 게 있다. 실제 발로 뛰는 영업이다.

바이브 코더는 넘쳐나지만, 만들어진 솔루션을 팔 판매처를 찾는 사람은 드물다. 고객이 원하는 것을 즉시 만들어줄 수 있는 시대가 됐지만, 그런 고객을 직접 발굴하고 문제를 포착해 의뢰로 연결하는 사람은 극히 적다. 이번 의뢰도 그랬다. 기술보다 먼저 필요한 것은 현장에서 문제를 발견하는 눈이었다.

이 프로젝트에서 얻은 교훈을 세 가지로 정리했다.

1. 고객 발굴이 곧 경쟁력이다

간단한 솔루션이라도 실제 문제를 해결하면 수익으로 이어진다. 이모지 검출과 참고문헌 형식 오류 검출은 기술적으로 단순하다. 하지만 '기한 안에 자체 검증 근거가 필요하다'는 현장의 절박함을 포착했기 때문에 의뢰를 받을 수 있었다. 생성형 AI 시대에 기술 구현 능력은 더 이상 희소하지 않다. 희소한 것은 고객을 찾아내는 능력이다.

2. 기술적 정직함이 신뢰를 만든다

AI 탐지 도구의 한계를 처음부터 솔직하게 전달했다. '100% 탐지 가능하다'는 기대치를 그대로 수용하지 않고, 각 항목의 신뢰도와 법적 한계를 명확히 설명한 것이 오히려 의뢰인의 신뢰를 높였다. 과장된 약속은 짧은 계약 하나를 따낼 수 있어도 다음 의뢰로 이어지지 않는다.

3. 계약서는 면책 조항이 핵심이다

AI 도구의 출력 결과를 행정 판단에 활용하는 경우, 개발자가 예상치 못한 법적 책임을 지는 상황이 발생할 수 있다. 계약서에서 '결과 활용에 따른 책임 귀속'을 명확히 명시하는 것은 선택이 아니라 필수다.

생성형 AI 시대에 또 하나의 경쟁력은 기술이 아니라 현장을 찾아가는 발이 아닐까.