삼성 AX 전환: Process‑to‑Agent 운영모델

안녕하세요, Seigniter의 유민수 개발자입니다.

2026년 6월 9일 삼성의 AI 대전환 발표를 보며 먼저 든 생각은 단순한 도구 배포 뉴스가 아니라는 것이었습니다. 전 관계사, 전 업무, 외부 LLM, 사장단과 임원 교육, 전 직원 교육, AI 전담조직이 한 번에 나왔습니다. 보통의 생산성 캠페인보다 훨씬 넓은 신호입니다.

다만 이 글은 삼성 내부 문서를 해석하는 글이 아닙니다. 삼성 뉴스룸과 Samsung SDS 공개자료를 보고, 대기업 AX가 어느 쪽으로 움직이는지 Seigniter 관점에서 정리한 공개자료 기반 분석입니다.

제가 보는 쟁점은 분명합니다. AX의 성패는 AI를 얼마나 많이 쓰게 하느냐보다, 핵심 업무 프로세스를 얼마나 agent-executable workflow로 바꾸고 안전하게 운영하느냐에 달려 있습니다.

이번 발표는 도구 배포보다 운영모델 전환에 가깝다

많은 기업의 AI 도입은 회의록, 요약, 번역, 문서 초안, 검색 같은 개인 생산성 업무에서 시작됩니다. 필요한 단계입니다. 직원들이 AI를 업무 안에서 만져 보고, 조직도 보안 정책과 사용 가이드를 만들며 초기 저항을 낮출 수 있으니까요.

그런데 삼성 발표에서 눈에 들어오는 대목은 개인 생산성 도구가 아닙니다. R&D, 생산, 마케팅, 지원 등 밸류체인 전반에 AI를 접목한다는 방향, 그리고 경영진이 업무 프로세스 혁신 방안을 직접 다룬다는 점입니다.

이 정도 범위라면 질문이 달라집니다. 누가 어떤 모델을 쓸 것인가보다, 어떤 업무 흐름을 다시 설계할 것인가가 먼저입니다. AX의 단위가 챗봇이나 기능 목록이 아니라 경영 프로세스로 옮겨가는 셈입니다.

대기업 AX가 어려운 이유도 여기에 있습니다. 외부 LLM을 열어 준다고 ERP, SCM, MES, PLM, CRM, 문서 시스템, 협업툴, 권한 체계, 감사 로그, 데이터 등급이 저절로 이어지지는 않습니다. 모델 접근성은 출발점일 뿐입니다. 성과는 업무 흐름과 통제 체계를 다시 짤 때 나옵니다.

Use Case AX만으로는 전사 성과를 설명하기 어렵다

AI 도입 초기에 Use Case 목록을 만드는 일은 자연스럽습니다. 회의록 자동화, 계약서 요약, 보고서 초안, 고객 문의 분류, 코드 생성, 사내 지식 검색은 빠르게 PoC로 만들 수 있습니다.

문제는 그다음입니다. Use Case가 늘어날수록 경영진은 다른 질문을 던집니다.

• 리드타임이 실제로 줄었는가
• 품질, 납기, 원가, 고객경험 중 무엇이 개선됐는가
• 위험한 자동화는 어디에서 막히는가
• 부서별 실험이 전사 표준으로 확산될 수 있는가
• AI 사용률이 아니라 업무 성과로 설명할 수 있는가

Use Case AX는 조직이 AI를 경험하게 만드는 씨앗입니다. 하지만 전사 성과로 이어지려면 Process AX로 넘어가야 합니다. Demand-to-Supply, R&D-to-Yield, Issue-to-Resolution, Source-to-Pay, Risk-to-Control 같은 end-to-end 가치흐름을 기준으로 봐야 합니다.

회의록을 잘 쓰는 AI와 공급 리스크를 줄이는 AI는 전혀 다른 문제입니다. 앞에서는 텍스트 품질이 중요하지만, 뒤에서는 데이터 정의, 시스템 연결, 승인 권한, 예외 처리, 감사 로그, 책임 소재가 함께 맞아야 합니다.

Process‑to‑Agent는 업무를 실행 단위로 바꾸는 일이다

Process‑to‑Agent는 프로세스를 agent가 일부 실행할 수 있는 운영 단위로 재설계하는 접근입니다. 여기서 agent는 답변만 생성하는 모델이 아닙니다. 시스템을 조회하고, 작업을 만들고, 알림을 보내고, 표준 보고서를 만들고, 정해진 조건에서 다음 단계를 제안하거나 실행하는 업무 단위에 가깝습니다.

