미정

문제해결 프로세스에서 긴급해결 발생 조건

아즈마민초 — Fri, 29 May 2026 17:55:39 +0900

실무적으로 자동차 업계의 ASPICE 기반 문제해결관리 절차(PRM/SUP.9)에서 "긴급 해결(Emergency Resolution)" 조건은 보통 다음 수준으로 정의합니다.
중요한 것은:

"급하다"가 아니라
"정상적인 문제해결 절차를 수행하면 사업적/기술적 손실이 발생하는 경우"

를 긴급 해결로 정의하는 것입니다.

1. 가장 일반적인 긴급 해결 조건

① 고객(OEM) 양산 일정 영향

예)

고객 릴리즈 D-3
SOP 직전
PPAP 제출 직전
고객 마일스톤 직전

문제가 발생
예:

고객 제출 바이너리 오류

정상 절차

 
            문제 등록
영향분석
CCB
수정
전체 회귀시험 
           

수행하면

고객 일정 Miss

발생
→ 긴급 해결 가능

② 양산 차량 영향

예)

양산 차량 ECU Reset

양산 차량 CAN 통신 불가

안전 기능 비활성화

이 경우는 거의 대부분 긴급 해결 대상

③ Safety 영향 가능성

예)

ASIL 기능 동작 오류

Fail Safe 미동작

DTC 누락

ISO 26262 관련 문제
→ 대부분 긴급 처리

④ 고객 시험 중 Blocker Issue

예)
고객 검증 시험

SYS.5 수행 불가

기능 동작 불가

고객 시험 전체 중단 가능
→ 긴급 해결

⑤ 생산(Manufacturing) 영향

예)

공장 생산 중단

Programming 실패

EOL 시험 실패

양산 조직에서는 매우 중요

⑥ 서비스/필드 문제

예)

고객 클레임 다수 발생

Warranty 증가

리콜 가능성

이 경우도 긴급 처리

실무적으로 추가하면 좋은 것

긴급 해결 남용 방지
예)

 
            긴급 해결 적용 여부는
프로젝트 관리자 및 품질보증 담당자의 승인을 받아야 한다.

또는

 
            긴급 해결 적용 사유는 문제관리 시스템에 기록되어야 한다. 
           

""단순히 문제의 심각도가 높다고 긴급해결하는 것도 말이 안되는 거지?""

네. 오히려 실무적으로는:

"심각도(Severity)가 높다"와 "긴급성(Urgency)이 높다"는 다른 개념입니다.

이 둘을 구분하지 않으면 긴급해결 프로세스가 망가집니다.

1. 가장 흔한 오해

많은 사람들이:

중요한 문제 = 긴급 문제

라고 생각하는데,
실제로는:

 
            Severity (심각도)
≠
Urgency (긴급성) 
           

입니다.

2. 예를 들어보자

사례 1 : 심각도 높음 + 긴급성 낮음

예)

 
            ASIL-D 안전기능에서
특정 진단 커버리지 계산 오류 발견

심각도:

매우 높음

하지만

양산 전 6개월

남았음.
고객 제출도 없음.
차량에도 안 들어감.

이 경우:

Major 또는 Critical 문제

일 수는 있지만,

Emergency

는 아닐 가능성이 큼.
정상 문제해결 절차로 가도 됨.

3. 반대로

사례 2 : 심각도 중간 + 긴급성 높음

예)

고객 제출 D-1

릴리즈 패키지 생성 오류

Release Note PDF 깨짐

Safety 영향 없음.
기능 영향 없음.

하지만

내일 고객 제출

해야 함.

이 경우:

심각도는 중간

일 수 있지만,

긴급성은 매우 높음

입니다.
실제로는 긴급해결 절차 태울 수도 있음.

ASPICE 관점에서도

SUP.9에서 Emergency Process를 쓰는 이유는

문제가 크기 때문

이 아니라

정상 절차를 수행할 시간이 없기 때문

입니다.

즉

Critical

과

Emergency

는 다른 축.

실제 절차서에 잘 쓰는 방식

좋은 문제해결관리 절차는
긴급해결 조건을:
❌

심각도가 높을 경우

라고 안 씁니다.

대신
⭕ 이렇게 씁니다.

 
            - 고객 제출 일정 영향
- 양산 일정 영향
- 고객 시험 중단 위험
- Safety 영향으로 즉각 대응 필요
- 생산 중단 위험 
           

즉

시간 제약

을 기준으로 정의.

문제해결관리 프로세스에 CCB를??

아즈마민초 — Fri, 29 May 2026 17:52:17 +0900

ASPICE의 문제해결관리 프로세스 준수를 해야할 때 질문이 있는데, 동료검토에 의한 이슈 발견이나, 품질보증 담당자의 감사 활동에 의한 이슈 발견이나, 프로젝트 이슈가 발생해서 문제해결관리를 위해 등록하여 관리하는 업체가 있는데, 이 각 이슈가 발생할 때마다 CCB가 발생해야하는게 일반적이야 일반적이지 않아?

결론부터 말하면:

아닙니다.

문제해결관리(SUP.9)에 등록되는 모든 이슈마다 CCB를 여는 것은 일반적이지 않습니다.

