https://www.youtube.com/watch?v=yY5zUp1J-iI

1. 이건 꼭 알아야 한다^1

[? 질문] 웹사이트에서 백엔드는 정확히 무엇을 하고, 프론트엔드와는 어떻게 나뉘는가^1
[= 답] 웹사이트는 **프론트엔드(눈에 보이는 시각 요소)**와 **백엔드(데이터 저장·관리 및 요청 처리)**로 나뉘며, 백엔드는 주문/회원/결제 같은 데이터를 다루고 클라이언트 요청에 응답하는 서버 로직을 만든다.[^2]

[? 질문] 사용자가 “구매하기”를 누르면 서버에서는 어떤 흐름(요청-응답)으로 일이 처리되는가[^3]
[= 답] 클라이언트가 주문 정보를 담아 서버에 **리퀘스트(요청)**를 보내고, 서버는 로직을 실행해 데이터베이스에 저장한 뒤 **리스폰스(응답)**를 돌려주는 요청-응답 사이클로 웹앱이 동작한다.[^4]

[? 질문] 백엔드 개발에 필요한 기술 스택은 무엇이며, 클라우드·마이크로서비스·부가 데이터 기술은 왜 등장하는가[^5]
[= 답] 백엔드는 (1) 서버를 만드는 백엔드 언어/프레임워크, (2) 기능을 끌어다 쓰는 패키지/패키지 매니저, (3) 데이터를 담는 데이터베이스, (4) 운영을 위한 클라우드(IaaS/PaaS/SaaS), (5) 복잡도를 줄이는 마이크로서비스, (6) 이미지·검색·캐시·분석 같은 목적별 특수 저장/처리 기술로 확장된다.[^6]

---

2. 큰 그림[^7]

이 콘텐츠는 “백엔드 웹 개발이 무엇인지”를 사용자 행동(구매 버튼 클릭) 시나리오로 설명하면서, 서버·DB·API·클라우드·마이크로서비스·각종 백엔드 주변 기술을 A부터 Z까지 순서대로 연결해 보여주는 입문 로드맵이다.[^7] 특히 “요청이 서버로 들어오고 데이터가 DB에 저장된 뒤 응답이 나간다”는 웹의 기본 작동 원리를 중심축으로 삼아, 실제 개발에서 어떤 도구(프레임워크/패키지)와 운영 방식(클라우드, 스케일링)이 필요한지 확장해간다.[^8]

• 백엔드의 본질은 데이터와 요청 처리다: 장바구니/주문/포인트 같은 정보를 저장·관리하고, 클라이언트 요청을 받아 처리한 뒤 응답한다.[^2]
• **API는 서버가 “처리할 수 있는 요청의 목록”**이며, 보통 REST 규칙(명사 URL + 동사 HTTP 메서드)으로 설계하지만 GraphQL, RPC 같은 다른 규칙도 존재한다.[^9]
• 클라우드는 빌려 쓰는 컴퓨팅이고, 트래픽 변동에 따라 가상머신을 늘리고(스케일 아웃) 로드밸런서로 분배하며, 더 나아가 PaaS/SaaS로 운영 부담을 줄인다.[^10]

---

3. 하나씩 살펴보기[^11]

3.1 웹사이트는 프론트엔드/백엔드로 나뉜다^1

영상은 “모든 웹사이트는 두 부분으로 나눌 수 있다”는 선언으로 시작한다.^1

• 프론트엔드: 웹페이지에서 사용자가 “볼 수 있는 모든 시각적 요소”를 의미한다.[^2] 즉 화면(UI)에 나타나는 구성요소 전반을 가리킨다.[^2]
• 백엔드: “여러분의 데이터를 저장하고 관리하는 것”이라고 정의한다.[^2]

백엔드가 다루는 데이터의 예시로 네이버 쇼핑을 들어, 사용자의 프로필, 장바구니, 주문내역, 포인트, N페이머니 같은 항목들이 “관리 대상 데이터”라는 점을 구체적으로 언급한다.[^3] 이는 백엔드가 단순히 서버 컴퓨터 그 자체가 아니라, 비즈니스에서 중요한 상태(사용자/주문/결제 등)를 다루는 층이라는 메시지로 이어진다.[^3]

또한 이 영상에서는 백엔드에서 사용되는 기술을 살펴보고, 프론트엔드 기술은 다른 영상에서 다룰 예정이라고 안내한다.[^4]

3.2 “구매하기” 클릭으로 이해하는 클라이언트-서버 메시지[^5]

화자는 쿠팡에서 쇼핑하다가 “주문할 준비가 되었다”는 상황을 가정한다.[^5]
사용자가 구매하기 버튼을 클릭하면 무슨 일이 일어나는지를 질문 형태로 던진다.[^5]

[? 구매하기 버튼을 클릭하면 무슨 일이 일어날까] [^5]
[= 내 컴퓨터(클라이언트)가 쿠팡 서버(서버)에게 주문 내역이 담긴 메시지를 보낸다] [^6]

여기서 핵심 전제는 다음과 같다.

• “인터넷에 연결된 모든 컴퓨터는 다른 컴퓨터에 메시지를 보낼 수 있다.”[^6]
• 따라서 “우리 컴퓨터는 쿠팡의 어느 서버 컴퓨터에도 메시지를 보낼 수” 있으며, 그 메시지는 주문 내역을 포함한다.[^6]

이때 용어를 정리한다.

• 메시지를 보내는 컴퓨터: 클라이언트(client)[^7]
• 메시지를 받는 컴퓨터: 서버(server)[^7]

