AI 기능 넣은 앱 개발 계약, 소스코드 말고 뭘 더 챙겨야 할까

AI 기능 넣은 앱 개발 계약, 소스코드 말고 뭘 더 챙겨야 할까

2026년 AI 기본법 시행 이후 반드시 확인해야 할 계약서 체크포인트 완벽 가이드

안녕하세요 😊 AI 기능이 들어간 앱을 외주로 개발하려고 준비 중이신가요? 아니면 이미 개발이 끝나고 운영 단계에 접어들었는데 뭔가 찜찜한 부분이 남아 있진 않으신가요?

AI 앱 개발 계약서는 일반적인 소프트웨어 외주 계약과 다르게 챙겨야 할 항목이 훨씬 많습니다. 소스코드 소유권만 확인하고 계약서에 도장을 찍었다가, 나중에 모델을 다른 회사로 옮기고 싶어도 옮길 수 없거나, AI가 학습한 데이터의 출처가 불분명해서 저작권 분쟁에 휘말리는 경우가 실제로 발생하고 있습니다.

이 글에서는 개발 외주 저작권부터 모델 가중치 소유권, 학습데이터 귀속, 프롬프트 자산 계약까지 AI 앱 개발 계약서에서 반드시 짚고 넘어가야 할 핵심 항목을 단계별로 정리해드립니다. 글을 다 읽고 나면 계약서 초안을 검토할 때 어떤 조항이 빠져 있는지 스스로 체크할 수 있는 감각이 생기실 거예요. 특히 2026년 1월부터 시행된 AI 기본법에 따른 표시 의무까지 함께 다루니, 지금 AI 앱 개발을 준비 중이라면 끝까지 참고해보시길 권합니다.

준비물·전제조건 — 계약서 검토 전 미리 정리해둘 것들

계약서를 검토하기 전에는 자사가 원하는 결과물의 범위와 소유 형태를 먼저 문서로 정리해두는 것이 순서입니다. 막연히 "AI 기능이 들어간 앱을 만들어주세요"라고 요청하면, 개발사가 제시하는 표준 계약서 문구를 그대로 받아들이게 될 확률이 높기 때문입니다.

준비 단계에서 정리해야 할 항목은 다음과 같습니다.

먼저, 결과물의 정의를 구체화해야 합니다. 앱 자체인지, 앱 안에 들어가는 AI 모델인지, 아니면 두 가지를 다 포함하는지 범위를 명확히 해두세요.

다음으로, 학습에 사용될 데이터의 출처를 미리 파악해야 합니다. 자사가 보유한 데이터인지, 개발사가 확보한 공개 데이터셋인지, 혹은 제3자로부터 라이선스를 받아야 하는 데이터인지 구분이 필요합니다.

그리고 예산 범위 안에서 API 호출 비용이 어떻게 변동될 수 있는지도 미리 확인해야 합니다. LLM 기반 기능은 사용량에 따라 비용이 크게 달라지기 때문에, 이 부분을 사전에 파악하지 않으면 나중에 운영비 폭탄을 맞을 수 있습니다.

마지막으로, 계약 종료 후 데이터를 어떤 형태로 돌려받을지에 대한 대략적인 그림을 그려두시길 권합니다. 이 항목은 도입 후에는 바꾸기가 매우 어렵기 때문에 처음부터 못 박아두는 것이 중요합니다.

Step 1. 지적재산권 귀속 조항부터 정확히 읽어야 합니다

계약서에서 가장 먼저, 가장 꼼꼼히 확인해야 할 조항은 지적재산권 귀속입니다. 비용을 지불하는 발주자 입장에서는 결과물의 IP가 자신에게 귀속되는 것이 일반적인 원칙이지만, 실무에서는 이 원칙이 생각보다 단순하게 적용되지 않습니다.

개발사가 처음부터 새로 만드는 코드와, 개발사가 기존에 보유하고 있던 라이브러리나 프레임워크를 활용한 부분은 별도로 구분해서 정리해야 합니다. 예를 들어 개발사가 여러 프로젝트에서 재사용하는 자체 프레임워크 위에 앱을 얹어서 개발했다면, 그 프레임워크 자체의 소유권까지 발주자에게 넘어가는 것은 아닙니다. 이 부분을 명확히 하지 않으면 나중에 "이 코드는 우리 회사의 다른 고객사에도 제공하는 공통 모듈이라 완전한 이전은 어렵다"는 답변을 듣게 될 수 있습니다.

특히 AI 기능이 포함된 앱에서는 다음 세 가지를 각각 나눠서 확인해야 합니다.

