휴학과 첫 출근

2025년 9월, 대학교 2학년 1학기를 마친 뒤 한국전자기술연구원(KETI)에서 4개월간 근무했다. 휴학 후 입대 전까지의 짧은 기간이었지만, 그 어느 때보다 밀도 있게 실무를 경험할 수 있었던 시간이었다.

한국전자기술연구원은 산업통상자원부 산하 전문생산기술연구소로, 중소·중견기업을 대신해 핵심 기술을 선행 개발하는 공공 연구기관이다.

평소 차량 전장 시스템에 막연한 관심이 있었는데, 현대자동차 Pleos 25 행사를 다녀온 뒤로 이 분야에서 직접 무언가를 만들어보고 싶다는 생각이 들었다. 그러던 중 동아리 활동으로 연이 닿은 교수님께서 KETI 모빌리티플랫폼연구센터의 채용 공고를 소개해주셨다. '임베디드 기반 지능형 차량통신 응용 S/W 개발 및 UX/UI 플랫폼 개발 지원' 직무였다.

지금까지 프론트엔드 개발만 해온 나에게, 이 직무는 관심은 있었지만 직접 다뤄본 적 없던 차량 전장이라는 도메인에 발을 들일 수 있는 좋은 기회였다. 차량 소프트웨어 분야는 앞으로도 꾸준히 성장할 것이라 보았고, 이 과정에서 쌓는 도메인 지식은 어떤 방향으로 나아가든 든든한 자산이 되리라 생각했다. 무엇보다 학부 재학 중에 연구기관에서 실무를 경험할 수 있는 기회는 흔치 않다고 판단해, 군 입대를 미루고 과감히 지원하게 되었다.

자소서를 쓰며 가장 크게 고민했던 부분은 '2학년 학부생인 내가 이 직무를 해낼 수 있는 사람으로 보일까'였다. 실무 경험은 없었지만, 동아리와 개인 프로젝트에서 낯선 코드베이스에 적응하고 제약 속에서 문제를 해결해 온 과정을 최대한 담아내고자 했다.

감사하게도 서류와 면접을 통과해 합격 소식을 들을 수 있었다. 그렇게 2025년 가을, 판교 연구소로 출근하며 나의 첫 사회생활이 시작되었다.

나는 인공지능연구본부 모빌리티플랫폼연구센터에 소속되어 '차세대 자율주행 차량통신 기술개발사업'의 일환으로 진행된 다음 두 가지 세부 국책 과제에 참여했다.

• 커넥티드 자율주행을 위한 5G-NR-V2X 성능 검증

• 서비스 QoS 보장 통신자원 중앙관리형 초고속/초고신뢰 V2X 통신모듈 기술개발

해당 사업은 과학기술정보통신부 산하 정보통신기획평가원(IITP)이 관리하고, KETI 모빌리티플랫폼연구센터가 총괄하는 총 163억 원 규모의 대형 국가 연구개발사업이다. KETI를 중심으로 ETRI, KT, LG전자 등 산·학·연 17개 기관이 함께 참여했다.

과제의 핵심 목표는 5G-NR-V2X 기술의 완성도를 끌어올려 커넥티드 자율주행 산업의 기반을 마련하는 것이었다. 구체적으로는 레벨 4 이상의 완전자율주행을 지원하는 초고속(150Mbps 이상)·초저지연(3ms 이하)·고신뢰(PRR 99.99% 이상) 차량통신 기술을 실도로 환경에서 검증하고, OBU(차량단말기)와 RSU(노변기지국) 시제품을 기반으로 다양한 응용 서비스를 실증하는 것을 목표로 했다.

V2X 모니터링 시스템 개발

2025.09 – 2025.11

기술 스택: Vanilla JS, WebGL (Three.js), WebSocket

처음 맡은 업무는 V2X 통신 시스템을 실시간으로 모니터링하는 관제 시스템을 개발하는 것이었다.

저성능 기기에서도 원활히 동작하도록 별도의 프레임워크 없이 Vanilla JS로 구현 방향을 잡고 Figma로 UI를 기획했다.

