자동화, RPA, 데이터 파이프라인, 관측가능성

자동화의 목표는 '사람 제거'가 아니다

자동화를 처음 도입하는 팀은 종종 같은 상상을 한다. 이메일이 들어오면 AI가 읽고, 분류하고, 답장을 쓰고, 필요한 시스템에 입력하고, 결재까지 올리고, 고객에게 보내고, 보고서도 만든다. 담당자는 커피를 마시며 결과만 확인한다. 멋져 보인다. 하지만 실제 조직에서 이 그림을 그대로 실행하면 대개 두 가지 중 하나로 끝난다. 아무것도 믿을 수 없어 결국 사람이 전부 다시 확인하거나, 너무 많이 믿었다가 한 번의 잘못된 실행으로 더 큰 비용을 치른다.

좋은 AI 자동화는 사람을 완전히 빼는 기술이 아니다. 반복 작업을 줄여 사람이 더 중요한 판단을 잘하게 만드는 운영 구조다. 즉, 사람은 복사·붙여넣기와 양식 맞추기에서 빠지고, 기준 설정·예외 판단·승인·책임 기록에 더 집중해야 한다.

RPA, 즉 로봇 프로세스 자동화는 사람이 화면에서 반복하던 클릭, 복사, 입력, 다운로드, 업로드를 소프트웨어 로봇이 대신 수행하게 하는 방식이다. ERP에서 매출 데이터를 내려받고, 엑셀에 저장하고, 전자결재 양식에 붙여 넣고, 메일을 보내는 일처럼 규칙이 분명한 업무에 강하다. 여기에 ChatGPT 같은 LLM을 결합하면 보고서 문장 작성, 이상 거래 설명, 이력서 요약, 품의서 사유 작성처럼 언어 판단이 필요한 단계까지 자동화 범위가 넓어진다.¹

하지만 이 조합의 힘은 동시에 위험이기도 하다. RPA는 시키는 대로 실행하고, LLM은 그럴듯한 문장을 만든다. 둘을 아무 통제 없이 붙이면 "그럴듯하게 틀린 판단"이 "정확하게 실행"된다. 그래서 이 장의 핵심 질문은 "무엇을 자동화할 수 있는가"가 아니라 "어디까지 자동화하고, 어디에서 멈추게 할 것인가"다.

한 번의 답변이 아니라 파이프라인을 설계하라

13장에서 우리는 구조화 출력이 왜 중요한지 살펴보았다. 고객 문의를 JSON으로 분류하고, 필드를 검증하고, 다음 시스템으로 넘길 수 있게 만드는 순간 ChatGPT는 단순한 대화 상대가 아니라 업무 시스템의 한 부품이 된다. 이번 장은 그 다음 단계다. 구조화된 출력이 나온 뒤 그것을 어디로 보내고, 어떤 조건에서 멈추고, 누가 승인하고, 어떤 기록을 남길 것인가를 설계해야 한다.

AI 자동화 파이프라인은 보통 다음 흐름으로 생각하면 가장 안정적이다.

1. 수집: 이메일, 폼, 채팅, PDF, 스프레드시트, ERP, CRM, 그룹웨어에서 원천 데이터를 가져온다.

2. 정규화: 파일 형식과 필드명을 맞추고, OCR이나 파서로 텍스트를 추출하며, 중복과 누락을 확인한다.

3. 분류: 업무 유형, 긴급도, 위험도, 담당 부서, 필요한 후속 조치를 판정한다.

4. 요약·초안 생성: 사람이 빨리 검토할 수 있도록 핵심 근거와 추천 조치를 만든다.

5. 검증: 필수 필드, 금액, 날짜, 정책 위반, 금지 데이터, 근거 부족 여부를 확인한다.

6. 승인: 위험도에 따라 자동 진행, 표본 검토, 담당자 승인, 이중 승인 중 하나로 보낸다.

7. 실행: ERP 입력, 티켓 라우팅, 고객 답장 발송, 결재 등록, 데이터베이스 업데이트를 수행한다.

8. 기록·모니터링: 누가, 언제, 어떤 근거로, 어떤 모델과 프롬프트 버전으로 처리했는지 남긴다.

이 흐름에서 중요한 점은 LLM이 모든 단계를 담당하지 않는다는 것이다. LLM은 주로 비정형 정보를 읽고, 분류하고, 요약하고, 초안을 만드는 데 강하다. 반면 금액 계산, 권한 확인, 중복 방지, 시스템 입력, 승인 상태 관리, 로그 저장은 일반 프로그램·워크플로 엔진·RPA·데이터베이스가 맡는 편이 안정적이다.

