SAP사의 ABAP 언어를 다루는 ABAPer는 보통의 개발자가 특정 개발 프레임워크를 활용하는 것보다 더욱 높은 비중으로 SAP가 제공하는 인프라인 BAPI, function module, Composition Environment 등을 써서 비즈니스 로직을 구현해야, 고객사의 SAP 솔루션 투자에 대한 ROI를 높여주게 된다.


 SAP의 주요 개발언어는 ABAP(Advanced Business Application Programming)으로, ABAP을 쓰는 개발자를 ABAPer라 부른다. Javaer나 C#ist 같은 용어가 없는 반면, ABAPer라는 용어가 쓰이는 현상[각주:1]은 SAP 환경이라는 특수성에 기인한 바가 크다. 종속적이라 표현해도 좋을 만큼 ABAP 개발은 SAP가 벌려 놓은 판을 충실히 따르는 게 미덕이다. 정말 버그가 적고 안정적이며 빠른 개발이 이루어진다. 이러기 위해서는 ABAPer나 IT Architect가 SAP 체계의 활용에 능해야 한다.


 더불어 ABAPer는 SAP 체계를 비롯한 일련의 비즈니스 절차에 대해서도 익숙할 필요가 있다. 스펙에 맞춰 개발만 해도 밥벌이는 할 만하지만, 단순 ABAP coder는 ABAPer로서 장수하기 힘들다. 어디나 그렇듯 경험 있는 개발자에게 거는 기대는 프로그래밍에만 있지 않기 때문이다. 컨설턴트가 있다고 해도, 어떤 비즈니스 프로세스를 보다 빨리 안정적으로 구현하거나 구현 가능성 유무를 금방 알거나 대안을 제시하되, SAP에서 기본제공하는 방식 위주로 엮어내기는 경험 많은 ABAPer만 가능한 일이다.


***


 초짜 ABAPer의 진로가 순수 개발의 영역에서 많이 벗어나는 게 눈에 띄는 것도 일반 개발자와의 차이라고 볼 수 있다. ABAP만 아주 잘해봐야 현업 고객 입장에서는 5년차와 7년차의 차이를 구분하기 힘든 만큼, ABAPer의 재량은 비즈니스에 대한 지식에 의해 빛을 보는 사례가 많다. 이러다 보니, 봉급 인상을 따라 ERP 모듈 컨설턴트로 성장하는 일이 잦다. 특정 모듈을 잘 하는 걸로 유명한 ABAPer도 꽤 있긴 한데 컨설팅 취향은 아닌 때가 많은 듯싶다.[각주:2] 이게 아니면 SAP IT Architect의 길이 있지만 한국 기업은 SAP ERP씩이나 하는데도 다소 영세한 구석이 있어서 이 역할을 필요로 하는 기업이 매우 적다.[각주:3]


***


 2015년 현재, 한국 기업이란 곳이 워낙 효율 위주로 돌아가서 정작 효과는 놓치기 십상이라 경력자로서 불안하기는 ABAPer나 일반 개발자나 매한가지이다. 3년차가 넘어가면서도 계속 개발일을 하고 싶다면 영어를 공부하는 게 어떨까 한다. 면식 있는 ABAPer/컨설턴트 부부도 호주로 이민 갔고[각주:4], 아일랜드나 이런 저런 영어권 나라에서 SAP 기술자를 우대한다는 얘기를 들으니 타향살이 하는 것도 괜찮겠다 싶다. 일종의 진입장벽이 있는 SAP 세계와는 달리 일반 개발자는 보다 명확한 증빙이 필요하다고 한다. 오픈 소스 프로젝트에 참여하거나 프로젝트 포트폴리오를 잘 갖추면 되지 않을까 한다.


 그런데 이러니 저러니 해도 한국에서 무려 IT 사업을 하거나 소소하게라도 프로젝트 일을 이어 하는 사람도 많다. 다 인연 닿는 만큼 할 수 있고, 마음 가는 대로 갈 수 있는 것인가 보다.


***

  1. 정작 SAP는 교육과정 소개나 여타의 공식문서에서 ABAPer라는 어휘를 쓰지 않는 편이다. [본문으로]
  2. 현업 고객을 상대하는 건 주로 컨설턴트로, ABAPer는 그런 번잡한 일은 거의 하지 않는다. 그냥 개발만 줄창 한다. [본문으로]
  3. Project Manager나 BC 기술자가 하면 된다고 생각들 한다. (애초에 SAP Korea에서도 얘기한 적이 없을 듯) [본문으로]
  4. 또 다른 IT 부부는 고기집을 냈고;;; [본문으로]
저작자 표시 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License


Posted by wizmusa

 IT 아웃소싱 조직이 일을 얼마나 하며 잘 하는지 판단하지 못해 Service Level Agreement(SLA, 서비스 수준 협약)을 하지 않는 기업이야말로 SLA가 필요한 조직이니, 이제라도 벤치마킹과 1~3년의 실적분석을 근거로 삼아 SLA로 가야 IT 기반의 점진적 업무혁신을 이룰 것이다.


 대개 일을 많이 시켜야 한다는 강박관념[각주:1] 때문에 업무범위와 분량을 명시한 SLA를 기피하는 기업이 있다. 그런데 보통 이런 기업은 IT를 잘 모르기까지 하여, 아웃소싱 조직의 업무평가를 근태로 하는 패악을 부리곤 한다. 야근에 주말특근까지 하면 일을 적당히 잘 시킨 것으로 착각한다. 전형적인 lose-lose 사례다.[각주:2]


 IT를 잘 아는 기업은 SLA를 선호한다. 업무범위를 명확히 하고 페널티 기준을 잘 지키며[각주:3] 아웃소싱 조직에 자율을 주면 관리요소가 훨씬 적어지기 때문이다. 한 사람이 스무 개가 넘는 업무 어플리케이션을 관리하는 것도 가능할 정도다. 이제 아웃소싱 조직은 물론 사용자(회사, 정보기획부서, 현업 사용자)까지 비효율의 구렁에 빠뜨리는 머리수 계약 같은 구태는 벗어던지는 게 좋지 않을까?[각주:4]


 SLA의 시범운용이 버거운 기업은[각주:5] 벤치마킹만 좀 해도 감 잡기가 쉽다. 컨설팅을 받는 게 제일 확실하다. 그렇게 SLA 기준을 정하고 나서는 IT 아웃소싱 서비스의 입찰을 공시하는 등의 일반적인[각주:6] 구매절차의 수순을 밟으면 그만이다. 낯설음을 극복한 후에는 SLA가 더 쉽고 깔끔하다. 싸우거나 맘 상할 일이 확 줄어서 여러 사람이 행복해진다. SLA에 대한 두려움은 극복할 만한 가치가 크다.


***

  1. 혹은 일을 많이 시키는 것으로 보여야 한다. [본문으로]
  2. 왜 lose-lose인지 이해 못하는 사람들이 좀 있을 것이다. [본문으로]
  3. 기왕이면 보상 기준도. [본문으로]
  4. 물론 CEO의 IT에 대한 이해수준이 관건이다. [본문으로]
  5. 운용 자체보다는 승인 받는 게 어렵겠다. [본문으로]
  6. 무척이나 익숙한. [본문으로]
저작자 표시 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License


Posted by wizmusa
이전버튼 1 2 3 4 5 ... 226 이전버튼

블로그 이미지
SAP BW/BO/BI, MS BI, IT기획 멀티 플레잉의 기록
wizmusa
Yesterday172
Today124
Total398,733

글 보관함

최근에 받은 트랙백

달력

 « |  » 2015.05
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31