(서평) Art of Unix Programming - 프로그래머가 가져야 할 마음 가짐을 알려주는 좋은 책.

제가 프로그래밍을 접한 시기가 97년이고, 윈도우 프로그래밍에 대한 정보를 얻기도 쉽지 않은 시기였습니다. (도서관도 시립 도서관외에는 힘들었고, 집 근처에 도서관이 없던지라 서점에 파는 책들이 전부였죠)

그런 상황에서 유닉스나, 리눅스 프로그래밍은 더 접하기 어려웠고, 그렇다보니 자연스레 윈도우 프로그래머가 되었습니다.

굳이 리눅스를 접해야만 할 이유가 없었고, 윈도우에 만족하고 있었지만, 현대 운영체제의 모태인 유닉스 계열 운영체제를 접해봐야 왜 그렇게 만들어졌는지 알아야만 윈도우 프로그래밍을 더 잘할 수도 있겠고, 유닉스 계열 운영체제가 맘에 든다면 그쪽으로 개발하는것도 괜찮겠다는 생각에 Fedora를 시작으로 리눅스를 사용하게 되었습니다.

서버 프로그래머이다보니 네트웍에 관심을 갖고 있는 것도 한몫 했죠.

책의 전반적인 내용은 프로그래머가 가져야 할 마음 가짐과 왜 유닉스가 개인 사용자가 느끼기에 불편한가 하는 것에 대한 이야기를 하고 있습니다.

유닉스는 프로그래머를 위한 문화이고, 그래서 프로그래머들의 기호를 맞추기 위해 세심한 조작이 가능하게 하였고, 서로 다른 프로그램이 상호 작용 하기 쉬워야 한다는 것이죠.

그러기 위해선 에러가 아닐 때에는 아무런 메시지도 띄우지 말아야 하고, 그런 역사가 과거 연산 속도가 떨어져 메시지 출력이란 작업이 비싼 작업 이었을 때로 부터 이어져 내려왔다는 것도 알 수 있었습니다.

그런 부분들이 일반 사용자가 느끼기에 불친절 할 수 있고, 어렵다는 점에 대해서는 저자도 인정하고 있었습니다만, 유닉스의 가치가 거기에 있는 것이 아니기에 유닉스는 인정 받아야 한다는 의견을 피력하고 있었습니다.

제 생각에도 유닉스는 뛰어난 운영체제이고 인정 받아 마땅하며, 이미 인정 받고 있죠.

하지만, 지나친 유닉스 사랑이 윈도우를 폄하하는 오류를 범하게 하고 말았습니다. 사용자 중심의 윈도우 문화는 폄하되어선 안된다고 봅니다.

오히려 사용자 중심적인 문화는 지향 되어야 하는 것이라고 생각합니다.

에릭 레이몬드씨가 지적한 문제점들이 사실이긴하나, 유닉스의 단점들에 이유가 있었듯이, 윈도우가 그렇게 된 이유들도 다 납득이 갈만한 이유가 있습니다.

유닉스 문화의 문제점을 지적하는 자기 성찰적 면모를 보이기도 했지만, 그렇다고 해서 윈도우의 단점만 지적한것까지 옳은 판단이라고 받아들일 수는 없었습니다.

많은 프로그래머에게 귀감이 될만한 좋은 내용이 넘치는 이 책에 많지 않은 내용이지만 윈도우에 대한 험담으로 그 가치가 조금 떨어졌지만, 그래도 여전히 좋은 책이고, 유닉스 프로그래머들에게는 자부심을, 그리고 유닉스에 대한 이해도를 높여주며, 윈도우 프로그래머들에게는 유닉스 문화에 대한 이해를, 그리고 윈도우 문화에 대한 고찰을 할 수 있는 좋은 책이었다고 생각드는 책이었습니다.

(서평) 패턴 그리고 객체지향적 코딩의 법칙 - 그들의 경험을 쉽게 이해하는 한가지 방법

