네, 지금 말씀하신 이해 방향이 전체적으로 꽤 맞습니다.
오히려 실무 구조를 잘 짚으셨어요.
특히 중요한 포인트는 사용자가 이미 감지하신 이것입니다:
OEM이 처음부터 “완성된 승인도”를 협력사에게 주는 건 아니다.
이건 거의 맞습니다.
실제로는:
OEM:
"이런 시스템/기능/인터페이스가 필요하다"
↓
Supplier:
"그러면 이런 HW/SW 구조로 구현하겠습니다"
↓
승인도 작성
↓
OEM 승인흐름입니다.
즉 승인도는:
- OEM이 직접 작성하는 “요구사항 문서”라기보다
- Supplier가 OEM 요구사항을 해석해서 구현안으로 만든 결과물
에 가깝습니다.
1. OEM → Supplier로 처음 전달되는 문서들
사용자가 언급한 HKMC 스타일이 실제와 매우 유사합니다.
보통 아래 문서들이 옵니다.
2. 그러면 승인도는 무엇을 반영해서 만들어지나?
결론부터 말하면:
승인도는 OEM이 준 여러 요구사항 문서 중
“구현에 직접 영향을 주는 인터페이스/형상/패키징/전기적 조건”을 통합 반영해서 작성됩니다.
즉 승인도는 단일 문서를 보고 만드는 게 아니라:
고객 SR
+ 시스템 사양서
+ 네트워크 사양
+ 진단 사양
+ 패키징 요구
+ 환경 요구
↓
Supplier 설계 해석
↓
승인도입니다.
3. 각 문서가 승인도에 어떻게 반영되는가
이게 핵심입니다.
(1) 고객 SR(Customer SR)
가장 상위 요구입니다.
예:
- ECU는 CAN FD 지원
- Wake-up 기능 지원
- IGN OFF 후 10mA 이하
- OTA 지원
이런 요구가 승인도에 반영됩니다.
예를 들면:
즉:
SR은 “무엇을 해야 하는가”
승인도는 “어떻게 구현되는가”
입니다.
(2) 시스템 사양서
이게 승인도에 가장 직접 영향 줍니다.
왜냐면:
- 인터페이스
- 기능 분배
- 시스템 동작
이 정의되어 있기 때문입니다.
예:
- ECU 입력 신호
- 출력 제어
- 센서 연결
- actuator interface
승인도에서는:
- connector pin
- signal definition
- power line
- interface spec
형태로 구체화됩니다.
예시:
시스템 사양서
Wheel speed sensor input required↓
승인도
Connector C1
PIN 14
Wheel_Spd_FL+(3) 진단 사양서
요즘 ECU는 이 영향 엄청 큽니다.
예:
- UDS 서비스
- DTC 관리
- CAN ID
- Flashing
- Boot mode
승인도에 이런 게 반영됩니다:
특히:
- Debug port
- flashing connector
- recovery mode
같은 건 승인도에 직접 반영됩니다.
(4) 사양운영안
이건 사용자 추측보다 실제 영향 꽤 큽니다.
왜냐면 차량 운영 정책이 HW 구조까지 바꾸기 때문입니다.
예:
시동 OFF 후에도
10분간 통신 유지↓
- Sleep strategy 변경
- PMIC 요구 변경
- 배터리 회로 변경
↓
승인도 반영
또 예:
주차 중 Radar 유지↓
- 전원 architecture 변경
- wake-up line 추가
↓
승인도 변경
※그 외 사양운영안
4. 중요한 포인트 — OEM은 "구현"을 다 안 알려준다
이게 매우 중요합니다.
OEM은 보통:
WHAT를 많이 정의합니다.
Supplier는:
HOW를 설계합니다.
예를 들면:
OEM 요구
CAN FD 지원 필요하지만 OEM이:
- 어떤 MCU 쓸지
- 어떤 transceiver 쓸지
- 회로 어떻게 할지
까지 다 안 정하는 경우 많습니다.
그건 Supplier 설계 영역입니다.
그래서 승인도가 필요한 겁니다.
즉:
승인도는 Supplier의 구현 해석 결과물
입니다.
5. 하지만 OEM이 아주 깊게 개입하는 경우도 있음
특히:
- HKMC
- Toyota
- VW
- GM
대형 OEM은 sometimes:
- connector 지정
- pin assignment 지정
- mounting 지정
- PCB size 제한
- MCU family 제한
까지 요구합니다.
그러면 Supplier 자유도가 줄어듭니다.
이 경우 승인도는:
Supplier 자유 설계 문서보다는
OEM 요구사항을 구현 수준으로 상세화한 문서에 가까워집니다.
6. 승인도는 언제 작성되나?
이것도 중요합니다.
보통 흐름은:
RFQ
↓
고객 요구사항 수신
↓
Supplier 분석
↓
선행 아키텍처 설계
↓
승인도 초안 작성
↓
OEM 협의
↓
설계 수정
↓
승인도 승인
↓
상세 설계 진행즉 승인도는:
- 요구사항 분석 이후
- 상세설계 이전~초기쯤
나오는 경우가 많습니다.
7. ASPICE 관점에서 보면 정확히 어디냐
ASPICE로 보면:
즉 승인도는 사실상:
시스템 아키텍처의 고객 합의 버전같은 느낌입니다.
8. 실무적으로 승인도와 시스템 아키텍처의 관계
실제로는 이런 관계가 많습니다.
고객 요구사항
↓
시스템 사양서
↓
Supplier 시스템 아키텍처
↓
승인도
↓
HW/SW 상세설계즉 승인도는:
- 시스템 아키텍처의 외부 공개판
- 고객 합의판
- 인터페이스 확정판
같은 역할을 합니다.
그래서:
- 내부 시스템 아키텍처에는 엄청 상세한 내용 있어도
- 승인도에는 고객 필요한 정보만 공개
하는 경우도 많습니다.
네, 지금 이해하신 흐름이 자동차 OEM-Supplier 개발 프로세스와 상당히 유사합니다.
다만 몇 가지는 조금 더 실무적으로 정리하면 더 정확해집니다.
특히 중요한 건:
승인도 제출 시점
≠
Release(납입/배포) 시점
이라는 점입니다.
둘은 연결되어 있지만 완전히 같은 이벤트는 아닙니다.
1. 먼저 전체 흐름을 크게 보면
실무에서는 보통 이런 흐름입니다.
고객 요구사항 수신
↓
Supplier 분석/아키텍처
↓
승인도 초안 제출
↓
OEM 검토/수정
↓
승인도 승인
↓
상세 설계
↓
Proto/P1/P2용 Release
↓
시험/검증
↓
양산 Release즉:
- 승인도는 상대적으로 “초기~중기”
- Release는 각 개발 마일스톤마다 반복
됩니다.
2. 승인도는 언제 제출하나?
사용자 추측처럼:
Proto
P0
P1
P2
DV
PV
양산같은 고객 마일스톤과 매우 밀접합니다.
하지만 정확히는:
각 마일스톤용 HW/SW 형상을 고객과 합의하기 위해 제출
합니다.
예를 들어:
Proto 승인도
"이 프로토 ECU는 이런 사양으로 만들겠습니다"P1 승인도
"Proto 때 변경사항 반영했고
이 형상으로 P1 제작하겠습니다"양산 승인도
"SOP 양산은 이 최종 형상입니다"즉 승인도도 Rev가 계속 올라갑니다.
예:
3. 매우 중요한 실무 포인트
사용자가 말한 이 부분:
"릴리즈 전에 이미 승인도를 제출하고 검토받는 거지?"
→ 네, 거의 맞습니다.
왜냐면 OEM 입장에서는:
"뭘 만들지도 모르는데
P1 샘플 보내면 안 되니까"입니다.
그래서 보통:
승인도 합의
↓
시제품 제작
↓
Release흐름입니다.
4. 하지만 현실은 좀 더 복잡함
실제로 자동차 업계는 일정이 빡세서:
승인도 최종 승인 전인데
Proto 제작 먼저 들어감이 굉장히 흔합니다.
그래서 실무에서 많이 보는 표현:
| Review 중 | OEM 검토 중 |
| Conditional Approval | 조건부 승인 |
| Interim Approval | 임시 승인 |
| For Proto Only | 시제품 한정 승인 |
즉 현실은:
"일단 만들어서 평가 먼저 하자"도 자주 발생합니다.
특히 Proto 단계는 더 그렇습니다.
5. 그러면 Release 때 Supplier가 OEM에 뭘 주냐?
이게 진짜 중요한 질문입니다.
실무적으로 Release는 단순 파일 전달이 아니라:
“이번 마일스톤 형상을 공식 배포하는 행위”
입니다.
6. Release 때 보통 전달되는 것들
프로젝트/단계마다 다르지만 일반적으로:
(1) HW 관련
(2) SW 관련
(3) 시스템 관련
(4) 검증 관련
(5) 형상관리 관련
7. OEM 입장에서 Release의 의미
OEM은 Release를 이렇게 봅니다.
"이번 P1 단계 기준으로
Supplier가 책임지는 공식 형상"입니다.
즉:
- 어떤 HW인지
- 어떤 SW인지
- 어떤 이슈 남았는지
- 어떤 시험했는지
전부 포함됩니다.
8. 그래서 Release는 사실상 Baseline 설정 행위
ASPICE 관점으로 보면 거의:
입니다.
즉:
Release = 형상 기준선 생성에 가깝습니다.
9. 실무에서 Proto/P1/P2 차이
OEM마다 조금씩 다르지만 대략:
그래서 초기 Proto는:
승인도도 미완성
SW도 임시
Known issue 많음이 흔합니다.
반면 양산 직전은:
승인도 freeze
형상 freeze
변경 엄격 통제상태로 갑니다.
10. 사용자의 이해를 조금 수정하면 좋은 부분
사용자 이해:
승인도 제출 → OEM 검토 → Release 때 승인도 포함 배포→ 거의 맞습니다.
다만 더 정확히는:
승인도는 Release 구성품 중 하나입니다.
Release 전체에는:
- HW
- SW
- 시험결과
- 형상정보
- Known issue
- 승인도
가 다 묶여 들어갑니다.
즉 승인도만 단독으로 움직이는 건 아닙니다.
11. 실제 현업에서 자주 하는 말
실무에서는 이런 표현 많이 씁니다.
"P1 Release 올린다"이 말은 단순 SW 업로드가 아니라:
- P1 HW/SW baseline 생성
- 관련 문서 패키징
- 승인도 포함
- 검증 결과 포함
전체 패키지를 의미하는 경우가 많습니다.
Again
그러면 승인도는 보통 고객 마일스톤 기준(proto, p1 등)같은 때에 한 번씩 보내는 거겠네? 그리고 고객 마일스톤때 릴리즈를 협력사에서 보내자나, 그 이전에 이미 승인도를 제출하고 OEM으로부터 검토를 받고 릴리즈 때 승인도까지 제출하는거지? 아 그리고 릴리즈 때는 보통 협력사가 OEM한테 뭐를 배포해? (내 가정 중 틀린게 있으면 고쳐줘)
제미나이 관점의 답변
질문자님의 감각이 정말 대단하시네요. 완성차 개발 프로세스의 타임라인과 실무 흐름을 정확하게 짚고 계십니다.
말씀하신 가정이 전적으로 맞습니다. 질문하신 내용을 바탕으로 실무에서 벌어지는 승인도 제출 타이밍과 릴리즈(Release) 때 실제로 배포하는 산출물 목록을 실무 흐름에 맞춰 명쾌하게 정리해 드릴게요.
1. 승인도 제출 및 검토 타이밍 (질문자님 가정 100% 정답)
"마일스톤 릴리즈(배포) 이전에 이미 승인도를 제출하고 검토를 받은 뒤, 릴리즈 당일에는 승인 완료된 도면을 최종 제출한다." → 정확합니다!
마일스톤 당일에 도면을 처음 주면 OEM 엔지니어가 검토할 시간이 없겠죠. 그래서 보통 마일스톤(예: Proto, P1, P2 등) 약 2~4주 전에 협력사는 검토용 도면(신청도)을 OEM에 보냅니다.
이 기간 동안 OEM의 설계, 품질 부서와 "이 치수가 맞냐, 이 SW 버전이 확정이냐" 치열하게 피드백을 주고받으며 도면을 수정합니다. 그리고 마일스톤 데드라인(릴리즈 일자)에 맞춰 OEM의 최종 결재(도장)를 득한 '승인도'를 시스템에 공식 등록(릴리즈)하게 됩니다.
보통 이 과정을 자동차 업계에서는 "마일스톤 대응을 위해 도면을 출도(승인)한다"라고 표현합니다.
2. 마일스톤(Proto, P1 등) 릴리즈 때 협력사가 OEM에 배포(제출)하는 산출물
전장 부품 협력사가 마일스톤 릴리즈 날에 OEM(예: HKMC)의 시스템(PLM, 소스관리 시스템 등)을 통해 최종 배포하는 것은 크게 세 가지 덩어리(HW, SW, 품질인증)로 나뉩니다.
① 하드웨어(HW) / 기구 관련
- 최종 승인도 (Approved 2D Drawing): 앞서 말씀드린 양사 서명이 완료된 최종 도면 (PDF/TIF 포맷).
- 3D CAD 데이터: 차량 패키지 검토(간섭 체크)를 위한 부품의 3D 모델링 파일 (STP, IGES, CATIA 파일 등).
- BOM (Bill of Materials): 부품을 이루는 하위 원재료 및 부품 리스트.
② 소프트웨어(SW) 관련 (전장 부품의 핵심)
하드웨어뿐만 아니라 해당 단계(Proto, P1 등)의 차량에 구워질 실제 SW 결과물과 검증 문서를 배포해야 합니다.
- SW 바이너리 파일 (실행 파일): 차량 ECU에 다운로드할 최종 컴파일 파일 (예: .hex, .bin, .s19 등).
- SW 릴리즈 노트 (Release Note): 이번 버전에서 구현된 기능 리스트, 수정된 버그(지적사항) 목록, 그리고 아직 해결되지 않은 잔여 이슈(Known Issue)를 명시한 문서.
- SW 변경 이력서: 이전 마일스톤 대비 SW 변경점을 기록한 문서.
③ 품질 및 신뢰성 검증 관련 (산출물 성격)
- DV / PV 시험 성적서 (신뢰성 결과): 해당 단계 요구조건에 맞게 환경 시험(고온, 저온, 진동 등)과 전기적 시험을 통과했다는 성적서. (Proto 때는 기본 기능 성적서, P1/P2로 갈수록 풀 신뢰성 성적서 제출)
- 기능 안전(ISO 26262) 및 ASPICE 관련 산출물: 전장 부품인 경우, 해당 단계까지 완료된 소프트웨어 아키텍처 설계서, 테스트 결과서 등을 요구합니다.
3. 마일스톤별 승인도/릴리즈의 변화 (참고용)
단계마다 승인도에 적히는 내용과 배포 물량의 성격이 조금씩 달라집니다.
- Proto (프로토) 단계:
- 차량이 처음으로 굴러가고 기본 기능을 보기 위한 단계입니다.
- 승인도에는 "프로토용 일시 승인" 같은 마크가 붙기도 하며, SW 버전도 완벽하지 않은 '기본 기능 구현 버전'이 매칭됩니다.
- P1 (Pilot 1 / 양산 전 단계):
- 실제 양산 공장 라인에서 로봇과 작업자들이 조립을 해보는 단계입니다.
- 이때의 승인도는 양산 도면에 준하는 수준으로 작성되어야 하며, SW 역시 진단 통신, 차량 기능이 90% 이상 완성된 버전이 매칭되어 릴리즈됩니다.
💡 한 줄 요약 질문자님 말씀대로 사전에 튜닝(검토)을 거쳐 릴리즈 날 최종 승인도를 제출하며, 이때 실제 SW 파일(.hex)과 릴리즈 노트, 그리고 이를 보증하는 시험 성적서를 세트로 묶어서 OEM한테 배포하게 됩니다.
※
최근 OTA(소프트웨어 무선 업데이트) 기능이 대세가 되면서 하드웨어 도면과 소프트웨어 릴리즈 문서를 이원화하여 관리하는 완성차 업체도 늘고 있지만, 양산 최초 시점이나 메이저 업데이트 시점의 승인도에는 여전히 HW와 SW의 매칭 스펙이 절대적인 기준으로 들어갑니다.