docs: 기존 글 리팩토링

contents/posts/folder-structure/index.md

@@ -31,19 +31,17 @@ tags:
 - **apis**
   ![](apis-image.png)
 
-  - 백엔드 서버에 요청을 보내기 위한 api를 저장하기 위한 폴더입니다.
-  - 데이터와 관련된 요청을 위한 로직만 모여있기 때문에 services라는 이름 보다 apis가 더 적절하다고 생각해 이름을 변경했어요.
+  백엔드 서버에 요청을 보내기 위한 api를 저장하기 위한 폴더입니다. 데이터와 관련된 요청을 위한 로직만 모여있기 때문에 services라는 이름 보다 apis가 더 적절하다고 생각해 이름을 변경했어요.
 
 - **libs**
   ![](libs-image.png)
 
-  - 외부 라이브러리와 관련된 파일들을 모아두기 위한 폴더입니다.
-  - text 가공을 위한 로직, 비디오를 다루기 위한 로직 등이 담겨있어요.
+  외부 라이브러리와 관련된 파일들을 모아두기 위한 폴더입니다. text 가공을 위한 로직, 비디오를 다루기 위한 로직 등이 담겨있어요.
 
 - **utils**
   ![](utils-image.png)
-  - 그 외 프로젝트 전반에서 사용되는 잡다한 코드들을 위한 폴더입니다.
-  - 그로잉 프로젝트에서 사용하고 있는 react-query, dayjs, react-hook-form 등의 라이브러리를 사용하는 데 필요한 로직들이 담겨있어요.
+
+  그 외 프로젝트 전반에서 사용되는 잡다한 코드들을 위한 폴더입니다. 그로잉 프로젝트에서 사용하고 있는 react-query, dayjs, react-hook-form 등의 라이브러리를 사용하는 데 필요한 로직들이 담겨있어요.
 
 ### 2. types → models
 
@@ -52,13 +50,11 @@ tags:
 - **models**
   ![](models-image.png)
 
-  - 기존에는 `types/chat/` 폴더의 하위에 `chatLine.dto.ts`, `chat.dto.ts` 등으로 하나의 dto를 하나의 파일에 작성했었는데 이를 기능에 따라 그룹화해 `models/` 에 위치 시켰습니다.
-    → 한 파일로 여러 dto들을 모아 두면 다른 파일에서 dto를 import할 때 import문이 간략해진다는 장점이 있어요!
-  - models 에는 백엔드와의 데이터 교환을 도와주는 dto들을 모아두었습니다.
+  기존에는 `types/chat/` 폴더의 하위에 `chatLine.dto.ts`, `chat.dto.ts` 등으로 하나의 dto를 하나의 파일에 작성했었는데 이를 기능에 따라 그룹화해 `models/` 에 위치 시켰습니다. 이렇게 하면, 한 파일로 여러 dto들을 모아 두면 다른 파일에서 dto를 import할 때 import문이 간략해진다는 장점이 있어요. 그리고 models 에는 백엔드와의 데이터 교환을 도와주는 dto들을 모아두었습니다.
 
 - **types**
   ![](types-image.png)
-  - dto 외의 font, style을 위한 타입들을 위한 폴더입니다.
+  dto 외의 font, style을 위한 타입들을 위한 폴더입니다.
 
 위와 같이 세부적으로 폴더를 분리해 로직의 역할에 따라 파일들을 분류할 수 있었습니다. 사실 dto 파일들은 api와 관련된 파일들이기 때문에 apis폴더 안에 위치시키는 것이 좋을 지에 대한 고민이 있었어요. 하지만 정의된 dto들이 apis폴더에 있는 파일 뿐 아니라 react-query를 위한 쿼리들이나 컴포넌트 파일에서도 사용되기 때문에 `src/models` 폴더에 위치시키기로 했습니다.
 
@@ -153,11 +149,11 @@ export default Header;
 그래서 저희는 파일 유형에 따라 분류를 했던 폴더 구조에서 도메인(기능)에 따라 분류를 하는 폴더 구조로 전환했습니다.
 
 - components 폴더에는 프로젝트에서 공통으로 사용할 컴포넌트를 모아둡니다.
-
   ![](components-image.png)
 
 - 도메인별 페이지, 해당 도메인 내에서 사용되는 컴포넌트와 훅들은 모두 pages에 모아둡니다.
-  <img src='login-image.png' width='200px' />
+
+  <img src='login-image.png' width='200px'/>
 
 위와 같이 폴더 구조를 변경한 후, 각 기능별 페이지 폴더 안에 필요한 파일들이 들어있는 형태가 되어 도메인별로 응집도를 높일 수 있었어요.
 
@@ -187,9 +183,12 @@ import { Modal, AlbumModal } from "components/common" // 간단
 그러나 베럴 파일 사용에는 몇 가지 고려해야 할 사항이 있다고 해요. 특히, 대규모 프로젝트의 경우 다음과 같은 이유로 주의가 필요합니다.
 
 1. **트리 쉐이킹(Tree Shaking) 최적화**
-   - 웹팩(Webpack)과 같은 모듈 번들러는 사용되지 않는 코드를 제거하는 트리 쉐이킹 과정을 통해 최종 번들의 크기를 줄입니다. 베럴 파일을 통해 모든 모듈을 임포트하면, 실제로 사용되지 않는 모듈까지 번들에 포함될 가능성이 있어 트리 쉐이킹의 효율성이 떨어질 수 있습니다.
+
+   웹팩(Webpack)과 같은 모듈 번들러는 사용되지 않는 코드를 제거하는 트리 쉐이킹 과정을 통해 최종 번들의 크기를 줄입니다. 베럴 파일을 통해 모든 모듈을 임포트하면, 실제로 사용되지 않는 모듈까지 번들에 포함될 가능성이 있어 트리 쉐이킹의 효율성이 떨어질 수 있습니다.
+
 2. **코드 스플리팅(Code Splitting) 최적화**
-   - 베럴 파일을 사용하면, 필요한 컴포넌트만을 로드하는 대신 관련된 모든 컴포넌트가 함께 로드될 수 있습니다. 이는 초기 로딩 시간에 부정적인 영향을 줄 수 있으며, 특히 대규모 애플리케이션에서는 성능 저하의 원인이 될 수 있습니다.
+
+   베럴 파일을 사용하면, 필요한 컴포넌트만을 로드하는 대신 관련된 모든 컴포넌트가 함께 로드될 수 있습니다. 이는 초기 로딩 시간에 부정적인 영향을 줄 수 있으며, 특히 대규모 애플리케이션에서는 성능 저하의 원인이 될 수 있습니다.
 
 이러한 이유로, 베럴 파일의 사용을 재고하고 프로젝트의 현재 방식을 유지하기로 결정했어요.