품질보증 담당의 어려움

재작년에 복학하고 알고 지내는 분(선배지만 공개된 글쓰기에선 존댓말하기 곤란하므로 오리대마왕씨라 칭하겠다. 말놓는 것 아님을 강조한다.)의 블로그에 근황 & 프로젝트 중간 점검이란 글이 올라왔는데, 어디나 똑같은 고민을 하는 듯 하여 공감가는 대목이 많았다.

개발자들로 구성된 블로그 스피어에선 더 나은 작업 환경, 소프트웨어 공학의 실용적인 도입을 원하는 목소리가 높지만, 정작 도입하려면 만만치가 않다. 서브버전(Subversion) 같은 형상관리시스템의 도입만 하더라도 개발자를 옥죄려는 시도로 보고 반발하는 경우가 적지 않다. 지금은 모두 서브버전의 혜택을 보는 듯 하지만 우리 회사 역시 그런 적이 있다고 들었다. 소프트웨어 산업계의 환경이 오랫동안 열악했다 보니 예전에는 믿지 못했을 이런 일까지 벌어지는데 누구를 탓할 수도 없는 노릇이라 답답할 때가 있다. 하기사 생각해보면 반발하는 경우는 차라리 낫다. 아예 관심조차 안 보일 때는 직업 만족도가 상당히 내려가게 된다(일시적일지라도).

아무도 귀 기울이려고 하지 않는군요

오리대마왕씨는 프로젝트에서 품질보증을 담당하는 걸로 아는데 남들은 모르는 고충이 참 많으리라 생각한다. 이제부터 본문을 한대목씩 살펴보며 이야기해보자.

commit 커멘트는 초기 교육때 한번 강조를 했고, 중간에 PL분들을 통해 다시 한번 전달을 하였음에도 불구하고 잘 지키는 사람 따로, 전혀 남기지 않는 사람 따로이다. 음, 아예 pre-commit hooking script를 통해 무조건 commit 커멘트를 남기도록 하는 것이 정답일까.

우선 cuckoo 서버팀(내가 속한 팀)은, 아니 cuckoo 프로젝트 팀 전체가 직위가 없다(몇몇 경우를 제외하면). 그렇다고 해서 팀의 위계체제가 없지는 않아서 팀장, 프로젝트 관리자 역할을 하는 사람이 있다. 다만, 그외의 사람들은 그저 팀원일 뿐이다. 그래서 이같은 문제에 효과적으로 대처하기 힘들다. 태터툴즈 개발팀처럼 Commit 커멘트를 넣지 않으면 커밋 자체가 안되게끔 해보자고 말해본 적은 있지만, 역시 강제력을 발휘해야 하는 부분에선 망설이게 된다. 귀찮은 일, 나를 통제하려는 수작으로 오해받을 여지가 있기 때문인데, 사실 약간의 권위조차 없으면 일을 추진하기 힘들다. 어디나 극구 반대하는 사람은 있기 마련이고 이럴 땐 설득이란 수단이 힘을 발휘 못하기 때문이다.

두번째로 너무 잦은 commit. 대개 2가지 유형이다. 이전 commit 에서 포함시켜야 할 내용을 넣지 않아서 그것을 위해 추가 commit 하는 경우가 있고, 테스트 해 보니 잘 안되서 개정된 내용을 다시 commit 하는 경우이다. 둘 다 충분히 피할 수 있는 문제이다.

오리대마왕씨의 팀에선 이클립스용 SVN 플러그인을 쓰는 모양이라 순수하게 TortoiseSVN을 쓰는 우리팀과는 상황이 다르다. 우리는 파일을 하나하나 직접 추가해줘야 하기 때문에 실수가 안나오기 힘들다. 물론 사람들이 익숙해지고 나선 그 빈도가 줄긴 했지만 근본적인 문제가 해결된 건 아니다.

내 생각엔 너무 자주 커밋하는 편이 너무 커밋을 안 하는 경우보단 훨씬 낫다. 새 기능을 넣느라 저장프로시저를 고치고 웹 페이지를 손봤다면 최소한 두번 커밋해야 한다. 저장프로시저를 고치는 일과 웹 페이지를 고치는 일은 논리적으로 구분되므로 Changeset을 두 개로 나누어야 한다. 물론 각각의 작업은 하나의 목적(새 기능 추가)를 위한 것이므로 하나의 티켓(Trac이란 이슈관리시스템의 개념 중 하나)으로 묶어야한다. 이렇게 Changeset을 나눠야 나중에 작업 기록을 추적할 때 이해하기가 쉽다.

가만 보면 이틀, 사흘에 한번꼴로 커밋하는 사람이 있다. 혼자 일하는 경우라 할지라도 하루 내지 이틀치 작업 분량을 실수로 잃어버릴 여지가 있으므로 그리 바람직하진 않다. 물론 함께 일하는 경우라면 더욱 문제라서 충돌(Conflict)가 나지 않는다 해도 무슨 일을 했는지 다른 사람이 파악하기엔 한번에 읽고 이해할 코드가 너무 많다.

어떠한 강요도 하지 않는 팀이다 보니 이런 규칙이나 실천방법(Practice)은 개인의 의지에 달렸는데, 가만히 살펴보면 절반 정도는 각자의 절제된 방식을 따르고 나머지 절반은 마지못해 커밋하는 기색이 느껴진다.

아, 제발 알아서들 하게

프로젝트 단위의 commit 을 종용하는 것은 그나마 좀 더 쉬운데, unit test 적용은 정말 어려운 문제다. 개발자의 영역을 침범하는 듯한 느낌도 들고, 개발자 입장에서도 QA가 얼마나 시어머니같이 느껴질까.

형상관리시스템의 도입이 이렇게 어려운 마당에 단위테스트는 말 다했다. 사실, 개발자 개인의 문제로 치부해버리긴 어려운 문제인데, 무엇보다 소프트웨어가 대부분의 일을 자동으로 처리해주는 형상관리시스템과는 달리 단위테스트는 순수하게 개발자가 직접 해야 하는 일이기 때문이다. 웹이나 책에 나오는 단순한 단위테스트 사례와는 달리 실전에선 매우 복잡한 테스트 코드가 등장할 때가 많은 것도 문제다. 그렇기 때문에 교육과 토론이 주기적으로 이뤄져야 하는데, 이는 팀장급 이상의 관리자들이 의지를 갖고 지원해주어야 성사될 문제라 답답할 때가 있다.

비관적으로 이야기하긴 했지만, 단위테스트를 꾸준히 작성하는 사람이 한명이라도 있으면 단위테스트를 작성하는 사람이 하나둘 늘어나긴 한다. 물론 그 분량이나 수준이 만족스럽겠느냐는 보는 관점에 따라 다르겠으나, 적어도 그들이 작성한 코드에선 버그가 많이 줄어든다. 관리자의 입장에선 단위테스트를 작성하지 않는 사람의 코드만 집중적으로 감시하면 된다.

Advertisements

최 재훈

블로그, 페이스북, 트위터 고성능 서버 엔진, 데이터베이스, 지속적인 통합 등 다양한 주제에 관심이 많다.
Close Menu