“실력만 보면 되죠?” AI R&D 외주 계약이 흔들리는 이유

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

발표 자료에서는 높은 정확도를 보여주던 AI 모델이 실제 현장에서는 제대로 작동하지 않는 경우가 있습니다. 기술력이 부족해서일 수도 있지만, 더 흔한 원인은 AI R&D 외주 계약에서 목표와 검수 조건을 구체적으로 정하지 않았기 때문입니다.

제안서에 ‘최적의 모델 개발’, ‘고도화 지원’, ‘성능 개선’이라는 표현만 있다면 잠시 멈춰야 합니다. 발주 조직과 수행사가 서로 다른 완성품을 상상한 채 프로젝트를 시작할 가능성이 크기 때문입니다. 아래 점검 항목은 제안 요청, 업체 선정, 계약 협의, 중간 검수, 최종 인수 단계에서 그대로 활용할 수 있습니다.

업체를 만나기 전에 내부 요구부터 숫자로 바꿉니다

‘좋은 AI’보다 해결할 업무를 먼저 적습니다

외주 업체를 고르기 전에 가장 먼저 확인할 것은 알고리즘이나 GPU 사양이 아닙니다. 누가 어떤 상황에서 무엇을 더 빠르고 정확하게 판단하려는지를 한 문장으로 설명할 수 있어야 합니다. 예를 들어 ‘불량을 판별하는 AI’보다 ‘검사자가 하루 3천 개의 부품 사진에서 균열 의심 대상을 우선 검토하도록 돕는 AI’가 훨씬 명확합니다.

목표가 모호하면 수행사는 구현하기 쉬운 지표를 선택하고, 발주자는 체감할 수 있는 업무 성과를 기대하게 됩니다. 분류 정확도 95%를 달성해도 놓치면 안 되는 결함을 반복해서 누락한다면 현장에서는 사용할 수 없습니다. 모델 성능과 업무 성과는 같은 말이 아니라는 점을 요구사항 작성 단계에서 구분해야 합니다.

착수 전 내부 합의 점검표

• 사용자: 연구원, 검사자, 상담원, 관리자 중 실제 결과를 확인할 사람을 지정합니다.
• 입력: 이미지, 문서, 센서값 등 투입 데이터의 형식과 월평균 발생량을 기록합니다.
• 출력: 분류 결과, 확률값, 요약문, 경보 등 필요한 결과 형태를 정합니다.
• 허용 오류: 오탐과 미탐 중 어느 쪽이 더 위험한지 우선순위를 정합니다.
• 운영 환경: 사내 서버, 클라우드, 현장 장비 중 배포 위치와 통신 제약을 확인합니다.
• 판정 책임: AI가 자동 처리할 범위와 사람이 최종 승인할 범위를 나눕니다.

팁: 요구사항을 읽은 비전공자가 ‘언제 성공으로 인정하는가’를 설명하지 못한다면 계약서에 넣기에는 아직 모호한 문장입니다.

기관형 연구개발 조직의 역할과 운영 맥락을 살펴볼 때는 한국과학기술연구원 소개 자료처럼 공신력 있는 기관 정보를 참고할 수 있습니다. 다만 다른 기관의 구조를 그대로 복제하기보다 이번 과제의 사용자와 의사결정 구조에 맞게 요구사항을 좁히는 것이 중요합니다.

제안서의 화려한 성능 수치는 같은 조건에서 비교합니다

포트폴리오보다 재현 조건을 질문합니다

후보 업체가 ‘정확도 98% 달성 경험’을 제시했다면 데이터 규모, 클래스 비율, 평가 데이터의 분리 방식부터 물어야 합니다. 학습에 사용한 대상과 거의 같은 데이터로 시험했거나 쉬운 정상 사례가 대부분이었다면 숫자가 높아도 이번 업무의 난도를 설명하지 못합니다. 특히 시계열 데이터는 미래 데이터를 학습 과정에 섞는 누수가 발생하기 쉬우며, 이미지 데이터는 동일한 제품을 촬영한 유사 사진이 학습 세트와 평가 세트에 동시에 포함될 수 있습니다.

생성형 AI 과제라면 단일 정확도 대신 사실성, 근거 제시, 유해 응답, 지시 준수, 응답 시간, 호출 비용을 함께 봐야 합니다. 업체가 자체 제작한 평가 문항만 사용하면 유리한 결과가 나올 수 있으므로, 발주자가 보유한 비공개 검증 세트와 실제 사용자가 만든 시나리오를 별도로 준비하는 편이 안전합니다.

제안 업체별 동일 질문

1. 제시한 성능은 어떤 데이터와 하드웨어에서 측정했습니까?
2. 학습·검증·시험 데이터는 어떤 기준으로 분리했습니까?
3. 평균값뿐 아니라 클래스별 정밀도와 재현율을 제공할 수 있습니까?
4. 같은 코드와 환경으로 발주자가 결과를 재현할 수 있습니까?
5. 기준 모델보다 성능이 낮을 때 어떤 개선 절차를 적용합니까?
6. 응답 지연 시간과 월간 추론 비용은 어느 조건에서 계산했습니까?

