[고희준] sprint7 #193

barrackkk · 2025-06-26T18:26:48Z

기본 요구사항

프로파일 기반 설정 관리

개발, 운영 환경에 대한 프로파일을 구성하세요.
application-dev.yaml, application-prod.yaml 파일을 생성하세요.
다음과 같은 설정값을 프로파일별로 분리하세요.
데이터베이스 연결 정보
서버 포트

로그 관리

Lombok의 @slf4j 어노테이션을 활용해 로깅을 쉽게 추가할 수 있도록 구성하세요.
application.yaml에 기본 로깅 레벨을 설정하세요.
기본적으로 info 레벨로 설정합니다.
환경 별 적절한 로깅 레벨을 프로파일 별로 설정해보세요.
SQL 로그를 보기위해 설정했던 레벨은 유지합니다.
우리가 작성한 프로젝트의 로그는 개발 환경에서 debug, 운영 환경에서는 info 레벨로 설정합니다.
Spring Boot의 기본 로깅 구현체인 Logback의 설정 파일을 구성하세요.
logback-spring.xml 파일을 생성하세요.
다음 예시와 같은 로그 메시지를 출력하기 위한 로깅 패턴과 출력 방식을 커스터마이징하세요.

로그 출력 예시

# 패턴
{년}-{월}-{일} {시}:{분}:{초}:{밀리초} [{스레드명}] {로그 레벨(5글자로 맞춤)} {로거 이름(최대 36글자)} - {로그 메시지}{줄바꿈}

# 예시
25-01-01 10:33:55.740 [main] DEBUG c.s.m.discodeit.DiscodeitApplication - Running with Spring Boot v3.4.0, Spring v6.2.0

예외 처리 고도화

커스텀 예외를 설계하고 구현하세요.

패키지명: com.sprint.mission.discodeit.exception[.{도메인}]

ErrorCode Enum 클래스를 통해 예외 코드명과 메시지를 정의하세요.

아래는 예시입니다. 필요하다고 판단되는 다양한 코드를 정의하세요.

예시

모든 예외의 기본이 되는 DiscodeitException 클래스를 정의하세요.

클래스 다이어그램

details는 예외 발생 상황에 대한 추가정보를 저장하기 위한 속성입니다.

예시
조회 시도한 사용자의 ID 정보
업데이트 시도한 PRIVATE 채널의 ID 정보

DiscodeitException을 상속하는 주요 도메인 별 메인 예외 클래스를 정의하세요.

UserException, ChannelException 등
실제로 활용되는 클래스라기보다는 예외 클래스의 계층 구조를 명확하게 하기 위한 클래스 입니다.

도메인 메인 예외 클래스를 상속하는 구체적인 예외 클래스를 정의하세요.
UserNotFoundException, UserAlreadyExistException 등 필요한 예외를 정의하세요.

예시

기존에 구현했던 예외를 커스텀 예외로 대체하세요.

NoSuchElementException
IllegalArgumentException
…

ErrorResponse를 통해 일관된 예외 응답을 정의하세요.

클래스 다이어그램

int status: HTTP 상태코드

String exceptionType: 발생한 예외의 클래스 이름

앞서 정의한 ErrorResponse와 @RestControllerAdvice를 활용해 예외를 처리하는 예외 핸들러를 구현하세요.

모든 핸들러는 일관된 응답(ErrorResponse)을 가져야 합니다.

유효성 검사

Spring Validation 의존성을 추가하세요.
주요 Request DTO에 제약 조건 관련 어노테이션을 추구하세요.
@NotNull, @notblank, @SiZe, @Email 등
컨트롤러에 @Valid 를 사용해 요청 데이터를 검증하세요.
검증 실패 시 발생하는 MethodArgumentNotValidException을 전역 예외 핸들러에서 처리하세요.
유효성 검증 실패 시 상세한 오류 메시지를 포함한 응답을 반환하세요.

Actuator

