Make AI 에이전트 구축 실전 — 공식 문서에 없던 함정 4가지

Make AI 에이전트를 처음 만들던 날, 에이전트를 설정하고 Slack에 메시지를 보냈는데 아무 반응이 없었다. 실행 로그를 보면 에이전트는 분명 돌아가고 있었다. 근데 결과가 안 나왔다. 한참 뒤지고 나서야 원인을 찾았다. 도구 시나리오 끝에 'Return output' 모듈을 빼먹었던 것. 공식 문서 어디에도 "이게 없으면 에이전트가 결과를 못 받는다"는 경고 문구가 없었다.

이 글은 그 경험에서 시작한다. Make AI 에이전트를 처음 구축하면서 막혔던 것들, 기대와 다르게 동작한 것들을 정리한 내용이다. 공식 가이드에서 설명하지 않는 실전 함정 위주로 썼다.

Make AI 에이전트가 기존 자동화랑 다른 이유

기존 자동화 도구는 조건 분기 방식이다. "A이면 B를 해라"라는 규칙을 미리 다 정의해야 한다. n8n, Zapier, 심지어 Make의 기존 시나리오 방식도 마찬가지다. 규칙이 명확한 반복 업무엔 잘 맞지만, 예외 상황이 생기면 사람이 직접 조건을 추가해줘야 한다.

Make AI 에이전트는 다르게 동작한다. LLM(대형 언어 모델)이 내부에서 돌아가면서, 어떤 도구를 쓸지 스스로 결정한다. "재고가 10개 미만이면 주문해라"가 아니라, "재고 상황 확인해서 필요하면 주문해"처럼 목표 단위로 지시할 수 있다는 뜻이다. 그 판단은 에이전트가 알아서 한다.

n8n·Zapier와 뭐가 다른가

세 도구 모두 자동화를 지원하지만 결이 다르다. Zapier는 앱 간 연결에 특화되어 있고, n8n은 커스터마이징 자유도가 높다. Make는 시각적 캔버스 위에서 에이전트와 시나리오를 함께 설계할 수 있는 게 특징이다.

실제로 n8n과 비슷한 자동화를 Make로도 만들어봤는데, Make 에이전트가 어떤 결정을 내렸는지 단계별로 확인할 수 있어서 디버깅이 훨씬 쉬웠다. 에이전트가 어떤 도구를 왜 선택했는지, 어떤 입력을 넘겼는지까지 로그로 보인다. 단점을 말하자면, 무료 플랜의 작업 수 제한이 n8n보다 빡빡하다. 규모가 커지면 비용을 고려해야 한다.

Make 에이전트 구축 4단계 — 실제로 해보면 달랐던 것

공식 문서는 4단계로 설명한다. 에이전트 생성 → 도구 추가 → 입출력 연결 → 테스트. 흐름 자체는 맞는데, 각 단계마다 문서에 안 나오는 세부 함정이 있다.

Step 1: 에이전트 생성과 LLM 연결

Make 캔버스에서 AI 에이전트 모듈을 추가하고 LLM을 연결하는 건 단순하다. 에이전트 역할을 설명하는 description을 쓰고, 모델을 고르면 된다. 여기까지는 5분이면 끝난다.

함정은 description 작성에 있다. "고객 문의를 처리하는 에이전트입니다"처럼 모호하게 쓰면 에이전트가 뭘 해야 할지 모른다. 어떤 도구를 어떤 상황에 써야 하는지까지 구체적으로 써야 한다. "배송 문의가 오면 배송 조회 도구를 쓰고, 환불 요청이면 환불 처리 도구를 쓰되, 판단이 애매한 경우엔 직접 답하지 말고 담당자 연결 메시지를 남겨라"처럼.

Step 2: 도구(시나리오) 추가 — 이게 핵심

에이전트는 혼자서는 아무것도 못 한다. 데이터를 가져오거나, 계산하거나, 어딘가에 값을 쓰려면 도구가 필요하다. Make에서 도구는 '시나리오'다. 재고를 조회하는 시나리오, 주문을 넣는 시나리오를 만들어서 에이전트에 연결하면, 에이전트가 상황에 따라 알아서 호출한다.

