Refactor: 파일 반환 dto optional로 변경 #226
Conversation
kdh10806
requested review from
Eseas,
taekminKwon,
K-KY,
HiSeungmin and
jeongns2611
as code owners
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| @@ -43,7 +43,8 @@ public ResponseEntity<APIResponse> uploadFile(@PathVariable("companyId") Long co | |||
| */ | |||
| @GetMapping(value = "/{companyId}/logo-image") | |||
| public ResponseEntity<APIResponse> getCompanyLogo(@PathVariable("companyId") Long companyId) { | |||
| FileMetadataDto logoImage = companyFileService.getLogoImage(companyId); | |||
|
|
|||
| FileMetadataResponse logoImage = companyFileService.getLogoImage(companyId); | |||
|
|
|||
| return ResponseEntity | |||
| .status(SuccessCode.OK.getStatus()) | |||
There was a problem hiding this comment.
코드 패치에 대한 간단한 코드 리뷰를 진행하겠습니다.
-
변경된 클래스의 이름:
FileMetadataDto에서FileMetadataResponse로 변경된 점은 명확하고 의미 있는 개선으로 보입니다. 변환된 객체가 API 응답에 더 적합한 이름인 것 같습니다. -
유형 일관성:
companyFileService.getLogoImage(companyId)메소드가 반환하는 객체의 유형을 변경한 것은 관련된 곳의 모두에서 일관성을 유지하는지 확인하는 것이 좋습니다. 해당 메소드가 반환하는 실제 데이터 유형이 변경되었으므로, 이 객체를 사용하는 다른 부분에서 오류가 발생하지 않도록 주의해야 합니다. -
주석 및 문서화: 메소드에 대한 주석과 문서화가 필요할 경우,
FileMetadataResponse가 어떤 데이터를 포함하는지, 그리고 호출자에게 어떤 정보를 제공하는지에 대한 명확한 설명이 필요할 수 있습니다. -
에러 처리:
getCompanyLogo메소드에서 logoImage가 null일 경우에 대한 처리 로직이 필요할 수 있습니다. 로고 이미지가 없을 경우에 대한 예외처리 및 적절한 HTTP 상태 코드 반환이 이루어져야 합니다. -
메소드 이름:
getLogoImage가 가져오는 것이 회사의 로고 이미지임을 명확히 하고 있지만, 메소드 이름을fetchCompanyLogo와 같이 바꾸면 더 명확한 의도를 전달할 수 있습니다. -
정적 반응코드 사용:
SuccessCode.OK.getStatus()대신ResponseEntity.ok()와 같은 메소드를 사용하는 것도 고려해볼 수 있습니다. 이는 코드의 가독성을 높이고 중복을 줄이는 데 도움이 됩니다.
이외에 특정한 버그를 구현할 수 있는 부분은 보이지 않지만, 코드의 나머지 부분을 함께 확인하여 변경 사항이 전체적인 기능에 잘 통합되는지 점검하는 것이 중요합니다.
| //dto 변환 후 반환 | ||
| return FileMetadataDto.toDto(fileEntity); | ||
| //dto 변환 및 반환 | ||
| return FileMetadataResponse.toDto(fileEntity).orElse(null); | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
이 코드 패치에 대한 간단한 코드 리뷰를 제공하겠습니다.
문제점 및 리스크
-
Nullable 반환 값:
FileMetadataResponse.toDto(fileEntity).orElse(null)부분에서orElse(null)을 사용하여 null을 반환할 수 있습니다. 호출하는 측에서 이 값을 null 체크를 하지 않으면 NullPointerException이 발생할 수 있습니다. 특히, 메소드를 호출하는 코드가 이 반환 값을 사용하는 경우를 면밀히 검토해야 합니다. -
메타데이터 DTO의 네이밍:
FileMetadataResponse로 DTO의 이름을 변경한 이유가 명확히 주석으로 설명되지 않았습니다. 이 변경의 이유나 해당 클래스가 어떻게 다른지에 대한 설명이 부족해 보입니다. 팀원이 쉽게 이해하도록 주석을 추가하는 것이 좋습니다. -
예외 처리:
fileHandler.getFile(...)에서 파일을 찾지 못할 경우에 대한 예외 처리가 없습니다. 이 메서드가 실패할 경우 어떤 예외가 발생하는지 검토해야 합니다. 적절한 예외 처리를 통해 서비스 안정성을 높일 수 있습니다.
개선 제안
-
Null 반환 방지: DTO가 null일 경우 기본값을 반환하도록 개선하거나 Optional을 적극적으로 사용하여 null 처리를 미리 수행할 수 있도록 변경하는 것이 좋습니다. 예를 들어,
orElseGet메서드를 사용하여 기본값을 제공하는 방법도 고려할 수 있습니다. -
주석 추가: 코드 변경의 목적 및 관련 정보를 충분히 기록하여 후속 개발자 또는 팀원이 쉽게 이해할 수 있도록 주석을 추가하는 것이 좋습니다.
-
로깅 추가: 메타데이터를 찾지 못했을 경우 로깅을 추가하여 디버깅 시 유용한 정보를 제공하는 것도 좋은 접근입니다. 예를 들어, 특정 companyId로 파일을 찾지 못했음을 로그로 기록할 수 있습니다.
이와 같은 점들을 고려하여 코드 성능과 안정성을 향상시킬 수 있을 것입니다.
| private static final int MAX_LINK_LENGTH = 1000; | ||
| private static final int MAX_LINK_TITLE_LENGTH = 100; | ||
| private static final int MAX_LINK_TITLE_LENGTH = 400; | ||
| private static final int MAX_LINK_LENGTH = 4000; | ||
|
|
||
| @Id | ||
| @GeneratedValue(strategy = GenerationType.IDENTITY) |
There was a problem hiding this comment.
코드 패치에 대한 간단한 리뷰입니다.
-
변경 사항 이해:
MAX_LINK_TITLE_LENGTH와MAX_LINK_LENGTH의 값이 증가했습니다. 이는 해당 필드에 허용되는 최대 길이가 늘어난다는 의미입니다. 이런 변경이 의도된 결과인지, 즉 데이터베이스나 비즈니스 로직에서 문제를 일으키지 않을지 확인해야 합니다. -
버그 위험:
- 기존의 데이터나 데이터베이스 인프라가 이러한 길이 증가를 처리할 수 있는지 검증이 필요합니다. 예를 들어, 데이터베이스 스키마에서 해당 컬럼의 길이를 적절히 수정했는지 확인하세요. 만약 스키마가 변경되지 않았다면, 기존 데이터가 잘리지 않거나 오류가 발생할 수 있습니다.
- 이 값들이 비즈니스 로직의 다른 부분에도 영향을 미치는지 검토해야 합니다. 이와 같은 변경이 있음에도 불구하고 해당 길이에 대한 유효성 검사가 제대로 구현되어 있는지 확인할 필요가 있습니다.
-
개선 제안:
- 상수 값들을 한 곳에서 정의하는 방법이 코드 유지 보수를 쉽게 할 수 있는 방법이 될 수 있습니다. 예를 들어, 모든 상수 값을 관리하는 클래스를 만들어서 사용하면, 변경 시 유연성을 가질 수 있습니다.
- 길이 제한을 단순히 숫자에 의존하기보다는, 서비스의 요구사항이나 비즈니스 로직을 밑바탕으로 하여 이름에서 유추할 수 있도록 주석을 추가하면 이해에 도움이 됩니다.
- 주석으로 이러한 변경 사항의 이유를 명시해주면, 나중에 코드를 참고하는 다른 개발자들에게 유용할 것입니다.
코드 리뷰 후, 이러한 사항들을 잘 반영하여 프로젝트를 더 발전시키길 바랍니다.
| private static final int MAX_LINK_TITLE_LENGTH = 100; | ||
| private static final int MAX_LINK_LENGTH = 1000; | ||
| private static final int MAX_LINK_TITLE_LENGTH = 400; | ||
| private static final int MAX_LINK_LENGTH = 4000; | ||
|
|
||
| @Id | ||
| @GeneratedValue(strategy = GenerationType.IDENTITY) |
There was a problem hiding this comment.
이 코드 패치를 검토한 결과, 다음과 같은 사항들이 발견되었습니다.
-
상수 값 변경:
MAX_LINK_TITLE_LENGTH와MAX_LINK_LENGTH의 길이가 증가했습니다. 이 변화가 실제 비즈니스 로직에서 요구되는 사항인지, 혹은 데이터베이스의 스키마와 일치하는지 확인하는 것이 중요합니다. 만약 이 변경이 필요하지 않다면, 이전의 길이 제한을 유지하는 것이 좋습니다. -
데이터 무결성: 링크 제목과 링크의 최대 길이를 늘리는 것은 잠재적으로 데이터베이스에서 더 많은 데이터를 저장하게 만들 수 있습니다. 이로 인해 성능 저하 또는 데이터베이스 부하가 증가할 우려가 있습니다. 이와 관련하여 데이터베이스에 적절한 인덱싱이 이루어지고 있는지 또한 확인해야 합니다.
-
코드 문서화: 새로운 상수 값이 추가되거나 변경될 때, 코드에 주석을 추가하여 변경 이유나 사용 목적을 명시하는 것이 좋습니다. 이는 향후 유지 보수 시 도움이 됩니다.
-
유닛 테스트: 이런 변경 사항에 대해 유닛 테스트가 존재하는지 확인해야 합니다. 변경된 값이 의도된 대로 작동하는지 확인하기 위해 테스트 케이스를 추가하는 것도 고려해 볼 수 있습니다.
-
일관성 유지: 상수의 값을 변경할 경우, 해당 상수를 참조하는 모든 곳에서 기대하는 동작이 일관되게 유지되는지 확인해야 합니다. 코드의 다른 부분에서 이 상수를 사용하고 있을 가능성이 높으므로, 테스트를 통해 확인하는 것이 중요합니다.
이와 같은 점들을 검토해보신 후, 필요한 개선 사항을 적용하시기를 권장합니다.
| @@ -25,6 +25,7 @@ public ResponseEntity<APIResponse<?>> handleException(Exception e, WebRequest re | |||
| String detailedMessage = e.getMessage() != null ? e.getMessage() : "An unexpected error occurred"; | |||
| APIResponse<?> response = APIResponse.fail(errorCode, detailedMessage); | |||
|
|
|||
| e.printStackTrace(); | |||
| return ResponseEntity | |||
| .status(errorCode.getStatusCode()) // HTTP 상태 코드 설정 | |||
| .body(response); // APIResponse를 응답 본문으로 설정 | |||
There was a problem hiding this comment.
코드 리뷰를 진행하겠습니다.
-
예외 스택 추적 출력 문제:
e.printStackTrace();를 추가하셨는데, 이는 콘솔 로그에 예외 정보를 출력합니다. 운영 환경에서는 스택 트레이스를 출력하는 것이 보안 위험을 초래할 수 있으므로, 로그 프레임워크를 사용하여 적절히 로깅하는 것이 좋습니다. 예를 들어,Logger를 사용하여 로그 레벨에 맞춰 예외를 기록하는 것이 바람직합니다. -
응답 메시지의 일관성:
detailedMessage를 구성할 때, 예외가 발생한 경우와 일반 오류가 발생한 경우에 대한 메시지를 분리하는 것이 좋습니다. -
NullPointerException 방어:
e.getMessage()가 null일 경우에 대비해 기본 메시지를 제공하고 있지만, 더 나은 접근 방식은 예외의 원인을 파악하고 이를 기반으로 메시지를 설정하는 것입니다. -
HTTP 상태 코드 확인:
errorCode.getStatusCode()가 유효한 상태 코드를 반환하는지 검증하는 로직이 필요할 수 있습니다. 예를 들어 잘못된errorCode가 전달되었을 경우를 대비하여 적절한 예외 처리를 추가하는 것이 좋습니다. -
APIResponse에 대한 명확한 정의:
APIResponse.fail()메서드가 어떻게 작동하는지, 그리고 어떤 오류 코드와 메시지를 받는지에 대한 문서화가 필요할 수 있습니다. 이는 코드 유지보수 시 유용할 것입니다.
이러한 점들을 고려하여 코드를 수정하시면 더 나은 품질의 코드를 작성할 수 있을 것입니다.
| @@ -235,7 +235,7 @@ public ResponseEntity<APIResponse<SuccessCode>> postProjectChecklistRejectFile( | |||
| * 체크리스트 승인 요청 반려 사유의 파일 목록을 조회하는 함수 | |||
| */ | |||
| @GetMapping("/reject/{applicationId}/files") | |||
| public ResponseEntity<APIResponse<List<FileMetadataDto>>> getProjectChecklistRejectFiles( | |||
| public ResponseEntity<APIResponse<List<FileMetadataResponse>>> getProjectChecklistRejectFiles( | |||
| @PathVariable Long applicationId){ | |||
|
|
|||
| return ResponseEntity.status(SuccessCode.OK.getStatusCode()) | |||
There was a problem hiding this comment.
코드 리뷰를 진행하겠습니다. 다음은 제안 사항 및 버그 위험 요소입니다:
-
타입 변경:
FileMetadataDto에서FileMetadataResponse로 변경한 것은 API 응답의 구조를 변경하는 것으로 보입니다. 이러한 변경이 존재하는 클라이언트 코드에도 영향을 줄 수 있으므로, 해당 변경 사항에 대한 문서화가 필요합니다. -
메소드 주석: 메소드에 대한 주석이 잘 작성되어 있으나, null 체크나 예외 처리에 대한 언급이 없습니다. 예외 발생 시의 처리 로직이나, 입력 값 검증을 추가하여 안전한 코드를 구현하는 것이 좋습니다.
-
PostMapping의
consumes속성:@PostMapping에consumes = {MediaType.MULTIPART_FORM_DATA_VALUE}를 추가한 점은 파일 업로드 요청을 명확히 구분할 수 있게 하여 좋은 선택입니다. 그러나 클라이언트가 이 형식을 따르지 않을 경우 발생할 수 있는 오류에 대해 적절한 오류 메시지를 반환하는 로직이 필요합니다. -
예외 처리: 파일 업로드와 관련된 메소드에서, 파일의 크기, 형식에 대한 검증 로직이 없습니다. 예상치 못한 타입의 파일이 업로드 될 경우 시스템 오류가 발생할 수 있으므로 예외 처리를 추가하는 것이 좋습니다.
-
HTTP 상태 코드: 모든 API 응답에서 성공 이외의 다양한 상태 코드도 적절하게 반환하도록 구성하는 것이 중요합니다. 특히, 실패할 경우 클라이언트가 어떤 문제가 발생했는지 명확히 알 수 있도록 해야 합니다.
-
Javadoc 스타일: 코드 주석이 JavaDoc 형식으로 적혀 있지 않으므로, 메소드 설명 부분을 JavaDoc 형식으로 작성하면 외부 문서화 도구와 자동화된 빌드 프로세스에서 더욱 유용하게 활용될 수 있습니다.
종합적으로 전반적으로 코드는 깔끔하나 예외 처리, 문서화, 응답 상태 코드 등을 강화할 필요가 있습니다. 이러한 부분을 개선하면 안정성과 유지보수성이 높아질 것입니다.
| @@ -57,7 +57,7 @@ void postCheckRejectFiles( | |||
| List<MultipartFile>files | |||
| ); | |||
|
|
|||
| List<FileMetadataDto> getChecklistRejectFiles(Long applicationId); | |||
| List<FileMetadataResponse> getChecklistRejectFiles(Long applicationId); | |||
|
|
|||
| List<LinkResponse> getChecklistRejectLinks(Long applicationId); | |||
|
|
|||
There was a problem hiding this comment.
코드 패치에 대한 간단한 리뷰를 진행하겠습니다.
-
변경 사항 확인:
FileMetadataDto에서FileMetadataResponse로 변경되었습니다. 이 변경이 해당 클래스의 구조나 기능에 큰 변화가 없도록 주의가 필요합니다.- 인터페이스의 메서드 시그니처가 바뀌었으므로, 이 인터페이스를 구현하는 클래스에서도 동일한 메서드 시그니처를 반영해야 할 것입니다.
-
버그 리스크:
- 현재
FileMetadataDto와FileMetadataResponse가 어떤 필드나 메서드를 가지고 있는지에 대한 정보가 부족하여, 교체 후 기능이 정상적으로 작동할지에 대한 리스크가 있습니다. 사용되는 곳에서 잘못된 타입이나 메서드를 참조할 수 있는 가능성을 고려해야 합니다. - 이 변경이 다른 부분에서 캐시나 데이터 처리에 영향을 미칠 수 있으므로, 충분한 테스트가 필요합니다.
- 현재
-
개선 사항:
- 코드에 주석을 추가하여 변경된 이유와
FileMetadataDto와FileMetadataResponse의 차이점을 간단히 설명하는 것이 좋습니다. 이는 향후 유지보수 시 이해를 돕는 데 유용합니다. - 인터페이스의 문서화 (JavaDoc)를 고려하여 각 메서드가 수행하는 역할을 명확하게 설명하면 좋습니다.
- 만약
FileMetadataResponse로의 변경이 기능적으로 차별화된 점이 있다면, 이를 반영하여 관련된 로직을 검토하고 필요하면 수정해야 할 것입니다.
- 코드에 주석을 추가하여 변경된 이유와
-
테스트:
- 기존의
getApplicationFiles및getChecklistRejectFiles메서드를 사용하는 모든 로직을 점검하여, 변경된 DTO에 대한 테스트 케이스를 추가하는 것이 중요합니다. - 변경된 내용을 커버하는 단위 테스트 및 통합 테스트를 작성하여 변경으로 인한 버그 발생 가능성을 최소화해야 합니다.
- 기존의
요약하자면, DTO의 변경은 주요한 사항이며, 그로 인해 발생할 수 있는 리스크를 관리하는 것이 필수적입니다. 변경 내용에 대한 명확한 문서화와 철저한 테스트가 필요합니다.
| CheckRequest checkRequest = checkRequestReader.read(applicationId); | ||
|
|
||
| List<FileMetadataDto> fileDtoList = checkRequestFileReader.readCheckRequestRejectFiles(checkRequest); | ||
| List<FileMetadataResponse> fileDtoList = checkRequestFileReader.readCheckRequestRejectFiles(checkRequest); | ||
|
|
||
| return fileDtoList; | ||
| } |
There was a problem hiding this comment.
코드 리뷰를 진행하겠습니다.
코드 변경 사항 요약
FileMetadataDto에서FileMetadataResponse로 변경됨.getApplicationFiles와getChecklistRejectFiles메서드에서 반환 타입이 변경됨.
잠재적 버그 리스크
- 타입 변경에 따른 영향:
FileMetadataDto를FileMetadataResponse로 변경하는 것은 모델 간의 차이로 인해 기존의 로직에서 예상치 못한 문제가 발생할 수 있습니다. 특히,checkRequestFileReader에서 반환되는 객체의 유형이 변경되지 않았거나, 두 클래스 간의 메서드나 필드가 다르다면 추가적인 변환이 필요할 수 있습니다. - 테스트 부족: 이러한 변경 후에 기존의 테스트가 충분히 작동하는지 확인해야 합니다. 관련 테스트 케이스가 없거나 업데이트되지 않았다면 버그가 발생할 위험이 있습니다.
개선 사항
-
변경된 타입에 대한 검증:
FileMetadataResponse가FileMetadataDto와 관련된 모든 기능을 지원하는지 확인하고, 필요하다면 변환 로직을 명확히 해두는 것이 좋습니다. 예를 들면, 두 DTO 간의 변환 메서드를 추가하는 것입니다. -
주석 추가: 코드 변경 부분에 대한 간단한 설명 주석을 추가하면 후속 개발자가 이해하는 데 도움이 됩니다.
-
정적 분석 도구 사용: 변경된 코드에 대해 정적 분석 도구를 사용하여 잠재적인 코드 문제를 식별하고 품질을 높일 수 있습니다.
-
일관성 유지: 파일 메타데이터를 처리하는 다른 부분에서도 이와 같은 변경을 일관성 있게 진행해야 합니다. 타입 변경이 필요할 경우, 모든 관련 코드가 반영되도록 해야 합니다.
이 외에도, 린트 및 코드 스타일 가이드에 따라 코드를 검토하여 가독성과 유지 보수성을 높이는 것도 고려해볼만 합니다.
|
|
||
| List<FileMetadataDto> readCheckRequestRejectFiles(CheckRequest checkRequest); | ||
| List<FileMetadataResponse> readCheckRequestRejectFiles(CheckRequest checkRequest); | ||
| } |
There was a problem hiding this comment.
코드 패치에 대한 간단한 리뷰를 해보겠습니다.
변경사항
FileMetadataDto를FileMetadataResponse로 변경함.- 메서드 시그니처에서 반환형이 변경됨.
개선 제안 및 버그 리스크
-
명확성:
FileMetadataDto에서FileMetadataResponse로 변경된 이유가 명확하지 않습니다. 변경 이유에 대한 주석을 추가하는 것이 좋습니다. 나중에 유지보수 시에 격차를 줄일 수 있습니다. -
호환성: 기존에
FileMetadataDto를 사용하는 코드가 여전히 있을 수 있습니다. 이 변경으로 인해 기존 코드와의 호환성 문제가 발생할 수 있습니다. 이 인터페이스를 구현하는 모든 클래스 및 의존 코드에서 수정이 이루어져야 합니다. 이를 사전에 확인하고 변환할 필요가 있습니다. -
테스트: 변경된 메서드의 반환 타입이 달라졌기 때문에 관련된 테스트 케이스를 검토하고 수정할 필요가 있습니다. 특히,
readCheckRequestFiles와readCheckRequestRejectFiles메서드의 반환값을 사용하는 코드에서 문제가 발생할 수 있습니다. -
의존성 관리:
FileMetadataResponse에 대한 의존성을 포함하는 코드를 확인해야 합니다. 새로운 객체를 사용할 때 관련된 로직이나 데이터 전송 방법이 변경되지 않았는지 확인해야 합니다.
결론
제안된 변경 사항에는 방향성이 있지만, 인터페이스의 일관성 및 기존 코드와의 호환성을 보장하는 것이 중요합니다. 충분한 문서, 테스트 및 검토를 통해 안정성을 높이는 것이 좋겠습니다.
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
코드 패치에 대한 간단한 코드 리뷰를 진행하겠습니다.
개선 사항 및 버그 리스크:
-
Optional 사용:
Optional.ofNullable(fileEntities).orElse(List.of())구문은fileEntities가 null일 경우 빈 리스트를 반환하는데, 이 부분은fileEntities가 null인 경우가 없다면 불필요하게 사용할 수 있습니다.fileEntities가 null이 아님을 보장한다면 이 부분은 단순히fileEntities.stream()로 변경할 수 있습니다. -
flatMap 사용의 적절성: 현재 코드에서
flatMap(Optional::stream)을 사용하고 있는데,toDto메서드가 Optional을 반환하는 경우에만 필요한 코드입니다. 만약toDto가 null이나 Optional을 반환하지 않는다면, 이 사용법은 적절하지 않을 수 있습니다..map(FileMetadataResponse::toDto)만으로 충분할 수 있습니다. -
예외 처리: 파일 메타데이터가 존재하지 않거나 처리 도중 예외가 발생할 가능성이 있는 경우에 대한 예외 처리가 고려되어야 할 수 있습니다. 현재 상태에서는 예외를 처리하는 로직이 없으므로, 안정성이 떨어질 수 있습니다.
-
중복 코드 제거: 두 메서드가 매우 유사하게 작성되어 있습니다. 이러한 중복 코드를 별도의 공통 메서드로 추출하여 유지보수성을 높이는 것도 좋은 방법입니다.
-
로깅 추가: 파일 메타데이터를 불러오는 과정에서 성공/실패 여부에 대한 로깅을 추가하면 문제 발생 시 디버깅에 도움이 될 수 있습니다.
-
Stream API 사용: 현재 코드에서 Stream API를 잘 활용하고 있으나, 가끔 가독성을 위해 전통적인 for-each 루프가 더 나은 선택일 수 있습니다. 팀의 코딩 컨벤션이나 일관성을 고려하여 결정하는 것이 좋습니다.
결론:
코드는 전반적으로 깔끔하게 리팩토링 되었으며, stream을 활용함으로써 가독성을 향상시키려는 노력이 보입니다. 하지만 위의 몇 가지 방안들을 고려하여 코드 품질을 더욱 높이는 것이 좋습니다.
바로 MERGE하지 마세요! 검토 후 MERGE해야합니다!
✅ 최근 작업 주제 (하나 이상의 주제를 선택해주세요.)
🏆 구현 목표
파일 반환 dto optional로 변경
📋 구현 사항 설명 (작업한 내용을 상세하게 기록합니다.)
🔍 테스트 방법 (변경 사항을 확인하기 위한 테스트 방법을 기술합니다.)
🛠️ 쓰이는 모듈
💬 기타 질문 및 특이 사항