728x90

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.

웹을 배우는 이유

앱은 앱 구동을 위한 머신이 필요. 안드로이드, ios와 같은 모바일 OS에 국한된 앱을 사용해야 한다.

반면 웹은 브라우저 종류에 상관없이 동일한 페이지를 읽을 수 있다. 웹 브라우저는 어디든지 설치가 가능하다.
모바일에서도 네이티브 앱을 개발하는 대신 PWA(Progressive Web Application)을 만들 수 있다.

PWA

모바일 기기에서 네이티브 앱과 같은 사용자 경험을 제공하는 웹 앱

네이티브 앱과의 차이

네이티브 앱 -> 앱스토어 최적화(ASO). 앱스토어에서 검색 결과 순위를 높이기 위한 절차
PWA -> 검색 엔진 최적화 (SEO).

장점

네이티브 앱보다 접근성이 더 좋다.
개발 비용이 더 저렴하다. 네이티브 앱은 각 모바일 os마다 앱 개발 + 유지 보수 필요.
개발과 업데이트에 걸리는 시간이 더 빠르다. 또한 배포가 매우 빠르다.

단점

브라우저에서 실행되기 때문에 네이티브 앱에 비해서 지연 속도가 크고 배터리 소모량이 더 많다.
모바일에서는 여전히 PWA보다 네이티브 앱이 더 많은 일을 할 수 있다.
- PWA에서도 푸시 알림 등이 가능하지만,
  사용자 경험을 위한 지오펜싱, 센서 감지 기능 등이 필수적인 경우 pwa로는 개발 불가능하다.
네이티브앱은 다중 인증 방식이 가능하고 보안이 더 좋음.

웹 개발

다음 3가지 기초사항이 필수적으로 요구된다.

HTML
형식에 맞는 웹 페이지를 만들기 위해 HTML 사용
CSS
웹 페이지를 꾸미는 역할
Javascript
유저 인터랙션. 유저 이벤트 처리 및 DOM 조작

프론트엔드 개발자는 웹 페이지의 표기 방식인 Rendering을 다룬다.
백엔드 개발자는 웹 페이지가 표기할 데이터와 관련된 조작을 다룬다.

프론트엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

기획자 20%
디자이너 80%

웹 기초 이해 필요
3. 백엔드 개발자

백엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

기획자 80%
디자이너 20%

웹 기초 이해 필요

프론트엔드 개발자

인프라스트럭쳐 이해 필요

devops - 배포 전과정 피드백
solution architecture
SRE (Service(Site) Reliability Engineer)
서버 가용성 조정

프론트엔드 개발자는 백엔드 개발자 비해서 대화할 주체가 적으나, 고객의 요구사항에 더 시달리는 경향이 있다.

웹의 본질

웹 리소스의 요청과 반환(응답)
웹은 초기에 여러 컴퓨터에 저장된 논문, 실험결과와 같은 정보 교환과 공동 연구를 목적으로 개발되었다.
클라이언트가 서버에게 요청을 하면, 서버는 클라이언트에게 웹 리소스를 응답한다.

웹 리소스는 두 가지로 나뉜다.

웹 데이터(json, xml 등의 형식)
웹 페이지

요청-반환 방법