즉, 사용자의 브라우저/기기 쪽은 클라이언트, 쿠팡 쪽에서 요청을 받아 처리하는 쪽은 서버로 설명된다.[^7]

3.3 서버는 “그냥” 메시지를 받을 수 없어서 백엔드 언어가 필요하다[^8]

화자는 중요한 제약을 짚는다: “컴퓨터는 기본적으로 인터넷에서 메시지를 받을 수가 없다”고 말한다.[^8] 즉, 네트워크 요청을 수신하고 처리하는 프로그램이 자동으로 존재하지 않는다는 뜻이다.[^8]

• 메시지를 수신할 수 있도록 “우리가 직접 프로그래밍 해줘야” 하며[^8]
• 그래서 “백엔드 프로그래밍 언어가 필요”하다고 연결한다.[^9]

또한 “거의 모든 프로그래밍 언어”에는 공통 기능이 있는데, 그게 바로 “이 컴퓨터를 서버로 바꿔서 메시지를 수신할 수 있게 해준다”는 점이라고 설명한다.[^9]
즉 특정 언어만 서버를 만들 수 있는 게 아니라, 다양한 언어로 서버를 만들 수 있다는 관점을 제공한다.[^9]

인기 있는 백엔드 언어 예시로 다음을 열거한다.[^10]

• 자바스크립트(JavaScript)[^10]
• 파이썬(Python)[^10]
• 루비(Ruby)[^10]
• PHP[^10]
• 자바(Java)[^10]

3.4 프레임워크와 패키지 매니저: “언어만으로는 너무 어렵다”[^11]

여기서 화자는 현실적인 개발 난이도를 강조한다.

• 백엔드 언어 “자체만을 사용하는 것은 실제로 매우 어렵고 많은 양의 코드가 필요”하다고 말한다.[^11]
• 그래서 더 쉽게 개발하기 위해 도구를 써야 하고, 그 도구가 “프레임워크와 패키지 매니저”라고 제시한다.[^12]

3.4.1 백엔드 프레임워크가 하는 일[^13]

백엔드 프레임워크는 “훨씬 적은 코드로 서버를 더 쉽게 만들 수 있도록 도와준다”고 정의된다.[^13]
즉 서버 개발에서 반복되는 기반 작업(라우팅, 요청 처리 구조, 미들웨어 등)을 프레임워크가 제공해 개발자가 비즈니스 로직에 집중하게 한다는 취지로 설명된다.[^13]

언어별 대표 프레임워크 예시는 다음과 같이 나열된다.[^14]

• 자바스크립트: Express.js[^14]
• 파이썬: Django[^14]
• 루비: Ruby on Rails[^14]
• 자바: Spring[^14]
• PHP: Laravel[^14]

3.4.2 패키지와 패키지 매니저[^15]

화자는 “프로그램은 혼자 만들 수가 없다”고 말하며, 실무적으로 타인이 작성한 코드를 가져다 쓰는 것이 일반적임을 전제한다.[^15]
그 “다른 사람들이 작성한 코드”를 **패키지(package)**라고 부른다고 설명한다.[^15]

패키지를 쓰는 목적 예시는 다음과 같이 제시된다.[^16]

• 계산 기능[^16]
• 데이터베이스 접근[^16]
• 사용자 로그인과 인증 관리[^16]

그리고 패키지들을 “설치하고 관리”하기 위해 **패키지 매니저(package manager)**를 사용한다고 한다.[^16]
언어마다 자체 패키지 관리자가 있고, 대표적인 것으로 아래를 든다.[^17]

• 자바스크립트: npm[^17]
• 파이썬: pip[^17]
• 자바: Maven(메이븐)[^17]

[!TIP] 프레임워크 vs 패키지 매니저를 영상의 문장 그대로 구분하기
프레임워크는 “서버를 쉽게 만들게 해주는 큰 틀/도구”이고, 패키지 매니저는 “계산·DB접근·로그인/인증 같은 기능 패키지를 설치/관리하는 도구”로 소개된다.[^13]

3.5 데이터를 저장하는 공간: 데이터베이스와 서버의 통신[^18]

다음으로 “필요한 것은 데이터를 저장할 공간”이라고 하며 데이터베이스로 넘어간다.[^18]
여기서 데이터 예시로 다음을 든다.[^18]

• 회원 정보[^18]
• 주문 목록[^18]
• 상품 정보[^18]
• 별점[^19]
• 상품 리뷰[^19]

이런 데이터를 저장하고 관리하기 위해 “데이터베이스를 사용”한다고 말한다.[^19]

중요한 포인트는 데이터베이스의 존재 형태다.

• 데이터베이스는 “다른 컴퓨터에서 실행되는 소프트웨어”라고 설명한다.[^20]
• 따라서 “우리의 컴퓨터(서버)가 데이터베이스와 통신할 수 있도록 설정”해야 한다고 말한다.[^20]

인기 있는 데이터베이스 예시는 다음으로 제시된다.[^21]

• MySQL[^21]
• PostgreSQL(자막상 post class로 표기)[^21]
• MongoDB[^21]

그리고 질문 형태로 백엔드 개발자가 무엇을 해야 하는지 결론을 만든다.

[? 백엔드 서버를 개발하기 위해 해야 할 것은 무엇일까] [^22]
[= 서버와 데이터베이스를 프로그래밍하는 것이다] [^22]

즉 백엔드 개발은 서버 로직만이 아니라 DB와의 연동/저장까지 포함한다는 구조를 잡는다.[^22]

3.6 주문 처리 흐름: 요청(request) → DB 저장 → 응답(response)[^23]

