AI 자동화 전에 업무 흐름부터 그려야 하는 이유
AI 자동화를 시작하면 새로운 도구부터 찾기 쉽습니다. 하지만 제가 먼저 자동화한 것은 개발 작업 자체가 아니었습니다. AI에게 작업을 맡긴 뒤 각 터미널을 돌아다니며 상태를 확인하는 행동이었습니다.
자동화하기 전, 일곱 개 터미널을 확인했습니다
저는 평소 Windows에서 Claude Code CLI를 이용해 개발합니다. 작업이 많을 때는 서로 다른 프로젝트를 진행하는 터미널을 최대 7개까지 동시에 열어 두기도 했습니다.
Claude가 긴 작업을 수행하는 동안 다른 일을 할 수 있다는 것이 CLI 에이전트의 장점입니다. 그러나 실제로는 하던 일을 멈추고 각 터미널을 열어 작업이 끝났는지, 권한이나 추가 입력이 필요한지 확인했습니다. 너무 자주 확인하면 현재 업무의 흐름이 끊겼고, 늦게 확인하면 Claude가 입력을 기다리는 동안 작업도 멈춰 있었습니다.
당시의 흐름은 다음과 같았습니다.
작업 요청 → 다른 업무 진행 → 여러 터미널을 반복 확인 → 선택 또는 입력 → 결과 검수
제가 자동화해야 했던 것은 AI의 개발 작업이 아니라, 사람이 다시 개입할 시점을 확인하는 일이었습니다.
자동화한 것은 AI가 아니라 다시 개입할 시점입니다
먼저 어떤 순간에 제가 터미널로 돌아가야 하는지 정했습니다. Claude Code의 훅 중에서 권한이나 사용자 입력이 필요할 때 발생하는 Notification, 메인 에이전트의 응답이 끝날 때 발생하는 Stop, 서브에이전트의 작업이 끝날 때 발생하는 SubagentStop을 기준으로 삼았습니다.
알림을 적용한 뒤의 흐름은 이렇게 바뀌었습니다.
작업 요청 → 다른 업무 진행 → 입력 요청 또는 완료 알림 → 해당 터미널로 복귀 → 선택·입력 또는 결과 검수
알림이 작업의 결과를 대신 판단하지는 않습니다. 선택지가 주어지면 제가 결정하고, 추가 정보가 필요하면 직접 입력합니다. 작업이 끝났을 때도 해당 터미널로 돌아가 결과를 검수합니다. 자동화가 맡은 역할은 사람이 필요한 순간을 알려주는 것까지입니다.
훅과 프로젝트명을 먼저 정했습니다
동시에 실행한 터미널이 많았기 때문에 단순히 “작업이 완료되었습니다”라는 알림만으로는 부족했습니다. 알림을 보고 어느 터미널로 돌아가야 하는지 바로 알 수 있어야 했습니다.
그래서 현재 작업 경로의 마지막 폴더명을 프로젝트명으로 사용했습니다. 알림 제목을 Claude · 프로젝트명으로 표시하니 여러 세션 중 확인할 작업을 구분할 수 있었습니다. 첫 알림은 AI의 도움을 받아 30분 안에 구현했습니다.

Windows용 PowerShell 훅은 현재 작업 경로에서 프로젝트명을 가져오고, 이벤트에 따라 알림 내용을 나누도록 만들었습니다. Notification에는 사람이 확인해야 할 요청을, Stop과 SubagentStop에는 각각 메인 작업과 서브에이전트의 완료 여부를 표시했습니다.
알 수 없는 이벤트나 잘못된 입력은 본래 작업을 방해하지 않도록 조용히 종료하게 했습니다. 화려한 기능보다 언제 알릴지와 어느 프로젝트인지를 정하는 것이 이 자동화의 핵심이었습니다.
동료가 바로 설치할 수 있도록 Windows용 압축 파일로 정리했습니다
개인적으로 사용하던 알림을 동료에게도 공유하기 위해 Windows용 압축 파일로 정리했습니다. Claude Code 알림 스크립트와 더블 클릭으로 실행하는 설치 파일, 기존 설정 백업과 문제 해결 방법을 하나의 압축 파일에 담았습니다.
지원한다고 해서 모든 이벤트를 기본으로 활성화하지는 않았습니다. 서브에이전트는 한 작업에서도 여러 번 끝날 수 있어 SubagentStop까지 기본 등록하면 오히려 알림이 지나치게 많아질 수 있었습니다. 그래서 설치 과정에서는 입력 요청을 받는 Notification과 메인 작업 완료를 알리는 Stop만 기본으로 등록했습니다.
5월 28일에 공유한 뒤 현재까지 저와 동료들이 실제 업무에서 사용하고 있습니다. 이제 작업이 끝났는지 확인하려고 여러 터미널을 돌아다니지 않습니다. 알림이 올 때까지 현재 업무에 더 집중하고, 사람의 판단이 필요한 순간에만 해당 터미널로 돌아갑니다.
공유받은 동료는 별도의 코드 수정 없이 설치했습니다. 작은 개인용 스크립트도 다른 사람이 설치하고 되돌릴 수 있는 형태로 정리해야 재사용 가능한 도구가 된다는 점을 확인했습니다.
개인 맥북에서도 같은 흐름을 유지했습니다
이후 개인적으로 사용하는 맥북에서도 같은 흐름을 유지하고 싶어 Python으로 확장했습니다. 훅의 종류와 프로젝트명 표시 방식은 Windows에서 사용하던 기준을 그대로 적용했습니다.
macOS에서는 terminal-notifier가 설치되어 있으면 이를 사용하고, 없으면 기본 osascript 알림으로 대체합니다. 특정 알림 도구가 없어도 핵심 흐름은 계속 동작하도록 한 것입니다.

운영체제가 바뀌어도 제가 원하는 결과는 같았습니다. 알림을 기다리며 다른 업무에 집중하고, 사람의 판단이나 검수가 필요한 순간에만 해당 터미널로 돌아가는 것입니다.
공식 기능이 충분해지면 중단할 생각입니다
일론 머스크는 2021년 Everyday Astronaut 인터뷰에서 요구사항을 의심하고 불필요한 단계를 삭제한 뒤 단순화·최적화하고, 마지막에 자동화하라고 설명했습니다. 제 사례에서도 먼저 살펴본 것은 새로운 도구가 아니라 반복해서 터미널을 확인하던 업무 흐름이었습니다.
현재 이 알림은 여러 터미널을 반복 확인하는 일을 없애 주기 때문에 유지하고 있습니다. 반대로 Claude Code가 프로젝트 구분과 입력 요청까지 충분히 알려주는 공식 기능을 제공한다면 직접 만든 알림은 중단할 생각입니다. 유지보수할 이유가 사라지기 때문입니다.
이 사례를 다른 업무에 적용할 때는 반복해서 확인하는 행동, 사람이 다시 개입해야 하는 조건, 결과를 검수할 지점을 순서대로 적어 보세요. 그중 사람의 판단은 필요하지 않지만 상태를 계속 확인해야 하는 단계가 작은 자동화의 후보입니다.
좋은 자동화는 복잡한 기술의 크기로 결정되지 않습니다. 반복되는 흐름에서 무엇을 없애고, 어느 순간에 사람의 판단을 남길지 정하는 것이 먼저입니다. 자동화 도구를 열기 전에 이번 주에 집중을 끊고 반복해서 확인한 순간부터 적어 보세요.
