9월 9일 n8n Assistant 안내는 자격 증명 접근과 활성화에 사용자의 승인을 둔다고 설명합니다. 이것이 매번 고객에게 보내는 메일 본문까지 검토했다는 뜻은 아닙니다. 제작 과정의 승인과 업무 건별 승인을 나눠 설계해 봅니다.
자동화가 “메일을 보내도 될까요?”라고 물었습니다. 그런데 누구에게 어떤 내용으로 보내는지 보이지 않습니다. 이 상태에서 승인 버튼을 누르는 것은 검토라기보다 추측에 가깝습니다. 사람이 판단할 정보를 먼저 화면에 모아 주세요.
예시는 고객 문의 답변입니다. AI가 초안을 작성했고, 담당자가 확인한 뒤 실제 발송하는 상황입니다. 아래 주소와 내용은 화면 구성을 설명하기 위한 가상 예시입니다.
| 승인 전에 보여 줄 것 | 예시 |
|---|---|
| 받는 사람 | 연습용 고객 A · 실제 주소는 발송 직전 확인 |
| 제목과 본문 | “문의하신 영수증 확인을 위해 주문번호를 알려 주세요.” |
| 실행할 행동 | 메일 1회 발송, 첨부 없음 |
| 승인 대상 버전 | reply-014 / 초안 v2 |
“왜 보내는가”도 한 줄로 붙이세요
원문의 “영수증을 못 받았다”는 문장과 AI가 만든 답변을 함께 보여 주면 검토가 빨라집니다. 주문을 조회하지 않았는데 “영수증을 재발송했습니다”라고 쓰여 있다면 담당자가 바로 고칠 수 있습니다. 원문, 확인한 사실, 제안한 답변이 한 화면에서 구분되어야 합니다.
승인 버튼 옆에는 수정과 보류 경로도 필요합니다. 모든 요청을 승인 또는 거절 두 가지로만 처리하면, 주문번호를 추가로 확인해야 하는 상황을 기록하기 어렵습니다.
승인 뒤 본문이 바뀌면 어떻게 될까요?
담당자가 v2를 확인했는데 발송 노드가 최신 초안 v3를 읽으면 승인한 내용과 실제 발송 내용이 달라집니다. 승인 기록에 본문 버전과 수신자를 묶어 저장하세요. 본문이나 첨부가 바뀌면 다시 검토하도록 해야 합니다.
승인 기록 예시 작업 ID: reply-014 검토한 버전: v2 상태: 승인 / 수정 요청 / 보류 검토자와 시각: 실제 로그인 사용자와 승인 시각 실행 결과: 발송 전 / 성공 확인 / 실패 / 결과 확인 필요
위 기록은 설계 예시입니다. “승인됨”과 “발송 성공”을 같은 칸으로 쓰지 마세요. 승인 뒤 연결 오류가 날 수도 있고, 응답이 끊겼지만 실제 메일은 발송됐을 수도 있습니다. 불확실한 상태에서 다시 보내기 전에 발송 내역을 확인해야 합니다.
n8n에서는 연결 범위를 확인하세요
n8n은 AI 도구 실행에 사람 검토를 넣는 기능을 안내합니다. 적용하려는 도구와 승인 채널을 설정한 뒤, 실제 승인 전에는 해당 행동이 실행되지 않는지 시험하세요. 일반 메일 노드 등 다른 경로가 승인을 우회하지 않는지도 봐야 합니다.
마지막으로 승인 버튼을 두 번 눌렀을 때도 메일은 한 번만 나가야 합니다. 작업 ID를 기준으로 이미 실행한 승인을 다시 처리하지 않도록 저장소에서 막으세요. 만료되거나 내용이 바뀐 승인은 새 검토로 돌리면 사람이 누른 버튼의 의미가 분명해집니다.
자료 확인
n8n · Introducing n8n Assistant · 2026-09-09
n8n · Human-in-the-loop for tools · 확인 2026-09-23
확인일: 2026년 9월 23일. 표·요청문·흐름도는 이해를 돕기 위해 구성했습니다. 계산 예시는 조건을 별도로 표시했으며, 실제 모델 성능을 측정한 결과는 아닙니다.