① 앱의 프론트엔드·백엔드 소스코드 소유권
② AI 모델 자체(모델 구조, 파라미터, 가중치)의 소유권
③ 모델 학습에 사용된 데이터셋의 소유권 및 활용 범위

이 세 가지는 성격이 완전히 다른 자산이기 때문에, 계약서에 "결과물 일체의 지적재산권은 발주사에 귀속된다"는 문구 하나로 뭉뚱그려 놓으면 나중에 해석 다툼이 생길 수 있습니다. 모델 가중치 소유권은 특히 중요한데, 가중치 파일 자체를 발주자가 넘겨받아 다른 인프라로 이전할 수 있는지, 아니면 개발사의 서버에서만 구동 가능한 형태로 남는지에 따라 향후 운영 자유도가 완전히 달라지기 때문입니다.

⚠️ 주의할 점은, 개발사가 오픈소스 모델을 파인튜닝하는 방식으로 작업했다면 원본 모델의 라이선스 조건(상업적 이용 가능 여부, 재배포 조건 등)이 계약서와 별개로 적용된다는 사실입니다. 이 부분은 계약서 초안 검토 단계에서 반드시 개발사에 서면으로 확인을 요청하시길 권합니다.

Step 2. 모델 문서화와 기술 이전 범위를 계약서에 명시해야 합니다

소스코드만 넘겨받는 것으로는 부족하고, 모델 구조에 대한 문서화와 기술 이전 범위까지 계약서에 못 박아야 합니다. AI 기능이 들어간 앱은 일반 웹서비스와 달리 "이 코드가 왜 이렇게 작동하는지"를 이해하려면 모델의 구조, 학습 파이프라인, 하이퍼파라미터 설정 등에 대한 별도 문서가 필요합니다.

소스코드만 받고 문서화 자료가 없다면 어떤 일이 벌어질까요. 담당 개발자가 이직하거나 계약이 종료된 이후, 그 앱을 유지보수하려는 다른 개발자나 내부 담당자가 코드를 봐도 왜 이런 구조로 만들어졌는지 파악하는 데만 오랜 시간이 걸리게 됩니다. 이는 곧 유지보수 비용의 급증으로 이어집니다.

계약서에 반드시 포함해야 할 문서화 항목은 다음과 같습니다.

먼저, 모델 아키텍처 문서입니다. 어떤 모델 구조를 사용했는지, 왜 그 구조를 선택했는지에 대한 설명이 포함되어야 합니다.

다음으로, 데이터 전처리 및 학습 파이프라인 문서입니다. 원본 데이터가 어떤 과정을 거쳐 학습용 데이터로 가공되었는지 재현 가능한 형태로 기록되어야 합니다.

그리고 API 명세서와 시스템 아키텍처 다이어그램도 필수입니다. AI 모델이 앱의 다른 컴포넌트와 어떻게 연동되는지 알아야 향후 확장이나 교체가 가능합니다.

마지막으로, 담당자 교육 및 기술 이전 세션이 계약 범위에 포함되어야 합니다. 단순히 문서만 넘겨받는 것과, 개발사 담당자가 직접 내부 담당자를 교육하며 질의응답을 진행하는 것은 실무 적용 속도에서 큰 차이가 납니다.

⚠️ 이 부분에서 자주 발생하는 실수는, "유지보수 계약을 별도로 체결할 예정이니 문서화는 대충 해도 된다"는 식으로 넘어가는 경우입니다. 유지보수 업체가 바뀔 가능성은 항상 열려 있기 때문에, 최초 개발 단계에서부터 제3자가 봐도 이해할 수 있는 수준의 문서를 요구하는 것이 안전합니다.

Step 3. 학습데이터 귀속과 제3자 침해 면책 조항을 함께 확인해야 합니다

학습데이터의 귀속 관계와 제3자 지식재산권 침해에 대한 면책 조항은 반드시 세트로 확인해야 합니다. 왜냐하면 AI 모델의 품질과 법적 리스크는 결국 학습에 사용된 데이터의 출처와 적법성에서 결정되기 때문입니다.

외부 AI 솔루션이나 API를 도입해서 앱에 붙이는 경우라면, 서비스 공급 계약서에 AI 모델 학습데이터의 적법성을 공급사가 보증한다는 조항이 명시되어 있는지 확인해야 합니다. 이 조항이 없다면, 만약 그 AI 모델이 저작권이 있는 콘텐츠를 무단으로 학습했다는 사실이 나중에 밝혀졌을 때, 그 법적 책임이 서비스를 이용한 발주자에게까지 전가될 위험이 있습니다.

