슬랙 워크플로우 빌더 사용법, 폼·버튼·커넥터·권한을 나누는 순서

제휴 및 광고 고지: 이 글은 업무 자동화 도구의 구성과 검수 순서를 설명하는 정보성 글입니다. 실제 Slack 플랜, 화면, 권한, 커넥터 지원 범위는 바뀔 수 있으므로 작업 전에 공식 도움말을 다시 확인하세요. 이 글은 특정 워크플로우의 실행 성공이나 업무 결과를 보장하지 않습니다.

마지막 검토일: 2026-08-05

결론: 슬랙 워크플로우 빌더는 버튼부터 누르지 말고 여섯 칸부터 나눈다

슬랙 워크플로우 빌더 사용법을 찾을 때 곧바로 새 워크플로우를 만들면, 시작 조건과 입력값과 사용 권한이 한 화면에서 섞이기 쉽습니다. 먼저 아래 여섯 칸을 적고, 그다음 Workflow Builder 화면으로 옮기는 편이 안전합니다.

Slack 공식 Workflow Builder 가이드는 템플릿 또는 빈 워크플로우에서 시작해 단계와 커넥터를 붙이는 흐름을 설명합니다. 이 글의 핵심은 기능을 많이 붙이는 것이 아니라, 각 기능이 담당하는 결정 칸을 분리하는 데 있습니다.

기존 autopickgo의 슬랙 견적 알림 자동화 글이 상담 요청을 Slack 알림으로 받는 사례라면, 이 글은 그 알림을 만들기 전 워크플로우 자체의 입구·입력·권한을 설계하는 글입니다.

1. 시작 조건부터 고르기: 링크·일정·메시지·Webhook은 같은 트리거가 아니다

Workflow Builder의 트리거는 워크플로우가 언제 시작되는지를 정합니다. Slack 공식 워크플로우 생성 안내에는 링크, 외부 webhook, 일정, 리스트 항목 변경, 특정 메시지, 채널 참여, 이모지 반응과 같은 시작 방식이 안내되어 있습니다. 이름이 비슷해도 운영 결과는 다르므로 ‘누가 시작하는가’와 ‘어떤 사건이 시작을 증명하는가’를 따로 적어야 합니다.

링크 시작은 Slack 안에서 실행되는 입구다

링크 트리거는 팀 채널, DM, 캔버스처럼 Slack 안에서 공유할 때 사용하기 좋습니다. Slack 도움말은 링크로 시작하는 워크플로우를 브라우저나 이메일에서 그대로 열어도 시작되지 않는다고 설명합니다. 따라서 외부 고객에게 링크를 보내 접수를 받을 계획이라면, 링크 트리거를 그대로 쓰지 말고 외부 서비스에서 시작하는 경로가 필요한지 먼저 확인해야 합니다.

기록할 값은 다음과 같습니다.

일정·메시지·반응 트리거는 반복 기준을 먼저 적는다

정해진 날짜와 시간에 반복할 업무라면 일정 트리거를 검토하고, 특정 키워드가 들어간 메시지나 이모지 반응을 업무 신호로 사용할 때는 그 신호가 중복되지 않는지 먼저 확인합니다. ‘메시지가 올라오면 시작’이라고만 적으면 같은 요청이 여러 번 실행될 수 있으므로, 원문 식별자·담당자·처리 상태를 다음 단계의 기록값으로 남기는 편이 좋습니다.

외부 Webhook은 입력 출처와 테스트 계정을 따로 관리한다

Slack의 외부에서 시작하는 워크플로우 안내는 외부 서비스의 HTTP 요청이 Slack 워크플로우를 시작하고, 요청값을 custom variable로 전달할 수 있다고 설명합니다. 이 방식은 Slack 밖의 시스템 이벤트를 받을 때 유용하지만 URL, 요청 본문, 권한, 재전송 여부를 함께 관리해야 합니다.

