Amazon Quick으로 내 업무와 관련된 Slack 이슈만 모아보기

하루 동안 쌓인 Slack 메시지에서 내 업무를 선별하고
다음 날 아침 Desktop과 모바일 Feed로 확인하기

Slack으로 다수 고객사의 업무를 처리하다 보면 영업 문의와 기술지원 요청이 여러 채널에 올라옵니다. 저를 멘션한 메시지는 알림으로 확인할 수 있지만 멘션이 없어도 제가 처리해야 하는 요청이 있습니다. 다른 업무를 처리하는 사이 채널에 메시지가 쌓이면 이런 요청은 뒤로 밀리고 결국 놓치는 경우가 있습니다.

채널 내용을 요약해 읽더라도 그중 제가 처리해야 할 요청은 다시 가려내야 합니다. 고객사 이름을 담당 목록과 대조하고 요청 작업이 제 지원 범위에 해당하는지 살펴봐야 하기 때문입니다. 메시지를 하나씩 찾아 읽으며 확인하는 과정을 줄이고 싶었습니다.

이번 구성의 목적은 하루 동안 쌓인 Slack 메시지를 다음 날 아침 Feed에서 요약해 보고 제가 놓친 업무가 있는지 확인하기입니다.

이를 위해 Amazon Quick에 담당 고객사·지원 범위·과거 작업 이력 자료를 연결했습니다. 그리고 Quick 기능을 이용해 매일 오전 7시마다 최근 24시간 동안의 메시지 중 제 업무와 관련된 이슈를 선별해 Feed에 정리하도록 구성했습니다. 아래에서는 가상의 고객사와 운영 자료로 구성 흐름을 살펴보고 Desktop·모바일에서 확인한 결과를 소개합니다.

*본문과 화면의 조직·채널·자료·Agent명은 예시 명칭으로 대체했으며 일부 화면의 명칭은 편집했습니다.

Slack 이슈 선별에 필요한 업무 기준

Slack 메시지에는 지금 발생한 상황이 담겨 있지만 담당 고객사 목록·지원 범위·과거 작업 이력은 별도 문서로 관리하는 경우가 많습니다. 업무 관련도를 판단하려면 Slack과 기존 문서 두 가지 정보를 함께 확인해야 합니다.

예를 들어 다음과 같은 메시지를 받았다고 가정해 보겠습니다.

OO 고객사의 금일 ECS 배포 후 Platform 서비스 내 새 태스크가 unhealthy 상태입니다. 확인 부탁드립니다.

이 메시지만으로는 담당자와 대응 범위를 확정하기 어렵습니다. 해당 고객사의 담당 목록과 이전 배포 이력을 함께 보면 누가 검토해야 하는지, 어떤 설정부터 확인해야 하는지 구체화할 수 있습니다.

이번 구성에서는 아래 기준으로 이슈를 선별했습니다.

판단 항목	확인할 내용
담당 여부	내가 담당하는 고객사 또는 직접 요청받은 업무인가?
지원 범위	운영 지원, PoC, 상담·자문 중 어디에 해당하는가?
과거 이력	이전 작업에서 남겨둔 확인 사항이나 미완료 항목이 있는가?
다음 조치	확인·검토·승인 요청 중 무엇이 필요한가?

Amazon Quick 업무 분석 아키텍처

그림의 실선 화살표는 업무 데이터가 Connector와 Agent를 거쳐 Feed로 이어지는 흐름입니다. 아래쪽 점선은 Agent가 판단할 때 Space의 업무 자료를 참고하는 관계입니다. 위쪽 Routine은 이 조회·분석 과정을 매일 정해진 시간에 실행합니다.

1. Connector로 업무 메시지를 조회합니다.
   이번 구성에서는 Slack 세 채널에서 최근 24시간 동안 작성된 본문과 스레드 댓글을 대상으로 했습니다.
   
