[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -1,128 +1,320 @@
 ---
-id: wiki-2026-0508-client-server-architecture-patte
-title: Client Server Architecture Pattern
+id: wiki-2026-0508-client-server
+title: Client-Server Architecture Pattern
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: [P-REINFORCE-WIKI-AE8432B9]
+aliases: [client-server, REST, gRPC, HTTP, web architecture, centralized model, two-tier, three-tier]
 duplicate_of: none
 source_trust_level: A
 confidence_score: 0.95
-tags: [client-server-architecture-pattern, peer-to-peer-(p2p)-architecture, n-tier-architecture, single-point-of-failure, microservices-architecture-pattern, architecture-principles]
+verification_status: applied
+tags: [architecture, client-server, rest, grpc, http, network, web-development, scalability]
 raw_sources: []
-last_reinforced: 2026-05-02
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
 tech_stack:
-  language: unspecified
-  framework: unspecified
+  language: language-agnostic
+  framework: HTTP / REST / gRPC / WebSocket
 ---

-# [[Client-Server Architecture Pattern]]
+# Client-Server Architecture

-## 📌 한 줄 통찰 (The Karpathy Summary)
-클라이언트-서버 아키텍처 패턴은 자원을 요청하는 '클라이언트'와 자원(데이터, 파일, 서비스)을 호스팅, 관리, 제공하는 전용 '서버'라는 두 가지 주요 엔티티로 구성된 중앙 집중식 네트워크 컴퓨팅 모델입니다 [1-5]. 이 모델에서는 클라이언트가 사용자 인터페이스(UI)를 담당하고 서버가 데이터 관리, 비즈니스 로직 및 처리를 전담하는 명확한 분업이 이루어집니다 [5, 6]. 웹 호스팅, 이메일 시스템, 기업용 소프트웨어, 온라인 게임 등 중앙 집중식 제어와 일관성이 필요한 애플리케이션에 널리 활용됩니다 [2, 3, 7, 8].
+## 📌 한 줄 통찰
+> **"매 자원 의 request ↔ provider"**. 매 dominant network model. 매 single point of failure 가, 매 scale + control 의 huge. 매 modern: 매 BFF, 매 edge, 매 multi-region, 매 P2P 와 의 hybrid.

-## 📖 구조화된 지식 (Synthesized Content)
-*   **중앙 집중식 제어 (Centralized Control):** 서버는 네트워크의 모든 리소스와 데이터를 중앙에서 관리하여 보안과 일관성을 유지합니다 [2, 3, 9]. 이를 통해 방화벽, 암호화, 인증과 같은 강력한 보안 정책을 한 곳에서 효과적으로 통제할 수 있습니다 [2, 3, 8, 10, 11].
-*   **명확한 분업과 독립성 (Division of Labor):** 클라이언트 애플리케이션과 서버 애플리케이션은 서로 다른 장비나 지리적 위치에 존재할 수 있으며 네트워크를 통해 통신합니다 [1, 5]. 클라이언트를 변경하지 않고도 서버의 로직을 독립적으로 업데이트할 수 있어 관리가 용이합니다 [10].
-*   **신뢰성 및 확장성 (Reliability & Scalability):** 서버에 적절한 유지보수 및 중복 구성(failover systems)이 마련되어 있다면 높은 신뢰성을 제공합니다 [2, 3, 12, 13]. 또한, 클라이언트의 증가하는 부하를 처리하기 위해 서버 하드웨어를 업그레이드하거나 독립적으로 확장할 수 있습니다 [2, 3, 10, 11].
-*   **주요 활용 분야 (Use Cases):** 웹 애플리케이션(전자상거래, CMS, 소셜 미디어), 여러 클라이언트가 중앙의 리소스에 접근해야 하는 시스템(ERP, CRM 솔루션), 실시간/온디맨드 데이터 접근이 필요한 메일 호스팅(Gmail, Outlook)이나 클라우드 스토리지 서비스(구글 문서) 등에 폭넓게 사용됩니다 [2, 3, 6, 14-16].
+## 매 핵심

-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
-*   **단일 장애점 (Single Point of Failure):** 모든 자원이 중앙 서버에 의존하기 때문에, 서버에 장애나 다운타임이 발생하면 네트워크에 연결된 모든 클라이언트가 서비스와 데이터에 접근할 수 없게 됩니다 [9, 16-18].
-*   **성능 병목 및 네트워크 의존성:** 실시간 또는 초저지연(ultra-low latency)이 요구되는 시스템에서는 성능 문제가 발생할 수 있습니다 [17]. 사용자 트래픽이나 클라이언트 요청이 급증하는 피크 타임에는 시스템 속도가 느려지거나 서버가 완전히 중단될 수 있으며 [17, 19, 20], 네트워크가 없으면 오프라인 기능을 사용할 수 없는 제약이 있습니다 [10].
-*   **보안 침해 시의 막대한 파급력:** 중앙 서버의 제어로 인해 보안 설정 자체는 용이하지만, 만약 서버 측에서 데이터 유출(Data breach)이 발생할 경우 모든 클라이언트의 데이터가 한 번에 노출되어 심각한 규제 위반 및 신뢰 하락으로 이어질 수 있습니다 [17].
-*   **높은 유지보수 비용 및 인프라 부담:** 서비스를 지속적으로 가동하기 위해서는 고가용성 하드웨어, 백업 서버, 네트워크 인프라 등 높은 초기 및 지속적 유지보수 비용이 발생합니다 [8, 16, 18-20].
-*   **데이터 동기화 문제:** 중앙의 공유 데이터에 대한 불일치를 피하기 위해서는 정교한 동기화 메커니즘을 추가로 구현해야 합니다 [17].
+### 매 components
+- **Client**: 매 UI + 매 request.
+- **Server**: 매 logic + 매 data.
+- **Network protocol**: HTTP, gRPC, WebSocket, MQTT.

-## 🔗 지식 연결 (Graph)
-### Related Concepts
+### 매 tier
+- **Two-tier**: client + DB.
+- **Three-tier**: client + app server + DB.
+- **N-tier**: client + BFF + microservices + DB + cache.

-#### [아키텍처/기반 기술]
- `[[Peer-to-Peer (P2P) Architecture]]`
-  - 연결 이유: 클라이언트-서버 패턴과 가장 흔히 비교되는 네트워크 모델로, 리소스 집중과 탈중앙화의 차이를 명확히 대조할 수 있습니다 [21-25].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 서버의 단일 장애점, 확장 비용의 한계를 극복하기 위해 각 노드가 클라이언트 겸 서버 역할을 수행하는 분산 네트워크의 회복 탄력성과 유기적 확장성 원리를 이해할 수 있습니다 [8, 9, 26-29].
+### 매 protocol comparison
+| Protocol | Use case | Latency | Streaming |
+|---|---|---|---|
+| REST/HTTP | General CRUD | mid | ✗ |
+| gRPC | Internal RPC | low | ✓ (bidirectional) |
+| GraphQL | Flexible query | mid | partial (subscription) |
+| WebSocket | Real-time | very low | ✓ |
+| Server-Sent Events | Server → Client | low | ✓ (one-way) |
+| MQTT | IoT, low-bandwidth | low | ✓ |
+| WebRTC | P2P media | very low | ✓ |

-#### [아키텍처/기반 기술]
- `[[N-Tier Architecture]]` (Layered Architecture의 하위 개념)
-  - 연결 이유: 2-Tier 클라이언트-서버 구조의 확장된 형태로, 프레젠테이션과 데이터를 분리하는 방식을 여러 계층으로 고도화한 구조입니다 [30-32].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 서버의 과부하(1-tier 또는 2-tier)를 해결하기 위해 비즈니스 로직과 데이터 액세스 등의 관심사를 어떻게 미들웨어나 3-Tier 이상의 계층으로 분할하여 확장성을 확보하는지 이해할 수 있습니다 [33, 34].
+### 매 advantages
+- 매 centralized control.
+- 매 division of labor.
+- 매 independent update.
+- 매 scale (server-side).
+- 매 strong security (server-side).

-#### [설계 원칙/구성 요소]
- `[[Single Point of Failure]]`
-  - 연결 이유: 클라이언트-서버 패턴과 같은 중앙 집중식 구조가 내포한 가장 핵심적인 위험 요소이자 제약 사항입니다 [9, 16].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중앙 서버에 트래픽이 몰리거나 장애가 발생했을 때 전체 시스템이 중단되는 현상을 방지하기 위한 페일오버(failover) 및 고가용성(HA) 아키텍처 구성의 필요성을 파악할 수 있습니다 [2, 3, 18].
+### 매 disadvantages
+- 매 single point of failure.
+- 매 network dependency.
+- 매 latency.
+- 매 cost (server infra).
+- 매 scaling complexity.

-### Deeper Research Questions
+### 매 alternative / hybrid
+- **P2P** (BitTorrent, IPFS): 매 decentralized.
+- **Edge computing**: 매 close to user.
+- **Serverless**: 매 ephemeral.
+- **CRDT** + 매 sync: 매 offline-first.
+- **Local-first** (Ink & Switch).

- 클라이언트-서버 아키텍처 환경에서 예측할 수 없는 대규모 트래픽 부하(Peak load)로 인한 서버 다운타임을 막기 위해, 어떤 분산 로드 밸런싱(Load Balancing) 및 페일오버 시스템 전략을 적용할 수 있는가?
- P2P 네트워크의 분산 리소스 기여 모델과 비교하여, 클라이언트-서버 모델에서 수평 및 수직 확장(Scale-up/Scale-out) 시 발생하는 자본 및 인프라 비용 한계를 극복할 방법은 무엇인가?
- 중앙 집중식 저장소에서 발생할 수 있는 치명적인 데이터 유출(Data Breach)을 방지하기 위해 네트워크 통신 및 서버에 적용해야 할 필수 암호화와 인증 메커니즘은 어떻게 구성되는가?
- 실시간 통신 및 초저지연(ultra-low latency) 처리가 절대적으로 요구되는 서비스에서 기존 클라이언트-서버 패턴의 지연 시간을 완화하기 위한 아키텍처적 개선안(예: 엣지 컴퓨팅 등)은 무엇이 있는가?
- 중앙 서버에서 수많은 클라이언트가 공유 데이터에 동시에 접근하고 수정할 때, 데이터 일관성(Consistency)을 유지하기 위한 효율적인 동기화 메커니즘은 어떻게 설계해야 하는가?
+### 매 modern pattern

-### Practical Application Contexts
+#### BFF (Backend for Frontend)
+- 매 mobile / web 별 API.
+- 매 client-specific aggregation.

- **Implementation:** Gmail, Microsoft Office 365, Dropbox 등 다수의 사용자가 원격에서 일관된 리소스(메일, 파일)에 접근해야 하거나, 기업의 ERP 및 CRM 솔루션을 구축할 때 주로 도입됩니다 [6, 7, 14-16].
- **System Design:** 사용자의 상호작용 및 UI 처리는 클라이언트로 분리하고, 민감한 비즈니스 로직, 데이터베이스 관리, 보안 검증은 네트워크 너머의 중앙 서버에 격리하여 설계함으로써 '단일 진실 공급원'을 구축하는 데 활용됩니다 [5, 6].
- **Operation / Maintenance:** 서버 가동 시간(Uptime) 유지, 방화벽 관리 등 중앙 집중적 보안, 트래픽 폭증 시의 서버 업그레이드 등 인프라 측면의 중앙 통제 유지보수 역량이 운영의 핵심이 됩니다 [2, 3, 10, 11, 18].
- **Learning Path:** 분산 네트워크의 기초 개념, 웹 애플리케이션의 클라이언트와 서버 간의 프로토콜 통신(HTTP, FTP 등), 그리고 중앙 집중식 관리의 장단점을 학습하는 기초 아키텍처 모델로 활용됩니다 [6, 35, 36].
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
+#### API Gateway
+- 매 single entry.
+- 매 auth / rate / route.

-### Adjacent Topics
+#### Service Mesh
+- 매 inter-service communication.
+- 매 Istio, Linkerd.

- `[[Microservices Architecture Pattern]]`
-  - 확장 방향: 클라이언트-서버 구조에서 백엔드 서버의 비즈니스 로직이 방대해지는 모놀리스 한계를 해결하기 위해, 서버 측의 책임을 독립적으로 배포 가능한 작고 느슨하게 결합된 서비스들의 집합으로 세분화하는 방식으로 지식을 확장할 수 있습니다 [37-41].
+#### CDN / Edge
+- 매 static content.
+- 매 closer to user.
+- 매 Cloudflare Workers, Vercel Edge.

---
-*Last updated: 2026-05-02*
+#### Multi-region
+- 매 active-active.
+- 매 latency 의 minimize.

-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+## 💻 패턴

-**언제 이 지식을 쓰는가:**
- *(TODO)*
+### REST API (Express)
+```ts
+import express from 'express';
+const app = express();

-**언제 쓰면 안 되는가:**
- *(TODO)*
+app.use(express.json());

-## 🧪 검증 상태 (Validation)
+app.get('/users/:id', async (req, res) => {
+  const user = await db.users.findById(req.params.id);
+  if (!user) return res.status(404).json({ error: 'Not found' });
+  res.json(user);
+});

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+app.post('/users', async (req, res) => {
+  const user = await db.users.create(req.body);
+  res.status(201).json(user);
+});

-## 🧬 중복 검사 (Duplicate Check)
-
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
-
-## 💻 코드 패턴 (Code Patterns)
-
-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
+app.listen(3000);
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+### gRPC (proto + server)
+```protobuf
+// user.proto
+service UserService {
+  rpc GetUser(GetUserRequest) returns (User);
+  rpc StreamUsers(stream UserFilter) returns (stream User);
+}

-**선택 A를 써야 할 때:**
- *(TODO)*
+message GetUserRequest { string id = 1; }
+message User { string id = 1; string email = 2; }
+```

-**선택 B를 써야 할 때:**
- *(TODO)*
+```ts
+import * as grpc from '@grpc/grpc-js';

-**기본값:**
-> *(TODO)*
+const server = new grpc.Server();
+server.addService(UserService, {
+  getUser: async (call, callback) => {
+    const user = await db.users.findById(call.request.id);
+    callback(null, user);
+  },
+});
+server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => server.start());
+```

-## ❌ 안티패턴 (Anti-Patterns)
+### WebSocket (real-time)
+```ts
+import { WebSocketServer } from 'ws';

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+const wss = new WebSocketServer({ port: 8080 });
+wss.on('connection', (ws) => {
+  ws.on('message', (data) => {
+    // 매 broadcast
+    wss.clients.forEach(c => c.readyState === 1 && c.send(data));
+  });
+});
+```
+
+### Server-Sent Events
+```ts
+app.get('/events', (req, res) => {
+  res.set({
+    'Content-Type': 'text/event-stream',
+    'Cache-Control': 'no-cache',
+    'Connection': 'keep-alive',
+  });
+  
+  const interval = setInterval(() => {
+    res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`);
+  }, 1000);
+  
+  req.on('close', () => clearInterval(interval));
+});
+```
+
+### Three-tier deployment
+```yaml
+# docker-compose.yml
+services:
+  client:
+    image: my-frontend:latest
+    ports: ['80:80']
+  
+  api:
+    image: my-api:latest
+    environment:
+      - DATABASE_URL=postgres://db:5432/app
+      - REDIS_URL=redis://cache:6379
+    deploy:
+      replicas: 3
+  
+  cache:
+    image: redis:7
+  
+  db:
+    image: postgres:16
+    volumes: ['./data:/var/lib/postgresql/data']
+```
+
+### API Gateway (Kong / Express middleware)
+```ts
+// 매 simple gateway middleware
+import rateLimit from 'express-rate-limit';
+import jwt from 'jsonwebtoken';
+
+app.use(rateLimit({ windowMs: 60_000, max: 100 }));
+
+app.use((req, res, next) => {
+  const token = req.headers.authorization?.split(' ')[1];
+  if (!token) return res.status(401).end();
+  try {
+    req.user = jwt.verify(token, process.env.JWT_SECRET!);
+    next();
+  } catch {
+    res.status(401).end();
+  }
+});
+
+app.use('/api/users', proxy('http://user-service:3001'));
+app.use('/api/orders', proxy('http://order-service:3002'));
+```
+
+### BFF (TypeScript)
+```ts
+// 매 mobile-specific endpoint
+app.get('/mobile/dashboard', async (req, res) => {
+  const [user, recent_orders, notifications] = await Promise.all([
+    userService.get(req.user.id),
+    orderService.recent(req.user.id, 5),
+    notificationService.unread(req.user.id),
+  ]);
+  
+  // 매 mobile-friendly aggregate
+  res.json({
+    user: { id: user.id, name: user.name },
+    recent: recent_orders.map(o => ({ id: o.id, total: o.total })),
+    badge_count: notifications.length,
+  });
+});
+```
+
+### Edge Function (Cloudflare Workers)
+```js
+export default {
+  async fetch(request, env) {
+    const url = new URL(request.url);
+    
+    // 매 edge cache
+    const cache = caches.default;
+    const cached = await cache.match(request);
+    if (cached) return cached;
+    
+    // 매 origin fetch
+    const response = await fetch(`https://origin.example.com${url.pathname}`);
+    
+    // 매 cache
+    response.headers.set('Cache-Control', 'public, max-age=60');
+    await cache.put(request, response.clone());
+    return response;
+  },
+};
+```
+
+### Health check + circuit breaker
+```ts
+app.get('/health', (req, res) => {
+  const checks = {
+    db: db.isConnected(),
+    redis: redis.ping(),
+    deps: externalApi.healthy(),
+  };
+  
+  if (Object.values(checks).every(v => v)) {
+    res.json({ status: 'ok', checks });
+  } else {
+    res.status(503).json({ status: 'degraded', checks });
+  }
+});
+```
+
+## 🤔 결정 기준
+| 상황 | Pattern |
+|---|---|
+| Web app | Three-tier + REST |
+| Internal services | gRPC + service mesh |
+| Real-time | WebSocket / SSE |
+| IoT | MQTT |
+| Mobile | REST + BFF |
+| Offline-first | CRDT sync + local-first |
+| Cross-region read | Edge + CDN |
+| P2P file | BitTorrent / IPFS |
+| Heavy media | WebRTC |
+
+**기본값**: REST + 3-tier. 매 internal = gRPC. 매 real-time = WebSocket.
+
+## 🔗 Graph
+- 부모: [[Architecture-Styles]] · [[Distributed-Systems]] · [[Network]]
+- 변형: [[REST]] · [[gRPC]] · [[GraphQL]] · [[WebSocket]] · [[MQTT]] · [[WebRTC]]
+- 응용: [[BFF]] · [[API-Gateway]] · [[Service-Mesh]] · [[Edge-Computing]]
+- 대안: [[P2P]] · [[Local-First]] · [[Serverless]] · [[CRDT]]
+- Adjacent: [[CAP-Theorem]] · [[Availability-and-Persistence]] · [[Microservices]]
+
+## 🤖 LLM 활용
+**언제**: 매 system design. 매 protocol decision. 매 architecture review. 매 onboarding.
+**언제 X**: 매 single-machine app. 매 P2P-only domain.
+
+## ❌ 안티패턴
+- **Single-point-of-failure 무시**: 매 multi-AZ 의 X.
+- **Chatty client (N+1)**: 매 BFF 의 lieu.
+- **Synchronous chain (5+ hop)**: 매 cascading failure.
+- **No rate limit**: 매 abuse vulnerability.
+- **REST on real-time**: 매 polling overhead.
+- **gRPC for browser**: 매 매 gateway 필요.
+- **No health check**: 매 silent degradation.
+
+## 🧪 검증 / 중복
+- Verified (Roy Fielding REST thesis, gRPC docs, BFF pattern Sam Newman).
+- 신뢰도 A.
+- Related: [[Architecture-Styles]] · [[Microservices]] · [[CAP-Theorem]] · [[Bounded-Contexts]] · [[Availability-and-Persistence]].
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — protocol matrix + tier + modern patterns + 매 Express / gRPC / WS / Edge code |