바이브 코딩으로 진단기 만들기

시작하기 전에 

"hsl's tsmaster 사용기" 블로그를 시작할 때(2024년 7월)는 마땅한 용어가 없어서 'ai의 도움을 받아 하는 코딩'이라고 길게 이야기를 했는데, 이제는 '바이브 코딩'이라는 용어가 자리를 잡은 것 같다.

 

'바이브 코딩으로 진단기 소프트웨어를 만들 수 있지 않을까?'라는 생각이 들었다.

 

바이브 코딩 초창기에는 pdf 파일을 업로드할 수 없거나, 업로드 할 수 있는 파일의 크기가 작았다. 지금은 그런 제한이 없거나 사용에 불편하지 않을 정도로 크다. 그렇다면 투썬의 무료 라이브러리인 libTSCAN의 함수 설명 문서를 통째로 업로드하고, 이를 바탕으로 바이브 코딩을 할 수 있을까? 한다면 무엇 정도를 개발할 수 있을까?

 

TSMaster의 Diagnostic(진단) 기능은 유용하다. TSMaster의 기본 기능이 저렴하다는 데는 대부분 사람들이 쉽게 동의한다. (어떤 사람은 그렇다고 내게 열정적으로 주장한다.) 추가 기능인 진단 기능이 저렴한가에 대해서는 의견이 갈린다. 각자 예산의 여유, 사용 빈도, 유용성이 다르다. TSMaster의 진단 기능은 의견이 갈릴 수 있을 정도로 싸다면 싸고 비싸다면 비싼 그런 가격이라고 개인적으로 생각한다.

위 두 가지 생각이 합쳐져서 이 시도를 해 볼 생각이 든 것 같다.

 

요즘은 많은 사람들이 ai 서비스를 구독하고 있다. 바이브 코딩으로 진단기 프로그램을 큰 시간 투자 없이 작성할 수 있다면, 이 사실은 여러 사람들에게 유용하지 않을까?

 

바이브 코딩으로 진단기를 만들어 보았다.

 

 

이 과정을 설명한다.

 

 

개요

• FRD (Functional Requirement Document) 작성
• 바이브 코딩 
• 진단기 
• 결론

 

FRD (Functional Requirement Document) 작성

• 내가 생각하는 진단기의 기능을 ai에게 설명하기 위해서, 채팅 창에 쓰기에는 너무 길어서, 짤막한 문서로 작성하였다. 이를 FRD(Functional Requirement Document)라고 부르겠다. 
• 처음 작성한 FRD는 대략 20줄 정도의 간략한 내용이었다.
  • ai와 대화를 하면서 (나는 vscode에서 작업하였다. 나는 GitHub Copilot을 구독하고 있다. 깃헙 코파일럿에서 모델을 선택할 수 있다. Claude Sonnet 4.5를 선택하였다.) 중간중간에 ai에게 이 문서를 업데이트해 달라고 요청했다. 지금 생각하면 이 문서를 업데이트할 때마다 새 파일에 저장해 달라고 했어야 했다. 블로그 포스팅을 하려니 최초 FRD가 필요하다. :-)  기억을 더듬어 처음 작성한 20줄 정도의 내용을 쓰자면 대략 아래와 같다. "해설:" 부분은 독자에게 설명을 위해 추가했다. 원본에는 없는 부분이다.

# ESC Diagnostic Tester - Functional Requirement Document (FRD)

## 개요

- ESC (Electronic Stability Control) 제어기를 진단하는 도구(이하, Diagnostic Tester, 진단 시험기, 시험기)이다.
- ESC와 시험기는 UDS(Unified Diagnostic Services) 기반 통신 프로토콜로 통신한다.
- 통신은 CAN (Controller Area Network)으로 한다.
- 사용자는 GUI에서 서비스를 선택하여 실행할 수 있다.

## 참조 문서

- esc_diag_hsl.md: ESC 진단 통신 스펙
  - 해설: 
    - 진단 통신 스펙을 발췌해서 만든 문서다. 
    - 클로드에게 요청하여, pdf를 md로 바꾸는 파이썬 코드를 작성해 달라고 했다. 앞으로도 이럴 경우가 종종 있을 것 같아서, 이번 기회에 ...
    - 그 코드로 pdf를 md로 변환하였고, md에서 필요한 진단 서비스들만 추출했다. 
    - pdf 대비 md의 파일 크기가 매우 작다. ai 서비스의 토큰을 아끼기 위해서 이렇게 했다.
    - 이 파일을 vscode의 작업 디렉토리 아래 doc 디렉토리에 저장하였다.
- libTSCAN_Library_Python_Description.md: TOSUN사의 libTSCAN 라이브러리 사용법 문서
  - 해설
    - TOSUN의 홈페이지에서 다운로드 받은 pdf 파일을 md로 변환하였다.   
    - 이 파일을 vscode의 작업 디렉토리 아래 doc 디렉토리에 저장하였다.
