SAP ECC에서 S/4HANA로,
전환을 기다리는 동안에도
혁신은 계속되어야 합니다

다가오는 지원 종료,
진짜 문제는 ‘사람’과 ‘시간’입니다

시작은 지원 정책이지만, 그 배경에는 ERP의 운영 모델 변화가 있습니다. 이번 전환의 핵심은 S/4HANA 중심의 제품 전략과 RISE with SAP를 통한 클라우드·구독 모델 확대입니다. 지원 일정은 기술팀의 업그레이드 계획뿐 아니라, 경영진이 라이선스·운영비·향후 투자 방향을 함께 검토해야 하는 문제입니다.

ECC의 초기 인핸스먼트 패키지(EHP 0–5)는 2025년 12월에 지원이 종료되었으며, 2027년 12월은 후속 주요 버전의 핵심 지원 기한입니다. 과거의 기한 연장을 다음 계획의 전제로 삼기보다는, 현재 적용되는 지원 일정 안에서 실행 가능한 로드맵을 확보하는 것이 중요합니다.

실무 사용자에게 이 일정은 단순한 달력의 날짜가 아닙니다. ABAP 개발자는 지원되는 환경으로 이동할 방법을 찾거나, 이미 진행 중인 마이그레이션에 투입됩니다. 그동안 보고서 하나를 수정하고 데이터를 한 번 더 추출하는 일은 점점 더 긴 대기열 뒤로 밀릴 수 있습니다.

더 적은 자원으로, 더 많은 성과를 요구받는 현장

전환과 일상 운영은 같은 사람, 같은 예산을 놓고 경쟁합니다. 현업에서는 사무실 복귀 정책에 따른 직원 몰입도 변화에 대응하면서, 비용을 통제하고 예측 정확도까지 높여야 하는 과제가 동시에 쌓이고 있습니다. “데이터는 있는데, 의사결정에 쓸 수 있는 형태로 제때 꺼내지 못한다”는 문제입니다.

S/4HANA 도입률과 ECC 잔류 전망은 조사 시점과 대상에 따라 달라지므로, 같은 기준의 통계처럼 비교해서는 안 됩니다. ‘일부 또는 전체가 가동 중인 고객’과 ‘ECC 전환을 완료한 고객’을 같은 수치로 읽으면 진척도를 과대평가할 수 있습니다. 여기서 주목할 것은 정확한 비율보다 전환 수요에 비해 전문 인력과 통합 파트너의 공급이 제한적이라는 구조적 압박입니다.

전환 지연을 곧바로 의사결정 실패로 해석해서도 안 됩니다. 오랜 커스터마이징을 정리하는 비용, 업무 중단의 부담, 구독 비용의 예측 가능성, 투자수익률(ROI) 입증의 어려움은 모두 전환 속도를 좌우하는 현실적인 요인입니다. 따라서 현실적인 사업성 검토는 ‘전환 비용’만 계산하는 것이 아니라, 현재 체계를 유지하는 비용과 개선을 미루는 비용까지 같은 기간·같은 범위에서 비교하는 데서 출발해야 합니다.

ECC에 머무르는 선택에도
비용은 발생합니다

지원이 종료된다고 ERP가 어느 날 갑자기 꺼지는 것은 아닙니다. 더 현실적인 위험은 변화에 대응하는 힘이 약해지는 것입니다. 신규 기능 개선은 뒤로 밀리고, 커스텀 코드를 유지하는 부담은 남으며, 제한된 전문 인력의 시간은 더 비싸집니다. 어떤 지원 체계를 선택하느냐에 따라 수정·업데이트를 받을 수 있는 범위도 달라집니다.

이른바 ‘동결된 ERP(Frozen ERP)’입니다. 시스템은 돌아가지만 업무 개선은 멈춘 상태입니다. IT 티켓이 쌓일수록 실무자는 데이터를 따로 내려받고, 스프레드시트에서 합치고, 어제와 같은 대사를 다시 수행하게 됩니다. SOX와 각종 내부통제 요구에 답하기 위해서는 이런 우회 작업까지 추적하고 문서화해야 합니다.

