무엇을 자동화하고, 무엇으로 만들 것인가

업무 하나를 놓고 갈라 내려가면 도착점이 정해지는 4단 의사결정 트리. 1·2단계는 진단 테스트와 같은 데이터(src/lib/tree.ts)에서 렌더되므로 항상 최신입니다.

0단계

비개발자가 업무를 들고 왔을 때 — 되는지부터 가린다

핸즈온 세션 사례 9건을 역추출해 만든 단계다. 실제로 안건이 막힌 지점은 도구 선택 이전이었다 — 데이터 위치, 권한, 판정 기준, 수신자. 이 단계를 통과하지 못한 안건에 도구를 고르는 것은 순서가 거꾸로다.

0단계가 잡아내는 것

벽 1

API가 있는 것과 내가 쓸 수 있는 것은 다르다사내 시스템에 OPEN API가 있어도 키가 보안 정보라 공유되지 않을 수 있다. 두 질문을 따로 물어야 한다.

벽 2

원천이 막히면 하류에서 읽는다로그인이 필요해 못 붙으면, 그 데이터가 흘러 들어온 메일함·시트·DW에서 읽는다. 목적이 알림·집계면 대개 충분하다.

벽 3

마지막 칸이 막히면 초안까지내보낼 쪽에 API가 없으면 전 구간 설계가 바뀐다. 업로드·발송·결재는 사람에게 남긴다.

벽 4

기준 정의가 진짜 숙제다'왜 3일인가'에 답할 수 있는지가 도구보다 먼저다. 답이 없으면 그게 첫 과제다.

갈림길

이 일에 쓰는 데이터가 어디 있는지 말할 수 있나?

어느 시스템·채널·시트인지.

아니요

아직 트리를 탈 수 없다데이터가 어디 있는지 먼저 적는다. 이게 안 적히면 도구도 못 고른다.

네

F2로 계속 →

그 데이터를 지금 내가 꺼낼 수 있나?

커넥터·API·DB가 있고, 권한도 나에게 온다.

네

F4로 계속 →

아니요 · 수단이 없거나 권한이 안 나온다

F3로 계속 →

그 데이터가 흘러 들어온 다른 곳이 있나?

메일함·시트·데이터웨어하우스.

네 · 하류에서 읽으면 된다

원천 대신 하류에서 읽는다목적이 알림·집계면 대개 이걸로 충분하다. 읽기 전용으로 스코프를 바꾼다.

그리고 F4로 계속 →

아니요 · 그 시스템에서만 볼 수 있다

여기서 멈춘다 · 개발 티켓으로 넘긴다자동화 범위 밖이다.

실제 데이터를 그대로 써도 되나?

개인정보·보안 정보가 끼지 않는다.

네

F5로 계속 →

아니요 · 민감 정보가 끼어 있다

목업·마스킹 데이터로 시작한다식별정보는 결과물에 넣지 않고, 대신 조회 키만 남긴다.

그리고 F5로 계속 →

판단 기준을 숫자·조건으로 지금 말할 수 있나?

'왜 3일인가'에 답할 수 있다.

아니요

기준 정의가 첫 숙제다임계값·필터·분류 기준을 먼저 확정한다. 도구는 그다음에 고른다.

네

F6로 계속 →

결과를 내보낼 쪽에 넣을 수단이 있나?

발송·업로드·기입 API.

네

F7로 계속 →

아니요 · 마지막 칸이 막혀 있다

초안까지만 자동화한다마지막 업로드·발송·결재는 사람이 한다. 이것만으로도 대개 대부분이 줄어든다.

그리고 F7로 계속 →

이 결과를 누가 받나?

나만 본다

1단계로 넘어간다제약 없이 도구를 고른다.

사내 다른 사람에게 간다

드라이런 게이트를 먼저 통과한다1~2주 본인 DM으로만 돌려 건수·문구를 검증하고, 수신자 매핑을 확보한 뒤 실제 발송으로 전환한다. 그다음 1단계.

