컨설턴트는 실제로 무엇을 하는가: 현실적인 관점

SAP 컨설턴트는 기업을 위해 SAP를 구성하고, 개발하고, 테스트하고, 안정화합니다. 실제로 그들이 내는 가치의 대부분은 프로그램 중반에 나옵니다. 표류한 범위를 정리하고, 아무도 하지 않은 워크스루를 진행하고, UAT 결함을 분류하고, Go-Live 이후 운영을 안정시킵니다. 기능 컨설턴트는 모듈 구성을, 기술 컨설턴트는 확장과 통합을, 프로그램 및 변화 관리 컨설턴트는 딜리버리와 정착을 맡습니다. 이 글은 외부 도움을 들일지 고민하는 리더와 컨설팅을 커리어로 저울질하는 분을 위한 것입니다. 리더라면 아래 신호 표가 언제 연락해야 하는지 알려 줍니다. 컨설턴트라면 일상 업무를 다룬 부분에서 이 일이 실제로 무엇을 뜻하는지 볼 수 있습니다.

외부 지원을 검토할 때마다 같은 질문이 나옵니다. 우리가 직접 할 수 없는 일을 컨설턴트는 도대체 무엇을 하는가?

솔직한 답은 컨설팅 업계에 썩 듣기 좋지는 않습니다. 가치의 대부분은 깨지지 말았어야 할 것을 고치는 데서 나옵니다. 진작 던졌어야 할 질문을 던지는 데서 나옵니다. 그리고 내부 팀이 여력도 명확한 시야도 바닥난 바로 그 시점에 역량과 명확성을 보태는 데서 나옵니다.

내부 팀을 탓하는 말이 아닙니다. SAP 프로그램은 원래 그렇게 돌아가는 경향이 있습니다. 내부 팀은 빠듯합니다. 시스템 통합 업체(SI)에게는 자기 우선순위가 있습니다. 의사결정은 쌓이고 범위는 표류합니다. 12개월짜리 프로그램이 6개월째에 접어들었을 때 누군가 이슈 로그를 열어 보면, 3주 차부터 그대로 있는 “해결 예정” 항목이 20개 나옵니다.

보통 그때 전화가 옵니다.

일부 컨설턴트는 청사진이나 계획 단계에 투입됩니다. 다수는 프로젝트 중반에 연락을 받는데, 흔히 두세 달 더딘 진행이나 인수인계 누락이 이어진 뒤입니다. 운영위원회 보고서는 주황색입니다. 팀은 열심히 일합니다. 진행은 더디고, 정확히 왜 그런지 말하는 사람은 없습니다.

1. Explore워크숍과 갭Fit-to-Standard 워크숍, 갭 문서화
2. Realize구축과 워크스루구성과 확장. 복구 요청은 보통 프로젝트 중반에 들어옵니다
3. DeployUAT 결함 분류와 컷오버구성, 프로세스, 교육 중 어느 쪽의 갭인가? 분류가 결정합니다
4. Hypercare안정화첫 월 마감과 이슈 큐

일반적인 투입 계기는 이렇습니다.

1. 범위가 표류했습니다. Explore에서 서명한 내용이 구축 팀이 지금 작업하는 내용과 더 이상 맞지 않습니다. 요구사항이 워크숍에서 비공식적으로 추가되었고, 변경 로그는 관리되지 않았으며, 확정된 범위 목록을 가진 사람이 없습니다.
2. 핵심 워크스트림이 멈췄습니다. 데이터 마이그레이션이 몇 주째 같은 오류율에서 벗어나지 못하는데 개선 계획이 없습니다. UAT에서는 닫는 결함보다 여는 결함이 더 많습니다.
3. Go-Live 일자는 고정인데 계획이 이를 뒷받침하지 못합니다. 이사회가 날짜를 정했습니다. 계획은 실제 진행과 대조되지 않았습니다. 프로그램 매니저는 이 궤적으로는 날짜를 맞출 수 없다는 것을 알지만 아직 에스컬레이션하지 않았습니다.

어느 경우든 일은 기존 계획에 인원을 더하는 것이 아닙니다. 실제로 무슨 일이 벌어지고 있는지 살피고, 문제를 분명하게 이름 붙이고, 앞으로 나아갈 길을 만드는 것입니다. SAP 프로젝트를 정상 궤도로 되돌리는 방법에 관한 제 가이드가 그 복구 순서를 다룹니다.