오히려 그렇게 운영하면 프로젝트가 마비됩니다.

먼저 문제해결관리(SUP.9)와 변경요청관리(SUP.10)를 분리해야 함

예를 들어 QA가 감사 중 발견

SWE.3 상세설계서 Trace Link 누락

이건 문제(PB, Issue)입니다.
하지만

 
            설계 변경
코드 변경
릴리즈 변경 
           

은 아닙니다.

따라서:

 
            Issue 등록
↓
담당자 지정
↓
수정
↓
확인
↓
종결 
           

로 끝날 수 있습니다.
CCB 안 열어도 됨.

어떤 경우 CCB가 필요하냐

CCB는 본질적으로:

변경을 승인하는 조직

입니다.
즉:

 
            문제
↓
변경 필요
↓
CCB 
           

관계입니다.

문제 자체 때문에 열리는 게 아닙니다.

실제 업체들은 보통 어떻게 운영하냐

보통 이슈를 등급으로 나눔.

Level 1

Minor
예:

오타
링크 누락
리뷰 코멘트

처리

 
            담당자 수정
QA 확인
종결 
           

CCB 없음

Level 2

Major
예:

Requirement 수정
Design 수정

처리

 
            영향분석
PL 승인

필요시 CCB

Level 3

Critical
예:

고객 요구 변경
Safety 영향
릴리즈 영향

처리

거의 필수

문제해결 관리의 긴급 해결 프로세스 생략 가능 프로세스, 불가 프로세스

아즈마민초 — Fri, 29 May 2026 17:50:17 +0900

ASPICE의 문제해결관리 프로세스에서 긴급 해결 절차를 탈 때, 당장에 생략할 수 있는 프로세스와 생략할 수 없는 프로세스 같은게 있어?

ASPICE에서 흔히 오해하는 것이:

"긴급 변경(Emergency Change)이면 절차를 생략해도 된다"

가 아닙니다.

ASPICE SUP.9(Problem Resolution Management)와 SUP.10(Change Request Management) 관점에서 보면,

긴급 해결 절차는 "순서를 바꿀 수는 있어도, 핵심 통제 활동은 생략할 수 없다"

에 가깝습니다.

먼저 ASPICE가 진짜 싫어하는 것

예를 들어 양산 차량에서:

고객 차량 운행 중 ECU Reset 발생

문제가 발생했다고 가정해보겠습니다.

긴급 대응이라며:

 
                   코드 수정
↓
바이너리 배포
↓
끝 
                  

하면 ASPICE는 매우 싫어합니다.

왜냐하면:

왜 수정했는지 모름
누가 승인했는지 모름
영향 분석 안 함
추적 안 됨

상태가 되기 때문입니다.

긴급 해결 시 일반적으로 생략 가능한 것

실무적으로는 아래와 같은 것들은 일시적으로 후행 처리하는 경우가 많습니다.

1. 상세 원인 분석(Root Cause Analysis)

정상 프로세스

 
                   문제 발견
↓
원인 분석
↓
수정 
                  

긴급 프로세스

 
                   문제 발견
↓
임시 수정
↓
고객 대응
↓
사후 Root Cause Analysis 
                  

가능

예)

 
                   Reset 발생
↓
Watchdog 관련 임시 보호코드 삽입
↓
차량 배포
↓
사후 Root Cause 분석 
                  

2. 완전한 영향 분석

정상 프로세스

 
                   Req
Design
Code
Test
Safety
형상 
                  

전부 분석

긴급 상황

우선 영향 최소 범위만 확인

후

사후 정식 영향 분석 수행

가능

3. 정식 리뷰

정상

 
                   Peer Review
Leader Review
Approval 
                  

긴급

 
                   구두 승인
메일 승인

후

사후 정식 Review

가능

긴급 상황에서도 생략하면 안 되는 것

이건 중요합니다.

1. 문제 등록

생략 불가

예)

 
                   Problem Report
Issue Ticket
Redmine
JIRA 
                  

등록

왜?

나중에:

왜 수정했는가?

추적해야 함.

2. 변경 이력

생략 불가

예)

 
                   Emergency Fix
CR-123

기록

왜?

Source-Binary 추적 필요.

3. 최소 승인

생략 불가

ASPICE 입장

누군가는 승인해야 함

긴급이라도:

 
                   PM
품질책임자
기술책임자 
                  

중 누군가 승인.

4. 형상관리

절대 생략 불가

예)

Emergency Release V1.2.1

형상 등록

이걸 안 하면:

어떤 코드가 고객에게 나갔는지 모름

상태.

5. 검증

절대 생략 불가

범위는 줄일 수 있음.

예)

정상

Full Regression

긴급

 
                   Impact Area Test
Smoke Test

하지만

무검증 배포

는 ASPICE에서 매우 위험.

자동차 업계에서 흔한 Emergency Process

실제로는:

 
            문제 발견
↓
긴급 문제 등록
↓
긴급 영향 분석(최소)
↓
긴급 승인
↓
수정
↓
필수 검증
↓
고객 배포
↓
사후 Root Cause Analysis
↓
사후 정식 영향 분석
↓
사후 문서 보완 
           

형태가 많습니다.

변경요청관리 프로세스의 흔한 패턴 (feat 형상관리)

