bingsoo blog

한국의 대표적인 글쟁이들을 소개하는 책이다. 이 책을 서점에서 발견하고 구입한 사람이라면 아마도 표지에 나와있는 여러 작가들 중 평소 관심이 가는 작가를 발견했기 때문이 아닐까 한다. 나 같은 경우 “구본형”, “공병호”와 같은 자기 관리 책을 쓰는 작가들에 일단 관심이 갔다. 생소한 직업 “자기 경영 전문가” 인가..아무튼 남들이 하지 않는 일을 어떻게 하게 된 것일까에 대한 궁금증이 전부터 있었고 이 책에 그 답이 있지 않을까 기대 한 것이다. 물론 전 부터 이 분들 책을 재미있게 읽기도 했다. “한비야”, “김용옥”도 눈에 들어온 이름이었다. 전 국민이 아는 작가라면 이 두 사람을 꼽을 수 있을 것이다. 이 정도로 지명도 있는 작가에 대한 궁금증은 당연하다고 본다. 그 외 내가 아는 이름은 “이완복”, “정재승” 정도였다. 기대했던 기대 하지도 않았지만 “임백준”과 같은 컴퓨터 업계의 글쟁이 들에 대한 언급은 없었다. 다루고 있는 분야는 인문, 사회, 역사, 만화, 건축, 과학 정도.

한겨레 출판에서 나온 책이니 만큼 한겨레와 연이 있었던 글쟁이(책에서 글쟁이라는 표현을 쓴다. 난 작가가 좋다.)들이 많이 섭외된 것 같다. 그 때문인지는 확실치 않지만 아무래도 분야가 조금 좁았던 것이 아닐까란 생각도 든다. 하지만 지은이 구본준씨에 의하면 어느 분야를 대표하는 글쟁이가 그 정도로 많지 않다고 한다. 한국의 출판 업계가 그 만큼 선진화 되어 있지 않다는 말일지도 모르겠다. 하지만 소설가 한명쯤은 섭외되었어야 하지 않았을까 아쉬움이 남는다.

제목이 “한국의 글쟁이들” 이어서 주로 그 들의 작업 방식, 글쟁이가 되기 까지의 과정에 대해 이야기 할 줄 알았다. 물론 그런 이야기가 주로 나오지만 의외로 그들이 어떻게 삶을 유지하는지 현실적인 이야기가 나와서 재미있었다. 또한 의도 한 것인지 작가마다 그들의 작업실 사진이 실려있는 경우가 많아서 그걸 보는 재미도 쏠쏠했다. 삼십대쯤 되면 방에 벽이 보이지 않을 만큼 책을 쌓아놓고 살겠다는 꿈을 가진 나로써 만 권 이만 권 씩 소장한 이들의 집, 작업실은 선망의 대상이 되기에 충분했다.

시간 난다면 서점에 서서 자기가 좋아하는 작가 서너명에 대한 이야기만 읽는다면 충분한 책이다. 타인의 삶을 살짝 엿본다는 것은 언제나 재미있다.

덧: 사실 표지 디자인은 좀 아쉽다. 더 세련되게 할 수 없었을까. 요즘은 내용도 내용이지만 제목과 표지 디자인에서 반은 먹고 들어가는건데 말이다.

Effective C++를 읽고 정리하는 포스트 입니다. 삐약 삐약 뉴비들을 위한 포스트이니 코드 좀 짜보셨다 하면 읽으실 필요 없습니다. 자 렛츠 고.

Item 16.
Use the same form in corresponding uses of new and delete.

이 형이 요점만 말해줄게요. new 썼으면 delete 하고 new로 배열 만들었으면 delete[] 하세요. 묻지도 따지지도 말아요. new로 한 10개 할당 해 놓고 하나만 해제 하면 너무 무책임 하잖아. 그쵸? 여자친구가 한 다섯 명 있는데 세 명한텐 헤어지자 해놓고 두 명 한텐 연락도 없이 잠수타면 그건 남자가 할 짓이 아니죠. 헛소리고, 주의해야 할 것이 하나 있습니다. 바로 typedef 두둥!
typedef std::string AddressLines[4];
/*라고 했다 칩시다. 그러고서*/

delete pal; /*하면 X되는거죠.*/
delete [] pal; /*해야 합니다.*/

저런 재앙을 피하기 위해서 웬만하면 배열엔 typedef 쓰지 말라고 Meyers 아저씨는 말하십니다. 이 분이 까라면 까는거에요.

관련 글
Use Object to manage resources

Effective C++ Item 13.

effective 시리즈를 읽지 않은, C++ 문법을 아는 정도의 초보 프로그래머를 대상으로 쓰는 글입니다. effective C++의 요약입니다.
new로 만들어낸 object를 delete 해 주지 않으면 어떤 일이 벌어질까요? 잘 아시는 대로 memory leak이 발생합니다. C++에는 Garbage Collecting 기능이 없기 때문에 프로그래머가 수동으로 이를 책임져야만 하죠. new 뒤에 delete를 붙이는 습관만 들이면 충분하다고 생각할 지 모르지만 아래 코드를 한번 보시죠.void f()
{
Myclass *pClass = createClass();
// do something
delete pClass;
}

위 코드를 유지 보수 하는 과정에서 do something 부분에 예상하지 못한 return이 들어갈 수 있습니다. 심지어 내가 아닌 누군가 그럴 수도 있죠. 공동 작업 하다보면 빈번히 발생하는 문제입니다. 이를 방지하기 위해 std::auto_ptr이란 것이 존재합니다.void f()
{
std::auto_ptr pClass(createClass());
// do something
}

로 개선 될 수 있습니다. auto_ptr로 감싼 것은 block을 벗어날 때 destructor가 호출 됨이 보장되는 것이지요. f함수의 마지막 까지 가지 않고 중간에 return 되더라도 pClass가 delete되는 것이 보장됩니다. 참 쉽져잉.

auto_ptr에 단점도 있습니다. 동일한 포인터를 동시에 지정하는 경우 처음의 포인터는 null로 만들어 버리는 것이 그것입니다. 이 문제를 해결해 주는 녀석은 std::tr1::shared_ptr입니다. tr1이 뭔지 모르는 분은… 걍 쓰세요.

마지막으로 남는 문제점은, std::auto_ptr 그리고 std::tr1::shared_ptr 모두 delete를 사용하지 delete[]를 사용하지 않기 때문에 동적으로 할당되는 배열에는 사용할 수 없습니다. 예를들어 std::auto_ptr aps(new std::string[10]) 이런거 안됩니다.

이번 장의 교훈은.. Resource 관리를 영리하게 하자 입니다. 난 짱이야 난 멋져 난 천재야 하셔서 스스로 delete 관리 하다간 memory leak을 발생시킬 여지가 크다는 것이지요. 배나온 아저씨들이 하라는데는 다 이유가 있어요.