통신 검증 시험의 미래 - 1/2

시작하기 전에

 

"미래는 이미 와 있다. 다만 골고루 퍼져 있지 않을 뿐이다."* 라는 말을 들은 적이 있다. (공감할 수 있는 말이라 생각했다. 언젠가 써 먹어야지 하고 기억하고 있었다. 오늘이 그 언젠가 이다.) 나는 바이브 코딩으로 진단기 만들기 :: hsl's tsmaster 사용기에서 AI가 가져올 수 있는 툴 패러다임 전환에 관해서 내 생각을 요점만 이야기 한 적이 있다.

 

바이브 코딩 등장 이전에 많은 도메인 전문가들은 자기 머리 속에 있는 노-하우에 따라 툴이 제공하는 위젯들을 클릭해 가면서 시험을 수행했다. 이 노-하우를 동료들과 공유하기 위해서 문서를 작성하고 세미나를 했다. 원하는 만큼 지식/경험 공유가 안 되었을 것이다. (그것은 원래 이루기 매우 어려운 일이라고 생각한다.) 그래서 툴 회사에 요청하여 그 노-하우를 툴에 포함시켰다. 지식/경험의 공유 입장에서 효과적이고 효율적인 방법이다. 나는 이 방법을 지지한다. 

 

툴 회사는 돈을 내는 고객에게 툴을 판매한다. 노-하우는 동료뿐 아니라 툴 사용자 모두와 공유된다. 그 전문가는 자신의 오랜 노력으로 쌓은 지식/경험에서 나온 노-하우를 툴 사용자 "모두"와 공유하고 싶었을까? 그는 그랬을 수 있지만, 그의 동료들 중에는 그에 대해서 우려하는 사람들이 있을 것이라 짐작한다. 그들의 우려는 지나친 것일 수도 아닐 수도 있다. 나는 '노-하우 공유 범위 관리'에 관해 복잡한 견해를 갖고 있다. 이 글은 우려하는 관점에서 작성한다.

 

바이브 코딩은 '노-하우 공유 범위' 문제에 해결책이 될 수 있다. 예를 들면 아래 그림과 설명 같이 할 수 있다. 

• 바이브 코딩으로 시험 노-하우를, 예를 들면, 파이썬 스크립트로 작성한다.
• 툴과 스크립트를 동시에 실행한다. (툴과 스크립트는 동시에 인터페이스 하드웨어에 접속할 수 있어야 한다. 그리고 독립적으로 메시지들을 송수신 할 수 있어야 한다.) 
• 툴은 차의 통신을 모니터하고 저장하는 기본 기능에 사용한다.
• 스크립트는 시험 절차에 따라 검증에 필요한 메시지들을 송수신한다. 수신한 메시지들을 처리하고 시각화한다. 

툴과 사용자의 스크립트가 동시에 통신에 접속할 수 있다면, 사용자의 시험 절차 노-하우를 스크립트로 작성하여 시험 자동화로 효율을 높이고, 스크립트 공유 범위 관리로 노-하우 공유 범위를 관리할 수 있다.

 

위와 같이 하면,

• 코드로 노-하우를 공유할 수 있다. 툴에 기능을 추가하여 공유하는 것과 다름없다.
• 시험 자동화를 통해 생산성 향상을 이룰 수 있다.
• 코드 공유 범위를 관리하는 방식으로 노-하우 공유 범위를 관리할 수 있다. 우리가 직접.

나는 "미래는 이미 와 있다. 다만 골고루 퍼져 있지 않을 뿐이다."라는 말로 글을 시작했다. 나는 3주쯤 전(오늘은 2026-09-14 이다.)에 위 방법이 실제로 적용되고 있는 것을 봤다. 이 방법은 아직 골고루 퍼져 있지 않다. 머지 않아 골고루 퍼질 것으로 기대한다. 

 

이 방법에는 부수적인 이득이 있다. 툴에는 기본 기능만 있으면 충분하다. 기본 기능의 툴은 저렴하다. 비용을 아낄 수 있다. 경우에 따라, 비용 절감이 아주 클 가능성이 있어 보인다.

 

이 포스트와 다음 포스트에서 위 방법을 데모한다. 

 

