v1.1.0

contentlayer.config.ts

@@ -19,10 +19,6 @@ export const Post = defineDocumentType(() => ({
       type: 'string',
       required: true,
     },
-    category: {
-      type: 'string',
-      required: true,
-    },
     thumbnail: {
       type: 'string',
       required: true,
@@ -36,6 +32,34 @@ export const Post = defineDocumentType(() => ({
       required: false,
     },
   },
+  computedFields: {
+    id: {
+      type: 'string',
+      resolve: (post) => {
+        const [_, id] = post._raw.flattenedPath.split('/');
+
+        return id || post._raw.flattenedPath;
+      },
+    },
+
+    url: {
+      type: 'string',
+      resolve: (post) => {
+        const [_, path] = post._raw.flattenedPath.split('/');
+
+        return `/posts/${path || post._raw.flattenedPath}`;
+      },
+    },
+
+    category: {
+      type: 'string',
+      resolve: (post) => {
+        const [category, path] = post._raw.flattenedPath.split('/');
+
+        return path === undefined ? '기타' : category;
+      },
+    },
+  },
 }));
 
 const contentSource = makeSource({

posts/difference-kakao-sdk-and-url.mdx → posts/Develop/difference-kakao-sdk-and-url.mdx

@@ -1,20 +1,22 @@
 ---
 title: 카카오 로그인의 SDK와 Rest API 방식의 차이점
 description: 카카오 로그인 문서를 읽으면서 알게된 카카오 SDK와 Rest API 방식의 차이점을 공유합니다.
-category: Develop
 createdAt: 2023-03-06
-thumbnail: https://user-images.githubusercontent.com/50941453/223130721-65425c5e-d6c3-4b2c-bc59-ac17c24172dc.png
+thumbnail: /images/posts/develop/difference-kakao-sdk-and-url/thumbnail.png
 ---
 
 안녕하세요! 오늘은 카카오 로그인 문서를 읽다가 알게된 **카카오 SDK와 Rest API 방식의 차이점**에 대해서 글을 작성해봅니다. 😀
 
 ## 1. 알아보게된 계기 🔍
+
 오늘 오후에 친구랑 같이하는 프로젝트에 관해서 **카카오 로그인 설정** 관련 이야기가 톡방에서 나왔었다. 그리고 어쩌다가 나는 카카오 로그인 공식 개발문서를 보게 되었는데, 공식 개발문서를 보는건 되게 오랜만이었다.
 
-![카카오 로그인 JavaScript 구현 방법](https://user-images.githubusercontent.com/50941453/223125803-7e5b986a-40d8-440f-8f61-7dd50499f694.png)
+![카카오 로그인 JavaScript 구현 방법](/images/posts/develop/difference-kakao-sdk-and-url/kakao-login-guide-document.png)
+
 그러다가 JavaScript를 사용한 구현 방법 문서를 보게되었는데, 평소에 회사에서도 그렇고 **REST API** 방식만을 사용한 나는 거의 처음보는 문서였다. 왜냐하면 REST API 방식으로 사용하면서 단 한번도 문제가 없었기 때문이었다.
 
 ### 1-1. REST API 방식이란? 📌
+
 카카오 로그인의 REST API 방식은 카카오 인가 코드를 받기위해서 **쿼리 파라미터에 필수값들을 넣어서 만들어진 URL에 직접 접속**후, 리다이렉트 된 페이지에서 인가 코드를 얻는 방식이다. 여기서의 핵심은 URL에 직접 접속한다는점이다.
 
 <br />
@@ -29,21 +31,26 @@ const KakaoLoginButton = (): JSX.Element => {
 
   return (
     <button
-      onClick={() => window.open(`${BASE_URL}?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&response_type=code`)}
+      onClick={() =>
+        window.open(
+          `${BASE_URL}?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&response_type=code`,
+        )
+      }
     >
       카카오 로그인하기
     </button>
   );
-}
+};
 
 export default KakaoLoginButton;
 ```
 
-<br />
 아래는 요청 주소의 형식이다.
+
 > https://kauth.kakao.com/oauth/authorize?client_id=(클라이언트 ID)&redirect_uri=(리다이렉트 URI)&response_type=code
 
 ### 1-2. 카카오 SDK 방식이란? 📌
+
 코드상에서 불러온 자바스크립트 SDK의 **전역 카카오 객체를 사용하여 로그인을 진행**하는 방식이다. 이렇게만 보면 어떤뜻인지 잘 감이 안오니 코드를 통해서 봐보자.
 
 ```tsx
@@ -59,7 +66,7 @@ const KakaoLoginButton = (): JSX.Element => {
     kakao?.Auth?.authorize({
       redirectUri, // 리다이렉트 URI만 넘겨주고, 해당 주소에서 인가 코드를 받아서 처리
     });
-  }
+  };
 
   useEffect(() => {
     const kakao = (window as any)?.Kakao;
@@ -70,42 +77,42 @@ const KakaoLoginButton = (): JSX.Element => {
     }
   }, []);
 
-  return (
-    <button
-      onClick={kakaoSDKLogin}
-    >
-      카카오 로그인하기
-    </button>
-  );
-}
+  return <button onClick={kakaoSDKLogin}>카카오 로그인하기</button>;
+};
 
 export default KakaoLoginButton;
 ```
 
 SDK를 활용한 로그인 방식도, REST API와 똑같이 리다이렉트된 페이지에서 인가 코드를 받아서 처리하는 방식으로 동일하다.
 
 ## 2. 그래서 차이점이 뭘까? 🤔
+
 참고로 PC에서 각 방법들을 실행할때는 아무런 차이가 없이 동일하게 동작한다. 하지만 모바일에서 실행해보면 어떨까?
 
 먼저, **Rest API** 방식의 로그인 실행 화면이다.
-![카카오 로그인 Rest API 실행 화면](https://user-images.githubusercontent.com/50941453/223123510-78886990-bee8-4e4e-8209-73c7dbab238b.png)
+![카카오 로그인 Rest API 실행 화면](/images/posts/develop/difference-kakao-sdk-and-url/rest-api-execute-login.png)
 
 그 다음은 **Kakao SDK** 방식의 로그인 실행화면이다.
-![카카오 로그인 Kakao SDK 실행 화면](https://user-images.githubusercontent.com/50941453/223123681-fb6a8184-5c94-46af-b9c1-f20ea2316d8b.png)
+![카카오 로그인 Kakao SDK 실행 화면](/images/posts/develop/difference-kakao-sdk-and-url/kakao-sdk-execute-login.png)
 
 사진으로 눈치를 챘을수도 있지만, 정리하면 아래와 같다.
 
 > Rest API: 카카오 로그인 페이지를 먼저 접속한 후, **카카오톡으로 로그인** 버튼을 통해서 카카오톡 앱에서 로그인을 할 수 있도록 제공한다.
 
-> Kakao SDK: 휴대폰에 카카오톡 앱이 설치되어있다면 바로 **카카오톡 앱을 실행**하여 로그인을 할 수 있도록 제공한다. 만약 카카오톡 앱이 설치가 안되어있다면, Rest API 방식에서 본 로그인 페이지가 나타난다. 
+> Kakao SDK: 휴대폰에 카카오톡 앱이 설치되어있다면 바로 **카카오톡 앱을 실행**하여 로그인을 할 수 있도록 제공한다. 만약 카카오톡 앱이 설치가 안되어있다면, Rest API 방식에서 본 로그인 페이지가 나타난다.
 
 곧바로 카카오톡 앱을 실행하여 로그인을 진행한다는 점이 사용자의 전환율을 이끌어내는데 더 도움이 될 수 있는 장점이 있다.
 
 그러나 카카오 쿠키가 존재하면 빠르게 로그인 페이지를 넘어가는 Rest API 방식에 비해, Kakao SDK 방식은 쿠키가 존재하더라도 무조건 카카오톡 앱을 실행하여 로그인하므로 약~간의 단점이 될 수도 있다. (카카오톡 잠금화면 사용자의 경우에만 해당, 잠금화면을 설정하지 않은 사용자는 그냥 물흐르듯이 넘어간다.)
 
 ## 3. 마치며 ⏰
+
 현재 회사 프로젝트의 카카오 로그인 코드는 **Rest API** 방식으로 구현이 되어있는데, 이를 Kakao SDK를 사용하는 방식으로 교체할지 고민해봐야겠다.
+
 <br />
+
 타입스크립트를 사용하는 나에게는 Kakao SDK 방식이 조금 불편하긴 하다만, 모듈화를 잘해놓으면 큰 문제는 없다고 본다.
+
 <br />
+
 혹시나 글에서 잘못된 부분이 있다면, 피드백 주시면 감사드리겠습니다! 😀 이상으로 글을 마치도록 하겠습니다. 감사합니다.

posts/forward-proxy-reverse-proxy.mdx → posts/Develop/forward-proxy-reverse-proxy.mdx

@@ -1,83 +1,121 @@
 ---
 title: Forward Proxy와 Reverse Proxy 정리
 description: 프록시 서버의 개념과 포워드 프록시, 리버스 프록시에 대해서 정리해봅시다.
-category: Develop
 createdAt: 2023-05-15
-thumbnail: https://github.com/yiyb0603/yiyb-blog/assets/50941453/054a55c1-2080-4067-b4ee-9b9924e78615
+thumbnail: /images/posts/develop/forward-proxy-reverse-proxy/thumbnail.png
 ---
+
 안녕하세요! 오늘은 <strong>프록시(Proxy)</strong> 서버의 개념과 이를 이용한 <strong>포워드 프록시(Forward Proxy)</strong>와 <strong>리버스 프록시(Reverse Proxy)</strong>에 대해서 알아보겠습니다.
 
 ## 1. 프록시 서버란? 🤔
-![프록시 서버의 정의](https://github.com/yiyb0603/yiyb-blog/assets/50941453/f9bb82d0-fa86-45d9-b3d5-e9a309f3bcd9)
 
-먼저 프록시 서버에서 <strong>프록시(Proxy)</strong>란 어떤뜻을 가지고 있을까요? 영어 단어사전에서 정의된 뜻은 ```대리```라고 정의되어 있는데요.
+![프록시 서버의 정의](/images/posts/develop/forward-proxy-reverse-proxy/proxy-server.png)
+
+먼저 프록시 서버에서 <strong>프록시(Proxy)</strong>란 어떤뜻을 가지고 있을까요? 영어 단어사전에서 정의된 뜻은 `대리`라고 정의되어 있는데요.
+
 <br />
-```대리```라는 말 그대로입니다. 프록시 서버의 역할은 특정 클라이언트가 자신을 통해서 다른 서비스의 서버로 접속할 수 있게끔 도와주는 서버를 뜻합니다.
+
+`대리`라는 말 그대로입니다. 프록시 서버의 역할은 특정 클라이언트가 자신을 통해서 다른 서비스의 서버로 접속할 수 있게끔 도와주는 서버를 뜻합니다.
+
 <br />
+
 프록시 서버를 사용하면 보안문제 등으로 인해서 접근할 수 없는 서버를 접속할수 있게끔 해주는 등, 우회 접속을 할 수 있습니다.
 
 ### 1-1. 프록시와 VPN의 차이점 ℹ️
-저는 프록시 서버의 정의를 보고나서 ```VPN```과 프록시 서버는 어떤 차이가 있을까? 하는 궁금증이 들었고, 가장 대표적인 차이점은 아래와 같았습니다.
+
+저는 프록시 서버의 정의를 보고나서 `VPN`과 프록시 서버는 어떤 차이가 있을까? 하는 궁금증이 들었고, 가장 대표적인 차이점은 아래와 같았습니다.
 
 - VPN은 장치의 모든 수신, 발신 데이터 보호
 - VPN은 트래픽을 암호화 합니다.
 - VPN은 인터넷 업체의 추적과 정부의 감시를 피하고, 해킹 공격을 방지합니다.
 
 VPN과 프록시는 **자신의 실제 IP 주소를 숨긴다**는 점에서는 동일합니다. 그러나 좀 더 세부적인 보안측면에서는 VPN이 더 좋네요. 😲
+
 <br />
+
 프록시 서버는 클라이언트나 서버 둘중 한곳에서만 사용되는것이 아닌, 양쪽에서 모두 사용될 수 있습니다. 이를 각각 **포워드 프록시**, **리버스 프록시**라고 합니다.
+
 <br />
+
 이 두가지 프록시 서버 방식에 대해서 함께 알아보겠습니다!
 
 ## 2. 포워드 프록시 (Forward Proxy)
-![포워드 프록시의 정의](https://github.com/yiyb0603/yiyb-blog/assets/50941453/5e9d2407-2a4a-4775-bd0d-bf0b5dea3521)
+
+![포워드 프록시의 정의](/images/posts/develop/forward-proxy-reverse-proxy/forward-proxy.png)
 
 포워드 프록시 서버는 클라이언트 바로 뒤에 위치하였으며, 클라이언트의 요청을 받아서 요청을 보내야하는 외부 서버에 **대신 접속하여 가져온 데이터를 클라이언트에게 응답해주는 서버**입니다.
+
 <br />
+
 포워드 프록시는 가장 일반적으로 널리쓰이는 프록시 서버 방식이며, 그냥 프록시 서버라고 정의가 되어있는 서버는 대부분 `포워드 프록시` 서버 방식을 사용합니다.
+
 <br />
-만약 우리가 github.com 이라는 주소를 요청했을때, 우리앞에 있는 포워드 프록시 서버가 대신 github.com의 데이터를 받아서 우리에게 전달해준다고 생각하시면 됩니다.
-그렇다면 이런 포워드 프록시 방식은 왜 사용하는 것일까요?
+
+만약 우리가 github.com 이라는 주소를 요청했을때, 우리앞에 있는 포워드 프록시 서버가 대신 github.com의 데이터를 받아서 우리에게 전달해준다고 생각하시면 됩니다. 그렇다면
+
+이런 포워드 프록시 방식은 왜 사용하는 것일까요?
 
 ### 2-1. 요청 캐싱
+
 포워드 프록시 서버는 우리가 특정 웹에 접속했을때, 해당 웹 서버의 정보를 캐싱해둡니다.
+
 <br />
-캐싱을 해둔다면 이전과 동일한 요청에 대해서 서버에 요청을 날리지 않고, 이미 가지고 있는 캐싱 데이터로 빠르게 클라이언트에게 응답을 해줄 수 있습니다. 이는 원 서버의 부하를 줄이는데도 도움이 됩니다.
+
+캐싱을 해둔다면 이전과 동일한 요청에 대해서 서버에 요청을 날리지 않고, 이미 가지고 있는 캐싱 데이터로 빠르게 클라이언트에게 응답을 해줄 수 있습니다.
+
+이는 원 서버의 부하를 줄이는데도 도움이 됩니다.
 
 ### 2-2. 클라이언트 보안
+
 일반적인 공공기관, 학교 등의 네트워크를 이용하다보면 특정 웹사이트에 접속하려고 하면 접속이 제한되는 경우가 종종 있습니다. 왜냐하면 포워드 프록시 서버를 두어서 내부망의 컨텐츠 액세스 규칙을 정의해두었기 때문입니다.
+
 <br />
+
 포워드 프록시 서버에 룰을 추가해서 특정 사이트에 접속하는 것을 막을 수 있습니다.
 
 ### 2-3. IP주소 암호화
+
 포워드 프록시 서버를 두면 모든 외부 웹사이트 요청에 대해서 프록시 서버를 통해 일어나게 되므로, 자신의 IP 주소를 숨길 수 있습니다.
+
 만약 외부 서버에서 IP 주소를 추적하려고 하면 포워드 프록시 서버의 IP 주소만 알 수 있게되므로 추적하기가 힘들죠.
 
 ## 3. 리버스 프록시 (Reverse Proxy)
-![리버스 프록시 서버의 정의](https://github.com/yiyb0603/yiyb-blog/assets/50941453/7f68f2e8-09d4-4681-b000-e0c260cafaa3)
+
+![리버스 프록시 서버의 정의](/images/posts/develop/forward-proxy-reverse-proxy/reverse-proxy.png)
 
 리버스 프록시 서버는 <strong>인터넷 바로 뒤(본 서버 앞)</strong>에 위치하였으며, 클라이언트 측에서 보낸 요청을 본 서버 대신 먼저받는 서버이고 **해당 리버스 프록시 서버가 본(main) 서버로 요청을 밀어주는 방식**입니다.
+
 <br />
+
 클라이언트측에게 응답 데이터(Response)를 보내주는것이 포워드 프록시라면, 백엔드측에게 요청 데이터(Request)를 보내주는것이 리버스 프록시라고 정의 할 수 있습니다.
+
 <br />
+
 만약 우리가 github.com 이라는 주소를 요청했을때, github.com의 메인 서버로 곧바로 요청이 보내지는것이 아닌, 서버 앞에 위치한 프록시 서버가 이를 받아서 배후(Reverse)에 있는 서버로 요청을 하게 됩니다.
+
 <br />
+
 그럼 이러한 리버스 프록시 방식을 사용하는 이유는 무엇일까요?
 
 ### 3-1. 로드 밸런싱
+
 만약 서비스를 운영중인 메인 서버가 3개일때, 한 서버에만 트래픽이 몰리면 어떻게될까요? 그 서버는 죽게 될것입니다. 😲
+
 그러나 리버스 프록시 서버를 앞에 두게되면, 트래픽이 여유로운 서버로 요청을 하는 등 서버 밸런스를 맞추는 과정이 이루어지는데 이를 **로드 밸런싱** 이라고 합니다.
 
 ### 3-2. 서버 보안
+
 클라이언트의 모든 요청은 리버스 프록시 서버 주소로 요청이 되기때문에, **본 서버의 주소를 숨길 수 있습니다.** 오직 본 서버에 접근을 할 수 있는 서버는 리버스 프록시 서버이기에 본 서버 주소를 감출 수 있는 장점이 있죠.
 
 ### 3-3. 캐싱
+
 리버스 프록시 서버는 클라이언트 요청에 대해서 캐싱을 합니다.
 캐싱을 해둔다면 이전과 동일한 요청에 대해서 빠르게 통신할 수 있다. (포워드 프록시의 캐싱 특징과 동일)
 
 ## 4. 마치며 📌
+
 오늘은 포워드 프록시, 리버스 프록시에 대해서 글을 정리해보았는데요. 최근에 nginx를 만지다가 리버스 프록시 개념이 중요하게 사용되는거같아서 알아보게 되었고, 이렇게 정리를 할 수 있었습니다.
+
 <br />
 혹시나 글에서 잘못된 부분이 있다면, 피드백 주시면 감사드리겠습니다! 😀
-<br />
-긴 글 읽어주셔서 감사합니다!
+<br />긴 글 읽어주셔서 감사합니다!