•AI는 소프트웨어의 초기 개발 비용 을 크게 낮췄지만, 수년간 유지보수와 보안, 장애 대응을 책임지는 운영 비용 까지 없애지는 못함
•직접 만들지는 가격뿐 아니라 장애나 침해의 피해 범위, 장기 운영 책임자, 사업 차별화, 교체할 경로 를 기준으로 판단해야 함
•자체 구축한 인증은 라이선스 절감액을 유지보수와 보안 심사 대응에 소모한 반면, 공식 제품이 나오자 교체한 내부 MCP 서버 는 필요한 기간만 운영한 자체 개발 사례였음
•비용은 3~5년 총소유비용 으로 비교하고, 내부 도구마다 취약점 발견과 패치를 맡을 담당자를 지정해 분기별로 책임 공백을 점검해야 함
•직접 만들 가치가 커진 영역은 작고 영향이 제한적이며 교체하기 쉬운 도구로, 사업을 차별화하는 기능은 만들고 그저 안정적으로 작동해야 하는 기능은 구매한다 는 기준은 유지됨
일주일 만에 만든 인증 기능, 문제는 그다음부터
•초기 B2B 스타트업에서 비용을 아끼기 위해 유명 오픈소스 구성요소를 확장해 인증 시스템을 자체 구축 함
•특수 요구사항을 반영하는 데 약 일주일이 걸릴 것이라는 예상은 대체로 맞았고, 초기 고객도 문제없이 사용함
•부담은 구현이 끝난 뒤에 나타남
•인증 공격에 대응하는 잦은 업데이트와 보안 패치를 계속 따라가야 했음
•상용 인증 서비스라면 기본으로 제공했을 기능까지 직접 개발해야 했음
•기업 고객의 보안 심사에서 신뢰받는 공급업체 이름을 제시하는 대신, 자체 인증의 안전성을 입증하는 데 상당한 시간을 써야 했음
•아낀 라이선스 비용은 개발 시간, 출시하지 못한 기능, 경영진의 고객 대응 시간 으로 되돌아옴
•결국 상용 인증 서비스로 전환했으며, 약 한 달 뒤 기존 오픈소스 구성요소에서 심각한 취약점이 발생해 여러 사용 사이트가 침해당함
•약 30일 차이로 피해를 피했지만, 운이 좋았던 것과 처음부터 올바르게 판단한 것은 다름
이미 있는 것을 다시 만들려면 사업적 이유가 필요함
•“이미 있는 것을 새로 만들지 말자”는 원칙은 자체 개발을 금지하는 것이 아니라 매우 강한 사업적 이유 를 요구하는 기준
•기존 제품이 마음에 들지 않거나, 라이브러리를 다르게 설계하고 싶거나, 주말이면 더 나은 대안을 만들 수 있다는 이유만으로는 부족함
•기준을 지나치게 유연하게 두면 이미 만들고 싶은 것을 정당화할 구실을 찾기 쉬움
• 엔지니어링 시간은 여전히 대부분 기업에서 가장 희소한 자원 이므로, 비싼 개발 인력은 경쟁사와의 차별화에 투입해야 함
•자체 캐싱 계층도 기존 제품으로 감당할 수 없는 규모를 처리하고 고객이 체감할 개선으로 이어진다면 만들 이유가 있음
•반면 회사 밖에서는 알아차리지 못할 소수의 예외만 해결한다면 자체 개발을 정당화하기 어려움
AI가 바꾼 것은 만드는 비용이지, 계속 운영하는 비용이 아님
•자체 개발 논의가 개별 라이브러리를 넘어 CRM, 프로젝트 관리, 내부 관리 도구와 보고 시스템 전체를 대체하는 예산 비교 로 확대됨
•Microsoft, Adobe, Spotify 같은 대기업은 규모와 특수한 요구사항 때문에 전담 팀이 비차별화 소프트웨어를 만드는 것이 합리적이었음
•과거에는 300명 규모 기업에서 성립하지 않던 계산이 개발자 몇 명과 AI 토큰 비용으로 달라졌으며, 이 변화는 진지하게 검토할 가치가 있음
•회사의 업무 방식에 꼭 맞는 도구를 저렴하게 만들 수 있게 되면서, 업무 적합성도 이전보다 현실적인 자체 개발 근거 가 됨
•하지만 만든 뒤의 관리 방식은 다름
•상용 공급업체는 사업을 지속하기 위해 제품을 계속 업데이트함
•오픈소스는 유지관리자가 갱신하며, 관리가 끊기면 다른 프로젝트로 옮길 수 있음
•내부 도구를 업데이트하려면 누군가 기존 업무를 멈추고 그 일을 맡아야 함
•AI가 패치 작성을 도와도 새 취약점을 발견하고 중요도를 판단하며 수정 결과를 책임지는 일 은 남음
•자체 개발의 실패는 첫 분기보다 18개월 뒤에 드러나기 쉬움
•처음 만들던 사람이 떠나고, 새 영업 책임자가 다른 동작을 요구하며, 코드를 처음 보는 사람이 시스템을 익혀야 함
•초기에는 잘 작동하고 비용도 적게 들어 보여 판단 오류를 발견하기 어려움
•핵심 질문은 “만드는 편이 더 싼가”가 아니라 “무엇을 앞으로도 계속 책임질 것인가” 임
직접 만들기 전에 확인할 네 가지 질문
• 피해 범위 : 장애나 침해가 발생하거나 유지보수가 중단되면 무엇이 영향을 받는가
•내부 대시보드 중단은 불편에 그칠 수 있지만, 인증 시스템의 중단이나 침해는 회사의 존립을 위협할 수 있음
• 장기 운영 비용과 책임 : 향후 수년간 감시, 패치, 보안과 새벽 2시 장애 대응을 누가 맡는가
•팀 이름이 아니라 실제로 호출을 받고 문제를 해결할 개인의 이름이 필요함
• 사업 차별화 : 고객이나 사업에 중요한 개선인가, 단지 기존 대안보다 취향에 잘 맞는가
•회사 업무에 더 잘 맞는다는 이유는 이제 유효하지만, 개선 폭이 실질적이어야 함
• 교체할 경로 : 1년 뒤 좋은 외부 제품이 나오면 큰 부담 없이 자체 도구를 버릴 수 있는가
•공백을 메우기 위해 잠시 만드는 것과 영구적으로 운영하는 것은 별개의 결정임
•이 질문들은 작고 교체하기 쉬운 도구 와 여러 시스템이 의존하는 영구적인 기반 시설을 구분함
•회의에서 하나만 묻는다면 “3년 차에는 누가 패치하는가” 를 물어야 하며, 답이 없다면 의사결정은 끝나지 않은 상태임
공식 제품이 나오자 교체한 MCP 서버
•회사 업무 자동화에 MCP 서버를 도입할 때 일부 공급업체가 공식 서버를 제공하지 않아, 해당 업체 API를 사용하는 내부 서버를 구축함
•공식 MCP 서버가 출시되자 즉시 전환해 자체 버전을 무기한 유지보수하고 보안을 관리할 책임 을 피함
•공급업체에는 자사 API와 제품 변화에 맞춰 서버를 정상 작동하고 최신 상태로 유지할 동기가 훨씬 큼
•인증 사례와의 차이는 엔지니어링 품질보다 피해 범위와 교체할 경로 에 있었음
•MCP 서버는 대안이 없어서 만들었고, 인증은 더 저렴해서 만들었으며, 두 사례 중 타당한 이유는 전자였음
직접 만들 가치가 커진 영역과 여전히 구매할 영역
• 작고 범위가 제한된 맞춤형 개발 은 이전보다 합리적일 수 있음
•상용 제품과 오픈소스 대안이 회사의 업무 방식을 크게 바꾸도록 요구하는 소규모 서비스와 구성요소
•어떤 공급업체도 대신 만들어주지 않을 시스템 간 연결과, 과거 외부 컨설팅에 맡겼을 맞춤 작업
•문제가 생겨도 영향이 제한적이며, 회사에 맞는 동작이 실제 업무 처리량을 개선하는 내부 도구
•아직 외부 대안이 없어 만들되 시장이 따라오면 실제로 교체할 임시 도구
• 인증, 신원 관리, 결제, 고객 데이터 보관 시스템과 서비스 운영의 핵심 기능 은 여전히 자체 개발의 위험이 큼
•자체 인증에서 발생할 수 있는 침해 사고는 라이선스 절감액으로 보상하기 어려움
•해당 기능의 안정성과 보안만 전담하는 기업의 투자를 개발자 몇 명과 토큰 비용으로 따라잡기도 어려움
•단, 그 기능 자체가 회사의 사업이라면 차별화 영역에 해당하며, 애초에 훨씬 큰 투자가 필요한 결정임
비용 비교는 3~5년 단위로
•개발자 2명, 3주와 토큰 수백 달러만 계산해 연간 1만 달러 라이선스와 비교하면, 구현 이후의 비용 을 놓치게 됨
•자체 개발의 총소유비용에는 다음을 포함해야 함
•초기 개발과 연간 유지보수, 패치와 업그레이드
•온콜과 장애 대응에 투입되는 실제 개발자 인건비
•고객 지원, 규정 준수 증빙과 SOC 2에 미치는 영향
•담당자 이탈에 따른 인수인계와 재작업 예상 비용
•예를 들어 초기 개발 6주에 매년 유지보수 3주 , 추가 지원과 규정 준수 시간을 더해 3~5년 비용을 계산함
•구매하는 경우도 같은 기간의 라이선스, 통합과 설정 비용을 합산해야 함
•CFO가 먼저 단기 비용만 비교하기 전에 기술 조직이 이 표를 준비하면, 라이선스 구매로 어떤 업무와 위험을 외부에 맡기는지 설명하기 쉬워짐
외부 의존성이 항상 더 안전한 것도 아님
•외부 라이브러리 하나를 추가할 때마다 공급망 공격에 노출되는 경로 도 늘어남
•기능의 범위가 작다면 의존성을 추가하기보다 직접 구현하는 편이 위험을 줄일 수도 있음
•다만 직접 만들면 보안 공지를 확인하고 패치를 배포할 책임도 맡게 되며, 이를 감당할 인력이 없는 팀도 많음
•따라서 외부 의존성이 언제나 더 안전하다고 가정할 수는 없음
• 구성요소의 규모, 의존하는 시스템의 범위, 사업 차별화와 실제 관리 역량 을 함께 따져야 함
주의할 두 가지 실패 패턴
• 주말 시제품이 검토 없이 실무에 투입되는 경우
•누군가 만든 시제품이 정식 의사결정 없이 실제 운영 시스템이 됨
•회사가 장기 운영을 맡기로 결정하지 않았는데도 유지보수 책임이 생김
• 조금 더 편하다는 이유로 자체 구현을 유지하는 경우
•기존 제품보다 나은 점은 있지만, 개선 폭이 영구적인 유지보수 책임을 정당화할 만큼 크지 않음
•조금 더 낫다는 것과 의미 있게 더 낫다는 것은 다름
같은 판단은 소프트웨어뿐 아니라 인력에도 적용됨
•새로운 기술이나 사업 영역의 역량 부족은 과거 계약직 활용, 교육, 채용과 팀 신설로 해결했지만, 비핵심 역량 일부는 이제 에이전트로 보완 할 수 있음
•사업을 차별화하지 않는 영역은 지식이 널리 알려져 있어 에이전트가 잘 처리하는 영역과 겹치는 경우가 많음
•이런 영역에서는 분야별 전문가를 늘리기보다 폭넓은 역량을 가진 소수 인력이 에이전트의 도움을 받아 대응할 수 있음
• 사업 핵심 역량 이라면 전략이 달라짐
•과거 5명 팀을 채용했을 상황에서 뛰어난 인력 1~2명을 채용하고 에이전트로 보강하는 방식이 가능함
•연간 SaaS 계약 대신 토큰에 지출하더라도 역량을 구매하고 그 사용 결과를 책임지는 결정 이라는 점은 같음
•구매 대상이 소프트웨어에서 역량으로 바뀌어도 피해 범위와 운영 책임은 사라지지 않으며, 리더는 사람으로 메울 공백과 외부 역량에 지출해 메울 공백을 구분해야 함
엔지니어, 재무팀과 경영진에게 설명할 것
• 엔지니어에게는 흥미와 사업적 타당성의 차이 를 설명해야 함
•문제가 흥미롭거나 기존 제품의 설계에 불만이 있다는 감정은 정당하지만, 그 자체가 사업적 근거는 아님
•의욕을 꺾기보다 회사의 차별화에 기여하는 문제로 에너지를 돌려야 하며, 이런 문제는 대개 더 어렵고 즉각적인 재미는 적음
• 재무팀에는 장기 비용과 외부에 맡기는 책임 을 보여줘야 함
•AI 비용까지 같은 예산에 들어오면서 소프트웨어 지출에 대한 검토가 강화됨
•CTO나 VPE가 라이선스 비용을 설명하려면 3년간 자체 운영할 비용과, 구매로 대신 처리하게 되는 업무를 제시해야 함
• 경영진에게는 인상적인 데모에 빠진 작업 을 설명해야 함
•영업 담당자나 프로덕트 매니저가 이틀 만에 만든 데모가 연간 수십만 달러 제품을 대체하는 것처럼 보일 수 있음
•하지만 이후 필요한 운영과 지원, 유지보수 인력은 데모에서 드러나지 않음
•공급업체에는 제품을 담당하는 100명이 있지만 내부에는 2명뿐일 수 있고, 그 2명의 비용이 라이선스보다 클 수도 있음
지금 운영 중인 내부 도구부터 점검하기
•내부 도구 목록을 만들고, 내일 취약점이 공개되면 누가 패치하고 어떻게 발견할지 확인해야 함
•담당자가 없는 도구는 외부 제품으로 교체하거나 책임질 사람을 지정해야 함
•아무도 장기 운영을 맡으려 하지 않는다면, 그 자체가 계속 유지할지를 판단할 근거임
•일회성 정리로 끝내지 않고 분기마다 책임자를 점검 해 담당자 이탈과 업무 변경으로 생기는 공백을 막아야 함
만드는 문턱은 낮아졌지만, 책임질 기준은 남음
•회사에 꼭 맞는 도구를 만드는 비용은 낮아졌지만 위험, 보안과 장기 운영 책임 까지 같은 비율로 줄어든 것은 아님
•자체 인증을 피해야 하는 이유도 원래부터 코드를 작성하는 데 걸리는 시간이 아니었음
•설득력 있는 데모와 부담스러운 청구서는 과도한 자체 개발을 부추기지만, 합리적인 변화는 작고 영향이 제한적이며 교체할 경로가 있는 영역 에 있음
•사업의 차별화에 필요한 것은 만들고, 그저 안정적으로 작동해야 하는 것은 구매한다는 원칙은 유지됨
•지금 알고 있는 비용을 처음부터 알았더라도 해당 도구를 다시 만들고 운영하기로 했을지 점검하고, 다음 자체 개발 제안에도 같은 질문을 적용해야 함
•이미 있는 것을 다시 만들지 않는 원칙의 핵심은 만드는 수고보다 만든 뒤 떠안는 책임 에 있음