파일 URL 대신 스토리지 키를 저장하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

파일 레코드에는 생명주기가 다른 두 값이 있다. 오브젝트 키는 무엇을 저장했는지 식별한다. 전달 URL은 클라이언트가 오늘 그 파일에 접근하는 방법이다. 둘을 하나의 영구 문자열로 저장하면 바뀔 수 있는 주소를 안정적인 데이터처럼 다루게 된다.

일반적인 이미지 업로드라면 데이터베이스에는 안정적인 키나 상대 경로를 두고, 클라이언트에 보낼 주소는 서버 응답에서 조합하는 방식을 선호한다.

레코드에는 안정적인 식별자를 둔다

오브젝트 스토리지에 파일을 올릴 때는 키를 넘긴다. 이 키나 오브젝트를 찾는 데 필요한 상대 경로를 도메인 레코드와 함께 저장할 수 있다. 응답 계층에서는 여기에 설정된 전달 주소의 앞부분을 붙인다.

앞부분은 나중에 다른 도메인이나 CDN 주소로 바뀔 수 있다. 데이터베이스에 안정적인 부분만 있다면 저장된 URL을 모두 고치지 않고 응답을 조합하는 곳에서 전달 주소를 바꿀 수 있다.

그렇다고 스토리지 사이의 오브젝트 이동까지 없어지는 것은 아니다. 오브젝트를 옮기는 일은 별도의 스토리지 마이그레이션이다. 다만 클라이언트에 주는 주소 변경과 그 작업을 분리할 수 있다.

내부 키와 원본 파일명에 다른 역할을 준다

사용자가 올린 파일명은 서로 겹칠 수 있으므로 기본 스토리지 키로 쓰기 어렵다. 제품의 내부 규칙, 이미 존재하는 레코드 식별자, 시스템에 맞는 별도 고유 식별자로 내부 키를 만든다.

원본 파일명도 제품에서 필요할 수 있다. 나중에 사용자에게 보여줘야 한다면 별도 필드에 보관한다. 내부 키는 오브젝트를 찾고, 원본 이름은 화면에 표시한다. 두 역할을 합치면 불필요한 충돌이 생기고 이후 변경도 어려워진다.

업로드 경로는 별도로 선택한다

API 서버가 파일을 받아 올릴지, 클라이언트가 미리 발급된 주소로 직접 올릴지는 다른 결정이다. 리뷰 이미지나 프로필 이미지처럼 일반적인 크기의 파일은 측정 결과가 허용한다면 서버를 거치는 방식도 충분할 수 있다. 큰 미디어나 다른 트래픽 조건에서는 선택이 달라질 수 있다.

미리 발급된 주소를 쓰는 흐름에는 별도 생명주기 문제가 있다. 데이터베이스 행은 만들어졌지만 클라이언트가 오브젝트 업로드를 끝내지 않을 수 있으므로 그 상태를 설계에서 다뤄야 한다.

어떤 경로가 “99%“의 정답이라는 표현은 강조를 위한 수사이지 보편 규칙이 아니다. 파일 크기, 정합성 요구, 운영 복잡도와 측정 결과로 업로드 경로를 고른다. 어느 경로든 데이터 표현은 단순하게 유지할 수 있다. 안정적인 오브젝트 식별자를 저장하고, 제품에 필요할 때만 원본 이름을 따로 보존하며, 현재 전달 주소는 응답 경계에서 조합한다.