Book

자바 성능을 결정짓는 코딩 습관과 튜닝 이야기, 이상민 지음, 한빛 미디어

어떤 것에 대한 지식을 효율적으로 습득하는 방법에는, 그 지식에 관해, 체계적으로 분류하고 정리해 놓은 권위 있는 책을 읽는 방법도 있지만, 잡지와 같이 지식들을 그저 늘어놓은 형태의 정보를 접하는 방법도 있다.

이 책은 후자에 해당하는 책이다. 자바의 코딩 습관에 관한 책이나 자바 성능 튜닝에 관한 문서는 있지만,  경험이 부족한 사람들에게 필요한 것은 정보 자체가 아니라 정보에 대한 좋은 레퍼런스가 필요한 경우가 있다.

잡지의 형식의 특성 중 하나는 필자의 경험에 따른, 시간이나 상황, 독자에 맞는 정보들을 보여 주려고 시도한다는 것이다. 권위가 있는 서적에서는 특성상 시간이나 경험에 따라 변할 수 있는 정보를 보여 주려고 하지는 않는다. 그럼에도 불구하고 현실에 살고 있는 우리들은 시간에 따라 변할 수 있는 정보를 필요로 한다. 예를 들어, 최소한 필자 또는 삼성 SDS에서 자주 쓰는 프로파일링 도구는 무엇인가와 같은 정보가 그러한 정보에 해당하는 것이다. (어떤 성능 튜닝 책에서는 프로파일링 도구를 모두 정리해 놓을 수 있지만, 이 책은 그런 것을 시도한 것 같지는 않다.)

이 책의 다른 미덕 하나는 ‘이야기’와 ‘실제 사례’를 들려주려고 시도했다는 점이다. 필요한 정보만 정리되어 담겨 져 있는 책이나 문서가 아니라, 나 같은 경우에도 ‘이야기’가 담겨 있는 책은 훨씬 접하기가 편안하다. 말하자면, 주말에 편한 의자에 앉아서 시간 때우기 용으로 읽거나 심지어는 화장실에서 읽을 수도 있다는 것이다.

최소한 이 책은 초보자를 위한 자바의 기본적인 코딩 습관, 성능 튜닝에 관한 지식 등으로의 참고 자료 또는 잡지가 되는 것에는 성공했다고 생각한다. 다만, 숙련자가 읽기에는 정보의 깊이라든가 정확성 등은 약간 부족한 면이 있다.

Ship It by Jared Richardson, William Gwaltney

Ship It은 소프트웨어 개발에 관한 가이드라인을 담은 책이다. ‘도구와 인프라스트럭처’, ‘실용주의적 프로젝트 기술’, ‘예광탄 개발’, ‘일반적인 문제와 해결방법’의 네 부분으로 나뉜다.

‘도구와 인프라스트럭처’는 CVS 또는 Subversion과 같은 코드 저장소, 빌드의 자동화, 이슈 및 기능 추적, 테스트 자동화와 같은 이슈를 다루고 있다. 사실 이러한 도구들을 사용하라는 가이드라인은 흔히 들을 수 있는 이야기지만, 이 장의 마지막 가이드라인인 ‘실험하지 말아야 할 때’에서는 ‘핵심적인 기술을 기술 실험 대상으로 삼아선 안 됩니다’라는 중요한 교훈을 얘기하고 있다. 의욕에 찬 하지만, 경험은 부족한 개발자들이 흔히 하는 실수다.

‘실용주의적 프로젝트 기술’에서 소개하는 목록 사용은 오래 전부터 나나 내가 일하던 팀, 내 주변의 사람들이 실제로 활용하면서 훌륭한 습관임이 증명된 프랙티스다.

일일 회의나 모든 코드의 검토, 코드 변경 통지 등은 내겐 약간 적용하기 힘들어보이는 프랙티스들인데, 각각의 프랙티스는 나름의 장점들을 갖고 있다는 것에 동의하기 때문에 조금씩 적용해 볼 생각이다.