제3자 지식재산권 침해 시 책임과 면책 조항 역시 마찬가지입니다. AI가 생성한 결과물이 제3자의 저작권이나 상표권을 침해했다는 클레임이 들어왔을 때, 그 책임을 누가 지는지가 계약서에 명확히 규정되어 있어야 합니다. 이 조항이 애매하게 작성되어 있으면, 분쟁이 발생했을 때 개발사와 발주자 사이에서 책임 소재를 두고 다시 협의해야 하는 번거로운 상황이 벌어집니다.

또 한 가지 중요한 것은, 앱 운영 과정에서 새롭게 축적되는 데이터의 귀속 문제입니다. 앱을 운영하면서 사용자들이 남기는 로그, 대화 기록, 피드백 데이터 등은 서비스 초기에 학습시킨 데이터와는 별개로 계속 쌓이게 됩니다. 이 데이터를 누가 소유하고, 향후 모델 재학습에 누가 활용할 권리를 갖는지도 계약서에 담아야 합니다.

📌 특히 주의할 점은, 데이터 권한 조항은 도입 후에 바꾸기가 거의 불가능하다는 사실입니다. 데이터가 한번 공급사의 시스템 안에 쌓이기 시작하면, 나중에 "이 데이터의 소유권을 우리 쪽으로 바꾸고 싶다"고 요청해도 시스템 구조상, 그리고 계약상 변경이 매우 어려운 경우가 많습니다. 그래서 이 조항은 도입 전 협상 단계에서 가장 강하게 요구해야 하는 항목 중 하나입니다.

Step 4. 프롬프트 자산, KPI, 유지보수 SLA, 비용 상한까지 챙겨야 합니다

프롬프트 엔지니어링 결과물, 성능 KPI, 유지보수 SLA, LLM 비용 상한은 계약서 후반부에서 자주 빠지는 항목이지만 실제로는 운영 단계에서 가장 크게 체감되는 부분입니다.

먼저 프롬프트 자산 계약부터 살펴보겠습니다. 최근 AI 앱 개발에서는 모델 자체를 새로 만들기보다, 상용 LLM에 정교한 프롬프트를 설계해서 원하는 결과물을 뽑아내는 방식이 많이 쓰입니다. 이때 개발 과정에서 만들어진 프롬프트 템플릿, 시스템 프롬프트, 프롬프트 체이닝 로직 등은 그 자체로 상당한 가치를 지닌 자산입니다. 하지만 계약서에 "소스코드"만 명시되어 있고 "프롬프트"라는 단어가 아예 언급되지 않은 경우가 많습니다. 프롬프트 자산도 산출물의 일부로 명시하고, 그 소유권과 향후 수정 권한을 계약서에 담아야 합니다.

다음으로 성능 KPI의 정량화입니다. "AI가 잘 작동하도록 만들어준다"는 식의 애매한 문구로는 나중에 결과물이 기대에 못 미쳤을 때 시정을 요구할 근거가 부족합니다.

가능하다면 다음과 같은 방식으로 정량화된 목표를 계약서에 명시하는 것이 좋습니다.

① 응답 정확도 또는 특정 태스크의 성공률 기준
② 평균 응답 속도(레이턴시) 기준
③ 특정 오류 유형의 발생 빈도 허용 기준

그리고 레퍼런스 검증도 계약 이전 단계에서 놓치기 쉬운 항목입니다. 개발사가 제시하는 이전 프로젝트 사례가 실제로 AI 기능까지 포함된 프로젝트였는지, 단순 웹 개발 사례를 AI 프로젝트인 것처럼 포장한 것은 아닌지 직접 확인해보는 과정이 필요합니다.

마지막으로 유지보수 SLA와 LLM 비용 상한 조항입니다. AI 기능은 특성상 외부 LLM API에 의존하는 경우가 많은데, API 제공사가 모델을 업데이트하거나 가격 정책을 변경하면 운영 비용이 예상치 못하게 늘어날 수 있습니다. 계약서에 월별 API 비용 상한선과 모델 업데이트 시 발주사와 사전 협의를 거친다는 조항을 넣어두면, 갑작스러운 비용 급증이나 모델 교체로 인한 서비스 품질 변화를 사전에 통제할 수 있습니다.

자주 발생하는 오류 — 계약 이후에 후회하는 대표 패턴들

