FSG Korea

기능안전과 CI/CD - 빌드 환경 자체가 곧 안전성 입증 자료다

FSG-IAR 관리자 2026-06-22 조회수 12

기능안전과 CI/CD - 빌드 환경 자체가 곧 안전성 입증 자료다

작성 : IAR SYSTEM KOREA 기술부

빌드 환경을 안정적으로 재현할 수 없다면, 규제 준수 역시 재현할 수 없다. 의료기기, 자동차 제어 시스템, 산업 자동화 장비 등 어떤 안전 필수 시스템을 개발하든 인증 기준은 개발 일정이나 예산 상황에 따라 달라지지 않는다. 다만 인증 과정에서 발생하는 부담을 얼마나 줄일 수 있는지는 개발 조직이 선택할 수 있다.

많은 임베디드 개발팀이 경험하는 병목은 인증 절차 자체가 아니다. 실제 문제는 그 아래에 쌓이는 개발 환경의 불안정성이다. 취약한 개발 환경, 일관되지 않은 툴체인, 시간이 지나면 재현되지 않는 빌드 결과가 대표적이다. 이러한 문제는 단순히 개발 속도를 늦추는 수준에 그치지 않는다. 기능안전이 요구되는 시스템에서는 안전성 입증 자체를 흔드는 요소가 된다.

컨테이너 기반 워크플로우는 이 문제를 근본적으로 해결한다. 규제 준수 절차를 대체하는 것이 아니라, 이를 구조적으로 더 쉽게 달성하고 유지하도록 만들어준다.

개발 환경 불안정성이 초래하는 숨은 비용

대부분의 임베디드 프로젝트는 초기에는 안정적으로 시작한다. 팀 규모가 작고 툴체인도 최신 상태이며, 빌드 결과 역시 예측 가능하다. 그러나 프로젝트가 확장되면 균열이 나타난다.

개발자마다 서로 다른 컴파일러 버전을 사용하게 되고, SDK 설정은 각자의 PC에서 조금씩 달라진다. 한 지역의 개발자가 재현하지 못하는 빌드 오류가 다른 지역에서는 반복적으로 발생하기도 한다. 신규 인력은 첫 코드를 작성하기 전에 개발 환경을 구성하는 데 며칠씩 소비한다.

일반 소프트웨어 프로젝트에서는 생산성 문제로 끝날 수 있다. 하지만 기능안전이 요구되는 프로젝트에서는 훨씬 심각하다.

인증 기관은 결정론적 동작을 요구한다. 동일한 입력이 동일한 출력을 안정적으로 생성해야 하며, 제품 수명주기 전체에 걸쳐 그 특성이 유지되어야 한다. 빌드 환경이 안정적이지 않다면 결과도 결정론적일 수 없다. 결과가 결정론적이지 않다면 안전성 입증 자료 역시 신뢰를 잃게 된다.

환경 드리프트(environmental drift)는 이론적 위험이 아니다. 실제로 임베디드 개발 현장에서 가장 흔하면서도 잘 드러나지 않는 인증 문제의 원인 중 하나다.

컨테이너가 실제로 바꾸는 것

컨테이너는 환경 문제를 ‘관리’하는 것이 아니라 사실상 제거한다. 각 개발 PC마다 툴체인을 수동으로 설치하는 대신, 컴파일러, 빌드 도구, 정적 분석 도구, 테스트 인프라까지 모든 요소를 하나의 이미지로 정의한다.

그 결과 모든 개발자, CI 파이프라인, 빌드 서버가 동일한 환경을 사용한다.
“내 PC에서는 되는데”라는 문제가 사라지고, 어떤 버전의 도구가 어떤 결과를 만들었는지도 명확해 진다.

이 일관성이야말로 기능안전 워크플로우의 기반이다.

CI/CD와 결합하면 효과는 더욱 커진다. 피드백 주기가 빨라지고, 통합 문제를 조기에 발견할 수 있으며, 분산된 팀 간 협업도 안정적이 된다. 예를 들어 Linux 기반 컨테이너에서 실행되는 IAR Build Tools는 일반 로컬 환경 대비 최대 2배 빠른 빌드 성능을 제공하며, 정적 분석은 최대 3.5배 빠르게 수행할 수 있다.

