포트폴리오 프로젝트 링크 오류를 찾고 신뢰를 되살리는 순서

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

채용 담당자가 포트폴리오에서 프로젝트를 선택했는데 데모 페이지가 열리지 않거나 저장소 링크가 권한 오류를 보여 준다면, 잘 작성한 설명과 성과 수치도 확인받기 어렵습니다. 특히 제출 직전에는 내 기기에서 한 번 열어 본 것만으로 정상이라고 판단하기 쉬운데, 로그인 상태·브라우저 캐시·배포 환경·주소 변경 때문에 외부 방문자에게만 문제가 생길 수 있습니다.

이 글은 링크를 무작정 다시 붙여 넣는 대신, 오류를 재현하고 원인을 분리한 뒤 복구와 재발 방지까지 진행하는 순서를 다룹니다. 프로젝트 링크가 많은 포트폴리오라면 한 항목씩 점검하면서 바로 적용할 수 있습니다.

1. 내 화면의 정상 표시부터 의심합니다

로그아웃 상태에서 오류를 재현하는 법

가장 흔한 실수는 제작자가 이미 로그인한 브라우저에서만 포트폴리오를 확인하는 것입니다. GitHub, Notion, Figma, Google Drive처럼 권한 설정이 있는 서비스는 소유자에게 정상 화면을 보여 주면서 외부 방문자에게 로그인 요청이나 접근 거부 화면을 표시할 수 있습니다. 따라서 첫 점검은 주소를 수정하는 일이 아니라 지원자가 아닌 방문자의 조건을 만드는 일이어야 합니다.

크롬 시크릿 창이나 다른 브라우저를 열고 포트폴리오 첫 화면부터 실제 탐색 순서대로 이동해 보세요. 주소창에 데모 URL을 직접 입력하는 방식만으로는 포트폴리오 내부 버튼의 잘못된 연결, 새 창 동작, 모바일 메뉴 문제를 발견하기 어렵습니다. 휴대전화에서는 회사 와이파이가 아닌 셀룰러 통신으로도 열어 보면 특정 네트워크나 보안 설정의 영향을 구분하는 데 도움이 됩니다.

1. 현재 사용 중인 서비스에서 모두 로그아웃하거나 시크릿 창을 엽니다.
2. 포트폴리오 홈에서 프로젝트 상세 페이지로 이동합니다.
3. 데모, 소스 코드, 발표 자료, 영상 버튼을 실제로 누릅니다.
4. PC와 모바일에서 각각 로딩 결과와 소요 시간을 기록합니다.
5. 오류 화면의 문구, 발생 시각, 최종 도착 URL을 함께 남깁니다.

오류를 기록할 때는 단순히 ‘안 열림’이라고 쓰지 말고 증상을 구체화해야 합니다. 예를 들어 ‘404 응답’, ‘권한 요청 화면’, ‘무한 로딩’, ‘인증서 경고’, ‘다른 프로젝트로 이동’처럼 분류하면 다음 조치가 빨라집니다. 새 창이 잠깐 열렸다 닫히거나 앱 설치 화면으로 넘어가는 현상도 링크 오류 기록에 포함하세요.

점검 팁: 링크를 만든 사람의 화면에서 정상이라는 사실은 외부 공개가 정상이라는 증거가 아닙니다. 제출 전 검수 기준은 항상 ‘처음 방문한 비로그인 사용자’입니다.

오류 범위를 한 번에 좁히기

같은 URL을 포트폴리오 버튼, 메신저, 브라우저 주소창에서 각각 열어 보세요. 직접 입력했을 때는 열리는데 버튼에서만 실패한다면 HTML의 href 값, 상대 경로, 클릭 이벤트를 우선 확인합니다. 어디서 열어도 실패한다면 배포 서비스, 공개 권한, 도메인 또는 원본 파일 쪽 문제일 가능성이 큽니다.

• 버튼 하나만 실패: 링크 오타, 잘못된 이벤트, 겹쳐진 요소를 확인합니다.
• 프로젝트 전체가 실패: 배포 상태와 빌드 로그를 확인합니다.
• 특정 사람에게만 실패: 로그인 권한, 지역 제한, 네트워크 차단을 확인합니다.
• 모바일에서만 실패: 앱 전환 주소와 터치 영역, 리디렉션을 확인합니다.

2. 오류 문구에 따라 원인을 분리합니다

404와 403은 고치는 위치가 다릅니다

