AI 업무 자동화란? — Slack·Obsidian·AI 에이전트로 반복 업무를 구조로 바꾸기

AI 업무 자동화란, 사람이 반복하던 요청 분류·요약·기록·알림·문서화를 AI 에이전트와 Slack·Obsidian 같은 업무 도구가 대신 수행하도록 연결하는 방식이다.핵심은 도구 개수가 아니라 수집 → 분류 → 실행 → 기록 → 개선의 흐름을 하나의 구조로 고정하는 데 있다. 1인 사업자와 소규모 팀이 반복 업무를 줄이고 그 과정을 지식으로 남길 때 가장 효과가 크다.

_{업데이트 2026-07-26 · 적용 대상: 1인 사업자·소규모 팀·1인 개발자 · 다루는 도구: Slack · Obsidian · AI 에이전트 · MCP · Cloudflare · Firebase}

나는 "엄코딩"이라는 이름으로 웹·앱·AI 자동화를 혼자 만들고 운영한다. 이 페이지는 그동안 실제로 돌린 자동화 시스템을 하나의 지도로 묶은 허브다. 개념만 늘어놓은 소개가 아니라, 각 단계마다 내가 직접 겪고 기록한 글로 이어지도록 엮었다. 반복 업무를 어디서부터 구조로 바꿀지 고민한다면 위에서 아래로 읽어도 되고, 관심 있는 단계의 카드만 눌러 실물 사례로 바로 건너가도 된다.

AI 업무 자동화란 무엇인가?

사람이 반복하던 요청 분류·요약·기록·알림·문서화를 AI 에이전트와 업무 도구가 대신 처리하도록 연결한 구조다. 여기서 중요한 건 자동화된 작업의 개수가 아니라 흐름이다. 요청이 들어오는 입구를 하나로 모으고, 그 요청을 역할에 맞게 나누고, 실행하고, 결과를 기록하고, 다시 고치는 다섯 박자가 끊기지 않게 이어질 때 비로소 "구조"가 된다.

나는 이걸 봇 1개로 시작하지 않았다. 책상에서는 터미널로, 밖에서는 휴대폰으로 일하다 보니 봇에게 일을 시키는 입구가 계속 흩어졌고, 그래서 봇을 짜기 전에 규칙부터 세웠다. 사람도 AI도 오직 Slack 채널 1개를 통해서만 봇단에 닿는다. 그 위에 역할이 나뉜 8개 봇과 검증 루프를 얹기까지 약 2주간의 연속 운영 로그가 쌓였는데, 그 기간에 배운 건 단순했다. 도구를 많이 붙인다고 자동화가 되는 게 아니라, 입구가 흩어지고 기록이 안 남으면 자동화는 사고를 더 빠르게 반복하는 장치가 된다는 것이다. 그래서 이 허브는 도구 자랑이 아니라 흐름 설계를 축으로 삼는다.

누가 이 구조를 쓰면 좋은가?

책상과 이동 중을 오가며 혼자 일하는 1인 사업자, 반복 요청과 알림에 사람 손이 계속 묶이는 소규모 팀, 그리고 기획부터 운영까지 혼자 감당하는 1인 개발자에게 맞는다. 서버에 에이전트를 상시 띄울 수 있고 최종 결정은 사람이 쥔다는 전제가 서는 환경일수록 효과가 크다.

나는 이 세 역할을 한 사람이 겹쳐 쥔 쪽이다. "엄코딩"이라는 이름으로 웹·앱·AI 자동화를 혼자 만들고 운영하는데, 입구를 하나로 모으니 데스크톱에서 하던 일을 모바일에서 이어받아도 흐름이 끊기지 않았다. 반대로 처음엔 봇을 무작정 늘렸다가 블로그 전담 작가 역할이 기존 콘텐츠 역할과 경계가 겹쳐 전면 제거한 적이 있다. 이때 기준이 하나 생겼다. 역할은 많을수록 좋은 게 아니라, 담당 경계가 분명하게 그어질 때만 둔다.

• 1인 사업자: 어디서 일해도 같은 입구로 요청을 넣고 싶은 사람. 데스크톱에서 하던 일을 모바일에서 이어받아도 흐름이 끊기지 않는 게 핵심 이득이다.
• 소규모 팀: 같은 반복 동작을 여러 사람이 제각각 하는 대신, 하나의 명세를 공유해 결과를 고르게 내고 싶은 팀.
• 1인 개발자: 기획·개발·심사·운영이 따로 떨어진 단계가 아니라 하나로 이어진다는 걸 이미 겪은 사람. 자동화로 그 연결을 손이 덜 가게 만들고 싶은 경우다.

