[서술형 준비 자료] 지식 관리 포털

단순히 기술을 나열하는 것이 아니라, '왜(Why)' 이 기술이 지식의 '효과적인 저장 및 활용'에 필수적인지를 서술하는 것이 높은 점수를 받는 핵심입니다.

1. RAG (Retrieval-Augmented Generation)

[활용] 현존하는 지식 관리 시스템의 '활용' 측면에서 가장 강력한 최신 패러다임입니다. 사용자가 자연어 질문을 했을 때, 포탈에 저장된 신뢰할 수 있는 내부 문서(Storage)를 먼저 검색(Retrieval)한 후, 이 정보를 기반으로 LLM(대규모 언어 모델)이 **답변을 생성(Generation)**하도록 하는 기술입니다.

전문가 포인트: "LLM의 환각(Hallucination) 현상을 최소화하고, 조직 내부의 최신 지식에 기반한 정확한 답변을 제공하기 위해 RAG 아키텍처를 도입한다"고 서술하면 최고점입니다.

2. 하이브리드 검색 (Hybrid Search)

[저장 및 활용] 지식 검색의 정확도를 극대화하는 핵심 전략입니다.

키워드 기반 검색 (BM25 등): Elasticsearch 같은 검색 엔진이 수행하는 전통적 방식. 'Spring Boot'라는 정확한 용어 검색에 강합니다.
시맨틱/벡터 검색 (Vector Search): '스프링으로 API 만드는 법'처럼 의미가 유추한 문서를 찾는 방식.

전문가 포인트: "두 방식의 검색 결과를 결합(Re-ranking)하여, 사용자의 명시적 키워드와 암시적 의도를 모두 충족시키는 '하이브리드 검색'을 구현해 검색 품질을 보장한다"고 설명해야 합니다.

3. 벡터 데이터베이스 (Vector Database)

[저장] RAG와 시맨틱 검색을 위한 필수 '저장소'입니다. 지식 문서(텍스트, 이미지 등)를 SBERT 같은 임베딩 모델을 통해 수치화된 벡터(Vector Embedding)로 변환하여 저장하는 DB입니다. (예: Pinecone, Milvus, Weaviate, 또는 Elasticsearch의 벡터 검색 기능)

전문가 포인트: "단순 텍스트 저장이 아닌, '의미의 유사성'을 기준으로 데이터를 빠르게 검색(ANN, 근사 최근접 이웃 탐색)할 수 있도록 벡터 DB에 문서를 임베딩하여 저장한다"고 구체적으로 언급해야 합니다.

4. Elasticsearch (or OpenSearch)

[저장 및 활용] 대용량 비정형 텍스트(지식 문서)를 '저장'하고 '활용(검색)'하는 데 가장 표준적인 솔루션입니다. 단순 DB 검색(LIKE '%...%')과는 비교할 수 없는 강력한 전문(Full-text) 검색, 형태소 분석(한글 처리), 집계(Faceted Search), 관련도 순 랭킹을 제공합니다.

전문가 포인트: "RDBMS에는 문서의 메타데이터(작성자, 태그, 버전)를 저장하고, Elasticsearch에는 문서의 본문(Content)을 색인하여 강력한 전문 검색 및 집계 기능을 구현한다"고 역할 분담을 명시해야 합니다.

5. GraphQL

[활용] 지식 '활용' 시 FE와 BE 간의 데이터 통신 효율을 극대화하는 API Query Language입니다. 지식 포탈은 '문서 + 연관 문서 + 댓글 + 작성자 정보' 등 복잡하게 얽힌 데이터를 한 화면에 보여줘야 합니다.

전문가 포인트: "REST API의 Over/Under-fetching 문제를 해결하기 위해 GraphQL을 도입한다. 이를 통해 클라이언트(React, Mobile)가 필요한 데이터 스키마만 정확하게 요청하여 네트워크 트래픽을 최적화하고 FE 개발 생산성을 높인다"고 서술해야 합니다.

