Unong's Story

AWS에 S3에 웹 호스팅 하는 방법

먼저 AWS를 검색해서 AWS 홈페이지에 방문한다.

aws 홈페이지 들어가자마자 프리 티어가 뜨는데 "무료 계정 생성" 버튼을 클릭해서 회원 가입을 해준다.

회원 가입을 하고 나면 아래 화면이 나오는데 주황 버튼을 눌러주면 된다.

오른쪽 맨 위에 나는 시드니로 설정되어 있어서 서울로 바꿔줬다.

이제 왼쪽 상단 검색창에 s3를 검색해서 들어가준다.

클릭하면 아래 화면이 나오는데 바로 "버킷 만들기"를 클릭한다.

이제 버킷 이름을 정해야 하는데 자기 상황에 맞게 정하면 된다.

나는 연습용이라 일단 unongweb으로 지었다.

나중에 바꿀 수 있기 때문에 너무 큰 걱정 안 해도 된다.

아래 친구는 그냥 두고

퍼블릭 액세스는 익명의 사용자가 내 버킷에 접근하고 조회하고 사용해도 괜찮은지 물어보는 것

나는 연습용이라 차단 설정을 해제해 봤다.

나머지 사항은 슈슈슉 넘기고 바로 "버킷 만들기"를 눌러줬다.

아래 화면이 나온다면 버킷 생성 완료!

이제 버킷 정책을 설정할 거다.

버킷 이름 (unongweb)을 클릭해서 권한 -> 버킷 정책 -> 편집

"편집" 버튼을 누르고

"새 문 추가" 버튼을 누른다.

편집을 누르면 AWS에서 기본적으로 제공하는 코드가 나오지만 무시하고

검색창에 S3를 검색해 클릭

검색창에 getobject를 검색하고

액세스 수준에 나오는 GetObject 체크박스 표시를 하면

왼쪽 코드에 뭐가 막 추가되어 있는 걸 확인할 수 있다.

오른쪽 메뉴에서 스크롤바를 내리면 "리소스 추가" 버튼이 나오는데 클릭

리소스 추가 모달창이 뜬다!

리소스 유형은 object로 해준다.

리소스 ARN은 Bucket Name에 내 버킷 이름 (unongweb)을 넣어주고

ObjectName에 파일 이름을 넣어 준다.

*은 모든 파일을 허용하겠다는 것!

"리소스 추가" 버튼을 눌러주면 다시 정책 페이지로 돌아오는데

Resource 부분이 추가된 걸 볼 수 있다.

Action(기능)을 Effect -Allow(허용) 할 건데

Principal(누구)에게 허용할 것인지 설정을 해줄 거다.

나는 모두에게 허용할 거라 Principal에 *을 넣어줬다.

이제 정책 설정이 끝났으니 오른쪽 하단에

"변경 사항 저장" 버튼을 눌러준다.

버킷 정책에 우리가 설정한 정책이 들어온 걸 확인할 수 있다.

이제 파일(객체)를 업로드해 줄 거다.

객체를 눌러주면 업로드를 할 수 있다.

나는 테스트용으로 index.html 파일을 만들어 두었다.

업로드하려는 파일을 "업로드" 버튼이 있는 쪽으로 끌고 온다.

그럼 아래 같은 화면이 나오는데 끌고 온 파일을 둔다.

그럼 이런 화면이 나오는데 "업로드" 버튼을 눌러준다.

업로드가 성공했다면 아래와 같은 화면이 나온다.

오른쪽 상단 "닫기" 버튼을 눌러준다.

이제 마지막으로 배포를 해볼 거다!

속성으로 이동을 해준 뒤,

스크롤바를 제일 하단으로 내리면 정적 웹 사이트 호스팅이 나온다.

오른쪽 "편집" 버튼을 눌러준다.

정적 웹 사이트 호스팅 "활성화" 버튼 눌러주고

인덱스 문서에 index.html을 넣어둔다.

(저 부분은 기본 페이지로 웹사이트 방문 시 제일 첫 페이지에 뜨는 부분이다.)

