1. Web Service란?

인터넷을 매개로 컴퓨터와 컴퓨터가 정보를 주고받는 모든 형태의 서비스를 의미.
단순히 웹 브라우저(크롬, 사파리 등)로 접속하는 사이트뿐만 아니라,
특정 기능을 제공하는 API나 설치형 애플리케이션까지 포함하는 넓은 개념.

• 주요 특징
  • 플랫폼 독립성: 브라우저나 전용 앱을 통해 기기에 상관없이 접근할 수 있다.
  • 동시성: 여러 사용자가 동시에 접속하여 이용 가능하다.
• 서비스 예시:
  • 검색(Google)
  • SNS(Instagram)
  • 전자상거래(Amazon)
  • SaaS(Notion, Figma)
  • API 중심 서비스(지도, 결제 API) 등

cf) 인터넷 상의 웹 말고 다른 통신 방식

인터넷이라는 거대한 네트워크망 위에는 웹(HTTP) 외에도
목적에 따른 다양한 통신 규칙(프로토콜)이 존재

✉️ 이메일 서비스
이메일을 주고받기 위해 설계된 통신 방식

• SMTP(Simple Mail Transfer Protocol)란?
  • 메일을 송신하거나 서버 간에 전달할 때 사용
• POP3/IMAP?
  • 메일을 수신할 때 사용하는 규칙
  • 서버에서 메일을 가져오는 방식에 따라 구분

📁 파일 전송 서비스
대용량 파일을 안정적으로 전송하기 위한 방식

• FTP(File Transfer Protocol)
  • 파일을 올리고(업로드) 내려받는(다운로드) 규칙
  • SFTP는 여기에 'Secure(보안)'를 더해 내용을 암호화해서 전송하는
    더 안전한 버전

🎮 온라인 게임
리그 오브 레전드나 배틀그라운드 같은 게임을 할 때,
내가 쏜 총알이 적에게 맞았는지가 실시간으로, 아주 빠르게 반영되어야 한다.
이렇듯 실시간성이 중요한 게임 환경에서는
데이터의 완결성보다 속도가 우선시되기도 한다.

• UDP(User Datagram Protocol)
  • 수신 확인 절차를 생략하고 데이터를 빠르게 던지는 방식
  • 지연 시간이 적어야 하는 실시간 게임이나 스트리밍에 적합

📞 실시간 음성, 영상 통신
줌(Zoom)이나 페이스타임 같은 서비스. 이것 역시 끊김 없는 실시간성이 중요.

• WebRTC(Web Real-Time Communication)
  • 웹 브라우저끼리 중간 서버 없이 직접 영상/음성을 주고받게 해준다.
  • RTP는 그런 실시간 데이터를 전송하는 표준 프로토콜.

---

2. 웹의 기본 동작 원리

2.1. 요약

웹의 동작은 딱 이 한 문장으로 요약할 수 있다.

"클라이언트가 요청(Request)하고, 서버가 응답(Response)한다."

[그림 1] 웹 서비스의 기본 구조

2.2. 용어 정리

• 사용자(User): 서비스를 이용하는 주체인 사람

• 클라이언트(Client):

  • 사용자가 서비스를 요청하기 위해 사용하는 도구
  • 대표적으로 크롬이나 사파리같은 웹 브라우저, 혹은 스마트폰에 설치된 모바일 앱 등이 여기에 해당

• 인터넷(Internet):

  • 클라이언트와 서버가 서로 데이터를 주고받을 수 있도록 연결해 주는 거대한 통신망

• 서버(Server):

  • 요청을 받아 응답(response)하는 주체
  • 클라이언트의 요청을 처리하고 결과를 만들어내는 프로그램

• 데이터베이스(Database, DB):

  • 데이터를 저장·조회·관리하는 소프트웨어

• 요청(Request):

  • 클라이언트가 서버에 처리를 요구하기 위해 전달하는 메시지

• 응답(Response):

  • 서버가 요청 처리 결과로 돌려주는 메시지

