용량을 크게 열면 검수를 생략해도 되나요?

크게 열어도 실패 문장과 확장자 허용 목록은 남아야 합니다. 상한이 없으면 대용량 파일 하나가 같은 서비스의 다른 사용자의 업로드까지 느리게 만듭니다.

현업이 쓰는 확장자를 오픈 후에 추가하면 변경인가요?

허용 목록에 날짜가 찍혀 있으면 추가는 변경입니다. 목록 자체가 없으면 오픈 후에도 미확정이라 매번 예외 처리가 됩니다.

모바일에서만 실패하면 어디를 보나요?

같은 파일을 PC와 모바일에서 각각 1건씩 봅니다. 모바일 통신 구간의 시간 제한이 더 짧으면 PC 합격만으로는 안 닫힙니다.

오류 문장에 숫자를 꼭 넣어야 하나요?

넣는 편이 문의가 줄어듭니다. 실패했습니다만 있으면 사용자는 다시 같은 파일을 올리고, 콜센터는 원인을 모릅니다.

첨부 제한 검수에 넣기 - 용량 확장자 건수와 실패 케이스

첨부 한 파일 20MB, 허용 확장자 5종, 한 건에 파일 3개. 이 세 숫자가 요구에 없으면 검수는 붙임 없는 화면으로 통과합니다. 오픈 다음 날 현업이 계약서 PDF와 사진 12장을 올리면 저장이 실패하고, 그 실패는 기능 목록에 없던 일이라 결함인지 변경인지부터 갈라지죠. 용량은 서버 설정 한 칸으로 끝나지 않습니다. 앞단 프록시, 웹 서버, 애플리케이션, 저장소가 서로 다른 한도를 가져요. 안내 문구의 한도와 서버 한도가 다르면 사용자는 오류 번호를 들고 오죠. 여기서는 네 구간의 한도를 맞추고 검수 시나리오에 실패 케이스를 넣는 순서를 적습니다. 오픈 범위를 닫기 전이라면 첨부 한 건을 실제로 올려 보시면 됩니다.

구간	예시로 볼 숫자	어긋나면
앞단 프록시	본문 크기 상한	화면 안내보다 먼저 잘림
웹 서버	요청 크기와 시간 제한	느린 업로드가 중간 실패
애플리케이션	파일당, 건당 개수, 확장자	코드와 안내 문구가 다름
저장소	일 총량과 보관 일수	디스크가 먼저 참
검수 문구	최솟값보다 1MB 작은 안내	사용자가 경계값에서 실패

첨부 한도를 맞출 때 같이 볼 네 구간

왜 오픈 다음 날에야 첨부가 터지나?

검수 시나리오에 파일이 없으면 업로드 경로는 한 번도 안 탄 기능입니다.

기능 목록의 문장은 첨부 가능으로 끝나는 경우가 많습니다. 검수에서는 본문만 저장하고 파일은 빼죠.

본문 저장이 되면 그 화면은 합격으로 남습니다. 오픈 다음 날 현업은 평균이 아니라 가장 큰 파일을 올립니다.

계약 PDF 18MB, 현장 사진 8장, 묶음 파일 1개. 합이 40MB를 넘으면 화면은 실패 코드만 보여 줍니다.

코드가 사용자 문장이 아니면 콜센터 문의가 1시간에 수십 건으로 늘어요. 검증(Validation) 항목에 파일 1건 성공과 한도 초과 1건 실패를 넣지 않으면, 이 문의는 예고된 결과입니다.

예고를 오픈 3일 전에 발견해도 한도 변경은 인프라 신청 2일이 붙습니다. 신청이 오픈 전에 안 끝나면 첫 주는 우회 접수, 곧 메일로 파일을 받는 운영이 됩니다.

한도는 왜 화면 숫자와 서버 숫자가 다른가?

앞단, 웹 서버, 애플리케이션, 저장소. 네 구간의 가장 작은 값이 실제 한도입니다.

화면에 20MB라고 적어 두고 앞단 프록시가 10MB에서 자르는 구성이 있습니다. 사용자는 15MB를 올리고 안내와 다른 오류를 보죠.

어느 구간이 잘랐는지 로그가 없으면 개발은 애플리케이션을 고치고, 애플리케이션은 죄가 없습니다. 네 구간의 숫자를 한 표에 적으세요.

