전체 글(388)
-
문서상 추적성은 완벽한데, 왜 변경 영향 분석은 안될까?
최근 프로젝트에서 요구사항을 변경을 추적하고 관리하는 업무를 수행하고 있는데요. 거기에선 수시로 많은 요구사항 변경들이 공유됩니다. 그런데 어떤 변경은 처음에는 큰 변경이라 생각지 않았지만, 요구사항 관리 시스템에서 해당 항목을 찾아보니 관련 시스템 요구사항과 소프트웨어 요구사항이 연결되어 있었고, 설계와 시험 항목까지 연결되어 있었습니다.그리고 문서상으로는 별다른 문제도 없어 보였습니다.그런데 변경 영향을 확인하기 위해 관련 담당자들이 모이면 상황이 달라집니다. 이 요구사항이 바뀌면 어느 소프트웨어까지 수정해야 하는지, 연결된 인터페이스에도 영향이 있는지, 기존 시험을 다시 수행해야 하는지 하나씩 확인하기 시작했는데 누구도 전체 범위를 명확하게 설명하지 못했습니다. 결국 각 담당자가 자신의 영역으로 돌..
09:13:06 -
시스템 요구사항 개발 절차 - (1) 무엇을 요구사항으로 작성해야 하는가? #1
시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나 인버터, 제동 시스템과 필요한 정보를 주고받는 것들이 대표적입니다. 하지만 실제 개발 초기에는 이러한 내용조차 처음부터 완전한 요구사항의 형태로 주어지지 않습니다. 운전자는 차량이 안전하고 자연스럽게 움직이기를 기대하고, BMS 담당자는 배터리가 허용하는 범위 안에서 VCU가 동작하기를 기대하며, 제동 시스템은 회생제동과 마찰제동 사이의 협조가 중요하고, 기능안전 관점에서는 고장이 발생했을 때 차량이 위험한 상태로 이어지지 않아야 합니다. 생산과 정비에서는 또 다른 요구가 존재합니다. 이러한 내용은 모두 시스템에 ..
2026.08.29 -
LLM+Ontology: 전문가의 지식을 누구나 사용할 수 있게 만들 수 있을까?
요즘 업무에서 LLM을 사용하는 것은 더 이상 특별한 일이 아닙니다. 궁금한 내용을 찾거나 문서를 정리하는 것은 기본이고, 조금 더 적극적으로 활용하면 RAG를 구축해 필요한 정보를 빠르게 검색할 수도 있습니다. 최근에는 바이브 코딩을 이용해 반복적인 업무를 자동화하거나, 데이터를 분석하고 가시화하는 일도 이전보다 훨씬 쉽게 할 수 있게 되었습니다. 물론 모든 결과를 그대로 믿을 수 있는 것은 아닙니다. 그럴듯하지만 사실과 다른 답을 만들어내는 Hallucination은 여전히 신경 써야 할 문제이고, 전문적인 내용일수록 원문이나 근거를 다시 확인하는 과정이 필요합니다. 때로는 LLM이 만들어준 결과를 검토하는 데 적지 않은 시간을 쓰기도 합니다. 그럼에도 LLM이 유용하다는 사실 자체를 부정하기는 어렵..
2026.08.26 -
RXSWIN: SDV 시대에 조직은 차량의 Software State를 설명할 수 있는가?
“그래서 지금 이 차에 들어간 Software가 정확히 뭔가요?” 차량에서 문제가 생기면, 연구소 담당자들이 모여 차량을 확인하고, 제어기에 접속해 Software Version을 확인합니다. 만약 소프트웨어 버전이 4.0.0 이라고 할 때, 이 소프트웨어는 언제 Release되었는지, 무엇이 변경되었는지, 어떤 Calibration과 조합되는지, 이 차량에 설치되어도 되는 Version인지, 어떤 형식승인 상태와 연결되는지, 그리고 생산 당시부터 들어 있었던 것인지 OTA를 통해 변경된 것인지까지 알아야 할 수 있습니다. Software Version은 확인했지만, 정작 알고 싶은 것은 단순히 Software Version보다 훨씬 많은 셈입니다. 특히, SDV 시대에는 Software를 개발하는 능력..
2026.08.24 -
Foot Brake로 이해하는 요구사항 Granularity: “운전자가 브레이크를 밟는다”는 하나의 기능은 어떻게 요구사항으로 구체화될까?
이전 포스팅에서 Requirements Granularity에 대해 이야기한 적이 있습니다. 요구사항 Granularity란 무엇인가?왜 지금 granularity를 다시 말해야 하는가 현장에서 제가 자주 듣는 말은 “요구사항이 너무 추상적이다”라는 말 입니다. 실제로 문서를 펼쳐 보면 “지원해야 한다”, “가능해야 한다”, “보habana4.tistory.com 당시 강조했던 것은 요구사항을 얼마나 자세하게 작성하느냐보다, 서로 다른 추상화 수준의 요구사항을 구분하고 그 관계를 유지하는 것이 중요하다는 점이었습니다. 이번에는 조금 더 구체적인 자동차 사례를 가지고 이 이야기를 이어가 보려고 합니다. 이번 포스팅에서 다루고자 하는 사례는 아주 익숙한 제동 시스템에서의 Foot Brake인데요, 운전자 ..
2026.08.21 -
자율주행차 사고, 책임소재? 소프트웨어 공학 관점에서 바라보기
자율주행차에서 주행 중 사고가 났다고 상상을 해 볼까요? 그런데 사고 당시 사람은 운전을 하지 않았습니다. 물론 자율주행차량이다 보니 당연히 사람이 운전을 하지 않았겠지요. 오직 차량 스스로 주변 환경을 인식하고, 보행자와 다른 차량의 움직임을 판단하고, 스스로 주행 경로를 결정하고 있었습니다. 그렇다면 사고의 책임은 누구에게 있을까요. 차량을 소유한 사람일까요? 자동차를 만든 제조사일까요? 아니면 자율주행 소프트웨어를 개발한 회사일까요?가끔 어떤 사람은 농담조로 “운전한 것이 AI라면 AI가 책임져야 하는 것 아닌가?”라는 말을 하기도 합니다. 실제로 현실에서 사고에 대한 책임 문제는 차량 소유자나 운행자, 자동차 제작사, 부품 및 소프트웨어 공급자 등 사고와 관련된 여러 주체 사이에서 원인과 책임관계..
2026.08.20