기본 콘텐츠로 건너뛰기

샤오미 PM2.5 미세먼지 측정기 사용 후기

저희 집에는 애가 셋이나 있습니다.

집에 애가 많으면 먹는것, 입는것 신경 쓸것이 참 많습니다.

좋은것만 해주고 싶은 게 부모 마음이다보니.. 애 있는 집에 공기청정기, 가습기 이런건 다 하나씩 있으시지 않나요? 없으실 수도 있겠지만..

어쨌든, 그래서 저희 집에도 샤오미 공기청정기 1세대 제품이 있습니다.

바로 옆이 산이라서 그다지 공기가 나쁘지는 않은 동네지만, 아파트 바로 옆이 4차선 도로이고 혹시나 해서 구매했던 공기청정기인데 항상 집안의 공기는 아주 아주 좋더군요..

그래서 공기청정기가 작동하는 적이 거의 없습니다.

그런데, 얼마전에 고등어구이가 미세먼지의 주범으로 지목된적도 있고,(누군가는 오해라고 했다..) 꼭 고등어구이가 아니더라하더라도.. 가스렌지를 사용하는 주부의 암 발생율이 매우 높기 때문에 덕트를 꼭 써야 한다는 얘기도 있었고,(하지만 덕트 청소와 필터 교체가 너무 귀찮아서 써본 기억이 없다.) 그런걸로 미루어보면 우리 집 공기가 매일 매일 아주아주 좋다는건 말이 안되는것 같다는 의심과 샤오미 공기청정기에 내장된 미세먼지 측정 센서의 성능이 최악이라는 얘기도 있고.. 이차저차삼차로.. 고민해 본 결과 미세먼지 측정기를 하나 더 장만하면 좋겠다는 아주 합리적이로 당연한 결론에 이르렀다.

그래서 인터넷을 다시 뒤져보았더니...

Awair(어웨어)가 좋다고 하는데.. 비싸고.. 그닥 이런것까지는 필요 없는 것 같고.. 가장 중요한건 샤오미 공기청정기와 연동하고 싶은데.. 메일로 물어봐도 답도 없드라.. 넌 OUT!!!

다시 인터넷을 뒤져보니.. 샤오미에서 만든 미세먼지 측정기가 있다는 것이었다..

음.. 그닥 믿음은 안가지만 샤오미 공기청정기와 연동도 된다하니.. 중고로 넙죽 하나 구해보았다.

미세먼지를 얼마나 정밀하고 정확하게 측정하는지는 전문가가 아닌 나로서 판단을 내릴 부분은 아닌 것 같지만, 개인적으로 샤오미 공기청정기에 내장된 센서보다는 정확한것 같다.

이 측정기를 구매하게 된 동기인 가스렌지 옆에 위치시켜보았더니.. 무언가를 굽거나 끓이면 확실하게 경고를 울리기는 한다.. 나는 그거 하나로 만족하기로 했다.

가장 좋은 점은 샤오미 공기청정기와 연동시켜서 공기가 나빠지면 자동으로 공기청정기가 동작하도록 할 수 있다.(그런데, 막상 설정해보면 10번 중에 한 2~3번은 실패한다. 이유는 모르겠지만..)

샤오미 미세먼지 측정기의 단점이라면 시계로 설정은 할 수 있는데, 시간을 설정을 못한다는 것이다. 때문에 시계로 설정을 하면 중국 베이징 시간이 나온다. 1시간 차이가 난다. 이런건 좀 설정할 수 있게 해주면 좋으련만.. 
그리고, 시계로 설정하지 않으면 Night Mode라고 정해진 시간이 되면 LCD 밝기를 줄이는 기능이 동작하지 않는다. 즉, Night Mode는 시계가 활성화되어야만 동작을 하는건데, 앱에서는 그런거 상관없이 활성화가 된다. 처음에 이게 왜 동작을 안하는건지 한참 고민했었다.

