“방문자 수만 보면 된다” 포트폴리오 분석 도구를 써보니

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

조회수는 늘었는데 연락은 오지 않았습니다

숫자 하나로는 알 수 없었던 방문자의 망설임

포트폴리오를 공개한 뒤 가장 자주 확인한 숫자는 방문자 수였습니다. 링크드인과 커뮤니티에 프로젝트 링크를 올린 날에는 조회수가 평소보다 세 배 가까이 뛰었고, 처음에는 이것만으로도 포트폴리오가 제 역할을 한다고 생각했습니다. 그러나 일주일이 지나도 협업 문의와 면접 연락은 거의 늘지 않았습니다. 사람이 들어왔다는 사실과 프로젝트를 제대로 읽었다는 사실은 전혀 달랐습니다.

그래서 한 달 동안 방문 분석 도구와 행동 분석 도구를 함께 사용해 봤습니다. 전체 방문자 수보다 유입 경로, 프로젝트별 체류 흐름, 버튼 클릭, 스크롤 깊이를 중심으로 기록했습니다. 포트폴리오라는 용어의 기본 범위가 궁금하다면 지식백과의 포트폴리오 설명도 참고할 만합니다. 단순한 작품 모음이 아니라 자신의 역량과 작업 경험을 보여주는 자료라는 관점에서 보면, 측정해야 할 대상도 조회수보다 훨씬 넓어집니다.

첫 주 기록에서 가장 놀라웠던 점은 홈 화면 방문자의 절반 이상이 대표 프로젝트를 열기 전에 이탈했다는 사실입니다. 반면 특정 프로젝트 주소로 바로 들어온 사람은 소개 문단과 결과 영역을 비교적 오래 읽었습니다. 문제는 홍보가 아니라 첫 화면에서 다음 행동을 설득하지 못한 구조에 있었습니다.

• 좋았던 점: 막연했던 이탈 원인을 화면과 행동 단위로 확인할 수 있었습니다.
• 아쉬웠던 점: 방문자가 적은 날의 수치는 우연에 크게 흔들렸습니다.
• 첫 번째 변화: 방문자 수 대신 프로젝트 열람률을 주간 핵심 지표로 삼았습니다.

조회수는 문 앞까지 온 사람을 세는 숫자입니다. 좋은 포트폴리오 분석은 그 사람이 어느 문장에서 멈추고 왜 다음 방으로 가지 않았는지 찾는 작업에 가깝습니다.

도구 두 개를 겹쳐 보니 이유가 보였습니다

유입 통계와 화면 행동은 서로 다른 질문에 답합니다

제가 사용한 방식은 유입 분석과 화면 행동 분석을 분리하는 것이었습니다. 전자는 방문자가 검색, SNS, 메신저, 채용 플랫폼 중 어디에서 왔는지 보여줬고, 후자는 어느 버튼을 눌렀으며 페이지를 얼마나 내려갔는지 알려줬습니다. 한 도구에서 모든 답을 얻으려 하면 설정은 복잡해지고 정작 필요한 판단이 흐려졌습니다.

초기 포트폴리오라면 무료 플랜이나 기본 제공 통계만으로도 충분합니다. 유료 서비스는 방문량, 데이터 보관 기간, 팀원 수에 따라 비용이 달라지므로 결제 전에 실제로 필요한 기능을 적어보는 편이 안전합니다. 저는 첫 달에는 비용을 쓰지 않고 기본 분석, 클릭 이벤트, 익명화된 화면 흐름만 시험했습니다. 방문자가 아직 많지 않은데 고급 대시보드부터 구독하면 데이터보다 도구 관리에 시간을 더 쓰는 상황이 생길 수 있습니다.

두 종류의 기록을 같은 날짜 범위로 맞춰 보니 차이가 선명했습니다. SNS에서 유입된 방문자는 첫 화면 체류가 짧았고, 채용 관련 링크에서 들어온 방문자는 프로젝트 상세와 소개 페이지를 연속해서 보는 비율이 높았습니다. 유입 경로별 의도가 다르니 동일한 첫 화면을 보여주는 것이 최선인지도 다시 생각하게 됐습니다.

