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

description: |-

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

[? 질문] 백엔드를 공부할 때 “진짜 기초”로 반드시 잡아야 할 3가지는 무엇인가^2
[= 답] 웹서버(Web Server), WAS(웹 애플리케이션 서버), 데이터베이스(Database) 이 세 가지이며, 이 셋의 책임/탄생 이유를 이해하면 다른 백엔드 기술(모니터링, 로드밸런싱, 캐싱, CI/CD, 쿠버네티스 등)을 “모래 위에 성”처럼 배우지 않게 된다.[^3]

[? 질문] 백엔드의 핵심 목표는 무엇인가[^4]
[= 답] “유저에게 데이터를 어떻게 안정적으로 전달할 것인가”이며, 웹서버–WAS–DB는 이 목표를 역할 분리로 달성하도록 진화한 백엔드의 핵심 구성이다.[^5]

[? 질문] WAS와 스프링/장고 같은 백엔드 프레임워크는 같은 것인가, 다르다면 무엇이 다른가[^6]
[= 답] 완전히 다르다. 프레임워크는 개발을 돕는 “설계도+도구모음”이고, WAS는 그 코드(프레임워크로 만든 애플리케이션)를 실제 서버 환경에서 실행시키는 “엔진/런타임”이다.[^7]

[^3]: @[00:20] "모니터링, 로드 밸런스, 캐싱… 쿠버네티스… 이 세 가지에 대한 이해 없이 배운다면 모래 위에 성…"; @[00:28] "…이 세 가지 안에 백엔드의 핵심이 모두 포함…" [^4]: @[00:32] "백엔드의 핵심은 결국 유저에게 어떻게 데이터를 안정적으로 전달할 것인가…" [^5]: @[00:36] "…첫 번째 웹서버, 두 번째 와스, 세 번째 데이터베이스…"; @[12:05]~@[12:12] "…각각 …문제를 풀기 위해 탄생… 역할과 책임의 분리…" [^6]: @[03:17] "…와스와 스프링 또는 장고… 관계를 헷갈려…"; @[03:22] "면접에서도 단골…" [^7]: @[03:27]~@[04:08] "…와스와 백엔드 프레임웍은 완전히 다른… 프레임웍은 설계도/부품… 와스는 엔진… 런타임…"; @[04:08] "왓스 없이는 백핸드 프레임은 동작할 수 없습니다."

2. 큰 그림^8

이 콘텐츠는 “백엔드 개발을 위해 반드시 이해해야 하는 전체 구성”을 백엔드의 역사적 문제 해결 흐름(정적 문서 공유 → 동적 페이지 필요 → 영속적/안전한 데이터 관리 필요)로 설명하며, 그 결과로 자리 잡은 웹서버–WAS–데이터베이스 3요소의 역할과 협력 과정을 실제 서비스 요청 시나리오로 끝까지 따라간다.[^9]

• 역할과 책임의 분리: 웹서버는 정적 파일 전달, WAS는 동적 로직 실행, DB는 영속 저장/동시성·무결성·검색 성능을 담당하며 각각 “왜 생겼는지(문제)”로 이해해야 한다.[^10]
• WAS vs 프레임워크 구분: 프레임워크(스프링/장고/익스프레스 등)는 개발 생산성을 위한 구조/도구이고, WAS는 HTTP를 해석해 애플리케이션 코드를 실행하고 응답을 만들어 다시 내보내는 실행 환경이다.[^11]
• 실제 요청 흐름의 체감: 접속(정적 파일)–로그인(API, DB 조회, JWT 발급)–게시글 조회(API, 토큰 검증, DB 조회, JSON 응답) 예시로 3요소 협업이 반복된다는 점을 보여준다.[^12]

[^9]: @[00:49]~@[01:45] 정적 웹의 등장과 웹서버 필요; @[02:08]~@[03:07] 동적 요구와 WAS 등장; @[06:33]~@[08:54] DB 필요; @[08:54]~@[11:37] 협력 시나리오 [^10]: @[11:44]~@[12:12] "…웹서버는… 정적 파일… 와스는… 동적… 데이터베이스는… 안전 보관… 역할과 책임의 분리…" [^11]: @[03:27]~@[04:50] 프레임워크/와스 구분 및 동작 예시; @[05:14]~@[05:55] 내장 서버/노드JS 설명 [^12]: @[09:06]~@[11:37] 원투코딩 커뮤니티 사이트 예시 3단계

3. 하나씩 살펴보기^13

3.1 “백엔드 기초는 3요소로 끝난다”는 선언과 문제의식[^14]

영상은 시작부터, 이 영상 하나를 제대로 이해하면 “백엔드 기초 개념”을 더 이상 비효율적으로 헤매지 않게 된다고 말한다.[^15] 그 이유는 백엔드 기술 전반을 관통하는 기반 개념이 따로 있고, 그걸 잡지 못하면 이후에 배우는 기술들이 “모래 위에 성”이 되기 때문이라고 전제한다.[^16]

특히 화자는 다양한 백엔드 관련 키워드(모니터링, 로드밸런스, 캐싱, SQS, CI/CD, 쿠버네티스 등)를 나열하며, 이런 것들이 중요하지 않다는 뜻이 아니라 3요소(웹서버, WAS, DB) 이해 없이 먼저 배우면 구조적 이해가 붕 뜬다고 강조한다.[^17]

이어서 백엔드의 핵심을 “유저에게 데이터를 안정적으로 전달하는 방법”으로 정의하고,[^18] 그 목표를 이루기 위한 가장 기본이자 중요한 구성으로 다음 3가지를 제시한다.[^19]

• 첫 번째: 웹서버(Web Server)[^20]
• 두 번째: WAS(Web Application Server)[^21]
• 세 번째: 데이터베이스(Database)[^22]

[^14]: @[00:04]~@[00:36] 3요소 선정과 백엔드 핵심 정의 [^15]: @[00:00] "…제대로 이해하시면…" [^16]: @[00:20] "…이해 없이 배운다면 모래 위에 성…" [^17]: @[00:20] 나열된 기술과 “모래 위에 성” 비유 [^18]: @[00:32] "…유저에게… 데이터를 안정적으로 전달…" [^19]: @[00:36] "…첫 번째 웹서버, 두 번째 와스, 세 번째 데이터베이스…" [^20]: @[00:45] "첫째, 웹서버입니다." [^21]: @[02:02] "두 번째… 와스입니다." [^22]: @[06:33] "…마지막 데이터베이스입니다."

