[edit] blog modal

deploy/content/blog.md

@@ -48,7 +48,12 @@ Blog
     <h3>📑 Meaning</h3>
     <p style="font-family: 'Pretendard-Regular';">
         현재 단락에선 백엔드와 프론트엔드 부분을 따로 나누어서 아키텍쳐 중심으로 설명을 이어나가보겠습니다. </br></br>
-        Back: 
+        <a style="font-weight: bold; border-bottom: none;">
+            Back: </br>
+        </a>
+        <a style="font-weight: bold; border-bottom: none;">
+        1. "왜 AWS Lambda + API Gateway인가?" </br>
+        </a>
         백엔드 어플리케이션은 이제껏 해왔던 아키텍쳐인 EC2 를 기반으로 생각을 했었는데, </br>
         EC2에 올려서 24시간 돌릴 필요가 있을까? 람다에 올려서 필요할 때만 호출하는게 더 저렴하지 않을까 싶어서 EC2와 람다에 올릴 때의 가격을 단순비교하여 보았습니다. <br/>  <br/> 
         - 2024.02 기준 USD 환율: 1331.18 won 
@@ -88,19 +93,31 @@ Blog
             ** Lambda + API Gateway 한달 기준 총가격: 약 6,335 won ** <br/><br/>
         </p>
         <p style="font-family: 'Pretendard-Regular';">
+            <a style="font-weight: bold; border-bottom: none;">
             이렇게 단순 비교지만 개인 블로그처럼 사용자가 적은 경우에는 EC2에 어플리케이션을 띄우는 것보다 <br/> 
             Lambda를 통해 호출 기반으로 띄우는게 몇배나 더 저렴했습니다.<br/> 
-            그렇기에 Lambda + API Gateway 를 이용하여 서버리스 아키텍쳐로 운용하기로 결정했습니다. <br/>
+            그렇기에 Lambda + API Gateway 를 이용하여 서버리스 아키텍쳐로 운용하기로 결정했습니다. </a>
+            <br/>
             다만 Java 기반의 어플리케이션은 lambda에서 cold start 생겨 평균 실행 시간이 높아져 비용이 높아질 수 있는 이슈가 있어<br/>
             초기엔 snap start 적용과 멀티 모듈을 통해 함수를 분할시킬 생각을 하였습니다. <br/>
-            하지만 이렇게 그럴듯한 계획은 언제나 부딪히기 마련인 것 같습니다. (눈물) <br/> 
-            실제 제가 구성했던 아키텍쳐로 개발 후에 각각의 람다로 배포하였을 때 평균 실행 시간이 어느정도 낮아지고 존재하고, 실행건수가 줄어들지만 <br/> 
-            오히려 평균 실행 시간의 차이가 미미하여 실행 건수가 매우 많지 않은 이상 결국 이러한 아키텍쳐가 오히려 비용이 더 드는 계산이 나오게 되어,  <br/> 
+            하지만 이렇게 그럴듯한 계획은 언제나 부딪히기 마련인 것 같습니다. (눈물) <br/> </br>
+            <a style="font-weight: bold; border-bottom: none;">
+            2. "왜 멀티 모듈인가?" </br>
+            </a>
+            실제 제가 구성했던 멀티 모듈 아키텍쳐로 개발 후에 각각의 람다로 배포하였을 때 평균 실행 시간이 어느정도 낮아지고 존재하고, 실행건수가 줄어들지만 <br/> 
+            오히려 평균 실행 시간의 차이가 크지 않아 실행 건수가 매우 많지 않은 이상 또는 어플리케이션이 매우 무거워지지 않는 이상 <br/> 
+            적용한 아키텍쳐가 오히려 비용이 더 드는 계산이 나오게 되어,  <br/> 
             최종적으론 앞서 보여드린 이미지 같은 아키텍쳐로 수정하게 됐습니다.<br/>
             멀티 모듈의 기준이 되는 아키텍쳐의 구성은 우아한 기술블로그 글을 참고하여 아키텍쳐를 구성했습니다. <br/>
+            그리고 도메인 모듈에서만 DB를 커넥트해서 정보를 얻을 수 있게끔 최종 구성을 완료했습니다. <br/>
             ref: <a href="https://techblog.woowahan.com/2637/" target="_blank"> 멀티모듈 설계 이야기 with Spring, Gradle </a> <br/>
