툴을 쫓는 사람들 (원제: Chasing Tools)

Tim Kadlec의 글 Chasing Tools를 번역한 글입니다.

직업 프로그래머로서 참여했던 나의 첫 번째 프로젝트는 레거시 코드로 가득한, 꽤 큰 규모의 웹사이트였다. 레거시 코드는 많은 문제를 유발한다. 이 프로젝트에서 가장 기억에 남는 일은 웹사이트에 무려 세 가지의 다른 자바스크립트 프레임워크가 공존하고 있었다는 사실이다!

개발자들은 과로에 시달렸고, 사이트에게 필요한 리빌드를 진행하기엔 예산이 부족했다. 물론 처음에 사용되었던 프레임웍을 계속해서 유지해올 수도 있었겠지만, 문제는 새로운 프레임웍이 등장할 때마다 기존에 사용해오던 프레임웍은 개발 전선의 뒤편으로 밀려났고, 활발했던 커뮤니티마저도 시들해져 버리곤 했던 것이다.

사실 그 프로젝트는 다행히도 잘 마무리되었다. 다른 모든 프레임웍들은 제거하고 jQuery만을 사용하기로 한 것이다 (이 얼마나 대단한 퍼포먼스 향상인가!). jQuery는 우리가 사용했던 다른 프레임웍들과 달리 새로운 프레임웍의 등장으로 인해 잊혀지지 않았고, 오히려 그 생태계는 시간이 갈수록 성장하고 번성했다.

물론 그저 순수한 자바스크립트를 사용했더라면 이런 문제들이 애당초 없지 않았겠냐는 비판을 해보고 싶은 마음도 없는 건 아니다.

그런데 그런 비판이 공정하게 느껴지진 않는다. 그렇지 않은가? 이런 툴들이 아무런 이유도 없이 제작된 건 아니니 말이다. 툴이 존재하는 건 누군가 그것이 어떤 상황에서 분명 도움이 될 것으로 생각했기 때문이다. 그래서 그들은 툴을 만들고 공유했다. 솔직히, 그것 자체는 정말 멋진 일이다.

최근 어떤 글이 과도하게 복잡해져 버린 근래의 자바스크립트 환경을 농담조로 비난한 것에 대해 일부의 개발자들이 불편함을 표현한 것 역시 그 순수한 의도가 공격받았기 때문일 것이다. 그 글은 분명 재미를 위해 쓰였겠지만 (난 웃었다), 누군가는 이것을 오픈소스 생태계와 그것에 공헌하는 사람들을 비판하는 것으로 받아들일 수 있었으리라 생각한다.

분명 그 글의 의도가 그런 부정적인 것은 아니었을 것이다. 중요한 것은 이 사안이 오픈소스 생태계가 가진 문제가 아니라는 것이다. 넘쳐나도록 다양한 선택지가 있다는 것은 정말 좋은 일이다. 선택사항이 부족한 것보다는 많은 것이 좋다. 문제는 새로운 툴이 나올 때마다 그것을 쫓아온 우리의 대응 방식이며, 더 심각한 문제는 우리가 이런 기술들을 가르치고 있는 방식에 있다.

소프트웨어 산업은 툴을 사랑하고 거기엔 이유가 있다. 툴은 우리의 생산성 증대를 도와준다. 툴은 프로젝트에 있어서 필수적인 단순한 작업들의 자동화를 돕는다. 툴은 난해한 브라우저 호환성 문제의 해결을 돕는다. 툴은 우리가 더 중요하고 흥미로운 문제들에 집중할 수 있도록 돕는다. 툴은 대체적으로 ‘좋은 것’이다.

하지만 안타깝게도 툴을 향한 우리의 애정은, 계속해서 새로운 툴이 출시되기를 기다리는 건강하지 못한 집착으로 이어졌다.

빌드 스크립트들의 사례는 꽤나 재미있다. Grunt는 등장과 함께 프론트엔드 개발 커뮤니티에서 체계적인 개발 프로세스를 정립하는 것에 대한 심도 있는 논의를 불러일으켰다. 그런데 개발자들이 Grunt 사용을 익숙하게 받아들이기 시작할 즈음, 얼리 어답터들은 이미 새로운 빌드 스크립트인 Gulp를 찬양하기 시작했다. 많은 개발자들이 Gulp로 갈아타는 동안, 일부 개발자들은 새롭게 등장한 또 다른 빌드 스크립트 Broccoli로 갈아타기 시작했다. 그것은 마치 새로운 대안을 사용하는 것에 익숙해지기도 전에 또 다른 대안이 계속해서 등장하는 것만 같았다.

