fix: 포스팅에서 잘못된 내용 수정

_posts/2024-07-31-DOORE 서비스의 고민을 정리하며.md

@@ -92,9 +92,9 @@ hidden: false
 
 ---
 
-직위(권한) 코드를 짜는데 굉장히 심혈을 기울였던 것 같다. 처음에는 늘 이용해왔던 것처럼 스프링 시큐리티를 이용하여 권한을 부여하려 했다. 하지만 서비스가 확장될 가능성을 고려하여 `studyRole`, `teamRole` 등 역할별 테이블을 따로 두었던 것과 권한이 메서드 별로 매우 복잡하기 때문에 시큐리티를 활용하는 방법보다 토큰에서 `member` 정보를 추출하여 DB에 저장되어있는 `role`을 확인하는 방법이 더욱 적절하다고 느꼈다. 그래서 시큐리티 개발하던 중 방향을 틀었다. 추가로 커스텀 어노테이션을 만들어서 메서드에서 사용하기 쉽게 하였다.
+직위(권한) 코드를 짜는데 굉장히 심혈을 기울였던 것 같다. 처음에는 늘 이용해왔던 것처럼 스프링 시큐리티를 이용하려 했다. 하지만 서비스가 확장될 가능성을 고려하여 `studyRole`, `teamRole` 등 역할별 테이블을 따로 두었던 것과 권한이 메서드 별로 매우 복잡하기 때문에 시큐리티를 활용하는 방법보다 토큰에서 `member` 정보를 추출하여 DB에 저장되어있는 `role`을 확인하는 방법이 더욱 적절하다고 느꼈다. 또한 개인정보 관리를 위해 두레서비스에서 인증은 하지 않고 인가만 하기로 결정했던 점도 있다. 추가로 커스텀 어노테이션을 만들어서 메서드에서 사용하기 쉽게 하였다.
 
-하지만 다시 생각해보면 `studyRole`, `teamRole`에 늘어날 역할이 별로 없는데 하나의 엔티티로 구성한 점, 다른 도메인 기능이 개발 되었을 때 그에 맞는 `Role`이 필요하다면 또 엔티티를 만들어야 한다는 점 등 현재 구조에 개선할 부분이 있어 보인다. 만약 DB가 개편된다면 스프링 시큐리티를 활용해 리팩토링하고 싶다. 
+다시 생각해보면 `studyRole`, `teamRole`에 늘어날 역할이 별로 없는데 하나의 엔티티로 구성한 점, 다른 도메인 기능이 개발 되었을 때 그에 맞는 `Role`이 필요하다면 또 엔티티를 만들어야 한다는 점 등 현재 구조에 개선할 부분이 있어 보인다.
 
 ### 6. 메서드, 잘 작성하였는가?