오픈소스를 도입할 때 라이선스 비용이 0원이라는 사실만 보면 예산표에서 빠지는 항목이 생긴다. 코드 자체는 무료여도 업데이트를 받아들이고, 장애를 처리하고, 사용자가 의지하는 기능을 바꿀 때 설명하는 일은 계속 남는다. 개발자 Glyph Lefkowitz는 2026년 9월 24일 글에서 오픈소스를 유지관리자가 사용자에게 일방적으로 주는 선물이 아니라, 서로 다른 가치를 주고받는 장기 관계로 봐야 한다고 썼다.
이 관점은 회사의 유지보수 예산을 어디에 놓을지 바꾼다. 특정 팀의 잡비로 묻어 두면 비용 절감 국면에서 가장 먼저 잘리기 쉽다. 반대로 채용, 제품 신뢰, 플랫폼 유지라는 효과와 연결하면 어떤 지출을 남겨야 하는지 판단할 수 있다.
오픈소스는 왜 공짜와 같은 말이 아닌가
유지관리자는 코드 공개로 평판을 얻고, 자신이 선호하는 기술 방향을 확산시키며, 외부의 버그 보고와 기여를 통해 도구를 함께 고친다. 기업도 채용 후보가 코드를 미리 보고 익히게 하거나, 고객 개발자에게 제품을 알리는 통로로 오픈소스를 쓸 수 있다. 사용자는 라이선스 비용 대신 검증된 도구와 공동 유지보수의 이득을 얻는다.
여기서 중요한 것은 코드가 아니라 관계의 지속성이다. 이 관계에는 이슈를 분류하고, 변경 사항을 알리고, 보안 업데이트를 보호하며, 사용자가 의존한 기능을 바꿀 때 영향을 다루는 일이 들어간다. 무료 다운로드만 계산하면 이런 업무가 보이지 않는다.
유지보수 인력을 어느 부서 비용으로 볼 것인가
원문은 오픈소스 유지보수를 임금이나 IT 비용으로만 묶는 회계가 왜곡을 만든다고 지적한다. 오픈소스 활동이 채용에 도움이 되면 채용비, 고객 개발자에게 제품을 알리면 마케팅비, 기업 전체가 쓰는 플랫폼을 안정시키면 공통 플랫폼 비용으로 효과를 나누어 봐야 한다는 주장이다.
이는 한 사람의 시간을 여러 부서에 억지로 청구하자는 뜻이 아니다. 예산을 승인하는 사람이 그 시간이 무엇을 지키는지 보게 하자는 뜻이다. 예를 들어 SDK의 릴리스 노트와 호환성 테스트는 개발자 홍보팀의 부수 업무가 아니라 고객 통합이 멈추지 않게 하는 제품 운영 비용일 수 있다. 공용 라이브러리의 보안 업데이트는 최초 도입팀만의 일이 아니라 그 라이브러리를 쓰는 모든 제품의 위험을 줄이는 비용이다.
기능 변경과 보안 업데이트가 같은 예산 문제인 이유
의존성을 추가하면 처음 내려받은 코드만 신뢰하는 것이 아니다. 이후 패키지 배포 권한을 가진 사람과 업데이트 과정도 함께 신뢰한다. 그래서 배포 자격증명을 보호하고, 보안 공지를 내고, 더 이상 유지하지 못할 때 종료 상태를 알리는 일은 사용자에게 제공하는 운영 품질이 된다.
기능 변경도 같다. 원문은 가상의 그림 프로그램이 특정 기능을 없앤 뒤 운영체제 업데이트와 충돌하는 사례를 든다. 사용자는 새 버전으로 옮기면 작업 방식을 잃고, 옛 버전에 남으면 보안 위험을 감수해야 한다. 공개된 코드가 있으니 포크하면 된다는 말은 개인이나 작은 팀의 이전 비용을 없애지 못한다.
따라서 도입팀은 패키지 가격 대신 세 가지를 예산 질문으로 바꾸는 편이 낫다. 누가 업데이트 권한을 관리하는가, 호환성이 깨질 때 어떤 버전까지 지원하는가, 유지보수가 멈추면 사용자에게 어떤 경로로 알리는가다. 이 질문의 답이 없으면 비용은 없어지는 대신 다음 장애나 강제 이전 때 한꺼번에 나타난다.
예산을 다시 볼 때 남겨야 할 것은 무엇인가
모든 오픈소스 프로젝트에 무제한 지원을 약속할 필요는 없다. 대신 조직이 무엇을 얻으려고 공개하고 사용하는지 먼저 적어 두면, 유지보수 범위도 정하기 쉬워진다. 채용과 평판이 목적이면 공개 활동과 응답 창구를, 공통 플랫폼 유지가 목적이면 보안 대응과 호환성 테스트를 예산 항목으로 남길 수 있다.
사용자와의 소통 창구도 운영 비용이다. 기술 이슈 트래커만으로는 비개발 사용자의 요구를 정리하기 어렵고, 불만이 여러 채널로 흩어지면 유지관리자의 대응 비용도 커진다. 작은 프로젝트에 별도 커뮤니티 운영자를 즉시 둘 수는 없더라도, 지원 범위와 종료 방식, 피드백 경로를 한곳에 정리하는 일은 다음 갈등과 이전 비용을 줄인다.
오픈소스 도입을 공유된 운영 기반에 참여하는 일로 보면 유지보수 예산의 위치가 선명해진다. 줄일 수 있는 비용과 나중에 더 크게 돌아올 비용을 같은 칸에 넣지 않는 것부터 시작하면 된다.