내가 맡고 있는 조직에 주간 회의를 적용하기 시작한지가 수개월 지났고, 현재는 어느 정도 정착이 되어가고 있다. 하지만, 어차피 작업이나 문제 관리를 위한 의사 소통이 매일 일어나는 것을 생각하면, 일일 회의는 의사소통이 예측 가능하게 일어나게 해주고, 때문에 효율적인 의사소통이 가능하게 해주리라 생각한다. (이는 주간 회의를 포함한 ‘정기적인 회의’의 장점일 것이다.) 하지만, 일일 회의를 시행하기 위해서는 주간 회의라는 익숙한 프랙티스를 포기해야 한다. 이와 같이, 어떤 프랙티스가 좋고, 현재의 프랙티스를 대체하자는 얘기는 너무나 쉽지만, 이것을 적용하기 위한 사람들의 지지를 얻고, 대체 과정의 비용을 줄이고, 실제로 잘 적용하는 것은 여러 고민과 많은 노력이 필요한 일이다.

코드 검토의 경우, 이 책에서는 변경을 포함한 모든 코드를 검토해야 한다고 나와있지만, 그보다 온화한 (덜 진보적인) 단계로, 새로운 모듈이나 프로그램, 시스템이 완성되었을 때, 코드 검토를 하는 프랙티스가 경험적으로는 상당히 좋았던 것 같다. 아마도 이를 코드 검토를 시작하는 팀의 마지노선으로 잡으면 될 것 같다. 코드 검토는, 이 책에서 얘기하는대로, 작은 단위로 할 수록 효율과 정확성이 높아지는데, 작은 단위로 리뷰하는 문화를 정착시키는 것은 또 다른 과제다.

현재 팀에는 기술 리더라고 할만한 사람들이 몇 명 있는데, 팀의 한 파트를 책임지고 있는 나도 그 중의 한명이라고 볼 수 있다. 간단하게 말해서, 기술 리더는 기술 업무와 관리 업무를 수행해야 하는데, 둘 다를 수행하는 것은, 한가지만을 수행하는 것에 비해 절대 쉬운 일은 아니다. 가장 중요한 책임 중 하나는 역시 우선 순위의 조정이다. 업무의 목록은 팀원들 각자가 결정할 수 있지만, 우선 순위의 문제는 항상 기술 리더의 책임이다. 요즘 내가 생각하고 있는 것은, 우선 순위 결정을 주간 보고나 주간 회의와 같은 과정에 자연스럽게 연결해 프로세스화 하는 것이다.

‘예광탄 개발’은 일반적인 애자일 개발과 얼마나 크게 차이가 있는지 모르겠고, 굳이 ‘예광탄 개발’이라는 이름표를 달아주어야 하는지 의문인데, 이 글에서는 설명을 생략하도록 한다.

‘일반적인 문제와 해결 방법’은 분류하기 힘든 가이드라인을 모아놓은 부분이라고 볼 수 있는데, 그 중 ‘불한당 개발자’에 대한 대처 방법을 다룬 항목이 흥미로웠다. 고삐를 채울 수 없는 불한당의 경우, ‘불한당의 행동을 문서화하고, 반항적 행동을 문제 삼아 해고해야 한다’는 것이다. 그리고, ‘대부분의 경우엔, 문서화 과정을 시작하는 것만으로도 충격받아 제자리로 돌아온다’라고 한다. 실제로도, 문제를 일으키는 팀원의 경우, 문제점을 지적당하면, 그 근거를 제시하라는 답이 돌아오기도 한다. 이에 대한 정당한 답변은 다른 사람에게 어떻게 얘기했는가, 어떤 예절 바르지 못한 행동을 했는가 등이 아니라, 잘 문서화된 작업 목록 뿐이다. 이런 수단이 악의적으로 사용되어서는 물론 안되겠지만 말이다. 한편, Jeff Atwood의 ‘Dealing With Bad Apple‘이란 글에서는 불한당 또는 Bad Apple은 팀 전체에 악영향을 미치며, 어떤 사람의 능력은 발전할 수 있어도 태도는 변하기 어렵다는 이유로, 빨리 제거하는 방법밖에 없다고 얘기하고 있다.

이 책 전체에서 드러나는 실용주의적 태도 – 어떤 프랙티스가 절대적으로 옳다고 주장하기 보다는 적합한 것을 적용해나가자는 태도 – 는 상당히 마음에 드는 편이다.

