AI R&D 공동연구 파트너를 처음 선정한다면

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

기술은 매력적인데 함께 연구해도 될 회사인지 판단하기 어렵고, 제안서는 화려한데 실제 개발 인력이 보이지 않는 경우가 있습니다. 특히 AI R&D 공동연구는 계약서에 서명한 뒤에야 데이터 반출 제한, 모델 소유권, 추가 비용 같은 문제가 드러나기 쉽습니다.

이번 인터뷰에서는 기업·연구기관의 기술사업화 프로젝트를 자문해 온 기술협력 컨설턴트 문세린에게 파트너 검증 방법을 물었습니다. 특정 업체를 추천하기보다, 처음 공동연구를 추진하는 실무자가 제안 단계에서 확인해야 할 근거와 질문에 집중했습니다.

Q. 좋은 AI R&D 파트너는 제안서에서 어떻게 드러납니까?

A. 기술 명칭보다 문제를 정의하는 문장을 먼저 보세요

문세린 컨설턴트는 제안서 첫 장의 기술 스택보다 해결하려는 업무 문제가 얼마나 구체적인지 확인하라고 말합니다. 좋은 파트너는 “생성형 AI를 도입한다”는 표현에 머물지 않고, 어느 사용자가 어떤 자료를 입력하며 현재 몇 분 걸리는 작업을 어느 수준까지 줄일 것인지 설명합니다. 성능 목표도 단순 정확도 하나가 아니라 오탐과 미탐 중 무엇이 사업에 더 위험한지 구분합니다.

예를 들어 제조 이상 탐지라면 “정확도 95%”보다 불량 유출률, 정상 제품의 오판 비율, 설비별 데이터 편차를 함께 제시해야 합니다. 사내 문서 검색이라면 답변 품질뿐 아니라 근거 문서 표시율, 접근권한 위반 가능성, 답변을 거부해야 하는 조건이 들어가야 합니다. 독자의 제안서에는 이런 운영 상황이 수치로 적혀 있습니까?

• 문제 범위: 적용 부서, 사용자, 입력 데이터와 출력 결과가 명시돼 있는지 확인합니다.
• 기준선: 현재 업무 시간이나 기존 모델 성능처럼 개선 전 수치가 있는지 봅니다.
• 실패 조건: 모델이 틀렸을 때 발생할 비용과 사람이 개입할 지점을 묻습니다.
• 제외 범위: 이번 연구에서 하지 않을 기능까지 문서에 적도록 요청합니다.

A. 자체 인력과 외부 솔루션의 경계를 질문해야 합니다

제안서에 등장하는 기술이 모두 파트너의 자체 역량이라고 가정하면 안 됩니다. 상용 API, 오픈소스 모델, 외부 데이터, 재위탁 인력이 각각 어디에 쓰이는지 물어야 유지비와 지식재산권을 예측할 수 있습니다. 특히 데모 화면만 보고 계약하면 실제 구축 단계에서 API 사용료, 보안형 인프라, 데이터 정제 작업이 별도 견적으로 붙을 수 있습니다.

“좋은 답변은 ‘다 할 수 있습니다’가 아니라 자체 개발 영역, 제3자 의존 영역, 아직 검증되지 않은 영역을 나눠 설명합니다.”

1. 제안 기능별로 자체 개발, 상용 서비스, 오픈소스를 구분해 달라고 요청합니다.
2. 핵심 개발자 이름 대신 역할, 투입률, 유사 과제 수행 범위를 확인합니다.
3. 담당자가 교체될 때 인수인계 기간과 산출물 기준을 계약 전 합의합니다.
4. 데모에 사용한 데이터와 실제 운영 데이터의 차이를 기록합니다.

Q. 회사 규모와 유명 레퍼런스만 믿으면 왜 위험한가요?

A. 법인 실체와 실제 수행 조직은 별도로 확인해야 합니다

상호가 익숙하거나 비슷하다는 이유만으로 특정 기관과의 관계를 추정해서는 안 됩니다. 실사 단계에서는 사업자등록증의 법인명, 계약 당사자, 세금계산서 발행 주체, 실제 연구 인력의 소속을 서로 대조해야 합니다. 명칭 확인이 필요할 때는 지식백과의 (주)우리기술 항목이나 한국과학기술연구원 기관 정보처럼 공개된 자료를 참고할 수 있습니다. 다만 이런 자료는 출발점일 뿐이며 최신 법인등기, 사업자 상태와 계약 권한은 별도로 확인해야 합니다.

