AI가 Slack 동료에게 메시지 보내기 전에 정해야 할 제품 규칙

AI가 Slack 동료에게 메시지를 보내는 기능은 기술적으로 어렵지 않다. ChatGPT나 사내 에이전트에 Slack connector를 붙이면 특정 사람에게 질문하고, 승인 요청을 보내고, 작업 진행 상황을 공유할 수 있다. 문제는 사람들이 그 방식을 좋아하느냐다. OpenAI 공동창업자 Greg Brockman은 “많은 사람이 ChatGPT를 Slack에 연결하지만, 동료의 ChatGPT가 대신 연락해 도움을 요청하는 것을 좋아하지 않는다”고 말했다.

이 관찰은 제품팀에 중요하다. 사용자는 같은 일을 사람 동료가 부탁하면 기꺼이 도와줄 수 있지만, AI가 중간에 들어오면 감정적 비용과 책임 구조가 달라진다. AI가 시간을 아껴주는 도구가 아니라 인간관계를 가로막는 레이어처럼 느껴질 수 있다.

왜 사람들은 AI 대리 연락을 불편해하나

첫 번째 이유는 의도가 불명확하기 때문이다. 동료가 직접 “이거 봐줄 수 있어요?”라고 하면 맥락과 우선순위를 대략 알 수 있다. 하지만 AI가 “사용자를 대신해 요청합니다”라고 보내면 이 일이 정말 급한지, 사람이 읽었는지, 거절해도 되는지 헷갈린다.

두 번째 이유는 책임 경로가 흐려진다. 잘못된 요청을 받았을 때 누구에게 물어봐야 하나. AI에게 답하면 실제 동료가 볼까. 내가 답한 내용이 모델 학습이나 로그에 남을까. 이런 질문이 생기면 사람은 협업보다 방어를 먼저 생각한다.

세 번째 이유는 관계의 미묘함이다. 조직의 협업은 정보 전달만으로 돌아가지 않는다. 말투, 타이밍, 상대의 바쁨, 이전 맥락, 신뢰가 섞인다. AI가 이 층위를 모른 채 DM을 보내면 같은 요청도 무례하게 느껴질 수 있다.

기본값은 ‘AI가 초안 작성, 사람이 전송’이어야 한다

AI가 메시지를 직접 보내는 기능을 만들 때 가장 안전한 기본값은 draft mode다. AI는 요청 초안을 쓰고, 사용자가 검토한 뒤 직접 보낸다. 이 방식은 시간 절약 효과를 유지하면서도 인간관계와 책임을 사람에게 남긴다.

예를 들어 에이전트가 빌드 실패 원인을 찾다가 백엔드 담당자에게 확인이 필요하다고 판단할 수 있다. 이때 바로 DM을 보내지 말고 “OO님에게 이렇게 물어보면 됩니다”라는 초안을 만든다. 사용자는 문장을 고치고, 긴급도를 조정하고, 필요하면 보내지 않을 수 있다.

자동 전송은 예외로 둬야 한다. 이미 팀이 합의한 운영 알림, CI 실패 요약, 온콜 escalation, 정해진 승인 요청처럼 규칙이 명확한 경우에만 허용한다. 그 외에는 사람이 send 버튼을 누르는 것이 낫다.

자동 연락을 허용할 때 필요한 조건

첫째, 발신 주체가 명확해야 한다. 메시지에는 “AI가 자동으로 보냄”보다 “OO님이 설정한 에이전트가 보냄”처럼 소유자가 보여야 한다. 수신자는 이 요청이 누구의 업무 맥락인지 알아야 한다.

둘째, 거절 경로가 있어야 한다. “지금 처리할 수 없으면 무시해도 됩니다”, “긴급하지 않으면 내일 답변해도 됩니다”, “잘못된 요청이면 이 스레드에 stop이라고 남겨주세요” 같은 선택지를 제공해야 한다. AI 요청은 사람에게 압박처럼 느껴지기 쉽다.

