5. 훅과 자동화 — 운영자가 잊어도 시스템이 잊지 않게

이 글은 시리즈 Alice 활용법의 5편이다. 4편 스킬과 슬래시 커맨드에서 mind의 반복 동작을 한 줄짜리 이름으로 응고했다면, 이 글은 그 짝 — 운영자가 그 이름조차 호출하지 않아도 절차가 발동되게 만드는 장치에 대한 기록이다.

0. 훅은 잊을 수 있는 mind를 시스템에 위탁한다

운영자는 잊는다. 어제 한 결정을, 방금 켠 세션의 직전 상태를, 보고 직전에 했어야 할 검증을, 매일 한 번씩.

스킬은 이 잊음을 부분적으로 막는다 — 운영자가 호출만 하면 절차가 풀린다. 그러나 호출 자체를 잊으면 스킬은 발동하지 않는다. 한 줄짜리 이름조차 떠올리지 못하는 순간이 있다.

훅은 그 순간을 메운다. 운영자의 의식에 의존하지 않고, 시스템이 특정 이벤트에서 절차를 자동으로 발동시킨다. 운영자의 mind 일부를 시스템에 위탁하는 일이다.

위탁할 만한 mind는 정해져 있다. "잊으면 안 되는데 자주 잊는 것", "조건이 명확해서 자동 판단 가능한 것", "발동 시점이 이벤트로 잡힐 수 있는 것". 이 글은 그 위탁의 기준과 실제 운영 사례에 대한 기록이다.

훅 메커니즘 자체는 Anthropic Claude Code의 hooks 시스템에서 차용했다. 이 글은 그 메커니즘을 어떻게 활용했는가에 대한 기록이지, 그 자체의 발명이 아니다.

1. 의식이 비는 순간이 있다

운영자가 가장 자주 잊는 것은 절차가 어렵기 때문이 아니다. 그 절차가 다른 일에 집중하고 있는 순간에 끼어 들어야 하기 때문이다.

순간	의식 상태	잊기 쉬운 절차
세션 시작 직후	"어디까지 했더라" 회상 중	메모리 동기화 상태 확인
코드 변경 직후	"이제 됐다" 안도 중	lint / 빌드 / 테스트 검증
보고 작성 직전	"어떻게 정리할까" 구성 중	작업 영역 외부 변경 여부 점검
세션 마무리 직전	"이제 끝났다" 종료 중	작업 로그, HANDOFF, push
위험한 명령 직전	"이거 하면 끝" 실행 중	진짜 의도 재확인

이 모든 순간에서 운영자의 mind는 다른 데로 가 있다. "잊지 마라" 같은 원칙으로는 막을 수 없다. 시스템 레벨에서 자동으로 발동되어야 한다.

훅은 그 발동의 장치다. 운영자의 의식이 비어 있는 순간에 끼어들어 절차를 강제한다.

2. 스킬과 훅의 경계

이 둘은 자주 혼동되는데, 핵심 구분은 한 가지다 — 누가 호출하는가.

	호출 주체	발동 시점	운영자 인지
스킬 / 슬래시 커맨드	운영자가 명시적으로	운영자가 결정	인지 후 호출
훅	시스템이 자동	이벤트가 결정	결과만 인지 (또는 인지 못함)

스킬은 "이걸 해 줘"라고 운영자가 결심해야 발동한다. 훅은 그 결심 없이도 발동한다. 그래서 훅의 가장 큰 가치는 — 운영자가 결심하지 못한 순간에도 절차가 보장된다는 점이다.

같은 절차를 두 방식 모두로 노출할 수도 있다. 예를 들어 /verify는 슬래시 커맨드로 직접 호출할 수도 있고, "완료" 보고 직전에 자동으로 발동될 수도 있다. 운영자가 의식적으로 호출하면 스킬, 시스템이 자동으로 발동하면 훅 — 두 입구로 같은 절차를 가리킨다.

3. 승급 기준 — 어떤 절차가 훅으로 올라가는가

모든 절차가 훅이 되어야 하는 것은 아니다. 다음 다섯 가지를 모두 통과하는 것만 자동 발동의 권한을 받는다.

3.1 빠뜨리면 손해가 크고 자주 빠뜨려지는가

