Security Tech

헷갈리는 웹 애플리케이션 필수 용어 정리

작성자 - dhkstn

1. 개요

웹 애플리케이션 개발자, 혹은 정보 보안을 공부하는 분들이라면 수없이 들어봤을 용어들이 있습니다.

프론트엔드, 백엔드, 클라이언트, 서버, 웹 서버(WS), 웹 애플리케이션 서버(WAS), SPA, MPA, SSR, CSR 등

매일 사용하는 용어지만, 누군가 "프론트엔드와 클라이언트의 정확한 차이가 뭔가요?"라고 물었을 때, 혹은 "Nginx는 웹 서버인가요, WAS인가요?"라는 질문에 망설임 없이 답변할 수 있으신가요?

실무에서도 이 용어들은 혼재되어 사용되곤 합니다. 하지만 각 개념의 역할과 작동 방식을 명확히 구분하는 것은 전체 시스템 아키텍처를 이해하는 첫걸음이자, 웹 보안의 공격 벡터를 파악하는 기초가 됩니다.

이번 포스팅에서는 비슷해 보이지만 엄연히 다른 웹 필수 용어들의 개념을 확실하게 정리하고, 그 차이점을 비교해 보겠습니다.

2. 프론트엔드/백엔드 vs 클라이언트/서버

가장 기초적이면서도 의외로 혼동하기 쉬운 네 가지 용어입니다. 이들을 구분하는 핵심 기준은 무엇을 개발하는가(기술 스택 및 영역)와 누가 요청하고 응답하는가(통신 관계)의 차이입니다.

2.1 프론트엔드(Front-end) & 백엔드(Back-end)

이 두 용어는 소프트웨어의 기능적 영역과 개발 분야를 구분할 때 사용합니다.

프론트엔드(Front-end)
- 사용자가 웹/앱을 이용할 때 직접 눈으로 보고 상호작용하는 사용자 인터페이스(UI)와 사용자 경험(UX) 영역입니다. 흔히 클라이언트 사이드(Client-Side)라고 불립니다.
- 해당 영역에서는 브라우저에서 실행되는 화면 구성, 디자인, 버튼 클릭 시의 동작, 애니메이션 등을 담당합니다. 사용자의 입력을 받아 백엔드로 전달하고, 백엔드에서 전달 받은 데이터를 화면에 가공하여 보여줍니다.
- 주요 기술
  - HTML, CSS, JavaScript
- 프레임워크
  - Vue.js, Angular, Svelte 등
- 라이브러리
  - React.js 등

프레임워크(Framework)와 라이브러리(Library)의 차이

둘 다 개발을 도와주는 도구이지만, 제어의 주도권(Control)이 누구에게 있느냐가 핵심입니다. 프레임워크는 애플리케이션의 뼈대(구조)를 제공합니다. 개발자는 프레임워크가 정한 규칙과 틀 안에서 코드를 작성해야 합니다. (제어권 - 프레임워크)

라이브러리는 개발자가 필요할 때 호출하여 사용하는 특정 기능의 도구 모음입니다. 개발자가 전체 흐름을 주도하며 필요한 순간에 가져다 씁니다. (제어권 - 개발자)

백엔드(Back-end)
- 사용자에게 보이지 않는 웹의 뒷면입니다. 서버 사이드(Server-Side)라고도 불리며 데이터 처리, 비즈니스 로직 수행, 서버 인프라 관리를 담당합니다.
- 프론트엔드로부터 요청(Request)을 받아, 데이터베이스(DB)에서 데이터를 조회/저장/수정하거나 복잡한 연산을 수행한 뒤, 그 결과(Response)를 다시 프론트엔드로 전달합니다.
- 주요 기술
  - Java, Python, Node.js, PHP, Go, Ruby 등
- 프레임워크
  - Spring Boot, Django, Express 등

2.2 클라이언트(Client) & 서버(Server)

이 두 용어는 네트워크 상에서 데이터 통신의 주체와 역할을 구분할 때 사용합니다.

