새로운 조직에서 내가 느낀 안타까운 점들

프로젝트가 한 두개씩 마무리되고 다음 일정 사이에 틈이 생겼다. 새로운 제품을 교육해 주실 개발실장님의 출장이 늦어지면서 나는 계속 대기 상태이다. 이 틈을 타서 한 달 조금 넘게 내가 새로운 조직에서 발견한 점을 정리해 두어야겠다.

문서의 산재

프로젝트가 계획되기 시작하면서부터 대부분의 프로젝트가 많은 문서를 배출하기 시작한다. 단순한 내용부터 제품 전체의 기획서까지. 그런데 이 문서들을 한군데 일목요연하게 정리한다는게 만만치가 않다. 내가 지금 일하고 있는 이곳에서도 부지런히 먼가 작성하고 올리고 공유하려고 노력하고 있는 것 같은데.. 막상 필요할 때 꺼내보려면 어디부터 봐야할지 막막해지곤 한다. 어떤 문서는 네트워크 폴더에 프로젝트 이름의 폴더를 만들어서 보관하고 어떤문서는 MS Share Point(우리 회사는 이걸 전사적으로 쓰는 듯하다.)에 올라가 있다. 또 어떤 문서는 메일로 전달받는다. 이런 문서를 잘 계획하고 관리하기 좋은 최적의 방법은 없을까?

형상 관리 부재
우리 제품은 고객사마다 많은 커스터마이징이 가해진다. 이름만 같을 뿐 전혀 다른 기능이 들어가는 경우도 있다는 말도 전해 들었다. 제품이 표준화가 되어 있지 않다는 것도 심각한 문제이지만.. 기능을 추가하고 그만한 보상을 돈으로 제대로만 받는다면야 그것은 문제가 되지 않는다.
다만 각 고객사에 전달된 프로그램과 모듈은 잘 관리되고 있어야 한다. 보통 하나의 프로그램에는 다양한 모듈이 속해있다. 이 모듈들은 대부분은 DLL 형태의 파일 단위로 이루어져 있을 확률이 크다. 이 파일 단위의 모듈들의 변경사항과 릴리즈 사항이 잘 관리되고 있어야만 유지보수도 가능하게 된다. 그나마 1년 전부터는 이력을 남기고 있다니 다행이 아닐 수 없다.

도구 활용의 어려움
제품의 품질을 향상 시키기 위해 테스트 엔지니어는 이슈(버그)를 계속 찾아내고 개발자들은 등록된 이슈를 최대한 수정하려고한다. 하지만 전문 이슈트래킹 도구를 사용하지 않는 우리 조직에서는 그 일이 기민하게 처리되지 않는 듯하다. 먼저 기 등록된 버그를 검색하기가 쉽지가 않다. 테스터의 기억력이 좋으면 언제 누가 올렸던 버그인지 기억해서 재오픈하겠지만 그것이 어려운 사람에게는 많은 항목들을 일일이 재입력하여 등록하는 번거로움이 따르게 된다. 그나마 수정되만 다행이지만 고칠 수 없다는 개발자의 코멘트를 보고나면 맥이 탁 풀려버린다. 에휴.. 두번째로는 보고서의 문제이다. 일일보고, 주간보고, 테스트결과보고... 특히 테스터 리터나 관리자라면 더 많은 보고서와 마주하지 않을 수 없겠다. 매일, 매주하는 이 보고를 좀 더 쉽게 빠르게 할 도구가 가장 간절해 보인다. 그나마 몇 주전부터 통합문서공유를 하기 전에는 일일이 메일로 보고를 받아 한 사람이 취합했으니 얼마나 힘드었을꼬.

사실 앞에 내가 나열한 문제들에 대한 해결책이 없는 것은 아니다. 문서나 지식을 모으기 위해서는 위키 등으로 통합할 수 있다. 모듈이나 버전, 형상관리를 하기 위해서는 서브버전이나 CVS 같은 도구가 도움이 될 것이다. 버그 트래킹이나 자동화를 이용하면 테스팅 업무 자체에도 도구를 도입해 많은 리소스를 절감할 수 있을 것이다.
그러나 이 일을 급하게 진행되기가 어렵다. 새로운 도구를 도입하는 것은 신중할 필요가 있기 때문이다.

1. 기존의 자료는 어떻게 유지할 것인가?

2. 새로운 도구을 사람들이 쉽게 적응할 것인가?

3. 누가 새로운 도구를 교육하고 관리할 것인가?

이런 점들을 생각해 보지 않고 섣불리 들어엎었다가는 더 큰 혼란이 야기될 수도 있다. 사실 지금의 형국으로만 보아도 몇 번의 시도가 있었음에도 정착되지 않은 듯한 흔적이 보인다. 그러니 더욱 신중해질 수 밖에..

아무튼 복잡한 머리 속을 글로 풀어놓으니 조금 마음이 후련해지는 듯 하다. 젊고 의욕에 넘치는 우리 품질관리실 사람들과 이 문제를 신중히 그러나 급하지 않게 잘 풀어나갈 수 있었으면 좋겠다.