범위와 프로세스 명확화

구성은 맞는데 그 주변의 프로세스가 무너져 있을 때가 있습니다. 흔한 패턴은 이렇습니다. 팀이 Explore에서 나온 Fit-to-Standard 문서를 기준으로 구성했는데, 현업 사용자들은 서명 이후 그 구성을 한 번도 본 적이 없습니다. 무엇을 만들고 있는지 말로만 들었지, 직접 보지는 못한 것입니다.

해결책은 기술적인 것이 아닙니다. 소통의 간극입니다. 할 일은 UAT 전에 현업 사용자에게 구성을 하나씩 짚어 가며 보여 주고, 테스트가 시작되기 전에 변경 사항의 명확한 목록을 만드는 것입니다.

화려하지 않습니다. 일이란 원래 이런 모습입니다.

기술 팀과 현업 팀 사이의 통역

SAP 프로그램은 기술적으로는 맞지만 현업이 쓸 수 없는 결과물을 자주 내놓습니다. 사례의 90%에서는 작동하지만 수출 오더에서는 깨지는 가격 결정. 정확하게 전기되지만 정산 팀이 알아보지 못하는 재무 문서를 만들어 내는 자재 이동.

기능 컨설턴트가 그 간극을 메웁니다. 그 자리에서 가장 기술적인 사람이어서가 아닙니다. 시스템의 동작과 비즈니스에 미치는 영향을 충분히 이해해서, 적절한 사람들이 적절한 결정을 내릴 수 있게 하기 때문입니다.

UAT 지원

사용자 인수 테스트(UAT)는 프로그램에 쌓인 결정들이 버텨 내느냐 무너지느냐가 갈리는 곳입니다. Explore에서의 모든 지름길, 모든 비공식 범위 추가, 요약 수준으로 작성된 모든 테스트 케이스가 여기서 드러납니다.

좋은 UAT 지원은 결함을 올바르게 분류해, 구성 갭, 프로세스 갭, 교육 갭을 가려내는 것을 뜻합니다. 현업 사용자가 연이은 실패에 부딪혀 프로그램 전체에 대한 신뢰가 흔들릴 때 분위기를 관리하는 것도 포함합니다. 그렇지 않으면 UAT 세션에서 나오는 결함 하나하나가 Go-Live를 의심할 이유가 되는데, 대개 분류가 부실했고 “Go-Live 준비 완료”가 무엇인지 아무도 정의하지 않았기 때문입니다.

Go-Live 이후 안정화

SAP 컨설팅에서 가장 화려하지 않은 일이 하이퍼케어입니다. Go-Live가 끝나고, 축하 이메일이 나가고, 구축 팀이 빠지기 시작합니다. 그러다 첫 월 마감이 닥칩니다. 전기 내역이 정산 양식과 맞지 않습니다. 생산 오더는 완료되는데 정산되지 않습니다. 교육은 받았지만 예외 상황에는 준비되지 않은 사용자들로 헬프 데스크가 가득 찹니다.

여기가 진짜 가치의 상당 부분이 만들어지는 곳이며, 대부분의 프로그램이 인력이 가장 부족한 곳이기도 합니다. 하이퍼케어 팀은 이슈 큐를 체계적으로 처리하고, 구조적 문제와 일회성 오류를 구분하며, 시스템에 대한 신뢰를 다시 쌓습니다.

일의 구조는 달라지지 않았습니다. 시간 배분이 달라졌습니다.

문서는 대부분 알아서 초안이 만들어집니다. 2025년부터 정식 출시된 SAP Joule for Consultants는 SAP Note를 포함한 SAP 자체 지식 베이스에서 구성 질문에 답하고 ABAP 코드를 설명합니다. SAP Cloud ALM의 Joule 기반 어시스턴트는 워크숍 자료에서 요구사항과 테스트 케이스 초안을 작성합니다. 기능 컨설턴트는 문서를 타이핑하는 시간이 줄고, 워크숍 결론을 따져 보는 시간이 늘어납니다.

코드는 쓰기보다 리뷰하는 일이 많아집니다. SAP의 개발자 어시스턴트는 코드 초안을 작성하며, SAP BTP의 Java와 JavaScript 확장을 위한 SAP Build Code도 그중 하나입니다. 기술 컨설턴트는 이제 그것을 리뷰하고, 보안을 점검하고, 테스트합니다.

