안녕, 난 자프링,코프링을 주로 사용하는 벡엔드 개발자이고 중간에 잠깐 node.js로 서버 개발해본 경험이 있음. 그동안 눈팅만 좀 하다가, 자바 관련 이야기를 해보고 싶어서 첫 글 남김 ㅎ

여기서는 자바 까는 글 밖에 없잖아. 그래서 자바 깔만한 점들은 충분히 다들 알테고, 다른 장점들에 대해서 이야기해볼려고 함.


1. 참고할만한 래퍼런스가 많다.


자바 + JVM 생태계 자체가 꽤나 연식이 있는 편임. 다른 모던한 언어들과 달리 관련 예시나 따라할만한 아키텍처에 대한 참고문헌이 풍부함.

그냥 튜토리얼 수준이 아니라, 꽤나 깊이 있는 문서들도 많이 존재함. 특히나 한국은 자바 공화국이잖아? 영어 뿐 아니라. 한글 문서에도 괜찮은 예제들을 많이 접할 수 있음.

이게 존나 중요함. 언어자체의 디자인이 좋고 나쁘고를 떠나서, 관련 문서를 쉽게 찾을 수 있는지 없는지가, 개발할 때 훨씬 더 중요하다는 걸 많은 이들이 알고 있을 거라 생각해.

솔직히 한국 한정해서 자바를 제외하고는 이 부분에서 따라올만한 언어는 존재하지 않는다고 생각해 ㅎ. 필자는 커리어 잠깐동안 node.js로 서버 개발을 해 본 적이 있는데, 완즈이 맨땅에 헤딩하는 기분이었어 ㅎ



2. 안정성


알다시피 자바는 꽤 연식이 있는 언어임. 그동안 여러 방면에서 사용해오면서 안정성이 검증되었음. 언어자체 특징이 약간 구닥다리 느낌이 나긴 하지만, 이런 특징 때문에 하위호환성을 굉장히 잘 지키는 언어에 속함. 기타 몇몇 다른 언어들과 달리, 버전 업데이트 하면 기존 라이브러리, 환경셋팅 바보 되는 게 아니라, 왠만하면 레거시 코드 재활용 가능함. 당근 메모리, 성능 관련 부분에서도 JVM 생태계를 가진 언어들이 비슷한 류의 언어들 중에서 가장 최적화가 잘 되어있는 편이기도 하고,


3 . 생태계 내에서 거의 표준화된 프레임워크


스프링 이야기를 안 꺼낼 수 가 없어. 자바로 서버사이드 개발을 한다면 프레임워크로 스프링을 사용한다는 건 거의 업계 표준임. 이건 국내 해외 가릴 거 없슴. ORM 쓸려고 한다면 JPA (하이버네이트) 를 쓴다는 것도 거의 표준이지. 다른 대안이 없는 것은 아니지만 당분간 이 아성을 뛰어넘을 순 없을 것 같아. 그만큼 오래되었고 수많은 사람들이 써오면서 가치가 검증된 프레임워크가 존재한다는 거고, 관련 래퍼런스도 아주 풍부하지 ㅎ 자바를 싫어한다고 하는 사람도 스프링 자체를 싫어하는 사람은 본 적 없는 거 같애 (물론 몇몇 사람들은 불만이 있는 것 같긴 해 ) 암튼 스프링 자체가 굉장히 잘 만든 프레임워크에 속해. 필자는 이것저것 여러가지 언어와 생태계 찍먹하면서 서버사이드 개발을 해본 경험이 있는데. 스프링의 확장성, 유연함을 따라갈 만한 서버사이드 프레임워크는 닷넷 빼고는 존재하지 않는다고 생각해. 흔히들 스프링이 무겁다고 이야기하잖아. 엔터프라이즈 환경에 어울리고, 하지만 원래 스프링은 경량화된 컨테이너라는 가치를 내걸고 만들어졌어. 지금도 여전히 그 가치는 유효해. 스프링의 코어는 IOC 컨테이너라는 단순히 의존성 주입을 해줄 수 있는 자그마한 컨테이너로 이루어져 있고. 대부분의 스프링 모듈은 그 컨테이너에 빈들로 올라가서 이루어져 있어. 이러한 특성으로 인해 계속해서 그 코어에 스프링이 제공해주는 인터페이스 를 구현한 빈들을 올려줌으로서 엔터프라이즈 환경에 맞는 무한한 확장성을 챙겨올 수 있었어 ㅎ, node.js 로 예를 들자면, 선택지가 많잖아? express, koa, nest.js.. 등등, ORM tool로는 시퀄라이즈, TypeOrm 등등 말만 들어도 개발자에게 선택장애를 일으키게 해주는 요소 대신 스프링이라는 추상화된 프레임워크 위에서 JVM 생태계의 다양한 라이브러리나 프레임워크를 녹여낼 수 있음