- libTSCANAPI/*.py: TOSUN사의 libTSCAN 라이브러리 사용을 위한 파이썬 모듈
  - 해설
    - TOSUN의 홈페이지에서 다운로드 받은 파일들이다.
    - 이 파일들을 vscode의 작업 디렉토리 아래 libTSCANAPI 디렉토리에 저장하였다.

## 기능 
- Configuration
  - CAN 연결/해제
    - 프로그램을 시작하면 프로그램은 연결된 인터페이스 하드웨어 인식합니다.
    - 사용자가 채널을 선택할 수 있는 드롭다운 리스트가 있습니다. 
    - 사용자가 CAN, CAN-FD를 선택할 수 있는 라디오 버튼이 있습니다. 
    - 사용자가 보드 레이트를 선택할 수 있는 드롭다운 리스트가 있습니다. 
    - CAN-FD를 선택하는 경우, 데이터 구간의 보드 레이트를 설정할 수 있는 드롭다운 리스트가 활성화됩니다.
    - 툴바에 Connect 버튼이 있습니다. 
- Diag & Comm
  - Diagnostic Session Control (0x10)
  - Extended 버튼이 있어서, 버튼을 클릭하면 Extended 모드 전환 요청이 전송됩니다.
- DTC
  - Read DTC 버튼이 있습니다. 버튼을 클릭하면 Read DTC 요청이 전송됩니다.
  - 수신된 응답을 파싱하여 표에 출력합니다. 
- Date
  - Read DID (Date by IDentifier) 버튼이 있습니다.
  - DID를 입력할 수 있는 텍스티 인풋이 있습니다.

• 이 정도를 쓰고, 클로드에게 '당신의 의견은 어떻습니까?'라고 문의했다. 클로드가 여러 좋은 제안들을 했다. 그래서 나는 '당신의 제안을 FRD에 업데이트 해주세요.' 라고 했다. 현재까지 완성된 FRD는 아래 링크와 같다.
  • diag_tester_FRD :: hsl's tsmaster 사용기    
  • 블로그에 마크다운 파일을 넣는 방법을 몰라서 링크로 대체한다.
  • 이 문서는 계속 업데이트할 예정이라 '현재까지'라고 했다.
  • 대화 시작부터 이 문서를 작성하는데까지 1 시간 남짓 걸린 것 같다. 

 

바이브 코딩

• 클로드와의 대화로 FRD를 계속 업데이트했다. 그러다가 대화가 날라갔다. 가끔 이런 일이 발생한다. (당신도 경험이 있을 것이다.) 나는 이런 일을 대비하여 대화 중간중간에 대화를 요약해서 파일로 저장해 달라고 요청한다. 이번 대화에서는 FRD 업데이트 요청을 했다. 위에서 말한 바와 같이 업데이트가 아니라 처음 한 번은 새 파일을 만들라고 하고 그 후에 업데이트를 요청했어야 했다.
• 대화가 날라간 이후의 대화는 아래 링크와 같다. 
  • 바이브 코딩 대화 :: hsl's tsmaster 사용기     
  • 대화가 길다. 대화 시작부터 종료까지 5~6 시간이 걸린 것 같다. 그런 주된 이유는 두 가지다. 
    • 클로드가 생성한 코드를 내가 실제로 실험하면서 검증하는데 시간이 걸렸다. 짧은 실험이지만 될 때까지 여러 번 반복할 수 밖에 없었다. 특히, 하드웨어 설정 방법, CAN 메시지를 송/수신하는 방법을 "클로드"가 깨우칠 때까지 (나는 클로드가 깨우친 이후에 깨우쳤다. ^^) 함수 인자들을 변경해 가면서 맞는 인자 조합을 찾을 때까지 짧은 실험들이 반복되었다.
    • 내가 한꺼번에 여러 가지 작업을 요청하고 기다리는 시간에 유튜브 비디오를 보면서 까먹은 시간이 상당하다. 일단 비디오를 보기 시작하면, 클로드가 작업을 마쳤다는 알림이 화면 구석에 떠도 무시하고 보던 비디오를 마저 보느라 ...^^
    • 딴청피지 않고 집중해서 했다면 ... 4시간 안에 마쳤을 것으로 예상한다.

 

진단기

• 위 바이브 코딩으로 만든 진단기가 실제 동작하는 모습을 이 포스트의 "시작하기 전에" 에 있는 비디오에서 확인할 수 있다.
• 첨부는 진단기의 코드이다. 이 코드가 누군가의 진단기 프로그램 개발에 디딤돌이 되면 좋겠다. 그 사람이 만일 바이브 코딩을 한다면, ai에게 '이 코드를 읽어보세요'라는 한 마디로 한두 시간을 아끼게 된다면 내게는 큰 기쁨이다. :-)  

diag_tester.zip

19.78MB

 

 

결론

• CAN 인터페이스 하드웨어와 무료로 제공되는 라이브러리를 이용하여 UDS 기반 진단 통신을 하는 GUI를 갖춘 진단기를 바이브 코딩으로 만들어 봤다.
• 코드를 수정하는 대신 채팅과 FRD 문서를 업데이트 하는 방식으로 (심지어 이 문서도 ai에게 업데이트 하라고 시키면서) 진단기를 개발할 수 있었다. (UDS 서비스의 일부 기능만 구현한 것이지만)
• 내 코딩 실력으로 이 진단기를 개발한다면 몇 주 내지 몇 개월이 걸렸을 것이다. 실제 시도했다면 ... 포기했을 확률이 성공했을 확률보다 훨씬 높다.

 

 

에필로그 

•  나는 2012년 말부터 2021년 1년까지 초까지 8+년 동안 자동차 제어기 개발용 소프트웨어 툴을 판매한 경험이 있다. 
• 이 기간 중에 대한민국 자동차 산업의 제어기 소프트웨어 개발 능력이 괄목하게 발전했다고 생각한다.
  • 이 시기에 아키텍처이자 소프트웨어 개발 방법론이자 자동차 제어기용 OS인 AUTOSAR가 씨 뿌려지고 싹을 틔우고 뿌리를 내렸다. (2026년 현재는 뿌리가 굵어지는 시기라고 생각한다.)
  • 기능 안전이라는 화두가 던져졌고, 소위, Model based Software Development라는 것의 필요성, 중요성, 이익이 인지되었다. (ai의 등장이 이 분야에 어떤 변화를 가져올 지 모를 일이다.)
  • 소프트웨어 개발 프로세스라는 것은 누군가가 시켜서 해야만 하는 귀찮은 것이 아니라, 수준있는 소프트웨어 개발 품질을 유지하고 이를 바탕으로 실력을 키우려면, 즉, 생존하려면 반드시 필요하다는 관념이 사실로 받아들여진 시기라고 생각한다. (관념으로 보는 관리자들이 아직 은퇴를 하지 않은 회사들도 있는 것 같다. :-)
• 이 시기에 툴은 단위 작업을 하는 개인의 개별 툴로써 고유의 기능을 했다. 전문가는 툴을 잘 사용한다. 툴을 잘 사용한다는 것은 한 작업이 완료되면 지체 없이 다음 작업이 이뤄지도록, 이 버튼을 클릭하고 결과에 따라 곧바로 저 버튼을 클릭하는 조작을 잘 한다는 의미이다. 데이터를 눈으로 확인하여 이상이 없음을 혹은 이상이 있음을 빠르게 확인하는 조작을 잘 한다는 의미이다. (툴을 잘 사용하지 못한다고 비전문가라는 의미는 아니다.)
• 사용자가 하는 많은 조작들 중에 상당 부분의 조작에는 '이럴 때는 이렇게 하고, 저럴 때는 저렇게 한다'는 규칙이 있다. 좋은 툴은 그런 사용자 조작을 프로그램으로 대신 할 수 있도록 API (Application Programming Interface)를 제공한다.
• 당시 사용자들은 프로그래밍에 능숙하지 않았다. 코딩 실력이 충분하지 않았다. 생각해보면, 지금 사용자들이 당시 사용자들에 비해 코딩 실력이 의미있게 뛰어난 것 같지 않다. 다만, 지금은 코딩 실력과 무관하게, '툴 조작의 규칙'을 ai에게 설명할 수만 있으면 바이브 코딩으로 툴을 전문가답게 잘 사용 할 수 있다. 
• 바이브 코딩으로 API를 이용해서 개별 툴을 잘 쓰는 것뿐 아니라 여러 툴들을 연계해서 잘 쓰는 것도 가능하다. 이 정도 수준으로 '툴 조작의 규칙'을 ai에게 설명할 수 있다면 그 사람은 전문가라고 생각한다. 
• 그동안 고객이 스스로 코딩하지 못하는 '툴 조작의 규칙'을 툴 회사들이 대신 툴에 코딩하여 넣었다. 기능 추가/개선은 유지 보수 비용 청구의 좋은  해명거리이다. 
• ai 구독이 보편화되고 있는 시기에 사람들은 패러다임 변화라는 문을 통과할 것이다. 그 문을 통과한 관리자들/책임자들 중에는 툴 유지 보수 비용을 기존과 다른 시각에서 보는 사람들이 생기지 않을까? '툴 조작의 규칙'이라는 자기 회사의 지식과 경험이 툴 회사의 돈벌이가 되는 것에 의문을 던지는 사람들이 나오지 않을까?