웹 서버? 서버란?

서버 = 서버

서론

 이 물음은 단순개발만을 위해 공부했던 내가, 사용만을 위해서 넘겨짚었던 자칫 방대하면서도 고통스러운 개념들을 정리해가기 위해 써내려가는 글이다.

 서버란 무엇인지, 웹 서버의 역할은 무엇인지, 서버를 돌린다는 의미가 무엇인지 등, 지금의 내가 사용은 하지만 그 이유와 동작에 대해선 넘겨짚었던 것들에 대해서 세세히 다루어 보려한다.

 

아.. 서버 터졌네

아아!!!!!!!!!

 

막연한 서버라고했을 때 무엇을 떠올리나 라고 내가 나에게 물어본다면 그 개념에 대해 짚기가 어렵다. 불과 몇년전까지만해도 서버란 내가 이용하고있는 해당 웹이나, 게임을 내게 서비스하고있는 해당 회사라고 생각했다. 그래서 “서버 터졌네” , “서버 이상하네” 라는 말을 알게모르게 사용하면서 굳혀진 개념 같다.

물론 최근까지도 서버란 전부 백엔드의 영역. 엔드포인트를 제공해주는, 내 요청에 응답을 해주는 시스템이라고 넘겨짚었던 것이 이 다음의 개념을 학습하기에 걸림돌이 되었다. 따지고 보면 이러한 것들이 틀린 말은 아니다. 관점이 다른 것 이였다

 

서버란? - 서버의 개념

 서버란 것을 굳혀진 어떠한 시스템 같은 하나의 직업으로 생각하고 보면 개념들이 햇갈린다. 어떨 때의 서버는 파일을 제공해주는 서비스가 될 수도있고, 어떨때의 서버는 게임 환경을 관리하고 제공하는 것이 될 수 있다. 서버란 것은 단순히 백엔드나 회사의 컴퓨터가 아닌 특정 서비스를 제공하는 모든 시스템을 포괄하는 개념이다. 즉 무엇을 하는가에 따라 정의되는 역할의 개념으로서 특정 물리적 장치나 소프트웨어에 국한된 개념이 아니란 것이다.

 이게 무슨말이냐면 ‘서비스를 제공하면 그것이 서버다’ 라고 할 수 있다는 것이다. 귀에걸면 귀걸이고 코에걸면 코걸이다.

 

예시를 들어보자.

 

식당에서의 서비스를 생각해보면 이해하기 쉬울 것이다.

 

1. 손님(클라이언트)이 메뉴를 주문(요청)
2. 주방(서버)에서 음식을 만들어(처리) 제공(응답)

이처럼 서버는 '서비스를 제공하는 주체' 그 자체다.

똑같당

같은 맥락에서:

• 도서관 사서도 일종의 '서버'다:
  • 방문객(클라이언트)이 책을 요청하면
  • 사서가 책의 위치를 찾아(처리)
  • 해당 책을 제공(응답)
• 자판기도 '서버'다:
  • 사용자(클라이언트)가 음료를 선택하고 돈을 넣으면(요청)
  • 자판기가 이를 처리하여
  • 음료를 제공(응답)
• 택시 기사님도 '서버':
  • 승객(클라이언트)이 목적지를 말하면(요청)
  • 운전하여 이동(처리)
  • 목적지에 도착(응답)

 여기서 더 나아가자면, 사서가 택시를 탄다면? 응답을 제공하는 사서가 이제는 택시기사에게 요청을 하는 클라이언트가 될 수 도 있다. 이 말을 웹사이트 관점에서 보자면, 특정 웹사이트가있는데 이 웹의 하단에는 이 회사의 위치가 있고 클릭하면 해당 위치를 보여주는 지도가 나타난다. 이때 이 지도데이터는 이 웹사이트가 지도 데이터 서버에서 필요한 정보를 요청해서 받아온 것 이다.

 

이런 관계를 정리해보면:

역할로서의 서버

1. 사용자(클라이언트) → 회사 웹사이트(서버)
   • 사용자가 웹사이트에 접속하여 회사 위치 확인 요청
   • 웹사이트는 이 요청에 대한 페이지 제공
2. 회사 웹사이트(클라이언트) → 지도 서버(서버)
   • 웹사이트가 지도 서버에 해당 좌표의 지도 데이터 요청
   • 지도 서버는 요청받은 좌표의 지도 정보 제공

