이해하는 AI에서 완수하는 AI로

병원 업무 후보 50개를 조사하며 생각한 AI 자동화의 설계 과제

AI가 진료 의뢰서를 읽고 필요한 정보를 추출했다. 화면에는 항목별로 정리된 결과가 나타난다. 데모에서는 꽤 그럴듯한 장면이다.

그런데 이 결과를 받은 담당자의 일은 끝났을까?

추출된 내용을 확인하고, 기존 시스템에 입력하고, 빠진 자료를 요청하는 일이 남아 있다. 등록 중 오류라도 나면 어디까지 처리됐는지부터 다시 살펴야 한다. AI가 문서를 읽었다고 해서 사람이 하던 일까지 끝난 것은 아니다.

이 문제를 살펴보려고 병원 업무 후보 50개를 조사했다. 먼저 AI가 보여주는 기능보다 담당자가 반복하는 일이 실제로 얼마나 줄어드는지 보고 싶었다. 업무를 줄이려면 어떤 조건이 갖춰져야 하는지도 함께 확인했다.

이 글에서는 조사 과정에서 반복해서 마주친 자동화 설계 문제를 정리한다.

업무를 먼저 조사한 이유

“문서를 요약할 수 있다”, “엑셀을 분석할 수 있다”는 설명은 기능을 소개할 때 유용하다. 하지만 병원에서 이 기능을 도입할 이유까지 설명해 주지는 못한다. 업무에서 차지하는 비중이 작을 수도 있고, AI의 결과를 다시 확인하느라 기존과 비슷한 시간이 들 수도 있다.

그래서 기능 목록부터 만들지 않고 담당자가 일을 처리하는 순서부터 따라가 봤다.

진료 의뢰서를 접수하는 직원이 어떤 자료를 받아 무엇을 확인하고 어느 시스템에 입력하는지 살폈다. 자료가 빠지면 누구에게 연락하는지, 답변이 오면 기존 건과 어떻게 연결하는지도 확인했다. 그 과정을 따라가며 자동화할 작업과 사람이 판단할 부분을 나눴다.

이런 질문을 바탕으로 진료의뢰 접수, 기업검진 행정, 의무기록 미비 점검, 구매 정산, 청구·입금 대조 등 50개 후보를 정리했다.

이 목록이 곧 50건의 자동화 성공 사례를 뜻하지는 않는다. 공개된 도입 사례와 직무 설명, 업무 자료, 제품·추진 계획을 함께 검토했고, 실제 도입이 확인된 작업과 업무의 존재만 확인된 작업, 인접 사례에서 확장한 가설을 구분했다.

서로 다른 업무에서 찾은 공통 흐름

처음 병원 업무 사례를 분석할 때는 업무 명칭이 달라 서로 관련이 없어 보였다. 그런데 처리 과정을 단계별로 나누자 공통된 패턴이 드러났다.

• 진료의뢰 접수 업무: 문서에서 정보를 읽고 기존 대상과 대조한 뒤 등록.
• 구매 정산 업무: 발주·입고·청구 자료를 읽고 수량과 금액을 비교.
• 기업검진 행정 업무: 대상자 명단과 예약·수검 현황을 맞추고 미완료 건을 추적.

이 업무들을 단계별로 나눠 보니 그림 1과 같은 공통 흐름이 드러났다.

그림 1. 병원 업무 후보에서 정리한 공통 처리 흐름. 정상 처리와 검증 단계의 예외 경로를 보여주는 설계 개념도이며, 실제 시스템의 모든 장애 경로를 나타낸 것은 아니다.

1. 자료를 받아 필요한 항목을 추출하고, 기존 데이터와 규칙에 맞는지 검증한다.
2. 실행할 권한과 승인 조건을 확인한 뒤 작업을 수행하고, 마지막으로 실제 처리 결과까지 확인한다.
3. 누락이나 불일치가 생기면 사람이 검토하거나 추가 자료를 기다린다.
4. 이후 보완된 내용이 조건에 맞는지 다시 검증한 뒤 다음 단계로 넘어간다.

