전산학 서버와 클라이언트 구조: 요청과 응답으로 이루어진 서비스의 기본 패턴

“서버가 다운됐다”라는 말의 정확한 의미를 이해해야 한다

일상에서 “서버가 터졌다”, “서버가 느리다”, “서버 문제다”라는 말을 자주 듣는다. 그러나 전산학 관점에서 서버(server)라는 단어는 단순히 성능이 좋은 컴퓨터를 뜻하지 않는다. 서버는 요청(request)을 받아 처리하고 응답(response)을 돌려주는 역할을 수행하는 프로그램 또는 시스템을 의미한다. 반대로 클라이언트(client)는 서비스를 이용하기 위해 요청을 보내는 쪽이다.
이 구조를 이해하면 웹사이트 접속 오류, 앱 로그인 실패, 결제 지연 같은 문제를 “감”이 아니라 “구조”로 해석할 수 있다. 또한 서비스가 커질수록 왜 캐시, 로드 밸런서, 데이터베이스 분리 같은 설계가 필요해지는지도 자연스럽게 연결된다.
이 글은 서버와 클라이언트, 요청과 응답, HTTP, API, 상태(stateless/stateful) 같은 핵심 키워드를 중심으로 서버-클라이언트 구조의 기본 패턴을 정리한다.

 

전산학 서버-클라이언트의 개념과 요청-응답의 기본 원리

1) 서버와 클라이언트란 무엇인가: 역할(role)로 구분한다

서버와 클라이언트는 하드웨어 종류가 아니라 “역할”이다.

• 클라이언트(client): 사용자 입장에서 서비스를 이용하기 위해 요청을 보내는 주체다. 예: 웹 브라우저, 모바일 앱, PC 프로그램.
• 서버(server): 요청을 받아 필요한 처리를 수행하고 응답을 보내는 주체다. 예: 웹 서버, API 서버, 파일 서버.

같은 컴퓨터라도 상황에 따라 서버가 될 수도, 클라이언트가 될 수도 있다. 예를 들어 PC가 프린터에 인쇄 데이터를 보내면 PC는 클라이언트, 프린터(또는 프린터 서버)는 서버 역할을 수행한다.

2) 요청(request)과 응답(response): 서비스의 가장 기본 단위

대부분의 온라인 서비스는 요청과 응답으로 동작한다.

1. 클라이언트가 요청을 보낸다(예: “로그인”, “상품 목록 조회”, “결제 승인”).
2. 서버가 요청을 해석하고 처리한다(인증, 권한 확인, 데이터 조회, 계산).
3. 서버가 결과를 응답으로 돌려준다(성공/실패, 데이터, 오류 코드).

이 패턴이 단순해 보이지만, 실제로는 요청이 서버 내부의 여러 구성요소를 거치며 처리된다. 서버는 종종 데이터베이스, 캐시, 외부 결제 API 같은 다른 서버들에게 다시 “클라이언트”로서 요청을 보내기도 한다.

3) HTTP는 요청-응답 패턴을 표준화한 규칙이다

웹에서 가장 흔히 쓰는 요청-응답 규칙이 HTTP다. 브라우저가 서버에 요청을 보내고, 서버가 HTML이나 JSON 같은 응답을 돌려준다. HTTP에서는 다음 요소가 중요하다.

• 메서드(Method): GET(조회), POST(생성/전송), PUT/PATCH(수정), DELETE(삭제)
• URL(경로): 어떤 자원을 요청하는지
• 헤더(Header): 인증 정보, 콘텐츠 타입, 캐시 정책 등 부가 정보
• 바디(Body): 전송할 데이터(로그인 정보, 폼 데이터 등)
• 상태 코드(Status Code): 200(성공), 401(인증 필요), 403(권한 없음), 404(없음), 500(서버 오류) 등

사용자는 “페이지가 안 열린다”라고 말하지만, 서버는 보통 상태 코드로 “왜 안 되는지”를 표현한다. 이 개념을 알면 문제를 더 정확히 설명할 수 있다.

4) API란 무엇인가: 클라이언트를 위한 “요청 규격”이다

API(Application Programming Interface)는 서버가 제공하는 기능을 클라이언트가 사용할 수 있도록 정해둔 규격이다. 모바일 앱이 서버에 로그인 요청을 보내고, 서버가 토큰을 응답으로 주는 방식이 API로 구현된다.
API가 중요한 이유는 서비스가 커질수록 “브라우저뿐 아니라 앱, 파트너 시스템, 내부 도구”까지 여러 클라이언트가 같은 서버 기능을 공유하게 되기 때문이다. 이때 API 규격이 명확해야 확장과 유지보수가 쉬워진다.

 

서버-클라이언트 요청·응답 흐름(브라우저/앱 → API 서버 → DB)

5) 상태(stateless)와 상태 유지(stateful): 서버 설계에 큰 영향을 준다

서버가 요청을 처리할 때 “이 사용자가 이전에 무엇을 했는지”를 기억해야 하는 경우가 있다. 예를 들어 로그인 상태, 장바구니, 제 진행 상태 같은 정보다.
하지만 HTTP 자체는 무상태(stateless) 구조에 가깝다. 그래서 상태를 유지하려면 별도 메커니즘이 필요하다.

• 세션 기반: 서버가 상태를 저장하고, 클라이언트는 세션 ID를 쿠키로 전달한다.
• 토큰 기반: 클라이언트가 토큰을 들고 다니며 요청마다 인증 정보를 제공한다.

이 차이는 서버 확장 방식(서버를 여러 대로 늘릴 때)과 보안 정책에 직접 영향을 준다.