사외 사용자가 접속한다

개발 협업 구간이다서버 배포·도메인·인증이 붙는다. 혼자 끝낼 수 있는 범위를 넘는다.

1 · 2단계

자동화할지 말지, 그리고 무엇으로 만들지

앞부분(반복성·누적시간·규칙·리스크)에서 자동화 여부와 설계 제약이 정해지고, 뒷부분에서 도구가 정해진다.

도구를 가르는 축

축 1

쓰는 사람이 나 하나인가팀이 공용으로 의존하면 개인 도구의 영역을 벗어난다. 실행 이력·재시도·권한·운영 감시가 필요해지는 지점.

축 2

대상이 코드베이스인가레포를 직접 고치면 Claude Code 계열. 문서·데이터·조사면 Cowork 계열.

축 3

절차가 이미 굳었는가굳었으면 저장해두고 반복 호출(Routine · Project), 안 굳었으면 대화로(Chat).

축 4

실행 비용이 감당되는가Routine 횟수 한도, n8n 실행 단위 과금. 한도를 넘으면 도구를 바꾼다.

설계 조건 배지 7종

✂️반자동으로 범위를 줄이세요 — 수집·정리·초안까지만 자동으로, 최종 결정은 사람이.

🚦승인 게이트 필수 — 외부로 나가거나 되돌리기 어려운 일이라, 자동은 초안까지. 마지막 실행은 사람이 클릭.

🔔실패 알림 필수 — 조용히 실패하는 자동화가 수동보다 나빠요. 알림 없는 완전 자동은 만들지 마세요.

🪞원천 대신 하류에서 읽기 — 원래 시스템에 권한이 없으니, 데이터가 흘러든 메일함·시트·DW에서 읽는 방식으로 설계하세요.

🔒민감 정보 주의 — 개인정보는 결과물에 넣지 말고, 조회용 번호(주문번호 등)만 남기세요. 실습은 목업 데이터로.

🧪드라이런 먼저 — 남에게 가는 알림은 1~2주 내 DM으로만 돌려 건수·문구를 검증한 뒤 실제 발송으로 전환하세요.

🪶작게 만드세요 — 한 달에 아끼는 시간이 크지 않은 일이라, 완성형을 짓지 말고 30분 안에 되는 최소 버전으로 시작하세요. 예외 처리는 실제로 걸릴 때만 붙입니다.

갈림길 — tree.ts에서 생성

이 일, 앞으로 또 하게 되나요?

같은 형태의 일이 다시 돌아오는지가 첫 갈림길이에요.

아니요, 이번 한 번이면 끝이에요

도착점 · ☕ 한 번이면 충분형 →

네, 계속 돌아오는 일이에요

Q2로 계속 →

이 일에 한 달에 시간을 얼마나 쓰나요?

적게 쓰는 일도 자동화합니다 — 얼마나 공들여 만들지만 달라져요.

30분도 안 돼요

작게 만들라는 조건이 붙어요

🪶 배지가 붙는다작게 만드세요 — 한 달에 아끼는 시간이 크지 않은 일이라, 완성형을 짓지 말고 30분 안에 되는 최소 버전으로 시작하세요. 예외 처리는 실제로 걸릴 때만 붙입니다.

Q3로 계속 →

30분은 훌쩍 넘어요

Q3로 계속 →

일하는 방식이 정해져 있나요?

같은 상황이면 항상 같은 순서·같은 기준으로 처리하는지.

네, 순서와 기준이 딱 정해져 있어요

Q5로 계속 →

아니요, 그때그때 판단이 달라요

Q4로 계속 →

판단할 때 참고하는 자료는 매번 비슷한가요?

결정은 그때그때 달라도, 보는 자료는 늘 같은 경우가 많아요.

네, 모으는 자료는 늘 똑같아요

자료 수집·정리까지만 자동화할 수 있어요

✂️ 배지가 붙는다반자동으로 범위를 줄이세요 — 수집·정리·초안까지만 자동으로, 최종 결정은 사람이.

