카테고리별 초기 문제 번호 관리 방식을 개선한다 by bricksky · Pull Request #295 · maeil-mail/maeil-mail-be

bricksky · 2026-01-08T02:41:01Z

close 카테고리별 초기 문제 번호 관리 방식을 개선한다 #294
- QuestionCategory Enum에 초기 문제 번호(initialSequence) 필드 추가 및 관리 책임 위임
- Subscribe 엔티티 내 매직 넘버(15L) 제거 및 생성자 로직 단순화

github-actions · 2026-01-08T02:42:53Z

Test Results

164 tests 163 ✅ 7s ⏱️
48 suites 1 💤
48 files 0 ❌

Results for commit 3d7c429.

♻️ This comment has been updated with latest results.

kunsanglee · 2026-01-08T03:05:40Z

안녕하세요 bricksky님 처음 뵙겠습니다. 이건상이라고 합니다. 🥳
제가 매일메일 프로젝트에서 손을 뗀지 너무 오래 되었는데, PR 알림을 받으니 엄청 반갑네요!
제가 하늘이한테 도움이 너무 안 됐는데 함께 해주셔서 감사합니다.
매일메일 프로젝트 잘 부탁드립니다! 👍

kunsanglee · 2026-01-08T03:13:51Z

 public enum QuestionCategory {

-    FRONTEND("FE"), BACKEND("BE");
+    FRONTEND("FE", 0L), BACKEND("BE", 15L);


QuestionCategory enum에 초기 질문지 순서를 캡슐화 하셨군요!
개인적인 생각으로는 프론트엔드, 백엔드 카테고리의 초기 질문지 순서를 직접 가지는 것이 실제 DB 데이터에 변경이 생겼을 때, 정합성이 맞지 않을 수 있겠다는 생각이 들어요.
어떻게 개선할 수 있을지 같이 얘기해보면 재밌겠네요 답변 기다리겠습니다! 👍 .cc @le2sky

안녕하세요 건상님! 꼼꼼한 리뷰 감사합니다.

사실 말씀해 주시기 전까지는 DB 데이터가 변경될 때의 문제까지는 미처 생각하지 못했습니다.
덕분에 놓치고 있던 부분을 깨달았네요. 😅

코멘트를 보고 고민을 좀 해봤는데, Enum에 값을 두는 대신 서비스단에서 DB를 조회해 동적으로 값을 받아오는 방식은 어떨까 생각이 들었습니다. 다만, 매번 DB를 조회하는 방식이 과연 이 상황에서 최선의 리팩터링일지는 잘 모르겠습니다🥹

혹시 이 방향으로 수정하는 것에 대해 어떻게 생각하시나요? 하늘님(@le2sky) 의견도 궁금합니다!

저는 해당 변경 사항을 긍정적으로 생각하고 있어요. 👍👍

개인적인 생각으로는 프론트엔드, 백엔드 카테고리의 초기 질문지 순서를 직접 가지는 것이 실제 DB 데이터에 변경이 생겼을 때, 정합성이 맞지 않을 수 있겠다는 생각이 들어요.

Enum에 값을 두는 대신 서비스단에서 DB를 조회해 동적으로 값을 받아오는 방식은 어떨까 생각이 들었습니다.

DB에 카테고리 별 질문 시작점을 따로 저장한다는 것으로 이해했는데 맞을까요?
만약 그렇다면, 15라는 값이 식별자를 의미하는 것이 아니라 순서를 의미하기 때문에 15번째 질문지가 저희가 의도했던 질문지가 아니게 될 경우에 문제가 발생할 것 같아요.

백엔드 질문지가 15번부터 시작했던 맥락을 공유드리자면, 서비스 초기에 테스트용 질문지(퀄리티가 낮음)를 넣어놨었는데요. 사용자가 생기면서, 새로운 사용자는 퀄리티가 높은 질문지부터 전달해야겠다고 판단했었습니다. 그래서, 백엔드 시퀀스를 점프시키는 결정을 내렸었어요.

최근 백엔드 질문지 피드백 중에 초반에 JPA 관련 질문지가 연속으로 많이 온다는 피드백이 있었어요.
만약, 연속된 JPA 질문의 끝이 20번째라고 하면, 20보다 시퀀스가 작은 사용자의 시퀀스를 20으로 점프시킨 이후에 기본 설정값을 20으로 수정하면 된다고 생각하고 있었어요. (기존 사용자는 중복이 없도록)

결국 문제의 핵심은 아래와 같다고 저는 생각하는데요.

기존 사용자는 중복 질문지를 받지 않아야 하고, (한 질문지는 전체 사이클이 돈 뒤에 그 질문지를 다시 받는다.)

질문의 시작점은 변경될 수 있다. ex) 서비스를 구독하고 4일동안 JPA 질문만 온다면 사용자 경험이 안좋을 수 있다. 혹은, 관리자가 질문의 시작점이 마음에 들지 않아서 바꿔야 한다.