6. MSA (Microservice Architecture)

[저장 및 활용] 대규모 지식 포탈을 위한 아키텍처입니다. '검색 서비스', '문서 관리 서비스', '사용자 인증 서비스', '알림 서비스' 등을 독립적으로 개발/배포/확장할 수 있도록 분리합니다.

전문가 포인트: "장애 격리(Fault Isolation)와 기술 스택의 유연성(Polyglot)을 확보하기 위해 MSA를 채택한다. 예를 들어, 검색 서비스는 Python(AI/ML)으로, 문서 서비스는 Spring Boot(Java)로 구축할 수 있다"고 장점을 명확히 해야 합니다.

7. 이벤트 기반 아키텍처 (EDA) with Kafka

[저장] MSA 환경에서 데이터 동기화(저장) 문제를 해결하는 핵심입니다. 예를 들어, 사용자가 '문서 서비스(Spring Boot)'에 새 문서를 저장(Commit)하면, '문서 생성됨' 이벤트를 Kafka에 발행(Publish)합니다.

전문가 포인트: "이 이벤트를 '검색 서비스'와 '벡터화 서비스'가 구독(Subscribe)하여 **비동기적(Asynchronous)**으로 Elasticsearch 색인과 Vector DB 임베딩을 수행한다. 이를 통해 서비스 간 결합도(Coupling)를 낮추고 시스템의 회복탄력성(Resilience)을 확보한다"고 설명해야 합니다.

8. React Query (TanStack Query)

[활용] React(FE)에서 '서버 상태(Server State)'를 '활용'하는 가장 전문적인 방법입니다. 지식 포탈의 데이터(문서, 댓글 등)는 '클라이언트 상태'가 아닌 '서버 상태'입니다.

전문가 포인트: "Redux/Zustand 같은 클라이언트 상태관리 도구와 구별하여, React Query를 통해 데이터 Caching, Stale-while-revalidate 전략, 비동기 로딩/에러 처리를 선언적으로 관리하여 사용자 경험(UX)과 성능을 최적화한다"고 언급해야 합니다.

9. Next.js (SSR/SSG)

[활용] React 기반 지식 포탈의 '활용' 및 '발견'을 돕는 핵심 프레임워크입니다.

SSR (Server-Side Rendering): 검색 엔진 최적화(SEO)를 통해 포탈 내 지식이 구글 등에서 잘 검색되도록 합니다.
성능: 초기 로딩 속도(TTV)를 개선하여 사용자 경험을 높입니다.

전문가 포인트: "순수 CSR(Client-Side Rendering) 방식의 React 앱이 가지는 SEO 취약점과 초기 로딩 성능 저하 문제를 해결하기 위해 Next.js의 SSR/SSG 방식을 도입한다"고 명시해야 합니다.

10. WYSIWYG Editor (예: Tiptap, Editor.js)

[저장] 지식을 '저장'하는 첫 관문입니다. 단순 textarea가 아닌, 사용자가 쉽게 문서를 작성(이미지, 코드 블록, 표 삽입)할 수 있는 편집기입니다.

전문가 포인트: "특히 Tiptap이나 Editor.js와 같은 Headless/Block-based Editor를 사용한다. 이는 데이터가 HTML이 아닌 JSON 스키마로 저장되어, 향후 Web, Mobile, AI 모델 등 다양한 플랫폼에서 데이터를 재활용(활용)하기에 용이하다"고 서술하면 매우 전문적으로 보입니다.

11. Spring Cloud Gateway

[활용] MSA 환경에서 모든 클라이언트(Web, Mobile)의 요청이 거쳐 가는 단일 진입점(Entry Point)입니다.

전문가 포인트: "API Gateway를 통해 인증/인가(JWT 검증), 라우팅(Routing), 로드 밸런싱, 서킷 브레이커(Resilience4j) 등 공통 기능을 중앙에서 처리하여 백엔드 마이크로서비스들의 복잡도를 낮춘다"고 설명해야 합니다.

