다시 읽는 클린 코드
재택근무가 다시 시작되고 동시에 한 달 남짓 유지하던 점심시간 책 읽기는 무산되어 버렸다. 핑계를 대자면 마침 읽고 있던 책을 끝내기도 했고, 좁은 공간에서 하루 종일 있다 보니 점심시간까지는 아무래도 집중을 하기 어려웠다. 그래서 책은 과감히 접고 식전 요가로 피보팅을 했다. 다행히 시작하고 주말을 포함해서 하루도 빠짐없이 꾸준히 하고 있다. 어느 정도 습관으로 자리를 잡은 것 같아 남는 시간(물론 퇴근 이후다. 점심시간에 밥 먹기도 빠듯하다.)에 다시 책 읽기를 시작해보자 싶어 책장에 있는 책을 집어 들었다. 그게 바로 우리의 밥 아저씨 엉클밥(로버트 C. 마틴)의 클린 코드다.
산지는 오래됐지만 매번 중간에 멈춰서 끝까지 읽어 본 적이 없다. 이참에 완독을 다짐하면서 다시 책을 폈다. 비슷한 대부분의 책이 그렇듯 1장은 책의 주제인 클린 코드란 무엇인지에 대해 먼저 이야기한다. 같은 질문에 대한 거장들의 답변과 함께 작가가 생각하는 클린 코드의 정의를 내린다. (1장에선 읽기 쉬운 코드의 중요성에 대해서만 언급하지만 책에는 더 많은 내용이 담겨 있다.)
프로그래머 수만큼이나 정의도 다양하리라는 작가의 말처럼 답이 없는 문제이긴 하지만 실제로 코드를 만들어 내는 개개인은 나름대로의 답을 가지고 있어야 하지 않을까 생각한다. 원칙과 기준이 있어야 일관성이 생기고 없으면 문제가 생겨도 무엇이 문제인지 알기도 어렵고 고치기도 힘들기 때문이다.
내가 생각하는 클린 코드를 정의하자면 바로 "추측(또는 예상) 가능한 코드" 다. 언젠가 일을 하다가 아하! 모먼트를 경험하면서 머릿속에 떠올렸던 내용이다. 조금 더 풀어 보면 "(난생처음 보는 코드라면 어느 정도 시간이 소요가 되긴 하겠지만) 코드를 읽어 가면서 했던 예상대로 동작하고, 짐작했던 곳에 코드가 위치해 있고, 전체적인 기능의 크기를 떠나 각 부분들은 오해의 여지없이 명확한 코드"라고 할 수 있을 것 같다. (글로 옮긴 건 처음이라 아직 정확하진 않은 것 같다.)
일을 하면서도 리뷰를 많이 하지만 요즘 별도로 코드 리뷰어를 하면서 코드를 읽는 시간이 이전보다 많아졌다. 사실 일을 할 때는 익숙한 내용이고 합이 어느 정도 맞춰진 상태에서 작성되는 코드이기 때문에 가끔씩을 제외하고는 적당한 노력으로 쉽게 읽을 수 있는 편이지만, 리뷰어를 할 때는 얘기가 조금 달라진다. 10명의 수강생들이 같은 기능에 대해 각자 다 다른 방식과 스타일로 코드를 작성한다. 아무리 짧은 코드라도 리뷰를 계속하다 보면 잘 짜인 코드와 그렇지 않은 코드의 차이를 몸소 체감하게 된다. 심지어 프로젝트가 규모가 커지고 리뷰할 내용이 많아지다 보면 잘 짜인 코드를 보고 고마움이 느껴지는 순간도 있다. 물론 그 반대의 상황도 있다. (코드의 품질을 측정하는 유일한 척도가 분당 내지르는 WFT! 의 횟수라던가...)
사실 코드를 읽는 난이도는 상대적이다. 아무리 잘 짜인 코드라도 읽는 사람이 그만한 지식이 없다면 쉽게 읽히지 않는다. 내 경험으로 예를 들자면, 신입사원 교육 시절 리눅스 커널 코드를 분석하면서 자괴감에 머리를 쥐어짰던 적이 한두 번이 아니다.(심지어 나온 지 얼마 안 된 안드로이드 커널이라 최적화가 그나마 덜 돼서 보기 쉬운 편이라고 했다.) 구글 작품인 데다 분석을 하고 나면 자연스레 다들 감탄을 했으니 분명 잘못 짜인 코드는 아닌 게 분명하다. 내가 읽을 능력이 부족했던 거다. 물론 지금도... 여하튼 그래서 언젠가 들었던, 코드의 품질은 팀의 평균 역량에 맞춰진다는 얘기에 동의하는 바이기도 하다.
좋은 코드가 무엇인가에 정의를 내렸다면 이젠 '어떻게'의 시간이다. 책의 나머지는 이 '어떻게'에 대한 내용을 담고 있다. 관련해서는 많이 읽어보고 접해본 내용들이기도 하고 방법론들도 많이 나와있기도 하다. 책에도 나오지만 아마 가장 기본적이면서 유명한 것 중 하나가 'SOLID'원칙일 것 같다. 개인적으로 그중에서도 가장 기본적이고 중요한 건 O(Open-Closed Principle)가 아닐까 한다. 이런 내용들은 책을 다 읽고 난 후에 다시 한번 정리를 해보는 기회가 있을 것 같다.
항상 좋은 코드를 짜려고 노력하지만 그에 비해 노력은 부족하지 않나 생각하기도 한다. 누군가 내 코드를 보고 'FTW'을 외치고 있진 않을까 걱정도 살짝 되면서, 이제부터라도 조금 더 노력을 해봐야겠다는 생각이 든다.
끝으로 책에 언급된 내용 중에 나와 가장 비슷한 듯 한 워드 커닝햄과 개인적으로 맘에 들었던 마이클 페더스가 말하는 클린 코드의 정의를 남겨본다. (대가들이라 그런가 정리도 역시 깔끔하다. 계속 보다 보면 표현만 다르지 결과적으로는 다 같은 내용을 의미하지 않을까 하는 생각도 든다.)
"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다."
- 워드 커닝햄 -
"깨끗한 코드의 특징은 많지만 그중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다 보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜 놓은 작품에 감사를 느낀다."
- 마이클 페더스 -