Web

Position

Frontend

프론트엔드는 웹 애플리케이션 또는 웹사이트의 사용자 인터페이스(UI)와 사용자 경험(UX)을 구축하는 영역을 말합니다. 이는 사용자가 직접 상호 작용하는 부분으로, 웹 페이지의 레이아웃, 디자인, 콘텐츠 표시 등을 담당합니다. 프론트엔드 개발자는 HTML, CSS, JavaScript 등을 사용하여 웹 페이지를 만들고, 이를 통해 사용자가 웹 애플리케이션과 상호 작용할 수 있도록 합니다.

최근에는 프론트엔드 개발에서도 다양한 프레임워크와 라이브러리가 등장하면서, 보다 효율적이고 강력한 웹 애플리케이션을 구축할 수 있게 되었습니다. 대표적으로 React, Angular, Vue.js 등이 있으며, 이들을 사용하면 웹 애플리케이션의 개발과 유지 보수가 더욱 용이해집니다.

Backend

백엔드는 웹 애플리케이션 또는 웹사이트의 뒷단을 담당하는 영역을 의미합니다. 사용자가 웹 페이지에서 요청하는 작업을 처리하고, 데이터베이스와 상호 작용하여 필요한 정보를 제공합니다. 이러한 작업들은 사용자에게는 보이지 않지만, 웹 애플리케이션의 핵심적인 기능과 데이터 처리를 담당합니다.

백엔드 개발은 다양한 프로그래밍 언어와 프레임워크를 사용하여 이루어집니다. 주로 사용되는 언어로는 Python, Java, Ruby, PHP, JavaScript(Node.js) 등이 있으며, 이들 언어를 기반으로 하는 다양한 프레임워크와 라이브러리가 개발되어 백엔드 개발을 보다 효율적으로 할 수 있게 됐습니다.

백엔드 개발자는 클라이언트의 요청을 받아들이고, 그에 맞게 서버 측에서 데이터 처리, 비즈니스 로직 실행, 데이터베이스 조회 및 업데이트 등을 수행합니다. 또한 보안, 성능 최적화, 사용자 인증 및 권한 부여와 같은 측면도 백엔드 개발자가 고려해야 할 중요한 요소입니다.

REST

REST(Representational State Transfer)는 웹 서비스를 위한 아키텍처 스타일 중 하나로, 네트워크 상에서 자원을 표현하고 상태를 전이시키기 위한 일련의 제약 조건과 원칙을 제공합니다. REST는 Roy Fielding의 박사학위 논문에서 처음으로 소개되었으며, HTTP 프로토콜을 기반으로 구현되는 것이 일반적입니다. REST는 웹 서비스를 간소하고 확장 가능하게 만들어주며, 다양한 플랫폼 간의 상호 운용성을 제공합니다.

REST의 주요 특징과 원칙은 다음과 같습니다:

자원 (Resources): 모든 것은 자원으로 표현되며, 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별됩니다. 예를 들어, 웹 서비스의 사용자, 제품, 주문 등이 각각의 자원이 될 수 있습니다.
표현 (Representation): 자원은 여러 가지 형태로 표현될 수 있습니다. 일반적으로 JSON 또는 XML 형식을 사용하여 데이터를 표현하며, 클라이언트는 이러한 표현을 통해 자원의 상태를 이해하고 조작합니다.
상태 전이 (State Transfer): 클라이언트와 서버 간의 통신은 자원의 상태를 전이시키는 것입니다. 이는 주로 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 이루어지며, 각 메서드는 특정한 의미와 목적을 가지고 있습니다.
표준 인터페이스 (Uniform Interface): RESTful 시스템은 통일된 인터페이스를 가져야 합니다. 이를 위해 자원 식별, 메시지 교환을 위한 표준 연산, 자원 상태 전이에 사용되는 표준 메서드가 정의되어 있습니다.
무상태성 (Stateless): 각 요청은 서버에 저장된 세션 정보를 사용하지 않고, 요청 간에 상태가 저장되지 않습니다. 각 요청은 독립적으로 처리되며, 서버는 요청을 이해하고 처리하기 위한 모든 정보를 요청 자체에 포함합니다.
계층 구조 (Layered System): 시스템은 계층적으로 구성될 수 있으며, 각 계층은 특정 역할을 수행합니다. 이는 시스템의 확장성과 유연성을 향상시킵니다.

RESTful API

