노코드 AI 에이전트로 요청 선별: 5단계 자동 분류 가이드

노코드 AI 에이전트는 코드 없이 들어온 요청을 자동으로 읽고 분류해 회신 초안까지 만드는 작업 흐름입니다.

요청을 사람이 하나씩 읽고 판단하는 대신, 접수 창구 1개와 분류 기준 3갈래를 먼저 정한 뒤 도구 3개를 연결하면 됩니다. 저희가 실무에서 쓰는 구성은 구글 폼(접수) → Make(연결) → GPT API(프로그램 연결 규격, 판단) 순서이며, 설정 자체는 5단계로 끝납니다. 다만 자동 발송까지 켜기 전에 2주 정도는 사람이 초안을 승인하는 기간을 두시길 권합니다. 분류 기준이 현실 요청과 맞는지 확인할 시간이 필요하기 때문입니다.

• 창구를 먼저 좁힌다 — 메신저·전화·메일로 흩어진 요청을 폼 1개로 모아야 자동화가 성립합니다.
• 판단은 3갈래로만 — 정상·재협의·거절 외에 분류를 늘리면 기준이 흔들리고 검수 시간이 늘어납니다.
• 회신은 초안까지만 — 기한 압박·책임 전가 신호가 잡힌 건은 경계 문구를 넣은 초안을 만들고 발송은 사람이 결정합니다.

이미 자동화를 여러 개 돌려 본 분보다, 노코드(코딩 없이 만드는 방식) 도구를 한 번도 연결해 본 적 없는데 성수기 요청부터 정리해야 하는 분에게 맞는 글입니다.

왜 지금 요청 선별 자동화를 준비해야 하나요?

9월은 요청의 성격이 한꺼번에 바뀌는 시기이기 때문입니다. 여름까지는 진행 중인 일이 이어지지만, 가을 성수기에 들어서면 새 요청이 겹쳐 들어옵니다.

• 4분기 캠페인 기획이 동시에 열린다 — 연말 프로모션 소재, 상세페이지 개편, 신규 채널 세팅 요청이 같은 주에 몰립니다.
• 남은 예산 집행 요청이 붙는다 — 하반기 예산을 소진해야 하는 부서에서 "이번 달 안에"라는 기한이 붙은 건이 들어옵니다.
• 연휴가 일정을 압축한다 — 명절 전후로 실작업일이 줄어드는데 마감일은 그대로 남아 압박이 커집니다.

이때 비용은 작업 시간이 아니라 판단 시간에서 발생합니다. 요청 하나를 읽고 "이걸 받아야 하나"를 고민하는 데 드는 시간이 실제 작업보다 길어지는 순간이 옵니다. 5인 팀 마케터가 겪는 전형적인 상황이 이것입니다. 하루에 열 건 넘는 요청을 받고, 절반은 기존 합의 밖의 일인데, 거절 문구를 쓰다가 결국 "일단 검토해 보겠습니다"로 끝냅니다.

요청을 판단하는 힘이 약해서가 아니라, 판단할 기준이 문서로 존재하지 않기 때문입니다. 기준이 사람 머릿속에만 있으면 피곤한 날에는 무너집니다. 노코드 AI 에이전트(여러 단계를 스스로 처리하는 AI 비서)는 그 기준을 시스템 바깥에 꺼내 놓는 장치에 가깝습니다.

어떻게 만드나요? 노코드 AI 에이전트 5단계 실행법

도구 3개를 순서대로 연결하면 됩니다. 각 단계는 무엇을, 어떻게, 어디까지 되면 끝인지로 나눠 정리했습니다.