12. JWT (JSON Web Token) & OAuth 2.0

[저장 및 활용] 포탈의 보안(인증/인가)을 담당합니다. (예: 사내 SSO 연동)

전문가 포인트: "Spring Security와 OAuth 2.0(Authorization Code Grant)을 통해 SSO 로그인을 구현하고, 인증된 사용자에게는 JWT를 발급한다. Spring Cloud Gateway에서 이 JWT의 유효성을 검증(Stateless)하고, 토큰의 Claim(정보)에 기반하여 **문서 접근 권한(읽기/쓰기)**을 제어한다"고 구체적으로 서술해야 합니다.

13. React Native (or PWA)

[활용] 모바일 환경에서의 지식 '활용' 방안입니다.

React Native: React 코드를 재활용하여 네이티브 앱을 구축합니다. (푸시 알림 등)
PWA (Progressive Web App): 모바일 웹을 앱처럼 설치하고 오프라인에서도 일부 동작하게 합니다. (더 낮은 비용)

전문가 포인트: "데스크톱 웹(React)과 코드 로직(React Hooks, 비즈니스 로직)을 공유하기 위해 React Native를 채택한다. 또는, 네이티브 앱의 배포/유지보수 비용을 고려하여 우선적으로 **RWD(반응형 웹 디자인)**와 PWA를 적용하여 모바일 접근성을 확보한다"고 트레이드오프를 언급하면 좋습니다.

14. CI/CD Pipeline (GitHub Actions, Jenkins)

[저장 및 활용] 개발된 기능을 안정적이고 빠르게 '저장(배포)'하고 '활용(제공)'하기 위한 자동화 프로세스입니다.

전문가 포인트: "MSA 환경에서는 서비스별 독립적인 CI/CD 파이프라인 구축이 필수적이다. GitHub Actions를 통해 PR(Pull Request) 시 자동으로 **단위 테스트(JUnit), 통합 테스트(Spring Boot Test), FE E2E 테스트(Cypress)**를 수행하고, Main 브랜치 머지 시 Docker 이미지를 빌드하여 Kubernetes 클러스터에 블루/그린(Blue/Green) 배포를 수행한다"고 구체적인 전략을 제시해야 합니다.

15. Docker & Kubernetes (K8s)

[저장 및 활용] MSA 컴포넌트(Spring Boot, React, ES, Kafka 등)를 안정적으로 실행(저장/활용)하기 위한 인프라 표준입니다.

전문가 포인트: "모든 서비스를 Docker 컨테이너화하여 개발-운영 환경의 일관성을 보장한다. Kubernetes를 통해 이 컨테이너들을 **자동으로 스케일링(HPA)**하고, 장애 발생 시 **자동 복구(Self-healing)**하여 고가용성 지식 포탈 서비스를 보장한다"고 언급해야 합니다.

16. Spring Data JPA & RDBMS (예: PostgreSQL)

[저장] 지식 포탈의 핵심 '메타데이터'를 안정적으로 '저장'하는 방법입니다.

전문가 포인트: "문서 본문(비정형)은 ES/NoSQL에 저장하더라도, 사용자 정보, 권한, 문서 버전 이력, 태그, 카테고리 등 정형 데이터와 트랜잭션(Transaction)이 중요한 핵심 메타데이터는 RDBMS(PostgreSQL)와 Spring Data JPA를 통해 관계형으로 명확하게 모델링하고 저장하여 데이터 무결성을 확보한다"고 역할 구분을 명확히 해야 합니다.

17. Observability (Prometheus, Grafana, ELK)

[활용] 복잡한 MSA 환경에서 시스템이 잘 '활용'되고 있는지 모니터링하는 것입니다.

전문가 포인트: "단순 모니터링을 넘어 '관측 가능성(Observability)'을 확보한다. Prometheus로 메트릭(검색 속도, 에러율)을 수집하고, Grafana로 대시보드를 구축한다. **ELK 스택(or Loki)**으로 분산된 서비스의 로그를 중앙에서 수집/분석하고, Zipkin/Jaeger를 통해 분산 추적(Distributed Tracing)을 구현하여 병목 구간(예: 검색 쿼리)을 식별하고 최적화한다"고 서술해야 합니다.

