chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,118 @@
|
||||
---
|
||||
id: "wiki-2026-0507-104"
|
||||
title: "백엔드_엔지니어링_및_데이터베이스_설계"
|
||||
category: "[[10_Wiki/Topics]]"
|
||||
status: "verified"
|
||||
canonical_id: "self"
|
||||
aliases: ["Backend Engineering", "Database Design", "API Design", "Node.js", "SQL", "NoSQL", "System Design", "백엔드", "데이터베이스"]
|
||||
duplicate_of: "none"
|
||||
source_trust_level: "A"
|
||||
confidence_score: 1.0
|
||||
tags: ["Backend", "Database", "Node.js", "API", "System Design"]
|
||||
raw_sources: ["Backend.md", "API_Communication_Patterns.md", "Relational-Database.md", "Query-Optimization.md", "NestJS_Microservices.md"]
|
||||
last_reinforced: "2026-05-07"
|
||||
github_commit: "pending"
|
||||
---
|
||||
|
||||
# 백엔드_엔지니어링_및_데이터베이스_설계
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터는 흐르고 시스템은 응답한다." 비즈니스 로직의 안정적인 실행 환경을 구축하고, 대규모 데이터의 영속성과 정합성을 보장하며, 고성능 통신 프로토콜을 통해 클라이언트와 에이전트의 요청을 처리하는 시스템의 심장부.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> 현대적 백엔드는 **'계층화된 아키텍처'**와 **'다중 저장소 전략(Polyglot Persistence)'**을 통해 확장성을 확보한다. API 설계는 단순한 데이터 전달을 넘어 보안, 속도 제한(Rate Limiting), 그리고 관측 가능성(Observability)을 포함하는 종합적인 관문으로 진화했다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. API 아키텍처 및 통신 패턴
|
||||
- **REST (Representational State Transfer):** 자원 중심의 표준 인터페이스. 무상태성(Stateless)을 통한 확장성 확보.
|
||||
- **GraphQL:** 클라이언트가 필요한 데이터만 요청할 수 있는 유연한 쿼리 언어. Over-fetching 방지.
|
||||
- **gRPC:** HTTP/2 기반의 고성능 바이너리 통신. 서비스 간 통신(Internal)에 최적.
|
||||
- **비동기 통신:** Message Broker (Kafka, RabbitMQ)를 활용한 이벤트 기반 아키텍처로 서비스 간 결합도 완화.
|
||||
|
||||
### 2. 데이터베이스 설계 및 최적화
|
||||
- **관계형 DB (RDBMS):** 엄격한 스키마와 ACID 트랜잭션 보장. 복잡한 조인과 정합성이 중요한 데이터에 적합.
|
||||
- **NoSQL:**
|
||||
- **Document (MongoDB):** 유연한 데이터 구조, 빠른 개발 속도.
|
||||
- **Key-Value (Redis):** 인메모리 처리로 초저지연 캐싱 및 상태 저장.
|
||||
- **Graph (Neo4j):** 복잡한 관계 중심 데이터 탐색에 특화.
|
||||
- **성능 최적화 기술:**
|
||||
- **인덱싱 전략:** B-Tree, Hash, GIN 등 접근 패턴에 맞는 인덱스 설계.
|
||||
- **샤딩 및 파티셔닝:** 데이터를 물리적으로 분산하여 부하 분산 및 쿼리 성능 향상.
|
||||
|
||||
### 3. Node.js 기반 백엔드 마스터리
|
||||
- **이벤트 루프 (Event Loop):** 싱글 스레드 논블로킹 I/O 모델의 핵심. CPU 집약적인 작업은 Worker Threads로 분리.
|
||||
- **메모리 관리:** V8 엔진의 힙(Heap) 구조와 가비지 컬렉션(GC) 메커니즘을 이해하여 메모리 누수 방지.
|
||||
- **미들웨어 및 인터셉터:** 요청/응답 파이프라인에서 공통 관심사(로깅, 보안, 변환)를 캡슐화.
|
||||
|
||||
### 4. 엔터프라이즈 데이터 패턴
|
||||
- **DTO (Data Transfer Object):** 계층 간 데이터 전송을 위한 객체. 도메인 엔티티를 외부 노출로부터 보호.
|
||||
- **Repository Pattern:** 데이터 접근 로직을 캡슐화하여 비즈니스 로직과 영속성 계층을 분리.
|
||||
- **의존성 주입 (DI):** 객체 생성을 외부에서 관리하여 테스트 용이성 및 결합도 완화.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 데이터 정합성과 성능 사이의 트레이드오프를 결정해야 하는 데이터베이스 스키마 설계 시.
|
||||
- 서비스 간의 통신 방식(HTTP vs gRPC vs Kafka)을 선택해야 할 때.
|
||||
- 대규모 트래픽 처리를 위한 서버 최적화 및 캐싱 전략 수립 시.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 복잡한 서버 로직이 필요 없는 정적 사이트 호스팅.
|
||||
- 프론트엔드 단독으로 처리 가능한 로컬 애플리케이션.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **요구사항 분석:** 읽기/쓰기 비율, 데이터의 관계 복잡도, 트랜잭션 필요 여부 파악.
|
||||
2. **저장소 선택:** RDBMS, NoSQL, Cache 중 목적에 맞는 저장소 매핑.
|
||||
3. **스키마 설계:** 정규화 또는 역정규화를 결정하고 인덱스 설계.
|
||||
4. **API 정의:** 인터페이스(REST/GraphQL)와 데이터 형식(JSON/Protobuf) 정의.
|
||||
5. **성능 테스트:** 부하 테스트를 통해 병목 지점을 찾고 최적화(Connection Pool, Query Tuning).
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **조급한 최적화 (Premature Optimization):** 초기 단계에서 과도한 샤딩이나 마이크로서비스 분리는 운영 복잡도만 높임.
|
||||
- **분산 트랜잭션의 한계:** CAP 정리(Consistency, Availability, Partition Tolerance)를 이해하고 보상 트랜잭션(Saga) 등의 대안 고려 필요.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** NestJS, Spring, PostgreSQL, MongoDB 등 주요 기술 스택의 공식 문서 및 실전 아키텍처 사례를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** [[Backend]], [[API_Communication_Patterns]], [[Relational-Database]], [[Query-Optimization]], [[Nodejs-Backend-Architecture]] 등 80여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 백엔드와 데이터베이스는 실과 바늘 같은 관계이나 문서가 파편화되어 있음. 이를 시스템적 관점에서 하나의 통합 지침으로 묶어 설계의 일관성을 확보함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **ORM vs SQL:** 과도한 ORM 의존보다는 복잡한 쿼리에서 Raw SQL의 성능 이점을 고려해야 함.
|
||||
- **서버리스의 부상:** 전통적인 상주형 서버에서 이벤트 기반의 서버리스(Lambda, Cloud Functions)로 인프라 비용 최적화 트렌드 반영.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[도메인_주도_설계(DDD)_및_소프트웨어_아키텍처]], [[클라우드_인프라_및_IaC_운영_표준]], [[보안_및_시스템_신뢰성_표준]]
|
||||
- **Raw Source:** Backend 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 80개 이상의 백엔드/DB 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
Reference in New Issue
Block a user