웹개발의 기초

ETC/1. Today I Learned

웹개발의 기초

montmer27 2025. 11. 25. 21:51

프론트엔드와 백엔드의 차이

레스토랑에 비유하자면 홀은 프론트엔드, 주방은 백엔드에 해당

사용자가 눈으로 보고 직접 조작하는 모든 영역이 프론트의 영역

클라이언트 = 웹 브라우저, 스마트폰 앱 등. 사용자의 요청을 대신 처리해 주기 때문

HTML/CSS : UI

Javascript : UX

백엔드 : 핵심 로직과 데이터가 처리되는 영역

서버 = 24시간 켜져 있는 강력한 컴퓨터. 기능 처리/데이터 관리/결과 서빙

주문 처리 = 비즈니스 로직

재료 관리 = 데이터베이스

음식 전달 = API 응답

예전에는 웹마스터 하나가 다 개발했다.

프론트를 알아야 하는 이유 : 협업의 대상 + 백엔드의 고객이 프론트이기에 프론트에 대한 이해가 필요함.

1-3.

인터넷과 웹

웹 : 전 세계의 컴퓨터들이 인터넷을 통해 데이터를 공유할 수 있는 거대한 데이터 공간.
인터넷 : 전 세계의 수많은 컴퓨터를 연결하는 거대한 물리적 네트워크

웹상에 모든 데이터의 3요소 by 팀 버너스 리

URL : 주소
HTTP : 규칙(서버-클라이언트 간 통신 규약, 하이퍼텍스트 통신 규칙)
HTML : 콘텐츠를 만드는 뼈대 (css로 디자인, js로 반응성 더함)

클라이언트의 역할, 서버와 요청/응답을 주고받는 큰 그림

클라이언트 : 서버에 요청하는 모든 프로그램

웹 브라우저 : 웹에 접속할 수 있는 컴퓨터 프로그램. HTML을 화면으로 그려주는 역할

모바일 : 브라우저처럼 요청을 주고받음. HTML을 받아 표시할수도 있지만, 화면을 그리는 코드는 앱 자체에 포함된다.

클라이언트의 작동 원리

1-4 HTML이란

HyperText Markup Language

- HyperText : 이동이 가능한 텍스트. 마크업 랭귀지(프로그래밍 언어가 아님)

HTML의 핵심 구성 요소

태그+속성이 합쳐서 하나의 요소를 이룬다.(Elements)
태그
속성 : 태그에 대한 세부 설정, 이름="값" 형태로 작성
- 타입 : 텍스트
- ID
- PLACEHOLDER : 입력창 안내문

폼 태그

목적 : 사용자가 입력한 정보를 서버로 전달하려면 form 내부의 input, select, textarea에 입력된 값이 필요. 입력된 값은 JS에 의해 JSON 형태로 변환되어 서버로 전송

JSON : 데이터를 저장/전송하기 위한 텍스트 기반 형식.

key : value 형태로 구성

textarea 태그 : input보다 긴 텍스트를 받을 때.

1-5 CSS

CSS가 무엇인가

CASCADING STYLE SHEETS의 약자

디자인과 배치 담당

각 태그에 class라는 별명을 붙이고, class 이름을 통해 스타일을 적용

단독으로 사용 불가하여 - HTML 내부에 CSS파일을 생성하거나 외부 CSS 파일을 HTML에 연결하여 사용하는 방식 2가지

내부에서 사용 - <head> 태그 안에 <style> 태그를 열어 작성

CSS의 기본 구조와 구성 요소

선택자 {
  속성: 값;
}

선택자 : 스타일을 적용할 대상

박스 모델 : content(내용) < padding(안쪽 여백) < border(테두리) < margin(바깥쪽 여백) 총 4층위의 계층적 구조

Display 속성값 예시 : block, inline, flex, grid, none

- display : block;

한 줄을 전부 차지

- display : inline;

자기 크기만큼만 차지, 옆으로 붙음

- display : flex

자식 요소들을 가로로 나란히 배치 (가장 현대적이고 강력한 방식)

- display : none

요소를 화면에서 사라지게 만듦 (권한에 따라 설정, JavaScript에서 제어)

'백엔드 개발자 관점에서 바라본 CSS

