[Summary]
- 단품 요소 기술을 넘어선 통합 시스템 기반 기술과 분석 프레임워크를 소개합니다.
- 자체 시스템 요구사항 개발, 시스템 아키텍처 설계, 시스템 분석으로 이어지는 시스템 설계의 핵심 3요소와 그 유기적인 관계를 강조합니다.
- V-Cycle은 순차적 일방통행이라는 편견, 추적성이 곧 설계 품질이라는 착각, 하위 설계일수록 항목 수가 무조건 늘어난다는 현업의 3가지 오해를 짚어내고 진실을 규명합니다.
- 엔지니어 개인의 경험에만 의존하는 방식에서 벗어나, 표준화되고 구조화된 시스템 분석 프레임워크 도입의 필요성을 제시합니다.
Author's Note
안녕하세요. HL만도에서 제동 제품의 플랫폼(Platform) 단위 시스템 아키텍처(System Architecture) 및 안전 분석 영역의 업무 수행 방식과 전반의 구조를 조율하는 역할을 담당하고 있는 장훈도 책임연구원입니다.
일반적으로 HL만도와 같은 1차 공급사(Tier 1) 업체들에서 기술력에 대한 이야기를 할 때에는 모터(Motor) 제어, 전자제어장치 하드웨어(ECU HW) 회로 제어 설계 등의 단품 요소 기술(Elemental Technology)*에 대한 내용을 주로 다룹니다. 그러다 보니 이러한 요소 기술들을 유기적으로 통합 설계하는 기반 기술 및 분석 방법론 자체를 기술력으로 표현하고 소개하는 자료는 거의 찾아보기 힘듭니다. 이러한 환경에서 시스템 기반 기술과 그 분석 방법의 체계를 소개할 수 있는 기회가 주어져 매우 기쁩니다.
💡 Editor’s Tip 요소 기술(Elemental Technology)이란?
모터, 반도체 회로, 밸브처럼 시스템을 구성하는 ‘개별 부품이나 단품 기능 기술’을 뜻합니다. 반면, 장훈도 책임연구원이 다루는 ‘시스템 아키텍처 및 기반 기술’은 이 개별 요소 기술들이 하나의 시스템 안에서 오작동 없이 안전하게 맞물려 돌아가도록 총괄하는 ‘전체 설계도이자 조율 체계’를 의미합니다.
필자는 늦은 밤 사무실에 홀로 남아 외로이 퇴근을 할 때마다 스스로에게 물음을 던지곤 했습니다.
“대체 무엇을 위해 이렇게까지 열심인가?”
“단품 요소 기술을 직접 만드는 능력이 없음에도, 나는 스스로를 엔지니어라 부를 수 있는가?”
오랜 고민 끝에 스스로 얻은 답은, “나의 아이가 거리를 다니다가 내가 설계 및 분석에 참여하여 개발한 제품이 탑재된 차량의 브레이크 이상으로 부상을 당하게 하고 싶지 않다”는 간절한 마음이었습니다. 추상화된 개체에 대한 올바른 설계 원칙을 세우고 정밀한 분석 방법론을 적용한다면, 스스로 얻은 답에 당당히 최선을 다한 결과로 증명할 수 있다는 확신을 얻을 수 있었습니다.
시스템 아키텍처 및 분석(System Architecture & Analysis) 기술 또는 방법론은 학술적인 내용보다 현장의 요소 기술 응용 및 적용, 통합 노하우(Know-how)가 집약되는 분야이기에 서적이나 논문은 물론 기업의 기술 소개 자료조차 찾아보기가 어렵습니다. 그래서 필자는 현업에서 치열하게 고민해 온 방법론과, 그 고민 끝에 도출된 HL만도의 시스템 분석 프레임워크(Framework)에 대해 소개해보고자 합니다.
1. 시스템 설계의 3요소
차량 산업에서 공급망(Supply Chain)을 여러가지 관점으로 볼 수 있지만, 대부분은 완성차 납품방식(OEM)으로 시스템 및 하위 시스템(System / Sub-system)을 개발하여 납품합니다. 그래서 개발은 고객 요구사항으로부터 시작됩니다.
그러나 HL만도와 같이 글로벌의 다양한 고객을 상대하는 회사에서는 고객 요구사항대로만 수동적으로 개발하게 되면 연구개발(R&D) 효율성이 매우 떨어집니다. 따라서 다수 고객의 요구사항을 수용할 수 있는 자체적인 시스템 요구사항(System Requirement) 개발이 필수적입니다.
- 시스템 요구사항(System Requirement) : 구체적인 수치들은 매개변수(Parameter, 파라미터) 화하고, 대부분 방정식이나 기능적 목적 또는 목표를 기술하는 방식으로 정의합니다.
- 시스템 아키텍처 설계(System Architectural Design) : 이를 실현(Realization)하기 위해 “언제, 얼마나, 어떻게” 작동할지를 구체화하는 단계입니다. 이때 우리는 요구사항 간 추적성을 통해 기술한 목적 또는 목표 달성의 방법이 적절한가를 검토합니다.
- 시스템 분석(System Analysis) : 시스템 아키텍처 설계가 예외 상황이나 잠재적 고장의 영향을 충분히 고려하여 안전하게 설계되었는가를 검증하는 핵심 활동입니다.
이 때 시스템 아키텍처뿐만 아니라 시스템 요구사항을 반드시 함께 보아야 합니다. 목적과 수단이 일치하는가, 즉 시스템이 목표한 바를 다양한 예외 상황 속에서도 충분히 달성할 수 있는 기술적인 근거가 확실한 것인가를 보아야 하기 때문입니다.
필자가 주로 다루고자 하는 주제가 바로 이 시스템 분석(System Analysis)이며, 본격적인 방법론 소개에 앞서 현업 엔지니어링 현장에서 흔히 마주치는 3가지 오해를 짚어보고자 합니다.
2. 현업 엔지니어가 짚어보는 시스템 개발의 ‘오해와 진실’
[오해와 진실 - 1] V-Cycle은 순차적으로 진행되는 일방통행 프로세스다?
진실 : 모든 개발 영역은 동시다발적으로 살아 움직이며 맞물려 돌아갑니다.
자동차 산업에서 주로 사용하고 있는 개발 방법론은 V-Cycle[1]입니다. 이를 프로세스 관점에서 체계화한 대표적인 표준이 능력 성숙도 모델(CMMI)과 에이스파이스(A-SPICE)[2]이며, 이러한 프로세스를 바탕으로 최소한으로 갖추어야 할 기술적 요건을 정의한 것이 기능 안전 표준인 ISO 26262와 사이버 보안 표준인 SAE/ISO 21434입니다.
[모아빌리티] A-SPICE 이해하기
모빌리티 업계를 꿈꾸는 이들은 주목! HL Mobility Labs가 모빌리티 실무자라면 꼭 알아야 하는 이야기를 모은 모빌리티 해설집 를 새롭게 준비했습니다. HL Mobility Labs가 준비한 모아빌리티 첫 이야
www.hlworld.com
흔히 V-Cycle의 구조도만 보고 개발이 좌측 상단에서 우측 상단으로 물 흐르듯 순차적으로만 진행되는 ‘일방통행 프로세스’라고 오해하곤 합니다. 하지만 현실의 개발 환경은 결코 순차적이지 않습니다. 설계 변경 요구는 최상위 시스템(System) 영역뿐만 아니라 소프트웨어(SW), 하드웨어(HW), 심지어 이미 시험(Test)이 한창 진행 중인 단계에서도 동시 다발적으로 발생합니다.
이상적으로는 변경 사항을 상위 시스템부터 차례대로 반영해야 하겠지만, 실무에서는 각 영역의 설계와 검증이 동시에 살아 움직이며 맞물려 돌아갑니다. 따라서 “상위 설계가 완전히 끝나지 않아 하위 업무를 진행할 수 없다”는 것은 현장을 고려하지 않은 커다란 오해입니다. V-Cycle에서 보이는 순차적인 단계는 단지 형상관리(Configuration Management) 측면에서 특정 시점의 기준선(Baseline)[3] 별 문서를 동결(Freeze)[4]해 정리한 관리적 결과물일 뿐이니까요.
[1] V-Cycle (V-모델): 시스템 개발 생명주기를 나타내는 모델로, 좌측의 하향식 설계와 우측의 상향식 검증을 1:1 대칭시켜 단계별 정합성을 확인하는 프로세스 체계.
[2] CMMI & A-SPICE: 소프트웨어 및 시스템 개발 조직이 신뢰할 수 있는 개발 프로세스를 갖추었는가를 평가하는 국제 공인 역량 평가 모델 (A-SPICE는 자동차 특화 표준).
[3] 기준선 (Baseline): 프로젝트 진행 중 특정 시점에 공식 승인되어 변경이 제한된 설계 산출물의 기준 상태.
[4] 동결 (Freeze): 설계의 잦은 변경으로 인한 혼선을 막기 위해 특정 시점에 사양 변경을 엄격히 제한하는 조치.
[오해와 진실 – 2] 설계 품질의 핵심 척도는 추적성(Traceability)이다?
진실 : 추적성은 수단일 뿐, 본질은 정보의 ‘일관성(Consistency)’입니다.
일반적으로 시스템 설계가 올바르게 되었는지를 평가할 때 가장 먼저 살피는 지표가 바로 추적성 (Traceability)[5]입니다. 실제로 프로세스 점검이나 기능 안전(ISO 26262), 사이버 보안(SAE/ISO 21434) 심사에서도 요구사항과 설계 항목 간의 추적성 확보율과 적절성을 집중적으로 점검하곤 하죠. 하지만 추적성은 어디까지나 ‘일관성’을 검토하기 위한 하나의 수단에 불과합니다. 단순히 A문서와 B문서의 링크가 기계적으로 연결되어 있다고 해서 훌륭한 설계라 단정할 수는 없습니다. 엔지니어링 설계에서 진정으로 들여다보아야 할 본질은 단순한 연결 고리(Traceability)가 아니라 , 정보가 논리적 모순 없이 하나로 관통하는 ‘일관성(Consistency)’, 즉 정보의 매끄러운 흐름입니다. 앞서 살펴본 [그림 1]의 ‘System Development Triangle’ 역시 이러한 정보의 일관성을 유지하기 위한 상호 유기적 관계를 도식화한 것입니다.
[5] 추적성 (Traceability): 고객 요구사항부터 설계, 코드, 테스트 결과까지 개발 전 과정이 양방향으로 연결된 상태.
[오해와 진실 – 3] 개발 단계가 깊어질수록 설계 항목 수는 무조건 늘어나야 한다?
진실 : 트리 구조로 펼쳐지는 요구사항의 ‘숫자’에 집착할 필요는 없습니다.
일반적으로 개발과정의 전개에 따라 상위 설계보다 하위 설계의 항목 수나 분량이 많아져야 한다고 생각합니다. 프로세스 영역의 형식적인 구분을 따르다 보면 상당히 타당한 이야기처럼 들릴 수 있습니다.
하지만 실무에서는 하나의 최적화된 시스템 요소(System Element)가 다양한 목적을 가진 복수의 상위 요구사항을 단번에 해결하기도 합니다. 뛰어난 시스템 엔지니어링은 통합 설계를 통해 시스템 요소를 간결하게 정리함으로써 원가 절감 및 복잡도 저감을 달성할 수도 있습니다.
따라서 수많은 상위 요구사항을 최적화된 시스템 요소에 집약해 할당하고, 이를 다시 다수의 논리적인 고장 시나리오로 세분화하여 분석한 뒤, 발생 가능성이 희박한 항목들을 단계적으로 걸러내는 것이 시스템 분석의 본질적인 흐름입니다. 따라서 피라미드나 트리 구조로 펼쳐지는 요구사항의 ‘개수’ 자체에 집착할 필요는 전혀 없습니다..
3. 시스템 분석과 프레임워크(Framework)의 필요성
시스템 분석은 고장 모드 및 영향 분석(FMEA)[6]와 같은 분석 도구를 활용하여 고장 발생 가능성과 그 영향을 파악해 설계를 보완하는 활동입니다.
여기에서 중요한 점은 분석 “도구”를 활용한다는 것입니다. 따라서 FMEA와 같은 것을 기술이라고 표현하기 보다는 도구 또는 방법론이라고 부릅니다. 하지만 필자가 강조하고자 하는 것은 이 방법론을 다루는 데에도 공학적 역량인 “엔지니어링 스킬(Engineering Skil)”이 필요하며, 그것 역시 명백한 ‘기술’이라는 점입니다.
만약 이를 단순한 “Know-how”로만 치부한다면, 경험의 축적만이 강조될 것이고, 분석은 경험 많은 소수의 베테랑 엔지니어만 수행할 수 있는 폐쇄적인 업무로 남을 것입니다. 하지만 실무 현장에서는 경험이 부족한 엔지니어들도 FMEA와 같은 도구를 활용해 설계의 안전성을 검토해야 하는 것이 현실입니다.
이에 따라 개인의 경험에만 의존하지 않고, 명확한 가이드라인을 따라 구조화된 분석 방법을 적용할 수 있는 표준화된 틀, 즉 ‘시스템 분석 프레임워크(Framework)’가 반드시 필요합니다.
[6] FMEA (Failure Mode and Effects Analysis, 고장 모드 및 영향 분석): 시스템 구성 부품의 잠재 결함을 도출하고 상위 시스템에 미치는 영향을 상향식으로 분석해 설계를 예방하는 품질 기법.
[1편을 마치며]
이번 1편에서는 시스템 엔지니어로서의 설계 철학과 시스템 설계 3요소를 둘러싼 현업의 오해와 진실을 살펴보았습니다. 그렇다면 이 프레임워크를 실전에서 구현하기 위해 어떤 현대적 엔지니어링 도구가 사용되며, FMEA∙FTA∙DFA는 어떻게 상호 보완되며 무결점 설계를 완성할까요? 이어지는 2편에서는 HL만도의 구체적인 시스템 분석 실행 체계와 실전 도구 활용 전략을 본격적으로 다뤄봅니다.
