업무를 하다 보면, 여러 벤더의 엔지니어들이 한자리에 모여 고객의 요구사항을 위해 코웍을 할 때가 많다.
그런데, 일을 하다 보면 꼭 한번씩 엔지니어들의 업무 영역이 겹치는(?) 부분이 발생한다.
써 놓고 보니, 겹친다는 단어가 적절치 않는 것 같은데, 이를테면 이러한 것이다.
고객은 OS위에 DB를 설치하고, APP을 통해 접근/서비스를 하고자 한다.
OS엔지니어가 와서 OS를 설치하고, DB엔지니어가 와서 DB를 설치하다가, OS엔지니어에게 커널 파라미터 수정을 요구한다.
OS엔지니어는 말한다. "DB에서 사용하실 부분이니까 직접 수정하세요."
DB 엔지니어가 반문한다. "그래도 설정부분이 OS에서 해야 하는 부분이니 좀 부탁드립니다." 하고.
어떤 OS엔지니어는 DB가 올라갈 것이라 하면, 협의 후에 알아서 커널 파라미터를 수정한다.
어떤 DB엔지니어는 OS엔지니어에게 직접하겠다 하고, 알아서 커널 파라미터를 수정한다.
그런데 이처럼 서로 당신네 영역이니, 당신이 하시오 하는 자세로 나오게 되면 참 곤란하다.
그런데 이 부분이 참 재미있다. 소속된 회사에서 오지랖 넓게 해주지 않아도 될 부분을 굳이 하려고 하지 말라고 배운다.
어쩔수 없이 해야하는 경우를 제외하고는, 해당 부분은 우리의 영역이 아니라고 밀어내라고 배운다.
초보 엔지니어들이, 고참 엔지니어들이 그렇게 하는 것을 보고 배우고, 그렇게 하면서 경력을 쌓아가고,
각 벤더별로 그러한 현상이 동일하게 일어나다 보니, 필드에서는 가끔 심한 충돌이 일어나기도 한다.
오래동안 사용하던 운영 서버에 스토리지를 추가적으로 접속한다.
서버 벤더에서는, 스토리지벤더에서 직접 접속하라고 한다. 그건 우리 업무 롤이 아니라고 한다.
스토리지 벤더에서는, 그래도 서버벤더에서 지원을 해 주셔야 하는게 아니냐고 반문한다.
여러 벤더의 장비들이 뒤얽혀 하나의 큰 시스템을 구성하는데에 있어,
업무 롤이라는게 과연 있는 것이 맞는 것일까? 없는 것이 맞는 것일까?
분명 존재하는 것이 맞는 것이야 하겠지만, 경계를 쉽게 구분지을 수 없을 만큼 모호한 경우가 대다수라,
이러한 경우에는 필드에 있는 엔지니어 마음대로 결정하게 되는 경우가 많다.
그리고 더욱 큰 문제는, 누구 하나 이런 문제를 정리하려고 들지 않는다는 데 있다.
문제의 가장 큰 부분은, 장애가 발생했을 때이다.
알기 어려운 문제가 발생했을 경우, OS측에서 조사를 하니, OS는 문제가 없다. DB에서 과도하게 메모리를 소비하여, 시스템이 패닉하였습니다. 라고 하면, DB쪽에서는 그게 아니라고 한다. 고객의 서비스와 연관되어 있으므로, 서로 책임회피를 하려고 한다.
결국 피해는 고객이 고스란히 받게된다. 문제를 찾아야, 반복을 막을 수 있다.
현재의 책임이 문제가 아니라, 원인분석이 가장 중요한 문제이다.
인정할 것은 인정하고, 해 줘야 할 것들은 위험을 감수하고서라도 책임져야 할 것이다.
그렇게 책임 회피 하는 자신들도, 온라인에서 물건을 구매 해 놓고, 배송이 늦다거나 제품에 결함이 있거나 하면, 판매자에게 불만을 토하고, 교환이나 환불 수리를 요구할 자신 또한 그때에 가서는 고객일 테니까.