파일 업로드 바이러스 검사: 앱을 위한 아키텍처 옵션

문제를 알기 쉽게 정리하면: 앱에 안전하지 않은 파일이 들어오는 문제

앱에서 사용자가 문서를 업로드할 수 있게 하면, 당신은 직접 만들지 않은 파일을 받아들입니다. 고객 포털, 인사 시스템, 청구 앱, 공급업체 온보딩처럼 문서 중심 제품에서는 업로드가 잦고, 사용자들이 이메일, 공유 드라이브, 제3자에서 가져온 파일을 올리는 일이 많습니다. 그래서 이런 앱은 실용적인 공격 대상이 됩니다: 한 번의 성공적인 업로드가 많은 다운로드로 확산될 수 있습니다.

위험은 단지 “바이러스”에 국한되지 않습니다. Word나 Excel 파일에는 악성 매크로가 들어있을 수 있고, PDF는 리더의 취약점을 이용하도록 조작될 수 있으며, “송장”처럼 보이는 문서는 사기성 문서로 전화를 걸어 가짜 번호에 연결하거나 자격증명을 입력하게 만들 수 있습니다. ZIP 안에 페이로드를 숨기거나, 이중 확장자(report.pdf.exe)를 사용하거나, 원격 콘텐츠를 포함해 열 때 외부로 접속하도록 하는 등 조용히 피해를 주는 파일도 있습니다.

단일 서버에 설치된 단순한 안티바이러스만 의존하는 것은 충분하지 않습니다. 업로드는 여러 앱 인스턴스에 도달할 수 있고, 저장 시스템 간에 이동하거나 오브젝트 스토리지나 CDN에서 제공될 수 있습니다. 어떤 코드 경로가 실수로 원본 업로드를 노출하면, 스캔이 완료되기 전에 사용자가 다운로드할 수 있습니다. 업데이트, 잘못된 구성, 그리고 “임시” 관리자 권한도 시간이 지나면서 스캔을 우회할 수 있습니다.

파일 업로드 바이러스 검사의 분명한 목표는 간단합니다: 스캔되지 않은 파일은 명시적으로 검토 권한이 있는 사람 이외에는 절대 다운로드되거나 열람되어서는 안 됩니다.

“안전”이 무엇인지 감정이 아니라 비즈니스 규칙으로 정의하세요. 예를 들어:

• 최신 시그니처 집합으로 악성코드 검사를 통과해야 함
• 허용된 파일 유형과 크기 제한에 부합해야 함
• 승인된 위치에서만 저장 및 제공되어야 함
• 누가 업로드했고 언제 최종 상태가 어땠는지 감사 추적이 있어야 함
• 최종 결정(릴리스 또는 거부)까지 차단되어야 함

AppMaster 같은 플랫폼으로 빌드한다면, 데이터 모델에서 “스캔 상태”를 일급 필드로 취급하고 모든 다운로드 동작이 이를 확인하도록 만드세요. 그 한 번의 게이트가 많은 값비싼 실수를 막아줍니다.

업로드 문서의 격리(quarantine)가 실제로 의미하는 것

“격리”는 저장소의 단순한 폴더가 아니라 시스템 내 상태로 생각하는 것이 가장 좋습니다. 핵심 아이디어는 간단합니다: 파일은 존재하지만, 앱에서 명확하게 기록된 스캔 결과가 나오기 전까지 아무도 열거나 다운로드할 수 없습니다. 이것이 파일 업로드 바이러스 검사에서 가장 중요한 부분입니다.

격리는 보통 명확한 상태를 가진 작은 라이프사이클로 동작합니다. 상태를 명시적으로 유지하면 미리보기, 직접 URL, 또는 내보내기 작업을 통해 안전하지 않은 콘텐츠가 실수로 노출되는 것을 줄일 수 있습니다.

실용적인 파일 상태 집합은 다음과 같습니다:

• received (업로드 완료, 스캔 전)
• scanning (작업자가 가져가서 스캔 중)
• clean (릴리스 가능)
• rejected (악성코드 발견 또는 정책 위반)
• failed (스캐너 오류, 타임아웃, 손상된 파일)