그래서 첫 질문은 어떤 agent를 만들 것인가가 아닙니다. 어떤 프로세스를 agent가 실행할 수 있는 크기로 쪼갤 것인가입니다.

좋은 workflow unit에는 여섯 가지가 들어갑니다.

1. Trigger: 어떤 요청, 이벤트, 위험 신호가 업무를 시작하는가
2. Input: 어떤 데이터, 문서, 시스템 권한이 필요한가
3. Composition: 사람, AI, agent의 역할을 어떻게 나눌 것인가
4. Execution: 조회, 생성, 추천, 시스템 호출 중 무엇을 수행하는가
5. Validation: 승인, 테스트, 감사 로그, 품질 기준은 무엇인가
6. Next: 산출물이 어디로 넘어가고, 피드백은 어떻게 돌아오는가

이 구조가 없으면 agent는 업무를 실행하는 시스템이 되지 못합니다. 사람이 계속 해석하고 다시 지시해야 하는 답변 생성 도구에 머뭅니다.

Agentization은 자율성보다 책임 경계가 먼저다

대기업에서 agent를 설계할 때 흔히 자동화 수준부터 이야기합니다. 하지만 자율성을 얼마나 줄 것인가보다 먼저 나눠야 할 것이 있습니다. 책임 경계입니다.

업무는 대략 다섯 영역으로 갈립니다.

• Human-only: 법적 책임, 고위험 의사결정, 윤리적 판단처럼 사람이 반드시 맡는 영역
• Human-in-loop: AI가 초안, 추천, 분석을 제공하고 사람이 승인하거나 수정하는 영역
• AI-assisted: 검색, 비교, 요약, 예측, 문서 생성처럼 사람이 주도하고 AI가 보조하는 영역
• Agent-executable: 시스템 조회, 티켓 생성, 알림, 표준 보고서처럼 규칙과 검증 기준이 명확한 영역
• Forbidden: 데이터 등급, 법규, IP, 보안정책상 agent가 접근하거나 실행하면 안 되는 영역

이 구분 없이 AX를 밀어붙이면 두 방향으로 흔들립니다. 리스크가 두려워 모든 것을 보조 도구 수준에 묶어 두거나, 반대로 통제 체계 없이 자동화부터 키우게 됩니다. 둘 다 전사 확산에는 한계가 있습니다.

대기업 AX에서 필요한 건 빠른 자동화 자체가 아닙니다. 성과와 통제를 함께 보면서 자율성을 단계적으로 넓히는 운영 방식입니다.

Governance는 마지막 검토가 아니라 실행 조건이다

많은 프로젝트에서 보안, 권한, 감사 로그는 구현 후반의 체크리스트로 밀립니다. AI agent에서는 이 방식이 특히 위험합니다. 권한과 데이터 등급을 뒤늦게 붙이면 API, 화면, 데이터 조회, 프롬프트, 로그 구조를 다시 고치게 됩니다.

Governance는 별도 문서가 아니라 workflow 안에 들어가야 합니다. 어떤 데이터는 외부 LLM으로 보낼 수 없고, 어떤 조회는 내부 RAG만 허용되며, 어떤 action은 관리자 승인이 필요하고, 어떤 예외는 기존 절차로 fallback되어야 합니다.

agent 설계서는 prompt가 아니라 세 가지 계약의 조합에 가깝습니다.

• Business contract: 목적, 트리거, 출력, 성과 기준
• Execution contract: 데이터, 도구, 시스템 접근, action 범위
• Control contract: 승인 조건, fallback, 로그, 평가, 감사 기준

이 계약이 분리되지 않으면 운영 중 문제가 생겼을 때 원인을 찾기 어렵습니다. 모델이 틀렸는지, 데이터가 낡았는지, 권한이 과했는지, workflow 정의가 모호했는지 구분할 수 없기 때문입니다.

데이터 신뢰도는 화면보다 먼저 해결해야 한다

AI agent가 기업 업무에 들어가면 자주 부딪히는 문제가 있습니다. 모델 성능보다 지표 신뢰도입니다. 같은 고객을 CRM과 ERP가 다르게 식별하거나, 같은 매출과 미수금의 정의가 부서마다 다르면 agent의 판단도 흔들립니다.

대시보드 숫자를 믿을 수 없다면 agent에게 실행 권한을 줄 수 없습니다. 어떤 지표를 보고 어떤 조치를 추천하거나 실행할지 정해야 하는데, 지표 정의가 불안정하면 자동화 수준도 올라가지 않습니다.

