본문 바로가기
IT지식/Web, Server

모든 개발자를 위한 HTTP 웹 기본 지식 간단 리뷰

by five-sun 2023. 5. 23.
728x90

- 해당 강의

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

 

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런

www.inflearn.com

 

개발자는 평생 HTTP 기반 위에서 개발, 언젠가 한번은 정리 해야 함

HTTP의 전체 흐름 이해, 실무에 꼭 필요한 핵심 내용

 

[인터넷 네트워크]

• 인터넷 통신:

  1. 복잡한 인터넷 망 IP를 이용해 통신을 한다.

• IP(Internet Protocol):

  1. 지정한 IP 주소에 데이터를 전달하고 패킷이라는 통신 단위를 사용한다
  2. IP 프로토콜은 비연결성, 비신뢰성, 프로그램 구분이 어렵다는 한계를 갖는다
  3. IP 패킷은 출발지 IP, 목적지 IP 등을 담고 있다.

*비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송, 대상 서버가 패킷을 받을 수 있는 상태인지 모름

*비신뢰성: 중간에 패킷이 사라지거나 패킷이 순서대로 전송, 패킷 소실

*프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면 구분이 어렵다

 

• TCP, UDP:

*애플리케이션: 웹 브라우저, 네트워크 게임, 채팅 프로그램 등

*OS: TCP, UDP, IP등

*네트워크 인터페이스: LAN 드라이버, LAN 장비 -> LAN 카드

 

  1. TCP 세그먼트는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 담고 있다.
  2. IP 프로토콜을 보안하기 위해 같이 사용한다.
  3. TCP 프로토콜의 특징으로는 연결지향, 데이터 전달 보증, 순서 보장이 되어 신뢰할 수 있는 프로토콜이고 현재는 대부분 TCP를  사용하고 있다.
  4. TCP 3 way handshake를 통해 접속 요청과 요청 수락이 이뤄진다.
  5. UDP의 특징은 연결지향 X, 데이터 전달 보증 X, 순서 보장X, 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠른 특징이 있다.
  6. UDP는 IP와 거의 같지만 PORT와 체크섬 정도가 추가되었다.(어플리케이션에서 추가 작업이 필요하다.)

