한빛미디어

"규칙", "격언"을 말하는 건, 쉽고도 어려운 일인것 같습니다. 물론 충분히 규칙을 이야기하고 격언을 만들어 낼 만큼 많은 지식이나 경험을 가진 사람이라면, 모르겠지만, 대충 중2병에 걸려서, 얇은 종잇장 같은 지식으로 규칙을 만들어 낸거라면, 섣부르게 그 규칙을 사용했다가는 낭패를 만날 수도 있거든요. 그런데, 이 책의 제목이 "규칙"입니다. 모가 아니면 도일 가망성이 높다는 거죠.

그런데, 저자인 크리스 짐머만은 제게는 생소한 이름입니다. 지금까지 이분의 책을 읽어본 일이 없거든요. 게다가 책에 소개된 프로필도 너무 짧습니다. 게임 회사 공동 창업자라니... 그래서, 링크드인과 아마존에서 저자를 찾았습니다. 역시 짧습니다. 다만, 저자는 대학 졸업후 MS에 입사해서 일하다가 9년이 넘은 다음 퇴사해서 써커펀치라는 게임회사를 친구들과 만들었고, 이미 25년이 넘게 그 회사에서 일하고 있다는 것 뿐입니다. 저자의 프로필이 간단한건, 저자의 커리어가 너무 단순하기 때문인지도 모르겠습니다.

​

책을 읽기 시작하면서, 약간 신선함을 느낄 수 있었습니다. 예제 코드가 저자의 주장을 설명하는 설명 언어로 사용되었기 때문입니다. 그리고 다음 표현을 만납니다.

25년 전에 제가 서커펀치의 첫 코드를 작성한 이후로 코드베이스가 지속적으로 발전했습니다. 아직은 이러한 발전이 끝날 기미가 보이지 않습니다.

우리의 코드는 25년 전에 비해 훨씬 더 복잡해졌지만 우리는 복잡성을 잘 통제해왔고, 효과적인 진전을 이룰 능력이 여전히 있습니다.

본문 42쪽

요즘 저는 "소프트웨어 성장 이론"에 관심을 가지고 있습니다. 프레드릭 브룩스가 <맨먼스 미신> 20주년판에 "소프트웨어를 구축하지 말고 성장시키라"고 한 말을 가져온 것인데요. 브룩스는 소프트웨어를 작성하는 것을 빌드(구축)한다고 하는 메타포가 낡고 오래되었으며 바꿀때가 되었다고 말하며 소프트웨어는 성장시켜야 한다고 했습니다. 무려 38년전에요. 하지만 우리는 소프트웨어를 성장시킬 생각은 하지 않고 아직까지도 소프트웨어를 구축하고 있죠. 말도 그렇게 쓰고요. '빌드 해봐~~' 이렇게요.

소프트웨어를 성장 시켜야 하는 이유에 대해서도 브룩스는 언급했는데요. 그건 "성장"이라는 게 자연에 여러 동식물들을 은유하기 때문입니다. 생물들은 단순한것 처럼 보이지만 단순하지 않고, 차츰차츰 성장하는 가운데 매우 복잡한 구조를 가지면서도 안정적이고 다양하고 자기 보호적이고 스스로 갱신하기 까지 하거든요.

그런데, 마이크로 소프트의 경험만으로 창업을 한 저자가 그걸 25년간 해오고 있는 것입니다. 지속적으로 발전했고, 발전의 기미가 끝날 보이지 않는 코드베이스를 가지고 있다고 고백하고 있으니까요 게다가 앞으로 더 성장시킬수 있는 코드베이스라고 자신하고 있기까지 하거든요. 첫번째 규칙을 설명하는 장을 읽으면서 저자의 사상에 수긍하기 시작한셈이네요. 짐머만의 규칙은 도가 아니라 모에 해당하는게 맞은 것 같습니다.

​

그후 책을 읽어가면서 짐머만이 애자일에 영향을 받았다는 생각을 조금씩 하게 되었습니다. "필요하지 않으면 구현하지 말라"라는 YAGNI(You ain't gonna need it) 같은 철학을 언급하기도 하고 익스트림프로그래밍(XP)개발 방식의 창시자인 켄트 벡을 인용하기도 하거든요.

이 추론 과정은 정신적 저글링을 수반합니다.

181 쪽

추론 과정을 저글링에 비유하는 건, 켄트 백의 <테스트 주도 개발> 책에 첨부되어 있는 마틴 파울러의 이야기에서도 나오는 개념인데, 짐머만도 비슷한 방식으로 이야기를 전개하고 있고요.

​

특히 코드 리뷰와 Doxygen에대한 견해는 반가웠습니다. 켄트 백의 글들을 보면 코드 리뷰가 어떤 의미를 가져야하는지를 알수 있는데요. 일반적으로 우리는 코드 리뷰 과정에서 버그를 찾아 낼 수 있다고 기대하지만, 코드 리뷰의 의미는 '남이 내 코드를 보는 과정'보다 '남이 볼 코드를 내가 작성하거나 검토하는 과정'에 있거든요.

누군가가 보고 있다는 것을 안다면 모두가 더 좋은 코드를 작성한다.

133 쪽

짐머만의 견해도 정확히 같은 거죠. 또한 Doxygen에 대해서는 다음과 같이 이야기합니다.

신중하게 사용하면 Doxygen은 여전히 유용하지만 보통은 그렇지 않습니다.

345 쪽

특히 이 이야기를 전개하는 섹션의 제목이 "이야기에는 목적이 있어야 한다"입니다. Doxygen은 사실 주석으로서의 기능이 아닌 Doxygen에 입력할 목적으로 주석을 넣는 코드가 많아야 하는 툴입니다. '이야기'가 있지만 '목적'은 없는 셈이지요.

​

아참 헝가리안 표기법을 이야기 하는 부분은 정말 흥미로웠습니다. 헝가리안 표기법은 찰스 팻졸드가 <프로그래밍 윈도우즈>에서 언급해서 유명해진 방식인데요. C나 C++코드에서 변수 이름을 선언할 때 변수의 형(변수 타입)을 나타내는 접두사를 붙이는 방식입니다. 마이크로소프트의 전설적인 개발자 "찰스 시모니"가 변수명을 그렇게 썼었다고 하는데요. 찰스 시모니를 기리기 위해서 헝가리안 표기법이라고 부르는 것이죠. 그런데 헝가리안 표기법이 병폐가 있는 경우가 있습니다. 절대적인 룰로 집착하다 보니 헝가리안 표기법으로 만든 변수명이 외계어처럼 되어버렸던 것이죠.

그런데 여기서 반전이 있습니다. 사실 헝가리안 표기법은 C언어의 간단한 타입들을 대상으로 한 것이 아니라 C로 작성한 객체지향 성격의 프로그래밍에서 인스턴스의 변수 이름을 짓는데 사용하는 방식이었습니다. GUI 컴포넌트에 대한 접두사였던 셈이죠.

이 책에서 짐머만이 쓰고있다는 헝가리안 표기법은 객체 인스턴스들을 대상으로 하는 것이었습니다. 그래서 외계어 같지도 않았고요. 마이크로소프트 출신다운 면모이기도 하네요.

​

전반적으로 재미있는 책이었습니다. C++을 안정적으로 사용해서 25년이상 코드 베이스를 성장시킬 수 있었던, 공부많이 하는 현자의 깨달음을 들어보는 책이었다고 말할 수 있겠네요.

​

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."