2026년 1월 22일·6분
혼란 없이 Slack 요청을 내부 제품으로 전환하기
반복되는 요청을 찾아 하나의 큐로 모으고, 워크플로우가 안정된 뒤에만 자동화를 추가해 Slack 요청을 구조화된 내부 제품으로 바꾸세요.
반복되는 요청을 찾아 하나의 큐로 모으고, 워크플로우가 안정된 뒤에만 자동화를 추가해 Slack 요청을 구조화된 내부 제품으로 바꾸세요.
몇 건의 Slack 요청은 별것처럼 느껴지지 않습니다. 그런데 같은 질문이 매일 나타나기 시작합니다: "권한을 추가해줄래?" "이 보고서를 고쳐줄 수 있어?" "새 워크스페이스를 만들어줄래?" 빠른 도움처럼 보였던 것이 구조 없는 비공식 시스템으로 변합니다.
첫 번째 문제는 분산입니다. 요청은 다이렉트 메시지, 팀 채널, 비공개 그룹, 사이드 스레드로 들어옵니다. 어떤 것들은 맥락을 포함하고 어떤 것들은 그렇지 않습니다. 누군가는 요청을 본 것 같다고 느끼지만 어디서 왔는지, 누가 맡았는지 기억하지 못합니다. 일이 하나의 명확한 큐에 들어가지 않기 때문에 잃어버려집니다.
두 번째 문제는 정보 부족입니다. 사람들은 빠르게 물어보고, 어떤 정보가 중요한지 모른 채 질문을 보냅니다. 그래서 일을 하는 사람이 누가 액세스가 필요한지, 어떤 시스템이 관련되는지, 언제 변경이 필요한지 같은 기본 정보를 쫓아야 합니다. 5분이면 끝날 일이 길고 반복되는 답변으로 변합니다.
긴급함은 이를 악화시킵니다. 가장 시끄러운 메시지가 앞에 오르며, 실제로 가장 중요한 일이 아닐 때도 우선 순위를 차지합니다. 조용하지만 중요한 요청은 뒤로 밀립니다. 시간이 지나면 팀은 우선순위로 일하는 대신 마지막에 가장 압박감 있게 올린 사람에게 반응하게 됩니다.
상태도 문제입니다. 공유 큐가 없으면 간단한 질문도 답하기 어려워집니다:
가시성 부족은 반복 작업, 지연, 양쪽의 불만을 만듭니다. 요청자는 무시당한다고 느끼고, 요청을 처리하는 쪽은 하루 종일 방해받는다고 느낍니다. 채팅 문제로 보였던 것이 사실은 워크플로우 문제입니다.
다시 반복해서 나타나는 요청부터 시작하세요. 추측하지 말고 지난 2~4주간의 실제 메시지를 검토하고 사람들이 실제로 무엇을 요청했는지 보세요.
짧은 검토 기간이면 충분한 경우가 많습니다. 매주 발생하는 요청을 보여주고 이제는 중요하지 않은 예외를 끌어들이지 않습니다.
메시지를 훑으면서 요청을 유형별로 묶으세요. 완벽한 분류가 필요하지 않습니다. 반복되는 작업이 무엇인지 실용적으로 파악하면 됩니다: 액세스 요청, 리포트 추출, 승인 확인, 작은 데이터 업데이트, 새 워크스페이스 설정 등.
간단한 스프레드시트면 충분합니다. 각 요청에 대해 다음을 적으세요:
마지막 항목은 많은 팀이 예상보다 더 중요하게 여깁니다. 같은 몇 사람이 반복해서 동일한 요청을 처리한다면 이미 내부 제품의 윤곽이 있을 수 있습니다. 지식이 어디에 있는지, 지연이 어디에서 발생하는지, 프로세스가 한 사람에게 과도하게 의존하는 부분을 볼 수 있습니다.
패턴은 금방 나타납니다. 영업은 같은 가격 예외를 자주 재무팀에 요청할 수 있습니다. 신입사원은 같은 앱 권한을 IT에 계속 요청할 수 있습니다. 매니저들은 약간 다른 표현으로 같은 주간 상태 업데이트를 운영팀에 요청할 수 있습니다.
지금은 드문 엣지 케이스는 건너뛰세요. 한 달에 한 번 발생하고 특별한 처리가 필요했던 요청은 제외하세요. 목표는 흔하고 지루하고 설명하기 쉬운 작업을 찾는 것입니다. 반복되는 요청은 표준화하기 쉽고 측정하기 쉬우며 명확한 인테이크 프로세스에서 혜택을 볼 가능성이 큽니다.
눈에 띄는 문제보다 더 작게 시작하세요. 가장 좋은 첫 사용 사례는 회사에서 가장 시끄러운 문제가 아닙니다. 자주 발생하고 몇 가지 명확한 단계로 진행되며 사람들이 합의할 수 있는 결과로 끝나는 것입니다.
강력한 첫 선택은 보통 단순한 승인 경로를 가집니다. 한 사람이 요청하고 한 사람이 확인하고 한 사람이 완료합니다. 다섯 팀이 관여해야 한다면 아직 깨끗한 요청 흐름을 만드는 것이 아니라 복잡한 프로세스를 맵핑하는 것입니다.
결과를 한 문장으로 설명해보세요. 그 문장이 모호하면 요청이 아마도 너무 광범위한 것입니다.
"팀을 위한 새 공유 인박스를 승인하고 생성하기"는 좋은 시작입니다. "고객 커뮤니케이션을 개선해주세요"는 아닙니다. 첫 번째는 명확한 완료 지점이 있고 두 번째는 열 가지 다른 의미를 가질 수 있습니다.
요청 유형이 충분히 작으면 다음 조건을 만족합니다:
사용 사례를 선택한 후에는 한 가지 지표를 골라 관찰하세요. 단순하게 유지하세요. 대기 시간은 모두가 이해하기 쉬우므로 좋은 시작입니다. 실수가 더 큰 문제라면 재작업(예: 누락된 정보로 인해 다시 질문해야 하는 빈도)을 추적하세요.
이 첫 사용 사례는 모든 것을 증명할 필요는 없습니다. 산재한 Slack 메시지보다 구조화된 인테이크 프로세스가 더 잘 작동한다는 것을 보여주기만 하면 됩니다. 작은 버전이 효과가 있으면 실제 데이터와 적은 의견, 자동화로 가는 쉬운 길을 얻게 됩니다.
첫 번째 해결책은 단순합니다: 한 개의 정문을 주세요. 사람들이 DM을 보낼지, 팀 채널에 게시할지, 누구에게 태그할지 추측할 필요가 없어야 합니다. 하나의 폼, 하나의 인테이크 채널, 또는 하나의 요청 인박스면 충분합니다. 도구 자체보다 일관성이 중요합니다.
그 큐는 매번 같은 기본 정보를 묻도록 해야 합니다. 짧지만 유용하게: 무엇이 필요한지, 왜 필요한지, 언제 필요한지, 승인이 필요하면 누가 승인하는지. 이런 정보가 빠지면 다시 대화가 시작됩니다.
상태 레이블도 도움이 되지만 단순하고 명확해야 합니다. 대부분의 팀은 복잡한 시스템이 필요 없습니다. 한눈에 무슨 일이 벌어지는지 알면 됩니다:
모두가 쉽게 이해할 수 있는 단어를 쓰세요. 요청이 너무 오래 머물러 있으면 상태가 이유를 분명히 해야 합니다.
같이 중요한 것은 큐를 초기에 확인하고 분류할 한 사람 또는 한 팀을 지정하는 것입니다. 그들이 모든 일을 한다는 뜻은 아닙니다. 첫 응답을 책임지고 요청이 완전한지 확인하며 적절한 곳으로 라우팅하는 역할을 맡는다는 뜻입니다. 명확한 소유자가 없으면 공유 큐는 곧 아무도 책임지지 않는 더미가 됩니다.
좋은 테스트는 이 질문입니다: 만약 내일 새로운 직원이 들어온다면, 그 직원이 어디로 보내야 하고 무엇을 포함해야 하는지 묻지 않고 요청을 제출할 수 있을까요? 대답이 '아니오'라면 자동화하기 전에 그것을 고치세요. 엉성한 인테이크 프로세스는 자동화하면 더 빠른 엉망진창이 될 뿐입니다.
자동화하기 전에 일주일 또는 이주일 정도 수작업으로 운영해보세요. 실제 요청이 어떻게 보이는지, 사람들이 어디에서 막히는지, 어느 부분을 시스템으로 바꿀 가치가 있는지 알 수 있습니다.
하나의 인테이크 형식으로 시작하세요. 짧은 폼, 고정된 템플릿, 또는 복사해 채우는 표준 Slack 메시지일 수 있습니다. 중요한 건 일관성입니다: 요청자 이름, 무엇이 필요한지, 왜 필요한지, 마감일, 필요하면 승인자.
그다음에는 하루 종일 반응하지 말고 정해진 시간에 큐를 확인하세요. 예를 들어 10:00와 15:00에 큐를 검토하세요. 이는 집중을 보호하고 요청이 무작위한 핑이 아니라 과정으로 이동한다는 것을 팀에게 가르칩니다.
같은 경로를 매번 사용하세요:
일하면서 실제로 수행한 단계를 적으세요. 단순하게 유지하세요. 항상 관리자 승인을 확인하거나 한 도구에서 다른 도구로 데이터를 복사하거나 같은 후속 질문을 한다면 그것들을 기록하세요. 반복되는 행동들은 나중에 더 나은 워크플로우의 원재료입니다.
또한 마찰 요소를 평이한 언어로 기록하세요. 누락된 세부 정보, 승인 지연, 불명확한 소유권, 반복적으로 나오는 질문들을 적으세요. 소량의 사례 후에 패턴은 빠르게 드러납니다.
단계가 더 이상 변하지 않을 때 자동화할 준비가 되었다는 좋은 신호입니다. 대부분의 요청이 동일한 경로를 따르면 자동화할 만한 안정성이 있습니다. 그 전까지는 수동 작업이 낭비가 아닙니다. 시스템이 실제로 무엇을 필요로 하는지 배우는 과정입니다.
같은 요청이 계속 나타난다면 그 결정은 한 사람의 머릿속에만 머물러 있어선 안 됩니다. 매번 하는 검사들을 실제로 사용하는 순서대로 적어두세요. 습관을 다른 사람이 따라할 수 있는 프로세스로 바꾸는 것입니다.
결과를 바꾸는 질문부터 시작하세요. 요청이 완전한가? 요청자가 승인을 받았나? 마감일이 온보딩, 급여, 고객 작업과 연관되어 있나? 그런 검사가 대부분의 요청에서 일어난다면 규칙 세트에 포함하세요.
규칙을 조직하는 간단한 방법은 다음과 같이 구분하는 것입니다:
이렇게 하면 인테이크 프로세스가 사소한 빈틈 때문에 멈추지 않습니다. 관리자가 한 가지 유용한 세부사항을 빼먹었지만 직원, 팀, 액세스 수준을 포함했다면 요청을 진행시켜도 될 수 있습니다.
다음으로 가장 자주 발생하는 결과에 대한 표준 응답을 작성하세요. 보통은 승인, 정보 부족, 잘못된 채널, 중복 요청, 검토 필요 같은 경우입니다. 각 응답은 간단하고 구체적으로 유지해서 다음에 무엇이 일어나는지 분명히 알게 하세요.
예를 들어 매번 새로 쓰는 대신 "승인되었습니다. 오늘 액세스를 설정합니다" 또는 "시작하기 전에 관리자 승인이 필요합니다" 같은 메시지를 사용하세요.
모든 단계를 규칙으로 만들 필요는 없습니다. 예외, 민감한 액세스, 이례적인 마감일, 정책을 위반할 가능성이 있는 요청 등은 사람의 판단이 필요합니다. 좋은 규칙은 사람을 프로세스에서 제거하는 것이 아니라 불필요한 괴로운 질문을 줄여줍니다.
신규 입사자 액세스는 종종 첫 번째 내부 제품으로 가장 적합합니다. 거의 모든 회사에서 발생하고 단계가 반복되며, 빠뜨리면 첫날 비용이 분명하게 드러납니다.
예전 방식을 상상해보세요. 매니저가 Slack에 "Sam이 월요일에 시작해. 설정해줄래?"라고 보냅니다. 그러면 세 팀이 각각 후속 질문을 하고 누군가는 한 시스템을 잊어버려 Sam은 첫 아침을 액세스를 기다리며 보냅니다.
더 나은 방법은 하나의 명확한 큐로 시작하는 것입니다. 매니저가 항상 같은 곳에 요청을 제출하고 폼은 역할, 시작일, 어떤 시스템이 필요한지만 묻습니다.
이 작은 변화는 두 가지 유용한 일을 합니다. 대화를 줄여 모두의 속도를 높이고, 무엇이 언제 요청되었는지에 대한 깔끔한 기록을 만듭니다.
표준 역할에 대해서는 과정이 '지루할 정도'로 단조로워야 합니다. 요청이 영업 담당자인지, 디자이너인지, 지원 담당자인지에 따라 동일한 승인과 액세스 패키지가 매번 따라가게 하세요. 예를 들어:
이때 프로세스가 호의가 아닌 제품처럼 느껴지기 시작합니다. 사람들은 어디에 제출해야 하는지, 어떤 정보가 필요한지, 보통 경로가 얼마나 걸리는지 알게 됩니다.
모든 요청을 자동화할 필요는 없습니다. 임시 계약자, 교차 팀 역할, 민감한 시스템 접근은 여전히 사람 소유자에게 맡겨야 합니다. 대부분의 요청이 하나의 경로를 따르고 예외만 특별 처리를 필요로 한다면 더 발전시킬 준비가 된 것입니다.
자동화는 작업이 이미 명확한 패턴을 따를 때 가장 도움이 됩니다. 팀이 아직 단계를 바꾸고 소유권에 대해 논쟁하거나 각 요청을 다르게 처리한다면 자동화는 혼란을 고정시킬 뿐입니다.
간단한 규칙은 이렇습니다: 사람들 스스로 동일하게 설명할 수 있을 때까지 수작업으로 운영하세요. 흐름이 지루하고 예측 가능하며 가르치기 쉬워지면 보통 자동화해도 안전합니다.
처음 자동화할 것은 판단이 필요 없는 저위험 작업입니다. 요청 워크플로우에서는 보통 리마인더, 확인, 상태 업데이트가 여기에 해당합니다.
누군가 요청을 제출하면 시스템이 접수 확인을 보내고 예상 처리 시간을 알려주며 요청이 새로움에서 진행 중, 완료로 이동할 때마다 업데이트를 게시할 수 있습니다. 이는 의사결정을 바꾸지 않고 후속 메시지를 줄입니다.
초기 자동화에는 다음이 포함될 수 있습니다:
라우팅은 나중에 하세요. 요청이 여전히 사람들 사이를 튕기고 있거나 누가 무엇을 승인해야 할지 계속 바뀐다면 자동 라우팅은 더 많은 정리 작업을 낳습니다. 수작업 경로가 안정되고 대부분의 요청이 동일한 인수인계를 따를 때까지 기다리세요.
항상 수동 오버라이드를 두세요. 일부 요청은 언제나 복잡하거나 긴급하거나 예외적입니다. 사람들이 규칙에서 벗어나 간단히 문제를 해결하고 진행할 수 있는 방법이 있어야 합니다. 시스템이 예외를 처리하지 못하면 사용자는 신뢰를 잃습니다.
자동화를 확장하기 전에 실패 사례를 검토하세요. 잘못 라우팅되었거나 지연되었거나 잘못된 답으로 닫힌 요청을 살펴보세요. 그런 실수는 프로세스가 여전히 불명확한 곳을 보여줍니다. 자동화는 이미 작동하는 워크플로우를 지원해야지 새로운 것을 발명하면 안 됩니다.
대부분의 팀이 막히는 이유는 요청이 너무 복잡해서가 아닙니다. 한 번에 모든 것을 고치려 하기 때문입니다.
한 가지 흔한 실수는 너무 빠르게 확장하는 것입니다. 팀들이 액세스 요청, 디자인 요청, 구매 승인, 버그 리포트를 한 프로세스에 섞어 넣습니다. 효율적으로 보이지만 각 요청 유형마다 규칙, 담당자, 타이밍이 다릅니다.
또 다른 실수는 어디서나 요청을 받는 것입니다. 사람들이 DM, 랜덤 채널, 그룹 채팅 어디에서든 요청하면 누군가는 나중에 세부 정보를 찾아야 합니다.
너무 일찍 자동화하는 것도 함정입니다. 승인이 사례별 판단에 달려 있다면 자동화는 잘못된 결정을 더 빠르게 만들 뿐입니다. 상태가 보이지 않으면 사람들은 요청이 보였는지, 승인되었는지, 차단되었는지 알 수 없어 다시 묻습니다.
간단한 예를 들면 상황이 어떻게 망가지는지 보여줍니다. 신규 입사자가 앱 액세스, 노트북, Slack 초대를 필요로 한다고 상상하세요. 각 부분이 다른 메시지로 들어온다면 팀은 작업하는 것보다 요청을 조각내는 데 더 많은 시간을 씁니다. 승인 규칙이 모호하면 자동화가 잘못된 사람에게 보내거나 먼저 검토해야 할 것을 승인해버릴 수 있습니다.
해결책은 보통 지루합니다. 좋은 신호이기도 합니다. 한 요청 유형으로 시작하세요. 하나의 인테이크 경로를 사용하세요. 매번 동일한 핵심 정보를 요청하세요. 새 팀원이 추측하지 않고도 따를 수 있을 만큼 승인 규칙을 단순하게 유지하세요.
진행 상황을 분명히 보여주는 것도 중요합니다. '접수됨', '검토 중', '완료' 같은 기본 상태만으로도 후속 메시지를 줄이고 신뢰를 쌓을 수 있습니다.
프로세스가 여전히 자주 예외를 필요로 한다면 무거운 자동화에 적합하지 않습니다. 먼저 규칙을 정리하세요. 그런 다음 이미 매번 동일하게 작동하는 부분부터 자동화하세요.
더 많은 팀, 더 많은 요청 유형, 또는 본격적인 자동화를 추가하기 전에 잠시 멈추고 기본을 테스트하세요. 프로세스를 만든 사람들에게는 작동하더라도 다른 사람들에게는 혼란스러울 수 있습니다.
몇 가지 간단한 사항을 확인하세요:
첫 번째 항목이 많은 팀이 예상보다 훨씬 더 중요합니다. 새로운 직원이나 바쁜 매니저가 도움 없이 프로세스를 따를 수 없다면 시스템은 확장할 준비가 되지 않은 것입니다. 워크플로우는 처음 보는 사람에게도 명확해야 합니다.
인테이크는 짧게 유지하세요. 사람들이 다섯 개의 거의 쓸모없는 추가 질문이 있는 폼보다는 명확하고 유용한 정보를 묻는 폼을 더 잘 사용할 것입니다.
소유권은 많은 시스템이 깨지는 지점입니다. "검토 중"은 누군가 한 사람이나 한 팀이 그것을 앞으로 진행시킬 책임이 있어야 의미가 있습니다. 책임자가 없으면 요청은 거기서 멈춰버립니다.
예외도 신경 써야 합니다. 항상 특이한 사례, 긴급 요청, 맥락이 부족한 사람이 있을 것입니다. 그런 경우들이 전체 Slack 대화를 다시 시작하지 않도록 백업 경로를 제공하세요.
그리고 여전히 사람의 결정이 필요한 단계를 보호하세요. 너무 일찍 자동화하면 일반적으로 재작업을 만들 뿐입니다.
워크플로우가 손으로 잘 작동하면 곧장 대형 시스템으로 건너뛰지 마세요. 하나의 큐와 하나의 반복 요청을 유지하고 그 경로를 먼저 매끄럽게 만드세요. 반복되는 Slack 작업을 신뢰할 수 있는 무언가로 바꾸는 가장 안전한 방법입니다.
이미 받는 요청들을 가이드로 사용하세요. 사람들이 반복해서 같은 세부사항을 빼먹는다면 그 항목을 필드로 추가하세요. 검토자가 반복해서 같은 선택을 한다면 그 선택을 간단한 규칙으로 바꾸세요. 실제 트래픽이 무엇이 프로세스에 속하고 무엇이 잡음인지 알려줍니다.
다음 버전에는 보통 몇 가지 항목만 추가됩니다:
자동화는 작은 조각으로 추가하세요. 액세스 요청에 항상 관리자 승인이 먼저 필요하다면 그 단계만 자동화하세요. 일부 요청이 여전히 판단을 필요로 한다면 수동으로 남겨두세요. 목표는 모든 것을 자동화하는 것이 아니라 반복되는 단계를 제거하고 예외를 눈에 보이게 유지하는 것입니다.
워크플로우가 계속 성장하면 자체 내부 앱이 필요할 수 있습니다. Koder.ai 같은 도구는 채팅을 사용해 요청 프로세스용 간단한 웹, 서버 또는 모바일 앱을 만들고, 요청 패턴이 나타날 때마다 계속 다듬을 수 있게 도와줍니다. Slack에 더 많은 일을 쌓아두지 마세요.
최고의 내부 제품은 보통 작게 시작합니다: 하나의 큐, 하나의 요청 유형, 실제 사용, 그리고 신중한 확장. 일주일 동안은 느리게 느껴질 수 있지만 다음 1년은 훨씬 빠릅니다.
채팅은 작업을 숨깁니다. 요청들이 DM, 채널, 사이드 스레드에 흩어져 들어오면 소유권, 상태, 우선순위를 알기 어렵습니다. 단일 큐를 만들면 요청을 추적하고 완료하며 측정하기가 쉬워집니다.
빈번하고 단순하며 반복 가능한 것을 고르세요. 좋은 첫 번째 사례는 시작과 끝이 명확하고 승인 경로가 작은 것—예를 들어 신규 입사자 액세스나 공유 인박스 생성 같은 것들이 좋습니다.
지난 2~4주의 실제 메시지를 검토하고 유형별로 그룹화하세요. 설명하기 쉽고 자주 발생하는 공통 요청에 집중하고, 드문 일회성 사례는 지금은 무시하세요.
짧지만 완전하게 유지하세요. 무엇이 필요한지, 왜 필요한지, 언제 필요한지, 승인자가 누군지(승인이 필요하면)를 물으세요. 목표는 불필요한 추가 질문을 줄일 최소한의 세부 정보를 모으는 것입니다.
아니요. 하나의 폼, 하나의 인테이크 채널, 또는 하나의 공유 인박스로 시작할 수 있습니다. 중요한 건 도구가 아니라 모든 사람이 같은 진입점을 사용하고 동일한 기본 요청 형식을 따르는 일관성입니다.
먼저 일주일에서 이주일 정도 수동으로 운영해보세요. 실제 사례를 얻고 어디에서 멈추는지, 어떤 단계가 항상 같은지 확인할 수 있습니다.
가장 안전한 저위험 부분부터 시작하세요. 요청 접수 확인, 리마인더, 상태 업데이트처럼 판단이 필요 없는 작업들이 초기 자동화에 적합합니다. 승인과 라우팅은 워크플로우가 안정될 때까지 수동으로 두세요.
여전히 판단이 필요한 것은 수동으로 두세요. 민감한 액세스, 특이한 마감일, 정책 예외, 정상 경로에 맞지 않는 요청 등이 여기에 해당합니다.
프로세스가 '좋은 의미로 지루해질' 때가 확장할 준비가 된 신호입니다. 새로운 요청자가 도움 없이 요청을 제출할 수 있고, 각 상태에 책임자가 있으며, 대부분의 요청이 동일한 경로를 따른다면 확장해도 됩니다.
요청량이 계속 늘고 규칙이 안정적이면 전용 내부 앱이 도움이 됩니다. Koder.ai 같은 도구는 채팅에서 간단한 웹, 서버, 모바일 앱을 만들고 워크플로우를 정교하게 다듬는 데 도움을 줄 수 있습니다.