클린 코드, 오해와 진실

2020.01.29.

협업을 위하여

클린 코드에 대한 세번째 글을 마무리하고 있을 때쯤 Dan Abramov(이하 댄)의 블로그에 GoodBye, Clean Code라는 글이 올라왔습니다. 한국어로 잘가, 클린 코드로 번역된 이 글은 한동안 제 페이스북 피드에 오르내렸습니다. 제목을 보며 '이제 내 블로그 글은 이제 어쩌나...' 싶었죠. 클린 코드에 대해 부정적인 입장인 것처럼 보였기 때문입니다. 하지만 자극적인 제목과 달리 실제 내용은 지나치게 한가지 관점에 얽매이지 말라는 내용이었습니다.

Don’t be a clean code zealot. Clean code is not a goal. Let clean code guide you. Then let it go.

댄은 본문에서 클린 코드에 지나치게 몰입한 탓에 재앙을 불러일으켰다고 고백합니다. 그중 하나가 코드를 작성한 사람과 변경에 대해 논의하지 않은 것이라고 말합니다. 협업에서 이처럼 업무를 처리하는 것은 최악이기 때문이며 서로 신뢰가 필요한 엔지니어링 팀에서 이는 안 좋은 영향을 미칠 수밖에 없다고 말합니다. 클린 코드 협업을 방해해선 안 된다는 것이죠.

함께 개발하기 위한 약속

클린 코드는 협업을 위한 도구가 되어야 합니다. 클린 코드는 약속입니다. "코드도 글이니까 쉽게 읽히도록 작성합시다"라고 개발자들 사이에서 암묵적으로 합의한 약속인 겁니다. 다른 말로 하자면 당신이 작성한 코드는 언젠가 다른 사람이 볼 것이기 때문에 최소한의 예의를 지켜달라는 권고이기도 합니다. 다른 사람이 읽고 이해할 수 있도록 해달라는 겁니다. 코드를 그저 프로그램이 동작하게 만드는 명령어의 집합으로만 생각하지 말자는거죠. 컴퓨터만 이해할 수 있게 하지 말고 옆의 동료도 좀 이해할 수 있게 쓰라는 겁니다.

동료를 생각하는 개발자가 되기까지

저도 뱅크샐러드에 입사하기 전에 추상화에 매몰되어 있었습니다. 지금도 추상화하고 함수로 표현하는 것을 좋아하지만 당시에는 더 심했습니다. 다른 사람이 제 코드를 못 읽는 건 수준이 낮아서라고 생각했죠. 지금 생각하면 아찔합니다. 어렵더라도 짧게 적는 게 최고라고 생각했습니다. 오히려 어렵게 짠 코드를 근사하다고 생각했습니다.

개인적으로는 클린 코드를 배우고 옆의 동료를 더 많이 생각하게 됐습니다. 지금 쓰는 이 코드를 다른 사람들이 한눈에 알아볼 수 있을까. 이름을 이렇게 지어도 괜찮을까. 처음 코드를 보는 사람이 이해하기 쉽게 짜려면 어떻게 해야할까. 어떤 배치로 코드를 구성해야 매끄럽게 이해가 될까. 계속 그런 고민을 하며 코드를 작성합니다. 이런 변화에 클린 코드가 지대한 영향을 끼쳤습니다.

얽매이지 않기 위해서 생각해야할 것

클린 코드라는 주제에서 벗어나는 내용이지만 언급하고 글을 맺을까 합니다. 클린 코드건 추상화건 어떤 도구를 처음 배우게되면 계속 그 도구를 사용하고 싶어집니다. 아이에게 망치를 주면 모든 것이 못으로 보이는 것과 같은 원리죠. 망치로 해결되지 않는 문제도 망치로 해결하려고 한다는 겁니다. 개발에서도 마찬가지입니다. 하나의 도구로 모든 것을 해결하려고 해선 안됩니다. 문제를 마주했을 때 이 문제를 해결하는데 내가 배운이 도구가 적합한지를 먼저 따져야합니다. 그 과정을 동료들이 도와줄 수 있다면 정말 좋겠죠. 동료들에게 문제를 공유하고 해결책을 함께 고민해야합니다. 그리고 다시 망치를 들어도 늦지 않습니다.

클린 코드도 도구일 뿐입니다. 많은 분들이 이 도구를 잘 활용해서 성공적인 개발을 할 수 있었으면 좋겠습니다. 감사합니다.