<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Make on Simon의 AI 시대에 살아남는 법</title><link>https://mhub.uk/tags/make/</link><description>Recent content in Make on Simon의 AI 시대에 살아남는 법</description><generator>Hugo</generator><language>ko-KR</language><copyright>2026 mhub. 이 블로그의 모든 글·그림과 전자책(그림으로 배우는 시리즈)의 저작권은 mhub에 있으며, 저작권자의 허락 없는 무단 복제·배포·전재를 금지합니다. 이용 허락이나 오류 제보는 문의하기로 보내 주세요.</copyright><lastBuildDate>Thu, 24 Sep 2026 08:01:55 +0900</lastBuildDate><atom:link href="https://mhub.uk/tags/make/index.xml" rel="self" type="application/rss+xml"/><item><title>코인추천 자동화, Zapier에서 Make로 옮긴 이유</title><link>https://mhub.uk/posts/q2-03-coin-reco-zapier-to-make/</link><pubDate>Thu, 24 Sep 2026 08:01:55 +0900</pubDate><guid>https://mhub.uk/posts/q2-03-coin-reco-zapier-to-make/</guid><description>&lt;p&gt;하루 두세 번, 업비트 시세를 모아 코인 추천 글을 자동으로 쓰고 텔레그램에 발송하는 파이프라인이 있다. 처음엔 이 파이프라인의 연결 고리(시세 조회, 텔레그램 릴레이)를 전부 Zapier로 짰다. 문제는 그 편리함에 비용이 따라온다는 것이었다 — 할당량이 생각보다 빨리 소진됐다.&lt;/p&gt;
&lt;p&gt;같은 일을 Make로 옮기는 작업은 단순 이전이 아니었다. 텔레그램 발송처럼 &amp;ldquo;메시지 하나 보내고 끝&amp;quot;인 시나리오는 쉬웠지만, 업비트 시세 조회는 &amp;ldquo;HTTP 요청을 보내고 결과를 그 자리에서 돌려받아야&amp;rdquo; 하는 요청-응답형 작업이라 난이도가 달랐다. Make의 시나리오는 기본적으로 비동기 워크플로우 모델이라, 이걸 동기 호출처럼 쓰려면 HTTP 모듈로 요청을 구성한 뒤 별도로 응답 인터페이스를 설정하고, &lt;code&gt;responsive: true&lt;/code&gt; 옵션으로 호출하면 결과가 그 자리에서 돌아오게 만드는 구조가 필요했다.&lt;/p&gt;</description></item></channel></rss>