Work IQ형 업무 데이터 에이전트 설계: CRM·ERP 권한을 안전하게 연결하는 법

Microsoft의 Work IQ preview 소식은 Copilot과 autonomous agent가 Dynamics 365, Power Platform, CRM, ERP 같은 실제 업무 데이터에 더 직접적으로 연결되는 방향을 보여준다. 이름이 무엇이든 핵심은 같다. 에이전트가 일반 지식이 아니라 고객, 주문, 계약, 재고, 미수금, 티켓, 내부 workflow를 읽고 행동한다. 개발자와 IT 리드는 이 흐름을 “편한 자연어 UI”로만 보면 안 된다. 업무 데이터 연결은 곧 권한 시스템을 에이전트에게 확장하는 일이다.

실무에서 Work IQ형 에이전트가 실패하는 지점은 모델 성능보다 데이터 경계다. 영업 담당자는 자기 계정의 deal만 봐야 한다. CS 담당자는 고객 주문 상태는 볼 수 있지만 결제 수단 전체 번호는 보면 안 된다. 재무팀 에이전트는 미수금 follow-up을 만들 수 있지만 임의로 할인율을 바꾸면 안 된다. 이런 제약이 없으면 에이전트는 업무를 빠르게 만드는 대신 내부 권한 사고를 빠르게 만든다.

먼저 데이터 지도를 만들어야 한다

에이전트를 붙이기 전에 “어떤 데이터가 어디에 있고, 누가 어떤 목적으로 쓰는가”를 정리해야 한다. CRM에는 lead, account, opportunity, contact가 있다. ERP에는 invoice, purchase order, inventory, shipment가 있다. 고객지원 도구에는 ticket, conversation, refund request가 있다. 이 객체들이 서로 연결되면 편리하지만, 권한도 같이 복잡해진다.

데이터 지도에는 최소 다섯 가지가 필요하다. 객체 이름, 민감도, owner system, allowed roles, allowed actions다. 예를 들어 invoice는 finance system이 owner이고, finance role은 read/write, sales role은 read limited, support role은 read none일 수 있다. contact email은 support가 볼 수 있지만, billing tax id는 finance만 볼 수 있다.

이 작업을 건너뛰고 LLM에 “필요한 데이터를 찾아 답하라”고 하면 과조회가 생긴다. 모델은 답변 품질을 높이려고 더 많은 컨텍스트를 가져오려 한다. 그래서 retrieval layer에서 필드 단위 필터를 걸어야 한다. prompt에 “민감 정보는 보지 마”라고 쓰는 것은 보조 장치일 뿐이다.

RBAC만으로 부족한 이유

대부분 회사는 role-based access control(RBAC)을 쓴다. 하지만 에이전트에는 RBAC만으로 부족하다. 같은 support role이라도 사용자의 의도에 따라 허용되는 행동이 다르다. “주문 배송 상태를 알려줘”에서는 주소 일부가 필요할 수 있지만, “이 고객이 VIP인지 알려줘”에서는 주소가 필요 없다. 같은 사람이 같은 역할로 요청해도 purpose가 다르면 데이터 범위가 달라져야 한다.

그래서 ABAC(attribute-based access control)와 purpose-based control을 섞어야 한다. user role, department, region, account ownership, ticket assignment, customer consent, task type을 함께 본다. 에이전트가 도구를 호출할 때는 “누가”, “어떤 세션에서”, “무슨 목적의 task로”, “어떤 객체를”, “어떤 필드까지” 요청하는지 policy engine에 넘겨야 한다.

또한 에이전트 자체의 권한과 사용자 권한을 분리해야 한다. 좋은 기본값은 “에이전트는 사용자를 대리하되, 사용자보다 넓은 권한을 갖지 않는다”이다. 단, batch automation처럼 서비스 계정 권한이 필요한 경우에는 별도 agent identity를 만들고, 사용자 요청과 agent service action을 로그에서 구분한다.

읽기와 쓰기 액션을 분리하기

업무 데이터 에이전트는 처음부터 쓰기 작업을 열면 안 된다. read-only Q&A부터 시작해도 충분히 가치가 있다. “이 고객의 최근 3개 티켓 요약”, “이번 분기 갱신 위험 계정 목록”, “미수금 30일 초과 invoice 요약” 같은 작업은 쓰기 없이도 시간을 줄인다.