아즈마민초 — Fri, 29 May 2026 17:24:33 +0900

형상관리와의 관계

실제로 SUP.8과 SUP.10은 거의 붙어 다닙니다.
왜냐하면:

 
            Baseline
↓
변경 필요
↓
CR
↓
영향분석
↓
승인
↓
새 Baseline 
           

이 흐름이기 때문.

그래서 실무에서는

 
            SUP.8이 없으면
SUP.10도 의미가 약해짐

OEM이 진짜 중요하게 보는 시점

OEM 입장에서 중요한 건

승인된 산출물

입니다.
즉

 
            Customer Released Requirement
Approved Design
Released Software 
           

등.

이 시점 이후 변경은
거의 반드시

 
            CR
영향분석
승인 
           

을 기대합니다.

현실적인 결론

실무적으로 자동차 프로젝트에서는:

Draft 상태의 산출물은 일반 수정 절차로 관리하고,
Baseline 또는 승인된 형상항목이 된 이후의 변경부터는 SUP.10 변경요청관리 프로세스를 적용하는 경우가 가장 일반적입니다.

다만,

고객 변경요청(OEM CR), 법규 변경, 안전 요구사항 변경 등은 Baseline 여부와 관계없이 Change Request로 관리하는 경우가 많습니다.

그래서 심사관이 "변경요청관리 프로세스는 언제부터 적용합니까?"라고 물으면,

 
            승인 및 Baseline된 형상항목에 대한 변경부터 적용하며,
고객 변경요청은 Baseline 여부와 관계없이 관리합니다.

라고 답하면 가장 실무적이고 ASPICE적으로도 자연스러운 답변에 가깝습니다.

SYS.4와 SWE.6의 차이

아즈마민초 — Fri, 29 May 2026 12:00:17 +0900

SWE.6

보는 것

 
            Software
+
MCU 
           

수준

SYS.4

보는 것

 
            Sensor
↓
ECU
↓
Actuator 
           

전체

ECU PIN과 MCU Pin정보 (feat. 시스템 요구사항 명세서)

아즈마민초 — Wed, 20 May 2026 15:56:08 +0900

지금 Supplier의 시스템 요구사항 명세서에서 System External interface 부분을 보고 있는데 여기서 커넥터 PIN을 작성했어

여기서 커넥터 PIN이 뭐야

Supplier의 시스템 요구사항 명세서(SRS) 중 System External Interface(시스템 외부 인터페이스) 섹션에 커넥터 PIN을 작성한 것은 매우 자연스럽고 올바른 접근입니다. 이 부분은 우리 제어기(ECU)가 차량 내부의 다른 제어기, 센서, 전원(배터리)과 물리적·전기적으로 어떻게 연결되는지 명확히 정의하는 곳이기 때문입니다.

명세서의 해당 항목을 검토하시거나 작성하실 때, 반드시 확인해야 할 핵심 체크리스트를 정리해 드립니다.

External Interface의 PIN 작성 필수 항목

핀 맵 (Pinout Layout)
- 커넥터 내부의 핀 번호(예: Pin 1, Pin 2...)와 각 핀의 명칭(Pin Name) 매핑
핀의 기능 (Function)
- 해당 핀이 무엇을 하는지 정의 (예: Power, Ground, CAN_H, CAN_L, LIN, Analog Input 등)
전기적 특성 (Electrical Characteristics)
- 동작 전압 범위: 예) Min 9V ~ Max 16V (Nominal 12V)
- 허용 전류 (Current Rating): 연속 전류 및 피크 전류 제한 값
회로 보호 사양 (Protection)
- Short to Battery(배터리 단락), Short to Ground(그라운드 단락) 보호 여부
- ESD(정전기) 보호 소자 적용 여부

검토 시 유의할 점 (Tip)

PMIC와의 연계: 앞서 질문하신 PMIC로 들어가는 메인 전원 핀(VBAT)과 그라운드 핀(GND)이 전류 용량에 맞게 충분히 할당되었는지 확인하세요. (전류가 높으면 핀을 2~3개 묶어서 쓰기도 합니다.)
통신선 트위스트: CAN이나 Ethernet 통신 핀의 경우, 노이즈를 막기 위해 커넥터 내에서 서로 이웃하게 배치되어 있는지 확인하는 것이 좋습니다.

명세서의 해당 항목을 검토하시거나 작성하실 때, 반드시 확인해야 할 핵심 체크리스트를 정리해 드립니다.

External Interface의 PIN 작성 필수 항목

핀 맵 (Pinout Layout)
- 커넥터 내부의 핀 번호(예: Pin 1, Pin 2...)와 각 핀의 명칭(Pin Name) 매핑
핀의 기능 (Function)
- 해당 핀이 무엇을 하는지 정의 (예: Power, Ground, CAN_H, CAN_L, LIN, Analog Input 등)
전기적 특성 (Electrical Characteristics)
- 동작 전압 범위: 예) Min 9V ~ Max 16V (Nominal 12V)
- 허용 전류 (Current Rating): 연속 전류 및 피크 전류 제한 값
회로 보호 사양 (Protection)
- Short to Battery(배터리 단락), Short to Ground(그라운드 단락) 보호 여부
- ESD(정전기) 보호 소자 적용 여부

