Slack Engineering

Slack 엔지니어링 팀이 AI 에이전트를 E2E 테스트 자동화에 적용한 실험 결과를 공유한다. 200회 이상의 자동화 실행으로 신뢰성·속도·비용을 정량 측정해, 기존 결정론적 테스트와 에이전트 기반 테스트가 각각 어느 단계에 적합한지 구분했다.

단일 AWS SageMaker/Bedrock 인프라에서 GPU 부족, 모델 출시 지연, 공급자 단일 장애점 문제가 누적.

Slack의 EMR 데이터 파이프라인은 700개 이상 Airflow SSH 작업에 의존해 보안 표면, 키 관리, 장애 복구, 관측성이 모두 취약했다.

장시간 실행되는 다중 agent 보안 조사는 수백 번의 추론과 대량 출력으로 context window가 넘치고 판단이 흐려질 수 있었다.

Slack은 HTTP/3 전환 과정에서 QUIC 기반 엔드포인트를 클라이언트 관점에서 측정할 관측성이 부족했다.

Slack의 기존 알림 시스템은 데스크톱과 모바일 설정 모델이 달라 사용자가 알림 동작을 예측하기 어려웠다.

보안 온콜은 매일 대량의 이벤트와 탐지 알림을 검토해야 하며, 단일 프롬프트 기반 에이전트는 조사 품질이 들쭉날쭉했다.

Slack Android 앱의 VPAT 과정에서 TalkBack 오류 안내, heading, 목록 개수, drag-and-drop 등 접근성 문제가 반복 확인됐다.

Quip과 Slack Canvas 백엔드 빌드가 60분 걸렸고, Python 백엔드와 TypeScript 프론트엔드 빌드가 강하게 결합돼 캐시가 거의 무효화됐다.

Slack의 단일 production Chef 환경은 신규 EC2 노드가 깨진 cookbook을 즉시 받아 대규모 scale-out 때 전체 장애로 번질 위험이 있었다.