기업 소프트웨어의 다음 사용자는 사람이 아니라 AI 에이전트다

AI 에이전트가 기업 소프트웨어의 사용자로 확장될 때 필요한 업무 기능, 작업 단위 권한, 승인 흐름, 실행 로그의 설계 기준을 정리합니다.

ERP의 다음 사용자는 사람인가, AI인가? 질문을 이렇게 바꾸면 AX가 다르게 보이기 시작한다.

기업에서 AX를 이야기할 때 가장 먼저 떠오르는 장면은 대개 비슷하다. 사내 문서를 검색해 주는 챗봇, 회의록을 요약하는 Copilot, 보고서 초안을 써 주는 생성형 AI 같은 것들이다. 이것들은 분명 유용하다. 하지만 기업 소프트웨어의 구조를 바꿀 정도의 변화라고 보기는 어렵다. 여전히 사용자는 사람이고, AI는 사람이 쓰는 화면 옆에 붙은 보조 도구에 가깝기 때문이다.

진짜 변화는 조금 다른 곳에서 시작된다. ERP, CRM, 프로젝트 관리 도구, 그룹웨어, 생산·품질·물류 시스템을 실제로 조작하는 주체가 사람만이 아니게 되는 순간이다. 사람이 메뉴를 찾아 클릭하고, 조건을 입력하고, 결과를 확인하는 방식 대신 AI 에이전트가 업무 목표를 받아 시스템 안에서 필요한 데이터를 조회하고, 정해진 절차를 실행하고, 예외 상황만 사람에게 올리는 구조가 가능해지고 있다.

이 글의 질문은 단순하다. 기업 소프트웨어의 주 사용자가 사람에서 AI 에이전트로 확장되면, 소프트웨어는 무엇을 기준으로 다시 설계되어야 할까?

결론부터 말하면 AX의 핵심은 “AI 기능을 붙인 소프트웨어”가 아니다. AI가 안전하게 일할 수 있도록 업무 절차, 권한, 데이터, 감사 로그를 소프트웨어 안에 실행 가능한 형태로 다시 넣는 것이다.

이 글은 어떤 AI 모델이 더 좋은지를 평가하는 글이 아니다. 읽는 순서는 이렇다. 먼저 사람을 전제로 만들어진 기업 소프트웨어의 설계 가정이 어디서 흔들리는지 확인하고, 다음으로 에이전트가 실제 사용자가 될 때 소프트웨어가 갖춰야 할 조건 세 가지를 정리한다. 마지막에는 우리 시스템이 에이전트라는 새 사용자를 받을 준비가 되어 있는지 확인할 점검 질문으로 끝맺는다.

지금까지의 기업 소프트웨어는 사람을 전제로 만들어졌다

지난 수십 년간 기업 소프트웨어의 기본 가정은 명확했다. 사용자는 사람이다. 그래서 화면은 사람이 이해할 수 있어야 하고, 기능은 사람이 찾을 수 있어야 하며, 프로세스는 사람이 순서대로 따라갈 수 있어야 했다.

ERP의 전표 처리, CRM의 고객 이력 관리, 그룹웨어의 결재, MES의 작업 지시, 품질 시스템의 이상 대응도 마찬가지다. 시스템은 업무의 기록과 통제를 담당하지만, 실제 판단과 조작은 사람이 한다. 사용자는 화면을 보고, 규정을 떠올리고, 관련 데이터를 확인한 뒤, 버튼을 누른다.

이 구조에서는 소프트웨어의 좋은 사용성이 중요했다. 메뉴가 직관적인가, 화면 전환이 빠른가, 입력 폼이 복잡하지 않은가, 사용자가 교육을 받고 따라 할 수 있는가가 핵심이었다. 즉, 소프트웨어는 “사람이 실수하지 않고 쓸 수 있는 도구”로 최적화되어 왔다.

그런데 AI 에이전트가 업무 실행자가 되면 이 전제가 흔들린다. 에이전트는 메뉴가 예쁘게 정리되어 있는지를 보지 않는다. 사람이 보는 대시보드보다 더 중요한 것은 다음 질문이다.