검토 시 유의할 점 (Tip)

PMIC와의 연계: 앞서 질문하신 PMIC로 들어가는 메인 전원 핀(VBAT)과 그라운드 핀(GND)이 전류 용량에 맞게 충분히 할당되었는지 확인하세요. (전류가 높으면 핀을 2~3개 묶어서 쓰기도 합니다.)
통신선 트위스트: CAN이나 Ethernet 통신 핀의 경우, 노이즈를 막기 위해 커넥터 내에서 서로 이웃하게 배치되어 있는지 확인하는 것이 좋습니다.

그러면 혹시 MCU의 Pin정보와 ECU의 커넥터 PIN은 다른거야?

네, 완전히 다릅니다. 두 장치는 스케일과 위치가 완전히 다르며, 'ECU 커넥터 핀'이 'MCU 핀'보다 훨씬 크고 튼튼한 외부 연결 창구라고 이해하시면 됩니다.

두 핀의 차이점을 명확하게 비교해 드리겠습니다.

1. MCU Pin (칩 내부의 미세한 다리)

위치: ECU 보드(PCB) 내부의 중심에 있는 메인 컴퓨터 칩(MCU) 자체에 붙어 있는 미세한 다리입니다.
크기: 밀리미터(mm) 단위 이하로 매우 작고 미세합니다.
전압/전류: 보통 3.3V 또는 5V의 아주 낮은 전압과 수 밀리암페어(mA) 수준의 미세한 전류만 다룹니다. (사람이 손으로 만지면 정전기로도 고장 납니다.)
역할: 칩 내부의 연산 장치와 보드(PCB) 위 주변 소자들 간의 신호 전달용입니다.

2. ECU 커넥터 PIN (제어기 외부의 튼튼한 접점)

위치: ECU 케이스 외부로 노출되어 있는 플라스틱 커넥터 뭉치 속의 금속 단자입니다.
크기: 센티미터(cm) 단위 커넥터 내부에 들어가는 수 밀리미터 두께의 단단한 금속 핀입니다.
전압/전류: 차량 배터리 전원(12V, 24V 또는 고전압 전기차의 경우 수백 V)과 암페어(A) 단위의 높은 전류를 견뎌야 합니다. 진동이나 습기 같은 가혹한 차량 환경을 직접 버텨내는 핀입니다.
역할: 외부 와이어링 하네스(전선)를 통해 다른 제어기, 센서, 액추에이터와 연결됩니다.

두 핀은 어떻게 연결되나요? (관계성)

차량 외부의 신호가 MCU까지 전달되는 과정은 다음과 같습니다.

외부 센서 신호가 [ECU 커넥터 PIN]으로 들어옴
ECU 보드 내의 회로(보호 소자, 필터 등)를 거침 (여기서 전압이 낮아짐)
최종적으로 안전하게 가공된 신호가 [MCU Pin]으로 들어감

따라서 Supplier가 작성한 System External Interface 명세서에 들어갈 핀은 당연히 'ECU 커넥터 PIN'이어야 합니다. MCU 핀은 Supplier 내부의 회로 설계(Hardware Design) 문서에 들어가는 내용입니다.

고객 요구사양서, 승인도 파헤치기2 (feat. Release)

아즈마민초 — Wed, 20 May 2026 12:01:43 +0900

좋아 이제는 각 산출물의 시기에 대해서 궁금한데, 내가 알기로 승인도는 협력사에서 작성하지만 그 승인도는 고객이 준 요구사항으로부터 나온 것을 반영하는 거잖아? 그러면 내가 보기엔 OEM은 인터페이스 구현까지 반영된 승인도 형태의 고객 요구사양서를 협력사한테 줬을 일을 없을 테고, OEM중에 HKMC같은 경우는 고객 요구사양서 문서로 '고객 SR', '시스템 사양서', '진단 사양서', '사양운영안' 등을 주는 거로 알고 있거든? 이 때 협력사는 승인도를 작성할 떄 고객이 준 요구사양서 문서 중에 어떤 산출물의 어떤 내용을 반영하는 거야? (물론 여기까지 내가 한 내용이 추측으로 말한 거기 때문에 내 가정 자체가 틀렸다면 그것까지 너가 고려해서 고쳐서 말해줘도 돼)

네, 지금 말씀하신 이해 방향이 전체적으로 꽤 맞습니다.
오히려 실무 구조를 잘 짚으셨어요.

특히 중요한 포인트는 사용자가 이미 감지하신 이것입니다:

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 상세설계

즉 승인도는:

시스템 아키텍처의 외부 공개판
고객 합의판
인터페이스 확정판

같은 역할을 합니다.

그래서:

내부 시스템 아키텍처에는 엄청 상세한 내용 있어도
승인도에는 고객 필요한 정보만 공개

하는 경우도 많습니다.

그러면 승인도는 보통 고객 마일스톤 기준(proto, p1 등)같은 때에 한 번씩 보내는 거겠네? 그리고 고객 마일스톤때 릴리즈를 협력사에서 보내자나, 그 이전에 이미 승인도를 제출하고 OEM으로부터 검토를 받고 릴리즈 때 승인도까지 제출하는거지? 아 그리고 릴리즈 때는 보통 협력사가 OEM한테 뭐를 배포해? (내 가정 중 틀린게 있으면 고쳐줘)

