[강의] Back-end 개요

Jerry·2025년 7월 25일

코드잇 스프린트 Spring Backend 5기

목록 보기

19/60

Back-end 개요

Server-Client 구조

Server-Client 구조란 데이터를 저장하고 관리하는 서버 부분과 해당 서버에 접속하여 데이터를 열람하는 클라이언트 부분으로 구성된 네트워크 구조이다.

클라이언트(Client): 사용자와 직접 상호작용하며 요청(데이터, 서비스)을 서버로 전달하는 프로그램 또는 장치
서버(Server): 클라이언트의 요청을 받아 처리하고, 필요한 데이터나 결과를 응답으로 제공하는 시스템
통신 방식: 주로 HTTP/HTTPS 등의 프로토콜로 요청-응답(Request-Response) 구조로 동작하며, 다수 클라이언트가 하나의 서버에 연결 가능

3-Tier 구조

3 Tier 구조란 웹에서 프레젠테이션(UI), 비즈니스 로직, 데이터 계층을 역할 별로 체계적으로 분리한 아키텍처이다.

프레젠테이션 계층(Presentation Tier): 사용자와 직접 상호작용하는 UI/프론트엔드 계층 (웹, 앱 화면)
비즈니스 계층(Business Tier): 비즈니스 로직을 처리하는 서버 계층 (Spring, Node.js 등)
데이터 계층(Data Tier): 데이터 저장, 관리를 담당하는 데이터베이스 계층 (MySQL, Oracle 등)

Server-Client 모델의 역사

Main Frame: Host-Terminal (1960~1970)
Server-Client: PC-Server (1980~1990)
Web: (1990~2000)
RIA/Cloud: (2000~)

구분	Main Frame	Client/Server 모델	Web	RIA / Cloud
Client Side 기능/자원	Thin	Fat (강력한 UI 기능)	Thin	Fat
Client	Dummy Terminal	설치 필요한 전용 Client Application	각종 브라우저	각종 브라우저 / App
Server Side 기능/자원	Fat (중앙집중)	Thin (Client Application에 기능 분산)	Fat (중앙집중)	병행 Thin (Client에 기능분산) Fat (자원/infra 확장)
Server	Main Frame (HOST)	Application Server Middleware (2, 3 tier)	Web Server Web Application Server	Web Server Web Application Server
네트워크 방식	통합 / 시리얼 케이블	LAN / WAN / VPN	LAN / WAN	LAN / WAN
통신 프로토콜	TN3270(IBM) SNA / PPP(모뎀)	TCP/IP (TCP / UDP)	HTTP / HTTPS / SOAP	HTTP / HTTPS / SOAP
State	Stateful	Stateful/Stateless (필요에 따라 개발 가능)	Stateless	Stateful
주 개발언어	COBOL 외 PL/I 혹은 FORTRAN / BASIC	4세대 언어 (Power Builder, Visual Basic, Delphi 등) 때때로 VC++	HTML / javascript, CGI, JSP / JAVA, ASP / VB / C#, PYTHON	XHTML, HTML5, javascript, ajax, JSP / JAVA, ASP, .NET, C#, PYTHON
단점	- 열악한 UI - 확장성 및 개발 유연성 부족 - 벤더 제품에 국한된 시스템 - 고비용 서버	- 클라이언트 배포/관리 어려움 - 사용자 간편 UI 구축 제한 - 구조를 라이어드로 유연하게 하려면 설계 이론적	- C/S 모델에 비해 약한 UI - 매 화면(page) Refresh - 보안 문제 - 서버 고부하 - 정적인 디자인 이미지	- 아직 표준화 진행 중 - 복잡한 서버 사이드 로직 - 클라이언트 기능 미흡 - 대용량 데이터 한계

서버의 종류

