임베디드와 펌웨어 쪽에서 일하면 Git 변경 사항을 확인하고 요구사항을 다시 읽은 뒤, 코드를 빌드해서 보드에 올리는 일이 반복된다.
요즘은 AI도 옆에 켜둔다. 레지스터 설정이나 오래된 코드를 보여주면 가능한 원인을 빠르게 정리해준다. 하지만 맞는지는 결국 보드와 로그로 확인해야 한다.
펌웨어에서는 빌드 성공이 업무의 끝이 아니라 시험의 시작일 때가 많다. 장치는 한 시간 동안 잘 돌다가 특정 온도나 통신 순서에서 멈출 수 있다. 코드가 멀쩡해 보여도 타이밍 가정 하나가 제품을 망가뜨리기도 한다.
이럴 때 C에서 배운 질문이 나온다. 데이터는 어디에 있고 누가 만들었으며 언제까지 유효한가. 누가 바꿀 수 있고 다 쓴 메모리는 누가 돌려주는가.
C는 직접 제어, 작은 실행 환경, 예측 가능한 비용 때문에 여전히 현장에 남아 있다. ST, NXP, Nordic, Texas Instruments, Infineon의 개발 도구를 열면 C 드라이버와 예제, 시작 코드가 자연스럽게 나온다.
그렇다고 C가 본래 안전한 언어라는 뜻은 아니다. 안전이 중요한 팀은 MISRA C, 정적 분석, 코드 리뷰와 광범위한 시험으로 알려진 실패 방식을 통제한다.
Python은 도구와 자동화를 빠르게 만드는 데 좋고, C나 C++는 측정으로 확인된 무거운 처리나 하드웨어에 가까운 계층에 배치할 수 있다. 좋은 엔지니어링은 하나의 언어로 모든 것을 만드는 일이 아니다.
C로 모든 것을 만들 필요는 없다. 다만 보드가 멈추고 도구가 느려졌을 때 원인을 더 아래에서 찾고 싶다면, C는 아직 배울 이유가 충분한 언어다.
댓글을 불러오고 있습니다.