n8n AI 자동화 실용 가이드: 반복 업무의 승인·오류·비용 설계

n8n AI 자동화를 반복 업무에 붙일 때는 문의 분류와 초안 생성부터 맡기고, 발송이나 게시 직전에 사람이 승인하는 구성으로 시작하길 권합니다. 이때 무엇을 승인할지, 실패하면 어떻게 복구할지, 최종 처리 1건당 비용이 얼마인지를 함께 정해 두세요. 그래야 소규모 사업자도 운영 부담이 어느 정도인지 판단할 수 있어요.

셋 중 가장 먼저 정할 것은 사람이 검토할 범위입니다. 초안에 판단 근거가 빠져 있으면 담당자가 그 근거를 다시 찾아야 해요. 그래서 승인 화면에는 실행할 내용과 근거를 나란히 보여 주는 편이 좋습니다.

고객지원과 콘텐츠 재가공, 승인은 어디에 둘까

기본 흐름은 ‘입력 → 초안 → 검토 → 실행 → 기록’입니다. n8n은 AI Agent에 연결된 도구마다 사람 승인을 요구하도록 설정하는 기능을 제공해요. 그 도구가 호출되면 실행을 멈추고 검토를 요청합니다. 승인하면 AI가 지정한 입력 그대로 실행되고, 거절하면 작업이 취소돼요. 구체적인 설정은 도구별 사람 승인 공식 문서에서 확인하세요.

업무마다 검토 화면에 띄울 항목은 다릅니다. 고객지원이라면 수신자와 답변 본문, 참조한 정책을 한 화면에서 봐야 해요. 문의 분류, 안내문 조회, 초안 생성까지는 자동으로 돌리고 환불이나 예외 보상은 담당자가 처리하도록 분기하는 구성을 생각하면 됩니다. 콘텐츠 재가공에서는 원문과 최종 문안, 게시 채널을 함께 보여 주세요. 여기서 검토자가 가장 공들여 봐야 할 부분은 원문의 주장과 게시 문안이 서로 맞는지입니다.

흔히 놓치는 지점은 승인이 어떤 버전에 대한 것이냐예요.

검토한 버전을 저장해 두고, 승인된 바로 그 내용을 발송하거나 게시해야 합니다. 승인 뒤에 문안을 다시 생성하면 사람이 본 내용과 실제로 나간 결과가 달라질 수 있어요. 거절된 건은 수정 단계로 보내고, 시간이 초과된 건은 담당자 확인으로 넘기세요. 수정본은 당연히 다시 승인을 받아야 합니다. 구분해 두자면, 도구 호출을 멈추고 승인받는 부분은 n8n의 공식 기능이고 버전 저장과 수정·담당자 분기는 업무에 맞춰 직접 짜야 하는 설계안이에요.

실패했을 때, 재실행보다 먼저 확인할 것

워크플로 설정에서 Error workflow를 지정해 두면 실행이 실패했을 때 별도의 오류 처리 흐름이 돌아갑니다. 이 흐름은 Error Trigger로 시작하니, 여기에 실패 기록 저장과 담당자 알림을 이어 주세요. 수신자나 게시 채널처럼 빠지면 안 되는 항목을 앞에서 검증하고, 누락됐을 때 Stop And Error 노드로 실패 처리하는 방법도 쓸 수 있어요.

여기서 많이 헷갈리는 게 있습니다. 실행이 성공했다고 답변이 적절하다는 뜻은 아니에요. 발송 노드가 정상적으로 작동해도 답변 내용은 정책과 어긋날 수 있으니, 필수 항목 검증과 사람의 내용 검토를 둘 다 두세요.

오류가 났을 때 바로 재실행 버튼을 누르기보다 외부 서비스의 발송·게시 결과와 실패 기록을 먼저 보길 권합니다. 이유는 재실행 방식에 있어요. 실행 내역 공식 문서를 보면 완료된 노드의 결과는 유지되지만, 실패한 노드는 이미 일부 처리한 항목까지 다시 처리할 수 있습니다. 답변 몇 건을 보낸 뒤에 실패했다면 재시도 과정에서 같은 답변이 한 번 더 나갈 수 있다는 얘기예요.

그래서 복구 판단용으로 처리 여부를 기록해 두는 방식을 권합니다. 고객지원은 문의 ID + 답변 버전, 콘텐츠는 원문 ID + 채널 + 게시 버전을 식별자로 쓰면 돼요. 실행 전에 같은 식별자로 완료 기록이 있는지 확인하고, 처리한 뒤에는 외부 서비스가 돌려준 결과도 함께 남기세요. 다만 이것만으로 충분하지 않은 경우가 있습니다. 발송은 됐는데 기록 저장이 실패했거나 동시 실행이 일어나면 식별자 기록만으로는 중복을 막기 어려워요. 저장소에 중복 제약을 걸 수 있는지, 대상 서비스가 같은 요청을 한 번만 처리하는 멱등성 기능을 지원하는지도 확인해야 합니다.

비용은 구독료보다 최종 처리 1건 기준으로

n8n 비용은 세 갈래로 나눠 봐야 정확해요. 워크플로 실행량에 따른 구독료, 워크플로 제작을 돕는 Assistant 크레딧, 실제 AI 호출에 드는 Gateway·외부 API 비용입니다. 이 중 Assistant 크레딧은 제작 지원용이라 워크플로 실행 자체에는 소비되지 않아요. 고객 답변을 생성하는 모델 비용과 섞어 계산하지 않도록 주의하세요.

비교 기준으로는 같은 기간의 총비용을 최종 처리된 문의나 게시물 수로 나눈 값을 씁니다. 총비용에는 구독료와 실제 서비스 사용료뿐 아니라 재생성·재시도로 늘어난 사용량, 승인·수정·복구에 들인 시간의 비용까지 넣어야 해요. 초안을 여러 번 만들었어도 최종 발송된 답변이 하나라면 처리 건수는 한 건입니다. 호출 단가가 낮더라도 수정 시간이 늘어나면 최종 처리 비용은 오히려 높아질 수 있어요.

Gateway 잔액을 엄격한 지출 상한으로 여기는 것도 조심해야 합니다. 잔액이 바닥나면 해당 노드는 멈추지만, 이미 진행 중인 요청은 완료될 수 있고 그 차액은 다음 충전 때 차감돼요. 수동 충전과 자동 충전 설정이 어떻게 다른지는 Gateway 공식 문서에서 구분해 확인하세요.

운영에 들어가기 전에는 네 가지 상황을 직접 시험해 보길 권합니다.

• 승인 거절 → 수정 단계로 넘어가는지
• 시간 초과 → 담당자 확인으로 넘어가는지
• 부분 처리 후 실패 → 중복 없이 복구되는지
• 잔액 소진 → 중단 알림이 오는지

여기서 제시한 업무 흐름은 설계 제안이니, 실제로 연결한 서비스에서 이 조건들을 검증한 뒤에 적용하세요.