이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
세 언어 중 가장 익숙한 건 C++입니다. 학교 임베디드 프로젝트에서 STM32 보드 위에서 C++로 센서 드라이버와 모터 제어 로직을 작성했습니다. 객체를 활용해 센서별 드라이버를 클래스로 분리하니 여러 센서를 붙였을 때 코드 구조가 훨씬 깔끔했습니다. C와 달리 클래스·오버로딩·레퍼런스가 가능해서 모듈화에 유리했습니다. 임베디드 환경에서 동적 메모리 할당(new/delete)은 피하는 게 좋다는 걸 직접 힙 단편화 문제를 겪으면서 배웠습니다. 정적 할당 위주로 코드를 짜는 패턴이 자연스럽게 생겼습니다. C#은 학교 UI 과제에서 일부 써봤지만, 하드웨어 접근이 필요한 작업에서는 C++이 훨씬 직관적이었습니다.
C++로 임베디드 코드를 작성하다가 메모리 해제 누락으로 시스템이 재부팅된 경험이 있습니다. 당시 저는 동적 할당 후 해제 시점을 정확히 관리하지 않았는데, 시스템이 간헐적으로 멈추기 시작했고 원인을 찾는 데 오래 걸렸습니다. 임베디드 환경에서 메모리 관리는 안전망이 없어 더 엄격하게 해야 한다는 걸 그때 배웠습니다. 이후로는 RAII 패턴을 적용하거나 동적 할당을 최소화하는 방식으로 코드 구조를 바꿨습니다.
C++의 강점은 추상화지만 임베디드에서는 그 추상화가 메모리 오버헤드를 숨길 수 있다는 원칙이 생겼습니다. 언어의 편의성과 임베디드의 제약은 항상 트레이드오프 관계라는 걸 경험으로 확인했습니다. RAII 패턴 적용 습관이 메모리 오류를 줄였습니다. C++의 강점과 임베디드의 제약은 항상 트레이드오프 관계라는 원칙이 생겼습니다.
코드 리뷰어 입장에서 C/C++/C# 혼용 프로젝트를 점검해본 경험이 언어 선택 기준을 바꿔줬습니다. 수업에서 코드 리뷰어 역할을 맡아 세 언어가 혼용된 프로젝트를 검토했는데, 언어 경계에서 데이터 형변환 오류가 가장 많이 발생했습니다. 각 언어의 타입 시스템 차이를 모르면 연결 지점에서 버그가 생긴다는 걸 그때 이해했습니다.
언어 간 인터페이스 레이어를 명확히 정의하는 것이 혼용 프로젝트의 핵심이라는 원칙이 생겼습니다. C++을 잘 쓰는 것은 기능을 아는 것이 아니라 언어 경계에서 생기는 리스크를 관리하는 것이라는 걸 그 경험에서 배웠습니다. 그 뒤로 언어 선택 시 인터페이스 설계를 먼저 고려하는 습관이 생겼습니다.
인터페이스 설계 우선 고려 습관이 언어 경계 오류를 줄였습니다. C++을 잘 쓰는 것은 언어 경계에서 생기는 리스크를 관리하는 것이라는 원칙이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신세계아이앤씨 임베디드·펌웨어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.