서버 종류	주요 기능 및 역할
웹 서버	HTML, CSS, JS 등 웹 콘텐츠를 클라이언트(브라우저)에 전달 예: Apache, Nginx
애플리케이션 서버	동적 웹 페이지 생성 및 비즈니스 로직 실행 예: Tomcat, WebLogic
데이터베이스 서버	데이터 저장, 검색, 수정 등 데이터베이스 서비스 제공 예: MySQL, PostgreSQL
파일 서버	파일 저장 및 공유 기능 제공 예: Samba, NFS
메일 서버	이메일 송수신, 저장, 전송 관리 예: Postfix, Exchange
프록시 서버	클라이언트와 외부 서버 사이에서 요청 중계, 캐싱, 보안 필터링 예:Squid
DNS 서버	도메인 이름을 IP 주소로 변환 예: BIND
FTP 서버	파일 전송 프로토콜을 이용한 파일 업로드, 다운로드 지원 예: vsftpd
클라우드 서버	온디멘드 기반 컴퓨팅 자원 제공, 유연한확장 가능 예: AWS EC2, Azure VM

Back-end 동작 원리

서버의 동작 원리

사용자가 웹 브라우저를 특정 URL로 접근했을 때 아래의 순서대로 Web 서버가 동작한다.

URL 입력: 사용자가 브라우저 주소창에 https://www.example.com과 같은 URL을 입력
DNS 조회: 브라우저가 DNS 서버에 요청해 도메인을 실제 IP 주소(10.123.42.112)로 변환
- 브라우저 캐시, OS 캐시, 라우터 캐시 등 여러 레벨의 DNS 캐시를 먼저 확인
- 캐시에 없다면 DNS 서버로 질의하고, 최종적으로 루트 → TLD → 권한 있는 DNS 서버로 위임 요청을 통해 IP 주소를 알아냄.
웹 서버에 요청: 브라우저가 변환된 IP로 80(HTTP)/443(HTTPS) 포트에 HTML 페이지 요청
- TCP 3-way 핸드셰이크 진행
- HTTPS면 추가로 TLS 핸드셰이크를 통해 암호화된 연결을 설정
요청 처리: 웹 서버(Apache, NGINX, Tomcat 등)가 요청을 분석하고 index.html 등 파일을 탐색
- 정적인 HTML이면 바로 응답하지만,
- 동적 요청(PHP, JSP, Spring 등)은 Web Server가 Application Server(Tomcat, WAS 등)에게 넘김 (ex. NGINX → Tomcat으로 Proxy Pass)
HTML 응답 전송: 웹 서버가 요청한 HTML 파일을 브라우저로 전송
브라우저 렌더링: 브라우저가 HTML, CSS, JS를 해석해 사용자 화면을 구성
- HTML 해석 중 <script src="">, <img>, <link> 등 외부 리소스가 있으면 병렬로 추가 요청
- JS 실행 후 DOM 조작 → reflow, repaint 등 렌더링 엔진이 작동

Web 정적 페이지와 동적 페이지의 개념

정적 페이지(Static Pages): 정적인 HTML로만 구성되어 있는 페이지로 유저와 서버간의 상호작용이 어려움
동적 페이지(Dynamic Pages): 동적인 페이지로 사용자의 요청이나 권한에 따라 페이지가 실시간이 변경될 수 있는 구조로 HTML을 사용하지만 중간에 동적으로 변화하는 JSP나 AJAX가 활용되어 페이지가 변경됨

Stateless(무상태) 개념

Web(http)는 기본적으로 Stateless 상태로 동작한다.
다만 인증과 같은 상태 유지를 위해 Stateful처럼 동작해야 한다. Stateful로 동작하기 위해선 Session이나 JWT와 같은 토큰을 활용하여 Stateful 상태를 유지한다.

Stateless: 서버가 클라이언트의 상태를 저장하지 않고, 각 요청을 독립적으로 처리하는 방식
Stateful: 서버가 클라이언트의 상태 정보를 유지하며, 이전 요청과 연결된 맥락을 기반으로 처리하는 방식

항목	저장 위치	서버 상태 유지 여부	Stateful?
쿠키 (Cookie)	클라이언트 (브라우저)	✅ 일부 (세션 ID 저장 시)	🔶 조건부로 stateful
세션 (Session)	서버	✅ 서버가 상태를 유지	✅ Stateful
로컬스토리지	클라이언트 (브라우저)	❌ 서버는 모름	❌ Stateless

Back-end 서버 구조

Web Server (정적 서버)

