[5/6] 전사 확산: 비용과 보안을 함께 설계한다 - 사용자는 더 이상 ERP에 접속하지 않는다

1. 파일럿에서는 안 보이던 두 가지 벽

몇 명의 헤비유저를 대상으로 한 파일럿은 대체로 성공적으로 끝납니다. 문제는 이걸 전 임직원 수천 명으로 확산하는 순간 드러납니다. 두 가지 벽이 동시에 나타납니다. 비용과 보안입니다.

파일럿 단계에서는 소수에게 가장 강력한 도구를 쥐어주면 됩니다. 하지만 전사로 넓히면서 같은 방식을 유지하면 비용이 감당되지 않고, 접근 경로가 늘어나는 만큼 통제해야 할 표면도 넓어집니다. 확산은 성공의 다음 단계가 아니라, 설계를 다시 해야 하는 지점입니다.

2. 비용 - 모두에게 같은 도구를 줄 필요는 없다

가장 흔한 실수는 “가장 좋은 AI를 전 직원에게”입니다. 하지만 앞선 편에서 봤듯, 일반사용자와 파워유저는 업무 성격이 다릅니다. 일반사용자는 정해진 절차를 따르는 반복 업무가 대부분이고, 파워유저는 여러 시스템을 넘나들며 판단을 내립니다.

이 차이를 비용 설계에 그대로 반영합니다.

• 헤비유저 - Claude Code와 같은 Agentic AI. 복잡한 다단계 작업과 판단이 필요한 만큼, 비용이 높더라도 이 그룹에 집중합니다.
• 일반사용자 - MS Copilot처럼 이미 사내에 보급된 가벼운 AI. 반복적인 트랜잭션 처리에는 충분합니다.

중요한 것은 두 그룹이 같은 ERP 연계 체계를 공유한다는 점입니다. Agent의 종류는 달라도 ERP에 접근하는 통로는 하나입니다. 이렇게 하면 도구별로 연계 로직을 따로 만들 필요가 없고, 나중에 헤비유저 그룹을 넓히거나 도구를 바꾸더라도 연계 계층은 그대로 유지됩니다.

3. 보안 - 접근 경로가 늘어나는 만큼 통제도 중앙화한다

전사로 확산하면 접근 경로가 기하급수로 늘어납니다. 부서마다, 팀마다, 심지어 개인마다 조금씩 다른 방식으로 AI를 SAP에 연결하기 시작하면 통제가 무너집니다. 누가 무엇에 접근할 수 있는지, 언제 무엇을 실행했는지 추적할 수 없게 됩니다.

해법은 인증과 사용 로그를 연계 계층 자체에 통합하는 것입니다.

• OAuth 인증 - 공용 기술 계정이 아니라 사용자 개인의 신원으로 접근합니다. 이렇게 해야 “누가” 요청했는지가 로그에 남습니다.
• SAP 권한 연계 - AI가 대신 실행하더라도, 실제 권한은 요청한 사람의 SAP 권한을 그대로 따릅니다. AI가 사람보다 더 많은 권한을 갖지 않습니다.
• 사용 로그 - 모든 요청과 실행 결과가 감사 가능한 형태로 기록됩니다.

공용 계정으로 AI를 붙이면 편하긴 하지만, 그 순간 누가 무엇을 했는지 구분할 수 없게 됩니다. 이 원칙은 공용 계정으로 AI를 SAP에 붙이지 마세요에서 더 자세히 다뤘습니다.

4. 비용과 보안은 같은 계층에서 다룬다

여기서 짚을 부분이 있습니다. 비용 설계(누구에게 어떤 도구를)와 보안 설계(누가 무엇에 접근하는지)는 서로 다른 문제처럼 보이지만, 실제로는 같은 계층에서 함께 다뤄야 합니다.

AI 에이전트 (Claude / Copilot)
        │
        ▼
인증 · 정책 · 감사 계층   ← 여기서 사용자 신원, 권한, 사용량이 모두 기록됨
        │
        ▼
ERP-MCP 게이트웨이
        │
        ▼
SAP S/4HANA

이 구조가 있으면 “이번 달 어느 부서가 AI를 얼마나 썼는지”, “누가 어떤 트랜잭션에 접근했는지”를 같은 로그에서 확인할 수 있습니다. 비용 관리와 보안 감사가 서로 다른 시스템에 흩어지지 않습니다. 이 통제 계층의 전체 그림은 AI를 ERP에 붙이는 건 커넥터 문제가 아니다에서 정리했습니다.

마무리

파일럿의 성공 방식을 그대로 전사에 복사하면 반드시 비용과 보안에서 막힙니다. 도구는 업무 성격에 맞게 나누고, 통로는 하나로 모으는 것. 이것이 전사 확산 단계에서 다시 설계해야 할 두 가지입니다. 다음 편에서는 이 미래상을 실제 조직이 어떻게 시작하는지, PoC부터 전사 확산까지의 로드맵을 다룹니다.