Slack 봇은 마감 알림이나 일일 리포트 같은 메시지를 사람 대신 정해진 채널에 자동으로 보내 주는 작은 도우미이며, 코드를 몰라도 5단계로 만들 수 있다. ① 봇이 왜 필요한가 ② Slack 앱·토큰 발급 ③ .env 설정 ④ 프롬프트로 메시지 보내기 ⑤ 실전 활용이다. 1편에서 익힌 '키는 .env에, 연결은 프롬프트로' 방식을 Slack에 그대로 적용하므로, 반복 알림을 한 번만 세팅해 두면 손 안 대고 돌아간다.

1. Slack 봇이 왜 필요한가요?

Slack 봇은 정해진 조건이 되면 메시지를 자동으로 보내 주는 프로그램으로, 사람이 매번 손으로 챙기던 알림을 대신한다. 채팅에 직접 말을 거는 챗봇이 아니라, "이런 상황이면 이 채널에 이 메시지를 보내라"는 심부름꾼에 가깝다.

업무에서는 이렇게 쓰이다.

• 마감 알림: 매일 오전 9시에 "오늘 마감 2건"을 담당 채널에 자동 발송
• 일일 리포트: 2편에서 모은 경쟁사 뉴스 요약을 아침마다 팀 채널에 게시
• 작업 완료 알림: 데이터 수집·백업이 끝나면 "완료" 메시지를 자동 전송

즉 Slack 봇은 "확인하는 걸 잊어서 놓치던 일"을 시스템이 먼저 알려 주게 만드는 자동 비서이다.

2. Slack 앱(봇) 만들고 토큰 발급하기

Slack 봇은 Slack API 페이지에서 앱을 만들고, 봇에게 메시지 보낼 권한을 준 뒤 워크스페이스에 설치하면 토큰이 발급된다. 이 토큰이 1편에서 배운 'API 키' 역할을 한다.

순서는 다음과 같다.

1. Slack API 페이지에서 'Create New App'을 눌러 앱을 만든다(From scratch 선택).
2. 'OAuth & Permissions'에서 봇 권한(Bot Token Scopes)에 chat:write를 추가한다.
3. 'Install to Workspace'로 설치하면 xoxb-로 시작하는 Bot User OAuth Token이 발급된다.
4. 메시지를 보낼 채널에 들어가 봇을 초대한다(채널에서 /invite @봇이름).

발급된 xoxb- 토큰이 곧 봇의 출입증이므로, 공개된 곳에 올리지 않다.

왜 봇 토큰을 여러 개로 쪼개 관리해야 하나

이 단계에서 스코프로 chat:write 하나만 넣는 것은 우연이 아니라 원칙이다. 봇 토큰은 사람 계정과 달리 무인으로 24시간 살아 있으므로, 유출되면 사람이 로그아웃하거나 비밀번호를 바꾸는 식의 즉각적 방어가 통하지 않는다. 그래서 "이 봇이 실제로 할 수 있는 일"을 스코프 단위로 최소화하는 것이 사실상 유일한 안전장치가 된다. 메시지만 보내는 봇에 파일 읽기·채널 관리·사용자 조회 권한까지 붙여 두면, 그 토큰이 새는 순간 피해 범위가 알림 하나가 아니라 워크스페이스 전체로 넓어진다.

용도가 늘어날수록 토큰을 하나로 키우기보다 봇을 쪼개는 편이 낫다. 마감 알림 봇, 리포트 봇, 배포 알림 봇을 각각 별도 앱으로 만들어 토큰을 분리해 두면, 어느 하나가 오작동하거나 유출돼도 나머지는 멀쩡히 돈다. 초반에는 번거로워 보이지만, 봇이 늘어난 뒤 "이 토큰이 대체 어디까지 건드릴 수 있지?"를 되짚는 비용보다 처음부터 좁게 나눠 두는 비용이 훨씬 싸다. 스코프 최소화와 봇 분리는 결국 같은 원칙: 사고가 났을 때 폭발 반경을 좁혀 두는 것: 의 두 얼굴이다.

3. .env 설정하기

발급받은 봇 토큰과 보낼 채널을 프로젝트 폴더의 .env 파일에 저장한다. 1편에서 다룬 방식 그대로이다.

SLACK_BOT_TOKEN=xoxb-발급받은-토큰
SLACK_CHANNEL=#팀-채널이름

그리고 .gitignore에 .env를 추가해 토큰이 외부로 새지 않게 한다. 이렇게 분리해 두면, 다음 단계에서 AI에게 ".env의 토큰으로 메시지를 보내라"고만 지시하면 된다.

4. 프롬프트로 메시지 보내기

키 준비가 끝나면, 실제 전송 코드는 Claude Code 같은 AI에게 프롬프트로 맡긴다. 무엇을 어느 채널에 보낼지 설명하면, AI가 .env에서 토큰을 읽어 Slack에 메시지를 보내는 코드를 만들어 준다. 예를 들어 이렇게 요청한다.