3.2 1요소: 웹서버 — “정적 문서를 전 세계에 즉시 보여주려면?”에서 출발[^23]

화자는 1990년대 초 월드와이드웹(WWW) 이 처음 등장했을 때를 상상해보자고 하며, 당시 웹이 지금 같은 쇼핑몰/소셜미디어가 아니라 “문서 공유” 중심이었다고 배경을 깐다.[^24] 주 사용처는 대학교/연구소에서 논문, 연구자료 같은 문서를 서로 쉽게 공유하는 목적이었다고 설명한다.[^25]

이때의 가장 큰 문제를 다음 질문으로 제시한다.[^26]

[? 질문] 내가 작성한 HTML 문서를 지구 반대편 사람에게 “즉시” 보여주려면 어떻게 해야 하는가[^27]
[= 답] 그 문제를 해결하기 위해 “웹서버”라는 아주 단순한 프로그램이 탄생했다.[^28]

웹서버의 초기 역할은 매우 단순했다.[^29]

• 특정 컴퓨터에 설치되어 있다.[^30]
• “index.html 파일을 보여줘” 같은 요청이 오면[^31]
• 컴퓨터에 저장된 index.html을 그대로 보내준다.[^32]

이 시기 웹의 특징은 “누가 접속하든 항상 똑같은 페이지”였다는 점이다.[^33] 사용자/시간에 따라 내용이 바뀌지 않는 웹이었고, 이를 정적 웹(Static Web) 이라고 부른다.[^34] 그래서 이 시대에는 “백엔드” 개념이 희미했는데, 서버가 사실상 파일을 서빙하는 역할이 전부였기 때문이라고 정리한다.[^35]

또한 웹서버의 대표 예시로 다음을 제시한다.[^36]

• Nginx(엔진엑스)[^37]
• Apache(아파치)[^38]
• Microsoft IIS[^39]
• Caddy(캐디)[^40]

이들은 “정적 파일 제공”이라는 기본 기능에 충실하고 고도로 최적화되어 있다고 설명한다.[^41]

[!NOTE] 웹서버 파트에서의 요지
웹서버는 “정적 파일을 빠르게 전달”하는 문제를 풀기 위해 태어났고, 정적 웹 시대에는 서버가 계산/로직을 수행하지 않았다는 점이 핵심 배경이다.[^42]

[^23]: @[00:45]~@[02:02] 웹서버 정의, 정적 웹, 대표 예시 [^24]: @[00:49]~@[00:58] "…www… 화려한 쇼핑몰… 소셜 미디어… 아니었습니다." [^25]: @[01:04]~@[01:10] "…대학교나 연구소… 문서를… 공유…" [^26]: @[01:10] "…가장 큰 문제…" [^27]: @[01:15] "…HTML 문서를… 즉시 보여 줄 수 있을까?" [^28]: @[01:15]~@[01:23] "…해결… 탄생… 웹서버…" [^29]: @[01:23]~@[01:32] "아주 단순… 인덱스.html… 그대로…" [^30]: @[01:28] "특정 컴퓨터에 설치…" [^31]: @[01:28]~@[01:32] "…요청이 오면…" [^32]: @[01:28]~@[01:32] "…그대로 보내주는…" [^33]: @[01:32]~@[01:36] "…항상 똑같은 페이지만…" [^34]: @[01:41] "…정적 웹, 스태틱 웹…" [^35]: @[01:41]~@[01:45] "…백엔드… 희미… 파일 서빙…" [^36]: @[01:50]~@[01:57] 웹서버 예시 나열 [^37]: @[01:50] "엔진엑스" [^38]: @[01:50] "아파치" [^39]: @[01:50]~@[01:57] "마이크로소프트… IIS" [^40]: @[01:57] "캐디" [^41]: @[01:57]~@[02:02] "…정적 파일… 충실… 최적화…" [^42]: @[11:50] "웹 서버는… 정적인 파일… 가장 빠르게 전달… 풀기 위해 탄생…"

3.3 2요소: WAS — “요청에 따라 실시간으로 만들어내는 능력”이 필요해지다[^43]

웹이 대중화되면서 사람들은 정적 문서 제공 이상의 것을 원하기 시작했다고 한다.[^44] 예로,

• 홈페이지 방문자 수를 표시하고 싶다[^45]
• 사용자마다 다른 정보를 보여주고 싶다[^46]
• 사람들이 글을 남길 수 있는 방명록을 만들고 싶다[^47]

그런데 기존 웹서버는 “미리 만들어진 HTML 파일”만 줄 수 있었고, 요청에 따라 실시간으로 HTML 내용을 생성할 수는 없었다.[^48] 이 새로운 문제를 해결하기 위해 등장한 것이 웹 애플리케이션 서버(WAS) 라고 설명한다.[^49]

WAS의 존재 이유를 “동적 웹페이지 생성”으로 정의하며,[^50] 여기서 말하는 “동적”의 의미를 구체화한다.[^51]

• 요청이 들어오면 서버에서 “무언가 일을 한 뒤”[^52]
• 그 결과를 담은 새로운 HTML을 실시간으로 만들어낸다[^53]

즉, WAS는 특정 요청을 받으면 “미리 약속된 프로그램”을 실행하고, 그 프로그램이 만든 결과물을 사용자에게 전달하는 방식이었다고 말한다.[^54] 화자는 이를 “요청에 따라 코드를 실행하는 엔진”이 WAS의 원형이라고 정리한다.[^55]

그리고 이 지점(서버가 생각하고 연산하고 로직을 처리하기 시작한 순간)을 “진정한 백엔드의 탄생”이라고 표현한다.[^56]

또한 웹서버와 WAS의 차이를 다음처럼 대비한다.[^57]

• 웹서버: 항상 동일한 정적 페이지를 반환[^58]
• WAS: 인자(요청/파라미터)에 따라 동적 페이지를 반환[^59]