“

밤 8시, 감사인의 질문에 답하기 위해
여전히 데이터를 추출하고 있는 실무자에게
필요한 것은 또 하나의 IT 티켓이 아닙니다.

실무자에게 필요한 것은 데이터에 접근하고 판단할 수 있는 업무 환경입니다.

기한 내 전환이 어렵다면, 무엇을 선택해야 할까요?

S/4HANA로 전환한다는 방향을 정했더라도 완료 시점까지의 운영 대책은 별도로 필요합니다. 기한 내 전환이 어렵다면, 현재 시스템의 지원을 이어갈 방법을 크게 세 가지로 나누어 검토할 수 있습니다. 다만 이 선택지는 ‘누가 현재 시스템을 지원할 것인가’에 대한 답이며, 데이터 활용이나 업무 혁신 전략 자체를 대신하지는 않습니다.

첫째, SAP 연장 유지보수로 전환 시간을 확보하는 방법입니다. 적용 조건을 충족하면 2030년 말까지의 지원을 검토할 수 있습니다. 기존 지원 체계를 이어갈 수 있다는 장점이 있지만 추가 비용이 발생하며, 전환 과제가 사라지는 것은 아닙니다. 계약 기간 안에 데이터 정제와 반복 검증을 실제로 진척시키는 계획이 함께 있어야 합니다.

둘째, 서드파티 지원으로 ECC 운영 기간을 재설계하는 방법입니다. 독립 지원 사업자에게 운영 지원을 맡기고 비용 구조를 조정하는 선택입니다. 판단 기준은 단순한 유지보수료 할인율이 아닙니다. 장애 해결 범위, 보안 및 법률·세무 변경 대응, 커스텀 코드 지원, 향후 SAP 전환이나 계약 변경에 미칠 영향을 확인해야 합니다. SAP 자체의 제품 로드맵과 제3자의 지원 서비스를 동일시해서는 안 됩니다.

셋째, 별도 지원 없이 ECC를 계속 운영하는 경우입니다. 장부상 비용은 낮아 보일 수 있으나, 문제 발생 시 대응 주체와 보완 통제를 기업이 직접 확보해야 합니다. 특히 규제 산업에서는 보안·감사 위험이 커질 수 있으므로, 검토 없이 일정만 미루다 이 상태에 들어가는 것을 경계해야 합니다.

이와 별개로 컴포저블(Composable) 접근을 검토할 수 있습니다. ECC를 업무의 코어로 유지하면서 주변에 분석과 자동화 기능을 덧붙여 단계적으로 개선하는 방식입니다. 이것은 네 번째 유지보수 계약이 아니라, 선택한 지원 체계 위에서 오늘의 업무를 바꾸는 운영 전략입니다. 지금 필요한 것은 IT를 배제하는 도구가 아니라, IT가 정의한 권한과 통제 안에서 현업이 직접 움직일 수 있는 방법입니다.

실무자를 위한 새로운 선택,
셀프서비스 자동화

Alteryx One과 DVW Connector for SAP의 조합은 SAP 데이터 업무를 위한 ‘맥가이버 칼’과 같습니다. SAP에 연결하고, 데이터를 정제하고, 비교하고, 보고서로 만드는 여러 작업을 시각적인 워크플로우 안에서 연결하기 때문입니다.

엑셀의 피벗 테이블, IF, VLOOKUP에 익숙한 실무자라면 필터·분기·조인이라는 개념도 비교적 친숙하게 받아들일 수 있습니다. 반복적인 데이터 준비 작업을 로우코드·노코드 방식으로 구성하면, 요청서를 쓰는 시간 대신 예외를 분석하고 판단하는 데 시간을 쓸 수 있습니다.