RESTful API(Representational State Transferful Application Programming Interface)는 REST 아키텍처 원칙을 따르는 웹 서비스 API입니다. RESTful API는 네트워크 상에서 자원을 표현하고 상태를 전이시키는 데에 일련의 규칙과 원칙을 적용하여 구현되어 있습니다.

CORS

출처 (Origin)

출처(Origin)는 3가지로 구성됩니다.

프로토콜(Protocol), 호스트(Host), 포트(Port)

위의 3가지가 모두 일치하면 같은 출처로 판단됩니다.

예: 도메인 주소 = https://www.google.com
프로토콜: 'https://'
호스트: 'www.google.com'

SOP (Same Origin Policy)

동일 출처 정책(Same Origin Policy, SOP)은 웹 애플리케이션은 자기 자신과 동일한 출처를 가진 리소스만 사용할 수 있다는 정책입니다.

만약 어떤 웹 애플리케이션이 다른 출처의 서버 리소스에 제한 없이 접근할 수 있다면 보안 문제가 발생할 수 있습니다. 그러므로 SOP을 적용하는 것은 보안 측면에서 중요합니다.

하지만 웹 개발에서 다른 출처를 가진 리소스를 사용하는 것은 흔한 일이며, 출처가 다르다는 이유로 차단된다면 불편할 수 있습니다. 그래서 모든 리소스가 SOP에 적용되지는 않으며, 주로 유효성은 다음을 통해 판단됩니다.

일부 리소스는 SOP의 제한을 받지 않습니다.
- 이미지 파일, CSS 파일, JS 스크립트 파일 요청 등
그 외 리소스는 CORS 정책으로 유효성을 판단합니다.

CORS (Cross-Origin Resource Sharing)

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처를 가진 자원에 접근할 수 있는 권한을 부여하는 정책입니다.

CORS의 동작 방식을 간단하게 설명하면 다음과 같습니다.

