익숙한 기술이 좋은 기술일까?

기술을 고를 때 이미 써본 쪽에 마음이 가는 건 자연스럽다. 어디부터 손대야 하는지 알고, 오류가 나면 확인할 곳도 대충 안다. 처음부터 문서를 뒤지는 것보다 빨리 시작할 수 있다.

그런데 그때 느끼는 편리함을 어디까지 기술의 장점이라고 말할 수 있을까. 같은 도구를 써도 처음 접하는 사람과 몇 년 써본 사람이 느끼는 난이도는 다르다. 내가 금방 끝낸 작업을 다른 사람도 금방 끝낼 수 있을지는 별개의 문제다.

익숙해지면 불편한 것도 잘 안 보인다

설정이 간단하다고 생각했는데, 늘 쓰던 설정 파일을 복사하고 있었을 수 있다. 오류를 보자마자 한 줄 고쳐서 해결했는데, 그 한 줄을 처음 알아내는 데는 며칠이 걸렸을 수도 있다.

해결 방법을 알고 있으면 매번 겪는 문제도 별로 불편하지 않다. 그러다 보면 기술을 설명할 때 그 과정을 빼먹는다. 나는 설치하고 바로 시작했다고 생각하지만, 처음 쓰는 사람에게는 문서에 없는 설정부터 찾아야 하는 일일 수 있다.

그 경험도 실력이고, 만들어둔 설정도 자산이다. 다만 내가 쓰는 환경에는 도구 자체와 그 위에 쌓아둔 경험이 함께 들어 있다. 누군가에게 기술을 추천할 때는 이 부분을 설명할 필요가 있다.

익숙하지 않은 기술에서 막혔을 때도 원인을 구분하기는 어렵다. 필요한 개념을 아직 모르는 것일 수도 있고, 내가 하려는 일이 그 도구가 쉽게 다루는 범위 밖에 있을 수도 있다. 처음 설치해서 화면 하나 띄워본 경험만으로 판단하기에는 모르는 부분이 많다.

익숙함도 선택의 근거가 된다

마감이 있는 작업에서 익숙한 기술을 고르는 건 충분히 합리적이다. 구현 시간을 어느 정도 예상할 수 있고, 문제가 생겼을 때 어디를 볼지도 안다. 새로운 기술을 배우는 동안 생길 시행착오를 줄일 수 있다.

“이 기술이면 내가 기한 안에 만들 수 있다”는 꽤 구체적인 판단이다. 내 경험과 작업 범위, 일정이 근거에 들어 있다. 여기서 조건을 빼고 “이 기술이 생산성이 좋다”고 말하면 주장하는 범위가 훨씬 넓어진다.

혼자 만드는 작업과 여러 사람이 유지보수할 작업에서도 익숙함의 값은 달라진다.

한 사람이 빠르게 구현할 수 있어도, 수정할 때마다 그 사람에게 물어봐야 한다면 다른 사람의 작업 시간은 늘어난다. 배포가 실패했을 때 어디를 봐야 하는지, 환경 변수가 어디에 있는지까지 한 사람만 알고 있다면 그 사람이 자리를 비운 날에는 작은 수정도 멈출 수 있다.

반대로 팀이 이미 충분히 다뤄본 기술이라면 그 경험을 계속 쓰는 이점이 크다. 새 기술의 기능 몇 가지가 좋아 보여도, 배우고 옮기고 운영 방식을 바꾸는 시간을 함께 계산하면 선택이 달라질 수 있다.

처음 만드는 속도만으로는 알 수 없는 것

새 기술을 살펴볼 때는 간단한 화면을 만들어보는 경우가 많다. 시작하는 경험을 확인하기에는 좋지만, 이후에 코드를 고치는 경험까지 보여주지는 않는다.

비교할 기회가 있다면 같은 작은 기능을 만들고, 거기에 변경 하나를 더 넣어보고 싶다. 예를 들어 목록 화면을 만든 뒤 필터를 추가하고, 잘못된 검색 조건을 넣었을 때 서버의 오류가 화면까지 전달되게 해보는 것이다.

그 과정에서 어느 파일을 열었고, 무엇을 찾아봤고, 기존 코드를 얼마나 바꿨는지 보면 처음 실행할 때보다 구체적으로 얘기할 수 있다. 시작하는 설정이 편한지와 요구사항이 바뀌었을 때 고치기 편한지도 따로 볼 수 있다.

배우는 것이 목적일 때는 또 다른 선택을 할 수 있다. 익숙하지 않아 시간이 더 걸려도 감수할 만하다. 이번에 빨리 끝낼 것인지, 다음 작업에서 쓸 수 있는 선택지를 늘릴 것인지에 따라 판단이 달라진다.

“익숙해서 골랐다”는 이유를 굳이 숨길 필요는 없다고 생각한다. 그 덕분에 실제로 일을 끝낼 수 있다면 중요한 장점이다. 다만 내가 추천하는 것이 도구의 어떤 특성인지, 그 도구를 다뤄본 내 경험인지 정도는 구분해서 말하고 싶다.