네, 지금 이해하신 흐름이 자동차 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

제미나이 관점의 답변

질문자님의 감각이 정말 대단하시네요. 완성차 개발 프로세스의 타임라인과 실무 흐름을 정확하게 짚고 계십니다.

말씀하신 가정이 전적으로 맞습니다. 질문하신 내용을 바탕으로 실무에서 벌어지는 승인도 제출 타이밍과 릴리즈(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의 매칭 스펙이 절대적인 기준으로 들어갑니다.

고객 요구사양서, 승인도 파헤치기1

아즈마민초 — Wed, 20 May 2026 11:41:26 +0900

혹시 자동차 프로세스에서 승인도가 뭔지 설명해줄 수 있어? OEM과 서플라이어간에 교류하는 고객의 요구사항 문서 중 하나 같긴한데..

네, 자동차 개발 프로세스에서 말하는 **“승인도”**는 일반적으로 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버전은 언급 안한거 같은데 승인도에 적힌 하드웨어 기구 버전에 맞는 SW버전은 안들어가?

네, 실제 자동차 업계에서는 승인도에 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 later

OEM 스타일 3

아예 HW/SW 통합 형상으로 관리

예:

ECU Part Number
HW Rev
SW Rev
Calibration Rev

전부 묶어서 승인

ADAS/자율주행 쪽은 이런 경향 강합니다.

8. ASPICE/기능안전 관점에서는 사실상 필수에 가까움

특히 ISO 26262에서는:

어떤 HW에
어떤 SW가
어떤 안전 메커니즘으로
어떤 버전 조합으로

검증되었는지가 중요합니다.

그래서 안전 감사에서는 종종 이런 질문 나옵니다.

"HW Rev B가
어떤 SW와 검증되었는가?"

이걸 추적 못하면:

형상관리 미흡
Release 관리 미흡
검증 재현성 부족

으로 지적될 수 있습니다.

실무적으로 변경요청은 어떻게 이루어지는가?

아즈마민초 — Tue, 19 May 2026 20:01:08 +0900

ASPICE를 준수하는 프로세스에서 문제해결관리와 변경요청관리 프로세스 간에 연계가 있자나, 즉 내부 문제 식별에서 변경이 필요할 경우 변경요청을 통해 변경요청관리 프로세스를 태우는 것과, 처음부터 고객이 변경 건을 요청해서 바로 변경요청과리 프로세스를 태우는 것이 있자나, 여기서 나는 전자의 경우에 대해서 실무적으로 정말 어떤 산출물을 가지고 어떤 활동들이 이어지는 건지 알고 싶어

맞습니다. ASPICE에서 실무적으로 중요한 포인트가 바로 그 부분입니다.
즉:

문제해결관리(Problem Resolution Management, SUP.9) 에서 식별된 문제 중
제품/산출물/요구사항/설계/테스트 등에 “변경”이 필요하면
변경요청관리(Change Request Management, SUP.10 또는 조직 Change Mgmt 프로세스) 로 연계되어
공식 변경통제 절차를 타게 됩니다.

그런데 실무에서는 이 흐름이 단순히 “이슈 하나 만들고 끝”이 아니라, 꽤 많은 산출물과 승인 흐름으로 이어집니다.

아래를 “현업에서 실제 굴러가는 수준”으로 설명해볼게요.

1. 상황 예시

예를 들어:

차량 시동 후 특정 조건에서
CAN Timeout 발생 시
Fail-safe 진입이 늦게 발생함

이라는 문제가 테스트 중 발견되었다고 가정해봅시다.

2. 문제해결관리 프로세스 시작 (SUP.9)

여기서는 핵심이:

“문제를 식별하고 원인 분석하고 추적 관리하는 것”

입니다.

보통 최초 산출물은:

(1) Problem Report / Defect / Issue 등록

도구 예:

Jira
Redmine
Codebeamer Issue Tracker
Polarion Defect
ALM 등

생성되는 정보:

이게 문제관리의 시작점입니다.

3. 초기 분석 활동

여기서 실무적으로 많이 하는 활동:

(2) Triage / Screening

보통 CCB 또는 리더급이 판단:

진짜 문제 맞는가?
중복인가?
우선순위는?
안전 영향 있는가?
즉시 수정 필요한가?

산출물:

Issue 상태 변경
Priority 결정
담당자 지정

예:

Assigned to SW Architect
Severity = Critical

4. 원인 분석 (Root Cause Analysis)

이 단계가 SUP.9의 핵심입니다.

실무적으로:

사용되는 기법:

5 Why
Fishbone
Fault Tree
Debug Log
Trace 분석

산출물:

RCA 보고 내용
영향 분석 초안

5. 여기서 “변경 필요” 판단 발생

중요한 포인트입니다.

문제 해결 방법이:

단순 운영 조치가 아니라
산출물 수정이 필요하면

여기서 변경관리 프로세스로 넘어갑니다.

즉:

6. 변경요청(Change Request) 생성

여기서 별도의 CR(Change Request)가 생성됩니다.

실무적으로는:

Problem Report와
Change Request를
링크로 연결합니다.

예:

관계

Problem PRB-1023 → CR-204 연결

7. 변경요청 산출물 내용

여기서부터는 “변경 통제” 영역입니다.

보통 CR에는:

(3) Change Request 문서/티켓

포함 내용:

8. 영향 분석 (Impact Analysis)

이게 ASPICE에서 굉장히 중요합니다.

실무적으로 가장 핵심 문서 중 하나입니다.

(4) 영향 분석서

분석 대상:

실무에서 여기서 보는 핵심

① 무엇을 수정해야 하는가?

요구사항?
설계?
코드?
테스트?

② 무엇을 다시 검증해야 하는가?

Regression 범위
Retest 범위
Safety Re-validation

③ 베이스라인 영향 있는가?

이미 Release된 베이스라인이면:

형상통제 필요
재승인 필요

9. CCB(Change Control Board) 승인

영향 분석 후 승인 단계.

여기서 판단:

산출물

CCB 회의록
승인 기록
전자결재
Tool Status 변경

예:

CR Status = Approved

10. 실제 개발 변경 수행

여기서부터 엔지니어링 활동 시작.

실제 수정:

11. 검증 및 Regression

변경 후 반드시:

영향 범위 검증
Regression 수행

실무적으로:

12. Closure

마지막으로:

(5) Problem Report 종료 조건 확인

문제가:

재현 안 됨
수정 검증 완료
회귀시험 완료

되면:

실제 실무 흐름을 한 줄로 정리하면

SUP.9(문제관리)

문제 발견
→ 문제 등록
→ 원인 분석
→ 수정 필요 판단

↓

SUP.10(변경관리)

변경요청 생성
→ 영향 분석
→ 승인(CCB)
→ 변경 수행
→ 검증/회귀시험
→ 베이스라인 업데이트

입니다.

실무에서 중요한 “연계 포인트”

ASPICE 관점에서 진짜 중요하게 보는 건:

① 문제 ↔ 변경요청 Traceability

즉:

“왜 이 변경을 했는가?”
“어떤 문제 때문에 변경되었는가?”

가 연결되어 있어야 함.

예:

PRB-1023 ↔ CR-204

② 영향 분석 Evidence

ASPICE assessor들이 매우 중요하게 보는 것:

“변경 영향 분석을 정말 했는가?”

입니다.

특히:

테스트 영향
안전 영향
타 기능 영향
Regression 범위

③ 승인 없이 변경 금지

ASPICE/ISO26262 둘 다 중요.

즉:

그냥 코드 수정 X
공식 승인된 변경이어야 함

실무에서 흔한 Tool 흐름

예시:

Problem Report 등록
    ↓
Root Cause Analysis
    ↓
Change Request 생성
    ↓
Impact Analysis 첨부
    ↓
CCB 승인
    ↓
Code Commit
    ↓
Test Result 연결
    ↓
Baseline Update
    ↓
Closure

마지막으로 아주 중요한 실무 포인트

실무에서는 사실:

Problem Report와
Change Request를

완전히 따로 운영하지 않는 회사도 많습니다.

예:

예를 들면 Jira/Redmine에서는:

Bug Issue 하나 안에
RCA
Impact Analysis
Approval
Test Result

다 넣어서 운영하기도 합니다.

다만 ASPICE 관점에서는 중요한 게:

프로세스 활동이 수행되었는가
Evidence가 남았는가

이지,
반드시 티켓이 두 개여야 하는 건 아닙니다.

baseline 잘 활용하기

아즈마민초 — Fri, 15 May 2026 15:18:38 +0900

형상감사 관련 질문을 할건데, 만약에 시스템 요구사항 명세서 1.2버전에 대해서 특정 베이스라인 긋는 시점일 때, 베이스라인을 그었어. 그 이후에 시스템 요구사항 명세서가 1.3 버전이 되었어 그러면 이 바뀌기 전에 반드시 형상 변경 요청이 되었어야하고, CCB회의도 이루어졌어야 해? ASPICE 프로세스를 만족하기 위해서 말이야

네, ASPICE 관점에서는 일반적으로 베이스라인 이후에 산출물이 변경되었다면, 그 변경은 반드시 형상변경관리(Change Control) 절차를 거쳐야 합니다.
즉 질문하신 상황이라면:

시스템 요구사항 명세서(SyRS) v1.2를 기준으로 Baseline 설정 완료
이후 문서가 v1.3으로 변경됨

→ 이 경우에는 원칙적으로:

변경 요청(CR/ECR 등) 등록
영향도 분석(Impact Analysis) 수행
CCB(Change Control Board) 승인
승인 후 문서 수정
새 버전(v1.3) 발행 및 필요 시 재베이스라인

이 흐름이 있어야 ASPICE의 형상관리/변경관리 기대사항을 만족한다고 보는 게 일반적입니다.

다만 중요한 건 ASPICE가 “반드시 CCB 회의를 해야 한다”라고 고정적으로 요구하는 건 아니라는 점입니다.

ASPICE에서 핵심은:

Baseline 이후 변경이 통제되었는가
변경 이력이 추적 가능한가
승인 권한이 정의되어 있는가
영향 분석이 있었는가
누가 승인했는가가 남아 있는가

입니다.

즉 CCB는 그걸 구현하는 대표적인 방법이지, “회의 자체”가 필수 요구는 아닙니다.

예를 들면 조직 프로세스에 따라:

Jira Workflow 승인
전자결재
Change Tool 승인
메일 승인
간소화된 Change Authority 승인

등으로도 가능합니다.

ASPICE 관점에서 연결되는 주요 프로세스는 보통:

SUP.8 Configuration Management
- 베이스라인 관리
- 형상항목 변경 통제
SUP.10 Change Request Management
- 변경 요청 등록/분석/승인/추적

입니다.

특히 SUP.8 BP5/BP6 계열에서:

baseline 이후 변경은 통제되어야 한다

라는 취지의 기대사항이 핵심입니다.

실무적으로 심사에서 많이 보는 포인트는 아래입니다.

반대로 예외도 있습니다.

예를 들어 조직 프로세스에서:

“Draft 상태는 baseline 아님”
“Baseline 이전 버전 변경은 자유 수정 가능”
“오탈자 수준은 Minor Change로 간소 승인 가능”

같은 규칙이 정의되어 있다면 괜찮습니다.

하지만 이미 공식 Baseline으로 선언된 시점 이후라면,
ASPICE에서는 일반적으로 “통제된 변경” 증적을 기대합니다.

한 줄로 정리하면:

Baseline 이후 v1.3으로 변경되었다면, ASPICE 만족을 위해서는 최소한 변경요청 + 승인(형상변경통제) 증적은 있어야 하고, CCB 회의는 대표적인 방법이지만 반드시 회의 형태일 필요는 없습니다.

아 근데 사실 아까 예시로 든 경우는, 베이스라인 그어진 형상인 1.2버전이 Accepted 상태가 아니라, draft 혹은 in review상태에서 어쩔 수 없이 베이스라인 긋는 시점이 와서, accepted가 아니라는 상황인 제약을 인지하고 베이스라인을 그었던 거야

아, 그 상황이면 얘기가 조금 달라집니다.
그 경우는 ASPICE 심사에서도 꽤 자주 나오는 현실적인 케이스예요.

즉 상황을 정리하면:

SyRS v1.2를 Baseline 설정
하지만 당시 상태는 Accepted 아님
- Draft / In Review 상태
프로젝트 일정이나 인터페이스 동결 등의 이유로
“완전 승인 전이지만 일단 기준점(Baseline)” 필요
이후 리뷰 반영해서 v1.3으로 변경

이런 흐름이죠.

이 경우 핵심은:

“그 Baseline이 어떤 성격의 Baseline이었는가?”

입니다.

ASPICE에서는 사실 “Baseline = 반드시 최종 승인본”이라고까지 강제하지는 않습니다.

실무에서는 아래처럼 많이 운영합니다.

즉 “완전히 Accepted는 아니지만 현 시점 frozen 기준”으로 baseline 잡는 건 가능합니다.

다만 중요한 건 프로세스/증적입니다.

예를 들어 심사에서 아래처럼 설명 가능해야 합니다.

“v1.2는 Draft 상태였으나 프로젝트 마일스톤상 임시 Baseline으로 설정하였다. 이후 Review 결과 반영을 위해 v1.3으로 업데이트하였다.”

이 흐름 자체는 크게 이상하지 않습니다.

그럼 v1.2 → v1.3 변경 시 CR/CCB가 반드시 필요하냐?

여기서 포인트는 조직 프로세스 정의입니다.

케이스 1) “Baseline 이후 모든 변경은 Change Control 대상”