계약서 서명 이후 가장 자주 발생하는 문제는 "그때는 별로 중요해 보이지 않았던 조항"이 나중에 발목을 잡는 경우입니다. 몇 가지 대표적인 패턴을 짚어보겠습니다.

첫째, 모델 가중치 파일을 넘겨받지 못해 다른 인프라로 이전이 불가능한 경우입니다. 계약서에 "결과물 일체를 이전한다"고만 적혀 있어도, 실제로 가중치 파일 자체가 개발사의 특정 서버 환경에 최적화되어 있어 물리적으로 이전이 어려운 사례가 있습니다.

둘째, 학습데이터의 출처를 확인하지 않아 저작권 분쟁 리스크를 뒤늦게 인지하는 경우입니다. 계약 당시에는 문제가 없어 보였지만, 나중에 학습데이터 중 일부가 저작권이 있는 콘텐츠에서 무단 수집된 것으로 밝혀지는 경우가 이에 해당합니다.

셋째, API 비용 상한 조항이 없어서 운영 비용이 예상보다 크게 늘어나는 경우입니다. 초기 견적에는 낮은 사용량 기준으로 산정되어 있었지만, 실제 서비스 이용자가 늘어나면서 API 호출 비용이 기하급수적으로 증가하는 패턴입니다.

넷째, AI 기본법에 따른 표시 의무를 놓치는 경우입니다. 2026년 1월 1일부터 시행된 AI 기본법에 따라, 생성형 AI 서비스를 제공하는 경우 콘텐츠가 AI로 생성되었다는 사실을 이용자가 인지할 수 있도록 표시해야 합니다. 이 의무는 서비스 운영자에게 있는데, 계약서에 개발사가 이 표시 기능을 구현해줄 책임이 있는지 명시되어 있지 않으면, 서비스 오픈 이후 별도 비용을 들여 추가 개발해야 하는 상황이 생길 수 있습니다.

활용 팁 & 베스트 프랙티스

계약서를 검토할 때는 개발사가 제시하는 표준 양식을 그대로 받아들이기보다, 위에서 짚은 항목들을 별도 부속 합의서로 추가하는 방식이 실무적으로 효율적입니다. 표준 계약서 전체를 새로 협상하려면 시간이 오래 걸리지만, 핵심 리스크 항목만 부속서 형태로 추가하면 협상 속도를 높일 수 있습니다.

몇 가지 실무 팁을 정리해드립니다.

먼저, 모델 문서화 요구사항은 계약 초기 견적 단계부터 포함시켜야 합니다. 개발이 다 끝난 뒤에 "문서화도 해달라"고 요청하면 추가 비용이 발생하거나, 개발사가 이미 다른 프로젝트로 넘어가서 대응이 늦어질 수 있습니다.

다음으로, 레퍼런스를 확인할 때는 실제로 그 프로젝트에 사용된 AI 모델의 성격을 구체적으로 물어보시길 권합니다. 단순히 챗봇 API를 연동한 수준인지, 자체 모델을 파인튜닝한 수준인지에 따라 개발사의 실제 역량 차이가 크기 때문입니다.

그리고 유지보수 SLA는 응답 시간뿐 아니라 모델 성능 저하 시 대응 절차까지 포함시켜야 합니다. AI 모델은 시간이 지나면서 성능이 저하되는 경우가 있는데, 이런 상황에 대한 대응 방식이 SLA에 포함되어 있는지 확인하시길 권합니다.

마지막으로, 계약서에 데이터 반환 형식을 구체적으로 명시하는 것이 좋습니다. 단순히 "데이터를 반환한다"가 아니라, 어떤 파일 형식으로, 어떤 스키마로 반환할지까지 정해두면 계약 종료 시 혼란을 줄일 수 있습니다.

응용·확장 — 계약 이후 단계에서도 이어가야 할 관리

계약서에 좋은 조항을 담는 것만큼 중요한 것은, 계약 이후에도 그 조항들이 실제로 지켜지고 있는지 주기적으로 점검하는 습관입니다. 계약서는 서명하는 순간 끝나는 것이 아니라, 프로젝트가 진행되는 내내 참조해야 하는 살아있는 문서입니다.

예를 들어 앱이 운영되기 시작한 이후에는, 모델 업데이트 이력이 계약서에 명시된 협의 절차를 거쳐서 이루어지고 있는지 정기적으로 확인해보시길 권합니다. 또한 API 비용이 계약서에 명시된 상한선 안에서 관리되고 있는지 월별로 체크하는 것도 좋은 습관입니다.

