콤퓨타수선집은 문체부지정 공식
저작권대리중개업체 육하원칙과 함께합니다.

콤퓨타생각 AI 모델이 사라지면 누가 책임져야 할까? AI 시대에 달라지는 유지보수의 기준

페이지 정보

본문

작성일

홈페이지나 프로그램을 개발해 납품하면 일반적으로 하나의 프로젝트가 끝났다고 생각합니다.


기획하고,


개발하고,


검수하고,


납품합니다.


이후 문제가 생기면 그것이 개발 과정에서 발생한 문제인지, 유지보수가 필요한 문제인지 판단합니다.


그런데 최근 AI가 프로그램 안으로 들어오기 시작하면서 이 익숙한 구조에도 조금 다른 문제가 생기고 있다고 생각합니다.


프로그램이 정상적으로 개발되어 납품됐더라도, 그 프로그램이 의존하고 있는 AI 모델은 계속해서 변할 수 있기 때문입니다.


그렇다면 한 가지 질문이 생깁니다.


우리가 정상적으로 개발해서 납품한 프로그램의 AI 모델이 어느 날 사라진다면, 그 프로그램은 누가 책임져야 할까요?


■ 어제까지 정상적으로 작동하던 프로그램이 오늘 작동하지 않는다면


상황을 하나 가정해보겠습니다.


콤퓨타수선집이 고객사의 홈페이지에 AI 상담 기능을 개발했습니다.


개발 당시에는 정상적으로 작동했고 고객사의 검수까지 완료한 뒤 납품했습니다.


그런데 6개월 뒤 해당 기능에 연결되어 있던 외부 AI 모델의 서비스가 종료됩니다.


개발회사가 프로그램을 잘못 만든 것도 아닙니다.


고객사가 잘못 사용한 것도 아닙니다.


외부 AI 기업이 기존 모델의 서비스를 종료한 것입니다.


하지만 고객이 보는 상황은 훨씬 단순합니다.


“어제까지 되던 기능이 오늘은 안 된다.”


그리고 결국 누군가는 이 문제를 해결해야 합니다.


우리는 이런 작업을 단순한 하자보수로 보기는 어렵다고 생각합니다.


기존 프로그램을 관리한다는 점에서는 유지보수에 해당하지만, 새로운 모델에 맞춰 프로그램을 변경하고 다시 검증해야 한다면 추가개발의 영역도 함께 존재하기 때문입니다.


그래서 결국 중요한 것은 누구의 잘못인가를 판단하는 것보다 이러한 상황을 처음부터 어떻게 정의하고 합의했는가라고 생각합니다.


■ AI 모델의 변화까지 개발회사가 책임질 수 있을까?


우리는 이전 글에서 개발회사가 판매하는 중요한 가치 중 하나가 결과물에 대한 책임이라고 이야기했습니다.


그 생각은 지금도 같습니다.


하지만 결과에 책임을 진다는 것과 앞으로 발생할 수 있는 모든 변화에 무한한 책임을 진다는 것은 다른 문제입니다.


OpenAI가 모델을 종료할 수도 있습니다.


Anthropic이 API 정책을 변경할 수도 있습니다.


AI 서비스의 이용요금이 변경될 수도 있고 기존에 제공되던 기능이 새로운 모델에서는 다르게 작동할 수도 있습니다.


이러한 변화까지 개발회사가 모두 예측하고 무상으로 책임진다고 약속하는 것은 현실적으로 어렵습니다.


그렇다고 반대로


“외부 AI 회사가 바꾼 것이니 우리는 책임이 없습니다.”


라고 말하는 것도 우리가 생각하는 개발회사의 역할과는 조금 다릅니다.


고객은 어떤 모델을 선택해야 하는지 판단하기 어려울 수 있고, 결국 그것을 기술적으로 검토하고 시스템으로 만든 곳은 개발회사이기 때문입니다.


그래서 AI 시대의 책임은 어느 한쪽이 모든 것을 부담하는 방식보다 책임의 범위를 미리 합의하고 변화가 발생했을 때 함께 대응할 수 있는 관계를 만드는 것에 가까워질 것이라고 생각합니다.


■ 고객에게 AI 모델을 선택하라고 하는 것도 답은 아닙니다


그렇다면 처음부터 고객에게 선택권을 주면 해결될까요?


“GPT를 사용하시겠습니까?”


