[SI이야기] SI업계에서 SM 운영자가 하는 일

지난번 포스팅에 이어서 오늘은 SM 운영자가 하는 일에 대해서 이야기해보려고 한다.

<지난 포스팅>

2020/05/12 - [슈르의 오피스라이프/SI 이야기] - [SI이야기] SI업계에서 SI 개발자가 하는 일

---

SM이라고 부르는 사람들은 한글로는 운영자라고 한다. SM은 system manager의 약자다. 이들은 단어 뜻 그대로 시스템을 운영/관리하는 사람들이다. 그렇기 때문에 다 만들면 전달하고 손을 떼는 SI 개발자와는 달리, 그 시스템을 계속 관리해주고 개선 작업을 해주는 사람들이라고 보면 된다. 이런 운영 작업이 오래되면 누더기 같은 시스템이 되기도 하는 것이지만... 일단 이들의 일은 정기적인 개선 작업을 위해 움직이는 사람들이고 사고가 나지 않도록 지키고 있는 사람들이라고 보면 된다. 

 

SI와의 차이 및 공통점 중심으로 적어보겠다. (결국 SI와 SM 중 뭐가 낫나요? 의 질문에 대한 답을 찾아야 하니까...)

 

1. (특징) SM 업무는 시스템에 따라 다른 곳에서 이루어진다.

업무가 고객사에서 주로 이루어지는 SI와 달리 SM은 상황에 따라 근무지가 다르다. 우선 외부인 경우에 대해서 이야기해보겠다. SI 프로젝트에서 시스템을 하나 구축해놓으면 고객이 그 시스템을 운영할 사람을 구하게 된다. 고객사에 따라서 기존 직원에게 업무를 추가해주는 경우도 있고, 외부에서 새로 채용하는 경우도 있지만, 시스템을 만들었던 회사에서 그 인력을 남겨달라고 요구하기도 한다. (만든 사람만큼 믿음직스러운 사람이 어디 있겠는가!) 고객이 요구한다고 공짜로 제공한다는 오해는 안 하길 바란다. 당연히 운영 또는 유지보수 계약이라는 이름으로 새로 계약을 하고 진행하게 된다. 그리고 SM으로 지정되는 사람은 계약된 기간 동안 주로 고객사에서 일하게 된다.

 

내부에서 일하는 경우도 있다. 만약 고객의 시스템을 만들어주었지만, 관리를 고객사에서 할 필요가 없는 경우라면 본사에서 업무를 수행하게 되기도 한다. 클라우드 기반의 시스템이었다든지, 아니면 회사에서 보유하고 있는 서비스를 이용하는 고객이라면 충분히 소속 회사에서 관리가 가능한 것이다. 대기업은 보통 자회사에 IT회사, SI회사들이 있는 편인데 이들이 이 일을 진행하고 있다고 보면 된다. 삼성은 삼성 SDS, LG는 LG CNS, SK는 SK C&C, 아시아나는 아시아나 IDT, 우리(금융사)는 우리 FIS, 신한은 신한데이터시스템... 이런 식으로 이루어진다. 

 

그래서 고객사에서 운영을 하는 사람들은 그 기간 동안 본인의 PC, 책상 등 근무에 필요한 모든 것들이 그 고객사에서 발급이 된다. 나만의 자리가 있지만, 계약기간까지~라고나 할까...

 

2. (단점) 소속 회사에 대한 애사심이나 소속감을 느끼기가 어렵다.
SI와 동일하다. 외부에서 고객사의 시스템을 운영하다 보니 결국 갑에게 돈 받고 일하는 을이다. 나의 회사도 아니고 남의 회사라고 하기엔 내 일을 주는 상사가 여기에 있고 하는 애매한 상황이 되는 것이다. '이럴 거면 내가 이 회사 직원이 되고 말지'라고 생각하며 그 회사로 이직하는 사람들도 있다. 

 

3. (장점) 일을 하기 위한 일 말고, 내가 해야 하는 일만 할 수 있다.

SI와 마찬가지다. SM은 사내정치에 연루되기 어렵다. 고객이 고객의 정치를 할 뿐이다. 나는 운영 계약에 의해 해야하는 일만 하면 된다. 다만, 운영자들은 SI와 달리 그 기간 동안 완료하면 되는 명확한 개발의 목록이 없다 보니 개발해야 하는 내용에 대한 이해, 개발 기간에 대한 정확한 산출, 그리고 실수 없이 이행하는 능력이 요구된다. 이 운영자들은 SI 개발자들보다는 업무에 대한 지식이 많은 편이고, 개발 능력은 다소 낮은 편이다.(능력자도 있다. 물론물론.! 하지만 SI 개발자 스펙과 비교해서 운영자에게는 높은 수준의 프로그래밍 스킬을 요구하지 않는다.)

 