쿠팡 주문 예시로 서버-DB-클라이언트 흐름을 단계적으로 설명한다.[^23]

1. 고객이 구매 버튼을 누르면 “주문 내역이 서버로 전달”된다.[^23]
2. 서버는 그 주문 내역을 “데이터베이스에 저장”한다.[^24]
3. 서버는 “주문이 처리되었다”는 메시지를 클라이언트에 “응답 메시지로” 보낸다.[^24]

그리고 이 메시지 왕복을 용어로 확정한다.

• 프론트엔드 → 백엔드로 보내는 메시지: 리퀘스트(request, 요청)[^25]
• 백엔드 → 프론트엔드로 보내는 메시지: 리스폰스(response, 응답)[^25]
• 이 주고받는 사이클: 요청-응답 사이클[^26]

화자는 “바로 이런 사이클이 웹 애플리케이션이 작동하는 방식”이라고 일반화한다.[^26]

[!IMPORTANT] 웹앱의 작동 방식으로 제시된 단일 문장
“요청-응답 사이클이 웹 애플리케이션이 작동하는 방식”이라는 문장으로, 이후 API/REST/클라우드까지 모든 설명이 이 구조 위에 쌓인다.[^26]

3.7 리퀘스트(요청) 안에는 무엇이 들어있나: 도메인, 타입, URL 패스[^27]

화자는 “이제 리퀘스트 안에 뭐가 있는지”를 본다고 한다.[^27]
주문 상황에서 요청이 담을 수 있는 정보 예시는 다음과 같다.[^27]

• 주문한 상품이 무엇인지[^27]
• 주문 수량[^27]
• 결제 수단(“결제는 뭐로 할 것인지”)[^27]

또한 주문 내용 외에도 요청에는 다음이 있다고 말한다.[^28]

• 요청의 타입 정보[^28]
• 도메인 이름[^28]
• URL 패스 정보[^28]

3.7.1 도메인은 목적지다[^29]

도메인 설명에서 쿠팡이 쿠팡닷컴 도메인을 “돈을 주고 구입”한다는 점을 든다.[^29]
그리고 쿠팡닷컴으로 가는 요청들은 쿠팡의 서버로 “리디렉션”된다고 설명한다.[^30]
따라서 “리퀘스트의 도메인 부분이 의미하는 것은 목적지”라고 결론짓는다.[^30]

3.7.2 타입과 URL 패스는 “어떤 종류의 요청인지”를 나타낸다[^31]

“타입과 URL 패스는 리퀘스트가 어떤 종류의 요청인지 나타낸다”고 설명한다.[^31]
그림 예시로 “타입이 POST이고 URL 패스가 /orders”라고 든다.[^31]

그리고 서버에서 요청을 처리하게 하려면, 프로그래밍 언어와 백엔드 프레임워크로 “다양한 종류의 요청들을 어떻게 처리할 것인지 코드를 짠다”고 연결한다.[^32]

3.8 라우팅 예시: POST /orders, GET /orders, DELETE /orders[^33]

화자는 동일한 URL 패스(/orders)라도 **타입(메서드)**에 따라 의미가 달라짐을 예시로 보여준다.[^33]

• POST /orders로 요청이 오면:

  • 주문 내역을 “생성”하고[^33]
  • 데이터베이스에 “저장”한 뒤[^33]
  • “주문이 처리됐다”고 “응답”한다.[^33]

• GET /orders로 요청이 오면:

  • 데이터베이스에서 “과거 주문 내역을 가져오고”[^34]
  • 그것을 응답으로 보낸다.[^34]

• DELETE /orders로 요청이 오면:

  • 주문을 “취소하고 삭제”한다.[^35]

그리고 이렇게 “서버가 처리할 수 있는 요청들”을 API라고 부른다고 정의한다.[^36]
또한 “API는 백엔드 프로그래밍에서 가장 중요한 개념 중 하나”라고 중요도를 올려 말한다.[^37]

[h API는 백엔드 프로그래밍에서 가장 중요한 개념 중 하나로 제시된다] [^37]

3.9 REST: URL 패스는 명사, 동사는 HTTP 타입(메서드)[^38]

화자는 타입과 URL 패스로 리퀘스트를 정의할 수 있고, 타입에는 여러 종류가 있다고 말한다.[^38]
열거된 메서드는 다음과 같다.[^38]

• GET
• POST(자막상 first로 표기된 부분이 있으나 맥락상 POST 나열 구간)[^38]
• PUT
• PATCH
• DELETE

이후 질문을 던진다: 왜 주문 요청 API를 만들 때 타입을 POST로 정하고 URL 패스를 /orders로 지었는가.[^39]
그 답은 “일종의 약속”, 즉 URL 패스 이름을 짓는 규칙이라고 한다.[^39]

그 규칙/약속이 REST라고 소개한다.[^40]

[? 왜 URL 패스를 /orders 같은 형태로 짓는가] [^39]
[= URL 패스 이름을 짓는 약속이 있고, 그 대표가 REST다] [^40]

REST의 특징을 다음처럼 설명한다.[^40]

• URL 패스에는 명사가 들어간다.[^40] (예: orders)
• “동사는 어디에 있을까요”라는 질문을 던진 뒤[^41]
• 요청의 타입이 액션, 즉 동사라고 보면 된다고 한다.[^41]

그리고 메서드 의미를 예로 맵핑한다.[^42]

• POST = “뭔가를 생성”[^42]
• GET = “뭔가를 불러옴”[^42]
• DELETE = “뭔가를 삭제”[^43]

