Java/Spring 공화국에서 스크립트언어를 주로 다루는 백엔드 엔지니어의 입지는 상대적으로 좁을수밖에 없기에, 한번은 경험해보자는 것도 쿠팡으로 이직한 여러 이유 중에 하나였습니다. 그렇게 1년이 지난 지금, 아주 주관적인 후기를 적어봅니다.
Java를 선택하는데 있어 기술적인 이유는 없었다
적어도 지난 1년동안, 기술적인 관점에서 Java를 사용해야 하는 이유는 없다는걸 알게 됐습니다.
사실 입사 전에도 그럴거라 예상은 하고 있었던 부분이지만, "마 니가 해봤나" 를 상대하기 위해서라도 한번은 해봐야 할 경험이었지요.
많은 사람들이 익숙하고, 그렇게 해왔다는게 가장 큰 이유였습니다.
서버 퍼포먼스 측면에서는 Go / Rust, 데이터를 다루는데 있어서는 관련 생태계가 독보적인 Python, 그게 아니더라도 Kotlin이라는 좋은 대안이 있어 Java만의 장점이라고 할만한건 없었습니다.
Spring 도 마찬가지입니다. Node + express 나 django, rails 같은 프레임워크에 비해 추상화 수준이 더 높지만, 그정도 수준의 추상화가 정말로 필요한 유스케이스는 거의 없었던 것 같습니다. 대부분의 경우 타 프레임워크보다 생산성이 높지 않습니다.
잡마켓 쏠림현상
왜 한국의 IT회사들은 Java/Spring 중심일까? 업계에 오래 계셨던분들이 더 정확하게 보시겠지만, 저는 주변 비개발자들에게 아래와 같은 이유를 듭니다.
- 2000년대 기준으로는 좋은 언어, 선택할만한 프레임워크였다.
- 정부 SI프로젝트에서 Java를 강제하고, SI회사에서는 Java 개발자를 채용하고, 정부지원 교육과정에서는 Java 개발자를 양산함.
- 이로 인해 개발자 잡마켓에서 절대적으로 Java 개발자 비중이 늘어남.
- 이런 배경 속에서 굳이 불편함을 감수하고 대세를 거슬러야할 이유가 있는 경우가 줄어듦.
- 자바 중심의 확증편향 재생산.
Java 코드는
Java 언어 자체적으로, 또 이 생태계에서 관행적으로 따르는 컨벤션을 존중하지만 한편으로는 기계적으로 특정한 "패턴"들을 사용한다는 느낌을 종종 받습니다.
명확합니다.
스크립트 언어를 쓰다 강타입 언어를 사용하니 이 명확함이 주는 장점과 왜 일부 엔지니어들이 강타입 언어만을 고수하는지 알 것 같습니다.
유독 인터페이스가 많습니다.
다형성이 필요할까 싶은 상황에서도 고민 없이 인터페이스를 만들고, 결과적으로 해당 인터페이스를 구현한 클래스가 하나밖에 없는 경우를 종종 보았습니다.
외부에 SDK형태로 코드를 제공한다던지 코드를 공유하면서 변경에 대해 격리해야 하는 상황과 전혀 관계 없는 독립적인 프로젝트에서도 관행적으로 불필요한 인터페이스를 둡니다.
이론적으로 장점들이 있고 그런 장점이 잘 발휘되는 케이스도 많지만, 그런 장점이 필요 없는 상황에서도 관행적으로 적용하는 부분이 문제입니다. 불필요한 추상화 레이어가 들어가 제가 일반 어플리케이션 개발에 있어 가장 중요하다고 생각하는 가독성을 저해합니다.
유독 파일이 많습니다.
모든 클래스, 인터페이스 등등을 각각 별도의 파일로 두어야 하니 파일이 너무 많습니다. 코드를 따라가다 보면 열리는 파일들이 금방 IDE 탭을 꽉 채워버립니다.
빌드에 시간이 좀 걸립니다.
스크립트 언어로 작성한 서버는 (ex. node, django) 사이즈가 커도 일단 서버 자체는 바로 뜨는데 비해 Java / Spring 서버는 빌드해서 실행하기까지 시간이 걸리는데, 생각보다 이 시간이 많이 거슬립니다.
Spring Framework는
일단 Spring MVC는 메리트가 하나도 없습니다. Spring Boot는 고려해볼만 하지만, 가급적이면 Java 대신 Kotlin + Spring Boot 가 좋겠습니다.
Convention 진영의 후발주자입니다.
Convention vs. Configuration은 논쟁이라고 할만한 시기도 있었으나 지금은 Spring MVC와 Spring Boot의 선호도만 놓고 보더라도 압도적으로 Convention의 승리입니다.
CISC 와 RISC 프로세서의 경쟁에서도 시작은 CISC가 우세했으나 뒤에는 RISC가 더 우세해진 것과 근본적으로는 굉장히 비슷한 이유입니다.
대부분의 프로젝트에 복잡한 설정이 필요한 경우가 잘 없습니다. 필요하다면 관련 내용만 따로 설정을 하면 되는데, Configuration 기조의 프레임워크 (Spring MVC)는 설정이 꼼꼼하게 챙기지 않으면 구동조차 쉽지 않습니다. Convention 기조의 프레임워크에서 컨벤션을 존중해서 얻는 이득에 비해 손이 많이 가고 생산성이 낮습니다.
크기가 방대합니다.
Spring Initializr에서 Add Dependencies 버튼을 눌러보면 타 프로젝트에서는 자체적으로는 지원하지 않는 기능들이 모듈로 준비되어 있는 것들을 볼 수 있습니다. 타 프로젝트에 그런 기능들을 제공하는 오픈소스 라이브러리가 없는건 아니지만, 공식적으로 그만큼을 지원한다는 점이 타 프레임워크와 차별화되는 부분일 수 있겠습니다. 어차피 사용 방법과 주의사항을 잘 숙지하고 사용해야 하는건 여느 프레임워크/라이브러리도 마찬가지기에 큰 장점인지는 모르겠습니다.
오래된 (모던하지 않은) 부분들이 있습니다.
간단한 예를 들자면 라우터의 부재가 있습니다. Spring Boot 프로젝트에서 특정 endpoint에 대해서 인증을 생략하려고 하면, WebSecurityConfigurerAdapter 에서 configure를 override 해서 특정 matcher에 제외해주는 방식으로 코드를 추가해야 합니다.
모던 프레임워크에서는 좀 더 직접적으로 각 endpoint에 가까운 곳(ex. express.js - router, DRF - viewset) 에서 관리하는 것과 비교되지요.
기본적으로 스프링에서 아주 많은것들의 접근법이 A를 위한 X를 A의 속성으로서 간편하게 관리하기보다는 X관리자라는 추상화된 인터페이스와 이를 구현한 몇 종류의 구현체를 제공하는 형태로 되어있는 느낌입니다.
나름의 결론
제가 책임져야 하는 의사결정에서 위에서 언급한 기술 외적인 요인 (인력풀 이슈) 혹은 기술적으로 결정을 속박하는 특단의 사정이 없다면 Java / Spring을 선택해서 사용할 일은 없을 것 같습니다. Java / Spring은 무겁고, 관행적으로 오버엔지니어링 하는 경향이 있고, 현대적이지 못한 부분들이 있습니다. 생산성보다 설계의 확장성을 중요시합니다.
제가 몰랐던 결정적인 무언가는 없었습니다. 아직까지는.
