Computing Paradigm의 변천과 Web 기술의 발전
컴퓨팅 프로그래밍의 변천의 모토 = 개발자 편의성에 의해 (개발자가 뭔가 불편하고 귀찮을 때 이를 해결할 방법을 제시하는 방향으로 발전)
- Program 기법 측면
개발자에게 편한 방법으로 발전 - 구조적 측면
http→응답이 텍스트라서 개발자 입장에서 편함→ 웹이 대두
HTML : 정적 리소스
CGI : 동적 리소스, 기능 구현
기존의 CGI(C, Cobol 등)는 프로세스단위라서 비효율적 → thread 기반으로 개선됨
플랫폼 종속성 (platform dependent) : 서버 플랫폼 확장 시 기존 서버 플랫폼의 양식을 따라야 하는 것
thread도 동일한 플랫폼 종속성 문제를 가짐 → 자바로 platform independent 구현 : 자바는 웹 겨냥이기 때문에 JVM을 통해 플랫폼 독립성을 유지할 수 있음
- 자바 : 플랫폼 독립적, 쓰레드 기반
- Servlet : 자바 기반의 CGI
- Text: 내가 직접 쓴 문자나 코드
- Context: 내가 직접 작성하지 않은, 상황이나 환경 정보
웹 어플리케이션의 요청 처리 흐름
클라이언트에서 URL로 요청 → 해당 아이피, 포트의 웹 서버로 요청을 전송 →
- 정적 파일인 경우 : 웹 서버에서 직접 처리
- 동적 컨텐츠인 경우 : 웹 서버는 요청을 웹 컨테이너로 전달하고, 서블렛에서 요청 처리
→ 클라이언트로 응답 반환
(서블렛은 웹 컨테이너 내에서 실행됨)
3-tier architecture
- 클라이언트 티어 : 사용자의 요청을 서버로 전달, 서버로 부터 받은 응답을 보여줌
- 비즈니스 티어 : 클라이언트에서 받은 요청 처리, 응답 반환
- 리소스 티어 : 데이터 저장소와 상호작용
클라이언트 티어(웹브라우저)가 비즈니스 티어(웹 서버)에 요청 → 비즈니스 티어(웹 서버)는 리소스 티어에 접근하여 요청 처리 → 클라이언트 티어에 응답 반환
B2B 시스템의 프로토콜, 데이터 형식
B2B 시스템에서 프로토콜은 http, 형식은 XML로 데이터를 주고받음
B2B에서 사용하는 언어가 다름(시스템1 에서는 자바를 쓰고, 시스템 2에서는 C를 사용하는 경우) → 프로토콜을 정해야함 → 각각 프로토콜을 만들기 어려움, 귀찮음 → http 사용 → b2b이므로 웹페이지를 그리는 html이 방식을 사용할 필요가 없음 → XML을 사용
XML : 데이터를 구조화하고 저장하는데 사용되는 마크업 언어
html(내용)은 DOM으로 해석
css(표현)는 css엔진으로 해석
js(동작)는 js엔진으로 해석
DOM : 브라우저가 HTML을 표현하고 조작하기 위해 사용하는 도구, 트리 구조
JS
기존 js엔진이 많은 양의 js를 처리하기에는 느림
V8 엔진 : 크롬에서 JS성능을 개선해서 빨라짐
Node.js : V8이 속도 빠르니까 서버용으로 만듦
JS는 간단하고 유연했으나, 규모가 커질수록 에러 발생 확률 증가
TypeScript : js의 유연함이 단점이 되는 문제를 해결
Angular, React, Vue.js …
리액트는 프레임워크로 발전
CSR : html은 비어있고, js는 꽉 차있음. js로 html을 동적으로 그려냄
SSR : 서버에서 html을 만들어서 보여줌
모던 웹 특징
- 컴포넌트기반 : 대규모 어플리케이션에서 유지보수 및 확장성 증가
- 상태관리 필요 : 데이터 흐름 예측, 일관성 유지, UI 갱신 효율성 증가
프론트 서버와 백엔드 서버가 구별된 경우 흐름
브라우저에서 프론트 서버로 요청 보냄 → 프론트 서버에서 html 반환 → html에 포함된 js에서 XHR을 http 요청으로 백엔드 서버로 요청 → 백엔드 서버에서 요청 처리 후 응답 반환
클라이언트 요청과 응답 처리 과정
- 클라이언트(브라우저)에서 웹 서버에 http로 요청 전송
- 웹 서버(하드웨어와 OS 기반으로 동작) 요청 수신, 정적 파일이면 웹 서버에서 바로 응답 반환, 동적 데이터면 서블릿으로 전달
- 서블릿에서 JavaSE, JavaEE를 사용해 응답 생성
- 웹 서버로 응답 반환
- 웹 서버가 클라이언트로 응답 반환
서블릿
서블릿의 구조 : 요청분석 → biz(비즈니스) → 응답
서블릿에 비즈니스 로직을 포함시키면 코드가 복잡해지고 관리 어려움 → 비즈니스 로직을 서블릿 밖으로 분리 → 재사용성, 유지보수 향상
비즈니스 로직을 분리하는 이유
- http는 속도가 느림
- 속도 개선을 위해 http가 아닌 Socket 연결이 필요
- http가 아닌 요청(다른 UI)을 받기 위해서는 서블릿내의 비즈니스 로직을 처리하는 방법 필요
- 서블릿은 HTTP 요청을 처리하는 자바 프로그램
- 근데 서블릿으로 요청을 바로 보낼 수 없기 때문에 biz를 서블릿 밖으로 따로 꺼내 처리할 수 있도록 만듦
- 따라서 biz는 여러 환경에서 reuse 가능하도록 객체지향적으로 프로그래밍
- 재사용은 구조가 개선되더라도 다 뜯어고치지 않아도 되도록 하는 것
서블릿은 클라이언트 요청을 처리해서 응답을 생성함 → 서블릿 내부 구조는 요청 분석, 비즈니스 로직 수행, 응답 생성 → 서블릿은 중개자 역할이므로 비즈니스 로직까지 포함하면 관리 어려움 → 비즈니스 로직을 분리 → 재사용성 증가, 코드의 복잡성 감소, 유지보수 및 확장성 향상
MVC 패턴
비즈니스 로직(Model)을 분리하여 프레젠테이션(View)과 제어(Controller)의 독립성 유지 → 유지보수, 확장성 향상
비즈니스 로직은 시큐리티, 트랜잭션, 영속성을 관리해야함 → JavaEE에서 제공하는 EJB를 통해 처리가능하지만 복잡함 → Spring으로 대체
biz(Model)는 시큐리티(sec), 트랜잭션(tx), 영속성(per)이 필요 → 3가지 합해서 안정성이라고 함
백엔드의 비즈니스 로직 처리 과정
백엔드 서버(프레젠테이션)에서 요청을 받음 → 프레젠테이션에서 요청을 분석해 백엔드 비즈니스 서버로 요청 → 백엔드 비즈니스 서버에서 이를 처리하는데, 시큐리티, 트랜잭션, 영속성을 설정할 수 있는 기능을 JavaEE에서 제공 → 이를 이용해 안정성 향상 하도록 구현 → 이 응답을 백 프레젠테이션으로 응답 → 백 프레젠테이션 서버에서 클라이언트로 응답 반환
Spring과 Spring Boot
biz 로직 코드는 얼마 안됨, 시큐리티, 트랜잭션, 영속성 처리 코드가 많음 → 이를 JavaEE의 EJB가 제공
EJB는 어려움 → 이를 쉽게 한 게 Spring
스프링은 외부 라이브러리(시큐리티, 트랜잭션, 영속성)를 가져와서 사용할 수 있음
원래는 톰캣을 깔아야 하는데, 스프링은 내장 톰캣을 사용할 수 있게 함 → JavaEE 스택이 필요 없어짐 → 이를 Spring Boot
enterprise : 대규모 조직의 복잡한 요구를 해결하는 소프트웨어 시스템
스프링같은게 엔터프라이즈 애플리케이션을 개발 할 수 있게 함
HTML
html은 표준 마크업 언어
마크업이란 <>처럼 생긴걸 말함
<!DOCTYPE html> → HTML5 버전을 의미함
'[LG 유플러스] 유레카 > Today I Learned' 카테고리의 다른 글
| [TIL][02.03] ES6, SSR, CSR, SSG, SOP, CORS (0) | 2025.02.04 |
|---|---|
| [TIL][01.24] JS, 배열, function, object, 생성자, Event, 반복문, Collection (0) | 2025.01.24 |
| [TIL][01.23] BootStrap, JavaScript, let, var (0) | 2025.01.23 |
| [TIL][01.22] CSS, BootStrap (0) | 2025.01.23 |
| [TIL][01.21] HTML, form, HTTP, React, Next.js, CSS (0) | 2025.01.21 |