프록시, 웹 서버, 애플리케이션, 저장소. 실제 허용은 넷 중 최솟값입니다.

최솟값보다 1MB 작게 안내 문구를 맞추면 경계값 다툼이 줄어요. 예를 들어 최솟값이 20MB이면 안내는 19MB, 시험은 19MB 성공과 21MB 실패.

요구사항 식별 때 현업에게 물을 숫자도 이 최솟값 기준으로 받습니다. 현업이 50MB를 원하는데 최솟값이 20MB이면, 그 차이는 인프라 변경이지 문구 변경이 아니에요.

문구만 50MB로 바꾸면 오픈 날 실패가 확정됩니다.

확장자와 개수는 어디에 적나?

허용 목록으로 적습니다. 금지 목록만 있으면 새 확장자가 계속 통과합니다.

pdf, jpg, png, xlsx, hwp처럼 업무에 필요한 확장자만 허용 목록에 넣으세요. 실행 파일과 스크립트는 목록에 없습니다.

금지 목록 방식은 빠뜨린 확장자가 곧 허용이 됩니다. 건수는 한 게시물당 파일 개수와 하루 사용자당 총량을 나누는 편이 좋아요.

개수만 3개로 제한하면 사용자는 묶음 파일 1개로 우회합니다. 총량이 없으면 3개 제한은 용량 제한을 무력화해요.

총량 60MB, 개수 5개, 확장자 5종. 이 세 숫자를 Risk(위험)에 올리기 전에 요구 ID로 고정합니다.

고정 전에 개발이 끝나면 제한은 코드에만 있고 검수 기준에는 없습니다. 기준에 없는 제한을 오픈 후 풀면, 푼 행위가 변경인지 장애 조치인지 다툼이 됩니다.

변경관리 번호 없이 한도를 올리면 다음 달 저장소 사용량이 견적과 달라집니다.

실패 케이스는 검수에서 어떻게 보나?

성공 1건보다 실패 2건이 문장을 검증합니다. 사용자가 읽는 오류 문장까지 기대값으로 적습니다.

실패 시험은 두 개면 충분합니다. 한도를 넘는 파일 1개, 허용되지 않는 확장자 1개.

기대값은 저장이 안 되는 것과, 화면에 보이는 문장입니다. 문장이 비어 있거나 영문 코드만 있으면 불합격으로 두세요.

현업은 코드를 해석하지 못합니다. 문장에는 어떤 한도를 넘었는지 숫자가 들어가는 편이 낫습니다.

예를 들면 파일당 19MB를 넘었습니다. 성공 케이스는 허용 확장자의 경계 안 파일 1개로 저장과 다시 받기를 확인하죠.

다시 받기가 안 되면 업로드는 반쪽입니다. 반쪽을 합격으로 두면 오픈 후 다운로드 장애가 따로 납니다.

바이러스 검사나 금지 파일 검사는 보안 담당의 별도 항목으로 두고, 이 글의 검수 범위는 한도와 안내 문장의 일치에 둡니다. 보안 제품의 탐지 규칙을 시험 조서에 섞으면 주체가 섞여 둘 다 안 닫혀요.

오픈 후에 한도를 올려 달라는 요청은 뭔가?

장애 조치가 아니라 요구 변경인 경우가 많습니다. 저장소와 비용 영향을 같은 주에 적습니다.

오픈 3일 차에 한도를 50MB로 올려 달라는 요청이 들어옵니다. 현장 사진이 안 올라가서죠.

사용자 불편은 맞습니다. 그래도 기준선에 19MB가 있었으면 이 요청은 변경입니다.

변경 영향은 애플리케이션 숫자 하나가 아니에요. 프록시, 타임아웃, 저장소 용량, 백업 시간이 같이 늘어납니다.

백업 창이 30분 늘어 야간 배치와 겹치면 다음날 마감이 밀릴 수 있습니다. 영향을 안 적고 숫자만 올리면 다음 달 인프라 청구가 견적과 달라져요.

임시로 특정 게시판만 올리는 방법도 변경으로 남깁니다. 임시의 종료일을 안 적으면 임시는 내년에도 남아 있습니다.

종료일이 있는 임시와, 전체 상향은 비용이 다릅니다. 그 차이를 보여 주고 발주가 고르게 하는 것이 수행사가 밤에 설정만 바꾸는 것보다 다툼이 적습니다.