클라이언트 (Client)
- 서비스를 요청하는 주체입니다. 일반적으로 사용자가 사용하는 웹 브라우저(Chrome, Safari 등)나 모바일 앱이 클라이언트가 됩니다.
- 반드시 사용자 단말기만 클라이언트가 되는 것은 아닙니다. 예를 들어, 백엔드 서버 A가 데이터를 얻기 위해 또 다른 백엔드 서버 B에게 요청을 보낸다면, 그 순간 서버 A는 클라이언트 역할을 수행하는 것입니다.

서버(Server)
- 클라이언트의 요청을 받아 데이터를 처리하고, 그 결과를 응답(Response)하는 주체입니다.
- 네트워크를 통해 서비스를 제공하는 컴퓨터 시스템 혹은 그 시스템 위에서 돌아가는 소프트웨어를 통칭합니다. 데이터베이스 조회, 로직 처리, 정적 파일 제공 등 클라이언트가 필요로 하는 리소스를 제공합니다.

3. 웹 서버 vs 웹 애플리케이션 서버

"Apache(아파치)와 Tomcat(톰캣)은 뭐가 다른가요?" 개발 초기 단계에서 가장 많이 마주하는 질문 중 하나입니다. 둘 다 서버 역할을 하는 것 같은데, 실무에서는 이 둘을 연동해서 사용하는 경우가 많습니다. 이 두 용어의 결정적인 차이는 "어떤 종류의 콘텐츠를 처리하느냐"에 있습니다.

3.1 웹 서버(Web Server)

웹 서버는 클라이언트가 요청한 정적 콘텐츠를 제공하는 서버입니다. 여기서 정적 콘텐츠란 HTML, CSS, 이미지(JPEG, PNG), 단순 파일 등 누가, 언제 요청하더라도 항상 동일한 내용을 보여주는 데이터를 말합니다.

웹 서버는 복잡한 연산을 수행하지 않습니다. 그저 클라이언트(브라우저)가 "이 로고 이미지 줘"라고 요청하면, 미리 저장된 경로에서 파일을 찾아 건네주는 역할에 충실합니다. 만약 본인이 처리할 수 없는 동적인 요청(예: 로그인, DB 조회)이 들어오면, 이를 뒤에 있는 WAS에게 넘겨주는 '문지기' 역할을 수행하기도 합니다.

주요 역할
- 정적 리소스 제공, 리버스 프록시, 로드 밸런싱
대표 소프트웨어
- Nginx, Apache HTTP Server, IIS

3.2 웹 애플리케이션 서버(Web Application Server - WAS)

WAS는 웹 서버의 기능에 더해 동적 콘텐츠 생성하는 서버입니다. 사용자의 요청에 따라 데이터베이스에 접속하여 데이터를 조회하거나, 비즈니스 로직(계산, 수정 등)을 수행한 뒤 그 결과를 실시간으로 만들어냅니다. 즉, 프로그램이 실행되는 환경을 제공합니다.

예를 들어, 마이페이지에 들어갔을 때 내 이름과 같은 주요 정보가 보이는 것은 WAS가 DB에서 내 정보를 가져와 HTML을 실시간으로 조립했기 때문입니다. 흔히 '미들웨어(Middleware)'라고도 불리며, 웹 서버와 데이터베이스 사이에서 동작합니다.

주요 역할
- 비즈니스 로직 수행, 트랜잭션 관리, DB 연결
대표 소프트웨어
- Apache Tomcat, JBoss(WildFly), Jeus, WebSphere

왜 둘을 나누어 쓸까요? (Web Server + WAS 조합)

물론 Tomcat 같은 WAS도 정적 파일을 처리할 수 있고, Node.js처럼 둘의 경계가 모호한 경우도 있습니다. 하지만 실무에서는 대개 Nginx(웹 서버)를 앞단에 두고, 그 뒤에 Tomcat(WAS)이나 Spring Boot를 배치합니다.

1. 성능 최적화
단순한 이미지/파일 전송은 빠르고 가벼운 웹 서버가 처리하고, 무거운 연산 처리는 WAS가 전담하여 서버 부하를 분산합니다.