REST 규칙을 따르는 API를 “REST API”라고 부른다고 정리한다.[^43]
또한 REST는 “API 만들 때 가장 많이 사용하는 규칙”이라고 위치시킨다.[^44]

[!NOTE] 영상이 제시하는 REST의 요지(표현 유지)
URL 패스는 명사, 행위(동사)는 **요청 타입(메서드)**로 표현하는 것이 REST의 핵심 특징으로 설명된다.[^40]

3.10 REST 말고도: GraphQL과 RPC[^45]

화자는 REST 외에도 “다른 규칙들도 있겠죠”라고 말하며 대안을 소개한다.[^45]

3.10.1 GraphQL[^46]

GraphQL 규칙은 “모든 리퀘스트를 /graphql로 보낸다”고 설명한다.[^46]
즉 REST처럼 리소스별로 다양한 URL을 만들기보다, 단일 엔드포인트로 모으는 특징을 강조한다.[^46]

3.10.2 RPC[^47]

RPC는 “좀 더 상세한 URL 패스를 사용”하는 것이 특징이라고 한다.[^47]
예시로 다음을 든다.[^48]

• POST /createOrder : 주문 생성 의미[^48]
• POST /getOrderHistory : 주문 히스토리 조회 예[^48]

그리고 RPC 방식의 URL은 “동사와 명사가 합쳐진 문장”으로 볼 수 있다고 해석한다.[^49]

이로써 “리퀘스트가 무엇인지”, “API가 무엇인지”, “API를 만드는 규칙인 REST/GraphQL/RPC”를 알아봤다고 중간 정리를 한다.[^50]

3.11 클라우드 컴퓨팅: 서버를 사지 않고 ‘렌트’한다 (IaaS)[^51]

이제 주제를 클라우드로 전환한다.[^51]
화자는 요즘은 “직접 서버를 구입하고 운영하는 회사는 거의 없다”고 말한다.[^51]
대신 “서버를 렌트해서 빌”리고[^51], 과거에는 “호스팅 업체”, 요즘은 “클라우드 업체”라고 부른다고 한다.[^52]

대표 클라우드 업체 예시는 다음과 같다.[^52]

• AWS(Amazon Web Services)[^52]
• GCP(Google Cloud Platform)[^52]
• Microsoft Azure(해저로 발음)[^52]
• Naver Cloud Platform[^52]

클라우드 컴퓨팅의 개념을 “별게 아니라 여러 대의 컴퓨터를 빌리는 것”이라며 단순화한다.[^53]
그리고 이를 “IaaS”, 즉 Infrastructure as a Service라고 풀어 설명한다.[^53]

3.11.1 가상머신(VM)과 데이터센터 그림[^54]

AWS는 “성능 좋고 빠른 컴퓨터들을 정말 많이 보유”하고 있고[^54], 서버 안을 들여다보면 수많은 컴퓨터가 있다고 한다.[^54]
이 “작은 컴퓨터”를 가상머신이라고 부르며, 우리는 사실 이런 작은 컴퓨터를 빌리는 것이라고 설명한다.[^55]

웹사이트 운영 시나리오는 다음처럼 제시된다.[^56]

• AWS 데이터센터의 서버 컴퓨터에서 가상머신을 빌려 백엔드 서버를 운영한다.[^56]
• 또 “다른 가상머신”을 빌려 데이터베이스 서버를 운영한다.[^57]

즉 서버/DB를 각각 별도의 VM으로 운영하는 그림을 통해, 인프라 구성의 기본 형태를 설명한다.[^56]

3.12 트래픽 폭증 문제와 해결: 스케일 아웃 + 로드밸런서[^58]

여기서 문제 제기를 한다: 쿠팡을 예로 들어 명절 전에 주문이 폭증하면 트래픽이 엄청 증가해 “서버가 감당을 못해서 터질 수” 있다는 것이다.[^58]

클라우드에서는 이 상황을 다음처럼 해결한다고 설명한다.[^59]

1. 같은 백엔드 코드를 돌리는 가상 머신을 “순식간에 여러 대” 빌린다.[^59]
2. 앞단에 로드 밸런서라는 “특별한 가상 머신”을 세팅한다.[^60]
3. 로드밸런서가 수많은 요청이 들어오면 “분배하는 역할”을 하며[^60],
   • 어느 한쪽에만 요청이 몰리지 않도록 분배한다.[^60]
   • “시키는 작업반장” 정도로 생각하면 된다고 비유한다.[^61]
   • 말 그대로 “로드를 밸런싱”한다고 덧붙인다.[^61]

그리고 명절이 끝나 접속량이 줄면 “추가한 가상 머신을 다시 꺼버린다”고 말한다.[^62]

이때 비용 효율성 논리를 제시한다.[^63]

• 서버를 직접 사서 운영한다고 가정하면 비싼 컴퓨터를 다 사야 하는데[^63]
• 명절이 지나면 그 장비가 “쓸모가 없어”진다.[^63]
• 그래서 클라우드 컴퓨팅이 비용 면에서 효율적이라는 결론을 낸다.[^63]

[c 트래픽 변동에 따라 VM을 빠르게 늘렸다가 줄여 비용 효율을 얻는 것이 클라우드 활용의 핵심 사례로 제시된다] [^62]

3.13 PaaS: 소스 코드 업로드만 하면 운영 세팅을 대신해준다[^64]

또 다른 문제를 제기한다: 화면처럼 많은 VM을 생성하고 세팅해야 하는데 “많은 시간과 노력”이 필요하다는 점이다.[^64]
이 운영 부담을 줄이기 위해 클라우드 업체들이 PaaS를 제공한다고 소개한다.[^65]