웹 서버는 HTML, CSS, JS, 이미지 같은 정적 리소스를 클라이언트에게 제공하는 서버로, HTTP/HTTPS 프로토콜을 통해 요청과 응답 방식으로 동작하며, Apache, NGINX, IIS 등이 대표적으로 사용된다.
정적 서버는 일반적으로 WAS보다 성능이 좋고 정적 리소스 공유에 최적화 되어있다.

웹 서버	개발사 / 배포	특징	장점	단점	활용 사례
Apache HTTP Server	Apache	모듈형 아키텍처, 멀티 프로세스 기반	오픈소스, 다양한 모듈 지원, 광범위한 사용	고부하 환경에서 성능 저하 가능	전통적 웹사이트, 중소형 서비스
NGINX	F5 / NGINX Inc.	이벤트 기반 아키텍처, 비동기 처리, 리버스 프록시·로드밸런싱 지원	고성능, 낮은 리소스 사용량, 확장성 우수	동적 처리에 한계	대규모 정적 사이트, CDN, 프록시 서버
Windows IIS	Microsoft	Windows 전용, GUI 관리, .NET과 밀접 통합	보안성 높음, MS 제품과 호환성 우수	Windows 의존성, 라이선스 비용	Windows 기반 인트라넷·포털

WAS(Web Application Server, 동적 페이지)

WAS는 동적 웹 애플리케이션을 실행하고 비즈니스 로직을 처리하는 서버로, 웹 서버와 데이터베이스 사이에서 동작하며 사용자 요청에 따라 동적으로 콘텐츠를 생성한다.
대표적으로 Tomcat, JBoss, WebLogic, JEUS 등이 사용된다.
동적 서버는 성능이 저하되므로 가능하면 정적 자원은 정적 서버로 구성하는 것이 좋다.

WAS	개발사 / 배포	특징	장점	단점	활용 사례
Apache Tomcat	Apache Software Foundation	Servlet/JSP 컨테이너, 경량 WAS	오픈소스, 가볍고 빠름, 커뮤니티 활발	EJB 등 고급 JEE 스펙 미지원	Spring·JSP 기반 웹 애플리케이션
JBoss EAP (WildFly)	Red Hat	완전한 Java EE 스펙 지원, 모듈형 아키텍처	엔터프라이즈 지원, Red Hat 기술 연계	설정 복잡, 상대적 무거움	대규모 엔터프라이즈 Java 시스템
WebSphere	IBM	JEE 풀스택 지원, 다양한 IBM 솔루션 통합	대기업용 엔터프라이즈 환경 최적화	높은 라이선스 비용, 무거움	금융, 제조, 공공기관
JEUS	TmaxSoft	국내 개발, Java EE 기반, 클라우드 지원	국산 기술, 공공기관 최적화, 빠른 기술지원	해외 커뮤니티 부족	공공기관·국내 대기업 시스템

Web Server VS WAS

Web Server

장점
- 정적 콘텐츠 처리에 최적화
- 리소스 사용량이 적음
- 리버스 프록시, 로드밸런싱 등 다양한 부가 기능 제공
단점
- 동적 콘텐츠 처리 불가능
- 데이터베이스 연동, 세션 관리 불가능

WAS

장점
- 동적 콘텐츠 생성 가능
- 데이터베이스 연동, 트랜잭션 관리, 세션 관리 등 엔터프라이즈 기능 제공
- MVC 패턴 등 애플리케이션 아키텍처 구현에 적함
단점
- 리소스 사용량이 많고 무거움
- 설정 및 관리 복잡함

Nginx + Tomcat 이중화 아키텍처

Nginx + Tomcat 이중화를 통해 정적 서버와 WAS를 조합하여 구성할 수 있다.
Nginx는 클라이언트 요청을 받아 정적 콘텐츠를 빠르게 제공하고 동적 처리가 필요한 요청은 Tomcat으로 전달해 효율적으로 분담한다.
Tomcat은 전달받은 요청을 처리하며 비즈니스 로직 실행과 데이터베이스 연동을 담당한다.
이 조합은 성능과 확장성을 높이고 정적, 동적 콘텐츠를 효과적으로 분리해 관리할 수 있게 한다.

