1/22/2009

TDD는 마음의 자세


TDD관련 책들을 조금씩 읽는데 드는 생각은 TDD는 마음의 자세라는 생각이 든다. TDD 책들 대부분이 철학책처럼 TDD가 왜 필요한지에 대해서들 설명해 놓았다. 설명들은 다 조금씩 다르지만, 일단 인간의 불완전성을 인정하고 들어 가야 이해가 되는 것이 사실이다. 눈으로 보기에 완벽해 "보이는" 코드도 인간의 인지와 사고의 한계로 인해서 사실은 잘못된 코드일 가능성이 너무 많은 것이다.
사람은 자기 스스로에게 코드가 완벽하다고 속거나 아니면 주위 환경에 의해서 쉽게 주의를 빼앗 기는 경우가 많으므로 모든 주의를 기울여서 코드가 100% 완벽하게 작성된다는 것은 현실에서는 불가능하다. 인간은 아날로그이고 코드는 디지탈이다. 인간은 실수가 용납되는 세계에 살고 있고, 코드는 실수가 용납 되지 않는 컴퓨터 속에서 살고 있다. 따라서 컴파일이 된다고 해서 올바로 작동하는 코드가 아니라는 이야기이다. 작성된 코드는 이미 버그를 내포하고 있다고 "가정"해야 한다. 그리고, 그 가정은 대부분의 경우 99.9% 맞다.
작년에 회사에서 개발하는 제품에 아주 중요한 기능을 하나 추가하였다. 거의 내가 작업을 진행하였으며, 아주 훌륭하고 대단한 기법을 사용했다라고 스스로 자만하고 내 코드에 흡족해 하고 있었다. 약 3000-4000줄 밖에 안 되는 코드이지만, 제품의 기능을 많이 바꿔 놓은 코드들이었다.
그런데 문제가 생겼다. 에러 처리를 잘못한 부분이 한군데 있었는데, 단지 에러 처리 한줄이면 되는 것을 "깜빡"하고 안 넣은 것이다. 그로 인해서 대부분의 사용자에게는 나타나지 않는 문제들을 일부 사용자들은 경험해야 했다. 그 문제는 "예외 상황"에만 발생하는 버그로서 사용자의 환경에 의해서 발현 여부가 결정된다. 그래서 그 버그는 나의 전체 테스트나 QA의 몇달간의 테스트를 모두 빠져 나갔다.
이 경우 이 문제를 발견할 수 있었을 유일한 기회는 아마 TDD였을 것이라고 확신한다. 해당 함수에 대해서 TDD를 적용하여 해당 함수 콜이 FAIL했을 경우 한번만 테스트 리스트에 넣고 돌려 줬으면 된다. 하지만, 나는 하지 않았고, 결국 많은 사람들에게 누를 끼치게 된 것이다.
TDD를 지금 실무에 적용하려고 "발악"을 하고 있다. 이미 Agile 적인 개발 방법론이나 문서화, 전체 프로그램 테스트, 집중력 강화 등의 모든 사용 가능한 방법들은 이미 투입하고 있으므로 마지막 남은 TDD라는 "눈"을 그려 넣어 주면, 이제 그 누구나 부러워 하는 "완벽"한 프로그래머가 될 수 있지 않을까 상상해 본다. 99% 잘해서 만족하고 흐믓해 하다가도 1%의 버그가 부메랑이 되어서 날아 오면 그날은 정말 기분이 별로가 되고는 한다. 앞으로 그런 아쉬운 순간들을 최대한 줄여 보도록 노력할 예정이다.

Posted via email from bugtruck's posterous

댓글 없음:

댓글 쓰기