이 흐름을 바탕으로 공통 처리 구조는 함께 쓰고, 업무별 규칙과 연결 대상만 따로 관리할 수 있다고 봤다. 실제 적용으로 검증해야 하지만, 서로 다른 업무를 같은 기준으로 비교하는 데는 쓸 수 있었다.

예를 들어 문서 접수와 처리 이력은 공통으로 사용할 수 있다. 반면 의뢰서의 필수 항목, 구매 정산의 허용 오차, 검진 계약의 단가 기준은 업무별로 달라야 한다. 시스템에 입력하는 방식 역시 병원마다 확인해야 한다.

처리 방식의 뼈대는 재사용할 수 있어도, 업무 규칙을 모든 병원에 그대로 적용할 수는 없다.

문서 처리에서 후속 시스템 입력까지

영국 Cambridgeshire Community Services NHS Trust는 진료 의뢰 업무에 ‘Ada’라는 자동화를 도입했다.

Ada는 UiPath 자동화 플랫폼을 기반으로 구축한 ‘디지털 워커’를 말한다. 생성형 AI 제품 사례라기보다, 문서에서 데이터를 읽고 검증해 후속 시스템에 입력하는 업무 자동화 사례에 가깝다.

NHS Shared Business Services가 공개한 자료에 따르면, Ada는 들어온 의뢰서의 데이터를 추출·검증하고 후속 시스템에 입력한다. 2025년 4월 운영을 시작했으며, 평균 의뢰 처리 시간이 약 40분에서 5분 미만으로 줄고 월 116시간 이상의 직원 업무시간이 절감됐다고 보고됐다. NHS SBS의 Ada 도입 사례

Ada는 문서를 읽는 데 그치지 않고 추출한 정보를 검증해 후속 시스템에 입력하는 단계까지 자동화했다.

다만 이 수치는 NHS SBS가 공개한 사례 자료에 나온 자체 보고값이다. 한 기관의 성과를 다른 병원이나 자동화 환경에 그대로 적용할 수는 없다. 병원마다 문서와 시스템, 예외 비율이 다르고, 공개된 시간 절감이 실제 인원 감축을 뜻하는 것도 아니다.

이 수치를 보편적인 성과 기준으로 쓰지는 않았다. 대신 문서 판독을 후속 시스템 입력까지 연결했다는 점에 주목했다.

이를 바탕으로 문서 처리를 어디까지 연결해야 담당자가 다시 손대는 일이 줄어드는지 살펴봤다.

형식과 내용의 정확성을 검증하는 방법

이런 업무에서 AI 모델의 역할은 문서의 항목을 해석하고 정해진 구조에 맞춰 값을 추출하는 범위로 좁힐 수 있다.

예를 들어 Gemini API의 구조화된 출력 기능은 JSON Schema에 맞춘 응답을 생성하도록 설정할 수 있다. 그러나 Google의 공식 문서도 출력값을 애플리케이션에서 검증하고, 형식은 맞지만 의미상 잘못된 결과를 처리하도록 안내한다. Gemini API 구조화된 출력 문서

숫자 칸에 숫자가 들어 있고 날짜 형식이 맞는다고 해서, 값까지 정확한 것은 아니다. 모델이 의뢰일 대신 출력일을 읽었을 수도 있다.

이런 오류를 확인하려면 추출한 값과 함께 출처를 남겨야 한다. 어떤 문서의 어느 페이지에서 읽었는지, 원문에는 어떻게 적혀 있었는지, 어떤 변환을 거쳤는지를 기록한다. 모델이 표시한 위치도 실제 원문과 맞는지 확인한다.

원문에서 확인할 수 없는 값은 임의로 채우지 않는다. 누락이나 불확실로 표시하고, 필수 항목이 비어 있으면 다음 단계로 넘기지 않는다.