격리는 나중에 액세스를 강제하고 어떤 일이 있었는지 감시할 수 있도록 적절한 메타데이터도 필요로 합니다. 최소한 다음을 저장하세요: 소유자(사용자 또는 조직), 상태, 원본 파일명 및 타입, 체크섬(중복 제거 및 변조 확인용), 저장 위치, 타임스탬프(업로드, 스캔 시작, 스캔 종료). 많은 팀은 스캐너 버전과 스캔 판정 세부 정보도 함께 저장합니다.

보존 기간은 정책 결정 사항이지만 의도적이어야 합니다. 격리된 파일은 스캔 및 실패 디버깅에 필요한 기간만큼만 보관하세요. 짧은 보존 기간은 위험과 비용을 줄이지만, 사고 조사와 사용자가 “내 업로드가 어디로 갔나요?”라고 물을 때 대응할 시간을 확보해야 합니다.

마지막으로, 스캔이 끝나지 않는 파일에 대해 무엇을 할지 결정하세요. 최대 스캔 시간을 정하고 “만료” 타임스탬프를 설정하세요. 기한이 지나면 파일을 failed로 옮기고 접근을 차단한 뒤 자동으로 제한된 횟수만 재시도하거나 삭제하고 사용자가 다시 업로드하도록 요청하세요.

위험을 줄이는 임시 저장 패턴

대부분 업로드 문제가 발생하는 곳은 임시 저장소입니다. 파일은 시스템에 있지만 아직 안전한지 모르는 상태이므로, 잠그기 쉽고 실수로 노출되기 어려운 장소가 필요합니다.

로컬 디스크는 단일 서버에서는 작동할 수 있지만 취약합니다. 앱 서버를 확장하면 저장소를 공유하거나 파일을 복사하고 권한을 일관되게 유지해야 합니다. 오브젝트 스토리지(S3 스타일 버킷이나 클라우드 컨테이너)는 문서 중심 앱에 더 안전한 경우가 많습니다. 접근 규칙이 중앙화되고 로그가 더 명확하기 때문입니다.

파일 업로드 바이러스 검사에 대한 간단한 패턴은 “격리(quarantine)”와 “클린(clean)” 저장소를 분리하는 것입니다. 두 개의 버킷/컨테이너로 구현하면 실수를 줄이기 쉽고, 하나의 버킷 내에서 엄격한 접두사(prefix) 구조로 관리하면 비용과 관리가 더 쉬울 수 있습니다.

접두사를 사용할 경우 혼동할 수 없게 만드세요. quarantine/\u003ctenant_id\u003e/\u003cupload_id\u003e 및 clean/\u003ctenant_id\u003e/\u003cdocument_id\u003e 같은 레이아웃을 선호하세요. 사용자 제공 이름을 사용하지 마세요. 서로 다른 상태에 대해 같은 경로를 재사용하지 마세요.

다음 규칙을 염두에 두세요:

• 격리에는 공개 읽기 권한을 허용하지 마세요, 임시라도 안 됩니다.
• 서버 측에서 오브젝트 이름을 생성하고 클라이언트 이름을 사용하지 마세요.
• 테넌트 또는 계정별로 파티셔닝하여 피해 범위를 줄이세요.
• 메타데이터(소유자, 상태, 체크섬)는 파일명에 넣지 말고 데이터베이스에 저장하세요.

암호화를 저장 시 적용하고 누가 복호화할 수 있는지 엄격히 통제하세요. 업로드 API는 quarantine에 쓸 수 있어야 하고, 스캐너는 quarantine에서 읽고 clean에 쓸 수 있어야 하며, 공개용 앱은 clean에서만 읽을 수 있어야 합니다. 클라우드가 키 정책을 지원하면 복호화 권한을 가능한 한 적은 역할에 묶으세요.

대용량 파일은 추가 주의가 필요합니다. 멀티파트 업로드의 경우 최종 파트가 커밋되고 예상 크기와 체크섬을 기록할 때까지 객체를 “준비 완료”로 표시하지 마세요. 안전한 접근 방식은 파트를 quarantine에 업로드한 다음 스캔이 통과하면 객체를 복사하거나 승격(promote)하는 것입니다.