Q5로 계속 →

아니요, 자료도 그때그때 달라요

도착점 · 🎨 감으로 일하는 장인형 →

이 일에 쓰는 데이터, 지금 직접 꺼내볼 수 있나요?

사내 시스템·구글시트·메일함·Slack 등 어디든요.

네, 내가 직접 열어볼 수 있어요

Q5P로 계속 →

화면으로는 보는데, Claude를 연결할 방법이 없어요

커넥터·API가 없는 사내 시스템

도착점 · 🔌 전용 통로가 필요한 개통형 →

어디 있는지는 아는데, 나에겐 권한이 없어요

Q5B로 계속 →

어디에 있는지 잘 모르겠어요

도착점 · 🗺️ 보물지도가 필요한 탐험가형 →

Q5B

그 데이터가 흘러 들어오는 다른 곳이 있나요?

예: 결과가 메일로 오거나, 누가 시트에 옮겨두거나, 데이터웨어하우스에 쌓이거나.

있어요 — 메일함·시트 같은 데서 볼 수 있어요

원천 대신 거기서 읽으면 돼요

🪞 배지가 붙는다원천 대신 하류에서 읽기 — 원래 시스템에 권한이 없으니, 데이터가 흘러든 메일함·시트·DW에서 읽는 방식으로 설계하세요.

Q5P로 계속 →

없어요 — 그 시스템에서만 볼 수 있어요

도착점 · 🤝 개발 협업 필요형 →

Q5P

데이터에 개인정보·보안 정보가 섞여 있나요?

고객 연락처, 지원자 정보, 인사 정보 같은 것들이요.

아니요, 민감한 건 없어요

Q6로 계속 →

네, 섞여 있어요

만들 수는 있어요 — 설계 조건이 붙어요

🔒 배지가 붙는다민감 정보 주의 — 개인정보는 결과물에 넣지 말고, 조회용 번호(주문번호 등)만 남기세요. 실습은 목업 데이터로.

Q6로 계속 →

잘못 실행되면 되돌릴 수 있나요?

외부 발송·삭제·결제·공개가 끼면 '되돌리기 어렵다'예요.

실수해도 다시 하면 돼요

🔔 배지가 붙는다실패 알림 필수 — 조용히 실패하는 자동화가 수동보다 나빠요. 알림 없는 완전 자동은 만들지 마세요.

Q7로 계속 →

외부로 나가거나 되돌리기 어려워요

만들 수 있어요 — 승인 단계가 붙어요

🚦 배지가 붙는다승인 게이트 필수 — 외부로 나가거나 되돌리기 어려운 일이라, 자동은 초안까지. 마지막 실행은 사람이 클릭.

Q7로 계속 →

이 결과물, 누가 쓰게 되나요?

쓰는 사람의 범위가 도구를 가르는 가장 큰 축이에요.

나 혼자 봐요

Q8로 계속 →

우리 팀이나 다른 부서도 같이 써요

QT1로 계속 →

회사 밖 사람도 접속해요

고객, 지원자, 외부 파트너 등

도착점 · 🤝 개발 협업 필요형 →

QT1

팀이 쓰는 건 어떤 형태인가요?

알아서 돌아가는 흐름인지, 사람이 열어서 조작하는 화면인지.

알림·리포트처럼 알아서 돌아가는 흐름이에요

공용 인프라 쪽으로 가요

🧪 배지가 붙는다드라이런 먼저 — 남에게 가는 알림은 1~2주 내 DM으로만 돌려 건수·문구를 검증한 뒤 실제 발송으로 전환하세요.

QN1로 계속 →

사람이 열어서 쓰는 화면·도구예요

조회 화면, 계산기, 신청 폼, 대시보드…

도착점 · 🖥️ 팀의 작업대형 →

주로 다루는 대상이 코드인가요?

저장소(레포)를 고치고 테스트하는 개발 작업인지.

