[AX EO-1] 우리 회사 업무, 어디까지 Agent에 맡길까

PART 11. 업무 이름을 입력과 결과로 바꿉니다

‘보고 자동화’는 너무 큽니다. ‘매주 월요일, 지난주 이슈 목록에서 완료 건수와 미해결 항목을 표로 만든다’까지 내려오면 무엇을 시험할지 보입니다. 반대로 ‘프로젝트를 관리한다’에는 의사결정, 설득, 예산, 계약까지 섞여 있어 한 번의 자동화 대상으로 다루기 어렵습니다.

공개된 기업 하네스·RAG 적용 기록에도 문서 회수, 원천 대사, 산출물 검증처럼 구체적인 작업이 등장합니다. 그런 수행 기록은 업무 후보를 찾는 근거입니다. 특정 도구가 모든 기업의 생산성을 높였다는 증거로 읽지는 않습니다.

카드에는 아래 다섯 항목을 적습니다. 각 항목에 점수를 곱해 ‘72점 이상이면 Agent’라고 판정하지 않습니다. 중요한 빈칸 하나가 다른 장점 여럿으로 상쇄되지 않기 때문입니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

빈도는 투자 판단의 입력입니다. 하루 수백 번 해도 규칙이 고정된 일은 코드가 맞을 수 있습니다. 드문 일이라도 다음 조사 단계가 크게 달라지면 Agent를 시험할 이유가 생깁니다. 유지보수와 검토를 맡을 담당자도 필요합니다.

PART 22. 복잡도는 필요한 지점에서만 더합니다

이 글에서 Workflow는 미리 정한 순서와 조건으로 실행하는 업무 흐름입니다. Agent는 모델이 환경의 결과를 보고 다음 단계와 도구를 선택하는 구조입니다. 검색증강생성(RAG)은 필요한 자료를 찾아 생성에 제공하는 방식이므로, Workflow와 Agent 어느 쪽에도 들어갈 수 있습니다.

Anthropic의 설계 설명은 정해진 코드 경로와 모델이 동적으로 고르는 경로를 구분합니다. 같은 글은 단순한 호출이나 검색으로 충분한지 먼저 보도록 권합니다. 여기서는 그 구조적 구분을 사용합니다. 2024년 글에 등장한 도구 목록을 현재 제품 선택표로 쓰지는 않습니다.

한 업무에서도 수치 계산은 코드, 서술 추출은 모델, 최종 등록은 Workflow로 나눌 수 있습니다. 책임자는 각 구간을 바꾸었을 때 어떤 오류가 줄어드는지 확인합니다. Agent를 선택하는 것 자체가 성공 기준은 아닙니다.

PART 33. 사례 하나: 주간 집계에는 코드를 선택합니다

가상의 지원팀이 매주 완료 업무 수와 작업 시간을 집계한다고 가정하겠습니다. 원천 파일은 고정된 양식이며 이슈 ID가 있습니다. 이 팀의 질문은 ‘어떻게 해석할까’보다 ‘같은 행을 두 번 세지 않았나’에 가깝습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

다음은 복사해서 대조할 수 있는 합성 입력과 기대 결과입니다. 숫자는 고객 처리량을 축소한 값이 아니라 이 예제를 위해 새로 만들었습니다.

task_id,status,minutes
T101,done,15
T102,done,25
T102,done,25
T103,blocked,

기대 결과
입력 행 수: 4
고유 이슈 수: 3
완료 이슈 수: 2
완료 업무 시간: 40분
미해결 이슈: T103

여기서 동일 ID의 내용까지 같은 행은 한 번만 셉니다. 같은 ID인데 상태나 시간이 다르면 임의로 마지막 행을 채택하지 않습니다. 어떤 기록이 최신인지 알 수 있는 원천 규칙이 없기 때문입니다. 그런 입력은 충돌 목록으로 빼고 집계 확정을 보류합니다.