사용자에게 출력되는 이미지/레이아웃에 문제가 있을 때 프론트와 소통하여 프론트 쪽 문제인지, 백엔드 쪽 문제인지 빠르게 파악할 수 있도록 공부하는 것이 좋음.

1-6 자바스크립트

5가지 구성요소

변수 : 값을 저장하는 공간
- const : 변하지 않는 값
- let : 변할 수 있는 값
함수 : 동작을 만들어줌
- function 함수이름(파라미터)
이벤트리스너 - 변수, 함수와 함께 동작을 만드는 3대 요소이기도 함
- 함수를 동작시키는 트리거
문서 제어(DOM Control) - Document Object Model
- 사용자의 입력값을 읽어오기
- 사용자의 입력값을 보여주기(쓰기)
- 수정/삭제 등
서버와의 통신
1. JSON 변환 후 백엔드 서버에 데이터 요청(fetch)/응답 처리

2-1. 서버란

백엔드 개발자들은 소프트웨어로서의 서버를 만드는 사람(Spring, Node.js, Django)

하드웨어 서버 안에서 실행되는 프로그램 - 클라이언트의 요청을 특정 포트를 통하여 받음

HTTP(80번 포트), HTTPS(443번 포트, 요즘 표준)

서버의 역할 2가지

웹 파일 제공 (정적 파일 전달 - 아무런 가공 없이 전달. html, css, javascript)
- 웹 파일을 제공하는 서버는 따로 '웹 서버'라고 부름
- 관련 프로그램 : Nginx, Apache
- 개발자 도구 - Network 탭에서 CSS/JS/Img가 정적 데이터들임
API 제공 (API에 따라 데이터를 제공한다는 뜻)
- 클라이언트의 요청 해석, 비즈니스 처리, 처리 상태 및 동적 응답 제공
- 요청 입력값과 서버 상황에 따라 결과 다름 (Dynamic)
- 이 역할을 수행하는 서버는 따로 '애플리케이션 서버'라고 부름
- 관련 프로그램 : Spring Boot
- 개발자 도구 - Network 탭에서 Fetch/XHR 필터 적용 시, JavaScript가 서버에 '추가 데이터'를 요청하는 통신 내역, 즉 서버 호출(API)만 보여주는 필터임. JSON 파일이 보

서버는 클라이언트의 모든 요청에 응답

2-2 HTTP란

HyperText Transfer Protocol : 멀리 떨어지는 컴퓨터 간 파일/데이터를 오류 없이 주고받기 위한 공통된 양식과 규약

HyperText : 하이퍼링크(a태그)를 통해 타 웹페이지나 정보로 즉시 이동할 수 있는 기능을 가진 텍스트
Transfer Protocol : 텍스트로 작성된 정보를 전달하기 위한 규약
- HTTP로 전송되는 모든 콘텐츠는 텍스트 형태로 변환됨

HTTP의 주요 특징

무상태성 : 서버가 클라이언트의 이전 상태를 기억하지 않음
비연결성 : 클라이언트가 요청을 보내고 서버가 응답을 마치면 기본적으로 연결을 끊음

HTTP의 구조

HTTP 요청(HTTP REQUEST)

Start Line : 보내는 사람/받는 사람/주소와 같은 기본 정보
1. version : HTTP 버전 (안정성을 위해 1.1버전을 가장 많이 이용함)
2. method : 클라이언트가 서버에 전달하는 4가지 요청
  1. GET : 조회 (Read)
  2. POST : 추가 (Create)
  3. PUT/PATCH : 수정 (Update)
  4. DELETE : 취소 (Delete)
3. url : 요청 대상 서버 IP 주소
  1. 홈페이지 주소(IP주소)
  2. 포트
  3. 경로
Status-Line
Headers : 요청의 상세 정보
1. Content-Type : Body(본문)에 담긴 데이터의 형식
  - application/json -> json 형식이라는 뜻
2. Accept : 클라이언트가 응답(전달)받을 수 있는 콘텐츠 종류 명시
  - application/json, text/html -> json, html 콘텐츠만 전달받을 수 있다는
Body : 실제 요청한 데이터 (빈 본문일수도 있음)
1. Content-Type : application/json : json은 현대 api 통신의 표준 데이터 형식임 (JavaScript Object Notation)
  - JavaScript와 호환이 좋으며
  - 가볍고
  - 사람이 읽기 쉽다
  - 구조 : 'key : value' 쌍으로 이루어진 텍스
