구축 제안 · 동작 데모 포함

미세먼지 측정 데이터
수집 시스템 구축 제안서

도로변에서 끊기지 않고 쌓이는 데이터를 만드는 것이 이번 과업의 핵심이라고 봅니다

신영진 | 백엔드 개발 · 시스템 운영 파트너

필수 범위를 먼저 만들어 봤습니다

측정값 조회와 CSV 내려받기, 장치 상태 확인까지 실제로 동작하게 구현했습니다

측정값 조회 · CSV

기간·장치·항목으로 걸러 조회하고 같은 조건으로 내려받습니다. 통신 복구 후 뒤늦게 올라온 값은 지연 수신으로 따로 표시합니다

장치 상태

최근 수신 시각과 함께 장치에 몇 건이 쌓여 있는지까지 보여줍니다. 미수신 장치는 경과 시간과 함께 눈에 띄게 표시합니다

도로변 장치에서 실제로 문제가 되는 것

기능 목록에는 한 줄이지만, 현장에 세워두면 아래 네 가지에서 데이터가 깨집니다

1통신 두절도로변은 통신이 자주 끊깁니다. 끊긴 동안 측정값을 장치에 쌓아두고 복구 시 순서대로 올리되, 측정 시각은 실제 측정한 때를 그대로 기록해야 이력이 흐트러지지 않습니다

2전원 차단 후 시각 오차라즈베리파이는 시계를 유지하는 부품이 없어, 전원이 끊겼다 들어오면 시각이 엉뚱하게 잡힙니다. 통신이 되면 자동으로 시각을 맞추고, 통신까지 끊긴 상태라면 시각 부품(RTC)을 추가하는 편이 안전합니다

3습도에 따른 과다 측정미세먼지 센서는 습도가 높으면 실제보다 높게 나옵니다. 비 오는 날이나 새벽에 값이 튀는 원인입니다. 온습도를 함께 저장해 두면 나중에 보정하거나 해당 구간을 걸러낼 수 있습니다

4프로그램 중단장시간 돌다 보면 프로그램이 멈추는 일이 생깁니다. 전원이 들어오면 자동 실행되게 하고, 멈추면 다시 띄우는 구조를 넣어야 현장에 가는 횟수가 줄어듭니다

이 네 가지는 나중에 붙이기 어려운 항목입니다. 특히 1번과 2번은 데이터 구조와 직접 연결되어 있어, 처음부터 들어가야 합니다.

기술 구성과 선택 이유

개발자가 없으시다고 하여 쉬운 표현으로 정리했습니다

장치Python 수집 프로그램

라즈베리파이에서 센서를 읽는 데 가장 널리 쓰이는 방식입니다. 참고 자료가 많아 이후 다른 사람이 손보기도 쉽습니다

전송HTTPS + 장치 키

측정값을 암호화해 보내고, 장치마다 발급한 키로 인증합니다. 아무나 값을 밀어 넣을 수 없게 합니다

서버·DB관계형 DB(PostgreSQL)

시간 순으로 쌓이는 데이터에 적합하고, 기간 조회와 CSV 추출이 빠릅니다. 수년치가 쌓여도 버팁니다

웹PC 웹 화면

설치 없이 브라우저로 접속합니다. 내부 검증용이므로 접근 제한을 두어 외부 노출을 막습니다

부품 후보	의견
온습도 센서 DHT22 vs BME280	BME280을 권장드립니다. DHT22는 값이 간헐적으로 읽히지 않는 경우가 있고 실외 장기 운용에서 불안정한 편입니다. BME280은 연결 방식이 안정적이고 기압까지 함께 측정되어, 나중에 활용 여지가 있습니다
미세먼지 센서 PMS5003 vs PMS7003	측정 성능은 사실상 동일합니다. PMS7003이 더 작아 케이스 설계에 유리합니다. 다만 두 제품 모두 팬이 돌아가는 방식이라 먼지가 쌓이면 값이 변합니다. 주기적 청소 또는 교체 계획을 함께 잡아두시길 권합니다
제어 보드 Pi 4 vs Pi 5	이번 작업량에는 Pi 4로 충분합니다. Pi 5는 발열과 전력 소모가 더 커서 실외 함체에서는 오히려 불리할 수 있습니다

미확정 항목 ① 측정 주기

실시간 / 1시간 단위 중 미정이라고 하셨는데, 그 사이를 제안드립니다

