Build vs Buy - AI로 개발은 싸졌지만, 3년 뒤 유지보수는 누가 맡을까?

AI는 소프트웨어의 초기 개발 비용을 크게 낮췄지만, 수년간 유지보수와 보안, 장애 대응을 책임지는 운영 비용까지 없애지는 못함 직접 만들지는 가격뿐 아니라 장애나 침해의 피해 범위, 장기 운영 책임자, 사업 차별화, 교체할 경로를 기준으로 판단해야 함 자체 구축한 인증은 라이선스 절감액을 유지보수와 보안 심사 대응에 소모한 반면, 공식 제품이 나오자 교체한 내부 MCP 서버는 필요한 기간만 운영한 자체 개발 사례였음 비용은 3~5년 총소유비용으로 비교하고, 내부 도구마다 취약점 발견과 패치를 맡을 담당자를 지정해 분기별로 책임 공백을 점검해야 함 직접 만들 가치가 커진 영역은 작고 영향이 제한적이며 교체하기 쉬운 도구로, 사업을 차별화하는 기능은 만들고 그저 안정적으로 작동해야 하는 기능은 구매한다는 기준은 유지됨 일주일 만에 만든 인증 기능, 문제는 그다음부터 초기 B2B 스타트업에서 비용을 아끼기 위해 유명 오픈소스 구성요소를 확장해 인증 시스템을 자체 구축함 특수 요구사항을 반영하는 데 약 일주일이 걸릴 것이라는 예상은 대체로 맞았고, 초기 고객도 문제없이 사용함 부담은 구현이 끝난 뒤에 나타남 인증 공격에 대응하는 잦은 업데이트와 보안 패치를 계속 따라가야 했음 상용 인증 서비스라면 기본으로 제공했을 기능까지 직접 개발해야 했음 기업 고객의 보안 심사에서 신뢰받는 공급업체 이름을 제시하는 대신, 자체 인증의 안전성을 입증하는 데 상당한 시간을 써야 했음 아낀 라이선스 비용은 개발 시간, 출시하지 못한 기능, 경영진의 고객 대응 시간으로 되돌아옴 결국 상용 인증 서비스로 전환했으며, 약 한 달 뒤 기존 오픈소스 구성요소에서 심각한 취약점이 발생해 여러 사용 사이트가 침해당함 약 30일 차이로 피해를 피했지만, 운이 좋았던 것과 처음부터 올바르게 판단한 것은 다름 이미 있는 것을 다시 만들려면 사업적 이유가 필요함 “이미 있는 것을 새로 만들지 말자”는 원칙은 자체 개발을 금지하는 것이 아니라 매우 강한 사업적 이유를 요구하는 기준 기존 제품이 마음에 들지 않거나, 라이브러리를 다르게 설계하고 싶거나, 주말이면 더 나은 대안을 만들 수 있다는 이유만으로는 부족함 기준을 지나치게 유연하게 두면 이미 만들고 싶은 것을 정당화할 구실을 찾기 쉬움 엔지니어링 시간은 여전히 대부분 기업에서 가장 희소한 자원이므로, 비싼 개발 인력은 경쟁사와의 차별화에 투입해야 함 자체 캐싱 계층도 기존 제품으로 감당할 수 없는 규...