▲

Home Assistant, adguard home, 8달러 스마트 콘센트를 활용한 브레인 로트 방지

 (romanklasen.com)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 인터넷 중독과 지속적 소셜 미디어 이용 문제를 해결하기 위한 실용적 방법 소개임
  • Adguard Home과 Home Assistant를 활용해 사용자가 직접 접근 제어를 적용할 수 있는 시스템 구성임
  • Zigbee 스마트 플러그를 활용하여 일정 시간만 소셜 미디어 접근을 허용하고, 이후 쿨다운 시간을 도입함
  • Adguard Home API 연동을 통해 필터링 규칙의 동적 온오프 제어가 가능함
  • 작은 자동화로 자기절제와 사용량 제한을 실천하는 접근법임

서론

인터넷은 필수적인 존재이면서 동시에 광고, 소셜 미디어 중독, 불필요한 콘텐츠 등 다양한 부정적 영향을 주는 매체임
필자는 소프트웨어 개발자로서 인터넷의 필요성을 인식하고 있으나, 사회적 미디어의 반복 사용 및 광고 등 부정적 요소 관리가 개인 과제임
과거 네트워크 차단 프로그램(Adblocker)으로 소셜 미디어를 막아봤지만, 모바일 데이터로 이를 쉽게 우회할 수 있었고, 완전한 차단은 현실적이지 않았음
가정 내 다른 구성원(예: 아내)도 업무나 연구를 위해 소셜 미디어가 필요해 완전 차단은 불가능했음
이러한 이유로 적절한 절제와 접근 권한 조절이 필요해짐

실마리와 아이디어

Hacker News에서 Neil Chen이 스마트 플러그와 ublock Origin 리스트 재작성으로 소셜 미디어 접근 일시 허용 아이디어를 제안함
해당 방법은 실용적이지 않아, 필자 환경에 맞게 Adguard Home과 Home Assistant를 활용해 아이디어를 변형 적용함

구성 요소

  • Adguard Home이 설치된 gli.net 라우터
  • Home Assistant 스마트홈 서버
  • 여러 개의 Zigbee 스위치
  • 약간의 여유 시간

이 모든 구성요소를 조합하여 네트워크 기반 자동화 접근 제어를 구현할 수 있음

계획

  • 버튼(예: Zigbee 플러그) 하나를 눌러 15분간 소셜 미디어 접근 허용
  • 이후 1시간 쿨다운이 적용되어 재사용까지 대기 시간 필요
  • 이 접근법을 통해 집안 구성원이 제한된 시간 동안만 자유롭게 소셜 미디어 이용 가능함

Adguard Home 라우터 설정

  • Adguard Home은 gli.net의 OpenWRT 커스텀 펌웨어에 통합되어 있음
  • 차단 또는 허용을 원하는 서비스들을 custom rule로 직접 등록해야 함
  • 내장 서비스는 토글이 불가능하므로 사용자 지정이 필수임

Adguard Home API 접근

  • Adguard Home은 OpenAPI 기반의 API를 제공함
  • API를 사용하려면 계정 및 비밀번호를 등록해야 하는데, 기본 인터페이스에서는 이를 지원하지 않음
  • 포럼 안내에 따라 /etc/Adguard/config.yaml 파일을 수정하여 별도의 API 접근용 비밀번호를 수동 등록 가능
  • 비밀번호는 bcrypt로 해싱하여 저장 필요

Home Assistant 연동

  • Home Assistant에서 Adguard Home의 제한적 기능 연동이 가능
  • "Filtering" 스위치 형태로 커스텀 필터 규칙 적용 여부를 자동화로 전환할 수 있음
  • 해당 엔티티를 활용해 사용자가 원하는 순간에 네트워크 접근 정책을 애플리케이션 차원에서 변경 가능

Home Assistant 자동화

  • 실제로 동작하는 자동화 예제가 적용되어 있음
  • 버튼을 누르면 규칙 비활성화 및 재활성화까지 전체 프로세스를 관리함
  • 실행 시간과 쿨다운 시간 모두 자동화에 포함되어 사용자의 습관적 사용량 제한에 도움을 줌

