Make란? 앱을 연결하는 자동화 기능·요금·사용법 정리

정보 확인일: 2026년 11월 5일. 공식 페이지 본문을 확인하여 작성한 글입니다. 외부 앱 연결이나 시나리오 실행은 진행하지 않았습니다. 요금은 신청 시 최신 조건을 확인하시기 바랍니다.

들어가며

표에 추가된 정보를 찾아 채팅에 옮겨 적고, 다른 담당자에게 같은 내용을 알립니다. Make는 이런 반복 작업을 앱 간 연결로 구성할 수 있는 서비스입니다. 공식 사이트에서는 앱과 데이터, AI를 시각적으로 연결하는 자동화를 소개합니다. Make 공식 사이트

처음부터 업무 전체를 자동화할 필요는 없습니다. “어떤 일이 발생하면, 어떤 정보를, 어디로 전달할지” 하나를 정하는 것부터 시작할 수 있습니다. 이 글에서는 기본 용어와 사용량을 이해하는 방법을 정리하고, 공식 입문 예제를 바탕으로 알림을 보내는 과정을 소개합니다.

Make란

Make에서는 일련의 자동 처리 과정을 “시나리오”라고 부릅니다. 그 안에 배치하는 각 앱의 처리 단위가 “모듈”입니다. 공식 입문 가이드에서는 Google Sheets의 새 행을 찾아 Slack으로 알림을 보내는 시나리오를 예로 들어 설명합니다. 첫 번째 시나리오

이 예제에서는 표의 새 행을 감지하는 역할과 메시지를 보내는 역할을 나누어 생각할 수 있습니다. 화면에서 연결되어 있더라도 보낼 정보의 내용까지 자동으로 정확하게 정해지는 것은 아닙니다. 편집부에서는 연결할 대상을 정하기 전에 업무에 필요한 항목부터 정리할 것을 권장합니다.

예를 들어 문의 내용을 공유한다면 접수일, 상담 내용, 담당자가 필요할 수 있습니다. 한편, 알림에 모든 개인정보를 담을 필요가 있는 것은 아닙니다. 다음 담당자가 업무를 진행하려면 어떤 정보를 전달해야 하는지 정하면 구성과 확인 사항을 좁힐 수 있습니다.

할 수 있는 일(주요 기능)

작업 시작 조건과 이후 처리 연결하기

시나리오의 출발점인 트리거는 양식 응답, 이메일 도착, 표의 행 추가 등 처리를 시작하는 계기를 뜻합니다. 공식 가이드의 Google Sheets 예제에서는 Watch New Rows를 선택해 새 행을 감시합니다. 첫 번째 앱 추가

편집부에서는 시작 조건을 문장으로 적어 보며 정리하는 방식을 제안합니다. “매일 막연히 확인한다”가 아니라 “새 신청 행을 찾으면 담당 채널에 한 번 알린다”라고 정의하는 것입니다. 대상과 결과가 모호하면 정상적으로 작동하더라도 목적을 달성했는지 판단할 수 없습니다.

알림이 필요 없는 행이나 아직 작성 중인 행을 어떻게 처리할지도 생각합니다. 처음 시험용으로 구성할 때는 조건을 지나치게 늘리지 않고 기본적인 한 건이 올바르게 처리되는지 살펴보면 수정할 부분을 찾기 쉬워집니다.

이전 처리의 정보를 다음 처리로 전달하기

Make의 “매핑”은 한 모듈의 출력을 다음 모듈의 입력에 할당하는 작업입니다. 공식 Slack 예제에서는 Google Sheets의 값을 메시지 본문의 필요한 위치에 배치합니다. 데이터 매핑

고정된 문구와 달라지는 값을 나누어 생각하는 것이 핵심입니다. “새 상담이 접수되었습니다”는 고정된 문구여도 이름이나 상담 내용은 행마다 달라집니다. 편집부라면 먼저 완성된 형태의 알림 문구를 하나 작성한 뒤, 어느 부분을 데이터로 바꿀지 표시합니다.