외부 webhook을 검토할 때는 실서비스 고객 정보 대신 이름이 ‘TEST’인 가상 레코드로 먼저 확인하세요. HTTP 요청이 도착했다는 사실과 이후 Slack 메시지 또는 외부 앱 작업이 성공했다는 사실은 별개입니다.

2. 폼·변수·버튼을 나누기: 입력값과 사람의 확인은 다르다

슬랙 워크플로우 폼은 요청자의 정보를 받는 입력 단계이고, 변수는 앞 단계에서 들어온 값을 뒤 단계에서 재사용하는 자리입니다. 버튼은 사람이 다음 단계로 넘기는 상호작용입니다. 세 가지를 ‘자동화 입력’ 하나로 합치면 어느 값이 원본이고 어느 행동이 확인인지 추적하기 어려워집니다.

폼에는 다음 단계에 필요한 값만 질문한다

폼을 만들기 전, 다음 단계가 실제로 필요로 하는 값을 먼저 적습니다. 예를 들어 고객 문의를 담당자에게 배정하는 흐름이라면 문의 유형, 우선순위, 회신 희망 시점, 원문 링크처럼 후속 조치에 쓰이는 값이 중심입니다. 업무와 관계없는 개인정보를 습관적으로 받으면 응답 파일을 관리해야 할 범위만 넓어집니다.

입력 설계표는 다음처럼 만들 수 있습니다.

기존 슬랙 신규 리드 알림과 구글폼 응답 배정 글은 폼 응답을 Slack 알림으로 보내는 사례입니다. 여기서는 그 사례를 복제하지 않고, Slack 내부 Workflow Builder 폼에서 어떤 질문을 받고 어떤 권한으로 공유할지를 먼저 결정합니다.

변수는 원본값과 가공값을 구분한다

Slack 공식 생성 안내에서 변수는 앞 단계의 정보를 뒤 단계에서 참조하는 값으로 설명됩니다. 따라서 변수 이름을 `고객정보`처럼 넓게 쓰기보다 `요청자`, `문의유형`, `원문링크`, `검토기한`처럼 실제 필드를 드러내는 이름으로 적으세요. 화면에 보이는 표시명과 외부 서비스로 전송되는 값이 다를 수 있으므로, 연결 단계에서 전송 필드도 별도로 확인해야 합니다.

변수 기록에는 다음 네 줄이 유용합니다.

1. 원본은 어느 질문 또는 이벤트에서 왔는가? 2. 다음 단계에서 어떤 형식으로 읽는가? 3. 사람에게 표시되는 값과 외부로 보내는 값이 같은가? 4. 값이 비어 있을 때 중단·보류·대체 중 무엇을 하는가?

버튼은 승인 결과가 아니라 확인 지점이다

버튼은 흐름을 다음 단계로 이동시키는 장치입니다. ‘확인’ 또는 ‘처리’라는 버튼 문구가 있다고 해서 법적 승인, 결제 승인, 고객 동의가 자동으로 성립하는 것은 아닙니다. 버튼을 누르는 사람이 무엇을 확인했는지, 버튼을 여러 번 눌렀을 때 중복 작업이 생기는지, 되돌리는 경로가 있는지를 기록해야 합니다.

Slack FAQ에는 워크플로우 버튼이 기본적으로 여러 번 눌릴 수 있다는 안내가 있습니다. 따라서 외부 메시지 발송, 주문 변경, 고객 상태 변경처럼 재실행 비용이 있는 단계 앞에는 중복 확인 필드나 사람의 최종 검토를 두는 편이 안전합니다.

3. 단계를 붙이는 순서: Slack 메시지와 외부 앱 변경을 분리한다

단계는 워크플로우가 실제로 수행할 행동입니다. Slack 공식 문서는 Slack 안의 행동, 제3자 서비스의 connector, 조직이 만든 custom step을 구분합니다. 이 구분을 기사나 작업표에서 지키면 ‘메시지가 잘 올라왔다’와 ‘외부 데이터가 바뀌었다’를 같은 성공으로 기록하지 않게 됩니다.