2. Space에 업무 기준 자료를 모읍니다.
   담당 고객사·지원 범위·과거 작업 이력 자료를 Agent가 참고할 수 있도록 연결했습니다.
   
3. Agent가 관련 이슈와 필요한 조치를 정리합니다.
   메시지와 업무 기준을 대조해 담당 여부와 우선순위를 판단합니다.
   
4. Routine으로 매일 오전 7시에 분석합니다.
   별도 요청 없이도 최근 24시간 동안의 메시지를 정리하도록 설정했습니다.
   
5. Desktop과 모바일에서 같은 Feed를 확인합니다.
   선별한 이슈의 판단 근거·필요 조치·원문 링크를 함께 볼 수 있습니다.
   
   

이처럼 Quick의 연결·지식 참조·예약 실행 기능¹을 조합하면 여러 채널의 메시지와 업무 문서를 일일이 확인하지 않아도 필요한 내용만 Feed에 모아볼 수 있습니다. 사용자는 정리된 결과를 바탕으로 놓친 요청이 있는지 살펴보고 다음 조치를 결정합니다.

그림의 Gmail·Microsoft Teams는 함께 연결할 수 있는 업무 도구 예시입니다. 이번 글에서는 Slack 조회, Space 참조, 이슈 선별, Desktop·모바일 Feed 확인 과정을 다룹니다. 아래에서는 이 흐름을 구성한 화면과 결과를 살펴봅니다.

1. AWS, How Amazon Quick works, 2026

1. Slack Connector로 분석할 메시지 범위 지정

먼저 Quick의 [Customize → Connectors]에서 Slack 연결을 확인했습니다. Slack Connector를 이용하면 채널 대화를 Quick에서 조회해 분석 대상으로 가져올 수 있습니다.

분석 대상은 영업, 기술, 기획 세 채널로 정했습니다. 수집 기간은 최근 24시간이며 해당 기간에 작성된 본문과 그 본문의 스레드 댓글을 함께 조회하도록 했습니다.

Slack에서는 채널 본문 조회와 스레드 댓글 조회가 별도 기능으로 동작²합니다. 본문 조회만 허용하면 댓글에 있는 추가 설명이나 진행 상황을 놓칠 수 있습니다.

분석할 채널과 수집 기간 그리고 허용할 동작은 Quick Desktop 앱의 Chat에서 자연어로 전달했습니다. 아래 화면은 Slack 분석 지침을 Chat 입력창에 작성한 모습입니다.

2. AWS, Slack integration, 2026

Slack 분석 범위를 정한 지침 예시

[Quick에 전달한 지침 예시]

Slack의 영업, 기술, 기획 채널을 분석 대상으로 사용해줘.

최근 24시간에 작성된 본문과 해당 본문의 스레드 댓글을 수집해줘.
동일한 이름의 채널이 있으면 워크스페이스와 채널 ID를 확인해줘.

Slack은 조회 목적으로만 사용하고
채널에 메시지나 댓글을 작성하지 않도록 설정해줘.

지침에는 수집 범위와 읽기 전용 원칙을 담았습니다. 자동 실행에 사용할 도구와 대상 채널 제한은 별도로 확인했습니다.

실제로 Routine 생성 후 권한을 점검하는 과정에서 본문·스레드 조회 도구가 빠진 것을 발견했습니다. 이후 필요한 도구를 추가하고 조회 대상을 세 채널로 제한했습니다. 연결 성공 여부뿐 아니라 실제 수집에 필요한 도구가 허용되어 있는지도 확인해야 합니다.

2. Quick Space에 업무 판단 자료 연결

업무 관련도를 판단할 기준 자료는 Space에 모았습니다. [Space 생성 → 로컬 폴더 접근 허용 → Space에 문서 업로드] 순서로 진행했습니다. ‘로컬 폴더 연결’은 Quick이 PC의 자료를 읽을 수 있게 하는 단계이고 ‘Space 업로드’는 그 자료를 분석 근거로 쓸 수 있게 준비하는 단계입니다.