Spring Boot Actuator 의존성을 추가하세요.
기본 Actuator 엔트포인트를 설정하세요.
health, info, metrics, loggers
Actuator info를 위한 애플리케이션 정보를 추가하세요.
애플리케이션 이름: Discodeit
애플리케이션 버전: 1.7.0
자바 버전: 17
스프링 부트 버전: 3.4.0
주요 설정 정보
데이터소스: url, 드라이버 클래스 이름
jpa: ddl-auto
storage 설정: type, path
multipart 설정: max-file-size, max-request-size
Spring Boot 서버를 실행 후 각종 정보를 확인해보세요.
/actuator/info
/actuator/metrics
/actuator/health
/actuator/loggers

단위 테스트

서비스 레이어의 주요 메소드에 대한 단위 테스트를 작성하세요.
다음 서비스의 핵심 메소드에 대해 각각 최소 2개 이상(성공, 실패)의 테스트 케이스를 작성하세요.
UserService: create, update, delete 메소드
ChannelService: create(PUBLIC, PRIVATE), update, delete, findByUserId 메소드
MessageService: create, update, delete, findByChannelId 메소드
Mockito를 활용해 Repository 의존성을 모의(mock)하세요.
BDDMockito를 활용해 테스트 가독성을 높이세요.

슬라이스 테스트

예시
@Import({ErrorCodeStatusMapper.class})

주요 컨트롤러(User, Channel, Message)에 대해 최소 2개 이상(성공, 실패)의 테스트 케이스를 작성하세요.
MockMvc를 활용해 컨트롤러를 테스트하세요.
서비스 레이어를 모의(mock)하여 컨트롤러 로직만 테스트하세요.
JSON 응답을 검증하는 테스트를 포함하세요.

통합 테스트

심화 요구사항

MDC를 활용한 로깅 고도화

요청 ID, 요청 URL, 요청 방식 등의 정보를 MDC에 추가하는 인터셉터를 구현하세요.
클래스명: MDCLoggingInterceptor
패키지명: com.**.discodeit.config
요청 ID는 랜덤한 문자열로 생성합니다. (UUID)
요청 ID는 응답 헤더에 포함시켜 더 많은 분석이 가능하도록 합니다.
헤더 이름: Discodeit-Request-ID
WebMvcConfigurer를 통해 MDCLoggingInterceptor를 등록하세요.
클래스명: WebMvcConfig
패키지명: com.**.discodeit.config
Logback 패턴에 MDC 값을 포함시키세요.
로그 출력 예시

# 패턴
{년}-{월}-{일} {시}:{분}:{초}:{밀리초} [{스레드명}] {로그 레벨(5글자로 맞춤)} {로거 이름(최대 36글자)} [{MDC:요청ID} | {MDC:요청 메소드} | {MDC:요청 URL}] - {로그 메시지}{줄바꿈}

# 예시
25-01-01 10:33:55.740 [main] DEBUG o.s.api.AbstractOpenApiResource [827cbc0b | GET | /v3/api-docs] - Init duration for springdoc-openapi is: 216 ms

Spring Boot Admin을 활용한 메트릭 가시화

Spring Boot Admin 서버를 구현할 모듈을 생성하세요.

- [x] admin 모듈의 메인 클래스에 @EnableAdminServer 어노테이션을 추가하고, 서버는 9090번 포트로 설정합니다.


import de.codecentric.boot.admin.server.config.EnableAdminServer;

@SpringBootApplication
@EnableAdminServer
public class AdminApplication {
    public static void main(String[] args) {
        SpringApplication.run(AdminApplication.class, args);
    }
}

# application.yaml
spring:
    application:
        name: admin
server:
    port: 9090

admin 서버 실행 후 localhost:9090/applications 에 접속해봅니다.
discodeit 프로젝트에 Spring Boot Admin Client를 적용합니다.
의존성을 추가합니다.
dependencies {
...
implementation 'de.codecentric:spring-boot-admin-starter-client:3.4.5
}
admin 서버에 등록될 수 있도록 설정 정보를 추가합니다.

