LLM Agent를 붙였는데도 일이 안 줄어드는 이유: 운영 레이어 5가지

LLM Agent를 붙이면 일이 줄어들 것 같았다. 문서를 읽고, 요약하고, 필요한 시스템을 호출하고, 결과를 보내면 된다. 데모에서는 대체로 잘 된다.

그런데 실제 업무에 붙이면 이상한 일이 생긴다. 답변은 빨라졌는데 사람의 확인 업무는 그대로다. 자동화는 하나 늘었는데 예외가 생길 때마다 더 많은 사람이 호출된다. 도구를 연결했더니 권한과 책임의 경계가 모호해진다.

이 문제는 모델이 덜 똑똑해서만 생기는 일이 아니다. Agent를 ‘답변 기능’으로 도입하고, 정작 일을 줄이는 운영 레이어는 비워 두었기 때문이다.

내가 AI 제품과 업무 자동화를 볼 때 먼저 보는 것은 모델 종류가 아니다. 아래 다섯이다.

1. 문제 경계: 무엇을 자동화하고, 무엇은 자동화하지 않을 것인가

“문의 대응을 Agent로 자동화한다”는 너무 큰 문장이다. 실제로는 다음처럼 잘라야 한다.

어떤 입력에서 시작하는가?
성공한 결과는 무엇인가?
어떤 경우에는 사람에게 넘겨야 하는가?
이 흐름이 실패해도 고객·매출·신뢰에 큰 손상이 없는가?

좋은 첫 자동화는 제일 어려운 업무가 아니다. 반복되고, 기준이 비교적 분명하고, 실패해도 되돌릴 수 있는 일이다. ‘모든 문의를 자동 답변’하기보다, ‘정해진 형식의 내부 문서를 찾아 담당자에게 초안을 전달’하는 편이 훨씬 안전하다.

나도 같은 기준으로 포기한 자동화가 있다. “슬랙에 오는 질문을 Agent가 알아서 답한다”는 경계가 너무 넓었다. 입력도, 성공 기준도, 실패했을 때 피해 범위도 한 문장으로 안 잘렸다. 대신 “정해진 폴더의 RFC를 읽고 리뷰 코멘트 초안만 남긴다”처럼 잘라야 운영이 된다.

2. 데이터와 권한: Agent가 무엇을 알고, 무엇을 해도 되는가

Agent에게 문서를 연결하는 순간부터, 문제는 검색 정확도만이 아니다. 어떤 문서를 읽어도 되는지, 답변에 어떤 정보가 섞이면 안 되는지, 누구의 권한으로 외부 시스템을 호출하는지를 정해야 한다.

데이터 경계가 불분명하면 둘 중 하나가 생긴다. Agent가 너무 많이 읽어서 위험해지거나, 너무 적게 읽어서 쓸모없어지는 일이다.

그래서 ‘RAG를 붙였다’보다 먼저 물을 질문은 이것이다.

이 Agent는 어떤 역할의 사용자를 대신하며, 그 역할이 원래 볼 수 있던 정보와 할 수 있던 행동만 수행하는가?

권한, 감사 로그, 데이터 보존은 나중에 붙이는 보안 옵션이 아니다. 제품이 실제 업무 안으로 들어가기 위한 기본 설계다.

3. 도구와 상태: 한 번의 호출이 아니라 되돌릴 수 있는 흐름인가

Agent가 API를 호출해 티켓을 만들고, 고객 정보를 바꾸고, 결제를 요청할 수 있다면 결과만 맞는 것으로는 부족하다. 중간에 실패하면 어디까지 실행됐는지, 다시 실행해도 중복되지 않는지, 사람이 중간에 멈추거나 수정할 수 있는지가 중요하다.

업무 자동화는 대화가 아니라 상태를 바꾸는 일이다. 그래서 좋은 흐름은 다음을 가진다.

각 단계의 입력과 결과가 남는다.
같은 요청을 다시 실행해도 의도치 않은 중복이 생기지 않는다.
실패한 단계만 재시도할 수 있다.
사람이 현재 상태를 보고 개입할 수 있다.

‘툴을 많이 연결한 Agent’보다 ‘실패했을 때 복구 경로가 보이는 워크플로우’가 실제로 오래 남는다.

4. 사람의 승인과 예외: 사람을 빼는 대신, 판단 지점을 남겨야 한다

사람을 완전히 없애는 게 자동화의 목표는 아니다. 사람의 시간을 판단이 필요한 곳으로 옮기는 편이 더 현실적이다.

승인이 필요한 지점은 미리 정할 수 있다. 금액이 일정 수준을 넘는 경우, 고객에게 외부 메시지를 보내는 경우, 불확실성이 높은 경우, 정책 해석이 필요한 경우가 그렇다.

‘사람 검토’라고 적어 두는 것만으로는 안 된다. 사람이 무엇을 보고 어떤 선택지를 고르는지까지 설계해야 한다. 승인 화면에 원문 근거, Agent의 판단, 실행 예정 행동, 되돌리는 방법이 함께 있어야 한다.

사람이 마지막에 다시 처음부터 판단해야 한다면 Agent는 일을 줄이지 못한다. 반대로 사람이 빠르게 승인·수정·반려할 수 있다면, 그때부터 자동화는 조직의 속도를 높인다.

5. 관측성과 비용: 잘 된 한 번보다, 나쁜 열 번을 빨리 찾는 능력

Agent는 항상 조금씩 틀린다. 그래서 운영에서 물어볼 질문은 ‘정확도가 몇 퍼센트인가’ 하나가 아니다.

어떤 입력에서 자주 실패하는가?
사람이 가장 자주 수정하는 단계는 어디인가?
도구 호출 비용은 어느 구간에서 급증하는가?
자동화가 만든 결과가 실제로 다음 업무 시간을 줄였는가?

이 질문에 답할 로그와 지표가 없으면, 팀은 데모에서 받은 느낌으로만 제품을 돌리게 된다. 작은 팀일수록 완벽한 대시보드보다 실패 사례를 모아 다음 주에 한 가지를 고치는 루프가 더 중요하다.

결국 남는 건 운영 설계다

모델·검색·툴 호출은 빠르게 비슷해진다. 반면 문서와 데이터의 경계, 권한과 감사, 승인과 예외, 실패 복구, 비용 관측을 어떻게 연결하는지는 잘 안 복제된다.

그래서 AI를 도입할 때 첫 질문을 이렇게 바꾸면 좋다.

“어떤 Agent를 만들까?”가 아니라 “어떤 일을, 어떤 위험 안에서, 사람 손을 덜 들이고 돌리게 만들까?”

Agent가 일을 줄이는 순간은 답변을 잘 만들 때가 아니다. 누가 무엇을 보고, 어떤 행동을 하며, 실패하면 어떻게 되돌아가는지가 하나의 흐름으로 닫힐 때다.