SAP 시리즈 1탄에서는 SAP ERP를 간략하게 설명하고 프로젝트 인력 구조와 특징에 대해 살펴보았습니다. 이번 포스팅에서는 SAP 프로젝트를 수행하는 모듈 컨설턴트(이하 '컨설턴트')와 ABAP 개발자(이하 '개발자')의 역할과 관계에 대해 조금 더 현실적인 이야기를 다루고자 합니다.
SAP 시장의 관행
SAP 프로젝트를 수행하다 보면 컨설턴트와 개발자의 역할이 명확히 구분되어 있는 것처럼 보이지만 사실 이들 사이에는 미묘한 갈등의 구간이 존재한다. 이 갈등의 원인을 쫓다 보면 결국 SAP 인력 시장에서 오랜 기간 동안 이어온 관행이 현재까지도 깨지지 않는 불문율처럼 자리 잡고 있다는 결론에 도달하게 된다.
SAP 인력 시장에서 당연하게 인정되고 공감대가 형성된 관행은 크게 네 가지가 있다.
- 첫째, 컨설턴트와 개발자는 한 개 모듈에 대해서만 전문적으로 수행한다. 단, 개발자의 경우 두 개 이상의 모듈 개발을 할 수는 있지만 SCM과 FCM의 영역을 넘나들지 않는다. 한 개발자가 MM(자재관리)과 PP(생산계획) 모듈의 개발을 할 수는 있지만 FI(관리회계) 모듈 개발은 하지 않는다는 것이다.
- 둘째, ABAP 프로그램 개발이나 수정이 필요한 프로젝트 인력은 컨설턴트와 개발자가 반드시 쌍으로 구성되어야 한다. 컨설턴트는 프로세스 설계와 개발스펙을 작성하고 개발자는 개발스펙에 준하여 개발을 한다는 명확한 역할 구분이 있다는 것이다.
- 셋째, 고객의 요구조건을 분석하고 이해관계자와 의사소통 하는 것은 컨설턴트의 고유한 역할이다. 즉, 개발자는 고객사와 직접 의사소통 하지 않는다는 것이다. 실제로 고객사 이해관계자 중 대부분은 프로젝트에 투입된 개발자가 누구인지 전혀 모른 체 프로젝트가 종료되는 경우가 많다.
- 넷째, 컨설턴트의 투입 단가는 개발자 보다 무조건 높다. 필자가 15년 이상 SAP 관련 업무를 진행하면서 개발자의 단가가 컨설턴트보다 높게 지급된 경우는 맹세코 단 한번도 없었다. 필자는 컨설턴트와 개발자 사이에 미묘한 갈등이 생기는 가장 큰 원인이 바로 네 번째 관행이라고 확신한다.
요약하자면, '컨설턴트는 절대 개발을 하지 않고 개발자는 프로세스 설계에 관여하지 않는다.' 그리고 '프로젝트에 투입되는 단가는 컨설턴트가 무조건 높다.'이다. 각자의 역할이 명확해서 얼핏 바람직한 관계처럼 보이지만 프로젝트를 기획하는 입장에서는 이만한 비효율이 따로 없다.
컨설턴트와 개발자의 미묘한 갈등
위 네 가지 관행은 특히 우리나라에서 심하게 고착화 되어 있다. 이번 챕터에서 다루게 될 내용은 현재 활동하고 있는 컨설턴트나 개발자들이 보기에는 다소 불편할 수 있다.
앞서 포스팅한 SAP 시리즈 1탄에서 컨설턴트와 개발자에게 요구되는 역량이 무엇인지를 설명했다. 컨설턴트는 커뮤니케이션 스킬과 분석 및 문제해결 능력이 필요하며 개발자는 ABAP 프로그래밍 언어를 능숙하게 다룰 줄 알아야 한다. 공통적으로 필요한 역량은 해당 비즈니스에 대한 이해와 모듈 지식이다.
컨설턴트에게 요구되는 역량은 개인의 성향이나 타고난 기질, 노력으로 누구나 확보할 수 있는 영역이다. 공통 필요 역량은 다양한 프로젝트 경험과 학습으로 쌓을 수 있는 노하우 성격의 역량이다. 이쯤 되면 의문이 생길 것이다. SAP 프로젝트는 왜 굳이 컨설턴트와 개발자의 역할을 분리하여 비효율을 초래하는가.
SAP를 처음 시작하는 모든 사람들에게는 두 가지 선택의 길이 열려있다. 요구사항을 분석하여 프로세스를 설계하는 컨설턴트가 될 것인가, 아니면 정해진 프로세스를 프로그래밍 언어로 구현하는 개발자가 될 것인가.
두 가지 모두 충분히 매력적인 선택일 수 있다. 하지만 우리나라 SAP 시장의 뿌리 박힌 관행 속에서는 두 선택의 상하 관계가 정해져 있다. 굳이 비유하자면, 컨설턴트는 항상 '형'이고 개발자는 '동생'같은 느낌이다. 심한 경우에는 컨설턴트는 '건물주'고 개발자가 '세입자'처럼 처럼 느껴지는 주종관계가 도드라지는 프로젝트도 있었다.
이러한 상하관계가 현재까지 지속되고 있는 결정적인 두 가지 이유가 있다.
- 첫째는, 프로젝트 투입 단가 차이이다. 컨설턴트의 프로젝트 투입 단가는 개발자 단가보다 최소 1.5배에서 2배 이상 높다. 우리나라는 다른 선직국에 비해 프로그램 개발 직군의 월급이 매우 적을 뿐만 아니라 '3D 업종'으로 불릴 만큼 사회적 인식도 좋지 않다. 일반적으로 사회에서 임금의 차이는 곧 직급의 차이, 계급의 차이로 인식된다. 이러한 사회적 인식과 실제 단가 차이가 컨설턴트와 개발자를 자연스럽게 주종관계로 이끌게 된 것이다.
- 둘째는, 컨설턴트 스스로 느끼는 권위의식이다. 컨설턴트들은 컨설턴트와 개발자에 대한 주종관계 같은 사회적 인식이 지속되기를 누구보다 바라는 사람들이다. 컨설턴트는 현재의 관계 구도를 유지하기 위해 의도적으로 개발자를 하대하거나 본인들은 일을 시키는 사람이라는 인식을 갖도록 명령하는 식의 어조로 말을 하는 경향이 있다. 친분이 있는 컨설턴트들이 작정하고 특정 개발자를 험담하고 악담을 유포해 SAP 시장에서 매몰시키려는 시도를 직접 목격한 적이 있다.
요약하자면, 현재 컨설턴트와 개발자가 상하관계 처럼 느껴지는 이유는 프로그램 개발 직군에 대한 한국 사회의 저렴한 인식과 이러한 현상을 유지하려는 컨설턴트들의 권력 카르텔이 만들어낸 현상인 것이다.
사회적 인식의 변화
'개발자'라는 단어를 보면 어떤 이미지가 연상 되는가. 몇 날 며칠 잠도 못 자고 코딩하는 사람이나, 옆에서 시키는 대로 기계적으로 키보드 두드리는 사람이 떠오른다면 이미 당신은 권력 카르텔에 물들어 버린 걸지도 모른다.
이러한 이유 때문에, 개발 직군에 있는 사람들은 본인이 'OO개발자'라고 불리는 것에 대해 상당한 거부감을 느낀다. 최근 몇 군데 IT컨설팅 회사에서는 '개발자' 대신 '개발컨설턴트' 혹은 '개발위원' 등의 변형된 형태의 호칭을 사용하고 있다.
SAP 시장에도 서서히 변화가 생기기 시작했다. 신분상승을 갈망하던 많은 개발자들이 컨설턴트로 전향하여 활발하게 프로젝트를 수행하고 있다. 앞서 언급했듯이 컨설턴트가 되기 위해 필요한 역량은 개인의 성향이나 타고난 기질, 노력으로 충분히 확보가 가능하기 때문이다.
'22년도에 필자가 진행했던 SAP 프로젝트에 투입된 컨설턴트 대부분이 개발자에서 컨설턴트로 전향한 분들이었다. 이분들은 소스코드 분석이 가능해서 비즈니스 요건을 프로그램으로 구현하기 위한 개발 스펙이 디테일하고 정확하다. 심지어 컨설턴트 중 몇 분은 직접 개발을 하기도 했다.
비즈니스 경험과 모듈 지식은 풍부하지만 소스코드 분석은 하지 못했던 이른바 '1세대 컨설턴트'의 시대가 빠르게 저물고 있다. 빅데이터, AI, 메타버스 등 신기술의 등장과 발전은 '개발자'라는 단어의 인식도 바꾸고 있다. 창의적인 생각과 아이디어를 제품으로 기획하고 창조해 낼 수 있는 최고 전문가가 바로 '개발자'다.
댓글