개인 포트폴리오에 새 프로젝트를 추가하기 전 무엇을 확인해야 할까?

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

새 프로젝트가 끝나자마자 화면 캡처부터 올리고 싶어질 수 있습니다. 하지만 개인 포트폴리오에서 중요한 것은 작업물의 개수가 아니라, 방문자가 짧은 시간 안에 내 역할과 문제 해결 능력을 이해하도록 만드는 일입니다. 프로젝트 하나를 잘못 추가하면 기존 경력의 초점이 흐려지고, 반대로 작은 작업도 제대로 편집하면 강력한 대표 사례가 됩니다.

아래 순서는 디자이너, 개발자, 기획자, 마케터처럼 결과와 과정을 함께 보여줘야 하는 직군이 공통으로 활용할 수 있는 게시 전 점검 절차입니다. 새 사례를 무조건 공개하기보다 포트폴리오 전체에서 어떤 기능을 맡게 할지 먼저 판단해 보세요.

이 프로젝트가 포트폴리오에 들어갈 이유부터 확인합니다

작업의 크기보다 증명할 역량을 정하기

첫 질문은 “멋진 결과물인가?”가 아니라 “이 프로젝트가 나에 관해 무엇을 증명하는가?”여야 합니다. 포트폴리오는 여러 자료를 한곳에 모은 보관함이 아니라 특정 목적에 맞춰 선별한 결과물입니다. 용어의 기본 의미는 Portfolio에 관한 지식백과 설명에서도 확인할 수 있으며, 핵심은 단순 축적보다 선택과 구성에 있습니다.

예를 들어 이미 모바일 앱 UI 프로젝트가 세 편 있다면 비슷한 화면을 하나 더 추가하는 효과는 크지 않습니다. 그 대신 사용자 조사, 접근성 개선, 복잡한 이해관계자 조율처럼 기존 사례에서 부족했던 능력을 보여주는 프로젝트가 더 유용합니다. 프로젝트마다 대표 역량을 한 문장으로 적었을 때 내용이 반복된다면 새 글을 추가하기보다 기존 사례를 보강하는 편이 낫습니다.

지원하려는 직무의 채용 공고 세 개를 펼쳐 놓고 반복되는 요구 역량을 표시해 보세요. 그중 새 프로젝트가 직접 증명할 수 있는 항목이 두 개 이상이라면 게시할 이유가 충분합니다. 반대로 유명 고객이나 큰 예산만 강조되고 자신의 판단이 드러나지 않는다면, 이름값은 있어도 professional portfolio의 설득력에는 크게 기여하지 못할 수 있습니다.

• 목표 직무 적합성: 지원할 역할에서 실제로 요구하는 능력을 보여주는가?
• 기존 사례와의 차별성: 이미 공개한 프로젝트와 다른 문제 또는 책임 범위를 담는가?
• 개인 기여도: 팀의 성과와 내가 직접 수행한 일을 분리해 설명할 수 있는가?
• 증거 확보: 판단의 근거가 된 자료와 결과를 공개 가능한 형태로 제시할 수 있는가?
• 한 문장 기억점: 방문자가 이 사례를 어떤 강점으로 기억해야 하는지 말할 수 있는가?

프로젝트가 많아 보이게 만드는 것보다 서로 다른 역량을 증명하는 사례 세 편을 선별하는 편이 훨씬 강한 인상을 남깁니다.

게시 전에 공개 범위와 근거 자료를 먼저 나눕니다

보여줄 수 있는 사실과 가려야 할 정보를 구분하기

작업을 소개할 가치가 있다고 판단했다면 글을 쓰기 전에 공개 권한부터 확인해야 합니다. 회사에서 수행한 프로젝트는 본인이 제작에 참여했더라도 계약서, 비밀유지조항, 고객사 정책에 따라 화면이나 수치를 공개하지 못할 수 있습니다. 특히 출시 전 기능, 관리자 화면, 내부 매출, 사용자 개인정보, 실험군별 원자료는 허락 없이 올리지 않는 것이 안전합니다.

공개가 어려운 자료는 무조건 삭제하기보다 범위를 바꿔 설명하는 방식을 검토하세요. 실제 고객명을 업종으로 바꾸고, 정확한 수치를 비율이나 범위로 표현하며, 원본 화면 대신 정보 구조를 재구성한 도식으로 의사결정 과정을 보여줄 수 있습니다. 다만 익명 처리만으로 계약상 공개 금지가 사라지는 것은 아니므로 애매하다면 담당자에게 서면 승인을 받는 절차가 우선입니다.