또 하나 이걸 단점이라고 하기는 애매모호한데, 이 앱이 측정하는 게 꼭 미세먼지만은 아니다. 무슨 얘기인고 하니.. 수증기도 미세먼지로 취급한다. 아침에 밥을 하면서 엄청난 수증기가 나오면 이 측정기는 그게 미세먼지인줄 알고 난리 부르스이다..ㅡ.ㅡ 뭐.. 그래도 아침에 공기청정기 한번 돌린다 생각하고 그냥 그러려니 하고 있다..

장점이라면 작고 이쁘고, 샤오미 공기청정기와 연동이 된다는 것이다.
그리고 기록이 계속 누적되기 때문에 언제 공기가 좋지 않았고, 언제 공기가 좋았는지 볼 수 있다. 

샤오미 제품으로 집안을 꾸미고 있는 사람이라면 한번 구매해 보는 것도 괜찮을 것 같다.

이 제품의 사용법은 딱히 설명드릴 것 없이 기존에 샤오미 제품을 사용해 보셨던 분이라면 금방 사용 가능할 정도로 단순하다. 그리고 앱이 중국어로 나오는건 구글 번역 앱으로 번역하면 대충 이해할 수 있어서..(구글 번역 앱이 없었다면.. ㅠㅠ)

그래도 혹시 궁금한게 있으시다면 댓글로...


댓글

이 블로그의 인기 게시물

피드백 루프: AI 시대 테스터가 지켜내야 할 핵심 엔진

소프트웨어 개발과 테스팅 현장에서 가장 자주 언급되지만, 막상 시스템이 복잡해질수록 쉽게 경시되곤 하는 핵심 개념이 바로 '피드백 루프(Feedback Loop)'입니다. 코드를 수정하고, 빌드하고, 테스트 결과를 확인하고, 다시 개선하는 그 순환 과정의 속도와 정확도가 결국 소프트웨어의 품질을 결정짓기 때문입니다. 품질 전문가 매슈 하이저(Matthew Heusser)가 자신의 블로그 Quality Remarks에 기고한 "One Loop After Another" 아티클은 바로 이 피드백 루프의 다층적 구조와, AI 시대에 우리가 놓치지 말아야 할 품질 검증의 본질을 날카롭게 되짚어 줍니다. (출처: Quality Remarks - One Loop After Another / Matthew Heusser) https://qualityremarks.com/one-loop-after-another/ 매슈 하이저는 소프트웨어 개발 생태계가 단순히 하나의 커다란 테스트 루프로 돌아가는 것이 아니라, 시간 축과 관점에 따라 겹겹이 쌓인 '연쇄적인 피드백 루프들(One Loop After Another)'로 이루어져 있다고 설명합니다. 초단기 루프 (Inner Loop): 개발자가 코드를 작성하는 몇 초~몇 분 단위의 루프입니다. 단위 테스트(Unit Test)나 IDE의 Linter, AI 자동 완성이 즉각적인 피드백을 주는 영역입니다. 단기 루프 (Daily / CI Loop): 커밋과 푸시가 이루어지고, CI/CD 파이프라인에서 통합 테스트와 정적 분석이 실행되는 몇 시간 단위의 루프입니다. 중기 루프 (Iteration / Exploration Loop): 스프린트 단위로 탐색적 테스팅(Exploratory Testing)을 수행하고, 실제 사용자 시나리오나 엣지 케이스를 사람이 직접 검증하며 시스템의 유기적 작동을 확인하는 며칠~몇 주 단위의 루프입니다. 장기 루프 (Outer / Market Loop): 실제 ...

에이전틱 AI 프로젝트에서 테스터의 5가지 핵심 원칙

