AI 에이전트를 회사 업무에 붙여보려다 깨닫는 7가지 운영 리스크

AI 에이전트를 회사 업무에 붙이기 전에 확인할 것: 데모가 운영에서 터지는 7가지 지점

AI 에이전트는 채팅창 안에 있을 때보다 도구를 호출하기 시작할 때 위험해집니다. DB를 조회하고, 고객 환불을 처리하고, 파일을 삭제하고, 리서치 보고서를 저장하는 순간부터는 "똑똑한 챗봇"이 아니라 작은 업무 시스템입니다.

개인 실험이라면 실패해도 다시 실행하면 됩니다. 회사 업무에 붙이면 다릅니다. 중간에 죽은 실행을 처음부터 다시 돌릴지, 사람이 승인해야 할 작업을 어디서 멈출지, 어떤 도구를 호출했는지 누가 볼 수 있는지, API 키가 어디에 남는지까지 정해야 합니다.

결론부터 말하면, 프로덕션 AI 에이전트는 모델 성능보다 운영 기준을 먼저 봐야 합니다. AgentSpan 같은 프레임워크가 내세우는 내구 실행, 휴먼 인 더 루프, 관찰성, 재시도, 멀티 에이전트 오케스트레이션은 멋진 기능 이름이 아니라 실무에서 사고를 줄이기 위한 체크포인트입니다. Agentspan 공식 설명에서도 crash-safe 실행, human-in-the-loop, observability 같은 방향을 확인할 수 있습니다. (Agentspan 공식 사이트)

아래 기준을 통과하지 못하면, 아직 회사 업무에 직접 붙일 단계가 아닙니다.

 

개발자가 AI 에이전트를 업무 시스템에 연결하기 전 승인, 로그, 비용, 복구 체크리스트를 확인하는 모습

 

한눈에 보는 판단표

 

확인 항목	어디서 확인할까	위험 신호	안전한 기준	추천 판단
실행 상태 저장	서버, 작업 ID, 상태 DB	프로세스가 죽으면 처음부터 다시 실행	실행 ID로 이어서 실행 가능	장기 작업이면 필수
재시도와 중복 실행	도구 호출, 작업 큐, 재시도 설정	실패할 때 같은 작업을 여러 번 수행	중복 방지 키, 재시도 횟수, 작업 상태 기록	결제·메일·삭제 작업은 특히 필수
사람 승인	환불, 삭제, 외부 발송, 권한 변경	모델 판단만으로 실행	승인 대기, 거절, 재개 경로가 있음	위험 작업은 자동 실행 금지
관찰성	대시보드, 로그, 추적 정보, 토큰 사용량	어떤 도구를 불렀는지 모름	입력·출력·도구 호출·시간·비용 추적	사내 적용 전 필수
비밀값 관리	API 키, DB 계정, 환경 변수	코드·로그·프롬프트에 키가 남음	비밀값 저장소, 서버 저장, 최소 권한	공개 저장소 사용 시 필수
테스트	가짜 도구 호출, 구조화 출력 검증	실제 LLM 호출로만 테스트	모델 호출 없이 흐름 일부 검증 가능	배포 전 필수
배포 구조	worker, server, DB, 인증	로컬 실행에 의존	컨테이너, 운영 DB, 인증, worker 분리 검토	운영 환경이면 필수

 

이 표에서 중요한 것은 "무슨 프레임워크가 좋다"가 아닙니다. 프레임워크를 고를 때 무엇을 물어봐야 하는지입니다.

 

 

 

1. 중간에 죽어도 이어서 실행할 수 있는가

AI 에이전트가 짧은 질문에 답하는 정도라면 실패 비용이 작습니다. 하지만 20분짜리 리서치, 수백 건 문서 분석, 여러 API를 거치는 업무 자동화라면 이야기가 달라집니다. 네트워크가 끊기거나 worker가 재시작되거나 DB가 잠깐 멈추면, 이미 쓴 토큰과 외부 API 호출 비용이 그대로 날아갈 수 있습니다.

