재작년에 복학하고 알고 지내는 분(선배지만 공개된 글쓰기에선 존댓말하기 곤란하므로 오리대마왕씨라 칭하겠다. 말놓는 것 아님을 강조한다.)의 블로그에 근황 & 프로젝트 중간 점검이란 글이 올라왔는데, 어디나 똑같은 고민을 하는 듯 하여 공감가는 대목이 많았다.
개발자들로 구성된 블로그 스피어에선 더 나은 작업 환경, 소프트웨어 공학의 실용적인 도입을 원하는 목소리가 높지만, 정작 도입하려면 만만치가 않다. 서브버전(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가 얼마나 시어머니같이 느껴질까.
형상관리시스템의 도입이 이렇게 어려운 마당에 단위테스트는 말 다했다. 사실, 개발자 개인의 문제로 치부해버리긴 어려운 문제인데, 무엇보다 소프트웨어가 대부분의 일을 자동으로 처리해주는 형상관리시스템과는 달리 단위테스트는 순수하게 개발자가 직접 해야 하는 일이기 때문이다. 웹이나 책에 나오는 단순한 단위테스트 사례와는 달리 실전에선 매우 복잡한 테스트 코드가 등장할 때가 많은 것도 문제다. 그렇기 때문에 교육과 토론이 주기적으로 이뤄져야 하는데, 이는 팀장급 이상의 관리자들이 의지를 갖고 지원해주어야 성사될 문제라 답답할 때가 있다.
비관적으로 이야기하긴 했지만, 단위테스트를 꾸준히 작성하는 사람이 한명이라도 있으면 단위테스트를 작성하는 사람이 하나둘 늘어나긴 한다. 물론 그 분량이나 수준이 만족스럽겠느냐는 보는 관점에 따라 다르겠으나, 적어도 그들이 작성한 코드에선 버그가 많이 줄어든다. 관리자의 입장에선 단위테스트를 작성하지 않는 사람의 코드만 집중적으로 감시하면 된다.
저도 자주 커밋하는 것이 띄엄띄엄 하는 것보다는 낫다고 생각하는 쪽입니다. 커밋한 거 저장하는 용량이 모자랄 시대도 아니고 말이죠;
그나저나 텍스트큐브도 어떠한 형태로든 테스트를 도입하고 싶긴 한데….그야말로 먼산이네요..orz
여기서 자주 커밋한다는 이야기는 아마 실수로 파일을 몇개 빼먹었다가 그 사실을 깨닫고 다시 커밋하는 경우를 염두에 두고 한 말일거예요. 이런 일이 반복되다 보면 한꺼번에 커밋했을 때처럼 다른 사람이 따라가기 힘든 면이 분명히 있죠. 그래도 커밋 횟수가 적은 팀보단 많은 팀이 낫긴 한데…… 관리하는 사람 입장에선 어느 쪽이든 골이 아플테니 ㅎㅎ
네, 재훈님 말이 맞습니다. commit 하고 보니 어,빠졌네? 하고 올리고, 올려놓고 보니 또 빠뜨려서 어, 빠졌네? 하고 올리고. 그 사이에 서버 측에서는 Class not found 로 compile 조차 안되는 상황에 빠지지요.
commit 주기는 당연히 자주 해 주는 것이 좋습니다. 단! “완결된 하나의 단위를” 올려야지, 완결되지도 않은 걸 올리면 팀 전체가 compile이 안되는 아름다운 시츄에이션이 펼쳐지니까요.
svn best practice 들 찾아보면 하나같이 자주 commit 하라고 합니다. 그러나 이거 말 처럼 쉽지는 않지요. 하나의 작은 단위로 작업이 종결되도록 하기 위해서는 개발자 자신이 작업을 세분화 시키는 노력이 수반되어야 합니다.
이런 문제는 회고 같은 걸 해서 피드백을 자주 주고 받는 수밖에 없는 듯 합니다.
이런건 어떨까요?
버그를 수정하거나 테스트를 위한 코드수정시 trunk에서 branch로 가지를 쳐서 FIX-bug-버그번호 또는 TRY-dll분리 이런 식으로 이름을 붙여서 자주 커밋하고 해결하고 나면 trunk에 커밋하는 방식…
시도는 못해보고 고민중인 내용입니다…
비슷한 방법이 널리 쓰인다더군요. branch에서 새로 커밋한 코드를 먼저 돌려보고 빌드가 성공하면 trunk에 넣는 방식입니다. 저도 생각만 해봤는데, 과연 이만한 시스템을 도입할 정도로 문제가 심각한지 생각해봐야겠죠.
움.. 근데 저도 해보진 않았지만, branch 후에 trunk 로 다시 merge 하는 작업이 꽤나 피곤하다고 하는군요. svn best practice 문서들에서도 “필요할 땐 과감히 써야 하지만, 되도록 branch 가져가는 일은 피해라” 라고 하네요.
branch를 따느냐 마느냐 결정은 버그나 테스트 수정의 중요도 및 크기에 따라 그때 그때 적절히 판단해야 할 것 같습니다. 그러나 일단 branch 따기 시작하면 trunk로 merge 하는 고통은 반드시 뒤따라야 하겠죠. 저같으면 어지간히 큰 건 아니라면 branch 안 딸 것 같아요. 그냥 일단 local에서 충분히 해서 바로 trunk 로 올리도록 할 것 같습니다.
음… 이 경우엔 branch와 trunk란 용어를 써서 약간 혼동이 있는 듯 하네요.
굳이 branch를 하는 방법만 말하는 건 아닙니다. 저장소를 두 개로 나누고 하나를 완충지대로 써도 될 것 같은데요. 완충지대에서 통과된 것만 Release용 trunk에 다시 커밋하는 경우를 생각해볼 수 있겠습니다. 이렇게 하면 병합하느라 고생할 일은 없는데, 서브버전이 이런 기능을 기본 제공하는 게 아니라서 스크립트를 만들려면 고생 좀 해야겠네요. 그래도 처음에만 고생하면 된다는 장점이 있긴 하니까요…..