내용이나 태도 뿐만 아니라, 구성 면에서도, 하나의 가이드라인마다 마지막에 ‘어떻게 시작하면 될까요?’, ‘제대로 사용하고 있는 걸까요?’, ‘경고 신호’와 같은 섹션을 두어, 이 책에 나온 가이드라인을 실제로 행동에 옮길 수 있는 지침으로 활용하기 좋게 만들어져 있다.

번역은 따로 언급할 필요가 없을 정도로 잘 되어 있는 편이다. 최근에 출판되는 해외에서 유명한 기술 서적들은 평균적인 번역 품질이 예전보다는 많이 좋아진 것 같다.

Prefactoring by Ken Pugh

오랜 경험을 통해서 소프트웨어 개발에 관한 통찰을 얻은 소프트웨어 개발자라면, 자신이 얻은 교훈을 세심하게 준비된 실제 사례를 곁들여 다른 사람에게 보여주고 싶은 욕구를 한번쯤은 느꼈을 것이다. 이 책은 바로 그러한 책이다.

이 책의 제목인 Prefactoring은 자신과 다른 사람들의 경험으로부터 얻은 통찰을 소프트웨어를 개발하는 데에 사용하는 것이라고 저자는 설명한다. 그렇다면, Prefactoring이란 경험을 가진 여러 소프트웨어 개발자들이 이미 하고 있는 일이다. 단지 반짝하는 제목 이상의 뭔가가 있을까? 다음은 저자가 내세우는 3가지의 가이드라인이다.

• Extreme Abstraction
• Extreme Separation
• Extreme Readability

더이상 언급이 필요없을 정도로 소프트웨어 개발에 있어서 핵심적인 가치들이라고 할 수 있다. Abstraction과 Separation은 나도 ‘프로그래머에게 필요한 능력‘이라는 글에서 언급한 적이 있다.

이 책에서 가장 읽을만한 부분은 Preface다. 이 책을 사지 않더라도 서점에 들르게 되면 서문 부분을 한번 뒤적거려볼만한 가치는 있다.

서문에서 얘기하고 있는 것 중 하나는 바로 어떤 원리나 프랙티스에 얽매이지 말고 항상 상황-문맥에 따라 트레이드 오프(trade-off)를 고려해서 판단해야한다는 것이다. 이름 있는 훌륭한 엔지니어들에게서는 항상 이러한 모습을 볼 수 있다.

One rule exists: nothing works everywhere, and hence, you must be the judge if a particular practice is appropriate for your application. You need to apply principles in context. The decison whether to use a particular principle or practice depends on the situation in which it is employed.

다른 하나는 바로 회고의 중요성이다. 회고에 대해서는 다른 글에서 좀 더 얘기하기로 하고 여기서는 말을 아껴야겠다. Norman L. Kerth의 Project Retrospectives라는 책을 추천하고 있는데, 한번 읽어봐야겠다.

이 책의 본 내용은 처음에 얘기했듯이 CD 대여점을 위한 가상의 프로젝트를 진행해 나가면서 정련된 가이드라인과 원리들을 보여주는 식으로 이루어진다. 이 가이드라인과 원리들은 하나하나 한번 읽고 넘기기 아까울 정도로 소중한 교훈들이지만, CD 대여점 프로젝트는 좀 지루한 편이다. 참고로 난 100 페이지 정도 읽고 나서는 그냥 나머지는 가이드라인만 읽고 말았다.

가이드라인 중에는 자주 들을 수 있는 것들도 있고 아닌 것들도 있는데, 그렇지 않은 것 중에 하나를 소개하자면 다음과 같은 것이 있다.

Splitters can be lumped more easily than lumpers can be split: It is easier to combine two concepts than it is to separate them.

다시 말하면, 뭉쳐있는 것을 나누는 것보다 나뉘어있는 것을 합치기가 쉽기 때문에, (고민이 된다면) 나누어놓는 쪽을 택하는 것이 좋다는 것이다.