가장 자주 막히는 부분이 여기다. 도구 시나리오의 마지막 모듈이 반드시 'Return output'이어야 한다. 이 모듈이 없으면 시나리오가 실행은 되지만 에이전트한테 결과를 돌려주지 않는다. 에이전트는 아무 일도 안 일어난 것처럼 인식한다. 내가 처음에 막혔던 그 상황이 바로 이것이었다. 공식 best practices 페이지에 한 줄 나오지만, 처음엔 놓치기 쉬운 내용이다.

Step 3: 트리거 연결 (Slack·Telegram)

에이전트가 준비됐으면 어디서 호출할지 연결해야 한다. Make는 Slack, Telegram, Tally 등 다양한 트리거를 지원한다. Slack 특정 채널에 메시지가 오면 에이전트가 읽고 처리하는 흐름을 만들었는데, 생각보다 연결이 단순해서 좋았다.

주의할 점은 트리거 시나리오와 에이전트를 연결하는 별도 시나리오가 필요하다는 거다. 트리거 → 에이전트 호출 → 응답 전송, 이 흐름을 프런트엔드 시나리오 하나로 만들어야 한다. 에이전트와 트리거를 직접 연결하는 게 아니다.

Step 4: 테스트와 디버깅

Make의 장점이 가장 잘 보이는 단계다. 에이전트가 어떤 도구를 선택했고, 어떤 입력을 넘겼고, 무슨 결과를 받았는지 단계별로 다 확인할 수 있다. n8n에서도 로그를 볼 수 있지만, Make는 에이전트 의사결정 과정이 더 명확하게 시각화된다. 문제가 생겼을 때 어디서 틀어졌는지 찾기가 훨씬 빠르다.

직접 구축한 자동화 3가지 — 잘된 것과 아닌 것

직접 만들어서 운영 중인 에이전트 자동화 사례들이다. 세 가지 모두 구축 시간은 달랐고, 결과도 달랐다.

① 재고 관리 봇 (성공)

구글 시트에서 재고 데이터를 읽어오는 시나리오와, 발주 요청을 생성하는 시나리오를 도구로 연결했다. 에이전트는 재고가 설정한 임계치 이하면 자동으로 발주를 넣는다. 판단 기준이 명확한 작업이라 에이전트가 잘 동작했다. 발주 처리에 걸리던 시간이 약 70% 줄었다. 도구 시나리오 설계에 반나절 걸렸는데, 그 이후엔 건드릴 일이 거의 없다.

② 주간 보고서 자동 생성 (성공)

여러 소스에서 데이터를 가져와 포맷에 맞게 정리한 뒤 Slack으로 전송하는 에이전트다. 매주 보고서 작성에 2~3시간씩 쓰던 게 0으로 줄었다. 처음 도구 시나리오 설계에 이틀 걸렸지만, 한 번 세팅하면 계속 돌아가니까 투자 가치는 있었다. 데이터 포맷이 바뀌거나 소스가 달라지면 시나리오를 수정해야 한다는 게 유일한 유지보수 포인트다.

③ 고객 메시지 자동 분류 (한계 발견)

고객 메시지를 배송, 환불, 제품 문의 등으로 자동 분류하는 에이전트다. 이게 가장 어려웠다. 에이전트 description을 10번 이상 수정했고, 그래도 모호한 메시지는 7~8% 비율로 틀린 카테고리로 분류됐다. 결국 완전 자동화 대신 사람이 확인하는 체크포인트를 중간에 넣었다. 에이전트가 분류 → 담당자 확인 → 확인 후 처리 흐름으로 바꿨다. 판단 기준이 명확하지 않은 작업에선 에이전트가 완전히 자율적으로 처리하게 두는 게 아직은 무리다.

Make 에이전트 제대로 쓰려면 놓치면 안 되는 것

써보면서 실제로 걸린 함정들을 정리하면 4가지로 요약된다.

