Revise architecture structure and tech decision details (#52)

Updated architecture structure section to reflect front-end details and
added explanations for technology choices.

Author: Daniel-Na118

README.md

@@ -58,7 +58,18 @@ https://www.notion.so/API-2ffe04be1b438100888be0685a7158ba?source=copy_link
 #### 주 단위 스프린트, 커밋 컨벤션 규칙 및 Git, GitHub를 통한 PR 단위 코드 리뷰  
 https://api.snuxi.com/swagger-ui/index.html  
 
-## 아키텍처 구조(BE)   
+## 아키텍처 구조(FE)
+*   **컴포넌트 기반 구조 (React)**: 재사용 가능한 UI 컴포넌트들을 중심으로 애플리케이션을 구축하여 유지보수성과 확장성을 높였습니다. 페이지 단위로 컴포넌트를 구성하고, 각 컴포넌트의 책임을 명확히 분리합니다.
+*   **상태 관리 (Jotai)**: 전역 상태 관리를 위해 Jotai 라이브러리를 사용합니다. Atom 기반의 미니멀한 접근 방식으로, 필요한 상태만 효율적으로 관리하고 컴포넌트 간의 불필요한 리렌더링을 최소화합니다.
+*   **클라이언트 측 라우팅 (React Router DOM)**: 단일 페이지 애플리케이션(SPA)의 내비게이션을 위해 React Router DOM을 활용합니다. URL과 UI의 동기화를 통해 사용자에게 매끄러운 페이지 전환 경험을 제공합니다.
+*   **API 통신 계층 (Axios)**: 백엔드 API와의 효율적인 통신을 위해 Axios를 사용합니다. 요청/응답 인터셉터를 활용하여 인증 토큰 관리, 에러 처리 등의 공통 로직을 중앙에서 관리합니다.
+*   **모듈화된 디렉토리 구조**:
+    *   `src/api`: 백엔드 API와의 통신을 위한 함수들을 정의합니다. (e.g., `auth.ts`, `room.ts`, `admin.ts`)
+    *   `src/common`: 공통으로 사용되는 상수, 유틸리티 함수, Jotai 아톰 등을 포함합니다.
+    *   `src/components`: 여러 페이지에서 재사용되는 UI 컴포넌트들을 모아둡니다.
+    *   `src/pages`: 각 서비스 페이지를 구성하는 컴포넌트들을 포함하며, 라우팅 단위의 엔트리 포인트입니다.
+    *   `src/router`: React Router DOM을 사용하여 애플리케이션의 라우팅 설정을 정의합니다.
+    *   `src/types`: TypeScript 타입 정의를 중앙에서 관리합니다.
 
 ## 주요 기능  
 #### 1. 약관 동의와 학교 메일 인증 절차로 안전하게!  
@@ -82,15 +93,18 @@ WebSocket 기술을 기반으로 빠른 실시간 텍스트 채팅을 지원해
 ![ability4](./img/5.png)
 
 ## 기술적 의사결정  
-#### 1. Kubernetes 대신 Nginx를 사용한 이유  
+1.  **React.js 및 TypeScript 채택**:
+    *   **React.js**: 선언적이고 컴포넌트 기반의 UI 개발을 가능하게 하여, 복잡한 UI를 효율적으로 구축하고 유지보수하는 데 용이합니다. 활발한 커뮤니티와 풍부한 생태계를 갖추고 있습니다.
+    *   **TypeScript**: 정적 타입 검사를 통해 개발 과정에서 발생할 수 있는 잠재적인 오류를 미리 방지하고, 코드의 가독성과 안정성을 향상시킵니다. 대규모 프로젝트 협업에 필수적이라고 판단했습니다.
 
-#### 2. WebSocket 에서의 메시지 전송 동적 제어 및 인증 흐름  
-단일 Pod 환경에서 메시지 전송을 동적으로 제어하기 위해 @SendTo, 외부 메시지 브로커를 사용하지 않고 simpMessagingTemplate 및 pub시 기본 메시지 브로커를 사용하였습니다.  
-인증 흐름은 WebSocket Upgrade를 위한 Handshake, 메시지 요청 종류에 따른 적합성을 검토하는 Interceptor, 메시지를 전송하는 비즈니스 로직으로 제어 흐름을 분리하였습니다.  
-  
-#### 3. 소셜 로그인 시 세션 방식을 선택한 이유  
-HttpOnly 쿠키로 XSS 공격을 차단하고, 악성 유저 발생 시 서버에서 즉시 세션을 만료 시켜 강제 로그아웃 할 수 있는 제어권을 확보했습니다.
+2.  **Vite를 빌드 도구로 선택한 이유**:
+    *   기존 Webpack 대비 매우 빠른 개발 서버 구동 및 HMR(Hot Module Replacement)을 제공하여 개발 생산성을 극대화합니다. ES Module 기반의 빌드 시스템으로 효율적인 번들링을 수행합니다.
+
+3.  **Jotai를 상태 관리 라이브러리로 선택한 이유**:
+    *   Redux와 같은 복잡한 보일러플레이트 없이 미니멀하고 직관적인 API를 제공합니다. Atom 기반으로 필요한 상태만 구독하여 컴포넌트의 불필요한 리렌더링을 최소화하고 성능을 최적화합니다. 특히, 작은 규모의 프로젝트에서 빠른 도입과 쉬운 학습 곡선을 가집니다.
 
-로그인 시 DB의 userId를 세션에 함께 담도록 커스터마이징하여(CustomOAuth2User), API 요청마다 DB 조회 없이 유저를 식별할 수 있게 성능을 최적화했습니다.
+4.  **클라이언트 측 라우팅에 React Router DOM 사용**:
+    *   SPA의 핵심인 URL 기반의 내비게이션을 선언적으로 관리할 수 있게 해줍니다. 동적 라우팅, 중첩 라우팅 등 다양한 라우팅 시나리오를 유연하게 처리할 수 있어 사용자 경험을 향상시킵니다.
 
-이용자 예상 규모(최대 수백 명)에 맞춰 JWT보다 세션 방식이 구현 비용 대비 효율적이라고 판단했습니다.
+5.  **Axios를 API 클라이언트로 활용**:
+    *   Promise 기반의 HTTP 클라이언트로, 간결한 API와 강력한 기능을 제공합니다. 요청/응답 인터셉터를 통해 토큰 기반 인증, 에러 처리(예: 401 Unauthorized 시 로그인 페이지로 리다이렉션) 등의 공통 로직을 효율적으로 구현하여 API 통신 계층의 일관성을 유지합니다.