2026 W04 주간회고

지난주 주간 보고

[2026-01-19 주간 보고]

항목명 설명 검증 방법 🔲✅❌
PlanReadBase 단독 조회 가능 읽기 모델 조회 시 Plan Aggregate 인스턴스를 생성하지 않아도 동작해야 한다 Read API에서 Aggregate 생성 코드가 없는지 코드 리뷰 ✅
Read Model ↔ Aggregate 의존성 단절 Projector / Read DTO 어디에서도 Plan(aggregate)을 참조하지 않는다 grep / IDE 검색으로 import 의존성 확인 ✅
CourtSelectionPolicy Value Object 공유 CourtSelectionPolicy 로직이 Aggregate / Projector 양쪽에서 동일하게 사용된다 동일 클래스/모듈을 양쪽에서 import 하는지 확인 ✅
Court 필터링이 Projector에서 수행됨 courtModels 필터링 로직이 DB 쿼리나 Aggregate가 아닌 Projector에 존재 Projector 코드 위치 확인 ✅
Read 쿼리에 정책 로직 없음 DB query 단계에는 court 정책 / 도메인 조건문이 없다 Prisma query / aggregation 코드 리뷰 ✅
Detail 조회에서만 courtModels include Plan 목록 조회 시 courtModels를 포함하지 않는다 List API 응답 payload / query include 확인 ❌ 프로젝션 옵션 인자 추가함
PlanCommonRead / PlanDetailRead DTO 분리 공통/상세 DTO가 명확히 분리되어 있다 DTO 정의 파일 확인 ✅
Projector는 순수 함수 Projector가 외부 상태(DB, 서비스)를 참조하지 않는다 생성자/의존성 주입 여부 확인 ✅
CourtSelectionPolicy 불변식 강제 ALL / INCLUDE / EXCLUDE 정책 제약이 코드로 강제된다 생성자 또는 팩토리에서 validation 확인 ✅
INCLUDE 정책에서 ids 필수 INCLUDE + 빈 배열이 허용되지 않는다 unit test 또는 runtime validation ✅
ALL 정책에서 ids 항상 빈 배열 ALL 정책에서 ids가 존재하면 에러 또는 무시된다 unit test ✅
EXCLUDE + 빈 배열 = ALL 동치 EXCLUDE 정책에서 ids가 비어있을 때 ALL과 동일하게 동작 unit test ✅
numberOfWeeks 최대 6 제한 LessonPlan / LongTermPlan에서 6 초과 불가 Aggregate 생성 시 validation 테스트 ❌사용하지않음
LessonSetting 마이그레이션 lesson_settings 컬렉션이 생성되고 academyId 기준으로 조회된다 DB 컬렉션 / index 확인 ✅
LessonSetting fallback 동작 신규 컬렉션이 없을 경우 legacy academy embedded 사용 feature flag / 분기 코드 테스트 🔲
LessonSetting unique 보장 academyId 기준 중복이 불가능하다 MongoDB unique index 확인 ✅
LessonSetting 백필 완료 기존 academy embedded 데이터가 신규 컬렉션으로 이전됨 migration 로그 / count 비교 ✅
CourtSelectionPolicy 마이그레이션 완료 legacy plan.courts → policy INCLUDE 변환됨 migration 스크립트 실행 결과 확인 ✅
Legacy 필드 유지 기존 TicketPlan 옵셔널 필드가 제거되지 않음 schema diff 확인 ✅
Backward compatibility 보장 기존 API consumer가 깨지지 않는다 스테이징 회귀 테스트 🏃
Read API 응답 타입 안정성 Read DTO에서 optional/nullable 의도가 명확하다 Swagger / 타입 정의 확인 🏃
PlanLegacyDtoFabricator 구현 기존의 TicketPlanResponseDto와의 호환성 레이어 ReadModel이 주어졌을때 예상 변환 결과를 테스트 🔲
정책 로직 단일 책임 유지 court 정책 로직이 한 곳에만 존재 중복 구현 여부 검색 ✅
Aggregate 테스트가 Read 없이 통과 Aggregate 단위 테스트가 Read Model 없이 가능 테스트 실행 🔲
Read 테스트가 Aggregate 없이 통과 Read Projector 테스트가 Aggregate 없이 가능 테스트 실행 🔲
기존의 ticketplanmodels 마이그레이션 모든 옵셔널 필드가 뒤섞인 거대한 도큐먼트를 각각의 타입별로 임베드 하거나 별도의 릴레이션으로 분리 마이그레이션 스크립트 실행 후 정합성 평가 ❌ 사유: 기존의 TicketPlan의 필수 필드를 제외한 나머지를 옵셔널로 변경하는 것으로 달성
PlanQueryPort 구현 다양한 필터, 정렬, 페이지네이션 조건을 입력으로 DB에 쿼리를 조회하고 PlanRead 읽기모델로 변환하는 레포지토리를 구현 레거시 TicketPlanRepository를 대체 ✅

prisma:push 기능 확장

관련 PR: https://github.com/curinginnos/racketime-api/pull/343

AS-IS

prisma:push 커맨드를 실행하면 자꾸 아카데미 테이블에 있는 2dSphere 인덱스가 사라지는 등의 문제가 있어 수작업으로 인덱스/유니크제약조건을 추가해야 하는 불편함이 따랐음.

TO-BE

prisma:index 커맨드를 신설하여 MongoDB 커넥션을 직접 연결 후 Prisma가 지원하지 않는 타입의 인덱스 (2dSphere, partialIndex)를 추가할 수 있게 되었음.

해당 커맨드는 prisma:push 커맨드 안에 병행하도록 하여 일관적으로 데이터베이스 인덱스를 관리할 수 있게 되었음.

현재 라켓타임은 휴대폰 번호 기반으로만 유저를 조회할 수 있어 일반 유저가 매칭 상대나 카메라 촬영 동의자를 추가할 때 UX 장벽이 크다.

이에 유저가 닉네임 기반으로 다른 유저를 조회/선택할 수 있게 하여 입력 부담을 줄이고 실사용 흐름을 매끄럽게 만드는 것을 목표로 한다.

닉네임은 흔한 값이 빠르게 선점되는 문제가 있으므로, 디스코드 방식처럼 닉네임#123 같이 핸들을 사용하여 정확히 유저 1명을 식별 가능하게 함을 염두에 두고 작업했다.

이번 주 잘한 일

이번 주 아쉬운 일

W05 목표

다음 1,2개월동안 회사가 나에게 기대야 할 "주축"은?

W05 Estimated Output

산출물

  1. 팀 내 wireframe 리뷰 1회
  2. UML 다이어그램 리뷰 1회
    1. class FSM (pre, during, post)
    2. Sequence
  3. AI 에이전트를 위한 fine-grained spec file 유스케이스당 하나씩, 1차 필수기능 중 P0 spec 6EA
    1. UC022
    2. UC021
    3. UC020
    4. UC001
    5. UC023
    6. UC002

Best

Worst

규칙 1) 월~화는 “스펙 P0 생산”만

규칙 2) 주간 이슈는 “슬롯제”로

규칙 3) 집에서 작업 금지(너가 이미 선언함)

대신 진짜 허용: