SOM × 임베디드 —
안전 소프트웨어의 부품표

본편 6화에서 잠깐 언급했다. "SOM은 도메인을 가리지 않는다."

그 문장 앞에서 멈춘 독자가 있을 것이다.

"웹 서비스라면 모르겠는데, 우리는 임베디드 소프트웨어를 개발해요. 화면도 없고, 브라우저도 없고, 사용자가 직접 클릭하는 UI도 없는데 — SOM이 무슨 소용이죠?"

이 번외편은 그 질문에 직접 답하기 위해 썼다. 임베디드·안전 소프트웨어 분야에서 SOM이 어떻게 작동하는지, 그리고 왜 이 분야에서 SOM이 오히려 더 강력할 수 있는지.

임베디드 소프트웨어의 현실 The reality of embedded software

임베디드 소프트웨어는 눈에 보이지 않는 곳에 있다.

자동차 ABS 시스템이 브레이크를 잠그지 않도록 제어하는 ECU. 의료 기기가 심박수를 측정하고 경고를 울리는 펌웨어. 산업 현장의 PLC가 컨베이어 벨트 속도를 조절하는 제어 로직. 항공기 플라이-바이-와이어 시스템이 조종 입력을 해석하는 소프트웨어.

이 소프트웨어들이 실패하면 단순한 버그가 아니다. 사람이 다친다.

그래서 임베디드·안전 소프트웨어는 민간 소프트웨어와 차원이 다른 품질 요구를 받는다. DO-178C(항공), ISO 26262(자동차), IEC 62443(산업 제어), IEC 62304(의료 기기). 이 표준들은 단순히 "테스트를 많이 하라"고 말하지 않는다. 모든 요구사항이 테스트로 연결됐음을 증명하라고 요구한다.

이것이 SOM이 등장하는 지점이다.

안전 표준이 요구하는 것 What safety standards demand

DO-178C를 예로 들자. 항공 소프트웨어에 적용되는 이 표준은 소프트웨어 레벨(DAL A~E)에 따라 검증 요건을 정의한다. 가장 엄격한 DAL A — 소프트웨어 오류가 항공기 추락으로 이어질 수 있는 수준 — 에서는 이런 것을 요구한다.

요구사항 → 코드 → 테스트. 이 세 가지가 완전히 연결된 추적성(Traceability)이 핵심이다.

이것을 지금 임베디드 현장에서는 어떻게 구현하는가. 대부분 엑셀이다. 요구사항 번호, 코드 파일명, 테스트 케이스 번호를 손으로 연결한 RTM 엑셀. 프로젝트가 커질수록 이 엑셀은 누군가의 전담 업무가 된다.

SOM ID가 이 문제를 구조적으로 해결한다.

임베디드에서 Program은 무엇인가 What is a Program in embedded

웹 서비스에서 Program은 '회원가입 화면', '주문 취소 프로세스'였다. 임베디드에서 Program은 무엇인가.

기능 단위다. 사용자가 화면으로 접근하는 것이 아니라, 시스템이 수행하는 하나의 목적 있는 동작.

자동차 ECU 프로젝트 예시:

Module: 제동 시스템
  SOM-0101  ABS 제어 루틴          (제동 시 바퀴 잠금 방지)
  SOM-0102  EBD 하중 분배 제어     (전/후륜 제동력 배분)
  SOM-0103  브레이크 압력 모니터링  (압력 센서 읽기 및 경고)

Module: 엔진 관리
  SOM-0201  연료 분사 타이밍 제어
  SOM-0202  점화 시기 최적화
  SOM-0203  냉각수 온도 관리

Module: 통신
  SOM-0301  CAN 버스 메시지 송신
  SOM-0302  CAN 버스 메시지 수신 및 파싱
  SOM-0303  진단 프로토콜(OBD-II) 처리

각 SOM은 기능 명세 문서의 해당 요구사항 번호와 연결된다. 소스 파일과 연결된다. 테스트 케이스와 연결된다.

화면이 없어도 된다. Program은 "사람이 이해할 수 있는 기능의 단위"이지, "사람이 클릭하는 화면"이 아니기 때문이다.

SOM이 안전 표준 인증을 어떻게 돕는가 How SOM helps safety certification

ISO 26262 인증을 준비하는 팀을 상상해보자.

인증 심사관이 묻는다. "ASIL D 요구사항 REQ-0142가 완전히 검증됐음을 보여주세요."

