슬랙 점심 주문 요약 봇.

01 · PROBLEM

점심 주문 하나에 시트와 스크립트가 동원되는 풍경

격주로 돌아오는 패치 주간이면 슬랙 점심 주문 채널에 메뉴 메시지가 올라오고, 팀원들은 숫자 이모지 reaction으로 메뉴를 고릅니다. 문제는 그 다음이었습니다.

시트로 나갔다가 슬랙으로 돌아오는 우회로 — 기존에는 Google Apps Script가 reaction을 긁어 스프레드시트에 집계했는데, 누군가 시트를 열어 스크립트를 수동 실행하고, 그 결과를 다시 슬랙에 손으로 옮겨 적어야 했습니다. ‘자동화’라고 부르기엔 사람 손이 세 번 들어가는 구조였습니다.

코드에 노출된 사용자 토큰 — 더 큰 문제는 보이지 않는 곳에 있었습니다. 그 Apps Script에는 개인 사용자 토큰이 평문으로 박혀 있었습니다. 점심 주문용 스크립트가 사실은 한 사람의 슬랙 권한 전체를 들고 돌아가는 보안 리스크였던 셈입니다.

02 · APPROACH

슬랙 안에서 시작해서 슬랙 안에서 끝나게

작은 도구일수록 동선이 전부라고 판단했습니다. 시트라는 우회로를 없애고, 주문이 일어나는 바로 그 자리 — 메시지와 쓰레드 — 에서 모든 것이 끝나는 구조를 목표로 했습니다.

클릭 한 번의 UX — 주문 메시지의 메뉴에서 “주문 요약하기”를 누르면, 몇 초 뒤 같은 메시지 쓰레드에 메뉴별로 그룹핑된 요약이 댓글로 달립니다. 누가 눌러도 되고, 배울 것도 없습니다.

상태 없는 서버리스 설계 — 외부 DB도, 큐도, 영구 저장소도 두지 않았습니다. Cloudflare Worker 하나가 reaction을 읽어 요약을 만들고, 결과는 슬랙 쓰레드 자체에 남습니다. 관리할 인프라가 없으니 운영 비용도 0에 수렴합니다.

보안 정상화 — 개인 사용자 토큰 대신 최소 권한 scope 3개만 가진 전용 Bot 토큰을 발급하고, 토큰은 코드가 아닌 Cloudflare Secret으로 관리하도록 바꿨습니다. 기존에 노출돼 있던 사용자 토큰은 폐기를 안내했습니다.

03 · BUILD

작지만 제대로 — 704줄짜리 정석

흐름은 단순합니다: 메시지 단축키 클릭 → Slack이 Worker로 payload 전송 → 서명 검증 후 즉시 ACK → 백그라운드에서 reaction·사용자 정보 조회 → 메뉴별 요약을 쓰레드에 답글.

작은 프로젝트지만 구조는 큰 시스템과 같은 기준으로 잡았습니다.

• 순수 함수 분리 + TDD — 메뉴 파싱·요약 포맷과 HMAC 서명 검증을 순수 함수로 분리하고 테스트부터 작성했습니다. 텍스트 이모지 코드와 유니코드 혼용, 빈 reaction 같은 엣지 케이스가 모두 테스트로 고정되어 있습니다.
• Slack 보안 요건 준수 — signing secret 기반 HMAC 서명 검증으로 위조 요청을 차단하고, Slack의 3초 응답 제한은 즉시 ACK 후 백그라운드 처리로 해결했습니다.
• 스펙 주도 개발 — 이 규모의 봇도 설계 스펙 → 구현 플랜 → 커밋 단위 구현의 동일한 프로세스로 만들었습니다. 전체 src+test 약 700줄, 커밋 14개.

04 · IMPACT

우회로 하나가 통째로 사라지다

3단계 수작업 → 클릭 1번 — 시트 열기, 스크립트 실행, 결과 옮겨 적기가 메시지 단축키 하나로 대체됐습니다. 주문이 모이는 자리에서 요약까지 끝나니, 결과를 찾으러 갈 곳 자체가 없어졌습니다.

보안 리스크 제거 — 코드에 평문 노출돼 있던 개인 사용자 토큰을 최소 권한 Bot 토큰 + Secret 관리 체계로 교체했습니다.

운영 비용 0의 상시 서비스 — 서버리스 + 무상태 설계로, 배포 이후 관리·비용 부담 없이 패치 주간마다 돌아가는 도구가 됐습니다.

05 · LEARNINGS

자동화 감각은 규모를 가리지 않는다

보이스 워크플로우 시스템이 ‘파이프라인 전체를 다시 설계하는’ 프로젝트였다면, 이 봇은 정반대 끝에 있는 프로젝트입니다 — 모두가 패치 주간마다 겪지만 아무도 문제라고 부르지 않던 마찰을 발견하고, 하루 만에 치우는 일.

작은 도구에서 배운 것이 오히려 선명했습니다. 첫째, 불편은 익숙해지면 보이지 않는다 — 시트를 여는 30초, 결과를 옮겨 적는 1분은 누구도 개선 요청을 올리지 않는 비용이지만, 패치 주간마다 전원이 지불하고 있었습니다. 둘째, 작은 자동화일수록 동선이 전부다 — 기능이 같아도 ‘슬랙 밖으로 나가야 하는 도구’와 ‘쓰레드 안에서 끝나는 도구’는 채택률이 다릅니다. 셋째, 규모가 작다고 기준을 낮출 이유는 없다 — 서명 검증, 최소 권한, 테스트로 고정한 엣지 케이스 같은 기본기는 700줄짜리 봇에서도 그대로 적용했고, 그 덕에 배포 후 손 갈 일이 없는 도구가 됐습니다.

큰 시스템을 설계하는 안목과 일상의 마찰을 줄이는 감각은 결국 같은 근육이라는 것 — 이 작은 프로젝트가 남긴 확신입니다.