현대적인 임베디드 워크플로는 단 하나의 결정으로 이루어지는 것이 아닙니다. 이는 하나씩, 대개 다음과 같은 순서로 내려지는 일련의 결정들입니다. 벤더의 프로젝트 형식에 얽매이지 않는 빌드 시스템을 선택하십시오. 재현 가능한 환경에서 CI를 가동합니다. 코드가 개발자의 책상을 떠난 후에도 디버깅이 여전히 제대로 작동하는지 확인합니다. 각 결정은 그 자체로 타당합니다. 하지만 이 모든 것을 종합해 보면, 대부분의 팀은 여전히 한 가지가 맞지 않는다는 사실을 발견합니다. 바로 인증된 툴체인 자체, 즉 컴파일러와 디버거가 원래 검증되었던 OS에 묶여 있는 상태라는 점입니다.
이 글은 바로 그 부분에 대해 다룹니다. 스택에서 가장 흥미로운 계층이기 때문이 아니라, 대개 가장 마지막에 변화하는 부분이기 때문이며, 이 부분이 변화하기 전까지는 나머지 워크플로의 현대화가 반쪽짜리에 그치기 때문입니다.
1단계: CI와의 연동을 견뎌내는 빌드 시스템
CMake가 첫 번째 과제를 해결했습니다. CMake는 프로젝트 파일에 얽매이는 문제를 해결하고, 단 하나의 IDE에서만 열 수 있는 도구 전용 형식에 묻혀 있던 대신, 빌드 대상 코드 바로 옆의 버전 관리 시스템 내에 저장되는 빌드 정의로 대체했습니다. 빌드가 이식 가능해지면, 터미널에서 실행되든, 에디터 내에서 실행되든, 아니면 CI 러너 내에서 실행되든 더 이상 중요하지 않게 됩니다. 매번 동일한 구성, 동일한 출력.
대부분의 임베디드 팀은 이미 이러한 전환을 완료했거나, 전환 과정의 상당 부분을 진행 중입니다. 이는 스택 내에서 논란의 여지가 가장 적은 계층입니다. 그 이유는 성과가 즉각적으로 나타나고, 그에 따른 타협점은 거의 없기 때문입니다.
두 번째 계층: 일관성을 유지하는 CI
컨테이너가 두 번째 역할을 수행했습니다. 컴파일러, 빌드 도구, 정적 분석 도구를 한 번만 패키징하면 모든 개발자 머신과 모든 빌드 서버가 동일한 이미지를 가져옵니다. “내 컴퓨터에서는 잘 돌아가는데”라는 말은 사라집니다. 팀 전체에 걸쳐 약간씩 다른 컴파일러 버전이 서서히 쌓이는 일도 없습니다. 안전이 중요한 프로젝트나 규정 준수가 필수인 프로젝트에서 이는 단순한 편의성이 아니라, 감사 시 정당화할 수 있는 빌드와 출시 5년 후 재현조차 불가능한 빌드 사이의 차이를 의미합니다.
이 부분도 대부분 해결되었습니다. 재현 가능한 컨테이너화된 CI는 이제 차별화 요소가 아니라 기본 기대치에 가까워졌습니다.
이미지: 리눅스 기반 CI 파이프라인(빌드, 정적 분석, 단위 테스트, 배포)을 처음부터 끝까지 실행하는 동일한 IAR 툴체인으로, 검증된 아티팩트를 결과물로 보여줍니다.
세 번째 계층: 안전지대에 머무르는 툴체인
스택이 대개 여기서 정체됩니다. 하드웨어를 깊이 이해하는 디버깅, 트레이스 레벨 및 RTOS 인식, ETM 트레이스, 실시간 레지스터 뷰, 실행을 중단하지 않는 라이브 워치 등은 역사적으로 Windows를 고수해야 하는 가장 강력한 근거였습니다. 여기에 ISO 26262, IEC 61508 또는 IEC 62304에 대한 TÜV SÜD 인증 툴체인을 추가하면, 새로운 OS로의 리호스팅은 단순한 재구축을 넘어 규정 준수 절차를 거쳐야 하는 과제가 됩니다. JTAG 및 디버그 프로브 드라이버와 라이선싱 인프라도 역사적으로 윈도우에서 더 성숙해 왔습니다.
이 모든 것은 단순한 관성이 아니었습니다. 이는 구조적이고 타당한 이유들이며, 바로 이 때문에 이 계층이 가장 마지막에 이동한 것입니다. 이곳은 “리눅스용으로 다시 컴파일하기만 하면 된다”는 말이 실제로는 결코 성립하지 않았던 유일한 영역이었기 때문입니다.
툴체인 자체가 크로스 플랫폼으로 전환되면 무엇이 달라질까요?
IAR 플랫폼의 크로스 플랫폼 IDE는 이 마지막 계층을 완성합니다. 이 IDE는 인증된 컴파일러와 디버거를 Windows와 함께 리눅스에 네이티브로 제공하며, Qt 프레임워크를 기반으로 구축되어 UI가 호환성 쉴름이 아닌 각 OS에서 진정한 네이티브로 작동합니다.
-
모든 개발자 워크스테이션과 모든 빌드 서버에서 동일한 인증된 툴체인과 재현 가능한 바이너리 결과를 제공하며, OS를 변경할 때 툴체인 자체를 다시 검증할 필요가 없습니다.
-
기본적으로 CMake 및 CI를 지원하므로, 동일한 프로젝트 구성이 터미널, IDE 내부, CI 내부에서 모두 동일하게 실행됩니다.
-
예전에는 Windows를 고수해야 했던 이유였던 디버그 깊이(추적, RTOS 인식, 라이브 레지스터 뷰)가 이제 리눅스에서도 네이티브로 제공됩니다.
-
컴파일러, 빌드 정의 및 분석 도구를 표준화하십시오. 이는 빌드의 재현 가능성을 결정하며, 도구별 프로젝트 파일이 아닌 버전 관리 시스템에 포함되어야 합니다.
-
CI를 컨테이너화하여 모든 파이프라인 실행 시 데스크톱에서 사용하는 것과 정확히 동일한 이미지를 불러오도록 하십시오. 이를 통해 설정의 “CI 버전”과 “개발자 버전” 간의 차이가 발생하지 않습니다.
-
편집기는 사용자 선호도에 맡깁시다. 한 엔지니어는 심층 추적 세션을 위해 완전한 IDE를 사용하며, 다른 엔지니어는 VS Code를 주로 사용하고, 세 번째 엔지니어는 터미널에서 모든 작업을 스크립트로 처리합니다. 이제 이 세 명 모두 어떤 OS에서든 동일한 바이너리를 생성합니다.
이러한 조합, 인증, 크로스 플랫폼 지원, 추적 깊이 등 모든 요소가 한 번에 온전히 유지된다는 점이 주목할 만한 부분입니다. 많은 도구가 이 세 가지 중 한두 가지만 제공합니다. 두 번째 OS를 추가하면서도 이 세 가지를 모두 유지하는 것이야말로 진정한 엔지니어링 과제이며, 이번 릴리스는 바로 이 문제를 해결하기 위해 개발되었습니다.
이미지: IAR Embedded Workbench에서 진행 중인 RTOS 인식 디버그 세션. 스레드 목록, 세마포어 상태, 실시간 로컬 변수, 디스어셈블리 정보를 보여주며, 변환 계층을 거치지 않고 네이티브로 실행되고 있습니다.
개발자가 아닌 툴체인을 표준화하라
세 계층이 마침내 일치함에 따라, 워크플로우는 이전에는 하나로 묶여 있던 두 가지 결정, 즉 바이너리를 생성하는 과정과 엔지니어가 작업하기를 선호하는 환경을 분리합니다.
툴체인 계층이 확정되면, 운영 체제는 더 이상 타협의 대상이 아닙니다. 리눅스를 선택하든 디버그 깊이를 유지하세요. 윈도우를 선택하든 CI 호환성을 유지하세요. 경량 편집기를 선택하든, 필요할 때 트레이스 액세스 기능을 유지하든 상관없습니다. 이것이 바로 주목할 만한 특징입니다. 하이브리드 팀은 강제적인 마이그레이션을 요구할 필요가 없으며, 엔지니어가 이미 선호하는 선택에 관계없이 더 이상 무언가를 잃지 않게 됩니다.
스택의 현대성은 가장 느린 계층의 수준에 달려 있습니다
현대적인 임베디드 워크플로는 가장 최신 구성 요소로 정의되지 않습니다. 아직 따라잡지 못한 레이어가 바로 그 워크플로를 정의합니다. 많은 팀의 경우, 그 요소는 바로 인증된 툴체인 그 자체였습니다. 스택에서 여전히 개발자들에게 ‘개발에 사용하는 OS’와 ‘나머지 모든 것이 이미 실행되고 있는 OS’ 사이에서 선택을 강요하는 유일한 부분이었죠. 어떤 계층이 여전히 여러분의 워크플로우를 저해하고 있는지 확인해 볼 가치가 있습니다.
다음 단계
실제 적용된 전체 스택을 확인해 보고 싶으신가요? 다음에서 확인해 보세요:
- 웨비나 “개발자를 위해 만들어진 크로스 플랫폼 IDE, 이제 IAR 플랫폼에 탑재: 네이티브 리눅스, 내장 CMake, 최신 C++20”을 시청하여 전체 과정을 시연으로 확인해 보세요. [링크 추후 공지]
- 크로스 플랫폼 IDE 체험판을 신청하여 여러분의 CMake 프로젝트에서 직접 실행해 보세요.
- 당사 전문가와 1:1 데모를 예약하여 귀사 팀의 특정 툴체인, CI 및 규정 준수 설정을 단계별로 확인해 보세요.