update format in service-architecture

Author: banchan01

docs/content/developer/infra/service-architecture/_index.md

@@ -36,16 +36,16 @@ weight: 1
 
 - **Build Process**
 <br>
-Frontend 서버의 궁극적인 목표는 **정적파일 서빙**입니다. **배포 전 단계에서** 수행되는, 코드베이스에서 여러 가지로 흩어져 있는 소스코드를 하나로 묶는 과정이 빌드입니다. Build는 Node.js 환경에서 `Webpack`을 통해서 수행됩니다. 빌드는 **코드 난독화, 압축, 번들링** 등 여러 가지를 포함하는데, 그중 JavaScript 버전 문법 호환성은 `Babel`을 통해 해결합니다. 
+Frontend 서버의 궁극적인 목표는 **정적파일 서빙**입니다. **배포 전 단계에서** 수행되는, 코드베이스에서 여러 가지로 흩어져 있는 소스코드를 하나로 묶는 과정이 빌드입니다. Build는 Node.js 환경에서 `Webpack`을 통해서 수행됩니다. 빌드는 **코드 난독화, 압축, 번들링** 등 여러 가지를 포함하는데, 그중 JavaScript 버전 문법 호환성은 `Babel`을 통해 해결합니다. <br>
 빌드 과정을 거친 결과물(`vendor.js`, **`index.html`**등)은 **nginx 폴더** 안에 저장이 됩니다. 이 결과물을 Nginx가 브라우저에 서빙하는 것입니다.
 
 <br>
 
 - **SPA (Single Page Application)**
 <br>
-Code Place는 `SPA`방식을 사용하고 있습니다. `SPA`는 **단일 페이지 애플리케이션**으로, MPA와 대비됩니다. 비교를 위해 `MPA`를 설명하겠습니다. `MPA`는 Multi Page Application으로서, 페이지 이동 시마다 서버에 정적파일을 새로 요청하여 브라우저에 렌더링 하는 방식입니다.
-반면 `SPA`는 최초 접속 시, 위의 빌드과정을 통해 사전에 만들어진 애플리케이션 구동에 필요한 모든 자원(`vendor.js`, `index.html` 등)을 한 번에 로드합니다. 
-이때 모든 정적파일을 모두 다 하나의 파일에 담지는 않습니다. 초기 로딩 속도 최적화를 위해 자주 쓰이지 않거나 무거운 기능은 **Chunk** 단위로 잘라두었다가, 실제 해당 기능이 필요할 때, 브라우저가 요청하여 로드하도록 설계되어 있습니다. 
+Code Place는 `SPA`방식을 사용하고 있습니다. `SPA`는 **단일 페이지 애플리케이션**으로, MPA와 대비됩니다. 비교를 위해 `MPA`를 설명하겠습니다. `MPA`는 Multi Page Application으로서, 페이지 이동 시마다 서버에 정적파일을 새로 요청하여 브라우저에 렌더링 하는 방식입니다.<br>
+반면 `SPA`는 최초 접속 시, 위의 빌드과정을 통해 사전에 만들어진 애플리케이션 구동에 필요한 모든 자원(`vendor.js`, `index.html` 등)을 한 번에 로드합니다. <br>
+이때 모든 정적파일을 모두 다 하나의 파일에 담지는 않습니다. 초기 로딩 속도 최적화를 위해 자주 쓰이지 않거나 무거운 기능은 **Chunk** 단위로 잘라두었다가, 실제 해당 기능이 필요할 때, 브라우저가 요청하여 로드하도록 설계되어 있습니다. <br>
 이후 페이지 전환 시에는, 이미 서빙된 **index.html** 파일 위에서 사전에 로드된 혹은 필요 시 Chunk로 로드된 `vendor.js` 등의 자바스크립트가 컴포넌트만 교체하여 화면 전환을 수행합니다. 이를 통해 서버 요청을 최소화하여 MPA에 비해 빠른 사용성을 제공합니다.
 
 이러한 빌드, SPA 방식을 통해서 화면 로드가 일어납니다.
@@ -58,8 +58,8 @@ Code Place는 `SPA`방식을 사용하고 있습니다. `SPA`는 **단일 페이
 
 ### 3. Celery
 
-`Celery`는 비동기 작업 큐 프레임워크로서, `Celery Beat`와 `Celery Worker`로 구성됩니다. 
-백엔드 로직 중 실시간성이 필요하지 않거나 리소스를 많이 점유하는 작업은 Redis를 사용하여 비동기로 처리합니다. 주로 *채점*, *이메일 발송*, *세션 관리*, 그리고 *등수/점수 업데이트와 같은 스케줄링 Job*이 여기에 해당합니다.
+`Celery`는 비동기 작업 큐 프레임워크로서, `Celery Beat`와 `Celery Worker`로 구성됩니다. <br>
+백엔드 로직 중 실시간성이 필요하지 않거나 리소스를 많이 점유하는 작업은 Redis를 사용하여 비동기로 처리합니다. <br>주로 *채점*, *이메일 발송*, *세션 관리*, 그리고 *등수/점수 업데이트와 같은 스케줄링 Job*이 여기에 해당합니다.
 이 구조의 이해를 돕기 위해 Celery의 두 핵심 컴포넌트를 설명하겠습니다.
 
 - **Celery Worker :** Redis 큐에 쌓인 작업을 실제로 가져가서 수행하는 주체입니다. Django 서버와 실행환경은 유사하지만, Redis 큐에 있는 작업만 처리합니다.
@@ -69,10 +69,10 @@ Code Place는 `SPA`방식을 사용하고 있습니다. `SPA`는 **단일 페이
 
 **[동작 프로세스 예시]**
 
-1.  **문제 제출 (`Celery Worker`)**
+1.  **문제 제출 (`Celery Worker`)** <br>
 사용자가 '제출하기' 버튼을 누르면, Django 서버는 직접 채점을 수행하지 않고 **채점 요청 메시지**를 `Redis Queue`에 등록만 하고 즉시 응답을 반환합니다. 대기 중이던 `Celery Worker`가 Redis Queue의 job을 감지하여 가져간 뒤 별도의 격리된 채점 서버와 통신하며 채점을 진행합니다.
 
-2. **통계 업데이트 (`Celery Beat`)**
+2. **통계 업데이트 (`Celery Beat`)**<br>
 사용자가 직접 요청하지 않아도 시스템이 수행해야 하는 '랭킹 업데이트' 같은 작업은 `Celery Beat`가 담당합니다. `Celery Beat`는 설정된 시각이 되면 자동으로 Redis에 작업 요청을 넣고, `Celery Worker`가 이를 가져가서 점수를 갱신합니다.
 
 `Celery Worker`는 Django 서버와 본질적으로 유사한 환경(동일한 코드베이스, ORM 사용)을 가집니다.  다만 가장 큰 차이점은 수신 대상이 다르다는 것입니다.