diff --git a/README.md b/README.md
index 977cb93..4ff834a 100644
--- a/README.md
+++ b/README.md
@@ -1,14 +1,21 @@
-# [성능 개선 보고서] 홈 화면 API 단계별 최적화 및 1,000 VUs 가용성 검증
-
-본 보고서는 홈 화면의 커뮤니티 게시글 조회 API를 대상으로, 초기 성능 측정부터 로직/인프라/아키텍처 최적화에 따른 시스템 임계치 변화를 정량적으로 분석한 기록입니다.
+# 🌾 UMC 7th FarmON BackEnd
+
+**농업의 연결 고리** **FarmON**은 UMC 7기에서 진행된 프로젝트 및 농업의 혁신을 이끄는 디지털 솔루션으로,
+**디지털 커뮤니티**를 통해 소규모 영세농업의 **공동농업을 활성화**하고, 플랫폼을 활용하여 **전국의 농업 전문가를 연결**하며, **농업 데이터**를 기반으로 **체계적인 농업 서비스**를 제공합니다.
+
---
+# 📊 부하 테스트 및 성능 최적화
+## 홈 화면 API 단계별 최적화 및 동시 사용자 1,000 VUs 가용성 검증
+
+본 문서는 홈 화면 커뮤니티 게시글 조회 API를 대상으로 k6를 활용해 **동시 사용자 1,000명 규모의 부하 테스트**를 수행하고,
+Prometheus와 Grafana를 통해 주요 성능 지표를 모니터링하며 **시스템의 성능 한계**와 **병목 지점**을 분석하여 개선한 과정을 정리했습니다.
## 1. 실험 개요 및 환경
### 1.1 실험 환경 및 시나리오
- **테스트 도구**: k6 (ramping-vus)
-- **테스트 시나리오**: 32분간 가상 사용자(VU)를 1에서 1,000까지 13단계에 걸쳐 점진적 증가
+- **테스트 시나리오**: 32분간 가상 사용자(VU)를 1 -> 1,000까지 13단계에 걸쳐 점진적 증가
- **대상 API**: 홈 화면 카테고리별 게시물 정보 반환 API (좋아요/댓글 수 포함)
- **모니터링**: Prometheus, Grafana
- **백엔드**: Spring Boot(3.0.0), Java(17)
@@ -34,6 +41,8 @@
+
+
### 2.2 실험 결과 (1,000 VUs)
| 지표 항목 | 측정 결과 | 판정 및 의미 |
@@ -47,7 +56,7 @@
## 3. [v2] 1차 개선: QueryDSL 기반 단일 조회 (N+1 제거)
-### ✅ 변경 사항 (What was changed?)
+### ✅ 변경 사항
- **쿼리 통합**: QueryDSL을 이용해 `JOIN` 및 `GROUP BY`를 활용한 **단일 집계 쿼리**로 리팩토링
- **최적화 기법**: `COUNT(DISTINCT ...)`를 적용하여 조인 시 중복 집계 방지
- **DTO Projection**: Entity 대신 조회 전용 DTO(**HomePostRow**)를 사용하여 영속성 컨텍스트 부하 절감
@@ -59,6 +68,8 @@
+
+
### 3.2 성능 지표 비교 (v1 vs v2)
| 지표 항목 | v1 (Baseline) | v2 (로직 최적화) | 성과 |
@@ -71,7 +82,7 @@
## 4. [v3] 2차 개선: 인프라 설정 최적화 (WAS/DB 튜닝)
-### ✅ 변경 사항 (What was changed?)
+### ✅ 변경 사항
- **HikariCP**: `maximum-pool-size: 30`, `connection-timeout: 30000` (커넥션 부족 해소)
- **Tomcat**: `threads.max: 400`, `max-connections: 8192` (동시 요청 수용량 증대)
- **RDS**: DB 파라미터 그룹 수정을 통해 `max_connections: 300` 확보
@@ -82,13 +93,14 @@
- **③ [물리 임계점 식별]**: 설정을 확장했음에도 p(95)가 **3.30s**에서 정체됨. 현재 구조상 **물리적 Disk I/O 포화**로 판단됨.
+
---
## 5. [v4] 개선: Redis 캐시 도입 (In-memory 아키텍처)
-### ✅ 변경 사항 (What was changed?)
+### ✅ 변경 사항
- **캐싱 전략**: 홈 커뮤니티 데이터를 `category:{PostType}` 키 구조로 **Redis**에 저장 (In-memory)
- **유효 정책**: `TTL 60초` 적용 및 좋아요/댓글 변경 시 `afterCommit` 시점에 **선택적 캐시 무효화(Evict)**
- **직렬화**: `GenericJackson2JsonRedisSerializer`를 통한 DTO 직렬화
@@ -99,7 +111,9 @@
- **③ [안정성 유지]**: 총 요청 수 **77.3만 건**으로 폭증했으나, 에러율 **0.009%**로 신뢰성 있는 응답 유지.
-
+
+
+
### 5.2 성능 지표 비교 (v1 ~ v4)
| 지표 항목 | v1 (Baseline) | v2 (로직) | v3 (설정) | v4 (Redis) | 성과 (v1 vs v4) |
@@ -120,4 +134,57 @@
| **Error Rate** | **1.0% 미만** | 0.005% | **0.009%** | **통과** |
**향후 목표**:
-로직, 인프라, 캐싱 최적화를 통해 비약적인 성능 향상을 거두었으나, 1,000 VU 환경에서 단일 인스턴스의 CPU 부하로 인해 p(95) 2.0s 목표에는 미달했습니다. 향후 **인스턴스 확장(Scale-out)** 및 **로드밸런서(ALB)** 적용을 통해 자원 부하를 분산하고 최종 목표 지표를 달성할 예정입니다.
\ No newline at end of file
+로직, 인프라, 캐싱 최적화를 통해 비약적인 성능 향상을 거두었으나, 1,000 VU 환경에서 단일 인스턴스의 CPU 부하로 인해 p(95) 2.0s 목표에는 미달했습니다. 향후 **인스턴스 확장(Scale-out)** 및 **로드밸런서(ALB)** 적용을 통해 자원 부하를 분산하고 최종 목표 지표를 달성할 예정입니다.
+
+---
+
+
+## 🔧 Tech Stack
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+ 
+ 
+ 
+
+
+
+## 🛠 Backend Architecture
+
+
+
+## 🗂 ERD
+
+
+
+## 🚀 git flow
+- `main`
+ - 프로젝트 최종 merge
+ - 기본 프로젝트 세팅, 배포 가능한 브랜치, 항상 배포 가능한 상태를 유지
+- `develop`
+ - 데모데이 전까지 완성한 기능들을 계속해서 merge
+ - 배포 가능한 브랜치, 항상 배포 가능한 상태를 유지
+- `{type}/{description}`: 개발 브랜치
+ - 예: `feat/login`, `fix/login-token`
+
+
+## 👩💻👨💻 Organization Repository
+https://github.com/Farm-On/BE
\ No newline at end of file