AI 코딩 에이전트와 자율형 에이전트가 빠르게 개발 워크플로우에 통합되면서, 단순히 코드를 잘 짜는 것을 넘어 '에이전트와 어떻게 협업하고 통제할 것인가'가 개발자와 아키텍트들의 가장 큰 화두로 떠올랐습니다. 윤석찬 님의 아티클 "AI 에이전트 시대, 개발자는 어떻게 일해야 하는가? – 프론티어 엔지니어링의 10가지 원칙"은 에이전틱 AI 시대에 엔지니어가 마주하는 패러다임 변화와, 실무 현장에서 일하는 방식을 어떻게 재정의해야 하는지 아주 명확한 가이드라인을 제시해 줍니다. (출처: channy.creation.net - 윤석찬 님의 블로그) https://channy.creation.net/blog/1989 비록 대규모 에이전트 오케스트레이션이나 초거대 인프라 시스템을 개인이 직접 구축하고 운용하는 것은 비용적·기술적으로 현실적인 한계가 있습니다. 하지만 개인 프로젝트에서 AI와 바이브 코딩(Vibe Coding)을 활용하며 겪었던 맥락 손실, 환각, 통제 불능의 경험들을 떠올려보면, 이 아티클이 제시하는 10가지 프론티어 엔지니어링 원칙은 소규모 개인 개발 환경에서도 대단히 깊은 공감을 불러일으킵니다. 이 글은 단순히 "AI 도구를 잘 쓰자"는 수준에 머무르지 않습니다. AI 에이전트가 생성해내는 불확실성 속에서 인간 엔지니어가 시스템의 맥락을 주도하고, 오작동을 제어하며, 품질의 키(Steering Wheel)를 쥐기 위한 구조적 사고법을 다룹니다. 그렇다면 프론티어 엔지니어링의 원칙을 바탕으로, 시스템의 신뢰성과 안전성을 검증해야 하는 테스터는 과연 어떤 실무 원칙을 세워나갈 수 있을까요? 윤석찬 님이 제시한 엔지니어링 원칙을 테스팅 관점으로 재해석해 보면, 다음과 같은 5가지 원칙으로 정리할 수 있을 것 같습니다. 1. 결정론적 검증에서 '경계선 및 허용 오차(Boundary)' 테스팅으로 전환하라 에이전트 기반 시스템은 같은 입력을 주어도 매번 다른 추론 경로를 거치는 확률적(Stoc...

에이전틱 AI 시대에 테스팅은?

 "소프트웨어 엔지니어링은 과연 끝난 것일까?" 최근 AI 코딩 에이전트와 바이브 코딩(Vibe Coding)의 급부상 속에서, 엔지니어들과 아키텍트들이 스스로에게 던지는 가장 뼈아픈 질문입니다. 이 질문에 대해 기술 현장의 날카로운 시선을 담은 이원국 님의 아티클 "소프트웨어 엔지니어링의 종말"과 arXiv 논문 "Agentic Software: How AI Agents Are Restructuring the Software Paradigm"은 아주 근본적인 패러다임의 변화를 짚어내고 있습니다. (출처: blog.wonkooklee.com - 소프트웨어 엔지니어링의 종말) https://blog.wonkooklee.com/blog/20260913_02/ (출처: arXiv - Agentic Software: How AI Agents Are Restructuring the Software Paradigm) https://arxiv.org/html/2606.05608v2 이원국님의 아티클과 논문에서 공통적으로 말하는 핵심은, 우리가 알고 있던 '인간이 직접 코드를 다듬고 작성하던 전통적 소프트웨어 엔지니어링'의 정체성은 종말을 고하고 있으며, 그 자리를 '에이전트 패러다임(Agentic Paradigm)'이 빠르게 대체하고 있다는 사실입니다. arXiv 논문 "Agentic Software"에서는 소프트웨어 구축의 단위가 단순히 결정론적(Deterministic) 알고리즘이나 코드에서, 목표를 스스로 자율 추론하고 도구를 호출하며 과업을 완수하는 'AI 에이전트 오케스트레이션'으로 이동하고 있음을 말하고 있습니다. 이제 개발자는 시스템의 메서드나 API 하나하나를 직접 타이핑하는 존재가 아닙니다. AI 에이전트가 코드를 생성하고, 실행하고, 테스트를 돌리고, 스스로 디버깅하는 일련의 자율 루프(Autonomous Loop)를 설계하는 '시스템...