선택은 코드입니다. 자연어 요약이 필요하면 검증된 결과표를 모델에 넘겨 설명을 덧붙일 수 있습니다. 모델이 원천 숫자를 다시 계산할 필요는 없습니다. 이 사례에서 Agent를 붙인다면 먼저 답해야 할 질문은 “고정된 처리로 해결하지 못한 분기가 무엇인가”입니다.

PART 44. 사례 둘: 회의 후 등록은 Workflow로 시작합니다

이번에는 가상 운영팀의 주간 회의입니다. 회의록에서 약속을 추출하는 데는 문장 해석이 필요하지만, 추출 이후에는 정해진 검사가 가능합니다. 담당·기한·허용 행동이 채워졌는지 확인하고 등록한 뒤 결과를 대사하는 순서입니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

합성 회의록에는 두 문장이 있습니다. “운영 담당은 2026-09-16까지 배포 점검표를 갱신한다”와 “권한 정책도 다시 살펴보자”입니다. 첫 문장은 담당 역할과 기한이 있습니다. 두 번째에는 담당과 종료 조건이 없어 실행할 업무로 확정하기 어렵습니다.

이 예제에서는 책임자가 ‘담당·기한이 확인된 회의 액션을 지정 보드에 등록’하도록 이미 허용했습니다. A17을 등록할 때마다 같은 승인을 다시 묻지 않습니다. A18은 그 허용 조건에 들지 않으므로 담당자와 완료 기준을 확인할 목록에 남깁니다.

등록 요청 뒤 응답이 끊겨도 바로 같은 내용을 한 번 더 만들지 않습니다. 대상 보드에서 원천 액션 ID M17-A17을 조회합니다. 이미 있으면 그 기록을 연결하고, 없으면 대상 시스템의 중복 방지 기능과 재시도 규칙에 따라 처리합니다. 확인할 수 없으면 실행 결과를 ‘미확인’으로 남깁니다.

선택은 모델을 포함한 Workflow입니다. Morgan Stanley Debrief의 공개 사례도 회의 기록을 후속 초안과 업무 시스템으로 연결하면서 최종 출력의 검토를 구분합니다. 그 기업의 구성을 그대로 복제하자는 뜻은 아닙니다. 우리 팀에서도 문장 생성과 허용된 실행을 따로 정의하자는 근거입니다.

PART 55. 사례 셋: 달라지는 조사 경로에는 Agent를 시험합니다

세 번째는 가상의 사내 도구 지원 업무입니다. “정책이 바뀐 뒤 검수 대상이 보이지 않습니다”라는 문의가 들어왔습니다. 화면 문제인지, 계정 역할인지, 문서 개정 문제인지에 따라 읽을 자료가 달라집니다. 모든 문의를 같은 문서 세 개로 해결할 수는 없습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

합성 원천은 다음과 같습니다. 9월 1일 정책에는 기존 검수자 그룹이 적혀 있고, 9월 10일 시행된 개정본에는 새 그룹이 필요하다고 되어 있습니다. 역할 조회에는 해당 계정이 기존 그룹에만 속한다고 나옵니다. 오류 기록은 같은 시점의 접근 거절을 보여 줍니다.

기대 답변은 “정책 개정 이후 필요한 그룹과 현재 역할이 다릅니다. 접근 거절 기록도 있습니다. 역할 소유자가 할당 누락 여부를 확인해야 합니다”입니다. “계정을 고쳤습니다”가 아닙니다. 조회 결과만으로 조직의 역할 부여 결정을 대신할 수는 없습니다.

선택은 조회 전용 Agent의 제한 실험입니다. 이 세 문서만 읽는 일이라면 Workflow도 충분합니다. 실제 문의에서 조사 경로가 바뀌는지, Agent의 추가 조회가 해결률을 높이는지를 비교한 뒤 선택을 유지합니다. 현재 자료를 못 찾는다면 Agent를 더 복잡하게 만들기 전에 자료 접근부터 정리합니다.

PART 66. 선택표를 책임자의 결정으로 연결합니다