레퍼런스도 고객사 로고의 개수보다 담당 범위를 봐야 합니다. 한 프로젝트에서 데이터 수집만 맡은 회사가 전체 AI 시스템을 구축한 것처럼 소개할 수도 있고, 반대로 규모가 작은 파트너라도 핵심 모델 검증을 책임졌을 수 있습니다. 따라서 “이 고객과 일했다”가 아니라 어떤 문제를 어떤 기간에 어느 인력으로 해결했는지를 질문해야 합니다.

• 계약서 법인명과 제안서·견적서의 상호가 일치하는지 확인합니다.
• 프로젝트 책임자가 해당 법인 소속인지, 프리랜서나 재위탁 인력인지 구분합니다.
• 레퍼런스 고객에게 공개 가능한 성능 지표와 운영 기간을 요청합니다.
• 협력 종료 후에도 시스템을 유지할 상근 인력이 있는지 살펴봅니다.
• 특허와 논문은 보유 여부뿐 아니라 이번 과제와의 직접적인 관련성을 검토합니다.

A. 인터뷰에서는 과거의 실패를 설명해 달라고 하세요

성공 사례는 영업 자료로 정리돼 있지만 실패 경험은 실제 역량을 더 선명하게 보여줍니다. “최근 과제에서 예상보다 오래 걸린 단계는 무엇이었습니까?”, “초기 가설을 폐기한 근거는 무엇입니까?”라고 질문해 보세요. 원인을 데이터, 모델, 인프라, 커뮤니케이션으로 나눠 설명하고 이후 절차를 바꾼 파트너라면 연구 불확실성을 관리해 본 조직일 가능성이 큽니다.

반대로 모든 실패를 고객 데이터 탓으로 돌리거나 구체적인 기록 없이 “유연하게 대응했다”고만 답한다면 주의해야 합니다. 실패 자체보다 위험한 것은 실패를 재현하고 학습할 체계가 없는 상태입니다. 회의록, 실험 기록, 변경 이력 중 익명화된 예시 한 건을 보여 달라고 요청하면 문서화 수준도 확인할 수 있습니다.

1. 예상과 달랐던 가설 한 가지를 설명하도록 요청합니다.
2. 중단 기준을 누가, 어떤 수치로 결정했는지 질문합니다.
3. 실패 후 일정과 예산을 어떻게 재산정했는지 확인합니다.
4. 같은 문제가 재발하지 않도록 추가한 절차가 무엇인지 듣습니다.

Q. 공동연구 범위와 비용은 어느 수준까지 쪼개야 합니까?

A. 총액보다 단계별 의사결정 비용을 봐야 합니다

AI R&D 견적은 데이터 상태를 확인하기 전과 후가 크게 달라질 수 있습니다. 그래서 처음부터 하나의 총액으로 고정하기보다 진단, 데이터 준비, 기준 모델, 고도화, 운영 검증으로 단계를 나누는 편이 안전합니다. 각 단계가 끝날 때 계속 투자할지, 범위를 줄일지, 중단할지를 판단할 수 있어야 합니다.

비용은 과제 난도와 데이터 보안 수준에 따라 편차가 매우 크므로 특정 금액만으로 적정성을 판단하기 어렵습니다. 다만 소규모 사전 진단은 수백만 원대, 제한된 데이터로 수행하는 PoC는 수천만 원대, 보안 인프라와 운영 연동까지 포함된 구축은 수천만 원에서 수억 원 이상으로 커질 수 있습니다. 이 수치는 계약 기준이 아니라 예산 대화를 시작하기 위한 범위이며, 인건비·클라우드·라이선스·라벨링·유지보수의 포함 여부가 실제 비교의 핵심입니다.

A. 변경 요청의 가격표를 계약 전에 만드세요