이 책은 경험이 쌓이면서 알게되는 진리들 (성급한 최적화, 객체지향 설계가 필요한 이유, 중복 제거가 필요한 이유 등등) 을 쉽게 설명해주고 있습니다.

전공이 컴퓨터 공학이었다보니 선후배나 동기들이 프로그래밍을 어떻게 하면 쉽게 배울 수 있느냐고 물어봅니다.

그런 부분에서는 이 책도 해답이 되긴 힘들다고 생각합니다. 이 책은 프로그래밍의 방법을 알려주는 책은 아니니까요.

제 생각에 이 책은 프로그래밍이란 과정은 알아가는데, 좀 더 유지보수하기 좋고, 이해하기 쉬운 코드를 목표로 삼고 있는 프로그래머들이 읽으면 적당한 책이라고 생각합니다.

저도 이 책의 나고수씨와 같이 패턴이름들을 외우고 있지 않습니다.

기껏 외우는거라 봤자 팩토리, 싱글턴 정도였죠. 하지만 사용해왔던 클래스 형식이나 구조들이 거의다 패턴으로 있더군요.

그런걸 보면 패턴은 의사소통의 수단중에 하나고, 코드 구조를 정리하는 수단이라고 볼 수 있죠.

사실 프로그램을 잘 모르는 상태에서 흔히 듣는 얘기가 회사들어가면 금방 알게 된다 하지만 그렇지 않은 경우도 많습니다.

결국은 어떤 것이 왜 좋은지, 왜 나쁜지에 대한 이해가 이뤄져야만 하죠. 주로 그것이 경험을 통해 이뤄지는 것이지만, 그런 상황을 알려주는 이 책도 한가지 방법이 될 수 있다고 봅니다.

저는 예전 경험들을 되돌아보는 느낌으로 읽었지만, 이제 처음 시작하시는 분들에게는 대리 경험으로써 큰 도움이 될꺼라 생각되는 좋은 책이었습니다.

(서평) 네트워크를 훔쳐라 - 그들의 심리를 파악하자

나는 공격하는 자보다는 방어하는 자의 입장이다.   그런데 왜 보안 서적이 아닌 해킹 관련 서적을 보냐고? 보안이란 이미 알려진 취약점을 틀어 막는다고 되는 것이 아니기 때문이다.   해킹이란 단순히 뛰어난 컴퓨터 지식을 기반으로한 공격 기술만을 말하는 것이 아니다.   책의 내용중 해커들이 파고 들 수 있는 시스템 취약점이 많다는 사실은 새삼 놀랠만한 내용은 아니었다.   뭐 당연한 것이겠지.   프로그래머가 실수를 했을 수도 있고, 악용될 여지의 취약점을 모두 고려한다는 건 쉬운 일이 아니기 때문이다.   이 책에서 설명한 공격 코드가 시스템의 어떤 취약점을 파고 들었고, 어떠한 생각을 가지고 다른 빈틈을 찾아나가는지에 대해 이해하는 것은 크나큰 소득이었다.

막연히 이렇게 해야 한다 라고 알고 있는 것보다, 어떤 취약점이 무엇 때문에 문제가 됐기에 막아야 한다는 것을 아는 것이 중요하다.

또한 기술적인 부분보다 심리적인 부분의 취약점이 더 클 수 있다는 내용들을 보며, 나의 보안의식에 대해 다시 한번 돌아보게 되었다. 나 역시 비밀번호를 다양하게 사용하지 않고 있으며, 공유 폴더에 중요한 자료를 꽤나 긴 시간 동안 넣어둔 적이 있다. 물론 그 공유 폴더가 사내에만 공유되는 것이지만, 사내 네트웍이 뚫렸다면?? 끔찍한 일이다.

소설과 같은 형식이다보니 기술적인 디테일은 부족했다. 하지만 나에겐 기술적인 디테일을 다룬 서적들 이상을 얻을 수 있었던 좋은 서적이었다.

