SI와 SM 업무 차이점

IT 신입생이거나, SI와 SM 중 어느 한쪽을 경험을 해보지 못한 경력자들은 이 두가지 분야에 대한 차이점에 대해서 많이 궁금할 것이다.

첫 직장을 선택하거나 다른 회사로의 이직을 준비하는 사람들은 이 두 업무의 차이점을 알고 해당 업무를 하는 곳으로 이직한다면, 본인에 성향에 맞는 일을 할 수 있는 곳에 들어갈 확률이 높다.

회사를 선택하고 있을 때 대부분 구인광고에 안내가 되어 있기는 하지만, 기재가 되어있지 않은 경우 면접자리에서 꼭 물어보도록 하자.

 

SI와 SM을 모두 경험해본 사람으로서 두가지의 차이점을 아래와 같이 서술하였으니, 참고하기 바란다.

SI와 SM 업무 방식은 검색하면 많이 나오므로, 각각의 장단점과 오해에 대해서 중점적으로 설명하도록 하겠다.

---

SI (System Integration) > 시스템 통합

- 주 업무 : 신규개발

- 시스템을 새로 구축하는 업무, 고도화 포함

- 분석/설계부터 테스트 이관까지 프로젝트 개발 수명주기 전반에 걸쳐 시스템을 새로 만드는 업무

- 대부분 여러 하청업체 및 파견업체, 프리렌서가 해당 시스템을 위해 모여서 대규모로 개발하는 장기간의 일회성 업무

 

장점

요구사항 분석부터 진행하므로, 제품 수명주기 전체를 경험할 수 있다.

> 전체 수명주기 경험을 통해 IT프로젝트에 대한 통찰력을 키울 수 있으며, 다른 SI 프로젝트 투입시 보다 수월하게 업무를 수행할 수 있다.

 

갈등의 해결과정을 경험할 수 있다.

> 이해관계자들 간의 협업 사이에서 일어나는 갈등이 SM보다 상대적으로 많이 일어나므로, 이에 대한 해결과정을 보거나 몸소 체험할 수 있다.

 

일자리가 많다.

> 신규 구축 프로젝트에 대한 구인광고가 SM보다 많다.

 

단점

한 회사에서만 계속 있을 경우, 같은 기술을 반복해서 쓸 확률이 높다.

 > 이미 만들어놓은 프레임워크를 가져다 쓰는 경우가 대다수이다.

 

어느 회사든 경험이 많은 주력 분야가 있으므로 수주해온 프로젝트들의 업무 분야들이 유사할 확률이 높다.

 > 예시로 쇼핑몰 SI를 많이한 업체는 쇼핑몰을 많이 할것이고, 금융쪽 SI을 많이한 업체는 금융쪽을 많이 수주할 것이다. 이는 동일한 프로세스를 반복할 가능성이 많다는 뜻이다.

 

시스템 분석/설계가 잘못되었다면... 야근 확정이다.

 > 설계 단계에서 잘못되었거나, 임원이 큰 틀에 대하여 수정을 원한다면, 프로젝트 기간은 이미 정해져 있으므로, 많은 시간을 들여서 다시 재작성 해야 한다.

> 개발단계에서도 기능개발 후 화면/테스트 시연시 큰 틀에서의 변경을 고객사에서 요청한다면, 소스코드를 이미 정해진 일정 안에서 대부분 다시 짜야 한다.

> 즉, 정해진 기간 내에 완료되지 않으면 집에 갈 수 없다.

---

SM (System Management) > 시스템 운영

- 주 업무 : 에러수정, 기능개선 및 추가, 안정화 작업, 경우에 따른 신규개발
- 해당 시스템이 문제없이 작동할 수 있도록 유지보수하는 업무

 

장점

깊은 도메인 지식 습득 가능

> 운영을 하다보면 해당 시스템 모든 부분에 소스를 분석하게 되므로, 자연스럽게 해당 업무에 대한 흐름 및 지식을 깊게 쌓을 수 있다.

 

주도적 문제해결 능력 향상

