얼마 전 1월 중순 경, 토스의 프론트엔드 챕터에서 프론트엔드 개발자들을 위한 코드 작성 지침서인 Frontend Fundamentals(이하 FF)를 배포하였습니다. 오픈카톡이나 같이 기술 정보를 공유하는 동료들한테 여기 페이지 공유를 수 회 받은 상태로 미루고 미루다가 이번에 문서를 꼼꼼히 읽어보면서 리뷰하는 시간을 가져보려 합니다.
FF는 문서 자체도 양질의 내용을 담고 있을 뿐만이 아니라, Github Repository Discussion에서 활발히 이루어지고 있는 좋은 코드에 대한 토론들도 매우 주목할만 합니다.
FF를 읽어보면서 제 코드에 적용할 수 있는 짧은 체크리스트를 만들어보고, 제가 가지고 있는 생각과 함께 공유하는 글이 될 것 같습니다.
FF에서는 좋은 코드가 무엇인지, 그리고 좋은 코드가 어떤 지표들로 평가될 수 있는지를 정의하고 그 지표들을 긍정적인 방향으로 변화시키기 위한 방법과 지침들을 공유합니다.
양이 압도적으로 많거나 하지 않기 때문에, 시간이 되시는 분은 직접 모두 읽어보시는 것을 추천드립니다. 토스의 프론트엔드 챕터가 어떻게 좋은 코드를 정의하고 논리적으로 구축해나가는지 알 수 있어서 좋은 레퍼런스가 될 것이라 생각합니다.
문서는 아래와 같은 목차를 가지고 있습니다.
문서 목차
좋은 프론트엔드 코드는 변경하기 쉬운 코드예요.
코드가 변경하기 쉬운 지는가독성,예측 가능성,응집도,결합도의 4가지으로 판단할 수 있어요.
- 가독성(Readability)
가독성은 코드의 읽기 쉬운 정도를 말해요.
- 맥락 줄이기
- 같이 실행되지 않는 코드 분리하기
- 구현 상세 추상화하기
- 로직 종류에 따라 합쳐진 함수 쪼개기
- 이름 붙이기
- 복잡한 조건에 이름 붙이기
- 매직 넘버에 이름 붙이기
- 위에서 아래로 읽히게 하기
- 시점 이동 줄이기
- 삼항 연산자 단순하게 하기
- 예측 가능성(Predictability)
예측 가능성은 함께 협업하는 동료들이 함수나 컴포넌트의 동작을 얼마나 예측할 수 있는지를 말해요.
- 이름 겹치지 않게 관리하기
- 같은 종류의 함수는 반환 타입 통일하기
- 숨은 로직 드러내기
- 응집도(Cohesion)
응집도는 수정되어야 할 코드가 항상 같이 수정되는지를 말해요.
- 함께 수정되는 파일을 같은 디렉토리에 두기
- 매직 넘버 없애기
- 폼의 응집도 생각하기
- 결합도(Coupling)
결합도란 코드를 수정했을 때의 영향범위를 말해요.
- 책임을 하나씩 관리하기
- 중복 코드 허용하기
- Props Drilling 지우기
CheckList
가독성
- 토스에서 정의하는 좋은 프론트엔드 코드는 변경하기 쉬운 코드이다.
- 사용자의 권한에 따라 다른 역할을 하는 컴포넌트 등, 분기 처리로 인해 동시에 실행될 수 없는 코드들은 "동시에 실행되지 않는 단위"로 분리하자.
- 개발자의 인지 범위를 고려하여 코드 단위별 맥락의 수를 최소화해야 한다. 컴포넌트가 가진 맥락들의 수준을 동일하게 만들고, 맥락들을 적절하게 분리하기 위해 추상화를 적극적으로 활용하자.
Wrapper패턴이나HOC(High Order Component)패턴 등을 통해 맥락을 추상화 및 분리할 수 있다.
- 로직의 종류에 따라 함수, 훅, 컴포넌트 등을 뭉쳐놓으면 그 대상이 관리하게 될 내부 로직이 무한정 늘어날 수 있다. 이 경우에도 맥락의 수가 다양해져 가독성을 해치게 될 수 있고, 리액트의 렌더링 기능상 성능에 문제가 생길 수 있으니 가급적이면 쪼개서 작성하자.
- 복잡한 로직을 다루거나, 재사용이 필요하거나, 단위 테스트가 필요할 때는 조건식이나 함수에 이름을 붙이고 분리하는 것이 좋다.
- 매직 넘버는 상수로 할당해서 사용하자.
- 코드를 처음 읽는 입장에서 수직 방향의 시점 변화가 얼마나 일어나는지 고려하자.
- 삼항 연산자는 삼항까지만...
예측 가능성
- 같은 이름의 함수는 같은 동작을 하도록 작성해야 한다.
- 같은 종류의 함수는 같은 타입의 반환이 이루어져야 한다.
- 함수의 시그니처에 드러나지 않는 숨은 로직은 분리하거나 시그니처를 수정하자.
응집성
- 디렉토리 구조를 재귀적으로 구성하는 등의 방법을 통해 함께 수정되어야 하는 코드들은 같은 경로 안에 포함되도록 하자.
- 매직 넘버는 상수로 할당해서 사용하자.
- 폼을 다룰 때 재사용성과 독립성을 높혀야 한다면 필드 단위로 관리하는 것이 좋고, 필드간 의존성이 필요하거나 일관된 흐름을 유지해야 한다면 폼 전체 단위로 관리하는 것이 좋다.
결합성
- 로직의 종류에 따라서 코드를 나누는 것이 아니라, 맥락과 책임에 따라서 하나씩 나누어야 한다.
- 중복되는 코드를 허용하자. 요구사항의 다양화에 의해 모듈화가 무색해질 수 있다. 페이지마다 동작이 달라질 여지가 있다면, 공통화 없이 중복 코드를 허용하는 것이 더 좋은 선택이 될 수 있다.
- Composition 패턴과 Context API를 활용하여 Props Drilling을 줄인다.
독후감
문서를 읽으면서 첫 번째로 든 생각은 프론트엔드 도구들이 어느 정도 고착화된 것 같다는 생각입니다.
문서 내의 예제나 대부분의 표현들은 React, react-query, react-hook-form, zod 등 토스에서 사용되고 있을 것으로 예상되는 라이브러리들로 이루어져 있었습니다. 예제들 자체가 라이브러리에 의존성을 가지고 있었어요.
물론 FF에서 제시하는 좋은 코드를 향한 솔루션들은 React 코드에만 해당되는 것은 아닙니다. 예제가 특정 라이브러리들에 의존성을 가지고 있음에도, 저 포함 읽는 사람들이 불편함을 크게 느끼지 않았으리라 생각되는 것은 아무래도 프론트엔드 개발에서 활용되는 도구들이 이제는 어느 정도 통일되고 있기 때문이 아닐까 하는 생각을 해보았습니다. 그리고 과연 토스는 redux가 저물었던 것처럼 메이저 라이브러리가 바뀌게 되면 이 문서의 예제들도 변경하는 보수작업을 지속할 수 있을까요?
두 번째로 든 생각은 좋은 프론트엔드 코드를 위해 잘 체계화된 문서를 이렇게 선뜻 커뮤니티에 공유한다는 점에서, 토스는 좋은 코드를 향한 진입장벽을 낮추는 데 기여하고 있다는 생각입니다.
우리는 오랜 시간 많은 개발자들이 쌓아온 개발 철학 위에서 개발을 해나가고 있습니다. 깔끔한 몇 줄의 코드를 작성하는 데에도 많은 히스토리가 담겨있을 수 있죠. 코드를 직접 작성하는 수준에서는 이런 히스토리들을 반영한 좋은 코드를 작성하기 위해 많은 노력이 필요합니다. 물론 히스토리 안을 모두 파서 전부 이해하고 있을 필요는 없지만, 어떤 관점에서 어떤 특징들이 필요했었는지를 파악하는 것은 필요합니다. 그리고 좋은 지침서는 필요한 관점과 특징들만을 정리하여 깔끔하게 제시합니다. FF는 충분히 좋은 지침서가 되기 위한 조건들을 갖추고 있다고 느껴졌기 때문에, 좋은 프론트엔드 코드를 향한 진입장벽을 낮추는 데 기여할 수 있을 것이라 느껴졌습니다.