[^43]: @[02:02]~@[03:17] WAS 등장 배경과 정의 [^44]: @[02:08] "웹이 점점 대중화… 더 많은 것을 원하기…" [^45]: @[02:13] "방문자수를 표시…" [^46]: @[02:13]~@[02:18] "…다른 정보를 보여주고…" [^47]: @[02:18] "…방명록…" [^48]: @[02:24]~@[02:31] "…미리 만들어진… 실시간… 능력은 없었…" [^49]: @[02:31]~@[02:36] "…탄생… 웹 애플리케이션 서버…" [^50]: @[02:36] "…동적인 웹페이지…" [^51]: @[02:41]~@[02:45] "…동적이란… 요청에 따라… 결과… 새로운 HTML…" [^52]: @[02:41]~@[02:45] "…서버에서 무언가…" [^53]: @[02:41]~@[02:45] "…실시간으로 만들어 낸다…" [^54]: @[02:45]~@[02:50] "…프로그램을 실행… 결과물을… 전달…" [^55]: @[02:57]~@[03:00] "요청에 따라 코드를 실행하는 엔진…" [^56]: @[03:02]~@[03:07] "…진정한 백엔드의 탄생…" [^57]: @[03:12]~@[03:17] 웹서버 vs WAS 대비 [^58]: @[03:12] "웹 서버는… 정적인…" [^59]: @[03:12]~@[03:17] "…와스는… 동적인…"

3.4 (면접 단골) WAS와 백엔드 프레임워크의 관계를 자동차 비유로 분리하기[^60]

화자는 많은 사람들이 “WAS와 스프링/장고 같은 백엔드 프레임워크의 관계”를 헷갈려 한다고 지적하며, 면접에서도 자주 나오는 질문이니 확실히 정리하겠다고 한다.[^61]

결론은 단호하다.[^62]

• [c WAS와 백엔드 프레임워크는 완전히 다른 것이다]

화자는 이해를 위해 “자동차” 비유를 든다.[^63]

• 백엔드 프레임워크: 자동차를 만들기 위한 정교한 설계도 + 부품 세트[^64]
  • 개발자가 회원가입/결제 같은 비즈니스 로직을 더 쉽고 빠르고 구조적으로 만들도록 준비된 뼈대/도구모음이라고 설명한다.[^65]
  • 예시: 스프링, 장고, FastAPI, Express[^66]
• WAS: 그 설계도와 부품으로 조립된 자동차를 실제로 움직이는 엔진[^67]
  • 개발자가 프레임워크로 작성한 코드를 서버 환경에서 실행시키는 런타임 환경 자체라고 정의한다.[^68]

이어서 “WAS 없이는 백엔드 프레임워크가 동작할 수 없다”고 말하며,[^69] 실제 동작 방식을 요청/응답 흐름으로 단계적으로 보여준다.[^70]

[^60]: @[03:17]~@[04:08] 혼동 지점 제시 [^61]: @[03:17]~@[03:22] "…헷갈려… 면접… 단골…" [^62]: @[03:27]~@[03:32] "…결론… 완전히 다른…" [^63]: @[03:32]~@[04:01] 자동차 비유 [^64]: @[03:32]~@[03:44] "…설계도이자 부품 세트…" [^65]: @[03:44]~@[03:49] "…비즈니스 로직… 뼈대… 도구모음…" [^66]: @[03:49]~@[03:54] 프레임워크 예시 [^67]: @[03:54]~@[04:01] "…움직이게 만드는 엔진…" [^68]: @[04:01]~@[04:08] "…실제로… 실행… 런타임 환경…" [^69]: @[04:08] "왓스 없이는… 동작할 수 없습니다." [^70]: @[04:18]~@[04:50] 요청/응답 객체 변환 흐름

3.5 WAS가 실제로 하는 일: HTTP 패킷 ↔ Request/Response 객체 변환과 실행 흐름[^71]

화자는 “예시를 통해” 프레임워크와 WAS의 동작 방식을 보여준다고 하며, 클라이언트 요청이 서버에서 처리되는 과정을 다음 순서로 설명한다.[^72]

1. 클라이언트가 요청을 보낸다.[^73]
2. 이 정보가 HTTP 패킷 형태로 서버에 전달된다.[^74]
3. WAS가 원시 HTTP 패킷을 해석(parsing)한 뒤, Request 객체를 생성한다.[^75]
4. WAS는 그 Request 객체를 백엔드 프레임워크에 전달한다.[^76]
5. 스프링/장고 같은 프레임워크는
   • URL에 해당하는 컨트롤러를 선택하고[^77]
   • Request 객체로 정해진 작업을 수행한다.[^78]
6. 결과물(JSON 또는 HTML 페이지)을 만들고[^79]
7. 그 결과를 Response 객체에 담아 WAS에 다시 전달한다.[^80]
8. WAS는 Response 객체를 다시 원시 HTTP 패킷으로 만들어 클라이언트로 전달한다.[^81]

화자는 이 흐름이 “실제 백엔드 프레임워크가 동작하는 방식”이라고 정리한다.[^82]

[!IMPORTANT] 여기서의 핵심 포인트
WAS는 단순히 “코드를 실행”하는 것뿐 아니라, 네트워크로 들어온 원시 HTTP를 애플리케이션이 다루기 쉬운 Request/Response 추상화로 바꾸고 다시 되돌리는 경계(런타임) 역할을 한다는 점을 강조한다.[^83]

[^71]: @[04:18]~@[04:50] 동작 과정 설명 [^72]: @[04:18] "…예시를 통해 보여…" [^73]: @[04:18] "…클라이언트… 요청…" [^74]: @[04:24] "…HTTP 패킷 형태…" [^75]: @[04:24]~@[04:29] "…해석… 리퀘스트 객체…" [^76]: @[04:29]~@[04:35] "…프레임웍에 전달…" [^77]: @[04:35] "…컨트롤러를 선택…" [^78]: @[04:35]~@[04:40] "…정해진 작업…" [^79]: @[04:40] "…제이슨 또는 HTML…" [^80]: @[04:40]~@[04:45] "…리스폰스 객체…" [^81]: @[04:45]~@[04:50] "…원시… 패킷… 클라이언트…" [^82]: @[04:50] "…동작하는 방식…" [^83]: @[04:24]~@[04:50] HTTP 패킷 ↔ 객체 변환과 전달 설명 전체

