Picasso's Bull 추상의 과정.

클린코드란?

대체적으로 명확한 변수 이름, 중복 줄이기를 뜻한다. 실무에서는 여기에서 더 나아가 섬세한 코드를 정리하는 스킬이 필요하다. 프론트엔드에서 읽기 좋은 코드를 작성하기 위해서 염두해야 하는 개념들과 실제 액션 아이템들을 토스 컨퍼런스 SLASH 21을 참고해서 정리해보겠다.

실무에서 클린 코드의 의의

실무에서 주로 하는 말 중에 "그 코드는 안 건드리시는 게 좋을 거에요. 제가 만지겠습니다!" 라는 말을 들어봤을 수 있다.

이 말은 즉슨 작업하려는 코드가 지뢰 코드라는 것을 의미한다. 지뢰 코드란 흐름 파악이 어렵고, 도메인 맥락 표현이 안 되어 동료에게 물어봐야 알 수 있는 코드를 뜻한다. 이런 코드들은 개발을 진행할 때 병목 현상을 일으키고, 유지보수할때 시간이 오래 걸리며 심각하면 기능 추가가 불가능한 상황이 된다. 또한 성능도 좋지 않은 경우가 많기에, 유저 입장에서도 쾌적하지 못한 경험을 제공한다.

이러한 점들을 바탕으로 실무에서 클린 코드의 의의는 유지보수 시간의 단축을 뜻한다. 동료, 혹은 과거의 내가 짠 코드를 바로 이해할 수 있다면 유지보수에 들어가는 개발 시간이 줄어든다. 또한 읽기 좋은 코드는 코드 리뷰의 시간도 줄여주며, 버그가 났을 때 디버깅 시간도 단축시켜준다. 예를 들어 고치는데 하루 걸리는 코드와 3일 걸리는 코드가 있다면, 후자는 개발자가 3배 더 필요하다. 아니면 직접 3배 더 일해야 하는 경우가 발생한다.

대부분 회사에서 일한다면 클린한 상태에서 코드를 짜는 것이 아니라, 기존 코드에서 기능을 추가한다던지, 버그를 고치는 일을 하게될텐데, 이러한 경우에 코드가 클린하지 못해서 개발 시간이 늘어나는 것은 곧 돈이 그만큼 나간다는 것을 의미한다.

안일한 코드 추가의 함정

기존에 클린하고 잘 작동하는 코드가 있다고 생각하자. 회사는 이 부분에 버튼 클릭 시에 팝업 기능을 요청했다. 이 기능을 A라고 해보자. 클린 코드에 무지하던 나는 함수가 늘어나고 코드가 늘어나는 것이 오히려 불편할 거라고 생각해서, 기존에 한 가지의 일만 하는 함수에 몇 가지 일을 같이 할 수 있게끔 코드를 작성했다. 이 과정에서 서순이 조금 꼬여서 A를 위한 코드를 위에 작성하고 이 후에 A와 관련되지 않은 코드가 진행된 후에 다시 A에 관련된 코드를 작성했다. 코드 전체적인 길이는 전과 비교했을 때 크게 늘어나지 않아서 만족했다.

하지만 과연 이 코드가 잘 짜여진 코드라고 할 수 있을까?

아니다. 지금 작성된 코드는 위 아래로 흩뿌려져 있으며, 기존에 한 가지 일을 하던 함수에 여러가지 일을 하게끔 만들었다. 개발자 동료 B가 와서 이 부분을 수정해야 한다고 가정한다면, B는 이 함수가 무슨 일을 하는 함수인지 쉽게 파악하지 못할 것이다. 그리고 이 정도가 심각하다면 B는 기능 추가를 할 수 없을 것이고, 결국 나를 부르지 않으면 해결하지 못할 것이다. 유지 보수 혹은 기능 개발의 시간이 늘어나고 이러한 현상은 곧 손해로 이어진다.

그렇다면 나는 어떻게 코드를 작성해야 했을까?

원하는 로직을 빠르게 찾고 병목 현상을 줄이기 위해 코드를 작성한다면, 세 가지 개념을 확실하게 알고 가는 것이 중요하다.

1. 응집도

