포트폴리오 프로젝트 링크가 자꾸 깨진다면 이렇게 고치세요

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

채용 담당자가 누른 링크부터 실제로 확인합니다

내 컴퓨터에서 열리는지는 기준이 아닙니다

포트폴리오를 제출한 뒤 프로젝트 버튼이 열리지 않거나 엉뚱한 화면으로 이동한다면, 디자인보다 먼저 신뢰가 무너집니다. 특히 채용 담당자는 회사 네트워크, 모바일 브라우저, 시크릿 모드처럼 제작자와 다른 환경에서 링크를 확인합니다. 로그인된 내 브라우저에서 정상 작동한다는 사실만으로는 공개 상태를 보장할 수 없습니다.

먼저 포트폴리오에 들어간 모든 링크를 문서로 모아 상태를 기록하세요. 프로젝트의 개념과 활용 범위를 다시 확인하고 싶다면 지식백과의 포트폴리오 설명도 참고할 수 있습니다. 링크는 작품을 장식하는 부속물이 아니라, 설명한 역량을 실제 증거와 연결하는 통로입니다.

• 대표 프로젝트 버튼: 상세 페이지와 정확히 연결되는지 확인합니다.
• 깃허브·문서 링크: 비공개 저장소나 권한 요청 화면이 나타나지 않는지 봅니다.
• 앱스토어·배포 주소: 서비스 종료 또는 국가 제한 여부를 점검합니다.
• 이메일·문의 버튼: 주소 오타와 제목 인코딩 문제를 확인합니다.

링크 점검은 제작자 계정에서 로그아웃한 상태로 시작하는 것이 가장 빠릅니다. 시크릿 창과 휴대전화 데이터망에서 각각 한 번씩 열어 보세요.

404 오류가 난다면 주소보다 배포 구조를 살펴봅니다

하위 경로와 파일명 대소문자가 흔한 원인입니다

메인 화면은 열리는데 프로젝트 상세 페이지만 404 오류가 난다면 라우팅 설정을 의심해야 합니다. 정적 호스팅은 서버가 존재하지 않는 하위 경로를 직접 요청받았을 때 첫 화면 파일로 돌려보내지 못하는 경우가 있습니다. 목록에서 클릭하면 열리지만 새로고침하면 깨지는 현상이 대표적입니다.

이미지와 PDF만 사라졌다면 파일명 대소문자도 비교하세요. 로컬 환경에서는 Project.pdf와 project.pdf를 같은 파일처럼 처리해도 배포 서버에서는 다른 경로로 판단할 수 있습니다. 폴더를 옮긴 뒤 예전 상대경로가 남았거나, 한글 및 공백이 포함된 파일명이 주소 변환 과정에서 달라지는 문제도 자주 발생합니다.

1. 오류 주소를 복사해 새 창에서 직접 엽니다.
2. 메인 페이지와 상세 경로의 응답 차이를 확인합니다.
3. 코드에 적힌 파일명과 서버의 실제 파일명을 글자 단위로 비교합니다.
4. SPA라면 호스팅 서비스의 fallback 또는 rewrite 설정을 적용합니다.
5. 수정 후 캐시를 지운 시크릿 창에서 새로고침까지 시험합니다.

주소를 임시로 메인 화면에 연결하는 방식은 피해야 합니다. 오류 표시는 사라져도 사용자가 기대한 사례를 찾지 못하므로 문제를 숨길 뿐입니다. 복구 시간이 필요하다면 버튼 옆에 점검 중이라는 문구와 대체 PDF를 제공하는 편이 더 정직합니다.

권한 요청 화면이 뜬다면 공유 설정을 분리합니다

원본 작업 공간과 제출용 사본을 구분하세요

노션, 피그마, 구글 드라이브로 프로젝트를 공유할 때 가장 흔한 고장은 권한 설정입니다. 링크를 가진 모든 사람에게 공개했다고 생각했지만 조직 계정만 접근할 수 있거나, 상위 폴더의 제한이 하위 파일에 적용되기도 합니다. 반대로 급하게 전체 공개로 바꾸다가 고객 정보와 내부 코멘트까지 노출할 위험도 있습니다.

안전한 해결법은 원본을 그대로 공개하지 않고 제출 전용 사본을 만드는 것입니다. 개인정보, API 키, 미공개 수치, 고객사 연락처를 지운 뒤 보기 전용 권한을 부여하세요. 포트폴리오는 여러 의미로 쓰이는 용어이므로 포트폴리오 관련 용어 정의처럼 맥락을 확인하되, 내 사이트에서는 직무 결과물이라는 의미가 즉시 드러나게 설명하는 것이 좋습니다.

