안녕하세요, 오픈소스SW 라이선스 관리자입니다. 문의주신 내용 답변드립니다. 점검 범위 기준을 일반적인 내용으로 답변드립니다. 일반적으로 라이선스 점검 범위는 구현부(프로젝트)냐 OS 설치 SW냐가 아니라, 최종 산출물에 포함되어 고객(외부)에게 배포되는지 여부를 기준으로 정하는 경우가 많습니다. 1. 점검 범위 기준: 구현부만 점검하고 OS에 설치된 SW(PostgreSQL 등)를 제외하는 것은, 그 SW가 실제로 고객에게 전달되는 산출물에 포함되는지에 따라 리스크가 달라집니다. - 자사가 직접 운영하는 서비스의 백엔드 인프라로만 사용(예: SaaS 형태로 자사 서버에서만 구동, 고객에게 바이너리·설치 파일·이미지가 전달되지 않음)한다면, 이는 '배포'에 해당하지 않아 라이선스 의무 자체가 발생하지 않으므로 현재처럼 라이선스 점검을 생략하셔도 무방합니다. - 그러나 On-premise 납품, 어플라이언스(서버+SW 묶음) 판매, VM/Docker 이미지 배포, 설치 패키지 제공 등 고객에게 산출물이 전달되는 구조라면, 그 안에 포함된 PostgreSQL 등 OS 설치 SW도 배포 대상에 포함되므로 구현부와 동일하게 라이선스 점검이 필요합니다. 2. 보안 취약점 점검: 라이선스 의무 발생 여부와 무관하게 실제 운영 환경의 보안 리스크(네트워크를 이용한 공격 등)가 있을 수 있으므로, 배포 여부와 상관없이 OS 설치 SW까지 점검하시는 현재 방식이 보안 리스크 예방에 도움이 될 것입니다. 3. 설치형 AI 모델: 위 기준과 동일합니다. 모델이 산출물에 포함되어 배포된다면 라이선스(예: Llama, 기타 모델 라이선스의 재배포·고지 조건) 점검이 반드시 필요하며, 잘 하고 계신 부분입니다. 정리해서 말씀드리면, 현재 점검 범위의 판단 기준 자체는 방향이 맞으나, 오픈소스 라이선스 점검의 경우 정확히 외부 배포 여부를 기준으로 정책화하시길 권장드립니다. 고객에게 전달되는 범위만 라이선스 점검 대상으로 선별하는 방식이 실무적으로 효율적입니다. (물론 내부 사정에 따라 특수한 상황이 있는 경우에는 점검 범위를 확장하셔도 됩니다.) 만약 서비스 형태가 On-premise/어플라이언스로 전환될 계획이 있다면, 그 시점부터는 PostgreSQL 등 OS 설치 SW도 점검 범위에 포함시키셔야 합니다. 보안취약점 점검의 경우, OS 레벨까지 시스템 전반적인 전체 구성요소를 식별한 뒤 정보 자산 중요도, 확인된 보안취약점의 위험성(Base Score), 공격 벡터(네트워크 공격 등) 등을 검토하고 분류하여 보안 취약점 조치에 대한 우선순위를 만들어 관리하시는 것을 권장드립니다. 감사합니다. ※ 법적 분쟁 발생시 본 답변은 법률적 해석이나 논리로 활용될 수 없습니다.