프로덕션에서 먼저 확인할 것은 memory가 아니라 내구 실행입니다. 실행 상태가 프로세스 안에만 있으면 프로세스가 죽는 순간 작업도 같이 사라집니다. 반대로 서버나 실행 엔진이 상태를 들고 있고 worker는 실행만 담당한다면, worker가 다시 붙었을 때 이전 단계부터 이어갈 수 있습니다.

AgentSpan 예시에서는 worker가 AgentSpan server에 연결하고, server가 실행 상태와 이력을 보관합니다. 프로세스가 죽어도 실행 ID로 다시 연결해 이전 단계부터 이어가는 식입니다. 공식 crash-resume 예시도 이 흐름을 보여줍니다. (Crash + resume 예시) 이 구조가 중요한 이유는 단순합니다. 회사 업무에서는 "다시 실행하면 되죠"가 답이 아닌 경우가 많기 때문입니다.

예를 들어 고객지원 에이전트가 주문 조회, 정책 확인, 환불 승인 대기까지 진행한 상태에서 죽었다고 해보겠습니다. 처음부터 다시 실행하면 주문 조회와 정책 확인을 반복하고, 사용자는 같은 정보를 다시 입력해야 하며, 경우에 따라 중복 환불 같은 사고도 생길 수 있습니다.

 

 

 

2. 재시도는 자동화하되 중복 실행을 막는가

재시도는 좋은 기능이지만, 잘못 쓰면 비용 폭탄이 됩니다. LLM 호출이 실패해서 다시 시도하는 것과 환불 API 호출이 실패해서 다시 시도하는 것은 같은 문제가 아닙니다.

LLM 호출이나 검색 호출은 일정 횟수 재시도해도 비교적 안전한 편입니다. 하지만 결제, 환불, 메일 발송, 파일 삭제, DB 업데이트는 다릅니다. 같은 작업이 두 번 실행되면 실제 피해가 생깁니다.

따라서 에이전트 도구를 만들 때는 "실패하면 몇 번 재시도할까"보다 먼저 "이 작업은 중복 실행되어도 안전한가"를 봐야 합니다. 안전하지 않다면 중복 방지 키, 작업 상태 테이블, 승인 기록, 중복 요청 차단이 필요합니다.

소스 강의에서 Firecrawl API key가 누락된 상태로 리서치 에이전트를 실행하자 도구 호출이 계속 재시도되는 장면이 나옵니다. 이 자체는 학습 예제지만, 운영에서는 중요한 경고입니다. 키 하나가 빠졌을 뿐인데 재시도 루프가 생기면 모델 비용, 외부 API 비용, 로그 비용이 같이 늘어날 수 있습니다.

 

 

 

3. 위험 작업은 사람 승인 없이 실행하지 않는가

AI 에이전트가 "추천"만 할 때와 "실행"까지 할 때는 설계가 달라야 합니다. 특히 환불, 삭제, 외부 발송, 권한 변경, 결제, 고객 데이터 수정은 모델이 바로 실행하면 안 됩니다.

여기서 필요한 것이 사람 승인 단계입니다. 단순히 "사람이 봐야 한다"는 말로는 부족합니다. 에이전트가 어느 단계에서 멈추고, 승인 요청에 어떤 정보가 담기고, 승인이 늦어져도 상태가 유지되고, 거절했을 때 무엇을 기록하는지까지 정해야 합니다.

AgentSpan의 human approval 예시는 approval_required=True가 붙은 도구를 호출하기 전에 실행을 멈추고, 사람이 approve 또는 reject할 수 있게 합니다. 중요한 부분은 "승인 버튼이 있다"가 아니라 "승인 대기 중에도 실행 상태가 유지된다"는 점입니다. (Human-in-the-loop 예시)

회사 업무에 붙일 때는 승인 화면에 최소한 다음 정보가 보여야 합니다.

• 어떤 작업을 하려는가
• 어떤 데이터에 영향을 주는가
• 예상 비용이나 금액은 얼마인가
• 이전에 어떤 도구 호출을 거쳤는가
• 승인 후 되돌릴 수 있는가
• 거절하면 에이전트가 어떻게 종료되는가

 

이 정보가 없으면 사람은 승인자가 아니라 도장 찍는 사람이 됩니다.

 

 

 

4. 에이전트가 무엇을 했는지 나중에 추적할 수 있는가

