Chore: 링크 수정

_posts/2024-09-28-block-querydsl.md

@@ -142,9 +142,9 @@ private BooleanExpression checkLoginMemberBlockOwnerOrTaggedMember(final Long lo
 
 ## 성능 비교 및 마무리
 
-결과적으로 개선이 되긴 되었지만, 드라마틱하게 실행 시간이 줄어들진 않았습니다. [이 곳](https://smwu-pochak.github.io/posts/test-query-performance/)에서 자세한 내용을 확인할 수 있습니다!
+결과적으로 개선이 되긴 되었지만, 드라마틱하게 실행 시간이 줄어들진 않았습니다. [이 곳](https://5jisoo.github.io/posts/test-query-performance/)에서 자세한 내용을 확인할 수 있습니다!
 
-또한 Querydsl 도입 이후, CustomRepository를 테스팅하는 방법을 [이 곳](ttps://smwu-pochak.github.io/posts/testing-repository/)에서 정리하였습니다!
+또한 Querydsl 도입 이후, CustomRepository를 테스팅하는 방법을 [이 곳](ttps://5jisoo.github.io/posts/testing-repository/)에서 정리하였습니다!
 
 # [10/2 내용 추가] 리팩토링 V2
 
@@ -177,7 +177,7 @@ return Optional.ofNullable(
 
 기존에 where 절에 포함되어 있던 `post.id.eq(postId)` 조건을 초반에 tag를 inner join할 때 on절의 조건으로 이동시켰습니다.
 
-[기존 쿼리](https://smwu-pochak.github.io/posts/block-querydsl/#%EA%B5%AC%ED%98%84-%EB%B0%A9%EC%8B%9D)의 구현방식에서 첫번째 `기준테이블인 post 테이블에 tag 테이블을 inner join` 해주는 과정에 on 조건절에 `post.id.eq(postId)` 를 추가하였습니다.
+[기존 쿼리](https://5jisoo.github.io/posts/block-querydsl/#%EA%B5%AC%ED%98%84-%EB%B0%A9%EC%8B%9D)의 구현방식에서 첫번째 `기준테이블인 post 테이블에 tag 테이블을 inner join` 해주는 과정에 on 조건절에 `post.id.eq(postId)` 를 추가하였습니다.
 
 원래 `where(post.id.eq(postId))`를 통하여 Tag와의 JOIN, Block과의 LEFT JOIN이 끝난 뒤 where문을 통해 post id를 필터링하는 방식에서 미리 join 전에 필터링을 거는 방식으로 변경하였습니다.
 
@@ -212,6 +212,6 @@ inner join의 경우, 조건을 `on`과 `where` 어디에 위치시켜도 성능
 
 ## 성능 비교
 
-기존, 개선한 V1, V2 쿼리 각각의 성능 측정은 [이 글](https://smwu-pochak.github.io/posts/test-query-performance/#2%EC%B0%A8-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%ED%95%B4%EB%B4%85%EC%8B%9C%EB%8B%A4)에서 자세히 측정하였습니다.
+기존, 개선한 V1, V2 쿼리 각각의 성능 측정은 [이 글](https://5jisoo.github.io/posts/test-query-performance/#2%EC%B0%A8-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%ED%95%B4%EB%B4%85%EC%8B%9C%EB%8B%A4)에서 자세히 측정하였습니다.
 
 근소하지만 성능 향상의 결과를 얻을 수 있었습니다.

_posts/2024-09-29-test-query-performance.md

@@ -28,7 +28,7 @@ _설정 완료!_
 
 ## 테스팅할 메소드
 
-자세한 리팩토링 과정은 [이곳](https://smwu-pochak.github.io/posts/block-querydsl/)에서 확인할 수 있습니다.
+자세한 리팩토링 과정은 [이곳](https://5jisoo.github.io/posts/block-querydsl/)에서 확인할 수 있습니다.
 
 - 기존 쿼리
 ```java
@@ -204,7 +204,7 @@ HTTP Request 정보를 다음과 같이 세팅해주었습니다.
 ## 2차 테스트를 해봅시다!
 
 > 위 쿼리를 다시 개선한 V2 쿼리를 다시 작성하였습니다! 따라서 기존 쿼리, V1 쿼리, V2 쿼리의 성능 비교를 해보도록 하겠습니다! <br>
-[자세한 내용](https://smwu-pochak.github.io/posts/block-querydsl/#join---on-%EA%B3%BC-where%EC%9D%98-%EC%84%B1%EB%8A%A5-%EC%B0%A8%EC%9D%B4)
+[자세한 내용](https://5jisoo.github.io/posts/block-querydsl/#join---on-%EA%B3%BC-where%EC%9D%98-%EC%84%B1%EB%8A%A5-%EC%B0%A8%EC%9D%B4)
 {: .prompt-info }
 
 ### 2차 테스팅 방법

_posts/2024-10-01-ubuntu-ufw.md

@@ -86,7 +86,7 @@ UFW는 데비안 계열 및 다양한 리눅스 환경에서 작동되는 사용
 
 운영 서버에서는 포트 관리를 위해 http(80), https(443), ssh(22)번을 열어주었는데, 여기서 제 착각이 있었습니다.
 
-DNS 설정 당시, [이렇게](https://smwu-pochak.github.io/posts/dns-setting/#ubuntu-%EB%B0%A9%ED%99%94%EB%B2%BD-%ED%99%95%EC%9D%B8) 방화벽 설정을 해주었는데, 생각해보니 MySQL 서버 연결을 위해 3306 포트가 필요하다는 생각을 못했던 것입니다.. 🤦‍♀️🤦‍♀️
+DNS 설정 당시, [이렇게](https://5jisoo.github.io/posts/dns-setting/#ubuntu-%EB%B0%A9%ED%99%94%EB%B2%BD-%ED%99%95%EC%9D%B8) 방화벽 설정을 해주었는데, 생각해보니 MySQL 서버 연결을 위해 3306 포트가 필요하다는 생각을 못했던 것입니다.. 🤦‍♀️🤦‍♀️
 
 <br>