Vienna sausage

비엔나 소시지 IT 블로그

활동 개요

2026년 5월 21일에는 CareWave의 WiFi CSI 데이터가 실제 서버까지 전달되는지 확인하기 위해 AWS EC2 서버를 생성하고, RuView Docker 환경을 구축했다.

전날 작업이 ESP32-S3 보드에서 CSI 데이터를 출력하는 단계였다면, 이번 작업은 ESP32에서 발생한 데이터가 클라우드 서버로 실제 전송되는지 확인하는 단계였다.

결과적으로 AWS EC2 인스턴스 생성, 보안 그룹 설정, 탄력적 IP 연결, Docker 설치, RuView Docker 실행, ESP32 4대 플래싱 및 프로비저닝, UDP 패킷 수신 확인까지 완료했다.

AWS EC2 Ubuntu 22.04 Docker RuView WiFi DensePose ESP32 UDP 5005 Provisioning

오늘 한 일 요약

  • AWS EC2 인스턴스 생성
  • Ubuntu 22.04 LTS, t2.micro 환경 구성
  • 보안 그룹 인바운드 포트 설정
  • 탄력적 IP 할당 및 EC2 인스턴스 연결
  • EC2에 Docker 설치
  • RuView Docker 이미지 pull 및 실행
  • RuView 웹 UI 접속 확인
  • ESP32 4대 RuView 펌웨어 플래싱
  • ESP32 4대 아이폰 핫스팟 기반 프로비저닝
  • target-ip, target-port, tdm-slot 설정
  • tcpdump로 EC2 UDP 패킷 수신 확인
  • Data source가 esp32로 전환되는 것 확인
  • 콘센트 전원 환경에서도 ESP32 동작 확인

전체 작업 흐름

이번 작업의 전체 구조는 다음과 같다. 

ESP32 4대
    ↓
아이폰 핫스팟 연결
    ↓
EC2 탄력적 IP로 UDP 전송
    ↓
AWS EC2 Ubuntu 서버
    ↓
Docker 기반 RuView 실행
    ↓
UDP 5005 포트로 패킷 수신
    ↓
RuView UI에서 Data source: esp32 확인

즉, 기존에는 ESP32와 노트북 사이에서 Serial Monitor로 데이터를 확인했다면, 이번에는 ESP32가 인터넷을 통해 클라우드 서버로 직접 데이터를 보내는 구조를 검증했다.

1. AWS EC2 인스턴스 생성 및 보안 그룹 설정

EC2 보안 그룹 인바운드 규칙 설정 EC2 보안 그룹 설정 및 탄력적 IP 연결

AWS EC2 인스턴스를 생성한 뒤, RuView와 이후 FastAPI/Spring Boot 연동을 고려하여 필요한 포트를 열었다. 또한 탄력적 IP를 생성하여 EC2 인스턴스에 연결했다.

EC2는 CareWave 시스템에서 ESP32 데이터가 모이는 클라우드 서버 역할을 한다. 로컬 노트북이 아니라 EC2를 사용하는 이유는 ESP32가 실제 설치 공간에서 인터넷을 통해 서버로 데이터를 보내야 하기 때문이다. 

EC2 설정 내용

OS: Ubuntu 22.04 LTS
Instance type: t2.micro
Elastic IP: 43.201.215.82

보안 그룹 인바운드 규칙
SSH 22
TCP 3000
TCP 3001
UDP 5005
TCP 8000
TCP 8080
TCP 3306

각 포트의 의미

  • 22: EC2 SSH 접속용
  • 3000: RuView 웹 UI 접속용
  • 3001: RuView WebSocket 또는 내부 출력 확인용
  • 5005/UDP: ESP32가 CSI/센싱 데이터를 보내는 핵심 포트
  • 8000: 이후 FastAPI 서버용
  • 8080: 이후 Spring Boot 서버용
  • 3306: MySQL 포트

특히 이번 작업에서 가장 중요한 포트는 UDP 5005다. ESP32가 EC2 서버로 데이터를 보낼 때 목적지 포트로 5005번을 사용하기 때문이다.

2. EC2 Docker 설치

EC2 Ubuntu 서버에 Docker 설치 완료 EC2 Docker 설치 화면

EC2 Ubuntu 서버에 Docker를 설치했다. Docker는 RuView를 컨테이너 형태로 실행하기 위해 필요하다.