• 유입 분석: 어디에서 왔는지, 어떤 페이지로 처음 들어왔는지 확인합니다.
• 행동 분석: 클릭 위치, 스크롤 깊이, 이동 순서를 살펴봅니다.
• 문의 기록: 폼 제출이나 이메일 버튼 클릭이 실제 연락으로 이어졌는지 대조합니다.
• 운영 메모: 수정한 날짜와 내용을 남겨 전후 변화를 비교합니다.

처음부터 모든 클릭을 수집할 필요는 없었습니다

포트폴리오에 맞는 네 가지 행동만 정했습니다

처음에는 로고 클릭, 메뉴 이동, 외부 링크, 스크롤, 파일 다운로드 등 눈에 보이는 행동을 전부 기록하려고 했습니다. 며칠 지나지 않아 이벤트 이름이 뒤섞였고 무엇을 고쳐야 하는지 판단하기 어려워졌습니다. 결국 포트폴리오 방문자가 취할 핵심 행동을 프로젝트 열기, 다음 사례로 이동하기, 이력서 보기, 문의 시작하기 네 가지로 줄였습니다.

이 방식의 장점은 데이터가 적어도 해석이 가능하다는 것입니다. 예를 들어 대표 프로젝트는 많이 열리는데 다음 사례로 거의 이동하지 않는다면 첫 사례가 지나치게 길거나 끝부분의 이동 버튼이 약할 수 있습니다. 이력서 버튼은 자주 눌리지만 문의가 없다면 경력 정보와 프로젝트 설명 사이에 신뢰를 깎는 불일치가 없는지 살펴볼 수 있습니다. 단순 클릭 수가 아니라 행동 사이의 연결을 보는 것이 핵심이었습니다.

포트폴리오가 작품이나 경력의 선별된 묶음이라는 개념은 또 다른 지식백과 정의에서도 확인할 수 있습니다. 모든 작업을 한꺼번에 보여주는 저장소가 아니라면, 분석 이벤트 역시 모든 움직임을 수집하기보다 작성자가 의도한 관람 순서를 검증하는 쪽이 자연스럽습니다.

1. 방문자가 가장 먼저 열어야 할 대표 프로젝트를 하나 정합니다.
2. 그 프로젝트를 읽은 뒤 기대하는 다음 행동을 한 가지 선택합니다.
3. 버튼 이름과 기록되는 이벤트 이름을 비슷하게 맞춥니다.
4. 본인 접속과 테스트 클릭은 가능한 범위에서 제외합니다.
5. 일주일에 한 번 같은 조건으로 숫자를 기록합니다.

이벤트 이름은 ‘클릭1’처럼 짓지 말고 ‘project_open’, ‘resume_view’처럼 행동이 드러나게 정하는 편이 좋습니다. 한 달 뒤에도 뜻을 바로 이해할 수 있어야 합니다.

스크롤 기록이 긴 사례연구의 약점을 드러냈습니다

끝까지 읽지 않는 독자를 탓할 수는 없었습니다

가장 공들인 프로젝트 사례는 배경, 조사, 문제 정의, 시안, 개선 과정, 성과 순서로 길게 구성해 두었습니다. 저는 내용이 충실하니 방문자도 자연스럽게 끝까지 읽을 것이라고 예상했습니다. 실제 기록에서는 문제 정의를 지나기 전에 이탈하는 경우가 많았고, 하단에 배치한 성과와 회고는 일부 방문자에게만 노출됐습니다.

처음에는 본문을 과감하게 줄였지만 체류 흐름이 크게 좋아지지 않았습니다. 두 번째 수정에서는 분량보다 순서를 바꿨습니다. 상단에 결과 화면, 맡은 역할, 작업 기간, 핵심 성과를 짧게 제시하고 자세한 과정은 그 아래에서 펼쳤습니다. 그러자 중간 영역까지 내려가는 비율이 좋아졌고, 다음 프로젝트 버튼을 누르는 움직임도 함께 늘었습니다. 긴 글 자체보다 읽을 이유를 늦게 제시한 것이 문제였습니다.

