2026년 07월 15일 오늘의 흐름을 읽고, 더 나은 내일을 준비합니다.
BREAKING
3편 집에서는 Tailscale 자동 종료, 외출하면 자동 실행. Hammerspoon으로 만든 첫 번째 실전 프로젝트
프로그램

3편 집에서는 Tailscale 자동 종료, 외출하면 자동 실행. Hammerspoon으로 만든 첫 번째 실전 프로젝트

ryupd 7월 4, 2026 1 min read

1편에서는 왜 Hammerspoon을 사용하게 되었는지 이야기했습니다. 그리고 2편에서는 설치 과정과 함께 여러 가지 자동화 방법을 비교해 보면서 최종적으로 ‘집 서버가 보이면 집이다’라는 기준을 선택하게 된 이유를 설명했습니다.

이제부터는 실제 프로젝트를 시작합니다. 이번 글은 단순한 사용법이 아닙니다. 우리가 실제로 구축하면서 어떤 시행착오를 겪었고, 어떤 방식으로 문제를 해결했는지 그대로 기록한 개발 일지에 가깝습니다. 만약 비슷한 환경에서 홈서버를 운영하고 있다면, 이 과정이 그대로 여러분의 자동화 프로젝트에도 적용될 수 있습니다.


프로젝트 목표는 단 하나였다.

이번 프로젝트의 목표는 매우 단순했습니다.

  • 집에서는 Tailscale을 자동으로 종료한다.
  • 외출하면 자동으로 Tailscale을 실행한다.
  • 사용자는 아무것도 하지 않는다.

단순한 요구사항처럼 보이지만 실제 구현에서는 생각보다 고려해야 할 부분이 많았습니다. ‘집’이라는 조건을 어떻게 정의할 것인지, 자동화는 언제 실행되어야 하는지, 잘못된 판단은 어떻게 막을 것인지 등을 하나씩 해결해야 했습니다.

첫 번째 구현, Wi-Fi 이름으로 집을 판단하기

가장 먼저 구현한 방식은 Wi-Fi SSID를 확인하는 것이었습니다. 집에서는 항상 mesh_mesh라는 무선 네트워크를 사용하고 있었기 때문에, 맥북이 현재 연결된 SSID만 확인하면 쉽게 집인지 외부인지 판단할 수 있을 것이라고 생각했습니다.

실제로 인터넷에서 찾아볼 수 있는 Hammerspoon 예제도 대부분 이 방식을 사용하고 있었습니다. 구현도 어렵지 않았고, 이론적으로도 가장 간단한 방법처럼 보였습니다.

하지만 실제 테스트에서는 예상과 다른 결과가 나왔습니다.

분명 연결되어 있는데, 연결되어 있지 않다고?

맥북은 분명 집 Wi-Fi에 연결되어 있었습니다. Safari도 정상적으로 동작했고, Ubuntu 서버에도 접속할 수 있었습니다. 하지만 Hammerspoon에서 SSID를 읽어오면 빈 값이 반환되거나, 터미널 명령에서도 현재 Wi-Fi 정보를 정상적으로 가져오지 못하는 경우가 발생했습니다.

이 단계에서는 코드가 잘못된 줄 알고 다양한 테스트를 진행했습니다. 접근성 권한을 다시 확인했고, 위치 서비스도 점검했습니다. 터미널 명령을 바꾸고 Hammerspoon Console에서 하나씩 테스트하면서 원인을 찾기 시작했습니다.

하지만 문제는 코드가 아니라 환경이었습니다. 최신 macOS에서는 특정 상황에서 Wi-Fi 정보를 읽는 방식이 이전과 다르게 동작할 수 있었고, 우리가 원하는 자동화 기준으로 사용하기에는 불안정하다는 결론을 내렸습니다.

기준을 바꾸자. 위치가 아니라 서버를 확인하면 된다.

이 시점에서 자동화의 기준을 완전히 다시 생각했습니다.

우리가 정말 알고 싶은 것은 ‘현재 집에 있는가?’가 아니라 ‘현재 집 서버를 직접 사용할 수 있는가?’였습니다. 그렇다면 Wi-Fi 이름도, GPS도 필요하지 않았습니다.

