요약 — CodeQuest에서 문제 한 건을 공유하려면 강좌 전체를 열어야 하는 도메인 경계를 분석했다. 공유 단위를 문제로 낮추고 개별 공유·해제와 전체 공개 목록을 분리했다. 기능 구조 개선은 보존하되 사용률 상승을 측정한 성과로 쓰지 않으며 소유자/공유 대상/공개 권한, 해제 후 조회·직접 URL 인가의 검증 범위를 구분한다.

배경

• 프로젝트/기능: CodeQuest — 교수자가 문제를 만들어 강좌에 배치하는 문제 은행(ProblemBank)
• 환경: Spring Boot, Spring Data JPA, MySQL
• 왜 문제였나: 운영 중인 서비스의 고도화 과제로 "콘텐츠 재사용성"이 올라왔는데, 정작 재사용하고 싶은 단위와 공유할 수 있는 단위가 어긋나 있었다

문제 (증상)

• 교수 A가 공들여 만든 문제 한 건을 교수 B에게 주고 싶어도 방법이 없다
• 강좌 단위로만 공유가 되니, 문제 하나를 주려면 강좌 전체를 열어야 한다 — 다른 문제·수강생 구성까지 딸려 간다
• 강좌 전체를 공유해야 하는 방식은 문제 한 건만 재사용하려는 요구에 맞지 않았다. 공유 기능의 사용률·재작성 건수 데이터가 없으므로 아무도 사용하지 않았다는 운영 지표로 단정하지 않는다.

원인 분석

• ProblemBank가 Course를 참조하고 Problem 목록을 소유하는 구조 — 즉 문제는 강좌에 종속돼 있었다
• 공유 기능을 강좌 위에 얹었으니 공유의 최소 단위가 자연히 강좌가 됐다
• 문제는 공유 단위가 요구보다 크게 잡혀 있었던 것이다. 공유 API 수를 늘리기 전에 강좌 소유 관계와 문제 공유 관계의 경계를 분리했다.

해결

공유의 최소 단위를 문제로 낮추고, 그 단위에 맞는 API를 폈다.

• 개별 공유와 전체 공개를 다른 목록으로 분리했다. 둘을 한 목록에 섞으면 "나에게 공유된 것"과 "누구나 쓰는 것"의 의미가 겹쳐 권한 판단이 흐려진다
• 전체 공개 목록이 생기면서 기본 제공 문제를 쌓아둘 자리가 만들어졌다 — 신규 강좌가 빈손으로 시작하지 않는다

결과

• 문제 한 건 단위로 주고받을 수 있게 되어, 강좌를 열지 않고도 콘텐츠가 오간다