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