예를 들어 세금계산서 안내 메일을 자동화한다고 해 보자. 나쁜 설계는 이렇다. "새 세금계산서가 생기면 ChatGPT가 알아서 고객에게 메일을 보내라." 좋은 설계는 다르다. ERP에서 발행 내역을 가져오고, 고객사명·금액·발행일·담당자를 구조화하고, 발송 대상이 맞는지 확인하고, ChatGPT는 회사 톤에 맞는 안내문 초안을 만들며, 일정 금액 이상이거나 신규 고객이면 사람이 승인한다. 최종 발송 후에는 메일 ID, 발송 시각, 사용한 템플릿 버전, 승인자를 기록한다.

자동화는 마법 지팡이가 아니라 컨베이어벨트에 가깝다. 컨베이어벨트의 품질은 가장 똑똑한 한 단계가 아니라, 각 단계 사이의 연결과 멈춤 장치가 결정한다.

RPA와 LLM의 역할을 분리하라

RPA와 LLM을 섞을 때 가장 흔한 실수는 둘의 역할을 구분하지 않는 것이다. RPA는 "손"에 가깝고, LLM은 "언어를 다루는 판단 보조자"에 가깝다. 손이 판단하면 위험하고, 판단 보조자가 직접 버튼을 누르면 더 위험하다.

RPA가 잘하는 일은 화면 조작, 파일 이동, 정해진 필드 입력, 시스템 간 복사, 정형 보고서 업로드다. 반면 LLM이 잘하는 일은 이메일의 의도를 파악하고, 긴 문서를 요약하고, 고객 감정을 분류하고, 품의서 사유를 자연스러운 문장으로 바꾸는 일이다. 따라서 안전한 설계는 보통 "RPA가 가져오고, LLM이 해석하고, 규칙 엔진이 검증하고, 사람이 승인하고, RPA가 실행한다"는 형태가 된다.

가능하면 시스템 연결은 다음 우선순위로 검토하자.

화면 기반 RPA는 매우 실용적이지만 깨지기도 쉽다. 버튼 위치가 바뀌거나, 팝업 문구가 바뀌거나, 로그인 절차에 추가 인증이 생기면 로봇은 엉뚱한 칸에 입력할 수 있다. 그래서 RPA는 "마지막 선택지"가 아니라 "레거시 시스템을 다룰 때 필요한 현실적 도구"로 봐야 한다. 사용할 때는 반드시 실행 전 검증, 실행 후 대조, 실패 시 중단 규칙을 둔다.

문서 처리 자동화: 수집에서 기록까지

AI 자동화의 대표적인 출발점은 문서 처리다. 조직에는 문서가 넘친다. 견적서, 계약서, 지원서, 회의록, 고객 VOC, 장애 리포트, 세금계산서, 품의서, 법령 개정 안내, 시장 보고서가 매일 들어온다. 이 문서들을 사람이 하나씩 열어 보고, 필요한 내용을 복사하고, 양식에 맞춰 정리하는 일은 자동화 효과가 크다.

다만 문서 자동화는 "문서를 요약한다"에서 끝나면 안 된다. 실무에서는 다음과 같은 파이프라인으로 설계해야 한다.

이 구조는 거의 모든 산업에 응용된다. 채용팀은 이력서를 수집해 경력과 스킬을 요약하고, 기준 미달 또는 민감 정보가 포함된 경우 검토 큐로 보낼 수 있다. 구매팀은 견적서에서 품목·단가·납기·거래처를 추출하고, 기존 계약 조건과 다르면 승인자를 지정할 수 있다. 고객지원팀은 문의를 분류하고 답변 초안을 만들되, 환불·보상·법적 위협·개인정보 요청은 자동 발송하지 않고 담당자 검토로 보낼 수 있다.

이때 LLM에게 맡길 일과 맡기면 안 되는 일을 분명히 해야 한다. LLM은 "이 문서에서 확인되는 위험 요소를 요약하라"는 요청에는 유용하다. 그러나 "위험이 없으면 자동으로 계약을 체결하라"는 요청은 위험하다. 계약 체결, 결제, 계정 정지, 고객 통보, 법적 판단, 의료·금융 의사결정처럼 외부 효과가 큰 행위는 별도의 승인 게이트를 통과해야 한다.

인간 검토는 어디에 넣어야 하는가

인간 검토를 모든 단계에 넣으면 자동화가 느려진다. 반대로 아무 데도 넣지 않으면 사고가 난다. 핵심은 위험도에 따라 검토 위치를 다르게 정하는 것이다. 모든 업무를 같은 방식으로 승인하면 안 된다.

먼저 업무를 세 등급으로 나누어 보자.

저위험 업무는 AI가 자동으로 처리하고 사람이 나중에 샘플을 점검해도 된다. 예를 들어 하루 200건의 고객 문의를 "배송, 환불, 계정, 기타"로 분류하는 일은 일정 정확도 이상이면 자동 라우팅할 수 있다. 다만 분류 신뢰도가 낮거나 특정 키워드가 포함된 경우에는 담당자에게 보낸다.