• PORT

  1. 같은 IP 내에서 프로세스 구분하는데 사용하다.
  2. 0 ~ 65535: 할당 가능
  3. 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음 (Ex: FTP - 20,21 / TELNET - 23 / HTTP - 80 / HTTPS  - 443

• DNS

  1. IP는 기억하기 어렵고 변경될 수 있다.
  2. DNS: 도메인 네임 시스템의 약자로 도메인 명을 IP 주소로 변환한다.

DNS 동작 원리 참고 영상: 

https://www.youtube.com/watch?v=YahjHM9UNCA 

[URI와 웹 브라우저 요청 흐름]

• URI(Uniform Resource Identifier)

  1. URI는 로케이터, 이름 또는 둘다 추가로 분류될 수 있다. 우리가 주로 사용하는 것은 URL이다.
  2. URI를 설계할 때, 가장 중요한 것은 리소스 식별이다.
  3. Uniform(리소스 식별하는 통일된 방식), Resource(자원, URI로 식별할 수 있는 모든 것), Identifier(다른 항목과 구분하는데 필요한 정보)

 

• URL

  1. 프로토콜//호스트명:포트번호/패스/쿼리 파라미터로 이뤄짐

 

• 웹 브라우저 요청 흐름

  1. HTTP 메시지 전송 -> 요청 패킷 전달 -> 요청 패킷 도착 ->  HTTP 응답 메시지

 

[HTTP]

• 모든 것이 HTTP

  1. HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML(API), 거의 모든 형태의 데이터를 전송 가능하고 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
  2. HTTP의 특징은 클라이언트 서버 구조, 무상태 프로토콜, 비연결성, HTTP 메시지, 단숨함, 수평 확장성이 있다.

• 클라이언트 서버 구조

  1. Request / Response 구조
  2. 클라이언트는 서버에 요청을 보내고, 응답을 대기
  3. 서버가 요청에 대한 결과를 만들어서 응답

• Stateful, Stateless: HTTP는 무상태 프로토콜

  1. Stateless: 서버가 클라이언트의 상태를 보존하지 않는 상태로 서버 확장성이 높지만 클라이언트가 추가 데이터를 전송해야 한다는 단점이 있다.
  2. Stateful: 항상 같은 서버가 유지되어야 하고 중간에 서버가 장애가 나면 대응이 어렵고 처음부터 다시 시작해야 하는 단점이 있다.
  3. *실무에서 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 존재하는데 일반적으로 브라우저 쿠키와 서버 세션을 사용해서 상태 유지를 하고 상태 유지는 최소한만 사용하며 무상태로 설계하는 것이 좋다.

• 비 연결성(connectionless)

  1. HTTP는 기본이 연결을 유지하지 않는 모델이고 일반적으로 초 단위 이하의 빠른 응답 속도를 갖고 있어 서버 자원을 매우 효율적으로 사용할 수 있다.
  2. 비 연결성의 한계를 극복하고자 HTTP 지속 연결을 사용하고 있다.

*비 연결성의 한계:

  1. TCP/IP 연결을 새로 맺어야 하므로 3way handshake 시간이 추가
  2. 웹 브라우저로 사이트를 요청하면 수 많은 자원이 함께 다운로드

• HTTP 메시지

*HTTP 요청 메시지:

  1. 시작 라인: HTTP 메서드, 요청 대상, HTTP 버전

 

*HTTP 응답 메시지:

  1. 시작 라인: HTTP 버전, HTTP 상태 코드, 이유 문구(사람이 이해할 수 있는 짧은 상태 코드 설명)
  2. HTTP 헤더: HTTP 전송에 필요한 모든 부가정보
  3. HTTP 메시지 바디: 실제 전송할 데이터, HTML 문서, 이미지, 영상 JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능

[HTTP 메서드]

• HTTP 메서드

  1. GET: 리소스 조회
  2. POST: 요청 데이터 처리, 주로 등록에 사용
  3. PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  4. PATCH: 리소스 부분 변경
  5. DELETE: 리소스 삭제

기타:

  1. HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
  2. OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
  3. CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
  4. TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

• GET

  1. 리소스 조회
  2. 서버에 전달하고 싶은 데이터는 쿼리(쿼리 파라미터, 쿼리 스트링)을 통해서 전달
  3. 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장 X

• POST

  1. 요청 데이터 처리
  2. 메시지 바디를 통해 서버로 요청 데이터 전달
  3. 서버는 요청 데이터를 처리: 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행
  4. 하지만, 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

• PUT

  1. 리소스가 있으면 대체, 없으면 생성 (덮어쓰기)
  2. 클라이언트가 리소스를 식별

• PATCH

  1. 리소스 부분 변경(수정)

• DELETE

  1. 리소스 제거

• HTTP 메서드의 속성

  1. 안전: 호출해도 리소스를 변경하지 않는다(GET, HEAD)
  2. 멱등: 한번을 호출하든 100번을 호출하든 결과가 똑같다. 외부 요인은 고려 X :(GET, PUT, DELETE)
  3. 캐시 가능: GET, HEAD, POST, PATCH가 가능하지만 실제로는 GET, HEAD 정도만 캐시를 사용한다. 캐시 키를 고려하기 어렵다

[HTTP 메서드 활용]

• 클라이언트에서 서버로 데이터 전송하는 데이터 전달 방식은 크게 2가지:

  1. 쿼리 파라미터: GET
  2. 메시지 바디: POST, PUT, PATCH

• 클라이언트에서 서버로 데이터를 전송하는 4가지 상황:

  1. 정적 데이터 조회: 이미지, 정적 텍스트 문서
  2. 동적 데이터 조회: 주로 검색, 게시판 목록에서 정렬 필터
  3. HTML Form을 통한 데이터 전송: 회원 가입, 상품 주문, 데이터 변경
  4. HTTP API를 통한 데이터 전송: 회원 가입, 상품 주문, 데이터 변경, 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

[참고 하면 좋은 URI 설계 개념]

• 문서(document)

단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)

예) /members/100, /files/star.jpg

 

• 컬렉션(collection)

서버가 관리하는 리소스 디렉터리

서버가 리소스의 URI를 생성하고 관리