• PaaS에서는 “단지 백엔드 소스 코드를 업로드만 하면 된다.”[^65]
• 그러면 PaaS가 “알아서 가상머신과 로드밸런서를 세팅해준다.”[^66]

즉 직접 인프라를 구성(IaaS)하는 대신, 코드 배포 중심으로 추상화된 플랫폼(PaaS)을 활용하는 흐름을 설명한다.[^66]

3.14 마이크로서비스: 기능 단위로 코드베이스를 쪼갠다[^67]

이제 “마이크로 서비스”를 살펴본다.[^67]
AWS 위에 “우리의 백엔드 서버”가 있다고 가정하고, 그 백엔드가 다음과 같은 “수많은 역할”을 가진다고 한다.[^68]

• 주문 처리 기능[^68]
• 결제 처리 기능[^68]
• 이메일 전송 기능(자막상 “이메일 승부”로 표기)[^68]

큰 기업의 백엔드 코드는 “수십만에서 수백만 줄”에 달할 수 있다고 말하며, 그 경우 “너무 복잡해서 관리하기 어려울 수 있다”고 문제를 설정한다.[^69]

해결책은 한 서버의 거대한 코드베이스를 “3개의 코드베이스로 나누는 것”이라고 제시된다.[^70]
이처럼 “백엔드 코드를 기능 단위로 쪼개는 것”을 마이크로서비스라고 정의한다.[^70]
그리고 “각각의 마이크로서비스는 각각의 백엔드를 갖게 된다”고 말한다.[^70]

3.14.1 서비스마다 언어/DB가 달라도 된다[^71]

마이크로서비스는 “같은 프로그래밍 언어와 데이터베이스를 사용할 필요가 없다”고 명시한다.[^71]
예시로 다음 조합을 든다.[^72]

• 주문 백엔드: 언어는 자바스크립트, DB는 MySQL[^72]
• 결제 백엔드: 언어는 파이썬, DB는 MongoDB[^73]

즉 기능 단위 분리뿐 아니라 기술 선택의 자율성도 강조한다.[^71]

3.15 SaaS: 특정 기능은 남의 백엔드 API를 써서 해결한다[^74]

화자는 “마이크로서비스조차도 직접 구축할 필요가 없다”고 말하며 한 단계 더 나아간다.[^74]
예로 이메일 서비스를 제공하는 Twilio(트윌리오) 같은 회사를 든다.[^74]

• 우리는 직접 이메일 서비스를 구축할 필요 없이[^75]
• 트윌리오가 제공하는 API를 이용해서[^75]
• 트윰리오의 백엔드에 “나의 고객에게 이메일을 보내달라”고 요청을 보내면 된다고 설명한다.[^75]

이처럼 “특정 서비스의 백엔드와 API를 제공하는 것”을 **SaaS(Software as a Service)**라고 정의한다.[^76]
또 한국의 대표 SaaS 업체 예시로 채널톡을 언급한다.[^76]

그리고 여기까지가 “클라우드 컴퓨팅의 핵심인 IaaS, PaaS, SaaS”를 살펴본 것이라고 정리한다.[^77]

3.16 마지막 파트: 프라이머리 DB 외 ‘기타 백엔드 기술’의 필요성[^78]

영상 마지막 섹션으로 “여러 가지 백엔드 기술”을 소개한다.[^78]
초반에 언급한 MySQL/PostgreSQL/MongoDB 같은 DB를 “프라이머리 데이터베이스”라고 부르며[^79], 이는 “일반적으로 웹사이트가 사용하는 데이터베이스”라고 설명한다.[^79]

또한 백엔드 공부를 시작할 때 일반적으로 “서버와 프라이머리 데이터베이스 순서로 공부”한다고 말한다.[^80]
하지만 “이것만 가지고는 개발하는데 어려움이 있을 것”이라며[^81], 기타 백엔드 기술을 “다양하게 아는 것이 중요”하다고 강조한다.[^81]

3.16.1 이미지 업로드: 프라이머리 DB는 부적절 → S3/Blob Storage + CDN[^82]

유저가 이미지를 업로드했을 때 백엔드에서 이미지를 저장하는 경우, 프라이머리 DB는 “적절하지” 않다고 한다.[^82]
대신 보통 다음을 사용한다고 제시한다.[^83]

• Amazon S3 같은 Blob Storage[^83]
• CloudFront 같은 CDN 기술[^83]

즉 대용량 바이너리(이미지) 저장은 객체 스토리지 + 전송 최적화(CDN)로 처리한다는 방향을 제시한다.[^83]

3.16.2 텍스트 검색: 프라이머리 DB는 느림 → Elasticsearch[^84]

텍스트 서치도 “마찬가지로 프라이머리 데이터베이스는 느려서 적절하지” 않다고 말한다.[^84]
그래서 “서치 데이터베이스로 알려진 Elasticsearch 같은 기술”을 사용한다고 소개한다.[^84]

3.16.3 트래픽 증가 시 DB 부담: Redis 캐시로 성능 개선[^85]

웹사이트 트래픽이 많아지면 “데이터베이스도 부담”이 된다고 한다.[^85]
이때 DB 옆에서 “도와줄 조수”가 필요하다고 표현하며[^86], Redis 같은 캐시를 사용해서 성능을 개선할 수 있다고 제시한다.[^86]

3.16.4 데이터 분석: 프라이머리 DB를 쓰면 안 된다 → 분석용 DB(Snowflake)[^87]