하이퍼케어 데스크에는 반복적인 질문이 줄어듭니다. Joule은 휴가 잔여일이나 경비 처리 상태 같은 반복적인 질문에 SAP 애플리케이션 안에서 답할 수 있어 하이퍼케어 데스크의 물량 일부가 줄어듭니다. 컨설턴트의 시간은 프로세스 갭, 마스터 데이터 문제, 사람이 필요한 사례로 옮겨 갑니다.

컨설턴트를 투입하는 이유는 달라지지 않았습니다. 이런 도구를 익힌 컨설턴트는 판단, 소통, 에스컬레이션에 더 많은 시간을 쓰고, 이제 AI가 충분히 초안을 쓰는 일에는 덜 씁니다. Joule for Consultants에 대한 SAP의 공식 설명이 이 도구가 다루는 범위를 공정하게 요약합니다.

기능 컨설턴트는 FI, CO, SD, MM, PP, EWM 또는 SuccessFactors 같은 모듈에 특화되어 있습니다. 비즈니스 프로세스에 맞춰 시스템을 구성하고, SAP 표준과 고객 요구사항 사이의 간극을 메웁니다. 이들의 가치는 모듈 전문성에 비즈니스 프로세스 지식을 더한 데 있습니다.

기술 컨설턴트(ABAP 개발자, SAP BTP 전문가, 통합 아키텍트, Basis)는 구성으로 다룰 수 없는 확장과 통합을 개발합니다. 최신 S/4HANA 프로그램에서는 Clean Core 원칙에 따라 신규 확장이 SAP BTP나 공개된 API로 옮겨 가는데, 이는 전통적인 ABAP 수정과는 다른 역량이 필요합니다.

프로젝트 및 프로그램 매니저는 딜리버리 구조를 제공합니다. 거버넌스, 리스크, 일정, 이슈 해결을 맡고, 프로그램 전체를 조망하므로 문제가 위기가 되기 전에 에스컬레이션됩니다.

변화 관리 컨설턴트는 사람 쪽을 다룹니다. 교육, 커뮤니케이션, 참여, 그리고 사용자가 시스템을 받아들일지 우회할지를 가르는 거버넌스입니다.

대규모 SAP 프로그램은 대부분 네 가지가 모두 필요합니다. 중견기업 프로그램은 적은 인원이 여러 역할을 겸하는 경우가 많고, 공백이 생기는 곳이 바로 거기입니다. 컨설팅 프레임워크와 컨설팅에서 중요한 역량은 네 가지 모두에 똑같이 적용됩니다. 컨설턴트로서 이 역할들 사이에서 자신의 경로를 그리고 있다면, SAPopedia가 커리어 경로와 과정을 정리해 두었고, ERPCV가 그 경험을 채용 담당자에게 보여 주도록 돕습니다.

컨설팅에서 가장 값비싼 실수는 사람을 너무 늦게 부르는 것입니다. Go-Live 4~6주 전의 컷오버 전 리스크 점검은 아직 시간이 있을 때 치명적인 문제를 찾아낼 수 있습니다. 컷오버가 실패한 뒤의 복구 투입은 비용이 훨씬 많이 듭니다. 게다가 운영 압박 아래에서, 시스템에 대한 신뢰를 잃은 조직 안에서 진행됩니다.

아래 표는 신호와 그에 맞는 도움을 정리한 것입니다.

신호	보통 의미하는 것	투입할 도움	2주 안에 내놓아야 할 결과
해결 예정일 없이 4주 넘게 열려 있는 이슈 로그 항목	기술이 아니라 거버넌스의 문제	독립적인 프로그램 어드바이저	책임자와 기한이 있는 의사결정 목록
Go-Live가 60일 이내인데 컷오버 리허설이 없음	검증되지 않은 컷오버. Go-Live에서 만난 돌발 상황은 실시간으로 만회할 수 없음	컷오버 또는 프로그램 리드	리허설을 마친 컷오버 계획과 Go/No-Go 기준
업무 오너들이 참석을 멈춤	의도적으로 개입하지 않으면 UAT는 실패함	변화 관리 리드와 기능 리드	핵심 사용자 대상 워크스루와 재참여 계획
한 워크스트림이 몇 주째 같은 오류율에 머묾	근본 원인을 찾지 못함	해당 워크스트림의 전문가	근본 원인 분석과 복구 계획
SI의 보고가 프로그램 건전성에 대한 유일한 시각임	독립적인 검증이 없음	고객 측 어드바이저	스폰서를 위한 솔직한 건전성 진단

