1. 백엔드 언어, 프레임워크
- Java(Kotlin), Spring 계열
- JS, Express(Node) 계열
- Python, Django 계열
- C#, .NET 계열
- PHP, Laravel 계열
2. Spring을 한국에서 많이 쓰는 이유
- Spring 프레임워크는 Java Enterprise Edition(기업용 자바)의 한계점을 극복하기 위한 배경에서 등장한 프레임워크
- 자바가 초창기에 서버로 활용될 때에는 자바 EE를 사용했었는데, 자질구레한 문제점들이 있었고,
- 로드 존슨이라는 인물이 이를 개선하기 위해 제안한 것이 바로 스프링 프레임워크
- cf. 그래서 이름도 겨울이 끝나고 ‘봄’이 왔다는 뜻에서 Spring
2.1 정적 타입 관점
- Java는 정적 타입
- Javascript는 Typescript로 보완 가능
2.2 컴파일 관점
- Java는 JVM에서 동작, 컴파일 언어
- JavaScript, Python 같은 언어들들도 JIT 컴파일을 지원해, 실행 전에 컴파일 수행 가능함
- 즉, 다른 언어들도 컴파일 다 가능함
2.3 생태계 관점
- 스프링은 자바 EE를 개선하기 위한 움직임에서 나온 프레임워크
- 기업이 애플리케이션을 만들 때 필요한 도구는 거의 다 갖추고 있음
- Node 진영도 수 많은 npm 서드파티 라이브러리가 존재
- But, 대규모 서비스 입장에서 “단 1초라도, 1명도 장애를 겪어서는 안된다.”
- 아직 써보지 않은 제 3자의 라이브러리를 선정해 모험을 감수하는 것보다,
- 이미 수많은 기업이 사용함으로써 검증된 라이브러리를 사용하는 것이 더 합리적
- But, 페이스북은 PHP를 개량하여 사용하고 있고, 드롭박스는 파이썬으로 돌아가고, 트위치는 Ruby On Rails로 돌아감
- 국내에서 이 위의 세 회사보다 더 많은 트래픽을 감당중인 회사는 없음
2.4 구인, 채용의 관점 - 근본적인 이유
- 어느 트래픽에 어느 언어를 써야만 한다는 정답은 없다.
- 실력 있는 개발자만 있으면, 세상 그 어느 언어를 갖다 놔도 매우 잘 돌아간다.
- 국내 시장에서 자바 스프링이 자주 보이는 것은, 경력자 구하기가 용이하기 때문이다.
- 2000년대 후반 Java, Spring 기반의 전자정부 프레임워크가 등장하며, 직간접적으로 공공기관과 관련된 일을 해야하는 회사들이 자바를 이용
- IT 사업이 점점 커지면서 기업들이 경력자를 많이 필요로 하게 되고, 그 결과 많은 경력자들이 애용하는 자바 스프링이 메인이 됨
2.5 스타트업은
- 스타트업 중에서 자바 스프링을 채택하는 곳은 드물다.
- “빠른 시간 내에 어떻게든 결과물을 내야하는 상황”에서 자바는 썩 좋은 선택은 아니다.
- 동적 타입 언어는 다소 예측하지 못한 문제들을 낳을 지는 몰라도, 생산성에서는 다른 언어들과 차원이 다르다.
- 그래서 대기업이 아닌 기업들을 볼 경우에 Node(Express, Nest)를 쓰는 경우를 자주 볼 수 있다.
2.6 본질
- 백엔드 개발에서 중요한 본질은 “네트워크 개념을 얼마나 잘 이해하고, DB를 얼마나 잘 이해하고, 이를 어떻게 응용할 수 있는가”
- 지금 쓰고 있는 프레임워크가 언젠가는 사멸(?)할 지도 모른다는 생각으로 접근해야 한다.
- 언젠가는 자바 스프링이 저무는 때가 오더라도, 백엔드에 대한 핵심 개념을 잘 간직하고 있다면, 어렵지 않게 다른 프레임워크를 집어들 수 있다.
- “기존에 하던 것을 버리고 스프링을 다시 배울까?”가 고민된다면, 그보다 “지금 하던 걸 더 깊게 파서 수준 높은 경험을 쌓기”
- 국내는 신규와 유지보수 포함하여 자바 스프링이 80퍼센트라 거의 필수
- 자바 스프링을 배워서 입문한 뒤에 경력을 쌓고 여러 경험을 쌓을 수 있는 빅테크에 들어가서 하고 싶은 언어들을 배우기
- 사람마다 살아가는 방식이 다르듯, “어떤 것이 정답”이란 것은 없다.
- django, node, spring 뭘 쓰든, 세 프레임워크 모두 설계만 잘하면 전 지구적 트래픽을 처리하는게 가능하다.
- 전세계적으로도 spring을 많이 쓴다.
- 다만, spring의 강점은 큰 규모 시스템을 만들 때 나오는 거라, 스타트업 규모에서는 node가 제일 인기 많다.
- IT giant 가 된 정도로 성장한 회사들은, 하나만 쓰지 않는다.
- 규모가 너무 크기 때문에 legacy는 처음에 개발했던거 그대로 가져가는 경우 많지만 새로 개발할 때는 여러가지 고려해서 개발한다.
3. 사례
- 지그재그 : 첫 시작은 풀 Node, 2022년 카카오 인수되기 전까지 Node 프로젝트 몇몇개 존재
- 이후 쿠팡, 배민, 네이버의 Java, Spring 시니어가 오면서 점차 전환
- 2022년도에 Node 프로젝트가 전부 없어지고, 100% Java, Spring으로 전환
4. 참고
백엔드 시장의 크기, 스프링 외의 채용의 문제, 전자정부 프레임워크