PDF 포트폴리오와 웹 포트폴리오, 함께 제출해 본 후기

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

채용 담당자에게 웹 주소만 보내면 세련돼 보일 것 같았고, PDF만 첨부하면 성의가 부족해 보일 것 같았습니다. 그래서 같은 프로젝트를 담은 PDF 포트폴리오와 웹 포트폴리오를 직접 만들어 여러 지원처에 함께 제출해 봤습니다. 막상 사용해 보니 두 형식은 디자인보다도 읽히는 상황, 수정 속도, 정보의 깊이에서 차이가 컸습니다.

처음에는 웹 버전을 중심으로 만들고 PDF는 화면을 그대로 옮기면 된다고 생각했습니다. 하지만 그렇게 만든 첫 PDF는 34MB가 넘었고, 작은 노트북 화면에서는 글자가 지나치게 작았으며, 인쇄하면 배경색 때문에 핵심 수치가 묻혔습니다. 반대로 PDF를 그대로 웹에 펼쳐 놓으니 페이지가 길고 탐색이 불편했습니다. 결국 같은 내용을 두 번 꾸미는 작업이 아니라, 같은 경험을 서로 다른 읽기 방식으로 번역하는 작업이라는 사실을 체감했습니다.

PDF는 빠르게 읽혔고 웹은 오래 머물게 했습니다

실제 열람 흐름에서 드러난 차이

제가 제출한 PDF 포트폴리오는 표지를 포함해 18쪽이었고 파일 크기는 최종적으로 7.6MB까지 줄였습니다. 웹 포트폴리오에는 동일한 네 개의 프로젝트를 넣되, 첫 화면에서는 프로젝트명과 역할, 핵심 성과만 보이도록 구성했습니다. 이후 지인 세 명과 현업 실무자 두 명에게 각각 두 형식을 열어 달라고 부탁하고 화면을 넘기는 순서를 관찰했습니다.

PDF를 본 사람들은 대부분 30초 안에 목차를 지나 최근 프로젝트와 성과 수치가 있는 페이지로 이동했습니다. 반면 웹을 본 사람들은 첫 화면에서 소개 문장을 읽고 카드 이미지를 선택한 뒤, 관심 있는 프로젝트 하나를 비교적 깊게 살폈습니다. PDF는 전체 경력을 훑는 데 강했고, 웹은 특정 프로젝트를 탐색하게 만드는 데 강했습니다. 어느 한쪽이 절대적으로 우수하다기보다 독자의 시간이 얼마나 있는지가 결과를 갈랐습니다.

• PDF의 장점: 다운로드 후 오프라인에서도 열 수 있고, 페이지 순서가 고정돼 전달하려는 흐름을 통제하기 쉬웠습니다.
• PDF의 단점: 작은 오탈자 하나를 고쳐도 파일을 다시 내보내고 모든 제출 링크와 첨부 파일을 확인해야 했습니다.
• 웹의 장점: 영상, 프로토타입, 상세 화면처럼 정적인 문서에 담기 어려운 자료를 자연스럽게 연결할 수 있었습니다.
• 웹의 단점: 로딩 속도와 모바일 화면, 브라우저 호환성까지 관리해야 해서 공개 후 점검할 범위가 넓었습니다.

용어 자체가 낯설다면 지식백과의 포트폴리오 설명을 먼저 살펴봐도 좋습니다. 다만 실제 채용용 포트폴리오는 작품을 모으는 데서 끝나지 않습니다. 지원 직무와 연결되는 판단 과정, 기여 범위, 결과를 짧은 시간 안에 이해시키는 설계가 필요합니다.

사용 팁: 제출처가 첨부 파일을 요구하면 PDF를 기본으로 제공하고, 표지와 마지막 페이지에 웹 포트폴리오 링크를 한 번씩 넣는 방식이 가장 안정적이었습니다. 링크만 던지는 것보다 담당자가 원하는 방식으로 먼저 열람하게 해 줍니다.

같은 프로젝트도 PDF와 웹에서 다르게 편집했습니다

PDF에는 판단 근거를 압축했습니다

