"우리가 직접 만들면 되지 않나요" - 사내 구축의 진짜 비용

레포 하나짜리 코드 분석 시제품은 주말 프로젝트로도 만들 수 있습니다. 그러나 프로덕션 수준의 SSOT는 모든 언어, 모든 레포, 모든 커밋을 계속 따라가야 하는 인프라입니다. 그 진짜 비용은 개발비가 아니라 최고 엔지니어들의 기회비용입니다.

기술력 있는 조직일수록 이렇게 묻습니다. "LLM 붙여서 우리가 만들면 되지 않나?" 맞습니다. 시제품은 됩니다. 저희도 그렇게 시작했으니까요. 문제는 시제품과 인프라 사이의 거리입니다.

시제품은 쉽고, 프로덕션은 다른 일이다

  • 언어. 레포 하나·언어 하나의 파서는 쉽습니다. 실제 회사에는 Java와 TypeScript와 Python과 10년 전 PHP가 섞여 있고, 언어마다 분석기를 따로 만들어야 합니다.
  • 연결. 코드는 깔끔한 트리가 아니라 순환이 섞인 그래프입니다. 레포와 레포는 임포트가 아니라 API 호출과 설정 문자열로 이어집니다. 이걸 놓치면 지도가 아니라 조각 모음이 됩니다.
  • 신선도. 만드는 것보다 유지가 어렵습니다. 매일 수십 커밋을 감지해 영향 범위만 다시 분석하는 파이프라인이 필요합니다. 이게 없으면 완성한 날부터 낡습니다.
  • 신뢰. 근거 연결, 모름 표시, 신뢰 등급. 이 정직성 장치가 없으면 "그럴듯한 사내 챗봇"이 하나 더 생길 뿐입니다.

진짜 비용은 기회비용이다

이걸 만들 수 있는 사람은 회사에서 시스템을 가장 깊이 아는 엔지니어들입니다. 그들이 내부 도구를 만드는 동안, 고객이 돈을 내는 제품은 누가 만들까요. 자체 구축의 청구서는 개발비가 아니라 최고 인력의 시간으로 날아옵니다. 그리고 그 도구는 만든 사람이 퇴사하는 순간 유지보수 불가능한 레거시가 됩니다. 레거시를 풀려고 만든 도구가 새 레거시가 되는 것이죠.

버전관리를 직접 만드는 회사는 없다

Git을 자체 개발하는 회사도, CI/CD를 처음부터 짜는 회사도 없습니다. 모든 팀이 결국 필요로 하는 것은 인프라고, 인프라는 사서 씁니다. 시스템 컨텍스트도 같은 길을 갑니다. 조직의 에너지는 인프라 재발명이 아니라, 그 위에서 무엇을 할지에 쓰는 게 맞습니다.

다음글 : 1~7일 만에 SSOT가 만들어지는 과정 - 처음 일주일의 기록