# application.yml
spring:
  application:
    name: discodeit
    ...
  boot:
    admin:
      client:
        instance:
          name: discodeit

# application-dev.yml
spring:
  application:
    name: discodeit
    ...
  boot:
    admin:
      client:
        url: http://localhost:9090


# application-prod.yml
spring:
  application:
    name: discodeit
    ...
  boot:
    admin:
      client:
        url: ${SPRING_BOOT_ADMIN_CLIENT_URL}

discodeit 서버를 실행하고, admin 대시보드에 discodeit 인스턴스가 추가되었는지 확인합니다.
admin 대시보드 화면을 조작해보면서 각종 메트릭 정보를 확인해보세요.

주요 API의 요청 횟수, 응답시간 등
서비스 정보

테스트 커버리지 관리

JaCoCo 플러그인을 추가하세요.

plugins {
    id 'jacoco'
}

test {
    finalizedBy jacocoTestReport
}

jacocoTestReport {
    dependsOn test
    reports {
        xml.required = true
        html.required = true
    }
}

테스트 실행 후 생성된 리포트를 분석해보세요.

리포트는 build/reports/jacoco 경로에서 확인할 수 있습니다.
[ ] com.sprint.mission.discodeit.service.basic 패키지에 대해서 60% 이상의 코드 커버리지를 달성하세요.

질문

Exception 처리 관련 질문

예외가 하나뿐인 경우에도 커스텀 예외 클래스를 직접 만들고, 그걸 상속 구조로 관리하는 것이 좋은지 궁금합니다.
예: BinaryContentException → BinaryContentNotFoundException 등으로 나누는 방식이 과한 건지.. 아니면 큰그림을 그려 추후에 발생할 버그를 위해 이런식으로 해도 되는건지 궁금합니다

MessageServiceTest 테스트 구조 관련 질문

메시지 생성 성공 테스트에서 mock 객체를 메서드 내부에서 생성하고 설정하는 방식과,
필드로 선언해서 재사용하는 방식 중 어떤 게 더 유지보수나 가독성 측면에서 바람직할까요? 이것도 개인 스타일인건지 아니면 관례적으로 사용하는 방법이 있는지 궁금합니다 !

컨트롤러 테스트 - 요청 유효성 검사 관련 질문

MessageCreateRequest에 유효성 제약 조건(@NotNull 등)이 3개 있는데, 각각을 별도의 테스트 케이스로 분리하는 게 좋은지, 아니면 하나의 테스트 메서드 안에서 모든 필드 유효성 실패 케이스를 한 번에 검증해도 괜찮은지 고민입니다.

- 개발, 운영 환경에 대한 프로파일 구성 - Logback 설정 파일 구성

- ErrorCode: 예상되는 에러 설계 - *Exception: 커스텀 예외 설계 - ErrorResponse: 일관된 예외 응답 정의

ssjf409 · 2025-07-02T04:41:35Z

src/main/java/com/sprint/mission/discodeit/controller/UserController.java

    }

