게으른 프로그래머가 비즈니스를 망친다?
Joel의 블로그에 Lazy Programmer, Didn’t Handle Exception라는 post가 올라왔다. 시간이 되면 joel의 post부터 보자! unit 테스트, 통합 테스트, 스트레스 테스트, 인수 테스트 등등 세상에 나온 테스트란 테스트를 다해도 우리가 만든 s/w는 버그를 가지고 있을 수 밖에 없다. 불완전한 것에서 나온 것은 불완전한 수준을 넘을 수 없는 것처럼, 모순 덩어리 인간이 만든 s/w는 필연적으로 불완전성을 내포할 수 밖에 없는 것이 당연하다. 따라서 버그를 박멸할 수 없다면 버그와 공존할 수 있는 방법을 찾아야 한다. 달리 말하면 개발자 입장에서 없앨 수 있는 범위 내에서 모든 버그를 퇴치해야 하지만, release 후 발생하는 버그에 대해서 나름대로 대처 방안이 있어야 한다.
사내 s/w의 경우, 사용자 그룹이 정해져 있기 때문에 release 후 발생하는 버그를 처리하기는 비교적 쉽다.(쉽지 않은 경우도 많다.) 그러나 사내 s/w라도 전세계 지사에 배포되서 사용하는 s/w라면 버그를 수집하기가 쉽지 않다. 사내 s/w의 사정이 이런데 불특정 다수에 의해서 사용하는 s/w는 버그 수집이 더 어려울 뿐만이 아니라, release 후 발생하는 버그에 대해서 신속한 대처를 해 주지 않는다면 비즈니스에 치명적인 영향을 줄 수 있다.
joel의 post도 이런 맥락에서 개발자들이 exception을 신중히 다룰 것을 충고해 준다. joel의 post에 있는 그림을 보자.
source from www.joelonsoftware.com
무척이나 친절한 exception 메시지다. 영어를 잘못하는 사람이 읽어도, 한국적인(?) 친절함이 느껴질 정도다. 예외가 발생했으니 어떻게 대처해야할지 잘 설명해 주고 있는듯 보인다. 그런데 이 exception 메시지가 사용자의 문제를 해결해 주기에 충분할까? post를 읽어 보면 전화 돌리기 놀이에 joel이 당한 듯 하다. 전화 돌리기 놀이는 다들 알다시피, 제품 문제 때문에 해당 회사에 전화를 걸면 이 부서, 저 부서로 전화를 돌려서 소비자를 지치게 만드는 상당히 고객 지향적인(?) 놀이다. 고객이 불편함을 겪는 가장 큰 이유는 개발자가 exception이나 bug를 제대로 처리하지 않아서 생긴다. 그런데 예외는 버그와 달리 프로그램의 필수 부분이다. 그렇기 때문에 exception이(물론 bug 포함해서) 발생했을 때는 exception의 원인을 알 수 있는 실마리를 제공해 주어야 한다. 그렇다고 해서 生exception을 보여 주는 것도 고객에 대한 예의가 아니다.
방금 갓 볶아낸 生 jsp exception… 생생하다.
그렇다고 간단하게 excpetion이나 bug id를 출력한 것으로 모든 책임을 다했다고 생각하지도 말자! 이 수법은 MS가 오래 전에 써먹었다. blue screen bug 전략이다. 이 시대의 개발자들은 시퍼런 화면 하나 던져 놓고 발 뻗고 잘 정도로 사악하지는 않다. 다 옛날 얘기다!?
추억의 블루 스크린
나도 가끔… 진짜 가끔 피곤할 때(무척 오래전에… 
), 코드에 손을 대면 아래와 같은 메시지 창 하나로 버그나 예외를 해결하기도 하였다. 그리고 누가 볼까 겁나서 빨리 소스를 commit해 버렸다. 가끔 어둠의 자식인 메시지 창이 꿈에 나타나서 “아버지! 절 왜 이렇게 나으셨나요?” 따지기도 하였지만, 꿈은 꿈일 뿐이다. 그런데 가끔 가뭄에 콩 나듯이 에러가 생기면, 천지난만한 웃음을 지었다! 웃는 얼굴에 고객이 뭐라 하지는 않는다.
웃자! 어둠의 자식 메시지 창이여!
버그나 예외 처리의 일차적인 책임은 개발자에 있다. 그러나 더욱 중요한 것은 회사에서 버그나 예외에 대해서 어떤 태도를 갖고 있는가다. 즉, 버그와 예외에 대한 태도가 회사의 품질 정책이라는 것을 지적하고 싶다. “software는 품질입니다.”라는 구태의연한 구호를 갖다 붙이지 않더라도, s/w의 품질이 얼마나 중요한지는 모두 공감하는 사실이다. 따라서 비즈니스의 사활이 걸린 품질 문제를 개발자에게만 떠넘기는 것은 무책임한 처사다. 품질은 상향식(bottom-up) 접근 방법을 사용해서 해결할 수 없다. 품질은 반드시 하향식(top-down) 접근 방법을 사용해야 한다. 물론 s/w 개발의 품질 실천은 개발자이기 때문에 회사의 강요에 의해서만 달성할 수도 없다. 즉, 실행은 bottom-up이 되어야 한다. 그러나 회사 정책이 정해진 다음 이런 강력한 실천 의지가 top-down 형태로 파생되어야 한다는 의미에서 품질은 하향식 접근 방법을 사용해야 한다고 말한 것이다. 따라서 옳고 그름을 떠나서 회사의 품질 정책이 수립된 이후 생exception을 보여 주던지, 블루 스크린으로 떼우던지, 미소와 메시지 박스로 해결하던지 개발자의 실천 강령이 수립될 수 있다. 그리고 나서 발생하는 품질 문제는 누구의 책임인지 판단할 수 있다. 품질 정책으로 삼을만한 것은 joel의 Painless Bug Tracking를 참조하자. 간단하지만 실용적이다!
미천한 버그 처리는 개발자가 원흉이지만, 그 배후에는 회사의 품질에 대한 방관도 존재한다는 사실을 잊지 말자!
About the Author
This is Hani! My job is consulting, system design and project management... Sometimes coding. I hope you have a great time on my blog.