완료되었으면 하단 "변경 사항 저장" 버튼을 눌러준다.

변경 사항 저장 버튼을 누르고 다시 속성 페이지로 돌아왔는데

스크롤을 젤 하단으로 내려서 정적 웹사이트 호스팅으로 오면

하단에 링크가 생긴 걸 볼 수 있다.

링크를 복사해서 새 탭에 붙여넣기를 해보면

자신이 넣은 파일 내용이 잘 나온다면

배포가 잘 되었다는 것!

OAuth2.0

Open Authorization의 약자로,

개방형 인가의 표준이다.

=> 소셜 로그인 기능

소셜 로그인?

유저가 해당 웹사이트에 가입한 ID와 PW 대신 다른 사이트에 있는

유저 정보를 사용해 인증하는 기능

구성 요소

리소스 소유자(Resource Owner)

사용자의 보호된 정보(Resource)에 접근하도록 자격을 부여하는 사람

OAuth 사용자 = 리소스 소유자

클라이언트(Client)

Resource Server의 API를 사용하여 정보를 가져오려고 접근을 요청하는 애플리케이션

리소스 서버(Resource Server)

사용자의 보호된 정보(Resource)를 가지고 있는 서버

=> OAuth 서비스를 제공

인가 서버(Authorization Server)

인증/인가를 수행하는 서버로,

Client의 접근 자격을 확인해 Resource Server의 서비스를 사용할 수 있게 인증,

Access Token을 발급해 권한을 부여하는 서버

주요 용어

인가 코드(Authorization Code)

Client가 사용자를 대신해 인가 서버에 접근 권한을 요청할 때 발급받는 유효 기간이 짧은 코드,

Access Token을 발급받기 위해 사용

액세스 토큰(Access Token)

Resource Server에서 Resource Owner의 정보를 가져올 때 사용하는 만료 기간이 있는 토큰

리프레시 토큰(Refresh Token)

Access Token이 만료되었을 때 갱신하는 용도로 사용하는 토큰

일반적으로 Access Token보다 만료 기간이 더 길다.

인증(Authentication)

Resource에 접근 자격이 있는지 검증하는 과정

인가(Authorization)

자원에 접근할 권한을 부여하는 과정

OAuth의 흐름 과정

위 사진을 예시로 OAuth의 흐름을 알아보겠다.

1.Resource Owner(사용자)가 Client 접속

2. 사용자 인가 요청

Client가 사용자를 대신해 Authorization Server(인가 서버)에 인가 요청

3. 사용자 동의

인가 서버가 사용자에게 동의 여부 물어봄

4. Authorization Code(인가 코드) 발급

사용자가 동의하면 인가 서버가 Client에게 인가 코드 발급

5. Client → Server

인가 코드 전달

6. Server → Authorization Server(인가 서버)

인가 코드를 사용해 Access Token(액세스 토큰) 요청

7&8. 인가 서버에서 인가 코드 확인 후 액세스 토큰 발급

9. Server → Resource Server(리소스 서버)

액세스 토큰을 사용해 Resource(사용자 정보) 요청

10&11. 리소스 서버에서 액세스 토큰 확인 후 사용자 정보 제공

12. Server → Client

사용자 정보 전달

SOP(동일 출처 정책)

Same-Origin Policy의 약자로,

같은 출처의 리소스만 가져올 수 있어

동일 출처가 아니라면 브라우저가 막아버리는 것을 말한다.

동일 출처?

//https:unong_story:014

프로토콜, 도메인, 포트{80, 443 등 (기본 포트는 생략될 수 있음)}가 모두 같은 것

예시) 동일 출처

1.

URL 1: https://www.example.com/page1.html

URL 2: https://www.example.com/page2.html

URL 모두 https:// 프로토콜, www.example.com 도메인, 그리고 기본 포트 443(HTTPS)이 일치

2.

URL 1: http://www.example.com/index.html

URL 2: http://www.example.com/about.html

URL 모두 http:// 프로토콜, www.example.com 도메인, 기본 포트 80(HTTP)이 일치

