현장에서 ASPICE나 기능안전 컨설팅/인증을 수행하다 보면 계획서 자체를 심사를 위한 산출물로서 인식하는 경우가 많습니다. 현업에 집중해서 실무를 하는 담당자 입장에서 충분히 공감되는 점이 있습니다. 한편으로 계획서를 심사 대응용 문서가 아니라 프로젝트가 실제로 움직이는 방식과 연결된 “운영 기준(Operational Baseline)”으로 전환하면, 문서 부담은 줄이면서 표준 준수의 실효성을 높일 수도 있습니다. 이번 글에서는 계획서의 실효성을 높이는 방법에 대해서 알아보겠습니다.
1. 개요
자동차 제어기의 개발 현장에서 ASPICE, 기능안전, 사이버보안을 동시에 적용하다 보면 프로젝트마다 프로젝트 계획서, 형상관리 계획서, 변경관리 계획서, 문제점 관리 계획서, 품질보증 계획서 등이 각각 별도 문서로 만들어집니다. 문제는 이 문서들이 한 번 작성된 뒤 거의 갱신되지 않고, 실제 프로젝트는 Jira, Git, 회의체, 코드 리뷰로 돌아가는데 계획서만 따로 존재한다는 점입니다.
이 현상의 본질은 문서가 많아서가 아니라, 계획서가 “실행을 정의하는 기준”이 아니라 “심사에 제출하는 산출물”로 목적이 뒤바뀌었기 때문입니다. 전략이란 원래 앞으로 하겠다는 다짐이 아니라 지금 우리가 어떻게 의사결정하고 통제하고 기록하고 검증하는지를 명문화한 것입니다. 그런데 대부분의 계획서는 실행과 분리된 채 “작성 그 자체”가 목적이 되어, 계획 작성에만 수 개월이 걸리면서도 정작 프로젝트 운영에는 쓰이지 않는 왜곡이 발생합니다.
여기서 한 가지 개념을 분명히 할 필요가 있습니다. 프로젝트가 “관리된다”는 말은 결국 조직이 일하는 방식, 즉 조직의 운영(Operation)이 정해져 있다는 뜻입니다. 개발하고, 검증하고, 변경을 통제하고, 문제를 처리하는 이 모든 활동을 조직이 반복 가능한 방식으로 수행하는 것이 바로 프로세스(Process)입니다. 그리고 이 프로세스, 다시 말해 “우리가 실제로 일하는 방법”을 정리해 놓은 것이 곧 전략이고 계획입니다. 따라서 전략과 계획은 실무와 별개로 새로 만들어 준비하는 문서가 아니라, 지금 조직이 개발과 검증과 관리를 어떻게 수행하는지를 그대로 적어 놓은 것이어야 합니다. 계획서가 죽은 문서가 되는 근본 원인은 바로 이 순서가 뒤집혀, 일하는 방식과 무관하게 문서부터 만드는 데 있습니다.
이 글에서는 문서 수를 줄이는 데 초점을 두지 않습니다. 그보다 계획을 실제 운영 시스템(Tool)과 연결된 살아있는 기준으로 바꾸어, 작성 부담을 낮추면서도 표준이 요구하는 통제와 증거(Evidence)가 자연스럽게 남도록 하는 실용적 방법을 제시합니다. 핵심은 한 문장으로 “문서 중심 준수(Document-driven Compliance)에서 운영 중심 준수(Operation-driven Compliance)로”입니다.
2. 3계층 계획 구조
여러 계획서를 각각 독립적으로 작성하면 목적, 범위, 역할, 일정, 승인, 변경관리 같은 항목이 문서마다 반복되어 중복이 커지고, 하나가 바뀌면 나머지도 고쳐야 하므로 사실상 갱신이 매우 어렵게 됩니다. 실용적인 해법은 문서를 계속 늘리는 대신 다음 3계층으로 재편하는 것입니다.
3계층 계획 구조
- 1계층 프로젝트 운영계획서(Project Operation Plan): 프로젝트 전체 운영 원칙과 기준을 정의하는 단일 문서 (예: A 도메인 제어기 운영계획서)
- 2계층 도메인 부속서(Domain Addendum): 기능안전, 사이버보안 등 도메인별 고유 활동만 최소한으로 추가 (예: 기능안전 부속서, 사이버보안 부속서)
- 3계층 Tool 기반 Evidence: Jira, Git, 리뷰 기록, 테스트 결과, 추적성 매트릭스 등 실제 수행 증거 (예: Jira CR-1024, Git v1.2.0 Tag)
기존에 별도 문서였던 것들은 다음과 같이 통합 또는 첨부합니다. 변경관리 계획서는 운영계획서 안의 변경통제(Change Control) 운영 규칙으로, 형상관리 계획서는 Git/ALM의 브랜치, 베이스라인, 릴리스 규칙 정의로, 문제점 관리 계획서는 Jira 이슈 워크플로우와 심각도(Severity) 기준으로, 품질보증 계획서는 QA 체크포인트, 리뷰 게이트, 감사 증거로 대체됩니다. 기능안전과 사이버보안처럼 표준 고유의 활동만 남은 부속서(2계층)로 남기면 됩니다.
여기서 원칙은 “계획서가 Tool 운영을 대체하는 것이 아니라, Tool 운영의 기준을 설명한다”는 것입니다. 실행의 상세 기록은 Tool에 남기고, 문서에는 그 Tool을 어떤 규칙으로 운영하는지만 적습니다. 필요한 경우는 해당 Tool의 사용 가이드를 참고하면 됩니다.
3. 실행 가능한 계획서 작성
계획서가 실행되지 않는 또 다른 이유는 내용이 지나치게 추상적이기 때문입니다. 예를 들어 변경관리 항목에 “본 프로젝트는 모든 변경을 관련 이해관계자의 검토와 승인을 거쳐 체계적으로 관리한다”라고 쓰면 문장은 맞지만 실무자가 무엇을 어떻게 해야 하는지 알 수 없습니다. 같은 내용을 다음과 같이 간단한 운영 규칙 형태로 바꾸면 그대로 실행할 수 있습니다.
실행 가능한 계획서 작성
- 변경 등록 위치: Jira CR 이슈 등록 (예: CR-2025-014)
- 변경 대상: 요구사항, 설계, 코드, 테스트 (예: EPS 조향각 요구사항 수정)
- 승인 필요 조건: 안전/보안 영향, 고객 요구, 베이스라인 변경 (예: OTA 기능 추가 시 승인)
- 승인자: PM, 개발 리드, Safety/Cybersecurity Manager (예: 브레이크 변경은 Safety Manager 승인)
- 영향분석 항목: 일정, 원가, 설계, 검증, 안전/보안 (예: 일정 2주 지연, 재검증 3건)
- Evidence: CR ID, 영향분석 결과, 승인 로그 (예: CR-2025-014 승인 로그)
- 업데이트 트리거: 베이스라인 변경, 릴리스, 요구사항 변경 (예: Baseline v2.0 확정 시)
예를 들어 텔레매틱스 ECU에 OTA(무선 업데이트) 기능을 추가하는 변경이라면, 담당자는 Jira에 CR을 등록하고 보안 영향 필드를 체크하며, 이 경우 Cybersecurity Manager 승인이 자동으로 요구되도록 워크플로우를 설정해 두면 됩니다. 계획서에는 예를 들면, 이 규칙 한 표만 있으면 충분하고, 실제 승인 이력은 Jira에 Evidence로 남습니다.
프로젝트 유형별 계획 수준
- 신규 개발 + ASIL 적용 + Cybersecurity 영향 → Full Planning (예: 신규 ADAS 도메인 제어기)
- 기존 제품 일부 기능 변경 → Lightweight Planning (예: 실내등 제어 로직 개선)
- 캘리브레이션 변경 중심 → Change-based Planning (예: 엔진 맵 캘리브레이션 조정)
- 문서 보완 중심 → Minimal Planning (예: 산출물 개선, 서식 보완)
- 양산 이후 이슈 대응 → Operation / Problem 중심 (예: 필드 클레임 대응)
또한 ASPICE, ISO 26262, ISO 21434를 모두 적용한다고 해서 모든 프로젝트가 같은 크기 및 내용의 문서를 만들 필요는 없습니다. 프로젝트 성격에 따라 계획을 테일러링(Tailoring)하면 부담이 크게 줄어듭니다.
4. Evidence Map
전략 수립이 매번 2~3개월씩 걸리는 근본 원인은 프로젝트마다 운영 방식을 백지에서 다시 설계하기 때문입니다. 회사 차원에서 표준 운영모델(Standard Operation Model)을 미리 만들어 두면 편리합니다. 단, 표준 운영모델이란 ASPICE/ISO 26262/ISO 21434 표준 내용을 옮겨 놓은 프로세스가 아니라, 조직이 수행하는 절차나 실제 실행하는 내용을 정의한 프로세스나 모델입니다. 이러한 모델이 있으면 프로젝트 시작 시에는 새로 설계하는 것이 아니라 표준을 선택하고 테일러링만 하면 되므로 기간을 1~2주로 단축할 수 있습니다.
이 중 실용적인 효과를 내는 것이 Evidence Map입니다. 문서 중심 조직은 “어떤 문서를 만들어야 하는가”를 먼저 묻지만, 운영 중심 조직은 “어떤 증거가 어디에 남는가”를 먼저 정의합니다. 아래처럼 관리 활동과 실제 증거를 미리 연결해 두면, 심사 시 “우리는 이 활동을 이 방식으로 운영하며 증거는 여기에 있다”라고 바로 제시할 수 있어 작성 부담과 심사 대응 부담이 동시에 줄어듭니다.
Evidence Map
- 프로젝트 계획 수립 → 운영계획서, 일정 베이스라인 (예: SOP 일정 확정)
- 형상관리 수행 → Git Tag, Baseline, Release Note (예: v1.3.0 Tag 생성)
- 변경관리 수행 → Jira CR, 영향분석, 승인 기록 (예: CR-118 승인 반영)
- 문제점 관리 수행 → Jira Issue, 근본원인 분석, 시정조치 (예: BUG-88 원인 분석)
- 품질보증 수행 → QA Review, Audit 결과, Checklist (예: Review Gate 통과)
- 추적성 확보 → ALM 추적성 매트릭스 (예: 요구사항-테스트 링크)
- 릴리스 판단 → Release Note, Known Issue, 승인 기록 (예: 잔여 결함 0건 승인)
5. 무엇을 언제 갱신할지 정의
계획서가 갱신되지 않는 가장 큰 이유는 “언제 고쳐야 하는지”가 정의되어 있지 않기 때문입니다. 그렇다고 모든 변경마다 문서를 수정하는 것은 비현실적입니다. 해법은 변경의 종류에 따라 갱신 대상을 다르게 두는 것입니다. 담당자 이름이나 일정 일부가 바뀌면 Tool의 RACI 표나 일정만 고치고, 단순 이슈 상태 변경은 Tool Evidence로 충분하므로 문서를 건드리지 않습니다. 반면 워크플로우, 승인 기준, 표준 적용 범위, 고객 요구사항이 바뀔 때만 운영계획서나 부속서를 갱신합니다. 이렇게 갱신 트리거를 계획서에 명시하면 계획서가 비로소 살아있는 문서가 됩니다.
한편 ASPICE와 두 표준 관점에서 가장 위험한 상태는 문서가 부족한 것이 아니라 문서와 실제 수행 방식이 다른 것입니다.
따라서 좋은 계획서는 완벽하게 이상적인 계획서가 아니라 실제로 지킬 수 있는 계획서입니다. 문서에 맞춰 일하려 하지 말고, 일하는 방식을 표준 요구사항에 맞게 설계한 뒤 그 결과가 문서와 Evidence로 남게 하는 것이 핵심입니다.
6. 결론
정리하면, 개선의 방향은 문서를 잘 쓰는 것이 아니라 실제 운영 방식이 표준 요구사항을 만족하도록 설계하고 그 결과가 자연스럽게 증거로 남게 만드는 것입니다. 현장 적용은 다음 순서를 권장합니다.
먼저 현재 작성 중인 계획서를 모두 나열하고 목적, 범위, 역할, 일정, 승인, 변경관리, 형상관리, 품질보증처럼 반복되는 중복 항목을 표시합니다. 다음으로 통합할 것과 분리할 것을 나눕니다. 프로젝트, 형상, 변경, 문제, 품질은 하나의 운영계획서로 통합하고, 기능안전과 사이버보안 고유 활동만 부속서로, 검증/테스트 상세는 필요 시 테스트 전략으로, 릴리스는 체크리스트 중심으로 남깁니다. 그리고 문서를 쓰기 전에 실제 Tool 워크플로우부터 정의합니다. 요구사항 변경은 어디서 등록하는지, 영향분석 필드는 무엇인지, Safety/Cybersecurity 영향은 누가 판단하는지, 베이스라인은 언제 생성하는지, 릴리스 승인 조건은 무엇인지에 답하지 못하면 계획서는 아무리 잘 써도 실행되지 않습니다. 마지막으로, 계획서는 이 워크플로우를 설명하는 수준으로 작성하고, 갱신 트리거를 명확히 규정합니다.
실무 적용 시 주의할 점은 세 가지입니다. 첫째, 표준 운영모델을 만들되 현장이 실제로 지킬 수 있는 수준으로 잡아야 합니다. 지나치게 이상적인 모델은 다시 죽은 문서가 됩니다. 둘째, Tool 워크플로우와 계획서의 규칙이 어긋나면 곧바로 불일치가 되므로, 워크플로우를 바꾸면 계획서 갱신 트리거가 작동하도록 연결해 두어야 합니다. 셋째, 테일러링 근거는 반드시 기록으로 남겨야 합니다. 생략한 활동에 대한 근거가 없으면 심사에서 가장 먼저 지적됩니다. 이 세 가지만 지키면, 계획서는 심사를 위한 부담이 아니라 프로젝트가 실제로 움직이는 방식의 명문화로 자리 잡을 수 있을 것으로 기대됩니다.
참고문헌
[1] ISO 26262-2:2018, Road vehicles – Functional safety – Part 2: Management of functional safety
[2] ISO 26262-8:2018, Road vehicles – Functional safety – Part 8: Supporting processes
[3] ISO/SAE 21434:2021, Road vehicles – Cybersecurity engineering
[4] VDA QMC, Automotive SPICE® Process Assessment / Reference Model, v3.1 (2017) / v4.0 (2023)
[5] VDA QMC, Automotive SPICE® Guidelines, 2.0 (2023)
[6] LHP Engineering Solutions, “What is Tailoring in Functional Safety?”
[7] Mintzberg, H. & Waters, J. A. (1985), “Of Strategies, Deliberate and Emergent,” Strategic Management Journal, Vol. 6, No. 3, pp. 257-272
[8] ISO 9001 Clause 7.5: Documented Information
관련 서비스
심사용 문서로 끝나지 않는 ASPICE 프로세스를 고민 중이시라면, 세온이앤에스가 어떻게 접근하는지 확인해 보세요.
관련 영상
이 글의 핵심을 영상으로도 정리했습니다.