개발자가 아무렇게나 커밋을 하지 못하게 하는 것
이라고 답할 것이다. 그리고 실제로 이렇게도 말씀 드렸다. 커밋에 대한 기준은 프로젝트마다 회사마다 다르다. 그리고 형상관리나 이슈관리를 쓰게 하는 것조차도 쉽지 않은데, 커밋을 개발자 마음대로 못하게 한다면 개발 못하겠다고 반기를 들 개발자도 무척 많을 것이다. 하지만 다양한 방법으로 소프트웨어 품질을 개선하려고 했는데, 그 노력이 유효하지 않다면, 최후의 수단으로 커밋을 개발 품질을 지키기 위한 마지막 방어선으로 삼는 게 좋다.
커밋이란, 소스를 개발자라는 개인영역에서 회사라는 공공영역으로 공개하는 것이다. 이때부터 생기는 문제는 개인의 문제가 아니라 팀의 문제고 회사의 문제가 된다. 따라서 커밋에 대한 정책이 명확하지 않은 회사는, 개발자에게 개인의 영역과 공공의 영역을 구분하지 않고, 개인에게 소스 코드의 품질을 전적으로 맡기겠다는 뜻이다.
커밋을 관리하지 않으면, 개발자는 대개 자신이 맡은 영역에서 문제가 생기지 않으면 커밋을 한다. 이렇게 아무런 관리도 받지 않고 커밋된 소스는, 다른 개발자가 소스를 업데이트 받아서 컴파일할 때 문제가 생긴다. 컴파일 시 문제가 당장 생기지 않아도, 통합하면서 기능이 잘못 구현되어 새로운 버그가 생길 수도 있다.
커밋할 때 조건을 까다롭게 걸 수도 있다. 조건 커버리지나 MCDC 커버리지 몇 퍼센트 이상 만족이라는 높은 단위테스트 기준과, 각종 품질 메트릭 수준을 만족했는지, 동료 검토를 받았는지 등의 모든 품질 기준을 커밋 때마다 확인받을 것을 회사 정책으로 삼을 수도 있다. 하지만 이건 어느 정도 수준이 되는 회사다. 국내엔 이런 회사가 거의 드물 것이다.
이런 복잡다단한 커밋 조건이 부담스럽다면, 동료 검토 정도를 커밋의 기준으로 삼아도 코드 품질은 확연히 달라진다. 내가 짠 소스를 동료들이 볼 것이라는 생각만으로 발 코딩을 하기란 쉽지 않기 때문이다. 이런 자기 절제의 메커니즘 말고도 검토는 코드 품질을 개선하는 효과를 준다.
소프트웨어는 하드웨어 개발과는 다르다는 말이 있다. 그래서 제조업체의 품질관리처럼 소프트웨어의 품질 관리를 할 수 없다고 한다. 나도 이 말에는 어느정도 동감한다. 하지만 이 말은 어디까지나 품질관리의 방법에 관한 이야기다. 품질관리를 왜 하는지를 생각해 보면, 소프트웨어나 하드웨어의 분야에 관계 없이 품질을 관리해야 한다는 결론을 얻는다.
하지만 회사에서 개발자가 품질을 고민하지 않고 아무렇게나 소스를 커밋할 수 있다면, 회사에서 품질이 제대로 관리되지 않는다는 뜻이다. 그래서 어쩌면 누군가의 회사에서 견공과 우공이 소스를 커밋하고 있을지도 모른다는, 생각이 든다.
글 : 신승환
출처 : http://www.talk-with-hani.com/archives/1492