Cusdis 자동화 강좌 소개

처음 자동화를 만들 때 가장 헷갈리는 것은 도구가 많다는 사실이 아니라, 각 도구가 어떤 역할을 하는지 구분되지 않는다는 점입니다. Cusdis는 댓글 이벤트를 발생시키는 원천이고, n8n은 그 이벤트를 받아 흐름을 실행하는 엔진이며, Cloudflare Tunnel은 self-hosted 환경에서 외부 신호를 받을 수 있게 해 주는 공개 경로 역할을 합니다.

이 챕터는 전체 흐름을 먼저 잡는 데 집중합니다. 댓글이 들어오면 어떤 신호가 어디로 이동하고, 어느 시점에서 AI가 개입하며, 어느 지점에서 최종 승인 요청이 발생하는지를 큰 그림으로 이해해야 이후 노드 설정이 쉬워집니다. 구조를 모르면 세부 설정이 많아질수록 더 막히기 쉽습니다.

또한 n8n Cloud와 self-hosted를 어떻게 선택할지도 여기서 다룹니다. 초급자에게는 보통 n8n Cloud가 더 빠른 출발점이지만, self-hosted는 더 많은 통제권을 줍니다. 다만 통제권은 곧 공개 주소, 업데이트, 보안 패치, 운영 책임을 함께 가진다는 뜻이기도 합니다.

자동화에서 입력은 가장 먼저 이해해야 하는 시스템 계약입니다. 댓글 이벤트가 어떤 필드를 포함하는지, site ID는 어디에 들어 있는지, 본문과 작성자 정보는 어떤 형태인지 모르고 다음 단계를 만들면, AI 판정이나 승인 API가 뒤에서 계속 어긋나게 됩니다. 그래서 이 챕터는 단순 연결보다 payload 읽기에 더 큰 비중을 둡니다.

Cusdis Site settings에서 webhook URL을 등록하는 행위는 단순 설정이 아니라 “댓글 시스템과 자동화 엔진 사이에 연결을 연다”는 의미를 가집니다. 이후 n8n Webhook 노드는 그 연결의 첫 수신 지점이 됩니다. 따라서 입력 테스트는 정상 댓글과 스팸성 댓글 두 경우 모두 최소 한 번씩 해 보는 것이 좋습니다.

이 챕터를 잘 이해하면 이후 단계가 훨씬 단순해집니다. AI 판정, 분기, 승인 로직은 모두 결국 이 입력 구조를 기준으로 움직이기 때문입니다. 입력이 흔들리면 뒤쪽 모든 노드가 흔들립니다.

생성형 AI를 자동화 안에 넣을 때 가장 위험한 순간은 “모델이 대충 자연어로 답했는데도 다음 단계가 계속 진행되는 상태”입니다. 사람에게는 그럴듯한 답변이더라도, 기계에게는 JSON 계약이 더 중요합니다. 이 챕터는 분류 결과와 이유, 답글 초안을 항상 같은 구조로 돌려주게 만드는 이유를 설명합니다.

프롬프트는 단순 요청문이 아니라 계약서처럼 써야 합니다. 어떤 필드가 반드시 있어야 하는지, 어떤 값만 허용되는지, 길이는 어느 정도인지, 확신이 없을 때는 어떤 상태를 반환해야 하는지를 함께 적어야 합니다. 그래야 AI가 애매한 경우에도 REVIEW 같은 중간 상태로 빠질 수 있고, 운영 리스크를 줄일 수 있습니다.

하지만 계약을 적어 두는 것만으로는 부족합니다. 실제 운영에서는 모델 출력이 깨지거나 일부 필드가 누락될 수 있기 때문에, JavaScript 후처리 코드로 파싱 실패를 흡수하고 기본값을 부여하는 방어 코드가 필요합니다. 이 강의는 그 방어 계층이 왜 필수인지 보여 줍니다.

자동화가 실제 운영처럼 느껴지려면, “맞는 댓글만 다음 단계로 보내는 것”과 “너무 기계적으로 보이지 않게 처리하는 것”이 동시에 필요합니다. If 노드는 이 흐름에서 가장 중요한 안전 장치입니다. Gemini가 NORMAL로 분류한 경우만 다음 단계로 보내고, SPAM이나 REVIEW는 다른 경로로 분리함으로써 자동화가 무분별하게 실행되는 것을 막습니다.

Wait 노드는 단순한 꾸밈이 아닙니다. 댓글이 달리자마자 즉시 답글이 달리면 사용자에게 기계적인 반응으로 보일 수 있고, 운영자 입장에서도 자동화가 너무 공격적으로 느껴질 수 있습니다. 짧은 랜덤 지연은 기술적으로는 사소해 보여도, 운영 경험 측면에서는 중요한 차이를 만듭니다.

마지막으로 HTTP Request 노드는 실제 행동을 발생시키는 지점입니다. 여기서는 승인 요청과 답글 본문이 정확한 구조로 전송되어야 하고, 어느 사이트를 대상으로 하는지와 인증 정보가 올바른지도 확인되어야 합니다. 이 단계는 워크플로우가 “판단”에서 “실행”으로 넘어가는 구간이기 때문에 가장 신중해야 합니다.

자동화는 한 번 돌아간다고 끝이 아닙니다. 공개 환경에 올리는 순간부터는 오탐, 미탐, 자격 증명 만료, webhook 장애, 모델 응답 이상, API 호출 실패 같은 현실적인 문제가 생길 수 있습니다. 따라서 마지막 챕터는 “더 멋진 자동화”보다 “문제 생겼을 때 어떻게 버틸 것인가”에 초점을 둡니다.

운영자의 관점에서 가장 중요한 것은 fallback입니다. 문제가 생겼을 때 워크플로우를 끄고 수동 승인으로 되돌릴 수 있는가, JSON 파싱 실패 로그를 별도로 모을 수 있는가, 처음 며칠간은 사람이 직접 승인 결과를 눈으로 확인하는가 같은 질문이 중요합니다. 이런 운영 질문은 자동화 자체만큼 중요합니다.

확장 아이디어도 이 기반 위에서 나옵니다. 슬랙 알림, 댓글 아카이빙, 운영 리포트, 모더레이션 대시보드 같은 기능은 멋져 보이지만, 먼저 안전한 기본 루프가 있어야 의미가 있습니다. 이 강의는 확장을 “다음 단계”로 소개하되, 기초 운영 루프를 먼저 안정화하라고 권합니다.