하나의 목적을 가진 코드가 한 군데에 모여있는 것을 의미한다. 최대한 스크롤을 움직이지 않고, 파일을 넘나들지 않도록 코드를 짜는 것이 중요하다. 리액트에서 커스텀 훅을 이용해서 같은 목적을 지닌 코드를 한 공간에 뭉쳐놓을 수 있는데, 좋은 접근이다. 하지만 함정이 하나 있다. 코드를 이해하는데 필요한 핵심 정보까지 다 넘겨버려서 오히려 코드 파악이 어려워질 수가 있다.

그렇다면 무엇을 뭉치고 무엇을 보여줘야 할까?

우선 뭉치고 다른 공간에 넣어놔도 되는 것은 당장 몰라도 되는 디테일한 부분이다. 중요한 것은 코드 파악에 핵심적인 정보는 숨긴 공간이 아닌 바깥에서 넘기는 것이다. 쉽게 생각하면 내가 아닌 다른 개발자가 봤을 때 "이 코드는 이런 패턴으로 동작을 하겠구나, 디테일한 동작은 커스텀 훅 안에 넣어놨군. 저 부분을 수정하러 온 것은 아니니, 내가 작성해야할 코드는 여기에 작성하면 되겠네." 라는 느낌이 들 수 있게끔 해야한다. 코드의 맥락이 일관성이 있어야 한다는 말이기도 하다.

이것을 일컫는 용어가 있는데 바로 '선언적 프로그래밍' 이다.

특징은 '무엇'을 하는 함수인지 빠르게 이해가 가능하다는 것과 세부 구현을 신경쓰지 않고 '무엇'만 바꿔서 함수를 재사용할 수 있다는 것이다. 이에 반대되는 것이 바로 '명령형 프로그래밍' 이다. 당연하게도 선언형 프로그래밍이 최신 트랜드다. 그렇다면 명령형 프로그래밍은 사용하지 않아야 할까? 토스 컨퍼런스 SLASH 21에서는 굳이 하나를 고집해서 쓰기보다는 두 가지 방법을 유동적으로 섞어서 사용해도 된다고 한다. 나도 이 생각에 동의한다. 개발자라는 직업은 유연한 사고를 바탕으로 소통이 중요한 직업이라고 생각한다. 트랜드라고 다 따라가지 말고 나름의 장점을 발휘할 수 있는 부분에는 유연하게 섞어보자.

2. 단일책임

하나의 함수는 하나의 일을 하는 것이 좋다. 하나의 함수가 여러가지 일을 동시에 처리하면 코드를 읽는 것이 어려워진다. handlePopUp 이라는 이름을 가진 함수가 있다면 팝업을 다루는 단 한 가지의 일을 하는 것이 유지 보수할 때도 훨씬 편리하고 빠르다. 이름을 다룬김에 함수명을 짓는 것도 짚고 가면 좋을 것 같다. 이벤트 핸들러 함수를 작성한다고 할 때, 함수안에 적힌 코드 중에서 중요한 내용들은 되도록 전부 함수 이름에 포함시켜주는 것이 좋다. 함수명이 너무 길어진다면 한글로 작성하는 것을 팀 회의 때 말해보자. 안되면 말고 되면 좋은 것 아니겠나!

그래도 단일책임에 있어서 가장 중요한 것은 하나의 함수가 한 가지의 일을 하는 것이라고 생각한다. 당연한 이야기지만 많은 사람들이 지키지 못하는 부분이라고 생각한다. 나같은 경우도 개인적인 작업을 할 때는 한 가지 일만 하는 함수를 만들고 후에 좋은 아이디어를 떠올려서 기능을 추가하는 일이 있으면, 코드가 길어지는 것이 싫어서 함수 하나에 여러 기능을 넣곤 했는데, 글을 작성하면서 많이 반성하게 된다. 중요한 것은 클린 코드는 짧은 코드가 아니다 라는 것이다. 코드 좀 길어져도 맥락과 일관성 있는 코드를 작성하는 것이 더 중요하다.

클린 코드는 짧은 코드가 아니다.
항상 기억해두자.

3. 추상화

추상화는 응집도 파트에서 다뤘던 내용 중 선언적 프로그래밍과도 연관이 있다. 선언적 프로그래밍이 무엇인가? 코드의 흐름을 읽기 위해 그리고 세부 구현은 몰라도 '무엇'만 변경해주면 쉽게 재사용이 가능하게 만들자는 하나의 패러다임이다. 여기서 추상화와 연관이 있는 것은 세부 구현을 숨긴 부분이다. 우리는 필요에 따라서 많이 숨기거나, 적당히 숨기거나, 조금 숨기는 방법을 택해서 코드를 작성할 수 있다. 필요에 따라 작성한 코드니 모두 타당한 방법이다. 정말 중요한 것은 코드의 흐름이 일관성이 있는가이고 이 코드의 흐름을 읽는 데 필요한 정보가 잘 표현이 되어있는가이다.