3.6 “나는 WAS 설치 안 했는데요?”: 내장 서버와 런타임이 WAS 역할을 숨긴다[^84]

화자는 위 설명 뒤에, 시청자가 이렇게 반문할 수 있다고 말한다.[^85]

[? 질문] 스프링부터 쓰는데 톰캣 같은 서버를 실행한 적이 없는데요 / 익스프레스로 개발하는데 WAS를 안 썼는데요[^86]
[= 답] 현대 백엔드 프레임워크들이 내장 서버(내장 WAS) 를 통합 제공하거나, 런타임 자체가 WAS 역할을 하기 때문에 “안 쓰는 것처럼 보일 뿐” 실제로는 쓰고 있다.[^87]

먼저 스프링을 예로 든다.[^88]

• 전통적인 스프링은 톰캣 같은 외부 WAS에서만 동작했다.[^89]
• 하지만 Spring Boot는 spring-boot-starter-web 안에 내장 톰캣 라이브러리를 포함한다.[^90]
• 그래서 메인을 실행하면 자동으로 톰캣 인스턴스를 띄우고, 톰캣이 HTTP 패킷을 파싱해 스프링 컨트롤러로 전달한다.[^91]
• 즉 “별도의 WAS 설치가 필요 없는 것처럼 보이지만”, 사실은 내장 WAS를 쓰는 것이라고 결론낸다.[^92]

다음으로 익스프레스를 예로 든다.[^93]

• Express는 Node.js의 HTTP 모듈을 그대로 활용한다.[^94]
• Node.js 자체가 자바스크립트 코드를 실행하는 런타임인 동시에 TCP 소켓을 열고 HTTP 패킷을 파싱할 수 있어 “WAS 역할까지” 한다고 설명한다.[^95]
• 따라서 “Node.js가 미니 WAS 역할”을 하고, Express는 그 위에서 라우팅과 미들웨어를 처리하는 백엔드 프레임워크 역할을 한다고 정리한다.[^96]

그리고 이 파트의 결론으로, WAS를 백엔드의 “심장부”에 비유한다.[^97]

• [h WAS는 동적 요청이 들어왔을 때 우리 코드를 실행하고, 결과를 다시 웹서버에게 돌려주는 심장부 역할을 한다]

[^84]: @[04:55]~@[06:04] 반문 제시와 해설 [^85]: @[04:55] "…반문할 수…" [^86]: @[05:00]~@[05:14] "…스프링… 실행 안 했는데…"; "…익스프레스… 와스… 안 썼는데…" [^87]: @[05:14]~@[05:17] "…내장 서버를 통합… 제공…"; @[05:32]~@[05:45] "…사실은 내장 와스를…" [^88]: @[05:17]~@[05:36] 스프링/스프링부트 설명 [^89]: @[05:17]~@[05:23] "…전통적인 스프링… 외부 와스…" [^90]: @[05:23]~@[05:27] "…스프링부트… 내장 톰캐…" [^91]: @[05:27]~@[05:32] "…메인을 실행하면… HTTP… 컨트롤러…" [^92]: @[05:32]~@[05:45] "…설치… 없는 것처럼… 사실은… 내장…" [^93]: @[05:45]~@[06:04] 익스프레스/노드 설명 [^94]: @[05:45] "…HTTP 모듈… 활용…" [^95]: @[05:45]~@[05:55] "…런타임… TCP 소켓… HTTP 패킷…" [^96]: @[05:55]~@[06:04] "…노드 JS가 미니 와스… 익스프레스… 프레임웍…" [^97]: @[06:04]~@[06:17] "…백핸드의 심장부…"

3.7 WAS의 예시(기술 스택별)와 “IIS는 둘 다 한다”는 언급[^98]

화자는 WAS의 예시를 언어/플랫폼별로 열거한다.[^99]

• Java: 아파치(맥락상 톰캣 등 아파치 재단 WAS를 가리키는 흐름)[^100]
• Python: Gunicorn, Uvicorn[^101]
• JavaScript: Node.js 런타임[^102]
• .NET: Microsoft IIS[^103]

그리고 IIS는 앞에서 웹서버 예시로도 나왔는데, 웹서버와 WAS 역할을 모두 수행한다고 덧붙인다.[^104]

[^98]: @[06:24]~@[06:33] 기술별 WAS 예시 [^99]: @[06:24] "…대표적으로…" [^100]: @[06:24] "자바의 아파치…" [^101]: @[06:24] "파이썬에는 G유니콘 유비콘…" [^102]: @[06:24]~@[06:33] "…자바스크립트는 노드 js…" [^103]: @[06:24]~@[06:33] "…단넷에는… IIIS…" [^104]: @[06:33] "…IIS는… 웹서버와스 역할을 모두…"

3.8 3요소: 데이터베이스 — 방명록은 됐는데 “서버 재시작하면 글이 사라진다”[^105]

화자는 WAS 덕분에 방명록 같은 상호작용 기능을 만들 수 있게 되었다고 말한다.[^106] 사용자가 글을 남기면 WAS가 내용을 담은 새로운 HTML을 만들어 보여주는 식이라는 것이다.[^107]

하지만 여기엔 치명적인 문제가 있었다고 한다.[^108]

• 서버를 껐다 켜면 방명록 글이 사라진다.[^109]
• 데이터가 메모리나 임시 파일에만 존재했기 때문이다.[^110]

웹이 더 복잡해지면서 “데이터를 제대로 다뤄야 한다”는 요구가 폭발적으로 늘었다고 구체 예시를 나열한다.[^111]

• 회원 아이디/비밀번호를 안전하게 보관해야 한다[^112]
• 쇼핑몰의 수만 개 상품 재고를 정확히 관리해야 한다[^113]
• 여러 사용자가 동시에 마지막 한정판 신발을 구매하려 한다[^114]
• 그런데 딱 한 명에게만 팔리도록 보장해야 한다[^115]

이런 상황은 영속 저장, 안전한 관리, 동시 접근 제어가 필요함을 의미하며, 이 문제를 해결하기 위해 백엔드 아키텍처에 합류한 “마지막 퍼즐”이 데이터베이스라고 설명한다.[^116]