• Return output 모듈 누락 — 에이전트가 침묵하는 가장 흔한 원인이다. 도구로 쓸 모든 시나리오 끝에 이 모듈이 있어야 한다. 없으면 에이전트는 결과를 못 받는다.
• 에이전트 description 불명확 — description이 모호하면 에이전트가 어떤 도구를 써야 할지 판단하지 못한다. 어떤 상황에서 어떤 도구를 써야 하는지까지 명시해야 한다.
• 처음부터 도구 범위를 너무 넓게 — "모든 걸 처리하는 에이전트" 만들려다 아무것도 제대로 안 되는 에이전트가 된다. 하나의 작업에 집중한 에이전트부터 만드는 게 낫다. 잘 돌아가면 그때 범위를 넓혀도 늦지 않다.
• 인간 검증 체크포인트 없음 — 에이전트가 돌이킬 수 없는 액션(주문, 이메일 발송, 데이터 삭제)을 취하기 전에 사람이 확인하는 단계를 넣어야 한다. 특히 초반엔 에이전트가 기대한 대로 동작하는지 확인 기간이 필요하다.

혹시 "Make는 3000개 이상 앱을 연결할 수 있다고 했는데, 에이전트가 그 앱을 다 쓸 수 있는 거 아닌가"라고 생각했다면 아니다. 앱 연결이 되어 있어도, 에이전트가 그 앱을 사용하려면 직접 시나리오를 도구로 만들어야 한다. 에이전트가 앱을 알아서 찾아 쓰는 구조가 아니다. 처음에 이 부분을 착각해서 시간을 좀 날렸다.

ai-it 블로그에서 이전에 AI 에이전트가 프로덕션에서 망하는 이유를 다뤘는데, Make 에이전트도 같은 맥락이다. 도구 설계가 허술하면 에이전트가 아무리 좋아도 결과가 안 나온다.

Make AI 에이전트 처음 시작하는 법 — 3단계

복잡한 걸 처음부터 만들면 막힌다. 단순한 작업 하나를 완성하고 나서 범위를 넓히는 방식이 맞다.

• ① 반복 업무 하나 고르기 — 주 3회 이상, 10~30분씩 걸리는 작업. 판단 기준이 명확한 것. 재고 체크, 주간 보고서, 데이터 이동 같은 게 좋다. 고객 감정 분류처럼 판단 기준이 모호한 건 나중에.
• ② 도구 시나리오 먼저 만들기 — 에이전트부터 만들지 말고, 도구로 쓸 시나리오부터 만들어라. 시나리오 끝에 Return output 모듈 넣는 것 확인하고. 시나리오가 혼자서도 제대로 돌아가는지 먼저 확인해야 에이전트에서 문제 생겼을 때 어디가 틀렸는지 알 수 있다.
• ③ 실제 환경에서 테스트 — Make 내부 테스트만 하면 엣지 케이스를 놓친다. Slack이나 Telegram으로 연결해서 실제로 메시지를 보내면서 테스트해야 실제 동작을 확인할 수 있다.

n8n이랑 Make 중 어느 쪽이 낫냐는 질문을 종종 받는데, 에이전트 기능만 놓고 보면 Make가 더 완성도가 높다고 느꼈다. 투명성(의사결정 로그)이나 시각적 설계 측면에서. 반면 n8n은 오픈소스라 비용 문제가 없다. 용도와 예산에 따라 선택하면 된다. 관련해서 n8n AI 자동화 실전 후기도 참고할 수 있다.

---

📎 참고 자료

• How to build AI agents with Make — Make 공식 가이드
• AI Workflow Automation — 80% Operations Reduction (BinaryBits 사례)

---

📌 함께 보면 좋은 글

• GitHub 코딩 에이전트 팀에 썼더니 Actions 요금이 두 배 됐다, 쓰기 전에 알아야 할 것
• GitHub Copilot Workspace 써봤는데, 57% 빠르다는 말은 맞고 나머지는 달랐다
• RAG 파이프라인 만들다 3번 갈아엎었다, 실패 패턴이 있었다