그러나 기능안전 관점에서 가장 중요한 장점은 속도가 아니다.
핵심은 감사 가능성(auditability)이다.

[그림 1] DevOps 구성

기능안전과 컨테이너는 자연스럽게 맞물린다

많은 개발 조직은 최신 DevOps 방식과 기능안전 규격이 상충한다고 생각한다. 이해할 만한 인식이다. ISO 26262, IEC 61508, IEC 62304 같은 표준은 컨테이너나 CI/CD 개념이 보편화되기 이전에 만들어졌다.

하지만 실제로는 다르다. 요구사항은 변하지 않았다. 변한 것은 이를 충족하는 방식이다. 적절히 구성된 컨테이너 환경은 기존 수동 환경보다 오히려 더 높은 수준으로 요구사항을 만족시킨다.

인증이 요구하는 핵심 요소를 보면 분명하다.

결정론적 빌드

동일한 입력을 넣으면 언제 어디서 실행하더라도 동일한 결과가 나와야 한다. 컨테이너 기반 파이프라인은 이를 보장한다.

추적성

개발 환경 자체가 버전 관리 대상이 된다. Dockerfile, 툴체인 이미지, 분석 설정까지 코드와 함께 저장된다. 모든 빌드는 특정 환경과 연결되어 감사 추적이 가능하다.

장기 재현성

안전성은 제품 출시로 끝나지 않는다. 자동차, 의료, 산업 시스템은 보통 10~20년 운영된다. 출시 5년 후 수정이 필요하면, 당시 인증에 사용한 동일한 환경을 그대로 재구성할 수 있어야 한다.

수동 툴체인으로는 사실상 어렵다. 재현 가능한 빌드는 단순 편의 기능이 아니라, 곧 안전성 증빙 자료다.

장기 유지보수 단계에서 가장 큰 차이가 발생한다

많은 팀이 과소평가하는 영역이 장기 유지보수다.

LTS(Long-Term Support) 지원이 없는 툴체인을 사용할 경우 개발 환경 변경은 곧 재인증 위험이 된다. 컴파일러를 업데이트하면 검증을 다시 해야 할 수 있고, 정적 분석 설정이 달라지면 기존 인증 자료가 무효화될 수도 있다.

이 비용은 프로젝트 기간 내내 누적되지만 초기에는 잘 보이지 않는다.

반면 TÜV 인증을 받은 LTS 툴체인을 컨테이너 안에서 운영하면 제품 수명주기 전체에 걸쳐 안정성이 유지된다. 업데이트는 통제된 방식으로 관리되며, CI/CD 파이프라인도 동일한 상태를 유지한다. 결과적으로 인증 비용과 운영 리스크가 크게 줄어든다.

예를 들어 출시 후 5년이 지난 제품에 유지보수 패치를 적용해야 한다고 가정하자. 기존 환경이라면 당시 빌드 서버는 폐기되었고, 운영체제는 지원 종료되었으며, 컴파일러도 구할 수 없을 가능성이 높다. 인증 환경을 재구성하는 데 수주가 걸릴 수 있다.

하지만 버전 관리된 컨테이너 이미지가 소스와 함께 보관되어 있다면, 어느 엔지니어라도 즉시 동일한 환경을 실행해 원본 바이너리를 재생성할 수 있다.

이것이 바로 감사 추적성이다.

하드웨어 접근도 가능하다

임베디드 개발에서 반드시 제기되는 질문이 있다.
“컨테이너에서 실제 타깃 보드와 연결할 수 있는가?”

가능하다.

USB/JTAG 패스스루 방식 또는 TCP/IP 기반 디버그 서버를 활용할 수 있다. 예를 들어 I-jet, J-Link, OpenOCD 등이 대표적이다. Windows Subsystem for Linux 환경에서는 usbipd를 통해 USB 장치를 컨테이너 내부에서 사용할 수도 있다.