결론 및 소감

  • 와이파이 자체를 꺼버릴 경우 우회 가능성이 있음
  • 하지만 이 방식은 사용 패턴 자체를 절제하는 데 실질적 도움 제공
  • 독, 즉 중독적 요소도 소량이라면 참을만하다는 관점에서 부분적 접근 통제가 유익함
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 산만함에서 벗어나기 위해 너무 복잡한 시스템을 만들고, 그 내용을 또 글로 쓰는 것은 정말 전형적인 Hacker News 스타일의 행동임을 느낄 수 있음

    • 문제 행동을 발견하고 외부적 제약으로 그 행동을 통제하는 것은 충분히 합리적인 방법이라는 생각임. 금연자가 담배를 들고 다니지 않는다고 비난하는 것과 비슷한 뉘앙스가 느껴짐
    • 요즘에는 복잡한 문제에는 현대적인 해법이 필요하다는 인식이 많음. 하지만 진지하게 말하면, 산만함과 집중력이라는 주제는 정말 어려운 주제임. 나는 동기부여가 강할 때는 어떤 방해도 통하지 않음. 반면에 지루한 일을 할 때는 그 무엇이든, 모든 게 방해가 됨
    • 기술로 인한 문제를 기술로 해결하고 싶어하는 심리, 삶을 지나치게 구조화해서 구조붕괴에서 회복하는 방법조차 구조화하려는 모습, 바로 우리의 현실임
    • 누군가 산만함에서 벗어나려고 너무 복잡한 시스템을 만들어 distractions에서 distractions를 받는 글을 읽고 거기에 댓글다는 게야말로 궁극의 Hacker News적 행동임 ;P
    • 작성자가 일부 스토리를 만들었거나, 아니면 HN 커뮤니티의 성향에 맞게 각색한 부분도 있을 거라는 생각이 들기도 함. 하지만 그 아티클은 길지도 않고 핵심에 집중하면서도 유쾌하고 유익했음. 작성자가 독일인인데 영어가 너무 유창해서 놀람. 정말 능력 있는 테크니컬 라이터임. 즐겨찾기에 추가함. 이런 글 더 보고 싶음

  • 휴대폰 중독 여부를 알기 위한 점진적 난이도별 실험 목록을 제안함
    1단계: 특별한 이유가 없는 날, 하루 종일 휴대폰을 서랍에 넣고 사용하지 않기
    2단계: 특별한 이유가 없는 날, 휴대폰을 서랍에 넣고 한 시간 이상 집 밖에 있기
    3단계: 친구 만나러 가거나, 점심 먹을 때, 장 보러 갈 때 휴대폰을 집에 두기
    4단계: 하루 동안 직장에 갈 때 휴대폰을 집에 두기
    5단계: 주말 전체 동안 휴대폰을 서랍에 넣고 사용하지 않기
    6단계: 여행할 때(휴가나 가족 방문 등) 하루 이상 휴대폰을 집에 두기

    • 이 방법들 좋게 느껴짐. 나도 휴대폰 없이 동네 산책하거나, 행사가 있을 때는 다운타운까지 빼고 나감. 처음엔 어색한데 곧 괜찮아짐. 작년에 인터넷 없이 여행을 했는데 너무 좋았음. 출발 전 TomTom 네비게이션의 오프라인 맵이 최신인지 확인함. 휴대폰은 비상용으로 차에 잠궈놓고 전원까지 꺼둠. 운전을 시작하면서 알림이 절대 오지 않는 평온함을 느꼈음. 실제로 그 알림들이 자주 오는 것도 아닌데, 그럴 수 있다는 사실만으로도 스트레스를 느꼈던 것 같음. 꺼두고 나니 큰 해방감이 있었음
    • 나는 심각하게 중독된 걸 알면서도 끊지 못하는 상태임. 술 중독자가 매일 보드카 한 병씩 마시는 것과 비슷함. 여러 번 끊으려 시도했지만 항상 실패함. 좋은 하루를 보낸 다음날 바로 다시 도로 돌아온 패턴임. 쓸데없이 유튜브 영상이나 물건 검색, 가질 수 없는 직업을 상상하는 데 하루에 5~10시간씩 쓰는 것 같음. 각종 차단 소프트웨어와 전략을 시도했지만 별 효과가 없었음. 복잡한 차단도 결국은 우회 방법이 생기고, 나중에는 아예 차단을 끄는 게 습관이 돼버림. 극단적으로는 집 인터넷을 끊고 폴더폰을 6개월간 쓴 적도 있었음. 화면 보는 시간은 줄었지만, 공공 와이파이가 있는 곳에서 시간 보내거나 의미 없는 TV 시청이 늘었음. 결국 기술적 해답은 없을 수도 있다고 느껴짐
    • 셀룰러 모델의 Apple Watch 사용 추천함. 비상시 연락만 받고 SNS나 산만한 앱엔 접근 제한을 둘 수 있음. 나도 애플워치 산 후 휴대폰 두고 나가는 일이 많아졌음
    • 나는 업무상 보안 구역에서 일하기 때문에 의도하지 않았지만 매일 4단계를 실천하고 있었음
    • 내겐 휴대폰이 기억 장치임. 꼭 휴대폰 없이 있어야 할 때는 반드시 노트와 펜, 그리고 아마 카메라도 챙겨야 함

  • Home Assistant에 깊은 애정이 있음. 예전에 아이가 구형 디지털 카메라를 갖고 놀게 했었음. 나중에 사진을 확인해보니, 한밤중에 집 외관을 찍으러 밖에 나간 사실을 알고 충격을 받음. 아이가 밤중에 스스로 대문을 열고 나가서 사진을 찍고, 다시 들어와 문을 꼭 잠그고 다시 침대로 돌아갔던 것임. 이 일을 계기로 무선 문 센서를 구입해 밤 10시~새벽 6시 사이에 문이 열리면 내 방의 등이 켜지도록 자동화함. 나중에는 모든 출입문과 창문에 센서를 붙이고 아이들이 쓸 수 있는 출입구 전체를 모니터링함. 이 출입구들이 도둑도 쓸 수 있는 곳이니 자연스럽게 방범 시스템도 되는 셈임. 방범 시스템 활성화 시 원격 알림까지 받아볼 수 있음. Home Assistant의 최고 장점은 특정 브랜드 앱이나 생태계에 종속되지 않는다는 점임. 우리 집의 문/창문 센서와 전구 브랜드가 달라도, 하나의 앱으로 모두 제어할 수 있음

    • 내게 제일 흥미로운 부분은 아이가 밤에 집 밖으로 나가 사진을 찍었던 행동임. 혹시 왜 그런 행동을 했는지 아이에게 물어보았는지 궁금함. 어린아이 입장에서 위험을 감수하고 밤에 밖으로 나가 집 사진을 찍으려는 마음이 정말 대단한 호기심임. 우리 아이 중 한 명도 그런 괴짜스러움이 있었을 것 같긴 하지만, 어둠을 무서워해서 실제로는 행동하지 못했을 것임. 참고로 우리 집은 이미 방범 시스템이 설치되어 있었고, 아이들도 그 존재를 잘 알고 있었음
    • 어떤 문/창문 센서를 사용했는지 궁금함
    • 자신도 같은 경험이 있다며, Hyperbole and a Half의 "richard" 만화를 공유함

  • 내 휴대폰에서 효과를 본 방법은 OneSec 앱임. 이 앱은 단축어(앱용), Safari 확장기능(웹사이트용)과 연동되어 접근하려는 차단 콘텐츠 전에 짧은 과제(예: 20초간 호흡법)를 하게 유도함. 시간 지연과 짧은 활동이 내가 지금으로선 원하지 않는 행동임을 상기하는 효과를 줌. 정말 필요해서 해당 플랫폼에 접속하고 싶을 때는 그냥 운동을 하고 들어가면 접근 허가됨. 단점은 Safari 확장에 웹 브라우징 전체 권한을 줘야 한다는 점, 데이터 수집 안 한다고 주장하긴 하지만 신뢰는 각자 선택의 문제임. 앱 차단에는 개인정보 접근 권한은 요구 안함

    • 때론 제일 간단한 해법이 ‘루다이트 식’임, 그냥 휴대폰을 놓고 멀리 떨어져 있기임. 만약 그조차 도저히 불가능하다면, 이미 앱 하나 더 설치하는 것 이상의 근본적인 문제가 있을 수 있다고 생각함
    • iPhone에서도 비슷한 단축어를 만들어 사용할 수 있을지 궁금함

  • 스마트홈 시스템을 선정할 때 내 기준이 있음. 조작 계통은 반드시 AC 전원 기반이거나 혹은 UPS 백업(아니면 둘 다)이어야 함. WiFi/Ethernet이 끊겨도 동작해야 중요하다고 판단하는 항목들에 적용함. 예전 도어벨(Doorbird)은 기계식 차임과 연결이 됐지만, 현재 쓰는 Reolink 모델은 그렇지 않음. 대신 PoE 기반이고 UPS 시스템 연결로 신뢰성 보장함. Reolink는 전원 소켓에 바로 꽂는 별도 차임이 있고, 카메라도 훨씬 나음. 내 IoT기기들은 인터넷에 자유롭게 접근하지 못하게 하며, IoT용 VLAN을 두 종류(일반용, 조금 더 우려되는 기기용)로 구성함. 회사 IT처럼 관리함. Nessus로 보안 점검도 함. Home Assistant 여러 대 관리 중이고, 집/회사/고객사까지 돌보고 있음. 작성자가 고른 스마트 플러그는 일부러 불편하도록(하지만 신뢰성은 챙기게) 설계된 모습임. 모니터링 기능도 포함되어 있을 것 같음. 이건 ‘제대로’ 하는 너드의 모습임

    • PoE to DC 전원 어댑터를 대부분 적용하기 시작했음. UPS를 유틸리티 클로젯에 집중시켜 오래 운영 가능함. 라우터, 스위칭 구성으로 집 전체 전원공급체계를 구축함. 보안카메라, PoE++ 스위치, AP 전부 PoE 기반임. UPS 배터리로 12~14시간 가능, 여차하면 ‘집 전체용 UPS’로 며칠 연장도 가능함. 광 NIU, 케이블 모뎀도 PoE 스플리터로 실어주는 방식임. 아직 변환하지 않은 몇몇 장치들도 있지만 요즘은 귀찮아서 방치함. 포트 수 적은 코어스위치 2개로 이중화해, 한 쪽이 나가도 반은 운영 가능임. AP 밀집도도 괜찮게 설계함. 망 전체 디바이스 수가 엄청나게 늘었음

  • 어떤 광고나 SNS보다도 YAML로 프로그래밍하는 게 뇌에 훨씬 더 치명적이라는 농담임

    • Home Assistant에서는 대부분의 자동화를 더 이상 yaml로 만들 필요가 없음. 본문의 소스코드를 올렸을지 모르지만 실제로는 그래픽 UI로 만들었을 수도 있다고 생각함. Node-Red도 사용할 수 있음

  • 왜 플러그를 쓰고 Zigbee 버튼은 사용하지 않았는지 궁금함

    • 그냥 집에 굴러다니던 플러그가 있어서 썼음, 버튼이 있어서 용도로 충분함. 오히려 장점도 있음. 작은 램프를 플러그에 꽂아둘 수 있고, 14분 후에는 플러그가 2초마다 켜졌다 꺼지면서 시간 종료를 알리고 다소 극적인 효과를 줌
    • 플러그는 버튼이 있고, 수동으로 켜면 이벤트를 발생시킴

  • Neil Chen이 소셜미디어 중독자를 위한 인터넷 필터 잠금 해제 아이디어를 올렸음을 공유함. 이 아이디어로 AdGuard Home 자동화를 만들어 같은 원리를 적용함

    • 멋진 작업에 감사함을 전하는 Neil Chen의 피드백

  • 지금은 네트워크 레벨에서 웹사이트 차단이 불가능함. 브라우저와 모바일이 하드코딩된 DNS 리졸버를 쓰기 시작해서 실효성이 떨어짐

    • 게이트웨이 아래로 흐르는 네트워크 트래픽은 모두 제어 가능함. DNSSEC가 더 어렵게 만들긴 해도, 결국 콘텐츠는 IP 주소에서 오므로 상위 네트워크 장비에서 드롭 가능함. DNSSEC에 대한 위키 설명
    • "브라우저와 폰이 하드코딩된 DNS 리졸버 쓴다"는 것에 출처를 궁금해함. 내가 아는 한, 대부분의 폰과 브라우저는 OS가 DHCP로 받아오는 DNS를 그대로 따름
    • 폰에서 시도해봤던 내용을 공유함. 대부분 앱과 브라우저는 DNS로 충분히 차단 가능함. gli.net 등에서는 "모든 클라이언트의 DNS 세팅 무시"와 "DNS 리바인딩 공격 보호" 설정이 있음. 이러면 라우터만이 유일한 DNS 리졸버가 됨. 수동으로 dig google.com @1.1.1.1 해도 라우터 결과만 나옴. DNS over HTTPS는 막지 못하지만, 이건 원래 막을 수 없게 설계되어 있다고 생각함

  • 나는 Mac에서 Alfred로 글로벌 단축키를 설정해, 누르면 시스템 DNS 리졸버를 1.1.1.1로 바꿨다가 DNS 캐시를 초기화함. 1분 혹은 10분 후 자동 복구됨. 내 디바이스 하나에서만 차단이 풀리고, 전체 네트워크에 영향이 없는 점이 마음에 듦. 아주 간단하게 구성할 수 있음

답변달기