Space 생성하기

Quick의 [Spaces → Create]에서 이름과 설명을 입력하면 업무 자료용 Space를 만들 수 있습니다. 이번 구성에서는 고객사 담당 정보와 작업 이력을 모은 Space를 사용했습니다.

로컬 자료 폴더 연결하기

로컬 자료는 [Customize → Knowledge → Add folder]로 연결했습니다. 이번에는 담당 고객사와 운영 이력이 담긴 [기술 업무 자료] 폴더의 접근을 허용했습니다.

연결한 폴더는 Knowledge의 Local folders 목록에 [Up to date] 상태로 표시되었습니다.

구성 초기에는 로컬 폴더 접근 권한이 없어 Quick이 파일을 읽지 못했습니다. Chat에서 파일 경로를 알려주는 것만으로는 접근 권한이 생기지 않아서 폴더를 연결한 뒤 업로드를 진행했습니다.

Space에 문서 업로드하고 확인하기

처음 생성한 Space는 비어 있었습니다. 이름만 만든 상태에서는 담당 고객사나 지원 범위를 문서로 확인할 수 없어 기준 자료 먼저 업로드했습니다. 문서 업로드도 폴더와 대상 Space를 지정해 Quick Chat으로 요청할 수 있습니다.

[Quick에 전달한 지침 예시]

연결된 로컬 폴더 '기술 업무 자료'의
파일 목록을 확인하고, 업무 판단에 사용할 문서를
'기술 업무 자료' Space에 업로드해줘.

업로드가 끝나면 문서 목록과 처리 상태를 확인해줘.

위 지침은 로컬 폴더의 문서를 Space에 올리는 요청 예시입니다. 가상 기술 업무 자료 12개를 ‘기술 업무 자료’ Space에 업로드했습니다.

가상 운영 자료에는 다음 내용을 담았습니다.

자료	활용 목적
고객사 담당 목록과 지원 범위	담당 여부와 계약 범위 확인
고객사별 구성과 리소스 기준	메시지에 나온 서비스와 운영 환경 대조
과거 작업 이력	이전 변경 사항과 후속 확인 항목 참조
기술지원 대응 규칙과 담당 배정	공통 요청의 배정 기준과 대응 범위 확인
EKS·ECS·Bedrock 점검 절차	필요한 확인 항목 정리
업무 기록과 변경 승인 양식	기록·승인 절차 참고

업로드한 문서는 Ready 상태가 되면 자연어로 질의할 수 있습니다³. 이번에 올린 12개 자료도 모두 Ready 상태로 준비된 것을 확인했습니다.

3. AWS, Spaces (Amazon Quick on desktop), 2026

자료를 올린 뒤에는 해당 Space를 업무 판단 근거로 사용하도록 요청했습니다. 담당 고객사·지원 범위·과거 이력을 기준으로 삼도록 명시했습니다. 이렇게 참고 자료를 Space에 모아두면 요청할 때마다 담당 목록과 작업 이력을 첨부하지 않아도 같은 자료를 바탕으로 분석할 수 있습니다.

[Quick에 전달한 지침 예시]

업무 관련도 판단 기준으로 '기술 업무 자료' Space를 사용해줘.

먼저 Space에 어떤 문서가 있는지 확인하고
담당 고객사·지원 범위·대응규칙·작업이력을
판단 근거로 사용할 수 있는지 점검해줘.

자료가 없거나 기준이 부족하면 임의로 판단하지 말고
어떤 자료를 보완해야 하는지 알려줘.

3. 전용 Agent에 업무 판단 기준 설정

Slack 이슈 분석은 전용 Agent가 맡도록 구성했습니다. 업무 기준 Space, Slack Connector, 분석 지침을 하나의 Agent에 연결하고 Routine의 실행 대상으로 지정했습니다.