4. 전체 개발자 풀 평균치가 높음.


이건 시니어급 개발자들(연식이 오래된 만큼 시니어 개발자들이 많음) 이 많다는 것과 별개로, 자바 언어 자체에서 타입이나 클래스를 강제하는 문법체계나, 스프링 프레임워크의 구조화된 툴로 인해. 개떡같은 개발자도, 어느정도 구조화된 수준의 코드를 양산해낼 수 있도록 강제하는 장점이 있슴. 필자는 express로 서버사이드 개발을 헤보면서 이건 도저히 팀 차원에서 써먹지 못하겠다고 생각이 든 적 이 있는데, 자바스크립트 언어 자체의 자유분방함 + 허허벌판 같은 express 구조 속에서 도저히 공통점을 찾을 수 없는 수많은 express 기반 웹 어플리케이션 서버 코드들을 보면서, 이거 정신 안 차리면 완즈이 개판되기 쉽다고 느꼈어 ㅎㅎ



5. 언어자체의 심플함


자바는 알다시피 타이핑이 장황한 언어 중 하나지. 그런데 그런 귀찮은 명시적인 부분들을 떼어놓고 보자면, OOP 개념만 잘 잡혀 있으면, 결코 배우기 어려운 편도 아니고, 사용하기는 굉장히 쉬운 편에 속한 언어라고 생각해. 자바스크립트처럼 배우기도 애매하고, 사용하기도 얘먜한 언어가 아님, 한 번 배울 때 약간 난이도가 있지만, 기본 개념만 알면, 언어 자체가 약간 원시적?이기 때문에 훨씬 실수할 여지가 줄어듬. 또 자바는 문법체계에서 스레드를 생성할 수 있도록 해주는 데 이 부분도 맘에 들어. 요새 자바스크립트처럼 이런 걸 언어차원에서 지원안해주는 언어들도 많이 있던데, node.js 로 개발해오면서, CPU 멀티코어를 쓰기 위해서 서버 클러스터링 도입하면 꼭 나오는 문제가 동일한 WAS 들끼리 컨텍스트 스위칭이 안 되서, 자원 공유가 안 된다는 게 정말 짜증났어, 결국 외부에 다른 의존성을 갖고 와야되는데, Node.js 장점 중 하나가 싱글스레드 기반 Nonblocking io라서 컨텍스트 스위칭 과정이 없어서 성능이 빠르고 가벼우며 동시성 충돌 문제를 신경 안 쓴다는 게 아니겠슴. 근데 결국에 이럴 거면 스프링을 쓰는 게 낫다는 생각이 많이 들더라구.



6. 계속 발전해나가고 있긴 함


많은 사람들이 자바는 너무 말이 많다. 구닥다리다. 얘기가 많음. 이건 사실이야. 자바는 특성상 보일러플레이트 코드가 굉장히 많아질 수 밖에 없는 언어야. 하지만 이 부분도 우리가 개선할 수 있어. 대표적으로 롬복같은 어노테이션 프로세싱을 활용하는 툴을 이용하면 중복코드의 양을 확 줄일 수 있지. 그리고 자바 8부터 지원하는 람다식이나 stream api 들을 적극적으로 활용하면, 다른 모던한 언어들과 비슷하게끔 모양새를 맞출 수 있음. 물론 그렇다고 하더라도 개발자 입장에서 문법적으로 편의적이라고 얘기할 수 없지만 생각보다 타이핑할 일이 다른 언어에 비해서 엄청나게 많지는 않아.


또 스프링이 너무 설정이 복잡하다. 지루하다 말도 많은데, 부트가 등장하면서 그 말도 사그라지고 있는 편이야. 암튼 스프링도 webflux라든가, 여러 최신 프로그래밍 패러다임을 지원해주는 쪽으로 따라가고 있고, 전통적인 방식의 개발과 새로운 트렌드의 기술 양쪽을 원할히 왔다가면서 개발할 수 가 있어.


암튼 내가 생각하는 자바의 장점은 여기까지야 ㅎㅎ 자바를 너무 까는 사람들이 많더라구, 자바가 답답한 언어임에는 맞는 말이지만, 그럼에도 엔터프라이즈 환경에서 1~2 순위로 선택되는 것은 다 이유가 있다고 생각해 ㅎ 꼭 전자정부프레임워크 때문이 아니라.