회복 탄력성 높은 프론트엔드 아키텍처 — 모니카 렌트, GOTO 2019
직장 동료가 공유해 준 영상. 회복 탄력성이 높은 프론트엔드 아키텍처에 관해 설명한다. 내용이 깔끔해서 정리해 공유한다.
불가피한 코드 재작성
업무를 하면서 코드 재작성이나 마이그레이션은 불가피한 일이다. 처음 프로젝트를 착수할 때는 마냥 재밌기만 하지만 시간이 지나면 기술 부채가 쌓여가고 리팩터링을 하게 된다. 하지만 어찌 된 일인지 기술 부채는 불어나기만 한다.
모두들 그린필드 프로젝트(Greenfield project, 처음부터 새로 시작하는 프로젝트)때는 신이 나서 달린다. 그러나 시간이 흐르고, 더 이상 달리기가 불가능할 때 쯤 슬슬 리팩터링 욕구가 고개를 든다. 나는 분명 기술 부채를 없애려고 시작한 리팩터링인데 시간이 지나니 이전보다 배로 부채가 늘어난다. 이럴거면 왜 코드를 다시 쓰는걸까? 시스템이 변경에 민첩하게 대응하게 만들려면 어떻게 해야 할까?
그렇다면 ‘좋은’ 아키텍처란 무엇인가?
알긴 아는데, 이미 정의가 너무 많다. 그러면 회사의 아키텍처에 대해 잘 알고 있는지 스스로에게 질문해 보자. 자신있게 대답하는 사람이 의외로 별로 없다. 레거시 코드뿐만 아니라 내가 새로 작성하는 코드 한 줄 한 줄이 아키텍처를 결정하는 행위이다. 매일의 업무가 아키텍처에 기여하는 행위이다. 이미 완성되어 있는 코드 디렉터리 만이 아키텍처가 아니다.
제한을 줄 수 있는 아키텍처
그렇기 때문에 좋은 아키텍처란 ‘제한을 줄 수 있는’ 아키텍처여야 한다. 아우토반은 왜 사고가 적을까? 제약이 많기 때문이다. 안전과 빠른 속도는 많은 제약 사항 위에서 보장된다.
이처럼 프로그래밍 기법을 제약으로 생각하여 그것을 기반으로 무언가 얻는다고 생각하자. OOP는 컴포넌트를 개별적으로 배포가능하게 도와준다. 함수형 패러다임은 경합 조건(race condition)과 동시성 문제를 예방한다. var 대신 const를 사용하면 데이터를 예측할 수 있고, jQuery 대신에 React를 사용하면 UI의 변경을 예측할 수 있다. CSS 대신 CSS-in-JS를 사용하면 전역 스타일링 충돌을 예방할 수 있다.
사람들에게 많이 알려진, 구글에서 흔히 나오는 아키텍처가 내 프로젝트에 꼭 맞는다는 보장은 없다. 다른 프로그래밍 언어 패러다임도 유연하게 받아들이는 자세가 필요하다.
프로젝트에 적용하기
프로젝트에 적용할 쉽게 적용할 수 있는 세 가지 제약사항을 소개하며 마친다.
- 첫째는 소스 코드 의존성이 내부로 향해야 한다. 그러면 변경 사항의 영향을 최소화 할 수 있다.
- 두 번째로 소스 코드 재사용은 보수적으로 결정할 필요가 있다. 재사용만이 능사가 아니라 때로는 컴포넌트를 복사 후 붙여 넣기 하여 따로 분리하는 게 나을 수도 있다.
- 마지막으로 경계를 확실히 구분 짓는 일이다. 각 모듈이 불러올 수 있는 의존성에 제약을 걸면 리팩터링이 잘못되는 것을 방지할 수 있다. (예: dependency-cruiser)
