[Review] 토스에서 말하는 "가독성 좋은 코드" 란 무엇일까?

 

Introduction

최근 토스 테크 블로그에, 토스 프론트엔드 팀에서 나눈 "코드 가독성" 에 대한 이야기가 공유되어 한번 살펴보게 되었다. 간단하게 기억에 남는 이야기들을 정리하고, 개인적인 생각을 덧붙여 보고자 한다.

 

https://toss.tech/article/firesidechat_frontend_1

모닥불 | EP.1 토스에서 말하는 “가독성 좋은 코드” 란 무엇일까?

 

---

코드 퀄리티, 꼭 챙겨야 할까?

• 어떤 사람들은 개발이란 단순히 비즈니스를 위한 수단이라 주장. 코드 퀄리티를 챙기는 것이 중요한가?
• 코드는 컴퓨터뿐만 아니라 협업하는 동료들을 위한 것. 그렇기에 코드 퀄리티를 챙길 필요성이 있다.

 

망한 코드 퀄리티로 인해 손해를 본 경험

• 무해해 보이는 함수를 호출했는데, 전혀 예상 못 한 식으로 이상하게 동작하는 경우 (사이드 이펙트)
• 코드 리뷰에서 잘 쳐냄으로써, 몇 시간씩 허무하게 사용한 디버깅 시간을 아낄 수 있었다면 더 많은 일을 할 수 있었지 않을까? 하는 생각을 함.
• 코드 영역마다 코드 퀄리티가 들쭉날쭉 하는 경우가 많았다. 관리가 잘 되는 부분도 있고, 그렇지 않은 부분이 혼재함.

 

좋은 코드 퀄리티 덕분에 행복해진 경험

• 1. 당장 재사용하지 않더라도 재사용이 가능한 요소를 설계하고자 하는 자세가 도움이 되었음.
  • 도메인 로직을 없애고 사이드 이펙트를 최대한 없앤다는 의의가 있음.
  • 믿고 쓸수 있는 요소를 만듦으로써 디버그 스코프에서 제외할 수 있었다.
• 2. 잘 짜여있는 코드베이스를 탐색할 때 이해가 훨씬 빨랐던 경험이 있었음.
  • 규칙이 명확하고, 읽는 사람이 기대한 것과 동일하게 작동하는 코드베이스.
  • 실제로 코드를 이해하는 데에 쓰이는 시간이 많이 절감되었다.

 

코드 가독성이란?

• 린터나 포매터로 관리할 수 있는 코드 퀄리티도 있고, 코드 아키텍쳐와 같은 큰 단위의 퀄리티도 있을 것.
• 가독성에는 개인적으로 크게 두 가지 요소가 있는 것 같다.
• 눈이 편한것 - 일관성을 지켜 산만해지지 않는 코드 (심미적 요소) / 코드의 정돈성
• 머리가 편한것 - 역할과 책임이 잘 나뉘어져 있고, 동작을 코드만 보고 이해 가능한 아키텍쳐적 관점에서의 가독성
• 주니어 때는 지엽적인 부분을 많이 리뷰했음.
• 연차가 찰 수록 이런 지엽적인 코드 스멜은 린터에 위임하고, 더 깊은 맥락이 필요한 리뷰를 많이 했던 것 같음.

 

코드 가독성을 위해 실천 중인 액션들

• 코드 스멜이 나는 코드를 가져와서, 두명씩 페어로 왜 문제인지 토론 -> 추상적인 룰을 도출하고, 이를 실제 코드에 적용해 보는 경험이 도움이 되었다.
• 다루는 코드의 스케일에 따라 다른 규모의 코드 퀄리티를 마주하게 될 것 (고려해야 할 요소가 많이 달라진다).
• 같은 문제를 풀 때, 더 쉬운 사고의 흐름을 보여줄 순 없을까? 하는 고민을 하는 것이 도움이 되었다.
• 복잡한 구현은 나중에 스스로도 이해 못 하며, 남들이 읽을 때에도 더욱 더 많은 시간이 들 것이다. 따라서 항상 더 쉽게 문제를 풀 수 있는 방법에 대해 고민하면 좋을 것.
• 코드는 추상화된 자신의 생각이며, 다른 사람은 이것을 맥락 정보 없이 보고 이해를 해야 한다. 최대한 맥락 정보를 코드에 녹여서 간단하게 표현해야 한다,
• 회사에서는 비즈니스 가치를 내는 코드를 짜야 한다. 따라서 촉박한 시간 하에 코드를 작성하느라 퀄리티를 많이 신경쓰지 못 하는 경우가 많을 수 있다. 하지만 시간에 쫒겨 더러운 코드를 만드는 것이 아니라, 빠른 시간 안에도 좋은 코드를 만들어낼 수 있는 능력을 체화시킬 수 있도록 노력해야 할 것.

 

코드 퀄리티를 챙기는 타이밍

