모바일 방문자를 놓치고 싶지 않은 포트폴리오라면

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

제 포트폴리오는 노트북에서 볼 때만큼은 꽤 만족스러웠습니다. 넓은 화면에 프로젝트 카드가 가지런히 놓였고, 소개 문장과 버튼의 간격도 안정적이었습니다. 그런데 지인에게 스마트폰으로 확인해 달라고 부탁한 뒤 생각이 달라졌습니다. 첫 화면의 핵심 문장은 두 번이나 줄이 바뀌었고, 프로젝트 이미지는 커 보였지만 정작 제가 맡은 역할은 화면 아래로 밀려 있었습니다.

방문 분석에서 모바일 비중이 높게 나타난다면 단순히 화면 폭만 줄여서는 부족합니다. 모바일 포트폴리오는 작은 데스크톱 페이지가 아니라 제한된 시간 안에 경력과 프로젝트를 이해시키는 별도의 경험에 가깝습니다. 제가 실제 기기에서 수정과 재확인을 반복하며 효과를 봤던 방법을 장점과 아쉬운 점까지 솔직하게 공유합니다.

손가락으로 넘겨 보니 프로젝트의 우선순위가 달라졌다

첫 화면에서 이름보다 역할이 먼저 보이게 했다

처음에는 이름, 영문 직함, 긴 자기소개, 소셜 링크를 모두 첫 화면에 담았습니다. 데스크톱에서는 풍성해 보였지만 스마트폰에서는 사용자가 프로젝트를 보기 전부터 스크롤해야 했습니다. 제 주변의 현직자 세 명에게 휴대전화를 건네고 자유롭게 보게 했더니, 두 명은 소개 문장을 끝까지 읽지 않고 바로 프로젝트를 찾았습니다.

그래서 첫 화면을 현재 역할, 해결할 수 있는 문제, 대표 프로젝트로 이동하는 버튼 순서로 줄였습니다. 이름은 브랜드를 확인할 만큼만 남기고, 긴 이력은 프로필 영역으로 옮겼습니다. 포트폴리오라는 말의 범위가 모호하게 느껴진다면 포트폴리오의 기본 개념을 먼저 살펴보는 것도 좋습니다. 작품을 모으는 데서 그치지 않고 무엇을 보여 줄지 선별한다는 관점이 모바일 구성에도 그대로 적용됩니다.

수정 후에는 대표 프로젝트까지 도달하는 스크롤 횟수가 줄었고, 지인들도 제 전문 분야를 더 빨리 말해 냈습니다. 다만 소개를 지나치게 압축하면 개성이 사라질 수 있습니다. 저는 한 문장 소개에 업종이나 기술을 나열하기보다 누구의 어떤 문제를 해결하는 사람인지를 남기는 방식이 가장 자연스러웠습니다.

• 이름: 한 줄 안에서 식별할 수 있는 크기로 표시합니다.
• 역할: 프론트엔드 개발자, 프로덕트 디자이너처럼 즉시 이해되는 표현을 씁니다.
• 핵심 가치: 경험 연수보다 해결 가능한 문제를 한 문장으로 보여 줍니다.
• 첫 버튼: ‘더 알아보기’보다 ‘대표 프로젝트 보기’처럼 목적을 명확히 적습니다.

휴대전화 첫 화면을 캡처한 뒤 다른 사람에게 5초만 보여 주세요. 직무와 강점, 다음에 누를 곳을 말하지 못한다면 정보가 부족한 것이 아니라 우선순위가 흐린 경우가 많습니다.

프로젝트 카드를 실제로 눌러 보며 고친 부분

카드 전체 클릭과 텍스트 링크를 함께 사용했다

제가 가장 먼저 발견한 문제는 작은 ‘자세히 보기’ 링크였습니다. 마우스로는 쉽게 눌렀지만 엄지손가락으로는 옆 카드나 빈 공간을 누르기 쉬웠습니다. 링크 주변을 넓히고 카드 전체를 누를 수 있게 바꾸자 이동이 편해졌습니다. 동시에 키보드 탐색과 화면 읽기 도구를 고려해 프로젝트 제목에도 명시적인 링크를 남겼습니다.