비교표에는 ‘기술 우수’, ‘경험 풍부’ 같은 주관적인 문구보다 증빙 가능한 항목을 넣습니다. 예를 들어 유사 프로젝트 20점, 재현 시험 25점, 운영 설계 20점, 보안 15점, 인수인계 10점, 가격 10점처럼 배점을 사전에 고정하면 발표를 잘하는 업체에 평가가 쏠리는 현상을 줄일 수 있습니다.

• 확인 자료: 익명화된 결과 보고서, 평가 코드, 시스템 구성도, 장애 대응 사례
• 주의 신호: 데이터 확인 전 성능 보장, 근거 없는 비용 절감률, 특정 인력 의존
• 우선 협상: 핵심 연구자의 실제 투입률과 교체 시 승인 절차

AI R&D 외주 계약서는 산출물과 권리를 분리해 읽습니다

‘소스코드 일체’라는 표현으로는 부족합니다

AI 프로젝트의 산출물은 실행 파일 하나가 아닙니다. 데이터 전처리 코드, 학습 코드, 추론 코드, 모델 가중치, 프롬프트, 평가 문항, 환경 설정, API 문서, 운영 절차서가 서로 연결됩니다. 계약서에 ‘개발 결과물 일체를 납품한다’고만 쓰면 수행사는 서비스 접속 권한만 제공하고, 발주자는 재학습 가능한 전체 소스를 기대하는 분쟁이 생길 수 있습니다.

각 산출물에는 파일 형식, 제출 시점, 저장 위치, 검수 방법을 붙여야 합니다. 예를 들어 모델 파일은 특정 프레임워크 버전에서 로딩되어야 하고, 소스코드는 빈 환경에서 설치 문서대로 실행되어야 하며, 데이터 목록에는 원천·가공·삭제 여부가 표시되어야 합니다. 문서를 받았다는 사실이 아니라 독립적으로 다시 실행할 수 있는지가 인수 기준입니다.

계약 전 권리 관계 점검표

• 배경 지식재산: 업체가 기존에 보유한 라이브러리와 이번 과제에서 새로 만든 부분을 구분합니다.
• 모델 권리: 가중치의 소유권, 사용 지역, 사용 기간, 재학습 및 수정 가능 여부를 명시합니다.
• 데이터 권리: 발주 데이터의 재사용, 보관, 제3자 제공, 계약 종료 후 삭제 조건을 정합니다.
• 오픈소스: 라이선스 이름과 버전, 상업 이용 가능 여부, 고지 의무를 목록으로 받습니다.
• 외부 API: 서비스 중단이나 가격 변경 시 대체 방안과 데이터 전송 범위를 확인합니다.
• 성과 공개: 논문, 학회 발표, 포트폴리오 공개 전에 서면 승인을 받도록 정합니다.

기술기업 정보를 검토할 때는 기업명이나 소개 문구만 보지 말고 사업 내용과 기술 분야를 구분해서 살펴야 합니다. 예컨대 우리기술 기업 정보와 같은 공개 자료는 법인과 사업 영역을 확인하는 보조 근거가 될 수 있지만, 현재 투입 인력의 역량이나 납품 능력을 대신 증명하지는 않습니다.

전문가 조언: 지식재산권 조항은 ‘누가 소유하는가’뿐 아니라 누가 복제·수정·재판매·추가 학습할 수 있는지까지 동사로 풀어 쓰는 편이 좋습니다.

견적을 비교할 때도 개발비만 보면 안 됩니다. 클라우드 사용료, 상용 API 호출료, 데이터 구매비, 보안 인증 대응비, 배포 후 유지보수비가 별도인지 확인하십시오. 최초 견적은 낮지만 매월 사용량에 따라 비용이 급증하는 구조라면 1년 총소유비용이 더 커질 수 있습니다.

중간 검수는 완성품 시연보다 실패 사례를 먼저 봅니다

단계별 통과 기준을 계약 일정에 넣습니다

최종 발표일까지 기다렸다가 문제를 발견하면 데이터 수집이나 구조 설계를 되돌릴 시간이 없습니다. 따라서 착수, 데이터 진단, 기준 모델, 고도화 모델, 운영 시험의 다섯 관문으로 나누고 각 단계에서 계속 진행할 조건을 정하는 것이 좋습니다. 데이터가 예상보다 부족한 경우에는 무리하게 개발을 밀어붙이지 않고 범위 조정이나 추가 수집을 결정할 수 있어야 합니다.

중간 검수에서는 가장 잘 작동하는 화면보다 실패 사례 20건과 그 원인 분류를 요청하십시오. 조명 변화 때문에 틀렸는지, 특정 문서 양식을 읽지 못했는지, 학습 데이터가 부족했는지에 따라 처방이 달라집니다. 실패 원인을 설명하지 못한 채 데이터만 더 넣겠다는 제안은 비용과 일정이 끝없이 늘어나는 신호가 될 수 있습니다.

