기술 중심의 개발자가 아니라, 문제 중심의 개발자

세상에는 많은 불편함이 있다. 이러한 불편함을 해결하기 위해 기술이 등장한다.

불편함이 있으면 이를 해결하는 기술을 찾아 불편함을 해소하면 된다.

우리는 기술 중심의 개발자가 아니라 문제 중심의 개발자가 되어야한다.

기술은 불편함이라는 문제를 해결하기 위해 이를 찾아 사용해야하지, 기술 자체가 목적이 되어서는 안된다.

선배 개발자들이 이야기한 말들이 이제서야 이해가 간다.

"왜 기술이 등장했는지 알아야 한다." "기술의 사용 방법뿐 아니라, 기술의 작동 원리도 알아야 한다."

계속해서 불편함은 여전할 것이고, 이러한 불편함을 해결하기 위해 기술이 끊임없이 등장할 것이기 때문이다.

예를 들어 Node.js가 있음에도 Deno와 Bun같은 JavaScript 런타임이 등장했다. Node.js의 성능, 보안 등의 문제를 해결하기 위해 등장한 JavaScript 런타임이다. 새로운 런타임 소식이 들려오며 '나도 이런 신기술을 익혀야 하는 거 아니야?'라는 불안감이 엄습해오곤 한다. 당시 Deno와 Bun을 설치해 사용해 봤다. TS를 따로 트랜스파일하지 않아도 되는 점, 빠르다는 점 등의 장점은 있었지만 '굳이?'라는 생각이 들었다. 여전히 Node.js가 JavaScript 런타임 생태계의 대부분을 차지하고 있고, 22버전부터는 Node.js도 타입 표기를 걷어내고 TS 파일을 바로 실행할 수 있게 됐다.

새로운 기술은 계속해서 등장할 것이다. 그리고 언젠가 Node.js도 다른 기술에 의해 대체되는 날이 올 것이다. 그럼에도 근본은 바뀌지 않을 것이다. 기존에는 node 파일명을 입력했다면, Deno가 Node.js를 대체한다면 deno 파일명을 입력하게 될 것이다. 기존에는 eslint로 린트 체크와 prettier로 포맷팅을 했다면, 언젠가는 biome 하나로 린트 체크와 포맷팅을 모두 하게 될 것이다. 사용하는 기술만 바뀐 것이지 문제를 해결하는 방식이나, 해결하고자 하는 문제 같은 근본이 바뀌지는 않았다.

이렇게 계속해서 기술이 변화하는 지금, 내가 집중해야 할 것은 무엇일까?

1. 지금 내게 필요한 기술

   기술은 문제를 해결하기 위해 등장했음을 잊지 말자.

   지금 우리 회사에서 사용하고 있는 기술은 무엇인가, 혹은 내가 들어갈 회사에서 사용하고 있는 기술은 무엇인가를 파악하고, 이에 집중하자.

2. 기본적인 사용법, 그리고 작동 원리

   명령어를 일일이 외울 필요가 없다. 어차피 명령어는 계속해서 변화하기 때문이다. 한 곳에 기록해두는 것으로 만족하자.

3. 근본

   기술이 아무리 변화해도 근본은 변화하지 않는다. jQuery에서 React로 웹 프레임워크 패러다임이 바뀌었을 때, JavaScript라는 언어는 변화하지 않았다. HTML, CSS 또한 변화하지 않았다. HTTP 프로토콜, REST 방식의 통신은 변하지 않았다. 그리고 앞으로도 바뀌지 않을 것이다.

앞으로도 기술이 아니라, 문제에 집중하는 개발자가 되자.

새로운 기술의 등장에 흔들리는 개발자가 아니라, 근본적인 문제에 집중하는 개발자가 되자.