네, 개발 작업이에요

Q9로 계속 →

아니요 — 문서·데이터·메일·시트 쪽이에요

Q10로 계속 →

이 레포 작업, 방식을 정해두고 반복 호출할 건가요?

매번 다른 작업이면 대화형, 같은 작업의 반복이면 루틴이에요.

네, 정해두고 계속 돌릴 거예요

루틴에는 실행 횟수 한도가 있어요 — 고빈도면 다시 생각

도착점 · 🔧 정비사형 →

아니요, 매번 하는 일이 달라요

도착점 · ⌨️ 페어 코딩형 →

Q10

이 일은 무엇으로 시작되나요?

방아쇠가 무엇인지 — 시계인지, 나인지, 다른 시스템인지.

정해진 시각·주기가 되면

매일 아침, 매주 월요일, 매월 초…

도착점 · 🌅 아침 브리핑형 →

내가 필요할 때 부르면

Q11로 계속 →

다른 곳에서 무슨 일이 생기면

요청 접수, 상태 변경, 메시지 도착…

QN1로 계속 →

Q11

처리하는 방식과 기준이 이미 굳었나요?

매번 같은 방식으로 하길 원하는지, 아직 방식을 찾는 중인지.

네, 늘 같은 방식으로 해요

도착점 · 🧰 내 손안의 비서형 →

아직 방식을 찾아가는 중이에요

도착점 · 🍞 아직 굳지 않은 반죽형 →

QN1

얼마나 촘촘하게 확인해야 하나요?

확인 주기가 아주 짧으면 만드는 방식이 달라져요.

하루 몇 번, 또는 일이 생길 때만이면 충분해요

도착점 · 🏭 팀의 파이프라인형 →

몇 분 단위로 계속 지켜봐야 해요

실시간 감시에 가까워요

도착점 · 📡 24시간 감시탑형 →

도착점

13개 결과 카드

진단 테스트가 내놓는 카드 전체. 이 목록도 tree.ts에서 직접 옵니다.

☕ 한 번이면 충분형Claude Chat

이번 한 번뿐인 일에 자동화를 짓는 건 배보다 배꼽이에요.

일회성 업무는 자동화 대상이 아니에요. Claude와 대화로 처리하고 깔끔하게 끝내는 게 가장 빠릅니다. 단 — 같은 일이 세 번째 돌아온다면, 그때 이 테스트를 다시 해보세요. 답이 달라져 있을 거예요.

Claude Chat에 업무를 그대로 설명하고 함께 처리한다
잘 됐던 프롬프트는 메모해 둔다
같은 일이 또 생기면 이 테스트를 다시 한다

🎨 감으로 일하는 장인형SOP 문서화 먼저

이 일의 진짜 자산은 자동화가 아니라 당신 머릿속 기준이에요.

매번 판단이 다르고 모으는 자료도 다른 일은 지금 자동화할 수 없어요. 하지만 '나는 어떤 기준으로 판단하는가'를 글로 적기 시작하면, 그 문서가 쌓인 뒤 자동화의 문이 열립니다.

최근 처리한 3건을 놓고 '왜 그렇게 판단했는지' 적어본다
판단 기준이 문장으로 적히면 SOP 문서로 만든다
SOP가 생기면 이 테스트를 다시 한다

🗺️ 보물지도가 필요한 탐험가형데이터 위치 파악 먼저

도구를 고르기 전에, 데이터가 어디 사는지부터 찾아야 해요.

이 일에 쓰는 정보가 어느 시스템·시트·메일함에 있는지 아직 말할 수 없다면, 어떤 도구도 고를 수 없어요. 어렵지 않아요 — 다음에 이 일을 할 때 '내가 지금 뭘 열어보고 있지?'를 적기만 하면 됩니다.

다음에 이 일을 할 때, 여는 화면·파일·채널을 전부 메모한다
각각이 어느 시스템(사내 시스템·구글시트·메일·Slack)인지 적는다
목록이 완성되면 이 테스트를 다시 한다

