임베디드 제품을 다루다 보면 해당 제품의 전용 모니터링 프로그램이나, 좀 더 범용적이고 널리 알려진 시리얼 모니터링 프로그램을 자주 쓰게 되기 마련인데요.
이번에 회사 제품용 시리얼 모니터링 프로그램을 만들게 되었습니다.
저는 이것을 만들기 위해 먼저 상용 프로그램의 좋은 기능을 조사했고, 검증된 통신 라이브러리를 GitHub에서 찾았으며, 사용할 언어 중(Python, Delphi, C# 등) 윈도우 시스템에 가장 적합한 것을 찾아냈습니다. 아무래도 비개발자가 사용하기에는 배포 시 실행 환경을 많이 타는 파이썬은 제외되었고, 윈도우 데스크톱용 앱 개발에는 C#이나 델파이가 좋았는데, 이는 USB 통신이 비교적 안정적으로 구축되어 있었기 때문입니다. 그중에서도 회사에서 델파이를 자주 사용한다는 이유로 델파이를 채택했습니다.
최종적으로는 이 정보들을 종합해서 바이브 코딩으로 클로드와 GPT를 활용하니, 결과물을 생각보다 어렵지 않게, 적은 시간으로 만들어낼 수 있었습니다.
(최종적으로는 오류를 만나 고생을 했지만, 그럼에도 바이브 덕분에 많이 편했습니다. 👍)
다시… 어쨌든, 바이브 코딩으로 모든 게 잘 풀렸다면 제가 이런 글을 안 썼겠죠..!
모니터링을 한 지 하루가 지나고 이틀이 지나는 시점, 저의 첫 PC 프로그램에 문제가 생겼습니다.
그리고 연달아서 2개의 크리티컬한 문제가 추가적으로 발생했습니다.
바이브 코딩으로 프로그래밍을 할 땐 “나” 혹은 “인공지능” 둘 다 고려하지 못한 것이 있었던 것이었습니다.
1) 복원성(Recovery) 부족
USB를 PC에 꽂아두었을 때, 자기 혼자 띠딩 하면서 인식이 끊긴 경험이 있으실까요?
이것은 PC의 전력이 불안정하여 USB에 전기 공급이 갑자기 부족해져 흐름이 끊겼거나, PC가 고사양 작업 시 USB 연결에 쓸 리소스가 부족해서 꺼지는 현상입니다.
이럴 땐 USB를 뺐다 꽂으면 해결되듯, 마찬가지로 임베디드 제품들 또한 PC와 통신하는 과정에서 하드웨어적/소프트웨어적 충돌, 공장 전력의 순간 피크 등 알 수 없는 이슈로 접속이 끊길 수 있더라고요...!
저는 이것을 복원시키기 위해 매번 접속이 되어 있는지 확인하는 루틴을 추가했고, 접속이 끊긴 디바이스를 찾아내기 위해 매 루틴의 끝에 인식 여부를 묻는 프로토콜을 날려 인식이 안 된 녀석이 있으면 재접속을 시도하는 코드를 추가했습니다.
2) 임베디드 제품의 결함 문제로 인한 상위 시스템(PC 프로그램) 불량 문제
하위 시스템에 결함이 상위 시스템까지 결함을 발생시키는 결함 전이(Fault Propagation) 문제를 고려하지 못했습니다. 임베디드 제품에서는 하드웨어적/소프트웨어적 이유로 시스템 오류가 발생할 수 있습니다. 이럴 경우 더더욱 소스 코드조차 없는 타 제품들은 블랙박스이기 때문에 사전에 예측할 수도 없습니다.
따라서 갑자기 발생한 에러를 기록해두는 에러 로깅 기능을 추가했고, 어떤 형태로 에러가 발생하는지 데이터를 수집했습니다. 그리고 에러가 일어날 경우 상위 시스템인 PC가 이를 인지하여 제품을 리셋하게 만들었습니다.
에러 로그를 수집해 보니, 에러가 날 때마다 센서값이 0 0 0으로 찍히는 상황을 특정해냈습니다. 따라서 저는 실제로 센서값이 0 0 0일 경우를 배제하기 위해 0 0 0이 연속으로 60번 발생하면(발생할 확률이 매우 낮기 때문에) 시스템을 강제 리셋하는 기능을 추가하여 문제를 해결했습니다.
이러한 모든 것들은 바이브 코딩으로 해결하기 힘든, 똥을 밟아봐야만 아는... 문제였습니다.
또한 앞으로 개발자로 성장하려면 “안정성”도 함께 신경 써야겠다는 생각이 들었습니다.
이것을 땜빵하려고 각종 잡스러운 기능을 넣는 것보다, 하위 제품과 상위 제품 각각이 잘 돌아가는 게 사실 더 좋은 거니까요.
(소프트웨어 안정성 해당 항목: 1) 프리징 현상 없음 2) 메모리 누수 없음 3) 응답 정지 없음 4) 통신 끊김 없음)
저는 항상 이렇게 생각해왔습니다.
아니… 바쁜 개발자들이 만든 프로그램이 기능적으로 잘 작동하는 것만으로 충분하지, 무슨 소프트웨어 안정성(Software Stability)이라는 항목까지 반드시 고려해야 하는 걸까..
제 발언은 지극히 바보 같고 질타받을 만한 요소가 있지만, 저 같은 많은 초보 임베디드 개발자부터 20년 차 개발자까지 왜 안정성까지 고려해서 개발을 하지 못하는 상황이 나올까 고민해봤습니다.
그리고 제 나름대로 많은 개발자들이 안정성에 대해서 한 번도 고민하지 않았던, 아니 할 수 없는 이유를 찾았습니다. 😀
바로… 생각보다 개발자들은 내가 만든 프로그램을 몇 개월 ~ 1년 이상 상시 가동 테스트해 볼 시간도 경험도 없기 때문입니다. 단순하죠.
심지어 물건이 팔려도 고객들은 프로그램에 문제가 생겼을 때, 큰 문제가 아니라면 그냥 껐다 켜서 해결해버립니다. 그들에겐 어찌 보면 큰문제가 아니기 때문에 그냥 넘어가는 거죠. 제품도 마찬가지고요.
반면, 정말 안전과 직결된 공장이나 자동차 같이 큰 규모의 프로젝트 외에는 쌓기 힘든 경험일 겁니다. 이런 안정성을 고민해 볼 수 있는 직군은 소수죠.
저는 운이 좋게도(?) 최소 2개월 동안 PC 모니터링 프로그램과 임베디드 장치 작동이 1번의 오류도 없이 연속되어야만 하는 상황에 직면했으며, 이로 인해 많은 것들을 깨닫는 계기가 되었습니다.
즐거우셨길 바라며, 제가 제작한 프로그램과 아키텍처를 간단히 올리고 마치겠습니다~