예시: AppMaster로 만든 고객 포털에서는 모든 업로드를 “pending”으로 처리하고 격리 버킷에 저장한 뒤, 스캔 결과가 status를 “clean”으로 바꿀 때까지 다운로드 버튼을 표시하지 않을 수 있습니다.

아키텍처 옵션: 인라인 스캔 vs 백그라운드 스캔

파일 업로드에 바이러스 스캔을 추가할 때 보통 두 가지 흐름 중 하나를 선택합니다: 인라인 스캔(사용자가 기다림) 또는 백그라운드 스캔(앱이 업로드를 수락하지만 클리어될 때까지 접근을 차단). 올바른 선택은 “보안 수준”보다 속도, 신뢰성, 업로드 빈도에 더 좌우됩니다.

옵션 1: 인라인 스캔(사용자 대기)

인라인 스캔은 스캐너가 결과를 반환할 때까지 업로드 요청이 완료되지 않는 것을 의미합니다. 업로드 → 스캔 → 허용/거부의 한 단계로 느껴져서 단순하게 느껴집니다.

인라인 스캔은 파일이 작고 업로드가 드물며 대기 시간이 예측 가능할 때 보통 허용됩니다. 예를 들어 팀 도구에서 사용자가 하루에 몇 개의 PDF만 업로드한다면 3~10초 대기는 괜찮을 수 있습니다. 단점은 스캔이 느리면 앱 전체가 느려진다는 점입니다. 타임아웃, 재시도, 모바일 네트워크는 정상 파일이라도 사용자 경험을 악화시킬 수 있습니다.

옵션 2: 백그라운드 스캔(비동기)

비동기 스캔은 먼저 파일을 저장하고 상태를 “quarantined”로 표시한 뒤 스캔 작업을 큐에 넣는 방식입니다. 사용자는 빠른 "업로드 수신" 응답을 받지만 파일이 클리어될 때까지 다운로드나 미리보기를 할 수 없습니다.

이 접근법은 대량 처리, 큰 파일, 바쁜 시간대에 좋습니다. 작업을 분산시키고 앱 응답성을 유지할 수 있으며, 스캐닝 워커를 웹/API 서버와 별도로 확장할 수 있기 때문입니다.

실용적인 하이브리드는 인라인에서 빠른 검사(파일 유형 허용목록, 크기 제한, 기본 포맷 검증)를 수행하고 전체 안티바이러스 검사를 백그라운드에서 하는 것입니다. 이렇게 하면 명백한 문제는 빨리 잡고 모든 사용자를 대기시키지 않습니다.

선택 가이드:

• 작은 파일, 낮은 볼륨, 즉시 결과가 필요한 워크플로우: 인라인 스캔
• 큰 파일, 많은 업로드, 예측 불가한 스캔 시간: 백그라운드 스캔
• 업로드 응답성에 대한 엄격한 SLA: 백그라운드 스캔 + 명확한 상태 UI
• 혼합 워크로드: 하이브리드(빠른 검사 우선, 전체 스캔은 비동기)

AppMaster로 빌드할 경우, 이 선택은 동기 API 엔드포인트(인라인) 또는 스캔 작업을 큐에 넣고 결과가 도착하면 파일 상태를 업데이트하는 비즈니스 프로세스(비동기)로 깔끔하게 매핑됩니다.

단계별: 비동기 스캔 큐 구축하기

비동기 스캔은 업로드를 수락하고 격리에 잠그고 백그라운드에서 스캔하는 것을 의미합니다. 사용자는 스캐너가 안전하다고 말할 때까지 접근할 수 없습니다. 문서 중심 앱에서는 보통 이것이 가장 실용적인 악성코드 스캔 아키텍처입니다.

1) 큐 메시지 정의(작게 유지)

큐는 할 일 목록입니다. 각 업로드는 파일 자체가 아니라 파일을 가리키는 하나의 메시지를 만듭니다.

간단한 메시지는 보통 다음을 포함합니다:

• 파일 ID(또는 오브젝트 키)와 테넌트 또는 프로젝트 ID
• 업로드한 사용자 ID
• 업로드 타임스탬프와 체크섬(선택 사항이지만 유용함)
• 시도 번호(또는 별도의 재시도 카운터)

큐에 원시 바이트를 넣지 마세요. 대용량 페이로드는 한도를 초과하고 비용이 늘며 노출 범위를 확대할 수 있습니다.