🔌 전용 통로가 필요한 개통형Custom MCP 연결 먼저

데이터는 있는데 Claude가 드나들 문이 없어요 — 문은 만들 수 있습니다.

사람 눈으로는 보이는데 커넥터·API 통로가 없으면 자동화가 첫걸음부터 막혀요. MCP 서버를 붙이면 그 시스템도 Claude가 직접 읽고 쓰는 도구가 됩니다. 회사에 이미 연결된 커넥터가 있는지부터 확인하고, 없으면 만들 안건이에요.

그 시스템에 이미 사내 MCP·커넥터가 있는지 AX 스쿼드에 확인한다
없다면 시스템에 API가 있는지 확인하고, 커스텀 MCP 구축을 AX 스쿼드와 상의한다
통로가 생기면 이 테스트를 다시 한다 — 보통 비서형·브리핑형이 나와요

🤝 개발 협업 필요형AX 스쿼드 · 개발팀과 상의

혼자 끝낼 수 있는 범위를 넘었어요 — 그게 나쁜 소식은 아니에요.

데이터에 접근할 방법이 없거나, 회사 밖 사람이 접속해야 하는 일은 서버·권한·인증이 필요한 개발 협업 구간이에요. 실제로 사내에서도 이런 안건은 개발 파트로 넘기거나 AX 스쿼드와 함께 진행했습니다. 지금까지 답한 내용을 그대로 들고 가면 이야기가 빨라져요.

이 테스트 결과와 업무 설명을 함께 정리한다
AX 스쿼드에 핸즈온 세션 또는 검토를 요청한다
우회로(읽기 전용 조회 등)가 있는지 함께 찾는다

🍞 아직 굳지 않은 반죽형Claude Chat

반복되는 일이지만, 아직 '나만의 방식'이 안 굳었어요.

절차가 굳기 전에 자동화를 만들면 계속 뜯어고치게 돼요. 지금은 Claude Chat으로 그때그때 처리하면서 방식을 다듬는 시기입니다. 같은 방식으로 세 번 돌면 — 그때가 자동화 타이밍이에요.

Claude Chat으로 처리하되, 쓴 프롬프트를 매번 저장한다
3회쯤 돌면 프롬프트에서 공통 절차를 뽑아낸다
절차가 보이면 이 테스트를 다시 한다 (아마 프로젝트형이 나올 거예요)

🧰 내 손안의 비서형Claude Cowork Project

부르면 정해진 방식대로 일해주는 나만의 작업 공간이 맞아요.

절차와 기준이 굳은 반복 작업이에요. Cowork 프로젝트를 만들어 지침·연결 도구·폴더를 세팅해두면, 매번 처음부터 설명하지 않고 '그거 해줘' 한마디로 같은 품질이 나옵니다. 자주 쓰는 절차는 스킬로 만들어 끼우면 더 단단해져요.

Cowork 프로젝트를 만들고 업무 지침을 적어 넣는다
필요한 커넥터(Slack·Confluence·Drive 등)를 연결한다
3회 이상 돈 절차는 스킬로 만들어 재사용한다

🌅 아침 브리핑형Claude Cowork Schedule (예약 작업)

정해진 시간에 알아서 돌고, 당신은 결과만 받아보면 돼요.

시계가 트리거인 개인 업무예요. 예약 작업으로 걸어두면 정해진 시각에 Claude가 알아서 조사·정리하고 리포트로 보내줍니다. 아침 브리핑, 주간 정리, 정기 모니터링이 전부 이 유형이에요.

원하는 결과물 형태(리포트·요약·표)를 한 번 정의한다
예약 작업으로 등록하고 주기를 정한다
1~2주는 결과를 검수하면서 지시문을 다듬는다

⌨️ 페어 코딩형Claude Code

코드를 직접 고치는 일은 대화하면서 함께 짜는 게 제일 빨라요.