18. Zustand (or Jotai)

[활용] React(FE)의 '클라이언트 상태'를 관리하는 현대적인 도구입니다.

전문가 포인트: "React Query가 서버 상태를 관리하는 동안, '다크 모드 설정', '사이드바 열림/닫힘 여부' 등 전역적이지만 서버와 무관한 순수 클라이언트 UI 상태는 Redux의 보일러플레이트 없이 Zustand 같은 가벼운 라이브러리를 사용해 효율적으로 관리한다"고 역할을 분리해야 합니다.

19. Spring Batch

[저장] 대량의 기존 지식 데이터를 '저장'(마이그레이션)하거나 야간에 '집계'(통계)할 때 사용합니다.

전문가 포인트: "초기 시스템 구축 시, 타 시스템(예: Confluence, 사내 파일 서버)에 산재한 기존 지식 문서를 대량으로(Bulk) 가져와 Elasticsearch 색인 및 Vector DB 임베딩을 수행하기 위해 Spring Batch를 활용한다. 이를 통해 대용량 데이터를 안정적으로 Chunk 단위 처리 및 로깅, 실패 시 재시도(Retry)를 보장한다"고 구체적 시나리오를 들어야 합니다.

20. CDN (Content Delivery Network)

[활용] 지식 포탈의 '활용' 속도를 전 세계 어디서든 빠르게 보장하는 기술입니다.

전문가 포인트: "지식 문서에 포함된 이미지, 동영상, 첨부파일 및 React 정적 에셋(JS, CSS)을 CloudFront/Akamai 같은 CDN을 통해 사용자에게 가장 가까운 엣지 로케이션(Edge Location)에서 제공한다. 이를 통해 원본 서버(Origin)의 부하를 줄이고 전역적인 페이지 로딩 속도를 획기적으로 개선하여 지식 접근성을 높인다"고 설명해야 합니다.

전문성을 드러내기 위해서는 '이 기술을 쓴다'가 아니라, '왜(Why)' 이 기술이 **'저장'**과 **'활용'**의 관점에서 '어떻게(How)' 문제를 해결하는지 명확히 연결하는 것이 중요합니다.

1. 블록 기반 편집기(Block-based Editor)와 JSON 스키마 기반 저장

[핵심: 저장의 구조화(Structuring)가 활용의 유연성을 결정한다]

지식 관리 포탈에서 사용자가 문서를 '저장'하는 첫 관문은 WYSIWYG 편집기입니다. 여기서 전문가는 **"단순 HTML 저장이 아닌, 블록 기반 JSON 스키마로 저장"**을 강조해야 합니다.

전통적 방식 (문제점): 문서를 통짜 HTML로 DB에 저장합니다.
- 저장 문제: <div>, <span> 등 불필요한 스타일 태그가 데이터와 섞여 '더러운 데이터(Dirty Data)'가 됩니다.
- 활용 문제:
  1. 플랫폼 종속성: 모바일 앱(React Native)에서 이 HTML을 네이티브 뷰로 렌더링하기 매우 까다롭습니다. (Webview 필요)
  2. AI 활용성 저하: RAG 모델에 이 HTML을 그대로 전달하면, AI가 태그를 분석하느라 불필요한 토큰을 소모하고, 의미 파악에 실패할 수 있습니다.
  3. 검색 비효율: '코드' 블록 내의 내용만 검색하고 싶어도, HTML을 파싱하지 않는 한 불가능합니다.