Slack 단계는 알림과 분류를 맡긴다

초기 설계에서는 Slack 메시지, 채널 전달, 담당자 멘션처럼 되돌리기 쉬운 단계를 먼저 배치합니다. 메시지 내용에는 요청 ID, 원문 링크, 담당자, 현재 상태를 넣고, 자동화가 어느 단계까지 왔는지 사람이 읽을 수 있게 합니다. 단순 알림 글과 구분하기 위해 메시지 첫 줄에 `요청 접수`, `검토 대기`, `처리 완료`처럼 상태를 명시하면 후속 검색도 쉬워집니다.

Connector는 외부 변경 직전에 붙인다

Google Sheets 행 추가, 캘린더 일정 생성, 다른 서비스의 티켓 생성 같은 작업은 connector 단계가 될 수 있습니다. Slack 커넥터 안내는 제3자 서비스의 행동을 추가하는 기능과 앱 승인 필요성을 설명합니다. 목록에 앱 이름이 보인다고 해서 현재 워크스페이스에서 즉시 사용할 수 있다는 뜻은 아닙니다.

connector를 붙이기 전에는 다음을 확인합니다.

조건 분기와 오류를 같은 문제로 보지 않는다

‘문의 유형이 결제이면 재무 채널로 보낸다’는 정상 데이터의 분기입니다. 반면 인증 만료, 필수 필드 누락, 외부 서비스 오류는 실행 실패입니다. 둘을 한 버튼이나 한 메시지로 묶으면 정상 분기와 복구 작업의 원인이 섞입니다. 조건별 담당 채널과 오류 담당자를 별도로 기록하세요.

다른 자동화 도구의 구조가 궁금하다면 메이크 자동화 시나리오 구조 글을 참고할 수 있습니다. 다만 Make의 시나리오와 Slack Workflow Builder의 권한·공개 범위는 같은 기능이 아니므로 화면을 그대로 대체하지는 마세요.

4. 공개 범위·복사·관리자: 사용할 사람과 고칠 사람을 따로 적는다

워크플로우가 만들어졌다고 해서 모든 사람이 같은 권한을 갖는 것은 아닙니다. Slack 생성 안내는 누가 워크플로우를 찾고 사용할지, 누가 복사할지, 누가 workflow manager로 수정·게시 취소·삭제할지를 구분해 설정하도록 안내합니다.

찾고 사용하는 사람의 범위를 먼저 정한다

내부 팀 전체가 사용하는 요청 폼인지, 특정 채널의 구성원만 사용하는 흐름인지, Slack Connect의 외부 조직까지 포함하는지부터 정합니다. 외부 조직을 포함할 때는 채널 접근 권한뿐 아니라 조직 정책이 외부 사용을 허용하는지 확인해야 합니다. ‘링크를 아는 사람은 누구나 사용’이라고 추측하지 말고 현재 설정 화면의 문구를 기록하세요.

복사 권한은 원본 관리와 분리한다

누군가 워크플로우를 복사할 수 있는지와 원본을 수정할 수 있는지는 다른 문제입니다. 복사본이 다른 채널, 다른 connector 계정, 다른 데이터 보관 위치를 가질 수 있으므로, 템플릿으로 배포할 때는 원본의 민감한 필드와 인증 계정이 복제되는지 확인해야 합니다.

Workflow manager는 운영 책임자다

관리자는 메시지 한 줄을 수정하는 사람만이 아니라 단계, 권한, 게시 상태, 다른 관리자 목록을 다룰 수 있는 사람입니다. Slack의 Workflow Builder 접근·기능 관리 안내에 따라 담당자가 바뀌면 관리자 목록과 마지막 검수일을 함께 갱신하세요. 퇴사·팀 이동·프로젝트 종료처럼 운영 주체가 바뀌는 순간을 놓치면 살아 있는 자동화의 책임자가 사라집니다.

