01
자동화하고 싶은 것은 버튼일까요, 기다리는 시간일까요?
업무를 자동화하고 싶다는 요청을 받으면, 먼저 최근에 처리한 일 하나를 함께 따라가 보려 합니다. 누가 요청했고, 어떤 자료가 빠져 있었고, 누구의 확인을 기다렸는지 묻습니다. 업무 매뉴얼에는 한 줄로 적혀 있어도 담당자의 하루에는 여러 번의 확인과 재입력이 들어 있을 수 있습니다.
요청서를 자동으로 만드는 것보다 요청서에 꼭 필요한 정보를 처음부터 받는 편이 나을 때도 있습니다. 알림을 늘리기보다 승인 담당자를 명확히 정하는 것이 먼저일 수도 있습니다. 우리가 요구분석을 중요하게 보는 이유입니다. 고객이 원하는 기능을 받아 적는 데서 그치지 않고, 그 기능으로 줄이려는 일을 구체화하겠습니다.
AX와 자동화가 만나는 지점
기업 AX가 어떤 업무에 AI를 적용하고 구성원이 어떻게 활용할지 정하는 넓은 과정이라면, 이 서비스는 특정 업무가 접수되어 완료되는 절차를 다룹니다. AI가 필요하지 않은 연결도 있습니다. 정해진 날짜에 알림을 보내거나 입력값을 다른 시스템으로 전달하는 일은 규칙과 API만으로 해결할 수 있습니다.
02
같은 일을 서로 다른 자리에서 들어봅니다
요청자는 빨리 답을 받고 싶고, 실무자는 필요한 자료를 한 번에 받고 싶고, 승인자는 판단에 필요한 근거를 보고 싶어 합니다. 한 사람의 설명만으로 설계하면 다른 사람에게 일이 옮겨갈 수 있습니다. 그래서 담당자별 인터뷰와 실제 양식, 처리 기록을 함께 보고 공통 흐름과 예외를 나눕니다.
요구분석 결과에는 화면 목록뿐 아니라 시작 조건, 입력 자료, 담당 역할, 완료 기준이 들어가야 합니다. 누구에게 어떤 권한이 있는지, 요청이 취소되거나 같은 자료가 두 번 들어오면 어떻게 할지도 적습니다. 이 내용을 바탕으로 현재 절차와 바꿀 절차를 나란히 검토합니다.
분석이 끝나면 남기는 것
고객에게는 업무 흐름도, 역할별 요구사항, 연결할 시스템과 권한 목록, 예외 처리 기준, 우선 적용할 과제를 정리해 드리는 구성을 제안합니다. 담당자가 바뀌어도 왜 이렇게 만들었는지 설명할 수 있는 자료가 목표입니다. 모든 절차를 한 번에 개발하기보다 반복 빈도와 오류의 영향, 연결 가능성을 보고 첫 범위를 정합니다.
03
이미 쓰는 도구에서 시작할 수 있습니다
아래는 요구분석 뒤에 검토할 수 있는 자동화 예시입니다. 현재 완성된 고객 구축 사례를 뜻하지 않습니다. 슬랙을 쓰는 조직이라면 요청의 입구를 슬랙에 두고, 원본 자료와 최종 상태는 기존 업무 시스템에서 관리하는 방식을 검토할 수 있습니다.
Slack Workflow Builder는 외부 앱 연결 단계와 조건 분기 등을 지원합니다. 다만 유료 요금제, 연결 계정 인증, 조직의 앱 승인과 설정이 적용될 수 있습니다. 실제 가능 범위는 고객 환경에서 확인해야 합니다.
Slack 공식 Workflow Builder 안내 ↗
| 업무 장면 | 줄일 수 있는 반복 | 사람에게 남길 판단 |
|---|---|---|
| 반복되는 내부 요청 | 필수 항목을 받고 담당자에게 전달, 접수 상태 회신 | 담당자 변경·우선순위 판단 |
| 자료 검토와 승인 | 원본 링크와 요청 내용을 모아 검토 대기 목록 생성 | 내용 확인과 최종 승인 |
| 회의 뒤 후속 업무 | 결정사항 초안에서 담당·기한 후보를 정리 | 회의 참여자가 확정한 뒤 등록 |
| 마감과 진행 확인 | 기한 기준으로 미완료 항목을 찾아 묶어 알림 | 기한 변경과 예외 승인 |
새 시스템을 만들지 않는 선택
기존 도구의 입력 양식이나 알림 설정만 바꿔도 충분한지 먼저 보겠습니다. 여러 시스템을 연결해야 하면 제공되는 API와 커넥터를 검토합니다. 연결 수단이 없는 화면 작업에는 RPA가 후보가 될 수 있지만, 화면 변경에 따른 유지보수까지 고려해야 합니다. AI를 쓰는 단계는 문서 분류나 요약 초안처럼 해석이 필요한 작업으로 구분하고, 결과를 확인할 자리를 둡니다.
04
연결한 다음에도 돌볼 사람이 필요합니다
Herm과 동료들은 실제 RPA 프로젝트 보고 35건을 분석하고 전문가 인터뷰와 워크숍을 거쳐 도입 프레임워크를 제안했습니다. 초기화·구현·확장의 세 단계에 걸친 접근입니다. 자동화를 만드는 일과 조직에서 운영하는 일을 함께 다루는 연구로 읽을 수 있습니다.
이 연구는 RPA에 관한 것이므로 슬랙 기반 자동화 전체의 성과를 입증하지는 않습니다. 우리가 가져오는 설계 질문은 분명합니다. 업무가 바뀌면 누가 규칙을 수정할지, 실패하면 어디에서 알아차릴지, 담당자가 직접 처리할 방법은 무엇인지 구현 전에 정하자는 것입니다.
Herm et al. · A framework for implementing robotic process automation projects ↗
| 확인할 것 | 실제 질문 |
|---|---|
| 상태와 책임 | 처리 중·실패·완료를 누가 확인하는가? |
| 중복과 재시도 | 같은 요청을 다시 보내도 두 번 실행되지 않는가? |
| 권한과 원본 | 원본은 어디에 있고 누가 열람할 수 있는가? |
| 변경과 중단 | 규칙이 바뀌면 누가 수정하고, 필요하면 어떻게 멈추는가? |
05
솔버톤에서 배운 연결의 문제
전남광주 솔버톤에서는 멘토와 참가팀의 연결, 가능 시간과 예약, 공지와 제출 자료를 한 프로그램 안에서 다뤘습니다. 역할에 따라 필요한 화면과 접근 범위를 구분하면서, 한 사람이 입력한 상태가 다음 사람의 행동으로 이어져야 한다는 문제를 다뤘습니다.
행사 후 전달받은 참가자 의견에는 멘토와 멘티를 연결하고 절차를 플랫폼에서 관리하는 방식이 직관적이고 편했다는 반응이 있었습니다. 별도의 설문이나 인터뷰 기록으로 집계한 결과는 아니지만, 다음 설계에서 살펴볼 단서를 줍니다. 사용자가 다음에 무엇을 해야 할지 쉽게 알 수 있는가 하는 질문입니다.
이 사례는 요구분석과 역할별 업무 연결을 설명하는 경험입니다. 기업의 슬랙 자동화 구축이 완료되었다거나 업무 시간이 얼마 줄었다는 실적으로 소개하지 않습니다.
06
잘 돌아가는 작은 흐름부터 넓힙니다
첫 적용에서는 처리에 걸린 전체 시간과 담당자가 직접 손댄 시간, 재요청과 오류를 함께 기록하는 방식을 제안합니다. 자동화가 빨리 실행되어도 앞뒤의 확인 업무가 늘었다면 개선이라고 보기 어렵기 때문입니다. 비교 기간과 업무 종류를 맞추고, 예외가 많은 날도 살펴보겠습니다.
이후 확대 여부는 운영 결과와 담당자의 경험을 보고 결정합니다. 한 부서에서 정리한 흐름을 다른 부서에 그대로 복제하기보다, 공통 규칙과 각 부서의 예외를 다시 확인하겠습니다. 고객 조직이 자동화를 이해하고 관리할 수 있도록 운영 안내와 인수인계 범위도 함께 정합니다.
함께 이야기하기
지금 맡고 계신 일부터 들려주세요.
반복되는 업무 하나와 현재 사용하는 도구를 알려주세요. 담당자와 자료가 오가는 흐름부터 함께 살펴보겠습니다.