근거 자료도 결과 수치만 모아서는 부족합니다. 방문자는 무엇이 얼마나 좋아졌는지뿐 아니라 그 변화가 자신의 작업에서 비롯됐다고 판단할 연결 고리를 원합니다. 문제를 발견한 자료, 선택지를 비교한 흔적, 실행 결과를 한 묶음으로 준비하면 사례의 신뢰도가 높아집니다. 포트폴리오의 활용 범위가 궁금하다면 포트폴리오 용어 해설을 참고하되, 실제 공개 가능 여부는 소속 조직의 최신 규정을 따르는 것이 맞습니다.

1. 원본 자료 목록화: 화면, 문서, 사진, 코드, 성과 데이터의 소유 주체를 적습니다.
2. 공개 등급 지정: 그대로 공개, 가공 후 공개, 공개 금지의 세 단계로 나눕니다.
3. 수치의 출처 기록: 분석 도구, 조사 기간, 표본 범위와 측정 기준을 메모합니다.
4. 대체 자료 제작: 공개 금지 화면은 흐림 처리에 의존하지 말고 일반화한 도식으로 다시 만듭니다.
5. 최종 승인 보관: 회사나 고객의 허락을 받았다면 승인 내용과 범위를 별도로 보관합니다.

성과 수치가 없을 때 사용할 수 있는 증거

모든 프로젝트에 매출 증가율이나 전환율이 있는 것은 아닙니다. 출시되지 않은 제안, 내부 도구, 개인 프로젝트라면 검증 가능한 과정의 변화를 근거로 제시할 수 있습니다. 작업 시간 단축, 오류 유형 감소, 사용자 인터뷰에서 반복된 반응, 팀이 채택한 규칙, 이후 프로젝트에서 재사용된 구성 요소가 좋은 예입니다.

• 작업 전후의 단계 수와 소요 시간
• 발견한 문제의 빈도와 우선순위 기준
• 동료 또는 사용자의 피드백을 반영한 횟수
• 폐기한 대안과 채택하지 않은 구체적인 이유
• 템플릿, 코드, 운영 규칙 등 이후에 재사용된 산출물

방문자가 빠르게 이해하도록 사례의 순서를 설계합니다

문제·역할·판단·결과를 한 흐름으로 연결하기

자료가 충분해도 전개 순서가 어수선하면 방문자는 핵심을 찾다가 페이지를 떠납니다. 첫 화면에는 프로젝트 이름보다 누구의 어떤 문제를 어떻게 바꿨는지를 먼저 보여주는 것이 좋습니다. 이어서 기간, 팀 구성, 담당 범위, 사용 도구를 짧게 제시하면 독자가 이후 내용을 해석할 기준을 얻습니다.

본문은 시간순 작업일지보다 의사결정 순서로 편집해 보세요. 조사 자료를 모두 늘어놓는 대신 어떤 관찰이 중요한 문제로 이어졌고, 그 문제 때문에 어떤 대안을 검토했으며, 최종 선택이 결과에 어떤 영향을 주었는지를 연결해야 합니다. “사용자 조사를 진행했습니다”에서 멈추지 말고 “결제 이탈자의 인터뷰에서 배송비 확인 지연이 반복되어 가격 영역의 정보 우선순위를 바꿨습니다”처럼 판단까지 밝혀야 합니다.

개인 사이트에서는 한 사례가 독립적으로 읽히면서도 전체 전문 경력과 연결되어야 합니다. Jim Samuels 같은 이름 중심의 personal site라면 사례 상단에 담당 분야를 일관된 용어로 표시하고, 하단에는 같은 역량을 다른 환경에서 보여주는 연관 프로젝트를 연결하는 방식이 효과적입니다. 방문자가 검색 결과에서 바로 들어와도 작성자의 전문 분야를 알 수 있도록 짧은 프로필 링크와 연락 경로도 함께 두세요.

좋은 사례 글은 모든 과정을 보여주는 기록이 아니라, 독자가 작성자의 판단을 재구성할 수 있을 만큼 정확한 단서를 제공하는 편집물입니다.

게시 직전 읽기 속도와 접근성 점검하기