그래서 AX 파일럿에는 Metric Trust Workflow가 들어가야 합니다. 지표 이름, 계산식, owner, refresh cycle, permission, validation, timezone, rounding rule, 제외 기준을 테스트 가능한 형태로 정리하는 작업입니다.

화려한 일은 아닙니다. 그래도 기업 AI의 실행력은 이런 지루한 정의에서 나옵니다.

대기업 AX는 중앙 표준과 현장 실행을 나눠야 한다

삼성처럼 관계사가 많고 업무 유형이 다양한 조직에서는 한 가지 방식만으로 AX를 밀어붙이기 어렵습니다. 중앙은 플랫폼, 보안 정책, 데이터 분류, 모델 평가, tool catalog, 감사 기준을 잡아야 합니다. 현장은 프로세스 맥락, KPI, 예외 처리, domain knowledge, 현업 adoption을 책임져야 하고요.

중앙이 모든 agent를 직접 만들면 속도가 느려집니다. 반대로 각 조직이 임의로 만들면 중복 투자와 통제 편차가 커집니다. 그래서 필요한 구조가 federated operating model입니다. 공통 표준은 중앙에서 잡고, 업무 재설계와 파일럿 실행은 현장 process owner와 AI product owner가 끌고 가는 방식입니다.

이때 외부 전문가의 역할도 모델 튜닝보다 프로세스 진단, agentization design, KPI model, adoption design 쪽에서 커집니다. AI 기술 자체보다 어떤 업무를 어떤 책임 구조로 바꿀 것인가가 더 어려운 과제가 되기 때문입니다.

초기 파일럿은 scale decision을 만들면 충분하다

AX 파일럿의 목표를 완성형 시스템 출시로 잡으면 범위가 커지고 의사결정이 늦어집니다. 초기 12주는 성과와 리스크를 동시에 검증하는 기간으로 보는 편이 낫습니다.

좋은 파일럿은 네 개 workstream을 병렬로 움직입니다.

• Process diagnosis: 핵심 프로세스 3~5개를 선정하고 병목, 예외, 재작업, 데이터 단절을 파악
• Data/system readiness: 필요한 데이터와 시스템 접근, 권한, 지표 정의를 점검
• Agent workflow design: 사람, AI, agent의 역할과 승인 지점을 설계
• Pilot validation: 제한 범위에서 성과 KPI, AI KPI, Control KPI를 함께 측정

파일럿의 종료 기준은 agent를 만들었느냐가 아닙니다. 확산할지, 중단할지, 어떤 통제 조건을 강화할지 결정할 근거를 확보했느냐입니다.

AX 리더가 먼저 결정해야 할 다섯 가지

삼성 AX 발표가 다른 대기업에 던지는 질문은 꽤 명확합니다. 모델 선택보다 운영모델 의사결정이 먼저입니다.

AX 리더가 먼저 정해야 할 것은 다섯 가지입니다.

1. Sponsor: CEO 또는 사업부장 sponsor와 책임 owner는 누구인가
2. Process scope: 성과와 리스크가 큰 workflow 1~2개는 무엇인가
3. Control level: 외부 LLM, 내부 RAG, 사내 모델, 금지 영역을 어떻게 나눌 것인가
4. Pilot rule: 성과 KPI, AI KPI, 통제 KPI를 어떻게 동시에 측정할 것인가
5. Scale model: 중앙 표준과 현장 실행의 역할을 어떻게 나눌 것인가

이 질문이 정리되지 않은 상태에서 AI 도구를 넓게 배포하면 사용률은 올라갑니다. 하지만 경영성과를 설명하기는 어렵습니다.

AX의 기준은 사용률이 아니라 agent-executable 전환률이다

삼성의 AI 대전환은 국내 대기업 AX 논의를 한 단계 앞으로 밀어 올렸습니다. 이제 질문은 AI를 쓸 것인가가 아닙니다. 이미 쓰는 방향으로 가고 있습니다.

남는 질문은 더 구체적입니다.

우리 조직의 핵심 프로세스 중 어느 부분이 AI-native workflow로 재설계됐는가. 어느 업무는 사람이 판단하고, 어느 업무는 AI가 보조하며, 어느 업무는 agent가 실행할 수 있는가. 그 실행은 어떤 데이터, 권한, 승인, 로그, fallback 위에서 안전하게 운영되는가.

AX 성공 기준은 AI 사용률이 아니라 핵심 프로세스의 agent-executable 전환률입니다. AI를 많이 쓰는 조직보다, AI가 일할 수 있는 업무 운영체계를 만든 조직이 다음 단계의 생산성을 가져갈 가능성이 큽니다.