성과 이름 사이의 공백, 비어 있는 항목, 긴 문장이 들어오는 경우도 확인합니다. 내용이 정확해도 읽기 어려운 알림이라면 나중에 읽는 사람의 수고가 남습니다. 정보를 옮겼는지뿐 아니라 받는 사람이 이해할 수 있는지도 시험 구성의 평가 대상입니다.

입출력과 처리 횟수 확인하기

각 모듈은 하나로 묶인 데이터인 “번들”을 다룹니다. 공식 도움말에서는 모듈 위의 출력 표시를 통해 입출력을 확인할 수 있으며, 데이터 건수에 따라 후속 처리 횟수가 늘어날 수 있다고 설명합니다. Operations 설명

연결선을 두 개 이었다고 해서 처리가 반드시 두 번으로 끝난다는 뜻은 아닙니다. 앞에서 여러 데이터가 전달되면 다음 처리에서 각각을 다루는 경우가 있습니다. 화면에 보이는 구성과 사용량을 구분해서 생각해야 합니다.

편집부에서는 테스트할 때 “입력한 건수”, “도착한 건수”, “표시된 처리 횟수”를 나란히 기록할 것을 권장합니다. 한 건의 성공만으로 판단하지 않고 여러 건을 처리했을 때 무엇이 달라지는지 확인하면 실제 운영 상황을 예상하기 쉬워집니다.

실행 빈도 정하기

시나리오 일정은 일정 간격, 매일, 요일 등으로 지정할 수 있습니다. 기본 설정은 15분 간격이며, 설정 가능한 최소 간격은 플랜에 따라 달라집니다. On demand는 수동 실행이나 API 호출 등을 기다리는 방식입니다. 일정 설정

빈도는 “빠를수록 좋다”는 기준보다 업무상 얼마나 기다릴 수 있는지를 기준으로 정합니다. 다음 영업일에 확인해도 되는 집계와 담당자에게 빠르게 알려야 하는 접수 업무는 필요한 간격이 다릅니다. 편집부라면 허용할 수 있는 대기 시간을 먼저 정한 뒤 설정을 선택합니다.

요금제

Make 공식 글에서는 Free에 월 1,000크레딧이 제공되며, 유료 선택지로 Core, Pro, Teams, Enterprise를 소개합니다. 확인 당시 요금 페이지 본문에서 현재 금액 목록을 일관되게 확보할 수 없어, 이 글에서는 유료 플랜의 금액을 특정하여 기재하지 않습니다. 공식 플랜 소개 / 요금 페이지

모든 작업에서 항상 같은 양의 크레딧을 사용하는 것은 아닙니다. 공식 도움말에 따르면 일반적인 비AI 앱에서는 하나의 operation이 1크레딧에 해당합니다. 반면 AI 기능 중에는 토큰 등에 따라 소비량이 달라지는 기능이 있습니다. Credits 설명

직접 설정한 연결로 외부 AI를 사용하는 경우, Make 처리에 필요한 크레딧과 별도로 AI 제공업체에 지불할 요금이 발생하는 구성도 있습니다. Make의 제공량이 충분하다고 해서 모든 외부 서비스 이용료까지 포함된다고 생각하지 않는 것이 좋습니다.

편집부에서는 첫 달부터 목표한 건수를 처리할 수 있다는 전제로 선택하기보다, 작게 시험 구성한 자동화의 소비량을 확인한 뒤 필요한 제공량을 판단할 것을 권장합니다. 평소 입력 건수뿐 아니라 월말에 한꺼번에 늘어나는 경우나 설정을 수정한 뒤 다시 테스트하는 작업도 고려합니다.

한 건의 처리량을 바탕으로 월간 사용량을 예상할 때는 반드시 자신의 구성에서 얻은 값을 사용합니다. 다른 사람의 “한 달에 이 정도면 충분했다”는 사례는 앱, 빈도, 건수가 다를 수 있습니다. 예상치를 계산할 때 사용한 조건을 남겨 두면 사용량이 늘어난 이유도 확인하기 쉬워집니다.

사용 방법: 표의 정보를 알림으로 연결하기

아래는 공식 가이드에 따른 구성 과정입니다. 실제로 연결하고 실행하기 전에 사용해도 되는 데이터와 알림을 보낼 곳을 정하시기 바랍니다. 편집부에서는 이 글을 위해 외부 앱에 연결하거나 메시지를 보내지 않았습니다.

