facts

AI 토큰 비용과 개발자 소수의 투입으로 소프트웨어의 초기 구현 문턱은 낮아졌으나, 보안 패치와 장애 대응 같은 운영 책임은 줄어들지 않았다. 자체 개발(Build)과 구매(Buy)를 결정하는 핵심 지표는 단순 구현 비용이 아닌 3~5년 단위의 총소유비용(TCO)이다.

의사결정 과정에서 검토해야 할 네 가지 기술적·사업적 축은 다음과 같다. 첫째는 장애나 침해 발생 시 시스템 전체에 미치는 '피해 범위'다. 둘째는 향후 수년간 패치와 새벽 2시 장애 대응을 수행할 '장기 운영 책임자'의 지정 여부다. 셋째는 해당 기능이 고객에게 제공하는 '사업 차별화' 수준이며, 마지막은 더 나은 외부 제품 출시 시 즉시 버릴 수 있는 '교체 경로'의 확보 여부다.

자체 개발이 합리적인 영역은 영향 범위가 제한적인 맞춤형 내부 도구, 시스템 간 연결을 위한 소규모 서비스, 외부 대안이 없어 임시로 구축하는 도구 등으로 좁혀진다. 반면 인증, 신원 관리, 결제, 고객 데이터 보관과 같은 핵심 기반 시설은 여전히 상용 제품 구매가 권장된다.

how-it-works

구현 비용의 착시가 운영 실패로 이어지는 메커니즘은 '주말 시제품'의 무분별한 투입에서 나타난다. AI의 도움으로 일주일 만에 구축한 인증 시스템의 경우, 초기 작동은 정상적이나 이후 발생하는 빈번한 보안 패치와 기업 고객의 보안 심사 대응 과정에서 막대한 엔지니어링 시간이 소모된다. 이는 라이선스 비용 절감액보다 더 큰 기회비용을 발생시키며, 결국 상용 서비스로 전환하게 만드는 원인이 된다.

반면, 공식 제품이 없는 상태에서 임시로 구축한 MCP(Model Context Protocol) 서버 사례는 '교체 경로'를 설정한 성공적인 자체 개발 모델이다. 공급업체가 공식 서버를 출시하자마자 즉시 전환함으로써, 무기한 유지보수와 보안 관리 책임을 외부로 이전했다. 두 사례의 차이는 코드의 품질이 아니라 피해 범위의 크기와 교체 가능성이라는 전략적 설계에 있다.

AI 에이전트의 도입은 인력 운영 방식에도 변화를 준다. 비핵심 역량 영역에서는 분야별 전문가를 늘리는 대신, 폭넓은 역량을 가진 소수 인력이 에이전트를 활용해 대응하는 구조로 전환된다. 다만 이는 역량의 구매 방식이 SaaS 계약에서 토큰 지출로 바뀐 것일 뿐, 결과물에 대한 책임과 운영 공백은 여전히 내부 인력이 메워야 하는 구조다.

implementation-impact

실무자가 자체 개발의 TCO를 산정할 때는 초기 개발비 외에 다음 항목을 반드시 포함해야 한다. 연간 유지보수 및 업그레이드 시간, 온콜(On-call) 장애 대응 인건비, SOC 2 등 규정 준수 증빙에 소요되는 시간, 담당자 이탈 시 인수인계 및 재작업 비용이다. 예를 들어 초기 개발 6주에 매년 유지보수 3주, 추가 지원 시간을 합산해 3~5년치 비용을 도출하고 이를 상용 라이선스 비용과 비교해야 한다.

현재 운영 중인 내부 도구의 리스크를 점검하려면 전체 목록을 작성한 뒤, 내일 당장 취약점이 공개되었을 때 누가 패치를 수행할지 담당자를 지정하는 '책임 공백 점검'을 분기별로 실시해야 한다. 담당자가 지정되지 않은 도구는 즉시 외부 제품으로 교체하거나 책임자를 명시하는 것이 운영 안정성을 확보하는 방법이다.

개발팀과 경영진이 자체 개발 제안을 검토할 때, 가장 구체적으로 확인해야 할 지점은 "3년 차에 누가 이 코드를 패치하는가"라는 질문에 대한 답변이다. 이 질문에 특정 개인의 이름이 아닌 팀 단위의 모호한 답변이 돌아온다면, 해당 프로젝트는 운영 책임이 설계되지 않은 상태이므로 승인을 보류하고 교체 경로를 먼저 설계해야 한다.