이처럼 하나의 주체가 서비스를 제공할 때는 '서버'가 되고 서비스를 요청할 때는 '클라이언트'가 된다.

 

 예시가 길었지만 결론은 서버와 클라이언트는 절대적인 개념이 아니라 서비스를 주고받는 관계에 따라 상대적으로 정의되는 역할임을 말하고싶었다. 이처럼 서버는 단순히 컴퓨터나 프로그램이 아닌, '요청을 받아 서비스를 제공하는 모든 것'이 될 수 있다. 이런 관점으로 보면 컴퓨터 세계의 서버도 단순히 '서비스를 제공하는 주체'라는 것을 이해하기 쉬워진다.

이렇게 먼저 서버란 무엇인지에 대해 어느정도 알게되었다면 이젠 이 서버가 왜 필요했는지에 대해 알아야한다.

 

웹서버는 왜 필요했을까?

팀 버너스리 경은 영국의 컴퓨터 과학자이다. 1989년 월드 와이드 웹의 하이퍼텍스트 시스템을 고안하여 개발했다.

 

웹의 아버지 팀 버너스리로부터 시작되었다.

 

그는 4가지의 필요성을 느꼈었다.

 

정보공유의 필요성

 

• 팀 버너스리가 CERN(유럽 입자물리연구소)에서 일할 때, 연구자들 간에 문서와 연구자료를 쉽게 공유할 방법이 필요했었다.
• 당시에는 각자의 컴퓨터에 있는 정보를 공유하기가 매우 어려웠을 것이다.
• 당시의 서로다른 컴퓨터와 운영체제를 사용했기 떄문에 정보 교환이 복잡했었다.

중앙 집중식 정보 저장소의 필요성

 

• 그리고 그는 모든 문서를 한 곳에서 관리하고 싶었고 누군가 정보를 업데이트하면 모든 사람이 즉시 최신 버전을 볼 수 있어야했다. → 정보의 일관성을 유지하기 위해서였다

 

표준화된 접근 방식의 필요성

 

• 누구나 쉽게 정보에 접근할 수 있어야 했다
• 특별한 프로그램 없이도 정보를 볼 수 있어야 했다
• 플랫폼에 상관없이 동일한 방식으로 작동해야 했다

하이퍼텍스트의 구현

• 문서들을 서로 연결하고 싶었다
• 한 문서에서 다른 문서로 쉽게 이동할 수 있어야 했다
• 이것이 나중에 우리가 아는 웹의 핵심 특징이 되었다

 

이러한 점을 토대로 개발한것이 월드 와이드 웹 이다.

 

월드와이드 웹(www)

www

 

월드와이드 웹(www)은 전체 시스템을 말하며, 이는 세가지 핵심요소로 구성되어있다.

 

HTML (Hypertext Markup Language)

• 웹 페이지를 만들기 위한 문서 형식
• 하이퍼링크를 통해 다른 문서로 이동 가능
• 문서의 구조를 정의하는 마크업 언어

HTTP (Hypertext Transfer Protocol)

• 웹 브라우저와 웹 서버 간의 통신 규약
• 클라이언트와 서버가 데이터를 주고받는 방식
• 요청(Request)과 응답(Response) 구조

웹 서버 (Web Server)

• HTTP 요청을 처리하는 프로그램
• HTML 문서를 클라이언트에게 전달
• CERN httpd가 최초의 웹 서버

 

http://info.cern.ch

http://info.cern.ch

최초의 웹사이트다. 이 웹의 기능은

기본적인 문서 보기	문서 편집
단순한 텍스트 표시 기본적인 포맷팅 (제목, 단락) 하이퍼링크를 통한 문서 간 이동	간단한 텍스트 편집 하이퍼링크 생성 HTML 문서 작성

 

 

 기능을 보면

단순한 문서를 보고, 통신을하고 문서 간 이동을 하더라도 이러한 사용자의 요청을 처리할 ‘무언가’ 가 있어야한다. 그리고 이 요청을 처리하고 응답을 하는 역할은 위에서 언급했듯이 ‘서버’ 이고 아래의 사진은 최초의 웹 서버이다. 팀 버너스리의 데스크톱 컴퓨터가 최초의 웹 서버였다.

 

우측 본체에 손글씨 메모가 붙어져 있다.

 

(this machine is a server. Do not Power Down) - 이 기계는 서버입니다. 전원을 내리지 마세요.

 

왜 전원을 내리지 말아야 하지?

TV의 전원을 꺼라..!

 

 CERN 내부 연구자들이나 일부 외부 연구기관 관계자들에 의해서 문서를 보여주고, 요청을 처리해야할 이 ‘서버’가 꺼지면 누구도 웹에 접속할 수 없었기 때문이다. 자세히는 문서를 열람하고싶은 사람이(클라이언트) 가 URL로 접속을 하면, 이 서버는 요청된 경로의 HTML 파일을 찾아서(처리) 해당 파일을 HTTP로 전송(응답) 해야 했기 때문이다.