이 지점부터는 AI, 프로그램, 실행 계층의 역할을 나눠야 한다.

• AI는 다양한 표현과 배치를 해석해 항목을 찾는다.
• 프로그램은 필수값, 코드, 계산식, 중복 여부처럼 명시할 수 있는 조건을 검사한다.
• 실행 계층은 현재 사용자의 권한과 승인 상태를 확인한 뒤 허용된 작업만 수행한다.

예를 들어 발주 수량이 20개이고 납품서에 18개가 적혀 있다면, 문서에서 ‘18’을 찾아내는 데 모델을 활용할 수 있다. 하지만 차이 2개를 계산하는 일은 코드로 수행하면 된다. 그 차이가 분할 납품인지 오배송인지는 별도의 근거나 담당자 확인 없이는 확정하지 않는다.

모델은 문서를 해석하되, 실행 권한까지 판단해서는 안 된다.

문서 내용은 처리할 데이터이지 시스템 권한을 바꾸는 명령이 아니다. 문서에 어떤 문장이 적혀 있어도 승인 절차나 허용된 실행 범위가 바뀌지 않도록 분리해야 한다. 외부 API에 보내는 데이터의 범위, 보관 조건, 접근 권한도 실제 병원 자료를 사용하기 전에 정해야 한다.

연결 오류 이후의 재실행 판단

추출과 검증이 끝나도 등록 과정에서 문제가 생길 수 있다. 시스템에 등록 요청을 보낸 직후 연결이 끊기면 화면에는 오류가 나타나도 대상 시스템에서는 등록이 완료됐을 수 있다. 반대로 요청 자체가 도착하지 않았을 수도 있다. 이 상태에서 무조건 다시 실행하면 중복 등록이 생길 수 있다.

처리 결과를 확인하지 않은 채 실패로 표시하면 담당자는 재실행해도 된다고 오해할 수 있다. 따라서 처리 상태를 성공, 실패, 결과 미확인으로 나눠야 한다.

업무별 식별자와 단계별 처리 이력을 남겨야 한다. 재시도하기 전에는 대상 시스템에서 실제 처리 결과를 확인한다.

그림 2. 연결 오류 이후의 결과 확인과 재시도 판단. 결과가 불확실할 때 미등록으로 처리하지 않는 흐름을 보여준다.

이미 등록된 건은 다시 실행하지 않는다. 미등록이 확인된 건은 권한과 중복 방지 조건을 점검한 뒤 재시도한다. 조회만으로 처리 여부를 판단하기 어려우면 보류하고 담당자에게 넘긴다. 조회 결과가 없을 때는 다른 처리 기록까지 확인한 뒤 미등록 여부를 판단한다.

같은 요청을 여러 번 보내도 최종 결과가 한 번 보낸 것과 같도록 하는 성질을 멱등성이라고 한다. 대상 시스템이 이를 지원하지 않으면 등록 이력을 대조해야 한다. 그래도 처리 여부를 판단할 수 없는 건은 담당자가 확인한다.

업무가 끝났다고 보는 시점도 따로 정해야 한다. 모델이 응답을 생성했다고 접수 업무까지 끝난 것은 아니다. 접수 자동화라면 대상 시스템에서 등록 번호가 생성됐는지, 등록된 내용이 원문과 일치하는지까지 확인해야 할 수 있다. 완료 조건은 업무마다 다르다.

담당자에게 넘길 때도 “오류가 발생했습니다”라는 문구만 보여주면 안 된다. 무엇이 문제인지, 어디까지 처리됐는지, 담당자가 무엇을 결정해야 하는지 함께 전달해야 한다. 그렇지 않으면 직원이 문서를 처음부터 다시 읽으며 처리 상태를 찾아야 한다.

사용자에게 필요한 정보만 보여주기

이런 예외와 복구 과정을 설계하다 보면 화면에도 많은 정보를 넣고 싶어진다. 하지만 내부 처리가 복잡하다고 사용자가 그 구조를 모두 알아야 하는 것은 아니다.