실제 DB 데이터에 변경이 발생했을 때, 발생하는 이슈들 ex) 백엔드 질문지가 한개 사라져서 15번째가 의도한 질문지가 아니게 되었다.

이걸 풀 수 있는 이상적인 설계가 있을까요?
제가 과하게 해석했거나, 생각에 부족함이 있다면 피드백 부탁드려요. 🙇🏻‍♂️

안녕하세요 하늘님! 상세한 맥락 공유 정말 감사합니다. 단순히 매직 넘버를 없애는 기술적 이슈로만 접근했었는데,
15번이라는 숫자에 '초기 컨텐츠 퀄리티 관리'와 '사용자 경험 확보' 라는 중요한 비즈니스 의도가 담겨있는지는 미쳐 몰랐습니다!

말씀해주신 내용을 바탕으로 내용을 정리해보면,

시작점은 운영 상황(퀄리티, 피드백)에 따라 유연하게 변경될 수 있어야 한다.

단순히 DB에 있는 첫 번째 질문을 가져오는 것이 아니라, '지정된 유효 시작값'이 필요하다.

시작점이 변경될 때, 기존 유저들의 시퀀스도 함께 점프되어야 한다. (예: 17번을 보고 있던 유저를 20번으로 이동)

위의 요구사항을 모두 충족하면서 정합성을 지키기 위해, 별도의 설정 테이블(CategoryPolicy)을 만들어서 관리하는 방식은
어떤지 제안드리고싶습니다!

[제안하는 설계]

CategoryPolicy 테이블 생성: category(PK), defaultStartSequence 컬럼을 둡니다. (초기 데이터: BACKEND=15)

구독 시 로직: 신규 구독자는 이 테이블의 defaultStartSequence 값을 조회하여 nextQuestionSequence에 주입합니다.

운영 로직: 만약 백엔드 시작점을 20으로 변경한다면, CategoryPolicy 값을 업데이트함과 동시에 "현재 시퀀스가 20 미만인 백엔드 구독자들을 일괄 20으로 업데이트" 하는 로직을 수행합니다.

이렇게 하면 질문 데이터가 변경되어도 설정값은 분리되어 있어 안전하고,
하늘님께서 우려하신 "의도치 않은 질문 발송"이나 "중복 발송" 없이 유연하게 시작점을 관리할 수 있을 것 같다고 생각합니다.

이 방향으로 설계를 변경하여 구현해보면 어떨까요? 괜찮으시다면 바로 작업 진행해보겠습니다! 😀

개인적인 생각으로는 프론트엔드, 백엔드 카테고리의 초기 질문지 순서를 직접 가지는 것이 실제 DB 데이터에 변경이 생겼을 때, 정합성이 맞지 않을 수 있겠다는 생각이 들어요.

좋은 의견 제안해주셔서 감사합니다! 이 대화의 시작점은 위와 같아요. 카테고리의 시퀀스 넘버가 의미하는 바는 '순서'이며, 시퀀스가 전체 데이터의 수를 넘겼을 때는 처음부터 전달되는 롤링 방식이에요. 제가 생각했을 때, 이를 토대로 DB 데이터에 변경이 생겼을 때 발생할 수 있는 유일한 문제는 다음과 같다고 생각했어요.

DB에 존재하는 질문지 데이터의 수나 질문지의 내용이 변경되었을 때, 원했던 질문지가 전달되지 않는다.

제안해주신 설계는 "실제 DB 데이터에 변경이 발생했을 때, 발생하는 이슈들 ex) 백엔드 질문지가 한개 사라져서 15번째가 의도한 질문지가 아니게 되었다." 이 요구사항을 만족하지 않다고 생각했어요! 왜냐하면, 결국 CategoryPolicy.defaultStartSequence의 값은 순서를 의미하기 때문입니다.(제가 순서로 이해했는데, 맞을까요?)

제안해주신 설계에서 defaultStartSequence 컬럼 대신, question.id로 설정하여 외래키 제약을 추가하면, 의도했던 시작점 질문지가 삭제되는 경우를 해결할 수 있을거라고 생각하는데, 동현님 생각은 어떠신가요? (질문지 자체의 내용이 다른 질문지랑 바뀌는 경우는 해결할 수 없지만, 그런 경우는 현실적으로 없을 것 같아요.)

bricksky · 2026-01-08T06:24:21Z

