내 머리속 지우개

SDV 시대에 피할 수 없는 기술적 부채와의 동행

자동차 산업은 지금, 기계 중심에서 소프트웨어 중심(Software-Defined Vehicle, SDV) 으로의 대전환을 맞이하고 있습니다. 차량의 성능과 기능을 결정짓는 요소가 엔진과 변속기가 아니라 소프트웨어 업데이트(OTA), 인공지능(AI), 네트워크 연결성 등의 디지털 기술이 되는 시대가 도래한 것입니다.  그러나 새로운 기술과 혁신이 도입될 때마다 반드시 따라오는 그림자가 있습니다. 바로 기술적 부채(Technical Debt)입니다. SDV 전환 과정에서 빠른 시장 대응과 개발 속도를 유지하기 위해 단기적인 해결책이 선택되는 경우가 많고, 이는 필연적으로 기술적 부채를 발생시킵니다. 그러나 기술적 부채를 단순히 코드 품질 저하나 개발 속도의 문제로만 본다면, 그 위험성을 간과하는 것입니다...

"모든 기능을 문제없이 동작하게 해 주세요!!" 언뜻 보면 완벽한 요구사항입니다.모든 기능을 구현해야 하고, 구현하는 모든 기능에 문제가 없어야 합니다.이만큼 완벽한 요구사항이 있을까요? ㅎㅎ 안타깝지만, 이게 최근까지도 현실에서 심심찮게 볼 수 있는 농담같은 진담이었습니다.이번 포스팅에서는 요구사항 작성시 발생하는 일관성과 모호성을 예방하기 위한 방안으로Easy Approach to Requirements Syntax (EARS)에 대해 살펴 보고자 합니다. 관련글 보기ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)명확한 요구사항 작성 (모호성 제거) - 시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Req..

한가지 에피소드를 살펴 볼까요?"프로세스가 없어서 그래!"프로젝트를 진행하면서 필요한 업무가 정의되어 있지 않을 때, 흔히들 "프로세스가 없어서 그래!!" 라고들 합니다. 그래서 프로세스를 정의해야 한다고 하면서 절차와 담당자를 지정하고 산출물을 정의한 프로세스 문서들을 많이 만들어 냅니다. 그런 다음 열심히 설명회를 하거나 교육을 진행하며, 실무자에게 프로세스를 준수 할 것을 요청합니다. 그런데 실무에서는 너무 많은 종류의 산출물로 인해 그리고 짧은 개발일정으로 인해 프로세스가 외면 받기 시작합니다. 또한 그렇게 시간이 흘러 조직이 변경되어 프로세스에 지정된 담당자가 존재하지 않거나, 프로세스 개선이란 이름으로 중간중간 누락된 절차들을 만들어 프로세스가 변화됩니다.  이 에피소드에서는 프로세스를 단순히..

Software-Defined Vehicle(SDV)는 차량의 주요 기능을 소프트웨어로 정의하고 제어하는 자동차 개발 패러다임입니다. 또한 SDV를 설명함에 있어 소프트웨어로 정의된 여러 기능들을 하드웨어 개발과는 별개로 빠르게 개발하고 유지보수와 추가 기능 개발이 하드웨어에 종속되지 말아야 한다는 속성, 즉 하드웨어-소프트웨어 디커플링(HW-SW Decoupling)이 중요한 속성으로 강조됩니다.  이번 포스팅에서는 SDV의 핵심 속성 중 하나인 하드웨어-소프트웨어 디커플링에 대해 좀 더 자세히 알아 보겠습니다. 사실 많은 사람들이 디커플링을 소프트웨어와 하드웨어가 완전히 독립적이다 라고 오해하는 경우가 있는데, 이는 디커플링의 정확한 본질을 잘 알지 못하는데서 비롯된 문제라고 생각됩니다. 이렇게 상당..

소프트웨어 개발 조직은 일반적으로 실제 소프트웨어를 개발하고 검증하는 직접 개발 수행 조직(Project Teams)과 소프트웨어 개발을 직접 수행하진 않지만, 이를 지원하거나 관리하는 Umbrella(우산) 조직(Management Teams)으로 나눌 수 있습니다. 이 두 조직은 서로 다른 역할을 수행하면서 협력하며 소프트웨어 개발 완성도를 높이고, 효율성과 품질을 개선할 수 있습니다. 실제로는 더 많은 조직들이 각자의 역할을 가지고 소프트웨어 개발에 기여하고 있겠지만, 이번 포스팅에서는 Umbrella Organization에 대해 좀 더 자세히 살펴 보고자 합니다.관련 글 보기소프트웨어공학: 소프트웨어 유지보수성 측정 - 왜 중요할까?소프트웨어 신뢰성 개선 전략 3가지 (3 Strategies f..

최근 자동차 산업은 전기차(EV), 자율주행차, 커넥티드카, SDV, 차량용 클라우드 서비스 등이 핵심 기술로 자리 잡으며, 자동차는 이제 단순한 이동 수단을 넘어 ‘소프트웨어 중심의 플랫폼’으로 진화하고 있습니다. 이러한 변화로 인해 소프트웨어 엔지니어에 대한 수요는 증가하고 있지만, 역설적으로 고연차 엔지니어들이 설 자리를 잃어가고 있는 현상도 나타나고 있습니다. 이 현상은 기술 변화 속도, 기업의 인력 운영 전략, 그리고 개인의 역량 변화가 복합적으로 맞물리면서 발생하고 있다고 생각됩니다. 관련 글 읽기소프트웨어 엔지니어가 갖춰야 할 핵심 역량 - 소프트웨어 엔지니어는 단순 개발자가 아닙니다.자동차 제어 소프트웨어 개발에서의 나쁜 소프트웨어 엔지니어 특징과 교훈소프트웨어 개발자 생산성에 관하여소프트..

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.  STPA의 단계별 절차STPA: 시스템 안전분석 - (1) 분석 목적 정의STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링STPA: 시스템 ..

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다. STPA의 단계별 절차STPA: 시스템 안전분석 - (1) 분석 목적 정의STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링STPA: 시스템 안..

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다. STPA의 단계별 절차STPA: 시스템 안전분석 - (1) 분석 목적 정의STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링 (현재 글)STPA..

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.STPA의 단계별 절차STPA: 시스템 안전분석 - (1) 분석 목적 정의 (현재 글)STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링STPA:..