현업 담당자는 모델을 고르거나 긴 프롬프트를 쓸 필요가 없다. 화면에는 ‘의뢰서 접수’, ‘납품 수량 확인’처럼 익숙한 업무 이름이 보여야 한다. 실행 뒤에는 진행 상태와 담당자가 판단해야 할 건만 구분해 볼 수 있으면 된다.

수량이 다른 건이라면 원문과 대조값, 차이가 난 항목, 다음에 할 수 있는 일을 한 화면에 보여준다. 담당자는 모든 결과를 다시 읽지 않고 시스템이 풀지 못한 문제만 판단한다.

모니터링 화면도 로그의 양보다 업무 상태가 먼저 보여야 한다. 확인 대기, 연결 중단, 등록 결과 재확인 중을 구분해야 한다. 담당자가 화면을 계속 지켜봐야만 안전하다면, 그 감시 시간도 새로운 업무가 된다.

UI는 예외 처리와 오류 복구에 드는 시간을 좌우한다. 따라서 화면 설계도 자동화 범위와 함께 정해야 한다.

자동화 효과를 측정하는 기준

자동화 효과는 추출 정확도 하나로 판단하기 어렵다. 담당자의 일이 실제로 얼마나 줄었는지 보려면 다음 항목을 함께 확인해야 한다.

자동 완료율을 보고할 때는 대상 범위도 함께 밝혀야 한다. 정상 서식만 선별한 결과인지, 전체 접수 건을 대상으로 한 결과인지에 따라 의미가 달라진다.

사람이 직접 작업한 시간과 접수부터 완료까지 걸린 전체 경과시간도 구분해야 한다. 사람의 손은 덜 가더라도 예외 건이 오래 대기한다면 서비스 지연은 그대로일 수 있다.

이 글에서는 순절감 작업시간을 동일한 업무량과 유사한 난이도를 기준으로 계산한다. 도입 전 사람의 작업시간에서 도입 후 준비·검토·예외 처리·재작업·감시 시간을 빼는 방식이다.

시간이 줄었다고 인건비가 같은 비율로 줄어드는 것도 아니다. 다른 업무에 재배치되는지, 초과근무가 줄어드는지, 외주나 추가 채용 수요가 줄어드는지를 구분해야 한다. 비용 효과를 계산할 때는 API 사용료와 유지보수, 내부 운영 부담도 반영해야 한다.

처음부터 모든 업무를 연결하기보다 범위가 분명한 한 업무부터 검증하는 편이 낫다. 승인된 시험 자료를 사용해 자동화 결과를 기존 처리 결과와 비교하고 예외와 장애 상황을 시험한 뒤, 확인된 범위부터 실제 실행으로 넓힌다.

완수하는 AI의 중단 조건

병원에서 반복되는 일 50개를 정리해 보니, 어떤 기능을 만들지와 그 앞뒤의 일을 어떻게 연결할지가 모두 중요했다.

자동화를 설계하려면 문서 이해와 함께 검증 규칙, 시스템 연결, 처리 상태, 실패 복구, 예외 검토 화면을 다뤄야 한다. 하나라도 빠지면 남은 작업은 다시 사람에게 돌아간다.

이 글에서 ‘완수하는 AI’는 모델 하나가 아니라 AI 모델과 검증 규칙, 시스템 연결, 처리 이력을 묶은 업무 자동화 체계를 뜻한다. 정해진 범위의 일은 결과를 확인할 때까지 처리하고, 불확실하면 멈춘다. 사람이 이어받을 때는 판단에 필요한 근거와 현재 상태를 남긴다.

병원 자동화의 효과는 담당자의 후속 작업이 얼마나 줄었는지로 판단해야 한다. 다시 입력하고 확인하고 처리 결과를 찾는 시간이 실제로 줄어야 한다.

AI에게 일을 맡기려면 시작뿐 아니라 완료 조건과 중단 조건까지 함께 설계해야 한다.