ERP 가동 전의 일을 겨냥한다: Oracle이 제시한 여섯 가지 구축 에이전트

아래에 정리한 출처를 바탕으로 Ken Jo가 제작한 설명 도식입니다.

새 업무 시스템이 청구서를 승인하려면 그 전에 누군가 승인 권한, 조직 구조, 다른 시스템과 주고받을 정보를 정해야 합니다. 이 결정은 설계 문서, 설정값, 통합 코드, 테스트로 이어집니다. 소프트웨어 구독은 그 작업의 시작일 뿐이죠.

2026년 10월 26일, Oracle은 Oracle AI Success Navigator를 통해 제공하는 에이전트 기반 구축 플랫폼을 발표했습니다. 현황 조사, 설계, 설정, 테스트, 통합, 혁신이라는 여섯 가지 에이전트 역할이 포함됩니다. 재무·인사·공급망 등의 업무 애플리케이션을 공급하는 Oracle이 이번에는 애플리케이션을 도입하고 개선하는 데 필요한 일을 겨냥했습니다. 공식 발표.

흥미로운 변화는 도움을 제공하는 시점입니다. 기존 ERP 사용을 돕는 에이전트는 이미 정해진 설정 안에서 일하지만, 구축 에이전트는 그 설정을 만드는 일을 돕습니다. 이 글에서는 Oracle 방식의 기반인 레지스트리, 세 가지 실용적인 평가 사례, 생성된 설정을 실제 운영에 적용하기 전에 요구해야 할 근거를 살펴봅니다.

업무 규칙을 설정값으로 옮기는 과정에서 일이 커진다

전사적 자원 관리, 즉 ERP는 공통 애플리케이션과 데이터 구조를 통해 주요 업무를 연결합니다. 공급업체 청구서 승인처럼 익숙한 절차에도 조직마다 다른 선택이 들어 있습니다. 올바른 설정을 만들려면 이 선택을 명확히 결정하고 일관되게 옮겨야 합니다.

예를 들어 일정 금액을 넘는 청구서에 추가 승인자가 필요하다는 가상의 요구사항을 생각해 보겠습니다. 팀은 금액, 통화, 적용할 사업부, 승인자 부재 시 처리 방식을 정해야 합니다. 구축 과정에서는 이 결정이 설계, 설정, 테스트 전반에서 유지되어야 합니다.

보기 좋은 도식만으로는 충분하지 않습니다. 문서에 적힌 규칙과 배포한 설정이 달라지면 시스템은 일관되게 작동하면서도 잘못된 일을 할 수 있습니다. 구축 업무에서 사업, 소프트웨어, 운영 환경을 이해하는 사람들 사이에 반복적인 확인과 인계가 필요한 이유입니다.

Oracle의 제안은 이 인계 과정을 겨냥합니다. 제품 고유의 지식을 계획과 설정 작업에 반영해 각 팀이 매번 다시 구성하던 설정 논리를 줄이려는 접근입니다. 우리의 판단은 이렇습니다. 의미 있는 결과는 검토된 요구사항을 테스트된 설정으로 옮기는 길이 짧아지고, 그 동작을 업무 담당자가 설명할 수 있게 되는 것입니다.

FSCR은 에이전트에게 제품에 맞는 작업 지침을 제공한다

Oracle은 같은 날 Fusion Setup and Configuration Registry, 줄여서 FSCR도 발표했습니다. 설정 옵션, 의존 관계, 적용 순서, 테스트, 검증을 포함한 구축 지식을 기계가 읽고 실행할 수 있게 담은 공개 Git 저장소라고 설명합니다. Oracle은 Fusion Applications와 함께 레지스트리를 지속적으로 관리한다고 밝혔습니다. FSCR 발표, 2026년 10월 26일.

일반적인 ERP 설명 글을 에이전트에게 모아 주는 것보다 구체적인 제안입니다. 유용한 구축 지침은 원하는 결과를 그 결과에 필요한 설정과 선행 조건에 연결해야 합니다. 설정이 의도한 결과를 만들었는지 확인하는 방법도 필요합니다.

실제 주방에 맞춰진 요리책이라고 생각하면 이해하기 쉽습니다. 재료와 순서가 실제 작업을 수행할 소프트웨어와 맞아야 합니다. 필수 준비 단계를 빠뜨린 조리법은 그럴듯하게 들려도 애플리케이션을 미완성 상태로 남길 수 있습니다.