4. (장점) 내 전문 영역이 조금은 생긴다.

3번의 설명으로 인해 운영자가 개발자로서 프로그래밍 천재다 하는 능력을 갖추긴 어렵지만 전문 분야가 생기긴 한다. 예를 들어 내가 ERP에서 회계를 담당하고 있다고 하면 그 업무에서 요구하는 회계지식을 계속 쌓아가기 마련이다. 프로그래밍이라고 해서 프로그래밍 언어만 알아서 되는 게 아니다. 무엇을 만들어야 하는 지도 알아야 하고, 필요에 따라서 맞게 수정도 해야 한다. 회계의 경우 세법이 바뀌거나 기준이 바뀌는 경우 수정이 필요한 만큼 1번 개발하고 끝나는 일이 아니기 때문에 무엇을 어떻게 바꿔야 하는지 알아야 한다. 그리고 당연히 그 개발된 내용이 정확한지에 대해 값 검증도 할 수 있어야 한다. 실제 그 업무를 담당하는 현업(Biz)보다는 알고 있는 지식의 내용이 적을 수도 있지만, IT와 Biz를 모두 아는 사람은 찾기 드문 게 이 업계에서 일해본 경험에서 얻은 깨달음이다.

 

5. (장점) 고객사로의 이직의 길이 열리기도 한다.

운영을 하다가 그 고객사로 이직하는 경우도 생긴다. 하지만 개발하고 떠나기 때문에 잡고 싶은 SI 개발자와 달리 SM 운영자는 계약으로 고객사의 일을 이미 하고 있는 사람이기 때문에 그 간절함이나 니즈가 다소 약하다. 훨씬 적은 금액으로 그 사람과 계약해서 일할 수 있는데 뭐 굳이 우리 회사로 데려와야 하냐.라는 의견이 나올 수가 있는 것이다. 만약 운영 계약이 종료되었고 그때 운영자 떠나는 게 아쉽다면(운영 계약 연장을 하지 못하는 상황) 이직의 오퍼가 올 수는 있다.

 

6. (단점) 기술 측면에서 정체되기 마련이다.

내가 담당하는 업무에 대한 Biz 지식이 늘어가는 만큼, 기술적인 IT 측면에서는 SI 개발자보다는 발전이 다소 느린 편이다. 신기술에 관심이 많은 개발자들은 그래서 운영 업무를 못 견뎌하는 경우도 있다. 실제로 회사에서 SI개발을 하다가 고객사에서 시스템 운영을 2년 한 사람이 있었는데 매해 연말에 운영에서 빼달라고 요구를 했었다. 하지만 고객사에서 그 운영자 교체에 대해서 불허한 나머지 계속 남아있었는데... 결국 퇴사를 불사한 전쟁을 통해서 성공적(?)으로 업무를 옮긴 사람이 있었다.

 

7. (특징) 소속 회사가 아닌 수행 업무가 경력이 된다.

특징일 뿐 장점은 아니다. 그 회사 시스템을 운영했다는 건 눈에 띄는 프로필이 되지 못한다. 그냥 시스템이 살아있도록 유지했다는 거네, 남이 만든 거 관리했다는 거네, 실제 만든 사람은 따로 있다는 거구먼 하는 인상을 주기 마련이다. 그렇기 때문에 그 업무에 대해 메리트를 느끼지 못하는 야망가들이 더러 생긴다. 

 

예외는 내가 운영한 시스템이 많은 사람들이 운영하는 걸 꺼리는 시스템인 경우다. 그 회사의 core 업무 시스템을 관리하면 메리트가 생기는 편이다. 그 이유는 4번의 이유와 같다. 내가 은행의 여신(대출) 시스템을 관리한다고 생각해보자. 남이 먼저 만들어놓았을 수도 있다. 은행의 역사가 워낙 길고 시스템도 거대하기 때문에 어차피 본인이 제일 처음 만든 사람이 될 수는 없다. 하지만 여신의 시스템은 자기만의 숨겨진 로직이 있는 편이다. 은행 직원도 모르는 로직들이 있기 때문에 그걸 아는 운영자인 당신은 IT와 Biz를 모두 아는 사람이 되어 상당히 경쟁우위에 놓이게 되기도 하는 것이다.

 

8. (단점) 평생 개발을 하지 않는다.

SI와 같다. SM으로서 당신의 몸값이 너무 올라가면 고객사에서는 당신이 아닌 더 젊은(저렴한) 인력을 요구하게 된다. 단가가 안 맞기 때문이다. 그런 경우 고객사에서 시스템 운영을 내려놓고 본사로 복귀하게 된다. 운영할 시스템이 없이 홀연히... 아니면 고객사에서 실무자가 아닌 그 운영자들을 관리하는 사람으로 올라가기도 한다. (운영 사이트에도 PM이 있다.)

 