중요한 차이는 작업이 ‘보인다’는 점입니다. 어떤 원본에서 출발해, 어떤 조건으로 필터링하고, 어떤 기준으로 값을 바꿨는지 확인할 수 있습니다. 적절한 실행 로그·버전 관리·승인 체계를 결합하면 감사와 거버넌스를 뒷받침하는 근거가 됩니다. AI 분석 지원 기능도 활용할 수 있지만, 가용 범위는 Alteryx의 제품 구성과 라이선스에 따라 확인해야 합니다.

이 조합을 단순한 ‘데이터 추출 도구’로만 보면 활용 범위가 좁아집니다. 핵심적인 차이는 읽기와 쓰기를 연결할 수 있다는 점입니다. SAP 데이터를 가져와 분석하는 데서 끝나는 것이 아니라, 외부 분석 환경에서 검증한 데이터나 처리 상태를 지원되는 인터페이스로 다시 전달하는 흐름까지 설계할 수 있습니다. 단, 쓰기는 읽기와 별개의 권한·승인·제품 구성을 확인해야 합니다.

ECC를 유지하는 재무·세무 조직이라면 보고서 자동화, 더 촘촘한 대사, 예외를 찾아내는 자동 통제부터 시작할 수 있습니다. 중요한 것은 문제를 발견하고 근거를 남기는 능력을 높이는 것이지, 자동화 도구로 SAP의 보안 패치나 법률·세무 업데이트를 대체하는 것이 아닙니다. 유지보수 전략과 데이터 운영 전략은 서로 보완하되 역할을 구분해야 합니다.

DVW의 네이티브 연결 역시 SAP의 권한 체계를 우회한다는 뜻은 아닙니다. 연결 계정, 허용된 인터페이스, 읽기·쓰기 범위를 먼저 설계해야 합니다. ECC와 S/4HANA 양쪽을 지원하는 연결은 오늘의 프로파일링·정제·검증 규칙을 내일의 전환에 재활용할 토대가 됩니다. 다만 연결이 이어진다는 것과 기존 워크플로우가 수정 없이 작동한다는 것은 다릅니다. 타깃 데이터 모델, 인터페이스, 클라우드 배포 방식에 맞춘 재매핑과 재검증은 필요합니다.

ECC를 넘어, 여러 SAP 업무 영역을 연결합니다

기업의 데이터는 ERP 안에만 머물지 않습니다. 재무·물류는 ECC와 S/4HANA에, 분석은 BW·BW/4HANA와 SAP Analytics Cloud에, 인사와 구매는 SuccessFactors와 Ariba에 나뉘어 있을 수 있습니다. BPC·IBP의 계획 데이터, Sales·Service·Marketing Cloud의 고객 데이터, 산업별 솔루션까지 연결 범위를 넓히면 업무별로 분리된 정보를 하나의 분석·자동화 흐름으로 이어갈 수 있습니다. 실제 연결 가능 여부는 제품 버전, 배포 환경, 커넥터 구성에 맞춰 확인해야 합니다.

연결 방식에서 중요한 것은 ‘데이터가 어디에 저장되어 있는가’보다 ‘어떤 업무 인터페이스와 권한으로 접근하는가’입니다. 이 구성에서는 SAP GUI·Fiori의 UI 계층과 BAPI·RFC·OData·IDoc 등의 애플리케이션 계층을 중심으로 작업을 연결합니다. 아래 도식의 데이터베이스 계층에 표시된 ×는 HANA나 Oracle 같은 저장 엔진을 직접 조회해 SAP의 업무 로직과 권한을 우회하는 방식을 전제로 하지 않는다는 의미입니다. 읽기 소스에 등장하는 테이블이나 HANA View도 실제 접근 경로와 권한을 구분해서 설계해야 합니다.

조회에서 검증·전기까지, 하나의 워크플로우로

