포트폴리오 만드는 법 (디자이너 & 개발자를 위한)

무엇을 넣을지 고르기

1. 1보여줄 수 있는 모든 프로젝트를 나열하세요 — 업무, 프리랜스, 사이드 프로젝트, 수업 과제, 해커톤, 오픈소스.
2. 2각각을 다음 기준으로 평가하세요: 원하는 일과의 관련성, 결과 중 당신의 기여로 주장할 수 있는 정도, 당신의 구체적인 기여를 설명할 수 있는지.
3. 3상위 3~5개를 남기세요. 많은 단서가 필요하거나 NDA 때문에 이야기할 수 없는 것은 빼세요.
4. 4세트가 폭을 보여주도록 하세요 — 같은 화면의 다섯 가지 버전이 아니라 서로 다른 유형의 문제.

케이스 스터디 구조

케이스 스터디는 형태가 정해진 짧은 이야기입니다. 독자가 2분 안에 훑고 5분 안에 끝까지 읽을 수 있는 것을 목표로 하세요.

1. 개요 (2~3문장)
   제품은 무엇이고, 누구를 위한 것이며, 프로젝트는 무엇이었는가.

2. 내 역할
   직함, 팀, 기간, 책임진 것과 기여한 것의 차이.

3. 문제
   사용자 또는 비즈니스 문제와, 그것이 실재한다는 것을 어떻게 알았는가 (데이터, 리서치, 불만).

4. 과정
   취한 3~4개의 핵심 움직임. 산출물을 보여주기: 스케치, 플로우, 프로토타입, 실험, PR.
   최소한 하나의 절충이나 막다른 길과 방향을 바꾼 이유를 포함.

5. 해결책
   최종 결과를 비주얼이나 라이브 링크와 함께. 중요한 의사결정에 주석 달기.

6. 영향
   수치가 있으면 (전환, 로딩 시간, 과제 성공률, 도입률). 없으면 정성적 결과와 다음에 측정할 것.

7. 배운 것
   솔직한 성찰 한두 가지.

개발자라면

• 모든 프로젝트에: 작동하는 라이브 데모 링크와 저장소 링크 둘 다. 깨진 데모는 데모가 없는 것보다 나쁩니다.
• 진짜 README를 쓰세요: 무엇을 하는지, 스크린샷이나 GIF, 기술 스택, 로컬에서 실행하는 법, 다음에 할 일.
• GitHub 프로필에 가장 좋은 저장소 4~6개를 고정하고 프로필 README를 추가하세요.
• 코드 품질 신호를 부각하세요: 테스트, CI, 명확한 커밋, 합리적인 구조. 검토자는 실제로 코드를 엽니다.
• 오픈소스 기여도 포함됩니다 — 병합된 PR을 링크하고 각각이 무엇을 했는지 짧게 쓰세요.
• 시각적인 것이 없는 백엔드나 데이터 역할에서는 명확한 아키텍처 다이어그램과 글로 된 설명이 스크린샷을 대신합니다.

# 프로젝트 이름
무엇을 하고 누구를 위한 것인지 한 문장.

![demo](demo.gif)

## 만든 이유
2~3문장.

## 스택
언어, 프레임워크, 주요 라이브러리, 호스팅.

## 로컬에서 실행하기
단계.

## 주요 의사결정
- 의사결정과 그 이유
- 당신이 한 절충

## 다음 할 일
짧은 목록.

디자이너라면

• 최종 시안만이 아니라 과정 산출물을 보여주세요: 리서치 메모, 사용자 플로우, 와이어프레임, 반복.
• 출시되지 않은 버전을 포함하고 이유를 말하세요 — 판단력을 보여줍니다.
• 포트폴리오 사이트 자체의 시각적 완성도를 높게 유지하세요. 의도하든 아니든 그것이 작업 샘플입니다.
• 모든 의사결정을 개인 취향이 아니라 사용자 니즈나 비즈니스 목표로 되돌려 연결하세요.
• UX 역할에서는 사고로 시작하고, 비주얼이나 브랜드 역할에서는 완성도로 시작하세요 — 다만 둘 다 둘 다 필요합니다.

어디에 호스팅할까

• 자신의 도메인에 있는 개인 사이트가 가장 강한 선택지입니다 — 완전한 통제, 진지함이 전해집니다.
• 빠르게 배포: 사이트 빌더의 템플릿, 또는 GitHub Pages, Vercel, Netlify의 간단한 정적 사이트.
• 디자이너는 도달 범위를 위해 Behance나 Dribbble로 보완할 수 있지만, 진짜 케이스 스터디는 자신의 사이트에 두세요.
• 개발자: GitHub는 필수입니다. 포트폴리오 사이트는 플러스입니다.
• 누군가 이메일로 요청할 때를 대비해 케이스 스터디 한두 개의 PDF나 슬라이드 버전을 항상 준비해 두세요.

흔한 실수

• 프로젝트가 너무 많고, 어느 것도 깊이 설명되지 않음.
• 문제 진술, 역할, 결과가 없는 스크린샷.
• 개인적으로 무엇을 했는지 말하지 않고 팀 성과를 주장하기.
• 연락처 정보가 없거나 연락할 명확한 방법이 없음.
• 채용 담당자에게 보내는 버전에 비밀번호로 보호되거나 깨진 링크.
• 가장 좋은 프로젝트를 3페이지에 묻어두기.

자주 묻는 질문