1. 테스트용 표와 완성된 형태의 알림 문구 준비하기

먼저 실제 고객 정보를 사용하지 않고, 내용을 알아볼 수 있는 가상 데이터를 몇 행 준비하는 방법을 권장합니다. 열 이름과 알림 문구를 맞춰 보며 각 항목이 어디에 들어갈지 정합니다. “이름만 있는 경우”, “본문이 비어 있는 경우”처럼 평소 발생할 법한 상태도 테스트할 수 있도록 준비합니다.

완료 조건도 미리 적습니다. 예를 들어 “새 행 하나에 대해 알림 한 건이 도착하고 필요한 항목을 올바르게 읽을 수 있다”라고 정하면 설정의 성공 여부를 확인하기 쉬워집니다. 단순히 화면에 오류가 나타나지 않았다는 사실을 완료 조건으로 삼지 않는 것이 핵심입니다.

2. 시나리오를 만들고 첫 번째 모듈 배치하기

공식 절차에서는 Create a new scenario에서 생성 화면을 열고 이름을 지정합니다. 중앙의 추가 기능에서 Google Sheets를 찾아 Watch New Rows를 선택합니다. 모듈 추가 공식 절차

이름에 입력 출처와 목적을 알 수 있는 표현을 넣으면 관리하기 쉬워집니다. 편집부의 예라면 “테스트 표의 새 행 알림”과 같은 이름입니다. 시험용과 실제 운영용을 구분할 수 있는 이름을 붙여 두면 나중에 설정을 검토할 때 혼동을 줄일 수 있습니다.

3. 연결할 계정 확인하기

Google Sheets 예제에서는 Create a connection에서 연결을 만들고 Google 계정을 선택해 접근을 허용합니다. 이 연결은 이후 다른 시나리오에서도 사용할 수 있습니다. 인증 방식은 앱마다 다릅니다. 연결 공식 절차

업무용 계정과 개인용 계정이 있다면 대상 표가 있는 계정인지 확인하는 것이 좋습니다. 인증에 성공했는지와 원하는 데이터에 연결되었는지를 나누어 확인합니다. 연결 이름에도 용도를 남겨 두면 나중에 담당자가 설정을 볼 때 판단하기 쉬워집니다.

4. Slack 알림 내용에 값 할당하기

공식 가이드에서는 Slack의 Send a Message와 Google Sheets 모듈을 조합해 알림을 보낼 곳과 본문을 설정합니다. 본문에 앞 단계의 값을 삽입하고 모듈 설정과 시나리오를 저장합니다. 매핑 공식 절차

테스트 알림은 해당 내용을 확인해도 되는 곳으로 보냅니다. 본문을 만들 때는 항목명과 값을 짝지어 배치합니다. 상담 내용과 연락처가 서로 바뀌지 않았는지, 입력하지 않은 값이 있어도 내용을 이해할 수 있는지 완성된 형태의 알림 문구와 비교해 확인하는 것이 좋습니다.

5. 한 번 실행한 뒤 두 앱에서 결과 확인하기

Run once로 테스트할 때는 모듈의 출력 표시를 열어 처리 내용을 확인하고, Slack에서도 도착한 내용을 대조합니다. 공식 가이드에서 “All”을 선택하는 예제는 기존 행도 대상으로 하므로, 대상 데이터의 범위를 이해한 뒤 실행합니다. 시나리오 테스트

테스트라도 실제 알림이 전달된다는 점을 염두에 둡니다. 결과가 예상과 다르다면 처음부터 전체를 다시 구성하기보다 표의 값, 앞 단계의 출력, 다음 단계의 입력, 알림 결과 순으로 확인하면 어느 지점에서 차이가 생겼는지 정리할 수 있습니다.

6. 빈도를 정하고 운영 담당자 기록하기

내용과 건수가 맞으면 필요한 일정을 설정합니다. 공식 가이드에서는 설정을 저장한 뒤 시나리오를 활성화하는 순서로 진행합니다. 실행 일정 설정