연결 대상이 정해지면 실제 업무의 순서를 워크플로우로 옮길 수 있습니다. 전표 업무를 예로 들면 SAP 로그온 → 입력 필터 → 회계기간 계산 → 전표 목록 조회 → ACS 필터 → 전표 상세 조회 → 전표 조정 → SAP 전표 전기로 이어집니다. 실무자가 화면과 파일을 오가며 반복하던 작업을 단계별로 구성하고, 각 단계의 입력·처리·결과를 확인하는 방식입니다.

이 구조는 읽기(Read)·업무 처리·쓰기(Write)를 분리하면서도 하나의 흐름으로 연결합니다. 테이블·리포트·BW Query·OData 등에서 데이터를 가져와 Alteryx에서 조정·검증하고, 지원되는 BAPI·IDoc·OData 등의 경로로 결과를 전달할 수 있습니다. 데스크톱에서 설계한 흐름을 서버나 클라우드에서 실행하려면 해당 환경을 지원하는 제품과 라이선스, 연결 설정이 필요합니다. Auto Insights와 AI 분석도 사용 가능한 제품 구성 안에서 결합합니다.

특히 전표 전기와 같은 쓰기 작업은 자동화할 수 있다는 이유만으로 즉시 운영에 적용해서는 안 됩니다. 테스트 환경 검증, 최소 권한, 업무 승인, 실행 로그와 예외 처리를 먼저 갖춰야 합니다. 반복적인 데이터 업무의 커스텀 ABAP 개발 부담을 줄이되 SAP 전문가의 설계·검토를 없애는 것은 아닙니다. 이렇게 정리한 연결과 검증 규칙은 현재의 업무 개선을 넘어, 다음에 살펴볼 S/4HANA 마이그레이션의 기반이 됩니다.

S/4HANA 마이그레이션을
어렵게 만드는 네 가지 허들

운영 개선에서 전환 준비로 시야를 넓혀보겠습니다. S/4HANA로의 이행은 단순히 데이터베이스를 바꾸는 일이 아닙니다. 기존의 데이터와 커스텀 프로그램이 새로운 비즈니스 모델에서도 올바르게 작동하는지 확인하는 과정입니다.

네 가지 허들은 결국 하나의 질문으로 모입니다. “데이터를 얼마나 정확하게, 그리고 얼마나 반복 가능하게 검증할 수 있는가?” 바로 이 지점에서 데이터 워크스트림이 전환 프로젝트의 중심이 됩니다.

12단계의 여정,
DVW가 연결하는 6개의 구간

마이그레이션의 전체 흐름은 아래의 12단계 로드맵으로 살펴볼 수 있습니다. 프로젝트를 이해하기 위한 예시이므로, 실제 단계와 순서는 전환 방식과 업무 범위에 맞게 조정해야 합니다. 이 중 DVW와 Alteryx의 활용이 집중되는 구간은 탐색, 정제, 매핑, 모의 적재, 대사, 병행 운영입니다.

단계를 정했다면, 다음은 ‘무엇을 옮길 것인가’입니다

이관 범위를 구체화하려면 데이터를 업무 특성과 검증 기준에 따라 나누어 살펴봐야 합니다. 자재·고객·공급업체·코스트센터·손익센터 같은 마스터 데이터는 적재 전에 중복, 누락, 오래된 레코드를 정리해야 합니다. 재무·물류의 미결 항목과 거래 데이터는 업무 연속성을 기준으로 이관 범위와 기준 시점을 합의해야 합니다.

커스텀 테이블과 Z테이블의 내용도 별도 평가 대상입니다. 여기에 담긴 업무 데이터의 이관은 ABAP 프로그램 자체의 호환성 검토와 다른 작업입니다. 데이터 영역마다 소스, 타깃 객체, 담당자, 변환 규칙, 대사 기준을 정해 두어야 ‘추출 가능한 데이터’가 ‘승인 가능한 이관 데이터’로 바뀝니다.

① 먼저, 무엇이 있는지 정확하게 파악합니다