• 로그아웃한 브라우저에서 별도 승인 없이 열리는지 확인합니다.
• 편집이 아니라 보기 전용 권한인지 점검합니다.
• 댓글, 버전 기록, 숨겨진 페이지에 민감한 내용이 없는지 살핍니다.
• 원본이 변경돼도 제출본 주소가 유지되는 구조를 선택합니다.

외부 문서가 꼭 필요한지도 질문해 보세요. 핵심 이미지와 역할, 문제, 해결 과정, 결과를 포트폴리오 본문에 담으면 외부 서비스 장애의 영향을 줄일 수 있습니다. 세부 산출물만 보조 링크로 두면 담당자는 최소한의 정보만으로도 평가를 계속할 수 있습니다.

배포 서비스가 잠든다면 첫 화면의 무게를 줄입니다

무료 호스팅의 대기 시간과 빌드 실패를 구분합니다

버튼을 누른 뒤 흰 화면이 오래 이어진다면 링크가 깨진 것이 아니라 무료 배포 인스턴스가 휴면 상태에서 깨어나는 중일 수 있습니다. 그러나 방문자는 원인을 알 수 없으므로 몇 초만 지나도 이탈합니다. 로딩이 끝나더라도 첫 화면에서 대용량 영상과 원본 이미지까지 동시에 내려받으면 프로젝트의 완성도보다 느린 경험이 먼저 기억됩니다.

호스팅 대시보드에서 최근 배포 상태와 오류 로그를 확인하세요. 빌드 명령 변경, 만료된 환경 변수, 지원이 끝난 런타임 버전 때문에 이전 배포만 남거나 새 버전이 실패할 수 있습니다. 배포 성공 표시와 실제 페이지 접근은 별개의 검증 항목이므로 둘 다 확인해야 합니다.

1. 모바일 데이터망에서 첫 화면이 표시되기까지 시간을 측정합니다.
2. 대표 이미지를 WebP나 AVIF로 변환하고 표시 크기에 맞게 줄입니다.
3. 자동 재생 영상 대신 포스터 이미지와 재생 버튼을 사용합니다.
4. 빌드 로그에서 환경 변수, 패키지 버전, 출력 폴더 오류를 확인합니다.
5. 서비스가 자주 잠든다면 정적 데모 영상이나 캡처 링크를 함께 둡니다.

유료 요금제로 바꾸기 전에 프로젝트가 서버 기능을 정말 요구하는지도 살펴보세요. 읽기 전용 사례라면 정적 페이지로 전환해 비용과 장애 지점을 동시에 줄일 수 있습니다. 서버가 필요한 시연이라면 월 이용료와 트래픽 제한을 확인하고, 링크 옆에 초기 실행이 다소 걸릴 수 있다는 안내를 짧게 표시합니다.

도메인과 보안 경고는 만료일에서 시작됩니다

HTTPS 인증서와 리디렉션을 함께 점검하세요

브라우저에 안전하지 않은 사이트라는 경고가 뜨면 대부분의 방문자는 즉시 창을 닫습니다. 도메인 자동 갱신이 실패했거나 DNS를 변경한 뒤 인증서 발급이 완료되지 않은 경우, 또는 HTTPS 페이지 안에서 HTTP 자원을 불러오는 혼합 콘텐츠가 원인일 수 있습니다. 주소창의 자물쇠 표시만 보지 말고 개발자 도구의 보안 오류도 확인해야 합니다.

www가 붙은 주소와 붙지 않은 주소를 모두 시험하고 하나의 표준 주소로 영구 이동시키세요. 예전 이력서나 채용 플랫폼에 남은 주소가 새 도메인으로 연결되는지도 중요합니다. 리디렉션을 여러 번 거치면 속도가 느려지고 일부 쿼리 주소가 사라질 수 있으므로 가능한 한 한 단계로 연결하는 편이 안전합니다.

• 도메인 등록기관의 만료일과 결제 수단을 확인합니다.
• DNS의 A, CNAME 레코드가 현재 호스팅 안내와 일치하는지 봅니다.
• HTTP, HTTPS, www 주소 네 가지를 각각 열어 봅니다.
• 이미지·폰트·스크립트 주소에 HTTP가 남아 있지 않은지 검색합니다.
• 갱신 알림을 개인 이메일과 캘린더에 이중으로 등록합니다.

도메인 이전 직후에는 지역과 통신사에 따라 반영 시간이 달라질 수 있습니다. 이 시기에는 기존 설정을 성급하게 삭제하지 말고 새 주소가 여러 네트워크에서 확인될 때까지 유지하세요.