웹 애플리케이션은 다른 출처의 리소스를 요청할 때, 요청 헤더의 Origin 필드에 자신의 출처를 기록합니다. (예: Origin = https://www.google.com)
서버는 응답 헤더의 Access-Control-Allow-Origin 필드에 "이 리소스에 접근하는 것이 허용된 출처"를 기록합니다.
브라우저는 서버로부터 받은 응답의 Access-Control-Allow-Origin과 자신이 보낸 요청의 Origin을 비교하여 응답의 유효성을 확인합니다.
- 이때 브라우저가 서버 응답을 유효하지 않다고 하면 CORS 정책이 위반된 것으로 판단됩니다.

CORS 정책 위반 문제

웹 개발을 하다보면 CORS 정책 위반 문제를 마주칠 수 있습니다. 특히 로컬에서 테스트할 때 자주 발생합니다.

서버

CORS를 직접적으로 우회하는 것은 쉽지 않습니다. CORS는 보안 문제를 해결하는 중요한 정책이며, CORS 정책의 판단은 주로 브라우저가 수행하기 때문입니다.

가장 좋은 방법은 서버에서 CORS 정책에 맞게 적절한 Access-Control-Allow-Origin을 설정하는 것입니다. 해당 필드에 애플리케이션의 요청 Origin 값을 대입하면 됩니다.

Access-Control-Allow-Origin: https://www.google.com

로컬

에러 메시지 예시: Access to audio at 'test.mp3' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.

애플리케이션을 로컬로 실행하고 로컬 파일 리소스를 요청할 때 Origin이 null로 설정되어 있다면 CORS 정책 위반이 발생합니다.

이 문제는 애플리케이션을 로컬 서버로 실행하면 해결할 수 있습니다.

Storage

쿠키(Cookie)

쿠키는 웹 서버와 웹 브라우저 간에 상태 정보를 저장하는 작은 데이터 조각입니다. 웹 서버는 클라이언트에게 쿠키를 보내고, 클라이언트는 이를 저장합니다. 그리고 이후에 같은 서버로 다시 요청을 보낼 때마다 해당 쿠키를 함께 전송합니다.

쿠키는 주로 세션 관리, 개인화된 경험 제공, 사용자 추적 및 기타 웹 사이트의 필요한 정보 저장 등 다양한 용도로 사용됩니다. 일반적으로 쿠키에는 다음과 같은 정보가 포함될 수 있습니다:

세션 관리: 세션 ID와 같은 인증 정보를 저장하여 사용자의 로그인 상태를 유지합니다.
사용자 설정: 사용자가 웹 사이트에서 설정한 환경 설정이나 선호도와 같은 정보를 저장합니다.
트래킹: 사용자의 행동을 추적하고 분석하기 위해 사용될 수 있습니다.
장바구니: 온라인 쇼핑 사이트에서 사용자의 장바구니에 담긴 상품 정보를 저장합니다.

브라우저는 쿠키를 일반적으로 디스크에 저장하는데, 이를 통해 사용자가 웹 사이트를 떠나고 나중에 돌아왔을 때에도 이전에 설정된 쿠키가 유지될 수 있습니다. 그러나 브라우저의 정보를 초기화하면 이러한 쿠키 데이터도 함께 삭제됩니다.

세션(session)

세션(session)은 웹 애플리케이션에서 사용자의 상태를 유지하기 위한 메커니즘입니다. HTTP 프로토콜은 기본적으로 stateless(무상태)이므로, 사용자의 상태를 유지하는 데 어려움이 있습니다. 세션은 이러한 문제를 해결하기 위해 도입된 개념입니다.

세션은 일반적으로 서버 측에서 사용자의 상태 정보를 저장하고, 클라이언트에게 세션 ID를 부여합니다. 사용자가 서버에 요청을 보낼 때마다 세션 ID를 함께 전송하여 서버가 해당 사용자를 식별하고 이전 요청에서 저장된 상태 정보를 가져올 수 있습니다.

세션은 보통 다음과 같은 상황에서 사용됩니다:

인증: 사용자 로그인 상태를 유지하고 로그인 정보를 저장합니다.
상태 유지: 사용자의 활동 상태를 추적하고 장바구니, 임시 데이터 등의 정보를 저장합니다.
보안: 중요한 정보를 클라이언트에 저장하는 것보다 서버 측에 저장하여 보안을 강화합니다.

쿠키 vs 세션

이론적으로는 쿠키에 모든 정보를 담고 있다면 세션이 필요 없을 것입니다. 그러나 실제로는 다음과 같은 이유로 세션이 여전히 사용됩니다:

보안: 쿠키는 클라이언트 측에서 관리하므로 보안에 취약할 수 있습니다. 반면에 세션은 서버에서 관리되기 때문에 보안적으로 더 안전합니다. 중요한 정보나 인증 토큰과 같은 민감한 데이터를 쿠키에 저장하는 대신 세션에 저장하여 보안을 강화할 수 있습니다.
용량 제한: 쿠키에는 일반적으로 용량 제한이 있습니다. 브라우저마다 쿠키의 최대 크기가 다르지만, 대부분의 경우 작은 용량으로 제한됩니다. 따라서 많은 양의 데이터를 저장해야 하는 경우 세션을 사용하는 것이 더 효율적입니다.
사용자 경험: 세션을 사용하면 사용자가 로그인한 상태를 유지할 수 있으며, 이를 통해 사용자 경험을 향상시킬 수 있습니다. 사용자가 웹 사이트를 떠나더라도 세션을 유지하여 재방문 시 로그인을 다시 요청하지 않아도 됩니다.

쿠키와 세션은 용도에 맞게 사용되며, 같이 사용할 수도 있습니다. 예를 들어, 쿠키에 세션 ID를 저장하여 필요할 때마다 서버로부터 세션 정보를 가져올 수 있습니다.

OAuth(Open Authorization)

OAuth(Open Authorization)는 웹 및 모바일 애플리케이션을 위한 개방형 표준 인증 프로토콜입니다. OAuth는 보안을 강화하고 사용자의 리소스에 대한 제어를 사용자에게 부여함으로써 개인정보 보호를 강화하는 데 도움이 됩니다. 또한 OAuth를 통해 사용자가 여러 애플리케이션을 사용할 때마다 각 애플리케이션에 사용자 이름과 비밀번호를 제공하지 않고도 로그인할 수 있습니다.

일반적으로 OAuth는 다음과 같은 시나리오에서 사용됩니다:

사용자 인증: 사용자는 애플리케이션에 로그인할 때 OAuth를 사용하여 자신의 신원을 확인합니다.
권한 부여: 사용자는 애플리케이션이 특정 리소스(예: 프로필 정보, 연락처, 이미지 등)에 액세스할 수 있는 권한을 부여합니다.
액세스 토큰 발급: 인증 서버는 사용자의 동의를 받은 후, 애플리케이션에 대한 액세스 토큰을 발급합니다.
액세스 토큰을 사용한 리소스 액세스: 애플리케이션은 발급받은 액세스 토큰을 사용하여 사용자의 리소스에 액세스하고 작업을 수행합니다.

액세스 토큰

액세스 토큰(Access Token)은 사용자의 인증 상태를 나타내는 문자열입니다. 사용자가 성공적으로 인증되면 인증 서버에서 액세스 토큰이 발급됩니다. 이 토큰은 보통 짧은 기간(일반적으로 몇 시간) 동안 유효하며, 애플리케이션이 특정 API를 사용하거나 사용자의 리소스에 대한 작업을 수행하는 데 사용됩니다. 액세스 토큰을 통해 인증된 사용자에게만 특정 리소스에 대한 액세스 권한이 부여됩니다.

리프레시 토큰

리프레시 토큰(Refresh Token)은 액세스 토큰의 갱신을 위해 사용됩니다. 일반적으로 액세스 토큰은 유효 기간이 짧기 때문에, 유효 기간이 만료되면 새로운 액세스 토큰을 얻기 위해 리프레시 토큰이 사용됩니다. 리프레시 토큰은 일반적으로 긴 유효 기간을 가지며, 리프레시 토큰을 사용하여 액세스 토큰을 갱신하면, 사용자는 로그인 상태를 유지한 채로 애플리케이션을 계속 사용할 수 있습니다. 리프레시 포튼은 보안적인 이유로 사용자의 기기에 저장되어야 합니다.

JWT

**JWT (JSON Web Token)**는 JSON 포맷을 사용하여 정보를 안전하게 표현하고 전송하기 위한 개방형 표준(RFC 7519)입니다. JWT는 주로 인증 및 권한 부여 목적으로 사용되며, 액세스 토큰으로 자주 활용됩니다.

장점

확장성: 상태 비저장이므로 서버 확장이 쉽습니다.
보안: 서명으로 무결성을 보장합니다.
효율성: 페이로드에 필요한 정보를 포함하므로 추가 조회가 필요 없습니다.

단점

크기: JWT는 자체적으로 정보를 포함하므로 크기가 클 수 있습니다.
무효화 어려움: 한 번 발급된 JWT는 만료 전까지 무효화하기 어렵습니다.
보안 위험: 서명이 유출되면 토큰이 위조될 위험이 있습니다.

JWT는 세 부분으로 구성된 문자열입니다. 세 부분을 Base64Url로 인코딩한 뒤, 점(.)으로 연결하여 최종 JWT가 만들어집니다.

Header

JWT의 타입과 서명 알고리즘 정보를 포함합니다.

alg: 서명에 사용된 알고리즘 (예: HS256, RS256)
typ: 토큰의 타입 (일반적으로 JWT)

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (페이로드)

사용자 정보 및 클레임(Claims)을 담고 있는 부분입니다. 클레임은 JWT에서 데이터를 표현하는 방식이며, 크게 세 가지로 나뉩니다: 4. 등록된 클레임 (Registered Claims): - 사전에 정의된 표준 클레임. - 예: iss (발급자), sub (주제), aud (대상), exp (만료 시간), iat (발급 시간). 5. 공개 클레임 (Public Claims): - 사용자 정의 데이터. - 예: 사용자 이름, 이메일 등. 6. 비공개 클레임 (Private Claims): - 발급자와 소비자 간에 정의된 데이터.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1672531200
}