TADIR는 레포지토리 객체 목록을, AGR_TCODES는 역할에 할당된 트랜잭션 정보를 살펴보는 출발점입니다. 여기에 배치 작업과 실제 사용 로그를 결합하면 정리할 커스텀 객체의 후보를 찾을 수 있습니다. 역할 할당 정보만으로 ‘미사용’을 단정하거나 객체를 바로 폐기해서는 안 됩니다. 업무 담당자의 확인과 SAP 호환성 점검이 함께 필요합니다.

② 연결과 변환을 하나의 흐름으로 묶습니다

추출 경로를 원시 테이블 하나로 제한할 필요는 없습니다. DVW를 활용하면 SAP Tables, T-Code·ABAP Reports, SAP Queries, BAPI, OData, BW Queries·InfoProviders, HANA Views 등 다양한 경로로 데이터에 접근할 수 있습니다. 업무 의미와 권한에 맞는 소스를 선택하고, SAP 데이터와 비SAP 데이터를 같은 워크플로우에서 조인·검증하면 이관 대상의 맥락까지 함께 확인할 수 있습니다.

여기서 제품의 역할을 구분해야 합니다. DVW Alteryx Connector for SAP는 Alteryx 환경에서 SAP 데이터 연결을 활용하는 구성입니다. 별도의 DVW Flow Tool은 100개 이상의 변환·정제 작업, 주소 검증을 포함한 AI 기반 정제, 적재 전 결과 미리보기 기능을 제공합니다. 이 기능들이 모든 커넥터에 기본 포함된다는 뜻은 아니므로, 도입할 제품과 실행 환경을 기준으로 확인해야 합니다.

타깃 적재 역시 구성 확인이 중요합니다. BAPI·RFC-enabled Function Module 쓰기, IDoc 기반 마스터·거래 데이터 적재, S/4HANA Cloud의 OData 쓰기는 Add-On 구성을 확인해야 하는 기능입니다. 따라서 ‘SAP에 연결된다’는 사실만으로 쓰기까지 가능하다고 가정하지 말고, 라이선스·대상 객체·권한·인터페이스를 함께 검증해야 합니다.

③ 모의 이행은 한 번이 아니라 반복합니다

정제 → 매핑 → 테스트 환경 적재 → 오류 확인의 사이클을 워크플로우로 구성합니다. 소스 ECC와 타깃 S/4HANA를 같은 프로세스에서 읽어 비교하면, 서로 다른 시점에 수작업으로 내려받은 파일을 맞추는 부담을 줄일 수 있습니다. 오류가 발생하면 규칙을 수정하고 같은 기준으로 다시 실행합니다. 중요한 것은 반복 횟수보다 실행마다 비교 조건과 검증 근거를 일관되게 유지하는 것입니다.

DVW Flow Tool Server를 활용하면 추출·대사 작업의 스케줄링, 무인 실행, 외부 시스템 트리거를 구성할 수 있습니다. 이는 서버 실행 환경을 갖췄을 때의 운영 기능으로, 데스크톱에서 워크플로우를 한 번 실행하는 것과 구분해야 합니다. 실무에서는 실행 시각, 원본 기준 시점, 실패 알림과 재처리 책임까지 정해 두어야 자동화가 운영 체계로 이어집니다.

④ 적재 이후의 결과까지 확인합니다

적재 완료 메시지가 곧 업무적 성공을 뜻하지는 않습니다. 최초 전체 이관 이후에도 반복 실행과 단계적 전환 중에 변경분이 발생합니다. 증분 추출에는 델타 로드 기능을 활용할 수 있지만, 이를 모든 데이터에 대한 실시간 동기화 보장으로 해석해서는 안 됩니다. 소스와 인터페이스의 변경 감지 방식, 추출 기준 시점, 재실행 시 중복 처리 기준을 별도로 설계해야 합니다.