* 검색해 보니 "미래는 이미 와 있다. 다만 골고루 퍼져 있지 않을 뿐이다."는 윌리엄 깁슨 - 나무위키 이라는 SF 소설가가 한 말이다. 그는 널리 사용되고 있는 사이버스페이스 - 나무위키 라는 신조어와 개념을 만들었다고 한다.

개요

• CAN 통신 검증
  • RC (Rolling Counter) & CRC 점검
  • 메시지 전송 주기 흔들림(jitter, 지터) 점검
• CANtegrity-CAN
  • 실행 모습
  • 코드
• 결론

 

CAN 통신 검증

RC & CRC

• CAN 메시지에 RC 신호와 CRC 신호를 넣는 것이 보편화 되고 있다. 기능 안전 목적이다. 
• RC의 경우, 범위 내에서 값이 순차적으로 증가한다. 1 바이트 신호라면 0 --> 1 --> ... 255 --> 0 이런 식이다. 누락이 있다면 전송 제어기에 오류가 있거나 메시지 전송 과정에 오류가 있다고 유추할 수 있다.
• CRC의 경우, 수신 제어기가 메시지의 데이터를 이용하여 계산한 CRC와 수신한 CRC를 비교하여 전송 과정에서 손상 발생 유무를 유추할 수 있다. RC와 마찮가지로 전송 제어기에 오류가 있을 수도 있다.
• RC, CRC의 점검이 필요한다.

메시지 전송 주기 흔들림

• CAN은 메시지 아이디로 버스 점유를 결정한다. 제어기가 정상 작동해도, 버스 점유 우선 순위에 따라 전송 주기 흔들림(jitter, 지터)이 있을 수 있다. 이 흔들림이 일정하지 않다. 
• 지터의 점검이 필요하다.

 

CANtegrity

바이브 코딩으로 RC, CRC, 지터 점검을 위한 간단한 기능의 파이썬 코드를 작성했다. 이를 부를 이름이 필요하다. 앞으로 반복해서 부를 예정이라서. 클로드가 준 이름들 중에 CANtegrity로 하기로 한다. CAN Integrity의 합성이다.

 

CANtegrity 개발을 시작할 때, CAN 통신 검증과 UDS 통신 검증을 모두 포함하려고 했다. 하다보니 코드가 커졌다. 코드가 크니 간단한 수정에도 토큰이 제법 들었다. 클로드가 전체 코드를 반복해서 읽는 것 같았다. 토큰을 아끼기 위해서 CAN 부분과 UDS 부분을 분리하였다. 클로드가 읽을 코드의 줄 수를 줄이기 위해서. CAN 부분을 CANtegrity-CAN이라고 부르기로 했다. 

 

실행 모습

• CANtegrity-CAN을 실행한 모습은 맨 아래 비디오와 같다. 아래는 화면을 설명하는 그림이다.
• 화면 왼쪽은 TSMaster 창이다. 창의 위쪽에 메시지 전송을 위한 Transmit 창이 있다. 아이디 0x061, 0x1F0 메시지들이 있다. 두 메시지의 데이터는 모두 0x00으로 채우져 있다. 아래쪽에 수신 메시지를 모니터링하기 위한 Trace 창을 배치했다. 제어기에서 전송되는 메시지들이 실시간으로 표시된다. 

• 화면 오른쪽은 CANtegrity 창이다. 창에 탭이 3개 있다. Configuration, E2E, Period. 
• Configuration 탭에서 CAN-to-USB 하드웨어를 설정한다. 
• E2E 탭에는 RC와 CRC를 점검하는 기능이 있다. E2E 탭에는 RC와 CRC 오류 점검 현황표가 있다. 아래 그림은 Transmit 창에서 RC와 CRC가 맞지 않는 메시지를 전송하여 일부러 오류를 발생시킨 상태이다. 오류가 잘 감지된다.

• Period 탭에는 메시지 전송 데이터 처리 기능이 있다. 최근 500개 메시지들의 타임스탬프 데이터에서 평균 등을 구하고 히스토그램을 그린다.

 

• 아래 유튜브 비디오에서 실행 모습을 볼 수 있다.