대상이 코드베이스이고 매번 하는 일이 다르다면, Claude Code로 그때그때 대화하며 작업하는 형태가 맞아요. 기능 구현, 리팩터링, 버그 수정처럼 판단이 계속 필요한 일이 여기 속합니다.

Claude Code를 레포에 연결한다
작업 단위로 대화하며 구현·리뷰를 진행한다
반복되는 레포 작업이 생기면 루틴으로 승격한다

🔧 정비사형Claude Code Routine

레포를 주기적으로 손보는 일은 정의해두고 반복 호출하세요.

절차가 굳은 레포 작업이에요. 루틴으로 정의해두면 시각·수동·이벤트 등 원하는 트리거로 반복 실행할 수 있습니다. 정기 점검, 의존성 업데이트, 테스트 스윕 같은 일이 여기 속해요.

작업 절차를 루틴으로 정의한다
트리거(시각·수동·이벤트)를 붙인다
실행 결과 알림을 반드시 걸어둔다

🖥️ 팀의 작업대형Claude Code로 앱 만들기

흐름이 아니라 도구가 필요한 일이에요 — 이제 앱도 직접 만들 수 있습니다.

사람이 열어서 조회하고 입력하는 화면이 필요하면, 알아서 도는 자동화(n8n)가 아니라 작은 앱이 맞아요. Claude Code와 대화하며 비개발자도 동작하는 버전까지는 만들 수 있습니다. 다만 팀이 접속하려면 서버·배포·권한이 붙어서, 공개 직전 구간은 AX 스쿼드와 함께 가는 게 빠릅니다.

화면에 꼭 있어야 할 조회·입력 항목을 종이에 먼저 그린다
Claude Code로 동작하는 버전을 내 PC에서 만들어 검증한다
팀·외부에 열려면 배포·권한을 AX 스쿼드와 상의한다

🏭 팀의 파이프라인형n8n

여러 사람이 기대는 일은 개인 도구가 아니라 공용 인프라에 올려야 해요.

팀이 함께 의존하거나 다른 시스템의 사건으로 시작되는 일은 n8n 워크플로우가 맞아요. 실행 이력·재시도·에러 처리가 붙어서 '조용히 죽는' 사고를 막아줍니다. 중간에 요약·분류 같은 판단이 필요하면 AI 노드를 끼워 넣으면 돼요.

트리거(스케줄·웹훅)와 단계를 종이에 먼저 그린다
n8n에서 워크플로우로 구성한다 — 언어 판단은 AI 노드로
처음 1~2주는 결과를 내 DM으로만 받아 검증한 뒤 실제 발송으로 전환한다

📡 24시간 감시탑형전용 워커 (AX 스쿼드와 상담)

분 단위 상시 감시는 n8n에 올리면 실행 횟수가 폭발해요.

짧은 주기로 계속 확인해야 하는 일은 n8n 실행 단위 비용·부하를 감당하기 어려워요. 감시 부분만 전용 서버(워커)로 돌리고, 감지된 이후의 처리(알림·정리)는 n8n이나 Claude에게 넘기는 구조가 맞습니다. 이 구간은 개발 지원이 필요하니 AX 스쿼드와 상의하세요.

'꼭 분 단위여야 하는지' 먼저 재검토한다 — 웹훅으로 밀어줄 수 있으면 n8n으로 충분
정말 상시 감시라면 AX 스쿼드에 워커 구축을 상담한다
감지 이후 처리는 n8n·Claude로 분리해 설계한다

3단계

이 절차를 스킬로 떼어낼 것인가

스킬은 도착점이 아니라 도착점에 얹는 재사용 단위다. Project·Schedule·Code·Routine 어디에든 붙는다. n8n으로 간 일은 워크플로우 자체가 그 역할을 하므로 이 단계를 지난다.

갈림길

매번 같은 설명·순서·기준을 프롬프트에 다시 쓰고 있는가?

아니요

스킬로 만들지 않는다그때그때 프롬프트로 충분하다.

네

S2로 계속 →

