기업의 업무 환경은 공식 설계만으로 작동하지 않는다. 자동화가 처리 범위를 넓힐수록 문서 밖의 예외와 암묵적인 판단도 기계가 실행할 조건의 일부가 된다.
임시 CSV가 인프라가 될 때
영업 실적이 재무 시스템에 늦게 반영되면 누군가 CSV를 내려받아 값을 붙여넣는다. 임시방편이 매달 반복되면 월마감 절차가 되고, 담당자가 자리를 비운 날에는 업무가 차질을 빚는다. 파일 하나가 사실상 인프라로 자리 잡는다.
이런 문제를 통합 부채라고 한다. 원본이 불분명한 데이터, 문서에 없는 흐름, 특정 개발자만 아는 필드 매핑, 사람이 매달 하는 대사 작업이 모두 여기에 속한다. 코드에 남는 기술 부채와 달리 눈에 잘 띄지 않아 개발 일정에서도 빠지기 쉽다.
Dynamics 365 같은 업무 환경에서도 급하게 만든 연동과 워크플로가 하나씩 운영 절차에 섞인다. 각각은 당장의 문제를 풀지만, 전체 구조를 설계한 사람은 있는가? 결국 직원이 시스템 사이에서 값을 옮기며 미들웨어 역할까지 맡는다. 이런 상황에서 재무 책임자 1,339명 중 약 40%가 자사 재무 데이터를 온전히 신뢰하지 못한 이유도 과도한 데이터 출처, 스프레드시트 오류, 수작업 수집이었다.
아무도 그리지 못하는 연결 지도
통합 부채가 쌓이면 신기능보다 영향 범위를 모른다는 사실이 시스템 업그레이드를 가로막는다. 어떤 배치와 리포트가 멈출지 알 수 없다면 미루는 편이 안전하다. SAP ECC의 표준 유지보수는 2027년 12월 종료될 예정 이지만, 의존 관계를 모르는 기업이 기한을 안다고 쉽게 움직일 수 있을까.
SAP는 같은 이유로 ‘클린 코어’를 강조한다. 표준 테이블을 직접 수정하거나 비공개 API에 기대면 릴리스마다 재시험 범위가 넓어진다. 최하위 준수 등급인 Level D는 업그레이드와 클라우드 이전을 막는 확장 방식 을 뜻한다. 커스터마이징 자체보다 어디에 있고 무엇에 영향을 주는지 모르는 상태가 더 위험하다.
더구나 ERP 밖에는 부서가 따로 도입한 자동화 도구와 관리되지 않는 커넥터도 숨어 있다. 전면 교체를 하면 이런 불확실성이 한꺼번에 나타난다. Tennant는 ERP 전환 뒤 주문과 출하에 차질을 빚어 4분기 매출이 약 3,000만 달러 줄었고, 주가는 하루 만에 25% 하락했다. Zimmer Biomet은 구현 파트너를 상대로 1억7,200만 달러 규모의 소송 까지 제기했다. 낡은 시스템 옆에 새 시스템을 붙이고 사람과 파일로 연결할수록 다음 변경은 더 어려워진다.
사람이 하던 검증은 어디로 갔나
그 과정에서 사람은 데이터를 옮기는 데 그치지 않고, 재고가 음수이거나 거래처명이 중복되면 입력을 멈추고 원인을 확인했다. 이런 판단은 담당자의 경험에만 남아 있어 자동화 명세에서 쉽게 빠진다.
그런데 AI 에이전트는 티켓을 열고 전표 초안을 만들며 재고를 배정한다. 잘못된 값도 정상 값과 같은 속도로 처리한다. 2026년 조사에서 조직의 65%가 사내 AI 에이전트 관련 보안 사고를 경험했다. 사고의 43%는 운영 중단, 41%는 의도하지 않은 업무 행동 으로 이어졌다.
모델 성능만 높여서는 해결되지 않는다. 기업의 77%는 에이전트가 믿고 쓸 수 있는 데이터와 지식이 전체의 20% 이하라고 답했다. 실제 운영 단계에 도달한 조직은 7% 에 그쳤다. 데이터가 언제 바뀌었고 어떻게 달라졌는지 모르는데, 에이전트의 판단을 어떻게 검증하겠는가.
이런 가운데 MCP(에이전트와 업무 시스템을 연결하는 표준 프로토콜) 덕분에 업무 시스템과의 연결은 쉬워졌지만 그만큼 권한과 감사가 빠진 접점도 빠르게 늘어난다. 중복 데이터를 양쪽에서 모두 사실로 받아들이면 사람이 천천히 조정하던 오류가 중복 발주나 이중 계산으로 순식간에 번진다.
모든 것을 고치려 하지 말 것
그렇다고 통합 부채를 모두 없앤 뒤 AI를 도입하는 계획은 현실성이 낮다. 기존 구조에 곧바로 쓰기 권한을 주면 오류만 더 빨리 퍼진다. 먼저 티켓 생성이나 전표 초안처럼 되돌리기 쉬운 행동 하나를 고르고, 그 행동에 필요한 데이터 경로만 정비한다.
그 정비는 수작업을 기록하는 데서 시작된다. 누가 어느 화면의 값을 복사해 어디에 입력하는지 보면 실제 연결 구조가 드러난다. 그중 대사, 재무 보고, 마스터 데이터처럼 오류 위험이 큰 경로부터 손본다.
각 경로에는 스키마 계약, 소유자, 데이터 리니지, 신선도, 품질 SLO 네 가지가 필요하다.
- 스키마 계약은 필드 형식이 바뀌면 배포 전에 오류를 잡는다.
- 소유자는 변경이 다른 시스템에 미칠 영향까지 책임진다.
- 데이터 리니지는 바뀐 값이 어디까지 전달되는지 추적한다.
- 신선도, 품질 SLO는 기준을 벗어난 데이터에는 에이전트가 행동할 수 없게 한다.
하나라도 빠졌다면 권한은 읽기로 제한한다. 새 경로는 기존 절차와 병행하며 결과를 비교하고, 차이가 일정 기간 허용 범위 안에 있을 때만 기존 연결을 없앤다. 기능을 조금씩 옮긴 뒤 의존성이 사라진 레거시를 폐기하는 방식으로, 스트랭글러 피그 패턴 이라 부른다. 종료 조건 없이 두 경로를 남기면 원본만 다시 둘로 늘어난다.
실무에서는 수작업을 조사한 뒤 위험도가 높은 세 경로부터 시작하면 된다. 읽기 권한부터 열고, 쓰기는 승인 직전까지만 허용한다. 병행 기간과 폐기 조건은 문서로 남기고, 계약이 없는 신규 연동은 허용하지 않는다. 진척도는 연결한 시스템 수가 아니라 사라진 수작업 수로 측정한다.
목표는 사람을 AI로 바꾸는 것이 아니다. 사람이 값을 옮기지 않아도 되도록 시스템 사이에 검증 가능한 계약을 만드는 일이다. 결국 AI 프로젝트는 에이전트뿐 아니라 에이전트가 움직일 데이터 경로까지 다뤄야 한다.
자동화가 늘어날수록 조직이 관리해야 할 대상은 프로그램이 아니라 업무가 돌아가는 조건이 된다. 기술 도입의 속도와 별개로, 이 조건을 확인하고 설명할 수 있는 범위가 실제 운영 역량을 좌우한다.