2. Content-Type : text/html : 본문에 html 파일을 텍스트 형태로 전달한다는 뜻. 보통 응답할 때 많이 사용한다.

HTTP 요청 예시

// (1) 시작 줄 (Start-Line)
Version: HTTP/1.1
Method: POST 
URL: 홈페이지 주소:80/items

// (2) 헤더 (Headers)
Content-Type: application/json
Accept: application/json, text/html
...

// (3) 본문 (Body)
{
  "name": "새우깡",
  "price": 1500,
  "category": "living"
}

HTTP 응답 (Response)

Start Line : 응답의 첫번째 줄 - 요청 처리 결과
1. Version : 응답을 보낸 http 버전 (*요청과 같은 버전이어야 함)
2. Status Code & Text : 요청 처리 결과에 상태를 구분하는 코드. fetch 함수로 응답을 받은 직후 가장 먼저 확인하는 곳
  - 2xx (성공)
    - 200 OK
    - 201 Created
  - 4xx (클라이언트 오류)
    - 400 Bad Request (주문서 양식 잘못됨)
    - 401 Unauthorized (번호표 없음)
    - 404 Not Found (그런 메뉴는 없습니다)
  - 5xx (서버 오류)
    - 500 Internal Server Error
Header : 응답에 대한 상세 정보를 담고 있음
- Content-Type : 응답해 주는 데이터 형
Body : 본문, 헤더와 함께 클라이언트에게 돌려줄 실제 데이터가 담기는 부분
- 백엔드 관점 :

HTTP 응답 예시

// (1) 상태 줄 (Status Line)
Version: HTTP/1.1
Status Code: 201 
Status Text: Created

// (2) 헤더 (Headers)
Content-Type: application/json

// (3) 본문 (Body)
{
  "id": "abc-123-xyz",
  "name": "새우깡",
  "price": 1500,
  "category": "living"
}

HTTP로 데이터를 전송하는 방법

: 콘텐츠는 본문에 작성하여 보내지만, 요청은 두 가지 방법으로 서버에 데이터를 전송

주소(URL)에 붙여서 보내기 (GET)
- 쿼리 스트링 : 물음표(?) 이하 질의 문자
- GET도 전달해야 하는 데이터가 많다면 본문을 통해 전송해야 함. 이 때 POST 사용
  POST는 복잡한 데이터를 Body에 실어보낼 수 있기 때문.
본문(Body)에 숨겨서 보내기 (POST, PUT, PATCH)

보낼 자료가 많거나(URL은 길이 제한이 있), 비밀번호처럼 민감한 정보일 때 이 방법 사용

2-3 Rest API

서버의 핵심 임무는 'API 제공'

API는 무엇이며, REST API는 무엇인가?

API 뜻 : Application Programming Interface

내부 구현을 모르는 사람도 빠르고 안전하게 쓸 수 있게 하는 데 목적이 있다. 따라서 사람이 이해하기 편하게 설계하는 것이 매우 중요

REST : API란

Representational State Transfer API : API를 일관되게 설계할 수 있도록 세우는 설계 원칙

서버의 자원(Resource)을 클라이언트가 이해할 수 있는 형태로 쉽게 표현하는 방식이다. 해당 자원은 url 경로로 표시된다.

State : 자원의 현재 상태 의미

등록되었는지
수정되었는지
삭제되었는지

Transfer : HTTP 통신을 이용하여 서버에 자원의 상태를 요청하고 응답받는 것

REST 6가지 원칙

균일한 인터페이스
- 자원 식별 : 모든 자원은 고유한 주소(url)로 식별돼야 한다.
- 표현을 통한 자원 조작 : 클라이언트는 JSON과 같은 데이터(표현)를 가지고 서버의 자원을 조작(CRUD)할 수 있어야 한다.
- 자기 서술적 메시지 : 요청/응답 메시지는 '스스로를 설명'할 수 있어야 한다. Header의 역할
클라이언트-서버 역할 분리 : 독립적 발전 가능
무상태성 (HTTP와 동일) : 서버의 이전 상태를 기억하지 않음
주문형 코드 : 서버가 클라이언트에 '실행 가능한 코드'도 전달하여, 클라이언트가 모든 기능을 내장하고 있을 필요가 없어 클라이언트를 가볍게 유지할 수 있음.
캐시 가능 : 임시 저장된 데이터를 재사용하여 속도를 높이고 서버 부담을 줄임
계층형 시스템 : 클라이언트는 자신이 대화하는 상대가 누군지에 관계없이 정보를 주고받을 수 있다. 클라이언트에 영향을 주지 않고 시스템을 확장할 수 있음