그 절차가 3회 이상 같은 형태로 돌았는가?

아니요

아직 대화로 두고 관찰한다굳기 전에 만들면 스킬을 계속 고치게 된다.

네

S3로 계속 →

판단 기준과 산출물 형식을 글로 적을 수 있는가?

아니요

기준을 먼저 문서화한다SOP 없이 만든 스킬은 매번 다른 결과를 낸다. 문서가 생기면 이 트리로 돌아온다.

네

S4로 계속 →

입력이 달라져도 같은 절차로 처리되는가?

아니요 · 케이스마다 절차가 갈린다

스킬 하나로 묶지 않는다케이스별로 쪼개거나, 공통 상위 절차만 스킬로 남긴다.

네

S5로 계속 →

쓰는 사람이 나 하나인가?

네 · 나만 쓴다

개인 스킬로 만든다필요할 때 호출해서 같은 절차로 돌린다.

아니요 · 팀도 같은 기준으로 돌아야 한다

플러그인으로 묶어 배포한다스킬·연결 도구·지침을 함께 패키징해 팀이 같은 결과를 내게 만든다.

스킬을 만들 때의 규칙

3번 돌고 나서 만든다굳기 전에 만든 스킬은 계속 고치게 된다. 같은 형태로 세 번 돈 절차만 떼어낸다.

글로 못 적으면 스킬이 아니다판단 기준과 산출물 형식을 문장으로 못 쓰면, 스킬이 아니라 SOP를 먼저 써야 한다.

케이스마다 절차가 갈리면 쪼갠다하나로 묶으면 분기 지옥이 된다. 공통 상위 절차만 스킬로 남기고 나머지는 분리한다.

팀이 쓰면 플러그인으로 묶는다스킬 하나만 넘기면 연결 도구·지침이 빠져 같은 결과가 안 나온다. 함께 패키징한다.

스킬이 아니라 다른 것일 때절차가 아니라 배경 지식·맥락이면 프로젝트 지침으로. 완전히 결정적인 계산이면 스크립트로.

규칙

트리 전체를 쓸 때의 규칙

0단계를 건너뛰지 않는다9건 중 완결된 건 1건. 나머지는 도구를 못 골라서가 아니라 권한·기준·수신자가 안 정해져서 멈췄다.

첫 발사는 항상 본인 DM으로남에게 가는 알림은 1~2주 드라이런으로 건수와 문구를 검증한 뒤 전환한다.

Routine은 실행 횟수 한도를 먼저 확인한다절차가 굳었어도 빈도가 한도를 넘으면 둘 수 없다. 주기를 낮추거나 고빈도 부분만 떼서 옮긴다.

실시간 감지는 워커로 뺀다분 단위 폴링을 n8n에 두면 execution이 터진다. 웹훅으로 밀어줄 수 있는지 먼저 확인한다.

되돌릴 수 없으면 승인 게이트외부 발송·삭제·결제·공개가 끼면 자동은 초안까지만. 마지막 실행은 사람이 클릭한다.

완전 자동에는 실패 알림이 붙는다조용히 실패하는 자동화가 수동보다 나쁘다. 알림 없는 완전 자동은 만들지 않는다.

월 30분은 자동화 여부가 아니라 만드는 크기를 가른다적게 쓰는 일도 자동화한다. 기준선 아래면 완성형을 짓지 말고 30분 안에 되는 최소 버전으로 만든다 — 트리에서 🪶 배지가 붙는 자리.

규칙이 안 명확하면 범위를 줄인다전부 자동화하려다 막히는 대신, 수집·정리·초안까지만 자동화하고 결정은 사람이 한다.

3회 규칙같은 일을 Chat에서 세 번 하게 되면 그건 이미 반복 업무다. 트리 위로 올려보낸다.

트리는 출발점이지 정답이 아니다도착점이 애매하게 걸리는 일이 나오면, 그 갈림길이 우리 팀에 맞게 안 잡힌 것이다. 분기를 고친다.