기차니즘 초절정 고수 일탈을 꿈꾸며... - 스팟

개발이라는 말을 코딩이라는 말의 동의어 쯤이라고 생각해서는 안된다. 왜냐하면 개발은 코딩만을 잘한다고 성공할 수 없기 때문이다. 혼자서 북치고 장구치고 하는 정도의 프로젝트 규모라면 이 책이 와닿지도 않을 뿐더러 지루하기까지 하다.

이 책은 코드개발이 거의 끝나고 막 오픈하려는 시점부터 나올법한 문제점을 저자의 실전경험을 바탕으로 써놓았다. 아무리 잘 짠 코드라도 장애한번 나지 않은 역사가 짧은 코드라면 그 코드에 문제가 없다고 장담할 수 없다. 사람이란 실수하게 마련이고 그 실수가 코드에 반영되기 때문이다. 사람의 실수을 줄이더라도 기계적인 실수도 있다. 가령 이벤트가 갑자기 잘 되서 웹사이트에 찾아오는 손님이 많다고 했을경우, 코드는 완전무결하다고 해도 네트워크의 트래픽이나 하드웨어의 CPU, 메모리, 하드디스크가 완전무결하다고 할 수 없다. 심시어 전원이 꺼질수도 있지 않은가.

코드를 말할 때 설계를 중시한다. 디자인 패턴이나 리팩토링이 잘된 설계를 유지하도록 권하는 안내서이라면 이 책은 꼭 해야될 것과 하지 말하야 할것을 말한다.

내 경험에 비춰보면 로그는 꼭 잘 남기는게 좋다. 일단 아예 없다면 문제를 해결할 수 있는 실마리를 찾기 힘드니 지금이라도 로그를 남길 수 있도록 프로그램을 개조하자. 이제 로그를 잘 남기기 시작했다면 사람의 눈에 잘 들어오도록 조정하자. 로그는 사람이 보는 것이다. 한눈에 판단할 수 있도록 코드의 컨벤션을 지키듯이 로그도 그래야 한다. 수준을 정하자. 디버그를 위해 코드에 남겨뒀던 로그를 삭제하는 짓은 미련하다. 한 번 문제가 생겼던 부분은 자주 문제가 생기기 때문에 수준(level)에 따라 조정할 수 있게 하는게 현명한 일이다.

이책에 나오는 것중에 또 공감되는 내용은 '고장을 내라?'이다. 어느 웹 사이트에 접속했는데 화면레이아웃이 다 깨지고 정신없는 스크립트 에러가 나는 원인은 수많은 기능중에 단 한가지 때문인 경우가 많다. 연동된 시스템이 죽을 수도 있고, 개발자의 실수로 오타가 삽입될수 있다. 이런 경우 고장난 기능을 다시 부르지 않도록 빨리 고장을 전체 시스템에 알릴 수 있도록 방어하는 기술이 필요하다. 고장난 부분을 계속 부르게 되면 고장은 더 심각해지고 복구도 어렵다. 때문에 고장난 부분은 고장났으니 다시 부르지 않도록 고장났음을 표시하는게 오히려 서비스를 받는 입장에서 좋다.

경험은 무엇보다 소중은 자산이다. 이런 경험을 책을 통해서 얻을 수 있다면, 쉽게 말해 밤샘을 회필할 수 있는 가능성이 높아진다고 할 수 있겠다.



덧1)
이 책은 트랙백 이벤트에 당첨되서 위키북스에서 제공해주신 책입니다. 잘 읽었습니다.