1. 요청 접수 폼을 만든다 — 구글 폼에 필수 항목 6개(요청자·소속·요청 목적·희망 기한·필요 산출물·기존 합의 범위 포함 여부)를 넣습니다. 응답을 스프레드시트로 받도록 설정하고, 테스트 응답 1건이 시트에 쌓이면 완료입니다. 5인 팀 마케터는 사내 공지에 "요청은 이 폼으로만" 한 줄을 붙여 메신저 요청을 폼으로 돌렸습니다.
2. Make 시나리오를 연다 — Make 무료 요금제는 월 1,000 크레딧과 활성 시나리오 2개를 제공하며, 남은 크레딧은 기간이 끝나면 소멸합니다. 새 시나리오를 만들고 스프레드시트 신규 행 감지 모듈을 첫 단계로 둡니다. 테스트 실행에서 방금 넣은 응답이 그대로 읽히면 완료입니다.
3. GPT API 호출 모듈을 붙인다 — 폼 답변을 하나의 텍스트로 합쳐 모델에 보내고, 결과를 JSON(데이터 표기 형식)으로 받도록 지시합니다. 받을 값은 분류(정상·재협의·거절), 판단 근거 한 줄, 위험 신호 목록 세 가지면 충분합니다. 테스트 3건에서 세 갈래가 모두 한 번씩 나오면 완료입니다.
4. 라우터로 세 갈래를 나눈다 — 분류 값에 따라 경로를 셋으로 갈라, 정상은 담당자에게 배정 알림, 재협의는 조건 확인 초안, 거절은 경계 문구가 들어간 초안이 생성되게 합니다. 세 경로가 각각 한 번씩 정상 실행되면 완료입니다. 5인 팀 마케터는 거절 경로에만 자신의 메일로 초안이 오도록 설정했습니다.
5. 2주 승인 기간을 둔다 — 초안은 만들되 자동 발송은 꺼 둡니다. 저희는 2주를 권합니다. 성수기 요청은 유형이 반복되므로 2주면 분류가 어긋나는 패턴이 대부분 드러나기 때문입니다. 오분류가 열 건 중 한 건 아래로 떨어지면 자동 발송을 검토합니다.

크레딧 소모는 미리 가늠해 두는 편이 낫습니다. Make는 과금 단위를 오퍼레이션에서 크레딧으로 전환했고, 시나리오 안에서 데이터를 처리하는 각 모듈은 보통 최소 1크레딧을 소모합니다. 모듈 6개짜리 시나리오라면 요청 1건당 최소 6크레딧으로 잡고 월 예상 건수를 곱해 보시길 권합니다. 실제보다 넉넉히 잡아야 성수기 중간에 멈추지 않습니다.

여기까지 하면 — 폼에 요청이 들어온 순간 세 갈래 중 하나로 분류되고, 회신 초안이 메일함에 도착하는 흐름이 손에 남습니다.

분류 프롬프트는 어떻게 쓰나요?

아래 문장을 GPT API 호출 모듈의 지시문 칸에 그대로 붙여 넣고, 대괄호 부분만 본인 상황으로 바꾸면 됩니다.

당신은 [업무 범위: 예) 콘텐츠 제작·광고 운영] 담당자의 요청 선별 보조자입니다. 아래 요청서를 읽고 정상, 재협의, 거절 중 하나로만 분류하세요. 판단 기준은 이렇습니다. 정상은 기존 합의 범위 안이고 희망 기한이 영업일 [5]일 이상 남은 요청입니다. 재협의는 범위는 맞지만 기한·산출물 분량이 합의와 다른 요청입니다. 거절은 합의 범위 밖이거나, 결정 권한이 없는 사람이 다른 팀의 책임을 옮겨 오는 요청입니다.

다음 위험 신호가 보이면 목록에 그대로 적으세요. 첫째 기한 압박(오늘 안에, 어차피 금방, 이미 위에 보고함). 둘째 책임 전가(원래 그쪽 일, 저번에도 해주셨잖아요). 셋째 범위 확대(간단한 거니까 하나만 더). 넷째 죄책감 자극(이거 안 되면 저희 팀이 곤란해집니다).