• UI(User Interface):

  • 사용자가 직접 보고 조작하는 화면과 그 구성 요소

• API(Application Programming Interface):

  • 프로그램이 다른 프로그램의 기능을 사용하기 위한 약속된 인터페이스

2.3. 초기 인터넷 통신

• 목적

  • 원거리 컴퓨터 간의 연결과 데이터 전달

• 한계점

  • 여러 컴퓨터가 같은 데이터를 원함
  • 데이터를 중앙에서 관리할 필요 발생
  • 항상 응답해 줄 고정된 대상이 필요해짐

• 해결책

  • 데이터를 한 곳에 모으자
  • 항상 켜져 있으면서, 요청이 오면 응답해 주는 역할을 만들자
    (이 아이디어로 클라이언트 - 서버 모델이 만들어짐)

2.4. 클라이언트 - 서버 모델 등장

특징

• 역할이 명확히 분리된다(전문성 강화)

• 요청과 응답의 방향이 정해져 있다

  • 요청: 클라이언트 → 서버
  • 응답: 서버 → 클라이언트

• 여러 클라이언트가 하나의 서버를 사용할 수 있다

• 서버는 항상 대기하며 요청을 처리한다

• 서버에서 데이터와 기능을 중앙에서 관리한다(관리 효율성)

• 역할은 통신 상황에 따라 달라질 수 있다

  • 브라우저 → 웹 서버: 브라우저는 클라이언트 , 웹 서버는 서버
  • 웹 서버 → 데이터베이스 : 웹 서버는 클라이언트 , 데이터베이스는 서버

2.5. HTTP란?

이 클라이언트와 서버가 서로 통신할 때 사용하는 '공용어'

2.5.1. 개념

HTTP (HyperText Transfer Protocol)는
텍스트나 이미지 같은 정보(HyperText)를 전송하기 위한 규칙.
클라이언트가 "이거 줘!"라고 요청하면, 서버가 "여기 있어!"라고 응답하는
기본적인 통신 규칙인 셈.

• 구성
  • 이 메시지는 요청인지, 응답인지
  • 무엇을 요청하는지 (메서드)
  • 요청이 성공했는지 실패했는지 (상태 코드)
  • 데이터는 어떤 형식인지 (헤더, 본문)

2.5.2. HTTP 요청 보내기

# 응답의 header만 출력
curl -I (url)

# html 형식도 띄워줌
curl (url)

# 요청부터 응답까지의 모든 내용이 출력
curl (url) -v

• curl: HTTP 요청을 보내기 위한 커맨드라인 도구

2.5.3. HTTP 요청 메세지

🏗️ 크게 세 부분으로 구성된다.

• 시작 줄 (Start Line):

  • 어떤 동작을 원하는지(메서드),
  • 어디로 가는지(URL)
  • HTTP 버전이 무엇인지

• 헤더 (Header):

  • 메타데이터(Key: Value의 형태)
  • 메시지의 본문 크기, 브라우저 정보 등 부가적인 정보

• 본문 (Body):

  • 서버로 보내야 할 실제 데이터
    (optional. 조회 시에는 보통 비어 있다.)

2.5.4. HTTP 메세지

요청과 응답은 특정한 형식의 메세지로 이루어진다.

[캡쳐 1] 메세지 출력 예시

2.5.6. 상태코드

클라이언트의 요청에 대해 서버가 처리 결과를 숫자로 알려주는 응답 코드
"요청하신 결과는 이렇습니다!"라는 요약인 셈.

• 2xx (성공): "잘 처리됐어요!"

  • 200 OK: 정상 처리
  • 201 Created: 리소스 생성 성공
  • 204 No Content: 성공했지만 응답 바디 없음

• 3xx (리다이렉션): "주소가 바뀌었어요, 이쪽으로 가주세요!"

  • 301 Moved Permanently: 영구 이동

