ESP32 Mini Web Server

왜 만들었나

작은 매장 안내, 수업용 페이지, 내 소개 페이지처럼 가벼운 웹페이지 하나를 올리려 해도 보통은 PC 서버나 유료 호스팅이 필요합니다. 손바닥만 한 ESP32 보드 하나가 웹서버 역할과 관리 화면까지 맡으면 전원과 Wi-Fi만으로 웹을 운영할 수 있지 않을까 하는 질문에서 시작했습니다.

목표: 전원 꽂고 Wi-Fi만 잡으면 끝

무엇을 만들었나

• 보드가 직접 웹을 제공: HTML·CSS·JS 파일을 Flash나 SD에 넣어 두면 보드가 그대로 서비스합니다.
• 브라우저 관리자 /admin: 파일 업로드·삭제, 메인 페이지 지정, 메모리·네트워크·저장공간·로그 확인을 PC 프로그램 없이 휴대폰 브라우저에서 합니다.
• SoftAP 첫 설정: 처음 켜거나 공유기 연결에 실패하면 보드가 설정용 핫스팟을 띄우고, 192.168.4.1/setup에서 Wi-Fi와 DHCP/고정 IP를 정합니다.
• AI 연동: 외부 AI API(Gemini·OpenAI)를 연결해 자연어로 웹페이지 제작·수정, 파일 조회, 보드 진단과 로그 분석을 요청합니다. 일반 대화와 실제 작업 요청을 나눠 필요한 도구만 켜는 라우터도 만들었습니다.
• 터치 화면 모델: M1(2.8인치)·M3(4.3인치)에는 LVGL 기반 온보드 UI를 올려 Wi-Fi 설정, 접속 QR, 파일 탐색, 라디오·갤러리·음성 입력까지 화면에서 바로 다룹니다.
• 보드 7종 펌웨어: ESP32-C3, S3, S3-N16R8(SD), M1, M3(P4+C6), M4, P4 개발 보드까지 같은 관리 흐름을 하드웨어에 맞게 이식했습니다.
• 케이스 설계: 보드별 케이스를 3D CAD로 모델링하고 여러 차례 개정했습니다(M3는 v3까지).

어떻게 만들었나

1. ESP-IDF 기반 펌웨어
Arduino 대신 ESP-IDF로 작성해 HTTP 서버, Wi-Fi·mDNS, NVS 설정 저장, Flash·SD 파일 시스템을 직접 구성했습니다. M3에서는 LVGL 작업은 코어 1, HTTP·오디오·네트워크 서비스는 코어 0으로 나누어 화면이 끊기지 않도록 했습니다.

2. 메모리와의 싸움
ESP32의 내부 RAM은 수백 KB 수준입니다. 큰 버퍼는 PSRAM으로 옮기고, 프레임버퍼를 LVGL과 LCD가 공유하게 하고, 파일은 작은 조각 단위로 보내는 식으로 메모리 예산을 맞추는 일이 작업의 큰 비중이었습니다. 메모리 예산은 호스트 테스트로도 검사합니다.

3. 공인 IP 없이 외부 공개: 클라우드 중계
집 공유기 안의 보드는 보통 밖에서 접속할 수 없습니다. 포트포워딩 대신 보드가 먼저 Cloudflare Worker에 연결해 기다리는(long polling) 구조를 택했습니다.

1. 보드가 기기 토큰과 함께 /poll 요청을 열어 두고 최대 20초 기다립니다.
2. 방문자가 기기주소.audreaming.com에 접속하면 Worker가 대기 중인 보드에 요청을 넘깁니다.
3. 보드는 응답을 2 KiB 조각으로 나누어 올리고, Worker가 모아 방문자에게 돌려줍니다.
4. 서버에는 기기 비밀키 대신 SHA-256 해시만 저장합니다.

보드 쪽은 "나가는 HTTPS 요청"만 하면 되니 펌웨어가 단순해짐

4. 검증 방식
실기기 외에도 LVGL PC 시뮬레이터로 실제 UI 소스를 렌더링해 화면을 확인하고, Node 기반 호스트 테스트로 AI 키 저장, 대시보드 폴링, 중계 서버 프로토콜 등을 검사했습니다.

결과

• C3부터 ESP32-P4 터치 보드까지 보드 7종에 같은 웹 관리 흐름을 적용
• Cloudflare 중계 서버와 개인 도메인 배포, HTTPS 응답 확인
• 터치 UI 모델(M1·M3)에 런처·라디오·갤러리·AI Agent·음성 입력 앱 구현
• 보드별 케이스 3D 모델링과 반복 개정

배운 점

작은 MCU에서는 기능 하나를 더할 때마다 메모리·전송 크기·작업 분리를 같이 설계해야 했습니다. 기계과 학생으로서 회로와 케이스, 펌웨어, 서버까지 한 제품의 전 구간을 직접 연결해 본 경험이 가장 큰 수확입니다.
다음 목표: 장시간 안정성 시험과 실측 성능 수치 정리