Docker를 사용하면 RuView 실행 환경을 EC2 서버에 직접 복잡하게 설치하지 않고, 이미 만들어진 이미지 기반으로 실행할 수 있다. 

Docker를 사용한 이유

1. RuView 실행 환경을 빠르게 구성할 수 있음
2. 서버 환경을 컨테이너 단위로 분리할 수 있음
3. 이후 FastAPI, Spring Boot, MySQL도 각각 컨테이너로 확장 가능
4. 배포 및 재실행이 쉬움

3. RuView Docker 이미지 Pull 및 실행

RuView Docker 이미지 다운로드 및 실행 RuView Docker 실행 및 UI 접속 확인

ruvnet/wifi-densepose:latest 이미지를 pull한 뒤 Docker로 실행했다. 이후 브라우저에서 RuView 웹 UI에 접속되는 것을 확인했다.

RuView는 WiFi 신호를 이용한 DensePose 기반 센싱 시스템이다. 이번 작업에서는 EC2에서 RuView Docker를 실행하고, ESP32가 전송한 데이터를 RuView가 받을 수 있는 환경을 구성했다. 

RuView 실행 구조

Docker image:
ruvnet/wifi-densepose:latest

접속 URL:
http://43.201.215.82:3000/ui/index.html

핵심 수신 포트:
UDP 5005

브라우저에서 RuView UI가 정상적으로 열렸다는 것은 EC2 서버, Docker 컨테이너, 보안 그룹 포트 설정이 기본적으로 정상 동작한다는 의미다.

4. ESP32 4대 RuView 펌웨어 플래싱

보드 1, 2 RuView 펌웨어 플래싱 및 프로비저닝 성공 ESP32 보드 1, 2 펌웨어 플래싱 성공

ESP32-S3 보드에 RuView 펌웨어 바이너리를 플래싱했다. 화면에서는 보드 1, 보드 2의 프로비저닝 성공 로그를 확인할 수 있다.

보드 3, 4 펌웨어 및 프로비저닝 성공 ESP32 보드 3, 4 펌웨어 플래싱 성공

COM12, COM13 포트를 사용하는 보드에서도 펌웨어 및 프로비저닝이 성공했다. 총 4대의 ESP32가 RuView 서버로 데이터를 보낼 수 있도록 준비되었다.

ESP32 1~4 재프로비저닝 ESP32 1~4 재프로비저닝 완료

네 대의 ESP32를 다시 프로비저닝하면서 서버 IP, 포트, 슬롯 정보를 맞추는 과정을 진행했다.

전날 작업에서는 ESP32-CSI-Tool 기반으로 CSI_DATA를 확인했다면, 이번 작업에서는 RuView 환경에 맞는 펌웨어 바이너리를 ESP32에 플래싱했다. 

ESP32 4대 작업 내용

보드 1: 이전에 플래싱 완료
보드 2: RuView 펌웨어 플래싱 및 프로비저닝 완료
보드 3: COM12 펌웨어 및 프로비저닝 완료
보드 4: COM13 펌웨어 및 프로비저닝 완료

펌웨어:
RuView 펌웨어 바이너리 4MB 버전

플래싱과 프로비저닝의 차이

플래싱
→ ESP32 안에 실행할 펌웨어를 넣는 과정

프로비저닝
→ ESP32가 어떤 WiFi에 접속할지,
  어느 서버 IP와 포트로 데이터를 보낼지 설정하는 과정

즉, 플래싱은 보드 안에 프로그램을 넣는 과정이고, 프로비저닝은 그 프로그램이 실행될 때 사용할 네트워크 설정을 넣는 과정이다.

5. WiFi 연결 문제와 아이폰 핫스팟 재프로비저닝

처음에는 학교 WiFi인 Duksung_WiFi로 ESP32를 연결하려고 시도했다. 하지만 학교 WiFi는 WPA2-Enterprise 방식이기 때문에 일반적인 SSID와 비밀번호만으로 ESP32를 연결하기 어려웠다.

그래서 아이폰 개인용 핫스팟을 사용하여 ESP32 4대를 다시 프로비저닝했다.

아이폰 핫스팟에 기기 연결 확인 아이폰 핫스팟 기기 연결 확인

ESP32 보드들이 아이폰 개인용 핫스팟에 연결된 것을 확인했다. 화면에는 개인용 핫스팟에 5개의 연결이 표시되어 있다. 

프로비저닝 설정

WiFi: iPhone 개인용 핫스팟
target-ip: 43.201.215.82
target-port: 5005