(먼 얘기지만 여기서 이 단일 ‘서버’에 대한 문제들과 단점들 점차 극복하며 여러 시대를 거쳐 현대의 유연한 클라우드 시스템까지 이어지게 된다.)

 

웹 서버의 발전

 

초기의 웹 서버

 초기의 웹 서버는 무엇이 문제였을까? 단순한 파일만을 전송했고 정적인 HTML 문서만을 제공했고, 기본적인 요청 처리만을 했다. 정적인 HTML을 좀 더 이해하기 쉽게 말하자면, 열 명의 사용자에게 각각 다른 이름을 넣은 문서를 보내려면 실제로 열 개의 HTML 파일을 만들어야 했었다. 이는 매우 비효율적이었을 것이다.

 

CGI

이런 한계를 극복하기 위해 1993년 CGI(Common Gateway Interface)가 도입되었다. CGI를 통해 처음으로 '동적 컨텐츠'가 가능해졌다. 이제 하나의 프로그램이 사용자의 요청을 받아서 필요한 부분만 바꿔서 HTML을 생성할 수 있게 된 것이다.

 

(하나의 편지를 쓰고 이름을 적어야하는 부분에 이름을 받을 NAME을 작성해두고, URL에서 이름을 파라미터로 받으면 해당 이름을 NAME에 담는 것이다. 그리고 이렇게 생성된 HTML을 다시 웹 서버에게 전달하고 이 HTML을 웹서버가 클라이언트에게 전달한다. )

 

하지만 CGI도 문제가 있었습니다. 요청이 올 때마다 새로운 프로세스를 만들어야 했기 때문에, 많은 사용자가 동시에 접속하면 서버에 큰 부담이 되었다.

 

 

서버 사이드 스크립트

 

 이 문제를 해결하기 위해 1995년경부터 서버 사이드 스크립트(PHP, ASP 등)가 등장했습니다. 이제 웹 서버 안에서 직접 프로그램이 실행되어 CGI처럼 매번 새로운 프로세스를 만들 필요가 없어졌습니다. 성능이 크게 개선될 수 있었다.

 

(서버사이드 스크립트란 side → ~편, ~쪽 으로 서버쪽에서 실행되는 프로그램을 의미한다)

 

 서버쪽에서 실행되는 프로그램으로 사용자가 볼 수 없고, 실행 결과인 HTML만 클라이언트로 전송한다. 따라 데이터베이스 접근 등 민감한 작업이 처리가 가능해진다.

 

CGI와 차이점은

CGI	서버 사이드 스크립트
요청마다 새 프로세스 생성 실행 후 프로세스 종료 리소스 많이 사용	하나의 엔진이 계속 실행 여러 요청을 같은 프로세스에서 처리 리소스 효율적 사용

 

하지만 전자상거래가 발전하면서 더 복잡한 처리가 필요해졌고 아래와 같은 요구사항들이 생겨났다.

다해줘!

복잡한 데이터 처리	사용자 관리	안전한 거래
상품 목록 관리 재고 관리 주문 처리	회원 정보 관리 로그인 상태 유지 장바구니 기능	결제 처리 트랜잭션 관리 데이터 일관성 유지

 

이에따라 서버사이드 스크립트의 한계도 역시 있었다.

단순한 구조	성능 이슈
페이지 단위의 처리 복잡한 비즈니스 로직 처리 어려움 코드 재사용성 낮음	대규모 트래픽 처리 한계 데이터베이스 연결 관리의 비효율 메모리 관리의 한계

WAS

그리고 이를 극복하기 위해 WAS가 등장했다.

WAS는 웹 어플리케이션 서버다. Web Application Server

한마디로 정리하면 ‘상황에 따라 다른 내용을 보여줘야 하는 복잡한 작업’ 을 처리하는 전문적인 서버이다.

 

 

 

기존의 웹 서버는 정적인 컨텐츠를 반환하는 것이였다. 하지만 앞선 한계점들을 극복하기위해 새롭게 동적인 컨텐츠를 처리할 무언가가 필요했고 그것이 WAS의 역할이다.

쇼핑몰에서 내 주문 내역을 확인하는 상황이라고 가정해보자

 

1. Client → Web Server

고객(Client)이 "내 주문 내역 보여줘" 라고 요청
(HTTP Request)

 

2. Web Server → WAS

웹 서버가 "이건 개인별 주문내역을 조회하는 거니까 WAS의 도움이 필요하겠네"라고 판단하고 WAS에게 작업 요청

 

3. WAS ↔ Database

WAS가 데이터베이스에 "이 고객의 주문 내역 좀 알려줘"라고 요청
데이터베이스가 "네, 이 고객은 지난주에 신발을 주문했네요"라고 응답

 