404 Not Found는 요청한 경로나 파일을 서버가 찾지 못했다는 뜻입니다. 저장소 이름을 바꾸거나 배포 폴더 구조를 수정한 뒤 예전 주소를 계속 사용했을 때 자주 발생합니다. 반면 403 Forbidden은 대상이 존재하지만 현재 방문자에게 접근 권한이 없다는 의미에 가깝습니다. 비슷하게 보이는 오류라도 주소를 고칠지, 공개 범위를 고칠지가 완전히 달라집니다.

401 또는 로그인 요청이 표시되면 인증이 필요한 자원을 공개 링크처럼 연결했는지 살펴보세요. 500번대 오류는 포트폴리오 버튼보다는 서버 실행, 환경 변수, 외부 API 장애에서 발생할 가능성이 높습니다. 연결 시간 초과나 DNS 오류라면 도메인 만료, 잘못된 DNS 레코드, 배포 서버 중단 여부를 확인해야 합니다.

개발자 도구를 사용할 수 있다면 브라우저에서 검사 창을 열고 Network 탭을 확인합니다. 빨간색 요청의 상태 코드와 요청 주소만 봐도 링크 자체가 틀렸는지, 연결된 페이지 내부의 이미지나 API가 실패했는지 구분할 수 있습니다. 코드를 잘 모르는 독자라면 오류 화면과 주소 전체를 캡처해 기록한 뒤 호스팅 서비스의 배포 이력과 대조해도 충분합니다.

열리지만 신뢰를 떨어뜨리는 반쪽 오류

페이지가 열린다고 해서 링크 점검이 끝난 것은 아닙니다. 데모의 핵심 버튼이 작동하지 않거나 샘플 데이터가 사라졌거나, 첫 화면이 20초 이상 비어 있다면 방문자는 사실상 고장으로 인식합니다. 포트폴리오는 단순한 파일 묶음이 아니라 역량을 판단하도록 선별하고 구성한 결과물입니다. 용어의 기본 맥락은 지식백과의 포트폴리오 설명에서도 확인할 수 있으며, 링크 이후의 경험까지 제출물의 일부로 봐야 합니다.

• 로딩 중이라는 표시 없이 화면이 오래 비어 있지 않은지 확인합니다.
• 테스트 계정이 만료되거나 비밀번호가 바뀌지 않았는지 확인합니다.
• 외부 API의 무료 사용량이 끝나 핵심 기능이 멈추지 않았는지 확인합니다.
• 이미지와 폰트가 혼합 콘텐츠 차단으로 누락되지 않았는지 확인합니다.
• 데모 안의 개인정보나 실제 고객 데이터가 노출되지 않았는지 확인합니다.

3. 링크 주소와 공개 권한을 안전하게 복구합니다

원본 주소를 확인한 뒤 한 곳씩 교체합니다

오류 원인을 찾았다고 모든 링크를 한꺼번에 바꾸면 새 오타가 생겨도 어느 수정에서 문제가 발생했는지 알기 어렵습니다. 먼저 프로젝트별로 ‘포트폴리오에 표시된 주소’와 ‘현재 서비스가 제공하는 공식 공유 주소’를 나란히 적으세요. 주소 끝의 슬래시, 대소문자, 저장소 이름, 브랜치 기반 경로까지 포함해 비교해야 합니다.

상대 경로를 사용한 정적 사이트에서는 현재 페이지 위치에 따라 링크 결과가 달라질 수 있습니다. 예를 들어 project/demo처럼 시작하는 주소는 상세 페이지 아래에서 예상치 못한 경로로 합쳐질 수 있습니다. 외부 데모라면 https://로 시작하는 절대 주소를 사용하고, 내부 프로젝트 상세 페이지라면 사이트의 라우팅 규칙에 맞는 주소를 선택하세요.

1. 배포 서비스나 문서 서비스에서 현재의 공식 공유 URL을 복사합니다.
2. URL을 새 시크릿 창에 붙여 넣어 원본 자체가 공개되는지 확인합니다.
3. 포트폴리오의 해당 버튼 주소만 교체하고 배포합니다.
4. 배포 완료 후 홈 화면에서 버튼을 눌러 최종 주소를 확인합니다.
5. 정상 확인이 끝난 항목에 날짜와 검사 환경을 기록합니다.

리디렉션으로 예전 주소를 새 주소에 연결할 수 있다면 기존 이력서나 채용 플랫폼에 이미 제출한 URL을 살릴 수 있습니다. 다만 리디렉션을 여러 번 연쇄하면 로딩이 늦어지고 중간 주소 하나가 만료될 때 전체 연결이 끊깁니다. 가능하면 한 번의 영구 리디렉션으로 최종 HTTPS 주소에 도착하도록 구성하고, 포트폴리오 본문에는 최종 주소를 직접 넣는 편이 안전합니다.

