[Git] pre-push 대신 pre-receive를 쓰기로 한 이유

배경

로컬 개발로 전환하면서, 기존에 있던 pre-push 훅(push 전에 pytest/mypy를 돌려서 실패하면 push 자체를 막는 안전장치)이 로컬(Windows)에서는 작동하지 않는다는 걸 깨달았다.

Q. NAS 안에서 push 훅을 하려면, NAS 컨테이너 안에서 도는 거 아닌가?

맞는 방향처럼 보이지만 정확히는 이렇다 — pre-push 훅 자체는 컨테이너 안에서 도는 게 아니라, **git push 명령을 실행하는 쪽의 로컬 셸(호스트)**에서 실행된다.

client-side 훅 vs server-side 훅

pre-push는 git의 client-side 훅이다. push를 "받는" 쪽(원격 저장소)이 아니라 push를 "실행하는" 쪽의 .git/hooks/에서 돈다는 뜻이다. (원격 쪽에서 도는 훅은 pre-receive/update 같은 server-side 훅인데, 이전 구조엔 그런 게 없었다.)

훅 스크립트 내용을 보면 실제로는:

• 훅 스크립트(sh) 자체는 push를 실행하는 머신의 호스트 셸에서 실행됨
• 그 안에서 docker exec -w ... "$CONTAINER" python -m pytest ...로 컨테이너 안에 진입해서 pytest/mypy만 컨테이너 내부에서 실행

즉 이전에 "NAS에서" 잘 됐던 이유는, NAS 호스트에서 직접 git push를 실행했기 때문이다 — 그 호스트에 Docker 데몬이 있고, docker exec로 같은 호스트에 떠 있는 컨테이너에 진입할 수 있었던 것.

로컬(Windows)에서 push하면 왜 안 걸리나

• 훅 스크립트는 로컬 머신에서 돌아야 하는데, 로컬엔 .git/hooks/pre-push 파일도 없고 Docker도 없다
• 설령 훅 파일을 로컬에 복사해 설치하더라도, docker exec로 NAS 컨테이너에 접근할 수 없다 (Docker exec는 네트워크 너머 원격 컨테이너에 들어갈 수 없고, 반드시 같은 Docker 데몬이 있는 호스트에서만 동작한다)

pre-push 훅은 "push 명령을 어디서 치느냐"에 종속되지, 원격 저장소 쪽 설정이 아니다. 그래서:

• 로컬에서 push하면서 자동 검사를 받고 싶다면 → 로컬에 Docker + 컨테이너 + 훅 설치가 다 필요 (현실적으로 번거로움)
• 또는 검사 시점을 옮겨서 → NAS 쪽에 별도 CI를 두는 게 "로컬 개발 + NAS 배포" 전환 방향과 더 맞음

그럼 CI를 NAS로 옮기면 메모리 이슈가 다시 제자리걸음 아닌가?

로컬 개발로 전환한 이유 자체가 메모리 문제(이전 진단 글 참고 — VS Code Remote-SSH가 호스트에 상시 1.9GB를 물고 있던 문제)였는데, CI를 다시 NAS로 옮기면 같은 문제가 재발하는 게 아닌지 의문이 들었다.

결론은 같은 문제가 아니었다. 원인을 구분해서 보면:

• 메모리 문제의 진짜 원인: NAS 호스트에서 VS Code Remote-SSH로 직접 코딩하면서 상주하는 extensionHost+언어서버가 계속 메모리를 점유하는 것. "사람이 NAS에 SSH로 붙어서 계속 편집하는 세션"이 문제였지, "가끔 컨테이너 안에서 짧게 pytest/mypy를 실행하는 것" 자체가 문제였던 게 아니었다
• 원래 방식(문제 원인): 로컬 → NAS Remote-SSH 접속 → 그 세션이 계속 떠 있으면서 언어서버·확장호스트가 상시 메모리 점유
• 새 방향(NAS를 push 수신 지점으로): 코딩 세션 자체는 로컬에서만 돌고, NAS는 push를 받아서 그때만 docker exec로 짧게 pytest/mypy를 실행 → 끝나면 그 프로세스는 종료. 상주하는 언어서버나 Remote-SSH 세션이 없음

즉 CI가 도는 짧은 컨테이너 실행은 상주 메모리 점유가 아니라 일회성 부하라서, 문제의 근본 원인(상시 상주 프로세스)을 재현하지 않는다.

다만 신경 써야 할 부분은 남아있었다:

• CI를 트리거하는 방식(server-side hook, webhook 리스너 등) 자체가 또 다른 상주 프로세스로 NAS에 떠 있어야 한다면, 그 메모리 사용량은 별도로 확인해야 한다 (다만 보통 이런 리스너는 언어서버보다 훨씬 가볍다)
• 여러 push가 동시에 들어와 docker exec pytest가 중첩 실행되면 순간적으로 스파이크는 있을 수 있다 (watchdog으로 대응 가능한 범위)

결론 — 검사 로직을 "받는 쪽(server)"으로 옮기기

핵심은 검사 로직을 "push하는 쪽(client)"이 아니라 "받는 쪽(server, NAS)"으로 옮기는 것이다. pre-receive(또는 update) 같은 receive-side 훅으로 바꾸면, 로컬이 Windows든 NAS든 상관없이 항상 NAS에서 검사가 실행된다. 이 훅은 push가 들어올 때만 잠깐 켜지는 프로세스라 상주 메모리 문제와 무관하다.

이 결정 이후 실제로 구현한 pre-receive 훅의 세부 로직(임시 워크트리 생성, 라이브 dev 서버 워킹트리와 분리, 비밀 파일 처리 등)은 별도 글에서 다뤘다.

---

GitHub에 커밋 이메일을 교정해서 올리는 절차는 이 과정과 별개의 주제라, 따로 정리해둔 글을 참고: GitHub push할 때마다 까먹는 커밋 이메일 교정 절차

[Git] GitHub push할 때마다 까먹는 커밋 이메일 교정 절차