• 이 업무 목표를 수행하는 데 필요한 데이터는 어디에 있는가?
• 어떤 조건에서 어떤 기능을 호출해야 하는가?
• 이 작업을 수행할 권한이 있는가?
• 실패했을 때 어떻게 되돌릴 수 있는가?
• 사람이 반드시 승인해야 하는 지점은 어디인가?
• 실행 결과를 누가, 언제, 어떤 근거로 감사할 수 있는가?

사람에게 좋은 UI와 에이전트에게 좋은 업무 환경은 겹치는 부분도 있지만 같지는 않다. AX가 소프트웨어 구조의 문제로 넘어가는 이유가 여기에 있다. 그래서 “우리 시스템은 쓰기 편한가”라는 질문은 “우리 시스템은 에이전트가 일할 수 있는 구조인가”라는 질문으로 바뀌어야 한다. 두 질문의 답은 서로 다르다.

에이전트는 화면보다 ‘업무 능력’을 호출한다

AI 에이전트를 단순히 “더 똑똑한 챗봇”으로 보면 변화가 작아 보인다. 하지만 에이전트의 의미는 답변이 아니라 실행에 있다. IBM은 AI 에이전트를 사용 가능한 도구로 워크플로를 설계해 자율적으로 작업을 수행하는 시스템으로 설명한다. 핵심은 대화가 아니라 목표를 받아 필요한 단계들을 수행하는 능력이다.

기업 소프트웨어 관점에서 이 말은 중요하다. 사람은 화면을 통해 시스템을 조작하지만, 에이전트는 가능하면 화면보다 기능과 절차를 직접 호출하려 한다. 예를 들어 “지난 분기 고객 클레임 중 납기 지연과 관련된 건을 추려 원인별로 분류해 줘”라는 요청을 생각해 보자. 사람이 한다면 CRM, 주문 시스템, 물류 이력, 품질 기록을 오가며 데이터를 내려받고 엑셀에서 정리할 것이다.

에이전트가 이 일을 하려면 필요한 것은 예쁜 화면이 아니다. 다음과 같은 실행 가능한 업무 능력이다.

이 표는 두 방식 중 하나를 고르라는 뜻이 아니다. 같은 시스템을 두 종류의 사용자가 각자의 방식으로 사용하게 된다는 뜻이다. 표를 읽을 때도 왼쪽과 오른쪽을 비교하는 것보다, 오른쪽 열에서 비어 있는 칸이 우리 조직의 어느 시스템에 해당하는지를 찾는 편이 실용적이다.

이 표에서 중요한 것은 에이전트가 사람을 완전히 대체한다는 뜻이 아니다. 오히려 반대다. 사람의 역할이 더 명확해진다. 사람은 목표, 판단 기준, 승인, 예외 처리, 책임을 맡고, 에이전트는 반복 실행과 데이터 이동, 초안 작성, 사전 검증을 맡는다.

