4편 Hammerspoon Polling은 왜 버리고 Event 기반 자동화를 선택했을까? 오래 사용할 자동화는 설계부터 다르다

3편에서는 Hammerspoon을 이용해 집에서는 Tailscale을 자동으로 종료하고, 외출하면 자동으로 실행하는 프로젝트를 구현했습니다. 처음에는 30초마다 홈서버를 확인하는 Polling(주기적 확인) 방식으로 만들었고, 기능 자체는 원하는 대로 동작했습니다.

하지만 며칠 동안 실제로 사용하면서 또 하나의 문제를 발견했습니다. 이번에는 코드가 아니라 자동화의 설계 방식 자체였습니다. 기능은 정상적으로 동작했지만, ‘오랫동안 사용할 자동화’라는 기준으로 보면 개선해야 할 부분이 분명히 존재했습니다.

이번 글에서는 왜 Polling 방식을 버리고 Event 기반 자동화로 변경했는지, 그리고 자동화를 설계할 때 어떤 기준으로 판단해야 하는지 실제 경험을 중심으로 소개합니다.

---

자동화는 성공했지만 만족스럽지는 않았다.

자동화를 처음 완성했을 때는 꽤 만족스러웠습니다. 집에서는 VPN이 자동으로 종료되고, 외출하면 자동으로 실행되었습니다. 처음 목표했던 기능은 모두 구현되었습니다. 실제로 며칠 동안 사용하면서도 원하는 결과는 정확하게 얻을 수 있었습니다.

하지만 Hammerspoon Console을 계속 열어두고 로그를 살펴보니 조금 이상한 점이 보이기 시작했습니다. 집에 계속 있는데도 30초마다 홈서버를 확인하고, 이미 종료된 Tailscale에 다시 종료 명령을 보내고 있었습니다. 외부에서도 마찬가지였습니다. 이미 실행 중인데도 일정 시간마다 다시 실행 명령을 반복하고 있었습니다.

사용자는 이 과정을 거의 느끼지 못합니다. 하지만 자동화 입장에서는 불필요한 작업을 계속 반복하고 있었던 것입니다.

Polling 방식의 장점과 한계

Polling은 일정한 시간 간격으로 상태를 확인하는 가장 단순한 방식입니다. 구현이 쉽고 대부분의 환경에서 안정적으로 동작하기 때문에 많은 자동화 프로젝트에서 처음 선택하는 방법이기도 합니다.

예를 들어 이번 프로젝트에서는 30초마다 Ubuntu 홈서버에 Ping을 보내고, 응답 여부에 따라 Tailscale을 실행하거나 종료하도록 만들었습니다. 구현도 간단했고, 테스트도 쉬웠습니다.

하지만 Polling 방식에는 구조적인 단점이 있습니다.

• 상태가 변하지 않아도 계속 확인한다.
• 이미 실행된 작업도 반복해서 실행한다.
• 로그가 불필요하게 많아진다.
• 장시간 사용할수록 비효율이 누적된다.

이번 프로젝트는 단순히 ‘동작하면 끝’이 아니라 매일 사용하는 자동화를 만드는 것이 목표였기 때문에, 더 좋은 구조를 고민하기 시작했습니다.

자동화의 핵심은 ‘변화’다.

며칠 동안 프로젝트를 사용하면서 스스로에게 질문을 하나 던졌습니다.

30초마다 확인할 필요가 있을까?

생각해 보면 집에 계속 있는 동안에는 아무런 변화가 없습니다. 외부에 계속 있는 동안에도 마찬가지입니다. 자동화가 필요한 순간은 단 하나입니다.

• 집에서 외부로 이동하는 순간
• 외부에서 집으로 돌아오는 순간

즉, 자동화는 시간을 기준으로 동작하는 것이 아니라 ‘상태가 바뀌는 순간’에만 실행되면 충분했습니다.

이 생각이 Polling에서 Event 기반 자동화로 넘어가는 결정적인 계기가 되었습니다.

Event 기반 자동화란 무엇인가?

Event 기반 자동화는 일정 시간마다 확인하지 않습니다. 대신 운영체제에서 특정 이벤트가 발생했을 때만 자동화를 실행합니다.