6) 서버는 보통 “하나”가 아니다: 역할 분리가 기본이다

현대 서비스에서 서버는 보통 여러 역할로 나뉜다.

• 웹 서버(정적 파일 제공, TLS 종료, 프록시)
• 애플리케이션 서버(비즈니스 로직 처리)
• 데이터베이스 서버(데이터 저장/조회)
• 캐시 서버(자주 쓰는 데이터 빠른 제공)
• 파일/이미지 서버, 메시지 큐, 검색 서버 등

사용자가 보는 “하나의 서비스”는 실제로 여러 서버가 협업한 결과다. 그래서 서버 장애는 단순히 컴퓨터 한 대가 고장 난 것뿐 아니라, 내부 구성요소 중 하나가 병목이 된 상황일 수도 있다.

 

전산학 실제 사례로 이해하는 서버-클라이언트 구조와 문제 해결

1) 사례 1: “인터넷은 되는데 특정 사이트만 안 된다”

이 경우 클라이언트(내 PC/폰)나 내 회선 문제일 수도 있지만, 서버 측 문제일 가능성도 있다. 서버-클라이언트 관점에서 보면 점검 순서가 명확해진다.

• 다른 사이트는 정상: 클라이언트와 인터넷 회선은 대체로 정상일 가능성이 높다.
• 특정 사이트만 장애: 그 사이트 서버 또는 중간 경로(DNS, CDN, 방화벽) 문제일 수 있다.
• 여러 기기에서 동일: 서버/서비스 쪽 문제일 확률이 더 올라간다.

즉, “서버 문제”라는 말은 “요청은 갔지만 응답이 정상적으로 오지 않는다” 또는 “응답이 오류 코드로 온다”로 구체화된다.

2) 사례 2: 로그인은 되는데 결제가 실패한다

로그인 서버와 결제 서버(또는 결제 모듈)는 내부적으로 분리되어 있는 경우가 많다. 로그인은 성공했지만 결제가 실패한다면, 서버 내부에서 결제 관련 구성요소가 장애를 겪고 있을 수 있다.

• 외부 결제 API 지연 또는 실패
• 내부 주문 데이터베이스 오류
• 재고 확인 로직 오류
• 인증 토큰 만료 또는 권한 오류

클라이언트 입장에서는 “앱이 이상하다”로 보이지만, 서버 입장에서는 “특정 요청 경로만 실패한다”로 분류된다. 이때 서버 로그나 상태 코드, 오류 메시지가 문제 해결의 단서가 된다.

 

장애 원인 분해(클라이언트·네트워크·서버·DB)와 점검 순서

3) 사례 3: 앱은 느린데 웹은 빠르다

같은 서비스라도 웹과 앱이 사용하는 API가 다를 수 있다. 또한 앱은 추가 인증 과정, 더 많은 데이터 요청, 이미지 최적화 방식 차이로 인해 느려질 수 있다.
이때 서버-클라이언트 구조로 보면 “클라이언트가 무엇을 요청했고, 서버가 무엇을 응답했는지”가 핵심이다. 즉, 느린 원인은 서버가 아니라 “앱이 요청을 과도하게 보내는 구조”일 수도 있다.

4) 서비스가 커지면 왜 로드 밸런서가 필요한가

사용자가 늘어나면 요청 수가 증가하고, 서버 한 대가 처리할 수 있는 한계를 넘는다. 이때 서버를 여러 대로 늘리고, 요청을 분산시키는 장치가 로드 밸런서(load balancer)다.
로드 밸런서는 클라이언트의 요청을 여러 서버로 나눠 보내 서비스 전체의 처리량과 안정성을 높인다. 사용자는 서버가 여러 대인지 모르지만, 요청-응답 흐름 중간에 분산 계층이 추가된 것이다.

5) 일반 사용자가 알아두면 좋은 실전 관점 3가지

서버-클라이언트 구조를 알고 있으면, 사용자도 문제 상황을 더 정확히 파악할 수 있다.

1. “내 기기 문제”와 “서버 문제”를 분리할 수 있다(다른 기기/다른 네트워크로 비교).
2. “전체 서비스 장애”와 “특정 기능 장애”를 구분할 수 있다(로그인/검색/결제 중 어디가 실패하는지).
3. 오류 메시지와 상태 코드를 무시하지 않게 된다(401, 403, 500 등은 원인 힌트다).

이 지식은 개발자가 아니더라도, 고객 지원 문의나 업무 시스템 장애 대응에서 큰 도움이 된다.

---

전산학 서버-클라이언트 구조는 거의 모든 온라인 서비스의 기본 골격이다

서버와 클라이언트는 장치 종류가 아니라 역할이며, 온라인 서비스는 요청과 응답의 반복으로 동작한다. HTTP는 이 요청-응답을 표준화한 규칙이고, API는 여러 클라이언트가 서버 기능을 일관되게 이용하도록 만든 규격이다. 서비스가 커질수록 서버는 웹/앱/DB/캐시 등으로 역할이 분리되고, 로드 밸런서 같은 분산 구조가 추가된다.
문제 해결 관점에서는 “무엇을 요청했는지”와 “어떤 응답이 왔는지”를 기준으로, 클라이언트·네트워크·서버·데이터베이스 중 어디에서 병목이 생겼는지 범위를 좁히는 것이 핵심이다.

다음으로 이어서 보면 좋은 주제는 두 가지다. 첫째, REST API와 HTTP 메서드/상태 코드가 서비스 설계에 어떻게 쓰이는지에 대한 정리다. 둘째, 캐시(Cache)와 CDN이 요청-응답 구조에서 왜 성능을 크게 바꾸는지에 대한 설명이다.