편집부에서는 가동을 시작하기 전에 알림이 멈췄을 때 확인할 담당자와 설정 변경 시 연락할 곳을 정할 것을 권장합니다. 자동화를 만든 사람만 내용을 이해하고 있으면 인수인계할 때 어려움을 겪습니다. 입력 출처, 알림을 보낼 곳, 빈도, 예상 건수를 짧은 메모로 남겨 두는 것이 좋습니다.

적합한 사람과 적합하지 않은 사람

편집부의 판단으로는 여러 앱 사이에서 같은 정보를 옮겨 적고 있으며, 입력과 결과를 구체적으로 설명할 수 있는 사람에게 적합한 선택지입니다. 처음에는 작게 구성하고 입출력을 확인하면서 개선하려는 사람도 검토해 볼 만합니다.

반대로 업무 판단 기준이 아직 정해지지 않아 무엇을 해야 완료되는지 설명할 수 없는 단계라면 업무 정리가 먼저 필요합니다. 작동 방식이나 비용을 한 번도 확인하지 않은 채 맡기고 싶은 경우에도 도입 후 운영과 기대가 맞지 않을 수 있습니다.

자동화의 가치는 연결한 앱의 수만으로 결정되지 않습니다. 담당자가 더 빨리 확인할 수 있는지, 정보를 옮기면서 빠뜨린 부분을 더 쉽게 찾을 수 있는지 등 실제 업무를 기준으로 평가할 것을 권장합니다.

비슷한 도구와의 차이

Zapier도 앱을 연결하는 워크플로를 제공하며, 공식 페이지에서는 조건 분기, 데이터 형식 정리, 일정 등을 소개합니다. Make에 대해서는 이 글의 입문 예제를 통해 시나리오의 모듈과 번들을 확인하면서 구성하는 과정을 살펴봤습니다. Zapier 워크플로

어느 쪽이 더 쉬운지는 사용하려는 앱과 처리 내용을 기준으로 판단하는 것이 좋습니다. 편집부라면 똑같이 “표의 한 행을 알림으로 보내기”를 주제로 삼아 연결 방법, 항목 지정, 결과 확인, 요금 계산 방식을 비교합니다. 연결 가능한 앱의 총수만으로 결론을 내리지 않는 것이 중요합니다.

주의 사항

사용량은 시나리오 수나 모듈 수만으로 판단할 수 없습니다. 건수와 실행 빈도, AI 사용 시 소비 방식을 함께 살펴봅니다. 공식 문서의 Credits와 Operations는 서로 다른 개념을 설명하므로, 오래된 글의 “작업 횟수”를 현재 요금에 그대로 적용하지 않도록 합니다.

또한 표의 열이나 알림을 받는 곳의 운영 방식이 바뀌면 이전에 올바르게 구성한 설정도 검토가 필요할 수 있습니다. 편집부가 제안하는 운영 방법은 원본 데이터의 형식을 변경할 때 알림 내용도 함께 확인하도록 절차를 정해 두는 것입니다.

자동화한 뒤에도 받는 사람이 활용할 수 있는 정보인지 살펴봅니다. 알림이 너무 많아 읽히지 않는다면 전송 성공 여부와 별개로 업무 설계를 검토할 여지가 있습니다.

마무리

Make는 앱 간 처리를 시나리오로 구성하고 입출력을 확인하면서 자동화를 설계할 수 있는 서비스입니다. 처음에는 입력 출처와 알림을 보낼 곳이 명확한 작은 작업으로 시험해 보면 모듈, 매핑, 크레딧의 관계를 이해하기 쉬워집니다.

연결하는 데서 끝내지 않고 필요한 정보가 도착했는지, 처리 건수와 사용량이 예상대로인지 확인하는 것이 좋습니다. 그 결과를 바탕으로 대상 업무나 플랜을 확대할지 판단할 것을 권장합니다.

출처(2026년 11월 5일 본문 확인)

• Make 공식
• 요금
• 공식 플랜 소개
• 첫 번째 시나리오
• 모듈 추가
• 연결
• 매핑
• 테스트
• 예약 실행 시작
• 일정
• Operations
• Credits
• Zapier 공식