참고: Anthropic의 에이전트 구축 가이드는 워크플로(미리 정의된 코드 경로로 모델과 도구를 조율하는 시스템)와 에이전트(모델이 자신의 과정과 도구 사용을 동적으로 지시하는 시스템)를 구분하면서, 가장 성공적인 구현은 복잡한 프레임워크가 아니라 단순하고 조합 가능한 패턴을 사용한다고 정리한다. 에이전트 도입에서 “얼마나 자율적인가”보다 “업무 절차가 얼마나 구조화되어 있는가”가 먼저라는 이 글의 관점과 같은 방향이다. (https://www.anthropic.com/engineering/building-effective-agents)

AX는 UI 개선보다 ‘업무 로직의 재배치’에 가깝다

많은 기업이 생성형 AI 도입을 UI 문제로 접근한다. 기존 시스템 옆에 채팅창을 붙이고, 문서 검색을 연결하고, 사용자가 자연어로 질문하면 답하게 만든다. 초기 도입으로는 좋은 방식이다. 사람의 학습 부담을 줄이고, 산재한 정보를 찾는 시간을 줄여주기 때문이다.

그러나 이 방식만으로는 AX가 깊어지기 어렵다. 채팅창은 사용자의 질문에 답할 수 있지만, 실제 업무는 질문과 답변만으로 끝나지 않는다. 업무에는 상태 변경이 있고, 승인 단계가 있고, 책임 소재가 있고, 예외 상황이 있다. 특히 기업 시스템에서는 “무엇을 알았는가”보다 “무엇을 실행했는가”가 더 중요하다.

우리 회사가 작년에 검토했던 구매 요청 에이전트를 예로 들겠다. 단순 요약이라면 요청서와 견적서를 읽고 핵심 내용을 정리하면 된다. 하지만 실제 업무 실행으로 들어가면 질문이 달라진다.

• 이 공급업체는 등록된 업체인가?
• 예산 한도를 넘는가?
• 동일 품목의 최근 구매 단가와 비교해 이상치가 있는가?
• 승인권자는 누구인가?
• 계약 조건상 법무 검토가 필요한가?
• 에이전트가 자동으로 결재선을 올려도 되는가, 아니면 추천까지만 해야 하는가?

이 지점부터는 LLM 성능만으로 해결되지 않는다. 회사의 업무 로직이 소프트웨어 안에 구조화되어 있어야 한다. 규정은 문서로만 존재해서는 부족하고, 에이전트가 참조하고 실행할 수 있는 정책·권한·워크플로 형태로 바뀌어야 한다.

그래서 AX는 “AI가 붙은 UI”보다 “AI가 실행할 수 있는 업무 로직”에 가깝다. 그리고 이것이 기업 소프트웨어 시장과 사내 IT 전략에 더 큰 변화를 만든다.

‘헤드리스 업무’가 늘어난다

앞으로 중요한 업무 중 일부는 사람이 화면을 열지 않은 상태에서 진행될 가능성이 크다. Microsoft WorkLab은 이런 흐름을 “headless”라는 표현으로 설명한다. 정책 변경, 데이터 갱신, 티켓 생성, 배송 지연 같은 이벤트가 발생하면 에이전트가 백그라운드에서 일을 수행하고, 사람에게는 검토나 승인 또는 예외 상황만 보여주는 방식이다.

참고: Microsoft WorkLab 원문은 “가장 중요한 에이전트 중 상당수는 채팅창으로 나타나지 않을 것”이라고 표현하며, 정책 변경·데이터 갱신·티켓 생성·배송 지연 같은 이벤트에 트리거되어 시스템 안에서 기계 속도로 실행되고, 사람이 검토·승인·개입해야 할 때만 결과를 드러낸다고 설명한다. 이 절에서 말하는 헤드리스 업무와 같은 개념이다. 원문은 또한 “이제 사용자는 사람과 에이전트 두 종류이며, 소프트웨어는 둘 모두를 서비스해야 한다”고 정리한다. (https://www.microsoft.com/en-us/worklab/ai-at-work-when-softwares-biggest-users-are-not-human)

이 개념은 제조와 운영 업무에서 특히 중요하다. 현장 업무는 이미 많은 이벤트로 구성되어 있다.

• 설비 알람이 발생한다.
• 특정 LOT의 대기 시간이 기준을 넘는다.
• 물류 장비의 경로가 막힌다.
• 품질 지표가 관리 한계를 벗어난다.
• 부품 재고가 안전 재고 아래로 내려간다.

기존 시스템에서는 이런 이벤트가 대시보드나 알림으로 올라오고, 사람이 보고 판단한다. AX가 진행되면 일부 이벤트는 에이전트의 작업 시작점이 될 수 있다. 에이전트가 원인 후보를 모으고, 관련 이력을 조회하고, 가능한 조치안을 정리하고, 위험도가 낮은 조치는 자동 실행하고, 위험도가 높은 조치는 사람에게 승인 요청을 올리는 식이다.

우리 공장에서 실제로 파일럿을 돌렸던 흐름이다. 야간에 설비 온도 알람이 발생했다. 기존 흐름이라면 아침에 출근한 담당자가 밤사이 알람 목록을 확인하고, 설비 이력을 조회하고, 조치 여부를 판단한다. 헤드리스 에이전트를 둔다면 흐름이 달라진다. 알람이 발생한 순간 에이전트가 해당 설비의 최근 정비 이력과 동일 유형의 과거 알람 조치 내역을 조회하고, “냉각수 온도 재설정” 같은 저위험 조치 후보와 “설비 정지 후 점검” 같은 고위험 조치 후보를 구분해 정리한다. 저위험 조치는 미리 정해 둔 범위 안에서만 자동 실행하고, 고위험 조치는 담당자에게 승인 요청만 올린다. 아침에 출근한 담당자는 판단의 재료가 이미 정리된 상태에서 승인 여부만 결정한다.

여기서 핵심은 “자동화 범위를 얼마나 넓힐 것인가”가 아니다. 더 중요한 질문은 “어떤 업무를 어떤 조건에서 에이전트에게 맡길 수 있는가”다. 이 질문에 답하지 못하면 AX는 실험실을 벗어나기 어렵다.

기업 소프트웨어가 갖춰야 할 세 가지 조건

에이전트가 기업 소프트웨어의 실제 사용자가 되려면 최소한 세 가지 조건이 필요하다.

1. 업무 기능이 호출 가능한 단위로 쪼개져 있어야 한다

사람은 복잡한 화면을 보면서 중간 판단을 할 수 있다. 하지만 에이전트에게 업무를 맡기려면 기능이 명확한 단위로 쪼개져 있어야 한다. “고객 이력 조회”, “최근 주문 내역 확인”, “승인 대상 여부 판단”, “결재 초안 생성”, “담당자에게 확인 요청”처럼 호출 가능한 작업 단위가 필요하다.

이 단위가 없으면 에이전트는 화면 자동화에 의존하게 된다. 화면 자동화는 빠르게 시작할 수 있지만 안정성이 낮다. 화면 구조가 바뀌면 깨지고, 예외 상황을 추적하기 어렵고, 권한 통제도 거칠어진다. 장기적으로는 API, 이벤트, 워크플로, 도구 호출 구조가 필요하다.

참고: 도구 호출을 표준화하려는 시도도 이미 진행 중이다. Model Context Protocol(MCP)은 AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈소스 표준으로, 에이전트가 데이터 소스와 도구에 접근하는 방식을 표준 인터페이스로 정리한다. “호출 가능한 단위”로 쪼개는 설계가 개별 기업의 사정이 아니라 산업 표준의 방향과 일치한다는 뜻이다. (https://modelcontextprotocol.io)

2. 권한이 사람 계정이 아니라 작업 단위로 설계되어야 한다

사람에게 부여된 권한을 에이전트가 그대로 쓰게 하면 위험하다. 에이전트는 빠르고 많이 실행할 수 있기 때문이다. 사람이 하루에 한 번 실수할 일을 에이전트는 짧은 시간에 수백 번 반복할 수 있다.

따라서 AX 시대의 권한 설계는 더 세밀해야 한다. 에이전트가 조회만 할 수 있는 데이터, 초안 작성까지만 가능한 업무, 사람 승인 후 실행 가능한 업무, 절대 자동 실행하면 안 되는 업무를 구분해야 한다. 특히 재무, 인사, 고객정보, 생산 조건 변경처럼 영향이 큰 영역에서는 권한과 승인 조건이 업무 단위로 정의되어야 한다.

참고: 에이전트 보안 위험을 분류하는 작업도 병행되고 있다. OWASP GenAI Security Project는 LLM과 에이전트 AI 시스템의 보안·안전 위험을 식별·완화하기 위한 글로벌 오픈소스 이니셔티브로, 과도한 권한 부여를 포함한 위험 유형을 정리한다. 작업 단위 권한 설계가 편의의 문제가 아니라 보안 요구사항인 이유다. (https://owasp.org/www-project-top-10-for-large-language-model-applications/)

NIST의 AI Risk Management Framework가 강조하는 위험 관리 관점도 이 지점과 연결된다. AI를 실제 업무에 넣는다는 것은 모델의 정확도만 보는 일이 아니라, 조직 안에서 어떤 위험이 생기고 어떻게 식별·측정·관리할지를 정하는 일이다. (https://www.nist.gov/itl/ai-risk-management-framework)

3. 실행 로그와 근거가 남아야 한다

기업 업무에서 자동화의 가장 큰 장벽은 “믿을 수 있는가”보다 “문제가 생겼을 때 설명할 수 있는가”다. 에이전트가 어떤 데이터를 보고, 어떤 규칙을 적용하고, 어떤 도구를 호출했으며, 왜 그 결과를 냈는지 남아야 한다.

사람이 한 일도 감사가 필요하지만, 에이전트가 한 일은 더 촘촘한 기록이 필요하다. 특히 여러 시스템을 넘나드는 업무에서는 실행 경로가 복잡해진다. CRM에서 고객 정보를 읽고, ERP에서 계약 조건을 확인하고, 그룹웨어에 결재 초안을 만들었다면, 각각의 시스템에 흩어진 로그만으로는 전체 판단 과정을 재구성하기 어렵다.

AX가 깊어질수록 기업 소프트웨어에는 “AI 실행 이력”이라는 새로운 층이 필요해진다. 이것은 단순한 사용 로그가 아니라, 업무 목표, 입력 데이터, 호출 도구, 중간 판단, 사람 승인 여부, 최종 결과를 연결하는 기록이어야 한다.

이 조건은 운영 설계의 기본 원칙과도 이어진다. 자동화를 실행한 주체와 그 결과를 검증하는 주체가 같으면 오류가 조용히 누적될 수 있다. 에이전트가 실행한 업무일수록 결과 검토는 사람 또는 별도의 검증 절차가 맡아야 한다. 실행과 검증의 분리는 로그를 남기는 것만큼이나 감사 가능성을 만드는 기본 장치다.

모든 시스템을 새로 만들 필요는 없다

여기서 한 가지 오해를 피해야 한다. 에이전트가 기업 소프트웨어의 사용자가 된다고 해서 모든 ERP, CRM, MES를 새로 만들어야 한다는 뜻은 아니다. 오히려 현실적인 AX는 기존 시스템을 버리는 방식이 아니라, 기존 시스템 위에 에이전트가 안전하게 일할 수 있는 계층을 추가하는 방식에 가깝다.

중요한 것은 무작정 자체 개발을 늘리는 것이 아니다. 어떤 업무는 상용 SaaS나 기존 패키지의 AI 기능을 쓰는 편이 낫고, 어떤 업무는 회사 고유의 프로세스와 데이터 맥락이 강하기 때문에 내부 설계가 필요하다. Microsoft WorkLab도 에이전트 시대가 기업에게 “무엇을 직접 만들고, 무엇은 외부 솔루션에 맡길지”를 다시 묻게 만든다고 지적한다.

참고: Microsoft WorkLab 원문은 같은 맥락에서 더 분명하게 말한다. 범용 솔루션으로 대체 가능한 소프트웨어를 직접 만들고 유지하는 데 쓴 시간은, 곧 기업의 경쟁 우위를 만드는 일에 쓰지 못한 시간이라는 것이다. 앞서가는 기업은 더 많이 만드는 기업이 아니라 “오직 자신들만 할 수 있는 일”에 가장 집중하는 기업이라고 정리한다. (https://www.microsoft.com/en-us/worklab/ai-at-work-when-softwares-biggest-users-are-not-human)

따라서 AX 전략은 다음과 같은 구분에서 출발해야 한다.

이 구분 없이 “우리도 AI 에이전트를 도입하자”고 접근하면 결과는 챗봇 여러 개가 될 가능성이 크다. 반대로 업무 유형을 나누면 어떤 영역은 빠르게 도입하고, 어떤 영역은 신중하게 설계해야 하는지 보인다. 이 표는 위에서 아래로 읽는 설명이 아니라, 우리 조직의 업무 목록을 오른쪽 열의 어느 칸에 놓을지 분류하는 도구로 쓸 때 유용하다.

AX의 병목은 모델보다 운영 조건이다

지금까지 AI 도입 논의는 모델 성능 중심으로 흘러왔다. 어떤 모델이 더 똑똑한가, 어떤 모델이 더 긴 컨텍스트를 처리하는가, 어떤 모델이 더 싸게 호출되는가가 중요했다. 물론 이 질문들은 여전히 중요하다.

하지만 기업 소프트웨어 안으로 AI 에이전트가 들어가면 병목은 다른 곳으로 이동한다. 지금 당장 확인할 수 있는 여섯 가지다.

1. 데이터가 업무 판단에 필요한 형태로 연결되어 있는가?
2. 시스템 간 API와 이벤트가 정비되어 있는가?
3. 에이전트가 할 수 있는 일과 하면 안 되는 일이 정의되어 있는가?
4. 실패했을 때 멈추고 사람에게 넘기는 기준이 있는가?
5. 자동 실행 결과를 감사할 수 있는가?
6. 현업 담당자가 에이전트의 제안을 검토할 수 있는 작업 방식이 있는가?

이 질문들은 모델 벤치마크로 답할 수 없다. AX의 성공 여부는 모델 도입 여부보다 기업이 자신의 업무를 얼마나 실행 가능한 구조로 정리했는지에 더 크게 좌우된다. 여섯 질문에 바로 답하기 어렵다면, 아직 모델을 교체할 논의를 할 단계가 아니다. 업무 구조화가 먼저다.

결론: AX는 소프트웨어의 사용자를 다시 정의하는 일이다

AX를 챗봇 도입으로 보면 할 수 있는 일이 제한된다. 문서를 요약하고, 질문에 답하고, 보고서 초안을 쓰는 수준에서는 기존 소프트웨어의 구조가 크게 바뀌지 않는다. 하지만 AI 에이전트가 ERP, CRM, 그룹웨어, 생산·품질·물류 시스템 안에서 실제 업무를 수행하기 시작하면 이야기가 달라진다.

기업 소프트웨어의 사용자는 더 이상 사람만이 아니다. 사람과 AI 에이전트가 함께 사용자가 된다. 사람은 목표와 판단과 책임을 맡고, 에이전트는 반복 실행과 데이터 이동과 사전 검증을 맡는다. 이를 위해 소프트웨어는 화면 중심에서 업무 능력 중심으로, 사람 계정 권한에서 작업 단위 권한으로, 단순 로그에서 실행 근거 기록으로 확장되어야 한다.

그래서 AX의 다음 경쟁력은 “어떤 AI 모델을 붙였는가”가 아니라 우리 회사의 업무가 AI 에이전트가 안전하게 실행할 수 있을 만큼 구조화되어 있는가에서 갈릴 가능성이 크다.

기업 소프트웨어의 다음 사용자는 사람이 아니라 AI 에이전트다. 더 정확히 말하면, 사람만을 전제로 만든 소프트웨어의 시대가 끝나고 있다.

다음 질문은 자연스럽게 이어진다. 에이전트가 호출할 “업무 능력 단위”는 어떻게 정의하고, 어떤 업무부터 쪼개야 하는가. 이것은 이 글의 범위를 벗어나므로, 별도의 글에서 다룰 주제다.

이 글은 공개 보도와 공식 자료를 바탕으로 한 기술 해설입니다. 특정 기업이나 증권에 대한 매수·매도 권유가 아니며, 투자 판단의 근거로 사용할 수 없습니다.

확인한 출처 / 근거

• Microsoft WorkLab, AI@Work: When software’s biggest users aren’t human — 헤드리스 업무, 사람과 에이전트라는 두 종류의 사용자, 자체 구축과 외부 솔루션의 판단 맥락.
• IBM Think, What Are AI Agents? — AI 에이전트의 도구·워크플로 기반 작업 수행 정의.
• NIST, AI Risk Management Framework — AI 운영의 위험 관리와 거버넌스 관점.
• Microsoft WorkLab, Agents, human agency, and the opportunity for every organization — 사람의 주도성과 에이전트 활용에 관한 참고 자료.
• Anthropic Engineering, Building effective agents — 워크플로와 에이전트의 구분, 단순하고 조합 가능한 구현 패턴.
• Model Context Protocol, Introduction — AI 애플리케이션과 외부 시스템을 연결하는 오픈소스 표준의 개요.
• OWASP, Top 10 for Large Language Model Applications — 과도한 권한 부여를 포함한 LLM·에이전트 보안 위험의 참고 자료.
• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile (AI 600-1) — 생성형 AI 위험 관리 프로파일 참고 자료.
• 참고: 본문의 구매 요청 검토와 야간 설비 알람 사례는 반도체 회사 AX 담당자로 일하며 겪은 경험을 바탕으로 재구성했으며, 일부 상황과 수치는 각색했습니다.