AI 업무 자동화의 핵심 구조는?

수집 → 분류 → 실행 → 기록 → 개선의 다섯 단계다. 요청을 하나의 입구로 모으고(수집), 역할에 맞게 나누고(분류), 실제 작업을 돌리고(실행), 무엇을 했는지 남기고(기록), 그 기록을 근거로 다시 고친다(개선). 이 다섯이 한 줄로 고정될 때 자동화가 흔들리지 않는다.

수집 단계는 입구를 하나로 만드는 일이다. 사람도 AI도 오직 한 채널을 통해서만 시스템에 닿게 하면, 어디서 일해도 같은 입구가 된다. 나는 로컬 직접 수정 경로와 Slack을 거쳐 게이트웨이가 위임하는 경로, 이 두 갈래가 결국 같은 저장소와 노트 볼트로 모이도록 동기화 채널 3종을 뒀다. 입구가 흩어지면 그다음 단계 전부가 흔들린다.

분류 단계는 들어온 요청을 역할에 맞게 나눈다. 하나의 봇이 요청 해석·실행·품질 판단을 한꺼번에 떠안으면 컨텍스트가 섞인다. 그래서 나는 라우터 봇이 직접 처리하지 않고 담당 역할 봇을 같은 스레드에서 멘션으로 호출하게 했는데, 이때 위임 메시지에 지시 출처·요청 요약·완료 기준·주의사항 네 가지를 한 메시지에 담는다. 받는 쪽이 되물을 필요 없는 완결된 지시라야 위임이 보고가 아니라 호출이 되기 때문이다.

실행 단계는 접수와 작업을 분리한다. 요청을 빠르게 받아 두고(접수), 실제 작업은 별도 처리기로 넘긴다. Slack Events API는 3초 안에 접수 응답(ACK)을 돌려줘야 해서, 나는 서명 검증과 접수 기록만 동기로 끝내고 실제 작업은 멱등성을 갖춘 큐로 넘겼다. 접수와 실행을 한 덩어리로 묶으면 하나가 느려질 때 전체가 멈춘다.

기록 단계는 무엇을 했는지 남기는 일이다. 기록이 자동으로 쌓여야 다음 세션이 이어받을 수 있다. 나는 세션이 끝날 때마다 작업 로그가 남도록 훅을 걸었고, 강제 종료로 로그가 유실되는 경우를 대비해 안전장치를 3겹으로 뒀다. 기록은 부산물이 아니라 시스템의 전제다.

개선 단계는 남긴 기록을 근거로 다시 고치는 루프다. 그리고 그렇게 만든 결과물이 검색과 AI 답변에 인용되도록 다듬으면, 자동화의 산출물이 밖으로 발견되기 시작한다. 실제로 나는 robots.txt를 손댄 기억도 없는데 검색봇이 엣지에서 막혀 한동안 AI 답변에 전혀 잡히지 않은 적이 있어, 개선 루프의 마지막 칸에 "크롤러가 정말 읽는가"를 넣게 됐다.

실제로 어떻게 돌아가나 — 사례 지도

아래는 다섯 단계 각각을 내가 직접 겪고 기록한 실물 사례다. 개념을 증명하는 자리이자, 이 허브가 얇지 않다는 근거다. 실제로 돌린 자동화만 세어도 블로그 파이프라인, 소스 자동 업로드, 세션 작업로그, 트렌드 수집, 성장루프 스케줄 작업으로 5종이었고, 그 대표인 편집국 파이프라인은 브리프·리서치·원고·품질 점수 게이트·비주얼·QA의 6단계로 굴러갔다. 각 카드의 단계 라벨을 따라가면 위의 파이프라인이 실제로 어떻게 굴러갔는지 보인다.

토대·관련 사례

위 다섯 단계를 떠받치는 토대와 맥락 글이다.

도입 전에 무엇을 점검해야 하나?

자동화를 붙이기 전에 아래를 스스로 점검한다. 도구를 고르기 전에 흐름부터 서 있는지 확인하는 목록인데, 머리로 만든 게 아니라 사고에서 나왔다. "완료" 판정 항목은 봇이 "업로드 완료"라고 보고했는데 목록 화면엔 안 보이는 유령 문서가 만들어진 사건에서, 소유권 항목은 로컬 크론과 서버 에이전트 두 업로더가 같은 소스를 각자 1건씩 올려 중복이 조용히 쌓인 사건에서 나왔다. (자가진단 폼은 준비 중이며, 지금은 아래 항목을 직접 짚어 보는 것으로 대신한다.)

