시스템 엔지니어로서의 일이 어느 정도 숙달이 되고 나서 그 후에는 ERP 패키지 도입 시 필요한 시스템 사이징 (Sizing)과 진단에 대한 업무를 처리하게 되었습니다. 앞서 이야기 드린 바와 같이 ERP 패키지가 회사의 중요한 업무를 처리하다 보니 시스템의 크기를 산정하는 일 또한 제안단계 및 향후 운영에 있어 매우 중요한 업무인데, 회사가 필요한 용량보다 너무 적은 크기의 시스템을 도입할 경우 초기 도입비용은 적게 들 수 있으나 도입한 지 얼마 되지 않아 시스템을 확장해야 문제가 발생할 수 있고, 반대로 너무 큰 크기의 시스템을 도입할 경우 불필요한 투자비용을 낭비할 수 있기에 적절한 크기의 시스템을 산정하는 작업은 언제나 도전적인 업무라고 생각합니다.

물론, 요즘은 하드웨어 비용이 과거에 비해 상대적으로 많이 저렴해졌기에 그 중요도가 어느 정도 떨어졌다고도 볼 수 있겠지만 일반적으로 서버는 고가의 자원에 속하고 규모가 큰 프로젝트의 경우에는 프로젝트 비용의 많은 부분을 차지하기에 적절한 서버의 크기를 추정해내는 것은 매우 중요한 일이라고 생각합니다. 패키지를 제공하는 업체 중 몇몇 업체들은 몇 가지 요소에 의해서 시스템 크기를 산정할 수 있도록 각종 도구들을 제공하지만, 그러한 도구들을 사용하기 위해서는 생각외로 상당히 구체적이고 상세한 데이터들을 모아서 입력을 해야 하는 경우가 많아 엔지니어의 경험이 매우 중요하다고 생각합니다. 특히, 한국의 경우 제안단계에서 업무의 범위가 결정되지 않은 상태에서 시스템의 크기가 결정되는 경우가 많아 한정적이고 제한된 정보를 가지고 시스템 크기를 결정해야만 하기에 단순히 툴을 돌려서 나온 결과값에 의존해서 장비의 크기를 결정하기는 어렵다고 생각합니다. 따라서, 실제적인 시스템 운영 및 개발에 대한 경험과 감을 가지고 있는 것이 매우 중요하며 이러한 과정을 거쳐야만 시스템의 용량산정 등의 업무를 할 수 있다고 생각합니다.

해당 분야에 있다보면 운영과 개발 측면에서 정말 뛰어난 분들이 보게 되는데, 이 분들이 궁극적으로 가게되는 분야가 제 생각에는 바로 튜닝(Tuning) 분야가 아닐까라는 생각을 해봅니다. 물론, 운영에 대한 노하우가 없이 개발에 대한 노하우만 가지고 튜닝 분야로 갈 수도 있지만 그럴 경우 개발 분야 특히나 SQL(Structured Query Language)에 대한 튜닝만 가능해지기에 일반적이지는 않을 수 있지만 제 생각에는 튜닝을 제대로 하기 위해서는 운영에 대한 노하우가 반드시 있어야 한다고 봅니다. 따라서, 튜닝을 할 정도의 실력을 갖추는 매우 어려운 일이라고 생각되며, 최소 몇 년 이상 꾸준히 공부하고 실전적인 경험을 쌓아야 하는 분야라고 볼 수 있습니다. 하지만, 일이 어려운 만큼 높은 실력을 갖추게 되면 그에 상응하는 상당한 보상이 주어지는 분야기도 한데, 보통은 일반적인 개발자 연봉의 2~3배 정도를 받는다고 할 수 있을 것 같습니다.

덕분에 고객에게 튜닝에 대한 단가를 높게 책정하고 있는데, 이러한 튜닝을 바라보는 입장에 따라 시스템 튜닝에 대한 비용이 비싸다고 이야기 하시는 경우도 듣게 되는 것 같습니다. 하지만, 튜닝을 통해 새로운 하드웨어 도입비용이외에도 새로운 하드웨어를 구매하기 위한 각종 서류작업들과 복잡한 의사결정 등 부가적인 비용들까지 고려할 경우 저는 그만큼의 가치가 있다고 생각합니다. 물론, 그 만한 대가를 주기 위해서는 튜닝에 대한 결과가 반드시 성공적으로 끝나야하겠지만, 튜닝을 통한 얻을 있는 여러 가지 장점들도 많기에 새로운 하드웨어 도입 결정 이전에 한번쯤 심각하게 고민을 해야하는 것이 튜닝이 아닐까 생각합니다. 

앞서 이야기 한 바와 같이 운영에 대해 어느 정도 경험이 있고 개발을 통해 높은 수입을 생각하시는 분들이 있다면, 가는 과정은 다른 어떤 길보다도 외롭고 힘든 과정이겠지만, 개발자로서 한번쯤은 도전해 볼만한 일이지 않을까라고 생각해 봅니다. 

추신: 튜닝과 관련된 단가에 대해서는 정해진 것이 없으니 상황에 따라 다르겠지만, 보통 2가지 정도의 가격산정이 개념이 존재한다고 볼 수 있을 것 같습니다. 먼저 튜닝을 위해 투입된 시간을 근거로 비용을 산정하는 방법인데, 통상적으로 시간 개념보다는 일 단위 또는 주 단위 개념으로 비용청구가 이루어지며 주 단위 비용청구의 경우 일반적인 개발자 한 달 정도 받는 금액 또는 그 이상을 청구하는 것이 일반적입니다. 또 다른 경우는 시스템 튜닝을 통해 얻어진 결과에 따라 기본료와 성공보수를 받는 것인데, 튜닝을 통해 시스템이 개선될 경우 하드웨어나 소프트웨어에 대한 추가 투자비용이 절약됨으로 이를 근거로 일정비율을 성공보수로 받는 개념입니다. 국내의 경우에는 후자보다는 전자의 경우를 더 많이 택하는 것으로 알고 있는데, 후자의 경우에는 시스템 튜닝에 대한 성공여부가 확실하지 않을 경우 고객이 택할 수 있는 좋은 방안이 아닐까 생각합니다.