2026-09-09

10월 1일 FAFSA 개막, 검증 서류를 언제 PDF 하나로 합치고 언제 따로 둬야 할까

미국 대학 재정지원 시즌에는 매년 마감일 두 개가 동시에 돌아가는데, 사람들이 자주 혼동합니다. 하나는 다들 뉴스로 접하는 달력 날짜입니다 — 다음 FAFSA 신청서가 일반에 공개되는 날짜로, 법으로 못박혀 있어 미뤄지지 않습니다. 다른 하나는 훨씬 조용하고 훨씬 더 기계적인 일입니다. 이미 검증(verification) 대상으로 지정된 학생은 세금·신원 관련 서류 묶음을 학교 재정지원 사무실의 특정 포털에, 정해진 형태로, 뉴스에는 거의 나오지 않는 학교 자체 마감일까지 제출해야 합니다. 이 글은 두 번째 마감일에 관한 것입니다. 페이지 단위 PDF 도구가 실제로 도움이 되는 지점이 바로 여기이고, 학생들이 (읽어보기라도 한다면) 찾게 되는 안내가 학교 웹사이트마다 서로 어긋나는 지점도 바로 여기이기 때문입니다.

움직이지 않는 날짜

공개일은 관행이 아니라 법입니다. 2023년의 참담했던 출시 이후 만들어진 고등교육법(Higher Education Act of 1965) 개정안, 이른바 FAFSA Deadline Act에 따라 미국 교육부는 매년 예외 없이 "9월 1일까지 신청서 출시를 (의회에) 확인하고, 10월 1일까지 출시해야" 합니다. 교육부는 2026–27학년도 신청서를 그 일정대로 확인했고, 2027–28학년도 FAFSA도 같은 절차를 따라 2026년 10월 1일 일반 공개를 목표로 진행되고 있습니다 — 교육부 자체 인증 절차 기준입니다.

검증은 이와는 별개의, 훨씬 조용한 시계로 돌아가고, 대부분의 학생은 이미 대상이 된 뒤에야 그 사실을 알게 됩니다. 학교들이 실제로 참고하는 매뉴얼인 2026–2027 연방 학자금 지원 핸드북의 검증 챕터는, 학생의 FAFSA 제출 요약본과 기관용 학생정보기록(ISIR)이 "학생이 검증 대상으로 선정되었는지를 표시"하며, 그 뒤 학교는 "검증 대상으로 선정된 학생에게 … 학교가 지정한 날짜까지 서류를 제출하도록 요구해야 한다"고 명시합니다. 핸드북은 학교가 학생에게 "그 절차에서 자신의 역할에 대한 명확한 설명", "제출해야 할 서류 목록", "지켜야 할 마감일과 어겼을 때의 결과"라는 세 가지를 알리도록 요구하지만, 그 서류를 실제로 어떻게 조립하느냐는 전적으로 학교 자체 포털의 몫으로 남겨 둡니다. 서로 어긋나는 안내들이 사는 곳이 바로 이 빈틈입니다.

"합쳐라"와 "합치지 마라"는 서로 다른 서류에 대한, 둘 다 맞는 말입니다

재정지원 사무실의 FAQ 페이지를 충분히 읽어 보면, 같은 주(state) 안에서도 서로 다른 사무실이 정반대로 들리는 지시를 각각 확고한 규칙처럼 적어 둔 걸 보게 됩니다. 휴스턴 대학교의 서류 업로드 안내는 "여러 페이지로 이루어진 서류는 먼저 PDF 파일 하나로 합친 뒤 업로드해야 한다"고 분명히 밝히고, 바로 여기서 중요한 예시를 듭니다 — "세금 거래명세서(tax transcript)가 6페이지라면, 그 6페이지를 전부 스캔해서 PDF 파일 하나로 저장하세요." 반면 UCF 재정지원 사무실은 겉보기엔 정반대 질문 — 필요한 서류를 전부 파일 하나로 업로드해도 되나요? — 에 이렇게 답합니다. "아니요, 권장하지 않습니다. 처리 지연을 막기 위해 필요한 서류마다 파일을 하나씩 따로 만드는 것을 권장합니다." 그러면서 부모의 세금 서류와 학생의 세금 서류를 따로 두어야 할 예시 쌍으로 들고, 각각 UCF의 파일당 3MB 상한 아래여야 한다고 못박습니다.