레지스트리가 회사의 업무 정책을 대신 정하지는 않습니다. 승인 체계, 운영 방식, 허용할 예외는 조직이 결정해야 합니다. 제품 지식은 그 결정을 설정으로 옮기는 데 도움이 되지만, 더 긴 구축 계획을 만든다고 이해관계자의 의견 차이가 해소되지는 않습니다.

프로젝트 팀에는 버전의 일치 여부가 유용한 질문이 됩니다. 어떤 제품 릴리스와 레지스트리 리비전을 바탕으로 설정을 제안했을까요? 애플리케이션이 바뀌면 어떤 가정을 다시 확인해야 할까요? 이는 레지스트리 접근법에서 도출한 평가 질문이며, 특정 자동 추적 기능이 제품에 있다는 주장은 아닙니다.

여섯 역할은 구축 업무를 검토 가능한 결과물로 나눈다

Oracle의 10월 26일 발표는 에이전트별로 다른 일을 맡깁니다. 현황 조사는 현재 상태를 살피고, 설계는 업무 절차를 애플리케이션 설계로 옮기며, 설정은 프로토타입을 만듭니다. 테스트는 관련 사례를 구성하고, 통합은 기존 시스템과의 연결을 다루며, 혁신은 추가 활용 기회를 찾습니다. 단계마다 다른 검토자가 이해할 수 있는 결과물이 나와야 한다는 점에서 이 구분이 중요합니다.

구축 팀이 AI가 한 일을 하나의 큰 묶음으로 승인할 필요는 없어야 합니다. 업무 책임자는 절차 설계를, 애플리케이션 전문가는 설정을, 테스트 책임자는 의도한 동작을 시험 사례가 다루는지 검토할 수 있습니다. 결과물에 따라 나누면 논의가 구체적이 됩니다.

앞의 두 열은 발표된 역할을 요약했고, 마지막 열은 이 글에서 제안하는 평가 기준입니다. 역할의 이름만으로 모든 결과의 품질이 보장된다고 생각하지 않으면서도 유용한 결과물을 살펴볼 수 있게 합니다. 잘 구성된 초안도 실제 사용할 조직의 조건에 맞춰 시험해야 합니다.

구축 과정에서는 업무 요구사항과 이를 충족하는 설정의 연결을 유지해야 합니다. 검토 지점은 제안하는 평가 경계이며 특정 Oracle 화면의 기능을 나타내는 것은 아닙니다.

작은 재무 프로토타입으로 설계가 충분히 구체적인지 확인한다

첫 번째로 유용한 사례는 테스트 환경의 작은 재무 절차입니다. 정상 사례, 예외, 검토를 위해 멈춰야 하는 사례가 있는 승인 규칙 하나를 고르세요. 설정을 시작하기 전에 제안된 설계가 의도한 동작을 명확하게 만드는지 보는 것이 목적입니다.

예를 들어 가상의 공급업체 청구서와 승인자 후보 두 명을 제공할 수 있습니다. 설계에는 어떤 경우에 누가 처리하고 필수 정보가 없으면 어떻게 되는지 설명되어야 합니다. 이 입력은 활용 예시이며 이 글을 위해 실제 구축했다는 뜻은 아닙니다.

팀이 설계를 승인하면 프로토타입이 이를 어떻게 표현했는지 확인합니다. 요구사항, 관련 설정, 각 테스트에서 관찰한 결과 사이의 관계가 유용한 근거가 됩니다. 정상 사례가 통과하는 것도 좋지만, 예외에서 설정이 업무 규칙을 제대로 반영하는지가 더 잘 드러나기도 합니다.

모호함도 여기서 드러납니다. 두 이해관계자가 서로 다른 승인 기준 금액을 제시했다면 설정을 생성하는 것만으로 정책 문제가 해결되지 않습니다. 먼저 의견 차이를 해결하고 승인한 규칙을 기록한 뒤 관련 작업을 다시 만들거나 조정해야 합니다.

통합 시험은 애플리케이션 사이의 일을 드러낸다

두 번째 사례는 Fusion과 기존 시스템 사이의 제한된 연결입니다. 업무 객체 하나를 고르고 어느 시스템이 기준 정보를 소유하는지, 어떤 필드를 옮길지, 오류를 어떻게 처리할지 정합니다. 범위가 작으면 유용한 통합 결과와 그럴듯한 코드의 양을 구분하기 쉽습니다.