안녕하세요 bricksky님 처음 뵙겠습니다. 이건상이라고 합니다. 🥳 제가 매일메일 프로젝트에서 손을 뗀지 너무 오래 되었는데, PR 알림을 받으니 엄청 반갑네요! 제가 하늘이한테 도움이 너무 안 됐는데 함께 해주셔서 감사합니다. 매일메일 프로젝트 잘 부탁드립니다! 👍

안녕하세요 kunsanglee님, 반갑게 맞아주셔서 감사합니다!

매일메일 프로젝트에 관심이 많았는데, 좋은 기회로 기여할 수 있게 되어 영광입니다:)
부족하지만 프로젝트 성장에 도움이 될 수 있도록 최선을 다하겠습니다. 앞으로 잘 부탁드립니다! 🙇‍♂️

le2sky

동현님, 리뷰가 늦어서 죄송합니다. 🙇🏻‍♂️
카테고리 관리 방식에 대한 제 생각 남겨놨어요. 해당 PR과 관계없는 커밋이 존재하는 것 같아서 RC를 드렸어요. enum으로 변경된 부분은 긍정적으로 생각합니다!

le2sky · 2026-01-17T06:04:31Z

 public enum QuestionCategory {

-    FRONTEND("FE"), BACKEND("BE");
+    FRONTEND("FE", 0L), BACKEND("BE", 15L);


저는 해당 변경 사항을 긍정적으로 생각하고 있어요. 👍👍

개인적인 생각으로는 프론트엔드, 백엔드 카테고리의 초기 질문지 순서를 직접 가지는 것이 실제 DB 데이터에 변경이 생겼을 때, 정합성이 맞지 않을 수 있겠다는 생각이 들어요.

Enum에 값을 두는 대신 서비스단에서 DB를 조회해 동적으로 값을 받아오는 방식은 어떨까 생각이 들었습니다.

DB에 카테고리 별 질문 시작점을 따로 저장한다는 것으로 이해했는데 맞을까요?
만약 그렇다면, 15라는 값이 식별자를 의미하는 것이 아니라 순서를 의미하기 때문에 15번째 질문지가 저희가 의도했던 질문지가 아니게 될 경우에 문제가 발생할 것 같아요.

백엔드 질문지가 15번부터 시작했던 맥락을 공유드리자면, 서비스 초기에 테스트용 질문지(퀄리티가 낮음)를 넣어놨었는데요. 사용자가 생기면서, 새로운 사용자는 퀄리티가 높은 질문지부터 전달해야겠다고 판단했었습니다. 그래서, 백엔드 시퀀스를 점프시키는 결정을 내렸었어요.

최근 백엔드 질문지 피드백 중에 초반에 JPA 관련 질문지가 연속으로 많이 온다는 피드백이 있었어요.
만약, 연속된 JPA 질문의 끝이 20번째라고 하면, 20보다 시퀀스가 작은 사용자의 시퀀스를 20으로 점프시킨 이후에 기본 설정값을 20으로 수정하면 된다고 생각하고 있었어요. (기존 사용자는 중복이 없도록)

결국 문제의 핵심은 아래와 같다고 저는 생각하는데요.

기존 사용자는 중복 질문지를 받지 않아야 하고, (한 질문지는 전체 사이클이 돈 뒤에 그 질문지를 다시 받는다.)

질문의 시작점은 변경될 수 있다. ex) 서비스를 구독하고 4일동안 JPA 질문만 온다면 사용자 경험이 안좋을 수 있다. 혹은, 관리자가 질문의 시작점이 마음에 들지 않아서 바꿔야 한다.

실제 DB 데이터에 변경이 발생했을 때, 발생하는 이슈들 ex) 백엔드 질문지가 한개 사라져서 15번째가 의도한 질문지가 아니게 되었다.

이걸 풀 수 있는 이상적인 설계가 있을까요?
제가 과하게 해석했거나, 생각에 부족함이 있다면 피드백 부탁드려요. 🙇🏻‍♂️

le2sky · 2026-01-17T06:06:43Z

