AI를 도입하자는 이야기가 나오면 대화는 대개 도구에서 시작합니다. 어떤 모델을 쓸지, 어떤 솔루션을 살지, 에이전트를 어디에 붙일지부터 정하려고 하죠. 그런데 막상 자동화를 만들어보면 막히는 지점은 거의 언제나 모델이 아니었습니다. 우리가 우리 일을 얼마나 정확히 알고 있는가였습니다.
핵심 요약
- AI는 직무명이 아니라 Task와 만납니다. “영업 담당자”라는 직무 전체와 일하는 것이 아니라, 그 안의 “잠재 고객 조사”, “제안서 초안 작성” 같은 단위와 만납니다.
- 필요한 건 업무 목록이 아니라 업무 구조입니다. 무엇이 그 일을 시작시키고, 무엇이 오가고, 누가 판단하고, 어디에서 예외가 생기는지까지 있어야 설계가 가능합니다.
- 하나의 Task가 빨라져도 전체가 빨라지지는 않습니다. 손을 대는 시간(Working Time)과 시작부터 끝까지 걸리는 시간(Lead Time)은 다릅니다.
- 모든 문제의 답이 AI일 필요는 없습니다. 없애기·단순화·표준화가 먼저고, AI는 그다음 선택지입니다.
- 우리 경우 자동화가 자리 잡은 지점은 Task 안에서 경계를 그은 곳이었습니다. “숫자는 코드가, 문장은 LLM이” 같은 식으로요.
“월간 경영보고서를 작성한다”
직무기술서에 이런 한 줄이 있다고 해봅시다.
월간 경영보고서를 작성한다.
사람에게는 충분히 이해되는 설명입니다. 이 문장을 읽은 신입에게 몇 번 어깨너머로 알려주면 일이 굴러갑니다. 하지만 이 한 문장만으로 AI에게 같은 일을 맡기기는 어렵습니다. 실제로 필요한 정보는 이런 것들이기 때문입니다.
- 누가 자료를 요청하고, 어느 부서에서 데이터를 받는가
- 자료가 Excel로 오는가, 시스템에서 추출되는가
- 어떤 기준으로 정리하고, 누락된 값은 어떻게 확인하는가
- 어떤 수치를 중요하게 보는가, 추가 확인이 필요한 조건은 무엇인가
- 초안은 누가 검토하고, 수정은 몇 차례 일어나는가
- 최종 산출물은 누구에게 전달되는가
AI를 실제로 적용할 수 있는지는 바로 이 세부 구조에서 결정됩니다. 그리고 대부분의 조직에서 이 정보는 어디에도 적혀 있지 않습니다. 담당자의 머릿속에만 있습니다.
AI가 만나는 층위는 직무명이 아니다
우리는 조직의 일을 흔히 직무 단위로 이해합니다. 영업 담당자, 인사 담당자, 구매 담당자처럼요. 직무는 채용·평가·보상의 기준으로는 훌륭한 단위지만, 자동화를 설계하기에는 상자가 너무 큽니다. 업무를 층위로 내려보면 이유가 분명해집니다.
| 층위 | 뜻 | 예시 |
|---|---|---|
| Job | 직무 — 역할 | “영업 담당자” |
| Duty | 주요 책임 영역 | “신규 고객 개발”, “제안 및 계약 관리” |
| — 직무기술서는 대체로 여기까지 설명합니다 — | ||
| Task | 실제로 수행하는 업무 | “잠재 고객 조사”, “제안서 작성”, “CRM 업데이트” |
| Activity | Task를 이루는 각 행동 | 요구사항 정리 → 과거 사례 검색 → 목차 구성 → 초안 작성 → 검토 반영 |
| Workflow | 이어지는 순서와 조건 | 이 Task와 Activity가 어떤 순서·조건으로 연결되는가 |
AI가 실제로 작동하는 지점은 대부분 점선 아래입니다. 문서를 요약하고, 값을 추출하고, 초안을 만들고, 규칙에 따라 다음 단계로 넘깁니다. 그래서 물어야 할 질문은 “이 직무를 AI로 바꿀 수 있는가?”가 아니라 “이 직무를 구성하는 각각의 업무는 어떻게 수행되고 있으며, 그중 어떤 부분을 다시 설계할 수 있는가?”입니다.
업무 목록과 업무 구조는 다르다
업무를 잘게 쪼갰다고 끝이 아닙니다. 구매팀의 업무를 “구매 요청 확인 → 공급업체 조사 → 견적 비교 → 업체 선정 → 발주 → 납기 확인”으로 정리했다고 해봅시다. 체계적으로 보이지만 이것만으로는 아무것도 자동화할 수 없습니다. 금액에 따라 승인 단계가 달라지는지, 신규 업체와 기존 업체의 절차가 다른지, 예외는 누가 판단하는지가 빠져 있기 때문입니다.
업무 지도(Work Map)라고 부를 만한 것이 되려면 Task마다 이런 항목이 함께 붙어야 합니다.
| 항목 | 무엇을 적는가 |
|---|---|
| Task | 실제로 무엇을 하는가 — “고객 문의 분류”, “비용 정산” 같은 실질 단위 |
| Trigger | 무엇이 이 일을 시작시키는가 — 이메일 수신인지, 특정 날짜인지, 시스템 상태 변경인지 |
| Input / Output | 무엇을 받아 무엇을 남기는가 |
| Role | 누가 관여하는가 — 실행·검토·승인·협업을 구분해서 |
| Frequency & Volume | 얼마나 자주, 얼마나 많이 — 하루 100번과 한 달 한 번은 다른 문제 |
| Working / Lead Time | 손대는 시간과 끝까지 걸리는 시간 |
| System & Data | 어떤 시스템을 거치는가 |
| Decision | 어떤 판단이 필요한가 — 규칙인지, 경험인지, 책임이 큰 판단인지 |
| Exception | 정상 경로를 벗어나면 어떻게 되는가 |
| Dependency | 앞뒤 업무와 어떻게 연결되는가 |
| Pain Point | 현업이 실제로 힘들어하는 곳 — 반복 입력, 검색, 대기, 재작업 |
이 항목들이 서로 연결되어야 목록이 아니라 지도가 됩니다.
우리 사례 ① — 브리핑 자동화를 Task로 쪼갰을 때
MoaVest는 하루 몇 차례 시장 브리핑을 자동으로 만들고, 미국장 마감 정리 글을 매일 새벽에 블로그로 발행합니다. 이 일을 처음 설계할 때 가장 간단해 보이는 문장은 이것이었습니다. “시장 데이터를 LLM에 주고 브리핑을 쓰게 한다.”
실제로 해보면 무너지는 지점은 문장이 아니라 숫자였습니다. 글은 그럴듯한데 등락률이 살짝 어긋나거나, 어제 수치가 오늘 문장에 섞여 들어옵니다. 그래서 하나의 Task로 보이던 “브리핑 작성”을 쪼갰습니다.
| 단계 | 하는 일 | 맡는 쪽 |
|---|---|---|
| 수집 | 지수·환율·원자재·뉴스 원천 데이터를 가져온다 | 코드 |
| 계산 | 등락률·평소 변동폭 대비 배수 등 사실값을 확정한다 | 코드 |
| 작성 | 확정된 사실을 문장과 맥락으로 엮는다 | LLM |
| 검증 | 본문 숫자가 계산값과 일치하는지 대조한다 | 코드 |
| 발행 | 실패 시 규칙 기반 문장으로 대체해 내보낸다 | 코드 |
핵심은 “AI를 쓴다/안 쓴다”가 아니라 하나의 Task 안에서 경계를 그은 것이었습니다. 판단이 필요 없는 계산은 코드가, 맥락을 엮는 문장은 LLM이, 숫자 일치 확인은 다시 코드가 맡습니다. Work Map의 항목으로 말하면 Decision과 Exception 열이 실제 설계를 갈랐습니다. 이 경계를 긋기 전에는 “브리핑 자동화”라는 한 덩어리였고, 그 덩어리 상태로는 품질을 손볼 방법이 없었습니다.
우리 사례 ② — 초안이 빨라져도 전체는 빨라지지 않는다
여기가 자동화를 만들 때 가장 자주 밟는 지뢰입니다. AI로 보고서 초안 작성을 2시간에서 20분으로 줄였다고 해봅시다. 83% 단축이니 숫자만 보면 대단한 개선입니다. 그런데 초안 이후 팀장 검토에 이틀, 관련 부서 확인에 하루, 최종 승인에 하루가 걸린다면 이야기가 달라집니다.
손대는 시간은 83% 줄었지만 시작부터 완료까지의 시간은 사실상 그대로입니다. 더 나빠질 수도 있습니다. AI 덕분에 초안을 훨씬 많이 만들게 되었는데 검토자가 처리할 수 있는 양은 그대로라면, 병목은 오히려 심해집니다.
우리 쇼츠 제작이 정확히 이랬습니다. 블로그 글에서 대본을 뽑고, 음성을 만들고, 영상을 렌더링하고, 업로드하는 과정은 사람 손이 거의 닿지 않습니다. 그런데 전체 리드타임을 결정하는 건 그 자동화된 구간이 아니라 중간의 사람 승인 게이트 하나였습니다. 렌더링을 아무리 최적화해도 승인이 하루 늦으면 하루 늦게 나갑니다. 개별 Task가 아니라 Task 사이의 연결을 봐야 한다는 말은 이런 뜻입니다.
- 업무가 어디에서 기다리는가
- 재작업이 어디에서 생기는가
- 정보가 어디에서 끊기는가
- 사람의 승인이 필요한 지점은 어디인가
- 시스템 사이에서 데이터를 수작업으로 옮기는 지점은 어디인가
모든 문제를 AI로 풀 필요는 없다
업무에서 문제를 발견하면 곧바로 “여기에 LLM을 붙일 수 있을까?”부터 묻기 쉽습니다. 하지만 현장에서는 더 단순한 방법이 더 좋은 답일 때가 많습니다. 아래 질문을 위에서부터 순서대로 던져보는 편이 낫습니다.
| 단계 | 질문 | 뜻 |
|---|---|---|
| Eliminate | 없앨 수 있는가 | 필요 없는 보고서를 AI로 자동 생성하는 건 좋은 개선이 아닙니다. 불필요한 일을 더 효율적으로 하게 만들 뿐입니다. |
| Simplify | 더 단순하게 만들 수 있는가 | 복잡한 승인 체계나 중복 입력부터 정리하는 편이 효과적일 수 있습니다. |
| Standardize | 표준화가 먼저인가 | 사람마다 방식이 다른 프로세스를 그대로 자동화하면 예외가 늘어납니다. |
| Automate | 명확한 규칙으로 처리되는가 | 생성형 AI보다 기존 워크플로 자동화나 시스템 기능이 더 안정적일 수 있습니다. |
| Augment | AI가 처리 비용을 줄여주는가 | 판단은 사람이 하되 검색·분석·요약·분류·초안을 AI가 맡습니다. |
| Transform | 다시 설계할 것인가 | 기존 프로세스에 AI 한 조각을 더하는 수준을 넘어, AI가 있다는 전제에서 업무와 역할을 다시 짭니다. |
우리도 이 순서 때문에 뒤집은 결정이 하나 있습니다. 자동 발행되는 글의 품질을 점검하는 장치를 만들면서, 처음에는 규칙에 걸리면 발행을 막도록 설계했습니다. 그런데 실제로 돌려보니 새벽에 무인으로 도는 발행이 문체 규칙 하나 때문에 통째로 멈추는 것이 더 나쁜 결과였습니다. 그래서 품질 점검은 발행을 차단하지 않고 측정만 하도록 바꿨습니다. Work Map의 언어로는 Exception을 어떻게 처리할지의 문제고, 이건 모델 성능으로는 풀리지 않는 종류의 결정입니다.
그런데 업무분석은 원래 어렵다
“그러면 업무를 자세히 분석하면 되지 않느냐”는 결론이 자연스럽지만, 해보면 쉽지 않습니다. 자기 업무를 가장 잘 아는 사람은 현업이지만, 현업은 자기 업무를 분석하기 위해 존재하는 사람이 아닙니다. 이미 할 일이 많습니다. 게다가 사람은 자기 일을 언제나 정확히 설명하지도 못합니다. 오래 반복한 업무일수록 중요한 단계를 건너뛰고 설명하고, 작은 판단이나 예외 처리는 아예 업무라고 생각하지 않습니다.
“그건 그냥 제가 보고 판단합니다.”
이 한 문장 안에 수년치 경험과 여러 판단 규칙이 압축되어 있는 경우가 많습니다.
여기서 재미있는 뒤집기가 가능합니다. 업무분석 자체를 AI로 먼저 돌려보는 것입니다. 조직에는 직무기술서, 업무분장표, SOP, 사내 규정, 과거 산출물, 회의록, 양식과 템플릿, 시스템 로그처럼 업무 정보가 이미 흩어져 있습니다. AI가 이 자료를 먼저 읽고 “이 직무에서는 이런 업무가 수행되는 것으로 보입니다” 수준의 초안을 만들면, 현업이 하는 일의 성격이 바뀝니다. 빈 종이에 자기 업무를 빠짐없이 적는 창작(Creation)에서, 이미 그려진 구조의 틀린 곳을 고치는 검증(Verification)으로요.
실제로 초안을 본 현업은 이렇게 말합니다. “이 단계는 실제로는 안 합니다.” “여기에 중요한 예외가 하나 빠졌습니다.” “이 일은 우리가 아니라 재무팀이 합니다.” “여기가 제일 오래 걸립니다.” 부담은 훨씬 적고 정보의 질은 더 높습니다.
다만 AI가 문서를 많이 읽었다고 실제 업무를 이해한 것은 아닙니다. 문서에 적힌 절차와 현장의 관행은 다르고, 시스템에 기록되지 않는 커뮤니케이션이 많으며, 특정 담당자만 아는 노하우도 있습니다. 그래서 AI가 만든 지도는 정답이 아니라 가설로 다루는 편이 맞습니다. 초안을 만들고 → 현업이 검증하고 → 실제 데이터와 비교하고 → 관찰로 보완하고 → 구조를 수정하는 루프를 한 바퀴는 돌아야 합니다.
마무리 — 최소 단위는 직무가 아니라 Task다
AI가 직업을 어떻게 바꿀지에 관한 이야기는 많습니다. 개발자는 어떻게 되는지, 마케터는 얼마나 대체되는지 같은 질문들이죠. 하지만 실제로 무언가를 자동화하려면 질문의 해상도를 한 단계 더 내려야 합니다. “마케터”라는 직무가 어느 날 한꺼번에 바뀌는 게 아니라, 그 안의 조사·분석·작성·검토·의사결정·커뮤니케이션이 서로 다른 속도로 변하기 때문입니다. 어떤 일은 사라지고, 어떤 일은 자동화되고, 어떤 일은 오히려 사람의 역량이 더 중요해집니다.
우리가 브리핑과 쇼츠를 자동화하며 배운 것도 같습니다. 잘 굴러가는 구간은 좋은 모델을 골라서가 아니라, 그 일을 충분히 잘게 쪼개서 어디까지가 코드의 몫이고 어디부터가 판단의 몫인지 선을 그을 수 있었던 구간이었습니다. 반대로 아직 삐걱대는 구간은 대개 그 선을 아직 못 그은 곳입니다.
AI Use Case를 찾기 전에, 우리 일을 한 장의 지도 위에 올려보는 것부터 시작할 수 있습니다. 질문은 결국 하나입니다. 우리는 우리의 일을 얼마나 알고 있는가?
이 글의 관점과 프레임(Work Map, 업무의 다섯 층위, Eliminate→Transform 순서)은 세이그나이터의 아티클 〈AX와 Work Map〉(2026.08.09)에서 가져왔습니다. 본문의 MoaVest 사례와 해석은 자체 내용입니다.