• 사전 공유 필수 (최소 1시간 전)
  • Discord 일정-공유 채널에 올려주세요!
• 2회 무단 결석 시 팀 회의에서 논의
  • 사전 공유 없이 10분 이상 지각 (무단 경고 1회 / 2회시 결석판정)

• 팀장과 1:1 면담 → 팀장 중재 → 팀 회의에서 공유 및 조정
  • 서로의 입장이 다를 수 있습니다. 감정을 내려놓고 이성적으로 대화합시다.

• 주간 할 일 및 진행도 공유
• 그 외 간단한 안건들 공유
• 월요일 미팅 이후 데일리 스크럼 진행

• 주간 한 일 정리
• 한 주간 피드백

회의 안건은 #회의-안건 채널에 올려주시면 감사하겠습니다!

스크럼 내용

• 어제 한 일
• 오늘 할 일
• 막힌 점 / 도움이 필요한 점

간단히 브리핑 이후 Github dailyScrum Repo - Issues 에 업로드

하루 태스크 완료 시 Close Issue , Discussion에는 팀장이 정리해서 올립니다.

일일 스크럼을 통해 진행된 내용들을 정리하여 Notion 주간 스크럼 채널에 올립니다.

기록자 → 팀장

프로젝트 진행 중 겪은 오류나 예외 상황을 기록합니다.

해결 과정과 깨달은 점을 정리하여 discord 404-not-found 채널에 올립니다.

주에 최소 2개씩 TIL 기록을 discord til 채팅 채널에 공유해주시길 바랍니다! 우리의 학습을 위해 꾸준히 공유해주시면 감사하겠습니다.

프로젝트 기간 도중 불편한 점, 개선해야 할 점, 건의할 사항이 있는 경우 discord #건의사항 채널에 올려주시면 확인 후 반영 후 개선하겠습니다.

개인간의 건의사항이나 불편한 점은 팀장에게 DM 주시기 바랍니다.

주간 TIL 및 에러다이어리 MVP에게는 소정의 기프티콘을 지급해드릴 예정입니다! (금요일 주간미팅에서 선정)

• 에러 다이어리 공유 2건 이상
• TIL 2건 이상
• 팀원 피드백 기여도
• PR 참여/리뷰 성실도

1주차 - 맘스터치 싸이버거 세트

• PM ↔ 전원: 회의, 일정, 데일리/주간 스크럼 등 전반 관리 및 지원
• PL ↔ DevOps/DBA: 기술 방향성에 따른 구조 조정, 배포 설계, 성능 문제 조율
• DevOps ↔ 형상관리자: 배포 시점 조율, 브랜치 머지 순서 정리
• DBA ↔ DevOps: 배포 시 DB 마이그레이션 및 데이터 연동 관련 협업

• 역할 담당자가 일정 불참 시 → Sub가 자동 대행
• 병목 또는 과중 발생 시 → PM이 팀원 간 업무 재분배
• 기술 난이도 높거나 병렬 진행 어려운 작업 → PL이 우선 도맡아 해결 후 공유
• 역할 갈등 또는 이견 발생 시 → PM이 중재하여 합의안 도출

• 역할은 초기에는 지정된 구조로 운영되며, 스프린트 2회차 이후에는 팀원 희망에 따라 순환 또는 교체 가능합니다.
• 역할 변경을 통해 각자 자신의 관심 분야 또는 약점 보완 가능성 확보를 목표로 합니다.
• 역할 순환 시, 이전 역할에서 작성한 산출물/운영 노하우는 반드시 문서화하여 다음 담당자에게 인수인계합니다.

의미 있는 공개 메서드에 JavaDoc 주석 필수, 내부 로직은 선택적으로 작성

src/main/java/com/teamname/project
├── global          // 공통 설정, 예외 처리
├── user
│   ├── controller
│   ├── service
│   ├── repository
│   ├── domain
│   └── dto
└── order
    ├── controller
    └── ...

• "테스트 범위는 좁게, 효과는 크게"
• 서비스 계층 중심 + 핵심 유즈케이스 우선

서비스레이어 단에서 단위 테스트 ← 필수 비즈니스 로직에 대한 단위 테스트를 중심으로 진행 시간 여유 있으면 컨트롤러 단에서 통합 테스트 진행

✅ 실무에서도 컨트롤러 테스트는 일부만 작성

• 비즈니스 로직 핵심 위치
• 리팩토링 후 안정성 확보
• Mock으로 의존성 최소화

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    @Mock UserRepository userRepository;
    @InjectMocks UserService userService;

    @Test
    void 사용자_조회_성공() {
        User user = new User(1L, "준경");
        given(userRepository.findById(1L)).willReturn(Optional.of(user));
        User result = userService.getUserById(1L);
        assertEquals("준경", result.getName());
    }
}

- 서비스 계층 테스트는 필수 (Mock 사용)
- 컨트롤러 테스트는 인증/예외 등 필수 항목만 작성
- 테스트 클래스명: XyzServiceTest
- Given - When - Then 구조 유지
- 미작성 시 TODO 또는 @Disabled 명시

@Test
@DisplayName("로그인 성공 시 사용자 정보 반환")
void loginSuccess() {
    // Given
    LoginRequest req = new LoginRequest("id", "pw");
    given(authService.login(req)).willReturn(token);

    // When
    String result = authService.login(req);

    // Then
    assertThat(result).isNotNull();
}

- 모든 클래스에 역할 어노테이션 명시
- 생성자 주입 + Lombok 사용 통일 (@RequiredArgsConstructor)
- REST API 경로는 HTTP 메서드 어노테이션 사용
- 파라미터 어노테이션 생략 금지
- 예외는 @RestControllerAdvice 기반 처리
- @Transactional은 서비스 계층에만 사용 (readOnly 여부 포함)
- Lombok 사용 범위는 사전 합의하여 통일

이슈 번호 연결 예시: feature/#11-order-api

• 여러 커밋을 하나로 압축하여 머지
• 커밋 로그 간결, 리뷰 목적 명확
• 기능 단위로 revert 가능

- 모든 feature 브랜치는 dev로 Squash Merge
- 커밋 메시지는 기능 단위 요약 + 이슈번호 포함
  예: feat: 로그인 기능 구현 (#5)
- main 브랜치는 dev에서만 머지

scope는 선택, subject는 현재 시제로

feat: 결제 기능 추가
fix(login): 잘못된 비밀번호 처리 로직 수정

• 한글로 명확히 작성 ("의미 없는 메시지 지양")
• 현재 시제, 간결하고 목적 명확하게 작성
• 기능 단위로 커밋 구분