미국 OEM RFQ의 covered software provenance: 부품사가 증빙 trail을 나누는 법

핵심 결론

미국 OEM RFQ에 covered software provenance 문항이 들어오면 첫 답변은 “중국산 부품 없음”이 아닙니다. 납품 품목 안에 어떤 실행 소프트웨어가 있고, 누가 개발·공급했으며, IP와 라이선스 권리가 어떤 경로로 이동했는지를 먼저 분리해야 해요.

이 글의 범위는 VCS·ADS 해당 여부 자체를 넓게 판정하는 일반 설명이 아닙니다. 이미 미국향 OEM RFQ에서 covered software provenance 문항을 받은 한국 부품사가 답변서와 증빙 trail을 어떻게 나눌지에 초점을 둡니다.

BIS 커넥티드카 최종규칙은 관세 규정이 아니라 정보통신기술·서비스 공급망 통제 규정입니다. Federal Register 최종규칙과 eCFR 15 CFR Part 791은 중국·러시아와 관련된 특정 VCS hardware와 covered software 거래를 다룹니다.

한국 2·3차 부품사가 항상 직접 Declaration of Conformity를 제출하는 것은 아닙니다. 그러나 미국 OEM이나 1차 협력사가 선언서, 허가, 내부 적합성 검토를 준비하는 과정에서 하위 공급자에게 증빙을 요구할 수 있습니다.

지금 접수된 RFQ가 미국향 2027 모델연도 플랫폼 견적과 연결돼 있다면, 필요한 것은 법률 결론 한 줄보다 추적 가능한 자료 구조입니다. 구매팀 답변, 개발팀 자료, 법무 검토가 서로 다른 범위를 말하지 않게 만드는 일이 먼저예요.

2027 모델연도는 달력상 2027년 납품일과 같은 의미가 아닙니다. 규칙상 model year는 실제 생산 달력연도와 별도로 특정 차량 모델을 지정하는 연도 개념입니다. covered software가 들어간 완성 커넥티드 차량은 2027 모델연도가 기준선이 되고, VCS hardware는 2030 모델연도와 비모델연도 부품의 2029년 1월 1일 기준을 따로 봐야 합니다.

RFQ 문항을 네 갈래로 쪼개야 하는 이유

실무에서 마찰은 용어가 어긋나는 지점에서 시작됩니다. 부품사는 통신모듈, 제어기, firmware, ADAS 기능 일부라고 부르지만 고객사는 covered software, Declaration of Conformity, PRC/Russia nexus 같은 표현으로 묻는 경우가 많거든요.

같은 문항을 구매팀은 원산지 확인으로, 개발팀은 소프트웨어 아키텍처 문제로, 법무팀은 제재·수출통제성 진술 문제로 읽을 수 있습니다. 따라서 RFQ 답변서는 최소 네 갈래로 나누는 편이 안정적입니다.

갈래	RFQ에서 확인할 내용	바로 닫으면 위험한 표현
covered software provenance	application, middleware, system software 중 VCS 또는 ADS 기능을 직접 가능하게 하는 항목	제품 전체 해당 없음
IP·라이선스 경로	최초 개발 법인, 현재 권리 보유자, 라이선스 제공자, 이전·양도 시점	현재 판매 법인만 기재
firmware 업데이트 경로	hardware-specific firmware의 버전, 배포 방식, 서명·승인 주체, 업데이트 책임	firmware는 소프트웨어가 아니므로 제외
하위 공급자 증빙 trail	코드·모듈·통신부품 공급자, 외주 개발사, 유지보수 주체, 확인서 회수 범위	1차 공급자 확인 완료로 종료

이 구분은 책임 회피용 문구가 아닙니다. 고객사가 판단할 수 있는 범위와 공급자가 실제로 확인한 범위를 맞추는 작업입니다.

covered software provenance에서 먼저 볼 항목

15 CFR Part 791의 covered software는 VCS 또는 ADS 기능을 차량 수준에서 직접 가능하게 하는 품목의 주 처리장치에서 실행되는 application, middleware, system software를 중심으로 정의됩니다. 여기에는 foreign interest가 있는 소프트웨어라는 전제가 붙습니다.