REST API 설계 : 설계의 결과를 명세서로 작성하는 과정까지 포함

명세서 : 클라이언트와 서버 간의 계약. 프론트엔드와 백엔드가 서로 기다릴 필요 없이 동시에 개발할 수 있도록 가능케 함.

REST API 도출

단계	질문	답변	설계
누가 API를 사용하는가
무엇을 다룰 것인가			다루고자 하는 서버 자원을 url 경로로 작성. 자원을 복수형태로 명사로 표현.
어떻게 하는가			HTTP Method를 행위에 대한 규칙으로 사용 GET/POST/PUT/DELETE/PATCH
하기 위해 무엇이 필요한가	무엇을 받아야 하는가
끝나고 무엇을 반환하는가		영수증과 데이터를 돌려줘야 함

API 요청 명세 작성법

Method - GET/POST/PUT/PATCH/DELETE
Endpoint : 요청이 향하는 목적지 주소, 행동의 대상이 되는 자원(Resource)을 나타내는 명사
- 동사가 아닌 명사, 복수형 사용
요청 파라미터 : 전달 데이터

구분	API 엔드포인트	주요 사용 Method	설명 및 용도
경로(Path Parameter)	/items/123	GET, PUT, DELETE	특정 자원 식별 용도
쿼리(Query String)	/items?sort=new&page=2	GET	자원에 대한 조건을 명시할 떄 사용(정렬, 필터링, 검색, 페이징 등) - ?로 시작, 각 조건은 &로 연결
본문(Body)	url에 보이지 않음	POST, PUT, PATCH	전송할 데이터 본체(주로 JSON 형식) GET은 절대로 BODY를 사용하지 않음 복잡한 객체나 배열을 보낼 때 사용

요청 헤더 : 요청의 정보 정의
- 필수 헤더들
- Content - Type : 보내는 Body의 형식 명시 (예. application/json)
- Authorization : 인증 정보(토큰)을 보낼 때 사용

API 응답 명세 작성법

상태 코드
- 2XX(성공)
  - 200 OK : GET/PUT 성공
  - 201 Created : POST 성공
  - 204 No Content : DELETE 성공
- 4XX (클라이언트 오류)
  - 400 Bad Request : 잘못된 요청
  - 401 Unauthorized : 인증 실패 / 유효하지 않은 토큰 / 로그인 필요
  - 403 Forbidden : 권한 없음
  - 404 Not Found : 자원을 찾을 수 없음
- 5XX (서버 오류)
  - 500 Internal Server Error : 서버 내부에서 오류 발생 (코드 로직 오류 / DB 연결 실패 등)
응답 헤더
응답 본문 (Response Body)
- 조건에 맞는 데이터가 없을 시, NULL이 아닌 빈 배열을 반환한다.
- 오류의 원인을 Body에 명시하여 주고, 민감한 정보는 노출하지 않는다.

'ETC > 1. Today I Learned' 카테고리의 다른 글

[Git 기초] 브랜치 전략 (0)	2025.12.03
[Git 기초] Branch가 만들어지지 않는 오류 해결 (0)	2025.12.02
인텔리제이에서 .idea 설정 파일 프로젝트에서 제거하기 (0)	2025.12.02
[Git 기초] Git으로 협업하기 (0)	2025.12.01
[SQL Exercise] 7. Subquery, JOIN, PIVOT TABLE (0)	2025.11.28

현재글웹개발의 기초

Developing

May my work be of your glory

spring, spring boot, java, Git, 백엔드, developer, 스파르타코딩클럽, redis, 데이터분석, 데이터엔지니어, sql, 부트캠프, 프로그래머스, 개발자, kafka, Junior Developer, backend, Claude, Algorithm, 자바,

Today :
Yesterday :

Developing