UI 구상을 마치고 본격적인 개발을 시작하면서, 장비 분류 로직을 구현하는 단계에서 예상치 못한 어려움을 마주했다. 리드 차량, 팔로우 차량, TX OBU, RX OBU 등 장비의 분류 체계가 복잡했고, 레거시 구조로 인해 레이블과 실제 데이터가 어긋나는 문제도 있었다. 일주일 정도 시간을 들여 기존 구조를 분석하고 직접 구조도를 그려가며 시스템을 이해해 나갔다. 그렇게 구조를 먼저 명확히 파악한 덕분에, 결과적으로 안정적인 장비 분류 로직을 구현할 수 있었다.

리드 차량의 내부 데이터 및 V2X 통신 데이터를 실시간으로, 그리고 직관적으로 확인해야 하는 요구사항이 있었다. 단순히 데이터를 나열하는 것을 넘어, 실제 주행 테스트나 시연 상황에서 연구원들이 편하게 사용할 수 있는 환경을 만드는 데 초점을 맞추었다.

플래투닝 시연을 위한 이 대시보드(HERMES)는 한 화면에 지도와 수많은 데이터를 효율적으로 배치하는 것이 관건이었다. 이를 위해 화면 좌측과 우측에 여러 개의 패널을 동시에 띄울 수 있는 유연한 레이아웃을 구현했다. 각 패널은 자유롭게 크기를 조절하거나 닫을 수 있고, 헤더를 드래그해 순서를 바꿀 수도 있다. 활성화된 패널이 차지하는 공간에 맞춰 중앙의 지도 영역이 자동으로 축소·조정되어 지도가 가려지지 않도록 했다. 좌측 사이드바에서는 열려 있는 패널의 아이콘이 하이라이트 처리되며, 클릭 한 번으로 해당 패널을 즉시 켜거나 끌 수 있다.

가장 중심이 되는 중앙 지도는 Mapbox와 Three.js를 활용해 구현했다. 실제 차량 형태의 3D 모델이 지도 위를 실시간으로 주행하도록 만들었는데, 이 과정에서 외부에서 구한 3D 모델들의 규격이 제각각이라 이를 맞추려고 처음으로 블렌더를 다뤄보기도 했다.

지도를 둘러싼 패널에서는 차량들의 상태를 직관적으로 보여주는 데 집중했다. 좌측 패널에는 속도, 방향 지시등, 조향각 등 리드 차량의 주행 정보를 시각화했고, 우측 패널에는 주변 차량과의 통신 상태를 실시간 그래프로 표출했다.

특히 우측 디바이스 패널에는 데이터 확인을 돕는 토글 기능을 더했다. 패널 상단의 'Auto track', 'Visible path', 'Comm line' 토글로 지도 상에서 특정 차량을 추적하거나 이동 궤적과 통신 상태 선의 표시 여부를 그때그때 제어할 수 있게 했다. 또한 정보 표의 펼쳐보기 버튼을 누르면 숨겨져 있던 세부 그래프가 활성화되어, 평소에는 핵심 수치만 보다가 필요할 때만 상세 분석을 할 수 있도록 한정된 화면 공간을 효율적으로 활용했다.

여기에 더해, 웹소켓으로 수신되는 JSON 포맷의 원본 데이터를 실시간 테이블 형태로 띄워 백엔드와의 데이터 정합성을 바로 확인할 수 있는 검증 패널도 마련했다.

대량의 데이터를 실시간으로 다루면서 발생한 성능 이슈는 다음 4가지 방법으로 최적화했다.

• 유효성 검사: WebSocket으로 수신되는 데이터 중 손상된 패킷을 필터링하는 파서를 구현했다.

• 통신 품질 시각화: 초기 시퀀스 번호 기준으로 누적 수신 패킷을 추적해 실시간 PRR을 계산하고, 차량 간 연결선 색상으로 상태를 표현했다.

• 메모리 최적화: 무한정 쌓이는 궤적 데이터로 인한 메모리 누수를 방지하기 위해, 좌표가 0.5m 이상 이동할 때만 기록하고 배열의 최대 길이를 제한했다.

