완전 자동화가 항상 옳은 것은 아닙니다. 고객에게 나가는 마케팅 메일, 잘못 보내면 환불해야 하는 결제 요청, AI가 작성한 공지문처럼 한 번 보내면 되돌릴 수 없는 작업에는 사람의 눈이 꼭 필요합니다. n8n의 Send and Wait for Response 기능은 이중 잠금 금고와 같습니다. 자동화가 문을 열려면 사람의 승인 키가 필요합니다.
Send and Wait for Response란?
Slack, Gmail, Microsoft Teams 노드 등에 내장된 이 옵션을 쓰면, 노드가 실행될 때 승인 버튼이 달린 메시지를 보내고 즉시 대기 상태로 전환됩니다. 워크플로우는 응답이 올 때까지 멈춘 채 n8n 서버 메모리가 아닌 영속적인 Waiting 상태로 들어가므로, 하루 뒤에 응답해도 정상적으로 이어집니다.
사람 승인 워크플로우 흐름
트리거 (새 콘텐츠 생성 요청 등)
→ AI 초안 작성
→ Slack: Send and Wait for Response
버튼: [승인] [수정 요청] [거절]
↓ 응답 도착 (최대 N시간 대기)
→ IF (응답 타입 확인)
→ 승인: 현재 대상·상태·담당자 권한·기한·중복 재확인 → 조건이 맞으면 실행
→ 수정 요청: 초안 수정 후 재발송
→ 거절: 종료 처리 + 취소 로그실습: Slack 승인 버튼 워크플로우 만들기
Slack 승인 워크플로우
- 새 워크플로우에 Manual Trigger(또는 Webhook)를 추가합니다. 이번 실습은 수동으로 트리거해 흐름을 확인합니다.
- Edit Fields(Set) 노드를 추가해 발송할 초안 내용을 담은 필드를 만듭니다. 예: draft = '이번 주 뉴스레터 초안입니다. 확인 후 승인해 주세요.'
- Slack 노드를 추가하고 Resource를 Message, Operation을 Send and Wait for Response로 설정합니다.
- 메시지 본문에 초안 내용을 표현식으로 넣습니다. Approval Type은 Custom Options로 설정하고, 버튼을 두 개 만듭니다. 첫 번째 버튼: label을 승인, value를 approved로. 두 번째 버튼: label을 거절, value를 rejected로 입력합니다.
- Slack 노드 뒤에 IF 노드를 추가하고, 조건을 '$json.data.value가 approved와 같다'로 설정합니다.
- true 쪽(승인)에는 현재 대상·상태·담당자 권한·기한·중복을 다시 확인하는 분기를 둡니다. 이번 실습에서는 실제 발송·결제 대신 Edit Fields로 가상 실행 결과만 남깁니다. false 쪽(거절)에는 반려 이유를 기록하고 종료합니다. 실서비스는 서버에서 확인한 신원과 권한, 현재 원본을 검증한 뒤 실행해야 합니다.
- Execute Workflow로 실행 후 Slack에서 승인·거절 버튼을 눌러 양쪽 분기가 모두 작동하는지 확인합니다.
승인 대기 방식 비교
| 방식 | 작동 방법 | 어울리는 상황 |
|---|---|---|
| Slack Send and Wait | 승인 버튼이 달린 Slack 메시지, 클릭으로 응답 | 팀이 Slack을 주로 쓸 때 |
| Gmail Send and Wait | 승인 링크가 포함된 이메일, 링크 클릭으로 응답 | 이메일로만 소통하는 외부 협력사 |
| Wait 노드 + Webhook | Wait 노드가 새 Webhook URL을 생성, 외부 시스템이 호출 | 커스텀 승인 UI를 직접 만들 때 |
| 승인 기한 만료 | 기한이 지나면 실행하지 않고 재확인 요청 | 늦은 승인이 오래된 조건을 실행하지 않게 할 때 |
승인 메시지에는 판단에 필요한 정보를 충분히 담으세요. '초안입니다. 승인해 주세요'보다 '아래 뉴스레터를 120명에게 발송합니다. 내용, 링크, 발송 대상을 확인 후 승인해 주세요'처럼 무엇을 승인하는지, 결과가 어떻게 되는지를 명확히 써야 담당자가 책임 있는 판단을 할 수 있습니다.
워크플로우가 Waiting 상태인 동안에는 실행 한도를 소비하지 않지만, 오래 대기 중인 워크플로우가 많으면 클라우드 플랜에 따라 제한이 생길 수 있습니다. Respond Within 옵션으로 최대 대기 시간을 설정하고, 시간이 지나면 자동으로 거절 처리하는 분기를 만들어 두세요.
- 적용 기준: '이게 잘못 실행되면 사과 메일을 보내야 하는가?'라고 자문해서 그렇다면 승인 지점을 반드시 넣으세요.
- 처음에는 Send and Wait의 수신자를 본인 계정으로만 지정해 흐름을 검증한 뒤, 실제 담당자로 바꾸는 절차를 밟으세요.
- AI가 작성한 콘텐츠를 자동으로 고객에게 바로 발송하는 구조는 초보 단계에서 가장 위험한 패턴입니다. 반드시 초안 저장 또는 승인 후 발송으로 시작하세요.
사람 승인을 자동화 흐름 안에 자연스럽게 넣으면, 속도와 안전성을 동시에 잡을 수 있습니다. 완전 자동화는 언제 사람을 배제할 수 있는지를 아는 것이고, 사람 승인은 어디서 사람이 개입해야 하는지를 아는 것입니다. 이 두 판단이 모여 신뢰할 수 있는 자동화가 완성됩니다.
5분 보강 — 승인 버튼보다 먼저 제안을 보존하기
담당자가 '승인'을 눌렀다는 사실과 실제 업무가 실행됐다는 사실은 다릅니다. 무엇을 승인했는지 남겨야 시간이 지나도 확인할 수 있습니다. 제안 카드에 대상 ID, 행동, 근거, 현재 버전, 담당자와 기한을 담고, 실행 직전에 현재 조건을 다시 확인하세요.
| 제안 카드 | 가상 교육 문의 예시 |
|---|---|
| 제안 / 요청 ID | P-12 / req-12 — 같은 업무 재시도에도 유지 |
| 대상 | 문의 Q-12, 회사 ORG-7, 일정 S-16 |
| 행동 / 근거 | 일정 확정 제안 / 요청 내용과 정원 확인 결과 |
| 기대 상태 / 버전 | 검토중 / 원본 v1 |
| 담당자 / 기한 | U-4 / 담당자가 정한 승인 유효 기한 |
| 기록 구분 | 제안 생성→승인 결정→실제 실행 결과를 따로 기록 |
승인 뒤에도 실행 전 확인이 남습니다
- 제안 보존 대상·행동·근거·기대 버전 기록
- 담당자 판단 승인·반려·재확인
- 현재 조건 확인 대상·상태·버전·권한·기한·중복
- 실행 또는 중단 실행 결과와 중단 이유 기록
확인되지 않은 정원은 먼저 확인합니다. 승인만으로 미확인 정보가 사실이 되지는 않습니다.
| 시험할 상황 | 기대 결과 |
|---|---|
| 정보가 확인되고 현재 조건·담당자 권한이 맞음 | 실행 가능 — 승인 기록과 실제 결과를 구별 |
| 담당자가 반려 | 실행하지 않음 — 반려 이유 보존 |
| 승인 후 원본 v2, 상태가 다른팀확정으로 바뀜 | 이전 제안 실행 차단 — 새 상황 재확인 |
| 승인 기한 만료 | 실행하지 않음 — 다시 확인 요청 |
| 권한 없는 사용자의 승인 요청 | 실행하지 않음 — 실행 전에 권한 검사 |
복사해서 따라 하기 — 승인 5가지 상황을 먼저 시험하기
가상 교육 문의 Q-12 / 회사 ORG-7 / 일정 S-16을 검토해줘.
제안 P-12, 요청 req-12, 기대 상태 '검토중', 기대 원본 버전 v1,
확인 담당자 U-4로 고정한다. 정원 등 필수 정보가 확인된 경우만 정상으로 본다.
다섯 상황의 결과와 근거를 표로 만들어줘.
① 담당자 권한과 현재 조건이 모두 맞음
② 담당자가 반려
③ 승인 뒤 원본 v2로 바뀌고 일정은 '다른팀확정'
④ 승인 기한 만료
⑤ 권한 없는 사용자가 승인 요청
결과는 실행 가능 / 실행하지 않음 / 재확인 필요로 구분해줘.
제안 생성, 승인 결정, 실제 실행 완료를 구별해줘.
같은 req-12 재시도는 새 업무로 만들지 마.
실제 예약·발송·외부 도구 호출은 하지 말고 결과표만 보여줘.선택 실습 약 7분 — 승인 뒤 원본이 바뀌면?
LeanX의 가상 과제로 직접 확인
- https://leanx.kr/ax-playground 를 열고 '고객 요청'을 선택합니다. '승인 뒤 원본이 바뀌면?' 보조 실습을 엽니다.
- 가상 문의 Q-12, 회사 ORG-7, 일정 S-16, 담당자 U-4와 원본 v1·검토중을 읽습니다. 실제 고객 입력이나 계정 연결은 필요하지 않습니다.
- '제안 만들기'를 누르고 '확인 역할 (학습용)'에서 '검토자 U-4'를 직접 선택합니다. '담당자 승인 (가상)'을 누릅니다. 승인만 했을 때 '누적 가상 처리'가 0건인지 확인합니다.
- '원본 v2로 변경'을 눌러 v2·다른팀확정으로 바꾼 다음 '실행 전 다시 확인'을 누릅니다. 이전 제안이 차단되고 원본 변경을 다시 확인해야 하는지 읽습니다.
- '실습 초기화'를 누릅니다. 원본이 바뀌지 않은 상태에서 '제안 만들기'→역할 '검토자 U-4' 선택→'담당자 승인 (가상)'→'실행 전 다시 확인' 순서로 진행합니다. 누적 가상 처리 1건을 확인하고 '실행 전 다시 확인'을 다시 눌러도 1건을 유지하는지 확인합니다.
완료 기준: 승인만으로 처리 0건, 원본 v2 변경 뒤 이전 실행 차단, 초기화 후 정상 모의 실행 1건, 같은 요청 중복 실행 0건입니다. 왜 중단됐는지 한 문장으로 설명하고, 자신의 업무에서 승인 뒤 바뀔 수 있는 값 하나를 적어보세요.
이 체험은 브라우저의 합성 데이터와 정해진 규칙으로 확인하는 학습용 모의 과제입니다. 실제 AI·예약·메일 발송이나 서버 인증을 수행하지 않습니다. 실서비스에서는 승인자 신원을 서버에서 확인하고, 권한·현재 원본·기한·중복을 검사해야 합니다. 버튼을 숨기거나 신원을 로그에 적는 것만으로 권한 검사가 되지는 않습니다.