카드 안의 정보도 과감히 바꿨습니다. 이전에는 기술 스택 배지가 여섯 개씩 붙어 있었는데 작은 화면에서는 색색의 라벨만 먼저 보였습니다. 이후 프로젝트 이름, 해결한 문제, 내 역할, 확인 가능한 결과를 앞에 두고 기술은 상세 페이지로 옮겼습니다. 시각적으로는 조금 담백해졌지만 방문자가 프로젝트의 의미를 파악하는 속도는 분명히 빨라졌습니다.

여기에는 단점도 있었습니다. 카드 전체를 링크로 만들면 카드 내부에 GitHub, 데모, 상세 보기 같은 여러 동작을 섞기 어렵습니다. 저는 목록 화면에서는 상세 페이지 이동 하나만 제공하고, 외부 링크는 상세 페이지에서 분리했습니다. 한 화면에 선택지가 많을수록 친절해 보일 수 있지만 모바일에서는 잘못 누를 가능성과 판단 부담도 함께 늘어납니다.

1. 프로젝트 제목만 읽어도 결과물의 성격을 알 수 있는지 확인합니다.
2. 설명은 모바일 기준 세 줄 안팎으로 제한하되 성과 수치를 무리하게 생략하지 않습니다.
3. 누를 수 있는 영역과 단순 장식 요소가 시각적으로 구분되는지 살펴봅니다.
4. 카드를 누른 직후 이전 화면으로 쉽게 돌아갈 수 있는지 직접 시험합니다.
5. GitHub나 라이브 데모가 없다면 억지로 빈 버튼을 만들지 않습니다.

이미지보다 설명이 늦게 뜨는 상황도 시험했다

프로젝트 이미지를 고해상도로 올렸을 때 와이파이에서는 문제가 없었지만 이동통신 환경에서는 카드가 늦게 나타났습니다. 이미지를 압축하고 적절한 크기의 WebP 파일을 사용하니 체감 속도가 좋아졌습니다. 무엇보다 이미지가 불러와지지 않아도 제목과 설명은 먼저 읽을 수 있도록 구성했습니다. 포트폴리오의 핵심은 장식 이미지가 아니라 프로젝트에 관한 판단 근거이기 때문입니다.

작은 화면에서 프로필의 신뢰도를 확인한 방법

연락처와 경력을 각각 한 번의 행동으로 연결했다

프로필 영역에는 이메일, GitHub, LinkedIn, PDF 이력서를 모두 넣어 두었지만 처음 모바일 테스트를 했을 때는 아이콘만 나열돼 있었습니다. 익숙한 사람은 알아볼 수 있어도 모든 방문자가 아이콘의 의미를 정확히 아는 것은 아닙니다. 그래서 아이콘 옆에 ‘이메일 보내기’, ‘GitHub 프로젝트 보기’, ‘PDF 이력서 열기’라는 텍스트를 추가했습니다.

이메일 버튼도 직접 눌러 봤습니다. 주소만 복사하도록 만들었을 때보다 메일 앱으로 연결하는 방식이 편했지만, 공용 기기나 메일 앱을 쓰지 않는 사람에게는 불편할 수 있었습니다. 지금은 주소를 텍스트로 표시하고 복사 버튼과 메일 링크를 함께 제공합니다. 연락 수단은 멋져 보이는 방식보다 실패했을 때 대체 행동이 있는지가 중요했습니다.

경력은 긴 타임라인 대신 최근 경험부터 역순으로 배치했습니다. 회사명만 강조했을 때는 제가 실제로 한 일이 잘 드러나지 않아 각 항목 아래에 책임 범위와 변화시킨 결과를 한 줄씩 붙였습니다. 다른 분야에서 쓰이는 포트폴리오 개념 설명도 참고하면, 목적에 따라 자료의 선택과 배열이 달라져야 한다는 점을 이해하는 데 도움이 됩니다.

• 프로필 사진: 필수 요소로 생각하지 말고 직무와 공개 범위에 맞춰 선택합니다.
• 경력 항목: 회사명과 기간만 적지 말고 담당 범위와 기여를 한 줄로 덧붙입니다.
• 연락 수단: 아이콘에 텍스트 라벨을 붙이고 이메일 주소를 복사할 수 있게 합니다.
• PDF 이력서: 파일 크기와 열림 여부를 모바일 브라우저에서 직접 확인합니다.
• 외부 프로필: 오래된 계정이나 비공개 저장소뿐인 링크는 노출 전에 점검합니다.