+public record MemberRequest(
+        @NotBlank(message = "OAuth Access Token은 필수입니다.")
+        String oauthAccessToken) {


해당 변경 분은 해당 PR에 포함되는 이유가 있을까요?? 👀

다른 브랜치에서 작업하던 내용이 실수로 포함되었네요 😅
해당 파일은 변경 전으로 되돌렸습니다!

sonarqubecloud · 2026-01-20T06:14:03Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

le2sky

동현님 고생 많으셨습니다! 👍👍
제안해주신 작업 해주셔도 좋을것 같아요! 다만, 운영 로직까지는 필요없을 것 같아요. 시퀀스 수정 쿼리는 금방 작성하기도 하고, 어드민 페이지 수정 리소스 들일 정도로 빈번히 사용되는 기능은 아니라고 생각했기 때문이에요. 그리고, 보완 사항 남겨놨으니 확인 부탁드립니다. 🙇🏻‍♂️

le2sky · 2026-01-26T13:45:02Z

 public enum QuestionCategory {

-    FRONTEND("FE"), BACKEND("BE");
+    FRONTEND("FE", 0L), BACKEND("BE", 15L);


개인적인 생각으로는 프론트엔드, 백엔드 카테고리의 초기 질문지 순서를 직접 가지는 것이 실제 DB 데이터에 변경이 생겼을 때, 정합성이 맞지 않을 수 있겠다는 생각이 들어요.

좋은 의견 제안해주셔서 감사합니다! 이 대화의 시작점은 위와 같아요. 카테고리의 시퀀스 넘버가 의미하는 바는 '순서'이며, 시퀀스가 전체 데이터의 수를 넘겼을 때는 처음부터 전달되는 롤링 방식이에요. 제가 생각했을 때, 이를 토대로 DB 데이터에 변경이 생겼을 때 발생할 수 있는 유일한 문제는 다음과 같다고 생각했어요.

DB에 존재하는 질문지 데이터의 수나 질문지의 내용이 변경되었을 때, 원했던 질문지가 전달되지 않는다.

제안해주신 설계는 "실제 DB 데이터에 변경이 발생했을 때, 발생하는 이슈들 ex) 백엔드 질문지가 한개 사라져서 15번째가 의도한 질문지가 아니게 되었다." 이 요구사항을 만족하지 않다고 생각했어요! 왜냐하면, 결국 CategoryPolicy.defaultStartSequence의 값은 순서를 의미하기 때문입니다.(제가 순서로 이해했는데, 맞을까요?)

제안해주신 설계에서 defaultStartSequence 컬럼 대신, question.id로 설정하여 외래키 제약을 추가하면, 의도했던 시작점 질문지가 삭제되는 경우를 해결할 수 있을거라고 생각하는데, 동현님 생각은 어떠신가요? (질문지 자체의 내용이 다른 질문지랑 바뀌는 경우는 해결할 수 없지만, 그런 경우는 현실적으로 없을 것 같아요.)

le2sky · 2026-01-26T13:46:48Z


    @PostMapping("/member")
-    public ResponseEntity<Void> createMember(@RequestBody MemberRequest request) {
+    public ResponseEntity<Void> createMember(@Valid @RequestBody MemberRequest request) {


이번처럼 다른 PR 커밋이 포함된 경우에는, 커밋 롤백을 하시는 게 깔끔할 것 같아요! 혹시 권한 문제가 있다면 편히 말씀 주세요 🙇🏻‍♂️

방금 확인했습니다!
넵! 추후에 같은 문제 발생한다면, 롤백으로 진행하겠습니다:)

refactor: QuestionCategory 초기 시퀀스 필드 추가 및 관련 로직 간소화

0d5d73b

bricksky requested review from kunsanglee and le2sky January 8, 2026 02:41

bricksky self-assigned this Jan 8, 2026

bricksky added the 프로덕트:매일메일 매일메일 코어 구현 및 개선 label Jan 8, 2026

kunsanglee reviewed Jan 8, 2026

View reviewed changes

feat: 회원 요청에 대한 유효성 검증 추가

79090c5

le2sky requested changes Jan 17, 2026

View reviewed changes

refactor: 회원 요청의 유효성 메시지 제거

3d7c429

bricksky requested a review from le2sky January 22, 2026 01:45

le2sky approved these changes Jan 26, 2026

View reviewed changes

le2sky merged commit 5f5eeaf into main Jan 26, 2026
3 checks passed

le2sky deleted the 294 branch January 26, 2026 13:54

le2sky unassigned bricksky Jan 26, 2026

le2sky removed the 프로덕트:매일메일 매일메일 코어 구현 및 개선 label Jan 26, 2026

bricksky self-assigned this Feb 10, 2026

le2sky unassigned bricksky Mar 3, 2026

Conversation

bricksky commented Jan 8, 2026

Uh oh!

github-actions Bot commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

kunsanglee commented Jan 8, 2026

Uh oh!

kunsanglee Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bricksky commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

le2sky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Jan 20, 2026

Quality Gate passed

Uh oh!

le2sky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Jan 8, 2026 •

edited

Loading

kunsanglee Jan 8, 2026 •

edited

Loading

bricksky commented Jan 8, 2026 •

edited

Loading