권한 기록은 다음 형식으로 남깁니다.

5. 폼 응답과 외부 데이터: 내려받을 수 있다는 것과 보관해도 된다는 것은 다르다

폼 응답은 자동화가 끝나면 사라지는 임시 입력이라고 단정할 수 없습니다. Slack은 워크플로우 폼 응답을 내려받는 경로와 삭제 요청의 별도 절차를 안내합니다. 폼 응답 다운로드 안내에 따르면 workflow manager가 Workflow Builder에서 응답 파일을 요청할 수 있고, 조직·플랜에 따라 사용 범위가 달라질 수 있습니다.

질문을 만들 때 보관 목적을 함께 적는다

상담 내용, 전화번호, 이메일, 주문번호처럼 식별 가능성이 있는 값을 받을 계획이라면 그 값이 왜 필요한지, 누가 볼지, 어디로 전송되는지부터 적습니다. 이 글은 특정 법률·보안·개인정보 준수 여부를 판단하지 않으므로, 조직 정책과 별도 검토가 필요한 값은 자동화 입력에서 제외하거나 담당자 확인 후 받는 편이 좋습니다.

응답 파일의 시간과 원본을 섞지 않는다

Slack 도움말은 폼 응답 CSV의 제출 시간대 표기를 안내합니다. 내려받은 파일의 시간대를 업무 시스템의 현지 시간으로 바로 바꾸기 전에, 파일의 표기와 팀 운영 시간대가 같은지 확인하세요. 응답 파일을 가공한 뒤에는 원본 파일, 가공본, 외부 전송본을 별도 이름으로 남겨서 어느 값이 자동화 원본인지 구분합니다.

완료 메시지가 데이터 처리 완료를 뜻하지는 않는다

`접수가 완료되었습니다`라는 Slack 메시지가 올라와도 connector가 실제로 행을 추가했는지, 일정이 생성됐는지, 외부 API가 성공 응답을 보냈는지는 별도 확인입니다. 최종 메시지에는 `접수됨`, `검토 중`, `외부 전송 성공`, `사람 확인 필요` 중 어떤 상태인지 구분해 적으세요.

6. 발행 전 테스트: 실제 고객 데이터 없이 다섯 경로를 확인한다

Workflow Builder를 게시하기 전에 설정 화면만 훑어보는 것으로는 부족합니다. 실제 고객, 실제 결제, 실제 공개 채널을 건드리지 않는 샘플을 만들고, 성공·보류·중복·권한 오류·외부 입력의 다섯 경로를 각각 기록하세요. Slack 공식 가이드의 단계 순서와 현재 워크스페이스 정책이 다를 수 있으므로, 아래 표의 ‘현재 화면’ 칸을 직접 채우는 것이 중요합니다.

정상 접수 경로

샘플 요청 하나를 넣고 트리거가 한 번만 작동하는지, 폼의 필수값이 다음 단계로 넘어가는지, 메시지와 connector의 대상이 예상한 곳인지 확인합니다. 성공 메시지에는 요청 ID와 처리 상태를 남깁니다.

미충족·보류 경로

필수값 하나를 비우거나 ‘기타’ 선택지를 넣고 흐름이 어디서 멈추는지 봅니다. 보류된 요청이 사라지지 않고 사람이 다시 찾을 수 있는지, 요청자에게 다음 행동이 안내되는지도 확인합니다.

중복 클릭·중복 요청 경로

버튼을 두 번 누르고 같은 webhook을 두 번 보내 봅니다. 외부 변경 단계가 중복으로 실행된다면 중복 키, 상태 확인, 사람 검수 중 어떤 보호 장치를 둘지 정해야 합니다. 테스트 후 샘플 데이터와 테스트 채널을 정리하세요.

