네, 자동차 개발 프로세스에서 말하는 **“승인도”**는 일반적으로 OEM과 협력사(Supplier) 사이에서 주고받는 “고객 승인용 도면(Approval Drawing)” 또는 “승인용 사양서”를 의미합니다.
실무에서는 꽤 중요한 문서이고, 단순 참고용 도면이 아니라 **“고객이 이 사양으로 개발/제작해도 된다고 공식 승인하는 기준 문서”**의 성격을 가집니다.
자동차 업계에서는 회사마다 조금씩 다르게 부르지만 보통 아래와 같은 표현들이 혼용됩니다.
- 승인도
- 고객 승인도
- Approval Drawing
- Customer Approved Drawing
- 승인 사양서
- Release Drawing
1. 승인도의 본질
핵심은 이겁니다.
“OEM이 Supplier에게 요구하는 제품의 기준 형상/사양/인터페이스를 공식적으로 합의한 문서”
즉,
- Supplier가 자기 마음대로 설계하는 게 아니라
- OEM이 요구하는 조건을 만족하는지 확인하고
- “이 기준으로 개발 진행해도 된다”고 승인하는 기준선(Baseline) 역할을 합니다.
2. 승인도에 들어가는 내용
대체로 아래 항목들이 포함됩니다.
(1) 제품 형상
- 치수
- 외형
- 장착 위치
- 커넥터 위치
- 홀 위치
- 패키징
예:
- ECU 외형
- 브라켓 위치
- 하우징 크기
(2) 인터페이스
- 전기 인터페이스
- CAN/LIN/FlexRay/Ethernet
- 핀맵
- 커넥터 규격
(3) 성능 요구
- 전압 범위
- 소비전류
- 응답시간
- 통신 속도
- 환경조건
(4) 규격/표준
- OEM 내부 규격
- ISO 규격
- EMC 조건
- 기능안전 조건
(5) 변경 이력
- Rev.
- 변경 내용
- 승인 날짜
- 승인자
1. 표제란 및 표식 정보 (Title Block & Sign-off)
도면의 신뢰성을 보장하는 가장 기본적인 관리 정보입니다.
- 부품 정보: 부품명, 부품 번호(Part Number), 적용 차종/프로젝트 코드
- 업체 정보: 서플라이어(부품사) 이름, 제조 공장 코드(DUNS 넘버 등)
- 최종 서명란 (Sign-off): 가장 중요합니다. 완성차 업체(OEM)의 담당 설계 엔지니어, 파트장, 팀장 등의 공식 승인 서명(또는 시스템 전자 결재 마크)과 승인 날짜가 반드시 찍혀 있어야 '승인도'로서 효력을 가집니다.
- 개정 이력 (Revision History): 도면이 몇 번째 수정되었는지(Rev.0, Rev.1 등), 무엇이 왜 바뀌었는지 기록하는 란입니다.
2. 형상 및 치수 (Geometry & Dimensions)
부품의 외관과 조립성을 결정하는 물리적 정보입니다.
- 3D/2D 투상도: 부품의 정면, 평면, 측면, 단면 및 필요시 ISO 뷰(입체도)
- 일반 치수 및 공차: 부품의 크기, 각도 등과 함께 허용되는 오차 범위($\pm0.1\text{mm}$ 등)
- 기하공차 (GD&T): 진직도, 평면도, 동축도, 위치도 등 차량 조립 시 다른 부품과 정확히 맞물리기 위한 기하학적 규격
- 특별 특성 (Special Characteristics): 안전, 법규, 차량 기능에 치명적인 영향을 주는 핵심 치수나 조립부에는 별도의 마크(예: 완성차 업체마다 다른 S, CC, SC 등의 기호)를 표시하여 특별 관리함을 명시합니다.
3. 기술 사양 및 주기 (Technical Notes & Specifications)
글로 기술되는 부품의 성능과 재질에 대한 엄격한 기준입니다.
- 재질 명기 (Material Spec): 사용된 플라스틱, 철강, 고무 등의 정확한 재질 규격 표준 번호(예: MS 사양, SAE, ISO 규격) 및 중량(Weight)
- 표면 처리 및 도장: 도금 두께, 도장 사양, 거칠기(Roughness), 부식 방지(방청) 기준
- 성능 사양 (Performance Spec): 부품이 버텨야 하는 내구 수명, 작동 온도 범위, 인장 강도, 체결 토크(Torque) 값 등
- 환경 규제 및 유해물질: IMDS(국제 환경 물질 시스템) 등록 여부나 RoHS 준수 여부 명시
4. 인터페이스 및 검사 기준 (Interface & Inspection)
완성차에 조립될 때와 품질 검사를 할 때의 기준입니다.
- 조립 및 간섭 조건: 차체나 주변 부품과 맞닿는 '기준점(Datum Point)'과 클립, 볼트 등의 체결 위치
- 검사 기준 정보: 품질 부서에서 부품을 검사할 때 어떤 부위를 집중적으로 측정해야 하는지(검사구/Gauge 적용 기준 등)에 대한 가이드라인
💡 쉽게 이해하기 위한 팁
승인도를 작성할 때는 **"이 도면 한 장만 제3자의 공장에 던져주어도, 우리가 원하는 품질의 부품을 똑같이 찍어낼 수 있는가?"**를 생각하면 됩니다. 서명(결재)을 통한 책임 소재 명확화, 정확한 크기(치수), 튼튼한 재료(재질), 버텨야 하는 힘(성능)이 모두 들어가 있어야 완벽한 승인도가 됩니다.
3. 승인도가 왜 중요하냐?
자동차 업계는 “말로 합의”하면 안 됩니다.
왜냐면:
- OEM
- Tier1
- Tier2
- HW
- SW
- 생산
- 시험
이 수많은 조직이 동시에 움직이기 때문입니다.
그래서 반드시:
“우리가 합의한 기준이 무엇인지”
를 문서로 고정해야 합니다.
그게 승인도입니다.
4. 승인도의 프로세스 흐름
실무적으로는 보통 이런 흐름입니다.
OEM 요구사항 전달
↓
Supplier 설계안 작성
↓
승인도 작성
↓
OEM 검토
↓
수정 요청
↓
재검토
↓
승인(Sign-off)
↓
개발/제작 진행즉 승인도는:
- 개발 착수 기준
- 양산 기준
- 변경관리 기준
- 책임 기준
이 됩니다.
5. 승인 후에는 어떻게 되나?
승인된 순간부터는 거의 “계약 수준”으로 취급됩니다.
그래서:
- 형상 변경
- 부품 변경
- 인터페이스 변경
- 성능 변경
같은 것이 생기면 반드시:
변경요청(ECR/ECO)
→ 영향분석
→ OEM 재승인절차를 타야 합니다.
즉 승인도는 사실상:
- 형상관리(Configuration Management)
- 변경관리(Change Management)
의 기준 베이스라인 역할도 합니다.
ASPICE에서도 이 개념과 연결됩니다.
6. ASPICE 관점에서 보면
승인도는 다음 프로세스들과 연관됩니다.
즉 승인도는 단순 도면이 아니라:
- 고객 합의 산출물
- 베이스라인 산출물
- 변경통제 대상
입니다.
7. 실무에서 자주 있는 상황
상황 1 — 고객 승인 전인데 개발 먼저 함
자동차 업계에서 매우 흔합니다.
"일단 개발 진행하세요"하지만 리스크 큽니다.
나중에 승인도 변경되면:
- HW 재설계
- SW 수정
- 시험 재수행
- 일정 지연
발생합니다.
그래서 실무에서는:
임시 승인
Conditional Approval같은 상태를 두기도 합니다.
상황 2 — 승인도와 실제 구현 불일치
이건 품질 이슈 됩니다.
예:
- 승인도는 CAN 500kbps
- 실제 구현은 1Mbps
→ 고객 클레임 가능
그래서 양산 전에:
- 승인도
- BOM
- 설계서
- 시험결과
정합성을 확인합니다.
8. 승인도와 요구사항 문서의 차이
많이 헷갈리는 부분입니다.
9. 자동차 업계에서 승인도가 특히 중요한 이유
자동차는:
- ECU 수십~수백 개
- Supplier 다수
- 인터페이스 복잡
- 양산 기간 길음
이라서 인터페이스 합의가 매우 중요합니다.
그래서 승인도가 사실상:
- “고객과 Supplier의 기술 계약서”
역할을 합니다.
특히:
- 커넥터
- 핀맵
- 패키징
- mounting
- network interface
같은 건 승인도 기준으로 움직이는 경우가 많습니다.
네, 실제 자동차 업계에서는 승인도에 SW 버전 정보가 포함되는 경우가 꽤 많습니다.
특히 요즘 ECU는 HW와 SW가 강하게 결합되어 있어서, 단순 기구/회로 승인만으로는 양산 정합성이 안 맞기 때문입니다.
다만 중요한 건:
“승인도에 SW 자체 전체를 상세히 적는다”기보다
“이 HW/기구 구성과 호환되는 SW 기준 버전”을 명시하는 개념
에 가깝습니다.
1. 왜 SW 버전이 필요하냐?
예를 들어 이런 상황 때문입니다.
즉:
- 핀 변경
- 회로 변경
- 센서 변경
- 메모리 변경
- PMIC 변경
- CAN transceiver 변경
같은 HW 변경이 생기면 SW도 영향받습니다.
그래서 OEM 입장에서는:
"이 HW에는 어떤 SW를 써야 하는가?"를 명확히 알아야 합니다.
2. 승인도에서 SW 버전이 표현되는 방식
실무적으로는 여러 형태가 있습니다.
(1) ECO/Revision Table에 명시
예:
※ 여기서 ECO란 OEM의 전장 시스템을 말함
(2) Note 영역에 기재
This hardware is validated with:
SW version : v3.2.5
Bootloader : v1.0.7
Calibration : CAL_24_05(3) 별도 호환성 매트릭스 참조
승인도에는 간단히:
Refer to HW/SW Compatibility Matrix라고 쓰고,
별도 문서에서:
관리하기도 합니다.
이게 요즘 더 일반적입니다.
3. 실제로 SW 버전이 매우 중요한 경우
특히 아래는 거의 반드시 관리합니다.
ECU 핀맵 변경
HW Rev B:
GPIO12 → GPIO15 변경→ SW 드라이버 수정 필요
Flash/EEPROM 변경
메모리 맵 바뀌면:
- Bootloader
- Linker
- Driver
영향받음
센서 변경
예:
- IMU vendor 변경
- Radar chip 변경
→ Driver/API 변경 필요
AUTOSAR Stack 변경
MCAL 버전 바뀌면:
- BSW
- RTE
- Application
정합성 영향
4. OEM이 특히 중요하게 보는 것
OEM 입장에서 중요한 건:
양산 ECU를 꽂았을 때
어떤 SW가 올라가야 정상 동작하는가입니다.
왜냐면:
- 서비스
- OTA
- 공장 flashing
- 리프로그램밍
- field issue 분석
전부 여기에 걸리기 때문입니다.
5. 그래서 실무에서는 결국 이렇게 감
실제 양산에서는 보통:
승인도
↓
BOM
↓
HW/SW Compatibility Matrix
↓
Release Note
↓
형상관리DB이렇게 연결됩니다.
즉 승인도 하나만 보는 게 아니라:
- HW 형상
- SW 형상
- Calibration
- Bootloader
- 생산 버전
전체를 Configuration Item처럼 관리합니다.
ASPICE의 SUP.8(형상관리) 관점이 여기랑 매우 연결됩니다.
6. 중요한 실무 포인트
실제로는 단순 “SW 버전”보다 아래가 더 중요합니다.
특히 차량은 Variant가 많아서:
같은 HW라도
차종/트림별 SW 다름이 굉장히 흔합니다.
7. 그래서 승인도에 어디까지 넣느냐?
회사마다 다릅니다.
OEM 스타일 1
승인도에는 HW 중심만 작성
- SW는 Release 문서로 분리
→ 독일 OEM 계열에서 많음
OEM 스타일 2
승인도에 호환 SW 최소 버전 포함
Compatible with SW v5.1 or laterOEM 스타일 3
아예 HW/SW 통합 형상으로 관리
예:
- ECU Part Number
- HW Rev
- SW Rev
- Calibration Rev
전부 묶어서 승인
ADAS/자율주행 쪽은 이런 경향 강합니다.
8. ASPICE/기능안전 관점에서는 사실상 필수에 가까움
특히 ISO 26262에서는:
- 어떤 HW에
- 어떤 SW가
- 어떤 안전 메커니즘으로
- 어떤 버전 조합으로
검증되었는지가 중요합니다.
그래서 안전 감사에서는 종종 이런 질문 나옵니다.
"HW Rev B가
어떤 SW와 검증되었는가?"이걸 추적 못하면:
- 형상관리 미흡
- Release 관리 미흡
- 검증 재현성 부족
으로 지적될 수 있습니다.
'ASPICE 기본 이론' 카테고리의 다른 글
| 변경요청관리 프로세스의 흔한 패턴 (feat 형상관리) (0) | 2026.05.29 |
|---|---|
| SYS.4와 SWE.6의 차이 (0) | 2026.05.29 |
| 실무적으로 변경요청은 어떻게 이루어지는가? (0) | 2026.05.19 |
| baseline 잘 활용하기 (0) | 2026.05.15 |
| SW, SYS 검증영역 병렬 진행 (0) | 2026.05.08 |