공동연구에서는 요구사항이 바뀌는 것이 정상입니다. 문제는 변경 자체가 아니라 비용과 일정에 미치는 영향을 기록하지 않는 데서 생깁니다. 데이터 소스 추가, 평가 지표 변경, 사용자 화면 추가, 외부 시스템 연동처럼 자주 생기는 요청을 미리 분류하고 산정 방식을 합의해야 합니다.

고정가 계약이라도 무제한 수정이 포함되는 것은 아닙니다. 월별 투입 인력 기준인지, 기능 단위인지, 승인된 변경서 기준인지 확인하고 구두 요청은 정식 범위에 자동 포함되지 않도록 절차를 둡니다. 투자 관점의 협력 구조를 조사한다면 현대기술투자(주) 관련 공개 정보처럼 조직의 성격을 확인할 자료도 참고할 수 있지만, 연구용역 계약과 투자 계약은 권리·보상 구조가 다르므로 반드시 구분해야 합니다.

• 포함 비용: 인력, GPU, 저장공간, API, 데이터 구매와 출장비를 구분합니다.
• 별도 비용: 보안 인증 대응, 추가 연동, 운영 교육의 단가를 확인합니다.
• 지급 조건: 단순 날짜가 아니라 검수 가능한 산출물과 연결합니다.
• 중단 비용: 단계 종료 시 정산 범위와 자료 인계 조건을 적습니다.
• 변경 절차: 요청자, 영향 분석, 승인자와 착수 시점을 지정합니다.

Q. 데이터와 모델 권리는 계약서에 어떻게 적어야 하나요?

A. ‘소유권 귀속’ 한 문장으로는 부족합니다

AI R&D 산출물에는 원천 데이터, 정제 데이터, 라벨, 프롬프트, 학습 코드, 모델 가중치, 평가 스크립트와 운영 로그가 함께 존재합니다. 이들을 모두 “결과물”이라고 묶으면 계약 종료 후 사용할 수 있는 범위를 두고 해석이 갈릴 수 있습니다. 산출물별 소유자와 이용권자, 복제 가능 범위, 보관 기간을 표로 분리해야 합니다.

파트너가 기존에 보유한 라이브러리와 이번 과제에서 새로 만든 코드를 구분하는 것도 중요합니다. 기존 자산까지 발주사가 소유하겠다고 요구하면 견적이 불필요하게 높아지거나 계약이 성립하지 않을 수 있습니다. 대신 운영에 필요한 사용권, 수정권, 제3자 유지보수 권한과 소스 접근 조건을 확보하는 방식이 현실적입니다.

• 원천 데이터는 열람 장소, 반출 가능 여부와 삭제 증빙 방식을 정합니다.
• 정제 데이터와 라벨은 재사용, 재판매, 다른 고객 학습에 쓸 수 있는지 명시합니다.
• 모델 가중치는 전달 형식, 실행 환경과 추가 학습 권한을 적습니다.
• 오픈소스 구성요소는 라이선스 목록과 고지 의무를 산출물에 포함합니다.
• 상용 API는 제공사 정책 변경이나 서비스 종료 시 대체 절차를 둡니다.
• 논문·보도자료·포트폴리오 공개는 사전 서면 승인 대상으로 지정합니다.

A. 보안 질문은 서버 위치보다 데이터 흐름에서 시작합니다

“국내 서버를 씁니까?”라는 질문만으로는 부족합니다. 사용자가 파일을 올린 순간부터 전처리, 임시 저장, 모델 호출, 로그 기록, 백업, 삭제까지 데이터가 이동하는 경로를 그려 달라고 해야 합니다. 외부 API로 전송되는 필드와 오류 로그에 남는 내용, 개발자가 운영 데이터에 접근하는 방식을 함께 확인하세요.

민감정보가 있다면 모든 데이터를 한 번에 전달하지 말고 비식별 샘플, 제한된 테스트 데이터, 승인된 운영 데이터 순으로 접근 범위를 넓히는 편이 좋습니다. 권한은 개인 계정으로 부여하고 공유 계정은 피해야 합니다. 프로젝트 종료일에는 계정 회수, 복사본 삭제, 저장매체 반납과 비밀유지 의무의 존속 기간까지 점검합니다.

“보안 문구가 길다고 안전한 것은 아닙니다. 누가 어떤 데이터에 언제 접근했고, 종료 후 무엇을 삭제했는지 증명할 수 있어야 합니다.”