ESP32 4대 tdm-slot:
보드 1 → tdm-slot 0
보드 2 → tdm-slot 1
보드 3 → tdm-slot 2
보드 4 → tdm-slot 3

tdm-slot이 필요한 이유

ESP32가 여러 대일 때 모든 보드가 동시에 데이터를 보내면 충돌이나 혼잡이 발생할 수 있다. tdm-slot은 각 보드가 데이터를 보내는 시간 구간을 나누기 위한 설정으로 이해할 수 있다. 

ESP32 1번 → slot 0
ESP32 2번 → slot 1
ESP32 3번 → slot 2
ESP32 4번 → slot 3

각 보드가 서로 다른 시간 구간에 데이터를 보내도록 구분

6. ESP32 → EC2 UDP 데이터 수신 확인

ESP32 로그와 EC2 tcpdump 수신 확인 ESP32에서 EC2로 UDP 패킷 수신 확인

ESP32 쪽에서는 CSI collector 로그가 출력되었고, EC2 서버에서는 tcpdump를 통해 UDP 5005 포트로 패킷이 들어오는 것을 확인했다.

4개 포트에서 UDP 패킷 수신 확인 ESP32 4대 UDP 패킷 수신 확인

각 콘센트에 꽂은 ESP32 4대에서 패킷이 들어오는 것을 확인했다. 로그에는 서로 다른 source port로 UDP 패킷이 EC2의 5005 포트로 들어오는 모습이 보인다.

이번 작업에서 가장 중요한 검증은 ESP32에서 EC2 서버로 실제 UDP 패킷이 들어왔는지 확인하는 것이다. tcpdump 로그에서 외부 IP와 여러 source port에서 EC2 내부 주소의 5005 포트로 UDP 패킷이 들어오는 것을 확인했다. 

확인된 UDP source port

118.235.4.75:47165
118.235.4.75:44891
118.235.4.75:33105
118.235.4.75:39692

목적지:
EC2 내부 주소:5005/UDP

이는 ESP32 4대가 핫스팟을 통해 인터넷에 연결되었고, EC2 서버의 UDP 5005 포트까지 실제 데이터가 도달했다는 의미다.

7. RuView UI에서 Data Source 전환 확인

RuView UI에서 esp32 데이터 소스 확인 RuView UI esp32 데이터 소스 확인

RuView 화면에서 Data source가 esp32로 전환된 것을 확인했다. 이는 RuView가 실제 ESP32 데이터를 데이터 소스로 인식했다는 의미다.

RuView UI가 열리는 것만으로는 ESP32 데이터가 들어온다고 볼 수 없다. 하지만 Data source가 esp32로 전환되고, 서버 로그에서 UDP 패킷 수신이 확인되면 ESP32와 EC2 RuView 서버 간 연결이 실제로 동작한다고 볼 수 있다. 

검증 흐름

ESP32 전원 연결
    ↓
아이폰 핫스팟 접속
    ↓
EC2 43.201.215.82:5005로 UDP 전송
    ↓
EC2 tcpdump에서 패킷 확인
    ↓
RuView UI에서 Data source: esp32 확인

8. 실제 공간 설치 및 콘센트 전원 테스트

실제 방 공간에 ESP32 4대 설치 후 테스트 실제 방 공간 ESP32 4대 설치 테스트

실험 공간에 ESP32 4대를 배치하고 콘센트 전원에 연결한 상태로 테스트를 진행했다.

초기 실험에서는 ESP32를 노트북 USB에 연결하여 로그와 전원을 함께 확인했다. 하지만 실제 환경에서는 ESP32가 노트북에 계속 연결되어 있을 수 없기 때문에, 콘센트 전원만으로도 정상 동작하는지 확인하는 것이 중요하다. 

초기 실험
노트북 USB 연결
→ 전원 공급
→ 플래싱
→ 로그 확인

실제 설치 테스트
콘센트 전원 연결
→ ESP32 단독 실행
→ 핫스팟 접속
→ EC2로 UDP 데이터 전송

이번 테스트를 통해 ESP32가 노트북에 연결되어 있지 않아도, 전원만 공급되면 서버로 데이터를 전송할 수 있다는 것을 확인했다.

9. 최종 작업 결과 정리

5월 21일 최종 작업 완료 내용 5월 21일 최종 작업 정리

