봇 하나가 아니라 편집국을 만들었다 — Slack 봇 기반 업무 자동화 프로세스 구축기
혼자 일하며 반복 업무를 봇 1개가 아니라 역할이 나뉜 8개 Slack 봇과 검증 루프로 구조화했다. 단일 관문 설계와 자동화가 낸 사고에서 세운 완료 판정 기준까지 기록한다.
한 줄 요약
- 혼자 일하며 반복 업무를 봇 1개가 아니라 역할이 나뉜 8개 Slack 봇과 검증 루프로 구조화한 기록이다.
Slack 봇 자동화의 핵심은 봇 개수가 아니라 단일 관문, 역할 경계, 완료 검증이라는 세 가지 프로세스 규칙이다. 이 방식은 서버에 에이전트를 상시 구동할 수 있고 최종 결정은 사람이 쥔다는 전제가 맞는 1인·소규모 환경에 적용된다. 기준 시점은 2026년 7월이고, 약 2주간의 연속 운영 로그를 근거로 정리했다.
왜 Slack을 업무의 단일 관문으로 삼았나?
책상 앞에서는 터미널로, 밖에서는 휴대폰으로 일하다 보니 봇에게 일을 시키는 입구가 계속 흩어졌다. 그래서 봇을 만들기 전에 규칙부터 세웠다. 사람도 AI도 오직 Slack 채널 1개를 통해서만 봇단에 닿는다. “어디서 일해도 같은 입구”라는 구조적 판단이 먼저였고, 봇은 그다음이었다.
단일 관문 설계는 모든 작업 요청이 하나의 Slack 채널을 거쳐서만 봇단에 도착하게 만드는 구조다(기준: 2026-07 운영 로그). 채널 뒤에는 웹호스팅 서버에서 상시 구동되는 AI 에이전트 게이트웨이가 있고, 실제 코드 작업은 그 안의 코드 실행 에이전트가 맡는다. 오케스트레이션과 실행이 나뉜 2층 구조인데, 이 글에서는 개념 수준으로만 다룬다.
작업이 시스템에 들어오는 경로는 두 갈래로 정리된다. 하나는 내가 로컬에서 직접 수정하는 경로, 다른 하나는 Slack을 거쳐 게이트웨이가 위임·실행하는 경로다. 어느 쪽이든 결과는 같은 저장소와 노트 볼트로 전파되도록 동기화 채널 3종을 뒀다. 입구가 하나이고 결과가 한곳으로 모이니, 데스크톱에서 하던 일을 모바일에서 이어받아도 흐름이 끊기지 않았다.
봇 하나가 아니라 8개 역할로 나눈 이유는 무엇인가?
봇 하나가 모든 요청을 받으면 요청 해석과 실행, 품질 판단이 한 컨텍스트에 섞인다. 그래서 개발, PM, 업무 총괄 라우팅, 디자인, 기획, 콘텐츠, 금융, 부동산의 8개 역할로 나눴다. 처음부터 8개였던 것은 아니고, 초기 5~6개 역할에서 필요가 확인될 때마다 늘려 온 결과다.
이 구조의 축은 라우터 봇의 위임 원칙이다. 라우터 봇은 전문 작업을 직접 처리하지 않고, 같은 스레드에서 담당 역할 봇을 멘션으로 호출해 넘긴다. 이때 위임 메시지에는 지시 출처, 요청 요약, 완료 기준, 주의사항 네 가지를 한 메시지에 담는다. 위임이 보고가 아니라 호출이 되려면, 받는 쪽이 되물을 필요 없는 완결된 지시여야 하기 때문이다.
역할을 늘리기만 한 것은 아니다. 블로그 전담 작가 역할을 추가했다가 기존 콘텐츠 역할과 경계가 겹쳐 전면 제거한 이력이 있다. 이때 기준이 하나 생겼다. 역할은 많을수록 좋은 것이 아니라, 담당 경계가 분명하게 그어질 때만 두는 것이다.
역할이 여덟이어도 같은 원칙으로 움직이려면 지식 구조가 받쳐야 했다. 마인드는 3계층으로 나눴다. 전 봇이 공유하는 헌법 문서 1개, 역할별 마인드, 그리고 휘발되는 세션 컨텍스트다. 충돌하면 상위 계층이 이긴다. 그리고 이 지식 전체를 봇 런타임 안이 아니라 런타임 밖의 노트 볼트에 둔다. 어느 환경에서 세션을 시작해도 같은 계약으로 부팅하게 만들기 위해서다.
위임한 일은 어떻게 “완료”가 되나?
위임된 작업의 완료 기준은 도구 호출 성공이 아니라, 작업 로그 기록과 담당 봇 본인의 read-back 확인이다. 봇이 “했습니다”라고 답하는 것과, 완료 기준을 자기 입으로 다시 읽어 확인하는 것은 다르다. 실제로 한 위임 스레드에서 선행 과제 4건을 점검했을 때 read-back이 확인된 것은 1건뿐이었고, 나머지 3건은 미완료로 판정했다.
이 기준 뒤에는 “실행되는 것”과 “보이는 것”은 다른 레이어라는 원칙이 있다. 일이 내부적으로 돌아가는 상태와, 내가 그 진행을 눈으로 확인할 수 있는 상태는 별개이고 둘 다 보장해야 한다. 위임이 채널에 보이지 않는 내부 작업 큐로 먼저 실행된 적이 있었는데, 결과적으로 일은 돌았지만 나는 그 사실을 볼 수 없었다. Slack에 보이는 경로로 다시 위임했고, 이후 위임은 채널에서 확인 가능한 형태를 기본으로 삼았다.
실제로 무엇이 자동화됐나?
이 기간에 확인된 자동화는 5종이다. 블로그 파이프라인, 소스 자동 업로드, 세션 작업로그, 트렌드 수집, 성장루프 스케줄 작업. 이 중 대표 사례는 블로그 편집국 파이프라인이고, 발행 버튼만은 끝까지 사람 몫으로 남겼다.
편집국 파이프라인은 브리프, 리서치, 원고, 품질 점수 게이트, 비주얼, QA의 6단계로 구성된다. 품질 게이트는 점수표 기반으로 총점 80점 미만이면 반려하고 재작성으로 돌려보낸다. 이 파이프라인은 실전에서 최소 4건을 완주했다. 한 글은 86점으로 조건부 통과 판정을 받아 보완 후 진행됐고, 다른 글은 이미지 11컷이 QA를 전컷 통과했다. 반려와 조건부 통과가 실제로 발생한다는 것이 이 게이트가 장식이 아니라는 근거다.
다만 “봇 8개가 모든 일을 알아서 처리한다”는 그림은 사실이 아니다. 파이프라인이 만드는 것은 발행 직전 패키지까지이고, 발행은 내가 전담한다. 무인 발행은 금지다. 사람 게이트가 남아 있는 것은 자동화가 덜 된 결함이 아니라, 공개 표면에 나가는 최종 결정을 사람이 쥐겠다는 설계다.
보조 사례로는 세션 자동 작업로그가 있다. 작업 세션이 끝날 때마다 로그가 남도록 훅을 걸었고, 강제 종료로 로그가 유실되는 경우를 대비해 안전장치를 3겹으로 뒀다. 기록이 자동으로 쌓여야 다음 세션의 봇이 이어받을 수 있기 때문에, 이 로그는 부산물이 아니라 시스템의 전제다.
자동화가 낸 사고에서 무엇을 배웠나?
앞의 완료 기준들은 머리로 세운 것이 아니라 사고에서 나왔다. 대표적인 두 건이 지금 규칙의 출처다. 하나는 중복 업로드 사건이고, 다른 하나는 “완료” 오보고 사건이다.
첫 번째는 중복 업로드 사건이다. 자동 업로드 결과에 같은 소스가 2건씩 올라와 있었다. 처음에는 크론이 중복 실행됐다고 의심했지만, 파고들자 진단이 뒤집혔다. 크론은 한 번씩만 돌았고, 로컬 크론과 서버 에이전트라는 두 업로더가 각자 1건씩 올린 것이 원인이었다. 같은 산출물의 소유권을 두 주체가 나눠 갖고 있었던 것이다. 중복 방지 로직이 있긴 했지만 최근 몇 건만 훑는 방식이라 업로드가 늘자 조용히 뚫렸고, 실패했다는 신호조차 없었다. 여기서 배운 기준은 이렇다. 같은 산출물의 소유권을 하나로 단일화하는 것이, 스키마나 중복 방지 로직으로 방어하는 것보다 우선이다.
두 번째는 “API 성공은 완료가 아니다”라는 기준을 만든 사건이다. 스키마가 맞지 않는 문서가 업로드되면서 목록 화면에는 보이지 않는 유령 문서가 만들어졌는데, 봇은 “업로드 완료”라고 보고했다. API가 성공 응답을 돌려줬기 때문이다. 완료 보고를 받고도 실제 화면에서 결과를 찾지 못한 뒤, 기준을 바꿨다. 완료 보고는 사용자가 보는 표면에서 재조회로 확인한 뒤에만 한다. 도구 호출의 성공 응답은 완료의 필요조건일 뿐, 충분조건이 아니다.
두 사건의 공통점은 자동화 자체가 아니라 “완료를 무엇으로 판정하는가”가 뚫렸다는 점이다. 검증 루프가 자동화의 반쪽이라고 쓴 이유가 여기에 있다. 실행을 늘리는 만큼 판정 기준을 세우지 않으면, 자동화는 사고를 더 빠르게 반복하는 장치가 된다.
한계와 업데이트 예정
이 글은 2026년 6월 말부터 7월 초까지 약 2주간의 운영 기록이다. 이 구조가 Slack 봇 자동화의 정답이라는 뜻은 아니고, 1인 환경에서 단일 관문·역할 경계·완료 검증이라는 규칙이 유효했다는 사례에 가깝다. 절감된 시간이나 비용 같은 효과 수치는 측정한 적이 없어 다루지 않았다. 역할 구성과 게이트 기준도 계속 바뀌는 중이므로, 이 글의 숫자는 작성 시점의 스냅숏으로 읽는 것이 맞다.
이후에는 read-back 기반 검증 루프를 어떻게 고도화했는지, 편집국 파이프라인의 반려·재작성이 실제 원고 품질을 어떻게 바꿨는지를 공개 가능한 범위에서 이어서 쓸 예정이다.