자바 백엔드 기술의 역사

자바 웹 기술 역사 

• 서블릿 - 1997
  • HTML 생성이 어려움
• JSP - 1999
  • HTML 생성은 편하지만, 비지니스 로직까지 너무 많은 역할 담당
• 서블릿, JSP 조합 MVC 패턴 사용
  • 모델, 뷰 컨트롤러로 역할을 나누어 개발
• MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~2010년 초
  • MVC패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원
  • 스트럿츠, 웹워크, 스프링 MVC(과거 버전)

서블릿이 나온 이유는 TCP/IP연결하고 , 멀티스레드 공부하는 것이 좀 어려움 그래서 서블릿이라는게 나온다. 

하지만 서블릿은  자바 코드로 작성해야한다.  이러한 서블릿은 HTML을 작성하는게 굉장히 어렵다. 

그래서 이러한 문제를 해결하고자 JSP가 나온다.  JSP는 HTML도 너무 쉽게  작성할 수 있고 자바코드도 그 안에서 다 작성할 수 있다. 

JSP가 최종적으로는 서블릿으로 변한다. 개발자는 이것까지는 고민할 필요는 없다. JSP는 HTML 생성은 편리한데 여기에 비지니스 로직까지 한번에 해버렸다. 그러니깐 JSP 파일하나에 수천줄이되서 유지보수가 헬이 된다. 

이러면서 MVC 패턴이라는게 등장한다.  모델, 뷰, 컨트롤러로 역할을 나누어 개발한다. 

핵심은 비지니스 로직을 구현하는 부분이랑, 화면을 렌더링하는 부분 두개를 나누는 것이  핵심이다. 

이렇게 해서 관심사를 나누는 것이다. 화면을 수정해야되면 JSP쪽을 고치고 비즈니스 로직과 관련된 부분을 수정해야하면 JAVA코드나 서블릿을 수정해야하는 것이다. 

 

패턴이있어 개발하는게 비슷함. 수많은 사람들이 비슷하니깐 프레임워크를 만들어야겠다고 고민하여 프레임워크가 나온다. 그래서 수많은 MVC프레임워크가 등장을 한다. 

웹이라는게 사실 개발하려면 고민해야할께 정말 많다. 

옛날에는 스트럿츠를 앞단에 깔고 뒷단에는 스프링을 깔았던 시절이다. 

 

자바 웹 기술 역사 

• 애노테이션 기반의 스프링 MVC 등장
  • @Controller 
  • MVC 프레임워크의 춘추 전국 시대 마무리 
• 스프링 부트의 등장
  • 스프링 부트는 서버를 내장 
  • 과거에는 서버에 WAS를 직접 설치하고, 소스는 War파일을 만들어서 설치한 WAS에 배포 
  • 스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화 

MVC컨트롤러들을 굉장히 깔끔하게 작성할 수 있게 되어 있음. 

Spring boot를 사용하면서 Spring을 굉장히 편리하게 사용할 수 있도록 변경되었다. 

스프링부트는 서버를 내장한다. 과거에는  WAS를 서버에 직접 설치를 한다. 그런 다음에 설치하고 직접 따로 실행을 한다. 소스코드는 소스코드대로 따로 모아서 빌드를 한다. 자바 코드들을 Jar파일을 모아서 War파일을 만든다. 

설치한 폴더에다가 이거를 넣어주면 그럼 배포가 된다. 

개발자들이 톰캣 설치, War파일 만드는 방법등 굉장히 복잡한 것들을 알아야함. 이 과정 자체가 굉장히 번거로움 

Spring boot가 빌드할 때, 톰캣서버를 넣어 버린다.  이렇게 되면 서버에 톰캣을 설치할 필요가 없어짐 빌드 결과에 Jar를 그냥 아무 서버에다가 java- **.jar로 실행해버린다. 그럼 그냥 서버가 띄워지고 내가 만든 코드가 실행이 된다. 

 

지금은 대부분은 신규 프로젝트는 대부분 스프링부트 기반으로 한다. 

 

자바 웹 기술 역사 

스프링 웹 기술의 분화 

• Web Servlet - Spring MVC
• Web Reactive - Spring WebFlux 

웹 서블릿이라는  기술스택, 웹 리액트라는 기술스택으로 분할된다. 

 

자바 웹 기술 역사 (최신 기술 - 스프링 웹 플럭스 (WebFlux))

• 특징
  • 비동기 넌 블러킹 처리 
  • 최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화
  • 함수형 스타일로 개발 - 동시처리 코드 효율화 
  • 서블릿 기술 사용 X
• BUT
  • 웹 플럭스는 기술적 난이도 매우 높음
  • 아직은 RDB 지원 부족 
  • 일반 MVC의 쓰레드 모델로 충분히 빠르다. 
  • 실무에서 아직 많이 사용하지 않음?(이부분은 잘 모르겠음)

만약 CPU 코어가 4개가  있다.  그러면 스레드의 개수를  CPU코어나 거기에 플러스 하나 정도로 맞추는 것이다. 그래서 정말 고효율로 쓰레드의 개수를 CPU와 맞췄기 때문에 이 쓰레드는 계속 돌 수 있는 것임 이러면 컨텍스트 스위칭 비용이 거의 들지 않음. 스레드가 수백개가 있으면 엄청 많이듬. 

 

동시처리 효율의 예) 상품도 조회하고 주문 서버도 조회하고 api를 여러개 가지고 와서 조합을 해야된다. 이러면 일반적인 자바코드로 이런걸 짜면 굉장히 쉽지 않고 깔끔하게 떨어지기가 어렵다. 이걸 함수형 스타일로 짜면 이런 코드도 굉장히 깔끔해짐. 

그리고 서블릿 기술을 사용하지 않음. 

 

자바 뷰 템플릿 역사

HTML을 편리하게 생성하는 뷰 기능

 

• JSP
  • 속도 느림, 기능 부족
• 프리마커 (Freemarker), Velocity(벨로시티)
  • 속도 문제 해결, 다양한 기능 
• 타임리프(Thymeleaf)
  • 내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능 
  • 스프링 MVC와 강력한 기능 통합 
  • 최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠름. 

Spring boot에서 뷰템플릿으로 JSP를  사용하는 것을 선호하지 않는다.