개발 관리? 무엇을 위한 관리이고, 왜하는 것인가? (1)

IBM에 와서 경력이 쌓이며 좋은 것 중에 하나가 다양한 고객층의 다양한 이야기를 들을 수 있다는 점이다.
업체들의 면면을 보면 끊임없는 노력을 통해 지속적으로 최선의 환경을 만들어가려고 노력하는 업체가 있는가 하면 어떻게 이러한 환경에서 개발이 이루어지고 있는가? 라고 생각될 정도로 열악함에도 꿋꿋이 유지되고 있는 굳건한(!) 업체까지 다양한 업체들을 보게 된다.

그래도 최근 몇년간 업체들은 나름 많은 투자와 관심을 가지고 이를 개선하기 위해 투자하고 있는 분야가 소스관리, 버그(이슈)관리 분야다. (형상. 변경관리라는 용어를 사용하고 싶기도하지만, 최소한 내가 보는 관점에서는 분명히 구분이 되어 보여 용어는 이렇게 써봤다.)
이러한 시스템을 도입하려(또는 도입한) 업체들을 보게되면 그 도입 이유는 다 다르다 할 수 있겠지만, 몇가지 공통점을 찾아볼 수 있다.

- 개발의 진행을 좀 더 절차적, 표준적으로 만들어보려는 이유 (중구난방식의 개발 방지)
- 변경된 내용에 대한 절저한 관리
- 관리를 통한 통제/관리
- 문제에 대한 빠른 처리 및 현황 파악/관리
- 앞선 내용들을 통한 개발 생산성 증대 및 품질의 향상
... 등등...

그런데, 이러한 이유에서 도입된 버그관리, 소스관리 도구들이 과연 얼마나 제 역할을 하고 있을까? 또 한다고 생각되는가?
이에 대한 대답은 내가 경험한 바로는 누구한테 이러한 질문을 했는가에 따라 그 답변이 확연히 달라 진다는 것이다.
- 관리직에 있는 사람, 운영자, 관리자, 매니저, 기획자, 개발자 ... 모두 다른 답변을 한다는 것이다.
그렇다면, 과연 누구의 눈높이를 맞춰야하는가? 누구의 만족도를 높여야 할 것인가? 물론, 모두의 눈높이를 맞추는 것이 가장 좋은 것이겠지만 그렇지 않다면 어느 집단을 우선순위로 개선해 나가야할 것인가? ... 최고의 결과가 아니라면 최선의 방법이란 것은 무엇일까?

나의 제언은 이러한 상황에서는 그 눈높이는 우선적으로 개발자들이 그 대상이 되어야한다는 것이고, 더욱 중요한 것은 그 대상이 되는 개발자란 것도 사람 자체이어야하는 것이지, 개발업무가 되어서는 안되다는 것이다. 또 한가지 첨언하고 싶은 것은 개발자라는 것은 개발만을 하는 대상만이 아닌 개발에 깊이 있게 참여하는 주요대상의 사람들까지도 포함한다. (PM, 아키텍쳐, 개발자 등..)

개발을 위한 방법론이 생기고, 개발을 위한 도구가 생기고 관리를 위한 관리도구가 생기고.. 하는 과정에서 언제부터인가 사람들은 이러한 것이 누구를 위해서 등장한 것인지를 잊고 있는건 아닌가 하는 생각도든다. 개발을 더욱 잘하기 위한 수단들이 오히려 개발자들을 관리하는 수단/도구로써만 역할을 통해 이들의 족쇄를 채우는 역할만을 하는 경우를 보게 되는 것이다.

그러한 측면에서 최근에 유행처럼 많이 도입하고 있는 버그(이슈)관리 시스템들에서 아쉬운 모습을 찾아보게 된다.
과연 누구를 위해 만들어졌는지 조차 모호한 제품도 많이 등장하고, 좀 괜찮다 싶은 제품은 도입하는 측에서 의도와 다르게 도입하여 사용하고 있는 경우도 허다하고 ... 이래저래 아쉽기는 마찬가지인 상황을 참 많이 보게 된다는 것이다.

개인적으로 가장 아쉽게 생각하는 부분은, 이러한 시스템들의 특징들은 웹에서 주로 내용들을 관리하게끔 되어져 있다는 것이다.(또는 별도의 어플리케이션으로.) 더한 경우는 소스관리시스템(SCM)과 연계하여 그 소스까지도 웹에서 보여주면 변경된 내용을 보여주기도하며 훌륭한 관리가 된다고 이야기까지 한다는 것이다. 물론, 이러한 시스템이 없던 시스템의 시절에 비한다면 분명 이러한 정보는 중요한 것이고 좋아진 환경일 수 있겠지만... 과연 이러한 것이 개발 실무자들에게는 얼마나 도움이 된다고 보는가?

보는 이들에게는 좋아보일지 모르고, 관리하는 사람의 입장에서 관리가 될 것처럼 보일 수는 있을지 모르겠지만,
관리라는 이유에 묻혀 개발자들이 얼마나 많은 시간낭비와 희생을 감수하고 있는지에 대해서는 잘 모르는 경우가 많은 것 같다.
결국, 개발자의 편의성을 무시된 시스템은 개발자들의 사용성을 떨어뜨리게 되고 더 나아가 이 시스템은 사용자체가 흐지부지하게 되는 결정적인 이유를 제시하게 된다. (억지고 강제해서 사용하게 하면 된다?라고 말하고 싶다면 ... 회사에서 가장 아끼는 개발자가 당장 내일이라도 떠날 수 있음을 고려하지 않고 하는 이야기일 것이다.)

개인적으로 RTC라는 제품을 릴리즈 되기전부터 관심을 가지고 된 결정적인 이유 중에 하나는 다음의 문장이 참 마음에 들어서이기도 하다. "People building great software, together" .
이 문장에서 보듯이 좋은 소프트웨어가 탄생되는 것의 중심엔 이를 직접 만드는 사람 있어어야 한다는 것이다.
결국엔, 그 사람이 제대로 개발을 할 수 있도록 방법과 환경을 최적화 해주는 것이 중요하다는 것이다.
(여기에 좀 더 진보해서 이들간의 협업까지도 이어지지만 여기까지 어여지기도 전인 사람 중심의 환경 조차도 제대로 안되고 있는 경우가 많은 것이 현실인듯 싶다.)

지금 소프트웨어 개발을 하고 있고, 더 나은 소프트웨어를 만들고자하는 의욕이 있다면
우선적으로 가장 실무단에서 일하는 사람부터해서 어떠한 환경에서 개발을 하고 있는지를 살펴보았으면 하고,
그러면서 차차 사람들을 넓혀 이들이 어떻게 함께 어울려져 일하고 있고, 할수 있는지를 고민해 보았으면 한다.

무엇보다 관리자의 기준과 눈높이에서 개발팀을 관리하려는 시선과 관점을 버렸으면 한다.
우선은 개발팀 중심의 환경을 고려하고 ... 관리는 그 속에서 쌓여지는 결과 또는 과정의 데이터를 통해, 관리라는 관점보다는 관심의 형태로 함께 어울려져 일할 수 있는 분위기를 만드는 것이 중요할 것이다.