데이터 분석 작업을 할 때도 프라이머리 DB를 사용하면 안 된다고 말한다.[^87]
이유는 프라이머리 DB는 “웹사이트를 운영하는데 집중해야” 하기 때문이라고 설명한다.[^88]
따라서 데이터 분석을 위한 “애널리티컬(analytical) 데이터베이스”가 따로 있으며, 예시로 Snowflake를 든다.[^88]

3.17 마무리: 이 정도 기술로 운영 가능 + ‘백엔드 로드맵’ 참고[^89]

화자는 “지금까지 영상에서 소개한 백엔드 기술만으로도 충분히 웹사이트를 운영할 수 있다”고 말한다.[^89]
추가로 구글에서 “백엔드 로드맵”을 검색하면 다양한 기술들이 나오며[^90], 이를 한번 살펴보고 “내가 얼마만큼 알고 있는지 판단”해보라고 권한다.[^90]

마지막으로 채널 진행자(“코딩셀러”로 발화)가 구독/좋아요/댓글을 부탁하며 종료한다.[^91]

---

4. 핵심 통찰[^92]

1. [h 백엔드는 ‘데이터를 저장·관리’하고 ‘요청을 처리해 응답’하는 역할로 정의된다.] 프론트엔드가 화면이라면, 백엔드는 주문/회원/포인트 같은 상태를 책임진다는 식으로 역할을 명확히 갈라 설명한다.[^2]
2. [h 웹의 동작은 요청-응답 사이클로 단순화할 수 있고, API는 그 요청 처리 능력의 집합이다.] 요청과 응답이라는 왕복 구조를 이해하면 이후 REST/GraphQL/RPC 같은 API 스타일도 같은 관점으로 묶인다.[^26]
3. [h 언어만으로 서버를 만드는 건 비효율적이어서 프레임워크/패키지 매니저가 필수 도구로 등장한다.] 프레임워크는 서버 구축 코드를 줄이고, 패키지/패키지 매니저는 필요한 기능을 조립하게 해준다는 도구 체계를 제시한다.[^12]
4. [h 클라우드는 “컴퓨터를 빌리는 것(IaaS)”이며, 스케일 아웃과 로드밸런싱으로 트래픽 변동을 흡수한다.] 명절 트래픽을 예로 들어 “늘렸다가 줄인다”는 비용 효율 논리를 보여준다.[^62]
5. [m 운영 자동화는 PaaS로, 기능 구매는 SaaS로 이동한다.] VM/로드밸런서를 직접 세팅하기 어렵기 때문에 코드 업로드만으로 운영을 맡기거나(PaaS), 특정 기능은 외부 API로 대체(SaaS)할 수 있다고 제안한다.[^66]
6. [m 규모가 커지면 마이크로서비스로 코드베이스를 기능 단위로 분리하고, 서비스별로 언어/DB 선택이 가능해진다.] 복잡도 관리 문제를 “쪼개기”로 해결하는 접근을 강조한다.[^70]
7. [h 프라이머리 DB 하나로는 부족하며, 목적별 저장/검색/캐시/분석 기술을 붙여야 운영이 가능해진다.] 이미지(S3+CDN), 검색(Elasticsearch), 캐시(Redis), 분석(Snowflake) 같은 ‘적재적소’ 구성을 제시한다.[^83]

• 실행 관점 체크리스트(영상 흐름 기반)
  • 서버 개발: 언어 선택 → 프레임워크 선택 → 패키지 매니저로 필수 패키지 구성[^12]
  • 데이터 계층: 프라이머리 DB 선택 및 서버-DB 통신 설정[^20]
  • API 설계: 요청 타입/URL 패스 설계, REST/GraphQL/RPC 규칙 중 선택[^45]
  • 운영: IaaS로 VM+LB 구성 또는 PaaS로 배포 단순화, 필요 시 SaaS API 활용[^65]
  • 확장: 트래픽/기능/데이터 유형에 따라 캐시·검색·CDN·분석 DB를 추가[^84]

---

5. 헷갈리는 용어 정리[^93]