[^105]: @[06:33]~@[07:16] 방명록 예시와 DB 필요성 도입 [^106]: @[06:36]~@[06:42] "…방명록… 만들 수…" [^107]: @[06:39]~@[06:42] "…와스가… HTML…" [^108]: @[06:42] "…치명적인 문제…" [^109]: @[06:47]~@[06:49] "…서버를 껐다 키면… 사라지는…" [^110]: @[06:49]~@[06:54] "…메모리나 임시 파일…" [^111]: @[06:54]~@[07:11] 복잡해진 요구 나열 [^112]: @[06:56]~@[06:58] "…아이디와 비밀번호…" [^113]: @[06:58]~@[07:02] "…수만 개의 상품 재고…" [^114]: @[07:02]~@[07:07] "…동시에… 구매…" [^115]: @[07:07]~@[07:11] "…딱 한 명에게만… 보장…" [^116]: @[07:11]~@[07:16] "…필요성… 폭발… 마지막 퍼즐… 데이터베이스…"

3.9 “그냥 파일에 저장하면 안 돼요?”: 파일시스템이 못 푸는 3가지 치명적 한계[^117]

데이터베이스를 도입하는 이유를 설명하기 위해 화자는 이런 의문을 제시한다.[^118]

[? 질문] 그냥 텍스트 파일(파일 시스템)에 저장하면 안 돼요?[^119]
[= 답] 좋은 질문이며, 이 질문의 답을 이해하는 것이 곧 데이터베이스의 존재 이유를 이해하는 것과 같다. 파일 시스템은 치명적인 3가지 문제를 해결하지 못한다.[^120]

화자는 “파일 시스템이 해결할 수 없는 치명적인 문제 세 가지”를 순서대로 든다.[^121]

(1) 동시성 제어 불가능: 레이스 컨디션을 막을 수 없다[^122]

한정판 신발 재고가 1개 남은 상황을 예로 든다.[^123] 수많은 사람이 0.01초(아주 작은 시간 차)로 동시에 구매 버튼을 누르면, 단순 파일 저장 방식은 “누가 먼저 가져갔는지”를 일관되게 보장하기 어렵다.[^124]

반면 데이터베이스는 “락(lock) 같은 정교한 메커니즘”으로 경쟁 조건(레이스 컨디션) 을 막고 데이터의 일관성을 지켜준다고 설명한다.[^125]

(2) 무결성 보장 불가: ‘둘 중 하나’가 아니라 ‘둘 다 성공/둘 다 실패’가 필요하다[^126]

계좌이체 예시를 든다.[^127]

• 내 통장에서 1만원을 빼고[^128]
• 당신 통장에 1만원을 넣는다[^129]

이 두 작업은 반드시 “한 묶음”으로 성공해야 하고, 하나라도 실패하면 “모두 없던 일이” 되어야 한다고 말한다.[^130]

데이터베이스는 이런 “모 아니면 도” 방식의 작업 단위를 트랜잭션(Transaction) 기능으로 보장하여, 데이터가 중간에 깨지지 않도록 무결성을 지킨다고 설명한다.[^131]

(3) 검색 속도 저하: 1억 명 파일 검색은 처음부터 끝까지 다 읽어야 한다[^132]

“1억 명 회원이 담긴 파일에서 특정 회원을 찾는” 상황을 상상해보라고 한다.[^133] 파일 기반이면 컴퓨터가 첫 줄부터 마지막 줄까지 모든 내용을 읽고 비교해야 한다는 것이다.[^134]

데이터베이스는 인덱스(Index) 기술을 사용한다.[^135] 책의 목차처럼 데이터 위치 정보를 미리 따로 정리해 두어, 수억 개 데이터 속에서도 원하는 정보를 “눈 깜짝할 사이”에 찾게 해준다고 설명한다.[^136]

데이터베이스의 정체: 파일 시스템의 근본 한계를 해결하는 전문 시스템[^137]

화자는 위 내용을 묶어, 데이터베이스를 다음처럼 정의/정리한다.[^138]

• 동시성, 무결성, (그리고 언급으로) 확장성, 성능 등[^139]
• 파일 시스템이 해결할 수 없는 근본 문제를 해결하기 위해 탄생한
• 고도로 전문화된 데이터 관리 시스템[^140]

[!TIP] 데이터베이스 필요성을 면접 답변으로 만들 때
“파일로도 저장은 가능하지만, 동시성(락/레이스 컨디션), 무결성(트랜잭션), 검색 성능(인덱스) 같은 핵심 요구를 안정적으로 해결하려면 DB가 필요하다”는 구조로 답을 구성하라고 영상이 사실상 가이드한다.[^141]

[^117]: @[07:16]~@[08:54] 파일시스템 vs DB 비교 [^118]: @[07:16] "…의문…" [^119]: @[07:21]~@[07:27] "…파일에 저장하면…" [^120]: @[07:27]~@[07:31] "…존재 이유…"; @[07:31]~@[07:35] "…치명적인 문제 세 가지…" [^121]: @[07:31]~@[07:35] "…세 가지…" [^122]: @[07:35]~@[07:54] 동시성 제어 파트 [^123]: @[07:39]~@[07:44] "…재고… 한 개…" [^124]: @[07:44]~@[07:49] "…0.01초… 동시에…" [^125]: @[07:49]~@[07:54] "…락… 레이스 컨디션… 일관성…" [^126]: @[07:54]~@[08:21] 무결성/트랜잭션 파트 [^127]: @[07:59] "…계좌 이체…" [^128]: @[08:04] "…통장에서 만 원을 빼서…" [^129]: @[08:04] "…넣어야…" [^130]: @[08:04]~@[08:09] "…반드시 한묶음… 실패하면 모두 없던 일…" [^131]: @[08:09]~@[08:16] "…트랜잭션… 무결성…" [^132]: @[08:21]~@[08:42] 검색/인덱스 파트 [^133]: @[08:26] "…1억 명의 회원…" [^134]: @[08:26]~@[08:32] "…첫 줄부터 마지막 줄까지…" [^135]: @[08:32]~@[08:37] "…인덱스…" [^136]: @[08:37]~@[08:42] "…책의 목차처럼… 눈 깜짝…" [^137]: @[08:42]~@[08:54] DB 정의/요약 문장 [^138]: @[08:42]~@[08:54] "…근본적인 문제… 해결…" [^139]: @[08:42]~@[08:49] "…동시성, 무결성, 확장성, 성능…" [^140]: @[08:49]~@[08:54] "…전문화된 데이터 관리 시스템…" [^141]: @[07:31]~@[08:42] 3가지 한계(동시성/무결성/검색) 설명 전반

