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

이모지 검출 범위 오류 수정

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

문자

v1

v2 수정

😊 🌟 🎉 🔥 👍

검출

검출

★ ✓ ■ → ※

검출

미검출

참고문헌 검출 로직 흐름

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

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

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

① 구현 범위 보고서

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

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

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

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

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

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

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

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

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

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

결과와 배운 점

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

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

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

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

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

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

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

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

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

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