“서버가 터졌다”, “서버에 올렸다”, “서버에서 처리한다” 같은 말을 자주 듣습니다. 그런데 막상 서버가 정확히 뭐냐고 물으면 설명이 애매해지는 경우가 많습니다. 용어는 익숙한데, 머릿속 그림이 없어서 그렇습니다.
서버는 어렵게 말하면 복잡해 보이지만, 역할만 놓고 보면 단순합니다. 누군가가 요청하면, 그 요청을 받아서 필요한 일을 처리하고, 결과를 돌려주는 쪽입니다. 웹 서비스는 이 흐름을 중심으로 돌아갑니다.

서버는 “요청을 받아서 처리하고 돌려주는 곳”입니다
서버를 한 문장으로 말하면 이렇습니다. 요청을 받는 쪽입니다. 사용자가 앱이나 웹에서 버튼을 누르거나 검색을 하면, 그 행동이 서버로 전달됩니다. 서버는 “무슨 요청인지” 확인하고, 필요한 데이터를 찾거나 계산한 뒤, 결과를 다시 보내줍니다.
사용자는 화면만 보니까 서버가 눈에 띄지 않습니다. 하지만 로그인, 결제, 게시글 저장 같은 중요한 작업은 대부분 서버에서 처리됩니다. 화면에서 “저장 완료”가 뜨는 순간 뒤에서는 서버가 바쁘게 움직입니다. 이 부분은 나중에 체감이 크게 오는 편입니다.
체크 포인트
- 서버는 요청을 받고, 처리하고, 응답합니다
- 로그인/결제/저장 같은 작업은 서버가 중심입니다
- 사용자 화면 뒤에서 서비스가 굴러가게 만드는 역할입니다
보이지 않아도, 없으면 안 됩니다.
클라이언트와 서버는 역할이 나뉩니다
웹 서비스 구조를 이해하려면 “클라이언트”라는 말을 같이 알아두는 게 좋습니다. 클라이언트는 사용자가 직접 쓰는 쪽입니다. 브라우저(크롬), 모바일 앱, PC 프로그램처럼 사용자의 화면을 담당합니다.
클라이언트는 화면을 보여주고, 사용자의 입력을 받습니다. 그리고 “이 요청을 처리해 주세요”라고 서버에 부탁합니다. 서버는 그 부탁을 받아 처리하고 결과를 돌려줍니다. 둘이 주고받는 관계입니다.
예시
- 사용자: 로그인 버튼 클릭
- 클라이언트: 아이디/비밀번호를 서버로 전송
- 서버: 인증 확인 → 성공/실패 결과 응답
- 클라이언트: 결과에 따라 화면 변경
화면은 클라이언트, 처리는 서버.
DB는 ‘데이터 창고’이고, 서버가 열쇠를 쥡니다
DB(데이터베이스)는 데이터를 저장하는 곳입니다. 회원 정보, 게시글, 주문 내역 같은 것들이 쌓입니다. 많은 초보자가 여기서 헷갈립니다. “DB가 서버인가요?”라고요. 엄밀히는 다릅니다.
DB는 저장소이고, 서버는 그 저장소를 사용해 요청을 처리하는 역할입니다. 사용자가 “내 주문 내역 보여줘”라고 요청하면, 서버가 DB에서 주문 내역을 꺼내서 가공한 뒤 사용자에게 돌려줍니다. 사용자가 DB에 직접 접근하진 않습니다. 보안과 안정성 때문에 서버가 중간에서 관리하는 구조가 흔합니다.
체크 포인트
- DB는 저장, 서버는 처리/관리
- 사용자는 DB를 직접 만지지 않는 구조가 일반적입니다
- 서버가 DB에서 꺼내고, 필요하면 계산해서 돌려줍니다
DB는 창고, 서버는 관리인.
API는 “서로 주고받는 약속”입니다
클라이언트와 서버가 대화하려면 규칙이 필요합니다. 그 규칙을 보통 API라고 부릅니다. “이 주소로 이런 데이터를 보내면, 이런 형태로 돌려준다” 같은 약속입니다. 여기서 약속이 어긋나면 화면도 서버도 같이 흔들립니다.
예를 들어 서버가 “nickname”이라는 이름으로 데이터를 보내는데, 화면 쪽은 “name”을 기대하면 표시가 안 됩니다. 이런 문제는 생각보다 흔합니다. 그래서 API 문서가 중요해지고, 서로 합의가 필요해집니다.
자주 맞추는 항목
- 요청 값(파라미터), 응답 형식(JSON 구조)
- 성공/실패 처리 방식(에러 코드, 메시지)
- 권한/로그인 필요한 조건
약속이 깨지면, 기능이 깨집니다.
웹 서비스가 돌아가는 흐름을 한 번에 보면 이렇습니다
서버가 어떤 위치에 있는지, 그림처럼 생각하면 편합니다. 복잡해 보이지만 흐름은 단순합니다.
- 사용자(브라우저/앱)에서 요청 발생
- 클라이언트가 서버에 요청 전송
- 서버가 요청 확인 후 필요한 처리 진행
- 서버가 DB에서 데이터 조회/저장
- 서버가 결과를 클라이언트에 응답
- 클라이언트가 화면에 결과 표시
이 구조를 머릿속에 그려두면, “서버가 느리다” “DB가 병목이다” 같은 말이 왜 나오는지 감이 잡힙니다. 처음에는 단어가 어려운 게 아니라 그림이 없어서 어렵게 느껴지는 경우가 많습니다.
서버는 한 대일 수도 있고, 여러 대일 수도 있습니다
처음엔 서버를 “컴퓨터 한 대”처럼 생각해도 이해에 도움이 됩니다. 다만 서비스가 커지면 서버는 여러 대가 될 수 있습니다. 접속자가 많아지면 한 대로 버티기 어렵기 때문입니다.
그래서 트래픽이 많아지면 서버를 늘리거나, 앞단에 트래픽을 분산시키는 장치를 두기도 합니다. 사용자 입장에서는 여전히 “사이트 접속”이지만, 뒤에서는 여러 장치가 역할을 나눠 갖는 경우가 많습니다. 겉은 하나인데, 속은 분업입니다.
체크 포인트
- 작을 땐 서버 1대로도 충분할 수 있습니다
- 커지면 서버를 늘리고 역할을 나눕니다
- 속도가 느려질수록 구조가 복잡해지는 편입니다
커지면 분업.
FAQ
Q. 서버는 무조건 ‘클라우드’인가요?
A. 아닙니다. 서버는 역할이고, 클라우드는 서버를 빌려 쓰는 방식 중 하나입니다. 회사에 직접 서버를 두는 경우도 있습니다.
Q. 서버와 백엔드는 같은 말인가요?
A. 비슷하게 쓰이기도 하지만 완전히 같진 않습니다. 백엔드는 서버 쪽 개발/업무 영역을 뜻하는 경우가 많고, 서버는 그 역할을 수행하는 환경/컴퓨터/시스템을 더 넓게 가리키는 경우가 많습니다.
Q. DB도 서버에 있지 않나요?
A. DB는 서버 컴퓨터에서 돌아갈 수 있습니다. 다만 역할은 구분해서 보는 게 이해에 도움이 됩니다. 저장 역할을 DB, 처리 역할을 서버(백엔드)가 맡는 구조가 흔합니다.
Q. 웹 사이트는 서버 없이 만들 수 없나요?
A. 단순한 정적 페이지는 가능하지만, 로그인/저장/검색 같은 기능이 들어가면 서버가 필요해지는 경우가 많습니다.
Q. 서버가 터진다는 건 무슨 뜻인가요?
A. 접속이 몰리거나 오류가 나서 요청을 제대로 처리하지 못하는 상태를 말하는 경우가 많습니다. 원인은 트래픽, 코드 버그, DB 병목 등 다양합니다.
서버는 요청을 받아 처리하고 결과를 돌려주는 쪽입니다. 클라이언트는 화면과 입력을 맡고, DB는 데이터를 저장합니다. 이 흐름만 그려두면 웹 서비스 구조가 훨씬 쉽게 보입니다. 오늘은 이 정도로 정리해두면 충분합니다.
'IT 테크 > 기타' 카테고리의 다른 글
| 클라우드란 무엇인가? AWS, Azure, GCP 비교 (0) | 2026.02.08 |
|---|---|
| API란 무엇인가? REST API 개념 정리 (1) | 2026.02.06 |
| 프론트엔드 vs 백엔드 차이 한눈에 이해하기 (1) | 2026.02.05 |
| 개발자와 비개발자의 차이, 하는 일 정리 (0) | 2026.02.04 |
| IT 회사에서 자주 쓰는 용어 정리 (신입 필수) (1) | 2026.02.03 |
