서비스 장애가 났을 때 담당자를 찾을 수 없는 라이브러리, 보안 이슈가 발생했는데 패치 일정도 검증 방법도 알 수 없는 기반 도구가 있다면 그 의존성은 이미 “무료”가 아닙니다. 비용이 청구서에 아직 나타나지 않았을 뿐, 개발팀의 대기 시간, 긴급 대응, 업그레이드 지연, 서비스 위험으로 비용을 내고 있을 가능성이 큽니다.
CTO와 개발 리드는 오픈소스를 도입할 때 라이선스 검토와 취약점 스캔에서 멈추기 쉽습니다. 두 절차는 필요하지만, 운영 단계의 더 큰 질문은 따로 있습니다. 우리 제품이 이 프로젝트에 계속 의존할 때, 유지보수 비용과 책임을 누구에게 어떤 방식으로 배분할 것인가입니다.
오픈소스 생태계에는 소수의 유지관리자가 널리 쓰이는 패키지를 맡는 경우가 적지 않습니다. 2024년 xz 백도어 사건도 기술 취약점만의 문제가 아니었습니다. 장기간 유지보수 부담을 진 개인에게 권한이 집중되고, 그 부담과 신뢰 관계가 공격 경로가 될 수 있음을 보여줬습니다. 기업의 대응은 “모든 오픈소스를 의심하자”가 아니라, 의존성마다 책임 모델을 다르게 설계하는 쪽에 가깝습니다.
먼저 분류할 것은 사용량이 아니라 사업 영향입니다
의존성 목록을 패키지 개수나 다운로드 수로 정렬하면 우선순위가 흐려집니다. 운영 책임을 정하려면 각 구성 요소가 멈추거나 위험해졌을 때 제품에 어떤 일이 생기는지부터 봐야 합니다.
다음 네 가지 질문으로 핵심 의존성을 가려낼 수 있습니다.
- 이 구성 요소가 없으면 로그인, 결제, 데이터 처리, 배포, 고객 제공 기능 중 무엇이 멈추는가?
- 보안 결함이나 호환성 문제가 생겼을 때 우리 팀이 우회하거나 패치할 수 있는가?
- 특정 유지관리자, 특정 클라우드 사업자, 특정 배포판에 과도하게 의존하는가?
- 대체 기술로 옮길 때 코드 변경뿐 아니라 데이터 이전, 운영 절차, 성능 검증까지 얼마나 필요한가?
여기서 중요한 것은 “가장 인기 있는 프로젝트인가”가 아닙니다. 제품의 인증 체인, 빌드 체인, 데이터베이스 드라이버, 암호화 라이브러리처럼 작은 구성 요소라도 장애 범위가 넓고 대체가 어렵다면 핵심 의존성입니다. 반대로 개발 편의용 도구라도 배포 파이프라인을 멈추게 한다면 운영상 핵심일 수 있습니다.
라이선스 의무와 운영 위험도 분리해서 기록해야 합니다. 라이선스는 배포, 고지, 소스 공개 같은 사용 조건을 다룹니다. 유지보수 책임은 보안 공지, 릴리스 지속성, 호환성 변화, 장애 시 대응 가능성을 다룹니다. 하나를 통과했다고 다른 하나가 해결되지는 않습니다.
네 가지 비용 배분 방식은 서로 대체재가 아닙니다
후원, 상용 계약, 내부 유지보수, 대체 기술은 하나만 고르는 메뉴가 아닙니다. 의존성의 성격에 따라 조합할 수 있습니다. 다만 각 방식이 해결하는 문제가 다릅니다.
| 방식 | 적합한 조건 | 기업이 얻는 것 | 기업이 계속 맡아야 할 일 |
|---|---|---|---|
| 후원·기부 | 널리 쓰지만 특정 기업 지원이 꼭 필요하지 않은 프로젝트 | 유지관리 지속성에 기여, 관계 형성 가능성 | 자체 패치·장애 대응 보장은 기대하지 않기 |
| 상용 지원 계약 | 장애 대응 시간, 보안 공지, 장기 지원 버전이 중요한 기반 기술 | 지원 창구, 지원 기간, 계약 범위 안의 책임 | 계약 제외 영역과 내부 운영 절차 관리 |
| 내부 유지보수 | 제품 차별화와 깊이 연결됐고 팀이 코드 이해·릴리스 역량을 가진 경우 | 패치 우선순위와 로드맵 통제력 | 인력 배치, 포크 관리, 업스트림 기여 |
| 대체 기술 전환 | 유지관리 공백이 길고 대체 비용보다 지속 위험이 큰 경우 | 단일 프로젝트·개인 의존도 감소 | 마이그레이션, 이중 운영, 재검증 |
후원은 가장 가벼운 선택이지만, 계약상 지원을 사는 방식은 아닙니다. 프로젝트를 사업적으로 널리 활용하면서도 직접적인 대응 창구가 필요하지 않은 경우에 적합합니다. 예를 들어 핵심이지만 표준화가 잘 되어 있고, 문제가 생겨도 내부에서 우회할 수 있는 구성 요소라면 후원과 자체 모니터링을 함께 둘 수 있습니다.
상용 계약은 “오픈소스가 불안하니 돈을 내자”는 판단보다 구체적이어야 합니다. 지원 시간, 보안 수정 제공 방식, 장기 지원 버전, 호환성 검증, 장애 시 책임 범위를 확인해야 합니다. 특히 제품 장애가 곧 고객 계약 위반이나 매출 손실로 이어지는 영역이라면, 유지관리자 개인의 자발적 대응보다 명시된 지원 조건이 더 중요할 수 있습니다.
내부 유지보수는 가장 많은 통제력을 주지만, 저장소를 포크하는 순간 끝나지 않습니다. 보안 수정 반영, 릴리스 자동화, 테스트 자산, 담당자 교체, 원 프로젝트와의 변경 차이까지 계속 관리해야 합니다. 팀이 해당 언어와 런타임, 배포 환경을 이해하지 못한다면 내부 포크는 독립성보다 고립을 만들 수 있습니다.
대체 기술은 유지관리 불안을 느낀 직후 실행할 카드가 아닙니다. 대체제가 더 활발해 보여도 라이선스, 호환성, 운영 인력, 생태계 성숙도에서 새 위험을 가져올 수 있습니다. 다만 유지관리자가 사실상 부재하고, 보안 공지나 릴리스가 장기간 끊겼으며, 내부에서도 복구하기 어려운 의존성이라면 전환을 검토할 이유가 충분합니다.
선택은 중요도와 통제 가능성을 함께 봐야 합니다
의사결정 회의에서는 다음처럼 나누면 논의가 빨라집니다.
영향이 크고 내부 통제가 낮은 의존성은 상용 지원, 유지관리 조직과의 직접 관계, 대체 경로 확보를 우선 검토합니다. 인증, 데이터 저장, 메시징, 운영체제 기반 구성 요소가 여기에 들어가기 쉽습니다. 계약을 맺더라도 특정 공급자만이 답인지, 공개된 표준과 데이터 이식성이 있는지도 같이 확인해야 합니다.
영향이 크고 내부 통제가 가능한 의존성은 내부 유지보수 역량을 공식 업무로 편성할 수 있습니다. 제품 기능과 밀접해 수정이 잦거나, 고객 환경 때문에 자체 패치가 필요한 경우가 대표적입니다. 이때 유지보수 업무를 개발 여유 시간에 맡기지 말고 담당자, 검토자, 릴리스 책임자를 정해야 합니다.
영향은 중간이지만 널리 쓰이는 의존성은 후원, 취약점 모니터링, 버전 고정 정책으로 관리할 수 있습니다. 지원 계약까지 필요하지 않을 수 있지만, 담당자가 한 명뿐이거나 릴리스 주기가 불명확하다면 위험 등급을 올려야 합니다.
영향이 낮고 대체가 쉬운 의존성은 과도한 계약보다 교체 가능성을 유지하는 편이 낫습니다. 추상화 계층을 지나치게 만들 필요는 없지만, 특정 API나 데이터 형식에 불필요하게 묶이지 않도록 신규 기능 설계에서 선택지를 남겨둘 수 있습니다.
위험 신호는 취약점 번호보다 먼저 나타날 때가 많습니다
오픈소스 프로젝트의 상태를 외부에서 완벽하게 판단할 수는 없습니다. 활동이 적다고 곧바로 위험한 것도 아닙니다. 기능이 안정돼 릴리스가 드문 프로젝트도 있기 때문입니다. 그러나 다음 신호가 겹치면 운영 계획을 다시 볼 시점입니다.
- 릴리스, 이슈 대응, 보안 공지가 특정 개인 한 명에게 집중돼 있다.
- 유지관리자가 지원 중단, 시간 부족, 후임 부재를 공개적으로 언급했다.
- 제품의 새 런타임·운영체제·클라우드 환경과 호환성 문제가 쌓이는데 해결 주체가 불명확하다.
- 패치를 적용하려면 내부에서 소스를 직접 수정해야 하지만, 그 변경을 검증하고 다음 버전에 반영할 절차가 없다.
- 대체 후보를 조사한 적이 없고, 데이터나 API가 특정 프로젝트의 구현에 깊게 묶여 있다.
이 신호는 해당 프로젝트를 비난할 근거가 아닙니다. 오히려 기업이 그 프로젝트의 자발적 노동 위에 어느 정도의 사업 위험을 올려놓았는지 점검하는 근거입니다.
구매팀과 개발팀이 함께 합의할 운영 항목
상용 계약이나 후원을 검토할 때 구매팀에 “오픈소스라서 비용이 필요하다”고만 설명하면 우선순위를 얻기 어렵습니다. 제품 운영과 연결된 요구사항으로 바꿔야 합니다.
개발팀은 핵심 의존성마다 최소한 다음을 남겨두는 편이 좋습니다. 서비스 영향도, 현재 버전과 업그레이드 경로, 보안 공지 수신 책임자, 장애 시 우회 방법, 내부 수정 가능 여부, 유지보수 방식, 재검토 시점입니다. 이 기록은 별도 거버넌스 문서가 아니라 아키텍처 결정 기록이나 서비스 운영 문서에 붙일 수 있습니다.
상용 지원을 평가한다면 공급자에게 지원 대상 버전, 보안 수정 제공 조건, 장애 접수와 응답 범위, 지원 종료 공지 방식, 포크 또는 자체 수정 상태에서의 지원 가능 여부를 확인해야 합니다. 후원을 결정한다면 그 예산이 기술 지원 구매가 아니라 생태계 유지에 대한 기여라는 점도 내부에 분명히 해야 합니다.
다음 분기 계획에서 할 일은 전체 오픈소스 목록을 다시 만드는 일이 아닙니다. 제품을 멈출 수 있는 의존성 몇 개를 먼저 고르고, 각각에 대해 “문제가 생긴 뒤 누가 어떤 권한으로 고칠 것인가”를 한 문장으로 정해보는 일입니다. 그 문장이 비어 있는 의존성부터 비용과 책임을 배분해야 합니다.