요청 재시도로 가상의 고객 기록이 두 번 도착했다고 생각해 보세요. 수신 시스템이 기존 기록을 갱신할지, 중복을 거부할지, 새 기록을 만들지 팀이 결정해야 합니다. 올바른 동작은 업무·기술 계약에 따라 달라지므로 생성된 구현 안에 암묵적으로 남겨 두면 안 됩니다.

경계 조건에서의 근거를 요청하세요. 식별자가 없거나, 대상 시스템이 응답하지 않거나, 수신 시스템이 허용하지 않는 값이 들어 있으면 어떻게 될까요? 이런 사례는 통합 논의를 성공 시연에서 운영 동작의 검토로 바꿉니다.

Oracle의 FSCR 발표는 전문가가 완성된 설정을 검토하고 수정을 요청하며 배포를 승인하는 과정을 명시합니다. 통합 결과에도 같은 원칙을 적용하세요. 생성된 작업을 검토하고 대표 데이터로 시험하며 실패한 변경을 복구할 방법을 정합니다. 결과를 유지할 팀이 연결 방식을 계속 이해할 수 있을 때 빠른 생성의 가치가 커집니다.

기존 플랫폼에서도 새 에이전트 전체를 기다리지 않고 평가를 시작할 수 있다

Success Navigator에는 이미 구축과 활용을 지원하는 공개 제품 경험이 있습니다. Oracle의 2026년 5월 11일 26.1 릴리스 설명은 AI Assist 홈페이지, 업데이트 계획, 릴리스 준비, 활용 로드맵, Starter Configuration을 다룹니다. 이 기존 기능은 10월 에이전트가 추가되는 플랫폼의 배경을 보여 줍니다. 공식 26.1 릴리스 글.

따라서 세 번째 평가 사례는 기존 Fusion 고객의 다음 업데이트입니다. 팀은 도입할 만한 기능, 영향을 받는 절차, 변화를 이해해야 할 사람을 정할 수 있습니다. 릴리스 목록에 있다는 이유로 기능을 켜기보다 활용 여부를 일관되게 판단하는 것이 기대 가치입니다.

평가를 관찰 가능한 결과에 연결하세요. 검토 절차를 단순화하려는 변화라면 현재 검토가 어떻게 진행되는지, 무엇이 개선인지부터 정합니다. 그러면 추천을 곧바로 배포 지시로 취급하지 않고 설정과 테스트에 노력을 들일 가치가 있는지 판단할 수 있습니다.

제공 범위에도 같은 정확성이 필요합니다. 10월 발표는 초기 도입 고객과 추가 에이전트를 설명하지만, 모든 역할에 공통으로 적용되는 정식 출시일이나 별도 가격을 제시하지는 않습니다. 시험을 계획하기 전에 실제 계정에 적용되는 기능과 접근 조건을 확인해야 합니다.

80%라는 수치는 한 구축 프로젝트의 특정 작업을 가리킨다

Oracle은 Lexington Health가 에이전트 기반 제공 방식을 통해 일부 설계·설정 작업의 노력을 80% 줄였다고 인용했습니다. 10월 26일 발표에 실린 고객의 설명입니다. 초기 도입 경험을 보여 주는 유용한 근거이지만, 해당 수치가 설명하는 작업 범위는 정해져 있습니다.

이 범위에 따라 숫자를 쓰는 방법도 달라집니다. 전체 ERP 프로젝트의 기간이나 예산이 80% 줄었다는 뜻도, 다른 조직이 같은 결과를 얻는다는 뜻도 아닙니다. 테스트, 데이터 작업, 통합, 교육, 조직 차원의 결정이 차지하는 비중은 프로젝트마다 다를 수 있습니다.

분모가 중요한 이유는 가상의 계산으로 이해할 수 있습니다. 어떤 프로젝트에서 설계 작업 하나에 100시간, 다른 일에 400시간이 든다고 가정하겠습니다. 그 설계 작업을 80% 줄이면 전체 500시간 중 80시간, 즉 16%를 절약합니다. 계산을 설명하기 위해 만든 입력이며 Lexington Health의 프로젝트 수치나 Oracle 성능의 추정치가 아닙니다.

발표된 비율은 측정할 질문을 만드는 데 사용하세요. 어떤 활동이 짧아졌는지, 이전 기준이 무엇인지, 남은 일은 무엇인지 묻는 것입니다. 그러면 매력적인 수치를 다른 사업 사례에 가져다 붙이지 않고 자기 팀의 제한된 작업을 비교할 수 있습니다.