처음 만든 버전에는 프로젝트마다 배경, 문제, 조사, 아이디어, 시안, 결과를 모두 넣었습니다. 내용은 충실했지만 정작 제가 무엇을 맡았는지 찾기 어려웠습니다. 두 번째 수정부터는 각 프로젝트 첫 페이지 상단에 기간·역할·기여도·사용 도구·핵심 성과를 한 줄씩 배치했습니다. 그 아래에는 문제 한 문장, 제가 내린 결정 두 가지, 결과 수치 한 가지를 우선 노출했습니다.

예를 들어 앱 개선 프로젝트에서 기존에는 사용자 인터뷰 과정을 네 페이지에 걸쳐 소개했습니다. PDF 버전에서는 “결제 이탈의 주원인이 옵션 선택 단계의 정보 과부하임을 확인했다”라고 압축하고, 인터뷰 인원과 분석 방식은 작은 보조 문장으로 내렸습니다. 대신 개선 전후 화면과 이탈률 변화가 한눈에 보이도록 구성했습니다. 읽는 사람이 더 궁금할 때 웹 버전에서 원문과 테스트 기록을 확인하도록 연결했습니다.

1. 프로젝트 첫 장에는 누구를 위한 어떤 문제였는지 80자 안팎으로 적었습니다.
2. 팀 성과와 개인 기여를 분리해 “팀이 했다”와 “내가 했다”가 섞이지 않게 했습니다.
3. 성과 수치는 기준 기간과 측정 방법을 함께 표기했습니다. 단순히 “전환율 20% 상승”이라고만 쓰지 않았습니다.
4. 보안상 공개할 수 없는 화면은 흐리게 처리하기보다 구조를 다시 그려 어떤 판단을 했는지 설명했습니다.
5. 본문 글자 크기는 실제 노트북에서 100% 배율로 읽어 보고 정했습니다. 확대해야 읽히는 설명은 과감히 줄였습니다.

웹에는 탐색할 이유를 남겼습니다

웹 포트폴리오에서는 모든 프로젝트를 같은 길이로 만들지 않았습니다. 대표 프로젝트 한 개는 조사 자료와 실패한 시안, 개선 과정까지 깊게 보여 주고, 나머지는 핵심 판단과 결과만 빠르게 확인하도록 했습니다. 모든 프로젝트가 장문이면 방문자는 선택권을 잃고, 모두 짧으면 실력을 검증할 근거가 부족해집니다. 깊게 볼 사례와 빠르게 볼 사례를 의도적으로 섞는 편이 체류 흐름에 도움이 됐습니다.

웹에만 넣은 요소는 짧은 인터랙션 영상, 프로토타입 링크, 업데이트 날짜였습니다. 다만 자동 재생 영상과 무거운 애니메이션은 제거했습니다. 첫 버전에서 19MB짜리 배경 영상을 넣었다가 모바일 데이터 환경에서 첫 화면이 늦게 뜨는 문제를 겪었기 때문입니다. 이미지는 필요한 표시 크기의 두 배 정도로 내보내고 압축했으며, 영상에는 정지 화면과 한 줄 설명을 함께 제공했습니다.

• 첫 화면: 직무 정체성, 경력 범위, 대표 프로젝트 세 개만 노출했습니다.
• 프로젝트 상세: 문제와 역할을 먼저 보여 준 뒤 과정, 결과, 회고 순서로 배치했습니다.
• 연락 영역: 이메일 주소를 복사할 수 있게 적고 PDF 다운로드 버튼을 함께 두었습니다.
• 업데이트 표시: 최근 수정일을 적어 방치된 사이트처럼 보이지 않게 했습니다.

포트폴리오가 여러 의미로 쓰인다는 점은 포트폴리오 관련 개념 설명에서도 확인할 수 있습니다. 채용 포트폴리오에서는 단순 소장 목록이 아니라 선별 기준이 중요합니다. 저는 프로젝트 수를 늘리기보다 “왜 이 사례를 보여 주는가”에 답하지 못하는 항목을 먼저 뺐습니다.

제작 시간과 비용은 웹보다 유지 관리에서 갈렸습니다

무료 도구만 써도 예상 밖의 비용이 생겼습니다