• 요청이 들어오는 입구가 하나로 모여 있는가, 아니면 채널마다 흩어져 있는가?
• 하나의 봇이나 스크립트가 해석·실행·판단을 한꺼번에 떠안고 있지는 않은가?
• 접수와 실제 작업 실행이 분리돼, 하나가 느려도 전체가 멈추지 않는가?
• 되돌리기 어려운 작업(외부 발행·삭제·결제·권한 변경) 앞에 사람 승인 경계가 있는가?
• 작업 결과가 자동으로 기록되어 다음 세션이 이어받을 수 있는가?
• "완료"를 도구 호출 성공이 아니라, 사용자가 보는 표면에서 재조회해 확인하는가?
• 자동화가 붙인 도구마다 "이게 내 맥락에서 자리값을 하느냐"를 되물었는가?
• 만든 결과물이 검색·AI 답변에 발견되도록 정적 HTML·구조·출처를 갖췄는가?

무엇을 주의해야 하나?

자동화는 실행을 늘리는 만큼 판정 기준을 세우지 않으면 사고를 빠르게 반복하는 장치가 된다. 아래는 실제 운영에서 걸렸던 지점들이다. 권한·실패·기록 누락·비용·유지보수 다섯 갈래로 나눠 둔다.

• 권한과 보안: 토큰은 코드·로그·프롬프트에 넣지 않고 secret 저장소에서 주입한다. 방문자 카운터의 해시 솔트도 소스에 박지 않고 wrangler secret으로 주입했다. AI가 읽는 메시지와 도구 설명은 신뢰된 명령이 아니다. 도구 설명에 지시를 숨기는 툴 포이즈닝 위험이 있어, 나는 MCP 서버를 고를 때 출처가 불분명하거나 관리 이력이 얕은 서드파티는 편의가 아무리 좋아도 후보에서 뺐고, 붙일 서버라면 노출하는 도구 설명을 실제로 읽어 "왜 이런 지시를 품고 있지" 싶은 대목이 걸리면 거기서 멈췄다.
• 완료 판정의 실패: 도구 호출이 성공 응답을 돌려줘도 그것은 완료의 필요조건일 뿐이다. 화면에 보이지 않는 유령 문서가 만들어졌는데 "완료"로 보고된 사고를 겪고, 완료 보고는 사용자가 보는 표면에서 재조회한 뒤에만 하도록 기준을 바꿨다. 실제로 한 위임 스레드에서 선행 과제 4건의 read-back을 점검했을 때 자기 입으로 완료 기준을 다시 읽어 확인된 것은 1건뿐이었고, 나머지 3건은 미완료로 판정했다.
• 기록 누락: 세션 로그가 유실되면 다음 세션이 이어받지 못한다. 강제 종료로 로그가 사라지는 경우를 대비해 안전장치를 여러 겹 두는 편이 낫다.
• 소유권 중복: 같은 산출물을 두 주체가 나눠 올리면 중복이 조용히 쌓인다. 스키마나 중복 방지 로직으로 방어하기 전에, 같은 산출물의 소유권을 하나로 단일화하는 것이 우선이다.
• 비용과 유지보수: 붙일 수 있다와 붙여야 한다는 다르다. MCP 서버를 붙일 때 이걸 실감했다. 서버 하나가 곧 도구 한 묶음이라, 서버에 도구가 열 개 딸려 있으면 그중 하나만 쓰려 해도 열 개 전부의 이름·설명·인자 스키마가 매 턴 컨텍스트에 실린다. 서너 개만 붙여도 컨텍스트가 훅 줄었고, 도구 수가 늘수록 비슷한 이름끼리 헷갈려 모델이 엉뚱한 도구를 고르는 일도 늘었다. 그래서 검색·파일 연동처럼 자주 쓰고 가벼운 것만 남기고 무거운 서버는 버렸으며, 남긴 것도 상시가 아니라 필요할 때만 켜서 자리값을 최소로 냈다.
• 무인 발행 금지: 공개 표면에 나가는 최종 결정은 사람이 쥔다. 이는 자동화가 덜 된 결함이 아니라 설계다.

자주 묻는 질문(FAQ)

AI 업무 자동화란 무엇인가?

사람이 반복하던 요청 분류·요약·기록·알림·문서화를 AI 에이전트와 Slack·Obsidian 같은 업무 도구가 대신 수행하도록 연결하는 방식이다. 핵심은 도구 개수가 아니라 수집 → 분류 → 실행 → 기록 → 개선의 흐름을 하나의 구조로 고정하는 데 있다. 1인 사업자와 소규모 팀이 반복 업무를 줄이고 그 과정을 지식으로 남길 때 가장 효과가 크다.

자동화하려면 도구를 얼마나 많이 붙여야 하나?