도메인 비용은 등록기관과 확장자에 따라 달라지고 첫해 할인보다 갱신 가격이 높을 수 있습니다. 포트폴리오를 장기간 운영한다면 할인 폭보다 갱신 비용, 개인정보 보호 옵션, DNS 관리 편의성을 기준으로 선택하는 것이 현실적입니다.

수정한 링크가 계속 예전 화면을 보여준다면 캐시를 의심합니다

브라우저 캐시와 검색 결과를 따로 다룹니다

주소를 고쳤는데 내 휴대전화에서는 계속 이전 페이지가 나타나는 경우가 있습니다. 브라우저 캐시, CDN 캐시, 서비스 워커가 오래된 파일을 보관하고 있기 때문입니다. 이때 코드를 반복해서 수정하면 원인이 더 복잡해지므로, 먼저 다른 기기와 시크릿 창에서 같은 현상이 재현되는지 비교해야 합니다.

파일을 교체할 때 이름을 그대로 유지했다면 CDN이 기존 자원을 전달할 수 있습니다. 빌드 도구의 해시 파일명을 사용하거나 버전 쿼리를 붙이고, 필요한 범위만 캐시 무효화하세요. 검색 결과에 예전 제목과 설명이 보이는 문제는 페이지 고장과 다릅니다. 메타 정보를 수정한 뒤 검색 엔진이 다시 수집할 시간을 기다려야 하며 즉시 바뀐다고 약속할 수는 없습니다.

1. 시크릿 창과 다른 네트워크에서 재현 여부를 확인합니다.
2. 강력 새로고침 후 서비스 워커 등록 상태를 살핍니다.
3. 배포 결과물의 파일명이 새 버전으로 생성됐는지 확인합니다.
4. CDN 캐시는 전체가 아닌 변경 경로 중심으로 비웁니다.
5. 포트폴리오 내부 링크와 검색 결과의 노출 정보를 구분해 기록합니다.

링크 텍스트도 함께 개선하세요. ‘여기’, ‘보기’처럼 모호한 표현보다 사용자 조사 과정 보기, 반응형 웹 데모 열기처럼 목적지를 설명하면 사용자가 이동 결과를 예측할 수 있습니다. 이는 접근성을 높이고 프로젝트 키워드의 문맥을 검색 시스템에 전달하는 데도 도움이 됩니다.

로그인이 필요한 프로젝트는 완전한 복구 대상이 아닙니다

보안·계약·서비스 종료라는 경계를 표시하세요

모든 프로젝트 링크를 공개 상태로 만들 수 있는 것은 아닙니다. 회사 보안 정책, 비밀유지계약, 유료 데이터 라이선스, 퇴사 후 계정 회수 때문에 원본 접근이 불가능할 수 있습니다. 이때 권한을 우회하거나 내부 화면을 무단 공개하는 것은 포트폴리오 개선이 아니라 새로운 위험을 만드는 행동입니다.

공개할 수 없는 사례는 문제 상황과 내 역할, 의사결정 기준, 측정 가능한 결과를 익명화해 재구성하세요. 화면 대신 흐름도나 직접 만든 모형을 사용하고, 수치에는 범위 또는 변화율을 적용합니다. 투자·사업 프로젝트처럼 국가별 환경과 규제가 중요한 사례라면 미국의 투자환경 자료처럼 공신력 있는 공개 출처를 배경 정보로 연결하되, 자신이 수행하지 않은 분석을 성과처럼 표현해서는 안 됩니다.

• 로그인이 필요한 제품은 30~60초 데모 영상과 핵심 캡처를 제공합니다.
• 종료된 서비스에는 운영 기간과 종료 사실을 명시합니다.
• NDA 프로젝트는 공개 가능한 범위를 담당자에게 먼저 확인합니다.
• 팀 성과와 개인 기여를 분리하고 맡은 산출물을 구체적으로 적습니다.
• 복구할 수 없는 링크는 방치하지 말고 비활성화 사유와 대체 자료를 둡니다.

실시간 데모가 없다는 사실 자체가 치명적인 약점은 아닙니다. 다만 왜 볼 수 없는지, 무엇으로 검증할 수 있는지 설명하지 않으면 미완성으로 보일 수 있습니다. 백엔드 의존 기능, 지역 제한 앱, 보안상 공개할 수 없는 업무는 이 글의 일반적인 링크 복구법만으로 해결되지 않습니다. 그런 예외에서는 무리한 공개보다 권한을 지키면서 판단 과정과 기여 범위를 증명하는 대체 자료가 더 정확한 답입니다.