• 4xx (클라이언트 오류): "당신의 요청에 문제가 있어요."

  • 400 Bad Request: 요청 형식 오류
  • 401 Unauthorized: 인증 필요
  • 403 Forbidden: 권한 없음
  • 404 Not Found: 리소스 없음
  • 409 Conflict: 상태 충돌
  • 422 Unprocessable Entity: 유효성 검증 실패

• 5xx (서버 오류): "미안해요, 제 서버에 문제가 생겼어요."

  • 500 Internal Server Error: 서버 내부 오류
  • 502 Bad Gateway: 게이트웨이 오류
  • 503 Service Unavailable: 서비스 불가

2.5.7. 웹 서비스와 HTTP

현재 우리가 사용하는 거의 모든 웹 서비스는 HTTP(혹은 보안이 강화된 HTTPS)를 기반으로 동작하며,
이를 통해 전 세계의 웹 자원이 연결

동작 원리

1) 사용자가 UI 조작
2) 클라이언트가 프로그램이 사용자의 행동을 의도에 맞는 요청으로 해석
3) 클라이언트는 해당 요청을 HTTP 요청 메시지로 만들어 서버에 전송
4) 서버는 요청을 처리하고, HTTP 응답 메시지를 반환
5) 클라이언트는 응답을 받아 화면이나 기능으로 반영

2.5.8. 클라이언트가 HTTP 요청을 표현하는 방식

• CRUD: 데이터에 대한 대표적인 기본 동작 4가지(개념적 분류)

  • Create: 생성
  • Read: 조회
  • Update: 수정
  • Delete: 삭제

• 클라이언트가 서버에 요청을 하려면 아래 두 가지를 명확히 전달

  • 무엇을 하고 싶은가? → 행위(Action)
  • 무엇을 대상으로 그 행위를 하고 싶은가? → 자원(Resource)
    • 데이터(Data) vs. 자원(Resource)
      • 데이터는 단순한 값. 저장된 정보
      • 자원은 웹에서 식별·접근·조작 가능한 대상
        (데이터, 파일, 기능 등 모두 포함)

• 행위는 HTTP Method로 표현(실제 수단)

  • GET: 자원 조회 (CRUD로 따지면 Read)
  • POST: 자원 생성 (CRUD로 따지면 Create)
  • PUT: 자원 전체 수정 (CRUD로 따지면 Update)
  • PATCH: 자원 일부 수정 (CRUD로 따지면 Update)
  • DELETE: 자원 삭제 (CRUD로 따지면 Delete)

• 자원은 URL(Uniform Resource Locator) 형태로 전달

  • 웹에서 자원(Resource)의 위치를 식별하는 주소
  • 예시
    • http://example.com/users → 사용자 목록 자원
    • http://example.com/users/1 → ID가 1인 사용자 자원
    • http://example.com/posts/10/comments → 게시글 10번의 댓글 자원
    • http://example.com/files/report.pdf → 파일 자원

• 그래서 실제로 어떻게 표현하는가?

  • 'HTTP 메서드 + 자원(URL)'
    → "자원(URL)에 대해 action(HTTP 메서드)을 수행해줘!"
  • 예시
    • 전체 사용자 목록을 조회하고 싶어!
      → GET https://example.com/users
    • 10번 게시글에 댓글을 작성하고 싶어!
      → POST https://example.com/posts/10/comments
      (내용은 body에 {"content": "hello"}와 같이 표현)
    • 123번 주문을 삭제하고 싶어!
      → DELETE https://example.com/orders/123

요청 시 주의사항 ⚠️

1) 같은 자원이어도 메서드에 따라 전혀 다른 의미의 요청이 된다

• 예시
  • GET /users → 사용자 목록 조회
  • POST /users → 사용자 생성

2) 행위는 URL이 아니라 메서드로 표현(매우 중요!!!)

• 예시
  • 새로운 사용자 추가
    /createUser ❌
    POST /users ⭕️
  • 주문 삭제
    /deleteOrder ❌
    DELETE /orders/123 ⭕️