셋째, 메시지 길이와 빈도를 제한해야 한다. 에이전트가 작은 의문마다 동료에게 묻기 시작하면 Slack은 금방 오염된다. 한 작업에서 외부 DM은 최대 1회, 같은 사람에게 하루 최대 N회, 업무시간 외 전송 금지 같은 제한이 필요하다.

넷째, 감사 로그와 미리보기가 있어야 한다. 사용자는 자신의 AI가 누구에게 어떤 내용을 보냈는지 확인할 수 있어야 한다. 조직 관리자는 남용 패턴을 볼 수 있어야 하지만, 민감한 DM 내용을 무차별적으로 노출해서는 안 된다.

좋은 메시지와 나쁜 메시지

나쁜 메시지는 이렇게 생겼다. “안녕하세요. 이 작업을 도와주세요. 자세한 내용은 아래를 참고하세요.” 발신 의도도 없고, 긴급도도 없고, 거절 방법도 없다. 수신자는 왜 자신이 받았는지 모른다.

좋은 메시지는 더 구체적이다. “OO님이 진행 중인 결제 리팩터링에서 subscription_status enum 기준을 확인하려고 합니다. 제가 찾은 문서는 2026-07 API schema인데, 최신 기준이 맞을까요? 긴급도는 낮고, 내일 오전까지 답변이면 충분합니다. 이 요청이 잘못 갔으면 무시하셔도 됩니다.”

핵심은 AI가 사람처럼 굴어야 한다는 뜻이 아니다. 오히려 AI임을 숨기지 않고, 소유자·맥락·기한·거절권을 분명히 줘야 한다.

작은 팀에서 시작하는 방법

작게 시작하려면 자동 DM부터 만들지 않는다. 먼저 AI가 작성한 메시지 초안을 작업 로그나 개인 inbox에 남기게 한다. 사용자가 하루 동안 어떤 초안이 유용했고 어떤 초안이 불필요했는지 표시하면, 그 다음에만 특정 유형을 자동화 후보로 올린다. 예를 들어 “CI 실패 후 담당 채널에 원인 요약”은 자동화 가치가 높지만, “막힌 부분을 아무 동료에게 질문”은 관계 비용이 크다.

또한 전송 전 preview 화면에는 원문 prompt보다 사람이 읽을 요약을 보여줘야 한다. 요청 이유, 수신자 선택 근거, 포함된 민감 정보, 전송 후 기대 행동을 한 화면에서 확인하게 만들면 사용자가 책임 있는 결정을 하기 쉽다.

제품 설계 기준

Slack, Discord, Teams 같은 협업 도구에 AI를 붙일 때는 기능 출시 전에 정책을 먼저 써야 한다. 어떤 상황에서 자동 전송이 가능한가. 누가 enable할 수 있는가. 수신자는 opt out할 수 있는가. 메시지 내용은 어디에 저장되는가. 실패하거나 오해가 생기면 누가 책임지는가.

또한 channel message와 DM을 다르게 봐야 한다. 공개 채널 알림은 팀 전체가 맥락을 공유하고 교정하기 쉽다. DM은 더 침습적이고 관계 비용이 크다. 따라서 자동화는 채널부터 시작하고, DM은 opt-in과 강한 제한을 두는 편이 좋다.

실행 체크리스트

• 기본값은 AI draft, 사람 send로 둔다. 자동 전송은 합의된 운영 알림에만 허용한다.
• 메시지에는 소유자, 맥락, 필요한 답변, 긴급도, 거절 방법을 포함한다.
• DM 자동 전송은 opt-in으로 두고, 사람별/작업별 빈도 제한을 둔다.
• 업무시간 외 전송, 반복 ping, 민감 정보 포함 메시지는 기본 차단한다.
• 사용자가 자신의 에이전트가 보낸 메시지 로그를 볼 수 있게 한다.
• 수신자가 opt out하거나 신고할 수 있는 경로를 제공한다.
• 공개 채널 자동화와 DM 자동화를 같은 위험도로 보지 않는다.

출처: Greg Brockman 공개 발언, Slack/협업 도구 기반 AI 에이전트 운영 경험, 기업용 AI assistant 제품 설계 패턴.