출력은 JSON 하나로만 주세요. 키는 classification, reason, risk_signals, draft_reply 네 개입니다. reason은 한 문장으로 씁니다. draft_reply는 존댓말 4문장 이내이며, 위험 신호가 하나라도 있으면 다음 세 요소를 반드시 포함합니다. 현재 확정된 작업 범위 한 줄, 이번 요청이 그 범위와 다른 지점 한 줄, 진행 가능한 조건(기한 조정 또는 범위 축소) 한 줄입니다. 사과 표현과 추측성 약속은 넣지 마세요.

여기서 핵심은 마지막 문단입니다. 착한 사람일수록 회신에서 먼저 사과하고, 그 순간 협상 위치가 바뀝니다. 이 구조는 만만하게 보이지 않는 다크심리학에서 다루는 경계 설정 관점과 이어집니다. 감정 표현을 줄이고 사실·차이·조건 세 줄만 남기는 방식입니다.

어떤 도구를 골라야 하나요?

월 요청 건수와 단계 수가 선택을 결정합니다. 무료 요금제에서 확인되는 조건을 기준으로 비교하면 판단이 쉬워집니다.

저희는 폴링 간격도 함께 봅니다. Zapier 무료 요금제의 폴링 트리거는 15분 간격으로 동작하므로, 접수 즉시 응답이 필요한 창구라면 이 간격이 실무에서 걸립니다. 반대로 하루 두세 번 몰아서 처리하는 팀이라면 문제가 되지 않습니다.

여기까지 하면 — 내 요청량과 단계 수에 맞는 도구 1개를 근거를 대며 고를 수 있습니다.

자주 하는 실수는 무엇인가요?

• 분류를 다섯 갈래 이상으로 늘리기 — 경계가 겹쳐 모델도 사람도 흔들립니다. 세 갈래로 시작하고, 재협의 안에서 하위 사유를 적는 방식이 안정적입니다.
• 첫날부터 자동 발송 켜기 — 오분류 한 건이 관계 문제로 번집니다. 초안 생성까지만 자동화하고 발송 버튼은 사람이 누르는 구성이 안전합니다.
• 접수 창구를 폼으로 좁히지 않기 — 메신저 요청이 남아 있으면 자동화는 절반만 돌고, 결국 두 번 일하게 됩니다.
• 회신 초안에 사과부터 넣기 — "죄송하지만"으로 시작하면 조건 제시가 부탁으로 읽힙니다. 사실·차이·조건 세 줄 구조를 유지하시길 권합니다.
• 크레딧 소모를 계산하지 않기 — 성수기 중간에 무료 한도가 끝나면 가장 바쁜 주에 흐름이 멈춥니다. 모듈 수와 월 예상 건수를 미리 곱해 두어야 합니다.
• 기준 문서를 만들지 않기 — 프롬프트만 있고 기준 문서가 없으면 팀원마다 다르게 수정합니다. 판단 기준은 별도 문서로 두고 프롬프트가 그 문서를 따르게 하는 편이 낫습니다. 관련 운영 사례는 인사이트에서 이어 보실 수 있습니다.

요약하면 무엇을 먼저 해야 하나요?

• 오늘 30분 — 구글 폼에 필수 항목 6개를 넣고 접수 창구를 1개로 좁힙니다.
• 이번 주 — Make 시나리오에 스프레드시트 감지, GPT API 호출, 라우터 3갈래를 연결합니다.
• 프롬프트 — 정상·재협의·거절 기준과 위험 신호 4종, JSON 출력 형식을 한 번에 지시합니다.
• 2주간 — 자동 발송은 끄고 초안만 검수해 오분류 패턴을 잡습니다.
• 도구 선택 — 단계가 4개 이상이면 Make, 2단계로 끝나면 Zapier 쪽이 판단하기 쉽습니다.

함께 보면 좋은 글 — 고객 응대 자동화: 자주 묻는 답변 20개 미리 쓰는 4단계, 혼자 판단하는 사장을 위한 아침·저녁 브리핑 봇, 노코드 AI 자동화 5단계 가이드