📌“리뷰는 단순 댓글이 아니다 – ReviewService로 본 권한 기반 사용자 피드백 시스템”

🗓 2025년 5월

✍️ by 박찬희

---

🧭 개발 동기: 리뷰는 신뢰 기반의 콘텐츠이다

많은 온라인 강의 플랫폼에서 리뷰는 단순한 평가 기능처럼 보이지만,

실제론 사용자의 신뢰, 강사의 평판, 서비스 성장의 핵심 축이다.

이번에 구현한 ReviewService는 단순한 댓글 저장 기능이 아닌,

“수강자만 작성 가능 + 중복 리뷰 방지 + 작성 시간 포맷 처리 + 구조적 확장성 확보”

를 목표로 설계된 리뷰 관리 모듈이다.

---

🎯 핵심 설계 요약

기능	설계 방향
리뷰 조회	작성일자 포맷 포함하여 사용자 친화적으로 제공
리뷰 등록	SRP 기반, 중복 없는 재사용 가능한 구조
리뷰 작성 권한 체크	수강 여부 + 중복 작성 여부 이중 검증
DAO 분리	DB 작업과 서비스 로직을 명확히 분리
예외/트랜잭션 처리	추후 확장 가능 구조 확보 (Spring 대응 고려)

---

🔧 사용 기술 스택

항목	내용
언어	Java 17
데이터베이스	MySQL
ORM 방식	직접 DAO 방식 (MyBatis 아님)
시간 처리	LocalDateTime + DateTimeFormatter
구조 패턴	Service Layer + DAO + DTO
예외 처리	RuntimeException 기반, 글로벌 예외 전파 고려

---

🧠 주요 로직 구현

1️⃣ 리뷰 조회: getReviewsByLectureId

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
for (ReviewDTO dto : list) {
    if (dto.getCreatedAt() != null) {
        dto.setCreatedAtFormatted(dto.getCreatedAt().format(formatter));
    } else {
        dto.setCreatedAtFormatted("");
    }
}

✅ 서버 단에서 날짜 포맷 처리 → 프론트는 단순 출력만 담당

✅ null 방어로 예외 안전성 확보

📌 사용자 UX 관점에서 “리뷰 시간 표시”는 콘텐츠 신뢰도에 큰 영향을 준다.

---

2️⃣ 리뷰 등록: insertReview & addReview

public void addReview(ReviewDTO dto) {
    reviewDAO.insertReview(dto);
}

• addReview()는 insertReview()의 별칭(alias) → 동일 기능의 명확한 용도 분리
• SRP 원칙 적용: 리뷰 등록 외 로직 없음 → 유지보수 용이

✅ 향후 API 구조가 바뀌더라도 내부 로직은 그대로 유지 가능

---

3️⃣ 리뷰 작성 권한 체크: canWriteReview

public boolean canWriteReview(int userId, int lectureId) {
    return hasEnrolled(userId, lectureId) && !hasReviewed(userId, lectureId);
}

• 수강 여부 + 중복 여부 이중 체크
• 비로그인 사용자의 리뷰 작성 시도를 완전히 차단

✅ 실무에서는 리뷰 조작 방지와 사용자 경험 보호를 위한 필수 설계 포인트

---

4️⃣ 구조 분리: DAO 기반 계층화 설계

this.reviewDAO = new ReviewDAO(); // DAO 주입

계층	역할
Controller	사용자 요청 분기 (예: /review/register)
Service (ReviewService)	비즈니스 판단 (권한, 중복 여부, 포맷 처리 등)
DAO (ReviewDAO)	DB 작업 (insert, select, count 등)
DTO (ReviewDTO)	데이터 전달 객체

✅ 유지보수 시 서비스 로직만 테스트 가능

✅ DB 변경이 있어도 DAO만 수정하면 됨 → 계층 독립성 확보

---

🔁 예외 처리 및 트랜잭션 전략

• 현재 트랜잭션은 SqlSession 기반 autocommit 구조 → 단순 작업에는 충분
• 복합 처리 (리뷰 등록 + 로그 기록 등)에선 @Transactional로 전환 필요

try {
   ...
} catch (Exception e) {
   throw new RuntimeException("❌ 리뷰 등록 중 오류 발생", e);
}

▶ 로그 메시지는 로깅 시스템 연동을 위한 출발점이며,

향후 AOP 기반 글로벌 예외 핸들링 구조로도 확장 가능

---

📈 실무 설계 포인트 & 리뷰 패턴화

기능 요소	실무 전략
사용자 권한 체크	강의 수강 여부는 enrollment 테이블 기준
중복 리뷰 방지	lectureId + userId 조합 유일성 체크
포맷 처리 책임	뷰단이 아닌 서비스단에서 처리하여 일관성 확보
테스트 설계	canWriteReview()와 getReviewsByLectureId()는 단위 테스트 핵심 대상
확장 고려	추천 리뷰 정렬, 첨부 이미지 등 확장 시 구조 유지 가능

---

📚 개선 및 확장 아이디어

항목	제안
별점 필드 추가	rating 필드 포함하여 1~5점 기준 정량 평가
리뷰 신고 기능	부적절한 리뷰 대응을 위한 신고/차단 API 도입
관리자 검토 기능	리뷰 등록 후 관리자 승인 구조 도입 가능
페이징 처리	리뷰 수 많을 경우, offset 기반 LIMIT 처리 도입
리뷰 통계 API	평균 평점, 리뷰 수 등을 제공하는 통계 API 구성

✅ 기능 요약

기능	설명
리뷰 조회	작성일 포맷 포함 리스트 반환
리뷰 등록	DTO 기반 insert 처리, alias 메서드 포함
권한 검사	수강 여부 + 기존 작성 여부 체크
계층 구조	Service ↔ DAO ↔ DB 분리 설계
예외 처리	RuntimeException으로 예외 추상화 및 확장 여지 확보

---

🧾 회고 – 리뷰란, 유저와 콘텐츠 사이의 인터랙션이다

이번 ReviewService 구현을 통해 느낀 점은 단순히 데이터를 저장하는 것이 아닌,

“콘텐츠 소비 이후의 행동을 정제된 로직으로 기록하는 것”이라는 점이었다.

• 리뷰는 유저의 의견이자 강사와 플랫폼의 피드백 수단
• 권한 체크, 중복 방지, 포맷 통일화는 신뢰성과 품질의 핵심
• 계층 분리, 테스트 가능성, 확장성까지 고려해야 실무에서 지속 가능한 코드가 된다