저는 연락 버튼을 만든 날보다 한 달 뒤에 다시 눌러 봤을 때 더 많은 문제를 발견했습니다. 링크, 파일명, 공개 권한은 제작 직후가 아니라 시간이 지난 뒤에도 정상인지 확인해야 합니다.

장점만 쓰지 않고 선택의 이유를 남겼다

자기소개를 작성할 때 모든 역량을 장점처럼 포장하면 오히려 인상이 흐려졌습니다. 저는 잘하는 분야 두 가지와 현재 깊게 다루는 분야 한 가지를 분리했습니다. 덕분에 방문자는 저를 만능 인력으로 오해하지 않고, 어떤 프로젝트에서 강점을 낼 수 있는지 비교적 정확하게 파악할 수 있었습니다.

모바일 포트폴리오에서 제가 반복했던 세 가지 실수

기기 한 대에서 통과했다고 공개해 버렸다

첫 번째 실수는 제 스마트폰에서만 확인한 것입니다. 화면이 작은 기기에서는 제목이 예상보다 길게 줄바꿈됐고, 다른 운영체제에서는 사용한 글꼴이 대체 글꼴로 표시돼 버튼 너비가 달라졌습니다. 모든 기기를 보유할 필요는 없지만 브라우저의 반응형 화면 기능으로 여러 폭을 살펴보고, 가능하면 가족이나 동료의 실제 기기 두세 대에서도 확인하는 편이 좋습니다.

두 번째는 가로 폭만 확인하고 세로 공간과 고정 요소를 무시한 것입니다. 하단 고정 연락 버튼과 브라우저 메뉴가 겹치자 실제 콘텐츠가 보이는 영역이 크게 줄었습니다. 버튼을 계속 노출해야 한다면 높이를 낮추고 닫기 기능을 제공하거나, 프로젝트 상세 화면에서는 고정 상태를 해제하는 식으로 맥락을 구분해야 합니다.

세 번째는 애니메이션을 완성도의 증거처럼 여긴 점입니다. 카드가 차례로 나타나는 효과는 처음에는 세련돼 보였지만 빠르게 스크롤할 때 콘텐츠가 빈칸처럼 느껴졌습니다. 결국 움직임을 줄이고 운영체제의 동작 감소 설정을 존중하도록 수정했습니다. 시선을 끄는 효과가 프로젝트 제목과 성과를 읽는 일을 방해한다면 포트폴리오의 목적과 어긋납니다.

• 한 기기만 테스트: 최소 320px 안팎의 좁은 화면부터 태블릿 폭까지 확인합니다.
• 가로 스크롤 방치: 긴 URL, 기술명, 코드 조각이 화면 밖으로 튀어나오지 않는지 살펴봅니다.
• 고정 메뉴 남용: 헤더와 하단 버튼이 본문을 동시에 가리지 않게 합니다.
• 자동 재생 효과: 영상과 애니메이션이 데이터 사용량과 집중에 미치는 영향을 고려합니다.
• 문의 동작 미확인: 제출 성공 메시지, 오류 안내, 개인정보 입력 범위를 실제로 시험합니다.

공개 직전에는 엄지손가락 동선으로 다시 읽었다

마지막 검수 때는 개발자 도구의 점수만 보지 않고 한 손으로 처음부터 끝까지 사용했습니다. 메뉴를 열고, 대표 프로젝트를 선택하고, 상세 내용을 읽은 뒤 프로필과 연락처로 이동했습니다. 이 과정에서 뒤로 가기를 누르면 스크롤 위치가 초기화되는 문제와 작은 닫기 버튼을 발견했습니다.

모바일 대응의 장점은 방문자가 장소와 기기에 구애받지 않고 David Lee의 프로필과 프로젝트를 확인할 수 있다는 점입니다. 반면 화면이 좁기 때문에 설명을 줄이는 과정에서 중요한 맥락까지 사라질 위험이 있습니다. 문장을 무조건 짧게 자르기보다 목록에서는 판단 기준을 보여 주고 상세 페이지에서 근거를 확장하는 구조가 제 경험상 가장 안정적이었습니다. 공개 버튼을 누르기 전, 당신의 포트폴리오도 마우스를 치우고 한 손으로 끝까지 사용해 보시기 바랍니다.