[QRoad]PDF 기반 publication 업로드 구조 개선기 - 1편 구조의 문제

이 글은 「PDF 기반 publication 업로드 구조 개선기」 시리즈의 1편입니다.

(1편) 기존 구조의 문제점 → (2편) S3 presigned URL 설계 → (3편) Spring Boot 구현

 

프로젝트 초반에는 /api/admin/publications API를 통해
publication을 텍스트 기반으로 저장하고 있었다.

프론트에서 텍스트를 입력하면 백엔드에서 그대로 DB에 저장하는 구조였고,
초기 기능 구현 속도도 빨라서 큰 문제는 없어 보였다.

하지만 프로젝트가 어느 정도 진행되면서
이 방식이 점점 현실과 맞지 않는다는 느낌이 들기 시작했다.

---

원본 데이터는 텍스트가 아니라 PDF였다

publication의 실제 원본은 대부분 PDF 파일이었다.

관리자는 PDF 파일을 업로드하고, 그 파일을 기준으로 publication을 생성하고 싶어 했지만
시스템은 오직 텍스트 입력만을 전제로 설계되어 있었다.

결국 다음과 같은 불편함이 생겼다.

• PDF를 직접 열어서 내용을 복사해야 하고
• 텍스트 변환 과정이 사람에게 맡겨지며
• “원본 파일”이라는 개념이 시스템에 남지 않는다

단순히 기능의 문제가 아니라, 데이터 흐름 자체가 어색한 구조라는 생각이 들었다.

---

기존 API에 파일 업로드를 붙이기엔 부담이 컸다

가장 먼저 떠올린 해결책은 단순했다.

“그럼 /api/admin/publications에서multipart로 PDF를 받아서 서버에서 바로 S3에 업로드하면 되지 않을까?”

 

하지만 조금만 생각해보면 이 방식에는 여러 문제가 있었다.

• 서버가 파일 데이터를 직접 받게 되고
• 파일 크기가 커질수록 메모리/디스크 부담이 생기며
• 업로드 중 문제가 생기면 요청 전체가 실패한다

무엇보다도, 파일 업로드와 publication 저장이
하나의 API에 강하게 결합된다는 점이 가장 마음에 걸렸다.

---

역할 분리가 되지 않는 구조였다

이 프로젝트는 팀 단위로 진행되고 있었고, 나는 파일 업로드와 저장 흐름을 담당하고 있었다.

하지만 기존 구조에서는:

• 파일 업로드
• PDF 처리
• publication DB 저장

이 모든 책임이 한 API 안에 섞일 가능성이 컸다.

이렇게 되면

• 역할 경계가 흐려지고
• 작은 변경에도 서로 영향을 주며
• 유지보수가 어려운 구조가 될 수 있다고 판단했다.

---

그래서 이런 고민이 생겼다

“publication 생성 API는 유지하면서,
파일 업로드만 더 안전하고 확장 가능한 구조로
분리할 수는 없을까?”

 

이 질문이 이번 구조 개선의 출발점이었다.