+            <a style="font-weight: bold; border-bottom: none;">
             위와 같은 아키텍쳐를 구성함으로써 계층화된 모듈들이 각각의 역할과 책임이 명확하게 있고, 추후 개발의 확장성과 용이성이 증가하였고 <br/>
-            각 모듈에선 최소한의 의존성을 갖기 때문에 lambda에서의 실행 시간을 늦출 수 있는 효과까지 주었습니다. <br/> <br/>
+            각 모듈에선 최소한의 의존성을 갖기 때문에 lambda에서의 실행 시간을 늦출 수 있는 효과까지 주었습니다. </a>
+            <br/> <br/>
+            <a style="font-weight: bold; border-bottom: none;">
+            3. "왜 MongoDB + Redis를 사용하나?" </br>
+            </a>
             이제 DB를 선택한 기준에 대해 설명드려 보겠습니다. <br/>
             먼저 블로그 속 게시글은 이미지를 포함할 수 있고 글의 내용도 길어 용량이 클 수 있기 때문에 <br/> 
             마크다운 파일에 내용을 적고 github에 올리기로 결정했습니다.  <br/> 
@@ -118,13 +135,35 @@ Blog
             클라이언트에서 redis 와 연결시켜 조회수만 올릴 수 있는 api를 만들어 운용하기로 아키텍쳐를 구성하였습니다. <br/>
         </p>
         <p style="font-family: 'Pretendard-Regular';">
-            이러한 아키텍쳐 덕분에 현재 한달 기준 최소 비용으로 따졌을 때 AWS 비용인 약 6,335원만 운영 비용이 나오게 됐습니다. <br/>
+            <a style="font-weight: bold; border-bottom: none;">
+            이러한 아키텍쳐 덕분에 현재 한달 기준 최소 비용으로 따졌을 때 AWS 비용인 약 6,335원만 운영 비용으로 나오게 됐습니다. <br/>
             다만 이용자 수가 많아진다면, 제가 생각하지 못한 비용이 나오게 되어 예상을 넘어가게 되면 또는 더 나은 아키텍쳐가 생기면 <br/> 
             언제든지 아키텍쳐는 수정되어야 한다고 생각합니다. <br/>
+            </a>
         </p>
         <p style="font-family: 'Pretendard-Regular';">
-            Front: 
+            <a style="font-weight: bold; border-bottom: none;">
+            Front: </br>
+            </a>
+            <a style="font-weight: bold; border-bottom: none;">
+            1. "왜 tailwind CSS 인가?"</br>
+            </a>
+            프론트엔드에선 먼저 CSS를 간편하게 설정하기 위해(스타일 지정 분류에 자신이 없어서) tailwind CSS 를 사용했습니다. </br></br>
+            <a style="font-weight: bold; border-bottom: none;">
+            2. "왜 TypeScript 인가?" </br>
+            </a>
+            이제 언어 선택 기준을 말씀드려야 하는데, <br/>
+            먼저 현재 포트폴리오 웹사이트 프로젝트를 진행하면서 마크다운 파일을 HTML로 변환시키는 작업을 JS로 해보았기 때문에 JS 언어를 선택했었습니다.<br/>
+            근데 Typescript 라는 언어가 타입 안전성에 강하고 추세가 JS보다 TS로 넘어가고 있다기에 <br/>
+            어차피 둘 다 잘할 줄 모르는 거 TS로 시작해보자 싶어서 JS대신 TS를 선택했습니다. <br/></br>
+            <a style="font-weight: bold; border-bottom: none;">
+            3. "왜 NextJS 인가?" </br>
+            </a>
+            이제 메인이 되는 프레임워크를 선택해야 하는데 백엔드 아키텍쳐를 짤 때 블로그가 동적으로 렌더링 되어야 하며, Redis와 직접 커넥트하여 조회수를 올리게끔 짰습니다. <br/>
+            이러한 배경을 볼 때 SSR이 필요하여 CSR과 SSR을 혼합해서 사용할 수 있는 NextJS를 선택하게 됐습니다. <br/>
+            NextJS를 선택한 후 마크다운 파일을 동적 렌더링을 시켜줄 수 있는 content layer 라이브러리를 알게 되어 조금 더 간편하게 그리고 레퍼런스가 많은 content layer 라이브러리를 사용하기로 하였습니다. <br/></br>
         </p>
+
     </p>
 </div>