중위험 업무는 조건부 자동화가 적합하다. 예를 들어 고객 답변 초안은 AI가 만들 수 있지만, 실제 발송은 다음 조건에 따라 나눈다. 일반 FAQ는 자동 발송하고, 환불·보상·불만 고조·VIP 고객·법적 표현이 포함되면 사람이 승인한다. n8n 같은 워크플로 도구에서도 Gmail 수신, 번역, OpenAI 기반 요약·답변 초안 작성, Slack 승인, 승인 후 발송처럼 인간 승인 단계를 중간에 끼워 넣는 구성이 자주 사용된다.²

고위험 업무는 AI가 결정을 내리는 것이 아니라 판단 자료를 준비하는 역할에 머물러야 한다. 대출 승인, 치료 권고, 계약 체결, 대규모 구매, 계정 영구 정지처럼 오류가 나면 되돌리기 어려운 일은 반드시 실행 전 승인 단계가 있어야 한다. 인간 검토를 "마지막에 대충 보는 절차"로 붙이면 형식적 승인, 이른바 고무도장 문제가 생긴다. 위험도에 따라 승인·예외 처리·감사 기록을 설계해야 하며, 무엇을 누가 어떤 근거로 승인했는지 남겨야 한다.³

Microsoft Copilot Studio의 다단계 승인 기능처럼 수동 승인, AI 승인, 조건부 분기를 조합하는 방식도 같은 흐름이다. 반복적이고 기준이 분명한 요청은 AI가 먼저 판단하되, 그 결정 자체를 다음 인간 승인 단계로 넘기거나 조건에 따라 다른 경로로 보내는 구조를 만들 수 있다.⁴

승인 게이트는 '멈춤'이 아니라 업무의 일부다

승인 단계는 자동화를 방해하는 장벽이 아니다. 오히려 자동화를 실제 업무에 넣기 위한 안전장치다. 문제는 승인 단계를 너무 허술하게 만들 때 생긴다. "확인 후 승인해주세요"라는 알림만 보내면 담당자는 무엇을 봐야 하는지 모른다. 결국 바쁜 사람은 승인 버튼만 누른다.

좋은 승인 화면에는 다음 정보가 있어야 한다.

• AI가 제안한 결론

• 결론을 뒷받침하는 원문 근거

• 누락되었거나 불확실한 정보

• 정책상 확인해야 할 체크 항목

• 승인자가 선택할 수 있는 행동

• 승인·수정·반려 사유 입력란

• 실행될 실제 후속 조치

예를 들어 환불 요청 승인 화면이라면 "고객이 화가 났습니다. 환불해 주세요"라고 보여주면 안 된다. 대신 주문번호, 결제일, 환불 가능 기간, 이전 환불 이력, 고객 문의 요약, AI가 판단한 사유, 정책상 환불 가능 여부, 예외 사유를 함께 보여줘야 한다. 승인자는 "승인", "수정 후 승인", "반려", "상위자 검토 요청" 중 하나를 선택한다.

Power Automate의 AI Builder는 GPT로 생성한 텍스트를 승인자가 검토하고 수정한 뒤 승인할 수 있는 승인 액션을 제공한다. 중요한 점은 단순히 예·아니오를 누르는 것이 아니라, AI가 만든 텍스트를 사람이 고쳐 최종 승인 텍스트로 넘길 수 있다는 점이다.⁵ 이런 방식은 고객 발송문, 임원 보고 문구, 인사 평가 문장처럼 표현의 뉘앙스가 중요한 업무에 특히 유용하다.

워크플로 엔진에서도 인간 승인 단계는 점점 표준 기능이 되고 있다. 예를 들어 Kestra는 자동화 흐름을 일시 중지하고, 승인자가 구조화된 입력으로 결정을 남긴 뒤 다시 실행을 이어 가게 하는 패턴을 제공한다. 승인자, 승인 여부, 사유를 기록해 감사 추적에도 활용할 수 있다.⁶

승인 게이트를 설계할 때는 다음 원칙을 지키자.

1. 승인 전에는 외부 실행을 하지 않는다. 고객 발송, 결제, 계정 변경, 데이터 삭제는 승인 이후에만 실행한다.

2. 승인자는 실제 책임자여야 한다. 아무나 누를 수 있는 승인 버튼은 감사 기록이 아니라 장식이다.

3. 승인 대상은 구체적이어야 한다. "이 건 처리 승인"이 아니라 "아래 금액으로 환불 메일 발송 승인"처럼 실행 내용을 명시한다.

4. 반려와 수정이 쉬워야 한다. 승인만 편하고 반려가 번거로우면 승인율은 올라가지만 안전성은 떨어진다.

5. 승인 지연도 처리해야 한다. 일정 시간 내 미승인 시 재알림, 대체 승인자, 자동 취소 규칙을 둔다.