SOM 없는 팀: RTM 엑셀을 열고, REQ-0142 행을 찾고, 연결된 테스트 케이스 번호를 확인하고, 테스트 결과 파일을 별도로 열고, 커버리지 리포트와 대조한다. 각 문서가 서로 다른 포맷으로 존재한다.

SOM 있는 팀: REQ-0142와 연결된 SOM ID를 연다. 그 SOM에 연결된 기능 명세, 소스 파일, 테스트 케이스, 실행 결과, 커버리지 데이터가 한 화면에 집계된다.

심사관 입장에서 어느 쪽이 신뢰가 가는가.

하드웨어 BOM과 소프트웨어 BOM의 결합 Merging hardware and software BOMs

임베디드에서 SOM이 특별히 강력한 이유가 하나 더 있다.

임베디드 시스템에는 이미 하드웨어 BOM이 존재한다. ECU 보드의 MCU, 센서, 커넥터, 저항. 이것들은 이미 부품 번호로 관리된다.

SOM은 이 하드웨어 BOM의 소프트웨어 짝이다.

하드웨어 BOM:
  HW-2041   압력 센서 (Bosch BMP388)
  HW-2042   CAN 트랜시버 (TI SN65HVD230)

소프트웨어 BOM (SOM):
  SOM-0103  브레이크 압력 모니터링  →  HW-2041 사용
  SOM-0302  CAN 메시지 수신         →  HW-2042 사용

하드웨어 부품이 교체되면 연결된 SOM을 즉시 파악할 수 있다. 해당 SOM의 테스트를 재실행해야 한다는 것도 자동으로 결정된다. 하드웨어 변경의 소프트웨어 영향도가 BOM 연결로 관리된다.

제조업에서 꿈꾸는 완전한 Digital Twin — 물리적 부품과 소프트웨어 기능이 하나의 체계로 연결된 — 이 임베디드에서 가장 완전한 형태로 실현될 수 있다.

남은 과제 The remaining challenges

솔직하게 말하자.

웹 서비스에 SOM을 도입하는 것보다 임베디드에 도입하는 것이 더 어렵다. 몇 가지 이유가 있다.

테스트 환경 복잡성: 하드웨어-인-더-루프(HIL) 테스트, 소프트웨어-인-더-루프(SIL) 테스트를 SOM 실행 체계에 연결하는 것은 웹 Playwright 자동화보다 훨씬 복잡하다.

실시간 제약: Action에 타이밍 속성(응답시간, 인터럽트 우선순위)을 추가하는 것이 SOM 표준 구조에 확장이 필요하다.

레거시 도구: 많은 임베디드 팀이 DOORS, Polarion, PTC Integrity 같은 요구사항 관리 도구를 이미 쓰고 있다. SOM을 이 도구들과 통합하는 브릿지가 필요하다.

이 과제들이 해결됐다고 말하지 않겠다. 다만 이것은 이론의 한계가 아니라 구현의 과제다. 이론은 성립한다. 임베디드에서도 소프트웨어 기능 단위는 식별 가능하고, 요구사항과 테스트는 연결 가능하고, 이력은 추적 가능하다.

이름을 붙일 수 있으면 SOM이 된다 If you can name it, it can be a SOM

이 번외편을 하나의 문장으로 요약하면 이렇다.

'ABS 제어 루틴'에 이름을 붙일 수 있다. '브레이크 압력 모니터링'에 이름을 붙일 수 있다. '연료 분사 타이밍 제어'에 이름을 붙일 수 있다. 이름이 붙으면 ID를 줄 수 있다. ID가 있으면 요구사항과 테스트를 연결할 수 있다. 연결이 되면 추적이 된다. 추적이 되면 품질을 관리할 수 있다.

도메인이 다르면 Program의 생김새가 다를 뿐이다. SOM의 원리는 같다.

공장에서 자동차를 만들든, 항공기를 만들든, 의료기기를 만들든 — BOM이 없이는 품질을 관리할 수 없다. 소프트웨어도 마찬가지다. 웹이든 임베디드든, SOM 없이는 기능 단위의 품질을 온전히 추적할 수 없다.

그것이 SOM이 도메인을 가리지 않는 이유다.

SOM 이론 연재 전편을 읽어주셔서 감사합니다. 질문, 피드백, 적용 사례가 있으시면 언제든 연락 주세요.