32일차. 도메인 연결하기 & 미들웨어

---

미들웨어를 어떻게 할것인지

 

[React Component]
    ↓
[Zustand Store]       ← action에서 api.* 호출
    ↓
[Frontend API Layer]  ← fetch 래퍼, 헤더/토큰/에러 공통 처리
    ↓
[API Gateway]
    ├ /api/esg/** → ESG Service      (비즈니스 파이프라인)
    └ /api/ai/**  → AI Orchestrator  (AI 미들웨어 파이프라인)
                          ↓
                   [AI 미들웨어 체인]
                     - LangChain
                     - MCP Tools
                     - LoRA Model 선택
                     - RAG 검색
                     - 로그/프로비넌스

 

결국에 ai 미들웨어는 gateway이후에 ai server로 가면서 쓰는 것이고

2:50

한마디로 말하면 공장입니다

2:50

어떤 공정을 넣을 것인가

2:50

어떻 경로를 잡을 것인가

2:50

이것도 설계에요

 

 

Request
 → Input Validate
 → Context Load(organization, report...)
 → RAG Retrieval
 → MCP Tool 호출
 → Prompt 조립
 → LoRA 모델 선택
 → LLM 호출
 → Output Parsing
 → Citation 정리
 → 저장(Log, Provenance)
 → Response // 대충 ai 미들웨어의 구조는 이렇다네요

2:52

일단 저희 화면하고 db연결은 됬거든요.

2:52

버튼 누르면 db에서 쿼리문 실행함.

2:53

저희는 중간에 미들웨어만 넣어주면됨요.

 

---

(앞에서 잡아둔 구조는 유지하면서 “서버 상태는 React Query”, “캐시·세션은 Redis”라는 원칙만 추가하면 됩니다.)

 

1. 전체 그림 (업데이트 버전)

[React Component] ↓ [Store Context] - Zustand (UI/도메인 상태: 현재 탭, 편집 중 섹션, 선택된 조직 등) - React Query (서버 상태: 체크리스트 목록, 리포트 리스트, AI 응답 캐시 등) ↓ [Frontend API Layer] - apiFetch (fetch 래퍼, 토큰/에러/공통 헤더) - esgApi / aiApi (도메인별 클라이언트) ↓ [API Gateway (Spring Cloud Gateway)] ↓ [Backend Services] - ESG Service (PostgreSQL) - AI Orchestrator (LangChain + MCP + LoRA + VectorDB) ↓ [Infra] - PostgreSQL (정식 영구 데이터) - VectorDB / pgvector (RAG 인덱스) - Redis (캐시, 세션, Job 큐)

2. 프론트엔드: React Query + Zustand 같이 쓰는 법
2-1. QueryClientProvider 세팅
main.tsx 또는 App.tsx 최상단에 감싸 줍니다.

// main.tsx (예시) import { QueryClient, QueryClientProvider } from '@tanstack/react-query'; import { ReactQueryDevtools } from '@tanstack/react-query-devtools'; import App from './App'; const queryClient = new QueryClient(); export function Root() { return ( <QueryClientProvider client={queryClient}> <App /> <ReactQueryDevtools initialIsOpen={false} /> </QueryClientProvider> ); }

이걸로 React Query Context가 열리고, 어디서든 useQuery, useMutation을 쓸 수 있음.

2-2. apiFetch 그대로 쓰면서 React Query 얹기
이미 있는 apiFetch를 그대로 유지하고,
 React Query는 단지 **“언제/어떻게 다시 부를지 + 캐싱”**만 관리하게 하면 됩니다.

// lib/api/esg.ts import { apiFetch } from './base'; export const esgApi = { getChecklistItems: (params?: { category?: string; status?: string }) => { const search = new URLSearchParams(); if (params?.category) search.append('category', params.category); if (params?.status) search.append('status', params.status); return apiFetch(`/api/esg/checklists${search.toString() ? `?${search}` : ''}`); }, // ... };

이제 이걸 React Query 훅으로 감싸기:

// hooks/useChecklistItems.ts import { useQuery } from '@tanstack/react-query'; import { esgApi } from '@/lib/api/esg'; export function useChecklistItems(params?: { category?: string; status?: string }) { return useQuery({ queryKey: ['checklists', params], queryFn: () => esgApi.getChecklistItems(params), staleTime: 1000 * 60, // 1분 동안은 신선하다고 봄 }); }

컴포넌트에서:

const ChecklistPage = () => { const { data, isLoading, error } = useChecklistItems({ category, status }); if (isLoading) return <Spinner />; if (error) return <ErrorBox message="체크리스트를 불러오지 못했습니다." />; return <ChecklistTable items={data} />; };

이렇게 하면 ESG 체크리스트 같이 “서버에서 들고 오는 리스트들”은 React Query로,
 현재 탭, 선택된 행, 모달 열림 여부 같은 건 그대로 Zustand에 두면 됨.

2-3. React Query 

 Zustand 연결이 필요한 경우
예를 들어, AI가 생성한 섹션을 Store에 넣고 싶다면
 React Query onSuccess에서 Zustand action만 한 번 호출해주면 됩니다.

// hooks/useGenerateSection.ts import { useMutation } from '@tanstack/react-query'; import { aiApi } from '@/lib/api/ai'; import { useReportStore } from '@/store/reportStore'; export function useGenerateSection() { const addSection = useReportStore((s) => s.addSection); return useMutation({ mutationFn: (payload: GenerateSectionPayload) => aiApi.generateSection(payload), onSuccess: (data, variables) => { // data.sectionText, data.metadata 등 백엔드 응답 구조에 맞게 addSection({ sectionKey: variables.sectionKey, content: data.sectionText, citations: data.citations, }); }, }); }

컴포넌트:

const { mutate: generateSection, isPending } = useGenerateSection(); const handleClick = () => { generateSection({ organizationId, standard: 'IFRS_S2', sectionKey: 'governance', inputs: formValues, }); };

패턴 요약
서버에서 오는 데이터 리스트/디테일 → React Query
페이지 간 공유, 편집 중 상태, 임시 UI 상태 → Zustand
필요할 때 onSuccess에서 Store 업데이트

3. AI/챗에 React Query 쓰는 패턴
채팅은 스트리밍·실시간성이 있어서

• 짧은 요청/응답 → React Query useMutation
• 지속적인 대화 상태 → Zustand messages 배열

조합 추천:

// store/chatSlice.ts export const createChatSlice: StateCreator<ChatState> = (set, get) => ({ messages: [], appendMessage: (msg) => set((state) => ({ messages: [...state.messages, msg] })), }); // hooks/useChatMutation.ts import { useMutation } from '@tanstack/react-query'; import { aiApi } from '@/lib/api/ai'; import { useChatStore } from '@/store/chatStore'; export function useChatMutation() { const appendMessage = useChatStore((s) => s.appendMessage); return useMutation({ mutationFn: (message: string) => aiApi.askConsultant({ organizationId: 'org-123', message }), onMutate: (message) => { appendMessage({ role: 'user', content: message }); }, onSuccess: (data) => { appendMessage({ role: 'assistant', content: data.answer }); }, }); }

4. 백엔드: Redis DB 어디에 꽂을지
이제 레디스(레지스) DB를 구조에 추가해봅시다.
 역할을 애매하게 섞지 말고, 아예 용도를 3개로 나누면 깔끔해요.
4-1. Redis 주요 용도 3가지

1. AI 응답 캐시
   • 같은 질문/같은 컨텍스트로 반복 호출 시 LoRA+RAG 비용 절감
   • key 예: ai:cache:consult:{orgId}:{hash(prompt+ctx)}
2. 세션/대화 히스토리 저장
3. AI Orchestrator가 스케일 아웃될 때,
   •  특정 유저의 채팅 히스토리를 어디서나 볼 수 있게 함
   • key 예: ai:session:{sessionId} → list(JSON messages)
4. 긴 작업(보고서 생성) Job 큐
5. “IFRS S2 전체 보고서 생성” 같이 오래 걸리는 작업을
   •  비동기 Job으로 던지고, 진행 상태를 폴링

4-2. AI Orchestrator에서 Redis 사용하는 위치
아까 만든 미들웨어 체인에 Redis를 끼워넣으면 이렇게 됩니다:

[Controller] /api/ai/chat/consultant ↓ [AI Service] ↓ [Middleware Chain] 1) load_session_from_redis 2) check_answer_cache_in_redis 3) retrieve_docs_from_vector_db (RAG) 4) build_prompt 5) select_model_with_lora 6) call_llm 7) save_session_to_redis 8) save_cache_to_redis 9) log_provenance_to_postgres ↓ [Response]

(1) 세션 로드/저장

def load_session_from_redis(ctx): key = f"ai:session:{ctx.session_id}" messages = redis.lrange(key, 0, -1) # JSON 문자열들 ctx.history = [json.loads(m) for m in messages] return ctx def save_session_to_redis(ctx): key = f"ai:session:{ctx.session_id}" redis.rpush(key, json.dumps(ctx.new_user_message)) redis.rpush(key, json.dumps(ctx.new_assistant_message)) redis.expire(key, 60 * 60 * 24) # 1일 TTL return ctx

(2) 캐시

def check_answer_cache_in_redis(ctx): cache_key = f"ai:cache:consult:{ctx.org_id}:{ctx.prompt_hash}" cached = redis.get(cache_key) if cached: ctx.answer = json.loads(cached) ctx.from_cache = True return ctx def save_cache_to_redis(ctx): if not ctx.from_cache: cache_key = f"ai:cache:consult:{ctx.org_id}:{ctx.prompt_hash}" redis.setex(cache_key, 60 * 10, json.dumps(ctx.answer)) # 10분 캐시 return ctx

이렇게 해놓으면
Redis는 순수하게 “빠른 휘발성 데이터”용,
Postgres는 “검증 가능한 영구 데이터”용으로 역할이 분리됩니다.

4-3. ESG Service 쪽 Redis 활용 (선택)
ESG Service(Spring) 입장에서도:

• 자주 조회되는 기준/체크리스트 메타데이터
•  → Redis 캐시

예:

// pseudo-code public ChecklistItem getChecklistItem(Long id) { String key = "esg:checklist:" + id; ChecklistItem cached = redisTemplate.opsForValue().get(key); if (cached != null) return cached; ChecklistItem item = repository.findById(id).orElseThrow(); redisTemplate.opsForValue().set(key, item, Duration.ofMinutes(5)); return item; }

5. 최종 구조 요약 (짧게)

1. 프론트

• React Query: 서버 상태·AI 응답·체크리스트 등 “백엔드에서 가져오는 데이터”
• Zustand: 현재 탭, 편집 상태, 로컬 UI 상태, 선택된 섹션 등
• 둘 사이 연결은 onSuccess에서 Store 업데이트 방식

1. 백엔드

• AI Orchestrator 내부:

• LangChain + MCP + LoRA는 여전히 미들웨어 체인 안

• Redis:

• 세션(대화 히스토리)
• AI 응답/컨텍스트 캐시

• (선택) Job 큐

• ESG Service:

• 기준/체크리스트 등 자주 조회되는 엔티티 캐시 용도로 Redis 사용 가능

1. API 계약

• 프론트는 계속 /api/esg/..., /api/ai/...만 봄

• React Query는 이 엔드포인트를 감싸고,

•  Redis·LangChain·LoRA·MCP는 전부 백엔드 내부 구현 디테일로 숨김

원하면 다음 단계로는:

• 실제 package.json에 @tanstack/react-query 추가하는 부분 + 루트 컴포넌트 코드
• Zustand slice + React Query hook 세트를
•  chat, report, checklist 각각에 대해 구체적으로 짜줄게.
•  

---

• React Query + Zustand + Redis로 깔끔하게 정리한 우리 프로젝트 아키텍처 (2025년 버전)

  최근 우리 프로젝트에 React Query를 본격 도입하고, Redis를 명확한 역할로 추가하면서 아키텍처가 훨씬 깔끔해졌습니다. 기존에 잘 쓰던 Zustand와 충돌 없이 공존시키는 패턴 + Redis 용도를 명확히 나눈 최종 구조를 정리합니다.
  text

   

  [React Component]
        ↓
  [Store Context]
     ├─ Zustand          → UI/도메인 상태 (현재 탭, 편집 중 섹션, 선택된 조직, 모달 상태 등)
     └─ React Query       → 서버 상태 (체크리스트 목록, 리포트 리스트, AI 응답 등)
        ↓
  [Frontend API Layer]
     ├─ apiFetch (토큰/에러/헤더 공통 처리)
     └─ esgApi / aiApi (도메인별 클라이언트)
        ↓
  [API Gateway - Spring Cloud Gateway]
        ↓
  [Backend Services]
     ├─ ESG Service → PostgreSQL
     └─ AI Orchestrator → LangChain + MCP + LoRA + VectorDB
        ↓
  [Infra]
     ├─ PostgreSQL      → 영구 데이터, 감사 가능 데이터
     ├─ VectorDB/pgvector → RAG 인덱스
     └─ Redis           → 캐시 + 세션 + Job 큐 (휘발성 빠른 데이터 전용)

  핵심 원칙
  • 서버 상태는 React Query
  • 캐시·세션·Job 큐는 Redis
  2. 프론트엔드: React Query + Zustand 완벽 조합 패턴
  tsx

   

  // main.tsx
  import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
  import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
  
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: 1,
        refetchOnWindowFocus: false,
      },
    },
  });
  
  export function Root() {
    return (
      <QueryClientProvider client={queryClient}>
        <App />
        <ReactQueryDevtools initialIsOpen={false} />
      </QueryClientProvider>
    );
  }

  2-2. 기존 apiFetch 그대로 쓰면서 React Query 얹기
  TypeScript

   

  // lib/api/esg.ts (기존 코드 그대로)
  export const esgApi = {
    getChecklistItems: (params?) => apiFetch(`/api/esg/checklists?...`),
  };
  
  // hooks/useChecklistItems.ts (React Query로 감싸기)
  export function useChecklistItems(params?) {
    return useQuery({
      queryKey: ['checklists', params],
      queryFn: () => esgApi.getChecklistItems(params),
      staleTime: 1000 * 60, // 1분
    });
  }

  → 서버에서 오는 리스트는 전부 React Query → 탭 상태, 선택된 행, 모달 오픈 여부 등은 그대로 ZustandAI가 섹션 생성 → 바로 리포트 스토어에 넣고 싶을 때패턴 요약
  • 서버 데이터 → React Query
  • UI/편집 상태 → Zustand
  • 필요 시 onSuccess에서 Store 업데이트
  3. AI 채팅에 React Query 쓰는 추천 패턴
  TypeScript

   

  // store/chatStore.ts
  messages: Message[];
  appendMessage: (msg) => set(state => ({ messages: [...state.messages, msg] }));
  
  // hooks/useChatMutation.ts
  export function useChatMutation() {
    const appendMessage = useChatStore(s => s.appendMessage);
  
    return useMutation({
      mutationFn: (message: string) => aiApi.askConsultant({ message }),
      onMutate: (message) => {
        appendMessage({ role: 'user', content: message });
      },
      onSuccess: (data) => {
        appendMessage({ role: 'assistant', content: data.answer });
      },
    });
  }

  → 메시지 배열은 Zustand, 요청·응답은 React Query mutation
   

  용도키 예시TTL설명

  1. AI 응답 캐시	ai:cache:consult:{orgId}:{promptHash}	10분	같은 질문 반복 시 LoRA+RAG 비용 절감
  2. 세션/대화 히스토리	ai:session:{sessionId}	24시간	스케일 아웃 시 어디서나 접근 가능
  3. Job 큐 (보고서 생성 등)	ai:job:report:{jobId}	작업 종료 시 삭제	오래 걸리는 작업 비동기 처리

  AI Orchestrator 미들웨어 체인에 Redis 끼우기Redis 캐시 예시 코드 (Python)5. 최종 요약 (한눈에 보는 핵심 원칙)이제 프론트는 /api/esg/..., /api/ai/...만 보면 되고, Redis·LangChain·LoRA·MCP는 전부 백엔드 내부 구현 디테일로 깔끔하게 숨겨져 있습니다.
  • package.json에 react-query 추가 + devtools 설정
  • checklist / report / chat 각각에 대한 완성된 hook + slice 코드 드릴게요!
  이 구조로 가면 확장성도 좋고, 캐시 히트율도 올라가고, 코드도 훨씬 예측 가능해집니다! 🚀
• 다음에 원하시면 실제로
•  
  계층담당 라이브러리담당 데이터비고

  프론트 상태	React Query	서버에서 오는 모든 데이터 (리스트, AI 응답)	캐시·자동 리프레시 담당
  프론트 상태	Zustand	UI 상태, 편집 중 데이터, 탭, 모달 등	가벼운 클라이언트 상태
  백엔드 캐시	Redis	AI 응답 캐시, 세션, Job 큐	휘발성 빠른 데이터 전용
  백엔드 영구	PostgreSQL	체크리스트, 리포트 최종본, 로그 등	감사·법적 증적용
  벡터 검색	VectorDB / pgvector	RAG용 문서 임베딩

• Python

   

  def check_answer_cache_in_redis(ctx):
      key = f"ai:cache:consult:{ctx.org_id}:{ctx.prompt_hash}"
      cached = redis.get(key)
      if cached:
          ctx.answer = json.loads(cached)
          ctx.from_cache = True
      return ctx
  
  def save_cache_to_redis(ctx):
      if not ctx.from_cache:
          key = f"ai:cache:consult:{ctx.org_id}:{ctx.prompt_hash}"
          redis.setex(key, 600, json.dumps(ctx.answer))  # 10분
      return ctx

• Python

   

  [Controller]
     ↓
  1. load_session_from_redis
  2. check_answer_cache_in_redis     ← 있으면 바로 리턴!
  3. retrieve_docs_from_vector_db
  4. build_prompt
  5. select_model_with_lora
  6. call_llm
  7. save_session_to_redis
  8. save_cache_to_redis
  9. log_provenance_to_postgres
     ↓
  [Response]

• 4. 백엔드: Redis 용도를 명확히 3가지로만 쓰기
• 채팅은 실시간성이 중요하므로 이렇게 나눕니다.
• TypeScript

   

  // hooks/useGenerateSection.ts
  export function useGenerateSection() {
    const addSection = useReportStore(s => s.addSection);
  
    return useMutation({
      mutationFn: payload => aiApi.generateSection(payload),
      onSuccess: (data, variables) => {
        addSection({
          sectionKey: variables.sectionKey,
          content: data.sectionText,
          citations: data.citations,
        });
      },
    });
  }

• 2-3. React Query ↔ Zustand 연결이 필요할 때
• 기존 apiFetch는 그대로 두고, React Query는 캐싱·리프레시 정책만 담당합니다.
• 2-1. QueryClientProvider 세팅 (최상위)
• 1. 전체 아키텍처 그림 (최신 버전)

🌈 “지금 우리가 뭘 하고 있는 거냐면요…”

➡️ 복잡한 ‘앱’이 있는데, 이걸 더 빠르고, 덜 망가지고, 더 똑똑하게 만들려고 정리하는 과정이야!

조금 더 귀여운 비유로 가보자 👇

---

🏠 1. 우리 집(프로젝트)이 너무 복잡했어

원래:

• 짐(데이터)이 여기저기 막 굴러다님
• 누가 뭐 들고 갔는지 모름
• 청소하기도 어려움
• 방 하나 정리하면 다른 방이 난리남

그래서 집 구조(아키텍처) 자체를 예쁘게 다시 꾸미는 중이야.

---

🏠 2. 방을 역할별로 딱 나눴어

🔵 Zustand 방

➡️ “지금 뭐 보고 있어?”, “어떤 창 열었지?” 같은 UI 상태 저장하는 방

🟢 React Query 방

➡️ “서버에서 가져오는 진짜 데이터”를 저장하는 냉장고 같은 방
(시간 지나면 자동으로 새걸로 갈아끼워주는 똑똑한 냉장고)

🔴 Redis 창고

➡️ “잠깐만 여기 넣어둬!” 하는 임시 창고

• 캐시
• 세션
• 빨리빨리 처리해야 하는 작업 큐

등등 휘발성 데이터 보관

---

🏭 3. 그래서 뭐가 좋아졌냐면…

• 필요할 때마다 서버에 가지 않아도 됨 → 빨라짐
• 뭐가 어디 저장돼 있는지 명확
• 실수로 데이터 엉키는 게 줄어듦
• AI 응답도 중복 계산 안 해도 됨 → 돈 절약
• 구조가 너무 깔끔해서 유지보수가 미친 듯이 편함

---

📦 4. 프론트엔드도 이렇게 말끔하게 정리함

• 서버에서 가져오는 데이터 = React Query
• 화면에서만 필요하거나, 잠깐 쓰는 상태 = Zustand
• 둘이 함께 써야 하면, React Query 성공 → Zustand에 넣기

완벽한 역할 분담!

말 그대로 전체 구조가
“어? 이 데이터는 어느 방에 있어야 하지?”
이 고민이 0이 된 거임.

---

🔥 5. 백엔드도 역할이 정리됨

• PostgreSQL → 영구 저장(사라지면 안 되는 것들)
• Redis → 임시 저장(빨리 쓰고 빨리 지워도 되는 것들)
• VectorDB → AI가 문서 잘 찾게 도와주는 검색 전용

---

🌟 결론 (초딩 버전)

“앱 안에 있는 모든 데이터를 어디에 넣어야 할지 딱 정해놓고, 더 빠르고 똑똑하게 만드는 정리 작업을 하고 있는 중이다!”

그리고 너가 정리한 그 구조는
2025년에 쓰는 ‘모범답안’ 수준으로 깔끔함.
진짜 잘 잡아놨어.

 

 

---

도메인 연결하기

 

 

 

 

버셀 접속해서 회원가입하고

프론트엔드만 복사해서 www.lca.info폴더  만들고 깃허브 다시 만들기

 

버셀에서 깃허브로 연결하고

올리려는 프론트엔드 폴더에 임포트 누르기

 

에러 나오면 클로드에 계속 물어보기