클로드는 판단과 생성에 강하고, Make는 실행과 연결에 강합니다.
두 도구를 한 흐름으로 묶기 전에 역할의 경계를 먼저 정해야 합니다.
클로드와 Make의 역할을 분리하는 이유
클로드와 Make를 함께 사용하면 콘텐츠 작성, 요약, 분류, 초안 생성, 데이터 정리 같은 작업을 자동화할 수 있습니다. 다만 둘을 모두 “자동화 도구”로만 보면 설계가 쉽게 복잡해집니다.
저는 클로드를 텍스트를 해석하고 판단하는 작업자, Make를 데이터를 옮기고 조건에 따라 실행하는 조정자로 나누어 생각합니다. 클로드는 문맥을 읽고 결과물을 만들며, Make는 어떤 데이터가 언제 어디로 이동할지 관리합니다.
예를 들어 새 콘텐츠 아이디어를 받았을 때, Make는 메모를 가져오고 필요한 필드를 확인합니다. 클로드는 메모를 바탕으로 제목 후보, 개요, 초안을 생성합니다. 이후 Make는 결과를 워드프레스 초안이나 데이터베이스에 저장하는 역할을 맡습니다.
이 구분이 없으면 Make 안에 지나치게 많은 판단 규칙을 넣거나, 반대로 클로드에게 데이터 처리와 시스템 제어까지 맡기게 됩니다.
자동화 전에 먼저 정할 입력과 출력
자동화는 프롬프트부터 작성하는 일이 아니라, 입출력 구조를 정하는 일에 가깝습니다. 먼저 사람이 제공할 최소 입력값과 자동화가 반환할 결과값을 목록으로 적어야 합니다.
콘텐츠 초안 파이프라인이라면 입력값은 다음처럼 정리할 수 있습니다.
- 콘텐츠 주제 또는 아이디어 메모
- 독자 유형
- 글의 목적
- 참고 자료 또는 링크
- 금지 표현과 작성 규칙
- 발행 채널 또는 저장 위치
출력값도 한 덩어리의 본문으로 받기보다 필드별로 나누는 편이 좋습니다. 제목, 요약, 본문, 태그 후보, 검토 필요 항목을 분리하면 Make에서 다음 단계를 연결하기 쉬워집니다.
특히 AI가 확신할 수 없는 부분은 별도 필드로 받는 구조가 중요합니다. 예를 들어 fact_check_needed 같은 항목에 확인할 내용을 반환하게 하면, 발행 전 검수 단계에서 누락을 줄일 수 있습니다.
Make 시나리오에 클로드를 넣는 기본 구조
가장 단순한 흐름은 입력, 검증, 생성, 저장의 네 단계입니다. 처음부터 복잡한 분기와 다중 에이전트를 만들 필요는 없습니다.
- Make가 폼, 스프레드시트, 노션 등에서 새 입력을 감지합니다.
- 필수 항목이 있는지 확인하고, 비어 있으면 보완 요청 목록으로 보냅니다.
- 입력 데이터를 정리해 클로드 API 호출에 전달합니다.
- 클로드의 응답을 구조화된 데이터로 받아 필요한 채널에 저장합니다.
여기서 중요한 것은 클로드의 응답 형식입니다. 자연어 문단만 반환받으면 Make가 제목과 본문, 검토 항목을 다시 구분해야 합니다. 이 과정은 오류가 나기 쉽습니다.
가능하다면 출력 형식을 고정합니다. 예를 들어 제목, 도입부, 본문, 확인 필요 사항을 정해진 키로 반환하도록 요청합니다. 실제 지원되는 구조화 출력 방식과 Make 모듈 설정은 사용 중인 API 및 연결 방식에 따라 확인해야 합니다.
프롬프트를 작업 명세서처럼 쓰는 방법
좋은 프롬프트는 문장을 길게 쓰는 것보다 작업 조건을 빠짐없이 전달하는 데서 출발합니다. “블로그 글을 써줘”보다 “어떤 독자에게, 어떤 형식으로, 어떤 근거 기준을 지키며 쓸지”를 명시하는 편이 안정적입니다.
저는 프롬프트를 다음 순서로 구성하는 편입니다.
- 역할: 콘텐츠 초안 작성자, 분류 담당자 등 역할을 지정합니다.
- 목표: 이번 요청에서 만들어야 할 결과를 한 문장으로 씁니다.
- 입력 데이터: Make에서 받은 값을 항목별로 전달합니다.
- 작성 규칙: 톤, 길이, 금지 표현, 문단 구조를 적습니다.
- 사실 기준: 제공되지 않은 수치나 사례를 만들지 말도록 지시합니다.
- 출력 형식: Make가 읽을 수 있는 필드 구조를 지정합니다.
핵심은 프롬프트 안에 자동화의 예외 처리 기준까지 넣는 것입니다. 참고 자료가 없거나 근거가 부족하면 추정하지 말고 으로 표시하도록 정하면, 그 결과를 사람이 검토할 수 있습니다.
클로드가 만든 결과를 곧바로 발행하는 흐름은 신중해야 합니다. 특히 제품 정보, 가격, 법률·의료·재무 관련 내용, 최신성이 중요한 정보는 별도 검토 단계를 두는 것이 안전합니다.
오류와 예외를 다루는 설계
자동화가 멈추는 이유는 대개 AI 성능보다 입력값 누락, 연결 오류, 예상하지 못한 응답 형식에 있습니다. 따라서 정상 흐름보다 예외 흐름을 먼저 설계하는 편이 좋습니다.
Make에서는 다음 경우를 분리해 두면 운영이 편해집니다.
- 아이디어 메모가 비어 있는 경우
- 클로드 응답이 필요한 필드를 포함하지 않은 경우
- 생성 결과에 확인 필요 항목이 있는 경우
- 저장 대상 도구의 연결이 실패한 경우
- 같은 입력이 중복으로 들어온 경우
오류가 발생했을 때 단순히 시나리오를 중단하는 대신, 실패 원인과 원본 데이터를 별도 검토 목록에 저장하는 방식을 고려할 수 있습니다. 그래야 나중에 어떤 입력에서 문제가 반복되는지 확인할 수 있습니다.
또한 AI 응답을 그대로 다음 모듈에 넘기지 말고, 길이와 필수 필드 여부를 한 번 확인하는 단계를 두는 것이 좋습니다. 자동화의 품질은 생성 결과 자체보다 결과를 통과시키는 기준에서 안정됩니다.
작은 테스트부터 운영으로 옮기는 순서
처음에는 하나의 입력 채널과 하나의 출력 채널만 연결하는 것이 좋습니다. 예를 들어 아이디어 메모를 받아 콘텐츠 초안을 생성한 뒤, 검토용 문서에 저장하는 흐름이면 충분합니다.
운영 전에는 실제 업무에서 자주 나오는 입력을 몇 개 모아 테스트합니다. 짧은 메모, 모호한 요청, 참고 자료가 없는 요청, 형식이 다른 요청을 모두 넣어 봐야 합니다.
테스트할 때는 결과물의 문장 품질만 보지 않습니다. 필드가 빠지지 않는지, 오류 시 원본이 남는지, 중복 실행이 일어나는지, 사람이 검토할 위치가 명확한지를 함께 확인합니다.
자동화 범위는 검증된 단계부터 넓히는 편이 낫습니다. 초안 생성이 안정된 뒤에 제목 변형, 이미지 요청서 작성, 워드프레스 등록, 발행 일정 관리처럼 다음 단계를 붙이는 방식이 관리하기 쉽습니다.
마무리
클로드는 해석과 생성에, Make는 연결과 실행 관리에 집중시킬 때 파이프라인이 단순해집니다.
좋은 자동화는 화려한 프롬프트보다 명확한 입출력 구조와 예외 처리에서 시작됩니다.
처음에는 초안 생성과 검토 저장처럼 작은 흐름 하나를 안정적으로 만드는 것이 우선입니다.
다음 글에서는 Make에서 AI 응답을 콘텐츠 필드로 나누어 저장하기 위한 출력 구조 설계 방법을 정리하겠습니다.