> 내가 담당하고 있는 시스템의 경우, 해당 시스템의 내부 구조를 가장 잘 알고 있는 사람은 나이므로 그동안 쌓아온 지식을 바탕으로 일정조율, 이슈사항 협의 등의 문제 해결을 내가 주도적으로 끌고 갈 수 있다.

 

여러가지 기술 및 코딩노하우 습득 가능

> 다수의 시스템을 운영하게 되면 시스템별로 사용하는 기술이 모두 틀리므로, 여러가지의 스킬을 경험할 수 있다.

> SM으로 넘어오기 전, SI개발 시점에 작업했던 타 개발자의 소스코드를 볼 수 있으므로, 내가 몰랐던 노하우도 습득이 가능하다.

 

단점

매너리즘에 빠질 수 있다.

> SI의 경우 프로젝트별로 각각 다른 환경이나, SM의 경우 어느정도의 특이점이 오면 하던일의 반복이 되므로 매너리즘에 빠질 수가 있다.

 

욕받이가 될 수 있다.

> 간혹 말이 통하지 않는 고객사 담당자를 만날때가 있다. SM은 이미 실제 사용자가 있는 상태이므로, 시스템에 대한 불만이 무조건 있기 마련이다. 미팅을 하거나 소통을 할때 고객사 담당자를 잘못 만난 경우, 해당 시스템에 대하여 불만을 격하게 토로하며 많은 요구사항을 요청하는 경우가 간혹 있다. 그러나 이는 어쩔 수 없다. 해당 시스템에 담당자는 나이기 때문에 내가 책임을 져야 한다. 다른사람이 구축한 시스템을 받았을 뿐인데도 말이다.

 

개발 트렌드에 덜 민감하다.

> SI는 신규 구축이다보니, 현시점 트렌드에 맞는 개발 환경 및 언어로 구축하는 경우가 많이 있다. 그러나 SM의 경우 이미 구축된 시스템을 유지보수하는 업무이다보니, 10년 이상 된 시스템을 운영할 수도 있다.

---

많은 사람들의 오해

 

SM 개발자는 SI 개발자보다 개발실력이 떨어진다.

> 오히려 반대로 생각해보자. SI의 경우 같은방식으로 여러개의 페이지를 찍어낸다. 특히 시간이 촉박하면 클린 코드를 고려하지 않고 기능/결과에만 집중해서 만드는 경우도 많이 있다. 또한 다른 SI프로젝트를 나갔을때도 같은 프레임워크를 사용한다면 더더욱 그렇다. 그래서 다양한 경험을 위해 다른 회사로의 이직을 하는 사람들도 적지 않다.

그러나 SM의 경우 하나의 고객사가 아닌 다수의 고객사를 담당하는 경우, 각각의 시스템에 따라 여러가지 스킬 및 환경을 경험할 수 있다. 개발 트렌드에 덜 민감하긴 하지만, SI프로젝트로 진행된 시스템을 바로 수주해서 받아오는 경우도 많이 있기 때문에 최신 기술에 대한 공부도 SI못지 않게 습득이 가능하다.

그러나, 이 경우 내가 몸담고 있는 회사 사정에 따라 틀려질 수 있다. SI의 경우 새로 투입될때마다 신기술을 적용하는 회사가 있을수도 있고, SM을 하고 있지만 몇년째 새로운 시스템이 들어오지 않는 경우도 있을 것이다.

 

SI가 SM보다 배울점이 많다.

> 내 생각에는 오히려 SI가 SM보다 역할이 제한적이다. SI는 주로 하는 업무가 정해져 있다 개발자, 인프라담당자, 퍼블리셔 등 하나의 시스템을 위해 여러 분야의 담당 인원들이 모여서 진행을 하게 된다.

SM의 경우에도 담당자가 나뉘어져 있으나, 대부분은 퍼블리싱의 경우 개발자가 직접 분석해서 수정해야 하는 경우가 많다. 화면단을 구성/개발하는 퍼블리셔를 운영계약하는 경우는 거의 없기 때문이다.

