https://www.youtube.com/watch?v=Z0bWYHUhvRs
description: |
1. 이건 꼭 알아야 한다^1
[? 질문] 웹/모바일 애플리케이션을 만들 때 프론트엔드와 백엔드는 각각 무엇을 담당하는가^1
[= 답] 프론트엔드는 사용자가 직접 보고 조작하는 **화면(UI)**과 사용 경험(UX), 그리고 화면에서 발생한 입력/상태를 처리해 서버와 데이터를 주고받는 역할을 한다.^4 백엔드는 사용자가 보지 못하는 곳에서 데이터베이스 설계/관리, REST API 제공, 서버 운영(분산/트래픽), CI/CD를 통한 무중단 배포 같은 시스템 전반을 책임진다.^27
[? 질문] 프론트엔드/백엔드 진로를 고민할 때 무엇을 기준으로 선택해야 하는가^2
[= 답] 각 영역의 역할을 먼저 이해한 뒤, 본인에게 맞는 분야를 선택해 학습을 시작하면 된다.^3
[? 질문] 프론트엔드와 백엔드는 사용하는 언어/프레임워크가 달라도 “본질적으로” 얼마나 다른가^44
[= 답] 언어와 프레임워크의 차이는 존재하지만, 웹 애플리케이션은 기본적으로 HTTP 프로토콜 기반으로 동작하므로 큰 틀에서의 작동 원리는 크게 다르지 않다.^45 따라서 접근하기 쉬운 언어/프레임워크로 시작해도 되고, 이후 다른 스택으로 확장 학습이 가능하다.^46
2. 큰 그림^1
이 콘텐츠는 웹 개발/모바일 애플리케이션 개발을 시작하려는 사람들에게 프론트엔드와 백엔드의 역할 차이를 설명하고, 각 영역에서 다루는 대표 개념(렌더링, 상태관리, API, DB, 서버 운영, 배포)과 언어/프레임워크 예시를 제시해 진로 선택과 학습 방향을 잡게 하는 목적의 안내 영상이다.^1
- 프론트엔드는 사용자가 직접 접하는 화면을 만들고, 입력/클릭 등 상호작용을 처리하며, UX/UI와 검색엔진/크롤봇 친화성 같은 요소까지 고려한다.^4
- 백엔드는 데이터가 저장·조회되는 데이터베이스와 이를 제공하는 REST API, 그리고 트래픽을 감당하는 서버 운영/분산 및 **CI/CD(무중단 배포)**를 책임진다.^27
- 언어·프레임워크는 다양하지만, 웹 서비스의 공통 기반(HTTP)과 개발 흐름을 이해하면 스택 간 이동(리액트→뷰, 스프링→익스프레스/장고 등)이 가능하므로 “쉬운 것부터 시작”하는 전략을 권한다.^44
3. 하나씩 살펴보기^1
3.1 왜 프론트엔드/백엔드를 구분해서 알아야 하나^2
영상은 “웹 개발이나 모바일 애플리케이션 개발”을 할 때 프론트엔드와 백엔드를 이해하는 것이 출발점이라고 말한다.^1 특히 개발을 처음 시작하는 사람은 어느 시점에 “백엔드로 갈지 프론트엔드로 갈지”를 결정해야 하는 순간이 오는데, 그 결정을 위해서는 각 영역이 무엇을 하는지부터 알아야 한다는 문제의식을 제시한다.^2
따라서 영상의 흐름은 다음처럼 잡힌다.^3
- 먼저 프론트엔드가 어떤 역할을 하는지를 “사용자와 직접 소통하는 화면” 중심으로 설명한다.^4
- 다음으로 프론트엔드에서 고려해야 할 요소(UX/UI, 크롤봇 친화성, 렌더링 방식, 상태관리, 서버/DB와의 데이터 통신)를 확장해 다룬다.^7
- 이어서 백엔드가 담당하는 일을 “사용자가 보지 못하는 곳”의 기술(DB 스키마/정규화/샤딩/레플리카, REST API, 서버 분산, CI/CD)로 설명한다.^27
- 마지막으로 언어/프레임워크 차이를 정리하면서, 큰 원리는 비슷하니 접근하기 쉬운 스택으로 시작하라고 조언한다.^44
3.2 프론트엔드의 정의: “사용자와 직접 소통하는 화면”^4
프론트엔드는 애플리케이션을 구축할 때 “사용자와 직접적으로 소통을 하는 화면”을 제작하는 영역이라고 정의한다.^4 여기서 화면이란 단순히 예쁜 화면을 의미하는 것이 아니라, 사용자가 서비스를 사용하기 위해 수행하는 모든 상호작용을 담는 층을 뜻한다.^5
프론트엔드가 처리하는 상호작용 예시로 영상은 다음을 든다.^5
- 사용자가 누르는 버튼
- 글자를 입력하는 인풋(Input)
- 사용자의 정보를 입력받아 애플리케이션이 동작하도록 “지원”하는 전반적 기능
이 설명의 요지는 “사용자가 만지는 모든 것”이 프론트엔드의 일차적 책임 범위이며, 사용자의 입력이 서비스 동작으로 이어지도록 연결해 주는 역할이라는 것이다.^6
3.3 프론트엔드의 핵심 고려사항 1: UI/UX(설계와 철학)^7
영상은 프론트엔드에서 중요한 기반으로 UI와 UX를 제시한다.^7 프론트엔드는 “사용자가 이 서비스를 어떻게 이용할지에 대한 설계와 철학이 있어야” 하며, 그 설계/철학이 UI/UX로 나타난다고 말한다.^7
- UI(User Interface): 사용자가 서비스를 “친화적으로 사용할 수 있도록” 인터페이스를 고민해야 한다는 관점으로 설명한다.^8
- UX(User Experience): 사용자가 서비스를 “좀 더 친화적으로 사용할 수 있도록” 경험이 설계되어야 한다고 말한다.^9
즉, 프론트엔드는 단순 구현이 아니라 “어떻게 쓰게 할 것인가”를 전제로 구성해야 한다는 메시지다.^7
[!IMPORTANT] UI/UX를 ‘디자인 꾸미기’가 아니라 ‘사용 방식의 설계’로 설명
프론트엔드는 화면을 만들지만, 그 화면은 사용자의 행동 흐름(입력→이동→완료)을 설계하는 결과물이며, 이를 UI/UX라는 표현으로 묶어서 강조한다.^7
3.4 프론트엔드의 핵심 고려사항 2: 크롤봇(검색/플랫폼)이 읽을 수 있는 구조^10
프론트엔드는 사람이 보는 화면만이 아니라, 구글/네이버의 “크롤봇 같은 플랫폼에서 저희의 서비스를 읽을 수 있어야” 한다고 말한다.^10 그래서 프론트엔드는 크롤봇 친화적인 환경을 만들어야 한다는 요구가 추가된다고 설명한다.^10
이 대목은 프론트엔드가 “렌더링 결과가 외부 시스템(검색엔진 등)에 어떻게 인식되는가”도 고려해야 한다는 관점을 깔고 있다.^10
3.5 CSR(클라이언트 사이드 렌더링)과 SPA로 이어지는 흐름^11
영상은 “CSR이라는 개념은 지금 당장 모르셔도 된다”고 전제하면서도, 최근 프론트엔드에서 중요한 변화로 CSR을 설명한다.^11 CSR은 Client Side Rendering의 약자라고 밝힌다.^12
3.5.1 과거 방식(서버 렌더링 중심)의 설명과 문제 제기^12
기존 웹 애플리케이션에서는 서버가 HTML 파일을 클라이언트 측으로 “렌더링해주는 역할”을 했다고 설명한다.^12 그런데 HTML이 서버에서 클라이언트로 렌더링되는 구조에서는, 사용자가 새로고침을 하거나 다시 접속하면 “모든 파일들을 다시 렌더링해야 되는” 문제가 생긴다고 말한다.^13
그 결과, 이 과정에서 “오버헤드가 심하게 발생”했다고 언급하며, 이것이 최근 CSR 선호로 이어진 배경이라고 설명한다.^13
[? 질문] 왜 최근에는 CSR(클라이언트 사이드 렌더링)을 주로 사용하는가^14
[= 답] 서버에서 매번 전체를 다시 렌더링해야 하는 구조는 새로고침/재접속 때 비용(오버헤드)이 커지므로, 이를 줄이기 위해 CSR이 주로 사용된다는 설명이다.^13
3.5.2 CSR과 SPA의 연결^15
영상은 CSR이 “싱글 페이지 애플리케이션(SPA)” 개념과 맞닿아 있다고 말한다.^15 즉, 화면 전환을 할 때마다 전체 페이지를 새로 받기보다는, 클라이언트에서 필요한 부분을 갱신하는 방식의 맥락으로 CSR을 위치시킨다.^15
3.6 프론트엔드의 상태(State) 관리와 서버와의 유기적 호흡^16
프론트엔드에서는 사용자가 클릭하거나 인풋값을 입력할 때 생기는 정보를 “스테이트(state)”라고 부르며, 이 “스테이트 관리를 해주셔야” 한다고 말한다.^16
또한 사용자가 필요한 정보를 렌더링(표시)하려면 “서버와 유기적인 호흡이 가능해야” 한다고 강조한다.^17 즉, 프론트엔드는 화면만 만드는 것이 아니라 서버에서 데이터를 가져오고, 사용자 입력을 서버로 보내 저장되게 하는 흐름까지 포함한다는 뜻이다.^18
3.6.1 비동기 통신(ajax로 언급)으로 데이터 주고받기^18
영상은 이 지점에서 “gmail에서 사용을 했었던 ajax 기술”이 이용된다고 말한다.^18 (발음은 “agx”로 표기되어 있으나 맥락상 AJAX로 설명된다.)^18
요지는 프론트엔드가 서버/DB에서 데이터를 가져와 화면에 뿌리고, 입력값을 서버로 보내 DB에 저장하는 상호작용을 수행한다는 것이다.^19
이 때문에 프론트엔드는 사용자가 “불편함 없이” 서비스를 이용하도록 만드는 것이 중요하고, 그 이유로 “디자인 측면이 굉장히 강조”된다고 말한다.^20
3.7 프론트엔드 화면을 “컴포넌트 단위”로 나눠 개발하는 예시^21
영상은 프론트엔드의 구체 예시로 화면 구성을 든다.^21
이런 구성요소를 “컴포넌트 단위로 나눠서 개발”한다고 설명한다.^22 컴포넌트 단위로 나누면 각 부분에서 다음을 결정해야 한다고 말한다.^23
이 모든 판단을 UI/UX 관점에서 확인하며 개발하라고 말한다.^23
3.8 로그인 화면 예시: 입력 → 클릭 → 서버로 페이로드 요청^24
로그인 화면도 같은 원리라고 말하며, 프론트엔드에서 다루는 항목을 구체적으로 나열한다.^24
그리고 사용자가 입력 후 클릭하면, 입력 정보가 **페이로드(payload)**로 담겨 서버로 요청이 나간다고 설명한다.^25 서버는 프론트엔드에서 전달된 정보를 바탕으로 다음을 할 수 있다고 말한다.^25
즉 “프론트에서 이벤트 발생 → 서버 요청 → 서버 처리/DB 저장 → 응답 반환”이라는 기본 구조를 로그인 사례로 연결해 보여준다.^25
3.9 프론트엔드에서 쓰는 대표 프레임워크/언어 스택^26
영상은 “프론트엔드에서는 어떤 언어들이 사용될까요”라는 흐름으로 대표 선택지를 제시한다.^26
3.9.1 많이 쓰는 프레임워크/라이브러리 예시^26
3.9.2 기초 언어: HTML, CSS^27
프론트엔드에서 기초적으로 알아야 할 언어로 HTML과 CSS를 든다.^27
- HTML은 “마크업 언어”이며, 개발 언어라기보다는 JSON, YAML(영상에서는 “암”으로 표기) 같은 “구조화된 파일 형식에 가깝다”고 설명한다.^28
- HTML은 애플리케이션 “전체 틀”을 구성하는 역할이라고 말한다.^29
CSS는 배경을 초록/회색으로 할지, 흰색/검은색으로 할지 같은 “스타일을 정하는 부분”이라고 설명한다.^30
3.9.3 CSS를 편하게 쓰는 도구 예시(MUI, Styled Components)^31
CSS를 더 편하게 쓸 수 있게 지원해주는 도구로 MUI나 Styled Components를 언급한다.^31 이런 도구를 리액트와 함께 쓰면 프론트엔드를 더 쉽게 개발할 수 있다고 말한다.^32
3.9.4 프론트엔드 필수 언어: JavaScript와 DOM 조작^33
프론트엔드에서 “가장 필요한 언어는 자바스크립트”라고 단언한다.^33 이유로 다음을 든다.^34
- 자바스크립트로 HTML의 **DOM(Document Object Model)**을 조작할 수 있다.^34
- 리액트/Vue/리액트네이티브 및 MUI 같은 컴포넌트들을 자바스크립트로 컨트롤할 수 있다.^35
따라서 프론트엔드를 생각한다면 JavaScript가 “필수적”이라고 결론짓는다.^35
3.10 백엔드의 정의: 사용자가 보지 못하는 곳(데이터/서버/배포)^36
백엔드는 프론트엔드와 달리 “사용자가 보지 못하는 곳에 대한 기술”이라고 설명한다.^36 즉, 화면 뒤에서 서비스가 동작하기 위해 필요한 데이터 저장/처리/전송/운영 체계를 의미한다.^36
3.11 백엔드의 핵심 업무 1: 데이터베이스 스키마와 데이터 관리^37
백엔드에서 먼저 해야 할 일로 “데이터베이스 스키마 관리”를 든다.^37 그리고 데이터베이스에 “적재되는 정보” 자체를 관리해야 한다고 말한다.^38
영상은 데이터베이스의 큰 분류로 SQL과 NoSQL을 언급하며(“지금은 당장 모르셔도 된다”는 단서를 붙임), SQL로 구성한다면 DB 정규화가 필수라고 말한다.^39
이어서 대규모 운영에서 필요한 개념을 나열한다.^40
- 샤딩(Sharding)^40
- 레플리카 셋(Replica set)^40
- 마스터-슬레이브 구조로 구성해 효율적으로 운영^40
- 대규모 트래픽 상황에서 데이터 로스가 발생하지 않도록 하는 작업^40
이 모든 DB 확장/안정성/고가용성 관점의 작업을 백엔드에서 진행한다고 설명한다.^40
[!IMPORTANT] 백엔드는 “DB를 그냥 쓰는 것”이 아니라 “트래픽과 장애를 견디게 만드는 것”까지 포함
영상은 정규화 같은 설계 개념뿐 아니라, 샤딩/레플리카/마스터-슬레이브 같은 운영 구조를 함께 언급하며 백엔드 책임 범위를 넓게 잡는다.^39
3.12 백엔드의 핵심 업무 2: REST API 제작 및 유지보수^41
두 번째로 백엔드는 REST API를 제작해야 한다고 말한다.^41 다만 REST API에 대한 “명확한 규정이 나와 있지 않다”고 언급한다.^42
그럼에도 기본 기대사항을 다음처럼 설명한다.^43
- 어떤 URL에 어떤 HTTP 메소드로 요청을 보냈을 때
- “기대한 결과값”이 서버로부터 반환되어야 한다.^43
따라서 백엔드는 이런 API를 제작하고 유지보수하는 작업을 한다고 정리한다.^43
3.13 백엔드의 핵심 업무 3: 서버 관리(여러 대, 분산, 트래픽 분담)^44
백엔드는 서버 관리도 해야 한다고 말한다.^44 여기서 “서버가 한 대만 있는 게” 아니라는 점을 강조하며, 여러 대로 분산된 서버들이 유기적으로 트래픽을 분담받아 API를 반환하고 DB에 접근해야 한다고 설명한다.^45
또한 대규모 트래픽이 들어왔을 때 트래픽을 “어떻게 분산 처리할지”를 고려해서 서버를 제작해야 한다고 말한다.^45
3.14 백엔드의 핵심 업무 4: CI/CD와 무중단 배포(카카오톡 예시)^46
마지막으로 CI/CD를 소개한다.^46 이는 “Continuous Integration / Continuous Deploy(Deployment)”의 의미로, 지속적 통합/지속적 배포를 관리하는 것이라고 설명한다.^46
영상은 이해를 위해 카카오톡을 예로 든다.^47
- 카카오톡에 업데이트가 생겼을 때, 업데이트를 반영하려고 “서비스를 중단”하고 업데이트 후 다시 게시한다면 서비스에 남아있는 사용자는 극히 소수일 것이라고 말한다.^48
- 그래서 사용자는 계속 서비스를 이용하지만, 백엔드가 CI/CD를 관리해 “무중단 배포, 무중단 통합”이 되도록 한다고 설명한다.^49
- 결과적으로 사용자는 계속 이용하고, 내부적으로는 업데이트가 진행되어 “업데이트를 해야 서비스를 계속 이용할 수 있도록” 정책/체계를 관리하는 것이 백엔드 업무라고 말한다.^49
[? 질문] 왜 CI/CD(지속적 통합/배포)가 백엔드의 중요한 업무인가^48
[= 답] 업데이트 때마다 서비스를 멈추면 사용자가 이탈하므로, 사용 중단 없이 업데이트가 반영되도록 무중단 배포/통합 체계를 운영해야 하기 때문이다.^48
3.15 백엔드 실무 예시: API 테스트 툴과 DB 스키마 작성^50
영상은 백엔드 작업을 “보면” 이런 것들이 있다고 하며 예시 화면/도구를 든다.^50
3.15.1 API 테스트 툴: Insomnia, Postman^50
API 테스트 툴로 Insomnia나 Postman을 언급한다.^50 실제 API를 입력하고 페이로드를 입력한 다음 DB로부터 결과값을 받아오는 장면이라고 설명한다.^51 즉, API별로 테스트를 진행할 때 이런 도구로 확인하면 된다고 말한다.^51
3.15.2 데이터베이스 스키마 설계와 정규화 단계 언급^52
데이터베이스 “키마(스키마)”를 작성해야 한다고 말하며, 앞서 말한 정규화나 정보 관리를 목적으로 DB 스키마를 어떻게 짤지 고민해야 한다고 한다.^52
또한 정규화가 “몇 단계까지 정교화 되어 있는지”도 고려 포인트로 언급한다.^53
영상은 실무적 타협선처럼 “보통은 정규화 3단계까지만 진행해도 문제는 없다”는 취지로 말하면서도, 결국 핵심은 데이터베이스를 어떻게 구성할지 고민이 필요하다고 정리한다.^53
3.16 백엔드에서 사용되는 언어/프레임워크와 실행 방식(스크립트 vs JVM)^54
영상은 백엔드에서 쓰는 언어를 열거하고, 특히 “스크립트 언어”와 “자바(JVM)”의 실행 방식 차이를 설명한다.^54
3.16.1 백엔드 프레임워크/언어 예시 나열^54
- Java 기반: 스프링(Spring) 프레임워크^54
- JavaScript 기반: Express^54
- Ruby, PHP^55
- Python(데이터 분석/머신러닝/딥러닝 분야에서 많이 쓰임) 및 이를 기반으로 한 백엔드 툴이 있다고 언급^55
3.16.2 “스크립트 언어” 설명^56
영상은(표현상 다소 혼재가 있으나) 자바스크립트/장고/PHP/루비 등을 묶어 “전부 다 스크립트 언어”라고 말하며, 이들은 “컴파일이 따로 진행이 안 돼도 프로그램을 돌릴 수 있다”고 설명한다.^56
3.16.3 Java는 JVM을 통해 OS에 상관없이 실행^57
자바는 특이하게 **JVM(가상 머신)**을 이용한다고 말한다.^57 이 가상 머신에 바이트코드를 입력하면 OS에 상관없이 스프링과 자바를 돌릴 수 있다고 설명하며, 그래서 자바가 굉장히 많이 쓰이는 언어 중 하나라고 덧붙인다.^57
3.16.4 Node.js/Django/PHP/Ruby는 “바로 실행”되는 언어로 설명^59
마지막으로 노드JS, 장고, PHP, 루비 같은 경우는 스크립트 언어로 컴파일 없이 “프로그램을 바로 실행할 수 있는” 언어라고 정리한다.^59
3.17 결론: 한 스택을 잡아 전체 흐름을 이해하면 스택 이동은 가능하다^60
영상은 오늘 내용이 프론트엔드/백엔드 차이점 설명이었다고 정리한 뒤, 마지막으로 강조하고 싶은 메시지를 제시한다.^60
- 트렌드나 프론트엔드/백엔드 구분도 중요하지만, “사실 하나의 언어, 하나의 프레임워크만 이해”해도 웹/모바일 애플리케이션이 어떻게 개발되고 실제 서비스가 되는지 전체를 이해할 수 있다고 말한다.^61
- 그러면 예를 들어 리액트로 시작한 뒤 Vue.js를 다시 배워도 되고, 스프링을 한 뒤 Express나 Django를 해도 된다고 설명한다.^62
- 언어와 프레임워크 차이가 있지만, HTTP 프로토콜로 작동되는 웹 애플리케이션의 특성상 큰 차이가 없다고 주장한다.^63
- 따라서 “접근하기 쉬운 언어와 프레임워크”를 선택해서 거기서부터 시작하면 웹/모바일 개발이 쉽게 다가올 것이라고 결론짓는다.^64
[!TIP] 시작 스택 선택 기준(영상의 조언을 실행 형태로 재구성)
“가장 접근하기 쉬운” 언어/프레임워크를 하나 고르고, 그걸로 HTTP 기반 요청/응답, 프론트-서버-DB 흐름, 배포까지의 전 과정을 먼저 경험한 뒤 필요하면 다른 스택으로 확장하라는 접근이다.^63
4. 핵심 통찰^1
- 프론트엔드는 “화면을 만든다”를 넘어, **사용자 상호작용(입력/클릭)**을 서비스 동작으로 연결하고 서버와 데이터 통신까지 포함하는 영역으로 설명된다.^5
- 프론트엔드 역량은 구현뿐 아니라 UI/UX 설계(사용자가 친화적으로 쓰게 만드는 관점)가 핵심 축으로 제시된다.^7
- CSR과 SPA 언급을 통해, 프론트엔드가 단순 마크업이 아니라 **렌더링 전략/성능(오버헤드)**까지 고려하는 분야임을 강조한다.^13
- 백엔드는 DB 설계(정규화)뿐 아니라, 샤딩/레플리카/마스터-슬레이브 같은 확장성과 안정성 구조까지 책임지는 것으로 설명된다.^39
- 백엔드의 중심 산출물 중 하나는 REST API이며, “요청을 보내면 기대한 결과를 반환”하는 계약을 설계·유지하는 일로 묘사된다.^43
- 운영 관점에서 백엔드는 서버 분산과 트래픽 처리, 그리고 CI/CD 기반 무중단 배포가 중요한 업무로 제시된다(카카오톡 업데이트 예시).^45
- 언어/프레임워크는 달라도 웹은 HTTP 기반이라 큰 틀에서 차이가 크지 않으므로, 하나로 시작해 전체를 이해하면 스택 이동이 가능하다는 학습 전략을 제안한다.^63
- 실행 가능한 시사점(영상 조언 기반)
5. 헷갈리는 용어 정리 (해당 시에만)^11
프론트엔드: 사용자가 직접 보는 화면을 만들고, 입력/클릭 등 상호작용 및 서버와의 데이터 교환을 담당하는 영역.^4
백엔드: 사용자가 보지 못하는 영역에서 DB/서버/API/배포 등 시스템 동작 기반을 담당하는 기술 영역.^36
UI (User Interface): 사용자가 서비스를 친화적으로 사용할 수 있도록 인터페이스를 설계하는 관점.^8
UX (User Experience): 사용자가 서비스를 더 친화적으로 이용하도록 경험을 설계하는 관점.^9
크롤봇: 구글/네이버 등 플랫폼에서 서비스를 “읽는” 봇(검색엔진 수집 맥락).^10
CSR (Client Side Rendering): 클라이언트 측에서 렌더링을 수행하는 방식으로 소개되며, 서버 렌더링의 오버헤드 문제 맥락에서 언급.^12
SPA (Single Page Application): CSR과 맞닿아 있는 개념으로 언급.^15
State(스테이트): 클릭/입력 등 사용자 상호작용 과정에서 생기는 정보로, 프론트엔드에서 관리해야 하는 대상.^16
AJAX: (영상에서는 “gmail에서 사용” 예로) 서버와 유기적으로 데이터를 주고받는 기술로 언급.^18
Payload(페이로드): 사용자가 입력한 정보가 서버 요청에 담겨 전달되는 데이터.^25
DB 정규화: SQL 기반 DB 구성 시 필수로 들어간다고 언급된 설계 기법.^39
샤딩(Sharding): 대규모 트래픽에서 DB를 효율적으로 운용하기 위해 언급된 분산 기법.^40
레플리카 셋(Replica set): 데이터 로스를 막고 효율을 높이기 위해 언급된 복제 구성.^40
마스터-슬레이브: 레플리카 구성 맥락에서 언급된 DB 구조.^40
REST API: URL과 HTTP 메소드로 요청했을 때 기대한 결과를 반환하도록 만드는 서버 API로 설명.^43
CI/CD: Continuous Integration/Continuous Deploy(Deployment). 지속적 통합/배포로, 무중단 배포/통합 맥락에서 설명.^46
JVM: 자바가 사용하는 가상 머신. 바이트코드를 통해 OS에 상관없이 실행 가능하다고 설명.^57