자동 실행 전 반드시 확인할 네 가지

AI 자동화가 실제 시스템을 움직이기 시작하면 "답변 품질"보다 "실행 안전성"이 더 중요해진다. LLM이 틀린 문장을 만드는 것과, 틀린 문장을 고객 5만 명에게 보내는 것은 전혀 다른 사건이다.

자동 실행 전에는 최소한 네 가지를 확인해야 한다.

첫째, 입력 데이터가 믿을 수 있는가. 원천 시스템, 파일 작성자, 업로드 경로, 수집 시각, 중복 여부를 확인해야 한다. 잘못된 입력을 넣으면 모델이 아무리 좋아도 결과는 틀어진다. "garbage in, garbage out"은 AI 시대에도 여전히 유효하다.

둘째, 출력 형식이 검증되었는가. JSON 스키마, 필수 필드, 허용값, 날짜 형식, 금액 범위, 문자열 길이를 확인한다. 예를 들어 urgency 필드는 low, medium, high만 허용하고, refund_amount는 결제 금액보다 클 수 없게 해야 한다.

셋째, 정책과 권한을 통과했는가. 모델이 "환불 가능"이라고 말해도 실제 정책상 불가능할 수 있다. 모델의 판단과 회사 규칙은 별개다. 권한 확인, 한도 확인, 승인자 확인은 코드와 정책 엔진이 맡아야 한다.

넷째, 중복 실행을 막았는가. 자동화에서 무서운 사고 중 하나는 같은 작업이 여러 번 실행되는 것이다. 같은 송장을 두 번 등록하고, 같은 고객에게 메일을 여러 번 보내고, 같은 결제를 중복 처리하는 식이다. 모든 실행에는 고유한 작업 ID와 멱등성 키가 있어야 한다. 멱등성이란 같은 요청이 여러 번 들어와도 결과가 한 번만 반영되게 만드는 성질이다.

실무에서는 다음과 같은 실행 전 점검 구조를 둘 수 있다.

입력 수집
→ 중복 검사
→ 스키마 검증
→ AI 분류·요약
→ 정책 검증
→ 위험도 판정
→ 승인 필요 여부 결정
→ 실행 전 미리보기
→ 실행
→ 실행 결과 대조
→ 로그 저장

이 흐름에서 "실행 전 미리보기"는 매우 중요하다. 자동화가 실제로 무엇을 바꿀지 사람이 한눈에 볼 수 있어야 한다. ERP에 입력될 필드, 고객에게 발송될 문장, 변경될 상태값, 첨부될 파일이 실행 전에 표시되어야 한다.

관측가능성: 자동화가 살아 있는지 보는 눈

자동화는 만들어 놓는 순간 끝나는 것이 아니다. 오히려 운영이 시작되는 순간부터 진짜 일이 시작된다. 오늘 잘 작동한 자동화가 내일도 잘 작동한다는 보장은 없다. 입력 데이터 형식이 바뀌고, API 응답이 느려지고, 모델 버전이 바뀌고, 프롬프트가 수정되고, 사용량이 급증하고, 비용이 튀고, RPA가 화면 변경에 막힐 수 있다.

그래서 AI 자동화에는 관측가능성이 필요하다. 관측가능성이란 시스템 내부에서 무슨 일이 일어나는지 밖에서 추적하고 이해할 수 있는 능력이다. 쉽게 말해 "잘 돌아가고 있는지, 어디서 막혔는지, 왜 비용이 늘었는지, 누가 어떤 결정을 승인했는지"를 볼 수 있어야 한다.

관측가능성은 크게 세 가지로 나눌 수 있다.

로그는 "무슨 일이 있었는가"를 알려준다. 메트릭은 "얼마나 자주, 얼마나 빠르게, 얼마나 비싸게 일어났는가"를 보여준다. 트레이스는 "한 건의 작업이 어느 단계에서 오래 걸렸고 어디서 실패했는가"를 추적한다.

OpenAI의 기업용 환경에서도 감사와 규정 준수를 위한 로그 내보내기와 관측 데이터 활용이 중요해지고 있다. ChatGPT Enterprise 관련 Compliance Logs Platform은 조직이 관측성과 컴플라이언스 데이터를 JSONL 로그 형태로 내보낼 수 있게 하는 방향으로 발전하고 있다.⁷ 이는 AI 활용이 개인 실험을 넘어 조직 운영의 일부가 되면, 대화 내용보다 더 중요한 것이 "누가, 어떤 맥락에서, 어떤 시스템을 통해, 어떤 결과를 만들었는가"라는 운영 기록임을 보여준다.

무엇을 로그로 남길 것인가

로그를 남긴다고 해서 모든 원문과 응답을 통째로 저장해야 하는 것은 아니다. 오히려 민감한 고객 정보, 개인정보, 영업비밀, 의료·금융 정보가 포함된 원문을 그대로 로그에 남기면 또 다른 위험이 생긴다. 좋은 로그는 필요한 정보를 남기되 불필요한 민감 정보는 줄인다.