프론트엔드: 사용자가 웹페이지에서 볼 수 있는 모든 시각적 요소.[^2]
백엔드: 데이터를 저장하고 관리하며, 클라이언트의 요청을 받아 처리하고 응답하는 영역.[^2]
클라이언트: 메시지(요청)를 보내는 컴퓨터.[^7]
서버: 메시지(요청)를 받는 컴퓨터.[^7]
프레임워크: 더 적은 코드로 서버를 쉽게 만들게 도와주는 개발 도구.[^13]
패키지: 다른 사람들이 작성해둔 재사용 코드 묶음.[^15]
패키지 매니저: 패키지를 설치하고 관리하는 도구(npm/pip/maven 등).[^17]
데이터베이스(DB): 데이터를 저장·관리하는 소프트웨어(보통 다른 컴퓨터에서 실행).[^20]
리퀘스트(Request): 프론트엔드 → 백엔드로 보내는 요청 메시지.[^25]
리스폰스(Response): 백엔드 → 프론트엔드로 보내는 응답 메시지.[^25]
요청-응답 사이클: 요청과 응답이 왕복하며 웹앱이 동작하는 기본 방식.[^26]
API: 서버가 처리할 수 있는 요청들의 집합.[^36]
REST: URL 패스는 명사, 동사는 HTTP 타입(메서드)로 표현하는 API 설계 규칙.[^40]
GraphQL: 모든 요청을 /graphql로 보내는 방식으로 소개된 API 규칙.[^46]
RPC: 동사+명사가 합쳐진 문장 같은 상세 URL 패스를 쓰는 API 규칙.[^49]
클라우드 컴퓨팅: 여러 대의 컴퓨터를 빌려 쓰는 개념.[^53]
IaaS: Infrastructure as a Service, 인프라(컴퓨터)를 빌리는 형태.[^53]
가상머신(VM): 클라우드에서 빌려 쓰는 ‘작은 컴퓨터’.[^55]
로드 밸런서: 들어오는 요청을 여러 서버로 분배하는 특별한 가상머신.[^60]
PaaS: 백엔드 소스 코드를 업로드하면 VM과 로드밸런서를 알아서 세팅해주는 서비스.[^66]
마이크로서비스: 기능 단위로 백엔드 코드를 여러 코드베이스/백엔드로 쪼개는 방식.[^70]
SaaS: 특정 서비스의 백엔드와 API를 제공해, 우리가 직접 구축하지 않고 이용하는 소프트웨어 서비스.[^76]
프라이머리 데이터베이스: 일반적으로 웹사이트가 사용하는 주 데이터베이스.[^79]
Blob Storage: 이미지 같은 파일/바이너리 저장에 쓰는 스토리지(S3 예시).[^83]
CDN: 콘텐츠 전송을 빠르게 하는 기술(CloudFront 예시).[^83]
Search Database: 텍스트 검색을 위해 쓰는 데이터베이스(Elasticsearch 예시).[^84]
Cache: DB 부담을 덜고 성능을 개선하는 보조 계층(Redis 예시).[^86]
Analytical Database: 데이터 분석 전용 데이터베이스(Snowflake 예시).[^88]

---

---

참고(콘텐츠 정보)[^94]

• 제목: 백엔드 개발 (Backend web development) - A to Z[^94]
• 채널: 코딩사과[^94]
• 길이: 16분 30초[^94]
• 링크: https://www.youtube.com/watch?v=yY5zUp1J-iI[^94]
• 키워드(제공): web development, backend, 백엔드, 백엔드 개발, DB, database, mysql, 클라우드 컴퓨팅[^94]

---