2. 보안 강화
실제 로직이 수행되는 WAS를 직접 노출하지 않고 웹 서버를 앞세워(Reverse Proxy) 외부 공격으로부터 내부 서버와 DB를 보호합니다. (SSL/TLS 암호화 처리도 주로 웹 서버가 담당합니다.)

3.3 포워드 프록시 vs 리버스 프록시 vs 로드 밸런서

위에서 언급한 리버스 프록시나 로드 밸런서, 실무에서 정말 많이 쓰이는 용어입니다. 헷갈리는 이 개념들, 누구를 숨겨주는가?를 기준으로 보면 명확합니다.

포워드 프록시(Forward Proxy)
- 클라이언트(사용자)를 숨겨주는 대리인
  - 클라이언트 보호(Client IP 보호)
- 클라이언트가 인터넷(서버)에 직접 접근하는 대신, 프록시 서버가 요청을 받아 대신 인터넷에 접속해 주는 방식입니다. 서버 입장에서는 요청을 보낸 것이 사용자인지 프록시인지 알 수 없습니다.
- 위치
  - 클라이언트 — [포워드 프록시] — 인터넷 — 서버
- 주요 용도
  - 캐싱(속도 향상), 사내 망 보안/통제(특정 사이트 차단)

https://velog.io/@rockwellvinca/Reverse-Proxy와-Forward-Proxy-쉽게-이해하기

리버스 프록시(Reverse Proxy)
- 서버를 숨겨주는 문지기
  - 서버 IP 및 구조 보호
- 클라이언트가 서버(WAS)에 직접 접근하지 못하게 하고, 프록시 서버가 가장 앞단에서 요청을 받아 뒤에 있는 실제 서버에게 전달해 주는 방식입니다. 우리가 흔히 구성하는 Nginx + Tomcat 조합이 바로 이 구조입니다.
- 위치
  - 클라이언트 — 인터넷 — [리버스 프록시] — 내부망(WAS)
- 주요 용도
  - 보안 강화(DMZ 구간 활용), SSL 암호화 처리, 로드 밸런싱

로드 밸런서
- 트래픽을 나누어 주는 교통정리 요원
- 웹 사이트에 접속자가 폭주할 때, 서버 한 대로는 감당이 안 됩니다. 이때 여러 대의 서버를 두고 트래픽을 골고루 분산시켜 주는 역할을 합니다. 대부분의 리버스 프록시 소프트웨어(Nginx, HAProxy 등)가 이 역할을 겸해서 수행합니다.
- 작동 방식
  - 요청이 오면 1번 서버, 2번 서버, 3번 서버에 순서대로 보내거나(Round Robin), 가장 덜 바쁜 서버에 작업을 할당합니다.