훅은 인지 비용이 있다 — 운영자가 모르는 사이에 시스템이 무언가를 한다. 그 비용을 정당화하려면 빠뜨림의 손해가 충분히 커야 한다. 검증 없이 push되는 변경, 메모리 동기화 안 된 채 시작되는 세션 — 이런 것들은 손해가 즉시 가시화된다. 훅의 자리.

작은 편의 수준의 절차는 훅이 아니라 스킬에 머문다.

3.2 발동 조건이 이벤트로 명확히 잡히는가

훅은 특정 이벤트에 묶인다. "세션 시작", "도구 호출 직전", "출력 보낼 직전", "세션 종료" 같은 식. 이벤트가 명확하지 않으면 — "이런 분위기일 때" 같은 — 훅이 되지 않는다.

3.3 결정이 자동 판단 가능한가

훅이 발동한 뒤 무엇을 할지가 자동으로 결정되어야 한다. "변경이 lint를 통과하면 OK, 아니면 차단" 같은 명확한 분기. 운영자의 추가 판단이 필요한 절차는 훅이 아니라 스킬 호출로.

3.4 실패가 안전한가

훅이 실패하더라도 시스템 전체가 망가지지 않아야 한다. 훅은 운영자의 의식 밖에서 작동하기 때문에, 실패하면 운영자가 즉시 알아채지 못한다. 그러니 실패 시 영향이 격리되어야 한다.

3.5 출력이 신호화되는가

훅의 결과는 운영자에게 한 줄로 전달되어야 한다. "성공", "차단", "경고" 같은 명확한 신호. 출력이 길거나 모호하면 훅이 운영자의 시야에서 잡음이 된다.

4. 운영 중인 훅 예시

운영자가 실제로 매일 의존하는 훅 일부.

4.1 SessionStart — 세션 시작 시

세션이 시작되는 순간 메모리 동기화 상태를 한 줄로 출력한다. "메모리 동기화: 최신" 또는 "메모리 동기화: 5분 전 — 갱신 필요". 운영자는 그 한 줄만 보고 즉시 판단한다.

이 훅이 없으면 — 운영자가 매번 "메모리 최신 맞나" 의식적으로 확인해야 한다. 의식이 다른 데로 가 있는 순간에는 잊고 그냥 작업을 시작한다. 그러면 stale 상태에서 결정을 내리게 된다.

4.2 PreToolUse — 위험한 명령 직전

rm -rf, force push, destructive SQL 같은 특정 명령이 실행되기 직전에 발동한다. 사용자에게 확인을 요청하거나, 정책 위반이면 차단한다.

이 훅의 가치는 — 운영자가 "이거 진짜 해도 되나" 라고 다시 생각하는 순간을 시스템이 강제한다는 점이다. 빠른 진행 흐름에 끼어드는 것이 핵심.

4.3 PreToolUse → /verify 자동 발동

작업 완료 보고 직전에 lint · 빌드 · 테스트를 자동으로 돌리는 훅. 운영자가 "끝났습니다"를 적기 직전에 시스템이 끼어들어 검증을 강제한다. 실패하면 보고가 막힌다.

운영자의 "이제 됐다" 안도가 가장 위험한 순간이다. 훅이 그 안도에 한 박자를 강제한다.

4.4 Stop — 세션 종료 시

세션이 끝나려는 순간 작업 로그가 갱신되었는지, HANDOFF가 다음 세션을 위한 정보를 담고 있는지 확인한다. 누락이 있으면 운영자에게 알린다.

이 훅이 없으면 — 운영자는 "이제 끝났다" 상태에서 그냥 종료한다. 다음 세션이 컨텍스트를 잃은 채 시작한다.

4.5 누적된 효과

이 훅들은 각각으로는 작은 절차다. 그러나 매일 운영자의 의식이 비는 5-6개의 순간을 시스템이 자동으로 메운다는 누적 효과가 크다. 운영자의 mind는 결정에만 집중할 수 있고, "잊지 말아야 할 절차"는 시스템이 들고 있다.

5. 설계 원칙

훅을 만들 때 운영자가 수렴한 원칙.

5.1 짧고 빠르게