권한·connector 오류 경로

실제 계정의 권한을 끊는 방식 대신, 권한이 없는 샘플 대상이나 별도 테스트 계정을 사용합니다. 커넥터가 보이지 않거나 인증을 요구하는 경우 앱 승인·추가 설정·사용자 인증 중 어떤 조건이 남았는지 기록합니다.

링크·Webhook 경로

링크 트리거는 Slack 내부에서만 시작되는지 확인하고, 외부 webhook은 민감하지 않은 샘플 본문으로 요청합니다. 외부 요청이 들어온 것과 후속 메시지·connector 실행이 완료된 것을 한 줄로 합치지 말고 두 개의 로그로 남깁니다.

7. 자주 묻는 질문과 최종 기록표

슬랙 워크플로우와 Slack 알림 자동화는 같은가요?

같지 않습니다. 알림 자동화는 특정 사건을 Slack 메시지로 전달하는 사례일 수 있고, Workflow Builder는 시작 조건·단계·변수·버튼·권한·관리자를 하나의 워크플로우로 구성하는 기능입니다. Slack 공식 FAQ도 시작 링크, 단계, 버튼, 사용 권한을 별도로 설명합니다. 파워오토메이트 승인 흐름 글처럼 다른 도구의 승인 사례가 이미 있다면, 새 글에서는 알림 문장을 반복하기보다 워크플로우의 설계·권한·테스트 경계를 다뤄야 합니다.

슬랙 워크플로우 폼을 만들면 외부 고객도 바로 작성하나요?

그렇게 단정할 수 없습니다. 링크로 시작하는 워크플로우는 Slack 안에서 실행된다는 현재 공식 안내가 있고, 외부 조직 사용 여부는 Slack Connect와 관리자 정책의 영향을 받습니다. 외부 접수가 목적이면 webhook, 별도 폼, 인증, 응답 보관 정책을 따로 검토해야 합니다.

버튼을 누르면 승인이 끝난 것으로 기록해도 되나요?

버튼 클릭은 워크플로우의 다음 단계로 이동시키는 동작일 뿐입니다. 승인 주체, 확인한 내용, 재클릭 가능성, 되돌리기 절차를 별도로 기록해야 합니다. 결제·계약·고객 상태 변경처럼 결과가 큰 업무는 자동 버튼만으로 최종 판단하지 마세요.

커넥터가 목록에 보이지 않으면 기능을 쓸 수 없나요?

현재 워크스페이스나 조직에서 앱 승인 또는 추가 설정이 필요한지 먼저 확인해야 합니다. Slack의 커넥터 안내는 연결 앱의 목록과 승인·설정 경계를 안내하지만, 모든 워크스페이스에서 동일하게 노출된다고 보장하지 않습니다.

몇 단계까지 만들 수 있나요?

Slack FAQ에는 워크플로우에 최대 100개 단계를 추가할 수 있다는 현재 안내가 있습니다. 다만 이 수치와 플랜·관리자 정책은 변할 수 있으므로, 실제 설계에서는 숫자 한도보다 사람이 검수할 수 있는 단위와 오류 지점을 먼저 줄이세요.

발행 전에 남길 최종 기록은 무엇인가요?

아래 표를 채운 뒤 공식 화면과 현재 워크스페이스 정책을 다시 확인합니다.

이 기록표가 비어 있다면 워크플로우를 게시하지 말고, 먼저 요청의 입구와 외부 변경 단계를 다시 나누세요. 자동화의 목표는 모든 판단을 없애는 것이 아니라, 반복되는 전달은 줄이고 사람의 확인이 필요한 지점을 눈에 보이게 남기는 데 있습니다. Slack의 현재 도움말과 워크스페이스 설정을 기준으로 작은 샘플부터 검증하면, 알림·폼·외부 작업이 서로 다른 상태라는 사실을 유지하면서 운영할 수 있습니다.