PDF는 디자인 도구의 무료 플랜으로도 충분히 제작할 수 있었고, 웹 역시 기본 템플릿과 무료 배포 범위에서 시작할 수 있었습니다. 그러나 실제 부담은 월 구독료보다 작업 시간이었습니다. 제 경우 첫 제작에는 PDF 약 14시간, 웹 약 24시간이 들었습니다. 이후 프로젝트 하나를 교체할 때 PDF는 2시간 남짓, 웹은 반응형 화면과 링크 점검까지 포함해 약 3시간 반이 필요했습니다.

유료 도구를 선택한다면 월 몇 천 원에서 몇 만 원 수준의 빌더 요금, 개인 도메인의 연간 등록 비용, 유료 서체나 이미지 라이선스가 추가될 수 있습니다. 서비스 가격은 플랜과 환율에 따라 달라지므로 결제 직전 공식 가격을 확인해야 합니다. 저는 초기에 기능이 많은 상위 요금제를 결제했지만 실제로 쓴 기능은 개인 도메인 연결과 기본 방문 통계 정도였습니다. 한 달 사용 후 필요한 기능을 적어 보고 더 낮은 플랜으로 바꾸는 편이 합리적이었습니다.

• PDF 제작 비용: 디자인 도구 구독 여부, 유료 서체, 교정 및 출력 테스트 비용을 확인했습니다.
• 웹 제작 비용: 도메인, 빌더 또는 호스팅, 저장 공간, 방문 통계 기능의 포함 여부를 따졌습니다.
• 숨은 시간 비용: 모바일 보정, 이미지 압축, 대체 텍스트 작성, 깨진 링크 검사 시간을 별도로 잡았습니다.
• 갱신 비용: 자동 결제일과 도메인 갱신 금액을 캘린더에 기록했습니다.

버전 관리가 제출 실수를 줄였습니다

가장 난감했던 순간은 지원 직무에 맞춰 고친 PDF 대신 이전 회사명이 들어간 구버전을 첨부했을 때였습니다. 이후 파일명을 “portfolio_직무_이름_월일.pdf” 형식으로 통일하고, 제출용 폴더에는 최종 파일 하나만 남겼습니다. 웹은 주소가 같아 수정 즉시 반영되는 장점이 있지만, 지원 후 내용을 크게 바꾸면 면접관이 처음 본 버전과 달라질 수 있습니다. 그래서 중요한 지원 건은 제출 당시 화면을 PDF로 별도 보관했습니다.

또한 프로젝트 성과가 바뀔 때마다 숫자만 고치지 않았습니다. 측정 기간과 표본, 제가 실제로 영향을 준 범위를 함께 다시 확인했습니다. 매출이나 전환율처럼 민감한 수치는 회사 내부 자료와 충돌할 수 있어 비율이나 구간으로 표현했습니다. 공개 권한이 애매한 자료는 팀원의 동의를 받거나, 로고와 고유 데이터를 제거한 재구성 화면으로 대체했습니다.

1. 원본 자료, 편집 파일, 제출용 PDF를 서로 다른 폴더로 나눕니다.
2. PDF의 문서 속성에서 제목과 작성자 정보가 오래된 값으로 남아 있지 않은지 확인합니다.
3. 파일을 휴대전화와 다른 운영체제에서 각각 열어 서체와 링크가 정상인지 봅니다.
4. 웹 페이지는 시크릿 창에서 열어 로그인 없이 모든 콘텐츠에 접근 가능한지 확인합니다.
5. 지원 완료 후 제출 날짜, PDF 버전, 웹 수정 이력을 간단한 문서에 남깁니다.

제가 가장 효과를 본 방법: 새 프로젝트를 추가할 때마다 전체를 다시 디자인하지 않고, 먼저 150자 소개와 대표 이미지 한 장만 교체했습니다. 면접 일정이 잡힌 뒤 관련성이 높은 사례의 상세 설명을 보강하니 업데이트 부담이 크게 줄었습니다.

이 과정에서 접근성도 함께 살폈습니다. 회색 배경 위에 연한 글자를 올린 초기 디자인은 분위기는 좋았지만 햇빛이 비치는 화면에서 거의 읽히지 않았습니다. 색 대비를 높이고 링크에 밑줄이나 명확한 버튼 형태를 적용했으며, 색상만으로 성패를 구분하던 그래프에는 텍스트 표시를 더했습니다. 멋진 화면보다 놓치지 않는 정보가 포트폴리오의 신뢰를 높였습니다.