• 렌더링 파이프라인 분리: 대량의 데이터가 실시간으로 DOM에 렌더링되면서 브라우저 프리징 현상이 발생했다. 차량 위치는 실시간으로 업데이트하되 측면 패널은 500ms 간격으로만 렌더링하도록 주기를 분리하여 병목을 해결했다.

과제 최종 시연

수많은 최적화 끝에 완성된 이 시스템은 11월 대구 지능형자동차부품진흥원(KIAPI) 주행시험장에서 열린 '차세대 자율주행 차량통신 기술개발사업 성과 시연회'에 성공적으로 투입되었다.

시연회 현장에서는 군집 주행(Platooning), 센서 공유(Sensor Sharing), 원격 주행 등 각 기관이 개발한 다양한 5G-NR-V2X 기반 응용 서비스가 실증되었다. 이 중 내가 개발한 대시보드는 KETI와 KIAPI가 합동으로 선보인 군집 주행(Platooning) 시연 과정에서 실시간 통신 상태와 차량 궤적을 모니터링하는 핵심 관제 화면으로 활용되었다.

행사 이후 보도된 언론 기사 사진에 내가 관제 화면이 그대로 실린 것을 보았을 때, 국가 R&D 과제의 실증 현장에 실질적인 기여를 할 수 있었다는 사실에 뜻깊은 보람을 느낄 수 있었다.

관련 기사: https://www.irobotnews.com/news/articleView.html?idxno=43579

Fleet Dashboard 개발 & 동시 접속 테스트

시연 이후, 30대 이상의 차량이 동시 접속하는 대규모 테스트를 지원하기 위해 Fleet Dashboard를 추가로 개발했다. 다수 단말 환경에서는 데이터가 방대해지는 만큼 정보의 필터링과 분석에 초점을 맞췄다.

동시 접속 테스트에서는 차량 한 대에 OBU가 여러 개 달리는 경우가 많아 대시보드에 장비 목록이 복잡해지는 문제가 있었다. 이를 해결하기 위해 수십 대의 장치를 그룹별로 묶어서 관리하는 기능을 만들었다. 특정 그룹을 선택하면 해당 디바이스들의 정보만 필터링되어 나타나며, 개별 디바이스를 클릭하면 PRR, Latency, RSSI 변화 추이를 상세 그래프로 확인할 수 있다.

데이터를 보는 방식도 유연하게 만들었다. 패널 크기를 조절할 수 있었고, 그리드 카드 형태와 목록 보기 사이에서 보기 방식을 전환할 수 있었다.

제일 반응이 좋았던 건 데이터 자동 수집 기능이었다. 원래는 실험 중 사람이 대시보드를 지켜보며 수동으로 데이터를 기록해야 했는데, 타이머를 설정해 지정된 시간 동안 데이터를 자동으로 수집하고 CSV 파일로 다운로드해주는 기능을 만들었다. 이 기능 덕분에 수작업으로 발생하던 데이터 누락이 사라졌고, 현장에서 실험 후 결과 데이터를 취합하는 데 걸리는 시간과 리소스가 눈에 띄게 줄어들었다.

원격 주행 시스템 개발

2025.11 – 2025.12

기술 스택: C, Linux 커널 드라이버, CAN 통신

지금까지가 데이터를 보여주는 역할이었다면, 다음 업무는 레이싱 휠을 이용해 실제 차량을 제어하는 원격 주행 파이프라인 구축이었다. 단순히 조이스틱 값을 읽는 것을 넘어, 하드웨어 장치 제어부터 CAN 네트워크 통신까지 전체 스택을 C 언어로 구현해야 했다.

​가장 먼저 부딪힌 장벽은 커널 드라이버였다. G923 스티어링 휠을 Jetson Orin과 연결 후, 포스 피드백을 ROS2 라이브러리로 제어하려 했는데, force feedback not supported 에러가 떴다. 커널 레벨에서 지원이 안 된다는 뜻이었다.