이는 여러가지 상황에서 적용될 수 있는데, 예를 들어 어떤 인터페이스에서 발생할 수 있는 예외 (또는 에러 코드)들을 정한다고 해보자. 당연히 너무 세부적으로 나누면 복잡할 것 같다는 생각이 들기 마련이다. 어느 정도 수준으로 나누어야 할지도 애매한 경우가 있다. 어차피 미래의 필요는 예측하기 힘들다. 하지만 우리가 지금 알 수 있는 것은 미리 나누어두는 것이 좋다는 것이다. 나중에 쌓인 에러 로그를 보면서 비슷한 종류의 에러끼리 모아서 분석할 수는 있지만, 애초에 나누어놓지 않은 에러는 분석이 아예 불가능하다.

이러한 원리는 이러한 결정이 돌이키기 힘들 수록 더욱 강하게 작용한다. 분류하는 정보의 크기가 너무 커서 다시 분류하기가 힘들수록, 이미 여러 고객들과 미리 정한 인터페이스를 변경하기가 힘들수록 이러한 가이드라인이 머리 속에 떠오를 것이다.

이 책은 그리 두꺼운 책도 아니니 부록에 있는 가이드라인 모음만 쓱 훑어보는 식으로 읽어보는 것도 괜찮을 듯 하다. 하지만, Jolt Award 수상작에게 기대한만큼 만족스럽지 못한 것도 사실이다.

Dynamics of Software Development by Jim McCarthy

요즈음 널리 유행하는 방법론들처럼 체계화 되어있는 것은 아니지만, 이 책은 소프트웨어 개발의 여러 부분들에 걸친 조언을 담고 있는 책이다. 그 범위는 소프트웨어 개발에서 어떤 것이 바람직한 리더쉽인가, 어떻게 팀을 만들 것인가, 고객이나 비즈니스 부문 등의 팀 외부와 어떻게 소통할 것인가, 경쟁 시장에서 어떻게 포지셔닝할 것인가,빌드와 출시, 개발 일정과 주기는 어떻게 할 것인가, 사람은 어떻게 뽑을 것인가와 같이 소프트웨어 개발 팀에 관련된 거의 모든 부문을 다루고 있다고 해도 과언이 아니다.

저자는 소프트웨어 개발팀을 생태계와 같은 것으로 보고 있다. 팀원들은 팀장의 지시에만 따르고, 미리 정해진 역할을 수행하는 것이 아니라, 팀장은 팀원에게 권한을 위임해야하며 (지식노동에 있어서 이것은 이미 황금률이다.) 팀원들은 자신의 능력이 다른 팀원들과 조화를 이루도록 역할을 진화시켜 나간다. 이러한 관점은 소프트웨어가 지식 노동의 산출물이기 때문에 무엇보다도 팀원들부터 아이디어가 자유롭게 나오고 그 중에서 최상의 아이디어가 선택되어야한다는 이유에 비롯한다.

애자일 소프트웨어 개발 프랙티스 (이를테면 XP와 같은)에서와 비슷한 주장들을 1995년에 쓰여진 이 책에서 하고 있는 것도 재미있는 점이다. (참고로, C3 프로젝트는 1996년에 시작되었고, Kent Beck이 유명한 Extreme Programming Explained를 내놓은 것은 1997년의 일이다.) 신속하게 개발주기를 반복한다든가, 알려진 상태를 유지하는 것, 고객과의 관계의 강조 등에서 그러한 것들을 엿볼 수 있다. Scrum과 같은 방법론은 1993년에 적용되기 시작했고, Iterative and Incremental Development: A Brief History와 같은 문서를 보면, 1980년대에 이미 점진적인 개발 방법이 소프트웨어 개발계에 떠들썩하게 떠오르고 있음을 할 수 있다.

설령 책이 제시하는 세부적인 방법들에 동의를 하지 않는다고 하더라도 한번이라도 팀에서 소프트웨어 개발을 해본 경험이 있다면, 지난 날의 경험을 회상하며 이 책의 조언에 대해 깊히 생각해보는 것은 매우 유익한 일일 것이다. 다만, 저자는 인문학적인 배경이 있는지 몰라도 문학이나 철학에 기원한 개념들을 자주 빌려쓰고 있을 뿐만 아니라 전체적인 문체도 간명한 편은 아니어서, 읽기가 쉽지 않은 면이 있다. 단지 번역의 탓만은 아닌 듯 보인다. 반대로 이러한 점 때문에, 한문장 한문장을 곱씹어볼 경우 여러가지 경우에 여러 의미로 다가올 수도 있을 것이고, 비단 저자의 조언을 곧이곧대로 받아들이기보다는 풍부한 고민의 원천이 될 수 있는 면도 있을 것이다.

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해, by Robert L. Glass

