설비 제어 소프트웨어 엔지니어의 이해

설비 제어 소프트웨어 엔지니어의 이해

나도 PC를 이용한 장비 제어 소프트웨어를 주업으로 하고 있지만 업계에서 소프트웨어만큼 독특한 직종도 없을 것이다. 타 부서와 잘 어울리지 못하고 그렇다고 지덜끼리 뭉치는 것도 아니고 있는 듯 없는 듯하며 잘하나 싶었는데 대형 사고만 친다.

보통 우리 업계에서는 설비를 만들게 되면 공정 엔지니어의 가이드에 따라 기구 설계에서 설비를 설계하여 부품을 가공하고 조립을 진행한다. 거기에 전장 엔지니어가 의도한 대로 전장 부품에 배치되고 각종 케이블이 연결되어 전기를 투입하게 된다. 전기가 투입된 후 문제가 없다고 판단되면 소프트웨어 엔지니어가 붙어 공정 엔지니어가 의도한 작업 절차(레시피:Recipe)에 따라 장치들이 자동으로 구동하게 만든다.

이후 설비가 출하되어 고객 사이트에 설치되고 테스트를 거쳐 시운전에 들어가면 기구 설계나 전장 엔지니어는 철수하게 되고 소프트웨어 엔지니어와 CS 엔지니어가 설비를 시운전과 양산를 개시하게 된다. 생산 라인의 양산은 24시간 가동된다. 따라서 일과 중에는 항상 설비 옆에 있어야 하고 야간이나 주말에도 문제가 발생하면 즉시 불려 와 원인 파악을 하고 조치하여 양산을 백업을 하게 된다. 이후 설비가 안정화되었다고 판단되면 서서히 빠져 다른 프로젝트로 배치된다.

가장 중요한 문제는 설비에서 예상치 못한 문제가 발생하면 현장에서 대기중인 CS엔지니어가 원인을 판단하겠지만 그렇지 못한 경우 거의 소프트웨어 엔지니어가 원인 파악을 하고 설비 정상 백업을 위해 관련 인원을 섭외하고 조치하고 다시 소프트웨어 엔지니어가 동일 문제가 발생하지 않는지를 확인 후 마무리하게 된다. 이러한 이유로 많은 스트레스를 받는 것은 당연한 일이다.

같은 공정을 진행하는 설비가 고객의 요청에 따라 다양한 layout을 가진다.

회사가 동일한 설비를 계속하여 생산하는 패턴을 가지면 그나마 좋은 환경이다. 조금씩 바뀌는 부품의 구성만 변경하면 흔한 말로 Ctrl-C, Ctrl-V만 하면 제품이 생산되어 나온다. 하지만 원가절감, 혁신, 개선, 고객요청 등으로 출하 시마다 많은 부분이 바뀌어 있으면 그야말로 고난의 연속이다.

또 다른 별난 환경이 있다. 그것은 신입은 거의 뽑지 않고 경력만 찾는 것이다. 많은 회사에서 대리, 과장 정도에 독자 프로젝트 처리 능력이 가능한 정도의 인원을 가장 선호한다. 업계에서 대리, 과장은 금값이다. 상대적인(차, 부장보다) 인건비가 적고 즉시 독자적인 프로젝트가 가능하니 모두 대리, 과장을 선호한다. 또한 이는 연공서열의 문화와 나이가 많으면 다루기 힘들다는 편견 등이 맥을 같이한다.

지금도 아니 언제나 같은 현상이 반복된다. 이런 상황에 누가 신입 사원을 뽑아 교육을 시켜 일을 맡기겠는가? 그냥 과장 하나 뽑아 부려먹고 버리고 말지...

어느 정도 능력이 되는 경력자를 자신이 맡은 설비에 대해서는 책임감을 가지게 된다. 어떠한 상황에서도 맡은 설비는 마무리하고 이후를 생각하지 장비 개발 도중 짐을 싸는일은 흔치 않다. 의도한 것은 아니겠지만 본능적으로 이런 현상을 이용하는 회사도 많다.

설비마다 제어 화면의 일관성이 없다면...

 