방식	연간 데이터량 (장치 4대 기준)	의견
실시간 (1초)	약 1억 2천만 건	센서 특성상 1초 값은 편차가 커서 그대로 쌓으면 노이즈가 됩니다. 데이터량도 과합니다
1~5분 평균 (권장)	약 40만 ~ 200만 건	차량이 지나갈 때의 변화를 놓치지 않으면서 노이즈는 걸러집니다. 장치에서 1초마다 읽어 평균을 낸 뒤 전송하는 방식입니다
1시간	약 3만 5천 건	도로 미세먼지는 차량 통과에 따라 순간적으로 치솟습니다. 1시간 평균으로는 포집장치 전후 차이가 평균에 묻혀 성능이 드러나지 않을 수 있습니다

권장 — 장치에서 1초마다 읽어 1분 평균으로 저장·전송. 성능 검증이 목적이라면 분 단위가 필요하다고 봅니다. 주기는 장치에 고정하지 않고 설정값으로 두어, 운용해 보시고 5분이나 10분으로 바꾸실 수 있게 만들겠습니다. 데이터가 너무 많다고 판단되시면 나중에 시간별 평균을 따로 만들어 두는 방법도 있습니다.

미확정 항목 ② 대시보드 화면

있으면 좋다는 단계라고 하셨는데, 목적을 생각하면 판단이 갈립니다

만들어 본 대시보드 예시

포집장치 전단과 후단의 PM2.5를 겹쳐 본 화면입니다

1결국 필요해집니다이번 과업의 목적이 포집 제품의 성능을 보이는 것이라면, 전단과 후단을 겹쳐 보는 그림이 결론입니다. 목록과 CSV만 있으면 매번 엑셀로 옮겨 그래프를 그리게 됩니다

2규모는 크지 않습니다데이터가 이미 쌓여 있으므로 그래프 한두 종을 붙이는 작업입니다. 처음부터 새로 만드는 것보다 훨씬 작습니다

3제안전체 대시보드가 아니라 기간·장치를 골라 한 항목을 그래프로 보는 화면 하나를 이번 범위에 넣는 것을 제안드립니다. 조건별 필터와 여러 지표를 한 화면에 모으는 형태는 다음 단계로

4빼실 경우데이터 구조는 그대로이므로 나중에 화면만 추가하면 됩니다. 기존 기능을 고칠 일은 없습니다

성공적인 마무리의 기준

일정을 가장 우려하신다고 하여, 무엇이 되면 끝인지를 먼저 명확히 하고 싶습니다

1며칠간 끊기지 않는 것장치를 실제로 세워두고 최소 3일 이상 연속 수집되며 빠진 구간이 없는 것. 하루 돌려보고 끝내면 현장에서 문제가 드러납니다

2끊겼다 붙어도 메워지는 것통신을 일부러 끊었다 복구했을 때 그 구간 데이터가 빠짐없이 올라오는 것. 이것을 검수 항목으로 넣어 확인하시길 권합니다

3현장에 가지 않고 알 수 있는 것장치가 멈췄을 때 화면만 보고 알 수 있는 것. 이것이 이번 시스템의 실질적인 목적이라고 봅니다

4데이터를 바로 쓸 수 있는 것내려받은 CSV를 가공 없이 분석에 쓸 수 있는 것. 전단·후단 비교가 가능한 형태로 저장 구조를 잡겠습니다

일정에 대해 — 45일 중 소프트웨어 개발 자체는 여유가 있는 편입니다. 다만 부품 수급과 현장 설치가 일정을 좌우합니다. 센서 모델이 확정되어야 장치 프로그램을 실기기로 검증할 수 있으므로, 착수 초기에 센서 1세트만이라도 먼저 확보해 주시면 개발과 하드웨어 준비를 병행할 수 있습니다. 이것이 일정을 지키는 가장 확실한 방법이라고 봅니다.

확인이 필요한 부분

착수 전 또는 초기에 정해주시면 좋을 사항입니다

?장치 대수와 위치전단·후단 비교가 목적이라면 한 지점에 2대가 필요합니다. 몇 개 지점에 몇 대를 세우실지에 따라 구조가 달라집니다

?통신 방식LTE 라우터인지 현장 와이파이인지 — 끊김 빈도와 데이터 요금에 영향이 있어 전송 주기 결정과 연결됩니다

?전원 공급상시 전원인지, 태양광이나 배터리인지 — 전원이 끊기는 환경이라면 시각 부품(RTC) 추가를 권장드립니다

?웹 접근 범위사내에서만 볼지, 외부에서도 접속할지 — 내부 검증용이므로 접근 제한 방식을 정해야 합니다

?특허 측정 방법등록하신 측정 방법이 값을 읽는 방식이나 계산에 반영되어야 하는지 — 그렇다면 저장 구조에 함께 담겠습니다

빠진 구간 없이
쌓이게 만들겠습니다

측정은 한 번 놓치면 그 시점의 데이터를 다시 얻을 수 없습니다.
데모는 직접 눌러보실 수 있습니다.