물론 진화는 대체로 이로운 것이다. 우리는 우리가 알고 있는 것을 토대로 발전하는 것을 지속해야 한다. 그리고 각각의 빌드 툴은 나름의 차별성을 가지고 있으므로, 사람들은 자신의 워크플로우에 더 적합한 툴을 선택해 사용할 것이다. 하지만 문제는 우리가 정작 해결되어야 할 문제에 대한 고민보다 오히려 새로운 것을 쫓는 것에만 몰두해 있다는 것이다.

어떤 이유로 이런 기류가 형성되었는지는 모르겠지만, 우리가 자바스크립트와 웹 기술 전반을 교육하는 방식에는 분명 문제가 있다.

만약 당신이 어떤 문제를 해결하기 위해 순수 자바스크립트에 대한 자료를 구하고자 시도해본다면 내가 하고자 하는 말을 이해할 수 있을 것이다. 문제 해결을 논할 때 특정 툴을 끼워 넣지 않은 글이나 강좌를 찾기란 쉽지 않다. jQuery가 주목받기 시작하던 시절 자주 지적되었던 문제점은 너무 많은 글들이 jQuery의 사용을 당연시한다는 것이었다. 같은 맥락에서 CSS만 가지고도 충분히 시연할 수 있는 것을 굳이 Sass를 사용하는 사례 역시 흔하다. 이 글 초반부에 언급했던 최근 자바스크립트 환경을 비판한 글을 읽어보면, 단순한 질문에도 ‘당신은 React를 배워야 할 것 같네요’ 라고 대답하는 가상의 캐릭터가 등장한다. 다소 인위적일 수는 있지만 내용 자체는 낯설지 않은 이야기다.

새로운 툴이 등장할 때마다 증가하는 개발 환경의 복잡도 만큼이나, 교육 과정에서 언급되는 툴의 개수가 증가함에 따라 학습 환경 역시도 점점 복잡해지고 있다. 이 글을 통해 말하고자 하는 논점도 바로 이 부분이다. 개발 환경에 결함이 있다는 것이 아니고, 다양한 선택권이 나쁜 것이라고 말하는 것도 아니다. 다만 누군가 어떤 문제에 대한 답을 구하고자 할 때, 그들이 얻는 답변 중 다수가 ‘이 툴을 설치하시고요, 이렇게 셋업부터 하세요’ 로 시작되는 현실에 관한 이야기다.

도움이 될 수 있는 새로운 툴을 가르치는 것은 좋은 일이다. 하지만 우리가 주의해야 할 것은 그 툴이 도움이 될 수 있는 이유뿐 아니라 도움이 되지 않을 수도 있는 이유 역시도 고려해야 한다는 점이다. 우리는 근본적인 문제와 특정 툴이 성급히 연관되지 않도록 분리하는 것에 좀 더 신경 써야 한다. 사람들이 기본적인 것부터 배울 수 있도록 도와야 한다. 그러고 나면 그들이 스스로 필요한 툴에 대한 결정을 내릴 수 있게 될 것이다.

전에도 언급한 적이 있지만, 개발자로써 배울 수 있는 가장 가치 있는 기술은 Node.js나 React, Angular, Gulp 또는 Babel 따위가 아니다. 당신이 시간을 들여 배워야 할 가장 가치있는 것들은 오히려 네트워크, HTML, CSS, 그리고 자바스크립트와 같은 웹의 핵심 기술들이다. 웹의 핵심에 대한 이해는 당신이 툴에 대한 결정을 내릴 수 있는 기반이 되어줄 것이다.

툴은 적합한 상황에서 유용하게 사용될 수 있지만, 그것을 판단하기 위해선 상황에 대한 이해가 선행되어야 한다. 해결해야 할 사안을 발견했을 때, 그것의 기저에 깔린 문제의 본질에 대해 생각해 봐야 한다. 문제를 확실히 파악하고 난 후에야 툴의 사용 유무와 어떤 툴을 사용할 것인지를 결정할 수 있다.

