Home
프로필

자바스크립트 백엔드

image

💡 NodeJS

  • 자바스크립트를 실행할 수 있는 런타임 환경이다.
  • 웹브라우저에 종속성을 가진 자바스크립트를 운영체제(터미널)에서 실행할 수 있도록 독립시킨 환경이다.
  • 즉 자바스크립트 런타임의 한 종류로 웹브라우저(크롬, 사파리, 파이어폭스 등)와 함께 Node.js가 있는 것이다.

💡 V8

  • V8은 구글에서 개발한 오픈소스 자바스크립트 엔진이다.
  • 처음엔 구글맵 서비스의 속도를 높이기 위해 개발되었다.
  • 지금은 Node.js와 크로미움 기반 웹브라우저(크롬, 브레이브, 아크, 웨일 등)에서 사용되고 있다.
  • 속도 개선의 배경에는 JIT이라고 불리는 컴파일링이 있다. 이는 인터프리터 방식으로만 작동하던 기존의 자바스크립트에 컴파일이라는 향신료를 첨가했다.
  • V8은 실행되면서 자바스크립트 코드를 바이트 코드로 한줄씩 전환한다.
  • 그러는 와중 JIT 컴파일러는 자주 사용되는 바이트 코드를 머신 코드로 캐시한다.

그러면 JIT이란 뭘까?

💡 JIT 컴파일

이미지
작동 흐름
  • 소스코드는 사람이 특정 프로그래밍 문법 안에서 영어로 작성한 코드, 즉 개발자들의 언어를 지칭한다.
  • 컴퓨터가 이를 이해하기 위해서는 번역의 과정을 필요로 한다.
  • 머신코드는 CPU가 바로 읽고 사용할 수 있는 바이너리 코드다.
  • 소스코드로부터 이를 생성하는 과정, 즉 번역하는 작업이 바로 컴파일이다.
  • 일반적으로 컴파일러는 실행되는 순간 문서 전체를 한번에 번역하고, 인터프리터는 실행되면서 한줄한줄 번역하는 특성을 지녔다.
  • 하지만 JIT은 빌드타임에 일회성으로 작동하고 마는 것이 아니라 런타임 내내 컴파일을 반복적으로 수행한다(Just In Time).
  • 컴파일 대상은 런타임에서 자주 사용되는 바이트 코드다. JIT은 이를 탄력적으로 식별하여 머신코드로 캐시해둔다. 즉 컴파일한다(Turbofan).
  • 이것이 속도를 높이는 원천이다.
  • 나머지 코드들은 인터프리터에 의해 바이트 코드 상태로 운용된다(Ignition).
  • 바이트 코드를 읽으면서 앞선 과정, 즉 최적화와 탈최적화, 무엇을 편입시키고 반출할지에 대한 끝없는 적응이 반복된다.

💡 백엔드의 구분

이미지
  • API Server
    클라이언트의 요청을 받아서 필요한 로직을 수행하는 장소다. 프론트엔드와 백엔드, 또는 백엔드끼리의 연결을 담당한다
  • 데이터베이스
    백엔드에서 데이터 저장을 위해 사용하는 저장소다. Postgres, MongoDB 등등 다양한 DB가 있다
  • 인프라 스트럭쳐
    백엔드를 실행하는 하드웨어를 관리하는 영역이다. 서버를 24시간 내내 가동하기 위해 필요하며 비용의 문제와 직결된다

💡 HTTP

  • HTTP는 웹상에서 클라이언트와 서버가 통신하기 위한 프로토콜이다.
  • 클라이언트가 서버에게 요청을 보내면 서버는 이에 응답한다.
  • 요청과 응답의 구조화된 데이터를 보낼 때 일반적으로 JSON을 사용한다.

HTTP 요청의 구성요소
  • URL: 요청에 쓰이는 (백엔드-프론트엔드 간에)합의된 주소
  • Method: 요청의 종류
  • Header: 요청에 대한 메타 데이터들
  • Body: 요청에 싣는 실질적인 데이터

  1. URL
    ex) https://hyezoprk.com/posts?page=2
  • Scheme: https
  • Host: hyezoprk.com
  • Path: posts
  • Query: page=2

  1. Method
  • GET: 데이터를 조회할 때 사용
  • POST: 데이터를 생성할 때 사용
  • PATCH: 데이터를 수정할 때 사용
  • PUT: 데이터를 수정하거나 추가할 때 사용
  • DELETE: 데이터를 삭제할 때 사용
  • HEAD/CONNECT/OPTIONS 등: 잘 사용하지 않음

  1. Header
  • 메타데이터를 정의한다.
  • 대표적으로 쿠키, 인증 토큰, 요청의 바이트 길이, 요청/응답을 보낸 Host, 요청하는 클라이언트 타입과 버전 등이 담긴다.
  • key, value 형태로 구성되고 모두 String 타입이다
  • 대부분 라이브러리, 프레임워크 등에 의해 자동으로 생성되는 경우가 많기 때문에 값을 변경하는 경우는 Body 보단 적다.

  1. Body
  • 요청에 실어 보내는 데이터를 담는다.
  • 대개 프론트엔드에서 폼, 인풋 등으로 입력받는다.

HTTP 응답의 구성요소
  • Header: 응답의 메타데이터
  • Body: 응답에 관련된 데이터 (보통 DB에서 가져온 데이터)
  • Satus Code: 응답의 종류
이미지
응답 코드표
주요 응답 코드
  • 200: 문제없이 요청이 성사
  • 201: 문제없이 데이터 생성 완료 (POST 요청에 많이 사용)
  • 301: 리소스가 영구적으로 이동됨
  • 400: 요청이 잘못됨(필수값 부족 등)
  • 401: 인증/토큰키가 잘못되어 권한이 없음
  • 403: 접근 불가능한 리소스. 401과 달리 인증은 된 상태
  • 404: 존재하지 않는 리소스.
  • 405: 허가되지 않은 요청 Method
  • 500: 알 수 없는 서버에러

💡 TMI(chatGPT와의 대담)

  • 타입스크립트 컴파일러는 JIT이 아니다. 나는 타입 에러마다 TSC가 에러를 던지는 꼴에서 JIT이랑 혼동이 왔더랬다...
  • 그러나 JIT은 런타임 최적화 컴파일러이고, TSC는 런타임 실행 전(AOT), IDE 차원에서 빠르게 실행되는 컴파일러일 뿐이다.
  • TSC에서 말하는 컴파일이란 타입스크립트 ▸ 자바스크립트 코드다.
  • JIT의 컴파일은 바이트 코드 ▸ 머신 코드다(근본).
  • 순서를 정리하면 다음과 같다
    • 타입스크립트 소스코드 작성
    • 타입스크립트 컴파일 by IDE ▸ 자바스크립트 코드 생성
    • 자바스크립트 코드 실행 by NodeJS ▸ 바이트 코드 생성 (런타임 진입)
    • JIT 컴파일 체계 작동 ▸ 머신코드 생성

참고링크

  1. 그럼 사파리에서는 JIT이 어떻게 작동할까?
  2. 자바스크립트 개발자를 위한 AST 이해
  3. AST 자료구조
  4. 바벨, 뭐하는 친구지?

Comment ?

▾ Comment

🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