[🔥TroubleShooting - MoodBuddy🔥] 사용자 피드백 🔊 : 일기 저장이 너무 느려요..😭😭

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

우리 무드버디는 2024.03 ~ 2024.08 기간 동안 1차 개발을 완료 후 배포하였으며, 사용자를 모집해서 서비스를 운영하였다.

운영을 하면서 사용자의 피드백을 꾸준히 받았으며, 가장 많이 받은 피드백 중 하나는 '일기 저장할 때 속도가 너무 느려요..' 이다.

위와 같은 문제가 발생하는 이유는 아래와 같다.

1. 일기 저장 API 호출 시, DB에 일기 정보 저장
2. 일기 저장 API 호출 시, S3에 일기 이미지 업로드 및 DB 저장
3. 일기 저장 API 호출 시, Open AI를 통한 일기 분석

📍 save

    @Override
    @Transactional
    public DiaryResDetailDTO save(DiaryReqSaveDTO diaryReqSaveDTO) throws IOException {
        final Long kakaoId = JwtUtil.getUserId();

        DiaryUtil.validateExistingDiary(diaryRepository, diaryReqSaveDTO.getDiaryDate(), kakaoId);

        String summary = gptService.summarize(diaryReqSaveDTO.getDiaryContent()).block();
        DiarySubject diarySubject = classifyDiaryContent(diaryReqSaveDTO.getDiaryContent());

        Diary diary = DiaryMapper.toDiaryEntity(diaryReqSaveDTO, kakaoId, summary, diarySubject);
        diary = diaryRepository.save(diary);

        DiaryUtil.saveDiaryImages(diaryImageService, diaryReqSaveDTO.getDiaryImgList(), diary);

        checkTodayDiary(diaryReqSaveDTO.getDiaryDate(), kakaoId, false);
        deleteDraftDiaries(diaryReqSaveDTO.getDiaryDate(), kakaoId);

        return DiaryMapper.toDetailDTO(diary);
    }

일기 저장할 때 위 세 가지를 한 번에 실행하기 때문에 일기 저장 시간이 오래 걸린다.

---

How

위 문제를 해결하기 위해서는 아래와 같이 일기 저장 API를 리팩토링해야 한다.

1. 일기 저장 API 호출 시 DB에 일기 정보 저장만 하도록 한다.
2. 일기 이미지 저장은 일기 저장 API와 분리한다.
3. Open AI를 통한 일기 분석 기능도 일기 저장 API와 분리한다.

---

Process

1. 일기 저장 API 호출 시 DB에 일기 정보 저장만 하도록 한다.
일기 저장은 기존 코드에서 저장 로직만 가져오고 깔끔하게 정리만 했다.

📍 DiaryApiController.java

@RestController
@RequestMapping("/api/v2/member/diary")
@Tag(name = "Diary", description = "일기 관련 API")
@RequiredArgsConstructor
public class DiaryApiController {
    private final DiaryFacade diaryFacade;

    @PostMapping("/save")
    @Operation(summary = "일기 작성", description = "새로운 일기를 작성합니다.")
    public ResponseEntity<DiaryResSaveDTO> saveDiary(@Parameter(description = "일기 정보를 담고 있는 DTO")
                                                      @RequestBody @Valid DiaryReqSaveDTO requestDTO) {
        return ResponseEntity.ok().body(diaryFacade.saveDiary(requestDTO));
    }
}

📍 DiaryFacadeImpl.java

@Component
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class DiaryFacadeImpl implements DiaryFacade {
    private final DiaryService diaryService;
    private final DraftDiaryService draftDiaryService;
    private final DiaryImageService diaryImageService;
    private final BookMarkService bookMarkService;
    private final UserService userService;
    private final RedisService redisService;

    @Override
    @Transactional
    public DiaryResSaveDTO saveDiary(DiaryReqSaveDTO requestDTO) {
        final var userId = JwtUtil.getUserId();
        diaryService.validateExistingDiary(userId, requestDTO.diaryDate());
        var diaryId = diaryService.saveDiary(userId, requestDTO);
        saveDiaryImages(diaryId, requestDTO.diaryImageUrls());
        checkTodayDiary(userId, requestDTO.diaryDate(), false);
        deleteData(userId, requestDTO.diaryDate());
        return new DiaryResSaveDTO(diaryId);
    }
}

📍 DiaryServiceImpl.java

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class DiaryServiceImpl implements DiaryService {
    private final DiaryRepository diaryRepository;

    @Override
    @Transactional
    public Long saveDiary(final Long userId, DiaryReqSaveDTO requestDTO) {
        return diaryRepository.save(Diary.of(
                requestDTO,
                userId)).getId();
    }
}

2. 일기 이미지 저장은 일기 저장 API와 분리한다.
처음 이미지 저장을 따로 API로 빼고 비동기 처리로 S3 업로드 및 DB 저장을 구현하려고 했다. 또 서버에서 썸네일 라이브러리를 활용해 이미지 리사이징을 적용했다.
하지만 서버에서 리사이징 ,S3 업로드 및 DB 저장을 직접 하는 건 시간도 오래 걸리고 보안상으로 안전하지 않다고 생각했다.

⛔️ 서버에서 직접 이미지 리사이징을 수행할 경우

• 서버의 리소스를 많이 사용하여 성능 저하 문제
• 여러 사용자가 동시에 업로드할 경우, 서버 부하 증가 문제
• 이미지 처리 과정에서 예상치 못한 오류 발생 문제

