소프트웨어 테스팅, 열심히 시험했는데, 같은 일을 두번 해야 한다면? 하실래요?

1. UT를 끝낸 뒤, IT에서 다시 만난 테스트토크 제어 소프트웨어를 개발하는 가상의 프로젝트에서 이야기를 시작해 볼까 합니다. 유닛테스트(Unit Test)를 완료하고, 통합테스트(Integration Test)를 준비하고 있습니다. 그런데 통합테스트 TC(Test Case)를 검토하던 담당자가 하던일을 멈추고 모니터 화면을 뚫어져라 쳐다 봅니다.“이 테스트는 지난번에 이미 수행했습니다.”“그때는 유닛테스트였고, 이번에는 통합테스트입니다.” 두 사람은 기존 테스트 명세와 테스트 수행 로그를 펼쳐 보았지만, TC 식별자는 분명 다릅니다. 하나는 상세설계와 연결된 TC이고, 다른 하나는 아키텍처에 연결된 TC 였습니다. 또한 문서의 제목도 각각 유닛테스트 명세서와 통합테스트 명세서로 구분되어 있습니다. ..

차량 ECU Fuzzing Test(퍼징 테스트), 왜 필요하고 어떻게 활용할까?

1. 자동차 사이버보안 강화와 퍼징 테스트의 필요성차량의 주요 기능을 소프트웨어로 구현하는 범위가 확대되고 있으며, 외부 통신을 통한 서비스 제공과 소프트웨어 업데이트도 자동차의 중요한 기능으로 자리 잡고 있습니다. 이러한 변화는 차량의 기능과 서비스 확장에 새로운 가능성을 제공하는 동시에, 사이버보안 관점에서 고려해야 할 공격 표면(Attack Surface)도 확대하고 있습니다. 과거에는 차량 내부의 제한된 네트워크와 ECU 간 통신을 중심으로 보안 문제를 살펴보았다면, 이제는 차량 외부의 통신 인터페이스, 진단 시스템, 소프트웨어 업데이트 경로, 외부 서비스와의 연계까지 함께 고려해야 합니다. 특히 차량 내부의 여러 ECU가 네트워크로 연결되어 있다는 점에서 하나의 인터페이스에 존재하는 취약점이 다..

1. 기능안전 전문가는 왜 Engineering Decision에서 멀어졌을까?기능안전 업무를 오래 수행하다 보면, 늘 아쉬운 모습 중 하나로 "기능안전 담당자는 HARA, FMEA, FTA, Safety Requirement와 같은 전문적인 활동을 수행하고 ISO 26262에 대해서도 상당한 지식을 가지고 있지만, 실제 시스템의 아키텍처나 설계를 결정하는 자리에서는 상대적으로 한 발 떨어져 있는 경우가 많다"는 점입니다. 실제 회의에서도 이런 모습을 종종 볼 수 있는데요, 개발자는 센서 구성이나 통신 구조, 진단 방식, 제어 로직, degraded mode와 같은 구체적인 설계 대안에 관심을 가지고 논의하는 반면, 기능안전 담당자는 이러한 논의가 어느 정도 진행된 이후 안전 요구사항이 충족되는지 확인하..

“기능안전 심사를 통과하면 기능안전이 달성된 건가요?” 과거 함께 일했던 상사가 제게 던진 질문입니다. 물론 당시 대화의 취지는 기능안전 심사의 중요성을 부정하려는 것이 아니라, 안전 분석을 통해 위험을 식별하고, 이를 통제할 수 있는 적절한 안전 메커니즘을 설계하며, 실제 제품에 구현한 후 검증을 통해 그 효과를 입증해야 비로소 기능안전 달성을 설명할 수 있다는 것이었습니다. 하지만, 그 대화는 이후 제게 또 다른 고민을 남겼습니다. “기능안전 달성 여부를 과연 PASS와 FAIL로 판단할 수 있을까?” 기능안전은 시스템의 기능 이상으로 인한 불합리한 위험을 방지하는 것을 의미합니다. 이러한 안전을 달성했는지 판단하려면 위험 분석의 적절성, 안전 대책의 효과성, 검증 증거의 충분성 등 여러 기술적 근..

1. 기능안전의 중요성은 크게 높아졌다.자동차 개발에서 "기능안전"이라는 단어가 지금처럼 자연스럽게 사용되기 시작한 것은 그리 오래된 일이 아닙니다. 10~20년 전만 하더라도 기능안전은 일부 안전 전문가나 특정 프로젝트에서 주로 다루는 전문 영역에 가까웠습니다. 그러다 보니 자연스럽게 개발자는 자신의 기능을 설계하고 구현하는 일이 중심이었고, 기능안전은 그 과정에서 필요한 경우 "별도로 검토하는 업무"로 인식되는 경우가 많았습니다.그런데 지금은 ISO 26262가 많이 보편화 되었고, 그에 따른 자동차 개발 프로세스도 어느정도 정착되었습니다. 그리고 자연스럽게 시스템 개발 전반에 녹아들어 시스템 개발의 일부 단계에만 머무르지 않습니다. 먼저 자동차 제조사에서는 Concept 단계에서 Hazard를 분석..

1. 위험 가설은 아직 시험 시나리오가 아니다어떤 시스템이 특정 조건에서 위험해질 수 있다는 생각(위험 가설)을 했다고 해서, 곧바로 시험을 시작할 수는 없습니다. 위험 가설은 어디까지나 “이런 상황에서 문제가 발생할 가능성이 있다”는 수준의 문제 제기 수준이므로, 실제 시험에서 필요한 "무엇을 변화시킬 것인지", "어떤 조건을 고정할 것인지", "무엇을 관찰할 것인지", 그리고" 어떤 결과를 위험의 징후로 판단할 것인지"가 더 구체적으로 더 정의되어야 합니다.예를 들어 “AEB가 보행자를 늦게 인식할 수 있다.”라는 위험 가설이 있다고 할 때, 이 문장은 충분히 중요한 안전 문제를 제기하고 있지만, 이 상태로는 시험 시나리오라고 보기 어렵습니다. 보행자를 늦게 인식한다는 현상이 어떤 조건에서 발생하는지..