Regression test failure.

오늘 드디어 커밋을 하고 말거라는 각오를 하고 출근했다. 코드 리뷰 시작한 다음날  ship! 메시지를 받았으나 코드 커밋 직전에 Regression test fail을 보고 나서 애매한 클래스 구조를 다시 설계하고 좀더 세밀한 테스트를 하게 되었다. 이 와중에 다른 사람들이 만들어 놓은 코드들에 대해서 상당히 많은 부분을 이해하게 되는 계기가 된듯 하다.

코드 커밋 전에 반드시 확인해야 될 부분은 내가 코드 수정하거나 기능 추가한 부분이 다른 언어 그러니까 한글 이외의 20개가 넘는 언어셋에 대한 퍼포먼스 테스트를 전혀 흐트러 뜨리지 않아야 된다는 것을 확인해야 된다. 이를 위한 테스트가 Regression테스트이다. C++로 개발하는 바, 예전에 C코드도 점점 C++ 클래스 구조로 리펙토링을 해나가는 찰나이고 어느 한 부분이라도 상속관계라든가 virtual 함수에 대한 잘못된 오용들이 만들어 내는 결과는 참담하기 그지 없다. 이런 클래스 구조는 사실 깊게 들여다 보지 않고 구조에 대해서 충분한 이해를 하지 않고 코딩하면 바로 Regression 테스트 실패 메시지를 경험하게 된다. 차라리 명확한 코드를 뽑길 원한다면 클래스를 쓰지 않는게 나을지도 모르겠다는 생각을 수십번은 한거 같다.



코드 수정량이 많을 경우에 Regression 테스트 실패 메시지는 상당히 곤혹스럽기 그지 없다. 왜냐면 데이터를 기반으로 테스트를 수행하는 경우 어느 부분때문에 이런 데이터 결과가 나오는지 결과만 보고 예측하기가 거의 불가능하기 때문이다(내 프로젝트는 Machine Learning 프로젝트이다. 따라서 더 힘들다). 따라서 모든 코드 수정사항에 대해서 디버깅을 해야 한다. 코드 수정 전으로 돌아가서 하나하나 다시 작업하고 중요한 시점마다 테스트를 다시 수행하고 하는 과정을 반복하며 거의 2주라는 시간을 보냈다.  이 2주의 시간은 간만에 C++클래스 구조라든지 디자인 패턴에 대해서 고민하게 만드는 시간이였다. 실제로 몇몇 디자인 패턴을 적용했고 그 덕분에 코드의 재활용성과 간략함은 증대된거같다. 하지만 다른 언어에 대한 충분한 이해가 없는 관계로 추상화가 거의 한글 위주로 되어 버린점도 없지 않다. 그러나 이 부분은 점점 해당 언어 개발자들이 리펙토링 해나갈 것이라 믿고 있다.

여튼 온늘 성공적으로 커밋을 했고 커밋 빌드 및 테스트도 무사히 완료 하게 되었다. 게다가 이전 버전과 퍼포먼스 비교 결과도 메일링으로 기분좋게 쏜 상태다.


항상 코드 작업 후에 느끼는 것은 테스트의 중요성이다. 이 테스트는 플랫폼의 안정성을 유지시켜 주는 핵심 가이드 라인이라고 할 수 있다. 따라서 테스트는 할 수 있는 거면 뭐든지 하게끔 강제하는게 정말 중요하다고 생각한다.

나는 이런 강건한 플랫폼이 생산하는 효율성에 대해서 잘 알고 있다. 플랫폼 자체가 강건하고 버전이 상승할때마다 이전것 이상의 퍼포먼스와 더불어 안정성을 보장한다면 이를 사용하는 서비스 엔지니어들의 리소스 낭비를 획기적으로 절감할 수 있다. 만일 자신의 회사에서 서비스를 운영하는 엔지니어들이 비정상적으로 많고 이의 업무 원인들이 서비스 개선이 아닌 서비스 유지를 위한 문제(예를 들어 서버의 런타임 오류들) 해결들이 대다수라면 반드시 플랫폼이 안정적으로 업그레이드 되는지 확인해봐야 할 것이다. 그리고 플랫폼 개발 과정에 테스트 코드들이 들어가 있는지 확인하고 코드 커밋 이전에 이 부분에 대해서 확실히 패스하는지 확인하는 과정을 거쳐야 할 것이다. 물론 이전에 코드 리뷰도 필수다.

물론 이 모든 과정을 거치기란 상당히 귀찮고 곤혹스러운 과정이 아닐 수 없다. 그리고 엔진 개발자들이 이런걸 지킨다고 해서 그들이 직접 이익을 보는게 아닐 수도 있다. 어떨때는 서비스에 문제가 생길때 다이내믹하게 해결하는 모습이 조직에서는 더 멋지게 보일 수도 있다. 심지어는 외부적으로는 안정적으로 돌아가는 서비스를 만드는 엔진 개발자들의 존재감이 없어 보이기도 한다. 따라서 이런 개발 조직 문화는 팀장 보다는 그 위 CTO레벨에서 추진해 나가는게 맞다고 생각한다. Hudson의 테스트 fail이 적게 나는 팀에게 연말에 경품을 준다든지.. 뭐 그런 재미난 제도도 큰 도움이 될 것이다.

오늘 사실 Regression test failure 뿐만아니라 Hudson에서 돌린 unit test에서 segmentation fault가 발생했다. 개발머신에서는 나지 않던 오류였는데, 역시 다른 리눅스 머신에서 테스트를 돌리니 이런 문제가 부각되기도 하는거 같다.이런 경우 발빠르게 valgrind를 돌려서 5분만에 오류 부분 찾아 고쳐 다시 커밋해서 지금은 잘 돌아간다.  뭐 이정도 코드량에 이정도 문제면 양반이다.

여튼 소프트웨어 개발 여정은 상당히 곤혼스럽고 복잡한 과정임에는 분명하다.  하지만 어찌하겠나… 이런 과정 하나하나가 진정 강건한 소프트웨어 개발을 위해 필요한 과정이니 말이다.

CC BY-NC 4.0 Regression test failure. by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.