모든 지원에 두 형식이 필요한 것은 아니었습니다

한 가지 형식에 집중하는 편이 나았던 경우

두 형식을 함께 운영해 보니 “무조건 PDF와 웹을 모두 만들어야 한다”는 주장에는 동의하기 어려웠습니다. 제출 시스템이 파일 하나만 받거나 심사자가 여러 지원자를 짧게 검토하는 공채라면, 완성도 높은 PDF 한 개가 더 효율적이었습니다. 반대로 인터랙션 디자인, 프론트엔드, 영상처럼 움직임과 실제 작동 상태가 중요한 직무에서는 웹이 강했습니다. 이때도 핵심 내용을 웹에만 숨겨 두지 않고 짧은 PDF 요약본을 함께 준비하면 전달 실패를 줄일 수 있었습니다.

시간이 일주일밖에 없는데 두 형식을 동시에 시작한다면 둘 다 어설퍼질 가능성이 큽니다. 저는 먼저 채용 공고에서 요구하는 제출 형식을 따르고, 그다음 면접에서 설명할 대표 프로젝트 하나를 완성하는 순서가 낫다고 느꼈습니다. 독자님이 지금 가진 자료는 결과 화면 위주인가요, 아니면 실제로 움직이는 프로토타입과 개발 기록이 많은가요? 답에 따라 첫 형식이 달라집니다.

• PDF부터 만들 상황: 경력 흐름이 중요하고, 정해진 순서로 짧게 설득해야 하며, 채용 시스템이 첨부 파일을 요구할 때입니다.
• 웹부터 만들 상황: 실제 작동 결과와 다양한 미디어를 보여 줘야 하고, 검색이나 개인 브랜딩까지 이어 가고 싶을 때입니다.
• 둘 다 운영할 상황: 지원 분야가 다양하고, PDF로 요약한 뒤 웹에서 근거를 확장할 프로젝트가 충분할 때입니다.
• 하나만 유지할 상황: 업데이트에 쓸 시간이 부족하거나 공개 가능한 자료가 제한적인 경우입니다.

웹이 더 전문적으로 보인다는 통념도 다시 봤습니다

실무자 피드백 중 의외였던 말은 “웹이라서 높은 점수를 주지는 않는다”였습니다. 로딩이 느리거나 메뉴가 복잡한 웹 포트폴리오는 오히려 기본기를 의심하게 만들었고, 단정한 PDF는 판단에 필요한 내용만 빠르게 전달했습니다. 반면 어떤 담당자는 PDF를 내려받는 과정 자체를 번거롭게 느꼈고, 휴대전화에서 바로 열리는 웹 링크를 선호했습니다. 독자의 환경을 모르는 이상 형식의 화려함만으로 우위를 정하기 어렵습니다.

포트폴리오라는 말이 투자 자산의 구성이라는 뜻으로도 사용되는 배경은 지식백과의 포트폴리오 항목에서 볼 수 있습니다. 채용 자료에도 비슷한 관점을 적용해 볼 만합니다. 한 가지 유형의 프로젝트만 몰아넣기보다 지원 직무에 필요한 역량을 서로 다른 사례로 증명하되, 관련성이 낮은 작업까지 무리하게 늘리지는 않는 방식입니다.

저는 현재 PDF를 제출의 출발점으로, 웹을 검증 자료의 저장소로 사용합니다. 다만 프리랜서 의뢰처럼 검색을 통해 처음 만나는 사람이 많다면 순서를 반대로 바꿀 생각입니다. PDF와 웹의 선택은 디자인 취향이 아니라 누가, 어디서, 얼마나 오래 읽는지에 대한 결정이기 때문입니다. 때로는 웹사이트를 새로 만드는 것보다 잘 편집한 여덟 쪽짜리 PDF가 더 강하고, 때로는 짧은 웹 사례 한 편이 서른 쪽 문서보다 더 많은 질문을 이끌어 냅니다.