[^2]: @[00:05] "프론트엔드... 볼 수 있는 모든 시각적 요소" / @[00:14] "백엔드는... 데이터를 저장하고 관리"
[^3]: @[00:19] "네이버 쇼핑... 프로필 장바구니 주문내역 포인트... 등을 관리" / @[00:45] "구매하기 버튼을 클릭하면 무슨 일이 일어날까요"
[^4]: @[00:27] "백엔드에서 사용되는 기술" / @[00:32] "다른 영상에서 프론트엔드..."
[^5]: @[00:39] "쿠팡... 주문할 준비" / @[00:45] "구매하기 버튼..."
[^6]: @[00:50] "인터넷에 연결된 모든 컴퓨터..." / @[01:00] "메시지는 주문 내역"
[^7]: @[01:05] "클라이언트... 서버"
[^8]: @[01:15] "컴퓨터는 기본적으로... 메시지를 받을 수가 없습니다" / @[01:21] "직접 프로그래밍"
[^9]: @[01:26] "백엔드 프로그래밍 언어" / @[01:32] "서버로 바꿔서 메시지를 수신"
[^10]: @[01:40] "자바스크립트 파이썬 루비 PHP 자바"
[^11]: @[01:51] "언어 자체만... 어렵고 많은 양의 코드"
[^12]: @[01:58] "도구... 프레임워크와 패키지 매니저"
[^13]: @[02:08] "백엔드 프레임워크... 훨씬 적은 코드"
[^14]: @[02:16] "express... 장고... 루비온레일스... 스프링... 라라벨"
[^15]: @[02:32] "프로그램은 혼자..." / @[02:35] "패키지"
[^16]: @[02:40] "계산... 데이터베이스 접근... 로그인과 인증" / @[02:46] "패키지 매니저"
[^17]: @[03:00] "npm... pip... 메이븐"
[^18]: @[03:09] "데이터를 저장할 공간" / @[03:12] "회원 정보 주문 목록 상품 정보"
[^19]: @[03:20] "별점... 리뷰" / @[03:24] "데이터베이스"
[^20]: @[03:29] "다른 컴퓨터에서 실행" / @[03:33] "통신... 설정"
[^21]: @[03:40] "mysql... post class... 몽고디비"
[^22]: @[03:47] "서버와 데이터베이스를 프로그래밍"
[^23]: @[03:59] "주문 내역이 서버로 전달"
[^24]: @[04:03] "데이터베이스에 저장" / @[04:07] "응답 메시지"
[^25]: @[04:14] "리퀘스트(요청)" / @[04:24] "리스판스(응답)"
[^26]: @[04:32] "요청 응답 사이클" / @[04:36] "웹 애플리케이션이 작동"
[^27]: @[04:43] "리퀘스트 안에 뭐" / @[04:46] "주문한 상품... 결제"
[^28]: @[04:54] "타입 정보 도메인 이름 URL 패스"
[^29]: @[05:04] "쿠팡닷컴... 구입"
[^30]: @[05:09] "쿠팡에 서버로... 리드 액션(리디렉션)" / @[05:19] "도메인... 목적지"
[^31]: @[05:24] "타입과 URL 패스" / @[05:33] "타입이 포스트... /오더스"
[^32]: @[05:42] "프레임워크... 요청 처리... 코드"
[^33]: @[05:49] "POST... 주문 내역 생성... 저장... 응답"
[^34]: @[06:07] "GET... 과거 주문 내역... 응답"
[^35]: @[06:21] "DELETE... 취소하고 삭제"
[^36]: @[06:27] "서버가 처리할 수 있는 요청... API"
[^37]: @[06:33] "api는... 가장 중요한 개념"
[^38]: @[06:45] "타입에도 여러 종류... get... put... patch... delete"
[^39]: @[07:00] "왜... 포스트... /오더스"
[^40]: @[07:11] "URL 패스... 약속" / @[07:19] "이 규칙... rest" / @[07:24] "명사"
[^41]: @[07:28] "동사는 어디" / @[07:37] "타입이 액션 즉 동사"
[^42]: @[07:37] "포스트... 생성" / @[07:43] "겟... 불러오는"
[^43]: @[07:52] "딜리트... 삭제" / @[07:56] "rest api"
[^44]: @[08:06] "가장 많이 사용하는 규칙"
[^45]: @[08:12] "다른 규칙"
[^46]: @[08:19] "그래프 ql... /그래프 qr(ql)"
[^47]: @[08:26] "rpc" / @[08:30] "상세한 URL 패스"
[^48]: @[08:35] "post create order" / @[08:40] "post get order history"
[^49]: @[08:47] "동사와 명사가 합쳐진 문장"
[^50]: @[08:56] "지금까지... rest 그래프 ql rpc"
[^51]: @[09:07] "클라우드 컴퓨팅" / @[09:11] "직접 서버... 거의 없습니다"
[^52]: @[09:19] "호스팅 업체... 클라우드" / @[09:19] "aws... gcp... azure... 네이버"
[^53]: @[09:35] "여러대의 컴퓨터를 빌리는 것" / @[09:39] "iaas... 인프라스트럭쳐 as a 서비스"
[^54]: @[09:48] "aws... 컴퓨터... 많이 보유" / @[09:54] "수많은 컴퓨터"
[^55]: @[10:01] "가상머신" / @[10:10] "작은 컴퓨터를 빌림"
[^56]: @[10:10] "가상 머신... 백엔드 서버 운영"
[^57]: @[10:23] "다른 가상 머신... 데이터베이스 서버"
[^58]: @[10:30] "명절... 트래픽... 터질 수"
[^59]: @[10:49] "가상 머신... 여러대 빌립니다"
[^60]: @[10:58] "로드 밸런서... 분배"
[^61]: @[11:05] "작업반장" / @[11:12] "로드 밸런싱"
[^62]: @[11:23] "추가한 가상 머신... 꺼버립니다"
[^63]: @[11:29] "서버... 사서 운영" / @[11:38] "비용면에서 효율적"
[^64]: @[11:46] "많은 가상 머신... 세팅... 시간과 노력"
[^65]: @[11:59] "파스" / @[12:04] "소스 코드 업로드"
[^66]: @[12:09] "파스가... 가상머신과 로드밸런서 세팅"
[^67]: @[12:16] "마이크로 서비스"
[^68]: @[12:21] "백엔드 서버... 주문처리 결제처리 이메일..."
[^69]: @[12:34] "수십만... 수백만 줄" / @[12:41] "복잡... 관리"
[^70]: @[12:46] "3개의 코드 베이스로 나눔" / @[12:52] "마이크로 서비스" / @[13:01] "각각의 백엔드"
[^71]: @[13:01] "같은... 필요가 없습니다"
[^72]: @[13:07] "주문... 자바스크립트... mysql"
[^73]: @[13:15] "결제... 파이썬... 몽고디비"
[^74]: @[13:25] "직접 구축할 필요" / @[13:29] "트윌리오"
[^75]: @[13:32] "직접... 필요 없이" / @[13:37] "api... 이메일 보내달라"
[^76]: @[13:43] "사스" / @[13:54] "채널 톡"
[^77]: @[13:59] "iaas pas saas"
[^78]: @[14:07] "마지막 섹션... 기술 소개"
[^79]: @[14:12] "데이터베이스... 프라이머리 데이터베이스" / @[14:21] "일반적으로 웹사이트"
[^80]: @[14:26] "서버와 프라이머리 데이터베이스 순서"
[^81]: @[14:33] "이것만... 어려움" / @[14:37] "다양하게 아는 것이 중요"
[^82]: @[14:43] "이미지 업로드... 프라이머리 데이터베이스는 적절하지"
[^83]: @[14:51] "아마존 s3... 블롭스토리지... 클라우드 프론트... cdn"
[^84]: @[15:01] "텍스트 서치... 느려서" / @[15:06] "일레스틱 서치"
[^85]: @[15:16] "트래픽... 데이터베이스도 부담"
[^86]: @[15:19] "조수" / @[15:25] "레디스... 캐시... 성능"
[^87]: @[15:30] "데이터 분석... 프라이머리 데이터베이스... 안 됩니다"
[^88]: @[15:36] "운영에 집중" / @[15:41] "애널리티컬... 스노우플레이크"
[^89]: @[15:50] "충분히 웹사이트 운영"
[^90]: @[15:58] "백엔드 로드맵" / @[16:03] "얼만큼 알고 있는지 판단"
[^91]: @[16:10] "구독과 좋아요" / @[16:16] "댓글" / @[16:21] "끝"
[^92]: @[00:14]~@[15:44] 전체 전개에서 반복 강조된 백엔드 정의, 요청-응답, 클라우드 확장, 부가 기술 소개를 근거로 재구성
[^93]: @[01:05]~@[15:44] 용어들이 직접 정의/예시로 등장한 구간을 기반으로 정리
[^94]: 사용자 제공 메타데이터(제목/채널/길이/링크/키워드) 그대로 인용