두 규칙은 사실 충돌하지 않습니다. 서로 다른 질문에 대한 답일 뿐입니다. 휴스턴 대학교 페이지 자체가 그 경계선을 직접 그어 둡니다 — "여러 장의 스캔 페이지가 서로 다른 할 일(To-Do List) 항목에 해당한다면, 올바른 서류가 올바른 항목에 올라가도록 반드시 나누어야 한다"고요. 두 안내를 합치면, 모든 학교가 실제로 적용하는 규칙은 하나입니다. 한 서류에 속한 페이지는 합치고, 서로 다른 요건에 답하는 서류는 따로 둔다. 6페이지짜리 거래명세서는 스캔 6번으로 쪼개진 서류 하나이니 합칩니다. 부모의 세금 신고서와 학생의 세금 신고서는 둘 다 "세금 서류"라는 점에서 비슷해 보이지만 체크리스트상으로는 서로 다른 두 항목이니, 종이 자체만 봐서는 알 수 없는 그 구분을 지켜 따로 둡니다.

어디서나, NearPDF에서도 거부당하는 파일 형식 두 가지

합칠지 나눌지의 문제 아래에는 훨씬 기계적인 두 번째 문제가 있습니다. 애초에 뭐가 "정상적인 PDF"로 인정되느냐는 것이죠. UIC 재정지원 사무실이 배포하는 짧은 서류 업로드 안내서는 파일 형식 두 가지를 이름까지 밝히며 금지합니다 — "'PDF 포트폴리오'나 '보안(Secured) PDF' 형식은 사용하지 마십시오," 그리고 별도로 "파일에 비밀번호가 걸려 있으면 안 됩니다." 같은 안내서는 병합 도구의 페이지 순서와 그대로 맞아떨어지는 규칙도 명시합니다 — "제출하는 워크시트는 서류 묶음의 첫(맨 위) 페이지여야 합니다" — 그리고 NearPDF를 열기 전에 먼저 지켜야 할 스캔 지침도 있습니다. "양면에 정보가 있는 서류는 양쪽 면을 모두 스캔하십시오."

보안 PDF는 바로 그 안내서가 따로 경고하는 비밀번호 걸린 파일이며, 동시에 NearPDF가 아예 열지 못하는 유일한 범주이기도 합니다. NearPDF의 병합·분할 엔진은 모든 파일을 pdf-lib의 PDFDocument.load()로 불러오는데, 이 호출이 파일이 암호화되어 있다고 알려오면 NearPDF는 그 파일을 조용히 빼 버리지 않고 파일 이름과 함께 "암호로 보호되어 제외되었습니다"라고 알려 줍니다(src/merge.worker.js의 loadAll() 참고). 이건 맞서 싸울 한계가 아니라 유용한 조기 경고입니다. NearPDF가 열지 못하는 파일은, UIC 안내서 자체의 규칙에 따르면, 재정지원 포털도 마찬가지로 거부할 파일입니다. 비밀번호는 스캔해서 무언가에 붙이기 전에 없애야지, 붙인 뒤에 없앨 게 아닙니다.

PDF 포트폴리오는 결이 다른, 더 은근한 실패 방식입니다. 파일 자체는 멀쩡히 열리기 때문입니다. 포트폴리오는 공유된 페이지 트리가 아니라, 표지 파일 하나 뒤에 서로 별개인 첨부 문서들을 묶어 놓은 구조입니다 — Adobe 자체의 포트폴리오 기능이 먼저 표지 화면을 보여주고, 클릭해 들어가야 각 첨부 파일을 따로 불러오는 이유가 바로 이것입니다. NearPDF의 병합·분할 도구처럼 PDF 자체의 페이지 트리를 읽는 페이지 단위 도구는, 포트폴리오 파일 스스로 노출하는 페이지 — 대개 그 표지 한 페이지 — 만 보게 되고, 그 안에 묶인 문서들은 보지 못합니다. 아마 이 점이야말로 UIC가 이 형식을 시행착오에 맡기지 않고 아예 금지한 이유일 것입니다. 학교의 접수 시스템이든 페이지 단위 도구든, 누군가 결과물을 열어 6페이지가 있어야 할 자리에 1페이지만 있는 걸 발견하기 전까지는 서류가 빠졌다는 걸 알아낼 믿을 만한 방법이 없기 때문입니다.

실제 미국 재정지원 사무실 세 곳이 요구하는 것: 같은 서류의 페이지는 합치고, 서로 다른 요건은 따로 두며, 잠기거나 포트폴리오 형식인 파일은 포털도 NearPDF도 열지 못합니다.