다른 예로, 서버쪽 문제가 생긴 경우 인프라 담당자는 따로 있긴 하지만 최초에는 내가 먼저 해결할 수 있는 부분인지 확인하기 위해 서버에 들어가 분석을 하게 된다. 최초 요청은 나에게 들어오기 때문이다.

 

의사소통 능력에 대해서도 설명하자면, SI의 경우 PM또는 PL에게 일을 받고 해당 일을 완료만 하면 되지만, SM의 경우에는 내가 주 담당자이므로 내 자신이 PM 또는 PL역할을 해야하는 상황이 많다.

그러나, 이 역시도 현재 처해진 환경에 따라 틀릴 수 있다. SM계약시 모든 영역을 칼같이 분리해 놓는다던지, SI 프로젝트 진행 도중 다른 인원이 퇴사하게 되어 내가 해당 업무도 같이 처리를 해야 되는 경우가 생길 수도 있다.

 

SI가 SM보다 경력발전에 훨씬 도움이 된다.

- 이 경력발전도 어떠한 부분에 대한 경력발전인지 명확하지가 않다. 커뮤니케이션 능력? 개발 스킬? 이력서 스펙?

- 확실한것은 SI를 하는 업체는 해당 분야에서 SI 경력이 많은 사람을 찾고, SM을 하는 업체는 해당 분야에서 SM경력이 많은 사람을 더 좋게 보는것이 당연하다. 그러나 이 역시 구인하는 업체가 원하는 경력이 경력 기술서에 기술되어 있어야 한다는 것이다.

예를들어, 고객관리 시스템 SI 프로젝트가 있다. 면접을 두명 보고 있는데 한명은 SI경력자고 한명은 SM 경력자다. SI경력자는 주문시스템 개발만 5년 했고, SM경력자는 고객관리 시스템만 5년을 운영했다. 대부분 SM을 했던 사람을 더 선호할 것이다.

결국, SI를 5년 했는데 같은 프레임워크로 비슷한 게시판만 만들었다면, 이는 경력 발전에 아무런 도움이 되지 않는다. 반대로, SM을 5년 했는데 하나의 시스템만 계속 운영했다면, 이 역시 이직하는데 많은 도움이 되지 않는다.

- 중요한건 내가 가지고 있는 스킬이 무엇인지, 그리고 어떠한 일을 했는지에 대한 경력이다. 이를 잘 어필할수만 있다면 SI/SM 모두 본인이 원하는 곳에 취직할 수 있을 것이다.

 

SI는 SM보다 야근이 많다.

- 꼭 그렇지도 않다. SM의 경우 다른 인원이 퇴사를 하였을 때 그 인원이 담당했던 시스템이 나에게 배정이 됨과 동시에 수정사항도 많은 시스템일 때 요청사항 갯수 및 개발 강도에 따라 야근을 계속 할 수도 있다.

- SI의 경우에도 초기 설계가 잘 잡혀있고, 초기 계약시 기간을 길게 잡았으면 야근을 하지 않을 수도 있다.

---

위와같이 SI/SM 각각의 장단점은 여러가지 환경에 따라 틀려지기 마련이다.

즉, 어떤 분야가 더 좋은지 나쁜지는 명확하게 판단이 불가능하기 때문에 SI와 SM에 대한 색안경을 벗어버린 후 나의 스킬을 업그레이드 시켜서 내가 들어갈 수 있는 회사의 폭을 넓혀나가는것이 우선인듯 하다. 그 이후에 입사면접에서 내가 원하는 세부적인 업무 환경을 파악하기 위해 궁금한 내용을 물어보는 방향으로 생각하는것이 좋지 않을까 한다.

 

워라벨이 지켜지는 회사를 다닌다면 저녁시간에 자격증을 준비하거나 업무에 도움되는 공부를 해보자. 남들보다 더 좋은 위치에 있을 것이다.

야근을 많이 하는 회사에 다닌다면, 부담스럽지 않은 범위 내에서 다양한 업무에 자원하면서 여러가지 경험을 쌓을 수 있도록 해보자.

 

내 실력 향상은 업무방식이 아닌 내 마음가짐에 달렸으며, 내 자신이 만들어가는 것이다.