fix: fix some contents

_posts/2024-01-03-tagging-with-jpa.md

@@ -52,10 +52,10 @@ tags: [backend, spring, java, tagging, labeling, 백엔드, 스프링, 자바, 
 
 그래서 결국은 Mapping table을 활용해서 1:N과 N:1로 풀 수 밖에 없는데, 이 구조에서도 값 타입을 활용한 것처럼 Join 횟수를 줄인다던지 해서 성능 최적화를 진행할 수 있지 않을까 고민하게 되었습니다.   
 
-그러던 중 떠올린 것이 **캐싱**입니다. 저희 프로젝트 자체가 **가게의 Label을 활용해서 필터링하는 쿼리가 굉장히 빈번하게 사용되게 되는데 Label 종류가 그렇게 많지 않으므로 모든 경우의 수에 대해 캐싱해두고 전달하면 높은 성능을 낼 수 있을 것**이라고 생각합니다. 물론 아직, 정확한 성능 비교는 진행하지 않았지만 직접 구현해가면서 실제로 성능이 어떻게 차이나는지에 대해서도 나중에 포스팅을 작성해보겠습니다.   
-
-저는 이 캐싱 방식을 통한 성능 개선이 저희 프로젝트에 굉장히 잘 들어맞는 개선 방향이라고 생각이 든 이유가, 마침 **저희 프로젝트의 Label은 한번 지정해두게 되면 업데이트가 잘 되지 않는 성격**을 가지고 있습니다. **이러한 부분은 캐싱 업데이트의 주기 또한 늦춰주므로 효과적인 개선이 될 것**이라고 기대하고 있습니다.
+그러던 중 떠올린 것이 **캐싱**입니다. 저희 프로젝트 자체가 **가게의 Label을 활용해서 필터링하는 쿼리가 굉장히 빈번하게 사용되게 되는데 Label 종류가 그렇게 많지 않으므로 모든 경우의 수에 대해 캐싱해두고 전달하면 높은 성능을 낼 수 있을 것**이라고 생각합니다. 하지만 여기서 만약 캐시를 사용한다면 어떤 캐시를 사용할지, 만약 로컬 캐시로 직접 구현한다면 동기화 이슈는 어떻게 처리할 것인지에 대한 고민이 반드시 필요할 것 같습니다. 그리고 아직 정확한 성능 비교는 진행하지 않았지만 직접 구현해가면서 캐싱 했을 때와 안했을 때 실제로 성능이 어떻게 차이나는지에 대해서도 나중에 함께 포스팅으로 작성해보겠습니다.   
 
+저는 이 캐싱 방식을 통한 성능 개선이 저희 프로젝트에 굉장히 잘 들어맞는 개선 방향이라고 생각이 든 이유가, 마침 **저희 프로젝트의 Label은 한번 지정해두게 되면 업데이트가 잘 되지 않는 성격**을 가지고 있습니다. **이러한 부분은 캐싱 업데이트의 주기 또한 늦춰주므로 효과적인 개선이 될 것**이라고 기대하고 있습니다.   
+
 ## 마무리
 2024년 새해 첫 포스팅은 이렇게 프로젝트를 진행하며 제가 요즘 고민하고 있는 부분들을 짚어보는 시간을 가져봤습니다. 이런 고민을 통해 얻어낸 잠정적인 결론이 결국 정답이라고 확신할 수는 없지만, 이렇게 하나하나 근거있는 생각을 쌓아가다 보면 결국 정답에 도달할 수 있다고 생각합니다. 정말 정답에 도달하기 위해, 앞으로도 종종 이런 기술적인 고민과 관련된 포스팅을 게재해보도록 하겠습니다. 감사합니다.