REST API
GraphQL
Queue
트래픽이 많으나, 실시간성이 중요하지 않은 경우 -> 메세지큐 사용
ex) Kafka
이때 Buffer를 사용한다. 요청을 Queue에서 대신 받아서 처리. Pub-Sub 패턴으로, 큐가 Publisher 역할을 하게 된다.
실시간성을 고려해야 함.
https://www.kai-waehner.de/blog/2022/11/29/apache-kafka-is-not-real-real-time-data-streaming/
WebSocket
각자가 서버이자 클라이언트가 된다. 실시간 게임, 실시간 채팅에서 사용된다.
소켓 연결을 유지하는 것 자체로도 비용이 발생하기 때문에, 실시간성이 필요한 환경에서만 사용하는 것이 좋다.
Webhook
데이터가 변경되었을 때 실시간으로 알림을 받을 수 있는 기능이다.
웹 서비스의 이벤트 데이터를 전달하는 HTTP 기반 콜백 함수이다. 클라이언트가 한 번 요청을 보내면 해당 요청은 비동기적으로 처리된다.
하지만 콜백이 누락될 수 있다는 단점 또한 존재한다.
https://sanketdaru.com/blog/polling-model-async-rest-spring-boot/
API Polling
웹 훅과는 달리 클라이언트가 서버 API를 호출해서 이벤트가 발생했는지 확인한다. 클라이언트가 주기를 설정하면, 주기적으로 요청을 하게 된다.
주기는 약 60초 ~ 120초 설정이 권장되지만, 실시간으로 이벤트 데이터를 받을 수 없다는 단점이 존재한다.
https://docs.tosspayments.com/resources/glossary/webhook

웹 브라우저

웹 브라우저는 특수한 형태의 웹 페이지를 읽을 수 있는 웹 페이지 리더기이다.
웹 브라우저 혹은 서버가 사람이 읽을 수 있는 형태로 웹 페이지를 변환하는 것을 렌더링 이라고 한다.
렌더링된 페이지를 화면에 그리는 것을 페인팅 이라고 한다.

서버와 클라이언트

웹, 개발이 아닌 일반적인 개념에서 서버와 클라이언트는 다음과 같이 정의할 수 있다.

클라이언트 -> 서비스 요청자
서버 -> 서비스 제공자

이는 일종의 Producer - Consumer 패턴 이라고 할 수 있다.
Publisher - Subscriber 패턴(Pub-Sub) 과 비슷하지만 차이를 보인다.
Publisher - Subscriber 패턴 에서는 Publisher와 Subscriber는 서로의 존재에 대해서 몰라도 상관이 없다.
또한 One to Many 패턴으로 Publisher가 데이터를 채널에 브로드캐스팅하면, Subscriber들은 자신이 원하는 채널만을 구독하여 데이터를 수락하게 된다. 만약 채널에 구독자가 없다면, 데이터들은 버려진다.
Producer - Consumer 패턴 에 비해서 결합도가 낮다.

웹과 관련해서 서버와 클라이언트는 상황에 따라서 달라질 수 있다.

웹페이지를 보는 관점 : 클라이언트 = 웹 브라우저 / 서버 = 웹 서버
웹 내 정보를 주고 받는 관점에서 : 클라이언트 = 결제 웹 서버 / 서버 = 유저 웹 서버
-> 유저 웹 서버에서 결제 웹 서버로 유저 정보(서비스)를 제공해주기 때문에

웹 클라이언트의 종류

웹 브라우저
특정 URI로 요청 가능. 그러나 항상 GET method로 요청된다.
Postman -> GUI (graphic user interface)
웹 브라우저와 달리 요청 method를 따로 지정할 수 있다.
curl -> CUI (character user interface)
역시 method를 따로 지정할 수 있지만, CUI이다.

웹 브라우저와 웹 서버간의 통신

웹 데이터
웹 페이지

웹 서버와 웹 서버 간의 통신

OPEN API (웹 데이터)
MSA

웹 서버 - 웹 서버 간의 통신에서는 일반적으로 웹 페이지는 교환하지 않는다.
서버와 서버 간의 소통에서는 일반적으로 웹 데이터를 주고 받는다.
웹 브라우저는 웹 페이지를 읽거나 분석할 수 있다 (웹 페이지의 *리더기 *역할)

서버를 그러한 역할이 따로 존재하지 않기 때문에 웹 페이지를 주고 받는 경우는 거의 없을 것이다.