프로덕션 AI 에이전트에서 가장 답답한 실패는 "결과가 이상한데 왜 그런지 모르는 상황"입니다. 모델이 어떤 프롬프트를 받았는지, 어떤 도구를 불렀는지, RAG 검색에서 어떤 문서를 봤는지, 몇 토큰을 썼는지, 어느 단계에서 오래 걸렸는지 모르면 문제를 고칠 수 없습니다.

관찰성은 멋진 대시보드를 의미하지 않습니다. 최소한 다음을 확인할 수 있어야 합니다.

 

봐야 할 것	없으면 생기는 문제
각 단계의 입력과 출력	잘못된 판단이 어디서 시작됐는지 모름
도구 호출 이름과 인자	DB 조회, 파일 삭제, 외부 API 호출을 추적하지 못함
도구 결과	모델 문제인지 도구 결과 문제인지 구분 불가
토큰 사용량과 duration	비용이 어디서 늘어나는지 모름
중단 이유와 에러	재시도할 문제인지 사람이 봐야 할 문제인지 모름
실행 ID	장애 대응과 고객 문의 추적이 어려움

 

AgentSpan은 실행 화면에서 agent turn, tool call, output, token, duration 등을 보는 방식을 보여줍니다. 이런 관찰성이 없으면 에이전트는 업무 자동화가 아니라 블랙박스가 됩니다.

AI 품질 자체를 장기적으로 관리하려면 별도 평가도 필요합니다. 이 부분은 AI Evals란 무엇인가: LLM·RAG·코딩 에이전트를 위한 실전 평가 설계법과 바로 이어집니다. 에이전트 로그는 장애 대응용이고, evals는 품질이 시간이 지나도 유지되는지 보는 장치입니다.

 

 

 

5. API 키와 권한이 worker 코드에 남지 않는가

개인 실험에서는 .env 파일에 키를 넣고 바로 실행해도 됩니다. 운영에서는 그 정도로 끝나지 않습니다. 에이전트가 여러 도구를 호출할수록 키와 권한이 늘어납니다. OpenAI, Anthropic, Gemini, Firecrawl, DB, 내부 API, Slack, GitHub, 클라우드 계정 정보가 한 곳에 섞이기 시작합니다.

문제는 키가 많아지는 것만이 아닙니다. 키가 어느 위치에서 필요한지 모르면 worker 코드, 로그, 프롬프트, 저장된 trace, 예외 메시지에 비밀값이 남을 수 있습니다.

AgentSpan 예시에서는 credential을 server 쪽에 저장하고, 도구 호출 시 필요한 값을 worker 환경으로 가져오는 방식을 보여줍니다. 이 구조가 항상 정답이라는 뜻은 아닙니다. 다만 적어도 "worker 코드 안에 모든 키를 하드코딩하지 않는다"는 방향은 맞습니다.

회사 기준으로는 다음 질문에 답해야 합니다.

• 누가 secret을 만들고 바꿀 수 있는가
• worker는 필요한 순간에만 권한을 받는가
• 로그와 trace에 키 일부가 남지 않는가
• 개발/스테이징/운영 키가 분리되어 있는가
• 퇴사자나 외주 계정의 권한을 회수할 수 있는가
• 에이전트가 호출할 수 있는 API 범위가 최소화되어 있는가

 

특히 DB와 연결되는 에이전트라면 데이터베이스 구조와 권한도 같이 봐야 합니다. Postgres를 AI 에이전트와 연결하는 관점은 Ghost.build란 무엇인가? AI 에이전트를 위한 Postgres 데이터베이스 도구 쉽게 이해하기와도 맞닿아 있습니다.

 

 

 

6. Guardrail을 안전장치로 오해하지 않는가

Guardrail은 필요합니다. 하지만 guardrail을 넣었다고 바로 안전해지는 것은 아닙니다.

소스 강의에서는 "ignore previous", "system prompt", "jailbreak" 같은 문구를 입력에서 차단하는 간단한 guardrail을 만듭니다. 예제 수준에서는 좋은 출발입니다. 그러나 운영에서 이 정도는 최소 방어입니다. 공격자는 같은 의미를 다른 표현으로 말할 수 있고, RAG 문서나 도구 결과를 통해 모델 판단을 흔들 가능성도 있습니다.