• 코드 퀄리티를 높이기 위해선 리팩터링을, 가령 일주일씩 해야 하는 경우도 있을 수 있다. 이런 경우엔 타 팀에 어떻게 양해를 구할 수 있을까?
• 사실 PO나 디자이너 입장에서는 리팩터링에 시간을 쓰겠다고 하면 어? 뭐지? 할 수 있다. 항상 본인의 코드 퀄리티를 야금야금 지켜나가는 것이 중요한 것 같다. 애초에 코드 퀄리티나 가독성을 일정 수준에서 유지할 수 있도록 일정 산정 및 커뮤니케이션을 하는 것이 중요하다고 생각.
• 주니어들이 많이 하는 실수가 있는데, 빨리 해냄으로써 좋은 평가를 받을 것이라 기대하는 경우이다. 당연히 일주일 걸리는 걸 3일만에 끝내면 아키텍쳐나 코드 퀄리티 측면에서 완성도가 떨어지가 쉽다. 버그 가능성이나 변경 가능성이 빠르게 끝냄으로써 더욱 커질 수 있다. 3일만에 했어도 추가 유지보수 비용이 지속적으로 붙는 결과를 낳는다. 억지로 작업 시간을 줄이려 하지 말자.
• 차라리 현실적으로 코드 작성 기간을 산정하고, 기간 내에 적절한 수준의 코드 퀄리티를 유지할 수 있도록 노력하는 것이 더욱 중요할 것이다.
• 숙련되면서 코드 작성 시간은 점점 처음보다 줄어들 것이고, 장기적으로는 더욱 신뢰받을 수 있다.

 

코드 퀄리티를 챙기기 위한 팁

• 코드 퀄리티의 중요성을 아직 잘 파악하지 못 하는 경우엔 적절한 리팩터링 시점을 파악하기 어려울 수 있음.
• 이런 경우엔 코드 작성에 명시적인 규칙을 정함으로써 어느 정도의 퀄리티 유지 및 퀄리티 수준을 파악하는 게 가능하다. 규칙으로써 퀄리티를 유지하고, 얼마나 많은 규칙이 위반되고 있는지로 코드베이스의 퀄리티 문제를 파악할 수 있다.
• 좋은 코드를 짜기 위해서는 좋은 코드를 많이 봐야 한다. You write what you read
• 좋은 코드를 많이 볼 수록 좋은 코드를 짤 수 있으며, 모범적인 프로젝트들을 살펴보고 내 코드를 돌아보는 것이 좋다.
• 오픈소스 기능과 비슷한 기능을 짜야하는 경우에, 오픈소스 베스트 케이스들의 인터페이스를 참고하는 것이 많은 도움이 되었다.
• 보통은 디버그 해야 하거나 니즈가 있을 때 오픈소스 프로젝트를 살펴보게 되는데, 다른 사람들은 어떻게 짰을까? 궁금해하게 되면서 이런 오픈소스 코드를 많이 보게 되는 것 같다.

 

---

개인적인 생각

사실 버그 없이 잘 작동하고 있는 코드가 이후에 변경될 일이 거의 없다면 (유지보수 할 일이 거의 없다면) 당장의 코드 퀄리티 수준이나 그것을 개선하는 작업은 의미가 없을 수 있다. 하지만 그렇다고 장담할 수 있는 코드가 얼마나 있을까?

결국 코드 퀄리티는 비용 효율성의 측면에서 바라봐야 한다. 코드 퀄리티를 유지한다는 것은 지금 비용을 투입해 이후의 (나 혹은 타인이 진행할) 유지보수 작업에 들 비용을 낮추겠다는 의미이다. 이 비용이란 것은 가까이서 보면 디버그나 코드 이해에 드는 시간, 즉 개발자가 들여야 하는 시간을 의미하며, 멀리서 보면 회사가 지불하는 실제 비용을 의미할 수 있다.

따라서 코드 퀄리티를 좋게 유지함으로써 이후 발생할 유지보수 비용을 절감함으로써 같은 시간, 금액 대비 더 많은 가치를 창출할 수도 있을 것이고, 혹은 코드 퀄리티를 유지하고자 들인 시간이 그 만큼의 유지보수 비용을 절감을 가져오지 못 할 수도 있다. 다만 경험적으로는 코드 퀄리티를 더욱 오랜 시간동안 방치하는 경우 그것을 바로잡는 데에 더 많은 비용을 유발한다고 생각한다. 또한 코드 퀄리티를 좋은 수준으로 유지하는 역량은, 한번 체득해 놓으면 이후에 작성된 코드의 품질에도 꾸준히 영향을 미치게 된다.

결국 영상에서 이야기한 것 처럼 평소에 본인의 코드 퀄리티를 자주 점검해 보고, 더 쉽게 구현할 방법을 찾는다던지, 좋은 오픈소스 프로젝트 소스를 많이 참고한다던지, 더 나은 혹은 더 이해하기 쉬운 코드가 어떤 것일지에 대해 틈틈히 고민해 보는 것이 장기적으로는 개인의 성과 및 비즈니스 가치 측면에서 더욱 좋을 것이라 생각한다.