2) 워커 흐름 구축(가져오기 → 스캔 → 기록)

워커는 메시지를 가져와 격리 저장소에서 파일을 가져와 스캔한 뒤 결정을 기록합니다.

명확한 흐름:

• 격리 저장소(프라이빗 버킷 또는 프라이빗 볼륨)에서 파일 ID로 파일을 가져옴
• 스캐너(AV 엔진 또는 스캐닝 서비스) 실행
• 결과를 데이터베이스에 기록: 상태(clean, infected, error), 스캐너 이름/버전, 타임스탬프
• clean일 경우: 파일을 승인된 저장소로 이동하거나 접근 플래그를 전환해 다운로드 가능하게 함
• infected일 경우: 격리에 유지하거나 삭제하고 관련자에게 알림

3) 멱등성(idempotent) 확보(재처리 안전)

워커는 충돌하고 메시지가 중복 전달되며 재시도가 발생합니다. 같은 파일을 여러 번 스캔해도 해가 없도록 설계하세요. 단일 진실 소스(예: files.status)를 사용하고 유효한 전환만 허용하세요. 예: uploaded -> scanning -> clean/infected/error. 워커가 clean을 보면 메시지를 인정하고 중지해야 합니다.

4) 동시성 제어(스캔 폭주 방지)

워커당 및 테넌트당 제한을 설정하세요. 동시에 실행할 수 있는 스캔 수를 제한하고 큰 파일을 위한 별도 큐를 고려하세요. 이는 바쁜 고객 하나가 모든 스캐너 용량을 소비하는 것을 방지합니다.

5) 실패 처리: 재시도와 감사 기록

스캐너 타임아웃, 네트워크 문제 같은 일시적 오류에는 재시도를 사용하고 최대 시도 횟수를 작게 설정하세요. 그 이후에는 수동 검토를 위한 데드레터 큐로 보냅니다.

감사 기록을 유지하세요: 누가 문서를 업로드했는지, 언제 격리에 들어갔는지, 어떤 스캐너가 실행되었는지, 어떤 결정을 내렸는지, 누가 파일을 승인하거나 삭제했는지 등. 이 로그는 고객 포털과 규정 준수를 위해 바이러스 스캔만큼 중요합니다.

접근 제어: 격리된 파일을 진짜로 비공개로 유지하기

격리는 단순한 데이터베이스 상태가 아닙니다. 아무도 파일이 안전하다고 증명되기 전까지 열 수 없다는 약속입니다. 가장 안전한 규칙은 간단합니다: 격리된 파일은 임시 URL이라도 공개적으로 제공하지 마세요.

다운로드 흐름은 단조롭고 엄격해야 합니다. 앱은 모든 다운로드를 이미지 가져오기처럼 취급하지 말고 보호된 액션으로 취급해야 합니다.

좋은 다운로드 흐름 예:

1. 다운로드 요청 수신
2. 해당 파일에 대한 사용자의 권한 확인
3. 파일 상태 확인(quarantined, clean, rejected)
4. 상태가 clean일 경우에만 파일 전달

사인된 URL을 사용하는 경우에도 동일한 아이디어를 지키세요: 권한과 상태 확인 후에만 생성하고 유효기간을 짧게 유지하세요. 유효기간이 짧으면 링크가 로그, 스크린샷, 전달된 이메일을 통해 유출되어도 피해를 줄입니다.

역할 기반 접근 제어는 특수 케이스 로직이 구멍으로 변하는 것을 피하게 해줍니다. 문서 중심 앱의 일반적인 역할은 다음과 같습니다:

• 업로더: 자신의 업로드와 스캔 상태를 볼 수 있음
• 리뷰어: 클린 파일을 볼 수 있고, 필요하면 안전한 검토 도구에서 격리 파일을 볼 수 있음
• 관리자: 조사, 재스캔, 권한 재정의를 할 수 있음
• 외부 사용자: 명시적으로 공유된 문서만 접근 가능

또한 ID 추측 공격을 방지하세요. 12345 같은 증가하는 파일 ID를 노출하지 마세요. 불투명한 ID를 사용하고 항상 사용자 및 파일별로 권한을 확인하세요(단지 “로그인된 사용자”만 체크하지 말 것). 저장소 버킷이 비공개여도 부주의한 API 엔드포인트가 격리된 콘텐츠를 유출할 수 있습니다.

