[1주차 강의] 3. 동적페이지

웹서버는 파일을 전달하는 친구이다.
클라이언트마다 다른 데이터를 보여줘야한다.
동적 페이지를 누가 만드느냐? WAS(Web Application Server)
세가지 구성요소 : Web 서버, WAS, DB
클라이언트가 특정 파일을 요청할 때, 특정 파일이 동적페이지이면 web서버는 WAS에게 요청함
WAS는 필요하면 DB를 조회하고 페이지를 만들어서 Web서버에 전달하고 Web서버는 클라이언트에게 전달함
./dockerCMD & : 백그라운드로 실행
소스코드를 본다고 해서 실제 코드가 보이지 않는다. WAS가 처리한 결과만 볼 수 있다.
php 문법 - $_GET['name'] : GET Method로 전달받은 파라미터
Method : Get, Post
Front-end : 클라이언트 측 코드(브라우저가 실행하는 코드) (HTML, CSS, JavaScript)
Back-end : 서버측 코드(php, asp, jsp...)

 

이번 강의는 전반적으로 기본적으로 웹 서버가 어떻게 작동하는지 알려주는 강의였다.
크게 새로운 개념이 없지만 일부 정리해보면 아래 4가지 정도가 있을 것 같다.

1. WAS 개념
2. RESTful 통신 방법
3. docker 개념
4. 프론트와 백엔드

 

이 중에서 이번 포스팅에서는 간단하게 1번과 4번에 해당되는 웹 시스템에 대해서 정리해보려고 한다. RESTful과 docker 개념은 깊게 들어가면 너무 내용이 많아질 것 같으니 추후 포스팅 해보자.

 

웹 시스템의 구조

용어들이 조금 혼동되어서 개념을 익히기 어려운 분도 있을 것 같다. WAS가 동적인 데이터를 다룬다면 백엔드와 동일한 개념일까? 프론트엔드와 웹서버도 같은 개념으로 볼 수 있을까? 실무에서는 WAS와 백엔드가 동일하게 쓰이는 경우가 대부분이지만 그렇지 않은 경우도 없지는 않다. 이런 개념들이 처음엔 받아들이기에 어려울 수도 있어서 완벽한 정의는 아닐 수도 있지만 큰 틀에서 웹 시스템에 대한 감을 잡아보면 좋을 것 같다.

---

사용자 입장 개념: 프론트엔드 vs 백엔드

웹 서비스를 사용할 때 사용자는 보통 “화면(UI)“만 보게 되지만, 그 뒤에는 요청을 받아 처리하고 응답을 만들어주는 여러 시스템들이 동작하고 있다. 이 흐름을 사용자 관점에서 나눠보면 프론트엔드와 백엔드로 구분할 수 있다. 프론트는 사용자와 소통하는 기능들을 담당하기 때문에 웹 시스템 입장에서 가장 앞단에 있고 백엔드는 사용자의 뒤쪽에서 작동하는 기능들을 담당하기 때문에 이렇게 명명하고 있다.

구분	설명	예시
프론트엔드 (Frontend)	사용자와 직접 상호작용하는 UI 화면	HTML, CSS, JavaScript, React, Vue
백엔드 (Backend)	사용자 요청을 받아 처리하는 시스템, 로직 실행, DB 연동	로그인, 결제, API 서버, DB 처리 등

• 프론트엔드는 보이는 영역 (브라우저에서 실행)
• 백엔드는 보이지 않지만 기능이 돌아가는 영역 (서버에서 실행)

---

서버 기능 기반: Web server, WAS, DB 서버

 

기능 기반 서버 분류와 확장 전략

프론트와 백엔드는 사용자 입장에서 비교적 직관적인(이 또한 명확하지는 않을 때도 있지만) 보이는 것과 보이지 않는 것 기준으로 설명했다. 하지만 실제 시스템을 설계하거나 운영하는 개발자 입장에서는 어떤 기준으로 어떤 단위로 나눠보는게 좋을까? 웹 서비스는 결국 24시간 돌아가야하는 서비스이기 때문에 만드는 것도 중요하지만 이를 잘 유지보수하는 것도 중요하다. 원활한 유지보수를 하기 위해서라면 사람뿐만 아니라 코드 역시 R&R을 기준으로 구분해보면 좋을 것이다. 웹 서비스 보다 작고 R&R을 구분할 수 있는 가장 큰 단위인 서버를 단위로 이 서버들이 무슨 기능을 하는지(기능 기준) 로 나누는 게 훨씬 실용적이다. 아래는 기능에 따라 나눌 수 있는 서버들의 대표적인 예다

필수 구성 요소 (기본 웹 서비스에 꼭 필요)

서버	기능 예시
웹서버 (Web Server)	정적 파일 전달, 요청 수신
WAS (Web Application Server)	동적 API 처리, 로직 실행
DB 서버	데이터 저장/조회 (회원정보, 게시글 등)

확장 가능한 구성 요소 (서비스 규모가 커지면 필요한 서버)

서버	기능 예시
캐시 서버	빠른 데이터 응답, DB 부하 감소
파일 서버	이미지, 첨부파일 업로드/관리
메시지 큐 서버	비동기 처리 (이메일 발송, 알림 등)
인증 서버	로그인, 권한 처리 등 인증/인가 분리
API 게이트웨이	API 라우팅, 인증, 로깅 등 API 전체 관리

 

---

필수 서버들, 실제로는 어떻게 동작할까?

1. 웹서버: 사용자의 요청을 제일 먼저 받는 친구

사용자가 브라우저에서 웹사이트에 접속하면 가장 먼저 만나는 건 웹서버다.
이 웹서버는 사용자의 요청을 분석해서, 아래와 같이 동작한다

