전체 글(394)
-
소프트웨어 아키텍처는 코드가 아니라 "사람의 연결망"이다
1. 기술적으로 좋은 아키텍처도 왜 현실에서는 쉽게 망가지는가소프트웨어 아키텍처를 설계할 때 우리는 주로 기술적인 구조에 집중해 왔습니다. 시스템을 적절한 컴포넌트로 분리하고, 각 컴포넌트의 책임을 명확하게 정의하며, 인터페이스를 단순하게 만들고, 결합도를 낮추는 것이 좋은 아키텍처를 만드는 중요한 방법이라고 배워왔습니다. 물론 이러한 원칙은 여전히 중요합니다.그런데 문제는 기술적으로 잘 설계된 구조가 반드시 현실에서도 잘 작동하고, 운영될 수 있는 것은 아니라는 점입니다. 잘 작성된 아키텍처 다이어그램을 보면, 시스템이 깔끔하게 잘 나뉘어져 있고, 각 컴포넌트에는 명확한 책임과 인터페이스가 잘 정의되어 있습니다. 하지만 막상 작은 기능 하나를 변경하려고 하는데에도, 다른 팀의 검토가 필요하고, 인터페이..
2026.09.19 -
Branch 커버리지를 가지고 MC/DC 커버리지를 만족할 수 있다?
얼마 전 해외 협력업체를 방문해 소프트웨어 코드 리뷰를 진행할 기회가 있었습니다. 코드의 구조와 구현 방식을 살펴보고 테스트 결과를 확인하면서 이런저런 이야기를 나누던 중, 자연스럽게 Code Coverage에 대한 이야기가 나왔습니다. 소프트웨어를 개발하다 보면 Statement Coverage나 Branch Coverage를 측정하는 것은 당연한 업무 중 하나입니다. 테스트를 수행한 뒤 어느 코드가 실행되었는지, 각 분기의 True case와 False case가 충분히 수행되었는지를 확인하고, 이를 통해 테스트가 코드의 구조를 얼마나 충실하게 훑었는지를 판단하는 것은 ISO 26262에서도 반드시 수행을 권고하는 활동입니다. 그 중에서도 높은 ASIL을 갖는 제어기의 경우 소프트웨어 검증 시, MC..
2026.09.14 -
복잡한 아키텍처를 단계적으로 설명하는 방법: C4 Model
소프트웨어 아키텍처를 설명하기 위해서는 주로 비지오나 파워포인트를 이용하여 다이어그램을 그린 적이 있습니다. 처음에는 나름 잘 정리했다고 생각했고, 시스템을 구성하는 주요 소프트웨어를 박스로 나누고, 서로 주고받는 인터페이스를 선으로 연결했습니다. 중요한 데이터의 흐름도 표시했고, 필요한 곳에는 어떤 기술을 사용하는지도 적었습니다. 그런데 다양한 보고 라인을 거치면서 누군가는 전체적인 구조가 안 보인다고 이야기 하기도 하고, 어떤 사람은 그림을 보면서 어디까지가 우리가 개발하는 영역이고 어디부터가 외부 시스템인지 잘 모르겠다고 하는 한편, 또 어떤 사람은 특정 기능이 어떤 컴포넌트로 구성되는지를 물었고, 또 다른 사람은 실제로 어떤 ECU에서 실행되는지를 궁금해했습니다. 되돌아 보니, 모든 사람들이 같은..
2026.09.12 -
SDV 시대, 차량 진단 - ODX와 OTX에서 SOVD까지, 무엇이 달라지고 무엇을 준비해야 하는가?
차량 진단을 처음 접했을 때 가장 처음 접했던 단어가 UDS였습니다. 진단기로 특정 ECU에 접속하고, Diagnostic Session을 변경하고, DID를 읽거나 DTC를 확인하고, Routine을 실행하는 식입니다. 그리고 조금 더 살펴보다 보면 Security Access와 ECU Programming까지도 접하게 됩니다. 그래서 "차량 진단 = UDS"와 같이 둘을 같은 개념으로 생각하기도 했습니다. 하지만 실제 차량의 진단 환경을 조금 더 넓게 들여다보면 UDS만으로는 설명되지 않는 부분이 많습니다. 예를 들어 진단기는 ECU가 어떤 DID를 제공하는지 알아야 합니다. 해당 DID의 데이터가 2 Byte인지 4 Byte인지, 물리값으로 변환하기 위해 어떤 Scaling을 적용해야 하는지도 알..
2026.09.06 -
시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #3
이전 포스팅에서 이어집니다. [관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Analy..
2026.09.05 -
시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #2
이전 포스팅에서 이어집니다...[관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Anal..
2026.09.01