내용을 완성한 뒤에는 휴대전화 화면에서 제목과 굵은 글씨만 훑어보세요. 그것만 읽어도 문제, 역할, 결과가 연결되지 않는다면 소제목을 다시 써야 합니다. 한 문단은 두세 문장으로 끊고, 전문 용어는 처음 등장할 때 풀어 쓰며, 링크 문구에는 “여기” 대신 이동할 페이지의 의미를 넣는 것이 좋습니다.

• 첫 화면에서 직무, 역할, 프로젝트 성격을 10초 안에 파악할 수 있는가?
• 각 이미지나 도표가 본문의 주장 하나를 실제로 뒷받침하는가?
• 색상만으로 성공과 실패, 선택과 제외를 구분하지 않았는가?
• 모바일에서 표, 코드, 긴 영문 주소가 화면 밖으로 밀려나지 않는가?
• 사례를 읽은 뒤 다음 프로젝트와 연락 페이지로 이동할 수 있는가?

프로젝트를 올린 뒤 생기는 세 가지 손실을 피합니다

맥락 없는 수치와 과도한 과정 설명 경계하기

첫 번째로 흔한 실수는 성과 수치를 크게 적으면서 기준을 생략하는 것입니다. “전환율 30% 증가”라고만 쓰면 방문자는 측정 기간, 비교 대상, 표본 크기를 알 수 없습니다. 가능하다면 “개편 후 4주간 직전 4주 대비 결제 완료율이 상대적으로 30% 증가했다”처럼 범위를 밝혀야 하며, 외부 요인이 있었다면 함께 표시하는 것이 전문성을 해치지 않습니다.

두 번째 실수는 과정의 양으로 성실함을 증명하려는 것입니다. 회의 사진, 포스트잇, 와이어프레임을 순서대로 모두 올리면 정작 중요한 판단이 묻힙니다. 각 자료 옆에 이 자료 때문에 무엇을 알았고 무엇을 바꿨는지를 설명할 수 없다면 과감히 제외하세요. 독자는 사용한 방법론의 이름보다 방법을 상황에 맞게 선택한 이유를 평가합니다.

세 번째는 새 프로젝트를 추가한 뒤 사이트 전체의 일관성을 확인하지 않는 것입니다. 새 사례에서 직무 명칭을 ‘프로덕트 디자이너’로 썼는데 소개 페이지에는 ‘UX 디자이너’, 이력에는 ‘UI 디자이너’만 적혀 있다면 전문 분야가 불분명해집니다. 게시일, 프로젝트 기간, 경력 연차, 연락처, 이력서 링크도 서로 맞는지 한 번에 대조해야 합니다.

1. 게시 당일: 시크릿 창과 모바일 기기에서 링크, 글꼴, 표의 가로 폭을 확인합니다.
2. 일주일 뒤: 유입 페이지와 이탈 지점을 살펴보고 첫 화면의 설명이 충분한지 판단합니다.
3. 한 달 뒤: 실제 면접이나 문의에서 반복된 질문을 기록해 빠진 맥락을 보완합니다.
4. 분기별: 역할, 수치, 공개 권한이 여전히 유효한지 확인하고 오래된 표현을 갱신합니다.

대표 프로젝트를 자동으로 늘리지 않기

새 글을 공개했다고 반드시 홈페이지 대표 영역에 추가할 필요는 없습니다. 대표 사례가 네 편을 넘어가면 선택 피로가 생길 수 있으므로 목표 직무와 가장 가까운 두세 편을 전면에 두고, 나머지는 아카이브나 분야별 목록에서 찾게 하는 편이 선명합니다. 최신 프로젝트라는 이유만으로 가장 위에 놓기보다 지금 원하는 기회를 가장 잘 설명하는 사례를 우선하세요.

마지막으로 삭제를 실패로 여기지 마세요. 과거 수준을 더 이상 대변하지 않거나 새 사례와 역할이 겹치는 작업은 비공개로 전환할 수 있습니다. 개인 포트폴리오의 품질은 추가한 페이지 수가 아니라 방문자가 불필요한 추측 없이 전문성과 연락 이유를 발견하는 데 걸리는 시간으로 드러납니다.

• 유명한 고객 이름만 남고 나의 기여가 보이지 않는 사례는 대표 영역에서 제외합니다.
• 출처를 설명할 수 없는 수치는 삭제하거나 검증 가능한 표현으로 낮춥니다.
• 새 프로젝트와 같은 역량을 반복하는 오래된 사례는 합치거나 아카이브로 이동합니다.