⛔️ S3 업로드 및 DB 저장을 서버에서 직접 처리할 경우

• API 응답 시간이 길어지는 문제
• 서버에서 파일을 직접 관리하는 것은 보안적으로 취약한 문제

그래서 위 방식의 문제를 덜어줄 수 있는 "Presigned URL" 방식을 다시 적용해 보기로 했다.

Presigned URL 이란?
Presigned URL은 클라이언트가 인증 없이 특정 S3 객체(파일)에 접근할 수 있도록 일시적으로 권한을 부여하는 URL이다.
즉, 서버에서 미리 서명된 URL을 생성하여 클라이언트에 전달하고, 클라이언트는 해당 URL을 사용하여 S3에 직접 파일을 업로드하거나 다운로드하는 방식이다.

📍 CloudController.java

@RestController
@RequestMapping("/api/v2/member/cloud")
@Tag(name = "Cloud", description = "클라우드 관련 API")
@RequiredArgsConstructor
public class CloudController {
    private final CloudService cloudService;

    @PostMapping("/generate-url")
    @Operation(summary = "preSignedUrl 생성 API", description = "preSignedUrl 생성 API 입니다.")
    public ResponseEntity<CloudResUrlDTO> generatePreSignedUrl() {
        return ResponseEntity.ok(cloudService.generatePreSignedUrl());
    }
}

📍 CloudServiceImpl.java

@Service
@RequiredArgsConstructor
public class CloudServiceImpl implements CloudService{
    private final AmazonS3 amazonS3;
    private final String dot = ".";
    @Value("${cloud.aws.s3.bucket}")
    private String bucket;
    @Value("${cloud.aws.s3.diary_images_folder}")
    private String profileImagesFolder;

    @Override
    public CloudResUrlDTO generatePreSignedUrl() {
        String fileName = UUID.randomUUID() + dot;
        String uploadPath = String.format("%s/%s/%s", profileImagesFolder, JwtUtil.getUserId(), fileName);

        GeneratePresignedUrlRequest generatePresignedUrlRequest = new GeneratePresignedUrlRequest(bucket, uploadPath)
                .withMethod(HttpMethod.PUT)
                .withExpiration(getExpirationTime());

        return new CloudResUrlDTO(amazonS3.generatePresignedUrl(generatePresignedUrlRequest).toString());
    }

    private Date getExpirationTime() {
        long expirationMillis = System.currentTimeMillis() + (1000 * 60 * 10);
        return new Date(expirationMillis);
    }
}

위 로직을 통해 Presigned URL을 클라이언트에서 요청하면 발급한다. 그리고 일기 저장을 할 때 클라이언트가 List에 이미지 URL을 담아서 주면 바로 DB에 저장하면 된다.

이렇게 하면 일기 저장와 일기 이미지 저장을 확실하게 분리할 수 있게 된다.

3. Open AI를 통한 일기 분석 기능도 일기 저장 API와 분리한다.
일기 분석 기능은 Open AI를 호출하고 GPT의 답변을 기다리고 받는 것이기 때문에 가장 오랜 시간을 차지한다. 그렇기 때문에 이를 일기 저장 API에 포함하는 것보단 아예 일기 분석 API를 만들어서 따로 요청하는 것이 가장 좋은 방식이었다.

@RestController
@RequestMapping("/api/v2/member/diary")
@Tag(name = "Diary", description = "일기 관련 API")
@RequiredArgsConstructor
public class DiaryAnalyzeApiController {
    private final DiaryAnalyzeFacade diaryAnalyzeFacade;

    @PostMapping("/analyze/{diaryId}")
    @Operation(summary = "일기 분석 (요약, 주제, 감정)", description = "작성된 일기를 분석합니다. 일기 저장, 일기 수정, 임시저장 일기 -> 일기 저장 할 때 호출하면 됩니다.")
    public ResponseEntity<DiaryResAnalyzeDTO> analyzeDiary(@Parameter(description = "일기 고유 식별자")
                                                           @PathVariable("diaryId") Long diaryId) {
        return ResponseEntity.ok().body(diaryAnalyzeFacade.analyze(diaryId));
    }
}

---

Result

위 과정을 통해 1차 배포 때에 비해 어느 정도 일기 저장 시간을 단축했는지 포스트맨을 통해 확인해 보았다.

postman 테스트 결과 [일기 저장 3.78s + 감정 분석 798ms = 4.578s]

postman 테스트 결과 [일기 저장 233ms + 일기 분석 1.49s = 1.723s]

결과, 1차 배포 때에 비해 일기 저장 2.855초를 단축할 수 있었다.

---

Thoughts

위 경험을 통해 한 기능을 구현하더라도 기능을 분리할 수 있으면 분리해서 성능을 개선하는 것이 좋다는 생각을 했다.
그리고 성능 개선보다 더 크게 배운 점은 "사용자"의 중요성이다. 만약 사용자에게 직접 배포하지 않고 프로젝트를 끝냈다면, 어떤 기능이 문제가 있고 어떤 기능을 개선해야 하는지 깨달을 수 없었을 것이다.

앞으로 개발에 있어서 사용자 배포는 없어서는 안 될 과정이라는 것을 배울 수 있었고, 사용자의 피드백을 수용하는 것도 없어서는 안 될 과정이라는 것을 배울 수 있었다.

---