SAP 컨설턴트는 프로젝트에서 실제로 무엇을 합니까?

비즈니스 요구사항을 분석하고, 이를 뒷받침하도록 SAP를 구성하며, SAP 기본값과 비즈니스에 필요한 것 사이의 간극을 메웁니다. Explore에서는 Fit-to-Standard 워크숍을 진행하고 갭을 문서화합니다. Realize에서는 구성을 구축하고 개발자와 함께 확장 작업을 합니다. Deploy에서는 UAT를 지원하고, 결함을 관리하고, 컷오버를 준비합니다. 하이퍼케어에서는 Go-Live 이후의 이슈를 해결합니다. 직무 기술서에 빠져 있는 부분은 단계 사이의 갭을 분류하고 압박 속에서 딜리버리 규율을 유지하는 일입니다.

조직은 실제로 언제 컨설턴트가 필요합니까?

대부분의 투입은 세 가지 상황으로 설명됩니다. 첫째는 프로그램 복구로, 범위가 표류했거나 워크스트림이 멈췄거나 Go-Live 일자가 위태로울 때입니다. 둘째는 전문 역량으로, PP-PI 구성이나 SAP BTP 통합처럼 팀에 모듈이나 기술 역량이 없을 때입니다. 셋째는 거버넌스로, 시스템 통합 업체가 운영하는 프로그램을 독립적으로 감독하고 싶을 때입니다. 상황이 나빠지기를 기다렸다가 부르는 것이 가장 흔한 패턴이며 가장 값비쌉니다.

기능 SAP 컨설턴트와 기술 SAP 컨설턴트는 어떻게 다릅니까?

기능 컨설턴트는 FI/CO, SD, MM, PP, EWM 같은 모듈에서 비즈니스 프로세스를 뒷받침하도록 SAP를 구성하며, 요구사항을 두고 현업 사용자와 직접 일합니다. 기술 컨설턴트는 구성으로 할 수 없는 것을 만듭니다. ABAP와 BTP 확장, 통합, 그리고 Basis를 통한 시스템 관리입니다. Clean Core 원칙에 따라 기술 작업은 시스템 내부의 ABAP 수정에서 BTP 확장과 공개된 API 쪽으로 옮겨 가고 있습니다.

컨설턴트가 가치를 더하고 있는지 어떻게 알 수 있습니까?

세 가지 지표가 있습니다. 기존 의견을 확인해 주는 데 그치지 않고, 검증된 적 없는 가정과 미뤄진 의사결정을 드러냅니다. 몇 주째 막혀 있던 의사결정이 내려지기 시작합니다. 그리고 항목을 해결 없이 닫아서가 아니라 근본 원인이 고쳐져서 이슈 로그가 줄어듭니다. 활동이 있는데도 로그 길이가 그대로라면, 문제가 구조적이거나 조치가 원인에 닿지 못하고 있다는 뜻입니다.

컨설팅 업무에서 가장 어려운 부분은 무엇입니까?

고객이 이미 알면서도 손대지 못한 문제에 이름을 붙이는 일입니다. 표류한 범위, 작성되지 않은 테스트 케이스, 참여를 멈춘 스폰서 같은 것들입니다. 그러려면 말이 먹힐 만큼의 신뢰, 믿어 줄 만큼의 신뢰성, 불편한 말을 할 만큼의 직설이 필요합니다. 진단을 희생해 가며 관계를 지키는 컨설턴트는 값비싼 맞장구일 뿐입니다.

고객에게 이미 SI가 있는데 왜 독립 컨설턴트를 고용합니까?

시스템 통합 업체는 계약된 범위를 인도할 책임이 있습니다. 독립 컨설턴트는 성과에 대해 고객에게 책임을 집니다. 서로 다른 일입니다. 고객 측 어드바이저는 설계 가정에 이의를 제기하고, 그 설계가 비즈니스 요구를 충족하는지 검증합니다. 변경 통제에서 고객의 상업적 입지를 지키고, 통합 업체의 보고를 거치지 않은 프로그램 건전성의 시각을 경영진에게 제공합니다. 이것은 통합 업체를 비난하는 말이 아니라 구조적인 이해 상충입니다.