3.10 총정리 시나리오: 원투코딩 커뮤니티 사이트 접속으로 보는 3요소 협력[^142]

화자는 “지금까지 배운 3요소가 실제 서비스에서 어떻게 협력하는지”를 보여주기 위해, 사용자가 원투코딩 커뮤니티 사이트에 접속하는 과정을 따라가며 정리하겠다고 한다.[^143] 여기서는 3개의 예시(단계)로 흐름을 보여준다.[^144]

예시 1) 사용자가 도메인 입력 → 웹서버가 정적 파일을 빠르게 전송[^145]

사용자가 브라우저에 원투코딩닷컴을 입력하고 엔터를 누른다.[^146]
이 요청을 웹서버가 가장 먼저 본다고 한다.[^147]

웹서버는 프론트엔드 애플리케이션을 구동하는 데 필요한 정적 파일들을 브라우저로 빠르게 전송한다.[^148] 브라우저는 받은 파일로 화면을 그려 “멋진 홈페이지 화면”이 보이게 된다.[^149]

다만 이 시점에는 “아직 로그인도 안 되어 있고 게시글 목록도 비어 있다”고 말하는데,[^150] 이는 정적 파일로는 사용자별 데이터(로그인 상태/게시글 데이터)를 채우지 못한다는 상황을 자연스럽게 연결한다.[^151]

예시 2) 로그인 버튼 클릭 → /api 로그인 요청 → 웹서버는 프록시로 WAS에 전달 → DB 조회 → JWT 발급[^152]

사용자가 아이디/비밀번호를 입력하고 로그인 버튼을 클릭한다.[^153] 프론트엔드는 이 정보를 담아 POST 요청으로 /api/login(영상에서는 발화가 끊기지만 “/api/로그인” 흐름) 주소로 API 요청을 보낸다고 설명한다.[^154]

웹서버가 요청을 받자마자 이렇게 판단하는 대사를 넣는다.[^155]

• “어, API로 시작하는 요청이네. 이건 내 일이 아니야. WAS로 넘겨야겠다.”[^156]

웹서버는 해당 요청을 뒤에 있는 WAS로 그대로 전달하는데, 이를 프록시(Proxy) 라고 부른다고 설명한다.[^157]

WAS가 로그인 요청을 받으면 “이제부터 비즈니스 로직이 시작”된다고 선언한다.[^158] 즉, 이 사용자가 진짜 회원인지 확인해야 하고,[^159] 이를 위해 WAS는 데이터베이스에 접속해서 다음을 조회한다.[^160]

• users 테이블에 해당 아이디가 있는지[^161]
• 암호화된 비밀번호가 일치하는지[^162]

데이터베이스는 회원 정보를 찾아 “일치하는 회원이 있다”고 WAS에 응답한다.[^163] WAS는 성공 응답을 받으면 로그인 성공 의미로 JWT 인증 토큰을 생성한다.[^164] 그리고 토큰을 JSON 데이터에 담아 웹서버를 통해 사용자에게 보내준다.[^165]

사용자 브라우저는 로그인 성공 데이터와 토큰을 받으며,[^166] 프론트엔드 앱은 화면 우측 상단에 “원투코딩님 환영합니다” 같은 메시지를 표시하고, 받은 토큰을 안전하게 저장한다고 설명한다.[^167]

+++ 상세 예시: 이 단계에서 드러나는 역할 분리

• 웹서버: “API 요청을 구분해 WAS로 전달(프록시)”이라는 라우팅/게이트 역할이 강조된다.[^157]
• WAS: 회원 검증 로직 수행, DB 조회, JWT 생성이라는 “비즈니스 로직 수행자”로 묘사된다.[^158]
• DB: users 테이블 조회로 “진짜 회원인지” 판단 근거 데이터를 제공한다.[^160] +++

예시 3) 게시글 클릭 → 토큰 포함 API 요청 → WAS가 토큰 검사로 사용자 식별 → DB 조회 → JSON 가공 후 전달[^168]

사용자가 “백엔드 개념 총정리”라는 제목의 게시글을 클릭한다.[^169] 프론트엔드 앱은 “123번 내용을 보여줘”라는 의미로 /api/posts/123 요청을 보낸다고 설명한다(발화상 숫자가 일부 흔들리지만 123번 게시글 흐름).[^^170]

이때 요청에는 인증 토큰을 포함한다.[^171] 웹서버는 다시 API 요청이므로 WAS로 전달한다.[^172]

WAS는 요청을 받고, 먼저 함께 온 인증 토큰을 검사해서 “아, 로그인한 원투코딩님이구나”라고 사용자를 식별한다고 한다.[^173] 그 다음 “123번 게시글을 찾아달라”는 요청을 처리하기 위해, WAS는 데이터베이스에 접속해 posts 테이블에서 게시글의 제목/내용/작성자 등의 정보를 조회한다.[^174]

데이터베이스가 123번 데이터를 찾아 WAS에 전달하면,[^175] WAS는 게시 데이터를 “예쁘게” JSON 형식으로 가공해 웹서버에 전달하고, 웹서버는 다시 사용자에게 최종 전달한다.[^176]

사용자 브라우저가 JSON 데이터를 받으면,[^177] 프론트엔드 앱은 이 데이터를 이용해 화면에 제목과 본문을 그려준다.[^178]

마지막으로 화자는 이것이 웹서비스 이용 때마다 “눈에 보이지 않는 뒤편에서 수없이 반복되는” 웹서버–WAS–DB의 처리 과정이라고 말한다.[^179]

