자동화 사례를 읽다 보면 남의 직무 이야기 같습니다. 개발자니까, 고객센터니까 가능했겠지 하고 넘기게 됩니다. 그런데 국내 AI 학습 커뮤니티 지피터스에 올라온 기록들을 직무별로 늘어놓으면 다른 그림이 보입니다. 영업은 접수부터, 인사는 검색부터, 기획은 수집부터, 제작은 반복 산출물부터 자동화를 시작했습니다. 첫 자동화 지점이란 판단 없이 같은 형식으로 반복되는 업무의 입구를 말하는데, 이 입구가 없는 직무는 없었습니다.
미리 밝혀 둘 것이 있습니다. 이 글의 사례는 모두 지피터스 회원이 직접 쓴 자기보고 기록입니다. 숫자도 전부 작성자 본인의 보고이고, 제3자가 검증한 성과는 하나도 없습니다. 정량 성과가 아예 없는 것도 있습니다. 그래서 이 글은 성과를 자랑하는 글이 아니라, 어디서 시작했고 어디서 막혔는지를 읽는 글입니다.
영업 — 접수부터 자동화합니다
제조업 스타트업에서 영업·무역·물류를 두루 맡아 온 담당자가 견적 메일 처리를 자동화했습니다(지피터스 원문). 구조는 단순합니다. 고객이 Google Form으로 문의를 넣으면 Google Sheet에 저장되고, Apps Script가 금액을 계산하고, Zapier가 견적 메일을 보내고, Trello에 고객 카드가 만들어집니다.
처음 계획은 더 야심찼습니다. GPT API로 비정형 이메일에서 품목과 수량을 뽑아내려 했습니다. 그런데 출력이 불규칙했습니다. 같은 수량이 '2개', '2', 'two'로 제각각 나왔고, JSON 파싱 에러가 이어졌습니다. 그래서 방향을 틀었습니다. 접수 자체를 폼으로 정형화한 것입니다. 자동화 학습을 시작한 지 2주 차에 만든 과제 수준의 단순한 구현이지만, 순서는 배울 만합니다. 비정형을 AI로 해석하는 것보다 접수 단계를 정형화하는 편이 빠를 때가 많습니다.
인사 — 평가는 남기고 검색만 맡깁니다
한 인사 담당자는 매주 나오는 채용공고와 쌓여 가는 인재풀을 잇는 매칭을 자동화했습니다(지피터스 원문). Airtable에 Jobs·Talent·Matches 세 테이블을 만들고, n8n이 워크플로우를 돌리고, OpenAI가 경력 텍스트를 평가하는 구조입니다.
여기에도 삽질이 있습니다. 처음에는 Airtable 수식만으로 풀려다 이틀을 썼고, 결국 n8n으로 갈아탔습니다. 더 중요한 전환은 그다음입니다. AI에게 평가를 통째로 맡겨 봤더니, 추천할 만한 인재가 아니라는 것을 알아본 쪽은 사람이었습니다. 그래서 사람이 키워드 서너 개를 우선순위대로 입력하고 AI는 그 기준으로 후보를 추리는 구조로 고치는 중입니다. 아직 진행형이고 정량 성과는 없습니다. 그래도 방향은 분명합니다. 판단은 남기고, 검색과 대조만 맡기는 것입니다.
기획 — 수집과 요약부터 시작합니다
스타트업에서 개발 PM과 사업 전략을 맡은 회원은 뉴스 수집·요약·배포를 자동화했습니다(지피터스 원문). n8n을 직접 서버에 올리고(셀프호스팅), SerpAPI로 뉴스를 찾고, OpenAI로 요약해서, 결과를 Slack·Discord·Telegram 세 채널로 뿌립니다.
이 기록에서 눈여겨볼 대목은 어려움의 위치입니다. 가장 어려웠던 것은 자동화 로직이 아니라 인프라였습니다. GCP 가상머신, Docker, Cloudflare 도메인 연결 같은 기반 작업이 시간을 다 가져갔습니다. 워크플로우가 무한루프에 빠져 서버가 디도스를 맞은 것처럼 멈추고, GCP가 인스턴스를 자동으로 꺼 버리는 일이 반복됐습니다. 본인 표현으로 "몇 번이나 포기하고 싶었어요"라고 합니다. 요컨대 로직은 금방인데, 그것을 24시간 돌게 만드는 일이 본체였던 셈입니다.
제작 — 반복 산출물을 맡깁니다
이커머스 상세페이지를 만드는 회원은 Claude Code CLI에 서브에이전트 9개를 붙였습니다(지피터스 원문). 기획, 디자인, 시장조사, 마케팅을 각각 다른 에이전트가 나눠 맡고, 산출물은 GitHub으로 관리합니다. 경영자문 서비스와 경영 서적, 실사례 2건으로 검증까지 마쳤습니다. 작성자의 평가는 이렇습니다. 개발 실력이 부족해도 도구를 잘 쓰면 결과물은 나옵니다. 다만 전문용어는 익혀야 합니다.
같은 결의 사례가 하나 더 있습니다. 코드를 한 줄도 못 짠다는 경영지원팀 직원이 Claude Code와 대화만으로 120명이 쓰는 사내 챗봇을 만들었고(지피터스 원문), 임직원 질문을 받아 가며 응답 매크로를 90개까지 늘렸습니다. 두 사례의 공통점은 도구가 아니라 태도입니다. 코드를 쓰는 대신 의도를 말했고, 결과는 직접 테스트했습니다.
안 되는 것도 있습니다
실패 기록도 있습니다. 코드 경험이 없는 임대인이 임대료·관리비 입금 확인과 미납 알림을 자동화하려 했습니다(지피터스 원문). Claude로 요구사항 문서를 쓰고 워크플로우를 설계하는 데까지는 갔습니다. 그런데 은행이 벽이었습니다. NH 오픈API는 사전심사와 인증 절차를 요구했고, 브라우저에서 직접 호출하지 못하게 막는 CORS 제한에도 걸렸습니다. 결과물은 더미 데이터로 돌아가는 대시보드, 그러니까 개념증명에서 멈췄습니다.
이 기록의 가치는 실패 그 자체에 있습니다. 금융, 의료, 개인정보처럼 규제가 겹겹인 영역에는 개인의 자동화 도구가 닿지 않는 곳이 있습니다. AI가 설계를 아무리 잘해 줘도 제도의 문은 따로 열어야 합니다. 그 벽이 어디 서 있는지 미리 아는 것도 자동화 역량입니다.
공통 패턴 세 가지
다섯 직무의 기록을 겹쳐 놓으면 세 가지 패턴이 남습니다.
- 코드가 아니라 의도를 전달합니다. 챗봇을 만든 경영지원팀 직원도, 상세페이지를 만든 회원도 코드를 쓴 것이 아니라 무엇이 필요한지를 말했습니다. 도구는 그다음 문제였습니다.
- 가장 값진 기록은 삽질입니다. Airtable 수식으로 날린 이틀, JSON 파싱 에러, 무한루프로 멈춘 서버. 이 기록들 덕에 다음 사람은 같은 자리에서 덜 헤맵니다.
- AI가 됐다고 해도 직접 테스트합니다. 챗봇 제작자의 교훈 그대로입니다. AI의 "해결됐어요"와 실제로 도는 것은 다른 문제입니다.
우리 조직이라면
자기 직무의 진입점을 찾으려면 세 가지를 물어보면 됩니다.
- 매주 같은 형식으로 반복되는 입력이 있나요. 견적 문의, 채용공고, 뉴스 키워드처럼 들어오는 것이 정형이면 그곳이 첫 지점입니다.
- 판단과 검색을 나눌 수 있나요. 인사 사례처럼 AI가 후보를 추리고 사람이 결정하는 경계를 그을 수 있으면 시작할 수 있습니다.
- 막힐 벽이 어디인지 아나요. 금융 API, 사내 보안 규정, 개인정보. 벽의 위치를 먼저 확인하면 개념증명에서 멈추는 일을 줄일 수 있습니다.