RFQ 답변에서는 제품명보다 실행 위치와 기능을 먼저 써야 합니다. 예컨대 통신 ECU에 올라가는 코드라도 모두 같은 성격은 아니에요. VCS 기능을 직접 가능하게 하는 middleware인지, 특정 하드웨어 장치를 제어하는 firmware인지, 차량 외부 통신과 무관한 진단용 코드인지가 갈립니다.

문서 항목	증빙 내용	실무상 경계
소프트웨어 식별	소프트웨어 명칭, 버전, 적용 부품 번호, 적용 플랫폼 또는 모델연도	제품군 전체를 한 문장으로 묶지 않음
실행 위치	primary processing unit, ECU, TCU, module, SoC 등 실행 위치	하드웨어 명칭만으로 covered 여부를 단정하지 않음
기능 연결성	VCS 또는 ADS 기능을 직접 가능하게 하는지	ADAS 관련이라는 이유만으로 ADS covered software로 확정하지 않음
개발·공급 법인	설계, 개발, 제조, 공급을 담당한 법인	개발 장소와 계약상 개발 주체를 혼동하지 않음
proprietary addition trail	작성자, timestamp, component name, supplier name 등 추적 항목	고객사 또는 선언 주체가 요구하는 수준을 확인
중국·러시아 관련성	owned, controlled, jurisdiction, direction 기준에 따른 법인 관계	제조지만으로 관련성 없음을 단정하지 않음

개별 개발자의 국적만으로 covered software가 중국·러시아 관련 소프트웨어가 되는 구조는 아닙니다. 반대로 한국에서 납품하더라도 라이선스 제공자, 외주 개발 법인, 지배 관계가 중국·러시아 기준에 걸리면 별도 검토가 필요합니다.

IP·라이선스 경로는 원산지보다 늦게 드러난다

자동차 부품 RFQ에서는 BOM과 제조지가 먼저 오가고, 소프트웨어 권리 관계는 뒤늦게 확인되는 경우가 많습니다. BIS 규칙의 언어는 제조지보다 넓습니다. designed, developed, manufactured, supplied와 owned by, controlled by, subject to the jurisdiction or direction 기준을 함께 사용합니다.

제가 이런 RFQ 답변서를 검토한다면, “현재 판매 법인은 한국 법인”이라는 문장을 가장 먼저 의심할 겁니다. 그 문장은 틀리지 않을 수 있지만, 고객사가 묻는 코드의 설계·개발·공급 경로를 다 보여주지는 못하거든요.

확인 항목	RFQ 답변에 필요한 세부 내용
최초 개발 법인	소프트웨어를 최초 설계·개발한 법인명, 소재지, 계약상 역할
현재 권리 보유자	IP 소유자, 사용권자, 재라이선스 권한 보유자
이전·양도 이력	권리 이전일, 대상 코드 범위, 이전 전후 유지보수 주체
라이선스 조건	독점·비독점 여부, 수정권, 배포권, sublicensing 가능 여부
유지보수·업데이트 권한	누가 패치하고, 누가 승인하며, 어떤 서버 또는 toolchain을 쓰는지
관련 법인 관계	지분, 이사회, 계약상 지시권, special share, proxy voting 등 통제 가능성

특히 기존 중국·러시아계 벤더로부터 받은 코드가 국내 법인으로 이전됐거나, 현재는 한국 법인이 유지보수하지만 원권리자가 외국 법인인 경우에는 한 줄 진술로 처리하기 어렵습니다. 권리 이전 계약, 유지보수 권한, 패치 승인 주체를 분리해서 남겨야 합니다.

firmware는 제외가 아니라 별도 trail이다

규칙상 covered software 정의는 firmware를 별도로 제외합니다. 다만 이 문장을 firmware 문서화 면제로 읽으면 곤란합니다. VCS hardware 정의와 HBOM 관련 문서, 고객사 보안 질문서는 firmware 버전과 업데이트 경로를 계속 요구할 수 있습니다.