.env의 SLACK_BOT_TOKEN으로 SLACK_CHANNEL 채널에
'오늘의 업무 브리핑 ☀️'이라는 제목과 함께
오늘 마감 목록을 보기 좋게 정리해서 보내는 코드를 만들어줘.
토큰은 코드에 쓰지 말고 .env에서 읽어와.

이렇게 '보낼 내용 + 보낼 채널 + 토큰은 .env에서 읽기'를 함께 적어 주면, 봇이 정해진 채널로 메시지를 보내 준다. 한 번 동작을 확인했다면, 보낼 내용만 바꿔 다양한 알림에 재사용할 수 있다.

프롬프트에 "토큰은 .env에서 읽어"를 굳이 적는 이유

위 프롬프트의 마지막 줄 "토큰은 코드에 쓰지 말고 .env에서 읽어와"는 사족처럼 보이지만, 실무에서 가장 자주 사고가 나는 지점을 정확히 막는 문장이다. AI에게 그냥 "Slack에 메시지 보내는 코드 만들어줘"라고만 하면, 모델은 눈앞의 토큰 문자열을 코드에 그대로 박아 넣는 가장 짧은 답을 내놓기 쉽다. 그 코드를 그대로 커밋하면 토큰이 깃 히스토리에 영구히 남고, 저장소를 공개로 돌리는 순간 봇이 통째로 남의 손에 넘어간다. 프롬프트 한 줄로 이 실수를 원천 차단하는 셈이다.

여기서 더 큰 교훈은, AI 코딩에서 안전은 "생성된 코드를 나중에 검사해서" 확보되는 게 아니라 "지시문에 미리 못 박아서" 확보된다는 점이다. AI는 지시받은 만큼만 신경 쓰기 때문에, 비밀 관리·에러 처리·재시도 같은 요구사항은 결과물을 리뷰하며 뒤늦게 붙이기보다 프롬프트에 처음부터 조건으로 넣는 편이 훨씬 안정적이다. "무엇을 만들지"만 적던 프롬프트에서 "어떤 제약을 지킬지"까지 적는 프롬프트로 넘어가는 것이, 장난감 스크립트와 매일 도는 업무 봇을 가르는 실질적 경계다.

5. 실전 활용하고 한 걸음 더

이 봇을 2편의 기사 모니터링과 연결하면, 매일 아침 경쟁사 뉴스 요약을 팀 Slack으로 받아 보는 자동 리포트가 된다. "2편에서 만든 뉴스 정리 결과를 매일 오전 9시에 Slack 봇으로 보내줘"처럼 앞 편의 결과물을 그대로 이어 붙이면 된다.

매주 평일 오전 9시에 자동 실행되도록 예약해줘.
실행되면 경쟁사 뉴스 요약을 만들어 Slack 채널로 보내고,
완료되면 '발송 완료'를 콘솔에 출력해줘.

예약 실행(스케줄러)까지 맡기면 사람이 켜지 않아도 정시에 알림이 온다. 다만 자동 발송은 토큰·권한이 걸린 작업이므로, 처음 몇 번은 결과를 직접 확인한 뒤 자동화로 넘기는 것이 안전한다. 다음 ④편에서는 이 알림들과 뉴스·지표를 한 화면에 모으는 '업무 대시보드'를 만든다.

자동 알림의 진짜 함정: 무소식이 오작동일 때

자동 발송에서 초보자가 가장 늦게 깨닫는 위험은 잘못된 알림이 아니라 오지 않은 알림이다. 매일 오전 9시에 오던 리포트가 어느 날 조용하면, 사람은 "오늘은 별일 없나 보다"라고 해석하기 쉽다. 하지만 실제로는 토큰 만료, 봇이 채널에서 강퇴, API 장애, 스케줄러 중단 같은 이유로 봇이 죽어 있는데 아무도 모르는 상태일 수 있다. 알림 자동화가 신뢰를 얻을수록, 그 침묵이 위험해지는 역설이다. 그래서 본문이 권한 "처음 몇 번은 직접 확인"이라는 습관은 단순한 몸풀기가 아니라, 봇이 실패했을 때 어떤 신호를 남기는지 눈으로 익혀 두는 과정에 가깝다.

한국 실무에서 이 문제는 특히 날카롭게 다가온다. 마감·보고가 정시에 몰리는 조직 문화에서는 "9시 리포트"가 곧 하루 업무의 기준점이 되기 때문에, 그 알림이 조용히 빠지면 팀 전체의 판단이 어긋난다. 대응은 어렵지 않다. 봇이 성공했을 때뿐 아니라 실패했을 때도 관리자 개인 DM이나 별도 채널로 "리포트 생성 실패" 같은 신호를 보내도록 프롬프트에 조건을 하나 더 붙이면 된다. 결국 업무 봇의 완성도는 "잘 될 때 잘 도는가"가 아니라 "안 될 때 안 된다고 말해 주는가"에서 갈린다.

---

참고: Slack API 문서 · Claude Code 공식 문서