집에는 항상 켜져 있는 Ubuntu 홈서버가 있습니다. 그렇다면 맥북에서 그 서버에 Ping을 보내기만 하면 됩니다. 응답이 오면 집이고, 응답이 오지 않으면 외부입니다.

집 서버가 보이면 집이다.

이 한 문장으로 자동화 기준이 매우 단순해졌습니다.

첫 번째 성공, 하지만 또 다른 문제가 생겼다.

홈서버 Ping 방식은 매우 안정적으로 동작했습니다. 집에서는 서버가 항상 응답했고, 외부에서는 응답하지 않았습니다. 이제 Hammerspoon이 Ping 결과에 따라 Tailscale을 켜거나 끄기만 하면 프로젝트는 끝날 것 같았습니다.

처음 구현은 30초마다 서버를 확인하는 방식이었습니다. 일정 시간마다 Ping을 보내고 결과에 따라 Tailscale을 실행하거나 종료하도록 만들었습니다. 기능은 정상적으로 동작했습니다.

하지만 며칠 동안 사용해 보니 또 하나의 문제를 발견했습니다.

이미 집에 있는데도 30초마다 계속 Tailscale 종료 명령을 실행했고, 외부에서도 이미 실행 중인데 다시 실행 명령을 반복하고 있었습니다. 사용자는 느끼지 못했지만, 자동화는 불필요한 작업을 계속 반복하고 있었던 것입니다.

자동화는 ‘동작’보다 ‘설계’가 중요하다.

많은 사람들이 자동화는 원하는 결과만 나오면 성공이라고 생각합니다. 하지만 실제로 오래 사용할 자동화를 만든다면 이야기가 달라집니다. 불필요한 작업이 계속 반복된다면 로그도 지저분해지고, 시스템 자원도 낭비하게 됩니다.

그래서 자동화를 한 단계 더 개선했습니다.

  • 현재 상태를 기억한다.
  • 집 상태가 계속 유지되면 아무것도 하지 않는다.
  • 외부 상태가 계속 유지되어도 아무것도 하지 않는다.
  • 상태가 바뀌는 순간에만 Tailscale을 제어한다.

즉, 중요한 것은 30초마다 확인하는 것이 아니라 변화가 발생했을 때만 반응하는 것이었습니다.

이때부터 이 프로젝트는 단순한 VPN 자동화가 아니라 이벤트 기반 자동화 프로젝트로 발전하기 시작했습니다.

이번 프로젝트에서 얻은 가장 큰 교훈

이번 프로젝트를 진행하면서 얻은 가장 큰 교훈은 ‘정답처럼 보이는 방법이 항상 가장 좋은 방법은 아니다’라는 점이었습니다.

처음에는 Wi-Fi 이름을 사용하는 것이 가장 쉬운 방법처럼 보였습니다. 그다음에는 GPS를 이용한 위치 기반 자동화도 생각했습니다. 하지만 실제 환경에서는 둘 다 최선의 선택이 아니었습니다.

결국 가장 안정적인 방법은 우리가 이미 가지고 있는 환경을 이용하는 것이었습니다. 항상 켜져 있는 홈서버가 있었기 때문에 그것을 기준으로 삼았고, 오히려 GPS보다 정확하고 Wi-Fi 이름보다 유지보수가 쉬운 자동화가 완성되었습니다.

앞으로 소개할 자동화도 같은 원칙을 따를 예정입니다. 기능을 많이 넣는 것보다, 오래 사용해도 문제가 생기지 않는 구조를 만드는 것이 더 중요하다고 생각합니다.


참고할 만한 공식 자료

  • Tailscale 공식 문서 – 글에서 다룬 Tailscale VPN의 자동 실행 및 종료 관련 공식 정보와 설정 방법을 신뢰성 있게 제공하기 때문에
  • Apple 개발자 문서 – Network Monitoring – macOS 환경에서 네트워크 상태를 탐지하고 이벤트 기반 자동화를 구현하는 방법에 대해 권위 있는 기술 문서를 제공하기 때문에


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

Leave a Comment