이렇게 프로세스 정의되어 있으면:

Draft baseline이라도
변경 요청
영향분석
승인

필요합니다.

이 경우 CCB 간소화는 가능해도,
“통제된 변경” 증적은 있어야 합니다.

케이스 2) “Draft Baseline은 경량 변경 허용”

실무에서 꽤 많습니다.

예를 들면 프로세스에:

Draft Baseline 상태에서는 리뷰 반영 변경 가능
Formal Acceptance 이후부터 strict change control 적용
Minor review comment는 CR 생략 가능

같은 예외 규칙이 정의되어 있으면,
v1.2 → v1.3에서 별도 정식 CR 없이 운영 가능할 수도 있습니다.

ASPICE는 이런 “조직 규칙이 명확히 정의되어 있고 일관되게 운영되는가”를 더 중요하게 봅니다.

심사원이 실제로 보는 건 보통 이겁니다.

좋은 케이스

“v1.2는 Interim Baseline”
“Review pending 상태 명시”
“Review comment 기반 수정”
“변경이력 존재”
“승인 흐름 존재”

→ 충분히 설명 가능

위험한 케이스

Baseline인데 아무 통제 없음
누가 왜 바꿨는지 없음
변경 이력 없음
리뷰 결과 추적 안 됨
승인 책임 불명확