우리가 원하는 만큼 코드를 추상화 시킬 수 있다. 스스로가 타당한 이유를 바탕으로 추상화를 해보고 만약 팀원이 맥락을 읽기 불편하다는 코드 리뷰를 받았다면, 필요한 정보들을 추상화된 코드에서 끄집어내서 표현해주면 된다. 개인적인 작업물일 땐 마음껏 해도 좋으나 협업을 하는 입장에서는 그래도 한번쯤은 너무 많이 추상적으로 작성하지 않았는지 확인해보는 것도 나쁘지는 않다.

그런데 딱 한 가지를 짚고 넘어가면, 높은 추상화와 중간 추상화 그리고 낮은 추상화된 코드들이 뒤섞여있으면 코드 파악이 어려워진다는 것을 유의하자. 추상화를 진행했다면 항상 비슷한 레벨의 추상화 코드로 짤수 있도록 노력해보자.

액션 아이템

액션 아이템은 당장 우리가 내일부터 개발을 하면서 가져갈 수 있는 마음가짐이다. 클린 코드를 작성하기 위해서 필요한 마음가짐이라고 생각이 되어 그대로 작성을 해보겠다.

1. 담대하게 기존 코드 수정하기.
구조 뜯기를 두려워하면 클린한 실무 코드를 유지할 수 없다. 그렇게 되면 기존 코드는 건드리지 않고 기능 '추가'만 하게 되기 쉬운데 겁먹지 말고 크게 한입 먹어보자. 도전을 두려워하면 성장도 멈춘다고 누가 그랬던 것 같다.

2. 큰 그림을 보는 연습.
처음에 코드를 작성할 때는 참 깨끗한 파일에서 시작을 할 수 있다. 그때 작성했던 코드는 맞지만 지금은 틀리다. 이 말은 기능 추가는 클린하지만, 전체적으로 어지러울 수 있다는 말이다. 안일하게 기능을 추가하기 보다는 앞으로도 사용될 코드라는 생각을 가지고 크게 보자. 적어도 그 코드는 안 건드리시는게 좋을거에요 라는 말은 하지 않도록 해야한다!

3. 팀과 함께 공감대 형성하기.
코드에 정답은 없다. 동료 개발자가 작성한 방식도 정답이 아니고 내가 작성한 방식도 정답은 아니다. 하지만 분명히 소통을 하면 더 나은 코드를 작성할 수 있다. 과감하게 질문하고 고치고 싶은 포인트를 팀원들과 얘기해보면 더 좋은 코드, 클린 코드에 가까워 질 수 있을 것이다. 이 부분은 개발자라면 늘 염두해두자.

4. 문서로 작성해보기.
코드로 작성하고 땡 해버리면 잊혀지기 십상이다. 항상 내가 작성한 코드는 readme에 작성을 해두던지 개인적으로 작성을 하던지 해서 기록을 하자. 이러한 액션은 큰 그림을 보는 연습이기도 하다. 오늘 내가 해야할 일은 무엇이고 어떠한 부분에 어떠한 코드를 작성했으며 추상화의 레벨은 어느정도이며 왜 이런식으로 작성을 했고, 향후에 이 부분에서 문제가 생긴다면 어떤 문제가 생길수도 있을 것 같고, 그런 문제가 생긴다면 어떻게 개선을 할 것인지를 미리 작성해보자.

개발 능력중 문서를 읽는 것은 더하기고 직접 만들어보는 것은 곱하기며 만들어본 것을 기록하는 습관은 제곱이라고 생각한다. 이번에 클린 코드에 관련된 내용을 정리해보면서 내가 작성한 코드들도 다시 보게되는 계기가 되었다. 컨퍼런스 마지막에 발표자께서 아름다운 사람이 머문 자리는 아름답다는 말을 하셨는데, 나는 지금껏 드러운 사람이 아니었을까? 라는 생각도 좀 든다. 아름다운 자리를 남기는 개발자가 되도록 꾸준히 노력하자.

유튜브 토스 SLASH | 21 진유림님 컨퍼런스 발표 영상

이 글을 읽는다면 이 영상도 꼭 보자. 두번 보자. 나는 세번 봤다.