파일 업로드 바이러스 검사를 구현할 때 접근 계층에서 실제 실패가 가장 많이 발생합니다. AppMaster 같은 플랫폼에서는 API 엔드포인트와 비즈니스 로직에서 이러한 검사를 강제하여 격리가 기본적으로 비공개로 유지되게 할 수 있습니다.

릴리스, 거부, 재시도: 스캔 결과 처리

파일이 스캔을 완료하면 가장 중요한 것은 명확한 상태로 이동시키고 다음 단계를 예측 가능하게 만드는 것입니다. 파일 업로드 바이러스 검사를 구축할 때 스캔 결과를 게이트로 취급하세요: 게이트가 허용하지 않으면 아무것도 다운로드 가능해지지 않습니다.

대부분 시스템에 적합한 간단한 결과 집합:

• Clean: 격리에서 해제하고 정상 접근 허용
• Infected: 접근을 영구 차단하고 감염 파일 워크플로우를 트리거
• Unsupported: 스캐너가 평가하지 못함(예: 암호로 보호됨). 차단 유지
• Scan error: 일시적 실패(타임아웃, 서비스 불가). 차단 유지

사용자 메시지는 명확하고 차분해야 합니다. “계정이 손상되었습니다” 같은 위협적인 문구는 피하세요. 더 나은 문구 예: “파일을 검사 중입니다. 계속 작업하세요.” 파일이 차단되었을 때는 사용자가 취할 수 있는 다음 행동을 알려주세요: “다른 파일 형식을 업로드하세요” 또는 “나중에 다시 시도하세요.” 지원되지 않는 파일의 경우 구체적으로 안내하세요(예: “암호화된 압축 파일은 스캔할 수 없습니다”).

감염된 파일의 경우 삭제할지 보관할지 초기에 결정하세요. 삭제가 더 간단하고 위험을 줄입니다. 보관은 감사를 위해 도움이 되지만, 격리된 영역에 엄격한 접근과 짧은 보존 기간을 두고 누가 볼 수 있는지(이상적으로는 보안 관리자만) 기록해야 합니다.

재시도는 일시적 오류에 유용하지만 무한 재시도로 쌓이지 않도록 하세요. 작은 재시도 정책을 설정하세요:

• 타임아웃과 스캐너 다운 시 재시도
• infected 또는 unsupported에는 재시도하지 않음
• 재시도 횟수 제한(예: 3회) 후 failed로 표시
• 재시도 간 백오프 추가하여 과부하 방지

마지막으로 반복되는 실패는 사용자 문제로 보지 말고 운영 문제로 다루세요. 많은 파일이 짧은 시간에 “scan error”로 떨어지면 팀에 알리고 새 릴리스를 일시 중지하세요. AppMaster에서는 데이터베이스에 이러한 상태를 모델링하고 내장 메시징 모듈로 알림을 라우팅할 수 있어 실패를 빠르게 인지하게 도와줍니다.

예시 시나리오: 문서가 많은 고객 포털

고객 포털에서는 클라이언트가 각 프로젝트에 대한 송장과 계약서를 업로드합니다. 사용자가 데스크톱에 있는 것을 그대로 끌어다 올리기 때문에 파일 업로드 바이러스 검사가 중요한 곳입니다.

고객이 PDF를 업로드하면 포털은 임시 비공개 위치에 저장하고 상태를 Pending scan으로 설정한 데이터베이스 레코드를 만듭니다. 파일은 아직 다운로드 가능으로 표시되지 않습니다. 스캐닝 워커가 큐에서 파일을 가져와 스캔을 실행한 뒤 레코드를 Clean 또는 Blocked로 업데이트합니다.

UI에서 고객은 문서가 즉시 나타나지만 명확한 Pending 배지가 붙어 있습니다. 파일명과 크기는 보여서 업로드가 성공했음을 알 수 있지만 스캔이 클린이 될 때까지 다운로드 버튼은 비활성화됩니다. 스캔이 예상보다 오래 걸리면 포털은 “이 파일의 안전성을 검사 중입니다. 1분 후 다시 시도하세요.” 같은 간단한 메시지를 표시할 수 있습니다.