AI 자동화 로그에는 보통 다음 항목이 필요하다.

원문과 응답 전문을 저장해야 하는 경우도 있다. 예를 들어 법적 감사, 고객 분쟁, 금융 내부통제상 근거 보관이 필요한 업무라면 일정 기간 보관이 필요할 수 있다. 하지만 이때도 접근 권한, 암호화, 보존 기간, 마스킹 기준을 분명히 해야 한다. 단순 디버깅 목적으로 모든 프롬프트와 응답을 무기한 저장하는 습관은 위험하다.

개발 관점에서는 OpenTelemetry 같은 표준 계측 도구를 활용해 AI API 호출의 지연시간, 모델명, 토큰 사용량, 비용 추정치를 트레이스에 붙일 수 있다. Elastic의 예시는 OpenAI 응답에 포함된 사용량 정보를 활용해 토큰 수와 비용을 관측 데이터로 남기고, API 호출 성능을 대시보드에서 볼 수 있음을 보여준다.⁸

대시보드는 세 종류가 필요하다

AI 자동화 대시보드는 하나로 끝나지 않는다. 경영진, 운영자, 보안·준법 담당자가 보는 관점이 다르기 때문이다.

첫째, 운영 대시보드는 지금 시스템이 잘 돌아가는지 보여준다. 처리 건수, 대기열 길이, 실패율, 평균 처리 시간, p95 지연시간, 재시도 횟수, 외부 API 오류율을 본다. p95 지연시간은 전체 요청 중 95%가 이 시간 안에 끝난다는 뜻이다. 평균만 보면 일부 느린 요청이 가려질 수 있으므로 p95나 p99 같은 지표가 중요하다.

둘째, 비용 대시보드는 토큰 사용량과 추정 비용을 보여준다. 부서별, 워크플로별, 모델별, 사용자 그룹별 비용을 봐야 한다. 갑자기 비용이 늘었다면 사용자가 늘어난 것인지, 프롬프트가 길어진 것인지, 자동화 루프가 생긴 것인지 확인해야 한다.

셋째, 품질·거버넌스 대시보드는 AI 결과가 얼마나 신뢰할 만한지 보여준다. 승인 반려율, 수정 승인율, 인간 override 비율, 낮은 신뢰도 라우팅 건수, 정책 위반 탐지 건수, 개인정보 마스킹 실패 건수, 평가 점수 추이를 본다.

Prometheus와 Grafana를 활용한 ChatGPT 모니터링 사례에서도 요청 수, 토큰 수, 지연시간, 오류율, 비용, 사용자·팀별 사용량 같은 지표가 핵심으로 다뤄진다.⁹ 중요한 것은 도구 이름이 아니다. "AI 자동화도 운영 서비스다"라는 태도다. 데이터베이스와 결제 시스템을 모니터링하듯, AI 파이프라인도 모니터링해야 한다.

실패 알림은 '모델 오류'보다 넓게 잡아라

AI 자동화의 실패는 모델이 틀린 답을 만들 때만 발생하지 않는다. 실제 현장에서는 훨씬 다양한 실패가 생긴다. 파일이 깨졌고, OCR이 표를 잘못 읽었고, API 키가 만료되었고, 승인자가 휴가 중이고, ERP 로그인 세션이 끊겼고, 같은 웹훅이 두 번 들어왔고, 프롬프트가 너무 길어졌고, 비용 한도에 도달했을 수 있다.

따라서 실패 알림은 다음 범주로 나누어 설계한다.

알림은 많다고 좋은 것이 아니다. 모든 사소한 오류가 Slack에 쏟아지면 아무도 보지 않는다. 좋은 알림은 행동 가능해야 한다. "오류 발생"이 아니라 "송장 처리 파이프라인에서 필수 필드 invoice_number 누락으로 17건이 검토 큐에 대기 중이며, 담당자는 구매운영팀입니다"처럼 다음 행동이 보여야 한다.

알림에는 심각도도 있어야 한다. 고객 발송 실패, 결제 중복 위험, 개인정보 마스킹 실패, 비용 급증은 즉시 알림이 필요하다. 반면 내부 요약 1건 실패는 일일 리포트로 충분할 수 있다.

실패 사례 1: 과자동화가 만든 빠른 사고

한 고객지원팀이 환불 문의 자동화를 만들었다고 하자. AI는 고객 문의를 읽고 환불 가능 여부를 판단한 뒤 답변을 작성한다. 처음에는 사람이 검토했지만, 몇 주 동안 큰 문제가 없자 팀은 자동 발송으로 바꿨다. 어느 날 정책상 예외에 해당하는 프로모션 상품 문의가 대량으로 들어왔다. AI는 문맥을 잘못 이해해 환불 가능하다고 답했고, RPA는 그 답변을 고객에게 발송했다.