4. WAS → Web Server → Client

WAS가 받은 정보로 웹 페이지를 만들어서 웹 서버에게 전달
웹 서버는 이 페이지를 최종적으로 고객에게 보여줌
(HTTP Response)

 

 즉, 클라이언트의 요청이 들어오면 웹 서버가 먼저 받고, 필요한 경우 WAS에게 도움을 요청하며, WAS는 데이터베이스와 통신하여 필요한 정보를 가져와 처리하는 구조입니다.

따라서 WAS의 주요 기능은 데이터베이스 커넥션 풀 관리와, 트랜잭션관리, 세션 관리, 비즈니스 로직 처리 등을 하며 효율적인 리소스를 관리한다.

 

 

현대의 서버

 

여기서 더 발전한것이 현대의 웹 서비스이다. 그리고 이 과정에서의 핵심은 ‘규모’와 ‘복잡도’이다.

 

기존

단일 시스템의 한계	서비스 수정/배포의 어려움
하나의 WAS로 모든 서비스 처리 트래픽이 몰리면 전체 서비스가 느려짐 예시: 쿠팡에서 대규모 할인 행사할 때 서버가 전체적으로 느려지는 상황	작은 수정에도 전체 시스템을 재배포 한 부분의 문제가 전체에 영향 예시: 장바구니 기능 수정하는데 전체 서비스를 중단해야 하는 상황

 

이에 따라 현대 웹 서버의 해결책은

마이크로서비스 아키텍처	컨테이너 기술
서비스를 작은 단위로 분리 독립적으로 개발/배포 가능 예시: 주문, 결제, 배송을 별도 서비스로 운영	필요한 환경을 패키지로 관리 어디서든 동일하게 실행 예시: Docker로 개발/테스트/운영 환경을 동일하게 유지

 

이렇듯 현대의 웹 서버는 더욱 진화했습니다.

로드벨런서 : 서버에 가해지는 부하를 분산해주는 장치 또는 기술

 

 비동기 처리로 더 많은 요청을 효율적으로 처리할 수 있게 되었고, 마이크로서비스 아키텍처를 통해 서비스를 작은 단위로 나누어 관리할 수 있게 되었습니다. 클라우드 환경에 최적화된 컨테이너 기술을 사용하여 서버를 더욱 효율적으로 운영할 수 있게 되었고, 자동으로 서버를 확장하거나 축소할 수 있는 유연성도 갖추게 되었다. 이러한 발전 과정은 결국 사용자에게 더 나은 서비스를 제공하기 위한 끊임없는 혁신의 결과였다. 단순한 파일 전송에서 시작해서 현재는 복잡한 비즈니스 로직을 처리하고, 수많은 사용자의 요청을 동시에 처리할 수 있는 강력한 시스템으로 발전한 것이다.

 

 

서버를 돌린다!

붕붕~~

 

 이렇게 서버가무엇인지 과거부터 현대시점까지 보았다면,  ‘서버를 돌린다’ 라는 말을 들었을 때 어느정도 흩뿌려졌던 개념이 집약적으로 모여지게된다. 아 서버를 돌린다라는 것은 서비스를 제공할 수 있도록 그러니까 요청에 응답을 줄 수 있도록 서버를 동작시킨다. 로 될 것이다.

 

맺는말

 이렇게 서버의 기본 개념부터 웹 서버의 발전 과정까지 읊어보았다. 처음에는 단순히 "서버가 터졌다"는 말로만 알고 있던 서버가, 사실은 '서비스를 제공하는 모든 주체'를 의미한다는 것을 이해하게 되었다. 팀 버너스리의 단순한 데스크톱 컴퓨터에서 시작된 웹 서버는 정적 HTML 문서 제공에서 CGI, 서버 사이드 스크립트를 거쳐 WAS로, 그리고 현대의 마이크로서비스 아키텍처와 클라우드 시스템으로까지 발전했다.

 이 모든 발전의 중심, 이것이 가능하게 된 이유는 '더 나은 서비스 제공'이라는 단순하면서도 강력한 목표가 있었다고 생각한다. 현대의 웹 서버는 단순한 파일 전송을 넘어 복잡한 비즈니스 로직을 처리하고, 수많은 사용자의 요청을 동시에 처리하는 강력한 시스템이 되었고 일상적으로 사용하는 전자상거래, 소셜 미디어, 스트리밍 서비스 등을 가능하게 만들었다.

 끝으로 서버의 본질은 결국 '서비스 제공'이다. 시대가 변하고 기술이 발전해도 이 핵심 가치는 변함없이 유지되고 있으며, 앞으로도 더 나은 서비스를 제공하기 위한 혁신은 계속될 것이라 생각한다.