전문가적 대안 (JSON 기반 저장): Editor.js나 Tiptap(Headless) 같은 편집기를 사용하여, 모든 내용을 구조화된 JSON으로 저장합니다.
- 저장 효과: 데이터가 '표현(View)'과 '내용(Model)'으로 완벽히 분리됩니다. DB에는 순수한 JSON 텍스트만 저장됩니다.
- 활용 효과:
  1. N-Platform 렌더링: 이 JSON을 웹(React)에서는 HTML로, 모바일(React Native)에서는 <Text>, <CodeView> 등 네이티브 컴포넌트로 자유롭게 렌더링할 수 있습니다.
  2. AI/검색 최적화: AI 모델에게는 type: "paragraph"와 type: "codeBlock"의 text/content만 추출하여 매우 깨끗한 텍스트를 제공할 수 있습니다.
  3. 시맨틱 분석: '코드 블록'만 따로 모아 코드 검색용으로 별도 색인하는 등, 데이터의 '의미(Semantic)'에 기반한 활용이 가능해집니다.

JSON

{
  "time": 1678886400000,
  "blocks": [
    { "type": "paragraph", "data": { "text": "이것은 지식 문서입니다." } },
    { "type": "codeBlock", "data": { "language": "java", "content": "public class Hello {}" } },
    { "type": "image", "data": { "url": "..." } }
  ]
}

2. RAG (검색 증강 생성) 아키텍처의 구체적 웹 앱 구현 흐름

[핵심: LLM을 단순 '채팅봇'이 아닌, '내부 지식 추론 엔진'으로 활용한다]

RAG는 지식 '활용'의 정점입니다. 평가에서는 이 아키텍처의 웹 앱(FE-BE) 관점에서의 데이터 흐름을 서술해야 합니다.

활용 시나리오: 사용자가 포탈 검색창에 "JPA N+1 문제 해결 방안 알려줘"라고 자연어로 질문합니다.
구현 흐름 (Step-by-Step):
1. FE (React): 사용자의 질문("JPA N+1...")을 백엔드 API (예: POST /api/chat/ask)로 전송합니다.
2. BE (Spring Boot):
  1. (Retrieval) 1단계: 쿼리 임베딩: 사용자 질문을 임베딩 모델(SBERT 등)에 전달하여 **질문 벡터(Question Vector)**를 생성합니다.
  2. (Retrieval) 2단계: 벡터 검색: 이 질문 벡터를 Vector DB(Milvus, Pinecone 등)에 질의하여, 의미적으로 가장 유사한 K개의 문서 조각(Chunk) 벡터를 찾습니다.
  3. (Retrieval) 3단계: 원본 텍스트 확보: 찾은 K개 벡터의 ID를 이용해 RDBMS나 Elasticsearch에서 **실제 원본 텍스트 조각(Contexts)**을 가져옵니다.
  4. (Augmentation) 4단계: 프롬프트 증강: LLM(GPT, Claude 등)에 전달할 프롬프트를 동적으로 재구성합니다.
    - "다음 [Context]를 바탕으로 [Question]에 대해 답해. [Context]에 없는 내용은 절대 지어내지 마."
    - [Context]: (문서1 조각 텍스트)... (문서2 조각 텍스트)...
    - [Question]: "JPA N+1 문제 해결 방안 알려줘"
  5. (Generation) 5단계: LLM 호출: 이 증강된 프롬프트를 LLM API로 전송하여 **답변(Answer)**을 생성합니다.
3. FE (React): BE로부터 받은 답변을 사용자에게 보여줍니다.
  - 전문가 포인트: 이때, 답변의 근거가 된 **원본 문서 조각들(Citations)**을 함께 링크로 제공하여, 사용자가 답변의 신뢰도를 검증하고 **원본 지식으로 즉시 연결(활용)**될 수 있도록 UX를 설계해야 합니다. 이는 LLM의 환각(Hallucination)을 방지하는 RAG의 핵심 목적과 직결됩니다.

3. 하이브리드 검색(Hybrid Search)의 랭킹 퓨전(Ranking Fusion) 전략

[핵심: 키워드 검색(정확성)과 벡터 검색(유사성)의 단점을 상호 보완하여 활용한다]

