기술은 쓰임새(use case)에 따라 고르고 조합한다
베터코드 인사이트의 시작 11편
요즘IT 기사에서 아래 이미지를 보다가 갸우뚱하며 질문이 생겨났다.
Java 다음이 Ruby가 맞나?
당장 동의가 되지 않았다. 하지만, 글쓴이의 의도를 생각하면 납득할 수 있는 내용이긴 하다.
서로 다른 관점의 공존
위 그림은 프로그래밍 언어 관점에서 기계어를 거의 그대로 쓰던 시절에서 인간 즉, 프로그래머를 위한 번역 계층이 진화되어 가는 모습을 그린 듯하다.[1] 하지만, 컴파일러나 인터프리터와 원본 코드만으로 실행되는 프로그램을 구성하는 일은 너무나 오래된 이야기처럼 들린다. 적어도 상업용 프로그래밍의 세계에서는 그렇다.
클라우드 환경이 보편화된 요즘은 프로그래밍 언어 하나로 프로그램을 작성할 수는 없다. 프로그래밍이란 일 자체가 바뀌었다고 볼 수도 있다. 가상 머신 위의 미들웨어 구성도 프로그램에 영향을 미치며, 화면 구성을 위한 HTML/CSS/JavaScript류의 언어와 백엔드의 언어 그리고 이들 둘 사이의 상호작용을 위한 언어가 별도로 존재하는 경우가 흔하다. 이런 문제로 IDE의 역할이 인터프리터의 역할을 일정 부분 흡수하는 듯도 보이고, Github 같은 협업 도구의 사용이나 Open API 호출 등을 고려하면 저 그림은 대학교 1학년 교재에나 나올 법한 그림처럼 보인다.
저자와 나의 견해 차이를 서로 다른 관점이라고 그대로 두기로 하자. 각자의 시각이 있을 수 있다고 보자. 그러고 나서 다시 문제를 좁혀서 Java보다 Ruby가 진화한 것인가를 자문해보면, 2007년에 나의 견해와 2022년의 나의 견해가 다르다는 점은 흥미롭다.
웹 개발에 최적이던 Ruby였지만...
2007년에 Ruby는 (내 주변 기준으로) 대유행이었다. 나 역시 Ruby에 흥미가 있어서 당시 Ruby 개발자가 발표하는 개발자 행사에 참여했던 일이 있다. 동적 언어의 강점과 Rails가 제공하는 강력한 템플릿은 이른바 CoC(Convention over configuration) 개념의 최종 버전을 보여주는 듯했다. 당시 내가 사용하던 Java에서는 Ruby만큼 편리한 CoC를 만들지는 못했다.
아무튼 당시 기억으로 굉장한 생산성을 제공했다. 그에 비해 Java는 세밀한 데이터 접근과 가공에는 유리했으나 웹 화면 구성에 있어서는 너무 후졌다. 그러나, 2010년 이후 모바일 앱이 유행하고 클라우드 세상이 오자 그렇게 CoC로 만든 코드가 레거시로 된 곳들을 본다. 생산성을 제공했던 관례가 진화하지 못하니 도리어 최근에는 서비스의 발목을 잡는 기술 부채가 된 곳들이 제법 있다.
네트워크 연계와 분산이 자연스러운 클라우드 환경 탓에 과거와 같은 식의 CoC는 더 이상 유효하지 않다. CoC 자체도 분산 환경에 맞춰 진화해야 했다. 여기서 나는 어떤 기술도 사회라는 환경에서 발생하는 쓰임새(use case)를 벗어나면 더 이상 유효하지 않다는 사실을 배울 수 있었다. 이런 결론에 도달하는 데에는 회의에서 동료가 준 인사이트가 큰 역할을 했다.
Java에서 Spring을 대체할 수는 없어요
최근에 회사 동료가 Better Admin 이란 제품(소프트웨어)에서 네트워크 성능 개선을 위해 캐시를 적용하는 과정에서 다음과 같은 기록을 공유했다. 그리고 대면 회의에서 그가 Gin 도입을 결정하기 위해 검증 작업을 해보기 전에는 Spring 경험이 프레임워크에 대한 자신의 인식을 제한했다고 말했다.
Java를 쓰며 Spring을 채용할 때에는 Spring 자체를 대체하는 일을 불가능한 일이라고 여기게 된다. 하지만, Go에서 프레임워크(Go식 표현은 미들웨어)는 그런 존재가 아닌 듯하다.
내 경험으로도 2000년대 초기 Struts 정도는 나도 마음에 들지 않으면 다른 대체품(Sun의 WAF)을 사용해 교체해서 썼다. Spring 등장 이후 Java 생태계 변화에 따른 영향이다.
또한, Java 언어 자체가 새로운 환경에 부적절하다는 지적은 Ruby가 득세할 때도, Scala가 유행할 때도, Kotlin이나 Go가 도전하는 지금도 여전하지만 Spring 없이 Java를 쓰자는 주장은 힘을 얻기 어렵다. 다시 말해 약점이 계속 노출되어 있지만, 그럼에도 Java를 쓰게 만드는 강점은 Spring이 종합 선물세트마냥 묶어서 제공한다.
2022년의 현실에서 Go를 써서 얻는 이점과 Java를 써서 얻는 이점이 명확하게 구분된다. 다시 말해서 Java를 Go와 동일선상에서 비교할 수 있고, 쓰임새에 따라 선택할 수 있다면 진영을 벗어나(혹은 벗어날 수 있는) 기술 생태계를 이해한 소프트웨어 개발자라 할 수 있다.
기술은 쓰임새(use case)에 따라 고르고 조합한다
나는 동료의 설명을 들을 때 깊이 공감하며 과거 한글 MSDN과 비주얼 스튜디오 없이는 개발을 못하던 MS 진영 개발자와 자바 진영 개발자의 차이에 대해 생각했던 내용을 떠올렸다.[2]
맥락이나 사회적 가치에 대해 명확하게 하지 않고 기술 자체를 평가하는 일은 무용하다. 기술은 도구이기 때문에 쓰는 사람의 기호를 탄다. 게다가 기술을 만드는 회사들은 거대 공룡이기도 해서 개발자들을 진영으로 거느린다. 어느 진영에 속하느냐에 따라 세상을 달리 보게 되어 있다.
AI에 대해서도 그렇고 오픈소스로 된 솔루션에 대해서도 결과만 두고 평가하는 이들이 적지 않다. 무려 5년 전에도 오픈소스 대한 미신을 다룬 글을 쓴 적이 있다. 오픈소스를 일종의 협업이나 소프트웨어 개발 방식에 대한 변화로 보지 않고 여전히 솔루션(해결책)으로만 보면 기술을 제대로 활용할 수 없다.
기술은 사회적 맥락속에서의 쓰임새를 중심으로 살펴야 한다.
주석
[1] 주제가 흥미를 느끼지 못해 제대로 읽지 않아서 '듯하다'라고 표현했다. 이 글은 그저 그림이 만든 자극에 반응하여 쓴 글이다.
[2] 최근 경험이 없으니 자연스럽게 개발하던 시절 비슷한 경험을 소환했다.
지난 베터코드 인사이트의 시작 연재
3. Funnel을 마케팅 말고 engagement 분석에?
5. 기술 부채는 무엇인가?
8. loosely-coupled: 빠르게 재구성하는 힘
