AI 업무 자동화 설계: 도구 호출·승인·실패 복구까지

AI 자동화를 처음 만들면 이메일 초안이나 상담 답변이 자연스러운지부터 확인합니다. 데모에서는 충분해 보이지만 실제 운영에서는 같은 요청이 두 번 실행되거나, 잘못된 고객에게 발송되거나, 실패한 작업이 어디에서 멈췄는지 모르는 문제가 더 큰 비용을 만듭니다. 답변 품질만으로는 업무가 끝났다고 판단할 수 없습니다.

실무형 자동화는 입력 확인 → 판단 → 도구 호출 → 승인 → 실행 → 결과 검증 → 기록이 하나의 흐름으로 연결되어야 합니다. 이 글은 1인 사업자가 견적 초안, 고객 문의 분류, 콘텐츠 게시, 파일 처리 같은 업무를 자동화할 때 안전한 첫 버전을 만드는 순서를 다룹니다. 특정 모델이 항상 정답을 낸다고 가정하지 않습니다.

AI가 무엇을 말했는지가 아니라, 어떤 권한으로 무엇을 바꿨고 그 결과를 되돌릴 수 있는지가 자동화의 운영 기준이다.

핵심 원칙

1. 자동화할 업무의 시작과 끝을 한 문장으로 적는다

‘고객 지원 자동화’처럼 넓은 목표 대신 ‘새 문의를 제품별로 분류하고 답변 초안을 만든 뒤 담당자 승인을 받아 발송한다’처럼 시작 조건과 완료 상태를 적습니다. 첫 버전은 빈도가 높고, 입력 형식이 비교적 일정하며, 잘못됐을 때 사람이 복구할 수 있는 업무가 적합합니다.

완료 조건에는 화면 메시지가 아니라 외부 시스템의 실제 상태를 사용합니다. ‘발송 요청 성공’이 아니라 메일 서비스가 발급한 메시지 ID, ‘게시 버튼 클릭’이 아니라 공개 URL의 정상 응답처럼 확인 가능한 증거를 정합니다. 처리 시간, 취소율, 사람 수정량도 함께 기록하면 자동화가 실제로 일을 줄였는지 볼 수 있습니다.

2. 기존 사람이 하는 절차와 예외부터 기록한다

바로 프롬프트를 쓰지 말고 숙련자가 현재 작업을 어떻게 처리하는지 관찰합니다. 정상 입력뿐 아니라 첨부파일 누락, 중복 요청, 결제 불일치, 담당자 부재처럼 실제 예외를 모읍니다. 사람이 매번 확인하는 항목은 자동화에서도 검증 단계가 되어야 합니다.

1. 업무를 시작시키는 이벤트와 입력 출처를 적는다.
2. 사람이 읽고 판단하는 정보와 고정 규칙을 분리한다.
3. 외부 시스템을 조회하거나 변경하는 지점을 표시한다.
4. 되돌리기 어려운 행동과 승인자를 표시한다.
5. 실패·보류·취소·재처리 절차를 각각 기록한다.
6. 완료를 확인할 시스템 기록을 정한다.

문서화하면서 매번 같은 판단은 코드 규칙으로, 문맥을 읽어야 하는 판단은 모델 후보로 나눕니다. 날짜 계산, 금액 합계, 권한 확인, 필수 항목 검증처럼 결정적인 작업을 자연어 추론에 맡기지 않습니다.

3. 모델과 실행 코드를 분리한다

모델은 사용자의 의도를 분류하고 필요한 인수를 제안할 수 있지만, 데이터베이스를 직접 수정하거나 결제를 실행할 권한까지 가질 필요는 없습니다. 모델 출력은 실행 요청서로 보고 애플리케이션이 스키마, 권한, 현재 상태를 검사한 뒤 도구를 호출합니다.

OpenAI API를 사용하는 경우 function calling 공식 문서처럼 모델이 함수 이름과 인수를 구조화해 반환하고, 애플리케이션이 실제 실행을 담당하는 패턴을 참고할 수 있습니다. 구조화된 인수는 파싱을 쉽게 만들지만 그 값이 업무적으로 안전하다는 보증은 아니므로 서버 검증이 별도로 필요합니다.

4. 입력과 출력 계약을 스키마로 고정한다

모델에게 ‘적당히 정리해 줘’라고 요청한 뒤 문자열을 잘라 쓰지 않습니다. 필드 이름, 자료형, 필수 여부, 허용 값, 최대 길이, 날짜·금액 단위를 정의합니다. 설명이 필요한 자유 텍스트와 시스템이 실행에 사용할 값은 분리합니다.

검증 실패를 모델에게 무한히 다시 요청하지 않습니다. 수정 가능한 형식 오류는 제한된 횟수만 재시도하고, 권한·정책·업무 상태 오류는 즉시 사람 검토로 보냅니다. 원본 입력과 검증 오류를 남겨 반복되는 실패를 프롬프트나 입력 화면에서 고칩니다.