EC2 생성, 탄력적 IP 할당, RuView Docker 실행, ESP32 4대 플래싱 및 프로비저닝, ESP32에서 EC2로 실제 데이터 수신 확인까지 완료했다.

  • EC2 생성 및 탄력적 IP 연결 완료
  • RuView Docker EC2에 배포 완료
  • ESP32 4대 플래싱 및 프로비저닝 완료
  • ESP32 → EC2 실제 데이터 수신 확인 완료
  • 콘센트 전원 환경에서 ESP32 동작 확인 완료

진행 중

현재 별도로 진행 중인 작업은 없다. 다만 RuView UI에서 노드 수와 키포인트 표시 문제가 남아 있어 다음 작업에서 확인이 필요하다.

내일 할 일

  • FastAPI에서 RuView WebSocket을 구독하는 코드 작성
  • RuView에서 나오는 실시간 데이터를 FastAPI로 받아오는 구조 구현
  • Isolation Forest 기반 이상 탐지 모델 구현
  • LSTM 기반 낙상 판단 모델 구현
  • RuView UI에서 키포인트가 표시되지 않는 원인 확인
  • 노드가 1대로만 표시되는 문제 수정

이슈

1. 노드가 1대로 뜨는 문제

ESP32 4대에서 UDP 패킷이 들어오는 것은 tcpdump로 확인했다. 하지만 RuView UI 또는 API에서는 노드가 1대로만 표시되는 문제가 있었다.

가능한 원인은 다음과 같다.

  • RuView가 여러 ESP32를 개별 노드로 구분하지 못하는 문제
  • tdm-slot 설정은 되었지만 UI에서 node_id가 분리되지 않는 문제
  • 프로비저닝된 장치 식별값이 동일하게 들어간 문제
  • RuView 내부 API에서 최근 활성 노드만 보여주는 문제

2. 키포인트가 표시되지 않는 문제

RuView UI에서는 사람이 표시되는 형태는 보였지만, 기대했던 키포인트가 제대로 뜨지 않는 문제가 있었다.

이는 RuView 쪽 모델 문제일 수도 있고, 입력 데이터 품질, ESP32 배치, 신호 세기, 데이터 source 처리 문제일 수도 있다. 다음 작업에서 로그와 API 응답을 함께 확인해야 한다.

잘된 점

  • EC2 서버 구축부터 RuView Docker 실행까지 한 번에 연결했다.
  • ESP32 4대 플래싱과 프로비저닝을 완료했다.
  • 학교 WiFi 문제를 아이폰 핫스팟으로 우회하여 해결했다.
  • tcpdump로 실제 UDP 패킷 수신을 확인했다.
  • 콘센트 전원에서도 ESP32 데이터 송신이 되는 것을 확인했다.
  • 결과적으로 ESP32 → EC2 → RuView까지 이어지는 1차 실시간 데이터 흐름을 검증했다.

아쉬운 점

데이터가 EC2 서버까지 들어오는 것은 확인했지만, RuView UI에서 기대한 키포인트가 정상적으로 표시되지 않았다. 또한 ESP32 4대를 연결했음에도 노드가 1대로만 보이는 문제가 남아 있다.

따라서 다음 단계에서는 단순히 패킷이 들어오는지 확인하는 것을 넘어서, RuView가 해당 데이터를 어떻게 해석하고 있는지, WebSocket/API 응답에서 어떤 값이 나오는지를 확인해야 한다.

정리

2026년 5월 21일 작업에서는 CareWave의 WiFi CSI 데이터 수집 구조를 로컬 실험에서 클라우드 서버 구조로 확장했다. AWS EC2에 RuView Docker를 올리고, ESP32 4대가 아이폰 핫스팟을 통해 EC2의 UDP 5005 포트로 데이터를 보내는 것을 확인했다.

이번 작업의 핵심 성과는 ESP32가 노트북에 직접 연결되어 있지 않아도, 콘센트 전원과 WiFi 연결만으로 클라우드 서버까지 데이터를 전송할 수 있음을 확인한 것이다. 이는 CareWave가 실제 요양시설이나 방 단위 공간에 설치될 수 있는 구조로 확장되는 중요한 단계다. 

5월 20일
ESP32에서 CSI_DATA 출력 확인

5월 21일
ESP32 4대 → EC2 RuView 서버로 UDP 데이터 전송 확인

다음 단계
RuView WebSocket 구독
FastAPI AI 모델 연동
Spring Boot 알림 서버 연동

← CareWave 목록으로 돌아가기