NearPDF로 실제 파일 만들기

빈 workspace가 아니라 스캔본에서 시작하십시오. 이미 PDF 페이지 형태로 저장된 사진이나 스캐너 결과물 — 대부분의 휴대폰 스캔 앱과 모든 평판 스캐너 소프트웨어는 기본적으로 PDF로 저장합니다 — 을 요건 하나씩 NearPDF의 workspace에 넣습니다. 병합하기 전에 해 둘 만한 작은 정리 두 가지가 있는데, 휴대폰으로 스캔한 재정 서류 묶음이라면 거의 항상 필요합니다. 비스듬하게 찍히거나 뒤집혀 찍힌 페이지는 저장하기 전에 페이지별 회전 컨트롤로 바로잡고, 양면 스캔이 단면 서류 뒤에 남긴 빈 페이지는 빈 페이지 제거 글이 설명하는 방식대로 지우는 편이 낫습니다 — 설명 없는 빈 페이지가 낀 묶음을 재정지원 사무실에 보내는 것보다는요.

한 서류의 페이지 순서가 — UIC 안내서가 요구하는 대로 워크시트나 표지가 맨 앞에 오도록 — 제대로 정렬되면, merge 도구로 그 페이지들을 파일 하나로 합칩니다. 여기서 참아야 할 부분은 거기서 더 나아가 합치는 것입니다. 부모와 학생의 세금 서류, 또는 서명한 워크시트와 별도로 요구되는 신분증 서류는, 같은 NearPDF 세션에서 둘 다 만들더라도 각자 자기 파일로 남아야 합니다. 반대편 포털이 그것들을 서로 다른 항목으로 체크하고 있기 때문입니다. NearPDF는 그 경계를 대신 지켜주지 않습니다 — 이 도구는 여러분이 넣은 페이지만 알 뿐, 학교의 체크리스트는 알지 못합니다. 그러니 PDF 하나가 어디서 끝나고 다음 PDF가 어디서 시작하는지를 정하는 것은 workspace가 아니라 체크리스트 자체입니다.

솔직한 한계

NearPDF 자체의 용량 상한은 넉넉하게 설계되어 있습니다 — 일반 데스크톱에서는 총 500MB까지, 휴대폰이나 메모리가 적은 기기에서는 파일당 50MB에 합계 100MB까지 — 이 글에 나온 학교별 상한은 전부 그보다 훨씬 낮습니다. UCF는 파일당 3MB, UIC는 5MB, 휴스턴 대학교는 PDF 하나당 25MB입니다. 그 차이가 뜻하는 방향은 한쪽뿐입니다. NearPDF 자체의 상한이 발목을 잡는 일은 사실상 없고, 발목을 잡는 건 여러분 학교의 상한일 겁니다. 그리고 NearPDF에는 압축 기능이 없어서, 병합한 뒤에 그 간극을 메울 방법이 없습니다 — 파일을 줄이는 유일한 방법은 페이지를 빼는 것뿐입니다. 합친 파일이 포털의 용량 제한을 넘는다면, 해법은 그 이후가 아니라 스캔 단계에서 찾아야 합니다. 해상도를 낮춰 다시 스캔하십시오. UIC 안내서 자체도 "읽을 수 있는 수준을 유지하는 가장 낮은 해상도로 스캔하라"고 말합니다 — 이미 페이지를 합쳐 놓은 다음 NearPDF 안에서 손볼 일이 아닙니다.

NearPDF는 포트폴리오 형식으로 오거나 이미 비밀번호가 걸려 있는 서류를 고쳐 주지도 못합니다. 둘 다 workspace에 들어오기 전에 고치거나, 잠기지 않은 평범한 형태로 다시 요청해야 합니다. 그리고 이 글의 그 무엇도 여러분이 실제로 검증 대상인지, 학교의 구체적인 체크리스트에 무엇이 들어 있는지 알려주지 않습니다 — 그 통지는 연방 학자금 지원 핸드북이 설명하는 그대로, FAFSA 제출 요약본과 재정지원 사무실에서 옵니다. PDF 도구에서 오는 게 아닙니다. NearPDF가 실제로 하는 일은, 무엇이 필요한지 이미 알고 난 뒤의 기계적인 절반입니다 — 이미 존재하는 스캔본을, 업로드 버튼에 닿기 전에, 이 글에 나온 각 규칙이 실제로 요구하는 모양으로, 전부 기기 안에서 만들어 주는 것입니다.