[^142]: @[08:54]~@[11:37] 총정리 시나리오 전체 [^143]: @[08:54]~@[08:59] "…어떻게 협력… 따라가며 총 정리…" [^144]: @[08:59] "첫 번째 예…"; @[09:26] "두 번째 예…"; @[10:34] "세 번째 예시…" [^145]: @[09:06]~@[09:26] 예시1 [^146]: @[09:06]~@[09:09] "…입력… 엔터…" [^147]: @[09:09] "웹서버가… 가장 먼저…" [^148]: @[09:13]~@[09:16] "…정적 파일… 빠르게 전송…" [^149]: @[09:16]~@[09:23] "…화면을 그립니다… 멋진 홈페이지…" [^150]: @[09:23]~@[09:26] "…아직 로그인… 목록도 비어…" [^151]: @[01:32]~@[01:45] 정적 웹의 한계와 연결되는 설명 [^152]: @[09:29]~@[10:30] 예시2 [^153]: @[09:29]~@[09:33] "…아이디… 비밀번호… 로그인…" [^154]: @[09:33]~@[09:40] "/api/로그인… API 요청…" [^155]: @[09:40]~@[09:45] 웹서버 판단 대사 [^156]: @[09:41]~@[09:45] "…API로 시작… 내 일이 아니야… 와스로…" [^157]: @[09:50]~@[09:58] "…와스로… 이것을 프록시…" [^158]: @[10:02] "…비즈니스 로직이 시작…" [^159]: @[10:02] "…진짜 우리 회원인지 확인…" [^160]: @[10:02]~@[10:07] "…DB 접속… 유저스 테이블… 조회…" [^161]: @[10:02]~@[10:07] "…해당 아이디…" [^162]: @[10:02]~@[10:07] "…암호화된 비밀 번호…" [^163]: @[10:07]~@[10:11] "…일치하는 회원…" [^164]: @[10:11]~@[10:22] "…JWT… 생성…" [^165]: @[10:22]~@[10:26] "…JSON… 웹서버 통해…" [^166]: @[10:26]~@[10:30] "…토큰을 받습니다…" [^167]: @[10:30]~@[10:34] "…환영합니다… 토큰 저장…" [^168]: @[10:38]~@[11:37] 예시3 [^169]: @[10:38]~@[10:42] "…게시글 클릭…" [^170]: @[10:42]~@[10:46] "/api/… 123 요청…" [^171]: @[10:46]~@[10:53] "…인증 토큰을 포함…" [^172]: @[10:53]~@[10:57] "…API 요청… 와스로…" [^173]: @[10:57]~@[11:04] "…토큰 검사… 사용자 식별…" [^174]: @[11:09]~@[11:13] "…DB… 포스트 테이블… 조회…" [^175]: @[11:13]~@[11:18] "…데이터를 찾아서… 전달…" [^176]: @[11:18]~@[11:22] "…JSON… 가공… 웹서버… 최종…" [^177]: @[11:22]~@[11:26] "…JSON 데이터를 받습니다…" [^178]: @[11:26]~@[11:31] "…화면에… 그려…" [^179]: @[11:31]~@[11:37] "…수없이 반복되는… 처리 과정…"

3.11 결론: 백엔드의 역사는 ‘문제 해결의 진화’이며, 3요소 이해가 모든 학습의 출발점[^180]

화자는 “결국 백엔드의 역사”를, 웹이 점점 복잡해지면서 마주친 문제들을 해결해온 과정 자체라고 정리한다.[^181] 그리고 각 요소의 탄생 이유를 다시 문제 형태로 명확히 재진술한다.[^182]

• 웹서버: “정적 파일을 수많은 사람에게 가장 빠르게 전달”하려면?[^183]
• WAS: “사용자 요청에 따라 동적 결과를 실시간으로 만들어내려면?”[^184]
• 데이터베이스: “데이터를 영속적이고 안전하게 보관·관리하려면?”[^185]

이어서 이 3가지는 단순한 기술 나열이 아니라, 현대 백엔드 시스템의 핵심 철학인 역할과 책임의 분리가 어떻게 자연스럽게 진화해 왔는지 보여주는 “역사적 증거”라고 말한다.[^186]

그리고 “수많은 백엔드 기술을 공부하기 전에” 가장 먼저 갖춰야 할 중요한 기초는, 이들의 탄생 이유와 각자의 책임을 이해하는 것이라고 강조한다.[^187]

마지막 정리 파트에서도 같은 흐름을 한 번 더 압축해 되짚는다.[^188]

• 모든 것은 정적인 문서를 공유하는 단순한 페이지에서 시작했고, 이를 위해 웹서버가 태어났다.[^189]
• 웹이 상호작용을 원하면서 동적 콘텐츠 생성을 위해 WAS가 등장하며 진정한 백엔드가 시작됐다.[^190]
• 데이터를 영속적이고 안전하게 관리할 필요성 때문에 DB가 합류하며 현대 백엔드 아키텍처의 3대 요소가 완성됐다.[^191]

그 결과 시청자는 “백엔드라는 거대한 시스템이 어떤 문제를 해결하기 위해 지금의 모습으로 진화해 왔는지” 핵심 그림을 머릿속에 그리게 됐다고 마무리한다.[^192] 그리고 시청자에게 “백엔드의 또 다른 핵심”이 있다면 댓글로 남겨 달라고 요청하며 영상이 끝난다.[^193]

[^180]: @[11:44]~@[13:10] 백엔드 역사/정리/마무리 [^181]: @[11:44] "…백엔드의 역사는… 해결… 과정…" [^182]: @[11:50]~@[12:05] 각 요소의 탄생 이유를 문제로 재서술 [^183]: @[11:50] "…정적인 파일… 가장 빠르게…" [^184]: @[11:58]~@[12:05] "…동적인 결과… 실시간…" [^185]: @[12:05]~@[12:12] "…안전하게 보관하고 관리…" [^186]: @[12:05]~@[12:12] "…역할과 책임의 분리… 역사적 증거…" [^187]: @[12:12]~@[12:19] "…공부… 전에… 가장 먼저… 기초…" [^188]: @[12:19]~@[12:57] "정리하겠습니다…" [^189]: @[12:35]~@[12:42] "…정적인 문서… 웹 서버…" [^190]: @[12:42]~@[12:50] "…상호작용… 동적… 와스…" [^191]: @[12:50]~@[12:57] "…데이터베이스… 3대 핵심 요소 완성…" [^192]: @[12:57]~@[13:06] "…진화… 핵심적인 그림…" [^193]: @[13:06]~@[13:10] "…댓글… 구독과 좋아요…"

4. 핵심 통찰[^194]

