200804212256

푸념

주변 친구들한테 유학 얘기를 하면 왜 좋은 회사 관두고 고생하냐고 얘기들을 많이 한다. 좋은 회사인 건 맞는데 한 가지 마음에 안드는 부분이 있다. 기술 분야, 즉 엔지니어로서 성장할 기회가 전혀 없는 점이다. 회사 자체가 기술 분야에 대해서 그다지 신경을 안쓰는 분위기라 어쩔 수 없긴 하지만…

오늘도 사업 부서와 서비스 개발 관련해서 회의를 하다가 좀 열받은 일이 있었다. 우리 회사는 모든 개발을 아웃소싱하기 때문에 개발팀의 역할이 많이 모호하다. 직접 개발을 하는 것도 아니고, 그렇다고 기획을 할 수 있는 위치도 아니고… 기술을 좀 아는 클라이언트 정도? 아무튼 꽤 어정쩡한 모양새다. 문제는 이런 위치 때문에 하는 일 역시 별로 정체성을 찾지 못한다는 것이다. 서비스 개발을 하면 보통 사업 부서와 개발 업체를 동시에 끼고 하다보니 양쪽의 역할을 얼마씩 다 수행하면서도 주도권을 갖기 어렵다.

개발팀으로서의 역할을 보자면, 전체적인 네트웍과 시스템에 대해서 피상적으로는 알기 때문에 개략적인 구상은 할 수 있지만, 실제 구현에 대해서는 업체에 일임할 수밖에 없으며, 개발 경험을 쌓는 것도 현실적으로 불가능하다. 직함은 Project Manager이지만 일반적으로  Software Engineering에서 정의하는 PM과는 백만 광년…까지는 아니더라도 삼심만 정도 차이는 난다.

그렇다고 클라이언트로서 뭔가 주도권을 갖느냐하면 그것도 아니다. 회사 내부 분위기상 사업 부서의 입김이 절대적으로 개발 부서를 압도한다. 기본적인 서비스 아이디어로부터 세세한 플로우까지 사업 부서의 최종 확인 없이는 개발할 수가 없다. 개발 부서가 단독으로 서비스를 낸다는 것은 상상도 못할 일이고.

오늘 회의에서도 사업 부서와 의견 충돌이 있었다. 아무리 서비스에 대한 아이디어 또는 비즈니스 플랫폼에 대한 구조를 제안해도 사업 부서에서 노하면 그걸로 끝이다. 게다가 우리 입장에서 볼 때 정말 말도 안되고 복잡하기 그지없는 서비스 모델을 갖고 와서 구현해 달라고 요구를 하니 정말 답답하기 짝이 없다.

그러니 결국 서비스 개발 관련해서는 사업 부서의 의견 받아서 개발 업체에 잘 전달하는 게 제일 중요한 사안이 된다. 이런 상황에서 개발 부서의 정체성을 찾는 게 정말 어렵다. 아예 직접 요구 사항 받아서 개발을 시키든가, 아니면 직접 기획을 할 수 있는 권한을 주든가, 둘 다 아니면 개발팀 자체를 없애든가. 개발팀이 없어지면 사업 부서에서 직접 개발 업체를 컨트롤하니 훨씬 효율적일 것이다.

R&D에서 Research는 이미 오래전에 포기한 상태이지만, (2년 전에 신입사원 위주로 R을 해보려는 시도는 했지만 실패했다.) Development에 대해서도 주체성을 못찾고 있는 것 같다. 거기서 헤매는 나도 그렇고, 우리 팀 사람들도 참 딱하다.

• 2008/04/21 22:56 에 작성