테스트와 벤치마크 툴을 통해 용자 되기

나는 TDD를 제대로 공부해본 적이 없다. 테스트 코드 작성하는 것을 무지 싫어한다. 하지만 테스트 하기는 무척이나 좋아한다. 그 이유는 두려움을 경감시켜 창의력을 발현하는데 도움을 주기 때문이다. 새로운 시도를 해보고 싶으면 dummy 프로젝트를 하나 만들어 단위 테스트를 하고 실 프로젝트에 옮기는 일을 자주 한다.

그런데 클래스가 500~1,000개쯤되는 레거시 클래스들이 중구난방으로 쓰고 있는 어떤 핵심 클래스가 있다고 치자. 그리고 나는 그 클래스를 고치고 싶다. 그냥 구현의 일부분을 간단히 고치는 경우도 있겠지만, 호출하는 녀석들을 파악해서 (thread stack을 검사하여) 각기 다른 처리를 해주고 싶다. 이런 접근은 일반적으로 옳지 않지만,  현실(쓰레기장)에서는 쓰레기처럼 행동해야 할 경우가 많고, 그 선택은 대부분의 경우 좋은 결과를 보여줬다. 그래서 아무튼, 하고 싶어졌다면.

내가 지금보다 더 어렸을 때는 테스트 만드는 수고를 하는 대신 용기를 가지기로 했다. 심사숙고해서 온갖 추측과 고뇌를 해서 코드를 고치고 실서버에 밀어 넣는다. 초당 에러가 100개쯤 떨어진다. 어이쿠! 하고 예전 코드로 바꾼다. 수집한 에러 4~500개를 로컬 개발 장비로 내려 받는다. 오류를 분석한다. 고친다. 반복한다. 가끔 오류 로그 남기기와 절체 코드를 작성하는 것도 귀찮을 때는, 실서버에 들어가서 vi 로 고쳐가며 추이를 살펴보기도 한다.

이런 짓은 범죄 행위에 가까운 것이며, 그것이 법적으로 문제가 있냐 없냐를 떠나서 엄청난 용기를 필요로 한다. 우리는 한살 한살 나이를 먹어감에 따라 지키고 싶은 소중한 것들이 늘어나게 마련이다. 그럴수록 현실에 안주하고 싶어하고, 위험을 감수하고 싶어하지 않는다.  게다가 이러한 접근방법은 모든 단위업무들이 realtime으로 이루어져야 하기 때문에 개발자 성격에 따라 신날지는 몰라도 엄청난 집중력을 필요로하며 다른 업무와 충돌하였을 경우 치명적인 스트레스를 유발하기도 한다.

만약.

무슨 일이 일어나도 내게 피해가 생기지 않는다는 것을 정말로 정말로 인지할 수 있다면, 에러는 더이상 위험한 것이 아니게 되고, 우리는 더욱더 창의적이 될 수 있다. 마음껏 상상을 나래를 펼치며 새로운 방법을 시도해보고 에러가 나면 "오류메시지를 통해 제게 소중한 피드백을 남겨주셔서 감사합니다" 라고 말하고 고치면 그만이다.

테스트는 개발자의 두려움을 줄여주고 창의력을 키우는데 도움을 준다. 그런데 Test Driven은 약간 사상누각이 아닌가 싶다. 핵심가치를 예쁘게 만드는 것에 집중하고, 그게 끝난 뒤 그것이 잘 돌아가는지 확인하여 안심하는게 중요하지, Driven 씩이나 해야할 필요가 있을까?

그래서 github에 http-replay-bench 라는 프로젝트를 만들었다.

사용자들이 날린 http-request를 모두 파일로 기록해뒀다가, 개발서버/개발DB에 퍼붓는 간단한 녀석. 초당 http post request 수가 60이 넘는 서버에서도 오버헤드를 거의 일으키지 않으니 운영중인 장비에 적용하는 것도 문제가 없다.

아직 README 파일만 만들었고 소스코드는 작성하지 않았다. 요새 진행중인 프로젝트가 4개라 12월 말경에나 실제 구현을 시작할 수 있을 것이다. 조금만 기달려달라. 내가 여러분의 창의력을 훈련하는데 조그마한 보탬이 되어주겠다.