따라서 guardrail은 다음 순서의 일부로 봐야 합니다.

1. 입력 guardrail: 명백한 악성 요청 차단
2. 도구 권한 제한: 모델이 호출할 수 있는 작업 자체를 줄임
3. 출력 guardrail: 민감 정보나 위험한 응답 차단
4. 승인 단계: 위험 작업은 사람에게 넘김
5. 로그와 사후 검토: 놓친 케이스를 다음 규칙에 반영

 

가장 위험한 오해는 "모델에게 하지 말라고 지시하면 된다"입니다. 프로덕션에서는 프롬프트보다 권한 경계가 먼저입니다. 모델이 실수해도 실제 시스템 피해가 작도록 도구를 좁게 설계해야 합니다.

 

 

 

7. 테스트와 배포 구조를 따로 검증했는가

에이전트 테스트는 어렵습니다. 모델 응답이 매번 조금씩 다르고, 외부 API 상태도 바뀌며, 비용도 듭니다. 그래서 많은 팀이 "한 번 돌려봤더니 되더라" 수준에서 멈춥니다.

하지만 최소한의 흐름 테스트는 필요합니다. 예를 들어 고객지원 에이전트라면 다음을 실제 LLM 호출 없이도 검증할 수 있습니다.

• 환불 정책 질문이 knowledge base 검색 도구를 호출하는가
• 주문 ID가 있으면 주문 조회 도구를 호출하는가
• 환불 실행 전 승인 대기로 멈추는가
• 구조화 출력에 stage, successful, message 같은 필드가 들어오는가
• guardrail에 걸린 입력은 모델 호출 전 차단되는가

 

이런 테스트는 모델의 "좋은 답변"을 보장하지 않습니다. 대신 업무 흐름이 최소한 잘못 연결되지 않았는지 확인합니다. 품질 평가는 별도 evals로 보고, 흐름 테스트는 배포 안정성을 위해 봐야 합니다.

그다음은 배포 구조입니다. 로컬에서 localhost 서버를 띄우고 SQLite에 상태를 저장하는 정도는 개발용으로 충분할 수 있습니다. 운영에서는 다릅니다. worker와 server가 어떻게 분리되는지, 상태 DB를 어디에 둘지, 인증은 어떻게 걸지, 여러 worker가 동시에 붙어도 괜찮은지 봐야 합니다.

AgentSpan 강의에서도 로컬 개발 뒤에는 Docker Compose, Postgres, 기본 인증, 여러 worker 연결 같은 배포 요소를 언급합니다. 여기서 배워야 할 핵심은 특정 도구 명령이 아니라 구조입니다. AI 에이전트도 결국 네트워크, 배포, DB, 인증 위에서 돌아갑니다. 컨테이너와 네트워킹 계층에서 자주 막힌다면 물리 서버, VM, Docker, Kubernetes 네트워킹 차이를 먼저 정리해두는 편이 좋습니다.

운영 배포 전에는 최소한 다음 질문에 답해야 합니다.

• 실행 상태 DB를 잃으면 어떤 업무가 영향을 받는가
• worker가 여러 대일 때 같은 작업을 중복으로 잡지 않는가
• server와 worker 사이 인증은 있는가
• 개발용 키와 운영용 키가 분리되어 있는가
• 장애 시 실행 ID로 고객 문의를 추적할 수 있는가
• 배포 중 worker가 재시작되어도 진행 중 작업이 유지되는가

 

 

 

실패 패턴: 이 신호가 보이면 아직 운영 투입 전이다

 