첫 평가는 요구사항 하나를 결과까지 따라간다

첫 시험은 사람들이 전체 연결 과정을 살펴볼 수 있을 만큼 작아야 합니다. 명확한 인수 기준이 있는 좁은 절차는 재무 전체를 구축해 달라는 큰 요청보다 더 많은 것을 보여 줍니다. 다음은 발표된 접근법을 평가하기 위한 제안 절차입니다.

1. 접근 권한과 범위를 확인합니다. Success Navigator의 계정 요청 경로를 이용하고 조직과 환경에서 사용할 수 있는 발표 기능을 확인합니다.
2. 업무 절차 하나를 선택합니다. 담당자, 원하는 결과, 예외를 정합니다. 테스트 환경과 적절한 샘플 데이터를 사용하세요.
3. 출발점을 기록합니다. 그 작업에 현재 들어가는 노력을 추정하거나 측정하고, 관련 없는 프로젝트 활동은 비교에서 제외합니다.
4. 제안된 설계를 검토합니다. 설정 전에 모호한 요구사항을 해결합니다. 승인한 결정과 관련 제품 가정을 보존하세요.
5. 프로토타입과 통합을 살펴봅니다. 중요한 설정과 필드 매핑을 설계까지 거슬러 확인합니다. 연결이 불분명하면 수정을 요청합니다.
6. 정상·예외 사례를 실행합니다. 성공하는 업무, 정보 누락, 중복 요청, 적용되는 실패 조건을 확인하세요. 생성된 설명만이 아니라 결과를 기록합니다.
7. 확대 여부를 결정합니다. 유용한 결과, 검토 노력, 재작업을 출발점과 비교합니다. 범위를 넓히기 전에 유지 관리 책임자를 정합니다.

검토와 재작업을 포함한 제한된 작업 전체를 측정하세요. 생성 노력의 감소는 결과에 기여하는 한 요소이며 다른 구축 업무를 대신하지 않습니다.

검토 부담은 특히 많은 것을 알려 줍니다. 에이전트가 설정을 빠르게 만들어도 전문가가 승인하기 위해 모든 가정을 다시 복원해야 한다면 일이 다른 단계로 이동한 것일 수 있습니다. 반대로 설계가 명확하고 테스트를 재현할 수 있다면 생성이 즉각적이지 않아도 검토는 쉬워질 수 있습니다.

사람이 설명할 수 있는 설정이 구축 에이전트의 신뢰를 만든다

Oracle의 접근은 제품 지식, 실행 가능한 설정 지침, 전문 역할을 하나의 구축 과정으로 모읍니다. 기대할 만한 결과는 회사가 승인한 내용과 애플리케이션의 동작이 더 직접적으로 연결되는 것입니다. 검토자가 그 연결을 살펴보고 시험하며 초기 프로젝트 이후에도 유지할 수 있을 때 가치가 생깁니다.

따라서 첫 질문은 구체적이어야 합니다. 실제 요구사항 하나를 설계·설정·테스트까지 옮기면서 피할 수 있는 일을 줄이고 결과를 더 명확하게 만들 수 있을까요? 여기에 답하면 다음 구축 결정을 뒷받침할 단단한 근거가 생깁니다.

출처

• Oracle 에이전트 기반 구축 플랫폼 발표, 2026년 10월 26일: 여섯 에이전트 역할, 초기 도입, Lexington Health 인용.
• Oracle Fusion Setup and Configuration Registry 발표, 2026년 10월 26일: 레지스트리 범위와 검토 방식.
• Oracle AI Success Navigator 26.1 릴리스 글, 2026년 5월 11일: 기존 플랫폼 기능.
• Oracle AI Success Navigator 제품 페이지와 Oracle 스크린샷 사용 정책, 2026년 10월 27일 확인: 공개 화면, 계정 요청 경로, 이미지 사용 조건.

활용 사례, 제안한 평가 기준, 500시간 계산은 설명을 위한 예시입니다. 고객이 발표한 비율은 해당 출처와 범위에 맞춰 인용했으며, 이 글을 위한 구축 벤치마크는 수행하지 않았습니다.

---

Telli.sh 추천: 구축 워크숍의 노트, 승인한 결정, 참고 자료를 프로젝트가 진행되는 동안 쉽게 다시 찾아보세요. Telli.sh 계정을 만들고 프로젝트 노트를 정리하세요.