클라이언트-서버 구조
단독 실행형(Standalone)은 UI·로직·데이터가 한 컴퓨터에 있습니다. 단순하고 오프라인에서도 동작하지만, 복사본마다 데이터가 따로 놀고 기능을 바꾸려면 모든 사용자가 다시 설치해야 합니다.
데이터 공유, 중앙 관리, 일괄 업데이트가 필요해지면서 요청하는 쪽(Client)과 제공하는 쪽(Server)을 분리했습니다.
- 성립 조건: 항상 켜져 있음 · 찾을 수 있는 주소(IP, 도메인) · 약속된 프로토콜(HTTP 등)
- 대화는 항상 클라이언트가 시작합니다. 서버가 먼저 보내려면 WebSocket, SSE, 푸시 알림이 필요합니다.
- HTTP는 무상태(stateless)입니다. 서버는 이전 요청을 기억하지 않으므로 로그인 상태는 세션·쿠키·토큰(JWT)으로 유지합니다.
Connection: close를 명시해야 끊습니다.식당의 손님과 주방
손님(클라이언트)이 주문서를 내면 주방(서버)이 음식을 만들어 줘요. 주방은 손님이 부르기 전에는 먼저 음식을 가져다주지 않아요.
혼자 집에서 요리하던 때(단독 실행형)는 친구와 같은 요리를 나눠 먹을 수 없었어요. 그래서 모두가 찾아올 수 있는 식당을 만든 거예요.
주방은 손님 얼굴을 기억하지 못해요(무상태). 그래서 올 때마다 번호표(쿠키·토큰)를 보여줘야 해요.
- 손님→브라우저, 앱
- 주문서→HTTP 요청
- 식당 주소→도메인, IP
- 식당 안 약속(메뉴판)→프로토콜
- 번호표→세션, 토큰
브라우저에서 https://blog.example.com/posts/1을 열 때:
- DNS 조회 →
blog.example.com의 IP 획득 - TCP 3-way handshake (SYN → SYN-ACK → ACK) + TLS handshake
GET /posts/1 HTTP/1.1전송- 서버: 라우팅 → 인증/인가 → 비즈니스 로직 → DB 조회
200 OK+{"id":1,"title":"..."}- 연결 유지(keep-alive) 또는 종료
- 웹·모바일 앱 백엔드의 REST API (Spring Boot, Express, FastAPI)
- 서버 → 클라이언트 실시간 전송: 채팅은 WebSocket, 알림·LLM 응답 스트리밍은 SSE, 앱 푸시는 FCM/APNs