스캐너가 문서를 플래그하면 고객에게는 “보안 검사를 통과하지 못했습니다”라는 짧고 기술적이지 않은 안내가 표시됩니다. 지원 및 관리자에게는 스캔 사유와 다음 조치가 포함된 별도의 뷰가 제공됩니다. 그들은 다음을 할 수 있습니다:

• 차단 상태를 유지하고 새 업로드를 요청
• 삭제하고 사유 기록
• 정책상 허용되는 경우 오탐으로 표시(관리자 전용)

분쟁(“어제 업로드했는데 잃어버렸어요”)이 발생했을 때는 잘 정리된 로그가 중요합니다. 업로드 수신, 스캔 시작, 스캔 종료, 상태 변경, 누가 어떤 조치를 했는지에 대한 타임스탬프를 보관하세요. 또한 파일 해시, 원본 파일명, 업로더 계정, IP 주소, 스캐너 결과 코드를 저장하세요. AppMaster로 이 기능을 구현하면 Data Designer와 간단한 Business Process 흐름으로 격리된 파일을 일반 사용자에게 노출하지 않으면서 상태와 감사 필드를 관리할 수 있습니다.

실제 보안 구멍을 만드는 흔한 실수

대부분 업로드 보안 실패는 복잡한 해킹이 아닙니다. 안전하지 않은 파일이 정상 문서처럼 동작하게 만드는 작은 설계 선택들이 원인입니다.

한 가지 고전적 문제는 경쟁 조건(race)입니다: 앱이 업로드를 수락하고 다운로드 URL을 반환하면 사용자가(또는 다른 서비스가) 스캔이 끝나기 전에 파일을 가져올 수 있습니다. 파일 업로드 바이러스 검사를 하면 “업로드됨(uploaded)”과 “사용 가능(available)”은 다른 상태라는 점을 명확히 하세요.

자주 반복되는 실수:

• 동일한 버킷/폴더에 clean과 quarantined 파일을 섞어 놓고 이름 규칙에 의존함. 권한이나 경로 하나 잘못되면 격리는 의미가 없음.
• 파일 확장자, MIME 타입, 클라이언트 측 검사만 신뢰함. 공격자는 아무 파일이나 .pdf로 이름을 바꿀 수 있음.
• 스캐너 다운타임을 대비하지 않음. 스캐너가 느리거나 오프라인이면 파일이 영원히 pending에 머무르고 팀은 안전하지 않은 수동 재정의를 추가하게 됨.
• 백그라운드 워커가 메인 API와 동일한 권한 검사를 건너뜀. “모든 파일을 읽을 수 있는” 워커는 조용한 권한 상승 경로가 됨.
• 격리 항목에 대해 추측하기 쉬운 ID(증가 숫자 등)를 공개함. 콘텐츠가 보호된다고 생각해도 위험함.

테스트 또한 취약점입니다. 팀은 몇 개의 작고 깨끗한 파일로만 테스트하고 끝내는 경우가 많습니다. 대용량 업로드, 손상된 파일, 암호로 보호된 문서 등도 테스트해야 합니다. 이들이 바로 스캐너와 파서가 실패하거나 타임아웃이 나는 경우입니다.

간단한 실제 예: 고객 포털 사용자가 실제로는 실행 파일이 들어 있는 아카이브를 report.pdf라고 이름 바꿔 업로드했습니다. 포털이 즉시 반환하거나 지원팀이 적절한 검사 없이 격리에 접근할 수 있다면 다른 사용자에게 직접 전달되는 경로를 만든 셈입니다.

출시 전 빠른 점검 목록

파일 업로드 바이러스 검사를 출시하기 전에 팀이 흔히 “괜찮다”고 가정했다가 나중에 문제를 발견하는 지점을 한 번 더 점검하세요. 목표는 간단합니다: 누군가가 URL을 추측하거나 요청을 재시도하거나 오래된 캐시 링크를 사용했다고 해서 안전하지 않은 파일이 읽을 수 있게 되면 안 됩니다.

