길벗 출판사에서 나온 비슷한 디자인의 책이 몇 권 있다. IT 교양서로 분류된 책 중에서 어두운 표지색을 내려오는 세로 제목 사이에 아이콘이 끼워져 있는데, ‘소프트웨어 장인’, ‘소프트 스킬’, ‘커리어 스킬’ 세 권이 있다. 우연히도 세 권을 다 읽어봤는데, 이 시리즈 (?) 에서 한 권 더 추가된 ‘심플 소프트웨어’ 를 최근에 도서관에서 빌려보게 되었다.
앞선 세 권과 비슷하게, 이 책 역시 작가의 블로그 내용을 엮어 낸 것이다. (https://www.codesimplicity.com/)
하지만 책에서만 소개되는 챕터가 존재하고, 챕터 간에 흐름이 끊기거나 하지 않고 나름 긴밀히 엮여있기 때문에 단순한 번역본으로 보기엔 무리가 있다. 한 챕터의 내용이 길지 않기 때문에, 가볍게 끊어 읽기에도 좋다. (무엇보다 다른 책들에 비해 책이 얇다. 아주 큰 차이점이다!)
이왕 할 거면, 잘 하려고 노력하자.
책 뒷면에 보면 ‘할 거면 잘 해라!’ 라고 적혀있다. 나는 처음에 이 뒷면을 보고, 자뭇 도발적이라고 생각했다. 하지만 읽다 보니, ‘못 하면 안 돼!’ 라는 뜻이 아니었다. 이왕 개발자를 할 거라면 잘 하고 싶은 마음으로 책을 펼쳤으면 하는 저자의 바람이라고 이해해주면 좋겠다.
단순한 개발을 해야 하는 이유
모든 챕터의 시작은 바로 ‘단순함’ 에서 출발한다. 단순해지면, 아래 목표들을 이루기가 수월하다는 것이다.
- 테스팅이 쉽다.
- 버그가 적다.
- 기능 추가를 해도 코드 품질이 크게 떨어지지 않는다.
- (다른) 개발자가 이해하기 쉽다.
- 보안이 향상된다.
먼저, 이해하고 공부하기
저자는 먼저, 개발자는 자신이 뭘 개발하는지 완벽히 이해하려고 노력해야 한다고 한다. 그동안 만나왔던 개발자의 10% ~ 20% 만이, 무엇을 개발하고 있는지 이해하고 있었다고 한다. 만약 무엇을 개발하고 있는지, 내가 보는 코드에 있는 개념이나 기법, 단어 중 어느 하나라도 모르고 있다면, 내가 참고하고 있는 설계에서 모르는 것이 하나라도 있다면, 무조건 그 부분을 이해하고 개발을 계속하라고 조언한다.
이해가 잘 안되면, 공부를 해야 한다. 더 자세한 설명을 해 주는 매뉴얼이나 참고서를 보거나, 프로그래밍 언어를 다시 배워야 할 수도 있다. 다른 사람에게 물어봐야 할 수도 있다. 이해가 되지 않았는데 일을 하는 것은 일종의 헛일이 될 수 있다고, 저자는 몇 번이고 지적한다. 당장은 문제가 해결될 지 몰라도, 결국 유지보수와 설계 변경으로 인한 비용을 몇 배나 지불하고 나서야 잘못됐다는 것을 깨닫는다고 말이다.
생산성 향상을 조직에 불어넣기
리펙터링이나 생산성 향상을 위한 도구나 기법 도입은, 심플 소프트웨어를 지향하기 위한 수단이므로 항상 염두에 둬야 하는 부분이다. 하지만 현실은 씁슬하게도, 다른 개발자나 상사에 의해 반려되는 아이디어이기도 하다. “다 좋은 거 알지, 그런데 제품 출시부터 먼저 해야 하지 않을까?”
맞는 말이다. 그래서 저자가 남긴 조언은 다음과 같다.
- 개발자가 생각하는 진짜 문제를 확인해라. 혼자 생각하거나, 다른 사람이 지적한 생산성 관련 문제를 가지고 가지 마라. 개발자가 짜증난다고 생각한 부분이 어디인지 파악해라.
- 암달의 법칙을 적용해서, 가장 쉽게 할 수 있으면서 효과가 가장 좋은 문제를 먼저 해결하라. 그러면 개발자의 신뢰를 얻을 수 있고, 보다 큰 리펙터링 업무를 지지해 줄 우군을 만들 수 있다.
- 이 계획을 막는 사람이 소수 남아있을 수 있다. 하지만 대부분은 업무를 효율적으로 처리하고 싶어하므로, 다수의 의견이 될 수 있다. 그렇다고 소수를 맹목적으로 비난하면 안 된다. 항상 친절하게 대하되, 회유하거나 협상하거나, 아니면 무시해라.
단순한 개발을 위한 것: 리펙터링
리펙터링으로 돌아가면, 기능 추가를 하기 전에 리펙터링을 먼저 해두라고 조언한다. 그래야지만, 기능 추가에 따르는 코드 품질 저하를 막을 수 있다는 것이다.
전적으로 동의한다. 내 생각을 덧붙이자면, 나는 이 과정이 기능을 추가하기 전에 코드를 이해하는 과정이라고 생각한다. (앞서 말했던 ‘이해하고 공부하기’ 와 연결된다.) 비유를 섞자면, 일종의 집안일이다. 귀찮지만, 그리고 티는 별로 안나지만, 꼭 해야 하는 일. 하지 않으면 삶이 팍팍해지고, 치우지 않은 것들이 장애물이나 위협이 되지만, 하고 나면 효율적으로 삶을 영위할 수 있는 그런 일 말이다.
물론 저자는 무분별한 리펙터링을 경계한다. 집에 불이 났는데 정원을 가꾸는 꼴이란다. 리펙터링은 항상 기능 중심에서 이뤄져야 한다. 그리고 리펙터링은 해도 해도 끝이 없기 때문에, 한계를 정해두라고 한다. 어느 정도 해야 다른 사람들이 알아볼 수 있을지를 생각한다면, 그 쯤 했을 때 그만 둘 수 있을 것이다.
사용자는 문제를 알려주고, 개발자는 문제를 해결한다.
나는 이 책의 초입에 ‘설계 2원칙’ 이라고 말한 것 보다, 이 1원칙만 고수해야 한다고 생각한다. (참고로 설계 2원칙이란 것은 별게 없고, 개발 비용이 크더라도 유지보수 비용이 훨씬 크게 줄어들면 반드시 해야 한다는 것과, 유지보수 비용과 코드 복잡성은 비례한다는 것이었다.)
아마 저자가 (간접적이나마) 가장 많이 언급한 개념이 이것이 아닐까 한다. 사용자가 제기한 문제만 효율적으로 풀어도, 훌륭한 개발자이다. 개발자가 문제를 만들어 알아서 해결하려 들면, 그것은 개발자의 오만이고, 코드 복잡성을 비정상적으로 증가시키는 요인이 된다.
위에서 ‘리펙터링’ 이야기를 할 때, 개발자가 겪는 진짜 문제를 수집하란 말을 했었다. 이 경우에는 ‘개발자’ 가 사용자가 된다.
마지막으로
이 외에도 ‘테스트할 때 고려해야 할 것’ 이나 ‘오픈 소스 프로젝트를 성공적으로 이끌었던 경험담’ 등을 같이 공유하고 있으니, 쉽게 읽히는 책이니만큼 다른 개발자 분들에게 추천하고픈 책이다.
마지막으로 언급하고픈 챕터가 하나 있는데, 내용은 짧지만 메시지는 강력하다. 하지만 개발에 국한된 내용은 아니어서 짧게 소개하고자 한다.
성공은 혁신이 아니라 실행에서 온다.
이 제목을 보자마자, ‘생활의 달인’ 에서 어떤 맛집 사장님이 음식을 준비하는 과정이 전파를 탄 기억이 어렴풋이 났다. 새벽 5시에 일어나 몇 시간 동안 갖가지 재료들로 음식을 준비고 있노라면, PD 가 ‘이런거 다 보여주셔도 돼요?’ 라고 묻는데, 사장님이 자신만만한 미소를 지으시던 것 같다. 마치 ‘할 수 있으면 해보시던가’ 같은 느낌.
아무리 좋은 아이디어라도 실행하지 않으면 쓸모가 없다. 이론가는 이론가일 뿐이고, 발명가는 발명가일 뿐이다라고 저자는 말한다. 전혀 다른 각도로 큰 교훈을 얻은 것 같아서, 이 책이 큰 도움이 되었다.