9. (특징) 야근은 적지만 정기 작업이 있다.

개발할 일이 많으면 야근하는 SI 개발자와 달리 SM은 정해진 스케줄에 맞게 일을 한다. 야근은 거의 없다고 보면 된다. 하지만 SM에겐 정기 작업이라는 것이 있다. 매달 하거나 분기마다 하거나 등 정기적으로 하는 일들이 있는데 이때는 그 시스템을 사용하지 않는 시간에 해야 하다 보니 늦은 시간에 이루어진다. 가끔 앱을 설치해서 쓰다 보면 공지사항에 무슨 작업으로 인해 0시부터 새벽 3시까지 사용이 불가능할 예정이라고 나오는 게 있는데 이게 그런 거라고 보면 된다. 정기 작업이 있는 경우 저녁 8시부터 준비 10시에 리허설 자정에 배포 이런 식으로 이루어지기 때문에 무조건 야간작업이다. 그것도 퇴근시간 6시와 또 동떨어진 작업시간이다. 그 빈 시간을 채우는 방법이 누군가의 노하우일 정도로... 정기적으로 이루어지는 일이다. 만약 근무하는 회사가 이 야간작업에 대해 보상이 제대로 되어 있다면 조금 꿀이긴 하지만 보통은 그냥... 일하는 날이다.

 

10. SI 계약 없이 진행하는 개발은 SM이 진행한다.

SI 계약을 별도로 하는 경우 어느 정도 규모가 있는 경우다. 지금 있는 인력으로는 개발을 하기 어려운 경우...라고나 할까. 하지만 운영되는 시스템에서 추가하고 싶은 기능이나 개발이 있다면 SM들끼리 일정을 짜서 SI를 하든 개발이 진행되기도 한다. (SM도 개발을 해야 하는 사람들입니다 ^^) 그런 경우 SI처럼 일정에 맞춰서 일하기 위해서 야근도 하고 주말에도 나오게 된다. 이런 경우가 얼마나 빈번한지는 개인적으로 모르지만, 그런 경우가 있다는 점만 오늘 밝혀두겠다.

 

11. (단점) 상시 대기조다.

정기 작업, 야근 없고 좋아 보이는 SM에게도 치명적인 단점이 있다. 그것은 바로 '장애'다. 어떠한 이유로 시스템에 장애가 발생하면 그 정도에 따라서 차이는 있지만, 치명적인 장애인 경우 당신은 새벽에도 불려 갈 수가 있다. 실제로 은행의 시스템 중 인터넷뱅킹, 모바일뱅킹 같이 24시간 돌아가야 하는 시스템의 운영자들은 엄청나게 높은 긴장감을 유지한 채 일을 한다. 어느 정도 체계가 잡혀있는 곳은 장애가 발생하거나 발생이 예상되는 경우 담당자에게 바로 문자 알람이 가도록 만들어져 있다. 운영자들은 언제 장애가 날지 모른다는 생각을 항상 하고 있으며, 장애가 나면 바로 달려갈 준비를 해야 한다. 때로는 그 종속성(?) 이 힘들어서 SI를 부러워하는 사람들도 있다.(만들 땐 힘들어도 만든 다음에는 줘버리고 나오면 끝이니까.)

 

물론, 담당한 시스템이 장애가 발생해도 다음날 처리하면 되는 시스템이라면 걱정이 없다. ^^

---

오늘은 SM의 특징, 장점, 단점에 대해 알아보았다. SM은 자기 회사 건물에서 일하고, 장애가 나도 신속하게 대응하지 않아도 되는 시스템을 맡았다면 꿀인 보직이다. 하지만 SI와 달리 장기휴가가 어렵기도 하다. 매일 가동되는 시스템이 있다는 건 매일 지켜야 하는 사람이 있다는 뜻이 되기도 하니 말이다. 요즘에는 2인 1조로 시스템을 맡아서 일하기도 하기 때문에 서로 동의를 하면 돌아가면서 긴 휴가를 갈 수 있기도 하지만 일이 사실상 끊긴 게 아닌 SM은 SI와 같은 홀가분함은 사실 느끼기 어렵다.

 

SM은 SI와 비슷해 보이지만 다른 업무고 일하는 사람의 성향도 많이 다른 편이다. 두 업무 중에 고민하는 사람이 있다면 깊은 고민을 한번 해보는 것도 좋을 수 있다. 둘 다 교집합의 업무도 물론 있으니 프로그래밍을 하는 업무를 고려한다면 둘 다 하긴 한다. ^^