단계별 제출물과 판정 항목

1. 착수 단계: 범위표, 책임자, 일정, 위험 목록과 의사소통 채널을 확인합니다.
2. 데이터 진단: 결측치, 중복, 편향, 개인정보, 라벨 오류와 활용 불가 데이터를 보고받습니다.
3. 기준 모델: 단순 규칙이나 기존 모델과 비교해 AI 개발의 추가 효용을 검증합니다.
4. 고도화 단계: 전체 평균뿐 아니라 중요한 사용자군과 오류 유형별 성능을 확인합니다.
5. 운영 시험: 실제 장비에서 속도, 장애 복구, 동시 사용자, 비용을 측정합니다.
6. 최종 인수: 발주자 담당자가 문서만 보고 설치·실행·복구하는 시험을 진행합니다.

검수 결과는 통과와 실패만으로 기록하지 말고 ‘통과’, ‘조건부 통과’, ‘재시험’으로 나누는 방식이 실용적입니다. 조건부 통과에는 수정 항목, 책임자, 기한, 재검증 데이터를 함께 적습니다. 구두 약속이나 회의 화면에만 남은 내용은 담당자가 교체되면 추적하기 어려우므로 회의록과 이슈 목록에 연결해야 합니다.

• 주간 확인: 완료 작업, 다음 작업, 결정이 필요한 문제, 예산 변동
• 월간 확인: 성능 추세, 데이터 변경, 보안 이슈, 일정 및 비용 전망
• 변경 요청: 요청 사유, 영향 범위, 추가 비용, 납기 변화, 승인권자

유명 업체보다 작은 전문팀이 더 나을 때도 있습니다

규모와 안정성만으로 최종 순위를 정하지 않습니다

대형 업체는 인력 대체, 프로젝트 관리, 보안 절차에서 장점이 있지만 핵심 개발을 하도급하거나 주니어 인력 중심으로 운영할 가능성도 있습니다. 반대로 작은 전문팀은 특정 산업 데이터와 모델 구조를 깊이 이해하고 의사결정이 빠를 수 있으나, 한 명의 퇴사나 장기 부재가 일정 전체에 영향을 줄 수 있습니다. 따라서 회사 규모 대신 이번 과제에 실제로 투입되는 사람과 대체 가능한 운영 구조를 평가해야 합니다.

낮은 가격을 무조건 위험 신호로 볼 필요도 없습니다. 이미 검증된 모듈을 보유했거나 과제 범위를 정확히 좁힌 업체라면 합리적인 비용을 제시할 수 있습니다. 반대로 높은 견적이 반드시 높은 품질을 뜻하지도 않습니다. 관리 인력과 영업 비용이 포함됐을 수 있으므로 역할별 투입 시간, 외부 서비스 비용, 유지보수 범위를 나눠 비교해야 합니다.

최종 협상에서 선택지를 남기는 방법

• 짧은 유상 사전 검증: 2~4주 동안 일부 데이터로 재현성과 협업 방식을 확인합니다.
• 단계 계약: 데이터 진단 결과가 기준에 미달하면 개발 단계에 들어가기 전에 중단하거나 범위를 바꿉니다.
• 핵심 인력 지정: 제안 발표자가 실제로 참여하는지와 최소 투입률을 계약에 반영합니다.
• 대체 인력 조건: 동급 경력자의 사전 승인 없는 교체를 제한하고 인수인계 기간을 확보합니다.
• 종료 지원: 계약 해지 시 코드, 데이터, 계정, 문서의 이전 기한과 지원 시간을 정합니다.
• 보증 이후 선택권: 유지보수를 기존 업체에 맡기거나 내부·제3자가 수행할 수 있도록 기술 종속을 줄입니다.

일부 조직은 세밀한 계약 조건이 혁신 속도를 늦춘다고 말합니다. 실제로 탐색적 연구에 고정된 성능 수치를 강제하면 새로운 접근을 막을 수 있습니다. 이런 과제에서는 최종 정확도를 미리 확정하기보다 실험 횟수, 비교 기준, 중단 조건, 결과 기록처럼 연구 과정의 품질을 검수 대상으로 삼는 편이 타당합니다.

반대 관점도 계약에 흡수할 수 있습니다. 핵심 안전·보안·권리 조건은 고정하되 모델 구조와 실험 방법은 수행사가 제안하도록 자율 영역을 남기는 방식입니다. 그러면 발주자는 통제해야 할 위험을 관리하고, 수행사는 전문성을 발휘할 공간을 확보합니다. 결국 좋은 AI R&D 외주 업체는 모든 답을 미리 안다고 주장하는 곳보다, 불확실성을 드러내고 단계별 판단 근거를 함께 설계하는 곳에 가깝습니다.