AI 에이전트 SLA 계약에서 나중에 비싸지는 조항은 업타임 보장, 데이터 소유권, 해지 조건, 모델 변경 고지 네 가지입니다. 넷 다 서명하는 날에는 비용이 0이고, 운영이 시작된 뒤에야 청구서나 인건비로 모습을 바꿉니다.
업체를 정하고 계약서 초안을 받은 자리에서 문서를 넘겨 보면, 기능과 금액은 이미 협의된 대로 적혀 있습니다. 그다음 장부터가 낯설죠. 서비스 수준, 데이터 처리, 계약 기간과 해지, 변경과 통지 같은 제목이 붙은 조항들입니다.
이 대목에서 결재 라인에 올릴 리스크를 정리해야 하는데, 무엇이 위험한지 판단할 기준이 마땅치 않은 경우가 많습니다.
결재자의 시선은 실무 검토와 다릅니다. 담당자는 이 계약으로 무엇을 할 수 있는지를 보지만, 서명란에 이름이 올라가는 사람은 이 계약이 어긋났을 때 무엇이 회사에 남는지를 봅니다. 제가 AI 도입이 어긋난 사례를 되짚을 때 제품이나 기술보다 먼저 확인하는 것도 계약서에서 비어 있던 문장입니다.
하마다랩스가 도입 상담에서 반복해 확인하는 것도 그 네 조항입니다. 기능 비교와 견적을 이미 끝내고 계약서 초안까지 받아 온 기업과 마주 앉는 자리인데, 비어 있는 문장은 늘 이 넷 언저리였습니다. 문구 하나가 빈 채로 서명되면 그 빈칸이 1년 뒤 운영 단계에서 돈이나 사람 시간으로 청구되기 때문이죠. 아래에서는 조항별로 그 경로를 따라갑니다.
먼저 밝혀 둘 것이 있습니다. 여기 정리한 내용은 계약 검토의 관점이지 법률 자문이 아니며, 조항의 효력과 최종 문구는 사내 법무나 자문 변호사의 검토를 거쳐 확정하시길 권합니다.
AI 에이전트 계약에서 나중에 비싸지는 조항은 어디에 있나요?
비용으로 돌아오는 조항은 네 곳에 몰려 있습니다. 업타임 보장(SLA 조항)이 서비스 수준을 정하고, 데이터 소유권이 자산의 귀속을 정하고, 해지 조건이 나가는 절차를 정하고, 기반 모델 변경 고지가 바뀌는 시점을 알립니다. 공통점은 서명 시점에 다툼이 없다는 것입니다.
다툼이 없는 이유는 단순합니다. 네 조항 모두 “장애가 났을 때”, “계약을 끝낼 때”, “모델이 바뀔 때”처럼 아직 오지 않은 시점을 다루거든요. 오지 않은 시점의 문구는 협상 테이블에서 우선순위가 밀립니다.
| 조항 | 계약서에서 비는 자리 | 운영 단계에서 나타나는 비용 |
|---|---|---|
| 업타임 보장 | 가동률 숫자만 있고 측정 단위·제외 항목·보상 산정이 없음 | 장애 손실이 우리 쪽 인건비·기회손실로 남음 |
| 데이터 소유권 | 원본만 언급하고 파생 자산의 귀속이 없음 | 이관 시 업무 규칙·설정 재구축 비용 |
| 해지 조건 | 자동 갱신 통지 기한·반환 비용·이관 지원 범위가 없음 | 종료 작업이 별도 유상 과업으로 청구 |
| 모델 변경 고지 | 기반 모델 교체·종료 시 고지 기한과 책임이 없음 | 재검증·프롬프트 재조정 공수와 단가 변동 |
표의 오른쪽 열은 전부 계약서에 금액으로 적히지 않는 항목입니다. 그래서 견적서를 아무리 정교하게 비교해도 잡히지 않고, 도입 2년 차 예산 회의에서야 “이건 왜 늘었나”라는 질문으로 등장하죠.
계약 전 점검 항목을 운영·보안·출구·확장 네 축으로 넓게 훑는 방법은 도입 의사결정 체크리스트에 따로 정리해 두었습니다. 여기서는 그중 계약 문서에 실제로 문장으로 들어가야 하는 네 조항만 깊이 들어갑니다.
조항 하나가 운영 비용으로 바뀌는 경로는 어떻게 생기나요?
경로는 세 걸음으로 만들어집니다. 정의가 비면 그 빈자리를 판단할 권한이 공급사에게 넘어가고, 그 판단의 결과가 우리 쪽 부담으로 정산됩니다.
첫걸음인 정의의 공백이 가장 조용합니다. “서비스가 정상적으로 제공되지 않는 경우”라는 문장은 읽을 때는 충분해 보이지만, 정상의 반대편이 무엇인지는 말하지 않거든요. 응답이 20초씩 늦어지는 상태는 장애일까요, 아니면 정상 범위의 지연일까요.
둘째 걸음에서 그 판단을 누가 하는지가 갈립니다. 계약서에 판정 주체와 근거 자료가 적혀 있지 않으면, 사실상 로그를 가진 쪽이 판정자가 되죠.
셋째 걸음은 정산입니다. 판정이 “정상 범위”로 나면 보상 조항은 발동하지 않고, 그동안 업무를 수동으로 돌린 인건비는 우리 손익계산서에 남습니다.
이 세 걸음은 네 조항에서 똑같이 반복됩니다. 그러니 조항을 읽을 때 던질 질문도 하나로 압축되죠. 이 문장에 정의, 측정, 판정 주체, 부담 주체가 다 들어 있는가.
업타임 보장은 숫자보다 무엇을 먼저 보나요?
가동률 숫자가 아니라 그 숫자를 만드는 계산식을 먼저 봅니다. 99.9%라는 표기는 같아도, 무엇을 분모로 놓고 무엇을 장애 시간에서 빼는지에 따라 실제 보장 수준이 크게 달라지거든요.
용어의 뿌리는 공적 기준에도 있습니다. 과학기술정보통신부 고시 「클라우드컴퓨팅서비스 품질·성능에 관한 기준」은 가용성을 서비스가 장애 없이 정상적으로 운영되는 능력으로 정의하고, 품질·성능의 기본 측정 기준을 제시합니다. 계약서의 가동률 조항은 그 정의를 우리 서비스 범위에 맞게 구체화한 문장이어야 합니다.
가동률의 분모와 제외 항목은 어떻게 정해지나요?
네 가지를 확인합니다. 측정 창이 월 단위인가 연 단위인가, 계획 정비 시간을 분모에서 빼는가, 부분 장애를 어떻게 환산하는가, 우리가 연동한 외부 시스템의 장애를 어느 쪽 책임으로 두는가.
측정 창의 차이는 생각보다 큽니다. 같은 99.9%라도 연 단위로 계산하면 한 달에 여덟 시간 넘게 몰아서 멈춰도 연간 목표는 지켜지거든요. 월 단위 계산에서는 그 정도 장애가 곧바로 미달로 잡힙니다.
계획 정비도 마찬가지입니다. 정기 점검을 분모에서 빼는 것 자체는 업계 관행이지만, 사전 통지 기한과 시간대, 연간 상한이 함께 적혀 있어야 관행이 제약으로 작동하죠. 통지 기한이 비어 있으면 업무 시간 한복판의 점검도 계약 위반이 아닙니다.
부분 장애의 환산 방식은 AI 에이전트에서 특히 예민합니다. 시스템은 살아 있는데 특정 워크플로만 실패하거나, 응답은 오는데 품질이 급격히 떨어지는 상태가 실제로 자주 나타나거든요. 이런 상태를 어떻게 셀지 적어 두지 않으면 장애 통계에 잡히지 않습니다.
연동한 외부 시스템의 장애도 경계를 그어야 할 대목입니다. ERP나 그룹웨어가 멈춰 에이전트가 일을 못 하는 상황은 공급사 책임 밖이라는 것이 일반적인 정리지만, 어느 쪽 장애인지 판단하는 절차와 근거 로그를 누가 제공하는지는 계약에 적을 수 있죠.
여기까지가 조항에서 확인할 계산식의 뼈대입니다. 숫자를 높이는 협상보다 이 뼈대를 채우는 협상이 실제 보호막을 두껍게 만듭니다.
보상 크레딧은 손실을 얼마나 메우나요?
크레딧은 손실 보상이라기보다 이용료의 부분 감면입니다. 가동률 미달 구간에 비례해 다음 달 요금을 깎아 주는 방식이 일반적이죠.
단위가 다르다는 점을 짚어야 합니다. 업무가 멈춘 손실은 사람의 시간과 처리 지연으로 발생하는데, 감면은 서비스 이용료를 기준으로 계산되거든요. 이용료가 손실보다 작으면 크레딧은 구조적으로 손실을 따라오지 못합니다.
그래서 협상에서 실익이 큰 항목은 감면율보다 통지와 복구 쪽입니다. 장애를 몇 분 안에 알리는지, 어느 경로로 누구에게 알리는지, 복구 목표 시간을 넘기면 어떤 절차가 발동하는지를 문장으로 받아 두면 우리 쪽 대응이 빨라지죠. 크레딧 조항만 다듬는 협상은 겉보기에 성과가 커 보여도 실제 보호막은 얇습니다.
데이터 소유권은 원본만 적으면 왜 부족한가요?
운영 중에 가치가 쌓이는 자산이 원본 밖에 있기 때문입니다. AI 에이전트를 1년 쓰면 늘어나는 것은 우리가 넣은 원본 데이터만이 아니라, 그 데이터를 쓰기 좋게 만든 구조물이거든요.
| 자산 유형 | 무엇인가 | 계약서에서 자주 비는 이유 |
|---|---|---|
| 원본 데이터 | 우리가 업로드·연동한 문서·거래 기록 | 대체로 명시됨 |
| 전처리·색인 | 검색용으로 변환·분할한 데이터 구조 | 제품 내부 산물로 취급 |
| 프롬프트·업무 규칙 | 예외 처리와 판단 기준을 담은 설정 | 자산이라는 인식 자체가 없음 |
| 실행·대화 로그 | 에이전트가 무엇을 근거로 처리했는지 | 공급사 운영 데이터로 분류 |
| 튜닝·평가 산출물 | 우리 데이터로 조정한 결과와 평가 세트 | 지식재산 조항에 뭉뚱그려짐 |
표의 아래 세 줄이 실무에서 값이 나가는 부분입니다. 원본은 어차피 우리 시스템에도 있지만, 몇 달에 걸쳐 다듬은 업무 규칙과 예외 처리 기준은 그 제품 안에서만 존재하거든요.
우리가 만든 업무 규칙은 누구 자산인가요?
계약서가 말하지 않으면 다투게 됩니다. 그래서 소유권 조항에는 원본, 파생 산출물, 우리가 작성한 설정과 규칙을 각각 한 줄씩 나눠 적는 편이 안전하죠.
함께 적을 것이 반출 형식입니다. 소유권이 우리에게 있다고 적혀 있어도 내보낼 방법이 제품에 없으면 문서상의 권리로 그칩니다. 표준 형식으로 내려받을 수 있는지, 그 기능이 계약 기간 내내 제공되는지를 조항과 제품 양쪽에서 확인하시길 권합니다.
학습 재사용 여부도 같은 조항 묶음에서 다룹니다. 우리 데이터가 공급사 모델의 개선에 쓰이는지, 쓰인다면 격리와 옵트아웃이 되는지를 적어 두어야 이후 보안 감사에서 답할 근거가 생기죠.
실행 로그의 열람권도 함께 적어 두시길 권합니다. 에이전트가 어떤 근거로 그렇게 처리했는지는 오작동을 되짚을 때도, 감사에서 설명을 요구받을 때도 필요한 자료인데, 로그가 공급사 운영 데이터로만 분류되어 있으면 우리 요청은 협조 사항이 되거든요. 조회 범위와 보관 기간, 내려받기 가능 여부를 한 줄로 적으면 요청이 권리가 됩니다.
개인정보를 다루면 계약서에 무엇이 더 들어가나요?
법이 문서 형식을 요구합니다. 개인정보 보호법 제26조 제1항은 개인정보 처리 업무를 위탁할 때 위탁 업무 목적 외 처리 금지, 기술적·관리적 보호조치 등을 담은 문서로 계약하도록 정하고 있습니다.
같은 법 시행령 제28조 제1항은 그 문서에 들어갈 사항을 더 구체적으로 열거합니다. 그중 계약 협상에서 자주 문제가 되는 항목은 재위탁 제한, 위탁 업무와 관련한 개인정보 관리 현황 점검 등 감독에 관한 사항, 수탁자가 의무를 위반했을 때의 손해배상 등 책임에 관한 사항입니다.
AI 에이전트가 고객 문의나 인사 데이터를 다루면 이 조항의 적용 여부부터 확인해야 합니다. 공급사가 우리를 대신해 개인정보를 처리하는 위수탁 관계인지에 따라 적용이 갈리므로, 이 판단은 법무의 확인을 거치는 편이 안전합니다. 소유권 문구와 별개로 위수탁 관계를 정리한 문서가 있는지, 재위탁 구조가 어디까지 열려 있는지를 함께 확인하는 편이 좋습니다.
재위탁은 AI 서비스에서 특히 길게 이어집니다. 공급사가 외부 언어 모델을 쓰고 그 모델이 다른 클라우드 위에서 돌아가면, 우리 데이터가 지나가는 경로에 두세 곳이 놓이거든요. 경로에 있는 곳들의 목록과 변경 시 통지 절차를 문서로 받아 두면, 나중에 보안 감사에서 같은 질문을 받았을 때 답이 준비되어 있습니다.
해지 조건에서 비용이 발생하는 지점은 어디인가요?
세 지점입니다. 계약이 자동으로 이어질 때, 중도에 끊을 때, 데이터와 자산을 돌려받을 때 각각 돈이 움직입니다.
중도 해지의 정산 방식부터 보겠습니다. 남은 기간 요금을 전액 물어야 하는지 일부만 정산하는지, 구축 대가와 구독료를 나눠 계산하는지, 이미 투입된 커스터마이징 비용은 어떻게 처리하는지가 조항마다 다르거든요.
해지 사유를 구분해 적는 것도 같은 조항에서 할 일입니다. 우리 사정으로 끝내는 경우와 공급사의 채무 불이행으로 끝내는 경우가 나뉘어 있어야, 서비스 품질이 무너졌는데도 위약금을 걱정하며 붙들려 있는 상황을 피할 수 있죠. 품질 미달이 반복될 때 해지권이 생긴다는 문장 한 줄이 그 구분의 시작입니다.
자동 갱신은 통지 기한이 관건입니다. 만료 30일 전 또는 60일 전까지 서면으로 알리지 않으면 동일 조건으로 1년 연장된다는 문구가 흔한데, 이 기한을 놓치면 재협상 기회가 통째로 다음 해로 밀리거든요. 계약 체결과 동시에 사내 일정에 통지 기한을 등록해 두는 편이 실질적인 대비입니다.
반환 쪽에는 법이 정한 기준선이 있습니다. 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」 제27조는 이용자와의 계약이 종료됐을 때 제공자가 이용자 정보를 반환하고 보유 정보를 파기하도록 정하고, 사업을 종료하려는 경우에는 그 사실을 이용자에게 알리고 종료일 전까지 반환·파기하도록 규정합니다.
다만 이 법이 우리가 맺는 계약에 그대로 적용되는지는 서비스 형태에 따라 달라집니다. 구축형인지 구독형인지, 공급사가 클라우드컴퓨팅서비스 제공자에 해당하는지에 따라 판단이 갈리므로, 적용 여부는 법무 검토로 확인하는 편이 정확하죠.
법에 기대지 않고 계약서에서 직접 확정할 항목은 비용과 기한입니다. 반환 데이터의 형식과 제공 기한, 반환 작업에 별도 대가가 붙는지, 이관 지원이 무상 범위인지 유상 과업인지, 파기 증빙을 어떤 문서로 받는지를 각각 적어 두면 종료 국면에서 협상할 것이 줄어듭니다.
전환 기간을 따로 두는 방법도 있습니다. 계약 만료 후 일정 기간 동안 읽기 전용으로 접속을 유지해 주는 조건인데, 이관 도중에 원본을 다시 확인해야 하는 일이 흔해서 실무에서 값을 하죠. 기간과 그 기간의 요금 조건을 함께 적어 두면 종료 일정에 여유가 생깁니다.
이 항목들이 비어 있을 때 생기는 비용의 성격은 분명합니다. 종료가 결정된 뒤에 견적을 받는 상황이라 가격 협상력이 우리 쪽에 거의 없거든요.
모델 변경 고지는 왜 별도 조항이 필요한가요?
기반 모델이 우리와 무관하게 바뀌기 때문입니다. AI 에이전트 대부분은 외부 언어 모델 위에서 동작하는데, 그 모델의 수명은 공급사가 정하죠.
관행은 공개되어 있습니다. OpenAI는 모델 지원 종료 문서에서 더 안전하고 유능한 모델을 내놓으면서 구형 모델을 정기적으로 은퇴시킨다고 밝히고, 지원 종료(deprecation)와 실제 접근이 끊기는 셧다운(shutdown)을 구분해 일정과 대체 모델을 함께 안내합니다.
문제는 그 일정이 우리 업무 일정과 무관하게 온다는 점입니다. 모델이 바뀌면 같은 프롬프트가 다른 결과를 내고, 몇 달 동안 다듬은 예외 처리 규칙이 어긋나기 시작하죠.
조항에 담을 것은 네 가지로 좁혀집니다.
- 고지 기한: 기반 모델 교체·종료를 며칠 전에, 어떤 경로로 알리는가
- 검증 환경: 교체 전에 우리가 시험할 수 있는 환경과 기간이 제공되는가
- 회귀 검증 책임: 기존 워크플로가 동일하게 동작하는지 누가 확인하고, 어긋나면 누가 조정하는가
- 단가 연동: 모델 변경이 이용료 산정에 반영되는 방식과 인상 시 통지 기한
세 번째 항목이 실제 공수를 가릅니다. 조정 책임이 적혀 있지 않으면 검증도 재작성도 우리 담당자의 몫이 되고, 그 시간은 어느 계약서에도 청구되지 않은 채 사라지거든요.
버전 고정이 가능한지도 물어볼 만합니다. 특정 모델 버전을 지정해 쓰다가 우리 일정에 맞춰 옮기는 방식이 지원되면 교체 충격을 분산할 수 있는데, 고정 기간에 상한이 있고 그 기간이 지나면 강제 이전되는 경우가 많으므로 상한과 이후 절차를 함께 확인하시길 권합니다.
기반 모델을 자체 환경에 두는 선택지도 협상 재료가 됩니다. 하마다랩스가 온프레미스 배포를 다루는 이유 중 하나도, 외부 일정에 흔들리는 폭을 줄이려는 고객이 실제로 있기 때문이죠.
고지 의무 쪽에서는 국내 법제도 움직였습니다. 2026년 1월 22일 시행된 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」은 생성형 인공지능을 이용한 제품·서비스를 제공할 때 그 사실을 이용자에게 미리 알리도록 하는 등 사업자의 의무를 두고 있습니다. 우리가 만든 에이전트를 고객이나 직원에게 제공한다면 그 고지를 누가 준비하고 갱신하는지도 계약에서 정리할 여지가 있습니다.
네 조항은 서로 어떻게 맞물리나요?
따로 놓고 보면 각각 작은 빈칸이지만, 실제 사고는 두세 개가 이어질 때 커집니다. 조항 사이의 연결 고리를 미리 그려 두면 어느 문장을 먼저 채울지가 분명해지죠.
먼저 볼 연쇄는 모델 변경에서 시작합니다. 기반 모델이 바뀌어 특정 업무의 처리 정확도가 떨어졌다고 해 보죠. 이 상태는 서비스가 멈춘 것이 아니라서 업타임 조항으로는 장애가 아니고, 품질 저하를 다루는 문장이 따로 없으면 보상도 해지 사유도 아닙니다. 결국 우리 담당자가 프롬프트를 손보는 일만 남죠.
두 번째 연쇄는 해지와 소유권 사이에서 생깁니다. 반환 조항이 원본 데이터만 다루고 있으면, 계약은 정상적으로 끝나는데 정작 그동안 쌓은 업무 규칙은 두고 나오게 되거든요. 소유권 조항에 파생 자산이 적혀 있어야 반환 조항이 실제로 작동합니다.
그래서 조항을 하나씩 검토하기 전에 연결부터 확인하는 순서를 권합니다. 품질 저하가 어느 조항에 걸리는지, 반환 대상이 소유권 정의와 같은 범위인지, 이 두 질문만 던져도 손봐야 할 자리가 좁혀지죠. 네 조항을 한꺼번에 채우기 어려운 상황이라면 우선순위도 여기서 나옵니다. 다른 조항의 공백까지 끌고 오는 문장부터 채우면 협상 횟수가 줄어듭니다.
네 조항의 비용은 한 장으로 어떻게 추산하나요?
금액을 맞히려 하지 말고 발생 시점과 부담 주체를 먼저 적습니다. 조항의 공백은 확률적인 위험이라 단가를 세우기 어렵지만, 언제 누구의 예산에서 나가는지는 지금 적을 수 있거든요.
| 공백 조항 | 비용이 나타나는 시점 | 부담 주체 | 지출 성격 |
|---|---|---|---|
| 업타임 정의·측정 | 첫 대형 장애 시 | 현업 부서 | 수동 처리 인건비, 지연 손실 |
| 파생 자산 귀속 | 교체·이관 검토 시 | IT 예산 | 규칙·설정 재구축 공수 |
| 해지·반환 절차 | 계약 만료 3~6개월 전 | IT 예산 | 이관 지원 유상 과업 |
| 모델 변경 고지 | 기반 모델 교체 시 | 담당자 시간 | 회귀 검증·프롬프트 재조정 |
부담 주체 열을 비워 두지 않는 것이 이 표의 핵심입니다. 같은 위험이라도 현업 부서의 초과 근무로 흡수되는 것과 IT 예산에서 집행되는 것은 회사가 체감하는 방식이 다르고, 예산에 잡히지 않는 쪽이 대개 더 오래 방치되거든요.
예산에 잡히지 않는 지출을 제가 특히 오래 보는 이유가 여기 있습니다. 회사를 운영하면서 확인한 것은, 금액이 큰 실패보다 아무의 항목에도 적히지 않은 지출이 훨씬 늦게 드러난다는 점입니다. 늦게 드러난 비용은 이미 한 해 예산에 섞여 있어서 원인을 조항으로 되짚기가 어려워집니다.
표를 이렇게 채우면 임원 보고에서 다루기 쉬워집니다. 금액이 아니라 항목과 시점으로 적혀 있으니 과장 없이 설명되고, 협상으로 없앨 수 있는 위험과 감수할 위험을 나누기도 수월하죠.
가상 시나리오로 감을 잡아 보겠습니다. 직원 200명 규모 유통사의 문서 처리 에이전트에서 기반 모델이 고지 없이 교체되어, 반품 요청서의 예외 항목을 걸러내던 정확도가 떨어졌다고 해 보죠. 서비스가 멈춘 것은 아니니 업타임 조항의 장애로 잡히지 않고, 품질 저하를 다루는 문장이 없으니 보상도 발동하지 않습니다. 남는 것은 담당자가 프롬프트를 다시 맞춘 시간인데, 그 시간은 어느 계약서에도 예산 항목에도 적히지 않습니다.
실제 고객사 데이터가 아니라 조항 공백이 겹칠 때의 경로를 보여 주기 위한 가상 예시입니다.
이런 항목을 도입 전 총소유비용에 미리 반영하는 방법은 3년 총소유비용 계산에서 다뤘습니다. 그 계산표에서 계약 조항의 공백은 대체로 0으로 잡힙니다.
협상에서는 무엇부터 요구하나요?
정의, 측정, 책임 순서로 요구합니다. 이 순서에는 이유가 있는데, 정의가 없으면 측정 방식을 정할 수 없고 측정이 없으면 책임을 물을 근거가 생기지 않기 때문이죠.
1순위는 용어 정의입니다. 장애·정상·부분 장애·계획 정비·파생 자산 같은 말이 계약서 안에서 어떤 뜻인지 한 번씩 규정되면, 나머지 조항의 해석 다툼이 크게 줄어듭니다.
2순위는 측정과 통지입니다. 무엇을 근거 자료로 삼을지, 누가 언제 어느 경로로 알릴지를 이 단계에서 문장으로 못 박습니다. 여기까지만 확보해도 장애와 변경 국면에서 우리 쪽이 사후 통보를 받는 위치에서 벗어납니다.
사내에서 먼저 정리할 것도 있습니다. 어떤 업무가 몇 시간 멈추면 실제로 곤란해지는지, 우리가 만든 규칙 중 다시 만들기 어려운 것이 무엇인지를 미리 적어 두면 협상에서 요구할 항목의 순서가 저절로 정해지거든요. 목록을 만드는 데 드는 시간은 길지 않습니다. 이 목록이 없으면 공급사가 내미는 표준 조건이 그대로 기준이 됩니다.
3순위가 책임과 보상입니다. 감면율·위약금·손해배상 한도처럼 협상 저항이 큰 항목이 여기 모여 있는데, 앞의 두 층이 서 있으면 이 층의 문구가 약해도 실무에서 방어가 되죠. 반대로 정의와 측정이 빈 채 보상률만 높여 놓으면 발동 자체가 어려운 조항이 됩니다.
공급사가 표준 계약서를 고칠 수 없다고 하면 어떻게 하나요?
본문 대신 붙는 문서를 활용합니다. 표준 약관을 그대로 쓰는 공급사도 별지나 부속 합의서, 발주서 특약으로는 조건을 붙이는 경우가 많거든요.
가장 흔한 형태가 SLA 별지입니다. 서비스 수준과 통지 절차를 표로 정리해 계약의 일부로 편입한다는 한 문장을 본문에 넣으면, 약관을 건드리지 않고도 구속력 있는 기준이 생기죠.
운영 매뉴얼을 참조 문서로 편입하는 방법도 있습니다. 다만 매뉴얼은 공급사가 언제든 개정할 수 있으므로, 개정 시 통지 의무와 불리한 변경에 대한 이의 절차를 함께 적어 두어야 참조가 안전해집니다.
전면 수정 대신 몇 줄만 요구하는 접근도 통합니다. 용어 정의 한 문단, 통지 기한 한 줄, 반환 형식 한 줄처럼 분량이 작고 원가가 걸리지 않는 항목을 골라 제시하면 검토 부담이 적어 회신이 빨라지죠.
그래도 조건을 받지 못한다면 그 사실 자체가 판단 재료입니다. 계약 문서에서 유연성이 전혀 없는 공급사는 운영 국면에서도 예외 대응이 어려울 가능성이 있으니, 후보 비교표의 한 줄로 기록해 두시길 권합니다.
이 조항들을 임원 보고에는 어떻게 옮기나요?
보고서에서는 리스크 항목으로 옮깁니다. 조항 원문을 그대로 붙이면 결재자가 읽지 않으므로, 위험·발생 시점·대응·잔여 위험 네 칸으로 줄인 표가 전달에 유리하죠. 결재판 앞에 앉은 사람이 실제로 묻는 것은 위험의 크기보다 그 위험이 우리 손안에 있느냐입니다.
문장은 확정형이 아니라 조건형으로 적는 편이 정확합니다. “장애 시 보상을 받는다”가 아니라 “월 단위 측정과 통지 기한을 확보하면 장애 손실의 대응 시간을 줄일 수 있고, 확보하지 못하면 수동 처리 인건비가 남는다”처럼 조건과 결과를 나란히 적습니다.
사업성 문서 전체의 구성과 결재 통과 기준은 임원 보고용 사업성 분석서에서 항목별로 다뤘습니다. 계약 조항 리스크는 그 문서의 리스크 항목 안에 한 장으로 들어가는 구성이 자연스럽습니다.
서명 전에 마지막으로 확인할 것은 무엇인가요?
네 조항에서 각각 한 문장씩만 다시 찾아보시면 됩니다.
- 가동률의 측정 창과 제외 항목, 판정 근거 자료가 적혀 있는가
- 프롬프트·업무 규칙·튜닝 산출물의 귀속과 반출 형식이 각각 적혀 있는가
- 자동 갱신 통지 기한, 반환 형식·기한·비용, 파기 증빙 방식이 적혀 있는가
- 기반 모델 변경의 고지 기한과 회귀 검증 책임이 적혀 있는가
네 줄 중 하나라도 비어 있다면 그 자리가 나중에 비용이 되는 지점입니다. 서명 전에는 한 문장을 추가하는 협상이지만, 서명 뒤에는 변경 계약이 되죠.
하마다랩스는 기업 맞춤형 AI 에이전트를 구축·운영하면서 500개 이상의 외부 시스템 연동과 온프레미스 배포를 다루고 있습니다. 계약 단계에서 어떤 조항을 어떻게 적을지, 우리 환경에서 어느 항목이 실제 위험인지 함께 검토하는 자리가 필요하시다면 도입 문의로 상담을 요청하실 수 있습니다.
자주 묻는 질문
계약서 초안을 받은 뒤 검토에 보통 얼마나 걸리나요?
조항 수보다 확인해야 할 상대가 몇 곳인지가 기간을 정합니다. 현업·정보보안·법무가 각각 볼 항목이 다르므로, 초안을 받은 즉시 세 곳에 동시에 돌리고 회신 기한을 정해 두면 일정이 크게 줄어들죠. 순차로 돌리면 같은 문서를 두세 번 왕복하게 됩니다.
가동률 99.9%와 99.5%는 실제로 얼마나 차이가 나나요?
30일을 기준으로 계산하면 허용 중단 시간이 약 43분과 약 3시간 36분으로 갈립니다. 다만 이 차이보다 계산식이 실제 체감을 좌우하는 경우가 많아서, 숫자를 올리는 협상보다 제외 항목과 부분 장애 환산을 명확히 하는 쪽이 실익이 큰 편이죠.
소규모 계약에도 별도 조건을 요구할 수 있나요?
요구할 수 있습니다. 규모가 작으면 협상력이 약한 것은 사실이지만, 용어 정의와 통지 기한처럼 공급사에게 추가 원가가 거의 들지 않는 항목은 받아들여지는 경우가 많죠. 보상률처럼 원가가 걸린 항목과 그렇지 않은 항목을 나눠 요구하는 편이 성공률이 높습니다.
파생 자산 귀속을 우리 쪽으로 적으면 공급사가 거부하지 않나요?
제품 기술과 우리 업무 지식을 분리해 적으면 합의가 쉬워집니다. 제품의 엔진과 알고리즘은 공급사 자산으로 남기고, 우리가 입력한 규칙과 예외 처리, 평가 기준만 우리 자산으로 가져옵니다. 실무에서 다투는 대상은 대개 후자입니다.
기반 모델이 바뀌면 성능이 반드시 떨어지나요?
떨어질 수도, 오히려 올라갈 수도 있습니다. 예측이 어렵다는 것이 문제의 본질이라, 조항의 목적도 성능 유지 약속이 아니라 변경 전에 시험할 시간과 어긋났을 때의 조정 책임을 확보하는 데 있죠.
이미 서명한 계약도 지금 손볼 수 있나요?
갱신 시점을 기다리지 않아도 되는 경우가 있습니다. 별도 합의서로 통지 절차나 반환 형식 같은 운영 조항을 추가하는 것은 본계약을 다시 쓰지 않고도 가능하므로, 다음 정기 미팅 안건으로 올려 보시길 권합니다. 갱신 통지 기한만이라도 지금 사내 일정에 등록해 두면 그것만으로도 선택지가 넓어집니다.
참고 자료
- 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」 제27조(이용자 정보의 보호) — 계약 종료 시 이용자 정보 반환·파기, 사업 종료 시 통지 및 종료일 전 반환·파기 의무(2026-08-25 확인): https://www.law.go.kr/법령/클라우드컴퓨팅발전및이용자보호에관한법률
- 「개인정보 보호법」 제26조(업무위탁에 따른 개인정보의 처리 제한) 및 같은 법 시행령 제28조 — 위탁 시 문서 계약 의무와 문서 포함 사항(재위탁 제한, 관리 현황 점검 등 감독, 손해배상 등 책임)(2026-08-25 확인): https://www.law.go.kr/법령/개인정보보호법
- 과학기술정보통신부 고시 「클라우드컴퓨팅서비스 품질·성능에 관한 기준」 — 가용성 정의 및 서비스 품질·성능 기본 측정 기준(2026-08-25 확인): https://www.law.go.kr/행정규칙/클라우드컴퓨팅서비스품질·성능에관한기준
- 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(2026년 1월 22일 시행) — 생성형 인공지능 이용 제품·서비스 제공 시 사전 고지 등 사업자 의무(2026-08-25 확인): https://www.law.go.kr/법령/인공지능발전과신뢰기반조성등에관한기본법
- OpenAI, “Deprecations” — 구형 모델의 정기적 은퇴 정책, 지원 종료(deprecation)와 셧다운(shutdown)의 구분 및 일정·대체 모델 안내(2026-08-25 확인): https://developers.openai.com/api/docs/deprecations
- 하마다랩스 도입 상담 관찰(2026년, 익명·건수 미집계) — 기능 비교와 견적을 마치고 계약서 초안을 받은 단계의 상담에서 업타임 정의·파생 자산 귀속·해지 절차·모델 변경 고지 네 항목이 반복해 비어 있던 패턴. 특정 고객 사례가 아닙니다.
- 하마다랩스 플랫폼·회사 소개(500개 이상 외부 시스템 연동·온프레미스 배포 지원): https://www.hamadalabs.com/platform · https://www.hamadalabs.com/about
작성자
방승애 — 하마다랩스 공동 창업자이자 대표(CEO). 스타트업 액셀러레이팅·벤처 투자·사업 운영 경험을 바탕으로 2023년 11월 하마다랩스를 공동 창업했습니다. 직원 50~300명 중소·중견기업이 내부 개발팀 없이도 AI 에이전트를 도입·운영하도록 노코드 플랫폼 윈디플로를 이끌며, 기업 AI 도입의 단계별 로드맵·실패 회피 기준·투자 판단 근거를 경영 의사결정 관점에서 다룹니다. 회사 소개: https://www.hamadalabs.com/