구글링 끝에 new-lg4ff라는 오픈소스 드라이버를 찾았다. DKMS로 빌드를 시도했는데 실패했다. Tegra용 커널 헤더를 설치하고 재시도해도 실패했다. 결국 드라이버 버전을 확인하고, 빌드 설정을 고치고, 기존 logitech 드라이버와 이름이 충돌한다는 걸 발견해 이름을 바꿔 빌드하고 나서야 마침내 성공했다. 인터넷에 명확한 답이 없어 에러 메시지를 따라가며 원인을 하나씩 좁혀나가야 했다. 프론트엔드 생태계와는 전혀 다른 커널 레벨의 낯선 환경이었지만, 문제를 하나씩 해결해 나가며 결국 방법을 찾아낸 것이 뿌듯했다.

하드웨어를 커널 레벨에서 정상적으로 인식시킨 뒤에는, 서드 파티 애플리케이션인 Oversteer를 사용해서 하드웨어의 스티어링 각도 제한과 포스 피드백 모터가 제대로 동작하는지 검증했다.

이후 해당 검증을 바탕으로 프로젝트의 C 코드에 하드웨어 제어 로직을 직접 통합했다. Linux 환경에서 Non-blocking 방식으로 조이스틱 데이터를 읽어왔고, 장치 파일에 커널 ioctl 명령을 호출해 모터를 제어했다. 이 과정을 하나로 묶어 팀 내 첫 번째 코드 리뷰로 발표했다.

하드웨어가 인식된 후, 이 입력을 차량의 CAN 메시지로 변환하는 파이프라인을 설계했다. 프론트엔드 환경에만 익숙했던 나에게 하드웨어에 닿는 HAL, 미들웨어, 애플리케이션으로 나뉘는 3계층 아키텍처는 무척 생소했다. 책임 연구원님께 조언을 구하고 일주일 넘게 기존 코드를 뜯어보며 전체적인 구조를 이해하려 노력했다.

​그 결과, 조이스틱 입력과 CAN 송수신을 독립된 모듈로 분리하여 유기적인 파이프라인을 구축할 수 있었다. 애플리케이션 계층에서는 제어를 담당하는 Control Task와 피드백을 읽어오는 Monitor Task를 병렬 스레드로 분리해 병목을 막았다. 이 스레드들이 미들웨어 계층의 Joystick Driver와 CAN Driver를 통해 데이터를 주고받으며, 최종적으로는 각 하드웨어 장치의 HAL을 호출하도록 아키텍처를 완성했다.

파이프라인의 뼈대를 완성한 후, 이 통로를 오가는 데이터를 차량이 온전히 이해할 수 있도록 가공하는 작업에 집중했다. 먼저 조이스틱에서 들어오는 Raw 값을 차량의 실제 조향각에 맞춰 정규화하고 스케일링했다. 이렇게 변환된 물리값을 다시 차량용 DBC 스펙에 맞춘 16진수 Little-endian 구조로 인코딩하여 제어용 CAN 메시지 바이트 배열에 삽입했다. 제어 명령을 전송하는 동시에 차량 ECU로부터 넘어오는 피드백 메시지를 수신하여 모니터링하는 양방향 루프를 완성했다.

이 과정에서 멀티스레딩 환경 최적화와 트러블슈팅도 진행했다.

• 입력 지연 최적화: 조이스틱 조작 시 차량 반응이 100~200ms 지연되는 문제가 발생했다. 이벤트를 한 번에 하나씩만 읽어 버퍼에 오래된 값이 쌓이는 것이 원인이었다. while 루프를 통해 버퍼를 한 번에 비우고 가장 최신 값만 적용하도록 수정하여 지연을 해결했다.

• 동기화 및 덮어쓰기 방지: 차량 연결이 간헐적으로 끊기는 문제를 추적한 결과, TX Task와 Control Task가 동일한 CAN 구조체에 동시 접근하며 데이터가 오염되는 현상을 확인했다. 구조체를 분리하고 전용 Mutex를 적용하여 안정화했다.