툴을 선택함에 있어서 고려해야 할 몇 가지 사항들이 있다. 다음은 내가 주로 생각해 보는 것들이다:

  1. 사용하려는 툴을 통해 어떤 사람들이 어떤 도움을 얻는가? 분명 누군가 도움을 얻기 때문에 이 툴이 존재할 것이다. 그렇지 않은가? 만약 이 질문에 대한 답을 찾기 어렵다면, 아마도 그 툴은 사용에 적합한 것이 아닐 가능성이 높다.
  2. 사용하려는 툴이 발생시키는 손해는 어떤 것인가? 얻는 것이 있으면 항상 잃는 것도 있기 마련이다. 누군가는 해당 툴의 사용으로 인한 손해를 보게 된다. 그것은 개발 환경에 더해지는 복잡함일 수도 있고, 최악의 경우 사용자가 그 대가를 치러야 할 수도 있다. 사용으로 인한 손해를 파악해야 그것으로부터 얻는 이득과의 비교를 통해 합리적 결정을 내릴 수 있다.
  3. 문제 발생 시에는 어떻게 되는가? 나는 이 질문을 Clearleft의 글로부터 인용해 왔는데, 이런 방식의 사고가 아주 맘에 든다. 뭔가 잘못되면 어떤 일이 발생하는가? 좋든 싫든 우리의 웹 환경은 불안하다. 어느 시점에서인가, 반드시 문제는 발생하기 마련이다.
  4. 해당 툴이 그것의 토대가 되는 기술을 지원하는가? 만약 그것이 프레임웍이나 라이브러리라면, 그것의 기반 기술을 의미 있는 방식으로 강화하는가? jQuery가 이에 관한 좋은 사례가 될 수 있을 것 같다. jQuery는 DOM을 컨트롤하기 위한 훨씬 편리한 방식이었고, 나아가 그것이 자바스크립트를 사용하는 방식과 지향점에 대해서도 영향을 미쳤다.

이 외에도 다른 질문들이 있겠지만 (커뮤니티가 얼마나 활발한가, 공헌자는 많이 있는가 등), 이 정도면 현재 본인의 개발 환경에 새로운 툴을 추가해야 하는지에 대한 질문의 시작점으로써는 충분하다고 본다.

그리고 그 질문에 대한 답은 대부분의 경우 ‘아니오’일 것이다. 다시 말해 당신의 개발자 친구들이 지난주에 출시된 새로운 코드 에디터로, 새롭게 공개된 프레임웍을 사용해본 것에 대해 신나게 이야기할 때, 그저 고개를 끄덕이며 나는 둘 다 접해보지 못했다고 말할 수 있어야 한다. 그것은 전혀 부끄러운 일이 아니다. 따분한 기술은 강력한 힘을 갖고 있다. 따분한 건 좋은 것이다.

아직까지 Vim을 사용하는 개발자를 옆에서 구경해본 적 있는가? 정말 끝내준다! 어떤 사람들은 아직도 그들이 Vim을 사용하는 이유가 종료하는 법을 배우지 못해서라고 농담을 하기도 하지만, 내 생각엔 그들이 Vim에 완전히 꽂혔기 때문인 것 같다. 다른 이들은 이 툴 저 툴 옮겨 다니는 동안, 그들은 이 ‘따분한’ 툴을 계속해서 사용하며 마스터 해왔고, 시간이 갈수록 점점 더 효율적으로 사용할 수 있게 되었다.

웹을 만드는 우리는 행운아들이다. 누구든 스스로 도움이 되리라 생각하는 일에 공헌할 수 있고, 실제로 많은 사람이 그렇게 하기 때문이다. 우리는 다른 이들이 공유하는 작업과 지식을 통해 끊임없이 새로운 것을 얻는다. 그것은 분명 격려받아 마땅한 일이지만, 그렇다고 해서 우리가 항상 최신 기술에 매달려야 할 필요는 없다. 이에 관한 Addy의 조언이 아주 적절하다:

“…기본을 정확히 세우라. 천천히 유익한 툴에 익숙해지고, 그것을 사용하며 지속적으로 효과적인 상태를 유지하라.”

핵심에서 시작하고 관심을 더 해가자. 무너지지 않는 단단한 웹 개발 방식과, 배움을 위해서도 말이다.

이 글은 Tim Kadlec의 글 Chasing Tools를 번역한 글입니다.