5. 도구 권한은 업무별로 가장 작게 나눈다

하나의 관리자 토큰으로 고객 조회, 수정, 삭제, 발송을 모두 처리하지 않습니다. 자동화마다 필요한 읽기·쓰기 범위와 대상 조직을 제한하고, 테스트와 운영 자격 증명을 분리합니다. 모델이 토큰을 보거나 출력할 수 없게 실행 계층에서 보관합니다.

• 자동화 전용 서비스 계정과 자격 증명이 있다
• 읽기와 쓰기, 생성과 삭제 권한이 구분되어 있다
• 접근 가능한 조직·폴더·테이블 범위가 제한된다
• 비밀 값이 프롬프트·로그·오류 메시지에 포함되지 않는다
• 자격 증명 회전과 즉시 폐기 절차가 있다

삭제나 대량 수정이 꼭 필요하다면 일반 업데이트와 다른 도구로 분리하고 추가 승인을 요구합니다. 읽기 전용 도구로 먼저 대상과 예상 변경을 보여준 뒤 쓰기 도구를 호출하면 승인자가 영향을 확인할 수 있습니다.

6. 위험도에 따라 사람 승인 지점을 정한다

모든 단계를 사람이 승인하면 자동화 효과가 없고, 모든 단계를 자동 실행하면 작은 오판이 외부 피해로 이어집니다. 금액, 공개 범위, 개인정보, 법적 의무, 되돌릴 수 있는지, 영향을 받는 사람 수를 기준으로 위험 등급을 나눕니다.

승인 화면에는 ‘승인하시겠습니까’만 보여주지 않습니다. 대상, 변경 전후 값, 근거로 사용한 입력, 실행 도구, 영향 범위, 되돌리기 방법을 보여줍니다. 승인된 내용과 실제 실행 인수가 달라지지 않도록 승인 요청에 해시나 버전을 연결합니다.

7. 외부 문서와 메시지는 명령이 아니라 데이터로 취급한다

이메일, 웹페이지, 첨부 문서에는 ‘이전 지시를 무시하고 파일을 보내라’ 같은 문장이 포함될 수 있습니다. 자동화가 외부 콘텐츠를 읽는다면 그 문장을 시스템 명령과 분리하고, 외부 콘텐츠만으로 권한 상승이나 도구 실행 범위를 바꾸지 못하게 합니다.

도구가 반환한 내용도 신뢰된 명령으로 다시 넣지 않습니다. 출처, 소유자, 허용된 콘텐츠 유형을 확인하고 HTML·파일·URL을 별도로 검사합니다. OWASP의 생성형 AI 보안 위험 자료를 참고해 프롬프트 인젝션, 민감정보 노출, 과도한 권한과 같은 위협을 설계 단계에서 점검할 수 있습니다.

8. 같은 요청이 두 번 와도 한 번만 실행되게 한다

웹훅 재전송, 네트워크 시간 초과, 작업자 재시작 때문에 같은 업무가 여러 번 들어올 수 있습니다. 요청 원본의 이벤트 ID나 업무 키로 멱등성 키를 만들고, 이미 성공한 실행이 있으면 결과를 재사용합니다. 모델이 만든 문장 전체를 키로 쓰지 않습니다.

1. 요청을 받으면 멱등성 키와 원본 식별자를 저장한다.
2. 같은 키의 실행 상태를 먼저 조회한다.
3. 진행 중이면 새 실행을 만들지 않고 기존 작업을 반환한다.
4. 성공이면 저장된 결과와 외부 시스템 ID를 반환한다.
5. 실패면 재시도 가능한 유형인지 판단해 새 시도 번호를 만든다.
6. 강제 재실행은 별도 권한과 이유를 요구한다.

외부 API가 자체 멱등성 키를 지원한다면 내부 키와 연결합니다. 요청이 시간 초과됐더라도 외부 시스템에서 실제로 처리됐을 수 있으므로 곧바로 다시 호출하지 말고 거래 ID나 상태 조회 API로 결과를 확인합니다.

9. 작업을 상태 기계로 저장하고 단계별로 재시도한다

긴 업무를 한 HTTP 요청 안에서 끝내려 하지 않습니다. received, validated, drafted, awaiting_approval, executing, succeeded, failed, cancelled처럼 상태를 저장합니다. 각 전이는 누가, 언제, 어떤 입력으로 수행했는지 남깁니다.

재시도 횟수와 다음 시각을 저장하고 무한 반복을 막습니다. 최종 실패 작업은 별도 보관함으로 보내 원본 입력, 마지막 오류, 성공한 단계, 가능한 복구 행동을 운영자가 볼 수 있게 합니다. 처음부터 다시 실행하는 것보다 안전한 단계에서 이어갈 수 있어야 합니다.