(서평) 프로그램은 왜 실패하는가? - 체계적인 디버깅 지침서

사실 프로그램 작성 만큼이나, 아니 더 중요할 수도 있는 과정이 디버깅입니다.   보통 버그는 논리적인 오류나 실수에서 자주 발생합니다. 그 코드가 영향을 끼치는 다른 코드에서 세웠던 가정이 깨졌다거나 하는 경우에 발생하기도 하죠.   이 책은 그런 부분의 이야기보다, 실서비스 되기전에 테스트를 어떻게 하면 버그를 잘 찾을 수 있을까, 또 이미 문제가 발생했다면 어떻게 찾을것인가에 대한 내용이 더 빈도있게 다뤄지고 있습니다.   이 책은 체계적인 디버깅 방법을 다양하게 다루고 있습니다. 로그, 버그 DB, 버그 트레이스, 테스트, 문제 재현, 추론 같은 방법들 말이죠.   저 같은 경우는 게임 서버를 맡고 있는데, 서버 유지보수 과정에서 겪은 문제들의 해결책이 이 책에 다 나와있었습니다.   제가 그 상황을 겪기전에 이 책을 알았다면 얼마나 좋았을까 안타까워하면서도, 그 만큼 필요했던 좋은 내용을 담고 있으며, 그 내용들이 잘 정리된 책이라는 점에서 좋은 책이라는 생각이 들었습니다.   문제가 발생할 여지를 줄여주는 리팩토링을 개발 과정에 도입하고, 빈틈을 빠져나간 버그들을 이 책에 나온 다양한 방법들을 적용한다면 완성도 높은 프로그램 개발자가 될 수 있을거라 믿어 의심치 않습니다.  

꾸준히 고민하고 노력하는 것만이 질 좋은 소프트웨어를 만들 수 있는 방법이다.

(서평) 리팩토링 - 실용적이고, 현실적이며 실천적이었다.

리팩토링이란 좋지 않은 구조의 코드를 좋은 구조로 바꾸는 작업을 말합니다.   돌아가기만 하면 되지 구조가 뭐가 중요하냐고 생각하시는 분들은 아마 유지보수의 악몽을 경험해보시지 않은 분들일 것입니다.   실용주의 프로그래머란 책을 읽어보면 깨진 창문 법칙이란 얘기가 나옵니다.   창문이 하나 깨지고 나면 다른 창문이 깨지는걸 대수롭지 않게 여기게 되어, 결국 모든 창문은 깨지게 된단 이야기입니다.   프로그램 코드도 마찬가지입니다. 지금 당장은 이렇게 하는게 문제 해결에 빨라. 우선 이렇게 해놓고 보자. 돌아가니까 내버려두자라고 생각해 대충 처리한 것들은 언제고 문제를 일으키기 마련입니다.   책서 언급한 리팩토링이 필요한 코드의 법칙에는 우리가 개발과정에서 느껴온 실수의 여지를 줄이는 방법이 있습니다.   우리의 머리는 대용량 컴퓨터가 아닙니다. 기억은 지워지기 쉽고, 직관적이지 않은 코드는 실수하기 쉽습니다.

메모의 기술이란 책에서는 이렇게 말합니다.   ‘기억하기 위해 메모하는 것이 아니라, 잊기 위해 메모하는 것이다’   사람의 기억은 믿을게 못됩니다. 리팩토링을 통해 직관적으로 바뀐 코드의 세세한 동작은 잊어버리셔도 됩니다. 코드를 메모처럼 잊읍시다.   꺼림직한 코드를 작성했을때에 늘 후회하는 상황이 발생했습니다. 언제고 다시 리팩토링 해야 했기 때문이죠. 늘 작성한 코드를 리팩토링 대상으로 놓고 검토하고 수정한다면 유지보수의 악몽에서 벗어날 수 있을거라고 확신합니다.   리팩토링은 실천의 미학이기 때문이죠.