3) 자원은 보통 복수형 명사로 표현(개별 자원은 보통 ID로 구분)

• 예시
  • GET /users → 사용자 목록(집합)
  • GET /users/1 → 사용자 한 명

4) 기본 CRUD를 벗어나는 예외의 경우도 존재

• 모든 요청이 생성·조회·수정·삭제로 깔끔하게 나뉘지 않기 때문
• 이런 경우, 관례적으로 POST를 사용하는 경우가 많다
  (그러한 '상태'로 '생성' = 그러한 상태가 되게끔 한다)
  • POST /orders/123/cancel → 주문 취소
  • POST /auth/login → 로그인
  • POST /payments/1/confirm → 결제 확정

2.5.9. REST(Representational State Transfer) API

웹의 기본 원칙을 따르는 API 설계 방식

• Restful 하지 않은 API 설계 예시
  • GET /getUsers
  • GET /user-123
  • POST /users/create
  • POST /deleteOrders

2.5.10. Query Parameter

/search?q=apple처럼 URL에 붙여서 전달하는 데이터.
"search(검색)를 하는데, 검색어(q)는 apple이야!"라고 전달하는 방식.
주로 조회 조건이나 옵션을 표현할 때 사용한다.
경로(path) 뒤에 ?key=value 형태로 추가하면 된다.

2.5.11. Request Body

HTTP 메세지의 '본문(Body)'에 데이터를 담아 서버가 그대로 처리하도록 전달.
POST 메서드와 함께 주로 쓴다.

2.5.12. HTTP 요청에 대해 종합적으로 정리하자면?

HTTP 요청은

[메서드 + 자원(URL) + 부가 정보(헤더) + 실제 데이터(본문)]의 조합으로 이루어진다는 것.

cf) 주의사항:

HTTP는 기본적으로 암호화가 되지 않는다.
아이디, 비밀번호 같은 민감한 정보가 그대로 노출될 위험이 있기 때문에
HTTPS가 필요해진다.

2.6. HTTPS란?

HTTPS는 HTTP에 'Security(보안)'를 더한 것.
HTTP가 평문으로 데이터를 주고받는다면,
HTTPS는 그 위에 암호화라는 옷을 입혀 안전하게 통신한다.

2.6.1. 암호화 방식

• 대칭키 암호화(Symmetric Encryption):

  • 데이터를 잠그는 키(암호화)와 여는 키(복호화)가 같다.
  • 빠르지만, 키를 처음에 주고받을 때 뺏기면 위험하다.

• 비대칭키 암호화(Asymmetric Encryption):

  • 두 개의 키가 사용된다.
    • 공개키(Public Key)
    • 비밀키(Private Key)
  • 공개키로 암호화 → 개인키로만 복호화
    (누구나 공개키로 잠글 순 있지만, 오직 비밀키를 가진 서버만 열 수 있다.)
  • 안전하지만 느리다.

2.6.2. TLS(Transport Layer Security) 핸드셰이크

HTTPS는 처음에 이 대칭키와 비대칭키를 절묘하게 섞어서,
'TLS 핸드셰이크'라는 악수 과정을 거친다.

TLS 핸드셰이크가 끝나면,
클라이언트와 서버는 서로를 신뢰할 수 있고,
데이터를 안전하게 암호화해서 주고받을 수 있다.

[그림 2] 비유로 이해해보는 TLS 핸드셰이크 과정

2.6.3. HTTPS 동작 방식

[그림 3] HTTP vs. HTTPS

1) 브라우저 → 서버 접속 요청
2) 서버 → 인증서(공개키 포함) 전달
3) 브라우저 → 인증서 신뢰 여부 확인(CA)
4) 브라우저 → 대칭키를 공개키로 암호화해서 전달
5) 서버 → 비밀키로 복호화하여 대칭키 획득
6) 이후 통신 → 대칭키로 빠르게 암호화

2.6.4. keep-alive

