대부분의 자동화는 같은 방식으로 사라집니다. 누군가가 뭔가 영리한 걸 만들어서 채팅 창에서 한 번 실행하고, 저녁 먹으러 노트북을 덮으면 모든 게 증발합니다. 스크립트는 결코 약한 고리가 아니었습니다. 노트북이 그랬습니다. 작업이 계속되려면 노트북이 열려 있고, 전원이 연결되어 있고, 깨어 있어야 했습니다. 그런데 노트북은 정반대의 역할을 하도록 설계되어 있습니다.
Mac mini 에는 그런 문제가 없습니다. 기본 모델 기준 약 $599 에 구입할 수 있고, 책상용 램프보다 전력을 덜 소비하며, 소음이 거의 없고, 정확히 하나의 임무만 있습니다: 계속 켜져 있기. 이 한 가지 특성이 바로, 사람들이 조용히 Claude 워크플로우를 맡기는 기계가 된 이유입니다.
이 글에서는 세 가지 워크플로우를 살펴봅니다. 자체적으로 분류하는 받은 편지함, 밤새 검토되는 풀 리퀘스트, 그리고 회의 제목 대신 브리핑을 제공하는 캘린더. 이 모든 것은 집 어딘가에 있는 mini 에서 실행되며, 아무도 시작하는 것을 기억할 필요가 없는 작업을 수행합니다.
왜 그냥 Claude 채팅을 사용하지 않나요?
이미 Claude 에 이메일을 붙여넣고 답장 초안을 요청할 수 있습니다. 이미 diff 를 붙여넣고 검토를 요청할 수 있습니다. 이 글의 어떤 내용도 채팅 창에 이미 존재하지 않는 기능을 필요로 하지 않습니다.
달라지는 것은 '누가 실행 버튼을 누르는가'입니다.
채팅에서는 매번 여러분이 트리거입니다. 탭을 열고, 내용을 붙여넣고, 답변을 읽고, 어딘가에 복사합니다. 그렇게 하는 것을 멈추는 순간 프로세스도 멈춥니다. 여러분의 손이 닿아야만 움직이는 도구입니다.
mini 에서는 트리거가 시계, 웹훅, 또는 폴더에 새 파일이 도착하는 것입니다. Claude 가 작업을 수행하고, 사전에 작성한 규칙에 따라 자신의 출력을 확인한 다음, 누군가 노트북을 열지 않아도 결과를 전송하거나 다시 시도합니다. 이것이 바로 "내가 사용하는 모델"과 "실행되는 시스템"의 차이입니다.
실제로 책상 위에 있는 것
세 가지 계층이며, 전혀 특별하지 않습니다:
기계. launchd 작업 (macOS 에서 cron 의 더 나은 사촌)을 실행하는 Mac mini 로, 이 작업은 스케줄에 따라 또는 파일 변경에 반응하여 Python 스크립트를 실행합니다. 작고 항상 켜져 있는 PC 라면 같은 작업을 수행할 수 있습니다. mini 는 단지 조용하고, 운영 비용이 저렴하며, 모니터 뒤에 숨길 수 있을 정도로 작을 뿐입니다.
저장소. 일반 폴더와 마크다운 파일, 그리고 워크플로우가 직접 접촉하는 것들 (IMAP 을 통한 받은 편지함, 로컬에 복제된 GitHub 리포지토리, .ics 피드와 동기화된 캘린더)이 있습니다. 어떤 것도 타사 앱 뒤에 존재하지 않습니다. mini 가 내일 사라지더라도, 생성된 모든 파일은 어떤 컴퓨터에서든 정상적으로 열립니다.
추론 엔진. API 를 통해 호출되는 Claude 입니다. Sonnet 은 실제 판단이 필요한 작업 (풀 리퀘스트 병합이 안전한지 결정, 여러분처럼 들리는 답장 초안 작성)을 처리합니다. Haiku 는 저렴하고 대량의 작업 (분류, 라벨링, 예/아니오 확인)을 처리합니다. 이렇게 작업을 분할하는 것이 월별 청구액을 커피 구독료 이하로 유지하는 주된 이유입니다.
이제 실제 워크플로우를 살펴보겠습니다.
루틴 1: 확인할 때쯤이면 소음이 사라진 받은 편지함
대부분의 받은 편지함은 어려운 결정으로 가득 차 있지 않습니다. 전혀 여러분이 필요하지 않은 것들 (뉴스레터, 캘린더 확인, 쉰 번은 대답한 업체 질문)로 가득 차 있습니다. 어려운 부분은 답변하는 것이 아닙니다. 결정을 내리기도 전에 각 항목이 빼앗아가는 20초의 집중력입니다.
1실행 시간: 평일 15분마다2감시 대상: 기본 받은 편지함의 새 메일34단계:5 1. 동일한 스레드의 최근 10개 메시지를 가져와 컨텍스트 확보6 2. Claude 가 새 메시지 분류:7 - 일상적 (확인 메일, 뉴스레터, 자동 회신)8 - 답장 필요 (실제 질문, 요청)9 - 사람의 결정 필요 (금전, 갈등, 모호한 모든 것)10 3. 일상적 -> 자동 보관, 일일 요약에 기록11 답장 필요 -> Claude 가 내 목소리로 응답 초안 작성, 임시 보관함에 저장,12 내가 열어보지 않으면 전송되지 않음13 사람 필요 -> 그대로 두고, 플래그 표시, 초안 작성 시도 안 함1415확인: 분류에는 한 줄짜리 이유가 포함되어야 함. Claude 가 실제 메시지16 내용을 참조하는 이유를 생성할 수 없으면, 해당 항목은 기본적으로17 "사람 필요"로 분류됨.18중단: 배치의 모든 메시지가 정렬되었거나, 단일 메시지에 대해 3회 재시도19 후에도 실패하면 직접 플래그가 지정됨
여기서 중요한 규칙은 폴백(fallback)입니다. Claude 가 자신 있게 분류할 수 없는 것은 추측하지 않습니다. 원래와 똑같이 여러분의 책상 위에 떨어집니다. 이 워크플로우는 어려운 10%에 대한 판단을 대체하려는 것이 아닙니다. 쉬운 90%에서 여러분의 주의를 빼앗지 않도록 하는 것입니다.
루틴 2: 깨어나기 전에 풀 리퀘스트가 1차 검토를 받습니다
코드 리뷰에는 이상한 실패 모드가 있습니다. 가장 중요한 리뷰 (밤 11시에 올라온 PR 의 리뷰)는 반쯤 잠든 상태에서 서둘러 처리되거나, 더 나쁘게는 "내일 볼게"라고 말하고는 결국 이루어지지 않은 채 병합될 가능성이 가장 높다는 점입니다.
1실행 시간: GitHub 웹훅을 통해 새 풀 리퀘스트가 있을 때마다23단계:4 1. diff 와 연결된 이슈 (있는 경우)를 가져옴5 2. Claude 가 고정된 기준에 따라 리뷰:6 - 연결된 이슈의 실제 범위와 일치하는가?7 - 인증, 결제, 마이그레이션에 대한 변경 사항이 있는가? (플래그 표시, 판단 금지)8 - 변경된 라인에 대한 테스트 커버리지: 있음 또는 없음?9 - 파일의 나머지 부분과 일관된 네이밍 및 구조인가?10 3. 각 기준 항목에 대해 1-5점으로 평가하고, 가장 약한 두 지점을 명시적으로11 지적하여 PR 에 직접 댓글 게시1213확인: 특정 라인 번호를 인용하는 경우에만 댓글이 게시됨.14 라인 참조가 없는 리뷰는 폐기되고 재시도됨. 모호한 피드백은15 게시할 가치가 없음.16중단: 댓글 게시됨, 또는 2회 재시도 후에도 실패하면 자동 리뷰를17 완료할 수 없었다는 메모와 함께 PR 을 그대로 둠
여기서 아무것도 병합되지 않습니다. 실제 첫 번째 눈이 검토하기 전에, 지치지 않는 두 번째 눈이 PR 을 살펴보는 것입니다. 고정된 기준에 따른 점수 매기기가 유용함을 유지하는 핵심입니다. 자유 형식으로 "이 코드를 리뷰해 줘"라고 요청받은 모델은 모든 것을 칭찬하거나 무작위로 잡아내는 경향이 있습니다. 네 가지 고정된 질문에 대해 점수를 매기도록 요청받은 모델은 매번 동일한 종류의 피드백을 생성하며, 이것이 바로 오전 8시에 읽을 가치가 있는 이유입니다.
루틴 3: 회의에 제목뿐만 아니라 브리핑이 함께 도착합니다
캘린더 초대는 언제, 어디서인지 알려줍니다. 하지만 회의에 들어가기 전에 실제로 기억해야 할 것 (그 사람과의 마지막 이메일 스레드, 이전 회의의 미해결 항목, 누군가가 물어볼 숫자)을 거의 알려주지 않습니다.
1실행 시간: 참석자가 2명 이상인 각 캘린더 이벤트 45분 전23단계:4 1. 마지막 이메일 스레드와 참석자 이름 또는 이벤트 제목에 연결된5 공유 문서를 가져옴6 2. Claude 가 한 페이지 분량의 브리핑 작성:7 - 지난번에 합의된 사항 (있는 경우)8 - 제기할 가치가 있는 미해결 질문 하나9 - 마지막 교환에서 언급된 숫자 또는 날짜10 3. 이벤트 30분 전에 푸시 알림으로 전달1112확인: 브리핑은 실제 이전 메시지 또는 문서를 참조해야 함.13 이전 컨텍스트를 찾을 수 없음 -> 알림에 "이력 없음"이라고 표시,14 허구의 요약을 생성하지 않음.15중단: 전송됨, 또는 참석자가 모두 새로운 경우 건너뜀
마지막 확인이 주목할 만합니다. 실제 컨텍스트를 찾을 수 없을 때 Claude 가 그럴듯한 브리핑을 아무것도 없이 작성하는 것은 쉽습니다. 그리고 그럴듯한 가짜는 브리핑이 없는 것보다 더 나쁩니다. 왜냐하면 그것을 신뢰할 것이기 때문입니다. 정직하게 "찾을 수 없음"을 강제하는 것이 실제로 도착하는 브리핑을 읽을 가치 있게 만드는 요소입니다.
위의 모든 것이 의존하는 두 가지 규칙
구체적인 내용을 제거하면 모든 루틴은 동일한 두 가지 가드레일에 의존합니다.
확인 가능한 규칙, 모호한 느낌이 아닌. "이 이메일을 분류하세요"는 느낌입니다. "이 이메일을 분류하세요. 그리고 라벨을 정당화하는 문장을 인용할 수 없으면 안전한 카테고리로 기본 설정하세요"는 규칙입니다. 차이는 Claude 가 자신의 작업을 특정 기준에 대해 평가하는지, 아니면 그냥 완성된 것처럼 보이는 결과를 생성하는지에 있습니다.
실제 중단 조건. 위의 모든 루틴에는 재시도 횟수에 대한 하드 리미트와 작업을 깔끔하게 수행할 수 없을 때의 정의된 폴백이 있습니다. 이것이 없으면, 형식이 잘못된 이메일 하나나 diff 가 깨진 PR 하나가 밤새 재시도 루프에서 API 호출을 소모할 수 있으며, 버그 보고서가 도착하기 전에 청구서가 나타납니다.
이 두 가지를 제대로 설정하면 특정 작업은 거의 중요하지 않습니다. 받은 편지함, 코드, 캘린더, 또는 완전히 다른 것이든 상관없습니다.
구축하기 전에 직접 수동으로 느껴보세요
이 모든 것을 시작하기 위해 터미널을 건드릴 필요는 없습니다. 일반 Claude 대화에서 동일한 형태를 실행하여 자동화하기 전에 실제로 유용한지 확인할 수 있습니다:
1다음 작업을 패스(pass) 방식으로 수행하며, 완료되었다고 말하기 전에2자신의 출력을 확인하십시오.34작업:5[처리하려는 것]67패스 규칙:8- 작업을 수행하십시오.9- 다음 기준에 대해 확인하십시오: [구체적이고 확인 가능한 조건]10- 확인에 실패하면 무엇이 잘못되었는지 말하고 해당 부분만 다시 수행하십시오.11- 통과하면 "완료"라고 말하고 중단하십시오.12- 명확한 질문을 하지 마십시오. 가장 합리적인 가정을 하고,13 한 줄로 진술한 다음 계속 진행하십시오.1415시작하십시오.
이것이 전체 메커니즘의 축소판입니다. mini, 웹훅, 스케줄이 없습니다. 단지 Claude 가 첫 번째 그럴듯한 초안에서 멈추는 대신 규칙에 따라 자신의 작업을 확인하는 것입니다. 동일한 종류의 작업에 대해 이 작업을 수동으로 서너 번 실행하고 계속 사용하게 된다면, 그것은 실행을 기억할 필요가 없는 기계에 올릴 가치가 있다는 신호입니다.
새벽 2시에 고장 나지 않도록 하는 순서
이러한 작업을 안정적으로 실행하는 사람은 cron 작업을 작성하는 것부터 시작하지 않습니다. 실제로 유지되는 순서는 다음과 같습니다:
- 출력이 일관되게 정확해질 때까지 채팅에서 수동으로 실행합니다.
- 해당 정확한 프롬프트를 스크립트로 변환합니다. 로직은 변경하지 않습니다.
- 다른 모든 것보다 먼저 확인과 재시도 제한을 추가합니다.
- 그런 다음에만 스케줄이나 웹훅에 연결합니다.
4단계로 바로 건너뛰면 "중단 조건 없음"이 얼마나 큰 비용을 초래하는지 알게 됩니다. 보통 아침에 중복된 PR 댓글이 가득하거나 보낸 편지함 폴더에 수백 개의 동일한 초안이 쌓여 있는 형태로 나타납니다.
이것이 실제로 제공하는 것
이 모든 것이 Claude 를 더 똑똑하게 만들지는 않습니다. 여러분이 사용하는 것과 여러분이 주의를 기울이지 않아도 작동하는 것 사이의 차이를 만듭니다. mini 가 흥미로운 부분은 아닙니다. 단지 다시 열 필요가 없는 기계에 워크플로우를 제공하는 가장 저렴하고 조용한 방법일 뿐입니다.
이 글의 수동 버전부터 시작하십시오. 몇 번 이상 수동으로 실행하고 있다면, 그것이 여러분이 잠든 후에도 계속 켜져 있는 박스에 올릴 가치가 있는 작업입니다.
이 글을 읽어주셔서 감사합니다
제작자: @0xclayn**
저장하기
