AI가 사내 도구를 만드는 초기 비용을 크게 낮추면서, 연간 구독료와 개발자 몇 명의 시간, 토큰 비용을 같은 표에 올려 비교하는 일이 늘었다. Kevin Goldsmith는 이 비교가 첫 구현 비용만 보여 준다고 짚는다. 도구를 만든 뒤 몇 년 동안 누가 보안 업데이트를 판단하고, 장애를 받고, 바뀐 업무 요구를 반영할지가 빠져 있기 때문이다.
질문은 "AI로 만들 수 있는가"보다 "3년 차에 누가 고칠 것인가"에 가깝다. 이 기준은 직접 구축이 유리한 범위와 처음부터 외부 제품을 써야 하는 범위를 비용표가 아니라 운영 책임으로 가르는 방법이다.
AI가 낮춘 것은 첫 구현 비용이다
AI 코딩 도구가 달라지게 한 것은 사내 CRM 보조 화면, 보고 레이어, 프로젝트 관리 도구처럼 예전에는 큰 조직에서나 직접 만들 법했던 영역의 계산이다. 요구를 말로 풀고 초안을 빠르게 만들 수 있으니, 라이선스 비용보다 개발비가 낮아 보이는 경우가 생긴다. 회사 고유의 업무 흐름에 맞추는 이점도 전보다 현실적인 근거가 됐다.
그러나 구현이 끝난 순간부터 비용의 이름이 바뀐다. 취약점 공지를 살피고, 업데이트의 영향을 판단하고, 권한과 데이터 처리를 점검하고, 현업의 변경 요구를 코드에 반영해야 한다. AI는 이 작업의 일부를 빠르게 할 수 있어도 공지를 놓치지 않을 사람과 결과를 책임질 사람까지 대신 정하지는 못한다.
Goldsmith가 소개한 인증 기능 사례가 이를 잘 보여 준다. 초기 스타트업에서 검증된 오픈소스 구성 요소를 확장해 인증을 직접 만들었고, 첫 주의 구현 추정은 대체로 맞았다. 뒤이어 업데이트 대응, 고객이 기대하는 기능 추가, 엔터프라이즈 보안 검토 대응이 쌓였다. 회사를 떠난 뒤 약 한 달 만에 해당 구성 요소의 심각한 취약점이 알려졌고, 여러 서비스가 침해됐다. 라이선스 비용을 아낀 판단은 개발 시간과 출시하지 못한 기능, 보안 설명 업무로 되돌아왔다.
1분기에 보이지 않는 비용은 18개월 뒤에 나타난다
내부 도구는 완성할 때 가장 좋아 보인다. 사용자는 만족하고, 만든 사람은 구조를 알고, 아직 업무 규칙도 단순하다. 원문이 제시한 고장은 대개 18개월쯤 뒤에 드러난다. 만든 사람이 다른 일을 맡거나 회사를 떠나고, 새 영업 책임자가 다른 방식으로 동작하길 바라며, 코드를 본 적 없는 사람이 맥락부터 익혀야 하는 시점이다.
그래서 구독료와 초기 개발비만 비교하면 비용을 낮은 시점에 고정하게 된다. 운영 주체가 정해져 있지 않은 도구는 기능 요청이 들어올 때마다 우선순위를 다시 다투고, 보안 패치는 누군가의 본 업무를 멈춰 세워야 한다. 팀 이름이 아니라 실제 담당자의 이름을 적으라는 Goldsmith의 제안은 이 공백을 드러내는 간단한 방법이다. 팀은 호출을 받지 않지만 사람은 받는다.
만들기 전에 답할 네 가지는 무엇인가
첫째는 장애 반경이다. 멈추거나 침해됐을 때 불편한 대시보드인지, 인증이나 결제처럼 사업을 멈추게 할 수 있는 기능인지 구분한다. 둘째는 소유 비용이다. 앞으로 수년간 누가 모니터링, 패치, 보안 점검과 야간 대응을 맡는지 적는다. 셋째는 차별화다. 경쟁사가 따라 하기 어려운 고객 경험이나 업무 처리량을 실제로 바꾸는지, 단지 개발팀의 선호에 더 맞는지를 가른다. 넷째는 탈출 경로다. 더 나은 외부 제품이 생겼을 때 고통 없이 교체할 수 있는지 본다.
이 네 질문은 작은 사내 도구와 영구적으로 의존할 기반 기능을 구분한다. 첫 번째는 영향 범위가 제한되고 교체 가능성이 있는 경우다. 두 번째는 처음에는 비슷해 보여도 인증, 신원 관리, 결제, 고객 데이터를 다루거나 핵심 경로에 놓여 있어 장애와 보안의 반경이 훨씬 크다. 후자의 라이선스 절감은 한 번의 사고 비용을 설명하지 못한다.
AI 시대에 더 맞는 직접 구축의 조건
직접 구축의 선은 분명히 이동했다. 시중 제품이 업무 방식을 지나치게 바꾸게 만드는 작은 서비스, 어떤 공급사도 만들어 주지 않을 시스템 간 연결, 업무 처리량을 실질적으로 바꾸는 제한된 내부 도구는 후보가 될 수 있다. 특히 시장에 아직 제품이 없고 나중에 공식 대안을 받아들일 수 있는 연결 도구는 임시로 만들 이유가 있다.
Goldsmith는 회사에서 공급사의 공식 MCP 서버가 없을 때 내부 MCP 서버를 만든 사례를 든다. 공식 서버가 나오자 자체 서버를 옮겨 탔다. 여기서 직접 구축은 영구 자산이 아니라 시장이 따라올 때까지 쓰는 다리였다. 처음부터 교체를 설계했기에 유지보수 책임을 끝없이 안고 가지 않았다.
AI는 "직접 만들기"의 문턱을 낮췄다. 그만큼 의사결정 회의에서는 초기 견적보다 보유 기간을 먼저 펼쳐야 한다. 3년 차의 패치 담당자, 교체 가능한 경계, 실패했을 때 멈추는 업무를 답할 수 있을 때에만 사내 도구를 운영 대상으로 검토할 수 있다.
출처: Kevin Goldsmith, Build vs Buy When Building Just Got Cheap, 2026년 8월 23일