AI 스타트업, 에이이다트의 성장일기 🤖2화 ‘완성’의 무게
Source: Platum
본 콘텐츠는 법무법인 비트가 실제 수행한 수많은 자문 사례들을 바탕으로, 스타트업이 겪을 수 있는 위기 상황을 생생하게 전달하기 위해 소설 형식으로 재구성한 ‘비즈니스 법률 다큐-픽션’입니다.
이야기의 몰입을 위해 설정된 등장인물의 이름과 회사명은 모두 허구이며 실제 인물이나 단체와는 무관함을 알려드립니다. 다만, 그 안에 담긴 법률적 리스크와 자문은 비트의 전문적인 검토를 거친 실전 전략을 바탕으로 하고 있습니다.
제2화. ‘완성’의 무게
(주제: 소프트웨어 개발 지연 및 완성도 분쟁)
“대표님, A사에서 내용증명이 왔습니다. 소송으로 가겠다는 건데, 이걸 어떻게 해야 할까요?”
운영팀장이 가져온 서류에는 붉은 직인이 찍혀 있었다. 발신인은 우리 제품 중 일부 기능의 고도화를 맡았던 외주 개발사. 반년 넘게 우리 사무실에서 같이 일하던 파트너가 이제는 적이 되었다는 사실이 서글펐다. 서류에 적힌 청구 금액을 보니 한숨부터 나왔다.
“우리가 지급한 중도금만 해도 4억 원입니다. 그런데 결과물은 어떻습니까? 트래픽이 조금만 몰려도 멈춰버리고, 기존에 동작하던 기능을 잘못 건드리는 바람에 우리 개발자들이 주말 밤에 긴급 점검하고, 데이터 동기화는 수시로 깨집니다. 그런데도 이제 와서 잔금과 추가 인건비를 달라고요?”
다행히도 에이이다트는 3년 차를 맞아 매출이 크게 늘었다. AX 전환 붐을 타고 많은 고객이 우리 제품을 찾기 시작했고, 폭발적인 트래픽을 감당하기 위해 백엔드 시스템을 대대적으로 갈아엎는 작업을 시작했다. 내부 개발팀은 신규 AI 모델 고도화에 올인하고 있었기에, 우리는 국내 최고 수준의 전문성을 가지고 있다던 외부 개발사를 믿고 10억 원 규모의 개발 계약을 체결했다.
당시 외주 개발사 대표의 자신감 넘치는 PT와 화려한 포트폴리오에 별 생각 없이 도장을 찍었다. 하지만 현실은 달랐다. 약속한 3개월이 지나자 “기술적 난이도가 생각보다 높다”는 변명과 함께 교체된 초급 개발자들이 투입되었다. 반년이 지나고, 일 년이 다 되었지만 여전히 개발 목표는 달성되지 못한 상태였다. 결국 나는 눈물을 머금고 계약 해지를 통보했다.
상대는 단호히 주장했다. “우리는 계약서에 명시된 맨먼스(Man‑Month)를 전부 투입했고, 이미 90% 이상 완성된 상태였다. 지연의 책임은 에이이다트 측에서 추가적으로 요구한 기능 때문이니, 그에 따른 추가 개발비 3억 원과 잔금 5억 원을 모두 지급하라”는 논리였다.
시리즈 A 투자 라운드가 진행 중이던 시점이라 투자자에게 소송이 발생한 이유와 예상 결과를 설명해야 하는 상황은 매우 불리했다. 또한 AI SaaS 개발회사로서 외주 개발사를 사용했다는 소문이 퍼질까 우려되었다.
변호사를 다시 찾았다.
“변호사님, 이 사건은 누구 한 명의 잘못이라기보다는 서로가 생각한 ‘완성’의 정의가 달랐던 것 같습니다. 그들은 ‘우리는 일했다’고 하고, 저희는 ‘쓸 수 없다’고 합니다. 하지만 저희로서는 이 깡통 같은 시스템에 잔금을 더 치를 수는 없습니다.”
변호사는 외주 개발사와 주고받은 수십 통의 이메일, 슬랙 로그, 깃허브에 기록된 모든 코드 수정 이력을 요청했다. 그는 개발 현장에서 지연 사유를 어떻게 조작하거나 과장하는지에 대한 경험이 풍부했다.
몇 주간의 분석 끝에 변호사는 검수 절차의 부재와 코드 수정 기록에 유리한 사실관계가 있다고 밝혔다.
“외주 개발사는 ‘거의 완성되었다’고 주장하지만, 계약서에 명시된 중간 산출물 패키지와 검수 요청서를 한 번도 제출하지 않았습니다. 계약서에서는 중간 검수가 최종 잔금 지급의 전제조건이라고 명시돼 있습니다. 후반부 개발 로그를 보면 대부분 우리 회사가 테스트한 결과를 받고 하자를 수정하는 내용뿐입니다.”
법정 공방은 치열했다. 상대 변호사는 메신저 대화 중 “이런 기능도 있으면 좋겠네요”라는 의견을 ‘추가 과업 요구’라고 몰아세우며 지연 책임을 우리에게 전가했다. 변호사의 대응은 다음과 같다.
- “소프트웨어 개발 계약은 단순한 노동력 제공(도급)이 아니라 ‘일의 완성’을 목적으로 하는 계약입니다. ‘완성’이란 계약서에 명시된 주요 기능이 실제 비즈니스 환경에서 정상적으로 구현되어야 함을 의미합니다. 외주 개발사가 납품한 코드는 테스트 환경에서도 오류가 빈번히 발생했으며, 이는 계약의 본질적 목적을 달성하지 못한 미완성 상태입니다.”
- “본 계약상 개발사는 마일스톤을 완성할 때마다 중간 산출물과 검수 요청서를 제출할 의무가 있으며, 이는 잔금 지급의 전제조건입니다. 그러나 개발사는 그러한 검수 요청을 한 적이 없습니다.”
- “발주사가 추가로 기능을 요구한 것이 아니라, 당초 계약 범위에 포함된 기능을 충실히 구현하기 위한 세부 구현 방식을 제안한 것입니다. 당시 개발사는 별다른 이의를 제기하지 않았습니다.”
결국 재판부는 개발사의 청구를 기각했다. 소프트웨어 개발 계약에서 “완성”은 단순히 코딩을 마친 상태가 아니라, 상호 합의된 기능이 객관적으로 완성된 상태임을 명시한 판례를 인용하며, 에이이다트의 계약 해지는 적법하고 잔금 및 추가 비용 지급 의무가 없다는 판결을 내렸다.
판결문을 받아 든 날, 나는 안도감과 함께 아쉬움을 느꼈다. 계약 초기에 ‘완성’ 기준을 더 세세히 정의하고, 중간 검수 절차를 체계화했다면 소송을 피할 수 있었을 것이다.
에이이다트는 이번 분쟁을 통해 기술만큼이나 중요한 ‘관리의 기술’을 배웠다. 법은 분쟁이 터졌을 때 휘두르는 칼이 아니라, 서로 다른 입장의 파트너들이 무한히 평행선을 달리지 않도록 중간에서 잡아주는 이정표였다.
✨ 법무법인 비트의 법률 TIP ✨
-
소프트웨어 용역 계약에서 ‘완성의 객관화’
개발사와 발주처 사이에서 가장 흔한 분쟁 원인은 결과물의 ‘완성도’에 대한 의견 충돌이다. 이를 방지하려면 계약 체결 시 구체적인 기능 명세서와 검수 절차·기준을 꼼꼼히 명시한다. -
과업 변경 및 추가 비용의 서면화
개발 과정에서 발생하는 변동 사항은 반드시 서면으로 남겨야 한다. 추가 기능 개발 시 비용·일정 조정이 명확히 기록되지 않으면, 발주처는 이를 당연한 부가 서비스로, 개발사는 추가 대금 청구 근거로 인식해 분쟁으로 이어질 수 있다.