예) /members

 

• 스토어(store)

클라이언트가 관리하는 자원 저장소

클라이언트가 리소스의 URI를 알고 관리

예) /files

 

컨트롤러(controller), 컨트롤 URI

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행

동사를 직접 사용 • 예) /members/{id}/delete

 

[HTTP 상태 코드]

 

• 상태 코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

  1. 1xx(Informational): 요청이 수신되어 처리중
  2. 2xx(Successful): 요청 정상 처리
  3. 3xx(Redirection): 요청을 완료하려면 추가 행동 필요
  4. 4xx(Client Error): 클라이언트 오류
  5. 5xx(Server Error): 서버 오류

• 1xx(Informational): 거의 사용하지 않음

 

• 2xx - 성공

  1. 200 OK: 요청 성공
  2. 201 Created: 요청 성공 -> 새로운 리소스 생성됨
  3. 202 Accepted: 요청 접수되었으나 처리는 완료 X
  4. 204 No Content: 서버가 요청을 성공했지만 응답 페이로드 본문에 보낼 데이터가 없음

• 3xx - 리다이렉션

  1. 300 Multiple Choices: NOT USE!
  2. 301 Moved Permanently: 영구 리다이렉션, 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  3. 302 Found: 일시 리다이렉션, 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  4. 303 See Other: 일시 리다이렉션, 리다이렉트시 요청 메서드가 GET으로 변경, 302와 기능은 동일
  5. 304 Not Modified: 캐시를 목적으로 사용, 클라이언트에게 리소스가 수정되지 않았음을 알려줌
  6. 307 Temporary Redirect: 일시 리다이렉션, 리다이렉트시 요청 메서드와 본문 유지, 302와 기능은 동일
  7. 308 Permanent Redircet: 영구 리다이렉션, 리다이렉트시 요청 메소드와 본문 유지

*리다이레션의 이해: 웹 브라우저 3xx 응답의 결과에 Location 헤더가 있다면, 그 위치로 자동 이동

  1. 영구 리다이렉션: 특정 리소스 URI가 영구적으로 이동
  2. 일시 리다이렉션: 일시적인 변경
  3. 특수 리다이렉션: 결과 대신 캐시를 사용

• PRG: Post/Redirect/Get

  1. POST 요청 이후, 새로고침 등으로 인한 중복 요청 방지를 위해 사용
  2. POST 요청 이후, 응답을 통해 자동 리다이렉트 하여 GET 요청을 보내 응답을 받은 흐름

• 4xx - 클라이언트 오류

  1. 400 Bad Request: 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  2. 401 Unauthorized: 클라이언트가 해당 리소스에 대한 인증이 필요, 인증(Authentication)/인가(Authorization)
  3. 403 Forbidden: 서버가 요청을 이해했지만 승인 거부, 접근 권한이 불충분
  4. 404 Not Found: 요청 리소스를 찾을 수 없음

• 5xx - 서버 오류

  1. 500 Internal Server Error: 서버 문제로 오류 발생, 애매하면 500 오류
  2. 503 Service Unavailable: 서버스 이용 불가, 서버가 일시적인 과부하 또는 잠시 요청을 처리할 수 없을 때

[HTTP 헤더]

• HTTP 헤더(과거)

  1. 앞서 이야기한 거와 같이 HTTP 전송에 필요한 모든 부가 정보
  2. 헤더 분류: General 헤더, Request 헤더, Response 헤더, Entity 헤더

• HTTP 바디(과거)

  1. 메시지 본문은 엔티티 본문을 전달하는데 사용
  2. 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
  3. 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공

*현재 HTTP 표준 변경: RFC2616 -> RFC 7235:

  1. 엔티티(Entity) -> 표현(Representation)
  2. Representation = respresentation Metadata + Representation Data

• HTTP 바디(최신)

  1. 메시지 본문을 통해 표현 데이터 전달
  2. 메시지 본문 = 페이로드
  3. 표현은 요청이나 응답에서 전달할 실제 데이터
  4. 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
  5. 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야함

• 표현

  1. Content-Type: 표현 데이터의 형식
  2. Content-Encoding: 표현 데이터의 압축 방식
  3. Content-Language: 표현 데이터의 자연 언어
  4. Content-Length: 표현 데이터의 길이, 바이트 단위 사용, Transfer-Encoding을 사용하면 사용 X