다만 스크롤 깊이를 곧바로 관심도로 해석하면 위험합니다. 모바일 화면에서는 같은 내용을 읽어도 스크롤 횟수가 많고, 화면을 빠르게 훑은 사람도 페이지 끝에 도달할 수 있습니다. 저는 스크롤 기록을 체류 시간, 핵심 버튼 클릭과 함께 봤습니다. 세 지표 중 두 가지가 같은 방향을 가리킬 때만 수정 후보로 올렸습니다.

• 상단 25%: 결과 이미지, 역할, 프로젝트 한 줄 설명을 배치했습니다.
• 중간 50%: 문제와 선택 이유를 구체적인 장면 중심으로 설명했습니다.
• 하단 75%: 검증 결과와 배운 점을 보여줬습니다.
• 마지막 영역: 다음 사례와 문의로 이어지는 선택지를 분리했습니다.

작은 수정은 한 번에 하나씩 시험했습니다

버튼 문구 하나도 날짜를 남겨야 비교할 수 있습니다

분석 도구를 설치하면 포트폴리오의 여러 부분을 동시에 고치고 싶어집니다. 저도 첫 주에 소개 문구, 썸네일, 프로젝트 순서와 문의 버튼 색상을 한꺼번에 바꿨습니다. 방문 흐름은 좋아졌지만 어떤 변경이 효과를 냈는지 설명할 수 없었습니다. 그다음부터는 한 주에 하나의 가설만 시험했습니다.

가장 효과가 분명했던 실험은 모호한 버튼 문구를 바꾼 일이었습니다. ‘더 보기’를 ‘프로젝트 과정 보기’로, ‘Contact’를 ‘협업 문의 보내기’로 고쳤습니다. 디자인은 그대로 두고 문구만 수정한 뒤 같은 기간의 행동을 비교했습니다. 방문량이 많지 않아 통계적으로 확정적인 결과라고 말할 수는 없었지만, 클릭 이후의 페이지 이동까지 함께 증가해 다음 버전에도 유지했습니다.

제가 남긴 실험표에는 날짜, 변경 위치, 가설, 관찰 지표, 결과, 다음 행동을 기록했습니다. 포트폴리오를 하나의 완성품이 아니라 지속적으로 다듬는 프로젝트로 본 것입니다. 다양한 맥락에서 쓰이는 포트폴리오의 의미는 지식백과의 관련 항목에서도 살펴볼 수 있는데, 실제 운영에서는 무엇을 담았는지만큼 그것이 목적에 맞게 전달되는지가 중요했습니다.

• 방문량이 적다면 하루 단위보다 일주일 단위로 비교합니다.
• 공휴일이나 외부 홍보가 있었던 날은 별도 메모를 남깁니다.
• 좋아진 수치만 보지 말고 다른 행동이 나빠지지 않았는지 확인합니다.

실제 연락과 연결하니 인기 프로젝트가 달라졌습니다

많이 본 작업보다 대화를 만든 작업이 중요했습니다

조회수만 놓고 보면 시각적으로 화려한 개인 프로젝트가 가장 인기 있었습니다. 하지만 면접과 협업 문의에서 자주 언급된 것은 방문 수가 상대적으로 적었던 실무 개선 프로젝트였습니다. 사용자는 화려한 화면에서 링크를 눌렀지만, 의뢰인은 문제를 어떻게 정의하고 이해관계자를 어떻게 설득했는지 설명한 사례를 기억했습니다.

그래서 문의가 왔을 때 상대방이 어떤 프로젝트를 보고 연락했는지 간단히 물었습니다. 부담을 줄이기 위해 문의 폼에는 ‘인상 깊게 본 프로젝트’라는 선택 항목을 넣고 필수 입력으로 만들지는 않았습니다. 이메일로 직접 연락한 경우에는 첫 미팅에서 자연스럽게 확인했습니다. 이 작은 질문 덕분에 온라인 행동 기록과 실제 평가 이유를 연결할 수 있었습니다.