→ SUP.8/SUP.10 약점 지적 가능

실무적으로는 이런 식으로 많이 방어합니다.

Baseline Type 구분
- Preliminary Baseline
- Interim Baseline
- Formal Baseline
문서 상태 명시
- Draft Baseline
- Review Baseline
Review Comment 기반 변경 관리
- CR 대신 Review Log 활용

한 줄로 정리하면:

Draft/In Review 상태에서 불가피하게 Baseline을 잡은 것은 ASPICE상 충분히 가능한 시나리오입니다. 다만 이후 변경(v1.3)이 “통제된 변경”이었다는 증적은 필요하며, 반드시 정식 CCB/CR만이 답은 아니고 조직 프로세스에 정의된 경량 변경관리 방식으로도 충분히 설명 가능합니다.

근데 이런 규칙이, 형상관리 계획서나 절차 같은데 아직 명시가 안되어 있다면 어떡해?

그럼 ASPICE 심사에서는 솔직히 조금 위험한 상태입니다.
왜냐하면 ASPICE는 결국:

“우리가 이렇게 운영했습니다”

보다

“그 운영 방식이 프로세스로 정의되어 있었습니까?”

를 더 중요하게 보기 때문입니다.

즉 지금 상황은:

실무적으로는 충분히 이해 가능한 상황
하지만 규정/절차에 명시가 없음
그러면 심사 시 “임의 운영(ad-hoc)”처럼 보일 가능성 있음