사고의 원인은 AI 하나가 아니다. 정책 데이터가 최신이 아니었고, 프로모션 상품이라는 위험 신호를 별도 분기하지 않았고, 자동 발송 한도가 없었고, 첫 이상 징후를 알려 주는 모니터링도 없었다. 더 큰 문제는 책임자가 불분명했다는 점이다. 고객지원팀은 "자동화가 보냈다"고 했고, IT팀은 "업무 기준은 현업이 줬다"고 했다.

이 사례의 교훈은 단순하다. 자동화 수준은 성능이 아니라 위험에 맞춰 올려야 한다. 처음부터 완전 자동화로 가는 것이 아니라, 그림자 모드로 결과를 비교하고, 제한된 범위에서 실행하고, 예외 조건을 늘리고, 모니터링을 갖춘 뒤 점진적으로 넓혀야 한다.

실패 사례 2: 잘못된 데이터 입력은 똑똑하게 확대된다

재무팀이 송장 처리 자동화를 도입했다. PDF에서 공급처, 품목, 금액, 세율, 지급기한을 추출하고, 구매주문서와 대조한 뒤 ERP에 입력하는 흐름이다. 어느 날 특정 공급처의 송장 양식이 바뀌었다. OCR은 공급가액과 부가세를 서로 바꿔 읽었고, AI 요약은 총액이 맞는 것처럼 자연스럽게 설명했다. RPA는 ERP에 값을 입력했다.

여기서 필요한 통제는 "AI에게 더 잘 읽으라고 하기"가 아니다. 금액 합계 검증, 이전 송장 양식과의 차이 탐지, 공급처별 허용 오차, 추출 신뢰도, 고액 거래 승인, 입력 후 ERP 값 대조가 필요하다. 문서 자동화에서 LLM의 요약이 그럴듯하다고 해서 필드 값이 정확하다는 뜻은 아니다.

수치가 있는 업무는 특히 규칙 검증을 강하게 붙여야 한다. 합계가 맞는지, 세율이 맞는지, 날짜가 영업일인지, 지급 계좌가 등록 계좌와 같은지, 금액이 승인 한도 안인지 확인해야 한다. LLM은 설명을 잘하지만 회계 통제 자체를 대체하지는 않는다.

실패 사례 3: 무단 실행과 권한 혼선

한 마케팅팀이 캠페인 자동화를 만들었다. 성과가 낮은 광고 소재를 AI가 분석하고, 새 카피를 생성하고, 광고 플랫폼에 업데이트하는 흐름이다. 테스트 단계에서는 내부 계정만 사용했지만, 운영 전환 과정에서 서비스 계정 권한이 과도하게 부여되었다. AI가 만든 카피가 브랜드 가이드와 맞지 않았고, 일부 문구는 사실 확인도 부족했다. 그런데 자동화는 실제 광고 계정에 바로 반영했다.

이 문제는 권한 설계 실패다. 자동화 계정은 필요한 최소 권한만 가져야 한다. 초안 생성 계정과 실제 배포 계정을 분리하고, 배포 전 승인 토큰을 요구하며, 고위험 채널은 별도 승인자를 둬야 한다. 특히 외부 고객에게 보이는 콘텐츠, 비용이 발생하는 광고 집행, 개인정보 접근, 데이터 삭제는 "AI가 제안"하는 권한과 "시스템이 실행"하는 권한을 분리해야 한다.

자동화 수준을 단계적으로 올리는 방법

안전한 조직은 자동화를 한 번에 켜지 않는다. 단계적으로 권한을 준다. 다음 네 단계로 생각하면 실무에 적용하기 쉽다.

이 단계에서 중요한 것은 되돌아갈 수 있어야 한다는 점이다. 자동화는 한 번 3단계로 올리면 영원히 3단계인 것이 아니다. 오류율이 오르거나, 입력 데이터가 바뀌거나, 정책이 바뀌거나, 담당자가 바뀌면 다시 2단계나 1단계로 낮출 수 있어야 한다. 이것을 운영에서는 롤백이라고 부른다.

또한 자동화에는 항상 "정지 버튼"이 필요하다. 비용이 급증하거나, 특정 실패율을 넘거나, 승인 큐가 폭증하거나, 정책 위반이 감지되면 자동으로 실행을 멈추고 사람에게 넘겨야 한다. 멈출 수 없는 자동화는 효율적인 것이 아니라 위험한 것이다.

비용과 지연시간도 품질이다

많은 팀이 AI 자동화 품질을 정확도만으로 본다. 하지만 운영 환경에서는 비용과 지연시간도 품질이다. 고객 문의 답변이 30초 늦어지는 것과 5분 늦어지는 것은 다르다. 내부 배치 작업이라면 10분이 괜찮을 수 있지만, 고객 채팅이라면 10초도 길 수 있다.