최고의 '활용'(검색) 품질을 위해서는 두 가지 검색 방식을 융합(Fusion)해야 합니다.

문제점:
- 키워드 검색 (BM25)의 한계: "자바 API 만드는 법" 검색 시, '자바', 'API' 단어가 없는 "Spring Boot RESTful 인터페이스 구현" 문서를 놓칩니다. (의미론적 한계)
- 벡터 검색 (Semantic)의 한계: "Spring Boot 3.2.1 릴리즈 노트" 검색 시, '3.2.1'이라는 정확한 고유명사보다 "스프링 최신 기능" 같은 비슷한 의미의 문서를 우선할 수 있습니다. (정확성 한계)
전문가적 대안 (하이브리드 검색):
1. 병렬 쿼리: 사용자의 단일 쿼리를 백엔드(검색 서비스)에서 Elasticsearch(BM25)와 Vector DB(ANN)로 동시에 전송합니다.
2. 결과 획득: Elasticsearch로부터 Top K (예: 20개)의 키워드 점수(BM25 Score) 리스트를 받고, Vector DB로부터 Top K (예: 20개)의 유사도 점수(Cosine Similarity) 리스트를 받습니다.
3. 랭킹 퓨전 (Re-ranking): 이 두 개의 이질적인 점수 리스트를 하나의 신뢰할 수 있는 리스트로 재정렬합니다.
  - 초급: 가중치 합 (Score = 0.4 * BM25_Score + 0.6 * Vector_Score). (두 점수의 스케일이 달라 부정확할 수 있음)
  - 고급 (필수 언급): **RRF (Reciprocal Rank Fusion)**를 사용합니다. RRF는 실제 점수 값이 아닌, **각 리스트에서의 '순위(Rank)'**를 기반으로 최종 점수를 매깁니다. (Score = 1/(rank_bm25 + k) + 1/(rank_vector + k)) 이는 스케일에 무관하게 안정적인 융합 결과를 제공하는 검증된 방식입니다.
4. 최종 결과: RRF 점수로 재정렬된 Top K 결과를 사용자에게 '활용'하도록 제공합니다.

4. 이벤트 기반 아키텍처(EDA)를 통한 비동기 데이터 파이프라인 구축

[핵심: '저장' 요청(Write)과 '활용' 준비(Indexing)를 분리하여 시스템을 안정화한다]

사용자가 문서를 '저장'하는 시점에 모든 '활용' 준비(검색 색인, 벡터화)를 동기식(Synchronous)으로 처리하면 시스템이 불안정해집니다.

동기식 처리 (문제점):
1. 사용자가 '저장' 버튼 클릭 (POST /api/documents)
2. 트랜잭션 시작
3. RDBMS에 문서 INSERT (10ms)
4. Elasticsearch에 INDEX 요청 (500ms) - 만약 ES가 느리거나 장애가 나면?
5. Vector DB에 EMBEDDING 요청 (1000ms) - 만약 Embedding 모델이 느리면?
6. 트랜잭션 커밋
7. 사용자에게 '저장 완료' 응답 (총 1510ms 소요)
- 결과: 사용자는 느린 응답 시간(Latency)을 경험하고, 중간 과정(예: ES 색인) 실패 시 전체 저장 트랜잭션이 롤백되거나 데이터 불일치(DB엔 있으나 검색이 안 됨)가 발생합니다.
전문가적 대안 (비동기 EDA - Outbox Pattern):
1. 사용자 '저장' 요청 (Write):
  - POST /api/documents
  - 단일 트랜잭션 내에서 (1) RDBMS에 문서 INSERT 및 **(2) Outbox 테이블에 "문서 생성됨" 이벤트 INSERT**를 수행합니다.
  - 트랜잭션 커밋 (20ms)
  - 사용자에게 **즉시 '저장 완료' 응답(200 OK)**을 보냅니다. -> 사용자 경험(UX) 극대화
