2025년 10월 06일·5분
대규모 환경에서의 안전한 파일 업로드: 서명된 URL과 검증
서명된 URL, 엄격한 형식·크기 검사, 악성코드 스캔, 권한 규칙으로 트래픽 증가 시에도 빠르게 동작하는 대규모 안전 파일 업로드 구현 방법.
서명된 URL, 엄격한 형식·크기 검사, 악성코드 스캔, 권한 규칙으로 트래픽 증가 시에도 빠르게 동작하는 대규모 안전 파일 업로드 구현 방법.
파일 업로드는 실제 사용자가 몰려들기 전까지는 단순해 보입니다. 한 사람이 프로필 사진을 올리다가 만약 1만 명이 동시에 PDF, 비디오, 스프레드시트를 올리면 앱이 느려지고 스토리지 비용이 급증하며 지원 티켓이 쌓입니다.
흔한 실패 사례는 예측 가능합니다. 앱 서버가 전체 파일을 처리하려고 해서 업로드 페이지가 멈추거나 타임아웃이 발생합니다. 권한이 엉켜서 누군가 파일 URL을 추측해 보지 말아야 할 것을 보게 됩니다. "무해해 보이는" 파일에 악성코드가 섞여 있거나 다운스트림 도구를 크래시 시키는 까다로운 형식일 수 있습니다. 로그가 불완전해 누가 언제 무엇을 업로드했는지 기본적인 질문에 답할 수 없게 됩니다.
원하는 것은 단조롭지만 신뢰할 수 있는 것들입니다: 빠른 업로드, 명확한 규칙(허용 형식과 크기), 사건 조사에 도움이 되는 감사 추적.
가장 어려운 절충점은 속도와 안전성입니다. 모든 검사를 사용자가 완료하기 전에 실행하면 사용자가 기다리고 재시도해 부하가 커집니다. 반대로 검사를 너무 늦추면 안전하지 않거나 권한 없는 파일이 퍼질 수 있습니다. 현실적인 접근법은 업로드와 검사를 분리하고 각 단계를 빠르고 측정 가능하게 유지하는 것입니다.
또한 "규모"를 구체화하세요. 파일 하루당 수, 분당 피크 업로드 수, 최대 파일 크기, 사용자의 위치를 적어두세요. 지역은 지연시간과 프라이버시 규정에 영향을 줍니다.
Koder.ai 같은 플랫폼 위에서 앱을 만든다면 이러한 한계를 초기에 정하는 것이 권한, 스토리지, 백그라운드 스캔 워크플로 설계에 큰 도움이 됩니다.
도구를 고르기 전에 무엇이 잘못될 수 있는지 명확히 하세요. 위협 모델은 큰 문서일 필요 없습니다. 방지해야 할 것, 나중에 탐지 가능한 것, 수락할 절충을 짧고 공유 가능한 방식으로 정리하면 됩니다.
공격자는 보통 몇 가지 예측 가능한 지점에서 침투를 시도합니다: 클라이언트(메타데이터 변경이나 MIME 타입 위조), 네트워크 엣지(재전송 및 속도 제한 남용), 스토리지(객체 이름 추측, 덮어쓰기), 다운로드/미리보기(위험한 렌더링 유발 또는 공유 접근으로 파일 탈취).
여기서 위협을 단순한 통제 수단으로 연결하세요:
과도한 크기 파일은 가장 쉬운 남용입니다. 비용을 늘리고 실제 사용자를 느리게 합니다. 바이트 한도를 강제하고 빠르게 거부하세요.
가짜 파일 타입도 흔합니다. invoice.pdf라는 이름이 다른 것일 수 있습니다. 확장자나 UI 체크를 믿지 마세요. 업로드 후 실제 바이트로 검증하세요.
악성코드는 다릅니다. 업로드 완료 전에 모든 것을 스캔하면 경험이 고통스러워질 수 있습니다. 일반 패턴은 비동기적으로 탐지하고 의심 항목을 격리한 뒤 스캔이 통과할 때까지 접근을 차단하는 것입니다.
권한 없는 접근은 보통 가장 큰 피해를 줍니다. 모든 업로드와 다운로드를 권한 결정으로 취급하세요. 사용자는 자신이 소유(또는 작성 허가가 있는) 위치에만 업로드해야 하며, 볼 수 있는 파일만 다운로드할 수 있어야 합니다.
많은 앱에 적합한 기본 v1 정책은 다음과 같습니다:
가장 빠른 업로드 방식은 앱 서버를 "바이트 비즈니스"에서 제외하는 것입니다. 모든 파일을 백엔드를 통해 전송하는 대신, 클라이언트가 단기 유효의 서명된 URL을 사용해 객체 스토리지로 직접 업로드하도록 하세요. 백엔드는 결정과 기록에 집중하고 기가바이트 전송을 처리하지 않습니다.
분리는 간단합니다: 백엔드는 "누가 무엇을 어디에 업로드할 수 있는가"에 답하고, 스토리지가 파일 데이터를 받습니다. 이렇게 하면 앱 서버가 인증과 파일 프록시를 동시에 하느라 CPU, 메모리, 네트워크가 병목되는 문제를 제거할 수 있습니다.
각 파일에 명확한 소유자와 수명 주기가 있도록 데이터베이스(예: PostgreSQL)에 작은 업로드 레코드를 유지하세요. 업로드 시작 전에 이 레코드를 만들고 이벤트가 발생할 때 업데이트합니다.
유용한 필드는 소유자 및 테넌트/워크스페이스 식별자, 스토리지 객체 키, 상태, 신고된 크기와 MIME 타입, 그리고 검증 가능한 체크섬 등입니다.
재시도가 발생해도 권한 검사가 올바르게 유지되도록 업로드를 상태 머신으로 다루세요.
실용적인 상태 집합 예시는 다음과 같습니다:
requesteduploadedscannedapprovedrejected백엔드가 requested 레코드를 생성한 후에만 클라이언트가 서명된 URL을 사용하도록 허용하세요. 스토리지에서 업로드를 확인하면 uploaded로 옮기고 백그라운드에서 악성코드 스캔을 시작한 뒤 approved가 될 때만 노출하세요.
사용자가 업로드를 클릭하면 앱이 파일 이름, 파일 크기, 용도(아바타, 인보이스, 첨부 등) 같은 기본 정보를 가지고 백엔드에 업로드 시작을 요청합니다. 백엔드는 해당 대상에 대한 권한을 확인하고 업로드 레코드를 생성한 후 단기 유효의 서명된 URL을 반환합니다.
서명된 URL은 좁게 범위를 정해야 합니다. 이상적으로는 하나의 정확한 객체 키에 대한 단일 업로드만 허용하고, 짧은 만료 시간과 명확한 조건(크기 한도, 허용 콘텐츠 타입, 선택적 체크섬)을 포함합니다.
브라우저는 그 URL을 사용해 스토리지로 직접 업로드합니다. 업로드가 끝나면 브라우저가 백엔드에 다시 호출해 완료를 알립니다. finalize 시 권한을 다시 확인하고(사용자 권한이 변경될 수 있음) 스토리지에 실제로 저장된 항목을 검증하세요: 크기, 감지된 콘텐츠 타입, 사용 시 체크섬. finalize는 재시도 시 중복을 만들지 않도록 멱등하게 만드세요.
그런 다음 레코드를 uploaded로 표시하고 백그라운드(큐/잡)에서 스캔을 트리거하세요. UI는 스캔이 진행되는 동안 "처리 중"을 표시할 수 있습니다.
확장자에 의존하면 invoice.pdf.exe가 버킷에 들어갑니다. 검증을 여러 곳에서 반복 가능한 검사 집합으로 처리하세요.
크기 제한부터 시작하세요. 서명된 URL 정책(또는 프리사인드 POST 조건)에 최대 크기를 넣어 스토리지가 초기에 큰 업로드를 거절하도록 하고, 백엔드가 메타데이터를 기록할 때도 동일한 한도를 적용하세요. 클라이언트는 UI를 우회하려 시도할 수 있습니다.
타입 검사는 파일명 기반이 아니라 콘텐츠 기반이어야 합니다. 파일의 첫 바이트(매직 바이트)를 검사해 기대한 것과 일치하는지 확인하세요. 실제 PDF는 %PDF로 시작하고 PNG는 고정 서명이 있습니다. 콘텐츠가 허용 목록과 다르면 확장자가 맞아도 거부하세요.
기능별로 허용 목록을 구체적으로 유지하세요. 아바타 업로드는 JPEG와 PNG만 허용할 수 있고, 문서 기능은 PDF와 DOCX만 허용할 수 있습니다. 이렇게 하면 위험을 줄이고 규칙 설명이 쉬워집니다.
원래 파일명을 스토리지 키로 절대 신뢰하지 마세요. 표시용으로 정규화(이상한 문자 제거, 길이 자르기)하되, 타입 감지 후 할당한 확장자를 포함한 UUID 같은 안전한 객체 키를 저장하세요.
데이터베이스에 체크섬(예: SHA-256)을 저장하고 이후 처리나 스캔에서 비교하세요. 이렇게 하면 손상, 부분 업로드, 재시도 중 변조를 잡아낼 수 있습니다.
악성코드 스캔은 중요하지만 결정 경로에 놓이면 안 됩니다. 업로드를 빠르게 수락한 뒤 파일을 차단 상태로 두어 스캔을 통과하기 전까지는 사용을 막으세요.
pending_scan 같은 상태로 업로드 레코드를 만들고, UI는 파일을 표시하되 아직 사용 불가능해야 합니다.
스캔은 객체가 생성될 때의 스토리지 이벤트로 트리거하거나 업로드 완료 직후 작업 큐에 잡을 게시하여 시작합니다(혹은 보완책으로 둘 다 사용). 스캔 워커는 객체를 다운로드하거나 스트리밍해 스캐너를 실행한 뒤 결과를 데이터베이스에 씁니다. 필수 항목은 스캔 상태, 스캐너 버전, 타임스탬프, 업로드 요청자 등입니다. 이 감사 추적은 "왜 내 파일이 차단됐나요?"라는 질문에 답할 때 도움이 됩니다.
실패한 파일을 정상 파일과 섞어두지 마세요. 일관된 정책을 선택해 적용하세요: 격리하고 접근을 제거하거나, 조사에 필요 없다면 삭제합니다.
사용자 메시지는 차분하고 구체적으로 하세요. 다음 조치(재업로드, 지원 문의)를 알려주고, 짧은 시간에 많은 실패가 발생하면 팀에 경고하세요.
무엇보다 다운로드와 미리보기에 대한 엄격한 규칙을 설정하세요: approved로 표시된 파일만 제공하고, 나머지는 "파일이 아직 검사 중입니다" 같은 안전한 응답을 반환하세요.
빠른 업로드는 좋지만 잘못된 사람이 잘못된 워크스페이스에 파일을 붙일 수 있으면 문제입니다. 가장 단순하면서 강력한 규칙은: 모든 파일 레코드는 정확히 하나의 테넌트(워크스페이스/조직/프로젝트)에 속하고 명확한 소유자나 생성자가 있어야 한다는 것입니다.
권한 검사를 두 번 수행하세요: 서명된 업로드 URL을 발급할 때와 누군가 파일을 다운로드/조회하려 할 때 다시 검증하세요. 첫 번째 검사는 무단 업로드를 막고, 두 번째 검사는 접근 권한이 취소되었거나 URL이 유출되었거나 사용자의 역할이 변경된 경우를 보호합니다.
최소 권한 원칙은 보안과 성능을 예측 가능하게 유지합니다. 모든 것을 하나의 광범위한 "files" 권한으로 두기보다 "업로드 가능","조회 가능","관리(삭제/공유) 가능" 같은 역할로 분리하세요. 많은 요청이 단순 조회(user, tenant, action)로 빠르게 처리될 수 있습니다.
ID 추측을 막기 위해 URL과 API에서 연속적인 파일 ID를 피하세요. 불투명 식별자를 사용하고 스토리지 키를 추측 불가능하게 유지하세요. 서명된 URL은 전송 수단이지 권한 시스템이 아닙니다.
공유는 시스템을 느리고 복잡하게 만드는 지점입니다. 공유를 암시적 접근이 아니라 명시적 데이터로 다루세요. 간단한 접근법은 사용자나 그룹에게 파일 하나에 대한 권한을 부여하는 별도의 공유 레코드를 두고 만료일을 옵션으로 제공하는 것입니다.
보안 검사에만 집중하다가 기본을 잊는 경우가 많습니다: 바이트 이동이 느린 부분입니다. 목표는 큰 파일 트래픽을 앱 서버 밖으로 유지하고, 재시도를 통제하며, 안전 검사 때문에 큐가 무한히 커지지 않게 하는 것입니다.
큰 파일에는 멀티파트나 청크 업로드를 사용해 불안정한 연결에서 처음부터 다시 시작하지 않게 하세요. 청크는 전체 최대 크기, 최대 청크 크기, 최대 업로드 시간 같은 명확한 한도를 강제하는 데도 도움이 됩니다.
클라이언트 타임아웃과 재시도를 의도적으로 설정하세요. 몇 번의 재시도는 실제 사용자에게 유용하지만 무제한 재시도는 비용을 폭주시킬 수 있습니다. 짧은 청크 타임아웃, 작은 재시도 한도, 전체 업로드에 대한 하드 데드라인을 목표로 하세요.
서명된 URL은 데이터 경로를 빠르게 하지만, 이를 생성하는 요청은 여전히 뜨거운 지점입니다. 다음으로 보호하세요:
지연시간은 지리적 위치에도 좌우됩니다. 가능하면 앱, 스토리지, 스캔 워커를 같은 리전에 두세요. 데이터 거주가 필요한 경우 업로드가 대륙을 오가며 지연되지 않도록 라우팅을 초기에 계획하세요. AWS 전역에서 운용되는 플랫폼(예: Koder.ai)은 데이터 거주가 중요할 때 워크로드를 사용자 근처에 배치할 수 있습니다.
마지막으로 다운로드도 계획하세요. 서명된 다운로드 URL로 파일을 제공하고 파일 타입과 프라이버시 수준에 따라 캐싱 규칙을 설정하세요. 공개 자산은 더 오래 캐시하고, 개인 영수증은 단기 유효로 유지하며 권한을 체크하세요.
직원들이 인보이스와 영수증 사진을 업로드하고 매니저가 비용 환급을 승인하는 소규모 비즈니스 앱을 상상하세요. 업로드 설계가 실무로 이어지는 지점입니다: 사용자 수가 많고 큰 이미지가 오가며 실제 비용이 걸려 있습니다.
좋은 흐름은 상태를 명확히 해 자동화할 부분을 줄이고 모두가 진행 상황을 알 수 있게 합니다: 파일은 객체 스토리지에 도착하고 업로드 레코드는 사용자/워크스페이스/비용 항목에 연결됩니다; 백그라운드 잡이 파일을 스캔하고 기본 메타데이터(실제 MIME 타입 등)를 추출한 뒤 항목은 승인되어 리포트에 사용되거나 거부되어 차단됩니다.
사용자는 빠르고 구체적인 피드백을 필요로 합니다. 파일이 너무 크면 한도와 현재 크기를 보여주세요(예: "파일은 18MB입니다. 최대 10MB"). 타입이 잘못되면 허용 항목을 알려주세요("PDF, JPG, PNG 업로드 가능"). 스캔 실패 시에는 차분하고 실행 가능한 안내("이 파일은 잠재적으로 안전하지 않습니다. 새 사본을 업로드하세요.")를 제공하세요.
지원팀은 파일을 열지 않고도 디버그할 수 있는 추적을 원합니다: 업로드 ID, 사용자 ID, 워크스페이스 ID, created/uploaded/scan started/scan finished 타임스탬프, 결과 코드(크기 초과, 타입 불일치, 스캔 실패, 권한 거부), 스토리지 키, 체크섬.
재업로드와 교체는 흔합니다. 이를 새 업로드로 처리하고 같은 비용 항목에 새 버전으로 붙여 누가 언제 교체했는지 히스토리를 유지하며 최신 버전만 활성으로 표시하세요. Koder.ai 위에서 이 앱을 만든다면 uploads 테이블과 expense_attachments 테이블의 버전 필드로 깔끔하게 매핑됩니다.
대부분 업로드 버그는 화려한 해킹이 아닙니다. 작은 지름길들이 트래픽이 늘어나면 실제 위험으로 바뀝니다.
더 많은 검사가 업로드를 느리게 만들 필요는 없습니다. 빠른 경로와 무거운 경로를 분리하세요.
인증, 크기, 허용 타입, 속도 제한 같은 빠른 검사는 동기적으로 하고, 스캔과 더 깊은 검사는 백그라운드 워커로 넘기세요. 사용자는 파일이 uploaded에서 ready로 이동하는 동안 작업을 계속할 수 있습니다. 채팅 기반 빌더인 Koder.ai로 개발할 때도 같은 사고방식을 유지하세요: 업로드 엔드포인트는 작고 엄격하게, 스캔과 후처리는 잡으로 미루세요.
출시 전에 "v1으로 충분히 안전"이 무엇인지 정의하세요. 팀은 보통 지나치게 엄격한 규칙(실제 사용자 차단)과 규칙 부재(남용 초대)를 섞어 문제를 만듭니다. 작은 범위로 시작하되 모든 업로드에 대해 "수신됨"에서 "다운로드 허용"까지 명확한 경로가 있는지 확인하세요.
긴밀한 출시 전 체크리스트:
최소 실행 정책이 필요하면 단순하게 유지하세요: 크기 제한, 좁은 타입 허용 목록, 서명된 URL 업로드, "스캔 통과 시까지 격리". 핵심 경로가 안정되면 미리보기, 더 많은 타입, 백그라운드 재처리 같은 기능을 추가하세요.
모니터링은 성장하면서 "빠름"이 "원인 알 수 없는 느림"으로 변하는 것을 막습니다. 업로드 실패율(클라이언트 vs 서버/스토리지), 스캔 실패율 및 스캔 지연, 파일 크기 버킷별 평균 업로드 시간, 다운로드 권한 거부, 스토리지 이그레스 패턴을 추적하세요.
현실적인 파일 크기와 실제 네트워크(모바일 데이터는 사무실 Wi-Fi와 다르게 동작)를 사용해 소규모 부하 테스트를 실행하세요. 출시 전에 타임아웃과 재시도를 수정하세요.
Koder.ai(koder.ai)에서 이것을 구현한다면 Planning Mode는 업로드 상태와 엔드포인트를 먼저 매핑한 뒤 그 흐름에 맞춰 백엔드와 UI를 생성하기에 실용적입니다. 스냅샷과 롤백은 한계를 조정하거나 스캔 규칙을 튜닝할 때도 도움이 됩니다.
앱 서버가 파일 바이트를 스트리밍하지 않도록 짧게 유효한 서명된 URL로 직접 객체 스토리지에 업로드하세요. 백엔드는 인증 결정과 업로드 상태 기록에 집중하고 기가바이트 전송은 처리하지 않습니다.
두 번 확인하세요: 업로드를 생성하고 서명된 URL을 발급할 때 한 번, 최종 확정 시와 파일을 제공할 때 다시 한 번. 서명된 URL은 전송 수단일 뿐이며 파일 레코드와 테넌트/워크스페이스에 연결된 권한 검사가 필요합니다.
재시도와 부분 실패가 보안 공백을 만들지 않도록 상태 머신으로 다루세요. 일반적인 흐름은 requested, uploaded, scanned, approved, rejected이며 다운로드는 approved일 때만 허용합니다.
서명된 URL 정책(또는 프리사인드 POST 조건)에 최대 바이트를 넣어 스토리지가 큰 파일을 초기에 거절하도록 하세요. 또한 finalize 단계에서 스토리지 보고 메타데이터로 동일한 한도를 다시 확인하세요.
파일명 확장자나 브라우저 MIME 타입을 신뢰하지 마세요. 업로드 후 실제 바이트(예: 매직 바이트)로 타입을 감지하고 해당 기능에 대한 엄격한 허용 목록과 비교하세요.
사용자에게 기다리게 하지 마세요. 업로드를 빠르게 수락하고 격리 상태로 두며 백그라운드에서 스캔을 실행하고, 클린 결과가 기록된 후에만 다운로드/미리보기를 허용하세요.
일관된 정책을 선택하세요: 격리하고 접근을 제거하거나, 조사에 필요 없다면 삭제하세요. 사용자에게는 차분하고 구체적인 안내(재업로드 또는 지원 문의)를 제공하고, 지원팀이 파일을 열지 않고도 설명할 수 있도록 감사 데이터를 유지하세요.
사용자가 제공한 파일명이나 경로를 스토리지 키로 절대 사용하지 마세요. UUID 같은 추측 불가능한 객체 키를 생성하고 원본 이름은 표시용 메타데이터로 정규화해 저장하세요.
중단된 연결에서 처음부터 다시 시작하지 않도록 멀티파트 또는 청크 업로드를 사용하세요. 재시도는 제한하고 타임아웃을 의도적으로 설정하며 전체 업로드에 대한 하드 데드라인을 두세요.
소규모 업로드 레코드에 소유자, 테넌트/워크스페이스, 객체 키, 상태, 타임스탬프, 감지된 타입, 크기, (사용한다면) 체크섬을 기록하세요. Koder.ai 위에서 구현한다면 Go 백엔드, PostgreSQL 업로드 테이블, 스캔용 백그라운드 잡으로 UI를 반응형으로 유지하기에 적합합니다.