- 주요 용도
  - 서버 부하 분산, 무중단 배포(서버 하나가 죽어도 다른 서버로 연결

https://whdrns2013.github.io/ops/20250610_005_loadbalancing/

4. SPA vs MPA

이 두 용어는 웹 애플리케이션의 물리적인 구조와 페이지 이동 방식을 구분하는 기준입니다. 가장 직관적인 차이는 "페이지 이동 시 화면 전체가 깜빡이며 새로고침 되는가?"입니다.

4.1 MPA(Multi Page Application)

MPA는 여러 개의 HTML 페이지로 구성된 전통적인 방식의 웹 애플리케이션입니다. 사용자가 링크를 클릭하거나 데이터를 전송할 때마다, 서버로부터 새로운 HTML 페이지 전체를 받아옵니다.

동작 방식
1. Initial Request
  - 사용자가 사이트에 처음 접속하면 서버는 첫 페이지의 완성된 HTML을 응답합니다.
2. Page Reload
  - 사용자가 버튼을 클릭하거나 폼(Form)을 전송하면, 브라우저는 현재 페이지를 지우고 서버에 새로운 요청을 보냅니다.
3. Response HTML
  - 서버는 요청에 맞는 새로운 HTML(헤더, 본문 포함)을 만들어 보내줍니다. 브라우저는 이 HTML을 받아 화면 전체를 다시 그립니다.

https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/november/asp-net-single-page-applications-build-modern-responsive-web-apps-with-asp-net

주요 사례
- 아마존(Amazon), 관공서 사이트, 포털 사이트의 뉴스 섹션(네이버 뉴스 등)
장점
- SEO(검색 엔진 최적화) 유리
  - 페이지마다 고유한 URL과 완성된 HTML이 존재하여 크롤러가 데이터를 수집하기 좋습니다.
- 초기 로딩 속도
  - 첫 페이지 로딩 시 필요한 정적 리소스만 가져오므로, SPA에 비해 초기 진입이 빠를 수 있습니다.
단점
- UX 저하 (Page Reload)
  - 페이지 이동 시마다 화면이 '깜빡'이는 현상이 발생합니다.
- 서버/네트워크 비효율
  - 모든 페이지에 중복되는 헤더, 내비게이션 바 등의 HTML 코드까지 매번 다시 다운로드해야 합니다.

4.2 SPA(Single Page Application)

SPA는 단 하나의 HTML 페이지로 동작하는 모던 웹 애플리케이션입니다. 초기 로딩 이후에는 필요한 데이터만 서버와 주고받으며 화면을 동적으로 갱신합니다.

동작 방식
1. Initial Request
  - 첫 접속 시, 웹 애플리케이션 구동에 필요한 HTML 뼈대와 정적 리소스(JS, CSS)를 모두 내려받습니다.
2. AJAX
  - 사용자가 상호작용(버튼 클릭 등)을 하면, 브라우저는 화면을 새로고침하지 않고 비동기(AJAX)로 서버에 요청을 보냅니다.
3. JSON Response
  - 서버는 HTML 대신 데이터(JSON)만 응답합니다.
4. Client Update
  - 브라우저(자바스크립트)가 받아온 JSON 데이터를 해석하여, 화면에서 변경이 필요한 부분만 쏙 골라 업데이트합니다.

주요 사례
- Gmail, 구글 지도(Google Maps), 노션(Notion), 에어비앤비(Airbnb)
장점
- 뛰어난 사용자 경험(UX)
  - 새로고침 없이 자연스럽게 화면이 전환되며, 앱(App)과 유사한 사용성을 제공합니다.
- 서버 부하 감소
  - 화면 껍데기는 클라이언트가 가지고 있고, 알맹이(데이터)만 주고받으므로 트래픽이 감소합니다.
단점
- 초기 구동 속도
  - 앱 구동에 필요한 거대한 자바스크립트 파일을 처음에 다 받아야 하므로, 첫 화면이 뜰 때까지 시간이 걸립니다.
- SEO 이슈
  - 검색 봇이 접속했을 때, 데이터가 채워지지 않은 빈 HTML만 보일 수 있어 별도의 처리가 필요합니다. (SSR 등을 통해 해결 가능)

5. SSR vs CSR

SPA와 MPA가 페이지 구조라면, SSR과 CSR은 화면을 어디서 그리는가(Rendering)'에 대한 방법론입니다. 4번 항목과 짝꿍처럼 따라다니는 개념입니다.

5.1 SSR(Server Side Rendering)

서버에서 데이터까지 모두 채운 완성품 HTML을 만들어 브라우저에게 전달합니다. 브라우저는 복잡한 과정 없이 받자마자 화면에 띄우기만 하면 됩니다.

동작 방식
1. 사용자가 웹 페이지를 방문하면, 서버는 즉시 브라우저에게 보여줄 HTML 콘텐츠를 컴파일(생성)하여 보냅니다.
2. 브라우저는 HTML을 다운로드하자마자 화면에 렌더링합니다. 이 시점부터 사용자는 화면의 내용을 눈으로 볼 수 있습니다. (Viewable)
3. 화면은 보이지만 아직 기능은 작동하지 않습니다. 브라우저는 뒤이어 자바스크립트(JS) 파일을 다운로드하고 실행(React 등)합니다.
4. JS 연결이 끝나면 비로소 버튼 클릭 같은 사용자 상호작용이 가능해집니다. (Interactable)

https://velog.io/@rookieand/CSR-SSR-SPA-MPA-이것들은-뭘까

주로 사용
- MPA 구조
특징
- TTV(Time To View) 빠름
  - 사용자가 화면을 보는 시점이 매우 빠릅니다.
- SEO 최적화
  - 검색 봇이 페이지 내용을 완벽하게 읽을 수 있습니다.
- 서버 부하
  - 사용자가 많아지면 매번 HTML을 생성해야 하는 서버의 부담이 커집니다.

5.2 CSR(Client Side Rendering)

서버는 내용이 비어있는 HTML과 자바스크립트 파일만 던져줍니다. 브라우저가 이 파일을 실행한 뒤, 데이터를 가져와서 직접 화면을 그립니다.

동작 방식
1. 사용자가 웹 페이지를 방문하면, 서버는 뼈대만 있는 최소한의 HTML과 자바스크립트 링크를 보냅니다.
2. 브라우저는 HTML을 읽고 스크립트 태그를 통해 거대한 JS 번들 파일을 다운로드합니다. 이때까지 사용자는 흰 화면이나 로딩 바만 보게 됩니다.
3. JS 다운로드가 끝나면 브라우저(React/Vue 등)가 실행되고, Ajax를 통해 서버에서 필요한 데이터(콘텐츠)를 가져옵니다.
4. 데이터를 다 가져와서 화면을 그리는 순간, "보는 것(Viewable)"과 "누르는 것(Interactable)"이 동시에 가능해집니다.

주로 사용
- SPA 구조(React, Vule, Angular 등)
특징
- TTV(Time To View) 느림
  - 자바스크립트를 다운로드하고 실행할 때까지 초기에는 빈 화면이 보일 수 있습니다.
- 화면 전환 빠름
  - 초기 로딩 후에는 서버를 거치지 않고 브라우저 내부에서 화면을 바꾸므로 반응 속도가 매우 빠릅니다.
- SEO 불리
  - 검색 봇이 빈 HTML만 보고 내용을 인식하지 못할 수 있습니다. (최근 검색 엔진은 JS 해석 능력이 향상되었으나 여전히 SSR에 비해 불리함)

Universal Rendering (SSG/SSR + CSR)

최근에는 두 방식의 장점을 합쳐, 첫 페이지는 SSR로 빠르게 보여주고(SEO 해결), 이후 상호작용은 CSR로 처리하는 방식(Next.js, Nuxt.js 등)이 표준처럼 사용되고 있습니다.

6. 최종 정리

지금까지 헷갈리기 쉬운 웹 개발 필수 용어들을 정리해 보았습니다. 각 용어는 독립적인 것이 아니라 서로 밀접하게 연관되어 있습니다. 마지막으로 한눈에 보기 쉽게 정리하며 글을 마치겠습니다.

구분	개념 A	개념 B	핵심 차이 (한 줄 요약)
개발 영역	프론트엔드	백엔드	사용자 화면(UI) vs 데이터 처리 및 서버 로직
통신 역할	클라이언트	서버	요청하는 주체(브라우저) vs 응답하는 주체(컴퓨터)
서버 종류	웹 서버 (WS)	WAS	정적 파일 전송(배달부) vs 동적 기능 수행(요리사)
네트워크	리버스 프록시	로드 밸런서	서버 보안/숨김(Nginx) vs 트래픽 분산
페이지 구조	MPA	SPA	HTML 전체 새로고침(깜빡임 O) vs 부분 갱신(깜빡임 X)
렌더링 주체	SSR	CSR	서버가 그림(SEO 유리) vs 브라우저가 그림(UX 우수)

7. 참고 자료

저작자표시 비영리 (새창열림)

'Security Tech' 카테고리의 다른 글

임베디드 & 펌웨어 (0)	2026.01.31
CVE-2026-24061 PoC (0)	2026.01.31
RDS·Aurora 서버리스 환경에서 달라지는 보안취약점 진단 기준 (AWS 공동책임모델) (0)	2025.11.30
Android와 iOS 아키텍처 비교: 모바일 플랫폼 구조와 특징 정리 (0)	2025.11.30
iOS에서 Frida 시작하기 (2탄) (0)	2025.10.31

Contents