웹 프론트엔드 개발자가 작성하는 코드를 사용하는 집단은 둘이다. 서비스 사용자와 다른 프론트엔드 개발자. 이를 바탕으로 프론트엔드 개발자의 업무 범위를 3가지로 나눌 수 있다.
첫 번째는 서비스 사용자만 쓰는 코드이다. 웹 페이지나 어드민 페이지를 구성하는 코드가 여기에 해당한다. 트리플에선 “서비스 프로젝트"라는 이름으로 불리기도 하며, 작은 단위로 저장소를 나눠서 -web 접미사를 붙여 관리하고 있다.
두 번째는 서비스 사용자와 프론트엔드 개발자 모두 사용하는 코드이다. 여러 페이지에서 공통으로 쓰이는 UI나 비즈니스 로직을 담은 모듈이 여기에 해당한다. 이들 코드는 첫 번째 코드를 작성하는 프론트엔드 개발자가 불러와 사용하고, 완성된 웹 페이지와 상호작용하면서 서비스 사용자도 쓰게 된다. 트리플에선 각 서비스 프로젝트를 별개의 저장소로 관리하고 있기 때문에 공통 모듈을 triple-frontend라는 이름의 모노레포로 관리한다.
세 번째는 프론트엔드 개발자만 사용하는 코드이다. 코드를 정적 분석하는 도구나 CI/CD, 또는 서비스 프로젝트의 보일러플레이트를 생성하는 코드 등이 있다. 트리플에서의 몇가지 예를 들면 eslint-config-triple이나 create-triple-app이 있다. triple-frontend에서 CI/CD를 담당하는 yaml 파일도 이에 해당한다고 볼 수 있다.
서비스 사용자의 코드
웹 페이지를 만드는 것은 프론트엔드 개발자의 가장 기본적인 역량이다. 디자인을 작동하는 페이지로 옮기는 과정에서 기본적인 HTML, CSS가 필요하고, 자바스크립트 지식이 필요하다. 한 번만 쓰고 버리는 페이지가 아니라면 계속 변경해야하기 때문에 유연한 구조를 설계할 수 있어야 한다.
서비스 사용자와 프론트엔드 개발자의 코드
서비스가 많아지면 일일히 새로운 페이지를 만드는 것은 비효율적이다. 작은 단위의 코드를 재사용하여 더 효율적으로 페이지를 만들 수 있다. 이때부터 작성한 코드를 다른 프론트엔드 개발자가 사용하기 때문에 인터페이스에 대한 고민이 필요하다.
공통 모듈을 만들 때에도 기본적인 HTML, CSS, JavaScript 능력이 필요하다. 더불어, 코드의 내용을 읽지 않고도 코드의 역할을 알 수 있는 인터페이스를 설계하는 능력이 필요하다. 이를 위해선 적절한 단계의 추상화와 직관적인 작명 등을 할 수 있어야 한다. 그리고 테스트 코드도 작성해야한다. 여러 프로젝트에서 사용하는 만큼 여러 개발자가 관여하기 때문에 원하는 기능에 대한 테스트를 잘 작성해둬야 새로운 기능을 추가하더라도 기존 기능에 문제가 없을 것이다. 이를 통해 개발자가 매번 모든 케이스를 테스트하지 않아도 된다는 안도감과, 내 마음대로 수정해도 문제가 없다는 자신감을 심어 줄 수 있다.
프론트엔드 개발자의 코드
프론트엔드 개발자의 반복되는 업무를 자동화하여 더 효율적으로 코드를 생산할 수 있다. 자주 나오는 리뷰 내용을 린트 규칙으로 만들고, 커밋 푸시마다 빌드와 테스트를 반복할 수 있도록 자동화하며, 매번 생성해줘야하는 보일러플레이트를 한 번에 만드는 도구를 만들어 프론트엔드 개발자의 업무 환경을 개선할 수 있다. 이를 통해 개발자 개인의 실수를 막을 수 있고, 개발자의 시간과 에너지를 아낄 수 있다. 또한 암묵적인 규칙을 코드로 명확하게 관리할 수 있다.
이를 위해선 자신의 개발 환경을 관찰하는 습관이 필요하다. 자신의 업무 중에서 반복되는 내용은 무엇인지, 그리고 그것을 자동화할 수 있는지 고민하고, 만약 자동화할 수 있다면 늦기 전에 작업해놓는 것이 좋다. 당장 작업할 시간이 없다고 미루면 더 큰 시간을 손해보게 된다.
결론
대부분의 업무에서 프론트엔드 개발자는 서비스 사용자만 신경 쓰게 된다. 좋은 코드를 평가하는 가장 쉬운 기준은 “이 코드가 작동하는가"이기 때문이다. 하지만 프론트엔드 개발자의 생산성을 높이면 새로운 기능을 더 빠르게 서비스 사용자에게 전달할 수 있다. 옆 팀원이 내가 작성한 코드의 “사용자"라는 것을 염두하여 더 나은 코드를 만들자.