핵심은 firmware를 covered software라고 과도하게 확정하지 않는 동시에, 업데이트 가능한 코드로서의 trail은 남기는 것입니다. 특히 OTA, 서비스 툴, 생산라인 플래싱, field update가 섞여 있으면 변경 관리 기준이 달라집니다.

firmware 항목	남겨야 할 trail	고객사에 확인할 질문
출하 firmware	버전, hash 또는 build ID, 적용 하드웨어, 릴리스 일자	출하 버전만 제출하면 충분한가
업데이트 방식	OTA, 딜러 서비스, 공장 재작업, 수동 toolchain	납품 후 업데이트가 Declaration 또는 RFQ 갱신 대상인가
서명·승인	signing key 관리 주체, release approval owner	고객사는 signing authority까지 요구하는가
외부 dependency	chipset vendor package, modem stack, driver bundle	어느 하위 패키지까지 supplier trail을 요구하는가
기능 경계	하드웨어 제어 목적 코드인지, VCS/ADS 기능을 차량 수준에서 직접 가능하게 하는 코드인지	firmware 명칭만으로 제외 처리 가능한가

가장 피해야 할 답변은 “firmware라 covered software 아님”으로 끝내는 방식입니다. 더 실무적인 답변은 “해당 코드는 hardware-specific firmware로 분류했으며, 버전·업데이트·공급 법인 trail은 별도 문서로 유지한다”에 가깝습니다.

하위 공급자 증빙 trail은 어디까지 내려가나

미국 OEM이 모든 2·3차 부품사에 같은 깊이의 SBOM을 요구한다고 단정할 수는 없습니다. 다만 Declaration of Conformity 구조는 due diligence와 문서 유지, 요청 시 제공 가능성을 전제로 합니다. 최종규칙은 선언서가 VCS hardware와 covered software의 공급망 문서를 뒷받침해야 한다는 방향을 분명히 둡니다.

2·3차 부품사가 준비할 문서는 “전체 소스코드 공개”가 아니라 고객사가 규칙상 판단을 이어갈 수 있는 trail입니다. 기밀성이 있는 경우에는 OEM, 1차 협력사, 또는 요청 기관에 직접 제공하는 경로를 따로 설계해야 합니다.

공급망 단계	회수할 증빙	빠지기 쉬운 지점
직접 하위 공급자	법인명, 공급 품목, 계약 범위, 제조·개발 역할	제조 품목만 받고 소프트웨어 역할을 누락
소프트웨어 벤더	component name, version, supplier name, author 또는 maintainer trail	라이브러리와 proprietary modification 구분 누락
외주 개발사	계약상 개발 주체, 산출물 범위, 유지보수 의무	국내 외주라는 이유로 지배 관계 확인 생략
반도체·통신모듈 공급자	관련 hardware 해당 가능성, 관련 firmware, chipset package	passive component와 통신·제어 기능 부품을 같은 수준으로 처리
IP 제공자	라이선스 계약, 양도 계약, sublicensing 권한	현재 공급자와 원권리자 불일치
업데이트 운영자	OTA 서버, release manager, signing key owner	납품 후 변경 절차를 RFQ 답변에서 제외

소유·통제·관할·지시 기준은 공장 주소와 다릅니다. 본점, 설립지, 지분, 이사회, 계약상 지시권, 대리·대표 관계가 모두 질문이 될 수 있어요. 공급망 확인서는 원산지 확인서보다 넓은 법인 관계 표에 가깝게 설계해야 합니다.

고객사에 되물어볼 보류 질문

RFQ 마감이 가까울수록 해당 없음으로 닫고 싶은 유인이 커집니다. 그러나 이 규칙에서는 성급한 부정 진술이 나중에 더 큰 수정 비용을 만들 수 있습니다. 특히 IP 이전 코드, firmware 업데이트, 하위 라이브러리 변경은 납품 직전에 다시 확인하기 어렵습니다.

