늦은 저녁을 먹다.
퇴근을 해서 늦은 저녁을 먹었다. 밥상머리에 앉아서 아내가 차려준 저녁을 먹으면서 왜 늦게 퇴근을 한 것일까? 왜 내가 지금 밥을 먹고 있는지 생각하게 되었다.
오늘 오후, 우리는 장애를 맞이했다. 2시부터 일어났던 장애를 6시에 알게 되었고 롤백을 했고, 피해에 대한 수치적 자료를 수집했고, 이슈가 장애의 원인이 되는 코드에 대해서 리뷰를 했다. 리뷰 후, 장애를 맞이했을 때에 대한 심정은 짜증도 나고, 참담한 심정이었지만(설령 그것이 내 책임이 아니지만, 우리 팀이기에) 다른 한편으로는 한 개인의 문제라기보다는 팀과 개발 프로세스에 문제가 있다는 것을 느끼게 되었다.
그렇게 느끼게 된 이유 중 하나는 장애가 최근 들어서 잦게 되었고, 한 개인에게 주의를 주어도 장애가 발생하는 것을 보게 되었기 때문이다. 그런 현상을 보면서 더는 개인의 코드에 대한 세세한 체크, 주의 이런 것으로는 안 되겠다는 생각을 하게 되었다.
이런 일이 있을 때마다 주의를 주어도 결국 개발자 개인은 인터넷에서 찾아보거나 개인의 경험에 의존적일 수밖엔 없다.(개인의 경험치가 쌓일 때 까지 기다려 주지 못하기에) 때문에 다시 문제가 발생하게 되는 것 같다.
뭔가 프로세스가 있어야 할 것 같았다. 어떤 프로세스가 있어야 할까? 밥알을 곱씹으면서 생각에 잠겼다.
커밋에 대해서
가장 먼저 든 생각은 커밋(commit)에 대한 부분이었다. VCS(우리는 svn을 사용하고 있다.)에 바로 적용하는 부분에 대해서는 뭔가 커밋이전에 체크 할 수 있는 방식이 필요할 것 같다는 생각이 들었다. git 기반의 vcs 시스템을 사용하면 좋지만, 적용예정인 코드에 대한 patch를 만들어서 팀원들에게 리뷰를 요청하는 것도 작은 시도가 될 수 있을 것 같다는 생각이 들었다. 이런 생각에 대해서는 그것을 봐주는 사람은 과연 다른 일을 할 수 있는가에 대한 문제가 연이어 생각하게 된다. 팀의 역할과 구성에 따라 다르겠지만, 우리 팀의 경우에는 각자 하는 일이 있고 영역이 다르기 때문에 다른 사람의 patch를 봐주기가 어려울 수도 있겠다는 생각이 들었다.(실제로 그런 의견이 있었다) 누가 어떻게 어떤 방식으로 봐줄 것인가 하는 문제는 여전히 남아 있다.
테스트는 올바른가?
테스트에 대한 문제로 넘어가 보면, 적용예정의 기능에 대한 테스트케이스를 구성하지만(유닛테스트가 아니다!) 과연 이 테스트케이스에 대해서도 모든 케이스를 커버하고 있는지 확신할 수 있을까? 하는 이슈가 있다. QA(혹은 조직)가 따로 있으면 좋지만, 없는 경우 만든 개발자가 테스트케이스를 만들게 되고 그러면 반드시 헛점이 생긴다. 뭐라고 딱 이야기 할수는 없지만, 팔이 안으로 굽는것 같은 경우가 발생이 된다. 또한, 구성하는 개발자 역시 경험에 의존하기 때문에 그 범위가 한정적일 수밖엔 없다.
이럴 경우에는 어떻게 보완할 수 있을지 생각해 보았다.
비슷한 작업을 해본 시니어 개발자가 테스트를 구성해보는 것은 어떨까. 좀 더 많은 경험치를 가진 개발자가 테스트를 구성하면 UI나 기능적인 부분 뿐만 아니라 비기능적인(보안이나, 정책 관련) 부분까지 커버 할 수 있지 않을까.
테스트 구성에 대한 검증을 하는 게 좋지 않을까. 이 테스트가 올바르고, 대부분의 영역을 커버하고 있는지에 대해서 다른 개발자에게 테스트 검증 요청을 하는 것도 좋지 않을까.
역시 가장 좋은 방법은 QA 전담파트를 만드는 것이 제일 좋은 게 아닐지.
코드에 대해서는 단위/유닛 테스트의 필요성에 대해서 절감하고 있긴 하지만, 그것을 강제하기란 쉽지 않은 것 같다.
툴
전체적인 개발 프로세스에 대한 빌드-테스트-배포를 할 수 있는 툴이 필요한 시점이라는 생각이 강하게! 들었다. 남의 나라, 남의 회사에만 있는것 같은 젠킨스, CI 같은것들 말이다. 다 수작업으로 하다보니 개인이 실수할 여지도 커지고 거기서 오는 심리적 압박감도 존재하는것 같다.
사람이 하는 일이기에 믿을 수 없다기보다는 사람이 하는 일이기에 실수할 수 있다고 생각해야하는게 맞는것 같다. 그리고 보완해 줄 수 있는 툴들을 이용해서 일의 결과물에 대해서 검증을 하고 안정성을 부여해야 할 것 같다. 그래야 오늘 같은 일을 덜 겪지 않을까?
시니어 혹은 관리자들은 이런 문제에 대해서 개인의 부주의와 경험 부족의 문제로 치부해버리곤 하는데 1차적일수도 있지만, 개발조직이 가져야 하는 여러 프로세스나 정책 같은 것들에 대해서 고민해보고 세우도록 노력해야 한다고 생각한다. 세워져 있다면, 현재의 비지니스-개발환경에 맞게 잘 돌아가고 있는지, 문제는 없는지 등등 지속적으로 점검하고 개선해 나가야 한다고 생각한다. 그리고 그것이 그들의 역할이 아닐까.
소회
늦은 저녁을 먹으면서, 밥알을 곱씹으면서 쓰디쓴 패배감을 맛본 느낌이었다. 다신 이런 늦은 저녁을 먹고 싶지 않다는 생각이 들었다. 저녁이 있는 삶, 늦은 저녁이 없는 삶을 만들기 위해서는 일을 하는 데 있어서 좀 더 개발자스럽게 일할 수 있게 환경을 구성해야 하고, 그것을 위해서 고민하고 또 고민해야 하지 않나 하는 생각이 들었다.