한 달 뒤 대표 프로젝트의 순서도 바꿨습니다. 가장 많이 본 작업이 아니라 제가 받고 싶은 제안과 가까운 작업을 첫 번째에 놓았습니다. 포트폴리오 SEO 역시 넓은 방문자를 무조건 모으는 방식보다 ‘서비스 개선 프로젝트’, ‘제품 디자인 과정’처럼 실제 역량과 맞는 표현을 제목과 설명에 넣는 쪽으로 조정했습니다. 검색 유입이 조금 줄더라도 적합한 방문자가 사례를 깊게 읽는 편이 더 가치 있었습니다.

1. 문의 폼에 프로젝트 선택 항목을 선택형으로 추가합니다.
2. 미팅에서 기억에 남은 장면과 이해하기 어려웠던 부분을 묻습니다.
3. 문의자가 사용한 표현을 기록해 프로젝트 설명의 언어와 비교합니다.
4. 원하는 업무와 연결되는 사례를 첫 화면의 앞쪽으로 이동합니다.
5. 조회는 많지만 목표와 무관한 작업은 별도 아카이브로 분리합니다.

한 달 사용 뒤에도 반복하지 않게 된 세 가지 실수

수치를 많이 모으는 것보다 잘못 읽지 않는 편이 중요합니다

첫 번째 실수는 표본이 작은데도 하루 수치에 반응하는 것입니다. 방문자가 열 명 안팎인 날에는 지인 한 명의 반복 방문만으로 평균 체류 시간이 크게 바뀔 수 있습니다. 저는 최소 일주일 단위로 흐름을 보고, 외부에 링크를 공유한 날짜를 따로 표시했습니다. 숫자가 급등하거나 급락해도 원인을 확인하기 전에는 바로 레이아웃을 바꾸지 않았습니다.

두 번째는 분석 스크립트를 여러 개 설치해 속도와 개인정보 안내를 놓치는 일입니다. 기능이 겹치는 도구는 하나씩 시험했고, 사용하지 않는 코드는 제거했습니다. 화면 녹화나 세션 재생 기능을 쓸 때에는 입력 내용이 가려지는지, 문의 폼이나 이력서의 민감한 정보가 불필요하게 수집되지 않는지 먼저 확인했습니다. 방문자 행동을 알고 싶다는 이유가 과도한 수집을 정당화하지는 않습니다.

세 번째는 수치가 낮은 프로젝트를 곧바로 실패작으로 판단하는 것입니다. 제목이 불명확하거나 카드가 아래쪽에 있어 선택받지 못했을 수도 있고, 소수의 적합한 방문자에게 강한 신뢰를 줄 수도 있습니다. 삭제하기 전에 노출 위치, 설명 문구, 실제 문의 기여도를 함께 확인해야 합니다. 제가 끝까지 남긴 프로젝트도 조회수는 낮았지만 면접에서 가장 긴 대화를 만들어 냈습니다.

• 성급한 수정: 하루 수치가 아니라 일정 기간의 방향을 봅니다.
• 과도한 수집: 목적이 없는 이벤트와 화면 기록은 켜지 않습니다.
• 인기와 성과의 혼동: 조회수와 실제 문의 기여도를 분리합니다.

지금도 매주 확인하는 항목은 많지 않습니다. 대표 프로젝트 열람률, 다음 사례 이동, 이력서 확인, 문의 시작 정도면 포트폴리오의 막힌 지점을 찾는 데 충분했습니다. 방문자가 적은 개인 블로그나 Susie Kim 포트폴리오에서도 거대한 데이터 체계를 만들기보다, 고치려는 질문 하나와 그 답을 보여줄 행동 하나를 연결하는 방식이 오래 유지하기 좋았습니다.