“Claude를 사용하시겠습니까?”


“Gemini를 사용하시겠습니까?”


현실적으로 많은 고객사는 이 질문을 기술적으로 판단하기 어렵습니다.


각 모델의 성능과 비용, API 구조, 지원 기능, 향후 변경 가능성까지 비교해 자신에게 가장 적합한 모델을 판단하기 위해서는 상당한 기술적 이해가 필요합니다.


그렇다고 고객이 특정 모델을 선택했다는 이유로 이후 발생하는 모든 문제에 대해 개발회사가 책임이 없다고 말하는 것도 적절하지 않다고 생각합니다.


반대로 개발회사가 모델을 선택했다고 해서 빠르게 변화하는 AI 기술 환경 전체를 책임지겠다고 약속할 수도 없습니다.


그래서 우리가 생각하는 가장 현실적인 방법은 선택권과 책임을 한쪽에 넘기는 것이 아니라 각자의 역할을 분명하게 만드는 것입니다.


개발회사는 개발 당시 발생할 수 있는 기술적 위험을 최대한 파악하고 설명합니다.


고객사는 서비스 운영 과정에서 외부 AI 환경이 변화할 수 있다는 점을 이해합니다.


그리고 실제 변화가 발생했을 때 개발회사가 상황을 빠르게 파악하고 대응할 수 있는 관계를 유지합니다.


우리는 이것을 일방적인 책임보다 공동의 책임을 가지고 서비스를 운영하는 관계에 가깝다고 생각합니다.


■ 그래서 계약서도 달라져야 한다고 생각합니다


AI 기능이 포함된 프로그램이 많아질수록 계약서와 견적서에도 이런 특성이 반영될 필요가 있다고 생각합니다.


기존에는 비교적 명확하게


개발 범위


개발 기간


비용


하자보수 기간


유지보수 범위


등을 정했다면, AI가 외부 서비스로 연결되는 프로그램에서는 몇 가지 새로운 변수가 생깁니다.


외부 AI 모델의 서비스 종료


API 정책 변경


AI 서비스 이용료 변경


기능 또는 사용 조건 변경


대체 모델 적용에 필요한 추가 작업


같은 문제입니다.


이러한 변화가 발생했을 때 어디까지 기존 계약 범위이고, 어디부터 추가 유지보수 또는 개발에 해당하는지 처음부터 협의할 필요가 있다고 생각합니다.


중요한 것은 개발회사의 책임을 피하기 위해 계약서에 면책 조항을 잔뜩 넣는 것이 아닙니다.


반대로 고객에게 무제한적인 유지보수를 약속하는 것도 아닙니다.


앞으로 발생할 수 있는 변화를 서로 알고 계약을 시작하는 것.


우리는 이것이 오히려 더 책임 있는 계약이라고 생각합니다.


■ 모델 변경에 따른 작업에는 별도의 비용이 필요하다고 생각합니다


외부 AI 모델이 종료되어 새로운 모델로 변경해야 하고 실제 개발자의 추가 작업이 발생한다면 우리는 원칙적으로 별도의 비용이 발생하는 것이 맞다고 생각합니다.


기존 개발 과정에서 발생한 하자를 수정하는 것과 외부 서비스 환경이 바뀌어 프로그램을 새롭게 수정하는 것은 성격이 다르기 때문입니다.


다만 여기서 개발회사도 해야 할 일이 있습니다.


처음부터 버전 변화에 지나치게 영향을 받는 구조로 서비스를 설계하지 않는 것입니다.


AI 모델이 바뀔 때마다 프로그램 전체를 다시 만들어야 한다면 유지보수 부담은 계속 커질 수밖에 없습니다.


따라서 변화가 발생했을 때 영향을 받는 영역을 가능한 한 분리하고, 새로운 모델이나 서비스로 전환할 때 전체 시스템에 미치는 영향을 줄이는 구조를 고민할 필요가 있다고 생각합니다.


모든 변화를 막을 수는 없어도 변화에 대응하기 어려운 프로그램과 대응하기 쉬운 프로그램은 다를 수 있기 때문입니다.


■ ‘개발 완료’라는 말의 의미도 조금 달라질 수 있습니다


우리가 이번 주제를 이야기하면서 가장 크게 느낀 부분은 이것입니다.


AI가 프로그램의 중요한 구성요소가 될수록