회사의 인지도를 이용하여 계속 채용하고 능력 이상의 일을 주면 어쩌 어쩌하여 맡은 프로젝트를 겨우 끝나고 지쳐 퇴사하면 다시 다른 인원을 채용하여 다시 돌리고 한다. 만일 생산 라인에서 같은 회사의 설비 화면이 설비마다 유사성 없이 저마다 다르다면 그런 회사 중 하나일 것이다. 

---

규모가 큰 회사의 경우 팀 구성에 별 문제가 없을 것이다. 단지 겉도는 팀의 특성상 한명 정도 구심점을 확보해 두면 아무 무리없이 굴러갈 것이다. 구심점의 역활은 팀장 보다도 팀장 밑에서 팀원들의 친구가 되어 상사를 같이 뒷담화하고 다독 거리는 역활이다. 문제는 규모가 작은 이제 설비 제작을 시작하는 회사이다.

회사 초기에 기구설계, 전장설계, 제조(CS 겸) 인원으로 시작하는 설비 제조 회사에서 소프트웨어 엔지니어가 필요하여 소프트웨어 인원을 찾게 된다. 하지만 소프트웨어 인원이 급하게 구해지지도 않을뿐더러 면접을 보더라도 혼자 다해야 한다고 하면 지원자는 망설이게 되고 단독 프로젝트가 가능한 인원은 경력이 너무 많아(?) 채용 결정을 못하게 된다.

시간은 흘러 설비가 완성되어 갈 때쯤 외주를 통해 급하게 테스트하여 출하하게 된다. 초기에 발생하는 디버깅이 끝나면 외주는 철수하게 되고 중대한 버그가 아닌 서비스나 기능 개선, 고객 요청 등에 대해서는 유료로 전환될 것이다. 이후에는 당연히 외주를 콜 할 때마다 비용이 지불되는 것은 당연하고 덤으로 눈치까지 봐야 한다.

이렇게 생각해 보면 초기 비용이 발생하더라도 믿을맨(내가 그일을 모르니 믿고 맡길 만한 사람) 하나를 중심으로 팀이 구성될 때까지 유지하게 되면 이후는 자연스럽게 유지가 될 것이다.

어느 부서든 마찬가지겠지만 한 분야를 맡기고 일을 부리는데 한 명으로 해보겠다는 생각은 너무 과한 욕심이다. 이 욕심은 결국 화를 부르게 된다. 일을 잘하면 항상 스카우트 대상이 된다는 것을 알아야 한다. 리스크(Risk) 관리가 필요하다.

일단 팀(2인이상)이 구성되면 한 명의 손실은 커버가 되고 바로 충원해 주면 자연스럽게 유지되고 원하는 쪽으로 흘러가게 된다. 그렇다고 해서 팀으로 모셔와 일을 맡기는 것도 큰 리스트가 된다. 다시 팀으로 나갈 수 있다는 것을 알아야 한다. 

가장 좋은 방법은 내가 마음에드는 인원을 내손으로 스카우트하는 것인데 그 또한 쉽지 않을 것이다. 업무가 다른 분야의 능력을 판단하기도 쉽지 않고 인원을 빼 간다는 악덕 기업 소리도 들어야 한다.

---

효율적인 소프트웨어 팀을 구성하기위해 가장 현명한 방법을 추천한다면 경력이 있는 믿을맨을 중심으로 팀을 구성하고 거기에 필요한 추가 인원을 보충하는 것이다. 신입을 뽑아 붙이든 경력을 붙이든 시간차를 두고 뽑아 자연스러운 팀 구성이 되게 하는 것이다. 

경력자에 대한 초기 인건비가 걱정된다면 위에 발생할 수 있는 현상을 보고 속 타는 것을 생각하면 그리 큰 비용이 아닐 것이다. 항상 사람이 가장 어려운 일이다. 

초기 소프트웨어 인원을 구성하는 또 다른 방법으로 다음과 같은 방법을 추천한다. 
신규 프로젝트를 시작하는 과정에서 외부 인력(프리렌서나 외주 개발사 인원)의 계약기간을 늘리고 해당 인원으로 하여금 회사에 상근 시키고 이후 새로 충원된 인원을 (신입 혹은 경력) 프로젝트에 참여시키고 해당 인원의 교육 까지를 책임지게 하는 것이다. 이러한 경우에는 프리랜서를 활용하는 편이 나을 것이다.