쓰기 작업은 위험도에 따라 나눈다. 낮은 위험은 draft 생성이다. 이메일 초안, follow-up task 초안, ticket reply 초안은 사람이 검토하면 된다. 중간 위험은 내부 상태 변경이다. ticket label 추가, account note 작성, task 생성은 되돌릴 수 있지만 audit log가 필요하다. 높은 위험은 외부 발송, 가격 변경, 환불, 계약 변경, 권한 변경이다. 이 단계는 human approval과 정책 검증 없이는 실행하면 안 된다.

실무 패턴은 two-step commit이다. 에이전트가 먼저 plan을 만든다. “3개 계정에 follow-up task를 만들고, 각 task due date를 금요일로 설정하며, 외부 이메일은 보내지 않는다”처럼 행동 계획을 보여준다. 사용자가 승인하면 실제 tool call이 실행된다. 승인 로그에는 plan hash와 실행 결과를 남긴다. 나중에 “승인한 내용과 실제 행동이 같았는지”를 검증할 수 있어야 한다.

Grounding과 freshness를 설계하기

업무 데이터는 자주 바뀐다. 어제의 pipeline, 오늘의 재고, 방금 업데이트된 결제 상태가 다를 수 있다. 에이전트가 오래된 컨텍스트로 답하면 업무 사고가 난다. 따라서 답변에는 데이터 기준 시간이 필요하다. “2026-10-11 22:40 KST 기준”처럼 표시하거나, 내부 로그에 source timestamp를 남긴다.

retrieval도 일반 RAG와 다르다. 문서 검색은 관련도 중심이어도 되지만, CRM/ERP 검색은 권한과 정확성이 먼저다. account id가 명확하면 semantic search보다 primary key lookup이 우선이다. 고객 이름이 중복될 수 있으면 추가 식별자를 요청해야 한다. 모델이 “아마 이 고객”이라고 추정해서 order를 조회하면 안 된다.

또한 에이전트 답변에는 근거 객체를 붙여야 한다. account, invoice, ticket, opportunity id를 내부 링크로 남기면 사람이 검토할 수 있다. 단, 사용자가 볼 수 없는 객체 링크는 노출하면 안 된다. grounding은 투명성을 높이지만, 권한을 우회하는 링크가 되면 안 된다.

운영 로그와 감사 기준

업무 데이터 에이전트는 감사 로그가 제품 기능이다. 최소한 actor user id, agent id, session id, requested action, accessed objects, accessed fields, policy decision, tool result, approval id가 필요하다. 단순히 LLM prompt와 response만 저장하면 부족하다. 나중에 어떤 고객 데이터가 누구에게 노출됐는지 확인할 수 있어야 한다.

로그는 개인정보를 과도하게 담지 않도록 설계해야 한다. accessed object id와 field name은 남기되, field value는 마스킹하거나 필요한 경우에만 암호화 저장한다. 특히 결제 정보, 주민등록번호에 준하는 식별자, 건강 정보, 민감 계약 조건은 별도 보관 정책을 둔다.

알림도 필요하다. 에이전트가 평소보다 많은 account를 조회하거나, 한 사용자가 자기 region 밖 데이터를 반복 조회하거나, write action 실패가 급증하면 보안 이벤트로 봐야 한다. LLM 사고는 악의가 없어도 내부자 위협과 비슷한 패턴을 만들 수 있다.

실행 체크리스트

• CRM, ERP, support tool의 주요 객체와 필드를 데이터 지도로 정리한다.
• 객체별 owner system, 민감도, allowed roles, allowed actions를 기록한다.
• 에이전트는 사용자 권한을 넘지 않는 것을 기본값으로 둔다.
• RBAC에 account ownership, region, ticket assignment, task purpose 같은 attribute를 추가한다.
• read-only Q&A부터 시작하고 쓰기 작업은 draft, reversible write, irreversible write로 나눈다.
• 외부 발송, 환불, 가격 변경, 계약 변경, 권한 변경은 human approval을 필수로 둔다.
• 도구 호출 전에 policy engine이 객체와 필드 단위 접근을 판단하게 한다.
• 답변과 로그에 데이터 기준 시간과 source object id를 남긴다.
• 고객 이름이나 회사명이 중복되면 모델이 추정하지 말고 추가 식별자를 요청하게 한다.
• actor, agent, session, object, field, policy decision, approval id를 감사 로그에 남긴다.

Work IQ형 업무 데이터 에이전트의 성패는 모델이 얼마나 자연스럽게 말하느냐보다, 권한과 감사가 얼마나 촘촘하냐에 달려 있다. CRM과 ERP를 붙이는 순간 에이전트는 내부 시스템 사용자가 된다. 제품 출시 전 먼저 해야 할 일은 멋진 데모가 아니라 데이터 지도, 권한 정책, write approval, 감사 로그를 설계하는 것이다.