• 정적인 파일 요청(html, js, css 등):
  → 웹서버가 직접 응답한다
• 동적인 API 요청(/api/login 등):
  → 요청을 WAS로 전달한다 (프록시 역할)

예를들어 Nginx 웹서버는 /, /index.html, /main.js 등은 직접 응답하고, /api로 시작하는 요청은 Spring Boot 서버(WAS)로 넘긴다.

 

 

2. WAS: 진짜 로직을 처리하는 주인공

WAS는 웹 애플리케이션의 동적 요청을 처리하는 서버다. 사용자의 로그인, 글 작성, 결제 같은 요청을 받아서 로직을 수행하고, 필요하면 DB에 데이터를 읽거나 저장한다. 예를 들어 /api/login으로 로그인 요청이 들어오면 사용자가 입력한 데이터 적합성을 검토하고 DB에서 사용자를 조회해서 옳은 정보를 비교하여 옳은 정보라면 토큰을 생성해서 응답해준다.

 

 

3. DB 서버: 데이터를 책임지는 친구

회원 정보, 게시글, 주문 기록 같은 모든 데이터를 저장하고 조회하는 역할을 한다. DB는 서비스의 규모나 비즈니스 로직에 따라 관계형(RDB) 또는 비관계형(NoSQL) 등 다양한 유형 중에서 선택해서 적용할 수 있다.

• 관계형 DB (RDB): 테이블 기반, 구조화된 데이터에 적합 (예: MySQL, PostgreSQL)
• 비관계형 DB (NoSQL): 유연한 구조, 대규모 분산 처리에 강함 (예: MongoDB, DynamoDB)

DB는 보통 WAS에서 SQL 쿼리를 통해 연결되며, 예를 들어 Spring Boot에서 MySQL 서버로 다음과 같은 쿼리를 실행해 test_id라는 아이디의 데이터를 조회할 수 있다
SELECT * FROM users WHERE login_id = 'test_id';

 

---

"그런데... 로그인도 WAS가 처리하면 되지 않나?

인증 서버도 WA에서 같이 처리하면 되는거 아닌가? 실제로 맞다. 서비스 초반에는(서비스 초반을 어떻게 정의하는지도 서비스 주체마다 달라질테지만) 대부분 로그인/회원가입 등의 인증 로직도 WAS 내부에 같이 구현한다. 하지만 서비스가 커지고 복잡해질수록 문제점이 생긴다. 인증 로직이 복잡해지거나 여러 서비스가 동시에 인증을 필요로 해지거나.

 

예를 들어 비즈니스 로직으로 인해서 인증 로직이 여러가지 웹 서비스와 연결될 수도 있다. 만약 네이버 홈페이지 로그인 기능을 처리하는 서버에서 모든 네이버 간편 로그인 기능을 담당하고 있다고 해보자. 그럼 네이버 홈페이지를 이용하는 사용자 수보다 훨씬 많은 사용자 수를 처리할 수 있는 서버의 규모를 갖춰야한다. 홈페이지를 운영하는 비용보다 훨씬 크게 나올 것이다. 그렇다고 분리하는게 항상 비용이 적게 드는 것은 아닐 수도 있다.

 

하지만 비용 문제가 아니더라도 구분할 필요는 충분하다. 만약 네이버의 메인페이지에서 특정 기능을 추가했는데 메모리 최적화가 안되어서 서버가 다운되었다고 하자.(네이버같은 회사에서 단일 서버로 운영할리는 없지만 만약에 모든 서버가 다운되었다고 가정해보자) 그러면 네이버 외부페이지에서 네이버 간편로그인이 전부 불가능해지고 이건 비즈니스에 심각한 영향을 초래하게 된다. 그래서 인증 서버를 분리해서 전담하는 구조가 등장한다. Keycloak, Auth0, 자체 인증 API 같은게 말이다.

 

---

서버 구성에 어떤 상황에도 통하는 마스터키같은 정답은 없다

서비스 규모와 요구사항은 각기 다르기 때문에,서버를 어떤 식으로 구성하고 어디를 확장할지는 "비즈니스에 맞게 결정하는 것"이 가장 중요하다. 그럼 어떤 상황일 때 어떤 서버들을 확장하면 좋을까?

상황	확장할 서버	이유
사용자 수가 폭증할 때	WAS (백엔드 서버)	API 요청 처리량 증가
조회량이 많은 페이지	캐시 서버	DB 부하 줄이고 빠른 응답
이미지, 파일 업로드 많을 때	파일 서버 (ex. S3)	정적 자원 분리, 저장 용량 분산
비동기 작업 (메일, 알림) 많을 때	메시지 큐 서버	빠른 응답을 위한 작업 분리
인증 방식이 다양해질 때	인증 서버	인증/인가 전담으로 관리
마이크로서비스 구조일 때	API 게이트웨이	API 집약, 보안, 트래픽 제어

처음에는 1대 서버로 시작해도 충분하다. 하지만 서비스가 커질수록, 기능을 나눠서 독립적으로 관리하는 구조로 발전시켜야 한다. 이때 각 서버의 역할과 확장 이유를 명확히 알고 있으면 시스템을 안정적이고 효율적으로 만들 수 있다.

---

 

정리하고 보니 역시 이번 포스팅에서도 새끼 질문들이 많이 나오는 것 같다. 각 서버별로 특징과 사용 전략들만 다뤄도 꽤 내용이 길어질 것 같다. 하지만 한 포스팅에 너무 많은 이야기를 담지는 말자! 1주차 강의에서 4번째 강의는 php 맛보기였는데 RESTful 내용과 php를 어떻게 쓰는지 설명해주신다. php는 쓰지 않기로 했으니 이건 별도로 포스팅하지 않기로!