AI로 개발이 싸져도 유지보수 책임은 사라지지 않는다

AI 덕분에 소프트웨어를 직접 만드는 비용은 낮아졌지만, 만든 뒤 관리하고 보안 패치를 적용하는 비용까지 줄어든 것은 아니다. 케빈 골드스미스(Kevin Goldsmith)는 무엇을 만들지보다 누가 몇 년 뒤까지 책임질지를 먼저 따져야 한다고 말한다.

만들기와 구매를 가르는 기준

골드스미스는 초기 B2B 스타트업에서 비용을 아끼려고 오픈소스 구성요소를 확장해 인증 시스템을 만들었다. 개발 기간은 예상대로 약 일주일이었지만, 이후 보안 업데이트를 계속 따라가고 고객이 원하는 기능을 추가해야 했다. 기업 고객을 대상으로 보안 검토를 받을 때 자체 인증 시스템의 신뢰성을 설명하는 일도 부담이었다. 라이선스 비용을 아낀 대신 개발 시간과 다른 기능을 만들 기회, 관리자의 시간이 들었다.

골드스미스가 회사를 떠난 뒤 회사는 외부 업체의 인증 솔루션으로 옮겼다. 약 한 달 후 해당 오픈소스 구성요소에서 심각한 취약점이 발견됐고, 이를 사용하는 여러 사이트가 침해됐다. 회사는 취약점을 약 30일 차이로 피했다. 그는 운이 좋았던 것과 올바른 결정을 한 것은 다르다고 짚는다.

AI는 무언가를 만드는 첫 비용을 낮췄지만, 이미 만든 것을 계속 책임지는 비용은 그대로 남겼다는 것이 골드스미스의 판단이다. 업체는 제품을 계속 업데이트할 사업적 이유가 있고, 오픈소스 프로젝트가 관리되지 않으면 다른 프로젝트로 옮길 수 있다. 내부 도구는 누군가 업무를 멈추고 업데이트해야 한다. AI가 코딩을 돕더라도 취약점 정보를 확인하고 대응 여부를 판단하며 결과를 책임질 사람은 필요하다.

직접 만들지 판단하기 전에 골드스미스는 네 가지를 따져보라고 제안한다.

• 실패하거나 침해되거나 관리가 끊겼을 때 피해가 어디까지 번지는가. 내부 대시보드가 멈추는 일과 인증 시스템이 멈추거나 침해되는 일은 위험의 크기가 다르다.
• 앞으로 몇 년 동안 누가 모니터링하고 패치하며 보안을 맡을 것인가. 팀이 아니라 담당자의 이름을 정해야 한다.
• 직접 만들면 사업에 중요한 차별점이 생기는가, 아니면 기존 제품보다 취향에 맞는가. 회사에 실질적인 이득을 주는 적합성은 이제 고려할 이유가 될 수 있지만, 그 이득이 의미 있어야 한다.
• 1년 뒤 적절한 외부 제품이 나오면 얼마나 쉽게 바꿀 수 있는가. 임시 대안으로 만들었다면 대체 제품이 나왔을 때 실제로 옮길 계획도 필요하다.

몇 년 치 비용과 보안 위험을 함께 본다

비교를 연간 라이선스 비용과 초기 개발 기간에만 맞추면 유지보수, 대기 근무, 패치, 규정 준수 증빙, 담당자가 떠난 뒤의 재작업이 빠진다. 골드스미스는 초기 개발 시간에 연간 유지보수와 지원·규정 준수 작업을 더해 3~5년 비용을 추산하고, 같은 기간의 라이선스·통합·설정 비용과 비교하라고 제안한다. 개발자 시간의 실제 비용도 계산에 포함해야 한다.

그렇다고 외부 의존성이 언제나 더 안전한 선택이라는 뜻은 아니다. 제3자 라이브러리도 공급망 공격의 경로가 될 수 있어, 작은 구성요소라면 직접 만들어 의존성을 줄이는 편이 나을 수 있다고 골드스미스는 본다. 다만 직접 만든 쪽은 보안 권고를 확인하고 패치를 배포할 책임도 맡는다. 규모와 의존도, 사업 차별성, 팀의 관리 역량을 함께 봐야 한다.

그는 인증과 신원 확인, 결제, 고객 데이터를 보유하는 시스템, 핵심 업무 경로에 놓인 기능은 직접 만들지 않는 편이 낫다고 말한다. 이런 기능을 전문으로 제공하는 업체가 보안과 운영에 투자하는 수준을 소수 개발자와 AI 비용으로 따라잡기 어렵다는 이유다. 다만 해당 기능 자체가 사업의 차별점이라면 판단이 달라질 수 있다.

직접 만들더라도 대체 경로를 마련한 사례도 소개한다. 회사에서 여러 업무를 자동화하기 위해 MCP 서버를 쓰기 시작했을 때, 일부 업체는 공식 서버를 제공하지 않았다. 회사는 해당 업체 API를 이용해 내부용 MCP 서버를 만들었고, 공식 제품이 출시되자 직접 만든 서버를 대체했다. 골드스미스는 인증 시스템 사례와 달랐던 점으로 피해 범위와 빠져나갈 방법이 있었는지를 든다.

내부 도구와 인력에도 같은 기준을 적용한다

AI로 내부 관리 도구나 보고 도구를 직접 만드는 계산이 달라졌지만, 골드스미스는 비용만으로 결론을 내리지 말라고 한다. 눈앞의 시연용 결과물은 인상적일 수 있어도, 외부 제품이 계속 제공하는 기능과 보안, 운영을 내부에서 맡아야 하는 비용은 시연에 드러나지 않는다. 도입 전에는 다년간의 총소유비용과 담당자를 따져야 한다.

그는 이번 주에 팀이 소유한 내부 도구를 나열하고, 취약점이 내일 공개되면 누가 패치할지, 취약점을 어떻게 알아차릴지 확인하라고 제안한다. 담당자가 정해지지 않은 도구는 교체하거나 누군가가 책임을 맡아야 한다. 검토를 한 번으로 끝내지 않고 분기마다 되풀이하는 방안도 제시한다.

같은 판단은 인력 구성에도 적용된다. 사업 차별성과 거리가 먼 역량 공백은 에이전트로 일부 메울 수 있지만, 사업에 중요한 분야라면 적은 수의 숙련된 인력을 뽑아 에이전트의 도움을 받는 편이 낫다고 골드스미스는 설명한다. 토큰 비용을 쓰는 선택도 장기적으로 책임질 대상을 정하는 결정이라는 점은 달라지지 않는다.

골드스미스가 제시하는 기준은 사업이 달라져야 하는 부분은 만들고, 그저 작동해야 하는 부분은 구매하는 것이다. 직접 개발이 싸졌다는 사실만으로 충분한 근거가 되지는 않는다. 비용은 만드는 데서 끝나지 않고, 계속 관리하고 책임지는 데까지 이어진다.

주제에 관한 확장 논의는 Build vs Buy When Building Got Cheap에서 들을 수 있다.