한계

현대엔 시대의 흐름에 따라 웹 기술로 할 수 있는 것들이 많아졌고,

자연스럽게 다른 출처로 요청을 하고 응답을 받아오는 수요가 증가했다.

=> 다양한 출처에서 데이터를 안전하게 공유할 수 있도록 하는 방법이 필요

=> CORS 등장

CORS

Cross-Origin Resource Sharing의 약자로,

웹 브라우저는 보안상의 이유로 다른 출처에서의 리소스 접근을 제한,

이를 해제하고 특정 조건에서만 접근을 허용하기 위해 사용한다.

쉽게 설명하기 위해 react로 todo 공부를 하다 나온 콘솔 창을 가져와봤다.

Client : localhost:3000 (react 개발서버)

Server : localhost:4000

=> Client와 Server의 Origin(출처=포트 3000이랑 4000)이 다르다.

Client에서 Server의 데이터를 막 가져간다?

ex1.com에서 ex2.com의 데이터를 막 꺼내가려 한다

=> 안됨! Origion이 다르면 무조건 막는다.

이제 다른 출처에서 접근할 수 있게 허용하기 위해 CORS를 설정을 해보겠다.

CORS 설정 방법

서버에서 설정된 HTTP 헤더 작성

Access-Control-Allow-Origin

리소스에 접근할 수 있는 주소

=> 어떤 도메인(Origin)에서의 요청을 허용할지를 지정

*를 사용하면 모든 도메인에서 요청을 허용

Access-Control-Allow-Methods

클라이언트 → 서버로 요청할 때 사용할 HTTP 메소드

ex ) GET, POST, PUT, DELETE, OPTIONS 등...

Access-Control-Allow-Headers

클라이언트 → 서버로 요청할 때 사용할 HTTP 헤더

ex ) Content-Type, Authorization 등...

예시 ) GPT Express.js (Node.js)

Next.js?

SSR(서버 사이드 렌더링)

Server Side Rendering의 약자로,

서버 쪽에서 렌더링을 한다는 뜻

웹 사이트의 일부 또는 전체가 클라이언트로 전송되기 전에 서버 측에서 렌더링 되도록 하는 방식으로,

주로 사용자마다 페이지의 데이터가 변경되어야 하는 페이지에서 사용한다.

pre-rendering?

Next.js는 기본적으로 빌드 시에 만든 모든 페이지를 미리 렌더링 한다.

=> 사용자 경험 향상, 검색 엔진 최적화(SEO)

방식은 두 가지

SSG(Static-Site Generation)

빌드 타임에 HTML에 생성되어 요청이 들어올 때마다 재사용하게 해준다.

SSR(Server-Side Rendering)

요청이 들어올 때마다 HTML을 생성한다.

사진 출처 : 오즈코딩스쿨 리액트 강의

번들링(Bundling)?

여러 개의 파일을 하나의 파일로 합치는 것.

ex) html, css, javascript 등...

효과

- HTTP 요청의 수를 줄여 속도 향상

- 코드를 압축해 파일 크기 축소

- 사용되지 않는 코드 제거로 최적화

Vite -> Rollup

CRA -> Webpack

코드스플리팅(Code Splitting)이란?

코드를 여러 개의 작은 부분으로 나누는 것.

=> 파일을 분리하는 작업

​

효과

- 초기 로딩 속도 개선

- 불필요한 코드 로드 방지

- 데이터 비용 절감

- 번들 파일의 크기 줄임

React.lazy와 Suspense를 이용한 코드 스플리팅

대규모 애플리케이션에서 성능을 최적화하는 효과적인 방법으로,

사용자가 필요로 하는 컴포넌트만 로드하여 초기 로딩 시간을 줄이고

사용자 경험을 개선한다.

먼저 기존 작업 파일에 lazy 작업을 해준다.

lazy를 사용 시 컴포넌트가 필요한 시점에만 로드를 하는데

비동기적으로 로드하기 때문에 느리다.

Suspense를 사용해