클라이언트가 서버1에 웹페이지 요청 -> 서버1이 서버2에게 웹페이지 요청 -> 서버2가 서버1에 웹페이지 응답
-> 서버1이 클라이언트에게 웹페이지 응답
이러한 경우라면 가능하겠지만 거의 드물다.

웹 브라우저는 CORS 취약성이 존재하기 때문에, 서버 - 브라우저 간 통신에서는 CORS 문제가 고려된다.
다만 웹 서버에는 CORS 취약성 x. 웹 서버 - 웹 서버 간의 통신에는 cors 고려하지 않아도 된다.

CORS 문제

CORS 문제는 프론트엔드 - 백엔드 서버가 서로 다르기 때문에 발생하는 문제이다. 데이터의 출처가 다르므로 신뢰할 수 없는 문제
이 문제는 same origin policy (sop)가 2011년 RFC 6454에서 처음 등장한 이후로 더 심각해졌다.
CORS 자체는 2009년 용어가 생겼으나 정책이 생기며 CORS 에러를 호소하는 개발자들이 많아짐

출처 비교 방법

다음 세 가지를 비교하여 모두 같은 경우 동일 출처로 간주한다.

Scheme
Host
Port

웹 페이지

웹 페이지는 고정된 형태를 가진다. 웹의 본질에서 설명했듯 초기 웹은 정보 교환과 공동 연구 목적으로 사용되었다.

논문의 경우 일정한 형식을 가진다.
제목, 소제목, 목차, 인용 등의 형식을 가지기 때문에 모든 문서들은 고정된 형태 안에서 작성이 가능하다.

현재는 요청과 응답을 위해 인터넷과 함께 사용된다.
웹 브라우저(클라이언트) 는 웹 서버 에 웹 페이지를 요청 함

HTML

고정된 형태를 가진 웹 페이지를 작성하기 위해서 사용하는 것이 바로 HTML
*이다. HTML은 Hyper Text Markup Language 의 약어로, Hyper Text는 문서 간에 *링크(하이퍼링크)로 연결되어 이동할 수 있음을 의미하고, Markup Language 는 특정 형식을 가진 언어임을 의미한다.

즉, HTML = 인용 + 고정된 형식

기타) 마크다운 -> 마크업의 파생언어. 태그를 쓰지 않는 간단한 문법. velog, notion, github 등에서 사용된다.

CSS

Cascading Style Sheets
cascading = 종속 우선 순위를 가짐
우선순위는 선택자(selector)와 명시도(specificity)로 결정된다.

CSS 작성 방법

각 속성은 ; 로 구분한다.

head 태그 하위에 style 태그를 입력하여 내부에서 CSS를 작성.

<!-- html 파일. -->
  <html>
    <head>
      <!-- ... --->
      <link rel="stylesheet" href="./style.css"/>
    </head>
    <body>
      <!-- ... --->
      <h1>Example</h1>
    <body>
  </html>

head 태그 하위에 별도의 CSS 파일 link를 입력

 /* css 파일. 파일 명 style.css */
 h1 {
   color: blue
  }

인라인 스타일
body 태그 하위의 태그 중 CSS를 적용하고자 하는 태그 내부에서 다음과 같이 작성.

<html>
  
  <head>
  <!-- ... --->
  </head>
  
  <body>
    <!-- ... --->
    <h1 style="color: blue;">Example</h1>
  <body>

</html>

CSS-in-JS
JS 안에서 CSS를 작성한다. 리액트 프레임워크 내에서 styled-components import 후 사용 가능.
```
import styled from 'styled-components';
let Title = styled.div`
    border-color: blue;
    `;
```

CSS 선택자 종류

CSS 선택자는 세가지가 존재한다.

태그 선택자
HTML 태그를 선택자로 사용
ex) pre
클래스 선택자
태그에 지정해둔 클래스를 선택자로 사용
. 기호를 사용한다.
ex) 클래스명이 container인 경우, .container
id 선택자
태그에 지정해둔 id를 선택자로 사용
# 기호를 사용한다.
ex) id가 username-label인 경우, #username-label

