macOS에서 파일 변경 감지하기 — kqueue의 세계

파일이 바뀌었는지, 어떻게 알 수 있을까?

개발하다 보면 "특정 파일이 변경되면 자동으로 뭔가를 실행하고 싶다"는 상황이 꽤 자주 생겨요. 예를 들면 설정 파일이 바뀌면 서버를 다시 시작한다거나, 소스 코드가 수정되면 자동으로 빌드를 돌린다거나 하는 경우요. 핫 리로드(hot reload)라고 불리는 기능이 대표적이에요.

이런 기능을 만들려면 운영체제 수준에서 파일 변경을 감지하는 방법을 알아야 하는데요. macOS(그리고 BSD 계열 운영체제)에는 kqueue라는 꽤 강력한 이벤트 알림 시스템이 있어요. 최근 한 개발자가 kqueue를 직접 사용해서 파일 변경을 감지하는 방법을 정리한 글이 올라왔는데, 그 내용을 자세히 풀어볼게요.

kqueue가 뭔가요?

kqueue(kernel queue의 줄임말)는 커널 수준의 이벤트 알림 메커니즘이에요. 이게 뭐냐면, 운영체제의 커널한테 "이 파일 좀 지켜보고 있다가 뭔가 바뀌면 알려줘"라고 부탁하는 거예요. 커널이 직접 감시하니까 우리가 주기적으로 파일 상태를 확인하는 것(polling이라고 해요)보다 훨씬 효율적이에요.

비유하자면, 택배를 기다릴 때 매 5분마다 현관문을 열어보는 게 polling이고, 초인종이 울리면 나가보는 게 kqueue 같은 이벤트 기반 방식이에요. 당연히 초인종이 훨씬 효율적이겠죠?

kqueue는 파일 변경만 감지하는 게 아니에요. 네트워크 소켓에 데이터가 도착했는지, 프로세스가 종료됐는지, 타이머가 만료됐는지 등 다양한 종류의 이벤트를 한 곳에서 처리할 수 있어요. 하나의 통합 인터페이스로 여러 종류의 이벤트를 모니터링할 수 있다는 게 kqueue의 장점이에요.

실제로 어떻게 쓰나요?

kqueue를 사용하는 흐름은 크게 세 단계예요. 먼저 kqueue() 시스템 콜로 큐를 만들고, 감시하고 싶은 이벤트를 kevent() 함수로 등록한 다음, 다시 kevent()를 호출해서 이벤트가 발생할 때까지 기다리는 거예요.

파일 변경 감지의 경우, 먼저 감시할 파일을 open() 시스템 콜로 열어야 해요. 그리고 그 파일 디스크립터(file descriptor)를 kqueue에 등록하면서 "이 파일에서 어떤 이벤트를 감시할 건지" 필터를 설정해요. EVFILT_VNODE라는 필터가 파일시스템 이벤트 전용 필터인데요, 여기에 NOTE_WRITE(파일 내용 변경), NOTE_DELETE(파일 삭제), NOTE_RENAME(파일 이름 변경) 같은 세부 플래그를 조합할 수 있어요.

중요한 점이 하나 있어요. kqueue는 파일 디스크립터를 기반으로 동작하기 때문에, 감시할 파일마다 디스크립터를 하나씩 열어야 해요. 디렉토리 전체를 재귀적으로 감시하려면 하위 파일과 폴더를 직접 순회하면서 등록해줘야 하거든요. 이 부분이 리눅스의 inotify와 비교했을 때 좀 불편한 점이에요. inotify는 디렉토리를 등록하면 그 안에서 생기는 이벤트를 자동으로 잡아주니까요.

리눅스의 inotify와 비교하면?

리눅스에서 비슷한 역할을 하는 게 inotify예요. 둘 다 커널 수준의 파일 변경 알림이라는 점에서 같지만, 설계 철학이 좀 달라요.

inotify는 파일/디렉토리 감시에 특화되어 있어요. 경로(path) 기반으로 동작하고, 디렉토리를 감시하면 그 안에서 파일이 생성되거나 삭제될 때도 이벤트가 와요. 반면 kqueue는 범용 이벤트 시스템이에요. 파일뿐만 아니라 소켓, 프로세스, 시그널, 타이머 등을 하나의 인터페이스로 처리할 수 있어요. 그 대신 파일 감시만 놓고 보면 inotify보다 설정이 좀 더 번거로워요.

그래서 실무에서는 보통 이런 차이를 추상화해주는 라이브러리를 쓰게 돼요. Node.js의 chokidar, Rust의 notify 크레이트, Go의 fsnotify 같은 라이브러리가 내부적으로 macOS에서는 FSEvents나 kqueue를, 리눅스에서는 inotify를 써서 크로스 플랫폼 파일 감시를 제공해요. macOS에는 FSEvents라는 더 고수준의 API도 있는데, Apple이 Spotlight 검색 같은 기능을 위해 만든 거예요. 대규모 디렉토리 감시에는 FSEvents가 더 편하고, 개별 파일 수준의 세밀한 제어가 필요하면 kqueue가 더 적합해요.

한국 개발자에게 주는 시사점

맥북으로 개발하는 한국 개발자가 정말 많은데, 정작 macOS의 시스템 프로그래밍에 대해서는 잘 모르는 경우가 많아요. kqueue를 직접 쓸 일이 흔하지는 않지만, 알아두면 좋은 상황이 꽤 있어요.

예를 들어 파일 감시가 "왜 가끔 이벤트를 놓치는지" 디버깅할 때요. chokidar 같은 라이브러리가 내부적으로 kqueue를 쓰는데, kqueue의 특성을 이해하면 왜 특정 상황에서 이벤트가 누락되는지 원인을 파악할 수 있어요. 또 간단한 개발 도구를 만들 때 — 예를 들어 로컬 개발 서버의 자동 재시작 기능 같은 거 — kqueue를 직접 사용하면 외부 라이브러리 의존성 없이 가볍게 만들 수 있어요.

그리고 시스템 프로그래밍 면접에서 "이벤트 기반 I/O"나 "select/poll/epoll/kqueue의 차이" 같은 질문이 나올 때, kqueue의 동작 원리를 아는 게 도움이 되겠죠.