만약 여러 개의 AI 기능이 들어간 앱을 순차적으로 개발할 계획이라면, 첫 계약에서 확보한 문서화 자료와 기술 이전 결과물을 다음 프로젝트의 기준점으로 활용할 수 있습니다. 이렇게 하면 두 번째, 세 번째 프로젝트를 진행할 때는 처음보다 훨씬 수월하게 계약 조건을 협상할 수 있게 됩니다.

또한 조직 내에 AI 앱 개발 계약을 여러 건 진행할 예정이라면, 이번 글에서 다룬 체크리스트를 사내 표준 양식으로 만들어두는 것도 좋은 방법입니다. 담당자가 바뀌더라도 동일한 기준으로 계약서를 검토할 수 있어 리스크 관리의 일관성을 유지할 수 있습니다.

점검 체크리스트

계약서에 서명하기 전, 마지막으로 아래 항목을 하나씩 확인해보세요.

① 소스코드, AI 모델(가중치), 학습데이터의 소유권이 각각 별도로 명시되어 있는가
② 개발사의 기존 라이브러리·프레임워크 활용 부분이 구분되어 있는가
③ 모델 아키텍처 문서, 데이터 파이프라인 문서, 기술 이전 세션이 포함되어 있는가
④ 학습데이터의 적법성 보증 및 제3자 침해 시 면책 조항이 있는가
⑤ 프롬프트 자산의 소유권이 명시되어 있는가
⑥ 성능 KPI가 정량적으로 표현되어 있는가
⑦ 유지보수 SLA와 LLM 비용 상한, 모델 업데이트 협의 절차가 포함되어 있는가
⑧ 계약 종료 시 데이터 반환 형식과 삭제 규정이 명시되어 있는가
⑨ AI 기본법에 따른 생성형 콘텐츠 표시 의무를 누가 구현하는지 정해져 있는가

자주 묻는 질문 FAQ

Q1. 모델 가중치를 반드시 파일 형태로 받아야 하나요?
A. 서비스 운영 방식에 따라 다릅니다. 개발사의 인프라에서 계속 서비스를 운영할 계획이라면 파일 자체를 받지 않아도 될 수 있지만, 향후 다른 인프라로 이전하거나 내부적으로 직접 운영할 가능성이 있다면 가중치 파일을 이전 가능한 형태로 받을 수 있는지 계약서에 명시해두는 것이 안전합니다.

Q2. 프롬프트도 저작권 보호 대상이 되나요?
A. 프롬프트 자체의 법적 성격은 아직 명확히 정리되지 않은 부분이 있지만, 계약 실무에서는 프롬프트를 결과물의 일부인 영업비밀 또는 자산으로 취급해 계약서에 소유권과 활용 범위를 명시하는 방식으로 리스크를 관리하고 있습니다.

Q3. 외부 API를 연동만 하는 경우에도 학습데이터 조항이 필요한가요?
A. 네, 필요합니다. 자체적으로 모델을 학습시키지 않고 외부 API를 연동만 하더라도, 그 API 제공사가 사용한 학습데이터의 적법성 문제가 서비스 이용자인 발주자에게 영향을 미칠 수 있기 때문에 공급 계약서에서 이 부분을 확인해야 합니다.

Q4. AI 기본법의 표시 의무는 앱 내 어디에 적용되나요?
A. 생성형 AI가 만든 콘텐츠를 사용자가 접하는 화면이라면 표시 의무의 적용 대상이 될 수 있습니다. 구체적인 표시 방식과 범위는 서비스의 성격에 따라 달라질 수 있으므로, 계약 단계에서 개발사와 이 기능의 구현 책임을 명확히 나눠두는 것이 좋습니다.

Q5. 계약서 검토는 꼭 변호사를 통해야 하나요?
A. AI 관련 계약은 일반 IT 외주 계약보다 복잡한 이슈가 얽혀 있는 경우가 많기 때문에, 최소한 핵심 조항(IP 귀속, 데이터 귀속, 면책 조항)만이라도 법률 전문가의 검토를 받아보시길 권합니다.

---

AI 기능이 들어간 앱 개발은 일반 웹·앱 개발보다 챙겨야 할 계약 항목이 확실히 많습니다. 하지만 오늘 정리해드린 체크리스트를 하나씩 따라가시면, 계약서에 어떤 조항이 빠져 있는지 스스로 판단할 수 있는 기준이 생기실 거예요. 계약은 프로젝트의 시작점이자, 향후 몇 년간의 운영 방식을 결정짓는 문서라는 점을 꼭 기억하시길 바랍니다 😊