lazy로 로드 된 컴포넌트가 로드되는 동안 보여줄 대체 UI를 표시해 준다.

모든 lazy 컴포넌트는 Suspense로 감싸져 있어야 한다.

Code Splitting을 통해 번들 크기를 줄이고, 초기 로딩 속도를 개선해 보자

우선 React.lazy before / after를 비교해 보겠다.

먼저 빌드를 해준다.

• 코드 번들링: 애플리케이션의 JavaScript, CSS, HTML 파일을 번들로 묶는다..
• 최적화: 코드 스플리팅, 트리 쉐이킹, 압축 등을 통해 성능을 최적화한다.
• 출력: 결과를 dist 디렉터리에 저장한다.

React.lazy before 보다 after가 js 파일이 훨씬 늘어난 게 보인다.

코드 스플리팅(Code Splitting)

Vite와 Rollup을 통해 빌드 과정에서 모듈을 청크로 나누는 설정.

vite.config.js 파일

plugins 아래에 아래 build 코드를 추가해 준다.

코드 스플리팅 결과

JavaScript 청크로 동적 import로 로드된 모듈과 외부 라이브러리를 포함한

여러 개의 JavaScript 파일이 생긴 걸 볼 수 있다.

useMemo

성능 최적화를 위해 사용되는 React 훅

컴포넌트가 리렌더링 될 때마다 계산된 값을 메모이제이션한다.

의존성 배열이 변경되지 않는 한 이전 계산 결과값을 재사용하며,

그렇지 않은 경우 기존 함수의 결과값을 그대로 반환한다.

=> 불필요한 계산 방지 & 렌더링 성능 개선

useCallback

함수를 메모이제이션하는 데 사용 & 성능 최적화를 위해 사용되는 React 훅

의존성 배열 중 하나라도 변경되면 메모이제이션된 콜백 함수 반환

=> 컴포넌트가 렌더링 될 때 불필요한 함수 재생성을 방지한다.

함수를 반환한다는 점에서 값을 반환하는 useMemo와 다르다.

메모이제이션(Memoization)?

useMemo와 useCallback 같은 메모이제이션 훅을 통해 최적화를 위해 사용

연산량이 많은 함수의 호출 결과를 저장해 두었다가, 같은 입력 값으로 함수를 호출하면

새로 함수를 호출하지 않고 이전에 저장해놨던 호출 결과를 바로 반환

=> 반환 시간 절약 & 불필요한 중복 연산 x

React.memo

React의 고차 컴포넌트(Higher-Order Component)

함수형 컴포넌트의 성능을 최적화하는 데 사용

React.memo는 props 변화에만 영향을 준다.

=>컴포넌트의 props가 변경되지 않는 한 리렌더링 x

props가 변경되지 않으면, React.memo는 이전의 렌더링 결과를 재사용한다.

자식 컴포넌트가 props에 의존하고, 부모 컴포넌트가 자주 렌더링 되는 경우 많이 쓴다.

요약

useMemo

함수 호출 결과 저장

계산된 값을 메모이제이션하고, 불필요한 재계산을 방지하는 방법

useCallback

함수 저장

함수가 불필요하게 새로 생성되지 않도록 최적화하는 방법

React.memo

컴포넌트 저장

컴포넌트가 props가 변경되지 않는 한 리렌더링되지 않게 하는 방법

Redux?

전역 상태 관리를 위한 라이브러리

모든 상태를 하나의 중앙 저장소(Store)에서 관리한다.

복잡한 데이터 흐름이나 상태 관리가 필요할 때 사용하면 좋다.

​

Redux 데이터 흐름

=> FLUX 패턴

만들어진 Action 객체는 Dispatch()로 전달되고

이 Dispatch()는 Reducer()로 Action 객체를 전달을 해준다.

Reducer는 Action 안에 있는 값을 해석해

Store에 담긴 상태를 업데이트한다.

변경된 상태에 맞춰 UI가 리렌더링 된다.

Action

상태를 어떻게 변화시킬 것인지

내용이 담겨있는 객체

액션 객체