훅은 운영자의 흐름에 끼어든다. 짧지 않으면 흐름이 끊긴다. 1초 이상 걸리는 훅은 비동기로 돌리거나, 진행 표시를 명확히. 운영자가 "왜 멈췄지" 생각하게 되면 훅의 가치가 마이너스가 된다.

5.2 출력은 한 줄

훅이 끝났을 때 운영자가 보는 출력은 한 줄. 자세한 로그는 별도 파일로. "메모리 동기화: 최신", "검증 통과: 3 테스트 OK", "차단: lint 오류 2건" 같은 식.

5.3 실패는 격리

훅 실패가 본 작업을 깨지 않아야 한다. 메모리 동기화 훅이 실패해도 세션은 시작되어야 한다 (다만 경고 출력). 검증 훅이 실패하면 보고는 막되, 작업 자체는 살아 있어야 한다.

5.4 우회 가능

가끔 운영자가 의도적으로 훅을 우회하고 싶을 때가 있다 — 디버깅 중이거나, 임시 작업이거나. 명시적인 우회 옵션이 있어야 한다. 우회한 사실은 로그에 남기되, 막지는 않는다.

5.5 멱등성

같은 이벤트가 두 번 발동되어도 같은 결과가 나오거나, 최소한 깨지지 않아야 한다. 훅은 자동 발동이라 같은 이벤트가 중복 발생하는 경우를 피할 수 없다.

6. 훅으로 만들면 안 되는 것 — 함정

승급 기준의 반대편.

6.1 운영자의 결정을 대신하는 것

훅이 "이런 코드면 자동으로 이렇게 고친다" 같은 것은 위험하다. 자동 수정은 종종 의도와 다른 방향으로 간다. 훅은 알림과 차단까지, 자동 수정은 운영자가 스킬을 호출해서 결정하게.

6.2 너무 자주 발동되는 것

매 키 입력마다, 매 파일 저장마다 발동되는 훅은 잡음이 된다. 이벤트의 자연스러운 빈도가 분 단위 이상이어야 한다. 초 단위로 발동되면 운영자의 흐름을 부순다.

6.3 출력이 긴 것

훅 한 번에 30줄 로그가 출력되면, 그것이 본 작업의 출력을 가린다. 길어야 할 정보는 파일로, 콘솔에는 한 줄 신호만.

6.4 실패가 본 작업을 깨는 것

훅 실패가 cascade로 본 작업까지 깨면, 운영자는 훅을 꺼 버리고 만다. 일단 꺼지면 영영 안 켜진다. 그러니 실패 격리가 필수.

7. 스킬과 훅의 합성

이 시리즈에서 4편 스킬 §5가 다룬 "스킬이 모이면 일어나는 네트워크 효과"가 훅을 만나면 한 단계 더 확장된다.

같은 절차를 두 방식으로 노출한다:

절차	스킬 호출	훅 발동
/verify	운영자가 명시적으로 검증 원할 때	작업 완료 보고 직전 자동
/start <project>	운영자가 프로젝트 진입할 때	(없음 — 운영자 의도가 시작점)
/session-end	운영자가 세션 마무리 선언할 때	(Stop 훅이 누락 점검만)
메모리 동기화	(별도 스킬 없음)	SessionStart 자동

이렇게 짝 지으면 — 운영자가 의식할 때는 스킬을, 의식이 비는 순간에는 훅을 통해 같은 절차가 보장된다. 결정 권한은 운영자가 들되, 안전망은 시스템이 받친다.

8. 한 원칙으로 압축

훅 설계의 핵심은 한 문장으로 줄어든다.

"운영자가 잊을 가능성이 높은 절차만, 시스템이 자동으로 발동시킨다. 그 외에는 운영자가 결심해서 스킬로 호출한다."

이 원칙이 지켜지면 훅은 운영자의 mind에서 부담을 덜어 주는 보호 장치가 된다. 지켜지지 않으면 — 운영자의 의도를 가로채는 잡음이 된다.

다음 글에서는 한 명이 모든 일을 하지 않는 구조 — 멀티에이전트 위임, 즉 어떤 일을 다른 협업자에게 맡기고 어떤 일을 직접 하는가에 대해 다룬다.