keep-alive는 HTTPS에서 처음 한 번 맺은 연결을 바로 끊지 않고,
여러 개의 요청을 보낼 수 있게 해주는 기능.

• keep-alive가 있을 때
  • 최초 요청 시 TCP 연결 + TLS 핸드셰이크 1회
  • 이후 요청들은 같은 연결 + 같은 대칭키 사용 → 성능 향상, 지연 감소
• keep-alive가 없을 때
  • 요청마다 TCP 연결을 새로 생성
  • 매번 TLS 핸드셰이크 발생 → 지연 증가, 서버·클라이언트 부담 증가

---

3. 프론트엔드란?

'프론트엔드'는 사용자가 HTTP를 모르는 상태에서도 서비스가 동작하게 해주는 프로그램이다.
우리가 직접 보고 만지는 모든 화면을 만드는 일이라고 볼 수 있다.

3.1. 프론트엔드(Front-end) 개발자의 역할 및 주요 기술 스택

• 역할
  • 사용자가 보는 UI 구현
  • 사용자 입력(클릭, 입력 등)을 처리
  • 사용자 행동을 HTTP 요청으로 변환
  • 서버(API) 응답을 받아 화면에 반영
  • 사용자 경험(UX)을 고려해 상호작용을 설계
• 기술 스택
  • HTML: 웹 페이지의 뼈대(구조) 만들기 (예: 제목, 단락, 이미지)
  • CSS: 웹 페이지 꾸미기(스타일) (예: 색상, 크기, 레이아웃)
  • JavaScript: 화면의 동작과 로직을 구현(상호작용) (예: 버튼 클릭 시 동작)
  • 브라우저 이해: 사용자의 디바이스·브라우저 환경에서의 동작 제어
  • HTTP/REST API: 서버와의 통신을 담당
  • React, Vue, Angular 등: UI와 상태 관리를 구조화

3.2. 프론트엔드 vs. 클라이언트

'클라이언트'는 브라우저 그 자체라면, '프론트엔드'는 브라우저 위에서 돌아가는 화면과 로직.
프론트엔드는 클라이언트의 핵심 구성 요소인 셈.

3.3. 회원가입 과정 예시를 통한 이해

1) 사용자가 회원가입 화면(UI)에서 정보를 입력(이메일, 비밀번호 등)
2) 프론트엔드가 입력값을 모아 회원가입 요청(HTTP 요청)을 서버로 전송
3) 백엔드 서버가 요청을 받아 입력값을 검증(형식, 중복 이메일 여부 등)
4) 문제가 없다면 비밀번호를 암호화하고 데이터베이스에 사용자 정보를 저장
5) 저장 결과를 바탕으로 성공 또는 실패 응답을 생성

---

4. 백엔드(Back-end)란?

'백엔드'는 눈에 보이지 않지만, 서버 뒷단에서 데이터를 처리하고 관리하는 핵심적인 부분

4.1. 백엔드 개발자의 역할 및 주요 기술 스택

• 역할

  • 클라이언트의 요청을 해석하고 처리
  • 서비스의 비즈니스 로직을 구현한다
  • 데이터베이스를 설계·조회·저장·수정한다
  • API를 설계하고 제공한다
  • 인증·인가, 권한 관리 등 보안 로직을 처리한다
  • 오류 처리 및 응답을 일관된 형태로 반환한다

• 기술 스택

  • 프로그래밍 언어(Python, Java, Node.js): 비즈니스 로직 구현
  • 웹 프레임워크 (FastAPI, Spring): 요청·응답 처리 및 구조화
  • HTTP / REST API: 클라이언트와의 통신 규약
  • 데이터베이스 / SQL: 데이터 저장·조회·관리
  • 운영체제 / 클라우드 / 인프라: 서비스 배포 및 확장
  • 로그·모니터링: 장애 분석과 안정성 확보

4.2. 백엔드 vs. 서버

