ODW #8: Slack MCP로 사고 대응과 FAQ 생성 작업 속도를 높이는 실습형 사내 워크숍 후기 (새 탭에서 열림)

Slack에 축적된 문의와 사고 대응 정보는 중요하지만, 문서화가 늦어지거나 담당자별 품질 차이로 지식 자산화가 어려웠다. 이 글은 사내 인증 기반 Slack MCP와 Confluence·Jira MCP를 결합해 FAQ, 사고 상황 요약, 인시던트 리포트를 자동 생성하는 워크숍 사례를 소개한다. 핵심은 기술 설명보다 실제 업무를 직접 자동화해 보고, 검증된 프롬프트를 스킬로 만들어 조직 전체에서 재사용하는 데 있다.

Slack 정보의 구조화 격차

• Slack에는 사고 대응, 문의, 프로젝트 논의 등 실시간 업무 정보가 축적된다.
• 그러나 문서화가 본업에 밀리거나 담당자에 따라 기록 품질이 달라진다.
• 그 결과 중요한 정보가 Slack 스레드에 묻혀 재검색과 재활용이 어려워진다.
• FAQ, 사고 보고서, 진행 상황 보고서 형태로 Confluence나 Jira에 정리할 필요가 있다.

Slack MCP 도입과 워크숍 목표

• 사내 Slack MCP는 사내 인증과 연동되어 개인 토큰이나 복잡한 OAuth 설정 없이 Slack 정보에 접근할 수 있다.
• 새로운 도구의 도입을 막는 요인은 다음과 같다.
  • 업무 중 별도로 학습할 시간 부족
  • 설정과 활용에 대한 심리적 부담
  • 사내 정보 확산의 지연
• 워크숍은 Slack MCP가 공개된 직후 빠르게 열어 참가자의 관심을 실습으로 연결했다.
• 목표는 깊은 기술 지식 전달보다 참가자가 당일부터 업무에 활용할 수 있게 만드는 것이었다.

Slack MCP의 주요 기능과 확장성

• Slack MCP는 다음 기능을 제공한다.
  • 메시지와 스레드 조회
  • 메시지 게시 및 액션 실행
  • 채널과 멤버 조회
  • 메시지 검색
• Confluence MCP와 결합하면 프로젝트 보고서나 FAQ를 자동 생성하고 게시할 수 있다.
• Jira MCP와 결합하면 Slack 논의를 바탕으로 작업 티켓을 만들 수 있다.
• 워크숍에서는 먼저 AI에게 Slack 채널에 “Hello”를 게시하게 하여 MCP의 동작을 직접 체험하게 했다.

문의 대응 내용을 FAQ로 변환

• Slack 문의 채널의 대화를 검색해 FAQ 형식의 마크다운으로 변환했다.
• 기존 Confluence FAQ와 대조해 이미 문서화된 내용은 제외했다.
• 생성된 내용을 Confluence 하위 페이지로 게시하고, 증상·해결책·원인 구조의 표로 정리했다.
• 활용 흐름은 다음과 같다.
  • 문의 채널과 Confluence 페이지 지정
  • ‘문의’를 포함한 최신 스레드 검색
  • 기존 FAQ와 중복 여부 확인
  • 신규 문의만 FAQ 파일로 생성
  • Confluence에 게시
• 이를 통해 반복 문의를 지식 베이스로 축적하고 담당자별 답변 품질 차이를 줄일 수 있다.

사고 상황 요약과 인시던트 리포트 생성

빠른 상황 파악

• “시스템 장애 내용 및 상황을 정리해줘”와 같은 자연어 지시로 Slack 스레드를 검색한다.
• AI는 해결 상태, 고객 영향, 담당자별 조치, 장애 타임라인을 요약한다.
• 예를 들어 장애 감지 시각, 원인 파악 시각, 대응 완료 시각을 한눈에 정리할 수 있다.
• 매니저가 중간에 합류하거나 담당자에게 직접 묻기 전에 전체 상황을 파악할 수 있어 의사 결정이 빨라진다.

인시던트 리포트 자동 작성

• 사전에 정한 형식에 따라 발생 시각, 감지 시각, 장애 기간, 원인, 영향 범위, 대응 내용을 자동 구조화한다.
• 데이터베이스 커넥션 풀 고갈이나 설정 변경 누락 같은 원인과 사용자 수, 영향 기능, 데이터 손실 여부 등을 보고서에 포함할 수 있다.
• 사고 대응 중에는 현황 요약을, 대응 완료 후에는 공식 리포트를 생성하는 식으로 목적에 맞게 활용한다.

정확도와 리뷰를 높이는 방법

• Slack의 모든 정보를 그대로 사용하지 말고 분석 범위를 먼저 좁혀야 한다.
  • 기존 Confluence 문서와 중복 제거
  • 특정 리액션이 달린 메시지만 선택
  • 특정 채널이나 기간, 키워드로 검색 범위 제한
• AI가 생성한 결과를 그대로 공개해서는 안 된다.
  • 개인정보 포함 여부 확인
  • 원본 스레드 출처 표시
  • 원래 발언을 과도하게 해석하지 않았는지 검토
• 실제 실습에서도 원본 스레드의 의도와 FAQ 내용이 미묘하게 달라지는 사례가 있어 사람의 리뷰가 필요함을 확인했다.
• “증상·해결책·원인 세 칼럼의 표로 작성”처럼 출력 형식을 구체적으로 지정하면 팀 문서 표준에 맞는 결과를 얻기 쉽다.

재사용 가능한 스킬 설계

• 반복 작업은 스킬로 저장해 프롬프트를 매번 다시 작성하지 않도록 했다.
• 워크숍에서 사용한 스킬은 다음 네 가지다.
  • slack-to-faq: Slack 스레드에서 FAQ 생성
  • faq-to-confluence: FAQ를 Confluence에 게시
  • slack-incident-status: 사고 상황 요약
  • slack-incident-report: 인시던트 리포트 생성
• 스킬 제작 과정은 다음과 같다.
  • 수동으로 여러 프롬프트를 실험
  • 효과적인 지시와 출력 형식 기록
  • 재사용 가능한 스킬로 정의
  • 팀에 공유하고 피드백을 반영해 개선
• 이를 통해 워크숍 참가자가 같은 절차를 재현하고, 팀 전체가 일관된 품질의 결과를 얻을 수 있다.

워크숍 운영에서 얻은 교훈

• 신기술이 등장해 관심이 높은 시점에 빠르게 교육을 제공하면 학습 참여를 높일 수 있다.
• “Hello” 게시처럼 단순한 성공 경험부터 시작한 뒤 FAQ 생성과 사고 대응으로 난도를 높이는 단계적 구성이 효과적이다.
• 일반적인 기능 소개보다 문의 대응과 장애 대응처럼 실제로 시간이 많이 드는 업무를 주제로 삼아야 활용 가능성을 쉽게 체감할 수 있다.
• 기술 자체보다 참가자가 직접 손을 움직여 자신의 업무에 적용해 보는 경험이 현장 정착에 중요하다.

실무에서는 Slack MCP를 전사적으로 한꺼번에 도입하기보다, 반복 문의나 인시던트 보고처럼 효과를 측정하기 쉬운 업무부터 시작하는 것이 좋다. 원본 출처와 사람의 검토 절차를 반드시 포함하고, 검증된 작업 흐름은 스킬로 표준화해 점진적으로 확산하는 방식이 적절하다.