Signature (서명)

JWT의 무결성을 보장하는 부분입니다. 헤더와 페이로드를 합친 후 비밀 키를 사용하여 서명을 생성합니다.

서명 생성 방식:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

세션 vs JWT

특징	세션	JWT
상태 관리	서버에서 상태 저장	클라이언트가 상태 정보 포함
확장성	서버 부담 증가	서버 부담 적음, 분산 시스템 적합
보안	세션 ID 보호 필요	서명으로 위조 방지, 민감 정보 주의
유효성 관리	서버에서 세션 만료 처리 가능	토큰 만료 전까지 유효
사용 사례	전통적인 웹 애플리케이션	RESTful API, 모바일/분산 환경

세션을 사용하는 것이 적합한 경우

상태를 서버에서 관리해야 하는 경우:
- 서버에서 세션을 관리하고, 유효성을 제어하기 쉬운 구조가 필요할 때.
- 예: 전통적인 웹 애플리케이션, 서버에서 사용자 상태를 자주 업데이트하거나 확인해야 하는 경우.
보안이 중요한 경우:
- 세션은 서버에서 상태를 관리하므로, 민감한 정보를 클라이언트에 노출하지 않습니다.
- 예: 민감한 금융 서비스나 내부 애플리케이션.
사용자 수가 적거나 서버 확장이 필요하지 않은 경우:
- 서버가 충분한 리소스를 가지고 있고, 세션 저장소 관리가 간단한 경우.