이라는 게 핵심입니다.

다만 이게 곧바로 Major NC급 문제라는 뜻은 아닙니다.

심사에서는 보통 아래처럼 판단합니다.

지금 상황에서는 현실적으로 3가지 방어 포인트가 있습니다.

1. “Interim Baseline” 개념을 사후라도 정의

가장 현실적입니다.

예를 들면 형상관리계획서(CMP)나 절차서에:

프로젝트 일정상 필요 시 Draft 상태에서도 Interim Baseline 가능

근데 "Draft Baseline 상태에서는 리뷰 반영 변경 가능"이런 규칙이 형상관리 계획서나 절차 같은 곳에 아직 명시가 되어 있지 않으면 어떡해?

그럼 냉정하게 말하면 ASPICE 관점에서는 “프로세스 미정의 상태에서 운영한 것”이 됩니다.
즉 심사원이 보면:

“왜 baseline 이후 변경을 CR 없이 했습니까?”

라고 물었을 때,

“실무적으로는 draft baseline이라서요”

라고 설명은 가능하지만,

심사원 입장에서는 바로 이어서:

“그 규칙이 어디 정의되어 있습니까?”

를 보게 됩니다.

그리고 현재 문서에 없다면,
엄밀히는 “정의되지 않은 예외 운영”으로 해석될 가능성이 있습니다.

다만 여기서 중요한 건:

이미 발생한 상황을 어떻게 ‘합리적으로 방어’하느냐

입니다.

실무 심사에서는 완벽무결보다도:

합리적 운영인가
통제 의도가 있었는가
추적 가능한가
개선 활동을 하는가

를 많이 봅니다.

지금 상황에서 가장 현실적인 대응은 보통 아래 순서입니다.

1. 절차/계획서에 규칙 추가 (가장 중요)

가능하면 ASAP로 아래 같은 내용을 넣는 게 좋습니다.

예시:

Draft/In Review 상태의 형상항목은 Interim Baseline으로 관리 가능
Interim Baseline 이후 리뷰 결과 반영 변경은 경량 변경관리 적용 가능
Formal Accepted Baseline 이후에는 정식 CR/CCB 적용

이렇게 정의를 추가하면:

“당시 명확한 정의는 부족했지만, 현재 프로세스를 보완하였다”

라는 개선 흐름이 만들어집니다.

ASPICE에서는 이런 CAPA/Process Improvement를 긍정적으로 보는 편입니다.

2. v1.2 baseline 성격을 명확히 남기기

이게 중요합니다.

예를 들면:

Baseline Log
Release Note
Configuration Record
Review Record

등에:

“v1.2는 프로젝트 일정상 Interim Baseline으로 설정되었으며 Review pending 상태임”

같은 흔적이 있으면 꽤 방어가 됩니다.

3. v1.3 변경이 “무통제 수정”은 아니었다는 증적 확보

CR이 없더라도 아래가 있으면 꽤 도움이 됩니다.

Review Comment
Peer Review 결과
Jira ticket
변경 이력
Git history
승인 메일
회의록

즉:

“완전 자유 수정이 아니라 리뷰 기반 controlled update였다”

를 보여주는 게 핵심입니다.

그리고 현실적으로 심사 결과는 보통 이렇게 갈 가능성이 큽니다.

중요한 건 ASPICE는 ISO처럼:

“문서에 한 줄 없었으니 실패”

이렇게만 보지는 않는다는 겁니다.

특히 숙련 심사원들은:

프로젝트 현실성
긴급 baseline 상황
고객 milestone 압박

이런 것도 이해합니다.

대신 싫어하는 건:

설명이 매번 바뀜
프로젝트마다 다름
누가 승인했는지 모름
변경 이유 없음

같은 “비체계성”입니다.

그래서 지금 상황에서 가장 좋은 전략은:

“당시 Interim 성격으로 운영했고, 이를 명확히 하기 위해 현재 CM 절차를 보완 중이며, 변경은 리뷰 기반으로 통제되었다”

라는 스토리로 정리하는 겁니다.

이 방향이면 ASPICE 심사에서 충분히 방어 가능한 편에 속합니다.