https://youtu.be/Y2ND2UXcHes

 

코드

• 나는 투썬의 libTSCAN을 이용하여 CANtegrity를 작성했다. libTSCAN에 관한 이전 포스트의 링크들은 아래와 같다.
  • libTSCAN API은 투썬 하드웨어의 기능들을 활용할 수 있는 API이다. 무료이다.
  • libTSCAN 함수 목록 :: hsl's tsmaster 사용기    
  • libTSCAN API - Python 설명서 :: hsl's tsmaster 사용기     
  • libTSCAN 예제 코드 :: hsl's tsmaster 사용기    
  • libTSCAN의 CAN 메시지 전송 주기 정확도 살펴보기 :: hsl's tsmaster 사용기    
  • 바이브 코딩으로 진단기 만들기 :: hsl's tsmaster 사용기     
• 코드를 올리려고 보니, 코드에 CRC 계산 방식이 포함되어 있다. CRC 계산 방법이 표준에 있는 방식이 아니라 특정 OEM의 방식이다. 나는 CRC 리버스 엔지니어링하기 :: hsl's tsmaster 사용기 에서 CRC를 리버스 엔지니어링 하는 방법을 설명했다. 그래서 그 OEM의 CRC 계산 방법을 안다. 그렇다고 그 방법을 공개하는 것이 괜찮은 일로 생각되지 않는다. 
• 코드에서 CRC 계산 부분을 특정 OEM의 방식이 아니라 일반적인 방식으로 계산하도록 수정하였다. 

cantegrity_blog_20260915_171147.zip

0.19MB

• 바이브 코딩에 경험이 어느 정도 있는 사람들은 이 코드를 기반으로 바이브 코딩을 하면 투썬의 TC1013을 설정하고 CAN 메시지를 송수신하는 파이썬 스크립트를 어렵지 않게 (쉽다는 의미는 아니다.) 작성할 수 있을 것으로 생각한다. 

 

결론

• 나는 위 방법을 독자에게 데모로 선보이기 위해 GUI를 작성했다. 이것이 내가 실제로 해야하는 검증 시험이었다면, 나는 GUI를 만들지 않고 화면과 로그 파일에 결과를 텍스트 출력을 하도록 했을 것이다. 히스토그램은 .csv와 .png 파일로 데이터와 이미지를 저장했을 것이다. 나는 CANtegrity-CAN과 CANtegrity-UDS를 날짜 기준으로 3일간 작업했다. 금요일 밤, 토요일 낮과 일요일 저녁. 시간으로는 16시간 미만이다. 만일 GUI가 없었다면, 나는 4시간 이내에 완성할 수 있었을 것이라고 확신한다. GUI가 없었다면, TSMaster의 버스 연결, 로깅 시작, 로깅 종료, 버스 연결 해제 등의 단계들을 모두 파이썬 코드에서 제어해서 자동화의 수준을 높였을 것이다.
• 나는 AI가 전장 시스템 검증 툴 비즈니스에 매우 큰 변화를 가져올 것이라고 믿는다. 과거 도메인 전문가들은 달리 방법이 없어서 툴 업체에 노-하우를 전수하고 툴 개선을 통해 노-하우를 동료들과 공유하였다. (툴 개선은 전문가에게는 툴의 수준을 넘어섰다는 자부심을 느낄 성취로 인정되기도 했다.) 이 과정에서 생산성 향상을 얻었지만 노-하우를 유출하였다. 일단 툴에 노-하우가 들어가면 그 배포 범위를 통제할 수 없었다. 도메인 전문가들이 바이브 코딩으로 노-하우를 코드로 작성한다면, 노-하우 유출 걱정 없이 생산성 향상을 이룰 수 있다.
• 노-하우를 코드로 만든다면, 툴은 기본 기능만 수행하면 된다. 기본 기능만 있는 툴의 가격은 저렴하다. (공급사가 많으니까.) 원가 절감이 가능하다는 의미가 된다.
• 노-하우를 코드로 관리하면, 다른 이점이 있다. 팀 차원에 협업의 수준을 높일 수 있다는 것이다. 이에 관한 내 생각을 별도의 포스트에서 이야기 하겠다.