공개 범위는 최소한으로 열어 둡니다

권한 오류를 해결하려고 프로젝트 원본과 모든 작업 자료를 공개로 전환하는 것은 위험합니다. 채용 담당자가 확인해야 하는 범위만 공개하고, API 키·고객 정보·회사 내부 문서·유료 자산은 제거하거나 별도의 사본으로 분리하세요. 비공개 저장소를 유지해야 한다면 코드 전체 대신 핵심 구조와 본인 기여를 설명한 공개 문서, 짧은 시연 영상, 코드 발췌 이미지를 제공할 수 있습니다.

• 데모: 로그인 없이 핵심 흐름을 체험할 수 있는 샘플 환경을 제공합니다.
• 문서: 링크 보유자 또는 인터넷상의 모든 사용자가 읽을 수 있는지 확인합니다.
• 저장소: 비밀 값과 라이선스를 점검한 뒤 공개 여부를 결정합니다.
• 영상: 비공개가 아니라 링크 공개 상태인지 다른 계정에서 시험합니다.
• 디자인 파일: 편집 권한 대신 보기 전용 권한을 부여합니다.

공개 권한을 넓히는 것이 해결의 전부는 아닙니다. 검토에 필요한 증거는 열고, 보호해야 할 원본은 분리하는 것이 포트폴리오 운영의 기본입니다.

4. 데모가 고쳐지지 않을 때 대체 경로를 설계합니다

죽은 링크를 남기지 말고 상태를 설명합니다

외부 API 종료, 회사 보안 정책, 서버 비용 같은 이유로 데모를 즉시 복구할 수 없는 프로젝트도 있습니다. 이때 깨진 링크를 그대로 두고 ‘나중에 고치겠다’고 생각하면 방문자는 사정을 알 수 없습니다. 버튼을 임시로 숨기거나 비활성화하고, 대신 왜 실행 데모를 제공하지 못하는지와 무엇으로 검증할 수 있는지를 짧고 명확하게 안내하세요.

설명은 변명처럼 길어지지 않아야 합니다. ‘운영 API 종료로 라이브 데모는 제공하지 않으며, 아래 90초 시연 영상과 구현 설명에서 핵심 흐름을 확인할 수 있습니다’ 정도면 충분합니다. 회사 프로젝트라면 ‘보안상 원본 화면은 비공개이며 공개 가능한 범위로 재구성한 사례 설명입니다’라고 범위를 밝혀 오해를 줄일 수 있습니다.

• 핵심 사용자 흐름을 보여 주는 60~120초 시연 영상을 연결합니다.
• 문제, 담당 범위, 해결 방식, 결과를 한 화면의 사례 설명으로 구성합니다.
• 중요 화면에는 기능 목적과 판단 근거를 짧은 캡션으로 붙입니다.
• 기술 프로젝트라면 구조도, 주요 코드 발췌, 테스트 결과를 제공합니다.
• 복구 예정이라면 확정 가능한 경우에만 예상 시점을 표시합니다.

대체 자료도 반드시 외부 접근 상태를 점검해야 합니다. 영상이 소유자 전용이거나 PDF 다운로드에 로그인이 필요하다면 죽은 데모 링크를 다른 죽은 링크로 바꾼 것뿐입니다. 여러 형태의 창작물과 경력 자료를 목적에 맞게 선별한다는 관점은 포트폴리오의 또 다른 용어 설명과도 맞닿아 있습니다.

버튼 문구로 방문자의 기대를 맞춥니다

모든 연결을 ‘자세히 보기’라고 표시하면 방문자는 무엇이 열릴지 예측하기 어렵습니다. 버튼에는 ‘라이브 데모 실행’, ‘GitHub 코드 보기’, ‘시연 영상 보기’, ‘프로젝트 문서 읽기’처럼 목적지를 적으세요. 데모가 제한된 기능만 제공한다면 ‘샘플 데모 실행’이라고 표시해 운영 서비스와 혼동되지 않도록 합니다.

새 창을 사용하는 경우에도 일관성이 중요합니다. 외부 사이트만 새 창으로 열고 내부 상세 페이지는 같은 창에서 이동하도록 기준을 정하면 탐색이 자연스러워집니다. 새 창 링크에는 보안을 위해 rel="noopener" 속성을 적용하고, 키보드만 사용하는 방문자도 버튼에 접근할 수 있는지 확인하세요.

