[WEEK08] 웹 기술의 진화

🌐 프로토콜이란?

• 컴퓨터끼리 데이터를 주고받을 때 지켜야 할 형식과 규칙
• 레이어마다 다름

🕸 초기 웹

• 최초의 웹 브라우저: WWW (텍스트 기반, 단순 HTML 문서 표시)
• 최초의 웹 서버: CERN httpd (정적 HTML 파일만 제공)

📡 HTTP란?

• 웹 브라우저와 웹 서버 사이의 약속
• ⭐ Stateless 프로토콜
  • 요청이 끝나면 과거 상태를 기억하지 않음
  • 단순하고 빠름 → 하지만 로그인, 장바구니 등 유지 어려움 → 쿠키, 세션 등장
• 예: GET /...html HTTP/1.1

---

📈 웹 대중화

• 클라이언트 사이드: 이미지, 서식 태그 등 그래픽 중심 발전 (스크립트/동적 업데이트 불가)
• 서버 사이드:
  • HTTP/1.0 도입 (응답 코드 및 헤더)
  • Apache 웹 서버 등장
  • 2-tier architecture (HTML + CGI)

🔁 상호작용하는 웹

• 클라이언트 사이드
  • Javascript 등장 (내용 변경 가능)
  • CSS 도입
  • 브라우저 전쟁 → 표준화 지연
• 서버 사이드
  • HTTP/1.1 도입 (지속 연결 지원)
  • CGI (동적 콘텐츠 + DB 연결)
  • PHP/ASP 등 웹 페이지용 스크립트 언어
  • FastCGI
  • 3-tier 아키텍처 도입

⚙ 동적 콘텐츠 처리 방식

1. 웹서버 내장 스크립트 엔진
   • 무한루프 → 웹서버 멈춤 ❌
   • 서비스 A 소스코드 수정 시 B도 영향 ❌
2. CGI (Common Gateway Interface)
   • 요청 시마다 새로운 프로세스 생성 → 트래픽 많아지면 비효율
3. FastCGI
   • 미리 실행된 프로세스 풀 활용 → 성능 개선

💡 Web 2.0과 동적 웹 애플리케이션

• 클라이언트 사이드
  • AJAX: 전체 페이지 새로고침 없이 일부만 업데이트
  • jQuery: JS 간소화
  • 브라우저 표준화 진행
• 서버 사이드
  • Ruby on Rails, Django
  • Nginx: 비동기 기반 성능 강화
  • 로드 밸런서, 클러스터링
  • MVC 프레임워크 확산 (Spring, Rails 등)
  • RESTful API 개념 등장

🔄 비동기 처리 방식

• 정적/동적 콘텐츠를 분리하여 처리

🧱 3-Layer Architecture

• 웹 서비스를 세 층으로 나누어 효율적 개발
  • Presentation
  • Business
  • Data

🤔 3-Tier Architecture vs 3-Layer Architecture?

🔹 3-Layer Architecture (개발 구조 관점)

• 정의: 소프트웨어를 역할에 따라 논리적으로 세 개의 레이어로 분리한 구조
• 구성:
  1. Presentation Layer (UI): 사용자 인터페이스, 브라우저 등
  2. Business Layer: 비즈니스 로직 처리 (서비스, 컨트롤러 등)
  3. Data Layer: 데이터 저장/조회, DB 접근 (DAO, Repository 등)
• 장점:
  • 코드의 역할이 명확하게 분리됨
  • 유지보수와 테스트 용이

🔹 3-Tier Architecture (배포 구조 관점)

• 정의: 시스템을 물리적으로 세 개의 서버(또는 Tier)로 분리한 구조
• 구성:
  1. Client Tier: 사용자 단말 (웹 브라우저 등)
  2. Application/Web Tier: 비즈니스 로직 처리 서버 (Tomcat, Spring 등)
  3. Data Tier: 데이터베이스 서버 (MySQL, Oracle 등)
• 장점:
  • 시스템 확장과 보안에 유리
  • 각 계층을 독립적으로 배포 및 운영 가능

구분	3-Layer Architecture	3-Tier Architecture
관점	논리적(개발) 구조	물리적(시스템) 구조
분리 기준	코드의 역할	배포/운영 단위
위치	한 서버 내에서도 구현 가능	각 계층이 서로 다른 서버에 존재
목적	모듈화와 유지보수 용이	확장성, 보안, 성능 확보

🦢 가벼운 웹서버 등장

• Spring Boot, Flask, Node.js → Business, Data layer 처리

🌐 RESTful API

• URI + HTTP Method + Response Code로 서비스 정의
• 반복되는 코드의 표준화

🧰 API 게이트웨이의 필요성

• 부하 분산, 버전 관리, 인증/보안, 문서화
• 분산된 백엔드 통합 관리

📶 트래픽 증가 대응

• Load Balancer (L4, L7)
  • L4 스위치: HW 기반 부하 분산
  • L7 (reverse proxy): 웹 서버 수준에서 분산

---

📱 현대 웹 & 모바일

클라이언트 사이드

• HTML5, CSS3 → 비디오, 애니메이션, 반응형
• React, Angular, Vue.js
• 브라우저가 무거운 연산 수행 → 서버 의존도 ↓

서버 사이드

• Node.js → JS로 서버 개발, 실시간 채팅/스트리밍
• 클라우드 플랫폼: AWS, GCP
• CDN (Akamai, Cloudflare)
• HTTP/2 (멀티플렉싱) → 속도 향상

🌍 CDN 서비스

• 미사용 시: 국제망 이용 → 느림
• 사용 시: 캐시 서버 활용
• 문제점: 모든 콘텐츠를 캐시에 담을 수 없음 → Hit rate 향상이 핵심

---

🔮 미래의 웹

클라이언트 사이드

• WebAssembly: 브라우저에서 네이티브 수준 속도 (ex. C로 컴파일)
• Next.js, Svelte: 빠르고 SEO 친화적인 앱 개발
• PWA: 설치 없이 동작, 푸시 알림, 오프라인 가능

서버 사이드

• Serverless (AWS Lambda): 서버 관리 없이 코드 실행
• HTTP/3: UDP 기반 QUIC → 빠르고 보안 강화
• Microservice Architecture
• Edge Computing: 사용자와 가까운 위치에서 서버 동작 (CDN보다 더 세분화)