세 장을 한꺼번에 비교하면 먼저 할 일이 보입니다. 아래 순서는 가상 팀이 첫 실험을 선택하는 예이며, 모든 기업의 도입 순위가 아닙니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

가상 팀은 먼저 주간 집계를 고릅니다. 결과가 작고 검증 가능하며 외부 상태를 바꾸지 않기 때문입니다. 동시에 회의 등록의 중복 방지 예제를 준비합니다. Agent 후보를 골랐다고 해서 그것을 가장 먼저 배포해야 하는 것은 아닙니다.

기존 업무 Agent 10종 글은 업무 성격과 필요한 구성요소를 살펴보는 선행 자료입니다. 그 글의 업무량 비중에는 시뮬레이션이 포함됩니다. 여러분의 우선순위에는 최근 실제 빈도, 검토 시간, 잘못 실행했을 때 되돌리는 부담을 새로 기록해야 합니다.

PART 77. 이런 상태에서는 도입 결정을 멈춥니다

첫째, 결과를 받아 쓸 책임자가 없다면 수용 기준을 정할 수 없습니다. “일단 AI로 만들어 보자”는 탐색은 가능하지만, 운영 도입과는 다른 활동입니다. 둘째, 필요한 자료를 읽을 수 없거나 판본이 충돌한다면 정확도 비교보다 원천 정리가 먼저입니다.

셋째, 등록은 가능하지만 실제 성공 여부를 조회할 수 없다면 자동 재시도를 넓히지 않습니다. 넷째, 시험할 예시가 성공한 입력뿐이라면 보류·오류·중복 입력을 보강합니다. 통상 입력에서 한 번 잘된 결과는 실패 복구 능력을 보여 주지 않습니다.

이 기준은 일을 멈추기 위한 승인 목록이 아닙니다. 빈칸을 발견하면 그 항목의 담당과 완료물을 정해 다음 선택을 가능하게 합니다. 예를 들어 ‘권한 미확인’이라면 접근 가능한 자료 목록을 받는 것이 다음 일입니다. 이미 정한 범위 안의 조회와 검사를 다시 승인받을 필요는 없습니다.

기업 사례에도 한계가 있습니다. C.H. Robinson의 공개 설명은 견적 등 업무 단위로 Agent를 확장한 운영 사례입니다. 같은 방식이 우리 조직에서 같은 효과를 낸다는 보장은 없습니다. 복잡도가 늘어난 만큼 오류와 재작업이 줄었는지 우리 업무로 확인해야 합니다.

PART 88. 내일은 업무 카드 한 장부터 채웁니다

처음 입력은 아래처럼 구체적으로 시작할 수 있습니다. 이 문장은 이미 완성한 합성 집계 사례를 재현하는 요청이며, 답을 실제 데이터에서 확인해야 한다는 조건도 포함합니다.

주간 이슈 집계 업무의 선택 카드를 작성해 주세요.
입력은 T101/done/15, T102/done/25, T102/done/25, T103/blocked/공란입니다.
완전히 같은 행은 한 번만 세고, 같은 ID의 값이 다르면 충돌로 남깁니다.
기대 결과는 고유 3건, 완료 2건, 완료 업무 시간 40분입니다.
외부 시스템은 변경하지 않습니다.
코드·Workflow·Agent 중 첫 선택과 선택을 바꿀 조건을 설명해 주세요.

실제 업무 한 건도 같은 형식으로 바꿔 보세요. 입력 예시, 선택 이유, 책임자, 수용 기준, 빈칸을 남기면 됩니다. 이 카드가 다음 글의 검색·권한 시험에서 지킬 조건이 됩니다.

다음 편 사내 RAG의 진짜 테스트에서는 문서가 개정되거나 담당 부서가 바뀐 뒤에도 근거와 접근권이 맞는지 시험합니다. 전체 시리즈 안내에서 업무 선택부터 운영 판단까지 이어 읽을 수 있습니다.