*표현 헤더는 전송, 응답 둘다에서 사용

 

• 협상(콘텐츠 네고시에이션: 클라이언트가 선호하는 표현 요청)

  1. Accept: 클라이언트가 선호하는 미디어 타입 전달, Quality Values가 클수록 우선순위
  2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩
  3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
  4. Accept-Language: 클라이언트가 선호하는 자연 언어, Quality Values가 클수록 우선순위

*협상 헤더는 요청시에만 사용

 

• 전송 방식

  1. 단순 전송: Content-Length
  2. 압축 전송: Content-Encoding
  3. 분한 전송: Transfer-Encoding
  4. 범위 전송: Range, Content-Range

• 일반정보

  1. From: 유저 에이전트의 이메일 정보, 잘 사용되지 않음, 검색 엔진에서 주로 사용, 요청에서 사용
  2. Referer: 이전 웹 페이지 주소
  3. User-Agent: 유저 에이전트 애플리케이션 정보, 클라이언트의 애플리케이션 정보, 요청에서 사용
  4. Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보, 응답에서 사용
  5. Date: 메시지가 생성된 날짜, 응답에서 사용

• 특별한 정보

  1. Host: 요청한 호스트 정보(도메인), 요청에서 사용, 하나의 서버가 여러 도메인을 처리해야 하거나 하나의 IP 주소에 여러 도메인이 적용 되어 있을 수 있으므로 필수
  2. Location: 페이지 리다이렉션
  3. Allow: 허용 가능한 HTTP 메서드, 405(Method Not Allowed)에서 응답에 포함해야 함
  4. Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• 인증

  1. Authorization: 클라이언트 인증 정보를 서버에 전달
  2. WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의, 401(Unauthorized) 응답과 함께 사용

[쿠키: 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달]

  1. Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
  2. 쿠키를 미사용할 경우, HTTP는 무상태 프로토콜이므로 이전의 상태를 모르므로 모든 요청에 사용자 정보 등을 포함하도록 개발 해야하는 문제가 생길 수 있다. 따라서 쿠키를 사용해서 문제를 해결
  3. 사용자 로그인 세션 관리, 광고 정보 트래킹 등에서 사용
  4. 쿠키 정보는 항상 서버에 전송
  5. 최소한의 정보만 사용(세션, id, 인증 토큰)
  6. 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지를 사용
  7. 보안에 민감한 데이터는 저장하면 안됨

• 쿠키 - 생명 주기

  1. Set-Cookie: expires: 만료일이 되면 쿠키 삭제
  2. Set-Cookie: max-age: 지정 시간이 지나면 쿠키 삭제, 0이나 음수를 지정하면 쿠키 삭제
  3. 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
  4. 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

 

• 쿠키 - 도메인(Ex: domain=example.org)

  1. 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
  2. 생략: 현재 문서 기준 도메인만 적용

 

• 쿠키 - 경로(Ex: path=/home)

  1. 이 경로를 포함한 하위 경로 페이지만 쿠키 접근

• 쿠키 - 보안

Secure: 쿠키는 http, https를 구분하지 않고 전송하는 Secure를 적용하면 https인 경우에만 전송

HttpOnly: XSS 공격 방지, 자바스크립트에서 접근 불가, HTTP 전송에만 사용

SameSIte: XSRF 공격 방지, 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

 

*XSS 공격: 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말한다. 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되며, 보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취한다.

*XSRF 공격: 사이트 간 요청 위조(XSRF 또는 CSRF)는 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격입니다.

이후에 더 알아보도록 하자.

 

[캐시 기본 동작]

• 캐시가 없을 때

  1. 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함
  2. 인터넷 네트워크는 매우 느리고 비쌈
  3. 브라우저 로딩 속도가 느림
  4. 느린 사용자를 경험하게 됨

• 캐시 적용

  1. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
  2. 비싼 네트워크 사용량을 절약
  3. 브라우저 로딩 속도가 빠름
  4. 빠른 사용자를 경험하게 됨
  5. 캐시 유효시간(max-age)이 존재하는데 이 시간이 초과하면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생

 

