*출처 : YASA
전기차 시대가 본격적으로 열리면서,
단순한 부품 제조를 넘어 소프트웨어와 시스템을 함께 설계하는 기업들이 빠르게 성장하고 있습니다.
그중에서도 YASA는 고성능 전기 모터 분야에서 주목받는 기업입니다.
2009년에 설립된 YASA는 자동차뿐 아니라 철도, 항공, 해양까지 확장되는 전동화 흐름 속에서 핵심 기술을 만들어왔습니다.
특히 2019년 페라리의 하이브리드 슈퍼카 SF90 스트라달레에 자사의 전기 모터가 채택되면서 기술력을 입증했습니다.
하지만 기술력과는 별개로, 개발 환경에서는 많은 기업들이 겪는 문제를 그대로 안고 있었습니다.
여러 도구를 조합해 운영되던 개발 환경
코드비머 도입 이전 YASA의 개발 환경은 전형적인 ‘도구 조합형 구조’였습니다.
개발 활동 관리를 위해 엑셀 스프레드시트와 기존 플랫폼들을 함께 사용하고 있었고,
품질 보증에는 MathWorks Polyspace와 Simulink Test 같은 도구를 활용했습니다.
버전 관리는 Git으로 이루어지고 있었습니다.
각 도구는 역할이 분명했지만, 전체 개발 흐름 관점에서는 한계가 있었습니다.
파편화된 도구 환경과 수동 프로세스에 의존하는 구조에서는
추적성을 체계적으로 관리할 수 있는 방법을 만들기가 쉽지 않았습니다.
특히 문제가 되었던 것은 단순한 효율이 아니라
규정 준수와 관련된 부분이었습니다.
애자일과 규정 준수 사이에서의 충돌
YASA는 자동차 OEM과 함께 대규모 프로젝트를 수행하고 있었고,
그 과정에서 ISO 26262와 ASPICE 요구사항을 반드시 충족해야 했습니다.
문제는 이 기준들이 단순한 문서 관리가 아니라
개발 전반의 프로세스를 요구한다는 점입니다.
동시에 YASA의 소프트웨어 팀은
애자일 방식으로 개발을 전환하고 있는 상황이었습니다.
이 과정에서 자연스럽게 충돌이 발생합니다.
반복적이고 자율적인 애자일 환경에서
엄격한 규제 기준을 만족시키는 워크플로를 정의하는 것이 쉽지 않았기 때문입니다.
결국 팀은 다음과 같은 필요를 명확하게 인식하게 됩니다.
- 요구사항을 체계적이고 투명하게 관리할 수 있는 방법
- 개발 수명주기 전반에 걸친 추적성 확보
- 사양과 연결된 테스트 및 검증 결과를 공식적으로 기록할 수 있는 체계
이 세 가지를 동시에 만족할 수 있는 환경이 필요했습니다.
ISO 26262와 ASPICE, 왜 중요한가
<ASPICE 기반 개발 흐름을 나타내는 V-Model 구조>
여기서 등장하는 것이 ISO 26262와 ASPICE입니다.
ISO 26262는 자동차 기능 안전을 위한 국제 표준으로,
시스템이 오류 상황에서도 안전하게 동작하도록 개발 프로세스를 정의합니다.
ASPICE는 Automotive SPICE의 약자로,
소프트웨어 개발 프로세스의 성숙도를 평가하는 기준입니다.
정리하면
ISO 26262는 기능 안전을 중심으로 시스템이 안전하게 동작하도록 요구하고,
ASPICE는 개발 과정이 체계적으로 운영되고 있는지를 평가합니다.
이 두 가지는 단순히 ‘지켜야 하는 규정’이 아니라,
개발 과정의 위험을 줄이고 실제 제품 품질을 확보하기 위해 필요한 기준입니다.
따라서 하나만 충족하는 것으로는 충분하지 않으며 안전성과 개발 프로세스를 함께 관리해야 합니다.
그래서 많은 기업들이 이 부분에서 어려움을 겪습니다.
단순히 문서를 정리하는 것 만으로는 부족하고,
개발 과정 자체가 기준을 만족하도록 운영되어야 하기 때문입니다.
결국 이를 충족하기 위해서는
개발 과정 전체를 기준에 맞게 운영할 수 있는 환경이 필요합니다.
Codebeamer 도입 이후 변화
YASA는 이러한 요구사항을 충족하기 위해
ISO 26262와 ASPICE를 지원할 수 있는 플랫폼으로 코드비머를 선택했습니다.
코드비머는 Git과 연계되어 기존 개발 환경을 유지하면서도,
개발 관리 프로세스를 하나의 기준 안에서 운영할 수 있도록 지원했습니다.
도입 이후 YASA는 ISO 26262 및 ASPICE 요구사항을 충족할 수 있는 기반을 마련하고,
개발 전반에서 추적성을 보다 체계적으로 확보할 수 있게 되었습니다.
특히 변경이 발생했을 때 영향 범위를 빠르게 파악할 수 있게 되면서,
애자일 방식의 개발 과정에서도 규정 준수를 함께 유지할 수 있는 환경이 갖춰졌습니다.
또한 고객과의 협업에서도 요구사항을 보다 원활하게 주고받을 수 있게 되었고,
이러한 변화는 실제 프로젝트 수행 과정에서도 긍정적인 결과로 이어졌습니다.
이 변화에 대해 YASA 내부에서는 다음과 같이 이야기합니다.
"많은 사람들이 느끼는 장점 중 하나는 모든 기능을 하나의 도구에서 사용할 수 있고, 여러 개의 개별 도구를 관리해야 하는 번거로움 없이 다양한 요소들을 쉽게 연결할 수 있다는 점입니다."
“요구사항과 설계 문서가 여러 파일과 네트워크에 흩어져 있는 대신, 활동을 조율하는 데 사용할 수 있는 단일 도구를 갖게 된 것이 매우 큰 도움이 되었습니다."
- 윌.트레하른, YASA 소프트웨어 책임자
마무리
YASA 사례는 복잡한 개발 환경에서 발생하는 문제를 잘 보여줍니다.
여러 도구를 함께 사용하는 구조에서는 개발 자체보다 관리에 더 많은 시간이 소요될 수 있고,
특히 규정 준수가 필요한 환경에서는 그 부담이 더욱 커집니다.
YASA는 이러한 문제를 해결하기 위해
ISO 26262와 ASPICE 요구사항을 충족할 수 있는 기준을 중심으로 개발 환경을 재정비했습니다.
그 결과, 개발 과정 전반을 보다 명확하게 관리하고
규정 준수와 애자일 방식을 동시에 운영할 수 있는 기반을 마련할 수 있었습니다.
※ 본 내용은 PTC 공식 사례를 참고하여 재구성하였습니다.
(출처: https://www.ptc.com/en/case-studies)
(주) 건우솔루션은 자동차 AVN, Cluster, Telematics, ECU 등의 전장 부품 소프트웨어 기술을 바탕으로
ASPICE 서비스, 소프트웨어 개발, 프로세스 및 품질 관리, 기술개발지원 서비스를 제공하고 있습니다.
자세한 서비스와 문의처는 아래를 참고해주세요
ASPICE 관련 서비스 자세히 보기 : https://geonwoo.com/aspice
CONTACT
Email : sales@geonwoo.com
Homepage : https://geonwoo.com
*출처 : YASA
전기차 시대가 본격적으로 열리면서,
단순한 부품 제조를 넘어 소프트웨어와 시스템을 함께 설계하는 기업들이 빠르게 성장하고 있습니다.
그중에서도 YASA는 고성능 전기 모터 분야에서 주목받는 기업입니다.
2009년에 설립된 YASA는 자동차뿐 아니라 철도, 항공, 해양까지 확장되는 전동화 흐름 속에서 핵심 기술을 만들어왔습니다.
특히 2019년 페라리의 하이브리드 슈퍼카 SF90 스트라달레에 자사의 전기 모터가 채택되면서 기술력을 입증했습니다.
하지만 기술력과는 별개로, 개발 환경에서는 많은 기업들이 겪는 문제를 그대로 안고 있었습니다.
여러 도구를 조합해 운영되던 개발 환경
코드비머 도입 이전 YASA의 개발 환경은 전형적인 ‘도구 조합형 구조’였습니다.
개발 활동 관리를 위해 엑셀 스프레드시트와 기존 플랫폼들을 함께 사용하고 있었고,
품질 보증에는 MathWorks Polyspace와 Simulink Test 같은 도구를 활용했습니다.
버전 관리는 Git으로 이루어지고 있었습니다.
각 도구는 역할이 분명했지만, 전체 개발 흐름 관점에서는 한계가 있었습니다.
파편화된 도구 환경과 수동 프로세스에 의존하는 구조에서는
추적성을 체계적으로 관리할 수 있는 방법을 만들기가 쉽지 않았습니다.
특히 문제가 되었던 것은 단순한 효율이 아니라
규정 준수와 관련된 부분이었습니다.
애자일과 규정 준수 사이에서의 충돌
YASA는 자동차 OEM과 함께 대규모 프로젝트를 수행하고 있었고,
그 과정에서 ISO 26262와 ASPICE 요구사항을 반드시 충족해야 했습니다.
문제는 이 기준들이 단순한 문서 관리가 아니라
개발 전반의 프로세스를 요구한다는 점입니다.
동시에 YASA의 소프트웨어 팀은
애자일 방식으로 개발을 전환하고 있는 상황이었습니다.
이 과정에서 자연스럽게 충돌이 발생합니다.
반복적이고 자율적인 애자일 환경에서
엄격한 규제 기준을 만족시키는 워크플로를 정의하는 것이 쉽지 않았기 때문입니다.
결국 팀은 다음과 같은 필요를 명확하게 인식하게 됩니다.
이 세 가지를 동시에 만족할 수 있는 환경이 필요했습니다.
ISO 26262와 ASPICE, 왜 중요한가
<ASPICE 기반 개발 흐름을 나타내는 V-Model 구조>
여기서 등장하는 것이 ISO 26262와 ASPICE입니다.
ISO 26262는 자동차 기능 안전을 위한 국제 표준으로,
시스템이 오류 상황에서도 안전하게 동작하도록 개발 프로세스를 정의합니다.
ASPICE는 Automotive SPICE의 약자로,
소프트웨어 개발 프로세스의 성숙도를 평가하는 기준입니다.
정리하면
ISO 26262는 기능 안전을 중심으로 시스템이 안전하게 동작하도록 요구하고,
ASPICE는 개발 과정이 체계적으로 운영되고 있는지를 평가합니다.
이 두 가지는 단순히 ‘지켜야 하는 규정’이 아니라,
개발 과정의 위험을 줄이고 실제 제품 품질을 확보하기 위해 필요한 기준입니다.
따라서 하나만 충족하는 것으로는 충분하지 않으며 안전성과 개발 프로세스를 함께 관리해야 합니다.
그래서 많은 기업들이 이 부분에서 어려움을 겪습니다.
단순히 문서를 정리하는 것 만으로는 부족하고,
개발 과정 자체가 기준을 만족하도록 운영되어야 하기 때문입니다.
결국 이를 충족하기 위해서는
개발 과정 전체를 기준에 맞게 운영할 수 있는 환경이 필요합니다.
Codebeamer 도입 이후 변화
YASA는 이러한 요구사항을 충족하기 위해
ISO 26262와 ASPICE를 지원할 수 있는 플랫폼으로 코드비머를 선택했습니다.
코드비머는 Git과 연계되어 기존 개발 환경을 유지하면서도,
개발 관리 프로세스를 하나의 기준 안에서 운영할 수 있도록 지원했습니다.
도입 이후 YASA는 ISO 26262 및 ASPICE 요구사항을 충족할 수 있는 기반을 마련하고,
개발 전반에서 추적성을 보다 체계적으로 확보할 수 있게 되었습니다.
특히 변경이 발생했을 때 영향 범위를 빠르게 파악할 수 있게 되면서,
애자일 방식의 개발 과정에서도 규정 준수를 함께 유지할 수 있는 환경이 갖춰졌습니다.
또한 고객과의 협업에서도 요구사항을 보다 원활하게 주고받을 수 있게 되었고,
이러한 변화는 실제 프로젝트 수행 과정에서도 긍정적인 결과로 이어졌습니다.
이 변화에 대해 YASA 내부에서는 다음과 같이 이야기합니다.
마무리
YASA 사례는 복잡한 개발 환경에서 발생하는 문제를 잘 보여줍니다.
여러 도구를 함께 사용하는 구조에서는 개발 자체보다 관리에 더 많은 시간이 소요될 수 있고,
특히 규정 준수가 필요한 환경에서는 그 부담이 더욱 커집니다.
YASA는 이러한 문제를 해결하기 위해
ISO 26262와 ASPICE 요구사항을 충족할 수 있는 기준을 중심으로 개발 환경을 재정비했습니다.
그 결과, 개발 과정 전반을 보다 명확하게 관리하고
규정 준수와 애자일 방식을 동시에 운영할 수 있는 기반을 마련할 수 있었습니다.
※ 본 내용은 PTC 공식 사례를 참고하여 재구성하였습니다.
(출처: https://www.ptc.com/en/case-studies)
(주) 건우솔루션은 자동차 AVN, Cluster, Telematics, ECU 등의 전장 부품 소프트웨어 기술을 바탕으로
ASPICE 서비스, 소프트웨어 개발, 프로세스 및 품질 관리, 기술개발지원 서비스를 제공하고 있습니다.
자세한 서비스와 문의처는 아래를 참고해주세요
ASPICE 관련 서비스 자세히 보기 : https://geonwoo.com/aspice
CONTACT
Email : sales@geonwoo.com
Homepage : https://geonwoo.com