飛人大愛의 Diary

버그 없는 프로그램을 만드는 것, 완전 무결한 에러율 0%의 로직을 구현해 내는 것, 누구나 언제든지 필요한 기능을 손쉽게 추가하고 개선해 나갈수 있도록 이해하기 좋게 코딩하는 것, 최소의 자원으로 최고의 퍼포먼스를 내는 최적의 프로그램을 짜는 것, 발생가능한 모든 상황을 미리 예상하고 대안을 보유하고 있도록 작성하는 것… 조금씩 말만 다르지 프로그래밍 분야에서 말하는 장인정신이란 대충 비슷합니다.
그런데 정말이지 이런것들이 개발자가 갖춰야할 장인정신일까요?

일단은 맞다고 하고 싶습니다. 완벽한 제품을 만드는 것이 장인의 정신이죠.. 하지만 반드시 장인정신의 덕목을 엄수해야 한다고 생각하지는 않습니다. 이건 제조업이 아닙니다. 제조업과는 다른 잣대로 생산물을 평가해야 하죠..
게다가, 사실.. 먹고 살자고 하는 짓이지 않습니까.. 주어진 시간 안에(정말이지 모호한 표현입니다만..) 계획된 목표물(역시 모호합니다.)을 만들어야 하는 것이 비지니스의 원리죠.. 시장경제가 어쩌니 하는 말들을 굳이 꺼내지 않아도 누구나 알고 있을 겁니다. 프로그래머는 엔지니어지 사이언티스트가 아니지 않습니까? 실용성이 있는 무언가를 만들어야 하는 것이지요.. 실용성을 생각한다면 비용와 이윤의 트레이드 오프가 무시할수 없는 변수로 등장 하게 되구요..

제 결론을 말할까요? 고쳐야 되는 버그를 찾아서 고치자 하는 겁니다. 물론 자원이 허락하는한 모든 버그를 고쳐야 하죠. 개선의 여지가 있는 모든 로직을 개선해야 하구요.. 하지만 때로는 포기할 줄도, 기약없지만 미룰 줄도 알아야 한다는 겁니다.

프로그램을 짜던 중 어떤 버그를 발견했습니다. 참으로 어처구니가 없는 일이었죠. 절대 일어날수 없는 입력값이 입력된겁니다. 심심해서, 또는 테스트 프로그램이 잘못 설정되는 바람에 그런 입력값을 주기도 어려운 입력값을 주게 된 것이죠. 이를테면 106키보드에서 358개의 키가 동시에 눌러졌다던지, 마우스 포인터의 좌표가 (-103.5, -87.3)이 되었다던지.. 웹서버에 전송할 HTTP Request 객체를 생성하고 소켓을 열기도 전에 Ethernet드라이벗로부터 HTTP Response가 수신되었다던지.. 상식적으로 일어나지 않을 거라고 확신이 드는 그런 입력값 말이죠.. 그랬더니 원래 의도했던 다이얼로그가 뜨지 않는겁니다. 물론 다시 버튼을 클릭 한번만 해 주면 이전의 이상한 입력값은 깨끗이 무시되고 의도한 다이얼로그가 뜨긴 합니다. 자.. 이 버그를 고쳐야 할까요? 장인정신이 투철한 개발자라면 예상치 못했던 입력값이 주어졌을 때, 예외상황을 선포하고 적절한 핸들링을 하기 위해서 말도 안되는 입력값을 상상력을 동원하여 재현해 보고 분석하여 몇가지를 무시한 결과로 다이얼로그를 보여주려고 할 겁니다. 유저는 입력이 이상했다는 것(노이즈가 개입되었을 수 있다는 것)은 전혀 느끼지 못한 채로 계속 프로그램을 작동 시킬 겁니다. 3일 밤을 꼬박 세워서 말이죠..

하지만 이런 종류의 버그에 대처하기란 쉽지 않습니다.
전세계에 배포하면 2억명의 고객에게 팔릴 이 제품에 대해, 107명쯤이 이 버그를 경험할텐데, 그중 92명은 버그를 눈치채지 못하고 버튼을 다시 클릭할겁니다. 15명은 뭔가 이상한 작동을 하는것 같다고 생각하지만 재현이 쉽지 않아 포기합니다. 하지만 개발자는 이 버그를 고치기 위해 불가능한 갖은 입력값을 프로그램에 던져보면서 모든 예외상황을 재현하려 애쓰면서 그에 적절한 반응을 보일수 있도록 코드를 수정할 것입니다. 3일 밤을 새면서 말이죠..
(사실 3일이면 다행이죠)
소프트웨어의 완성도는 고객에게 기업에 대한 신뢰를 높여준다지만, 이 버그가 수정된걸 눈치채고 역시 훌륭한 업체라고 생각하는 고객은 전 세계 2억명 고객중에 15명에 불과합니다. 어쩌면 이 15명 조차 못느낄 지도 모르죠..
15명에게 기업의 이미지가 매우 좋아졌지만, 소프트웨어의 신뢰도도 매우 높아졌지만, 15명의 충성도 높은 고객을 확보하였지만, 이 15명의 고객이, 프로그래머가 3일간 밤을 세우며 디버그 하는 바람에 출시가 일주일 늦어져 발생한 16억 3천만원의 매출을 올려주려면 정말 오래 걸릴겁니다.

예시가 적절치 못했을지도 모르겠습니다. 숫자도 제 멋대로 막 갖다 붙인겁니다. 하지만, “반드시 지금 고쳐야 하는 버그”와 “기회가 되면 고쳐야 하는 버그”는 구분할줄 알아야 합니다. 로또 1등을 19회 연속으로 맞아 앞으로 먹고 살 걱정 안하고 소프트웨어 공학의 발전과 자기 만족에만 인생을 쏟아부을 생각이 아니라면 말이죠..

버그대처와 관계되는 프로젝트 관리에 대해 이야기 하자면 끝도 없이 길어지겠지만 이미 스크롤의 압박은 충분히 만들었다고 생각되는군요^^; 다 써놓고 보니 어쩌면 비굴해 보일지도 모르는 글이지만 수정하지 않겠습니다. 비굴해지는 연습도 해봐야죠;;

이 글은 개발자로서의 저의 가치관에 대한 글입니다. 다음이 저희 회사라고 저와 입장이 같지는 않을수도 있습니다. 두달쯤 후엔 DNA에서 루미넌스를 볼수 없을지도 모른다는 말이죠..

ㅎㅎ 농담입니다.