예를 들어 CSS의 utility class based 개발은 프론트 개발자가 DOM 작성이랑 화면 디자인을 같이 하면서부터 각광받기 시작했음.

옛날에는 서버 개발자가 템플릿 엔진으로 DOM을 생성하면 그걸 회사의 요구에 따라 예쁘게 바꿔주는 게 css 개발자였기 때문에, utility class 같은 걸 남발하면 후속조치가 개씹암걸리게 되었음. 근데 이제는 아니잖아?

모노레포도 마찬가지임. 팀 단위로 다루는 프로젝트의 갯수가 늘어나니까 유용한 기술이 된 거지, 그 전에는 당연히 프로젝트별로 다른 저장소를 마련하고 자주 쓰는 기술은 따로 라이브러리를 다운받아 두었음. 그게 Node가 개발의 주 언어를 차지하면서 상황이 달라진거. "라이브러리 소환!"에 드는 코드 비용이 사실상 제로에 가까워졌는데 뭘 못하겠냐

기술이 유명해지는 이유에는 그 기술이 옛날에는 없던 기능을 구현해서도 있지만, 옛날의 기업 환경에 맞게 만들어진 기술들이 시간이 지나면서 새로운 대안이 필요하게 되어서도 있다.

그렇다고 해서 옛날 기술이 뒤처지거나 사라지는 것도 아니고, 각자의 장점을 살려서 더 풍성한 생태계를 만들어낾. RSS는 일반사용자용 기술로써는 사장됐지만 여전히 백단 데이터 교환에서는 유용하게 쓰임. NestJS는 Angular용 템플릿 엔진으로써의 기능은 잃었지만, 대신 튼튼한 객체 구조를 만드는 데에는 좋음.

옛날에는 그 생태계에서 좀 더 범용적인 지위를 차지하고 있던 기술이, 시간이 지나면서 자신만의 특장점을 살려 특화되는 건 어제오늘 일이 아님. redux 같은 상태관리 라이브러리도 그랬고, Bootrstrap/MUI 같은 클라이언트 컴포넌트 프레임워크도 마찬가지임. 그런 면에서 "너 같은 게 도대체 어떻게 지위를 차지한 거니?" 같은 질문은 오만한 걸 넘어 무식한 행위인거임. 포퓰리즘적이기도 하고.

- dc official App