사용자 흐름부터 시작하세요. 모든 다운로드, 미리보기, “파일 열기” 액션은 업로드 시점이 아니라 요청 시점에 파일의 현재 스캔 상태를 다시 확인해야 합니다. 이렇게 하면 경쟁 조건(누군가가 즉시 클릭함), 지연된 스캔 결과, 파일 재스캔 시 발생할 수 있는 엣지 케이스로부터 보호됩니다.

다음은 최소한의 사전 출시 체크리스트입니다:

• 격리 저장소는 기본적으로 비공개임: 공개 버킷 접근 없음, “링크 있는 사용자 모두” 없음, 원시 오브젝트 저장소에서 직접 제공하지 않음
• 모든 파일 레코드에 소유자(사용자, 팀, 또는 테넌트)와 pending, clean, infected, failed 같은 명확한 라이프사이클 상태가 있음
• 스캔 큐와 워커에 제한된 재시도, 명확한 백오프 규칙, 항목이 정체되거나 반복 실패할 때의 알림이 있음
• 업로드, 스캔 결과, 다운로드 시도(차단된 시도 포함)에 대한 감사 로그가 있으며 누가, 언제, 왜인지를 기록함
• 수동 재정의 기능은 드물게만 사용하며 관리자 전용이고 기록되며 시간 제한이 있음(비공개 "mark clean" 버튼 금지)

마지막으로 시스템을 끝까지 관찰할 수 있어야 합니다. 지금 몇 개의 파일이 스캔 대기 중인지, 어떤 테넌트가 실패를 겪고 있는지 답할 수 있어야 합니다. AppMaster를 사용하는 경우 Data Designer에서 파일 라이프사이클을 모델링하고 Business Process Editor에서 상태 검사를 강제하여 규칙을 웹과 모바일 전반에 걸쳐 일관되게 유지하세요.

다음 단계: 설계를 작동하는 앱으로 바꾸기

먼저 파일이 가질 수 있는 정확한 상태와 각 상태에서 허용되는 것을 한 장으로 정리하세요. 간단하고 명확하게 유지하세요: “uploaded”, “queued”, “scanning”, “clean”, “infected”, “scan_failed”. 각 상태 옆에 누가 파일을 볼 수 있고, 다운로드하거나 삭제할 수 있는지 액세스 규칙을 추가하세요.

그다음, 볼륨과 사용자 경험 목표에 맞는 접근 방식을 선택하세요. 인라인 스캔은 설명하기는 쉽지만 업로드를 느리게 만들 수 있습니다. 비동기 스캔은 문서 중심 앱에 더 잘 확장되지만 상태, 큐, "대기 중" UI가 추가됩니다.

설계에서 빌드로 옮기는 실용적인 방법은 현실적인 문서(PDF, Office 파일, 이미지, 아카이브)와 현실적인 사용자 행동(여러 업로드, 취소, 재시도)을 사용해 전체 흐름을 프로토타이핑하는 것입니다. "스캐너가 작동한다"로 끝내지 마세요. 앱이 격리된 파일을 실수로라도 제공하지 않는지 검증하세요.

일주일 안에 실행할 수 있는 간단한 빌드 계획:

• 파일 상태, 전환, 접근 규칙을 한 페이지에 정의
• 인라인, 비동기, 또는 하이브리드 중 하나를 선택하고 장단점을 문서화
• 업로드 -> 격리 저장소 -> 스캔 작업 -> 결과 콜백, 감사 로그 구현
• 사용자에게 보이는 UI 상태(대기, 차단, 실패, 승인) 구축
• 초기부터 모니터링 추가: 백로그 크기, 실패율, clean까지 소요 시간

코드 없는 툴로 빌드한다면 AppMaster는 파일 메타데이터(상태, 소유자, 체크섬, 타임스탬프) 모델링, 업로드 및 검토 화면 구축, 스캔 워크플로우 오케스트레이션을 도와 실제 제품 흐름을 조기에 테스트하게 해 줍니다. 그런 다음 권한, 저장 분리, 신뢰할 수 있는 재시도 같은 중요한 부분을 강화하세요.

마지막으로, 숫자로 무엇이 “좋다”인지 결정하세요. 출시 전에 알림 임계값을 설정해 스캔 정체와 실패 증가를 사용자보다 먼저 발견하세요.