우선순위

명료하게 정의될 수록(specific할수록) 우선순위가 높다.

같은 선택자에 대해서 여러개의 css를 적용하는 경우, 뒤에 오는 것이 우선순위가 더 높다.
부모에 지정한 css보다 자식에 지정한 css가 우선순위가 더 높다.
넓은 범위보다 좁은 범위에 지정한 css가 우선순위가 더 높다.
태그 선택자 > 클래스 선택자 > id 선택자 > 인라인 스타일
오른쪽으로 갈 수록 범위가 좁아지며, 우선 순위가 높다.
인라인 스타일은 태그 내부에서 css를 작성한 것이다.

Javascript

자바스크립트는 DOM 조작을 한다.
DOM(Document Object Model)은 HTML 조작을 위한 API이다.
필드와 메서드를 가지는 객체를 조작하기 때문에 DOM이라는 이름이 붙었다.
DOM을 조작하면, 화면에 보여지는 웹 페이지 내부의 HTML이 조작된다.

캐시

클라이언트 <-> 웹 브라우저 <-> 웹 서버

클라이언트가 http 요청을 하게 되면, 웹 브라우저는 해당 요청을 서버에게 전달한다. 그리고 서버는 요청에 따른 응답을 웹 브라우저에게 전달하고, 웹 브라우저는 해당 응답을 클라이언트에게 전달한다.

웹 브라우저는 네트워크 비용을 아끼고 성능을 높이기 위해 최적화를 하는데, 그 방법론이 캐시(Cache)이다.

매번 서버로 웹 페이지를 요청하는 대신 이전에 요청해둔 응답을 캐시에 저장해서 클라이언트로부터 같은 요청이 들어오면 캐시에 저장해둔 웹 페이지를 반환한다.

728x90

'ASAC' 카테고리의 다른 글

[ASAC 06] SEO, 웹 페이지 성능 Core Web Vital (1)	2024.08.27
[ASAC 06] 네트워크, DNS (0)	2024.08.27
[ASAC 06] MSA와 API Gateway (0)	2024.08.27
[ASAC 06] GraphQL (0)	2024.08.27
[ASAC 06] REST API (0)	2024.08.27

기억 못 할 거면 기록이라는 좋은 수단이 있다

[ASAC 06] 웹

웹을 배우는 이유

PWA

네이티브 앱과의 차이

장점

단점

웹 개발

프론트엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

웹 기초 이해 필요
3. 백엔드 개발자

백엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

웹 기초 이해 필요

인프라스트럭쳐 이해 필요

웹의 본질

요청-반환 방법

웹 브라우저

서버와 클라이언트

웹 클라이언트의 종류

웹 브라우저와 웹 서버간의 통신

웹 서버와 웹 서버 간의 통신

CORS 문제

출처 비교 방법

웹 페이지

HTML

CSS

CSS 작성 방법

CSS 선택자 종류

우선순위

Javascript

캐시

'ASAC' 카테고리의 다른 글

티스토리툴바

[ASAC 06] 웹

웹을 배우는 이유

PWA

네이티브 앱과의 차이

장점

단점

웹 개발

프론트엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

웹 기초 이해 필요3. 백엔드 개발자

백엔드 개발자가 소통하는 주체들

비즈니스 이해 필요

웹 기초 이해 필요

인프라스트럭쳐 이해 필요

웹의 본질

요청-반환 방법

웹 브라우저

서버와 클라이언트

웹 클라이언트의 종류

웹 브라우저와 웹 서버간의 통신

웹 서버와 웹 서버 간의 통신

CORS 문제

출처 비교 방법

웹 페이지

HTML

CSS

CSS 작성 방법

CSS 선택자 종류

우선순위

Javascript

캐시

'ASAC' 카테고리의 다른 글

관련글

티스토리툴바

웹 기초 이해 필요
3. 백엔드 개발자