1. [c 백엔드 학습의 출발점은 기술 목록이 아니라 “왜 이 구성요소가 생겼는지”를 문제-해결 관점으로 이해하는 것이다.] [^195]

   • 실행: 웹서버/ W AS/ DB를 “기능”이 아니라 “해결한 문제”로 각각 1문장씩 설명해보라.[^182]

2. [h 웹서버–WAS–DB는 ‘유저에게 데이터를 안정적으로 전달’하기 위한 역할 분리의 결과이며, 이후 기술들은 이 위에서 의미를 가진다.] [^196]

   • 실행: 로드밸런싱/캐싱/쿠버네티스 등을 볼 때 “웹서버 영역 최적화인가, WAS 확장인가, DB 병목 해결인가”로 분류해보라.[^3]

3. [h WAS와 프레임워크 혼동을 끊는 가장 좋은 기준은 ‘설계도(프레임워크) vs 실행 엔진(런타임/WAS)’ 구분이다.] [^197]

   • 실행: “내장 서버”가 제공되는 프레임워크를 쓸 때도, 내부적으로 WAS가 어떻게 뜨는지(예: 내장 톰캣) 확인하는 습관을 들여라.[^90]

4. 데이터베이스의 필수성은 “저장”이 아니라 동시성(락), 무결성(트랜잭션), 검색 성능(인덱스) 같은 운영 요구에서 결정된다는 점을 파일 시스템과의 비교로 설득한다.[^198]

   • 실행: 한정판 재고/계좌이체/대규모 회원 검색 3가지 예시로 DB 필요성을 설명하는 답변을 준비하라.[^123]

5. 실제 서비스 요청은 “정적 화면 렌더링(웹서버)”과 “데이터/API 처리(WAS+DB)”가 결합되어 반복되며, 로그인 같은 기능은 토큰(JWT) 발급과 검증 흐름까지 포함한다.[^199]

   • 실행: 임의의 서비스(본인 프로젝트)에서 “첫 접속 → 로그인 → 데이터 조회”를 웹서버/WAS/DB 관점으로 시퀀스 다이어그램으로 그려보라.[^152]

[^194]: @[00:20]~@[12:19] 전체 메시지 종합(3요소 우선, 역할 분리, 프레임워크 vs WAS, DB 필요성) [^195]: @[11:44]~@[12:19] "…탄생 이유… 책임… 가장 먼저…" [^196]: @[00:32]~@[00:36] "…유저에게… 안정적으로 전달…"; @[12:05]~@[12:12] 역할/책임 분리 [^197]: @[03:32]~@[04:08] 자동차 비유 및 런타임 정의 [^198]: @[07:31]~@[08:49] 파일시스템 한계 3가지 + 확장/성능 언급 [^199]: @[08:54]~@[11:37] 3단계 시나리오(정적 파일, 로그인+JWT, 게시글 조회+토큰검증)

5. 헷갈리는 용어 정리 (해당 시에만)[^200]

정적 웹(Static Web): 사용자나 시간에 따라 내용이 바뀌지 않고, 서버가 저장된 HTML 같은 파일을 그대로 제공하는 형태.[^201]
동적 웹(Dynamic Web): 요청에 따라 서버가 로직을 수행하고 결과를 담은 HTML(또는 데이터)을 실시간으로 생성해 제공하는 형태.[^202]
웹서버(Web Server): 정적 파일을 빠르고 안정적으로 전달하는 데 최적화된 서버 프로그램(예: Nginx, Apache, IIS, Caddy).[^203]
WAS(Web Application Server): 원시 HTTP를 해석해 애플리케이션 코드를 실행하고, 결과를 응답으로 만들어 돌려주는 실행 환경(런타임/엔진).[^204]
백엔드 프레임워크: 회원가입/결제 등 비즈니스 로직을 구조적으로 빠르게 만들도록 제공되는 뼈대/도구모음(예: Spring, Django, FastAPI, Express).[^205]
프록시(Proxy): 웹서버가 받은 요청을 뒤쪽 서버(WAS)로 그대로 전달하는 동작(영상에서는 API 요청을 WAS로 넘기는 예로 설명).[^206]
JWT: 로그인 성공 시 WAS가 생성해 클라이언트에 전달하는 “인증 토큰”으로 소개되며, 이후 요청에서 토큰을 검사해 사용자를 식별하는 데 사용.[^207]
락(Lock): 동시 접근 상황에서 경합(레이스 컨디션)을 제어해 데이터 일관성을 지키는 DB 메커니즘으로 언급.[^208]
트랜잭션(Transaction): 계좌이체처럼 여러 작업이 “모두 성공 또는 모두 실패”하도록 묶어 무결성을 보장하는 DB 기능.[^209]
인덱스(Index): 책의 목차처럼 데이터 위치 정보를 미리 정리해 빠른 검색을 가능하게 하는 DB 기술.[^210]

[^200]: @[01:41]~@[10:22] 용어들이 직접 정의/예시로 등장하는 구간 전반 [^201]: @[01:32]~@[01:45] 정적 웹 설명 [^202]: @[02:41]~@[02:45] 동적 의미 설명 [^203]: @[01:50]~@[02:02] 웹서버 예시 및 역할 [^204]: @[04:01]~@[04:08] 런타임 정의; @[04:18]~@[04:50] 패킷/객체 변환 [^205]: @[03:44]~@[03:54] 프레임워크 정의 및 예시 [^206]: @[09:50]~@[09:58] "이것을 프록시…" [^207]: @[10:11]~@[10:26] JWT 생성/전달; @[10:57]~@[11:04] 토큰 검사 [^208]: @[07:49]~@[07:54] 락과 레이스 컨디션 [^209]: @[08:09]~@[08:16] 트랜잭션 [^210]: @[08:32]~@[08:42] 인덱스/목차 비유

---

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

• 제목: 백엔드 개발을 위해 꼭 알아야 할 전체 구성[^212]
• 채널: 원투코딩 OneTwoCoding[^213]
• 길이: 13분 13초[^214]
• 링크: https://www.youtube.com/watch?v=M8E6vYAIuzQ[^215]

[^211]: @[00:00]~@[13:10] 영상 전반(메타 포함) [^212]: 사용자 제공 메타데이터(제목) [^213]: 사용자 제공 메타데이터(채널) [^214]: 사용자 제공 메타데이터(길이) [^215]: 사용자 제공 메타데이터(링크)