Slack 기반 QA 자동화

Slack 요청 한 줄이
분석, 수정, 배포까지.

QA 채널에 남긴 요청을 에이전트가 읽고, 코드를 고치고, 개발환경에 배포해 검수를 요청합니다. 담당자는 Slack 버튼 하나로 운영 배포를 승인합니다. 문구 · 스타일 · 소규모 로직 수정이 개발자 큐에 쌓이지 않습니다.

  • Claude · Codex 에이전트
  • GitHub 계정 연동
  • 여러 Slack 워크스페이스
qa-commerce-web스레드
지

지은 (QA)10:02

/qa 로그인 버튼이 모바일에서 잘림

메인트리앱10:02

#128 접수 · 로그인 버튼이 모바일에서 잘림

분석을 시작합니다. 결과는 이 스레드에 남겨요.

메인트리앱10:04

처리 가능 · 작업 시작

LoginButton 의 고정 너비를 최소 너비로 바꾸고, 375px 이하 브레이크포인트를 추가합니다.

메인트리앱10:11

작업 완료 · 검수 요청

개발환경 배포됨 → dev.commerce.example.com

운영 배포 승인 반려
민

민수 (담당자)10:15

✅ 운영 배포를 승인했습니다

메인트리앱10:17

운영 배포 완료

main 에 머지 · 배포 성공. 태스크 #128 을 닫습니다.

요청이 Slack 에 흩어진다

버그 · 개선 요청이 채널 곳곳에 남아 누가 무엇을 처리 중인지 추적하기 어렵습니다.

작은 수정이 큐에 쌓인다

문구 하나, 여백 하나도 개발자 손을 거쳐야 해서 처리까지 며칠이 걸립니다.

사이클이 사람을 여러 번 거친다

요청 → 수정 → 배포 → 검수가 매번 다른 사람의 손에서 멈추고, 관리자는 처리량을 정량적으로 보기 어렵습니다.

작동 방식

요청부터 운영 배포까지, 네 단계

모든 단계가 하나의 Slack 스레드에 기록되고, 웹 대시보드에서 같은 흐름을 실행 로그와 함께 볼 수 있습니다.

  1. 01

    Slack 에서 요청

    QA 채널에서 /qa 로그인 버튼이 모바일에서 잘림 처럼 한 줄만 남기면 접수됩니다. 요청은 스레드로 묶여 이후 진행 상황이 같은 자리에 쌓입니다.

  2. 02

    에이전트가 분석하고 수정

    프로젝트 위키와 요청문을 읽고 처리 가능 여부를 먼저 판단합니다. 불가하면 사유를 회신하고, 가능하면 격리된 브랜치에서 코드를 고치고 커밋합니다.

  3. 03

    개발환경 배포 · 검수 요청

    개발 브랜치에 머지하고 배포 명령을 실행한 뒤, 검수 링크와 함께 [운영 배포 승인] [반려] 버튼을 스레드에 올립니다.

  4. 04

    승인하면 운영 배포

    담당자가 버튼을 누르면 운영 브랜치에 머지하고 운영 배포를 실행합니다. 사람이 승인하기 전에는 운영에 아무것도 반영되지 않습니다.

queuedtriagingin_progressawaiting_reviewapproveddeployingdeployed· 불가 판정이나 반려는 rejected 로 끝납니다

기능

QA 팀과 개발팀이 같은 화면을 봅니다

Slack 은 요청과 검수의 자리, 웹은 설정과 기록의 자리입니다. 둘은 같은 데이터를 봅니다.

슬래시 커맨드 접수

/qa <요청>, /qa form, /qa status. 프로젝트 설정에서 채널을 고르면 봇이 들어가고, 채널에서 초대해도 연결할 프로젝트를 골라 이어 줍니다.

자동 triage

처리 가능 · 불가를 먼저 가르고, 불가 사유와 계획을 스레드로 회신합니다. 사람 큐에 쌓이지 않습니다.

GitHub 연동 · 브랜치 격리

GitHub 계정을 연동해 저장소를 고르면 태스크마다 브랜치를 만들고 개발 → 운영 브랜치로 단계 머지합니다.

Slack 에서 검수 · 승인

검수 링크, 승인 · 반려 버튼, 반려 사유 모달까지 Slack 안에서 끝납니다. 스레드 댓글은 태스크 타임라인에 남습니다.

웹 대시보드 · 실행 로그

칸반과 리스트로 진행 상황을 보고, 에이전트 실행 로그와 배포 이력을 단계별로 확인합니다.

위키 · 보고서 · 통계

프로젝트 위키가 에이전트 프롬프트에 주입되고, 기간별 보고서와 일 · 주 · 월 처리량 통계를 제공합니다.

역할

세 가지 역할, 분명한 권한

  • Admin 최종 관리자

    전체 프로젝트 통계, 워커 상태, Slack 워크스페이스 연결과 사용자 권한을 관리합니다.

  • Manager 프로젝트 담당자

    저장소 · 배포 · 위키를 설정하고, 검수 요청을 확인해 운영 배포를 승인하거나 반려합니다.

  • Member QA 요청자

    Slack 이나 웹에서 요청을 남기고 진행 상황을 확인합니다. 설정은 건드리지 않습니다.

안전장치

자동화하되, 운영은 사람이 결정합니다

  • 승인 전 운영 미반영

    운영 배포는 반드시 담당자가 Slack 버튼이나 웹에서 승인한 뒤에만 실행됩니다.

  • 브랜치 격리

    태스크마다 별도 브랜치와 worktree 에서 작업합니다. 위키의 수정 금지 영역은 에이전트 프롬프트에 함께 들어갑니다.

  • 비밀값 암호화

    GitHub 토큰과 환경 변수 파일은 AES-256-GCM 으로 암호화해 저장하고, 브라우저로는 내려보내지 않습니다.

  • Slack 서명 검증

    모든 Slack 요청은 서명과 타임스탬프를 검증합니다. 워크스페이스마다 토큰이 분리됩니다.

  • 워커 상태 감시

    heartbeat 가 끊긴 워커의 태스크는 자동으로 재큐잉됩니다. 동시 처리 상한을 프로젝트별로 둡니다.

시작하기

설정은 세 번이면 끝납니다

  1. 1

    Slack 에 메인트리 추가

    관리자 화면에서 Slack에 추가를 누르고 워크스페이스를 승인합니다. 여러 워크스페이스를 붙일 수 있습니다.

  2. 2

    GitHub 계정 연동 · 저장소 선택

    본인 GitHub 계정을 연결하고 organization 과 저장소, 개발 · 운영 브랜치와 배포 명령을 고릅니다.

  3. 3

    채널에 봇 초대

    프로젝트 설정에서 채널을 고르면 봇이 바로 들어갑니다. 채널에서 /invite @maintly 를 먼저 해도 어느 프로젝트에 연결할지 물어보고 이어 줍니다.

다음 QA 요청부터 메인트리에게 맡겨 보세요

접수 → triage 회신까지 몇 분, 처리 가능한 요청은 검수 링크까지 자동으로. 운영 배포는 여전히 당신의 승인으로.