개요
찬동83이 e4ds에서 진행한 “ESP32로 완성하는 나만의 IoT 시스템” 웨비나의 Q&A입니다.
Espressif Systems의 ESP32는 저가형, 저전력, 고성능 시스템온칩(SoC)으로, 와이파이와 블루투스 통신 기능을 통합하여 사물 인터넷(IoT) 프로젝트에 매우 적합하며, 듀얼/싱글 코어 프로세서, 다양한 주변 장치, 풍부한 GPIO를 제공하여 아두이노 IDE 등 다양한 개발 환경에서 사용 가능합니다. 본 웨비나는 찬동83이 직접 설계한 ESP32 IoT 보드로 개발환경 설정부터 UART 통신, 블루투스 SPP, 웹 서버 및 대시보드 구현까지 IoT 프로젝트의 핵심을 단계별로 배울 수 있습니다.
웨비나 링크: ESP32로 완성하는 나만의 IoT 시스템 - e4ds news
방송을 보기 위해서는 회원 가입 및 웨비나 등록이 필요합니다.
관련 제품:
다음은 ESP32에 대한 Q&A입니다:
Q1: 안정성이 걱정이되요. CPU가 빠른 만큼 주의 해야 할게 더 많아 보이는데요.
A: 지금 MCU급에서는 CPU가 빨라지긴 했지만 외부에 고속 통신하는 메모리나 기타 주변 장치가 붙지 않기 때문에 저희가 봤을 때는 안정성이 크게 걱정될 건 없어 보입니다. 저희도 최근에 STM32H7 시리즈로 PSRAM과 고속 통신도 하고 플래시도 붙이면서 작업한 게 있었는데, 그런 경우에는 확실히 좀 많이 신경 써야 됩니다. 스트레스 테스트를 포함한 안정성을 위한 검증을 많이 해야 하지만, 이 정도의 성능에서는 제가 봤을 때는 크게 걱정은 안 하셔도 될 것 같습니다.
Q2: 전력소모는 어떤가요?
A: 저희가 보통 클래식 ESP32라고 부르는 ESP32는 저전력 블루투스(BLE)를 지원할 뿐이지 저전력 설계와는 거리가 멉니다. 이후에 출시된 ESP32-S 또는 ESP32-C 시리즈들이 저전력으로 사용할 수 있는 제품들입니다. EPS32는 사용할 수 있는 전력을 그대로 다 사용하신다고 보시면 될 것 같아요. 그래서 저전력을 고려하신다면 ESP32 보다는 ESP32-S 또는 ESP32-C 시리즈를 사용해야 합니다.
Q3: 개발 환경은 아두이노랑 ESP쪽에서 나오는 IDE 환경이 있는데, 어느것이 좋을까요?
A: 서로의 장점이 다릅니다. ESP-IDF로 개발하는 경우 세밀한 최적화와 디테일한 설정이 가능하다는 점이 큰 장점인 반면, 아두이노 IDE는 보다 빠르고 간편하게 개발할 수 있다는 점에 장점이 있습니다.
Q4: 아두이노IDE는 어떤 버전을 선호 하시나요?
A: 아두이노 IDE는 최신 버전으로 사용하고 있습니다.
Q5: 오늘 코엑스 AIot 전시회 다녀왔는데 Nordic사 제품이 많던데요. 장단점 비교를 할 수 있나요?
A: 노르딕 제품은 BLE에 강점이 있고, ESP는 와이파이에 강점이 있을 것 같습니다.
Q6: serialBT하면 SERIAL 모드 접속이 되는가요? BLE 다른 모드 이용은 어떤걸 참조해야할까요?
A: 예제로 보여드린 것은 블루투스 클래식에서 SPP 프로파일을 사용하는 방식이었습니다. 이것을 BLE를 이용해 비슷하게 구성할 수 있습니다. 아두이노 IDE에도 관련 예제가 있습니다. 예제에서 ESP32 BLE Arduino 항목을 보시면 BLE_uart가 있습니다. 이것이 BLE로 UART 시리얼 통신하는 예제라고 보시면 될 것 같습니다.
Q7: wifi 와 ble를 같이 쓰면서도 가능한가요?
A: 저희가 전에 개발했던 제품 중 하나가 도어락입니다. 도어락은 배터리 소모를 최소화해야 하기 때문에 노르딕 칩을 사용했습니다. 그리고 앱으로 제어하기 위해서는 무선을 적용해야 하는데, BLE는 근거리 통신만 가능하므로 원거리 제어를 위해 브릿지가 필요했습니다. BLE 신호를 공유기가 받아서 서버로 전달할 수 있도록, 저희는 ESP32로 브릿지 기능을 구현했습니다. 해당 제품에 똑같은 모듈이 적용되었으며, 와이파이와 BLE를 동시에 사용했는데 문제없이 잘 동작했습니다.
Q8: ESP32 보드가 아닌 모듈들도 인증이 되어 있나요?
A: 저희가 사용하는 EP32 모듈은 이미 인증이 되어 있어서 PCB 레벨의 개발 보드인 저희 제품은 인증을 받지 않아도 상관이 없습니다. 무선 기능이 포함된 모듈은 반드시 인증을 받아야 하는데, ESP32의 특정 모듈들은 Espressif에서 이미 인증을 받아두었습니다.
Q9: BLE만 지원되면 타 모듈(GPS) 등과의 Serial 통신은 어떻게 지원이 되는지요?
A: 현재 사용하는 버전의 ESP32는 총 3개의 UART 시리얼 포트가 있습니다. 그래서 이들을 직접 유선으로 연결해서 UART로 받은 데이터를 BLE로 전달할 수도 있습니다.
Q10: 소개하신 C 또는 S 계열은 저전력 설계가 Nordic 수준으로 가능한가요?
A: 노르딕 제품은 저전력에 특화된 솔루션이라고 보시면 됩니다. 반면 ESP32는 기본적으로 와이파이 기능을 내장한 모델이 많습니다. 물론 더 확인이 필요하지만, 노르딕만큼 저전력화하기가 쉽지는 않을 것이라는 개인적인 생각입니다.
Q11: 아두이노 외에 개발환경이 어떤게 있나요?
A: 맥북, 윈도우 환경 그리고 IDF에서 작업 가능합니다.
Q12: 초기에는 ADC가 좀 안좋아서 쓰기 그렇던데요. 요즘 시리즈는 좋아졌는지요?
A: 최근에는 ESP32에도 캘리브레이션 옵션이 추가되어 있어서, 어느 정도 수준을 원하시는지는 모르겠지만 저희가 사용했던 범위에서는 충분히 쓸 만했습니다. ST32G4 시리즈가 아날로그에 특화된 제품들이 많은데, 이런 제품들과 비교하는 게 아니라면 일반적인 수준에서는 사용하는 데 큰 문제는 없을 것 같습니다.
Q13: UART로 센서를 여러 개 연결할 때 충돌이나 데이터 처리 이슈가 생기기 쉬운데, 이런 경우 어떤 방식으로 설계하는 것이 좋을까요?
A: 보통 UART로 데이터를 받아 처리할 때는 큐(Queue)에 담아 하나씩 꺼내 순차적으로 처리하는 방식을 사용합니다. 그래서 충돌 문제는 거의 경험하지 못했습니다. ESP32에서는 RTOS가 기본적으로 올라가 있으므로, 별도의 Task를 만들고 이벤트 기반으로 데이터를 받아 처리하는 방식으로 구현하시면 될 것 같습니다.
Q14: Bluetooth SPP를 활용해 스마트폰과 통신할 때 별도의 앱을 만들지 않고 테스트할 수 있는 간단한 툴이 있는지 궁금합니다. 무선 제어를 실제 프로젝트로 확장할 때 안정성을 높이기 위한 기본적인 고려사항도 궁금합니다.
A: 세미나 영상에서 보신 앱을 이용하시면 테스트는 가능할 것으로 보입니다. 다만, 실제 프로젝트에서 무선 제어시 보안이 중요하다면 인증과 데이터 무결성 관련 부분에도 신경을 써야 합니다. 또한, 무선 통신은 언제든 데이터 손실이 발생할 수 있다는 전제를 두고 관련 대책을 마련해야 합니다. 즉, 송신 측은 수신 측이 데이터를 정상적으로 받았는지 확인해야 하고, 수신 측은 받은 데이터가 올바른지 검증하는 과정이 필요합니다.
Q15: ESP32 웹 서버에서 실시간 센서 데이터를 시각화할 때 속도나 부하를 줄이기 위한 최적화 방법이 있을까요? 추가로, 이 구조를 React나 Vue 같은 프레임워크로 확장할 때 주의해야 할 점은 무엇인지요?
A: 실시간 센서 데이터 시각화라면 WebSocket을 이용하는 방법이 효과적이지 않을까 싶습니다.
Q16: battery 레벨 측정인데, 캘리브레이션을 해야 하는 거 같아서, 좀 딥하게 들어가는 내용이네요…
A: 세미나에서 말씀드린 캘리브레이션은 ESP32에서 별도의 함수로 제공됩니다. esp_adc_cal_characterize 함수를 검색해보시면 도움이 되실 것 같습니다.
Q17: 접속가능한 Client수는 몇개나 되나요?
A: 이론상 설정 변경으로 최대 16개까지 가능하지만, 일반적으로는 4~10개 정도인 것 같습니다.
Q18: 센서 수집, Bluetooth, 웹 서버를 ESP32 한 개에서 동시에 돌릴 때 리소스 부족 문제가 생기지 않는지 궁금합니다. 만약 부담이 된다면 이를 분산하거나 최적화하는 현실적인 방법이 어떤 형태인지요?
A: 말씀하신 문제는 변수가 너무 많습니다. PSRAM과 플래시 용량이 더 큰 ESP32 모듈을 사용하는 방법도 있을 수 있으며, 두 개의 모듈을 사용해 서로 통신으로 연결하고 개별 기능을 구현할 수도 있습니다. 실제로 센서 데이터 수집, 블루투스, 서버 연동 정도는 리소스가 크게 부족하지 않았지만, 이는 애플리케이션마다 달라서 명확한 답변을 드리기 어렵습니다.
Q19: ESP32 기반 IoT 시스템을 취미 수준에서 실제 서비스나 제품 수준으로 확장하려면 어떤 요소 보안, 전력, 안정성을 가장 먼저 고려해야 하는지요? 실습 구조에 간단한 인증 기능을 추가할 수 있는 현실적인 방법이 있는지도 궁금합니다.
A: IoT 제품의 경우 보안이 가장 중요한 부분이지 않을까 생각됩니다. ESP32는 보안 키를 저장할 수 있도록 별도의 암호화 파티션을 제공합니다. 보통 상용 제품에서는 디바이스에 키를 저장할 때 다음과 같은 방법을 이용합니다.
- 공장에서 개별 키를 저장해 출하한다 - 간단하지만 키가 해킹당하면 해결 방법이 없습니다.
- 기본 키만 저장해 출하 후, 사용자가 서버에 연결해 디바이스를 등록 할 때 적절한 인증 절차를 통해 키를 내려받아 저장한다 - 복잡도는 다소 높지만 해킹이나 기타 문제 발생 시 다양한 대처가 가능합니다. 물론 초기 실습 단계에서는 키를 하드코딩해서 넣어 테스트하기도 합니다.
Q20: 센서 데이터를 로컬 저장 없이 바로 클라우드에 전송하려면 어떤 아키텍처가 적합할까요? 또 웹 서버 방식 대신 MQTT를 사용했을 때 장·단점이 어떻게 달라지는지도요
A: 1. 일반적으로 많이 사용하는 큐나 버퍼 기반의 Producer/Consumer 패턴이 적합하지 않을까 생각됩니다. 두 개의 Task를 사용해, 한쪽에서는 센서 데이터를 큐에 넣고 다른 Task에서는 큐에서 꺼내 전송하는 방식입니다.
2. MQTT의 가장 큰 장점은 경량 프로토콜이라 트래픽 효율이 좋다는 점입니다. 반면 웹 서버 기반은 MQTT보다 프로토콜이 무겁고, 매번 접속과 해제가 필요해 실시간성이 다소 떨어지는 단점이 있습니다. 웹 서버 기반에서는 디바이스가 서버 정보를 받아오기 위해 매번 서버에 재연결해야 하고, 서버는 데이터가 갱신되기 전까지 연결을 유지해야 하는 등 불필요한 작업이 추가됩니다.
Q21: ESP32에서 입력/출력 핀을 사용할 때 주의해야 할 전압 범위나 보호 회로가 있을까요? 개발환경을 Windows, macOS, Linux 중 어떤 OS에서 설정하는 것이 가장 안정적인지 경험적으로 추천해주실 수 있는지요?
A: ESP32는 기본적으로 3.3V로 구동됩니다. 내부에는 보호 회로가 없다고 보는 것이 좋으므로, 3.3V를 넘지 않게 사용하는 것이 안전합니다. 개발 환경은 Windows를 많이 사용하고 있습니다. 빌드 성능은 Linux나 macOS에서 더 안정적이고 빠른 편이지만, 큰 차이는 없습니다; 빌드 속도는 최초 한 번만 차이가 많이 납니다. 따라서 개발자가 익숙한 OS에서 개발하는 것이 더 효과적이라고 생각합니다.
Q22: ESP32 단에서 데이터 샘플링 주기와 전송 주기를 다르게 설정할 때 어떤 구조가 효율적일까요?
A: 저희는 보통 큐와 이벤트를 이용해 처리하는 것 같습니다. 태스크를 별도로 나누고, 한쪽에서는 큐에 데이터를 쌓고 다른 쪽에서는 큐에서 꺼내 전송하는 구조를 사용합니다.
Q23: Firebase나 AWS IoT Core 같은 클라우드 플랫폼과 연동할 때 가장 쉽게 적용할 수 있는 방법은 무엇인가요?
A: 보통 MQTT(Message Queuing Telemetry Transport)를 많이 사용하며, 적용도 쉽습니다.
Q24: 아두이노 코드를 ESP-IDF로 전환해야 할 필요가 생기는 경우는 어떤 상황인가요?
A: 다음과 같은 상황에서 IDF는 불필요한 기능을 제거해 펌웨어 크기를 줄일 수 있습니다.
- 코드 크기, 실행 속도, 메모리 사용량 등 최적화가 필요하거나 까다로운 실시간 처리 요구 사항이 있을 때
- 하드웨어 주변 장치를 세밀하게 제어하거나, 아두이노 라이브러리가 제공하지 않는 기능을 직접 사용해야 할 때
- FreeRTOS의 기능을 직접 그리고 깊이 있게 활용해 센서 수집, 통신, 로직을 독립적인 스레드로 분리해 안정성을 높여야 할 때
- 아두이노 환경의 오버헤드가 부담될 때
Q25: OTA 업데이트를 안정적으로 구현할 때 실패 대비 절차 롤백 기능을 포함할 수 있나요?
A: ESP32에서는 OTA를 위해 플래시의 애플리케이션 파티션을 두 개로 나눠 사용할 수 있습니다. 첫 번째 애플리케이션 파티션에서 프로그램이 실행되다가 OTA가 발생하면 두 번째 애플리케이션 파티션에 다운로드를 진행합니다. 해당 코드에 문제가 없으면 재부팅 후 두 번째 파티션에서 프로그램이 실행됩니다. 즉, 실패가 발생하면 첫 번째 파티션이 그대로 구동되므로 안정적인 OTA가 가능합니다. 무선 OTA를 사용하는 제품들은 대부분 OTA 데이터를 저장할 별도의 공간을 가지고 있는 것 같습니다.