[프로젝트 운영] 모두의 후기를 다시 보며 정리한 Redis, AI 요약, 인증 구조

들어가며

2026년 3월에는 모두의 후기 프로젝트를 다시 열어보는 시간이 많았다.

처음에는 포트폴리오에 넣기 위해 만든 프로젝트라고 생각했지만, 시간이 지나고 다시 보니 단순 구현 목록보다 더 중요한 부분이 보였다.
리뷰, 댓글, 북마크, 이미지 업로드, 인증, AI 요약 같은 기능들이 서로 어떻게 연결되어 있고, 운영 중에는 어떤 문제가 생길 수 있는지 다시 생각하게 되었다.

이번 글은 모두의 후기를 운영 관점에서 다시 보며 정리한 기록이다.

다시 본 인증 구조

모두의 후기는 Spring Security와 JWT를 기반으로 인증을 처리했다.

로그인 후 AccessToken과 RefreshToken을 발급하고, RefreshToken은 쿠키 기반으로 관리하는 구조였다. 당시에는 기능이 동작하는 데 집중했지만, 다시 보니 확인해야 할 지점이 많았다.

• AccessToken 만료 시간은 적절한가
• RefreshToken은 어디에 저장되는가
• Cookie의 path, SameSite, HttpOnly 설정은 의도와 맞는가
• 재발급 요청은 어떤 경로에서 허용되는가
• 인증 실패와 권한 실패 응답은 구분되는가

인증은 한 번 구현했다고 끝나는 영역이 아니었다.
브라우저 정책, 프론트엔드 요청 방식, 서버 보안 설정이 함께 맞아야 안정적으로 동작한다.

이전 프로젝트에서 JWT와 Cookie 문제를 여러 번 겪었기 때문에, 모두의 후기에서도 인증 흐름을 다시 점검해야겠다고 느꼈다.

Redis를 왜 사용할 수 있는가

프로젝트를 다시 보면서 Redis를 어디에 활용할 수 있을지도 고민했다.

리뷰 서비스에서는 조회수, 인기 게시글, 북마크 순위, 댓글 순위처럼 빠르게 정렬하거나 집계해야 하는 데이터가 생길 수 있다.

RDBMS만으로도 처리할 수 있지만, 모든 요청마다 정렬 쿼리를 실행하면 데이터가 늘어날수록 부담이 커질 수 있다.

이때 Redis의 ZSET을 활용하면 점수 기반 정렬 데이터를 관리하기 좋다.

예를 들면 다음과 같은 구조를 생각할 수 있다.

key: popular:reviews
member: reviewId
score: bookmarkCount 또는 viewCount

Redis는 메인 저장소라기보다는 빠른 조회와 랭킹 보조 저장소로 사용하는 것이 적절하다고 생각했다.

중요한 것은 Redis를 썼다는 사실이 아니라, 어떤 문제를 해결하기 위해 Redis가 필요한지 설명할 수 있어야 한다는 점이었다.

Gemini API 요약 기능 다시 보기

모두의 후기에는 Google Gemini API를 활용한 리뷰 요약 기능이 있었다.

처음에는 “AI가 긴 리뷰를 요약해준다”는 기능 자체가 흥미로웠다.
하지만 운영 관점에서 다시 보면 AI API는 외부 의존성이다.

고려해야 할 점은 다음과 같다.

• API 호출이 실패하면 어떻게 처리할 것인가
• 응답 시간이 길어지면 사용자는 어떻게 기다리는가
• 요약 결과를 매번 새로 생성할 것인가, 저장할 것인가
• 프롬프트 변경이 결과 품질에 어떤 영향을 주는가
• 비용과 호출 횟수는 어떻게 관리할 것인가

AI 기능도 결국 서버 기능이다.
응답이 느리거나 실패할 수 있고, 예외 처리와 저장 전략이 필요하다.

그래서 SummarizationService처럼 AI 호출 책임을 별도 서비스로 분리한 것은 좋은 방향이었다고 다시 느꼈다.

DTO와 Entity 책임 분리

프로젝트를 다시 볼 때 DTO와 Entity의 책임도 다시 생각했다.

Entity는 데이터베이스와 도메인 규칙을 표현하고, DTO는 API 요청과 응답을 표현한다.

처음에는 DTO가 많아지는 것이 번거롭다고 느꼈지만, 운영 관점에서는 오히려 분리하는 편이 안전하다.

DB 구조가 바뀌어도 API 응답 구조는 유지할 수 있고, 프론트엔드가 필요한 데이터만 내려줄 수 있다.

특히 리뷰 목록, 검색 결과, 마이페이지, 사용자별 리뷰 조회처럼 비슷하지만 조금씩 다른 응답이 필요한 경우 DTO 설계가 중요했다.

유지보수 관점에서 배운 점

프로젝트를 다시 보면서 가장 크게 느낀 것은, 기능을 만드는 것과 유지보수하는 것은 다르다는 점이었다.

처음에는 기능이 동작하면 성공이라고 생각했다.
하지만 시간이 지나고 다시 보면 다음 질문이 남는다.

• 이 코드는 어디를 수정해야 하는지 쉽게 알 수 있는가
• 실패했을 때 로그로 원인을 추적할 수 있는가
• 외부 API가 실패해도 서비스 전체가 무너지지 않는가
• 인증과 권한 처리가 일관적인가
• 응답 구조가 프론트엔드와 안정적으로 맞는가

이 질문에 답할 수 있어야 운영 가능한 프로젝트라고 말할 수 있을 것 같다.

마무리

2026년 3월에 모두의 후기를 다시 보면서, 포트폴리오 프로젝트를 실제 서비스처럼 바라보는 연습을 했다.

Redis, JWT, RefreshToken, Gemini API, DTO 구조 같은 기술들은 각각 따로 존재하는 것이 아니라 하나의 서비스 안에서 함께 움직인다.

앞으로 프로젝트를 설명할 때는 “무슨 기능을 만들었다”보다 “운영하면서 어떤 문제가 생길 수 있고, 그 문제를 어떻게 줄이려고 했는가”를 더 중심에 두려고 한다.