1. 들어가며
차량 임베디드 시스템 개발에서 재사용(Re-use)은 이미 일상적인 전략입니다. 새 차종을 개발할 때 부트로더와 통신 스택, AUTOSAR나 BSW, 운영체제, 검증된 제어 로직, 이전 플랫폼의 애플리케이션 소프트웨어를 그대로 가져다 쓰는 일은 예외가 아니라 기본에 가깝습니다. 이렇게 검증된 자산을 재사용하면 개발 기간과 비용을 크게 줄일 수 있고, 이미 필드에서 수년간 동작한 코드라는 점에서 품질 측면의 이점도 분명합니다.
재사용의 이점은 세 가지로 요약됩니다. 첫째, 기존 개발에서 만든 작업 산출물(요구사항 명세, 설계서, 검증 보고서)을 다시 활용할 수 있습니다. 둘째, 변경되지 않은 부분에 대해서는 과거의 평가 결과를 그대로 승계할 수 있습니다. 셋째, 필드에서 축적된 검증된 운용 이력(Proven in Use)이 신뢰의 근거가 됩니다. 신규 모델이 이전 모델과 80~90% 동일하다면, 그 90%에 대한 분석과 검증을 처음부터 다시 할 이유는 없습니다.
이 재사용이라는 활동은 개별 엔지니어의 요령에 머무르지 않고, 자동차 분야의 핵심 표준에도 정식 프로세스로 들어가 있습니다. ISO 26262, Automotive SPICE®(이하 ASPICE®), ISO/SAE 21434가 각각 재사용 분석, 영향 분석, 재사용 자산 관리를 명시적으로 요구합니다. 다시 말해 현장의 실천과 표준의 요구가 같은 방향을 가리키고 있습니다.
그런데 역설적인 장면이 있습니다. 현장은 부품과 코드를 활발히 재사용하면서도, 정작 표준이 정의한 재사용 프로세스는 우회하는 경우가 많습니다. 결과적으로 “코드는 재사용하지만 그 정당성은 매번 새로 증명하거나, 아예 증명을 생략”하는 상태가 됩니다. 이 글에서는 이러한 논리적인 오류의 원인을 짚고, 재사용을 실제 개발 시간과 비용 절감으로 연결하는 실무적 방향을 제시합니다. 논의는 세가지 표준에 국한되지 않으며, 차량 임베디드 개발 전반에서 재사용을 어떻게 자산화할 것인가에 초점을 둡니다.
2. 재사용 프로세스의 외면
재사용 자체는 활발한데 재사용 프로세스는 외면받는 이유는 한 가지가 아니라 구조적으로 얽혀 있습니다. 현장에서 반복적으로 관찰되는 몇 가지 사항은 다음과 같습니다.
첫째, 영향 분석의 역설입니다. 재사용의 출발점은 무엇이 바뀌었고 무엇이 바뀌지 않았는가를 가려내는 영향 분석인데, 정작 바뀌지 않았음을 표준이 요구하는 수준으로 입증하는 작업이 신규 개발만큼 무겁게 느껴집니다. 변경분을 안전하게 한정하지 못하면 결국 전체를 다시 들여다봐야 하고, 그럴 바엔 처음부터 새로 한다는 심리가 작동합니다.
둘째, 형상 및 추적성 데이터의 단절입니다. 재사용 근거는 명확한 Baseline과 그에 대한 변경분 식별에서 나옵니다. 그러나 과거 프로젝트의 형상관리가 느슨했거나 요구사항-설계-검증 간 Traceability가 끊겨 있으면, 이 산출물이 어느 버전에 대응하고 무엇이 검증되었는지를 사후에 복원하기가 매우 어렵습니다. 근거를 찾지 못하니 재사용을 정당하게 주장할 수 없습니다.
셋째, 책임과 리스크 회피입니다. 재사용한 부분에서 문제가 생기면 책임 소재가 모호해집니다. 특히 안전과 보안 영역에서는 재사용을 정당화하는 논거(Proven in Use argument, Cybersecurity Claim)를 문서로 남겨야 하는데, 이 논거 작성 자체가 부담스러워 차라리 새로 개발해 책임을 단순화하려 합니다.
넷째, 도구체인과 데이터의 비호환입니다. 과거 산출물이 현재 사용하는 요구사항 관리 도구, 모델, 파일 포맷과 맞지 않으면 재사용은 곧 새로운 변환과 정리 작업이 되어 버립니다. 마이그레이션 비용이 재작성 비용에 근접하면 재사용의 경제성이 사라집니다.
다섯째, 일정과 KPI 압박입니다. 단기 일정 관점에서는 익숙한 방식으로 새로 만드는 편이 더 빠르게 느껴지고, 재사용 절차를 학습하고 근거를 갖추는 초기 투자가 당장의 마일스톤에는 비용으로만 보입니다. 평가 지표가 이번 프로젝트의 납기에 맞춰져 있으면 재사용의 장기 이익은 후순위로 밀립니다.
3. 국제 표준에서의 재사용 요구사항
앞에서 언급한 표준 모두 검증된 자산을 가져다 쓰되 변경의 영향을 분석하고 그 근거를 남기라는 동일한 철학을 공유합니다. 다만 강조점이 조금씩 다릅니다.
ISO 26262는 변경에 대한 영향 분석을 핵심에 둡니다. Part 2의 6.4.3은 Item-level의 영향 분석을, 6.4.4는 기존 엘리먼트를 재사용할 때의 엘리먼트 수준 영향 분석을 요구하여, 변경이 기능안전에 미치는 영향과 재사용 가능 여부를 판단하게 합니다. Part 8은 재사용을 뒷받침하는 두 가지 메커니즘을 제공합니다. Clause 12(Qualification of software components)는 기존 소프트웨어 컴포넌트를 정해진 절차로 검증해 재사용을 정당화하고, Clause 14(Proven in use argument)는 충분한 필드 사용 이력을 근거로 안전성을 논증하도록 합니다.
ASPICE®는 재사용을 프로세스 자산 관리의 관점에서 다룹니다. 재사용하려는 자산이 현재의 요구사항과 맥락에 적합한지를 평가하고, 재사용의 조건과 제약을 문서화하며, 형상관리 및 변경관리와 연계해 재사용 자산의 상태를 추적하도록 요구합니다. 즉 어떤 조건에서 무엇을 어떤 제약으로 재사용하는가를 관리 대상으로 명시합니다.
ISO/SAE 21434는 재사용을 사이버보안 관점에서 재평가하도록 요구합니다. 6.4.4(Reuse)는 변경이나 운영환경 변화, 또는 알려진 공격과 취약점의 변화가 있을 때 재사용 분석을 수행하라고 하고, 6.4.5(Component out-of-context)는 맥락을 가정해 개발된 컴포넌트의 가정과 외부 인터페이스를 문서화하고 검증하도록 하며, 6.4.6(Off-the-shelf component)은 기성품 컴포넌트의 보안 문서를 수집하고 분석해 충분성을 판단하게 합니다. 이 활동들은 6.4.3(Tailoring)과 연계되어, 재사용으로 생략하거나 조정하는 활동에 대한 근거를 남기도록 합니다.
세 표준의 재사용 요구를 정리하면 다음과 같습니다.
- ISO 26262
- 재사용관련 조항: Part 2 6.4.3, 6.4.4 / Part 8 Clause 12, Clause 14
- 핵심 요구: 변경의 아이템 및 엘리먼트 수준 영향 분석, 소프트웨어 컴포넌트 검증, 검증된 사용 이력 논거
- 주요 산출물: 영향 분석 결과, 컴포넌트 검증 보고서, Proven in Use 논거
- ASPICE®
- 재사용 관련 조항: 재사용 자산 및 재사용 프로그램 관리 관점
- 핵심 요구: 재사용 적합성 평가, 재사용 조건과 제약 문서화, 형상 및 변경관리 연계
- 주요 산출물: 재사용 평가 기록, 재사용 자산 목록과 제약 명세
- ISO/SAE 21434
- 재사용 관련 조항: 4.4 / 6.4.5 / 6.4.6 (+ 6.4.3 Tailoring)
- 핵심 요구: 재사용 시 보안 재평가, OoC 가정과 인터페이스 검증, 기성품 보안 문서 분석
- 주요 산출물: 재사용 분석 결과, 가정과 인터페이스 명세, Tailoring 근거
요약하면, 세 표준 모두 재사용을 금지하지 않습니다. 오히려 근거를 갖춘 재사용을 정식 경로로 인정합니다. 다만 이 표준들은 재사용을 관리하는 틀일 뿐, 재사용 자체의 동기는 표준 이전에 이미 존재합니다. 막히는 지점은 표준이 아니라, 그 근거를 댈 수 있는 데이터와 준비의 부재입니다.
4. 효과적인 재사용 전략
재사용을 실질적 이익으로 바꾸려면, 재사용을 다음 프로젝트에서 결정할 일이 아니라 이번 프로젝트에서 미리 준비할 일로 옮겨야 합니다. 이는 세 표준의 요구를 충족하기 위해서이기도 하지만, 그 이전에 차량 임베디드 개발의 효율 자체를 높이는 길입니다. 몇 가지 실무 방향을 제안합니다.
첫째, 재사용을 전제로 설계합니다. 산출물을 기능 및 모듈 단위로 구조화하고 요구사항-설계-검증에 추적성 태그를 부여하면, 다음 프로젝트에서 변경된 모듈만 평가 대상으로 한정할 수 있습니다. 부트로더, 통신 스택, BSW처럼 차종 간 공통으로 쓰이는 영역을 처음부터 분리해 두면 나중에 떼어 쓰기 쉽습니다.
둘째, 델타(Delta) 평가 프레임워크를 도입합니다. 기준선 대비 델타(변경분)을 식별하는 절차를 정형화하면, 영향 분석의 범위가 자동으로 한정되고 변경되지 않은 부분의 평가 결과를 명시적으로 승계할 수 있습니다. 핵심은 전체를 다시 보는 것에서 바뀐 것만 보고 나머지는 승계 근거를 남기는 것으로 작업의 기본값을 바꾸는 데 있습니다.
셋째, 재사용 자산 라이브러리를 운영합니다. 산출물만 따로 보관하면 재사용 시점에 근거가 흩어집니다. 산출물에 형상 정보, 검증 근거, 개발 당시의 가정과 제약을 하나의 패키지로 묶어 보관하면, 다음 프로젝트는 꺼내서 검증 근거를 확인하는 것만으로 재사용을 시작할 수 있습니다.
넷째, 영향 분석을 체크리스트화하고 자동화합니다. 변경이 어디까지 파급되는지를 추적성 기반으로 자동 식별하고, 어떤 변경이 어떤 재평가를 유발하는지를 규칙으로 정의해 두면, 영향 분석이 매번 백지에서 시작하는 작업이 아니라 반복 가능한 절차가 됩니다.
다섯째, 논거를 템플릿화합니다. Proven in Use 논거, Cybersecurity Assurance Level(CAL) 주장, 분산 개발 시의 Cybersecurity Interface Agreement(CIA) 같은 재사용 정당화 문서를 표준 템플릿으로 갖추면, 논거 작성 부담이 크게 줄어듭니다.
이 다섯 가지의 효과는 분명합니다. 재평가 범위가 줄어 검증 공수와 일정이 절감되고, 동일한 검증된 자산을 일관되게 사용함으로써 품질과 일관성이 함께 올라갑니다. 재사용의 초기 투자는 비용처럼 보이지만, 두 번째 프로젝트부터는 회수되는 자산입니다.
5. 결론
차량 임베디드 개발에서 재사용은 이미 시간과 비용을 줄이는 핵심 수단으로 자리 잡았고, 위 세 표준은 그 재사용을 안전하고 일관되게 관리하는 길을 열어 두었습니다. 현장에서 그 길을 끝까지 걷지 못하는 이유는 표준이 어려워서가 아니라, 재사용을 주장할 근거(추적성, 형상)가 준비되어 있지 않기 때문입니다. 영향 분석을 이번에 치러야 할 비용으로만 보면 재사용은 늘 부담스럽지만, 산출물을 처음부터 재사용 가능한 형태로 설계하고 그 근거를 자산으로 축적하면 영향 분석은 다음 프로젝트의 시간을 사주는 투자로 바뀝니다.
그래서 제안하는 생각의 방향은 두 가지입니다. 하나는, 다음 양산 프로젝트의 작업 산출물을 언젠가 재사용될 것을 전제로 설계하는 것입니다. 다른 하나는, 재사용 자산을 개인의 폴더가 아니라 조직 차원의 거버넌스로 관리하는 것입니다. 재사용 자산 라이브러리, 델타 평가 절차, 논거 템플릿을 조직의 표준 프로세스로 정착시킬 때, 비로소 표준에는 있는데 현장에는 없던 재사용 프로세스가 실제 개발 시간과 비용의 절감으로 돌아옵니다.
참고문헌
[1] ISO 26262:2018, Road vehicles – Functional safety, Part 2: Management of functional safety (6.4.3, 6.4.4)
[2] ISO 26262:2018, Road vehicles – Functional safety, Part 8: Supporting processes, Clause 12 (Qualification of software components), Clause 14 (Proven in use argument)
[3] ISO/SAE 21434:2021, Road vehicles – Cybersecurity engineering, Clause 6 (6.4.3 Tailoring, 6.4.4 Reuse, 6.4.5 Component out-of-context, 6.4.6 Off-the-shelf component)
[4] Automotive SPICE® Process Assessment / Reference Model
[5] ISO/SAE PAS 8475, Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility
[6] ISO 26262:2018, Road vehicles – Functional safety, Part 1: Vocabulary