액션 생성자

Dispatch

Action 객체를

Reducer로 넘겨주는 역할을 하는 함수

액션 객체

액션 생성자

Reducer

리턴하는 값이 새로운 상태가 되는 함수

Reducer가 여러 개면?

combineReducers()로

묶어서 하나로 만들 수 있음

Store

Redux의 전역 상태 저장소

createStore()에 Reducer를 전달해서 생성

구성 요소를 다 만든 후

React-Redux에서 제공하는 기능을 사용한다.

App과 전역 상태 저장소 연결

=> <Provider store={ store }>

상태 저장소에서 상태 꺼내서 사용

=> useSelector()

dispatch() 만들어서 사용

=> useDispatch()

Redux-Thunk?

Action으로 객체 말고도 함수를 사용할 수 있게 해주면서

Redux에서 비동기 처리를 할 수 있게 해주는 미들웨어

설치 방법

사용 방법

applyMiddleware(thunk)를 사용하여 redux-thunk를 Store에 적용

createStore 함수를 사용하여 스토어를 생성

store의

첫 번째 인자로 스토어의 상태를 관리할 Reducer를 가졌다면,

두 번째 인자로 redux-thunk 미들웨어를 스토어에 적용한다.

applyMiddleware를 가져와서

redux-thunk의 thunk를 applyMiddleware의 인자로 전달해 준다.

전역 상태 (Global State)

React 외부에서 상태를 관리하는 방법

프로젝트 전체의 상태 관리를 총괄하는 것이다.

전역에서 관리하기 때문에, 어떤 컴포넌트에서든 상태 값을 반영하고, 변경시키는 것이 가능하다.

ex)

Redux

Redux Toolkit

Recoil

MobXa

Zustand

Jotai

Redux & Redux Toolkit?

Redux

전역 상태 관리를 위한 라이브러리

모든 상태를 하나의 중앙 저장소(Store)에서 관리한다.

복잡한 데이터 흐름이나 상태 관리가 필요할 때 사용하면 좋다.

Redux Toolkit

초기 설정과 코드량이 많아질 수 있는 Redux를 보완하기 위해 만들어졌다.

코드 유지 보수성을 향상시킨다.

Redux & Redux Toolkit 사용법

Redux 설치방법

Redux Toolkit 설치방법

Counter 상태 관리 예시

로컬 상태 (Local State)

React 내부에서 상태를 관리하는 방법

특정 컴포넌트 내에서 데이터를 관리,

다른 컴포넌트와 공유되지 않는다.

ex)

useState

Context API

Context API?

props 대신 component tree를 통해 곧바로 컴포넌트에 전달하는 방식

props drilling을 회피하기 위한 용도로 사용한다.

다른 레벨의 많은 컴포넌트가 특정 데이터를 필요로 할 때 주로 사용한다.

Context API를 useState 및 useReducer를 함께 사용하는 편이다.

컴포넌트가 상태 관리를 공유할 수 있도록 트래킹을 도와주고, 실제 상태 변경은 useState 및 useReducer 등의 hook 이 진행한다.

Context API 사용법

먼저 Context를 생성해 주어야 한다.

createContext 함수를 사용한다.

Provider

Provider를 사용하여 생성한 context를 하위 컴포넌트들이 데이터를 받을 수 있도록 해준다.

Provider로 하위 컴포넌트들을 감싸주면

모든 하위 컴포넌트들이 Context에 접근 가능하다.

Consumer

value를 Provider의 하위 컴포넌트들에게 전달하면 하위 컴포넌트들은 이 값을 사용하는데,

데이터를 소비(구독) 한다는 의미를 가져 Consumer 컴포넌트다.

Consumer 컴포넌트 예시

++ useContext()

Consumer 컴포넌트보다 더 추천하는 방법이다.

useContext() 훅

: createContext() 함수 호출로 생성된 Context 객체를 인자로 받아

현재 Context 값을 리턴한다.

** useContext() 훅 사용 시 파라미터로 Context 객체를 넣어줘야 한다 **

useContext() 훅 예시