• 통신 주기 엄수: CAN 버스 select() 대기 타임아웃을 10ms에서 1ms로 단축시켜, 병목 상황에서도 10ms(100Hz) 제어 주기를 엄격하게 방어했다.

수많은 디버깅 끝에 내가 짠 코드로 실제 차량의 스티어링 휠이 돌아가는 걸 확인했을 때는 신기했다. 이 내용을 바탕으로 두 번째 코드 리뷰를 발표했다. 이후 페달 값 연동을 추가하여 원격 가감속 제어 로직까지 완성했다.

로컬 연동 테스트가 성공적으로 마무리된 후, 이 파이프라인을 쪼개어 UDP 네트워크 기반으로 확장했다. 가상 CAN 네트워크 브릿지를 구축해, 원격지 스테이션에서 전송한 조이스틱 명령을 외부 네트워크를 거쳐 차량의 실제 CAN 버스로 보내는 진짜 원격 주행 아키텍처를 완성했다.

카메라 영상 스트리밍을 결합한 웹 GUI도 별도로 구축했다. 6분할 다중 카메라 뷰와 함께 현재 조향각에 따른 예상 경로 3D 궤적 시각화 기능을 넣어 운전자의 편의를 도왔다.

실도로 환경에서 차량을 안정적으로 원격 주행하며 프로젝트를 마무리지었다.

4개월, 19번의 출장, 170번의 커밋

4개월간 약 170개의 커밋을 남겼다. 책상 앞에만 있지 않고 성남 본원, 대구 KIAPI 주행시험장, 충북대 오창 C-track 등 총 19번의 출장을 다니며 현장에서 장비를 테스트했다.

단순히 실무를 겪어보겠다는 생각으로 시작한 4개월이었지만, 결과적으로 국가 R&D 과제의 요구사항을 직접 구현하며 유의미한 결과물을 남길 수 있었다. 프로젝트가 끝난 후 책임연구원님께서 링크드인에 남겨주신 추천서는, 한 명의 엔지니어로서 프로젝트에 실질적인 기여를 했음을 인정받은 것 같아 뜻깊었다.

시야의 확장

학교에서 C언어로 알고리즘 문제를 풀던 것과, 실제 프로젝트에서 Makefile로 여러 파일을 빌드하고 스레드 간 공유 메모리를 관리하며 하드웨어까지 다뤄보는 것은 완전히 다른 세계였다.

이전까지의 나는 프레임워크 안에서 컴포넌트를 만들고 API를 연결하는 것에만 익숙한 좁은 시야의 프론트엔드 개발자였다. 그러나 KETI에서는 리눅스 커널 드라이버를 빌드하고, CAN 메시지의 비트를 조작하며, 멀티스레드 환경의 병목을 풀어내야 했다.

이 과정을 통해 가장 크게 변한 것은 '시스템을 바라보는 눈'이다. 모르는 문제에 직면했을 때 막막함을 느끼기보다 시스템 아키텍처를 떠올리고 어디서부터 디버깅을 시작해야 할지 논리적으로 접근하는 감각을 익혔다. 디바이스 하드웨어부터 미들웨어를 거쳐 사용자 웹 인터페이스까지, 전체 구조의 큰 그림을 이해하고 접근하는 것이 문제 해결의 깊이를 얼마나 다르게 만드는지 몸소 깨달을 수 있었다.

마치며

한국전자기술연구원에서의 근무는 비록 4개월이라는 짧은 기간이었지만, 나침반의 방향을 완전히 바꿔준 큰 변화의 시간이었다. 대학교 학부생 신분으로 실무에 부딪힌다는 것이 두렵기도 했지만, 도메인의 벽을 넘어 끊임없이 학습하고 도전하며 엔지니어로서의 자신감을 얻었다.

프론트엔드와 하드웨어 제어 계층을 수직으로 관통하며 다진 이 귀중한 실무 경험은, 앞으로 내가 단순히 화면만 그리는 것이 아니라 애플리케이션 전반의 견고한 설계를 고민하는 개발자로 성장하는 데 든든한 밑거름이 될 것이다.