Robert Glass의 이 책은 내가 읽은 소프트웨어 엔지니어링에 관한 문헌들에서 자주 인용되기에 꼭 한번 읽어봐야지 하고 생각하고 있던 책이다.

제목 그대로 이 책은 소프트웨어 엔지니어링에 관한 사실들과 오해들을 열거하고, 각각에 관한 논쟁과 저자의 의견들을 정리해놓은 책이다. 각각의 항목들은 다른 유명한 저작들에서 언급된 내용이 많아서 ‘집대성’의 느낌이 든다. 이 책의 가장 큰 목적은 저자가 서론에 언급한대로 ‘기본적이면서도 중요’한 사실들인데도 ‘자주 잊혀지’는 사실들을 사람들이 ‘반복해서 배우게’하는 것일 것이다. 한편으로는 사실들의 원저작에 해당하는 개개의 저작들을 읽을 때와는 다르게, 여러 사실들과 논쟁을 한곳에 정리해놓음으로써, 소프트웨어 엔지니어링에 대한 생각을 정리하고 관점을 만들어낼 수 있도록 도와준다.

대부분의 사실들은 말그대로 ‘사실’로 통용되는 것들이지만, 몇몇은 아직 논쟁거리인 경우도 있고, 개인적으로 동의하고 싶지 않거나 또는 그동안 믿지 않았던 것들도 있었다. 사실 이러한 점들을 읽는 도중에 메모를 해서 정리했어야 하는데, 그러지 못한 것이 후회된다. 하지만, 이 책은 한번 더 읽어볼 기회가 있을 듯하고, 그 때는 반드시 그에 관한 글을 따로 써야겠다.

저자가 채택한 사실에서 몇가지 경향을 찾아본다면, 다음과 같다.

• 사람이 중요하고 도구와 기술은 그보다 중요하지 않다.
• 어떤 문제에서든 은탄환은 없다.
• 소프트웨어 개발 프로세스의 초기 단계들(요구사항, 설계)은 중요하다.
• 소프트웨어 개발 프로세스의 몇몇 단계들은(테스팅, 검토, 유지보수)은 대단히 중요하지만 과소평가되고 있다.
• 대규모 또는 범용적인 재사용은 어렵다.

저자는 소프트웨어 엔지니어링 학계에서 널리 받아들여지고 있는 사실들은 단정적으로 받아들이고 있으며, 소프트웨어 엔지니어링에 있어서의 최근의 변화에 대해서는 어느 정도 긍정적인 점들은 인정하기는 하나 약간 망설이는 느낌이 든다. 한마디로 말해 보수적이다. 어떻게 보면, 학계가 바라보는 현재의 소프트웨어 엔지니어링에 대한 시점이 이 책에 그대로 반영되어있다는 느낌이 든다. (이를테면, 학계에서도 인정이 되고 있는 패턴에 대해서는 항목을 하나 할애해서 재사용에 대한 해법 중 하나로 인정하고 있다. 반면 오픈소스나 XP에 대해서는 약간 방어적이다.)

하지만, 그러한 태도가 이 책의 단점이라기보다는 장점이라고 생각한다. 소프트웨어 엔지니어로서 우리는 새로운 기술, 도구, 프랙티스가 우월하므로 도입해야만 한다는 강박관념에 항상 시달려왔다.  우린 오히려 좀 더 신중해야할 필요가 있다.

이 책을 읽으면서 자꾸만 내가 겪었던 현실들이 떠오르면서 나 또는 다른 사람들이 기본적이면서도 중요한 사실들을 얼마나 자주 잊고 있는가를 되돌아보게 되었다. 저자에게 동의하지 않을 수 없는 것은 이러한 사실들은 정말로 반복해서 배우는 수밖에 없을 것이라는 점이다.