사내 프로젝트에서 에디터를 새로 만들기로 하였다.
그 전 에디터는 교육이 필요할 정도로 쓰기가 복잡했었는데, 이번에 재정비를 하면서
사용자 친화적이고 직관적인 에디터를 원하셨다. 다행히 나는 이전 개인 프로젝트에서 글모임 서비스를 운영해본 경험이 있기 때문에 낯선 개념이 아니다.
요구사항들을 다음과 같았다.
- 첨부파일 다중 첨부
- 글 중간에 사진 첨부
- 해시태그 기능
- 카테고리 소분류, 대분류
- 문서 간 전환을 나타내는 탭 기능
- 임시저장, 수정, 최종제출
- 접근할 수 있는 카테고리 목록, 광고 설정 등이 권한에 따라 달라짐
먼저 유저 플로우 설계를 팀원들과 함께 진행했으며, 백엔드와의 주요 논의 지점은이미지를 어떻게 업로드할것이냐 였다
우선 이미지 업로드 방식들에 대해 알아보자
1. Base64 인코딩 업로드
이미지를 Base64로 변환 후 JSON 형식으로 서버로 전송
Base64 인코딩은 파일 크기를 약 33% 더 크게 만든다.
이로 인해 데이터 전송량이 증가하고, 업로드 시간이 늘어나며, 네트워크 비용이 더 많이 소모될 수 있다.
Base64로 인코딩된 이미지는 서버에서 다시 디코딩 후 저장해야 하므로, 서버의 처리 시간이 증가할 수 있다.
특히 대량의 파일 업로드 요청이 있을 경우, 서버의 CPU와 메모리 리소스가 크게 소모될 수 있다.
간단한 데이터 전송에만 쓰고 실무에선 거의 쓰지 않는 방식이라고 한다.
2. 클라이언트 -> 서버 -> 클라우드 (Proxy Server Upload)
클라이언트가 이미지를 서버로 보내면, 서버가 이를 클라우드 스토리지로 전송.
보안 및 검증이 용이하다
서버와 클라우드 스토리지의 관리 용이성 증가.
서버의 중간 역할로 인해 트래픽 증가 및 과부하가 생길 수 있음
3. 직접 클라우드 업로드 (Direct to Cloud Storage)
클라이언트가 이미지를 클라우드 인증 토큰을 받아 직접 클라우드 스토리지로 업로드.
서버 트래픽 감소.
업로드 속도 향상.
클라이언트에서 파일 크기 제한, 인증 등을 처리해야 함.
우리는 3번 방식을 채택했다.
많은 사진들과 첨부파일로 인해서 서버 부하가 클거라고 생각햇기 때문에.
Presigned URL
서버는 클라우드 스토리지 서비스에서 특정한 리소스에 대한 접근을 허용하는 URL를 생성한다. 이 URL을 Presigned URL이라고 부르고, 주로 파일 업로드나 다운로드 작업에 사용된다. 클라이언트는 이 URL을 통해 클라우드 스토리지에 직접 접근하여 파일을 업로드하거나 다운로드할 수 있다
1. 여기서 보안 문제가 신경이 쓰였다.
Presigned URL은 유효 기간이 설정된 임시 URL이기 때문에 URL을 알게 된 다른 사람이 해당 URL을 사용할 수 있다. 만약 이 URL이 유출되면, 유효 기간 내에 누구든지 그 URL을 통해 파일을 업로드하거나 다운로드할 수 있다. 이는 보안에 취약점을 만든다.
2. 글을 쓰는 동안 Presigned URL이 만료된다면 재발급해주는 로직이 필요해보인다.
3. 글을 쓰면서 첨부했다가 다시 지운 사진의 경우에도 이미 스토리지에 올라가기 때문에 리소스가 낭비될것이다.
이 세가지 문제를 해소시켜줄 수 있는 해결책을 찾았다.
1️⃣ 제출버튼(최종제출,임시저장)을 누르면 ➡️ 2️⃣ Presigned URL 발급 ➡️ 3️⃣ 이미지 스토리지에 올리기
이렇게 순차적으로 시행하고, 만료시간도 최대한 짧게 설정하는 것이다.
그렇게 하면 Presigned Url이 딱 필요한 순간에 발급을 해서 최종 이미지를 하나씩 업로드하니까 보안의 취약점을 어느정도 보완하면서 서버 자원도 절약할 수 있을 것이다.