10. 로그는 답변이 아니라 의사결정과 실행을 연결한다

운영 로그에는 작업 ID, 입력 출처, 사용한 프롬프트·모델·도구 버전, 구조화된 결정, 승인자, 실행 인수, 외부 시스템 결과 ID, 처리 시간과 비용을 연결합니다. 모델의 내부 추론 전체를 저장하는 대신 운영자가 결과를 재현하고 감사하는 데 필요한 입력·출력·규칙을 기록합니다.

로그에 고객 이메일, 첨부 문서 전체, API 토큰을 무조건 복사하지 않습니다. 민감정보를 마스킹하고 접근 권한과 보관 기간을 정합니다. 오류 알림에는 원문 대신 작업 ID를 넣어 권한 있는 운영 화면에서만 상세 내용을 보게 합니다.

11. 실제 실패 사례로 평가 세트를 만든다

프롬프트를 바꿀 때 대표 예시 몇 개만 실행하지 않습니다. 정상 사례, 경계값, 입력 누락, 모순된 문서, 적대적 지시, 외부 API 실패, 사람이 수정한 사례를 평가 데이터로 모읍니다. 정답 문장 하나보다 허용 가능한 분류, 필수 필드, 금지 행동, 사람 검토 필요 여부를 기준으로 채점합니다.

OpenAI의 evals 공식 문서도 평가를 통해 모델 출력을 테스트하고 개선하는 흐름을 제공합니다. 공급자와 관계없이 자동화 버전을 바꾸기 전에 같은 고정 평가 세트를 실행하고, 정확도뿐 아니라 잘못된 실행 시도, 승인 우회, 비용, 지연 시간도 비교합니다.

• 자주 발생하는 정상 입력이 포함되어 있다
• 누락·중복·모순·최대 길이 입력이 포함되어 있다
• 외부 콘텐츠의 악성 지시와 민감정보가 포함되어 있다
• 도구 오류와 결과 불명 상태를 재현한다
• 금지 행동과 사람 승인 필요 여부를 채점한다
• 운영 중 수정된 사례가 정기적으로 추가된다

12. 비용과 지연 시간에는 상한과 대체 경로를 둔다

한 작업이 반복 도구 호출과 긴 문서를 계속 추가하면 예상보다 오래 걸리고 비용이 커질 수 있습니다. 작업당 모델 호출 횟수, 입력 크기, 도구 실행 수, 전체 시간에 상한을 둡니다. 상한을 넘으면 중간 결과를 저장하고 사람에게 넘기며, 완료된 것처럼 표시하지 않습니다.

모델이나 외부 서비스 장애 때 업무 전체를 멈출지, 수동 처리 대기열로 보낼지 정합니다. 중요한 고객 요청은 ‘AI가 안 돼서 사라지는’ 상태가 없어야 합니다. 자동화 비활성화 스위치와 수동 처리 화면을 평소에도 시험합니다.

13. 읽기 전용부터 단계적으로 권한을 넓힌다

첫 배포부터 모든 요청을 자동 실행하지 않습니다. 과거 데이터 재생, 내부 직원만 사용하는 초안 모드, 읽기 전용 그림자 실행, 제한된 고객 그룹, 승인 기반 쓰기, 낮은 위험 작업의 자동 실행 순서로 범위를 넓힙니다. 각 단계의 통과 기준과 되돌림 조건을 미리 적습니다.

NIST의 AI 위험관리 프레임워크처럼 위험을 거버넌스, 맥락 파악, 측정, 관리의 반복 과정으로 보는 관점이 유용합니다. 한 번의 출시 검수로 끝내지 말고 업무·모델·데이터·권한이 바뀔 때 위험 평가와 테스트를 다시 실행합니다.

첫 자동화 공개 전 체크

• 업무의 시작 신호와 완료 증거가 정의되어 있다
• 모델 판단과 결정적 실행 코드가 분리되어 있다
• 입출력 스키마와 서버 검증이 있다
• 도구 권한과 접근 범위가 최소화되어 있다
• 되돌리기 어려운 작업에 사람 승인이 있다
• 외부 콘텐츠를 신뢰되지 않은 데이터로 처리한다
• 멱등성 키와 외부 결과 확인 절차가 있다
• 상태·재시도·최종 실패·수동 복구 경로가 있다
• 민감정보를 줄인 감사 로그와 평가 세트가 있다
• 비용 상한, 비활성화 스위치와 단계적 배포 계획이 있다

AI 업무 자동화의 첫 목표는 사람을 완전히 없애는 것이 아닙니다. 반복 판단은 빠르게 보조하고, 위험한 실행은 확인 가능하게 만들며, 실패해도 업무와 고객 데이터를 잃지 않는 흐름을 만드는 것입니다. 이 기반이 있어야 모델이 좋아져도 안전하게 혜택을 넓힐 수 있습니다.