착수 → 개발 → 납품 → 완료


라는 전통적인 프로젝트 구조만으로 서비스를 설명하기 어려워질 수 있다는 것입니다.


AI 모델은 바뀝니다.


API도 바뀝니다.


가격도 바뀔 수 있습니다.


정책과 사용할 수 있는 기능도 달라질 수 있습니다.


그렇다면 AI가 깊게 연결된 프로그램은 완성된 상태로 한번 만들어 넘기는 제품이라기보다 변화하는 외부 환경 속에서 계속 관리해야 하는 시스템에 가까워질 수도 있습니다.


만들어서 넘기는 개발


↓


운영하면서 관리하는 개발


이러한 변화가 생긴다면 개발회사의 역할 역시 달라질 수 있습니다.


코드를 작성하고 납품하는 것만으로 관계가 끝나는 것이 아니라, 고객의 시스템이 변화하는 외부 기술 환경 안에서 계속 작동하도록 관리하는 역할이 중요해질 수 있습니다.


■ 단건 유지보수에서 지속적인 관리로


홈페이지 유지보수 역시 지금까지는 문제가 발생할 때마다 요청하는 방식이 많았습니다.


“이 부분을 수정해주세요.”


↓


견적


↓


작업


↓


완료


↓


다음 요청


하지만 AI 기능이 많아지고 외부 기술에 대한 의존성이 높아지면 이러한 단건 방식만으로 관리하기 어려운 서비스도 생길 수 있다고 생각합니다.


문제가 발생한 뒤 처음 시스템을 분석하는 것보다 평소 어떤 외부 서비스와 모델을 사용하고 있는지 알고 있는 개발사가 지속적으로 관리하는 편이 빠르게 대응할 수 있는 경우가 있기 때문입니다.


그래서 우리는 앞으로 홈페이지와 소프트웨어 유지보수에서도 일종의 ‘유지보수 보험’과 비슷한 구조가 필요할 수 있다고 생각합니다.


아무 문제가 없을 것이라고 보장하는 서비스가 아닙니다.


문제가 생겼을 때


누가 이 시스템을 알고 있는지,

누가 상황을 확인할 것인지,

그리고 누가 해결하기 위해 움직일 것인지


가 정해져 있는 관계에 가깝습니다.


■ AI 시대의 유지보수란 ‘믿음’이라고 생각합니다


AI 기술이 빠르게 변하는 환경에서 개발회사도 앞으로 어떤 모델이 종료될지 모두 알 수 없습니다.


고객도 알 수 없습니다.


AI 기업의 정책 변화까지 어느 한쪽이 통제할 수도 없습니다.


결국 모든 미래의 문제를 계약서에 적어놓는 것도 불가능합니다.


그래서 오히려 중요한 것은 문제가 발생하지 않는다고 약속하는 것이 아니라 문제가 발생했을 때 어떻게 행동할 것인지에 대한 신뢰라고 생각합니다.


개발회사는 자신이 만든 시스템을 이해하고 있어야 합니다.


앞으로 생길 수 있는 문제를 가능한 범위에서 미리 살펴야 합니다.


변화가 발생하면 빠르게 상황을 파악해야 합니다.


그리고 고객과 책임의 범위를 투명하게 이야기하면서 해결 방법을 찾아야 합니다.


고객 역시 외부 기술의 변화까지 개발회사가 무한하게 책임질 수 없다는 사실을 이해할 필요가 있습니다.


그렇게 서로의 역할을 알고 계속 관계를 유지할 수 있을 때 비로소 빠르게 변화하는 기술을 서비스에 사용할 수 있다고 생각합니다.


그래서 우리가 생각하는 AI 시대의 유지보수는 단순히 프로그램을 고치는 일이 아닙니다.


AI 시대의 유지보수란, 결국 믿음입니다.


문제가 절대 생기지 않을 것이라는 믿음이 아니라,


문제가 생겼을 때 함께 해결할 사람이 있다는 믿음입니다.


────────────────────


■ 함께 읽으면 좋은 글


콤퓨타이슈

「AI 모델도 서비스가 종료된다 — GitHub·Claude·Gemini에서 나타나는 모델 교체」


콤퓨타지식

「AI 모델이 바뀌면 프로그램에는 어떤 일이 생길까? 모델 폐기와 마이그레이션의 원리」