전용 Agent에 판단 기준을 저장해 두면 평소 Chat에서도 같은 기준이 적용됩니다. 특정 고객사의 이슈를 물어볼 때마다 참고 자료와 정리 형식을 다시 설명할 필요가 줄어듭니다.

[Customize → Agents]에서 전용 Agent를 생성해 지침과 연결 자료를 설정한 뒤 게시했습니다. 게시한 Agent는 Agents 목록에 표시됩니다.

전용 Agent의 이름은 ‘기술 이슈 분석 에이전트’로 정하고 Slack Connector와 업무 기준 Space를 연결했습니다. 업무 관련도와 우선순위뿐만 아니라 판단 근거와 필요한 조치도 출력하도록 구성했습니다.

아래는 전용 Agent의 Instruction에 입력한 판단 기준과 출력 형식 예시입니다. 업무 관련도·우선순위·판단 근거를 함께 보여주도록 작성했습니다.

[Quick에 전달한 지침 예시]

너는 기술 업무 담당자의 Slack 업무 이슈를 분석하는 에이전트야.

[참고 자료]
연결된 Space의 담당 고객사·지원 범위,
고객사별 구성, 대응규칙, 과거 작업이력을 참조해줘.

[판단]
각 이슈의 업무 관련도를 상·중·하로 표시하고
관련 있다고 판단한 근거를 한 줄로 적어줘.
확실하지 않으면 '불확실'로 표시하고 이유를 설명해줘.

[출력]
고객사 / 프로젝트 / 관련도와 근거 / 우선순위 /
상태 / 필요 조치 / Slack 원문 링크를 정리해줘.
우선순위가 높은 이슈부터 보여줘.
마지막에는 관련 없음으로 제외한 메시지 수를 표시해줘.

[동작 범위]
Slack은 읽기 전용으로 사용해줘.
관련된 새 이슈가 없으면 '오늘은 새 관련 이슈 없음'이라고 알려줘.

게시한 ‘기술 이슈 분석 에이전트’의 상세 화면에서는 저장된 지침과 함께 Slack Connector와 업무 기준 Space가 연결된 것을 확인할 수 있습니다.

화면 속 출력 형식에는 고객사·프로젝트·관련도 근거·우선순위·상태·필요 조치·Slack 원문 링크가 포함되어 있습니다. 동작 지침에는 ‘평소 질문과 당일 이슈 정리 요청을 처리하는 방법’과 ‘Slack에 글이나 댓글을 작성하지 않는 규칙’을 담았습니다.

이 구성에서 관련도와 우선순위는 별개의 항목입니다. 예를 들어 담당 고객사의 상담 요청은 관련도가 높아도 긴급하지 않을 수 있습니다. 반대로 ‘장애’라는 단어가 포함된 긴급 메시지라는 담당 여부와 지원 범위를 확인해야 합니다.

4. Routine으로 매일 오전 7시에 자동 분석

전용 Agent를 게시한 뒤 Routine의 실행 대상으로 연결했습니다. 매일 아침 직접 분석을 요청하는 대신 정해진 시간에 실행된 결과를 Feed에서 확인하도록 했습니다.

이번 Routine의 이름은 ‘일일 업무 이슈 정리’입니다. 한국 시간(Asia/Seoul) 기준 매일 오전 7시에 실행되도록 설정했습니다.

Routine에서도 Agent의 실행, 실행 시간, 분석 범위, 결과 게시 위치를 자연어로 지정할 수 있습니다. 아래는 이번 구성에 사용한 Routine 지침 예시입니다.

[Quick에 전달한 지침 예시]

'기술 이슈 분석 에이전트'를
매일 오전 7시, Asia/Seoul 기준으로 실행해줘.

세 채널의 최근 24시간 메시지를 업무 기준 Space와 대조하고
관련 이슈만 활동 Feed에 게시해줘.

Slack 메시지는 조회만 하고
분석 결과는 Feed에 게시해줘.