Back-end 프로토콜

프로토콜(Protocol)

사전적 의미
- 외교 의례, 의전
- (조약의) 초안; (합의안, 조약의) 보충 협약
- 프로토콜, 통신 규약
통신 프로토콜
- 통신의 절차 정의
- 각 절차 단계에서 사용하는 메시지의 내용 정의

TCP/IP

인터넷에서 메시지를 전송하기 위한 기본 프로토콜
IP(Internet Protocol)
- IP 주소를 바탕으로 메시지를 목적지까지 전송할 때 사용하는 프로토콜
- 특징
  - Best Effort: 최선을 다해 전송하지만, 정확히 전달될지 보장하지 않음
  - 왜곡, 중복, 분실 가능하지만 체크하지 않음
- IPv4(4바이트), IPv6(8바이트)
TCP(ㅅTransmission Control Protocol)
- IP를 통해 전달된 메시지가 올바른지 체크하여, 에러가 있는 경우 수정 및 재전송 기능을 제공
- port 번호 사용
  - 해당 메시지의 수신 어플리케이션을 지정할 목적으로 사용하는 정수
  - 통신을 하는 프로세스는 자신만의 고유한 포트 번호를 할당 받아야 함
TCP/IP는 운영체제 안에 구현되어 있음

IP 주소

IPv4 주소

전 세계 모든 컴퓨터에 부여된 고유의 식별 주소
4바이트(32비트)로 구성
- 사람이 식별하기 쉽도록 0.0.0.0부터 255.255.255.255로 표현
네트워크 번호와 그 네트워크에 접속해서 부여하는 호스트 번호로 구성
배정할 수 있는 IP의 수는 40억 개
- 40억 개의 IP로 전 세계의 모든 장치에 배정할 수 없음
- 사설 IP와 공개 IP를 이용해 IP 부족 문제 해결 or IPv6 활용
사설 네트워크(private network)
- 기본적으로 외부와 차단된 네트워크로서, 내부적으로만 사용
- 사설 IP를 사용하며 범위가 정해져 있음
- 사설 네트워크 간에 IP가 중복되더라도 상관없음
- 외부 네트워크와 연결될 때는 Proxy를 통해 통신 가능함

HTTP 프로토콜

주요 특징

문자 기반 프로토콜
Well-known port로 80 사용
클라이언트가 서버로 요청을 보내면 서버는 요청 내용을 클라이언트로 응답 후 접속 해제

Request

요청 라인(Reuqest Line)

HTTP 메서드 방식 및 요청 URL과 프로토콜 정보

요청 헤더(Reuqest Header)

웹 브라우저 정보, 언어, 인코딩 방식, 요청 서버 정보 등 추가 정보

요청 본체(Request Body)

요청에 필요한 내용

Response

상태 라인(Status Line)

응답 상태 코드 및 프로토콜 정보

응답 헤더(Response Header)

응답 처리 날짜, 인코딩 방식, 요청 서버 정보 등과 같은 추가 정보

응답 본체

응답에 필요한 내용

URI 구조

URI vs URL

구분	URI (Uniform Resource Identifier)	URL (Uniform Resource Locator)
목적	리소스의 식별자	리소스의 위치 표시
포함 관계	URL의 상위 개념	URI ⊃ URL
예시	`mailto:hello@example.com`	`https://www.example.com/index.html`
정의	리소스를 유일하게 식별할 수 있으면 URI	위치를 명시(접속 가능)하면 URL

한 줄 요약:
URI는 "리소스를 식별"하는 모든 식별자,
그중 URL은 "접속 가능한 주소"를 의미한다.

URI 구조