JWT를 사용하는 것이 적합한 경우

확장성과 분산 시스템이 중요한 경우:
- JWT는 클라이언트에 상태를 저장하므로, 서버 간 상태 동기화가 필요하지 않습니다.
- 예: 마이크로서비스 아키텍처, 서버리스 환경, 글로벌 사용자 기반.
RESTful API 또는 모바일 환경:
- 클라이언트가 API를 호출할 때마다 상태를 서버에 저장하지 않고도 인증을 유지할 수 있습니다.
- 예: 모바일 앱, SPA(Single Page Application).
서버 부담을 줄이고 싶을 때:
- 세션 저장소를 유지하지 않아도 되므로 서버 리소스가 절약됩니다.
토큰 기반 인증이 필요한 경우:
- JWT는 자체적으로 인증 정보를 포함하므로, 외부 인증 시스템과 통합하기 쉽습니다.

웹소켓

웹소켓(WebSocket)은 웹 애플리케이션에서 양방향 통신을 가능하게 해주는 프로토콜입니다. HTTP와 비교했을 때, 웹소켓은 지속적인 연결을 유지하면서 클라이언트와 서버 간에 실시간으로 데이터를 주고받을 수 있게 합니다.

양방향 통신
- 웹소켓은 클라이언트와 서버가 서로 데이터를 주고받을 수 있는 연결을 제공합니다. 이는 HTTP와 달리, 서버에서 클라이언트로 직접 데이터를 보낼 수 있다는 장점이 있습니다. HTTP는 기본적으로 클라이언트가 서버에 요청을 보내면 서버가 응답하는 방식으로 동작하지만, 웹소켓은 서버가 클라이언트에게 실시간으로 정보를 보낼 수 있게 해줍니다.
지속적인 연결
- HTTP는 요청을 보낼 때마다 연결이 열리고 닫히기 때문에 단발성입니다. 반면, 웹소켓은 한 번의 연결을 통해 클라이언트와 서버가 지속적으로 데이터를 주고받을 수 있습니다. 이 연결은 클라이언트와 서버가 명시적으로 끊을 때까지 계속 유지됩니다.
저지연, 빠른 실시간 통신
- 웹소켓은 데이터 전송의 지연 시간이 매우 짧고, 실시간 통신에 최적화되어 있습니다. 일반적으로 HTTP 방식보다 훨씬 빠른 데이터 처리가 가능합니다.
헤더가 간단하고 효율적
- 웹소켓은 연결을 설정할 때만 HTTP를 사용하여 연결을 초기화합니다. 그 이후에는 HTTP의 헤더를 사용하지 않고, 최소한의 데이터만으로 메시지를 전송합니다. 따라서 네트워크 대역폭을 절약할 수 있고, 통신이 효율적입니다.

연결 과정

클라이언트가 웹소켓 연결 요청을 보냅니다. 이는 HTTP 프로토콜을 통해 "Upgrade" 헤더를 사용하여 웹소켓 연결을 요청하는 방식입니다.
서버가 이를 승인하면, HTTP 연결이 웹소켓 프로토콜로 업그레이드되고, 이후에는 웹소켓을 통해 양방향 통신이 이루어집니다.
서버와 클라이언트는 지속적인 연결을 유지하면서, 언제든지 서로 데이터를 전송할 수 있습니다.
연결을 종료하려면 클라이언트나 서버가 "Close" 메시지를 보내어 연결을 종료합니다.

웹소켓 vs HTTP

HTTP: 요청-응답 방식으로, 클라이언트가 요청을 보내면 서버가 응답을 반환하는 방식입니다. 각 요청마다 연결이 이루어지며, 연결이 종료되면 다시 연결을 맺어야 합니다.
웹소켓: 클라이언트와 서버가 한 번 연결을 맺으면 그 후로 계속 데이터를 주고받을 수 있습니다. 이 연결은 종료될 때까지 계속 유지됩니다.