비용도 마찬가지다. 한 건당 20원으로 처리되던 작업이 프롬프트 변경 후 300원이 되면, 월 100만 건 처리 시스템에서는 큰 차이가 된다. 특히 긴 문서 전체를 매번 모델에 넣는 방식은 비용을 빠르게 키운다. 필요한 부분만 검색해 넣거나, 중간 요약을 캐싱하거나, 단순 분류에는 저렴하고 빠른 모델을 쓰고, 복잡한 검토에만 강한 모델을 쓰는 계층화가 필요하다.

비용 관리를 위해서는 다음 지표를 본다.

• 작업 한 건당 평균 토큰 수

• 입력 토큰과 출력 토큰의 비율

• 워크플로별 월간 비용

• 사용자·부서별 비용

• 실패한 요청에 사용된 비용

• 재시도와 반복 루프에 사용된 비용

• 모델별 비용 대비 성공률

지연시간 관리를 위해서는 전체 처리 시간뿐 아니라 단계별 시간을 봐야 한다. 수집은 빠른데 승인 대기에서 오래 걸리는지, 모델 응답이 느린지, ERP 입력이 병목인지 알아야 개선할 수 있다. 트레이스가 필요한 이유가 바로 여기에 있다.

자동화 설계서 템플릿

AI 자동화를 시작하기 전에 팀이 함께 한 장짜리 설계서를 작성하면 사고를 크게 줄일 수 있다. 다음 템플릿을 그대로 사용해도 좋다.

[자동화 이름]
예: 고객 환불 문의 분류 및 답변 초안 자동화

[목표]
무엇을 줄이고 무엇을 개선하려는가?
예: 반복 분류 시간을 줄이고, 환불 문의 답변 초안 품질을 표준화한다.

[입력]
어떤 데이터가 어디서 들어오는가?
예: Zendesk 티켓 제목, 본문, 주문번호, 고객 등급, 최근 주문 정보

[AI가 수행할 일]
예: 문의 유형 분류, 감정 강도 판단, 답변 초안 작성, 필요한 추가정보 제안

[AI가 수행하지 않을 일]
예: 실제 환불 승인, 금액 확정, 고객에게 자동 발송

[출력 형식]
예: JSON 스키마, 필수 필드, 허용값

[위험도 분기]
예: 일반 배송 문의는 자동 초안 생성, 환불·보상·법적 표현은 담당자 검토

[인간 승인 위치]
예: 환불 가능 답변은 고객 발송 전 CS 리더 승인 필요

[실행 시스템]
예: Zendesk 댓글 초안 저장, Slack 승인 요청, 승인 후 이메일 발송

[로그]
예: job_id, ticket_id, prompt_version, model, status, 승인자, 발송 여부

[모니터링]
예: 일일 처리량, 자동화율, 반려율, 수정률, 평균 응답 시간, 비용

[중단 조건]
예: 오류율 5% 초과, 반려율 30% 초과, 시간당 비용 2배 증가 시 자동 중단

[책임자]
업무 책임자, 기술 책임자, 승인 정책 책임자, 장애 대응 담당자

이 템플릿의 핵심은 "AI가 하지 않을 일"을 명시하는 데 있다. 자동화 실패는 대개 할 일을 못해서보다, 하지 말아야 할 일을 해버려서 발생한다.

실습: 구매요청 자동화 파이프라인 설계

이제 간단한 실습을 해 보자. 회사에 구매요청 메일이 들어오면 AI가 내용을 요약하고, 필요한 결재 초안을 만들고, 금액과 위험도에 따라 승인자를 지정하는 자동화를 설계한다고 하자.

먼저 입력은 구매요청 메일 본문, 첨부 견적서, 요청 부서, 희망 납기, 예산 코드다. AI는 요청 목적, 품목, 수량, 금액, 공급처, 납기, 누락 정보, 위험 요소를 추출한다. 출력은 다음과 같은 구조화 데이터로 제한한다.

{
  "request_type": "software|hardware|service|other",
  "summary": "",
  "vendor": "",
  "amount_krw": 0,
  "delivery_deadline": "YYYY-MM-DD|null",
  "budget_code_present": true,
  "risk_level": "low|medium|high",
  "missing_fields": [],
  "approval_route": [],
  "recommended_next_action": ""
}

그 다음 규칙을 붙인다. 50만 원 미만이고 등록 공급처이며 예산 코드가 있으면 팀장 승인으로 보낸다. 50만 원 이상 500만 원 미만이면 팀장과 재무 검토를 거친다. 500만 원 이상이거나 신규 공급처이면 구매팀 검토와 임원 승인을 요구한다. 개인정보 처리, 외부 데이터 이전, 보안 소프트웨어, 장기 계약이 포함되면 금액과 관계없이 보안 또는 법무 검토를 추가한다.