-
+    private Optional<BinaryContentCreateRequest> resolveProfileRequest(MultipartFile profileFile) {
+        if (profileFile.isEmpty()) {


resolveProfileRequest를 호출하는 쪽에서 Optional.ofNullable에서 꺼내서 호출해서요.
MultipartFile profileFile가 null인 경우도 고려는 해야할 것 같아요.

ssjf409 · 2025-07-02T04:44:57Z

src/main/java/com/sprint/mission/discodeit/dto/request/LoginRequest.java

@@ -0,0 +1,9 @@
+package com.sprint.mission.discodeit.dto.request;
+
+public record LoginRequest(


여기에도 유효성 검사 필요하죠?

ssjf409 · 2025-07-02T04:52:30Z

...ava/com/sprint/mission/discodeit/exception/binarycontent/BinaryContentNotFoundException.java

+import java.util.Map;
+import java.util.UUID;
+
+public class BinaryContentNotFoundException extends BinaryContentException {


이 Exception이랑 ChannelException 잘 작성하신것 같은데, 실제로 이 Exception들을 던지는 코드는 어디에 있나요?

ssjf409 · 2025-07-02T04:59:14Z

src/main/java/com/sprint/mission/discodeit/mapper/UserMapper.java

+    @Mapping(source = "profile", target = "profile")
+    UserDto toDto(User user);


저는 애노테이션으로 바꾸시는 것보다 삭제하셨던 코드로 작성된게 훨씬 유지보수나 이해하기 쉽다고 생각해요.

SpEL은 컴파일 시점에 정적 분석의 대상이 아니라서 코드에 문제가 있어도 발견되지 않아요. 그 상태로 배포가 나가서 실제 코드가 동작하는 순간에 확인이 되는데, 너무 리스크가 크다 생각합니다.

그것보다 삭제하셨던 코드가 버그를 컴파일 시점에 발견할 수도 있고 이해하기도 쉬워서 왜 굳이 바꾸셨는지.. 저는 이해가 잘 안되네요..

@Mapping을 저는 써본적이 없어서 리뷰 달면서 알게되었는데.. 잘 쓰면 유용한 면도 있을것 같다고 생각하는데요. 그만큼 리스크도 커 보이네요.

ssjf409 · 2025-07-02T05:02:54Z

src/main/java/com/sprint/mission/discodeit/repository/MessageRepository.java

+  @Query("SELECT m FROM Message m "
+      + "LEFT JOIN FETCH m.author a "
+      + "JOIN FETCH a.status "
+      + "LEFT JOIN FETCH a.profile "
+      + "WHERE m.channel.id=:channelId AND m.createdAt < :createdAt")


@Query은 가급적 사용하지 않는게 좋아요.

다른 코멘트에서 단것처럼 SpEL가 정적 분석의 대상이 아니라서 버그를 만큼 위협도 크고 발견 시점도 배포를 해야 발견할 수 있어서요.

join 때문에 발생하는 N + 1 문제를 해결하기 위해서 @Query 애노테이션을 쓴거라면 @BatchSize나 아래 옵션을 쓰는걸 추천드려요.

spring: jpa: properties: hibernate: default_batch_fetch_size: 20

ssjf409 · 2025-07-02T05:06:31Z

src/main/java/com/sprint/mission/discodeit/repository/MessageRepository.java

+      + "FROM Message m "
+      + "WHERE m.channel.id = :channelId "
+      + "ORDER BY m.createdAt DESC LIMIT 1")
+  Optional<Instant> findLastMessageAtByChannelId(@Param("channelId") UUID channelId);


이것도

Optional<Message> findTopByChannelIdOrderByCreatedAtDesc(UUID channelId);

이렇게 작성하고 사용하는 쪽에서 아래와 같이 사용하는걸 권장드려요.

messageRepository.findTopByChannelIdOrderByCreatedAtDesc(channelId) .map(Message::getCreatedAt);

단일 row의 경우, 전체 컬럼을 가져오는 것과 특정 컬럼만 가져오는 것 간의 성능 차이는 미미하고, JPA의 영속성 컨텍스트를 고려하면 전체 엔티티를 가져오는 것이 재사용성과 캐시 활용 측면에서 더 유리할 수 있어요.

ssjf409 · 2025-07-02T05:19:22Z

src/main/java/com/sprint/mission/discodeit/service/basic/BasicAuthService.java


-        if (!user.getPassword().equals(request.password())) {
-            throw new IllegalArgumentException("비밀번호가 일치하지 않습니다.");
+        if (!user.getPassword().equals(password)) {


아직 Login에서 password 평문으로 저장하면 안 된다고 안 배우신거죠?

아래 링크에 방법 나와있으면 참고만 좀 부탁드립니다.
https://hou27.tistory.com/entry/Spring-Boot-Spring-Security-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-%EC%95%94%ED%98%B8%ED%99%94

ssjf409 · 2025-07-02T05:23:27Z

src/main/resources/logback-spring.xml

+  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
+    <file>${LOG_PATH}/discodeit.log</file>
+    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
+      <fileNamePattern>${LOG_PATH}/discodeit.%d{yyyy-MM-dd}.log</fileNamePattern>
+      <maxHistory>30</maxHistory> <!-- 30일 보관 -->
+    </rollingPolicy>
+    <encoder>
+      <pattern>${LOG_PATTERN}</pattern>
+    </encoder>
+  </appender>


로깅 파일을 시간단위로 롤링하는 정책은 현업에서도 많이 쓰고 굉장히 잘 하신것 같아요.
하지만 파일이 너무 커져서 문제가 되는 경우도 있거든요.
그래서 보통은 최대 파일크기도 같이 설정으로 걸어둬요.

아래 파일 크기 + 시간 주기로 롤링하는 정책입니다.

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>./logs/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>./logs/app.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxFileSize>100MB</maxFileSize>  <maxHistory>30</maxHistory>  <totalSizeCap>5GB</totalSizeCap>  </rollingPolicy> <encoder> <pattern>${ROLLING_PATTERN}</pattern> </encoder> </appender>

ssjf409 · 2025-07-02T05:26:05Z

src/test/java/com/sprint/mission/discodeit/controller/ChannelControllerTest.java

+            " test", List.of(userDto), null);
+
+        // when
+        when(channelService.create(request)).thenReturn(channelDto);


이건 given에 있는게 적절해보여요.
channelService.create(request) 호출 됐을때 channelDto 리턴하도록 모킹하겠다는 의미거든요.

mockMvc.perform(post("/api/channels/public") .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(request))) .andExpect(status().isCreated()) .andExpect(jsonPath("$.name").value("testChannel"));

이 부분에서도 when과 then에 대한 내용이 섞여있어요.

given: 테스트를 위한 준비 단계
when: 테스트의 대상이되는 코드 실행 단계
then: 실행 결과를 검증하는 단계

정확하게 분리하려면 아래와 같이 해야할것 같아요.

// Given PublicChannelCreateRequest request = new PublicChannelCreateRequest("testChannel", "test"); ChannelDto channelDto = new ChannelDto(UUID.randomUUID(), ChannelType.PUBLIC, "testChannel", "test", List.of(userDto), null); when(channelService.create(request)).thenReturn(channelDto); // When ResultActions result = mockMvc.perform(post("/api/channels/public") .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(request))); // Then result.andExpect(status().isCreated()) .andExpect(jsonPath("$.name").value("testChannel"));

아래에도 비슷한 실수가 많네요. 굳이 코멘트 안 달게요.

ssjf409 · 2025-07-02T05:30:28Z

src/test/java/com/sprint/mission/discodeit/service/basic/BasicChannelServiceTest.java

+        assertThat(result.description()).isEqualTo(request.description());
+
+        then(channelRepository).should().save(any(Channel.class));
+        then(channelMapper).should().toDto(any(Channel.class));


테스트 코드의 가독성을 높히려면, given, when, then 각 절 내부에서는 빈 공백을 없애고
절이 넘어갈때만 빈 공백이 있는게 좋아요.

ex)

// given PublicChannelCreateRequest request = new PublicChannelCreateRequest("testPublicChannel", "testPublic"); ChannelDto channelDto = new ChannelDto( UUID.randomUUID(), ChannelType.PUBLIC, "testPublicChannel", "testPublic", new ArrayList<UserDto>(), null ); given(channelRepository.existsById(UUID.randomUUID())).willReturn(false); given(channelMapper.toDto(any(Channel.class))).willReturn(channelDto); // when ChannelDto result = channelService.create(request); // then assertThat(result).isNotNull(); assertThat(result.name()).isEqualTo(request.name()); assertThat(result.description()).isEqualTo(request.description()); then(channelRepository).should().save(any(Channel.class)); then(channelMapper).should().toDto(any(Channel.class));

ssjf409 · 2025-07-02T05:41:45Z

전체적으로 잘 작성하셨다 생각합니다. 특히 이번 요구사항인 ErrorCode랑 Exception 구현이랑 설정들은 잘하셨다 생각해요.

다만, 과도한 SpEL 사용 (@Query, @Mapping)은 사용을 안하는 쪽으로 변경하시는게 시스템이 더 안정적이라 생각합니다.

그리고 https://github.com/codeit-bootcamp-spring/3-sprint-mission/pull/193/files#diff-406981bef1e21a3e1fc249c8b7a962c02d1437b8db6e6c7b03dc2cb2244f4e95R18
이런 부분에서 Builder 패턴을 쓰지 않아서 실수할 여지가 있어 보입니다. 코드 리뷰 하는 사람도 각 파라미터 순서에 잘 맞게 넣은게 맞는지 확실하지 않아서 커밋 내용들만 보고는 확인이 어렵습니다. builder를 좀 더 적극적으로 사용하길 권합니다.

barrackkk added 19 commits June 18, 2025 23:14

베이스코드로 변경

e387a7c

feat: 프로파일 기반 설정 관리

d0862d1

- 개발, 운영 환경에 대한 프로파일 구성 - Logback 설정 파일 구성

feat: Service 레이어 로깅 추가

439f30f

feat: Controller 레이어 로깅 추가

8819b95

chore: .log 파일 gitignore에 추가

176c111

feat: 커스텀 예외 설계

8b0f312

- ErrorCode: 예상되는 에러 설계 - *Exception: 커스텀 예외 설계 - ErrorResponse: 일관된 예외 응답 정의

feat: 커스텀 예외 구현

80738c2

feat: 제약 조건 관련 어노테이션 추가

a36e3ab

feat: @Valid 사용하여 요청 데이터 검증 구현

d7103d2

feat: MethodArgumentNotValidException을 전역 예외 핸들러에서 처리

2330df9

feat: Actuator 추가

fe482cb

feat: 단위 테스트 구현

c068caf

feat: 의존성 추가

cf96b1a

feat: Repository 슬라이스 테스트

5a99e6f

feat: Controller 슬라이스 테스트

b45677c

feat: 통합 테스트 구현

5b9aad3

feat: MDC를 활용한 로깅 고도화 구현

89adcf6

feat: Spring Boot Admin을 활용한 메트릭 가시화

f8b7df9

feat: JaCoCo 플러그인 추가

16ccef1

barrackkk requested a review from ssjf409 June 26, 2025 18:27

barrackkk added the 매운맛🔥 뒤는 없습니다. 그냥 필터 없이 말해주세요. 책임은 제가 집니다. label Jun 26, 2025

ssjf409 reviewed Jul 2, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[고희준] sprint7 #193

[고희준] sprint7 #193

Uh oh!

barrackkk commented Jun 26, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 Jul 2, 2025

Uh oh!

ssjf409 commented Jul 2, 2025

Uh oh!

Uh oh!

		@@ -0,0 +1,9 @@
		package com.sprint.mission.discodeit.dto.request;

		public record LoginRequest(

		@Mapping(source = "profile", target = "profile")
		UserDto toDto(User user);

[고희준] sprint7 #193

Are you sure you want to change the base?

[고희준] sprint7 #193

Uh oh!

Conversation

barrackkk commented Jun 26, 2025

기본 요구사항

프로파일 기반 설정 관리

로그 관리

로그 출력 예시

예외 처리 고도화

유효성 검사

Actuator

단위 테스트

슬라이스 테스트

심화 요구사항

MDC를 활용한 로깅 고도화

Spring Boot Admin을 활용한 메트릭 가시화

테스트 커버리지 관리

질문

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!

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!

Choose a reason for hiding this comment

Uh oh!

ssjf409 commented Jul 2, 2025

Uh oh!

Uh oh!