2. 이벤트 발행 (CDC): Debezium 같은 CDC(Change Data Capture) 솔루션이나 별도 스케줄러가 Outbox 테이블을 감지하여, "문서 생성됨" 이벤트를 **Kafka(메시지 큐)**에 발행(Publish)합니다.
3. '활용' 준비 (Async Consumers):
  - 검색 서비스 (Consumer): Kafka의 "문서 생성됨" 이벤트를 구독(Subscribe)하여 비동기적으로 Elasticsearch 색인을 수행합니다. (실패 시 Kafka가 재시도 보장)
  - 벡터 서비스 (Consumer): 동일한 이벤트를 구독하여 비동기적으로 문서를 임베딩하고 Vector DB에 저장합니다.
- 효과: '저장' 시점의 응답성(Latency)을 확보하고, '활용' 준비 과정의 회복탄력성(Resilience)과 확장성을 보장합니다. (데이터는 **최종적 일관성(Eventual Consistency)**을 가짐)

5. GraphQL을 통한 클라이언트 주도형 데이터 '활용' 최적화

[핵심: FE(React)가 필요한 지식 데이터 조각들을 '효율적으로 한 번에' 가져오도록 한다]

지식 포탈의 '활용' 화면(예: 문서 상세 페이지)은 본문, 댓글, 작성자 정보, 연관 문서 등 여러 도메인의 데이터 집합체입니다.

REST API (문제점):
- N+1 문제 / Waterfall 현상: FE(React)가 화면을 그리기 위해 여러 API를 순차적으로 호출해야 합니다.
  1. GET /api/documents/123 (문서 정보) -> 응답 후
  2. GET /api/users/45 (작성자 정보)
  3. GET /api/documents/123/comments (댓글 목록)
  4. GET /api/documents/123/related (연관 문서)
- Over-fetching: 목록 페이지에서는 '제목'만 필요한데, GET /api/documents가 불필요한 '본문'까지 모두 내려줍니다.
- Under-fetching: 상세 페이지에서는 위처럼 여러 번의 호출이 필요합니다.
전문가적 대안 (GraphQL):
- 백엔드(Spring Boot)는 단일 /graphql 엔드포인트와 **데이터 스키마(Schema)**를 제공합니다.
- FE(React)는 **자신이 '활용'할 데이터의 구조를 정확히 명시한 쿼리(Query)**를 만들어 단 한 번 전송합니다.
GraphQL
```
query GetDocumentPageData {
  document(id: "123") {
    title
    contentJson # 블록 JSON 본문
    author { # 'author' 리졸버가 처리
      name
      profileImage
    }
    comments { # 'comments' 리졸버가 처리
      id
      text
      createdAt
    }
  }
}
```
- BE (Resolvers): 백엔드는 이 쿼리를 받아, 각 필드(document, author, comments)에 매핑된 리졸버(Resolver) 함수들을 실행하여 데이터를 병렬로 조립한 후, 요청한 모양 그대로 응답합니다.
- 활용 효과:
  1. 네트워크 효율 극대화: 단일 요청으로 모든 데이터 페칭(Fetching)이 완료됩니다.
  2. FE/BE 간 결합도 감소: FE는 필요한 데이터가 바뀌어도 BE API를 수정 요청할 필요 없이, 자신의 GraphQL 쿼리만 수정하면 됩니다.
  3. 강력한 타입 시스템: 스키마를 통해 FE와 BE가 동일한 데이터 타입을 공유하여 개발 생산성이 향상됩니다. 이는 '클라이언트 주도형(Client-driven)' 데이터 활용 방식의 핵심입니다.

저작자표시 (새창열림)

'컴퓨터 과학 > IT 용어 & 개념 정리' 카테고리의 다른 글

AWS OpenSearch 서비스란? (0)	2024.01.16
AWS DynamoDB 서비스란? (0)	2024.01.16
AWS S3(Simple Storage Service)란? (0)	2024.01.16
AWS Route53이란? (0)	2024.01.11
CORS(Cross-Origin Resource Sharing)란? (1)	2024.01.11