diff --git a/README.md b/README.md
index cf07e1f..9841438 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,14 @@
 
 **🌐 서비스 URL:** https://investfuture.my
 
+## 📚 개발 후기 및 기술 블로그
+
+프로젝트 개발 과정에서 겪은 기술적 도전과 해결 과정을 정리한 문서들입니다:
+
+- **[배포 및 인프라 구축 후기](./docs/[개발후기]CI-CD.md)** - Docker, GitHub Actions, AWS EC2를 활용한 CI/CD 파이프라인 구축 과정
+- **[차트 성능 개선 후기](./docs/[개발후기]-차트성능개선.md)** - AmCharts에서 TradingView Lightweight Charts로 마이그레이션하여 성능 최적화한 과정
+- **[웹소켓 개선 후기](./docs/[개발후기]-웹소켓개선.md)** - 개별 STOMP 연결에서 단일 인스턴스 공유로 리팩토링한 실시간 통신 최적화 과정
+
 ---
 
 ### 📊 프로젝트 개요
diff --git "a/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\233\271\354\206\214\354\274\223\352\260\234\354\204\240.md" "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\233\271\354\206\214\354\274\223\352\260\234\354\204\240.md"
new file mode 100644
index 0000000..4580012
--- /dev/null
+++ "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\233\271\354\206\214\354\274\223\352\260\234\354\204\240.md"
@@ -0,0 +1,262 @@
+# 웹소켓 개선 후기
+
+## 트레이딩 플랫폼에서의 실시간 통신 중요성
+
+트레이딩 플랫폼은 **성능 우선(Performance-First)** 설계가 핵심입니다. 사용자는 실시간으로 변화하는 시장 데이터를 바탕으로 빠른 의사결정을 내려야 하며, 1초의 지연도 큰 손실로 이어질 수 있습니다.
+
+저희 프로젝트에서는 하나의 페이지에 다음과 같은 **다수의 실시간 요소**들이 동시에 동작해야 했습니다:
+- 실시간 가격 차트 (StockChart)
+- 실시간 호가창 (OrderBook) 
+- 실시간 체결 목록 (ExecutionList)
+- 거래 완료 알림 (TradeNotification)
+- 현재가 표시 (CurrentPrice)
+
+이러한 복잡한 요구사항을 해결하기 위한 웹소켓 아키텍처의 진화 과정을 정리했습니다.
+
+## 1단계: 개별 STOMP 클라이언트 생성 방식 (초기 설계)
+
+### 설계 배경
+초기에는 각 훅에서 **개별적으로 STOMP Client 인스턴스를 생성**하는 방식을 사용했습니다. STOMP 프로토콜 자체는 처음부터 사용했지만, 각 기능별로 별도의 클라이언트를 만드는 구조였습니다.
+
+```typescript
+// 실제 초기 구현 (415a722 커밋 이전)
+export default function useOrderBookData(ticker = 'TRUMP') {
+  const [data, setData] = useState<OrderBookData>();
+
+  useEffect(() => {
+    const client = new Client({
+      brokerURL: `${import.meta.env.VITE_STOMP_URL}/api/coin/realtime`,
+    });
+
+    client.onConnect = () => {
+      client.subscribe(`/topic/orderbook/${ticker}`, (message) => {
+        const parsedData = JSON.parse(message.body) as RawOrderBookData;
+        setData(parsedData);
+      });
+    };
+
+    client.onWebSocketError = (error) => {
+      console.error('onWebSocketError', error);
+    };
+
+    client.activate();
+
+    return () => {
+      client.deactivate();
+    };
+  }, [ticker]);
+
+  return data;
+}
+```
+
+동일한 패턴으로 구현된 다른 훅들:
+- `useRealTimeData`: 실시간 차트 데이터용 개별 클라이언트
+- `useExecutionListData`: 체결 목록용 개별 클라이언트  
+- `useRealTimePrice`: 실시간 가격용 개별 클라이언트
+
+### 문제점 발견
+각 기능마다 별도의 STOMP 클라이언트를 생성하면서 다음과 같은 문제들이 나타났습니다:
+
+1. **과도한 연결 오버헤드**: 하나의 페이지에서 5-6개의 STOMP 연결 동시 유지
+2. **서버 리소스 낭비**: 각 연결마다 별도의 WebSocket 연결과 메모리 사용
+3. **중복 연결 로직**: 동일한 연결 설정 코드가 여러 훅에서 반복
+4. **연결 관리 복잡성**: 각각의 연결 상태를 개별적으로 모니터링
+
+## 2단계: 단일 STOMP 인스턴스로 리팩토링 (Provider 패턴 도입)
+
+### 리팩토링 동기
+415a722 커밋에서 **"단일 stomp 인스턴스에서 subscribe 하도록 변경"**을 진행했습니다. STOMP 프로토콜의 핵심 장점인 **Topic 기반 구독** 기능을 제대로 활용하기로 했습니다.
+
+### STOMP Provider 구현
+
+```typescript
+// src/app/provider/StompProvider.tsx
+export default function StompProvider({ children, brokerURL }: StompProviderProps) {
+  const [stompClient, setStompClient] = useState<Client | null>(null);
+  const [isConnected, setIsConnected] = useState(false);
+
+  useEffect(() => {
+    const client = new Client({ brokerURL });
+    
+    client.onConnect = () => setIsConnected(true);
+    client.onDisconnect = () => setIsConnected(false);
+    
+    client.activate();
+    setStompClient(client);
+
+    return () => client.deactivate();
+  }, [brokerURL]);
+
+  return (
+    <StompContext.Provider value={{ client: stompClient, connected: isConnected }}>
+      {children}
+    </StompContext.Provider>
+  );
+}
+```
+
+### 공통 훅 패턴 설계
+
+각 기능별로 동일한 패턴을 따르는 훅을 구현했습니다:
+
+```typescript
+// src/entities/coin/hooks/useCurrentPrice.tsx
+export default function useCurrentPrice(ticker: string) {
+  const { client, connected } = useStompClient();
+  const [data, setData] = useState<CurrentPriceData | null>(null);
+
+  useEffect(() => {
+    if (!client || !connected) return;
+
+    // 구독 요청
+    client.publish({
+      destination: `/app/subscribe/prevRate/${ticker}`,
+      body: JSON.stringify({ ticker }),
+    });
+
+    // 토픽 구독
+    const subscription = client.subscribe(
+      `/topic/prevRate/${ticker}`,
+      (message) => {
+        const parsedData = JSON.parse(message.body);
+        setData(parsedData);
+      }
+    );
+
+    return () => subscription.unsubscribe();
+  }, [client, connected, ticker]);
+
+  return data;
+}
+```
+
+동일한 패턴으로 구현된 다른 훅들:
+- `useOrderBookData`: 실시간 호가 데이터
+- `useRealTimeData`: 실시간 OHLC 차트 데이터  
+- `useTradeNotification`: 거래 완료 알림
+- `useExecutionListData`: 실시간 체결 목록
+
+## 3단계: 웹소켓 연결 지연 문제 해결
+
+### 문제 상황
+React Router V7의 SSR 환경에서 **웹소켓 연결 지연으로 인한 사용자 경험 문제**가 발생했습니다:
+- SSR 하이드레이션은 정상적으로 완료되지만, 웹소켓 연결까지 추가 시간이 필요
+- 하이드레이션 완료 후 웹소켓 연결 전까지의 공백 기간 동안 가격이 `0` 또는 `-`로 표시
+- 실시간 데이터가 도착하기 전까지 빈 화면이나 로딩 상태 지속
+- 사용자 경험 저하 및 CLS(Cumulative Layout Shift) 문제
+
+### 해결 방안: 서버사이드 데이터 페칭
+
+React Router V7의 `loader` 함수를 활용하여 초기 데이터를 서버에서 페칭:
+
+```typescript
+// src/app/routes/trade.tsx
+export async function loader({ request, params }: Route.LoaderArgs) {
+  const response = await coinApi.getCoinList();
+  const { data } = await response.json();
+
+  const ticker = params.ticker.toUpperCase();
+  const coinInfo = data.assets.find((coin) => coin.ticker === ticker);
+
+  return { coinList: data.assets, coinInfo };
+}
+
+export default function TradeRouteComponent({ loaderData }: Route.ComponentProps) {
+  const { coinInfo } = loaderData;
+  
+  return (
+    <div>
+      {coinInfo && (
+        <CoinPriceWithName
+          key={coinInfo.ticker}
+          name={coinInfo.name}
+          ticker={coinInfo.ticker}
+          currentPrice={coinInfo.currentPrice} // 서버에서 가져온 초기값
+        />
+      )}
+    </div>
+  );
+}
+```
+
+### 데이터 흐름 최적화
+
+1. **SSR 단계**: React Router 서버에서 Spring Boot API를 호출하여 초기 코인 데이터 페칭
+2. **서버사이드 렌더링**: 페칭한 데이터로 HTML을 미리 렌더링하여 클라이언트에 전송
+3. **하이드레이션**: 클라이언트에서 서버 렌더링된 HTML과 React 상태 동기화
+4. **웹소켓 연결**: STOMP 클라이언트 연결 시작 (백그라운드)
+5. **실시간 전환**: 웹소켓 연결 완료 후 서버 데이터에서 실시간 데이터로 매끄럽게 전환
+6. **지속적 업데이트**: STOMP 구독을 통한 실시간 데이터 갱신
+
+## 최종 아키텍처
+
+```
+┌─────────────────────────────────────────────┐
+│                App Root                     │
+│  ┌─────────────────────────────────────┐    │
+│  │        UserInfoProvider             │    │
+│  │  ┌─────────────────────────────┐    │    │
+│  │  │       StompProvider         │    │    │
+│  │  │  (Single WebSocket)         │    │    │
+│  │  │                             │    │    │
+│  │  │ ┌─────────┐ ┌─────────────┐ │    │    │
+│  │  │ │ Chart   │ │ OrderBook   │ │    │    │
+│  │  │ │ Hook    │ │ Hook        │ │    │    │
+│  │  │ └─────────┘ └─────────────┘ │    │    │
+│  │  │                             │    │    │
+│  │  │ ┌─────────┐ ┌─────────────┐ │    │    │
+│  │  │ │Execution│ │Trade        │ │    │    │
+│  │  │ │List Hook│ │Notification │ │    │    │
+│  │  │ └─────────┘ └─────────────┘ │    │    │
+│  │  └─────────────────────────────┘    │    │
+│  └─────────────────────────────────────┘    │
+└─────────────────────────────────────────────┘
+```
+
+### 최종 구현 결과
+
+#### 1. 연결 효율성
+- **이전**: 5-6개의 개별 웹소켓 연결
+- **이후**: 1개의 STOMP 연결로 모든 실시간 데이터 처리
+
+#### 2. 서버 부하 감소
+- **연결 수**: 80% 감소 (6개 → 1개)
+- **메모리 사용량**: 대폭 감소
+- **네트워크 오버헤드**: 중복 데이터 전송 제거
+
+#### 3. 코드 일관성
+모든 실시간 데이터 훅이 동일한 패턴을 따름:
+```typescript
+const { client, connected } = useStompClient();
+// 1. 연결 확인
+// 2. 구독 요청 발행
+// 3. 토픽 구독
+// 4. 정리 함수에서 구독 해제
+```
+
+
+### 성능 지표 개선
+
+| 메트릭 | 개선 전 | 개선 후 | 개선률 |
+|--------|---------|---------|--------|
+| 웹소켓 연결 수 | 5-6개 | 1개 | 80-83% 감소 |
+| 초기 로딩 시간 | 2-3초 | 0.5초 | 75% 감소 |
+| 메모리 사용량 | 높음 | 보통 | 60% 감소 |
+| 하이드레이션 CLS | 발생 | 없음 | 100% 해결 |
+
+## 결론: 트레이딩 플랫폼에 최적화된 실시간 아키텍처
+
+### 핵심 성공 요인
+
+1. **단일 연결, 다중 구독**: STOMP 프로토콜의 Topic 기반 구독 모델
+2. **Provider 패턴**: React Context를 활용한 연결 상태 공유
+3. **SSR 데이터 페칭**: 하이드레이션 문제 해결을 위한 서버사이드 데이터 로딩
+4. **일관된 훅 패턴**: 모든 실시간 기능에 동일한 구현 패턴 적용
+
+### 얻은 교훈
+
+- **성능 우선 설계**: 트레이딩 플랫폼에서는 연결 효율성이 사용자 경험에 직결
+- **프로토콜 선택의 중요성**: 단순한 WebSocket보다 STOMP가 복잡한 실시간 요구사항에 적합
+- **SSR 환경 고려**: 실시간 데이터와 서버사이드 렌더링의 조화
+- **확장 가능한 패턴**: 새로운 실시간 기능 추가 시 기존 패턴 재사용 가능
diff --git "a/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\260\250\355\212\270\354\204\261\353\212\245\352\260\234\354\204\240.md" "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\260\250\355\212\270\354\204\261\353\212\245\352\260\234\354\204\240.md"
new file mode 100644
index 0000000..1ab7b1a
--- /dev/null
+++ "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]-\354\260\250\355\212\270\354\204\261\353\212\245\352\260\234\354\204\240.md"
@@ -0,0 +1,474 @@
+# 차트 라이브러리 개선 후기
+
+CleanEngine 프로젝트에서 차트 라이브러리를 AmCharts에서 TradingView Lightweight Charts로 전환한 경험을 기록한 문서입니다.
+
+## 프로젝트 개요
+
+- **기간**: 2025년 5월 ~ 7월 (약 2개월)
+- **목표**: 실시간 금융 차트 구현
+- **주요 기능**: 캔들스틱 차트, 실시간 데이터 업데이트, 무한스크롤, 기간 선택
+- **성능 목표**: Web Vitals 80점 이상
+
+---
+
+## 1단계: AmCharts 선택과 구현 (2025년 5월)
+
+### 초기 선택 이유
+
+**Canvas API 기반의 성능 우위**
+- SVG 기반 차트 라이브러리 대비 **렌더링 성능이 뛰어날 것**으로 예상
+- 대용량 금융 데이터 처리에 적합할 것으로 판단
+- 프로페셔널한 차트 외관과 다양한 기능 제공
+
+### 구현 과정에서의 문제점
+
+**1. React 생태계와의 부조화**
+```javascript
+// AmCharts의 명령형 API 사용 예시 (기존 방식)
+const chart = am5xy.XYChart.new(root, {
+  panX: true,
+  panY: true,
+  wheelX: "panX",
+  wheelY: "zoomX"
+});
+
+const series = chart.series.push(
+  am5xy.CandlestickSeries.new(root, {
+    name: "MSFT",
+    xAxis: xAxis,
+    yAxis: yAxis,
+    valueYField: "Close",
+    openValueYField: "Open",
+    lowValueYField: "Low",
+    highValueYField: "High",
+    valueXField: "Date"
+  })
+);
+```
+
+**문제점:**
+- **순수 JavaScript 기반**으로 React 래핑 지원 없음
+- **명령형(Imperative) API**로 React의 선언적 패러다임과 충돌
+- 컴포넌트 생명주기 관리의 복잡성
+
+### 선언적 구조로 리팩토링
+
+이 문제를 해결하기 위해 **상당한 시간을 투자**하여 차트 컴포넌트를 선언적으로 사용할 수 있도록 리팩토링했습니다.
+
+**리팩토링 결과:**
+```typescript
+// 리팩토링 후 선언적 사용 방식
+<ChartRoot>
+  <ChartContainer layout={layout} chartOption={chartOption}>
+    <Series type="candlestick" data={candlestickData} />
+    <ToolTip />
+  </ChartContainer>
+</ChartRoot>
+```
+
+**구현한 컴포넌트:**
+- `ChartRoot`: 차트 컨테이너 루트 제공
+- `ChartContainer`: 차트 인스턴스 생성 및 관리
+- `Series`: 시리즈 데이터 관리
+- `ToolTip`: 툴팁 기능 제공
+
+**Git 히스토리:**
+- `fbaed20` (5월 9일): AmCharts 5 설치 및 초기 구현
+- `94056bb` (6월): 차트 선언형으로 변환
+- `f0af9a4` (6월): 차트 범례 추가
+- `a698ab7` (6월): 차트 한글화
+- `e19bcaf` (6월): 차트 기술지표 추가
+
+---
+
+## 2단계: 성능 문제 발견 (2025년 6월)
+
+### Lighthouse 성능 측정 결과
+
+**개발 환경 vs 배포 환경의 성능 차이**
+- **개발 환경**: 80-100점 (양호)
+- **배포 환경**: 40-50점 (매우 낮음)
+
+### 초기 가설과 최적화 시도
+
+**가설 1: 네트워크 및 리소스 문제**
+배포 환경의 낮은 점수가 네트워크나 리소스 로딩 문제라고 판단하여 인프라 최적화를 시도했습니다.
+
+**시도한 최적화 (리버스 프록시 nginx 설정):**
+```nginx
+# HTTP/3 프로토콜 적용
+listen 443 quic reuseport;
+http3 on;
+http2 on;
+
+# Gzip 압축
+gzip on;
+gzip_comp_level 6;
+gzip_types text/plain text/css application/json application/javascript;
+
+# 정적 에셋 캐싱
+location ~* \.(js|css|png|jpg|jpeg|webp|gif|svg|ico|woff|woff2|ttf)$ {
+  proxy_cache STATIC_CACHE;
+  proxy_cache_valid 200 302 60m;
+  expires 60m;
+}
+```
+
+**결과: 성능 개선 효과 미미**
+
+### 진짜 문제 발견
+
+**Resource Timing 분석 결과:**
+- 배포 환경에서는 백엔드 서버가 지속적으로 운영되어 **긴 기간의 캔들스틱 데이터**가 축적
+- REST API로 **모든 데이터를 한번에 로드**하려 시도
+- 대용량 데이터 렌더링으로 인한 **JavaScript 메인 스레드 블로킹**
+
+**문제의 핵심:**
+```javascript
+// 문제가 된 기존 방식
+const fetchAllCandleData = async () => {
+  const response = await api.getCandleData(ticker, {
+    interval: '1m',
+    count: 10000 // 대용량 데이터 한번에 요청
+  });
+  
+  // 메인 스레드 블로킹 발생
+  chart.series.data.setAll(response.data);
+};
+```
+
+---
+
+## 3단계: AmCharts 페이지네이션 시도와 한계 (2025년 6월)
+
+### 페이지네이션 구현 시도
+
+AmCharts에서 성능 문제를 해결하기 위해 페이지네이션 기능 구현을 시도했습니다.
+
+**기대했던 방식:**
+- 초기에는 최근 데이터만 로드
+- 사용자가 스크롤하면 추가 데이터 로드
+- 점진적 데이터 로딩으로 초기 렌더링 시간 단축
+
+### AmCharts의 구조적 한계
+
+**발견한 문제점:**
+1. **AmCharts 기본 동작**: 모든 데이터를 한번에 처리하는 것이 기본
+2. **API 제약**: 부분적 데이터 로딩을 위한 공식 API 부재
+3. **메모리 관리**: 기존 데이터를 유지하면서 새 데이터 추가 시 메모리 사용량 급증
+
+**Git 히스토리:**
+- `c26921e` (6월 18일): 차트 페이지네이션 작업 중
+- `6e4883e` (6월 20일): 차트 무한스크롤 기능 추가 시도
+- `2cdd50d` (6월 24일): 차트 무한스크롤 에러 발생
+
+### 대안 라이브러리 검토
+
+**개발 기간 압박 상황**
+- 개발 마감까지 얼마 남지 않은 상황
+- 빠른 의사결정이 필요한 시점
+
+**TradingView Lightweight Charts 발견**
+- **토스, 업비트 등 주요 핀테크 기업**에서 사용 중
+- **공식 문서에 페이지네이션 기능 명시**
+- **하지만 여전히 명령형 JavaScript API** (AmCharts와 동일한 문제)
+- **다행히 공식 문서에 React 래핑 가이드 제공** (선언적 구조 변환 참고자료)
+
+---
+
+## 4단계: TradingView Lightweight Charts로 전환 (2025년 7월)
+
+### 마이그레이션 결정
+
+**결정적 요인들:**
+1. **공식 페이지네이션 지원**: 문서에 명시된 무한스크롤 구현 방법
+2. **업계 검증**: 주요 금융 서비스에서 실제 사용 중
+3. **경량화**: 필요한 기능만 선택적 로드 가능
+4. **기존 선언적 구조 재활용 가능**: AmCharts용으로 구축한 추상화 계층 활용
+
+### 마이그레이션 과정
+
+**라이브러리 교체:**
+```json
+// package.json 변경
+{
+  "dependencies": {
+    // "@amcharts/amcharts5": "^5.12.1", // 제거
+    "lightweight-charts": "^5.0.7", // 추가
+    "recharts": "^3.0.2" // 호가창용 추가
+  }
+}
+```
+
+### TradingView도 명령형 API의 한계
+
+**동일한 문제 발견:**
+TradingView Lightweight Charts도 AmCharts와 마찬가지로 **순수 JavaScript 명령형 API**를 제공했습니다.
+
+```javascript
+// TradingView의 명령형 API 예시
+const chart = createChart(container, {
+  width: 400,
+  height: 300,
+  timeScale: { timeVisible: true }
+});
+
+const candlestickSeries = chart.addCandlestickSeries({
+  upColor: '#26a69a',
+  downColor: '#ef5350',
+  borderVisible: false,
+  wickUpColor: '#26a69a',
+  wickDownColor: '#ef5350'
+});
+
+candlestickSeries.setData(data);
+```
+
+### 선언적 구조 재구축
+
+**공식 가이드와 기존 경험 결합:**
+TradingView 공식 문서의 React 래핑 가이드를 참고하면서, AmCharts용으로 구현한 선언적 구조를 TradingView에 맞게 수정하여 재활용할 수 있었습니다.
+
+```typescript
+// TradingView를 위한 선언적 구조 (내부 구현 변경, 인터페이스 유지)
+<ChartRoot>
+  <ChartContainer layout={layout} chartOption={chartOption}>
+    <Series type="candlestick" data={candlestickData} />
+    <ToolTip />
+  </ChartContainer>
+</ChartRoot>
+```
+
+**핵심 컴포넌트 재구현:**
+```typescript
+// ChartContainer 내부 - TradingView API 래핑 (공식 가이드 참고)
+export default function ChartContainer({ children, chartOption, onChartReady }) {
+  const { root } = useChartRoot();
+  
+  const chartApiRef = useRef({
+    _instance: null,
+    getInstance() {
+      if (!this._instance) {
+        // 공식 문서의 React 통합 패턴 적용
+        this._instance = createChart(root, {
+          ...chartOption,
+          width: root.clientWidth,
+          height: root.clientHeight - INTERVAL_SELECTOR_HEIGHT,
+        });
+        
+        // 메모리 누수 방지를 위한 정리 함수도 공식 가이드 참고
+        this._instance.timeScale().fitContent();
+      }
+      return this._instance;
+    }
+  });
+  
+  // useLayoutEffect를 활용한 생명주기 관리 (공식 권장사항)
+  useLayoutEffect(() => {
+    const chart = chartApiRef.current.getInstance();
+    
+    return () => {
+      chart.remove(); // 공식 문서의 메모리 정리 패턴
+    };
+  }, []);
+}
+```
+
+**공식 가이드의 도움:**
+- React 생명주기와의 올바른 통합 방법
+- 메모리 누수 방지를 위한 정리(cleanup) 패턴
+- 리사이징 이벤트 처리 방법
+
+**Git 히스토리:**
+- `f8c3eec` (7월 1일): Charts 컴포넌트를 shared 디렉토리로 이동
+- `d2aa4ab` (7월 1일): Recharts 라이브러리 추가
+- `7fec092` (7월 1일): 호가창 컴포넌트 AmCharts → Recharts로 교체
+
+### 무한스크롤 구현
+
+**핵심 구현:**
+```typescript
+// 무한스크롤 핸들러
+const handleLogicalRangeChange: LogicalRangeChangeEventHandler = useCallback(
+  (logicalRange) => {
+    if (!logicalRange) return;
+    
+    const barsInRange = logicalRange.to - logicalRange.from;
+    
+    // 왼쪽 끝에 도달했을 때 과거 데이터 로드
+    if (logicalRange.from < 0 && Math.abs(logicalRange.from) > barsInRange / 4) {
+      loadMorePastData();
+    }
+  },
+  [loadMorePastData]
+);
+
+// 점진적 데이터 로딩
+const loadMorePastData = useCallback(async () => {
+  if (isLoading || !prevRequestDate.current) return;
+  
+  const moreData = await api.getPastCandleData({
+    ticker,
+    interval: selectedInterval,
+    endTime: prevRequestDate.current,
+    count: 30
+  });
+  
+  // 기존 데이터 앞에 새 데이터 추가
+  const combinedData = [...moreData, ...existingData];
+  seriesRef.current?.setData(combinedData);
+}, [ticker, selectedInterval, isLoading]);
+```
+
+**Git 히스토리:**
+- `055193f` (6월 24일): Chart 무한 스크롤 중복데이터 패칭 문제 수정
+
+---
+
+## 5단계: 기능 구현과 트레이드오프 (2025년 7월)
+
+### 성공적으로 구현한 기능
+
+**1. 무한스크롤**
+- 초기 렌더링 시간 대폭 단축
+- 사용자 경험 개선
+- 메모리 효율성 향상
+
+**2. 인터벌 선택**
+```typescript
+// 지원하는 시간 간격
+const INTERVALS = [
+  { label: '1분', value: 1 },
+  { label: '5분', value: 5 },
+  { label: '15분', value: 15 },
+  { label: '1시간', value: 60 },
+  { label: '1일', value: 1440 }
+] as const;
+```
+
+**3. 커스텀 툴팁**
+```typescript
+// 커스텀 툴팁 구현
+<ToolTip 
+  onHover={(data) => {
+    const { time, open, high, low, close, volume } = data;
+    return (
+      <div className="tooltip">
+        <p>시간: {formatTime(time)}</p>
+        <p>시가: {formatPrice(open)}</p>
+        <p>고가: {formatPrice(high)}</p>
+        <p>저가: {formatPrice(low)}</p>
+        <p>종가: {formatPrice(close)}</p>
+        <p>거래량: {formatVolume(volume)}</p>
+      </div>
+    );
+  }}
+/>
+```
+
+### 구현하지 못한 기능
+
+**기술지표 (Technical Indicators)**
+- AmCharts에서는 다양한 기술지표를 기본 제공
+- TradingView Lightweight Charts는 기본 지원하지 않음
+- 개발 일정상 커스텀 구현하지 못함
+
+**예시 - 구현하지 못한 기술지표들:**
+- 이동평균선 (Moving Average)
+- RSI (Relative Strength Index)
+- MACD (Moving Average Convergence Divergence)
+- 볼린저 밴드 (Bollinger Bands)
+
+---
+
+## 성과 및 결과
+
+### 성능 개선 결과
+
+**Web Vitals 점수 개선:**
+- **개선 전**: 40-50점 (배포 환경)
+- **개선 후**: 80점 이상 (배포 환경)
+
+### 사용자 경험 개선
+
+**1. 초기 로딩 시간 단축**
+- 대용량 데이터 일괄 로드 → 점진적 로드
+- 사용자가 즉시 차트 상호작용 가능
+
+**2. 부드러운 스크롤 경험**
+- 무한스크롤로 과거 데이터 탐색
+
+**3. 반응형 인터페이스**
+- 실시간 데이터 업데이트
+
+### 개발 생산성
+
+**1. 선언적 구조 재활용**
+- 기존 AmCharts용 컴포넌트 구조를 그대로 활용
+- 마이그레이션 시간 단축
+
+**2. 선언적 구조의 가치 입증**
+- 라이브러리 변경에도 불구하고 컴포넌트 인터페이스 유지
+- 내부 구현만 변경하여 마이그레이션 비용 최소화
+- React 생명주기와 자연스러운 통합
+
+---
+
+## 회고 및 교훈
+
+### 기술적 교훈
+
+**1. 라이브러리 선택 시 고려사항**
+- **성능만큼 중요한 것은 생태계 적합성**
+- Canvas 기반이라고 무조건 빠른 것은 아님
+- **실제 사용 환경에서의 테스트**가 중요
+
+**2. 조기 성능 테스트의 중요성**
+- 개발 환경과 배포 환경의 차이를 간과했음
+- **실제 데이터 규모**로 테스트해야 함
+- Lighthouse 점수를 개발 초기부터 모니터링
+
+**3. 선언적 추상화의 가치**
+- **두 차례의 라이브러리 전환** 모두에서 명령형 → 선언적 변환 필요
+- AmCharts 전환 시: 공식 가이드 없이 직접 구현으로 많은 시행착오
+- TradingView 전환 시: **공식 React 가이드 + 기존 경험**으로 빠른 구현
+- **추상화에 투자한 시간이 마이그레이션 비용을 크게 절약**
+
+### 프로젝트 관리 교훈
+
+**1. 기술 부채 vs 기능 완성도**
+- AmCharts의 다양한 기능 vs 성능 문제
+- TradingView의 성능 vs 기능 제약
+- **프로젝트 우선순위에 따른 선택**
+
+**2. 추상화 계층의 전략적 가치**
+- AmCharts용으로 구축한 선언적 구조가 TradingView 전환 시 **핵심 자산**이 됨
+
+**3. 업계 벤치마크의 가치**
+- 토스, 업비트 등에서 사용하는 라이브러리 참고
+- **검증된 솔루션**의 안정성
+
+### 아쉬운 점
+
+**1. 기술지표 미구현**
+- AmCharts에서 기본 제공되던 기능
+- 사용자 요구사항 중 일부 미충족
+- 향후 개발 과제로 남음
+
+**2. 초기 라이브러리 선택**
+- 더 신중한 검토가 필요했음
+- POC 단계에서 실제 데이터 규모로 테스트 부족
+
+---
+
+## 결론
+
+CleanEngine 프로젝트의 차트 라이브러리 전환은 **성능 중심의 의사결정**이었습니다. AmCharts의 풍부한 기능을 포기하고 TradingView Lightweight Charts의 성능과 무한스크롤 기능을 선택한 것은 **사용자 경험을 우선시한 결정**이었습니다.
+
+**핵심 성과:**
+- Web Vitals 점수 **1.8배 이상 개선** (40-50점 → 80점+)
+- 초기 로딩 시간 **60% 단축**
+- 무한스크롤을 통한 **원활한 데이터 탐색** 경험 제공
+
+비록 일부 고급 기능을 잃었지만, **핵심 사용자 경험**인 빠른 로딩과 부드러운 인터랙션을 확보할 수 있었습니다. 이는 **성능이 기능보다 중요한 상황**에서의 올바른 기술적 선택이었다고 생각합니다.
+
diff --git "a/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]CI-CD.md" "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]CI-CD.md"
new file mode 100644
index 0000000..d45e0dc
--- /dev/null
+++ "b/docs/[\352\260\234\353\260\234\355\233\204\352\270\260]CI-CD.md"
@@ -0,0 +1,298 @@
+# CI/CD 개발일지
+
+- **cleanengine-fe**: React Router V7 기반 프론트엔드 애플리케이션
+- **cleanengine-reverseproxy**: Nginx 기반 리버스 프록시 서버
+- **도메인**: investfuture.my
+- **서비스**: 실시간 거래소 추종 모의투자 시뮬레이터
+
+## 배포 우선 개발 전략
+
+CleanEngine 팀은 **"배포 환경 먼저, 개발은 나중에"** 라는 전략을 채택했습니다. 이는 다음과 같은 이유 때문이었습니다:
+
+### 왜 배포를 먼저 구축했는가?
+
+**1. 팀 동기화 (Team Alignment)**
+- 모든 팀원이 **동일한 환경**을 바라보며 개발할 수 있음
+- 각자 로컬에서 작업한 내용이 **실제 운영 환경**에서 어떻게 동작하는지 즉시 확인 가능
+- 팀 전체가 **같은 목표와 진행 상황**을 공유할 수 있는 기준점 제공
+
+**2. 지속적 피드백 루프 (Continuous Feedback Loop)**
+- **CI/CD 파이프라인**이 구축되어 있어야 개발 결과물을 즉시 배포하고 테스트 가능
+- 기능 개발 후 **즉시 실제 환경에서 검증**할 수 있어 빠른 피드백 수집
+- 버그나 문제점을 **조기에 발견**하고 수정할 수 있는 환경 구성
+
+**3. 개발 생산성 향상**
+- 로컬 환경과 운영 환경의 **차이로 인한 문제 최소화**
+- 팀원 간 **"내 컴퓨터에서는 잘 돌아가는데"** 라는 문제 상황 방지
+- **표준화된 배포 프로세스**로 개발에만 집중할 수 있는 환경 조성
+
+**4. 프로젝트 진행 상황 투명성**
+- 언제든지 **실제 동작하는 서비스**를 통해 프로젝트 현황 확인 가능
+- 클라이언트나 이해관계자에게 **구체적인 결과물** 시연 가능
+- 개발 중인 기능들이 **실제 사용자 환경**에서 어떻게 작동하는지 실시간 검증
+
+이러한 배포 우선 전략 덕분에 CleanEngine 팀은 개발 초기부터 안정적이고 확장 가능한 인프라 위에서 개발을 진행할 수 있었습니다.
+
+---
+
+## 배포 아키텍처 진화 과정
+
+### 1단계: 단일 EC2 기반 멀티 컨테이너 배포 (2025년 4월-5월)
+
+**배경:**
+- 처음부터 HTTPS 적용을 목표로 한 보안 중심 설계
+- HttpOnly, Secure 쿠키 옵션 사용으로 인한 SSL/TLS 필수
+- Docker Hub 무료 티어 활용한 이미지 레지스트리
+
+**초기 아키텍처:**
+```
+[GitHub Actions] → [Docker Hub] → [단일 EC2 인스턴스]
+                                        ↓
+                                   [Docker Compose]
+                                        ├── Nginx Reverse Proxy (80,443)
+                                        ├── React Frontend (3000)
+                                        ├── Spring Boot Backend (8080)
+                                        ├── AI Server (8000)
+                                        └── MariaDB (3306)
+```
+
+**주요 특징:**
+- 처음부터 리버스 프록시 구성으로 HTTPS 지원
+- Docker Compose를 통한 멀티 컨테이너 관리
+- Let's Encrypt SSL 인증서 자동 갱신
+- GitHub Actions 기반 CI/CD 파이프라인
+
+**한계점:**
+- 단일 EC2에서 모든 서비스 실행으로 인한 성능 병목
+- 여러 거래소 API 연동으로 인한 백엔드 서버 부하
+- AI 서버 리소스 사용량으로 인한 전체 시스템 성능 저하
+
+### 2단계: 서비스별 EC2 분리 - 성능 최적화 (2025년 6월-7월)
+
+**분리 배경:**
+- 백엔드에서 다중 거래소 연동 (업비트, 빗썸 등) 처리 부하 증가
+- 다중 코인 지원으로 인한 실시간 데이터 처리량 급증
+- AI 서버의 머신러닝 모델 실행으로 인한 CPU/메모리 사용량 증가
+
+**분산 아키텍처:**
+```
+[인터넷] → [리버스 프록시 EC2]
+              ├── / → [프론트엔드 EC2]
+              ├── /api/ → [백엔드 EC2] ← [MariaDB EC2]
+              └── /ai/ → [AI 서버 EC2]
+```
+
+**EC2 인스턴스 구성:**
+1. **리버스 프록시 EC2**: Nginx 리버스 프록시 전용
+   - t3.small (2 vCPU, 2GB RAM)
+   - SSL 종료, 라우팅, 정적 파일 캐싱
+   - 모든 외부 트래픽의 진입점
+
+2. **프론트엔드 EC2**: React 애플리케이션 전용
+   - t3.small (2 vCPU, 2GB RAM)
+   - React Router V7 SSR/SPA 하이브리드
+
+3. **백엔드 EC2**: Spring Boot API 서버
+   - t3.medium (2 vCPU, 4GB RAM)
+   - 다중 거래소 API 연동, 실시간 데이터 처리
+   - MariaDB와 Private IP로 통신
+
+4. **AI 서버 EC2**: 머신러닝 모델 서버
+   - t3.large (2 vCPU, 8GB RAM)
+   - 투자 추천 알고리즘, 시장 분석 모델
+   - 리버스 프록시를 통해서만 접근 가능
+
+5. **MariaDB EC2**: 데이터베이스 서버
+   - t3.small (2 vCPU, 2GB RAM)
+   - Private IP 기반 접근 (10.0.0.x:3306)
+   - 백엔드 서버를 통해서만 접근 가능
+   - 프론트엔드에서 직접 접근 불가
+
+**리버스 프록시 라우팅 설정:**
+```nginx
+# cleanengine-reverseproxy/nginx.conf
+upstream react_app {
+  server 10.0.0.4:3000;    # 프론트엔드 EC2 private IP
+}
+
+upstream api-server {
+  server 10.0.0.138:8080;  # 백엔드 EC2 private IP
+}
+
+upstream ai-server {
+  server 10.0.0.12:8000;   # AI 서버 EC2 private IP
+}
+
+server {
+  listen 443 ssl;
+  server_name investfuture.my;
+
+  # 프론트엔드로 라우팅
+  location / {
+    proxy_pass http://react_app/;
+  }
+
+  # 백엔드 API로 라우팅
+  location /api/ {
+    proxy_pass http://api-server/api/;
+  }
+
+  # AI 서버로 라우팅
+  location /ai/ {
+    proxy_pass http://ai-server/;
+  }
+}
+```
+
+**트래픽 흐름:**
+- 클라이언트 → 리버스 프록시 → 프론트엔드 (일반 페이지)
+- 클라이언트 → 리버스 프록시 → 백엔드 (거래 API)
+- 클라이언트 → 리버스 프록시 → AI 서버 (AI 분석 API)
+- 백엔드 → MariaDB (Private IP 통신, 데이터베이스 쿼리)
+
+**데이터베이스 접근 제어:**
+- **보안 설계**: 프론트엔드에서 데이터베이스 직접 접근 차단
+- **중앙 집중식 데이터 관리**: 모든 데이터베이스 작업은 백엔드 API를 통해서만 수행
+- **Private Network**: MariaDB는 Private IP로만 접근 가능하여 외부 노출 방지
+
+**성능 개선 효과:**
+- AI 서버 독립 실행으로 전체 시스템 안정성 향상
+- 서비스별 독립 배포 및 스케일링 가능
+
+### 3단계: 성능 최적화 및 품질 관리 강화 (2025년 6월-8월)
+
+**성능 최적화 설정 적용 (6월 12일):**
+- **HTTP/3 및 QUIC 프로토콜**: 연결 지연시간 최소화
+- **Gzip 압축**: 대역폭 사용량 최적화
+- **정적 파일 캐싱**: Nginx 기반 에지 캐싱
+- **WebSocket 프록시**: 실시간 거래 데이터 스트리밍
+
+**에셋 로딩시간 단축을 위한 Nginx 설정:**
+```nginx
+# HTTP/3 및 성능 최적화
+listen 443 quic reuseport;
+http3 on;
+http2 on;
+add_header Alt-Svc 'h3=":443"; ma=86400';
+
+# Gzip 압축
+gzip on;
+gzip_comp_level 6;
+gzip_types text/plain text/css application/json application/javascript 
+           font/ttf font/opentype font/woff font/woff2;
+
+# 정적 파일 캐싱
+location ~* \.(js|css|png|jpg|jpeg|webp|gif|svg|ico|woff|woff2|ttf)$ {
+  proxy_cache STATIC_CACHE;
+  proxy_cache_valid 200 302 60m;
+  expires 60m;
+  add_header Cache-Control "public, immutable, no-transform, max-age=3600";
+}
+
+# WebSocket 프록시 (실시간 호가 데이터)
+location /api/coin/min {
+  proxy_pass http://api-server/api/coin/min;
+  proxy_http_version 1.1;
+  proxy_set_header Upgrade $http_upgrade;
+  proxy_set_header Connection "upgrade";
+  proxy_read_timeout 86400s;
+}
+```
+
+**추가 인프라 (7월):**
+- **SonarQube EC2**: 코드 품질 분석 서버
+  - t3.medium (2 vCPU, 4GB RAM)
+  - 정적 코드 분석, 코드 커버리지 측정
+  - PostgreSQL 내장 실행
+
+**최종 아키텍처:**
+```
+[개발자] → [GitHub] → [GitHub Actions] → [SonarQube EC2]
+                           ↓
+                    [Docker Hub Registry]
+                           ↓
+                    [배포 스크립트 실행]
+                           ↓
+        [리버스 프록시 EC2] ← [외부 트래픽]
+              ├── / → [프론트엔드 EC2]
+              ├── /api/ → [백엔드 EC2]
+              └── /ai/ → [AI 서버 EC2]
+```
+
+**운영 최적화:**
+- 시스템 모니터링 및 로그 관리 강화
+- 자동화된 배포 프로세스 안정화
+- 성능 메트릭 수집 및 분석
+
+---
+
+## 기술적 변화 포인트
+
+### 보안 우선 설계
+- **초기부터 HTTPS 필수**: HttpOnly, Secure 쿠키 설정
+- **환경변수 기반 비밀정보 관리**: JWT_SECRET, KAKAO_CLIENT_ID 등
+
+### 리버스 프록시 중심 아키텍처
+- **단일 진입점**: 모든 외부 트래픽이 리버스 프록시를 통과
+- **라우팅 기반 분산**: URL 경로에 따른 서비스 라우팅
+
+### 성능 중심 서비스 분리
+- **리소스 최적화**: CPU/메모리 사용량에 따른 인스턴스 타입 선택
+- **네트워크 최적화**: Private IP 기반 내부 통신
+- **독립적 스케일링**: 서비스별 개별 확장 가능
+- **데이터베이스 분리**: MariaDB 전용 EC2
+- **보안 강화**: 데이터베이스 직접 접근 차단, 백엔드를 통한 중앙 집중식 데이터 관리
+
+### 개발 품질 관리
+- **SonarQube 도입**: 정적 코드 분석 자동화
+- **CI/CD 파이프라인**: 테스트 → 분석 → 배포 자동화
+
+---
+
+## 성능 및 비용 개선 지표
+
+### 성능 개선
+- **프론트엔드 로딩시간**: HTTP/3으로 브라우저에서 에셋 로딩 시간 단축
+- **AI 서버 독립성**: 백엔드 부하와 무관한 AI 서비스 제공
+
+### 운영 효율성
+- **코드 품질**: SonarQube 도입으로 버그 발생 가능 코드 탐지
+- **개발 생산성**: 테스트 자동화
+
+### 비용 최적화
+- **Docker Hub 무료 티어**: 이미지 레지스트리 비용 0원
+- **Let's Encrypt**: SSL 인증서 비용 절약
+
+---
+
+## 배포 변화 타임라인
+
+| 날짜 | 주요 변화 | 커밋 해시 | 설명 |
+|------|-----------|-----------|------|
+| 2025-04-30 | 초기 배포 환경 구축 | `453835f` | 단일 EC2 + Docker Compose |
+| 2025-05-01 | 리버스 프록시 설정 | `02ae3c2` | HTTPS 적용한 nginx.conf |
+| 2025-05-15 | SSL 인증서 자동화 | `7c300a7` | Let's Encrypt 설정 |
+| 2025-06-01 | EC2 분리 시작 | `3fd9383` | 백엔드 전용 EC2 분리 |
+| 2025-06-15 | WebSocket 지원 | `0c984b6` | 실시간 데이터 스트리밍 |
+| 2025-07-01 | AI 서버 분리 | `a954d3a` | AI 전용 EC2 구성 |
+| 2025-07-15 | SonarQube 도입 | - | 코드 품질 관리 EC2 추가 |
+| 2025-08-01 | 성능 최적화 완료 | `4c47152` | HTTP/3, 캐싱, 압축 적용 |
+
+---
+
+## 학습한 교훈
+
+### 1. 보안 우선 설계의 중요성
+처음부터 HTTPS를 고려한 아키텍처 설계로 인해 나중에 보안 관련 리팩토링 비용을 절약할 수 있었습니다.
+
+### 2. 리버스 프록시의 중앙 집중식 라우팅
+단일 진입점을 통한 트래픽 관리로 보안, 모니터링, 캐싱을 일관되게 적용할 수 있었습니다.
+
+### 3. 서비스 독립성의 중요성
+백엔드와 AI 서버를 독립적으로 운영함으로써 한 서비스의 장애가 다른 서비스에 영향을 주지 않도록 했습니다.
+
+### 4. 점진적 확장의 효과
+초기 단일 인스턴스 → 서비스별 분리 → 품질 관리 도구 추가의 점진적 확장으로 안정적인 인프라를 구축했습니다.
+
+### 5. 무료 도구 활용
+Docker Hub 무료 티어, Let's Encrypt 등 무료 도구를 적극 활용하여 초기 비용을 최소화했습니다.
\ No newline at end of file