중요한 점은 AI가 승인자를 "마음대로" 정하지 않게 하는 것이다. AI는 위험 요소와 추천 경로를 제안할 수 있다. 하지만 실제 승인 라우팅은 회사의 승인 매트릭스, 즉 금액·부서·품목·위험도별 규칙이 결정해야 한다.

마지막으로 관측 지표를 정한다. 하루 처리 건수, 평균 승인 대기 시간, 필수 필드 누락률, AI 추출값 수정률, 반려율, 금액 구간별 처리 시간, 자동 초안 생성 비용을 대시보드로 본다. 한 달 뒤 이 지표를 보면 자동화가 정말 시간을 줄였는지, 아니면 승인 대기만 늘렸는지 알 수 있다.

운영 체크리스트

AI 자동화를 실제 업무에 넣기 전, 다음 질문에 모두 답할 수 있어야 한다.

• 이 자동화의 업무 책임자는 누구인가?

• 입력 데이터의 출처와 신뢰도는 어떻게 확인하는가?

• 개인정보나 민감 정보는 어디에서 제거하거나 마스킹하는가?

• AI 출력은 어떤 스키마로 검증하는가?

• 어떤 조건에서 자동 실행하고, 어떤 조건에서 사람에게 넘기는가?

• 승인자는 누구이며, 대체 승인자는 누구인가?

• 승인자가 무엇을 보고 판단해야 하는가?

• 같은 작업이 두 번 실행되지 않도록 막는 장치가 있는가?

• 실패하면 재시도할 것인가, 중단할 것인가, 사람에게 넘길 것인가?

• 로그에는 무엇을 남기고 무엇을 남기지 않는가?

• 비용과 지연시간은 어디서 모니터링하는가?

• 오류율이나 비용이 급증하면 자동으로 멈추는가?

• 프롬프트, 모델, 스키마, 승인 규칙의 버전은 어떻게 관리하는가?

• 운영 중 발견된 오류를 다음 개선에 어떻게 반영하는가?

이 체크리스트는 귀찮아 보이지만, 자동화가 커질수록 더 큰 시간을 아껴 준다. 작은 자동화는 담당자의 기억으로도 굴러간다. 그러나 팀 자동화, 부서 자동화, 고객-facing 자동화는 기억이 아니라 기록과 절차로 굴러가야 한다.

자동화 이후에 남는 인간의 일

AI 자동화가 잘 설계되면 사람의 일은 사라지지 않는다. 오히려 더 선명해진다. 사람은 더 이상 같은 문장을 반복해서 쓰거나, 같은 칸에 같은 값을 입력하거나, 긴 문서에서 날짜를 찾느라 시간을 쓰지 않는다. 대신 어떤 업무를 자동화할지 고르고, 기준을 만들고, 예외를 판단하고, 책임 있게 승인하고, 실패를 분석하고, 다음 버전을 개선한다.

미래의 일 잘하는 팀은 AI에게 모든 것을 맡기는 팀이 아니다. AI가 잘하는 일과 사람이 책임져야 하는 일을 분리하고, 그 사이에 검증 가능한 파이프라인을 놓는 팀이다. 질문 설계, 문맥 관리, 도구 연결, 구조화 출력까지 배웠다면 이제 한 가지를 더 붙여야 한다. 바로 운영이다.

운영 없는 자동화는 데모다. 로그 없는 자동화는 기억에 의존하는 도박이다. 승인 없는 고위험 자동화는 사고를 기다리는 장치다. 반대로 멈출 줄 알고, 기록할 줄 알고, 사람에게 넘길 줄 아는 자동화는 조직의 일하는 방식을 바꾼다.

다음 부에서는 이러한 운영 원리를 산업별 현장에 적용해 볼 것이다. 교육, 의료, 법률, 마케팅, 개발, 금융, 창작, 고객 서비스는 각기 다른 위험과 기회를 갖고 있다. 같은 ChatGPT라도 교실에서의 사용법과 금융 내부통제에서의 사용법은 다르다. 이제부터는 산업별 맥락 속에서 "어디까지 맡기고 어디서 사람이 책임질 것인가"를 더 구체적으로 살펴보자.

참고

¹RPA란? ERP 업무 자동화를 위한 ChatGPT 실전 활용법

²Multilingual email auto-replies with DeepL, GPT-4o and Slack human approval

³Human in the Loop AI: Approval Loops for Regulated Workflows

⁴Multistage and AI approvals in agent flows (preview)

⁵July 2023 updates for AI Builder

⁶Add Human-in-the-Loop Approvals to Automated Workflows

⁷ChatGPT Enterprise를 위한 새로운 규정 준수 및 관리 도구

⁸Monitor OpenAI API and GPT models with OpenTelemetry and Elastic

⁹Monitoring ChatGPT Usage and Performance with Prometheus and Grafana