선택:

HTTP:
- 요청-응답 방식의 단발성 통신이 필요한 경우 (예: REST API, 정적 리소스 제공).
- 데이터 요청이 많지 않거나 저지연을 요구하지 않는 경우.
- => 대용량 메시지, 보안이 중요한 경우, 응답 구조가 간단한 경우
웹소켓:
- 실시간 양방향 통신이 필요한 경우
- 클라이언트와 서버 간의 지속적인 연결을 통해 즉각적인 데이터 전달이 필요한 경우.
- 서버가 많은 요청을 동시에 처리해야 할 때 지속적인 연결을 활용하여 효율적으로 처리할 수 있음.
- => 작은 메시지, 보안이 덜 중요한 경우, 실시간 처리 필요

HTTP와 웹소켓을 혼합해서 사용하는 방식이 가장 효율적일 수 있습니다.

HTTP는 사용자 인증, 데이터 조회와 같은 전통적인 요청 처리에 사용하고,
웹소켓은 실시간 알림, 게임 내 이벤트, 채팅 등 실시간 데이터 흐름이 중요한 부분에 사용하면 좋습니다.

활용 예시

웹소켓은 실제 업계에서 실시간 통신이 필요한 다양한 분야에서 많이 사용되고 있습니다. 특히 실시간 데이터를 빠르게 주고받아야 하는 서비스에서는 웹소켓이 필수적인 기술로 자리잡고 있습니다.

실시간 게임

온라인 게임에서는 실시간 상호작용이 필수적입니다. 특히 멀티플레이어 게임에서는 플레이어 간 실시간 데이터 전송이 필요합니다. 예를 들어, 점수, 위치 정보, 아이템 획득 등을 실시간으로 전송해야 하므로, 웹소켓이 사용됩니다.
롤(League of Legends), 포트나이트(Fortnite), 카운터 스트라이크(CS:GO) 같은 대형 게임에서도 게임 서버와 클라이언트 간 실시간 데이터 전송에 웹소켓을 사용합니다.

채팅 애플리케이션

실시간 메시징은 웹소켓의 주요 사용 사례 중 하나입니다. 카카오톡, 슬랙, 텔레그램, 디스코드 같은 채팅 애플리케이션에서는 실시간으로 메시지를 주고받기 위해 웹소켓을 사용합니다.
웹소켓을 사용하면 메시지 전송 지연을 최소화할 수 있어, 채팅 시스템의 효율성과 사용자 경험을 크게 향상시킵니다.

주식/금융 대시보드

금융 서비스에서는 실시간으로 주식 가격, 환율, 시장 변동 등 실시간 데이터를 사용자에게 전송하는 것이 중요합니다. 웹소켓은 이러한 데이터를 효율적으로 전송하는 데 사용됩니다.
예를 들어, 로빈후드(Robinhood), E*TRADE, **웹플러스(WeBull)**와 같은 주식 거래 플랫폼에서도 웹소켓을 사용하여 실시간 가격 변동을 제공합니다.

실시간 협업 도구

Google Docs, Microsoft Office 365와 같은 협업 툴에서는 여러 사용자가 실시간으로 문서를 편집할 수 있도록 웹소켓을 사용합니다.
실시간으로 동기화되는 문서 편집, 채팅, 작업 상태 공유 등을 지원하는 시스템에서 웹소켓이 핵심 기술로 사용됩니다.

알림 시스템

푸시 알림 시스템에서도 웹소켓을 사용할 수 있습니다. 웹소켓을 통해 앱에서 발생한 업데이트, 알림, 경고 등을 실시간으로 사용자에게 전달할 수 있습니다.
예를 들어, Facebook이나 Twitter와 같은 소셜 미디어에서 알림 기능을 실시간으로 제공하는 데 웹소켓을 사용합니다.

트래킹 및 모니터링 시스템

실시간 트래킹 시스템에서도 웹소켓이 사용됩니다. 예를 들어, 택배 추적, 실시간 위치 추적, 운송 모니터링 시스템에서는 지속적인 위치 업데이트와 상태 변경을 실시간으로 받아야 하기 때문에 웹소켓을 활용합니다.
Uber, Lyft와 같은 택시/배달 서비스에서 운전자의 위치 업데이트 및 승객의 실시간 요청 처리를 위해 웹소켓을 사용합니다.

Files

Web.md

Latest commit

History