1. 데이터 흐름도를 계약 전 보안 검토 자료로 받습니다.
2. 최소 권한 원칙에 따라 역할별 접근 범위를 설정합니다.
3. 개발·검증·운영 환경의 데이터와 계정을 분리합니다.
4. 사고 발생 시 통지 시간, 책임자와 조사 협조 범위를 정합니다.
5. 종료 시 삭제확인서뿐 아니라 접근 로그와 계정 회수 결과를 받습니다.

Q. 계약 직전에 특히 많이 놓치는 세 가지는 무엇입니까?

A. 데모 성공을 운영 성능으로 오해하는 실수가 가장 흔합니다

첫 번째 실수는 파트너가 선별한 샘플에서 나온 결과를 실제 현장 성능으로 받아들이는 것입니다. 데모 데이터와 운영 데이터는 문서 길이, 이미지 품질, 전문용어, 결측치 비율이 다를 수 있습니다. 발주사가 직접 고른 비공개 평가 세트로 재시험하고, 평균값뿐 아니라 가장 성능이 낮은 데이터 구간을 확인해야 합니다.

평가 세트를 파트너에게 미리 모두 공개하면 그 데이터에 맞춰 조정한 결과가 일반 성능처럼 보일 수 있습니다. 학습용, 중간 검증용, 최종 검수용 데이터를 분리하고 마지막 세트는 발주사가 관리하세요. 생성형 AI라면 정답 일치율 외에도 근거 인용, 환각, 유해 응답, 답변 거부의 적절성을 사람이 표본 평가해야 합니다.

• 현업에서 자주 발생하는 쉬운 사례와 드문 예외 사례를 함께 넣습니다.
• 정답을 맞힌 비율 외에 치명적 오류의 건수를 별도로 집계합니다.
• 응답 시간과 동시 사용자 수처럼 운영 조건에서도 시험합니다.
• 모델이나 프롬프트가 바뀔 때 동일 평가를 다시 실행할 수 있게 보관합니다.

A. 담당자 이름, 인수 조건, 종료 조건을 비워 두지 마세요

두 번째 실수는 제안 발표를 한 전문가가 실제 과제에도 계속 참여할 것이라고 믿는 것입니다. 계약서나 수행계획서에 프로젝트 책임자, 핵심 역할, 최소 투입률, 교체 시 승인 절차를 적어야 합니다. 특정 개인을 무조건 고정하기 어렵다면 동등 역량의 대체 기준과 인수인계 기간을 정하는 방식이 합리적입니다.

세 번째 실수는 성공 조건만 쓰고 중단 조건과 인계 조건을 쓰지 않는 것입니다. 목표 지표에 미달했을 때 무한히 기간을 연장하면 비용과 기회손실이 커집니다. 두 차례 개선 후에도 최소 기준을 넘지 못하거나 필수 데이터 확보가 불가능한 경우처럼 중단 기준을 정하고, 그 시점까지 생성된 코드·문서·실험 기록을 어떤 형식으로 받을지 명시하세요.

1. 첫째, 계약 서명 전에 실제 책임자와 기술 실무자가 참여하는 질의응답을 진행합니다.
2. 둘째, 저장소 접근권한, 실행 방법, 환경 설정 파일의 인계 기준을 문서화합니다.
3. 셋째, 성능 미달·일정 지연·보안 위반별 시정 기간과 종료 권한을 구분합니다.
4. 넷째, 최종 검수 후 2~4주의 안정화 기간과 수정 범위를 협의합니다.
5. 다섯째, 연구 종료 30일 전 운영 담당자 교육과 장애 대응 모의훈련을 배치합니다.

마지막 협상에서 가격 몇 퍼센트를 낮추는 데만 집중하면 정작 더 비싼 위험을 남길 수 있습니다. 파트너가 바뀌어도 데이터를 이해하고 모델을 실행할 수 있는지, 성과가 기대에 못 미쳐도 학습한 내용을 조직에 남길 수 있는지를 기준으로 계약을 살펴보세요. 좋은 공동연구 계약은 성공을 약속하는 문서가 아니라 불확실성을 함께 다루는 방법을 정한 문서입니다.