• 백엔드
  • 서버에서 실행되는 소프트웨어 영역
  • 데이터 처리, 비즈니스 로직, API 구현
  • 개발 영역·역할에 가까움
• 서버
  • 프로그램이 실행되는 컴퓨터 또는 실행 환경
  • 물리적 개념에 가까움 (또는 인프라 관점)

4.3. REST API 관리는 그럼 누구 책임?

• 백엔드 개발자
  • 특정 기능을 제공하기 위해 API를 먼저 설계·구현
  • 클라이언트가 사용할 수 있는 기능의 범위를 정의
• 프론트엔드 개발자
  • 백엔드가 제공한 API가 있어야 기능을 사용 가능
  • 정의된 API 스펙에 맞춰 요청을 보내고 응답을 처리

REST API의 설계와 일관성은 백엔드가 책임지고, 프론트엔드는 그 계약을 따른다.

---

5. 데이터와 저장소

5.1. 서버와 데이터베이스

서버는 데이터를 직접 가지고 있기보다, 전문적인 데이터 저장소인 데이터베이스를 이용.
서버가 데이터베이스에 요청해서 데이터를 가져오거나 저장.

데이터베이스에 대한 개념

5.2. SQLite 실습

• SQLite: 파일 기반의 경량 관계형 데이터베이스

  • 별도 서버 없이 하나의 파일로 데이터베이스를 사용
  • Python에 기본 내장되어 있어 설치 불필요
  • 설치·운영 부담 없이 로컬에서 데이터를 다뤄야 할 때 많이 사용

• DB Browser for SQLite: SQLite 데이터베이스 파일을 GUI로 열어보고 수정할 수 있는 도구

  • 사이트 접속해서 운영체제에 맞게 설치해서 사용하면 됨

---

6. 네트워크 기초

6.1. 네트워크(Network)란?

여러 컴퓨터가 서로 연결되어 데이터를 주고받을 수 있는 구조

6.2. 인터넷(Internet)이란?

전 세계 모든 네트워크가 연결된 하나의 거대한 네트워크

• 네트워크 = 작은 연결
• 인터넷 = 그 모든 연결의 집합

인터넷의 핵심은 딱 하나
👉 “데이터를 보내고 받는 것”

6.3. 데이터 전송의 핵심 문제

데이터를 보내려면 반드시 알아야 하는 두 가지가 있다.

📦 비유: 편지 보내기

편지를 보내려면?

• 주소 (어디로?)
• 받는 사람 (누구에게?)

이 두 정보가 필요하다.

👉 인터넷도 완전히 동일하다

필요 요소	의미
IP 주소	어디로 보낼지
Port 번호	누구에게 보낼지

6.4. IP 주소란?

IP 주소는 네트워크 상에서 컴퓨터를 식별하는 주소다.

• 비유: 집 주소
• 예: 142.250.206.46

📌 역할

• “어느 컴퓨터로 갈지” 결정

6.5. Port란?

Port는 한 컴퓨터 안에서 실행 중인 프로그램을 구분하는 번호다.

• 비유
  • IP → 건물 주소
  • Port → 몇 호인지

📌 자주 사용되는 포트

포트	의미
80	HTTP
443	HTTPS

🚨 핵심 포인트

• IP만 있으면 컴퓨터까지만 도착
• Port까지 있어야 정확한 프로그램에 전달
  → IP + Port ('IP:Port'의 형태)여야 하는 이유

6.6. DNS(Domain Name System)란?

도메인 이름을 IP 주소로 변환하는 시스템이다.

💡 왜 필요할까?

• IP 주소는 기억하기 어려움
  → 사람이 이해하기 쉬운 이름 사용
  (ex. google.com → 142.250.xxx.xxx)

• 비유: 전화번호부

  • 이름 → 전화번호 변환

DNS 동작 과정

1) google.com 입력
2) DNS에 "IP 뭐야?" 요청
3) IP 주소 응답
4) 해당 IP + Port(443)로 요청

👉 도메인 → DNS → IP → 서버 연결