병행 운영 구간에서는 두 시스템의 건수·금액 총계·필드 값을 같은 업무 기준으로 대사하고, 차이가 발생한 데이터 영역을 추적합니다. 가능하다면 처리 확인과 상태를 소스에 되돌려 기록하는 흐름도 고려할 수 있습니다. 이 역시 지원되는 쓰기 구성과 승인을 전제로 하며, 일방적인 추출보다 완결된 통제 절차를 만드는 데 목적이 있습니다.

“옮겼습니다”가 아니라,
“일치함을 확인했습니다”

대사(Reconciliation)는 소스와 타깃 사이의 차이를 설명할 수 있게 만드는 과정입니다. 검증은 건수, 필드 값, 집계 총계의 세 층위에서 이루어져야 합니다. 건수는 누락·중복 여부를 살피는 출발점이고, 금액 등의 집계는 업무 결과의 일관성을, 필드 비교는 개별 데이터의 변환 상태를 확인하는 근거가 됩니다. 어느 한 수준만 통과했다고 전체 이관의 정확성을 단정할 수는 없습니다.

아래 T006(측정 단위) 예시처럼 ECC와 S/4HANA에서 비교 가능한 데이터셋을 각각 추출한 뒤, 비교 키를 정하고 필드별 차이를 분류할 수 있습니다. 실제 프로젝트에서는 데이터 영역별 변환 규칙과 기준 시점도 함께 맞춰야 합니다.

‘전체 건수는 동일하다’는 결과만으로는 필드 값의 변경을 알 수 없습니다. 반대로 차이가 발견되었다고 모두 오류인 것도 아닙니다. 승인된 변환 규칙에 따른 정상 변경일 수도 있습니다. 차이 발견 → 원인 분류 → 담당자 확인 → 재검증의 과정이 있어야 대사 결과를 승인과 감사의 근거로 활용할 수 있습니다.

대사의 마지막 산출물은 ‘승인 가능한 근거’입니다

대사 결과는 Excel·PDF·대시보드 형태로 정리하고, KPI 대시보드로 이관 준비도를 추적할 수 있습니다. 중요한 것은 출력 형식보다 그 안의 정보입니다. 데이터 영역, 실행 차수, 비교 시점, 적용 규칙, 미해결 차이와 처리 책임을 함께 남겨야 현업과 감사 담당자가 결과를 검토할 수 있습니다.

예를 들어 마스터 데이터는 필수값 충족과 중복 해소 상태를, 재무 데이터는 미결 항목과 금액 대사를 중심으로 준비도를 설명할 수 있습니다. 이러한 지표는 업무 특성에 맞게 정하는 검증 기준의 예시입니다. 대시보드가 만들어졌다는 사실이 승인을 대신하지는 않습니다. 합의된 허용 기준과 담당자의 확인을 통과했을 때 비로소 ‘적재가 끝났다’를 넘어 ‘전환해도 되는 상태다’라고 설명할 수 있습니다.

새로운 ERP를 기다리지 말고,
새로운 업무 방식부터 시작하세요

ECC에 남아 있을지, S/4HANA 전환을 서두를지는 각 기업의 판단입니다. 다만 의사결정은 두 갈래로 병행해야 합니다. 하나는 지원·계약·전환 시점을 정하는 ERP 전략이고, 다른 하나는 데이터 접근·품질·통제를 개선하는 실무 실행입니다. 전자의 결론이 나지 않았다는 이유로 후자까지 멈출 필요는 없습니다.

ECC 잔류 기업에는 리포팅과 자동 통제로 현재의 운영 부담을 줄이는 데, 전환 기업에는 프로파일링·정제·모의 적재·대사로 준비도를 높이는 데 같은 데이터 역량이 쓰입니다. DVW Connector for SAP와 Alteryx의 가치는 바로 이 연결에 있습니다. 오늘 축적한 업무 규칙과 검증 근거가 내일의 이행에서도 쓰일 수 있도록 설계하면, 하나의 개선이 현재 운영과 미래 전환에 두 번 기여할 수 있습니다.