실패 패턴	언제 발생하는가	경고 신호	대응
죽으면 처음부터 다시 실행	긴 리서치, 대량 문서 처리, 여러 도구 호출	worker 재시작 후 이전 단계로 못 돌아감	실행 ID 기반 재개 설계
승인 없는 위험 작업	환불, 삭제, 권한 변경, 외부 발송	모델 답변 직후 API 호출	승인 단계와 감사 로그
로그 없는 도구 호출	RAG, DB 조회, 브라우저 자동화	결과만 있고 중간 호출 기록이 없음	도구 호출 입력·출력 저장
비용 재시도 루프	API key 누락, rate limit, 네트워크 장애	같은 도구 호출이 반복됨	재시도 횟수 제한, 실패 원인 분류
키 노출	빠른 실험 코드를 운영으로 복사	.env, 로그, 예외 메시지에 키가 보임	secret store, 권한 분리, 로그 마스킹
테스트 없는 구조화 출력	JSON/스키마 기반 업무 흐름	필드 누락으로 후속 단계 실패	가짜 응답 기반 스키마·흐름 테스트
로컬 서버 의존	개인 PC에서만 실행	SQLite, localhost, 수동 터미널 실행	Docker, DB, 인증, worker 분리 검토

 

이 표에서 세 개 이상 걸리면 아직 자동화 범위를 줄이는 편이 낫습니다. 특히 고객 데이터, 돈, 파일 삭제, 외부 발송이 걸린 업무라면 데모 성공만으로 배포하지 않는 것이 맞습니다.

 

 

 

이런 경우에는 아직 AI 에이전트를 쓰지 않는 편이 낫다

모든 자동화가 에이전트여야 하는 것은 아닙니다. 규칙이 명확하고 입력 형식이 일정하며 결과가 결정적인 작업은 일반 스크립트나 워크플로 도구가 더 낫습니다.

예를 들어 매일 같은 SQL을 돌려 CSV를 저장하는 작업, 정해진 폴더의 파일명을 바꾸는 작업, 특정 API를 호출해 슬랙에 알림을 보내는 작업은 에이전트가 없어도 됩니다. 여기서 LLM을 넣으면 오히려 비용과 불확실성이 늘어납니다.

또 하나 피해야 할 경우가 있습니다. 로그도 없고, 승인 단계도 없고, 되돌리기 어려운 작업입니다. 파일 삭제, 권한 변경, 외부 메일 발송, 고객 데이터 수정처럼 되돌리기 어려운 작업은 에이전트가 아니라 작은 수동 승인 도구부터 만드는 편이 낫습니다.

반대로 에이전트가 유리한 경우는 다음에 가깝습니다.

• 입력이 자연어이고 매번 조금씩 다르다
• 여러 도구 중 어떤 것을 쓸지 판단해야 한다
• 중간 결과를 보고 다음 단계를 바꿔야 한다
• 사람이 승인해야 할 지점이 있다
• 실패해도 이전 상태를 유지하고 재개해야 한다
• 실행 과정을 나중에 감사해야 한다

 

여기에 해당하지 않는다면 먼저 단순 자동화로 해결하는 편이 좋습니다. AI 에이전트는 만능 자동화가 아니라 불확실한 업무 흐름을 다루는 도구입니다.

 

 

 

도입 전 마지막 질문

AI 에이전트를 회사 업무에 붙이기 전에는 모델 이름보다 아래 질문을 먼저 던져야 합니다.

• 이 작업은 실패해도 다시 실행해도 되는가
• 중복 실행되면 실제 피해가 생기는가
• 어떤 단계에서 사람이 승인해야 하는가
• 어떤 도구 호출이 언제 실행됐는지 추적 가능한가
• API 키와 권한은 어디에 보관되는가
• 테스트는 모델 호출 없이도 일부 검증 가능한가
• worker가 죽어도 실행 상태를 복구할 수 있는가
• 운영 배포에서는 어떤 DB, 인증, 로그 구조를 쓸 것인가

 

이 질문에 답하지 못한 상태라면, 아직 에이전트의 지능을 높일 때가 아닙니다. 먼저 업무 범위를 줄이고, 권한을 제한하고, 로그와 승인 단계를 붙여야 합니다.

AI 에이전트가 실무에서 실패하는 이유는 모델이 멍청해서만이 아닙니다. 오히려 데모가 너무 쉽게 성공해서 운영 설계를 건너뛰기 때문입니다. 프로덕션에서는 "답을 잘하는가"보다 "실패했을 때 통제 가능한가"가 먼저입니다.

그 기준을 통과한 뒤에야 에이전트는 장난감 챗봇이 아니라 업무 시스템이 됩니다.