누군가 에이전트에게 “이 상품 가격을 바꿔줘”, “이번 배포용 밸런스 값을 수정해줘”라고 요청하고, 그 결과가 엑셀 파일에 반영되는 환경을 생각해 보겠습니다. 파일을 고치는 일 자체는 이제 어렵지 않습니다. 문제는 그 다음입니다. 누가 어떤 기준으로 값을 바꿨는지, 변경이 유효한지, 배포 전에 누가 확인했는지, 잘못 바뀌었을 때 어디까지 되돌려야 하는지를 설명할 수 있어야 합니다.
따라서 엑셀 기반 업무 데이터를 개인별 자동화에 맡길지 판단할 때는 “AI가 파일을 잘 수정하는가”보다 “조직이 데이터 변경을 하나의 통제된 작업으로 다룰 수 있는가”를 먼저 물어야 합니다.
중앙화 도구의 역할은 개발자를 대신하는 화면을 하나 더 만드는 데 있지 않습니다. 사람, 스크립트, 에이전트가 어떤 경로로 요청하더라도 같은 검증 규칙과 승인 절차, 이력, 복구 방법을 거치게 만드는 데 있습니다.
먼저 정할 일: 파일 편집이 아니라 변경 단위를 정의한다
엑셀 업무가 개인 업무에 가까우면 각자가 자동화 도구를 만들어도 큰 문제가 없을 수 있습니다. 예를 들어 작성자 본인만 보는 분석용 표이고, 틀린 값이 들어가도 외부 시스템이나 다른 팀의 업무에 영향을 주지 않으며, 원본을 다시 만들 수 있다면 중앙 시스템을 서둘러 구축할 이유는 약합니다.
반대로 아래 조건이 겹치면 중앙 경로를 검토할 시점입니다.
- 한 파일의 값이 서비스 설정, 가격, 재고, 정산, 운영 정책, 게임 데이터처럼 다른 시스템의 결과를 바꾼다.
- 여러 사람이 같은 시트나 같은 데이터 집합을 수정한다.
- 변경 이유와 승인자를 나중에 확인해야 한다.
- 잘못된 값이 배포되면 파일을 다시 고치는 것만으로 문제가 끝나지 않는다.
- 에이전트, 매크로, 사내 도구처럼 사람이 아닌 실행 주체가 늘고 있다.
- 동일한 검증 로직을 팀마다 따로 구현하고 있다.
이때 관리 대상은 엑셀 파일이 아니라 변경 요청이어야 합니다. 변경 요청에는 적어도 변경 대상, 이전 값, 새 값, 요청자, 요청 사유, 실행 시각, 검증 결과, 승인 결과, 배포 또는 반영 결과를 남길 수 있어야 합니다.
첫 요구사항 문서에는 화면 목록보다 이 변경 단위를 먼저 적는 편이 좋습니다. 그래야 웹 UI, API, 자동화 스크립트, 에이전트 도구가 늘어나도 같은 기록 형식을 유지할 수 있습니다.
산출물: 변경 단위 정의서
| 항목 | 확인할 내용 |
|---|---|
| 변경 대상 | 파일, 시트, 행, 열, 데이터 식별자 중 무엇을 기준으로 식별할지 |
| 변경 내용 | 이전 값과 새 값을 어느 수준까지 보관할지 |
| 변경 사유 | 자유 서술만 받을지, 업무 사유를 분류할지 |
| 영향 범위 | 어떤 서비스, 배포물, 후속 작업에 영향을 주는지 |
| 승인 기준 | 금액, 권한, 환경, 데이터 유형에 따라 승인자를 달리할지 |
| 복구 기준 | 이전 버전 복원, 반대 변경 적용, 재배포 중 무엇으로 되돌릴지 |
중앙화 여부는 영향도와 재현 가능성으로 판단한다
중앙 도구를 만들지 말지 논의할 때 “엑셀은 원래 협업에 불편하다”만으로는 부족합니다. 다음 네 축을 놓고 현재 업무를 평가해야 합니다.
첫째는 영향도입니다. 셀 하나를 바꿔도 고객 가격, 지급 금액, 서비스 노출, 운영 규칙처럼 되돌리기 어려운 결과가 생긴다면 변경 전 검증과 승인 경로가 필요합니다.
둘째는 동시성입니다. 여러 사람이 같은 데이터를 수정하면 단순한 파일 공유보다 충돌 처리 규칙이 중요해집니다. 누가 최신 값을 기준으로 수정했는지 모르면, 각각 올바른 자동화가 실행돼도 결과는 잘못될 수 있습니다.
셋째는 재현 가능성입니다. “누가 에이전트에게 요청해서 바꿨다”는 설명만으로는 충분하지 않습니다. 같은 요청을 다시 검토할 때 입력 데이터, 적용한 규칙, 생성된 결과를 확인할 수 있어야 합니다. 에이전트의 자연어 응답은 보조 설명이 될 수 있지만, 변경 기록 자체를 대신하지는 못합니다.
넷째는 복구 비용입니다. 파일 버전을 되돌리는 비용과 운영 결과를 바로잡는 비용은 다릅니다. 잘못된 가격이 외부에 노출되었거나 잘못된 데이터가 후속 시스템으로 전달되었다면, 원본 파일 복원 외에 영향 범위 확인과 후속 조치가 필요할 수 있습니다.
이 네 항목 중 영향도와 복구 비용이 높다면, 자동화의 편리함보다 중앙 실행 경로를 먼저 설계하는 편이 안전합니다. 반대로 영향이 좁고 작성자 스스로 되돌릴 수 있으며 공유 데이터가 아니라면 개인 자동화를 허용하되, 중앙 도구 후보 목록에만 올려 두는 방식도 가능합니다.
구축 순서: 읽기, 제안, 실행을 한 번에 열지 않는다
중앙화 도구는 수정 API부터 공개하면 설계가 흔들리기 쉽습니다. 특히 에이전트가 호출할 수 있는 인터페이스를 제공하려면 조회, 변경 제안, 실제 반영을 나누어야 합니다.
1. 현재 파일 흐름과 데이터 책임자를 확인한다
먼저 어떤 엑셀 파일이 어떤 시스템으로 변환·배포되는지 그립니다. 원본 엑셀, 변환 산출물, 검증 프로그램, 배포 대상, 담당 조직을 한 장의 흐름도로 정리합니다.
이 단계에서 반드시 찾아야 할 것은 “파일을 고칠 수 있는 사람”이 아니라 “값의 의미를 판단할 수 있는 사람”입니다. 예를 들어 가격의 형식 오류는 시스템이 찾을 수 있어도, 할인 정책에 맞는 가격인지는 업무 책임자가 판단해야 할 수 있습니다.
산출물: 데이터 흐름도와 책임 매트릭스
- 원본 데이터의 소유자
- 검증 규칙의 소유자
- 승인자와 승인 조건
- 배포 실행자 또는 실행 시스템
- 장애 발생 시 복구를 결정하는 담당자
- 변경 이력의 보존 위치
2. 사람이 읽는 차이와 기계가 검증하는 차이를 분리한다
엑셀 파일은 코드처럼 줄 단위 변경을 읽기 어렵습니다. 따라서 중앙 도구는 파일이 바뀌었다는 사실만 보여주기보다, 시트·행·열·식별자 기준으로 무엇이 달라졌는지 구조화해 보여줄 필요가 있습니다.
다만 사람이 보는 diff와 시스템 검증은 다른 역할을 합니다. diff는 검토자가 변경의 맥락을 파악하게 돕고, 검증기는 허용되지 않는 값을 차단합니다. 둘 중 하나만 있으면 부족합니다.
검증 규칙은 다음처럼 나눠 적는 것이 좋습니다.
- 형식 검증: 필수 값, 데이터 형식, 허용 범위, 중복 여부
- 참조 검증: 다른 시트나 기준 데이터에 존재하는 값인지
- 업무 규칙 검증: 상태 조합, 가격 정책, 배포 조건처럼 업무 의미를 가진 규칙
- 영향 검증: 변경 결과가 생성 파일, 빌드, 배포 과정에서 문제를 일으키는지
검증 실패 시에는 “실패했다”는 결과만 남기지 말고, 어느 데이터 식별자와 어떤 규칙에서 실패했는지 반환해야 합니다. 원본 파일이 바이너리 형식이라 변경 내용을 일반 코드 리뷰처럼 읽기 어렵다는 문제를 줄이는 핵심이 여기 있습니다.
산출물: 변경 diff 명세와 검증 규칙 목록
3. 에이전트에는 수정 권한보다 변경 제안 권한부터 준다
에이전트가 업무 데이터를 다루게 하려면 처음부터 직접 반영 권한을 부여할 필요가 없습니다. 초기 단계에서는 다음 흐름이 더 적합합니다.
- 사용자가 자연어로 변경을 요청한다.
- 에이전트 또는 자동화 도구가 구조화된 변경안을 만든다.
- 중앙 검증기가 변경안을 검사한다.
- 사람 또는 정책 엔진이 승인 여부를 결정한다.
- 승인된 변경만 원본 또는 운영 데이터에 반영한다.
- 반영 결과와 변경 ID를 요청자에게 돌려준다.
이 방식이면 에이전트는 변경을 제안하는 역할을 맡고, 중앙 도구는 검증과 실행을 담당합니다. 나중에 충분히 검증된 변경 유형만 자동 승인 대상으로 넓힐 수 있습니다.
에이전트 연동에 MCP 같은 도구 호출 인터페이스를 검토할 수는 있습니다. 다만 프로토콜 선택보다 중요한 것은 호출 경로가 기존 권한 확인과 입력 검증을 우회하지 않는다는 점입니다. UI에서만 적용하던 검증을 별도 도구 호출에서 빼버리면, 중앙화의 목적이 사라집니다.
산출물: 변경 요청 API 또는 도구 계약서
- 조회 가능한 데이터 범위
- 제안 가능한 변경 유형
- 실행 가능한 변경 유형
- 호출 주체의 인증 방식
- 사용자 권한과 실행 권한의 연결 방식
- 승인 대기, 실패, 반영 완료 상태값
- 동일 요청의 중복 실행을 막는 요청 식별자
승인과 복구는 데이터 유형별로 다르게 설계한다
모든 변경에 사람 승인을 붙이면 자동화가 멈추고, 모든 변경을 자동 반영하면 중앙 통제가 약해집니다. 데이터 유형별로 승인 정책을 나누는 편이 현실적입니다.
예를 들어 형식 교정이나 정해진 목록에 대한 단순 추가처럼 영향이 제한된 작업은 검증 통과 후 자동 반영 후보가 될 수 있습니다. 반면 가격, 지급 기준, 서비스 노출 조건, 권한 관련 값처럼 영향이 큰 데이터는 변경 제안과 검증 결과를 사람이 확인하도록 둘 수 있습니다.
승인은 “승인 버튼을 눌렀다”는 기록으로 끝나지 않아야 합니다. 승인자는 무엇을 보고 승인했는지 판단할 수 있어야 합니다. 변경 diff, 검증 결과, 영향 범위, 요청 사유를 한 화면 또는 하나의 검토 단위에서 연결해야 하는 이유입니다.
복구도 사전에 방식별로 정해야 합니다. 이전 파일을 통째로 되돌리는 방법은 빠를 수 있지만, 그 사이 반영된 정상 변경까지 함께 사라질 수 있습니다. 반대로 특정 변경만 취소하는 방식은 더 정교하지만, 취소 후에도 데이터 규칙을 만족하는지 다시 검증해야 합니다.
산출물: 승인 정책표와 복구 런북
복구 런북에는 최소한 다음 질문의 답을 넣습니다.
- 어떤 변경 ID를 취소할 것인가?
- 이미 생성·배포된 산출물은 무엇인가?
- 반대 변경을 적용할지, 이전 버전을 복원할지?
- 복구 후 어떤 검증을 다시 실행할지?
- 영향을 받은 팀이나 시스템에 무엇을 알려야 하는지?
Git 저장소는 이력의 일부일 뿐, 운영 통제 전체는 아니다
엑셀 파일을 Git으로 관리하면 버전 자체는 남길 수 있습니다. 그러나 바이너리 파일은 코드처럼 변경 내용을 읽기 쉽지 않고, 파일 크기와 저장소 운영 방식도 함께 고려해야 합니다. GitHub는 저장소 크기, 단일 객체 크기, 읽기·쓰기 활동량이 커질수록 기본 Git 작업과 화면 응답이 느려질 수 있다고 안내합니다. 대용량 또는 생성 산출물을 모두 저장소에 쌓는 방식은 별도 검토가 필요합니다.
따라서 Git을 사용하더라도 다음 역할을 구분하는 편이 낫습니다.
- Git: 버전, 코드와 데이터의 연결, 검토 흐름
- diff 서비스: 시트·행·셀 수준의 변경 해석
- 검증기: 데이터 규칙과 변환·빌드 조건 검사
- 승인 서비스: 권한과 승인 정책 적용
- 실행 기록: 요청부터 반영·복구까지의 감사 이력
- 배포 경로: 승인된 결과를 운영 환경에 전달
이 구분은 처음부터 서비스를 여러 개로 나누라는 뜻은 아닙니다. 초기에는 기존 데이터 처리 서버 안에 인터페이스를 추가하고 기존 검증 로직을 재사용할 수 있습니다. 다만 에이전트 연동 부분, 변경 처리 로직, 데이터 검증 로직의 책임을 코드 수준에서 분리해 두면, 호출량이나 운영 요구가 커졌을 때 독립적으로 옮길 여지가 생깁니다.
운영 전 검증에서는 정상 수정보다 실패와 되돌리기를 시험한다
출시 전 데모에서 “값을 바꾸고 화면에 보인다”는 장면만 확인하면 부족합니다. 아래 상황을 테스트 시나리오로 만들어야 합니다.
- 필수 값이 빠진 변경안이 검증 단계에서 차단되는가
- 같은 데이터를 두 요청이 동시에 수정할 때 충돌을 감지하는가
- 권한 없는 사용자가 에이전트 또는 API를 통해 우회 실행할 수 없는가
- 승인 전 변경이 배포 대상에 섞이지 않는가
- 변환 또는 빌드 실패 시 원인을 변경 단위까지 좁힐 수 있는가
- 반영 후 특정 변경만 취소했을 때 재검증이 수행되는가
- 실행 주체가 사람, 스크립트, 에이전트여도 같은 이력이 남는가
산출물: 운영 전 시험 결과와 권한 검토 기록
이 시험에서 반복해서 막히는 지점이 있다면 중앙화 도구의 범위를 줄여야 할 수도 있습니다. 모든 엑셀 업무를 하나의 플랫폼으로 옮기는 것이 목표는 아닙니다. 여러 사람이 공유하고, 다른 시스템에 영향을 주며, 설명과 복구가 필요한 변경부터 통제된 경로로 옮기는 것이 우선입니다.
개발 리드는 다음 회의에서 “에이전트가 이 파일을 수정해도 되는가”라고 묻기보다, “이 변경이 실패했을 때 우리는 요청, 검증 결과, 승인자, 반영 범위, 복구 방법을 한 번에 찾을 수 있는가”를 확인해 보십시오. 그 질문에 답하기 어렵다면 자동화 권한을 넓히기보다 변경 경로부터 설계할 때입니다.