1. 버튼 문구만 읽어도 목적지가 예상되는지 봅니다.
2. 비활성 버튼은 클릭 가능한 색과 모양으로 오해되지 않게 바꿉니다.
3. 링크 주변에 로그인 필요 여부와 권장 환경을 표시합니다.
4. 대체 자료를 데모 버튼보다 지나치게 아래에 숨기지 않습니다.

5. 제출 뒤 링크가 다시 깨지지 않게 운영하는 방법

“이미 제출한 뒤 주소가 바뀌면 어떻게 하나요?”

가장 자주 받는 질문은 이력서와 채용 사이트에 포트폴리오를 이미 제출한 뒤 프로젝트 주소가 바뀌었을 때의 대응입니다. 핵심은 제출된 개별 프로젝트 URL을 모두 회수하려 하기보다, 내가 통제하는 포트폴리오 주소를 안정적인 허브로 유지하는 것입니다. 이력서에는 가능하면 특정 배포 서비스의 긴 주소보다 개인 도메인의 포트폴리오 홈이나 고정된 프로젝트 상세 주소를 사용하세요.

프로젝트 상세 주소를 변경해야 한다면 예전 주소에서 새 주소로 리디렉션을 설정합니다. 리디렉션 기능이 없다면 기존 상세 페이지를 삭제하지 말고 ‘프로젝트 주소가 변경되었습니다’라는 짧은 안내와 새 링크를 남기는 방법도 있습니다. 채용 담당자는 예전 메일이나 내려받은 PDF에서 접속할 수 있으므로, 새 포트폴리오만 고친 뒤 끝냈다고 생각하면 안 됩니다.

1. 지원서에 적은 포트폴리오 주소와 프로젝트 주소 목록을 확인합니다.
2. 개인 도메인과 호스팅의 만료일, 자동 갱신, 결제 수단을 점검합니다.
3. 바뀐 페이지에는 예전 주소에서 새 주소로 이동하는 경로를 남깁니다.
4. 즉시 수정할 수 없는 외부 지원서는 안정적인 포트폴리오 홈에서 연결을 보완합니다.
5. 중요한 면접 전날과 당일 아침에 비로그인 상태로 다시 검사합니다.

재발 방지를 위해 매달 한 번 또는 지원 일정 전마다 링크 점검일을 정해 두세요. 프로젝트가 네 개라면 홈, 상세 페이지, 데모, 코드, 문서 정도만 확인해도 수십 개의 연결이 생깁니다. 브라우저 확장 기능이나 링크 검사 도구를 이용하면 404와 리디렉션을 빠르게 찾을 수 있지만, 로그인 뒤에만 보이는 오류와 데모 내부 기능까지 판단해 주지는 못하므로 마지막에는 사람이 직접 핵심 흐름을 눌러 봐야 합니다.

• 매달: 전체 외부 링크의 응답과 공개 권한을 확인합니다.
• 지원 전: 지원 직무와 관련된 핵심 프로젝트를 직접 실행합니다.
• 배포 후: 캐시를 비운 브라우저와 모바일 환경에서 재검사합니다.
• 도메인 갱신 전: 결제 정보와 인증서 자동 갱신 상태를 확인합니다.
• 서비스 변경 시: 기존 주소의 리디렉션과 대체 자료를 준비합니다.

링크 상태를 기록할 때는 ‘정상’이라는 한 단어보다 검사 날짜, 기기, 브라우저, 로그인 여부, 최종 도착 URL을 남기는 편이 유용합니다. 예를 들어 ‘9월 3일, 모바일 사파리, 비로그인, 영상 재생 정상’처럼 적으면 다음 검사에서 무엇이 달라졌는지 비교할 수 있습니다. 프로젝트 설명 옆에 실제 업데이트 날짜를 과도하게 노출할 필요는 없지만, 내부 관리표에는 마지막 확인 시점을 반드시 남겨 두세요.

외부 주소가 또 바뀔 가능성이 높은 서비스라면 포트폴리오 상세 페이지를 중간 허브로 활용하세요. 이력서에는 변하지 않는 상세 페이지를 싣고, 그 안에서 데모와 코드 주소를 갱신하는 구조입니다. 그러면 이미 발송한 PDF를 다시 회수하지 못하더라도 방문자는 최신 경로에 도착합니다. 결국 링크 관리에서 중요한 것은 한 번도 장애가 생기지 않는 척하는 것이 아니라, 장애를 빠르게 발견하고 방문자가 검증을 계속할 수 있는 경로를 유지하는 능력입니다.