몇주 전에 집 근처 비영리조직에 납품한 RFID 리더기가 말썽이라는 고객 문의를 받았다.
식당에서 운영 중인데 점심 시간의 피크 타음에 처리 시간이 3~4초 이상 걸리는 현상이었다.
그런데 문제는 이 시간이 갈수록 더 걸린다는 것이다.
이 장비는 모두 구글 안티그래비티를 이용해 개발했다.
금요일 밤에 고객사에 방문, 장비를 회수하고 주말에 안티그래비티를 이용해 수정을 진행했다.
빠르게 답을 얻었고 수정된 앱을 다시 리더기에 업로드 했다.
설명은 그럴싸 했지만 결과는….. 효과가 없었다.
동일한 실수를 2번 반복하면 모델을 바꾸어야 한다.
프로젝트 폴더를 클로드 코드에서 열고 같은 질문을 했다.
사용한 모델은 SONNET 5, 가성비가 좋다.
무려 10분이나 소스를 살펴 보고 원인을 찾았다.
[원인]
1. DB 조회 부하: 접속 로그 테이블에 인덱스가 없어 대시보드가 매번 풀스캔에 가까운 JOIN을 돌리고 있었다.
2. 펌웨어의 동기식 전송: ESP32 리더기가 태그 하나를 찍을 때마다 HTTPClient를 새로 만들어 서버로 전송하는데, 이 전송이 화면 갱신과 같은 스레드에서 순서대로 실행되며 병목을 만들었다.
원인을 찾았으니 해결 방법도 있다.
ESP32는 2개의 코어를 가지고 있어 태그를 읽는 쓰레드와 서버 전송을 담당하는 쓰레드를 분리해서 비동기 방식으로 운영가능하다.
1. 비동기 큐 분리: FreeRTOS 큐와 백그라운드 태스크로 “화면 갱신”과 “서버 전송”을 완전히 분리했음. 태그를 찍으면 화면은 즉시 바뀌고, 실제 서버 전송은 별도 태스크가 큐에서 꺼내 처리.
2. Keep-Alive(연결 재사용): 매번 새 TLS 핸드셰이크를 하는 대신, 같은 HTTPClient 객체를 계속 재사용(setReuse)해서 연결을 살려두고 핸드셰이크 자체를 생략
[느낀점]
1. 수정과 테스트는 2시간 정도 걸렸고, 4대의 장비를 성공적으로 업데이트 했다.
웹 개발자에게 임베디드 개발은 새로운 영역이지만 불가능한 영역은 아니다.
2. 구글 제미나이 모델은 프론트엔드는 마음에 드는데 경박하고 아무 생각이 없는 ADHD 환자 느낌이다.
엔지니어가 아닌 아티스트에 가깝다.
반면에 클로드 소넷은 좀더 비용이 들고 느리지만 진중하고 문제해결 능력이 있다.
이제 구글 제미나이 모델을 이용해 껍데기를 만들고 크리티컬한 부분은 클로드 코드를 사용하면 되겠다.
3. 다행이 장비가 설치된 곳이 집과 가까운 곳에 있어 회수 – 수정 – 재설치가 주말에 가능했다.
추후 임베디드 프로젝트는 고객에게 즉시 출동할 수 있는 지역 위주로 진행해야 겠다.
끝.