System Integration(SI) / System Management(SM) 경험

  현재 본인은 SI관련 업무를 하고 있지만, SI개발이 완료되면 가끔 연장해서 SM 업무도 맡기도 하고, 과거에 몇몇 SM 관련 이슈로 문제점을 해결해 보기도 했다.

 

  중요한건 SI와 SM의 업무 경험 차이인데 이 부분은 정말로 차이가 나뉘는 부분인 것 같다.

SI 는 시스팀 구축 및 개발에 착수하게 되는데 1개월 정도 기능 회의와 시스템, DB설계를 다 고안하게 되면 개발에 착수한다. 물론, 얼마나 시스템이 복잡하느냐에 따라 계획된 설계가 수정되기도 하고 개발 기간이 늘어나긴 하지만 한번 개발이 착수되고 나면 요구되는 기능들을 시간안에 끝내 놓는게 주 목표이다.

 

  SI에서 개발이 완료되고 QA 팀에 의해서 어느정도 테스트가 끝나게 되면 배포 후 바로 계약이 끝나는 경우가 있긴 하지만 우리 팀의 경우는 규모가 어느정도 큰 백앤드의 개발이라 다행이 1회성 개발에 끝나지 않고 SM의 연장선으로 간다.

배포 후에도 지속적으로 클라이언트 비지니스 팀과 회의를 통해 추가적인 성능과 보완이 필요한 파트들을 계속해서 개발해 나간다. 이부분은 확실히 Agile methodology로 가는 방향으로 보여 매 스프린트 마다 새로운 경험을 하게 되지만, 단점은 이미 설계되고 Production에서 돌아가고 있는 코드를 건들이게 된다는 점이다. 조심스럽게 해야되고 이후 발생되는 문제에 대해서는 책임지고 즉각 고쳐야 하기 때문이다. 물론 Integration Testing과 Code Isolation을 기본으로 하면서 추가 기능을 개발하지만, 본인이 개발했던 소스코드가 아니고 심지어 다른 어플리케이션 서비스와 맞물리게 되는 중간 지점이라 신경써야 할게 한두개가 아니다. 심지어 최악의 상황은 다른 어플리케이션 담당 팀들이 버전 업그레이드를 통한 베이스코드 변경을 발표 할 때이다. 때문에 종종 추가 기능들이나 성능 개선 코드들이 의도치 않게 기존 기능과 충돌되거나 작동이 이상하게 되는 부분이 있으면 테스팅 환경에서 발견된다. 그래서 QA팀이 있어서 안심일 따름이다. 이런 경험들로 이렇게 본인은 거의 1년동안 SI와 SM을 한 프로젝트 팀에서 일하고 있다.

 

  SI 와 SM의 경험들을 대략 간략하게 적었는데 궁국적인 차이는 개발에 착수하느냐, 유지보수/성능개선에 있냐에 따라 나뉘는 것 같다. 솔직히 두개다 필요한 경험들인 것 같다. SI만 하게되면 SM에서 벌어지는 배포, 보안점검, 병목현상, 고객 컴플레인을 경험을 못하니 SI 개발을 할 때 조금더 넓은 안목으로 개발을 못 할 수도 있게 될 것 같다. 따라서 만약 SI에서만 일을 해오신 분이라면 SM부분의 경험도 해보셨으면 좋겠다라는 의견을 남겨 놓는다.

 

 

새로운 기능은 버그를 낳는다...