SI / 서비스업의 업무 특성 (장단점은 배제하고 좀...)
아래 어떤분이 질문 주셨는데
이걸 댓글로만 남기고 퉁 하는 건 좀 아닌 것 같더라구요.
SI는 System Integration
시스템 통합 이라는 이름을 갖고 있지만 핵심은 이겁니다.
고객이 회사고, 그 회사가 요구사항을 제시하고,
개발사는 그 고객사와 계약을 하면서 요구사항을 어디까지 받아 프로젝트에 반영할 지 결정을 합니다.
프로젝트가 완성되면, 고객사는 그걸 가지고 일반 사용자에게 서비스를 합니다. 고객사가 서비스하는 겁니다.
개발사가 서비스하는 게 아닙니다.
서비스업은, 대개 고객이 일반 사용자
물론 고객이 회사일 수도 있지만, 그런 경우, 실질 사용자는 그 회사의 직원이 됩니다.
건의사항 게시판 같은 걸 운영하기는 하지만, 그외 누군가의 요구사항을 외부에서 일방적으로 받지는 않습니다.
회사 내에서 기획과 결정이 끝나죠.
서비스 주체는 당연히 자기 회사가 됩니다.
이 두 차이를 생각해보면
어떤 부분에서 두 집단에서 차이가 벌어지는지 알 수 있습니다.
우선 서비스업 직원 분들은, 자사 솔루션이 당연히 있습니다.
업무 지식이라 해봤자 그 솔루션에 대해서만 알면, 나머지는 코딩 실력에서 판가름이 납니다.
(물론 자사 서비스에 대해서는 아주 깊게 이해하게 되겠죠)
SI는 다릅니다.
매 계약 시마다 고객사가 바뀔 수가 있습니다. 그 때마다 고객사 특유의 업무도 파악을 해야 합니다.
그리고
SI도 다같은 SI가 아닙니다. 금융 SI, 교육 SI, 공공기관 SI 등 분야가 다 나뉘어 있습니다.
금융 SI하던 경력있는 개발자들은, 금융 관련 지식을 갖고 있을수밖에 없습니다. 가령 카드사 코드라든지, 거래취소 방식, 전문 통신 등등. 어떻게 보면 코딩 실력보다 업무 지식이 더 중요할 수도 있죠.
그래서 이직할 때도 같은 분야의 SI로 가면 우대받는 것입니다.
그리고 고객사가 갑이니만큼
고객사 입장에서도 생각을 해보자구요.
프로젝트 하나 하려면 비용, 비싸요. 인건비만 생각해봐도, 몇천만원은 엄청 저렴한 수준이라는 걸 알 수 있죠.
뭐 일단 프로젝트, 만들었다 쳐요.
유지보수도 같은 업체에 맡기려니 비쌀 것 같죠?
그래서 유지보수는 다른업체에도 맡기고 싶어요.
입찰받고 경쟁 붙이고 싶어요.
그러려면? 표준 프레임워크로 만들어져 있어야 겠지요?
그래서 SI는 표준 기술 사용이 강제됩니다. 고객사가 요구를 해요.
그럼 다시 돌아와서
왜 시스템 통합 이라는 용어를 쓰냐.
저 업무 지식을 도메인 지식이라는 표현으로도 쓰더라구요.
이게, 여기저기가 겹칩니다.
가령,
요새는 국가 보조금도 일일히 동사무소에서 신청받으면 업무가 마비되잖습니까.
그래서 카드사랑 연계를 합니다. 그래서 특수 카드도 출시를 해요.
이 카드로 결제하면 보조금만큼 차감해서 남은 금액만 청구해줄게.
와 같은 일이 벌어집니다. (실제 경험담)
그래서 여러 분야끼리 합쳐야 하는 경우가 왕왕 생깁니다.
그때 SI업체가 하는 일은? 일단 시작은 해당 분야 개발자를 뽑는 겁니다.
이렇게 SI는, 프로젝트 목표를 이루기 위해서, 여러 분야가 합체하기도 합니다.
그리고 SI 특성 중에 또 다른 이상한 게 하나 더 있는데
금융쪽을 제외하구요
다른 분야쪽은 통신사들이 은근히 많이 연관이 되어있습니다.
통신사들이 대신 영업해주는 데도 꽤 있습니다. 자금도 통신사에게 투자받아서.
우리 휴대폰 요금을 내릴 생각은 하지 않고...
https://yozm.wishket.com/magazine/detail/2407/
광고는 많지만 글이 좋음.
이 글도 삭제될 거 같은데 시험삼아 써봤어요.
한 마디만 더 첨부하자면
SI 업체도 우리 사회에 반드시 필요한 존재들이라는 거에요.
