[데브코스] Spring Boot 인증·인가(Auth) (36강) - 글·댓글 권한 체크 로직을 컨트롤러에서 엔티티로 옮긴 이유
[데브코스] Spring Boot 인증·인가(Auth) 기초
목록 보기
33/49
36강에서는 글(Post)과 댓글(PostComment)의 권한 체크 로직을
컨트롤러에서 제거하고 엔티티로 이동하는 리팩토링을 진행했다.
겉으로 보면 단순히 코드 위치만 바뀐 것 같지만,
실제로는 역할 분리 + 객체지향 설계 원칙을 적용한 중요한 변화다.
1️⃣ 먼저 개념 정리: 인증 vs 인가
강의에서 먼저 짚고 간 개념이 있다.
🔐 인증(Authentication)
“너 누구야?”
- 사용자가 누구인지 확인
- 로그인, 토큰 검증, API Key 검증
- Rq.getActor()가 담당하는 영역
🔑 인가(Authorization)
“너 이거 할 수 있어?”
- 특정 행동(수정, 삭제 등)을 할 권한이 있는지 확인
- 비즈니스 규칙에 해당
👉 이번 강의의 핵심은
인가 로직을 어디에 두는 게 맞느냐다.
2️⃣ 기존 구조: 컨트롤러에 인가 로직이 있었다
리팩토링 전 컨트롤러 코드는 이런 형태였다.
Member actor = rq.getActor();
Post post = postService.findById(id).get();
if (!actor.equals(post.getAuthor()))
throw new ServiceException("403-1", "글 삭제 권한이 없습니다.");문제점은 뭘까?
- 컨트롤러가 권한 규칙을 직접 알고 있음
- 같은 로직이
- 글 수정
- 글 삭제
- 댓글 수정
- 댓글 삭제
에서 계속 반복됨
👉 중복 + 역할 과다
3️⃣ 컨트롤러는 원래 무슨 역할일까?
컨트롤러의 역할은 명확하다.
- 요청을 받는다
- 필요한 객체를 준비한다
- 흐름을 연결한다
즉,
❌ 규칙 판단
❌ 비즈니스 결정
이런 건 컨트롤러 책임이 아니다.
4️⃣ 리팩토링 결과: 인가 로직을 엔티티로 이동
36강에서는 권한 체크 로직을 엔티티 내부로 이동했다.
📌 Post 엔티티
public void checkActorCanModify(Member actor) {
if (!author.equals(actor))
throw new ServiceException("403-1", "글 수정 권한이 없습니다.");
}
public void checkActorCanDelete(Member actor) {
if (!author.equals(actor))
throw new ServiceException("403-2", "글 삭제 권한이 없습니다.");
}📌 PostComment 엔티티
public void checkActorCanModify(Member actor) {
if (!author.equals(actor))
throw new ServiceException("403-1", "댓글 수정 권한이 없습니다.");
}
public void checkActorCanDelete(Member actor) {
if (!author.equals(actor))
throw new ServiceException("403-2", "댓글 삭제 권한이 없습니다.");
}5️⃣ 컨트롤러는 어떻게 바뀌었을까?
이제 컨트롤러는 묻기만 한다.
Member actor = rq.getActor();
Post post = postService.findById(id).get();
post.checkActorCanDelete(actor);
postService.delete(post);- “삭제해도 돼?” → 엔티티에게 위임
- 컨트롤러는 결과만 신경 씀
👉 훨씬 읽기 쉬워지고 역할이 명확해졌다.
6️⃣ 왜 엔티티에 인가 로직을 두는 게 맞을까?
이 질문이 핵심이다.
✔ 이유 1: 규칙의 주인은 엔티티다
- “글은 누가 수정할 수 있는가?”
- “댓글은 누가 삭제할 수 있는가?”
이건 Post, PostComment 자체의 규칙이다.
👉 규칙은 객체가 스스로 알고 있어야 한다.
✔ 이유 2: 중복 제거
컨트롤러마다 있던
if (!actor.equals(author)) ...이제 한 군데에만 존재한다.
✔ 이유 3: 변경에 강해진다
만약 정책이 바뀐다면?
“관리자는 모든 글을 삭제할 수 있다”
이제 바꿀 곳은?
- ❌ 모든 컨트롤러
- ⭕ 엔티티 메서드 하나
7️⃣ 서비스 vs 엔티티, 어디까지가 맞을까?
강의에서 짚은 기준은 이거다.
📦 서비스(Service)
- 여러 엔티티를 엮는 로직
- 트랜잭션 단위 작업
- 흐름 제어
🧱 엔티티(Entity)
- 자신의 상태와 규칙
- 자신에 대한 판단
- “이 행동이 가능한가?”
👉 인가 로직은 엔티티에 더 가깝다.
8️⃣ 인증/인가 흐름 다시 정리
전체 흐름을 정리하면 이렇게 된다.
- Rq가 인증(Authentication)을 담당
→ “이 사용자는 누구인가?” - 엔티티가 인가(Authorization)를 담당
→ “이 사용자가 이 행동을 할 수 있는가?”
각자 역할이 분리됐다.
9️⃣ 이 강의의 진짜 핵심
36강의 핵심은 이 문장이다.
“비즈니스 규칙은 컨트롤러가 아니라
그 규칙의 주인인 객체가 가져야 한다.”
🔟 최종 요약
- 인증과 인가는 다르다
- 인증은 Rq, 인가는 엔티티 책임
- 컨트롤러는 흐름만 담당
- 권한 규칙은 엔티티로 이동
- 중복 제거 + 객체지향 설계 강화
이 리팩토링은 단순한 코드 이동이 아니라
“어디에 어떤 책임을 둘 것인가”에 대한 연습이다.
