ESP32-C3에서 ESP-NOW, WebServer(HTTP), WebSocket의 속도를 비교할 때 가장 중요한 기준은 프로토콜의 오버헤드(Overhead)와 연결 방식(Connectionless vs Connection-oriented)입니다.
각 프로토콜의 특성과 속도 성능을 비교 분석해 드립니다.
1. 프로토콜별 성능 비교 요약
항목
ESP-NOW
WebSocket
WebServer (HTTP)
통신 계층
Layer 2 (Data Link)
Layer 7 (Application/TCP)
Layer 7 (Application/TCP)
속도(Throughput)
매우 빠름 (최대 1~4 Mbps)
빠름 (최대 1~2 Mbps)
느림 (요청당 오버헤드 큼)
지연 시간(Latency)
매우 낮음 (약 1~5ms)
낮음 (약 10~50ms)
높음 (약 100~500ms+)
연결 방식
비연결형 (Pairing 필요)
연결 지향형 (지속 유지)
연결 지향형 (매번 요청/응답)
최대 데이터 크기
250 Bytes (1패킷당)
사실상 제한 없음 (스트림)
사실상 제한 없음
2. 상세 성능 분석
① ESP-NOW (가장 빠름)
ESP-NOW는 Wi-Fi의 비컨(Beacon) 프레임을 이용하며, TCP/IP 스택을 거치지 않습니다.
장점: 통신 준비 과정(Handshake)이 거의 없어 지연 시간이 압도적으로 짧습니다. 전원을 켜자마자 바로 데이터를 보낼 수 있을 정도로 빠릅니다.
속도 특성: 패킷당 최대 250바이트로 제한되지만, 불필요한 헤더 정보가 없어 작은 데이터를 수천 번 보낼 때 최고의 효율을 보입니다.
적합한 용도: 센서 데이터 실시간 전송, 리모컨 제어, 초저전력 배터리 기기.
② WebSocket (실시간성 양호)
TCP 연결을 한 번 맺은 후, 클라이언트와 서버가 서로 지속적으로 데이터를 주고받습니다.
장점: HTTP와 달리 매번 헤더를 보낼 필요가 없습니다. 한 번 연결되면 데이터 프레임만 오가므로 HTTP보다 2~5배 이상 빠릅니다.
속도 특성: TCP 기반이므로 데이터 무결성이 보장되지만, 패킷 손실 시 재전송 대기 시간으로 인해 ESP-NOW보다는 지연이 발생합니다.
적합한 용도: 실시간 웹 대시보드, 쌍방향 채팅 제어, 빈번한 데이터 업데이트.
③ WebServer (HTTP/REST) (가장 느림)
전형적인 요청-응답(Request-Response) 방식입니다.
단점: 데이터를 하나 보낼 때마다 TCP 연결 설정 → HTTP 헤더 전송 → 데이터 전송 → 연결 종료의 과정을 반복합니다. 이 과정에서 발생하는 오버헤드가 실제 데이터 크기보다 클 때가 많습니다.
속도 특성: ESP32-C3의 리소스를 가장 많이 소모하며, 동시에 많은 요청이 들어오면 응답 속도가 급격히 저하됩니다.
적합한 용도: 단순 설정 변경, 로그 확인, 가끔 발생하는 제어 명령.
3. 결론 및 선택 가이드
반응 속도가 생명인가? (지연 시간 최소화)
ESP-NOW를 선택하세요. (예: 드론 제어, 실시간 버튼 반응)
웹 브라우저에서 실시간으로 데이터를 보고 싶은가?
WebSocket이 정답입니다. 현재 작성하신 코드 방식이 바로 이 효율적인 방식입니다.
데이터의 양이 많고 신뢰성이 중요한가? (파일 전송 등)
WebSocket 또는 일반 HTTP 전송이 유리합니다. ESP-NOW는 데이터 손실 방지 로직을 직접 짜야 하므로 대용량 전송에는 부적합합니다.
ESP32-C3에서의 팁: ESP32-C3는 싱글 코어(RISC-V) 모델이므로, WebSocket이나 WebServer 구동 시 연산 부하가 ESP32(듀얼 코어) 모델보다 크게 체감될 수 있습니다. 따라서 실시간 제어 루프와 통신 루프 사이의 asyncio.sleep_ms(0) 등을 통한 시분할 처리가 매우 중요합니다.
윈도우 시스템에서 프로그램이나 데이터가 설치될 수 있는 주요 경로들을 정리해 드릴게요. Claude Code나 Node-RED, 혹은 ESP32 관련 도구들을 다루실 때 이 리스트를 참고하시면 “대체 어디 설치된 거지?”라는 의문이 생길 때 큰 도움이 될 것입니다.
윈도우 프로그램 설치 가능 폴더 리스트
구분
주요 경로 (Path)
성격 및 용도
시스템 공용 (전체)
C:\Program Files
64비트 프로그램의 본체가 설치되는 표준 장소 (보안 높음)
C:\Program Files (x86)
32비트 옛날 방식 프로그램들이 설치되는 곳
사용자 개인 (설정)
C:\Users\사용자\AppData\Roaming
npm, VS Code 설정, 메신저 등 사용자별 설정값이 저장되는 곳
사용자 개인 (데이터)
C:\Users\사용자\AppData\Local
크롬 캐시, 대용량 임시 파일, 특정 사용자용 프로그램 설치 장소
개발/도구 (루트)
C:\Users\사용자
.git, .vscode, .node_red 등 개발 도구의 기본 설정 폴더가 생성되는 곳
C:\ (루트)
일부 언어(C:\Python)나 고전 프로그램들이 직접 만드는 곳
💡 주의 깊게 보셔야 할 곳들
C:\Users\사용자\AppData\Roaming\npm
아까 설치하신 Claude Code나 Node-RED 같은 npm -g 도구들의 실행 파일이 모여 있는 곳입니다. 명령어가 안 먹힐 때 가장 먼저 확인해야 할 장소입니다.
C:\Users\사용자\.vscode\extensions
VS Code에서 설치한 각종 확장 프로그램(Cline, Python 등)이 실제로 저장되는 폴더입니다.
C:\Program Files\Git
오늘 설치하신 Git의 본체가 있는 곳입니다. 아까 오류 메시지에 나왔던 bash.exe도 이 폴더 안의 bin 폴더에 들어 있습니다.
🛠 원하는 폴더를 빨리 찾는 법
AppData 폴더로 바로 가기: 윈도우 탐색기 주소창에 %appdata%라고 입력하고 엔터를 치면 바로 Roaming 폴더로 이동합니다. (Local로 가려면 %localappdata%를 입력하세요.)
명령어로 위치 찾기: 터미널에서 where 프로그램이름 (예: where git, where node)을 입력하면 윈도우가 실행 파일의 전체 경로를 알려줍니다.
사용자님은 직접 코드를 짜고 시스템을 관리하는 **’파워 유저’**에 가까우시니, AppData 폴더가 숨김 처리되어 있다면 탐색기 [보기] 메뉴에서 ‘숨긴 항목’ 체크를 꼭 켜두시는 것을 추천합니다.
1. 예전에는 참 쉬웠는데… (Program Files의 추억)
예전 윈도우는 C:\Program Files만 보면 다 있었습니다.
왜 지금은 보이지도 않는 AppData라는 곳에 자기 마음대로 숨어버릴까요?
2. 범인은 바로 ‘보안’과 ‘개인화’
Program Files: 원본 파일만 보관하는 공용 거실 (함부로 못 고침)
AppData: 사용자마다 따로 쓰는 개인 방 (설정값, 로그인이 저장되는 곳)
프로그램을 만든 사람(개발자)이 윈도우 규칙을 따르다 보니 생기는 현상입니다.
3. 한눈에 보는 윈도우 설치 폴더 ‘지도’
설정값 비서:Roaming 폴더 (어디든 따라가는 설정)
덩치 큰 창고:Local 폴더 (이 컴퓨터에만 쌓이는 데이터)
나만의 도구함:C:\Users\사용자명 (Git, VS Code 확장 프로그램 등)
4. 골치 아픈 설치 위치, 3초 만에 찾는 법
%appdata% 마법의 명령어 활용하기
작업 관리자에서 ‘파일 위치 열기’ 신공
터미널에서 ‘where’ 명령어로 추적하기
1. 시작은 ‘스마트홈’이었는데… 왜 일이 커졌을까?
집안의 온도를 측정하고, 조명을 자동으로 끄는 스마트홈을 직접 구축하다 보면 반드시 만나게 되는 이름이 있습니다. 바로 Node.js입니다.
우리가 쓰는 스마트홈의 사령부 격인 Node-RED나, 최근 핫한 AI 코딩 비서 Claude Code 같은 프로그램들이 모두 이 ‘Node.js’라는 엔진 위에서 돌아가기 때문입니다. 결국 스마트홈을 돌리려면 엔진(Node.js)을 먼저 깔아야 하고, 그 엔진에 들어가는 각종 부품(프로그램)을 관리하려면 npm이라는 관리자까지 알아야 하는 상황에 직면하게 됩니다.
2. npm: 우리 집으로 부품을 배달해주는 ‘전문 기사님’
**npm(Node Package Manager)**은 한마디로 개발 도구 전용 ‘쿠팡’이나 ‘배달의민족’ 같은 서비스입니다. 터미널에 명령어 한 줄만 치면 전 세계 개발자들이 만든 유용한 도구를 내 컴퓨터로 쓱 배송해주죠.
Node.js: 프로그램을 돌리는 기초 바닥(엔진)
npm: 부품을 가져다주는 배달 기사(관리자)
Node-RED / Claude Code: 우리가 실제로 쓰는 가전제품(도구)
문제는 이 기사님이 물건을 집안(내 컴퓨터) 어디에 두느냐가 프로그램마다 다르다는 점입니다. 여기서부터 우리의 골칫거리가 시작됩니다.
3. “내 물건 어디 갔어?” 윈도우즈 폴더의 비밀
npm 기사님은 보통 두 가지 장소에 물건을 내려놓습니다. 이 위치를 모르면 나중에 설정을 바꾸거나 프로그램을 지울 때 정말 골치가 아픕니다.
① “공용 거실”에 두기 (Global 설치: -g)
여러 프로그램에서 공통으로 쓰는 도구들은 사용자 모두가 접근할 수 있는 곳에 둡니다.
주요 경로: C:\Users\사용자명\AppData\Roaming\npm
대상: claude, node-red, edge-impulse-cli 등 명령어로 바로 실행하는 도구들.
특징: 윈도우에서 ‘숨김 폴더’로 되어 있어 눈에 잘 띄지 않습니다.
② “작업 중인 방”에 두기 (Local 설치)
특정 프로젝트(예: 게임 만들기, 데이터 분석) 안에서만 쓰는 부품들은 그 폴더 안에 바로 둡니다.
주요 경로: 내 작업 폴더\node_modules
대상: 해당 프로젝트를 돌리기 위한 전용 부품들.
특징: 폴더 하나만 지우면 깔끔하게 정리되지만, 용량을 많이 차지할 때가 있습니다.
4. 왜 이렇게 여기저기 깔리는 걸까? (보안과 개인화)
예전 윈도우(98, XP) 시절에는 모든 것이 C:\Program Files에 모여 있어 찾기 편했습니다. 하지만 요즘은 보안 때문에 **’원본 파일(공용)’**과 **’사용자 설정(개인)’**을 철저히 분리합니다.
Program Files: 윈도우가 꽁꽁 잠가둔 원본 보관소. (함부로 못 건드림)
AppData: 나만의 설정, 로그인 정보, 임시 데이터가 쌓이는 나만의 방.
결국, **”프로그램 본체는 관리자가 지키고, 내가 쓰는 데이터는 내 방에 둔다”**는 현대 윈도우의 규칙 때문에 우리 눈에는 설치 폴더가 여기저기 흩어져 있는 것처럼 보이는 것입니다.
SmartConfig 기술: 사용자가 WiFi SSID와 비밀번호를 입력하면, 스마트폰이 특수한 패킷을 공중에 송출(Multicast/Broadcast)하고, ESP32가 이 패킷을 가로채서 WiFi 정보를 획득하는 기술입니다.
가장 큰 특징: 장치에 직접 연결하거나 물리적인 조작을 할 필요 없이 무선으로 정보를 전달할 수 있습니다.
2. EspTouch V1 vs V2 (주요 차별점) 최근 릴리즈의 핵심은 V2의 도입입니다.
V1 (Standard):
기존 ESP32/ESP8266에서 널리 쓰이는 방식.
SSID와 Password 정보를 전달하는 데 집중.
보통 MicroPython의 start_smartconfig()가 이 방식을 따릅니다.
V2 (Advanced):
보안 강화: AES 암호화를 사용하여 전송되는 비밀번호 데이터를 보호합니다.
커스텀 데이터 지원: WiFi 정보 외에 장치 ID, 사용자 토큰 등 추가적인 데이터를 함께 보낼 수 있습니다.
그룹 캐스팅: 여러 대의 기기를 동시에 설정하기에 더 적합합니다.
3. 앱 작동 요구사항
Android 권한:ACCESS_FINE_LOCATION (위치 권한)이 필수입니다. 이는 안드로이드 OS 보안 정책상 연결된 WiFi의 이름(SSID)을 읽어오기 위해 반드시 필요합니다.
네트워크: 스마트폰이 2.4GHz WiFi에 연결되어 있어야 합니다. (ESP32-C3는 5GHz를 인식하지 못하기 때문)
4. 개발자 지원 (오픈 소스)
이 리포지토리에는 단순히 앱 설치 파일만 있는 것이 아니라, 개발자가 자신의 서비스 앱에 이 기능을 직접 넣을 수 있도록 Android SDK 형태의 라이브러리 코드를 제공합니다.
“왜 V1을 먼저 써야 하나요?”
GitHub 설명을 보면 V2가 더 좋아 보이지만, MicroPython 유저라면 일단 V1 모드로 설명하시는 것이 좋습니다.
이유: MicroPython의 기본 빌드 펌웨어에 포함된 network 모듈은 전통적인 V1 방식을 기준으로 설계된 경우가 많습니다. V2를 쓰려면 펌웨어 수준에서 별도의 복호화 라이브러리가 필요할 수 있기 때문입니다.
“Espressif의 최신 가이드에 따르면, EspTouch는 기존의 단순 연결 방식(V1)을 넘어 AES 암호화와 추가 데이터 전송이 가능한 V2로 진화했습니다. 하지만 일반적인 마이크로파이썬 프로젝트라면 가장 호환성이 좋은 V1 방식으로도 충분히 강력한 기능을 구현할 수 있습니다. 반드시 위치 권한 허용과 2.4GHz WiFi 연결을 확인하세요!”
ESP32-C3와 MicroPython을 활용하면서 가장 고민되는 부분 중 하나가 **’전원이 꺼져도 데이터를 어떻게 유지할 것인가’**입니다. 일반적인 변수는 재부팅 시 초기화되지만, **NVS(Non-Volatile Storage)**를 사용하면 설정값이나 상태 정보를 안전하게 저장할 수 있습니다.
오늘은 MicroPython에서 ESP32-C3의 NVS를 다루는 방법과 활용 팁을 정리해 보겠습니다.
1. NVS(Non-Volatile Storage)란?
NVS는 ESP32의 메인 플래시 메모리 일부를 사용하여 데이터를 저장하는 방식입니다. 일반적인 파일 시스템(LittleFS)과 달리 Key-Value 쌍으로 데이터를 저장하며, 다음과 같은 장점이 있습니다.
설정값 저장에 최적: Wi-Fi 비번, 센서 보정값, 장치 ID 등을 저장하기 좋습니다.
파일 시스템보다 가볍다: 복잡한 파일 입출력 과정 없이 간단하게 읽고 쓸 수 있습니다.
안정성: 전원이 갑자기 차단되어도 데이터가 손상될 확률이 적습니다.
2. MicroPython에서 NVS 사용하기
MicroPython은 esp32 모듈 내에 NVS 클래스를 제공합니다.
🛠️ 기본 코드 스켈레톤
Python
3. 실전 활용: 부팅 횟수 카운터 만들기
ESP32-C3가 켜질 때마다 숫자를 1씩 증가시켜 NVS에 저장하는 간단한 예제입니다.
Python
4. ESP32-C3 사용 시 주의사항
쓰기 횟수 제한: NVS는 플래시 메모리를 사용합니다. 수만 번 이상의 반복적인 쓰기는 메모리 수명을 단축시킬 수 있으므로, 루프 내에서 무분별하게 commit()을 호출하는 것은 피해야 합니다.
데이터 타입 제한: MicroPython의 NVS 구현은 주로 i32(정수)와 blob(바이너리 데이터)을 지원합니다. 부동소수점(Float)을 저장하려면 바이너리로 변환하거나 100을 곱해 정수로 변환하여 저장하는 트릭이 필요합니다.
네임스페이스 관리: 여러 라이브러리를 사용할 경우 네임스페이스(NVS("이름"))를 구분하여 데이터 충돌을 방지하세요.
5. 마치며
ESP32-C3는 저전력과 효율성이 강조된 칩인 만큼, 굳이 무거운 파일을 만들지 않고도 설정을 유지할 수 있는 NVS 활용은 필수적입니다. Wi-Fi 정보나 마지막 센서 상태값을 저장해두어 스마트한 IoT 기기를 만들어보세요!
** NVS 활용방법 **
1. 스마트 기기 설정값 관리 (Wi-Fi 정보 및 API 키)
파일 시스템(LittleFS)에 config.json을 만들어 관리할 수도 있지만, NVS를 쓰면 파일 파손 위험이 적고 접근 속도가 빠릅니다.
활용 예시: 사용자가 설정한 Wi-Fi SSID, 비밀번호, 센서 보정(Calibration) 값, 클라우드 서버 API 토큰 저장.
장점: 설정값이 바뀌어도 코드 수정 없이 NVS의 특정 키값만 업데이트하면 됩니다.
Python
2. 장치 상태 복원 (Last State Save)
갑작스러운 정전이나 재부팅 후에도 장치가 **”이전의 상태”**를 기억해야 할 때 유용합니다.
활용 예시:
스마트 전구: 전원이 꺼지기 전 마지막 밝기와 색상 유지.
스마트 팜: 마지막으로 물을 준 시간 기록.
산업용 카운터: 누적 생산량 카운트 유지.
팁: 상태가 바뀔 때마다 쓰기보다는, 특정 주기나 임계값이 변했을 때만 commit() 하여 플래시 메모리 수명을 보호하세요.
3. Deep Sleep 데이터 전달
ESP32-C3의 Deep Sleep 모드에 들어가면 RAM의 모든 데이터가 사라집니다. 이때 RTC Memory를 쓸 수도 있지만, 데이터가 복잡하거나 전원이 아예 차단될 가능성이 있다면 NVS가 정답입니다.
활용 예시: 딥슬립에서 깨어날 때마다 센서 데이터를 NVS에 누적 저장한 뒤, 10개가 쌓이면 한꺼번에 서버로 전송.
Python
4. OTA(Over-the-Air) 펌웨어 업데이트 상태 기록
무선으로 펌웨어를 업데이트할 때, 업데이트 진행 단계나 성공 여부 플래그를 NVS에 저장합니다.
활용 예시: 업데이트 도중 재부팅되었을 때 NVS를 읽어 “아직 업데이트 중”임을 인지하고 작업을 재개할 수 있습니다.
NVS를 적절히 활용하면 단순한 임베디드 코딩을 넘어, 실제 상용 제품 수준의 안정적인 시스템을 구축할 수 있습니다.
** NVS 용량은 어느정도인가? esp32-c3 mini 의 경우 **
ESP32-C3 Mini와 같은 모듈에서 MicroPython을 사용할 때, NVS의 용량은 ‘파티션 테이블(Partition Table)’ 설정에 따라 결정됩니다. 하지만 일반적인 사용 환경에서의 기준은 다음과 같습니다.
1. 기본 할당 용량 (Default)
따로 설정을 건드리지 않고 공식 MicroPython 펌웨어를 올렸다면, 보통 24KB (0x6000 bytes) 정도가 NVS 영역으로 잡혀 있습니다.
실제 사용 가능량: 내부 관리용 헤더와 메타데이터(약 4~8KB)를 제외하면, 실제로 우리가 데이터를 저장할 수 있는 공간은 약 15~18KB 정도입니다.
저장 가능 개수: 아주 작은 정수나 짧은 문자열 기준으로는 약 100~200개 이상의 Key-Value 쌍을 저장할 수 있습니다.
2. 최대 확장 가능 용량
만약 24KB보다 더 큰 공간이 필요하다면, 파티션 테이블을 직접 수정하여 NVS 용량을 늘릴 수 있습니다.
이론적 한계: NVS 파티션은 수 MB 단위까지 키울 수 있습니다.
권장 한계: 에스프레시프(Espressif) 가이드에 따르면, NVS는 64KB 이하로 유지하는 것을 권장합니다.
이유 1 (속도): NVS는 데이터를 찾을 때 인덱스를 훑어야 하므로, 용량이 너무 크면 읽기/쓰기 속도가 느려집니다.
이유 2 (RAM): NVS를 초기화할 때 파티션 크기에 비례하여 RAM(Heap)을 사용합니다. (1MB당 약 22KB의 RAM 소모)
3. 데이터 유형별 크기 제한
용량만큼 중요한 것이 한 번에 저장할 수 있는 데이터의 크기입니다.
데이터 타입
최대 크기 제한
비고
정수 (Integer)
64-bit (8 bytes)
set_i32, set_i64 등으로 저장
문자열 (String)
4,000 bytes
종료 문자 포함
바이너리 (Blob)
약 500 KB
파티션 크기의 97.6% 또는 508,000 bytes 중 작은 값
4. 요약 및 제안
간단한 설정값(Wi-Fi, ID, 보정값): 기본 24KB로도 차고 넘칩니다.
큰 데이터(이미지, 로그 파일, 긴 텍스트): NVS 대신 **LittleFS(파일 시스템)**를 사용하세요. NVS는 “설정값 저장용”이지 “데이터베이스나 파일 저장용”이 아닙니다.
ESP32-C3 Mini 주의점: 보통 4MB 플래시를 탑재하고 있는데, NVS를 너무 크게 잡으면 펌웨어가 들어갈 자리나 일반 파일 저장 공간이 부족해질 수 있으니 주의해야 합니다.
결론: 특별한 설정 없이 사용하신다면 약 15KB 내외의 데이터를 Key-Value 형태로 쪼개서 저장한다고 생각하시면 가장 안전합니다!
** 파일로 저장 vs NVS 저장 비교 **
open("config.txt", "w") 같은 방식으로 파일을 직접 다루는 것이 훨씬 직관적이고, PC에 연결했을 때 내부를 직접 들여다볼 수 있어 디버깅도 편하죠.
그럼에도 불구하고 왜 임베디드 전문가들이 NVS를 따로 사용하는지, 파일 시스템(LittleFS/FAT)과 비교해 장단점을 명확히 짚어 드릴게요.
1. NVS vs 파일 시스템(File System) 비교
비교 항목
NVS (Key-Value)
파일 시스템 (open/write)
저장 방식
키-값 쌍 (딕셔너리 형태)
전체 파일 (바이트 스트림)
안정성
매우 높음 (원자성 보장)
상대적으로 낮음 (전원 차단 시 깨짐)
속도
빠름 (특정 값만 즉시 수정)
느림 (파일 전체를 읽고 써야 함)
메모리 수명
분산 저장으로 플래시 보호
동일 위치 반복 쓰기로 수명 단축 위험
직관성
코드 안에서만 확인 가능
파일 탐색기에서 바로 확인 가능
2. 왜 NVS가 더 유리할까? (장점)
① 전원 차단에 대한 내성 (Atomic Write) 파일 시스템의 최대 약점은 **”파일을 쓰는 도중 전원이 꺼지면 파일 자체가 깨질 수 있다”**는 점입니다. 반면 NVS는 내부적으로 트랜잭션 처리가 되어 있어, 쓰기 작업 도중 전원이 나가도 이전 데이터가 유지되거나 최신 데이터가 완전히 저장되는 것을 보장합니다.
② 플래시 메모리 수명 연장 (Wear Leveling) 파일 시스템에서 특정 설정 파일 하나를 계속 수정하면, 실제 플래시 메모리의 같은 물리적 위치를 반복해서 긁게 될 확률이 높습니다. NVS는 데이터를 저장할 때 내부적으로 위치를 골고루 분산시켜 저장하므로 칩의 수명을 더 길게 유지해 줍니다.
③ 부분 수정의 효율성 설정값이 50개인데 그중 ‘밝기’ 하나만 바꾸고 싶을 때:
파일: 전체 파일을 읽어서 메모리에 올리고 -> 값 수정 -> 전체 다시 쓰기 (무겁고 위험)
NVS:nvs.set_i32("bright", 100) 한 줄로 끝. 해당 위치만 갱신 (가볍고 안전)
3. 왜 파일 시스템이 더 편할까? (단점)
① 시각적 확인 불가 질문하신 대로 NVS는 툴을 사용하지 않는 이상 눈에 보이지 않습니다. 파일은 main.py 옆에 config.json이 딱 버티고 있으니 관리하기가 심리적으로 편하죠.
② 복잡한 데이터 구조 NVS는 단순한 숫자나 문자열에는 강하지만, 리스트 안에 딕셔너리가 있고 그 안에 또 리스트가 있는 복잡한 계층 구조를 저장하기엔 파일(JSON 형태 등)이 훨씬 유리합니다.
💡 결론: 언제 무엇을 쓸까?
NVS를 쓰세요:
Wi-Fi 비번, 센서 보정값, 장치 ID 등 시스템 핵심 설정값
장치가 작동 중에 자주 업데이트되는 상태 정보 (부팅 카운트, 마지막 동작 모드 등)
절대 깨지면 안 되는 최소한의 기본값
파일 시스템(open)을 쓰세요:
센서 데이터 로그(CSV), 웹 서버용 HTML 파일 등 데이터 양이 많을 때
PC에서 수시로 파일을 직접 열어서 내용을 확인하거나 수정해야 할 때
복잡한 객체나 대량의 텍스트를 저장할 때
한 줄 요약: “안전하고 가볍게 유지하고 싶은 시스템 설정은 NVS, 덩치가 크고 눈으로 보고 싶은 데이터는 파일“이 정답입니다!