[scheme] : [//authority] [path] [?query] [#fragment]

구성 요소	의미	예시
`scheme`	사용 프로토콜	`http`, `https`, `ftp`, `mailto`, `file`
`authority`	도메인 + 포트 + 인증정보	`www.example.com:8080` 또는 `user:pass@host`
`path`	자원 경로 (폴더/파일)	`/index.html`, `/api/user/123`
`query`	추가 파라미터	`?search=cat&sort=desc`
`fragment`	문서 내 위치 참조	`#section2`, `#top`

예시

https://user:pass@example.com:8080/path/to/resource?search=cat&sort=desc#section2

요소	값
scheme	`https`
authority	`user:pass@example.com:8080`
path	`/path/to/resource`
query	`search=cat&sort=desc`
fragment	`section2`

DNS

DNS(Domain Name System)란?

사람에게 익숙한 도메인 이름(www.example.com)을
컴퓨터가 이해할 수 있는 IP 주소(93.184.216.34(로 바꿔주는 시스템

웹사이트 주소 입력 시 우리가 직접 IP를 입력할 필요 없이
DNS가 "이 도메인이 어느 IP 서버인지" 찾아줌

작동 순서

사용자가 브라우저 주소창에 www.example.com 입력
브라우저 → 여러 캐시 확인
- 브라우저 DNS 캐시 (가장 빠름)
- OS(운영체제) DNS 캐시
- Local DNS 캐시 (hosts 파일)
  - 예: /etc/hosts, C:\Windows\System32\drivers\etc\hosts
- 라우터 또는 게이트웨이 캐시
- ISP(인터넷 서비스 제공자)의 DNS 서버 캐시
- → 이 중 하나라도 있으면 즉시 IP 반환, 아래 단계 생략

캐시에 없다면 → 브라우저는 DNS 재귀 리졸버(Recursive Resolver)에게 질의

보통 ISP나 구글 DNS(8.8.8.8), Cloudflare DNS(1.1.1.1) 등이 맡는다.

재귀 리졸버가 DNS 계층 질의 수행
- Root DNS 서버
  - 전 세계에 13개 루트 DNS 서버 클러스터가 존재
  - .com, .net, .kr 등 TLD 서버의 위치 알려줌
    → ".com을 관리하는 TLD 서버 응답"
- TLD DNS 서버
  - .com 등 상위 도메인을 담당
  - example.com의 권한 있는 DNS 서버 주소(NS 레코드) 반환
    → "example.com을 담당하는 네임서버 응답"
- Authoritative DNS 서버
  - example.com 소유자가 운영하는 네임서버
    → "IP 주소 93.184.216.34 응답
재귀 리졸버 → 브라우저에 IP 응답
- 재귀 리졸버는 응답 받은 IP를 자신의 캐시에 TTL만큼 저장
브라우저는 응답 받은 IP로 TCP 연결 + HTTP/HTTPS 요청
- IP가 93.184.216.34면,
  → https://93.184.216.34로 실제 접속
- 이후 서버가 요청을 처리하고 응답 전송

DNS 계층 구조

Root (.)  
├── TLD (.com, .net, .kr, ...)  
│   └── 도메인 권한 서버 (example.com)  
│       └── 하위 도메인 (www.example.com)

To study

HTTP/HTTPS의 차이 및 핸드셰이크
- HTTP vs HTTPS
- 3-way handshake
Web Server와 Application Server의 차이
- 웹 서버(Web Server)와 WAS(Web Application Server)의 차이
브라우저의 렌더링 과정
- 브라우저의 렌더링 과정
DNS 관련 레코드
- DNS Records

Jerry

Backend engineer

이전 포스트

[Weekly Paper] HashSet, O(n)과 O(logn) 비교

다음 포스트

[강의] Back-end 개요

코드잇 스프린트 Spring Backend 5기

Back-end 개요

Server-Client 구조

3-Tier 구조

Server-Client 모델의 역사

서버의 종류

Back-end 동작 원리

서버의 동작 원리

Web 정적 페이지와 동적 페이지의 개념

Stateless(무상태) 개념

Back-end 서버 구조

Web Server (정적 서버)

WAS(Web Application Server, 동적 페이지)

Web Server VS WAS

Nginx + Tomcat 이중화 아키텍처

Back-end 프로토콜

프로토콜(Protocol)

TCP/IP

IP 주소

HTTP 프로토콜

Request

Response

URI 구조

URI vs URL

URI 구조

예시

DNS

DNS(Domain Name System)란?

작동 순서

DNS 계층 구조

To study

[Weekly Paper] HashSet, O(n)과 O(logn) 비교

[강의] Spring Framework 개요

0개의 댓글