macOS에서는 생각보다 다양한 이벤트를 감지할 수 있습니다.

• Wi-Fi 변경
• 네트워크 연결 변경
• 절전 모드 진입
• 절전 모드 해제
• 앱 실행
• 앱 종료
• 모니터 연결
• 배터리 상태 변경

이번 프로젝트에서는 그중에서도 네트워크 변경 이벤트와 절전 해제 이벤트를 사용하기로 했습니다. 사용자가 집을 나가거나 돌아오면 대부분 네트워크 환경이 바뀌기 때문입니다.

상태를 기억하도록 만들었다.

Event 기반으로 바꾸면서 한 가지 기능을 더 추가했습니다. 바로 현재 상태를 기억하는 것입니다.

예를 들어 현재 집에 있는 상태라면 HOME이라는 값을 저장합니다. 이후 네트워크 이벤트가 발생해도 여전히 HOME이라면 아무 일도 하지 않습니다.

반대로 외부로 이동해 AWAY 상태가 되면 그때만 Tailscale을 실행하고 상태를 AWAY로 변경합니다. 이후에는 계속 외부에 있어도 다시 실행하지 않습니다.

이 구조를 적용하면서 자동화는 훨씬 자연스럽게 동작하기 시작했습니다. 사용자는 존재조차 의식하지 못하지만 필요한 순간에는 정확하게 반응하는 자동화가 완성된 것입니다.

이번 프로젝트에서 가장 중요했던 것은 코드가 아니었다.

이번 프로젝트를 돌아보면 가장 오래 고민했던 부분은 Lua 문법도 아니었고, Hammerspoon API도 아니었습니다. 오히려 ‘무엇을 기준으로 자동화를 설계할 것인가’였습니다.

처음에는 GPS를 생각했습니다. 그다음에는 Wi-Fi 이름을 사용하려 했습니다. 이후에는 홈서버 Ping을 기준으로 바꾸었고, 마지막에는 Event 기반 구조로 개선했습니다.

결국 자동화의 품질을 결정하는 것은 코드가 아니라 설계였습니다. 어떤 기준으로 판단하고, 언제 실행하며, 언제 아무것도 하지 않을지를 결정하는 과정이 훨씬 중요했습니다.

앞으로의 자동화는 더 똑똑해질 것이다.

이번 프로젝트는 단순히 VPN을 자동으로 켜고 끄는 것으로 끝나지 않습니다. Event 기반 자동화라는 구조를 갖추면서 앞으로 더 많은 기능을 쉽게 추가할 수 있게 되었습니다.

예를 들어 집에 도착하면 Docker Desktop을 자동 실행하거나, Obsidian을 열거나, 특정 개발 환경을 준비하는 것도 같은 방식으로 구현할 수 있습니다. 반대로 외출하면 불필요한 프로그램을 종료하거나 절전 설정을 변경하는 것도 가능합니다.

즉, 이번 프로젝트는 하나의 자동화를 만든 것이 아니라 앞으로 만들 모든 자동화의 기반을 만든 셈입니다.

---

다음 편 예고

마지막 편에서는 지금까지 만든 자동화를 하나의 완성 프로젝트로 정리합니다. 전체 코드와 설정 파일을 공개하고, 초보자도 그대로 복사해 사용할 수 있도록 설치부터 테스트까지 단계별로 설명합니다. 또한 Hammerspoon으로 추가로 구현할 수 있는 실전 자동화 아이디어도 함께 소개할 예정입니다.

---

참고할 만한 공식 자료

• Apple Developer Documentation – Hammerspoon – Hammerspoon의 Event 기반 자동화 구현과 macOS 이벤트 감지 방법에 대한 공식 개발자 문서로, 글에서 소개하는 자동화 설계와 기술적 배경 이해에 도움을 줌
• Wikipedia – Polling – Polling 방식과 Event 기반 자동화의 차이점을 이해하는 데 참고할 수 있는 컴퓨터 과학 분야 신뢰도 높은 원문 자료

---

더 많은 프로그램 활용법과 리뷰는 프로그램 카테고리에서 확인할 수 있습니다.