많이 붙이는 게 목표가 아니다. 나는 여러 MCP 서버를 실무에 붙여보며 검색·파일 연동은 남기고 상시 로딩되는 무거운 서버는 버렸다. 서버 하나가 곧 도구 한 묶음이라 서너 개만 붙여도 컨텍스트가 훅 줄었고, 비슷한 도구가 여럿이면 모델이 엉뚱한 도구를 고르는 일도 늘었다. 그래서 붙이기 전에 세 가지를 묻는다. 호출 빈도가 높은가, 더 가벼운 CLI로 대체되지 않는가, 인증이 안전하게 닫히는가. 셋을 통과한 것만, 그것도 필요할 때만 켜서 쓴다.

자동화가 "완료"됐다는 걸 어떻게 믿나?

도구 호출이 성공 응답을 돌려줬다는 사실만으로 완료로 기록하지 않는다. 나는 한 위임 스레드에서 선행 과제 4건을 점검했을 때 자기 입으로 완료 기준을 다시 읽어 확인된 것이 1건뿐이라, 나머지 3건을 미완료로 판정한 적이 있다. 그래서 파일을 만들었다면 다시 열어 내용과 위치를 확인하고, 외부 시스템을 바꿨다면 사용자가 보는 표면에서 결과를 재조회한다. 실행했다는 말보다 무엇을 어디에서 다시 읽어 확인했는지를 근거로 남길 때, 요청 수락과 실제 완료를 구분할 수 있다.

AI 에이전트와 전통 자동화(스크립트·CLI)는 무엇이 다른가?

한 번 하고 말 작업이라면 스크립트 한 줄이 가볍고 빠르다. 하지만 같은 동작을 반복하고 인자가 복잡해 매번 형식을 틀릴 만한 작업이라면, 에이전트가 표준화된 도구 명세로 그 형식을 붙들어 주는 쪽이 결과가 고르다. 혼자 쓰는 1회성 작업이면 전통 방식, 여럿이 반복하는 작업이면 에이전트가 유리하다는 구분이 실전에 가깝다.

되돌리기 어려운 작업까지 전부 자동화해도 되나?

아니다. 읽기 전용이거나 중복 실행을 멱등 처리할 수 있는 작업만 자동 재시도한다. 외부 발행·삭제·결제·권한 변경처럼 되돌리기 어려운 작업은 재시도 전에 사람이 승인한다. 특히 무인 발행은 두지 않는다. 공개 표면에 나가는 최종 결정을 사람이 쥐는 것은 자동화의 결함이 아니라 의도한 경계다.

자동화가 만든 결과물이 검색·AI 답변에 인용되게 하려면?

본문이 처음부터 정적 HTML로 존재해야 크롤러가 읽는다. 그 위에 질문 직후 답을 먼저 주는 구조, 출처·통계·표, 그리고 저자·조직을 잇는 엔티티를 얹는다. 학습봇과 검색봇을 따로 통제하는 것도 중요하다. 자세한 설계는 GEO와 SEO를 나눠 설계하는 글에 정리해 뒀다.

1인이나 소규모 팀에도 이런 자동화가 과하지 않나?

오히려 인원이 적을수록 반복 업무 한 사람 몫이 크게 걸린다. 입구를 하나로 모으고 기록을 자동으로 남기는 최소 구조만 세워도, 데스크톱에서 하던 일을 모바일에서 이어받는 연속성이 생긴다. 나도 처음부터 8개 봇을 만든 게 아니라 초기 5～6개 역할에서 필요가 확인될 때마다 하나씩 늘렸고, 경계가 겹친 역할은 도로 걷어냈다. 필요가 확인될 때마다 역할을 하나씩 늘려 가는 누적형으로 접근하는 편이 현실적이다.

다음 행동(CTA)

읽고 나서 무엇부터 할지 막막하다면, 위 사례 지도에서 지금 내 상황에 가장 가까운 단계의 글부터 하나 골라 읽는 것을 권한다. 내 경우 순서는 늘 같았다. 입구를 하나로 모으는 일이 먼저였고, 완료 판정 기준은 그다음이었다. 그러니 수집이 흩어져 있다면 Slack 봇 구축기부터, 완료 판정이 불안하다면 read-back과 D1 카운터로 정직하게 센 기록·측정 사례부터 시작하면 된다.

자동화를 어디서부터 손댈지 함께 짚어 보고 싶다면 커피챗으로 이야기 나눠도 좋다. 편하게 contact@seonoh.dev로 메일을 보내면 된다. 상황을 스스로 점검하는 자가진단 폼도 준비 중이니, 열리면 이 페이지에서 안내하겠다.