생성한 Routine은 [Mission control → Routines]에서 관리할 수 있습니다⁴. 이번 Routine에는 실행 대상으로 전용 Agent를 지정하고 Slack 조회와 Feed 게시에 필요한 도구를 연결했습니다.

4. AWS, Mission Control (Amazon Quick on desktop), 2026

이번 Routine 구성은 기준 자료를 Space에 업로드해 참조하는 방식입니다. 정기적인 실행 과정에서 로컬 파일을 직접 읽는 방식이라면 해당 단계에서 Desktop 앱 연결이 필요하므로 두 방식은 실행 조건이 다릅니다.

5. Feed에서 선별 결과와 근거 확인

Desktop에서 분석 결과 확인하기

Routine을 만든 뒤 Agent를 실행하고 Feed에 게시된 결과를 확인했습니다.

위 Feed에 정리된 결과는 다음과 같습니다.

구분	결과
관련 이슈	9건
운영 장애	3건
PoC 지원	2건
상담·자문·블로그	4건
관련 없음으로 제외한 메시지	16건

위 수치는 가상 업무 데이터로 실행한 결과입니다.

예를 들어 ‘ECS 배포 오류’는 과거 작업 이력을 근거로 실제 헬스체크 경로와 이미지 준비 시간을 재확인하라는 조치로 정리했습니다.

담당자는 Feed에 모인 이슈에서 우선 확인할 업무와 필요한 조치를 살펴보고 원문 링크로 대화 맥락을 확인할 수 있습니다. 여러 채널을 다시 훑기 전에 확인 대상을 좁혀 주기 때문에 아침 업무 점검에 활용할 수 있습니다. 제외 건수도 함께 표시해 필터링 범위가 적절한지 점검할 수 있도록 했습니다.

모바일 Quick 앱에서 같은 Feed 확인하기

아침에 PC를 열기 전에도 아이폰 Quick 앱에서 같은 Feed를 확인할 수 있습니다. 모바일 앱의 Feed 목록에서 ‘일일 업무 이슈 정리: 내 담당 이슈 9건’을 선택한 뒤 [See more]를 눌러 내용을 펼쳤습니다.

이렇게 매일 아침 정리된 Feed를 모바일로 확인하면 이동 중에도 전날 놓친 요청이나 출근 후 처리할 업무를 미리 점검할 수 있습니다.

적용하면서 확인한 점과 보완할 부분

운영 시 보완할 수집 기준과 사내 데이터 연동을 통한 확장 방향은 다음과 같습니다.

첫째, 오래된 스레드의 새 댓글 수집 여부를 정해야 합니다. 현재 설정은 최근 24시간 동안 작성된 본문과 그 댓글이 수집 대상이며 오래된 본문에 새로 달린 댓글은 제외합니다. 여러 날 이어지는 장애를 추적하려면 기존 스레드의 신규 활동도 확인하도록 수집 기준을 확장해야 합니다.

둘째, AWS에 보관한 사내 데이터를 Space에 연결하는 방식으로 확장할 수 있습니다. 고객사 담당 정보·계약 범위·작업 이력을 ETL로 가공해 Quick에 연결하면 로컬 문서를 매번 업로드하는 작업을 줄일 수 있습니다.

S3 버킷 접근 권한과 VPC 엔드포인트 연결을 설정⁵하면 원본 데이터 스토어를 인터넷에 공개하지 않고도 Space에 연결한 사내 데이터⁶를 업무 판단에 활용할 수 있습니다.

5. AWS, Administrator setup (Amazon S3 integration), 2026
6. AWS, Managing a space, 2026

Amazon Quick을 활용해서 Slack 이슈를 모아보는 방법 어떻게 보셨나요?
조직 업무 환경에 맞는 Amazon Quick 도입과 구성이 고민이라면 가비아 AWS에 문의해 주세요.

글쓴이

Brido(홍창섭) | 가비아 AWS 기술유닛