부제 : 기술 스택 선정 시 고려해야 할 기술의 발전 사이클과 자기 능력 평가
내가 프로그래밍 일을 하면서 갖게 된 몇 가지 경험적 지식이 있다. 오늘은 그 중 하나인 "힙스택 보존 법칙"을 설명해보려 한다. 명제는 간단하다.
힙스택을 3개 이상 고르면, 프로젝트는 산으로 간다.
꽤나 공감이 가는 문장일 거라 생각한다. 특히 주니어 시절 전혀 모르는 기술의 늪에 빠져 토끼굴을 파본 경험이 있다면 말이다. 그렇다면 왜 그런 것일까?
프로젝트의 생애
프로젝트는 탄생한다. 마치 갓난쟁이가 세상을 향해 울음을 터뜨리듯, 새로운 세계를 향해 발을 내딛는다.
이 시점에 프로젝트는 "알려져 있지 않다", 다시 말해 호환성을 확보한, 검증된 프로젝트가 아니다.
예시를 들어보겠다. Svelte(자체 템플릿 언어를 사용하는 웹 프레임워크) 같은 신규 프레임워크가 등장한다면, 기존 린터 도구나 포매터 도구와 처음엔 호환되지 않을 것이다. 어쩌면 사용하고 싶은 프로그래밍 언어가 Svelte 템플릿 언어 내부로 통합되지 않을 수도 있다.
ESLint(자바스크립트 생태계 사실상 표준 린터)같은 힙하지 않은 기술이라면 누군가가 호환 레이어나 플러그인을 만들었을 수 있다. 하지만 Biome(자바스크립트 생태계 신흥 린터 겸 포매터)같은 힙한 기술을 덧붙인다면? 어쩌면 호환성 확보를 위해 당신이 직접 코드를 작성해 연동해줘야 할 수도 있다.
우리는 이러한 호환 레이어 내지는 플러그인 이 충분히 많은 프로젝트를 가리켜 커뮤니티가 크다, 또는 성숙하다 고 부른다.
프로그래밍은 결국 두 퍼즐 조각을 끼워맞춰 연결하는 행위를 포함한다. 서로 다른 생각을 가진 프로그래머가 만든 퍼즐 조각이라면, 그 사이를 연결한 새로운 퍼즐 조각이 필요할 가능성이 높다.
그걸 전부 만드는 야크 털 깎기를 반복하다보면 사람은 지친다. 결국, 프로젝트를 산으로 보내버릴 가능성이 높아지는 셈이다.
힙스택을 쓰려는 자, 그 무게를 견뎌라
그렇다면 힙스택을 3개 이상 고르고도 프로젝트가 제 항로를 벗어나지 않았다면, 왜 괜찮았던 걸까?
크게 두 가지 경우로 나눠 생각해볼 수 있겠다.
- 충분히 힙하지 않았다. 다시 말해, 성숙한 기술이다. (기술의 안정화)
- 힙함을 견딜 수 있었다. 다시 말해, 호환 레이어 를 작성할 능력이 된다. (능력의 성장)
위에선 3개 이상이라고 이야기했지만, 능력에 따라 4개, 5개도 괜찮은 사람이 있을지도 모른다.
다른 사람에겐 힙한 기술이, 그에겐 힙하지 않은 기술이 되어버리는 걸지도 모른다.
마치 백독불침, 천독불침, 만독불침의 기인이 되어가듯이.
하지만 그러한 기인이 되기 위해선 약한 독부터 차례로 내성을 길러야 한다.
우리는 그 과정을 학습 이라고 부르기로 했다.
왕관을 쓰려는 자, 그 무게를 견뎌야 하듯, 힙스택을 쓰려는 자. 그 학습의, 충돌의 무게를 견뎌라.