되물어볼 질문	질문의 목적
해당 RFQ가 미국향 2027 모델연도 covered software 검토에 직접 연결되는가	달력 납품일이 아니라 모델연도 기준을 맞추기 위해
고객사는 covered software 판단을 제품, 기능, 코드, proprietary addition 중 어느 수준으로 요구하는가	제품 단위 부정과 코드 일부 보류를 구분하기 위해
Declaration of Conformity, General Authorization, Specific Authorization, Advisory Opinion 중 어느 경로를 전제로 자료를 요청하는가	증빙 깊이와 책임 범위를 정하기 위해
firmware와 application software를 별도 목록으로 제출해야 하는가	covered software 제외와 firmware trail 유지를 분리하기 위해
하위 공급자는 몇 단계까지 확인해야 하는가	1차 확인서로 충분한지, 주요 코드·모듈 벤더까지 필요한지 정하기 위해
기밀 자료는 OEM을 거치지 않고 지정된 채널로 직접 제출할 수 있는가	CBI 또는 라이선스 제한이 있는 공급자 자료 처리 경로를 정하기 위해
변경 발생 시 기존 확인서의 갱신 기준은 무엇인가	firmware 변경, 라이브러리 교체, 라이선스 변경의 재확인 조건을 정하기 위해

이 질문은 답변 지연용이 아니라 범위 확정용입니다. “규제 대상 아님”보다 “당사 납품 범위에서 확인한 항목과 고객사 판단이 필요한 항목을 분리한다”는 구조가 분쟁 가능성을 줄입니다.

공식 규칙에서 확인할 경계

규칙 원문은 Federal Register 최종규칙과 eCFR 15 CFR Part 791을 우선 확인하는 편이 낫습니다. Federal Register 문서는 최종규칙의 배경과 규제 문안을 함께 보여주고, eCFR은 현재 조문화된 Part 791을 확인하는 경로입니다.

기술 범위는 BIS covered software·VCS hardware FAQ에서 보조적으로 확인할 수 있습니다. 이 FAQ는 covered software, legacy software, infotainment, firmware, TCU 같은 경계 질문을 다룹니다.

규칙 적용 구조와 절차는 BIS 커넥티드카 규칙 개요에서 함께 확인할 수 있습니다. Declaration of Conformity, General Authorization, Specific Authorization, Advisory Opinion은 같은 결론을 다른 이름으로 부르는 절차가 아닙니다. 거래가 금지되지 않는다는 선언, 일반 허가, 개별 허가, 사전 의견 요청은 각각 필요한 자료와 효과가 다릅니다.

RFQ 답변서의 실무형 마무리

미국 OEM RFQ 대응의 목적은 하위 부품사가 미국 규칙 전체를 대신 판정하는 것이 아닙니다. 납품 품목 안의 코드, 권리, firmware, 하위 공급자 관계를 고객사가 검토 가능한 형태로 제시하는 것입니다.

답변서의 마지막 문장은 네 부분으로 닫는 편이 안정적입니다.

문장 위치	넣을 내용
확인 범위	당사가 확인한 부품 번호, 소프트웨어 버전, 적용 플랫폼, 모델연도
확인 결과	개발·공급 법인, IP·라이선스 경로, firmware trail, 하위 공급자 확인 범위
보류 항목	고객사의 covered software 판단 기준, 선언서·허가 경로, 기밀 자료 제출 방식
변경 관리	firmware 업데이트, 하위 라이브러리 교체, 권리 이전, 공급자 변경 시 갱신 절차

모든 것을 원산지 문제 없음으로 묶으면 문서는 짧아집니다. 그러나 firmware 변경, 라이선스 갱신, 하위 공급자 교체가 생기는 순간 같은 답변서를 다시 열어야 합니다.

미국향 2027 모델연도 플랫폼 견적에 연결된 RFQ라면, 답변서의 결론보다 trail의 분리 방식이 더 오래 남습니다. 접수된 문항을 제품 전체의 해당·비해당으로 닫기 전에, 코드, 권리, 업데이트, 하위 공급자 네 갈래를 먼저 확인해보세요.