• 검증 헤더와 조건부 요청

캐시 유효 시간 초과해서 서버에 다시 요청하면 두 가지 사황이 나타날 수 있다.

  1. 서버에서 기존 데이터를 변경
  2. 서버에서 기존 데이터를 변경 X

캐시 만료후에도 서버에서 데이터를 변경하지 않았다면 다시 데이터를 전송하는 것보다 캐시를 재사용하는 것이 더 좋다.

단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요했고 검증 헤더가 추가되었다.

 

• Last-Modified: 데이터 최종 수정일

  1. 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답
  2. Last-Modified를 확인하고 캐시의 메타 정보를 갱신
  3. 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
  4. 매우 실용적인 해결책

* 문제점: 날짜 기반의 로직을 사용해서 1초 미안 단위로 캐시 조정이 불가능하고 데이터를 수정해서 날짜는 변경되었지만 데이터 결과가 똑같은 경우도 존재할 수 있음

 

• ETag(Entity Tag)

  1. 캐시용 데이터에 임의의 고유한 버전 이름을 담아둠
  2. 데이터가 변경되면 이 이름을 바꾸어 변경함
  3. 진짜 단순하게 Etag가 같으면 유지, 다르면 다시 다운로드를 동작
  4. 이를 통해 캐시 제어 로직을 서버에서 완전히 관리할 수 있음

• 캐시 제어 헤더

  1. Cache-Control: 캐시 제어
    1. Cache-Control: max-age: 캐시 유효 시간, 초 단위
    2. Cache-Control: no-cache: 데이터는 캐시해도 되지만, 항상 오리진 서버에서 검증하고 사용
    3. Cache-Control: no-store: 데이터에 민감한 정보가 있으므로 저장 X
    4. Cache-Control: public: 응답이 캐시에 저장
    5. Cache-Control: private: 응답이 해당 사용자만을 위한 것이므로 private 캐시에 저장
    6. Cache-Control: s-maxage: 프록시 캐시에만 적용되는 max-age
    7. Age: 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
  2. Pragma: 캐시 제어(하위 호환)
    1. Pragma: no-cache Http 1.0 하위 호환
  3. Expires: 캐시 유효 기간(하위 호환)
    1. expires: 캐시 만료일을 정확한 날짜로 지정, 지금은 더 유연한 max-age 권장(우선순위가 더 높음)

• 프록시 캐시

모든 요청을 오리진 서버에 접근해서 데이터를 다운로드 하려면 시간이 굉장히 오래 걸리는 문제가 발생할 수 있다.

그래서 프록시 캐시 서버라는 것이 존재

 

•  캐시 무효화

  1. Cache-Control: noe-cache, no-store, must-revalidate
  2. Pragma: no-cache (HTTP 1.0 하위 호환을 위해 추가)

*Cache-Control: no-cache는 데이터는 캐시해도 되지만, 항상 오리진 서버에 검증하고 사용, 오리진 서버 접근시 오류보다는 오래된 데이터를 출력

*Cache-Control: must-revalidate는 캐시 만료 후 최초 조회시 오리진 서버에 검증하고 사용, But 오리진 서버 접근 실패시 반드리 오류가 발생해야한다(504 에러)

 

이렇게 까지 해서 모든 개발자를 위한 HTTP 웹 기본 지식을 학습하며 간단하게 정리해볼 수 있었다.

 

서버와 통신을 할 때, 해당 내용을 알고 있다면 어떻게 전송을 보내야 할지, 문제가 발생했을 때 어떻게 해결하면 좋을지를 결정할 때 중요한 배경지식이 될 것 같다.

 

 

 

728x90
저작자표시 비영리 변경금지

'IT지식 > Web, Server' 카테고리의 다른 글

[Web] API, REST API에 대해 공부해보자  (1) 2023.11.03
[Javascript] ES6 컬렉션  (0) 2023.02.13
[Javascript] ES6 문법 정리 (대표 9가지) + Babel  (0) 2023.02.13
[Web] 실습 UI 개발로 배워보는 순수 javascript와 VueJS개발  (0) 2023.02.10
[Web] Docker에 대해 공부해보자  (0) 2023.01.03

관련글

티스토리툴바